在智能手机上完成一件事，常常要先完成一连串“找入口”的动作。
准备一次出行，要在地图、铁路、航班和日历之间切换；处理工作消息，要分别打开邮箱、协作平台和文档工具；想找一家附近的咖啡店，也可能需要在地图、点评与品牌应用里反复比较。
生成式 AI 已经让人与机器的交互从“点击功能”转向“描述意图”，但在手机上，很多 AI 助手仍停留在对话层：它们能给出文字建议，却没有真正接管任务的组织、信息的汇总和操作前的确认。
DigitalMate 希望提供一个统一入口，让用户提出需求、查看结果，并继续完成任务。
DigitalMate 是 openJiuwen 社区面向移动场景的一个项目，运行在 HarmonyOS 设备上。用户通过自然语言提出需求，DigitalMate 识别任务、调用相应工具与服务，并生成适合当前任务的原生界面，将不同来源的结果组织到同一任务中。
openJiuwen 社区提供 Agent 开发与运行相关的框架、工具及应用项目，社区背景可参见 openJiuwen 官方介绍：https://github.com/openJiuwen-ai。
一个请求，对应一张为任务生成的界面
传统 App 的界面在发布时就已经固定：开发者预先设计页面、按钮和流程，用户再学习如何沿着这条路径完成任务。
DigitalMate 采用了另一种思路。用户提出“帮我查明天从北京去上海的出行方式”、“看看附近有什么咖啡店”或“找出邮箱里最新的重要邮件”后，系统会针对任务实时组织信息，并生成一张可交互的原生任务界面。
DigitalMate 使用声明式的 A2UI 消息描述界面，再由 HarmonyOS 客户端从受控组件目录中完成渲染。A2UI 是面向 Agent 交互的界面协议，通过消息描述界面结构与数据，由客户端使用自己的组件呈现，协议机制可参见 A2UI 官方说明（https://a2ui.org/introduction/what-is-a2ui/）。出行任务可以展示车次和航班选项，美食任务可以展示商户卡片，涉及外部动作时则切换为确认面板。未知组件会被拒绝，工具结果、空结果和错误状态也都有明确的展示方式。
这意味着，界面可以随任务变化，但交互边界仍然由客户端掌握。
图 1｜DigitalMate 将高铁与航班结果汇总到同一任务界面，并保留结果来源。
多源信息聚合：让分散的数据围绕同一个目标协作
处理手机上的任务，从来不只是理解一句自然语言。面对“帮我规划明天的行程”、“找附近值得去的咖啡店”或“搜索 Qwen 的官方视频”这样的请求，真正有用的结果往往分散在不同平台、账号和数据结构中。用户过去需要逐个打开应用、重复输入条件，再靠自己完成筛选和对照。
DigitalMate 将多源信息聚合作为连接用户意图与真实服务的关键技术。负责理解与编排的 Agent 会先识别目标，将任务拆解为相应的信息需求，再把查询交给出行、地图、本地生活、邮件、媒体或 SaaS 等数据能力。不同来源返回的数据随后被组织为统一的任务结果，并通过 A2UI 生成适合当前场景的原生界面。
这不是把多个搜索页面简单拼在一起。DigitalMate 会围绕同一目标整理时间、地点、标题、平台和状态等核心字段，让来自不同来源的信息能够在一个视图中比较；同时保留每条结果的来源，避免聚合之后失去可追溯性。对于用户而言，原本跨应用完成的“搜索—切换—比较—确认”流程，被收拢成了一次连续交互。
在不同任务中，这套机制会呈现出不同形态：
出行聚合：分别获取高铁与航班信息，按时间等关键条件组织到同一任务界面；
本地生活聚合：连接地图、本地生活平台与品牌服务，集中展示附近商户并标注来源；
邮件聚合：汇总不同邮箱中的结果，保留账号与连接状态，并支持基于选中邮件生成可审核草稿；
媒体聚合：针对同一个搜索目标，同时呈现 B 站等平台的公开结果；
工作资料聚合：通过用户授权的连接，在 GitHub、Google Drive、Docs、Notion、Linear 等服务中查找相关资料。
图 2｜不同邮箱的结果可在同一任务界面中汇总，来源状态与异常不会被隐藏。
图 3｜同一个媒体任务可以聚合 B 站等多个视频源的公开结果。
多源聚合还必须面对真实世界中的不完整性。某个 Provider 可能尚未授权，也可能因网络、密钥或服务状态而暂时不可用。DigitalMate 不会用模型生成的内容填补这些缺口，不是编造车次、价格、餐厅、邮件或社交消息，而是展示各来源的真实状态；当部分来源失败时，已经成功返回的数据仍可继续呈现，用户也能判断结果是否完整，以及下一步需要连接哪个服务。对于一个要进入真实生活流程的 Agent 来说，“知道自己没拿到数据”与“知道答案”同样重要。
这里有一条关键原则：没有真实结果，就不伪造一个看起来合理的答案。
不只是聊天框：内容瀑布流也在学习用户的兴趣
DigitalMate 的另一种形态，是由 Agent 驱动的内容发现页。
用户可以在同一信息流里浏览来自不同内容源的卡片，也可以直接用自然语言提出新请求。系统根据用户主动打开、点赞和有效停留等信号，维护一个有界的兴趣记忆，并调整后续相似主题的检索计划。
它不会把一次快速划过简单等同于“不喜欢”，也不会让内容里的文字反过来成为操控 Agent 的指令。兴趣变化需要经过结构化决策和本地持久化，失败时保留旧状态；内容卡片与 Agent 指令之间则保持明确边界。
视频 1｜用户浏览跨来源内容，并在同一界面中请求“帮我查下深圳明天的天气”；DigitalMate 返回带来源与时间的天气结果。视频时长约 66 秒。
这段视频体现了 DigitalMate 对“Agent 入口”的理解：用户不必离开当前上下文，再去寻找天气应用或搜索框。一个自然语言请求，就可以让界面从内容消费切换到任务执行。
“关于你”：长期记忆可见，也可由用户修正
如果 Agent 每次都从零开始，它很难成为真正的数字伙伴；但如果记忆不可见、不可改，个性化又会变成新的黑箱。
DigitalMate 在用户管理页提供了“关于你”入口。系统可以把与当前账号关联的长期偏好整理为可读概览，用户也可以主动补充或修正。比如，“我点咖啡时只选燕麦奶”这样的偏好可以进入长期记忆，在后续相关任务中被召回。
记忆并不是简单堆积聊天记录。DigitalMate 会在任务需要时进行向量召回，并为记忆更新和遗忘提供明确入口；涉及删除时，仍由用户选择具体条目。账号体系也支持为现有账号增加登录方式，同时保留原有昵称和本地数据。
视频 2｜从华为账号登录进入 DigitalMate，查看手机号绑定、用户管理与“关于你”的长期记忆概览。视频时长约 24 秒。
这种设计把个性化的控制权重新交还给用户：Agent 可以逐渐了解一个人，但用户始终能够看到它形成了怎样的理解，并在理解有偏差时进行更正。
涉及外部操作，先审阅再执行
DigitalMate 通过 HarmonyOS 应用提供任务入口与交互界面。实时天气、邮件、地图和 SaaS 搜索等能力需要通过网络访问相应服务，部分能力也需要用户完成账号授权。
在外部动作上，DigitalMate 采用“先审阅，再执行”的策略：
- 邮件回复先生成草稿，不把草稿冒充为已发送；
- 日历创建、更新与删除需要清晰的目标和确认；
- 支付只在用户确认后进入相应 Provider 流程，未获得 Provider 成功结果时不会宣称支付完成；
- 导航、叫车和消息发送等动作均区分“展示入口”“等待确认”与“已经执行”；
- 网页研究不会绕过登录、验证码或访问私密内容。
这看起来比“替你全自动完成一切”更克制，却更接近 Agent 在真实设备上的产品要求。因为一旦 AI 能调用真实账号、真实数据与真实服务，最重要的能力之一，就是在正确的时刻停下来，让用户做最后决定。
从 App 中心，走向任务中心
过去十多年，智能手机的基本组织单位一直是 App。每个 App 都有自己的入口、信息结构和操作方式，用户负责在它们之间搬运上下文。
DigitalMate 尝试把这个关系反过来：用户只描述目标，Agent 负责理解任务、寻找能力、整合结果和生成界面；App 与服务退到后台，成为可被调度的工具。
它目前已经能够覆盖出行、本地生活、邮件、日历、地图、媒体、社交信息、支付入口和多种 SaaS 搜索场景。更重要的是，这套系统没有把“能回答”当作“已完成”，而是把真实数据来源、授权状态、错误反馈和用户确认共同纳入任务流程。
DigitalMate 探索的方向，是围绕用户的目标组织手机上的信息与操作。
当用户不再需要思考“该打开哪个 App”，Agent 才真正成为新的移动入口。
更多 DigitalMate 项目进展与产品动态，可关注 openJiuwen 社区。
相关资源
- openJiuwen 官网（https://www.openjiuwen.com/）：平台与社区信息。
- openJiuwen GitHub 社区页（https://github.com/openJiuwen-ai）：社区介绍及已公开项目列表。
- openJiuwen 官方文档入口（https://docs.openjiuwen.com/docs-page）：平台开发文档与使用指南。
- A2UI 官方说明（https://a2ui.org/introduction/what-is-a2ui/）：声明式界面消息与客户端渲染机制。
上述链接分别用于介绍社区背景与协议机制；DigitalMate 的具体能力以对应产品版本和演示为准。
