在已有应用中接入智能体时，我通常会先问一个问题：用户需要的是一个新的聊天界面，还是希望现有业务能够被更方便地调用？

如果应用中的数据、状态和操作主要位于设备端，那么端 A2A 就值得重点评估。HarmonyOS 7 支持已有 Agent 通过 A2A 等方式接入系统级智能入口，端侧方案则需要重点考虑应用内能力、系统交互、权限与数据边界。

这次我以一个个人知识管理应用为例。应用中已经有本地笔记、标签和收藏功能，我希望用户能够通过自然语言查找笔记，并在确认后执行收藏或整理操作。

先定义哪些能力可以被调用👈

我不会把整个应用的页面直接交给智能体，而是先建立一层受控的业务接口。查询笔记可以只读执行；修改标签、删除内容或导出文件则需要更严格的校验和确认。

例如，可以先在应用业务层定义查询条件：

interface NoteQuery {
 keyword?: string;
 tag?: string;
 onlyFavorites?: boolean;
}
interface NoteSummary {
 id: string;
 title: string;
 tags: string[];
 favorite: boolean;
}
interface NoteRepository {
 search(
 query: NoteQuery
 ): Promise<NoteSummary[]>;
}

这段代码是应用侧的数据访问接口，不是端 A2A 的系统接口。它的作用是将笔记查询能力与 UI、Agent 交互层分离。正式接入时，需要按目标 SDK 和平台文档实现相应的 Agent Extension Ability、通信机制及能力注册。

这样设计有两个好处：一是应用内部页面和系统智能入口可以复用相同的业务逻辑；二是智能体只能访问明确开放的能力，不会因为获得一个自然语言请求就自动拥有整个应用的数据权限。

处理好查询上下文与用户授权👈

假设用户提出“找出上个月整理的机器学习笔记”，系统可能需要解析关键词和时间范围，再由应用执行本地查询。如果日期不明确，或者有多个相似结果，应优先展示候选项，而不是返回一个未经验证的确定答案。

如果应用支持本地数据检索，我会尽量在应用内完成数据过滤，只向智能体交互层返回完成当前任务所需的信息。笔记正文、附件和其他敏感字段不应该因为构建上下文而被无差别传递。

还要特别注意，端侧执行不等于天然安全。应用仍然需要校验调用方、授权范围和参数，避免其他模块通过不受控的入口访问私有数据。日志中也不应直接输出完整的笔记正文或敏感内容。

UI Extension 决定了任务能否顺畅完成👈

如果系统智能体只返回“找到三条笔记”，用户还需要重新打开应用定位内容，体验仍然不够连贯。

在平台允许的交互形式下，应用可以考虑向智能体对话提供结构化结果，例如笔记标题、标签、时间和继续操作的入口。涉及修改数据时，再通过明确的确认步骤完成操作。

我会重点测试应用处于前台、后台或未启动状态时的调用表现，同时覆盖无搜索结果、重复请求、权限不足和应用数据更新等场景。对于系统入口能够触发哪些生命周期行为，也需要按照对应 SDK 规范验证，不能仅凭应用内部调用成功就认为端 A2A 已经接通。

这次实践让我意识到，端 A2A 不是简单地把应用功能搬到系统对话中，而是重新定义应用能力的边界。将本地数据、业务逻辑、交互展示和系统调用分层处理，才能在提升可达性的同时，保持原有应用的安全性与可维护性。