正在加载，请稍候
鸿蒙 AI 应用架构的四层切分、端 A2A 与云 A2A 的选型标准，以及意图注册为什么是发布契约而非代码问题。
把鸿蒙端当成又一个客户端来排期，是最容易超预算的立项错误。它有一套独立的意图发布契约，架构账单往往在第一次上架时才显形。
鸿蒙 AI 应用架构建议分四层：意图接入层、智能体编排层、系统能力层、数据与权限层。四层里只有最上面的意图接入层是鸿蒙独有的，其余三层可以和你已有的安卓、iOS 或 Web 端共用同一套设计。
这样切分的好处是可报价、可分工。华为在 Harmony Intelligence 里把能力归到「小艺开放平台的 Agent 与 Skill 能力、系统开放能力、鸿蒙智能体框架 2.0、系统应用的 AI 能力」几条线（华为 HarmonyOS 开发者，页面更新于 2026-10-26），工程上正好对应下面这张表。
| 分层 | 职责 | 鸿蒙侧落点 | 能否跨端复用 |
|---|---|---|---|
| 意图接入层 | 把应用功能声明成系统可调用的意图，接住外部拉起 | insight_intent.json、意图装饰器、InsightIntentExecutor | 否，鸿蒙独有 |
| 智能体编排层 | 对话逻辑、工作流、知识库、工具调用 | 端 A2A 或云 A2A | 大部分可复用 |
| 系统能力层 | OCR、语音识别合成、自然语言理解等原子能力 | Vision Kit、Speech Kit、Natural Language Kit 等 | 抽象层可复用，实现需替换 |
| 数据与权限层 | 账号授权、会话状态、敏感数据边界 | 端侧存储 + 授权链路 | 可复用设计，不可复用代码 |
四层里最容易被低估的是编排层。它真正的工作量不在提示词上，而在长期记忆、工具注册与多轮状态的一致性——这部分取舍我们单独写过一篇智能体长期记忆的三种架构与工程取舍，选型时可以对照着看。另一个常见错位是把编排层和数据权限层混在一层里做，结果权限变更要改整个工作流，这个问题在企业 Agent 的隐性瓶颈不是模型，而是「工作区」里有更细的拆解。
端 A2A 把智能体之间的协作放在设备侧完成，换来的是更低响应延迟与端侧隐私安全；云 A2A 用云端协议对接既有 Agent 服务，省端侧算力但依赖网络。选型标准只有一条：这条链路是否触及个人敏感数据、是否要求弱网可用。
官方对两种模式的定位是：端 A2A（端侧 Agent-to-Agent 接入）主打「极致响应与端侧隐私安全无缝协作」，云 A2A 主打「基于云端协议快速对接现有 Agent 服务」（同前引华为页面）。官方还给出了一个云 A2A 的实践范例——京东 Agent，覆盖 Agent 创建配置、会话交互、账号授权全流程。这提示了一件事：跨主体协作优先走云侧，因为授权与账号体系本来就在云上。
| 维度 | 端 A2A | 云 A2A |
|---|---|---|
| 响应延迟 | 低，不走网络往返 | 取决于网络与服务端 |
| 隐私边界 | 敏感数据可不出设备 | 数据需上行，依赖云端合规 |
| 端侧算力占用 | 高 | 低 |
| 对接存量 Agent | 需要端侧重写编排 | 直接复用既有服务 |
| 适合场景 | 个人数据、弱网、即时反馈 | 跨企业协作、重推理、长流程 |
实操上不必二选一。常见切法是：设备侧完成意图理解、参数补全与结果呈现，重推理与知识检索留在云侧；一次会话里两段各走各的通道，互不阻塞。真正决定架构形态的往往是端侧内存预算——一旦要在本机跑模型，就得先划一条降级线，具体算法可以参考给鸿蒙端 AI 划一条降级线里的预算思路。
因为意图在鸿蒙里不是运行时才决定的事：它要提前按标准 Schema 声明，整包只有一个声明文件，还必须随应用上架到应用市场后才生效。这意味着「意图」是产品与上架的契约，改它等于改发布物。
src/main/resources/base/profile/insight_intent.json，且整个工程中只能存在一个（华为 Intents Kit 接入方案）。多模块并行开发时，这个单文件是最容易产生合并冲突的地方。把这几条当成验收清单用，比当成开发文档用有效：上架阶段九成的返工都发生在这里，而它们和代码质量无关。
下面是一条参考实施路径，用于说明四层如何落到代码，不是我们已交付项目的复盘。前置条件是：智能体已开发、应用已关联、设备已登录华为账号并处于联网状态——这是华为对 Function 组件拉起智能体的明确要求（Agent Framework Kit 开发指南，更新于 2026-09-07）。
Index.ets 引入 @kit.AgentFrameworkKit 的 FunctionComponent 与 FunctionController，挂应用内入口；加载前先用 isAgentSupport 判断 agentId 是否可用，无效就别渲染。这条路径里，真正需要鸿蒙专属人力的只有第 2、4、5 步；业务价值集中在第 3 步。排期时把预算压在编排层，比压在端侧 UI 更划算。至于交付后怎么判定「做完了」，我们另有一份鸿蒙端工程落地的六个验收口径，可以直接拿去做验收表。
截至 2026-10-26，蓝曜炬辉已发布的交付案例共 7 个，全部为 2026 年项目；行业分布是人工智能 2 个、企业服务 2 个、教育培训 2 个、文旅消费 1 个。样本里没有鸿蒙端项目，所以本文架构部分给的是参考方案，不是交付复盘——这个边界必须先讲清楚。
这组分布本身有个可用信号：找我们做 AI 应用的企业，集中在已经完成业务数字化的行业，且主力入口仍在 Web 与内部系统。对这类企业的建议顺序是——先把后端的 Agent 编排、工具调用与数据层做扎实，再把鸿蒙端作为第二入口增量接入，而不是把鸿蒙端当成一个新战场从零立项。
反过来的情况也一样：如果你已经有一个稳定运行的智能体服务，接鸿蒙端的增量成本主要落在意图声明与上架合规上，属于可预估的范围；如果你还没有编排层，先补后端。想看我们怎么做后端与数据层，可以看交付案例；要评估鸿蒙端接入的工作量，直接联系我们聊场景更有用。我们是广州的团队，服务粤港澳大湾区与全国远程协作。
不一定，取决于你要的是「系统级入口」还是「应用内能力」。只调用 Vision Kit、Speech Kit 这类原子能力不需要智能体；一旦要让外部或系统把小艺当成入口拉起你的功能，就需要创建智能体、关联应用并走审核。
不能。该文件必须位于指定 profile 目录，且整个工程只能存在一个，多模块团队需要把它当作共享的单一真源来管理，否则会在合并与上架时反复返工。
可以，而且多数生产形态就是混用：端侧负责意图理解、隐私敏感数据与即时反馈，云侧负责重推理、跨系统协作与知识检索，两条通道互不影响各自的可用性。
没有可引用的公开工时统计，我们的案例库也只有 7 个非鸿蒙项目，因此不给具体工期数字。可控的做法是把排期切成两段：端侧与意图联调、意图注册与上架审核，后者受审核节奏影响，不宜压缩。