Agent 产品的状态管理

分清对话、任务状态、业务事实和模型上下文，让 Agent 的建议与正式写入保持清楚边界。

「产品经理的 Agent 入门」之七
上一篇：Agent 的自主性 · 系列入口 · 下一篇：Agent 的评估与产品化

用户说“把第二个方案设为 MVP”，Agent 回复“已经更新”。但系统真的知道第二个方案是哪一个对象吗？用户有权限吗？数据库写入成功了吗？其他协作者会看到相同结果吗？

如果这些问题没有答案，Agent 的回复只是语言，不是可信的产品状态。

四种真相

业务真相：用户、需求、文档版本和权限；
任务真相：一次 Run 执行到哪一步、等待什么；
对话真相：用户与 Agent 说过什么；
推理上下文：模型这一次实际看到了什么。

四者可以互相引用，不能互相替代。聊天记录不应成为正式需求状态，Memory 也不应成为业务数据库。

五层产品架构

Experience：对话、工作台、进度、Diff、审批
Product：用户、业务对象、权限、版本、正式状态
Orchestration：Agent、Workflow、Skill 路由、暂停与恢复
Capability：Tools、MCP、检索、文件和外部服务
Model：推理、生成、模型路由与限额

Trace、Eval、Cost、Latency 和 Incident 应横向穿过这些层。

用 Proposal 分开建议和写入

Agent 分析 → Proposal / Patch → Schema 校验
→ 用户查看来源、差异和影响 → 批准 / 修改 / 拒绝
→ Product Layer 写入 → 创建版本和审计记录

Proposal 不是多点一次确认。它提供了可解释、可撤销、可处理并发冲突的中间对象，明确模型建议与业务事实之间的边界。

有效审批要让用户看懂

用户至少要看到 Agent 准备做什么、影响哪些对象、当前值与新值、依据、能否撤销，以及拒绝后流程怎样继续。文档与代码展示 Diff；外部消息展示完整收件人和正文；数据修改展示旧值、新值与影响范围。

好的 Agent UX 展示当前目标与阶段、来源、已确认事实、假设、待确认项、动作、风险和需要用户作出的决定，而不是大段神秘的“内部思考”。

本篇小结

对话记录、任务进度、模型 Context 和业务数据库是四类不同状态，不能互相替代。
Agent 的建议应先形成可检查的 Proposal 或 Patch，再由确定性程序校验、批准和写入。
好的 Agent 界面要展示目标、阶段、来源、差异、风险和待确认决定，而不只是一个聊天框。

对话负责协作，Runtime 负责执行，业务数据库负责事实，审批与审计负责信任。