用户说：“帮我完成评论巡检设置。”
从表面看，这像是一句可以直接交给大模型的指令。模型识别出“评论巡检”，判断用户想完成初始化，再生成一套表单，似乎就能把任务做完。
但只要往后多走一步，问题就出现了：巡检哪些项目和笔记？用户能看到哪些数据？缺少参数时怎么补？保存前是否需要确认？写入失败后保留哪些输入？完成后，下次进入会话应该看到原表单，还是看到结果摘要？
这些问题里，只有一部分需要模型理解。剩下的大部分，需要确定的流程、真实的数据和明确的状态。
智投内部方案选择的不是“让大模型从头到尾生成页面”，而是一条混合路线：模型理解意图，Skill 推进步骤，业务 API 提供权威数据和写操作，前端 Renderer 用可信组件完成交互。
我的判断是：这不是为了少用模型，而是为了把模型用在更值钱的地方。
一句话之后，模型只完成了第一步
以内部方案中的评论巡检设置为例，一条完整链路可以拆成：
图中的循环不是一条只进不出的流水线：模型负责理解与解释，工程系统负责把用户动作收敛为业务结果，再把结果交还给用户。
这里最容易混淆的，是“模型理解了任务”和“系统完成了任务”。
模型可以判断用户大概率想设置评论巡检，也可以建议一组巡检规则。但项目列表、笔记范围、账户权限和最终保存结果，不能由模型根据上下文猜出来。按钮变成“已完成”，也不能代替业务系统的成功回执。
因此，Agent 产品的第一条职责边界应该是：模型输出推动流程，业务回执结束流程。
这条边界看起来偏工程，实际是产品问题。它决定了用户看到的是一段“看起来已经做完”的回答，还是一个真正可追溯、可恢复的业务结果。
四层职责：不是谁更智能，而是谁更适合
智投内部方案可以拆成四层。
| 层 | 主要职责 | 不应该承担 |
|---|---|---|
| 模型 | 理解意图、发现不确定性、语义推荐、解释原因 | 猜权限、伪造业务结果、决定不可关闭的红线 |
| Skill / 规则 | 推进步骤、检查必填、处理分支、控制回退 | 替代业务系统保存真实数据 |
| 业务 API | 返回权限内数据、执行写操作、提供权威回执 | 决定如何向用户解释复杂结果 |
| Renderer | 稳定渲染组件、本地校验、显隐和即时反馈 | 根据非法指令“猜着画”、把前端状态当成业务状态 |
这四层不是传统的“AI、前端、后端”换个名字。它们按两个问题重新划分责任：
- 这一步需要处理不确定性，还是执行确定规则？
- 这一步给出的是建议，还是权威结果？
意图理解、推荐和解释没有唯一答案，模型更有价值。字段必填、权限校验、预算变更和业务保存有明确规则，工程系统更可靠。
产品经理在评审 Agent 方案时，可以少问一句“这里能不能也让模型做”，多问一句：“如果模型这次答错，谁来发现，谁来兜底，用户会损失什么？”
九类 UI 指令，定义的是 Agent 的动作空间
智投内部规范定义了九类 UI 指令：
- 收集：
collect、select、upload - 过程：
processing、message - 决策：
review、confirm - 结果：
complete、error
乍看之下，这很像传统组件库：表单、选择器、进度、确认框、完成页和错误页都提前做好了，大模型似乎没有“生成界面”。
但 A2UI 的关键从来不是让模型每次发明一个新页面。官方 A2UI 允许确定性 Agent 返回预制界面。真正重要的是：Agent 能否用结构化协议表达“现在需要什么交互”，客户端能否用可信组件完成渲染，用户操作能否以明确语义回到任务流程。
智投的九类指令正是在做这件事。它们不是九张固定页面，而是九种业务交互意图。
更重要的是，前端回传的动作也有明确区分：表单和选择结果用 submit，二元决策用 confirm，进行中的自由输入用 freeform，中断、续做和重开分别使用 interrupt、resume、revisit。
如果没有这层协议，模型收到的可能只是“用户点了按钮”或一段新的自然语言，还要重新猜动作发生在哪一步、修改了什么、是否应该继续。标准回传把这种猜测变成了确定输入。
因此，业务组件目录不仅定义“能展示什么”，也定义“Agent 和用户可以做什么”。它是交互能力清单，也是风险边界。
速度收益来自少绕路
让模型参与每一步，最直接的问题不是成本，而是等待。
一次看似简单的下拉操作，如果先发给模型理解，再由模型决定调用工具，等待数据返回后重新生成组件，最后还要解析和校验结果，用户只是展开一个选项，却走完了一条完整推理链。
智投方案把不同动作送到更短的路径：
- 固定状态、合作类型等静态枚举，客户端直接展示；
- 必填、格式和字段显隐，客户端即时处理；
- 用户可见账户、项目和笔记，由后端 API 按权限返回；
- 保存、删除、外发等写操作，由业务服务执行并返回结果；
- 竞品推荐、标签建议和原因解释，再交给模型。
这样做有三个直接收益。
第一，减少模型参与次数。不是所有点击都需要重新推理。
第二，首个控件、远程数据和任务结果可以分阶段返回。用户不必等完整页面和全部数据生成后才看到第一步。
第三，错误更容易定位。是模型理解错、接口失败、权限不足，还是组件数据不合法，可以按层处理，而不是统一显示“Agent 执行失败”。
当前材料没有智投线上首反馈、首控件时间或总体完成耗时，不能声称具体提升了多少。这里能确认的是实现机制：它减少了不必要的模型往返，具备速度上的结构性优势。真实收益仍需线上指标验证。
HITL 的核心不是确认框，而是决策权
工程化路线的另一面，是明确哪些决定不能留给模型。
智投内部 HITL 方案按发起方划分了五类人工介入：
- 模型遇到不确定性，需要用户补充或选择；
- Skill 执行到业务必填步骤，需要结构化输入；
- 产品红线触发，例如批量删除、外发或投放预算变更；
- 记忆写入发生冲突，例如项目信息已有值、个人偏好与项目偏好不一致；
- 调度或多人协作需要等待、审批或转交。
这五类介入的风险并不相同。模型不确定时，可以轻量追问；业务缺参时，可以出现表单；红线动作必须确认，而且不能由 Skill 或模型关闭；记忆冲突要同时展示原值、新值和来源；多人协作还要明确谁有裁决权。
这比“所有关键步骤都弹一个确认框”多走了一步：先确定为什么需要人，再决定让人看什么、能做什么、是否允许跳过。
卡片的 active、collapsed、summary 三态也服务于同一目标。用户可以中断当前流程，保留进度后续续做；完成后，原交互压缩为决策摘要；如果允许重新编辑，则通过 revisit 显式重开，并截断基于旧答案产生的后续推导。
这里需要保留一条边界：界面回到上一步，不代表业务数据已经回滚。涉及写入、外发或投放的动作，是否可逆仍由业务系统决定。
反方观点：这不就是带聊天框的工作流吗
对这条路线最有力的批评是：流程、组件和动作都预先定义好了，Agent 的自主性在哪里？
如果产品把意图、路径、推荐、解释和呈现全部写死，只允许用户通过聊天触发固定流程，那么这个批评成立。那确实只是给传统工作流加了一个自然语言入口。
但智投路线真正要固定的，不应该是所有可能性，而是确定性和高风险部分：
- 权限边界必须固定；
- 业务写操作必须走权威接口；
- 红线确认必须固定；
- 提交、完成、中断和回退的语义必须固定；
- 意图理解、语义推荐、解释和中长尾组合可以动态。
模型能力提升后，动态部分可以继续扩大。例如，从“选择一张预制业务卡片”演进到“在可信 Catalog 中组合基础组件与业务组件”。但自由度应该跟随风险逐步开放，而不是一次性全交给模型。
判断一个 Agent 产品是否先进，不该数模型调用次数。更有用的问题是：模型处理不确定性，工程是否守住不能出错的部分。
下一步：先做映射，不急着重写
智投内部方案已经具备 A2UI 的几个核心思想：结构化 UI 指令、可信组件渲染、用户动作回传、渐进状态更新和组件目录约束。
它仍不等同于已经采用官方 A2UI。内部协议还承担了 Skill 步骤、记忆、HITL 和会话生命周期等职责，而官方 A2UI 主要解决 Surface、组件、数据和动作的表达。
因此，下一步不一定是重写。
更稳妥的路径是：
- 先固化九类组件、动作语义、卡片状态和错误处理；
- 建立内部
type与 A2UI Catalog 的映射，识别能直接对齐和需要扩展的部分； - 分清客户端函数、业务 API 和模型工具，避免同一种动作存在多条实现路径；
- 用协议样例和 Golden Cases 验证旧会话与新版本；
- 补齐首反馈、完成时长、失败率和人工修改率，再决定开放多少动态组合能力。
官方协议可能带来跨端、跨 Agent 和生态兼容价值，但这些收益需要与迁移成本一起评估。为了追逐“A2UI”这个名字而重写现有体系，不会自动改善用户体验。
智投这条路线给产品经理的启发并不复杂：先把任务拆成不确定判断和确定执行，再分配模型与工程的职责。模型负责理解，工程负责完成，人负责关键决策。
这三者的边界越清楚，Agent 越不像一次性 Demo，越接近可以长期交付的产品。
资料边界：本文基于截至 2026 年 7 月 28 日的 A2UI 统一研究材料及智投内部方案文档。现有证据能证明方案和规范存在，不能证明九类组件均已上线，也没有线上时延、成功率或用户反馈数据；因此全文按“内部方案拆解”表述，不作为上线效果复盘。
系列导航
- 上一篇：04 【A2UI】GUI 负责看清，CLI 负责做快（04-gui-vs-cli）
- 下一篇：06 【A2UI】状态收敛才是交付分界线，这些坑要注意（06-a2ui-delivery-pitfalls）