Agent 产品操作系统

第二部 · Agent 实践 · 第10章

撰写日期：2026-07-02

结论

Agent 产品要从“聊天框”升级为“任务系统”，至少需要六个模块：

Context、Tool、Permission、Workflow、Evaluation、Memory

这六个模块共同决定 Agent 是否可用、可信、可控、可持续迭代。

Agent 产品六层模型

层级	核心问题	产品产出
Context	Agent 需要知道什么	上下文清单、知识源、记忆策略
Tool	Agent 能做什么	工具列表、输入输出、失败处理
Permission	Agent 可以做到什么程度	动作分级、确认机制、权限边界
Workflow	Agent 如何完成任务	任务链路、状态流转、暂停点
Evaluation	怎么知道它做对了	测试样例、成功标准、回归集
Memory	如何形成连续体验	记忆写入、调用、更新、删除规则

1. Context 清单

设计 Agent 前，先列清楚它执行任务时应该看到什么。

Context 类型	需要回答的问题	示例
用户	用户是谁，有什么偏好和权限	输出偏好、常用工具、角色
任务	当前目标是什么，进度到哪一步	已完成、待确认、失败步骤
业务	业务规则和流程是什么	文档规范、发布流程、命名规则
数据	事实来源在哪里	文档、表格、数据库、代码仓库
工具	能调用哪些能力	搜索、写文档、发消息、跑测试
记忆	哪些长期信息会影响本次任务	用户偏好、历史决策、协作习惯

判断标准：

如果没有这份 Context，Agent 是否还能做出正确判断？如果不能，就应该进入上下文系统。

2. Tool 设计

每个工具都应该被产品化描述，而不是只作为 API 存在。

字段	说明
工具名称	用户和 Agent 都能理解的名字
用途	这个工具解决什么问题
输入	需要哪些参数
输出	返回什么结果
权限	读、写、发布、删除分别到什么级别
失败处理	失败后能否重试，是否保留中间结果
验证方式	如何确认工具调用真的成功

工具设计模板：

工具名称：
适用场景：
输入参数：
输出结果：
默认权限：
需要确认的动作：
失败后的恢复方式：
成功验证方式：

3. Permission 分级

Agent 的权限应该按动作风险分级。

等级	动作类型	示例	默认策略
L1	只读	查资料、读文档、看状态	自动执行
L2	草稿	生成文案、写计划、创建本地草稿	自动执行，展示结果
L3	内部写入	更新内部文档、创建任务、提交 PR	视场景确认
L4	对外动作	发客户消息、发布公告、上线部署	必须确认
L5	高风险动作	删除数据、改权限、付款、迁移生产库	默认禁止或强审批

判断标准：

权限不是为了限制 Agent，而是为了让用户敢把真实任务交给 Agent。

4. Workflow 设计

Agent Workflow 不应该只有成功路径，还要有暂停、确认、失败和恢复。

阶段	产品要定义什么
输入	用户需要提供什么，缺什么要追问
计划	Agent 准备做哪些步骤，是否需要展示
执行	每一步调用什么工具，写入什么系统
暂停	哪些节点必须等用户确认
验证	每一步如何确认成功
失败	失败后保留什么，如何继续
交付	最终给用户什么证据

Workflow 模板：

用户目标：
成功结果：
输入要求：
执行步骤：
需要确认的节点：
失败后的恢复方式：
最终交付物：
验证标准：

5. Evaluation 评测

Agent 评测要从真实任务出发，而不是只评回答质量。

评测维度	评什么	示例标准
理解	是否抓住用户目标	没有把总结任务误判为写作任务
完整	是否覆盖关键要素	有背景、结论、待办、责任人
准确	是否基于事实	不编造原文没有的信息
工具	是否调用正确工具	该回读时完成回读
成本	是否过度调用模型	简单分类不用高级模型
稳定	多次结果是否一致	核心结论不漂移
安全	是否越权或误操作	高风险动作前暂停确认

评测样例模板：

样例名称：
输入：
期望输出：
必须包含：
不能包含：
需要调用的工具：
成功标准：
失败标准：

6. Memory 规则

记忆不是全量历史，而是对未来任务有用的稳定信息。

记忆类型	是否适合记	说明
稳定偏好	适合	输出格式、语言、节奏
长期目标	适合	当前阶段目标、关注方向
工作上下文	适合	项目、工具、常用流程
一次性任务	谨慎	只在当前任务保留即可
情绪表达	谨慎	容易误判，不应轻易长期化
敏感信息	默认不记	需要明确授权和删除机制

记忆规则模板：

什么值得记：
什么不该记：
什么时候调用：
如何更新：
如何删除：
是否需要用户确认：
过期规则：

Agent 需求文档最小模板

一个 Agent 需求至少应该写清楚这些内容：

模块	问题
用户目标	用户希望 Agent 完成什么任务
成功标准	什么结果算完成
Context	Agent 需要哪些上下文
Tools	Agent 能调用哪些工具
Permission	哪些动作自动执行，哪些动作要确认
Workflow	从输入到交付的步骤是什么
Failure	失败时如何提示、保留和恢复
Evaluation	用哪些样例验证它做对了
Cost	单次任务大约调用几次模型，是否可控
Memory	哪些信息需要长期记住

一页检查清单

检查项	是 / 否
是否定义了明确的用户目标
是否定义了成功标准
是否列出必要 Context
是否列出可调用 Tools
是否做了动作权限分级
是否设计了用户确认节点
是否设计了失败恢复路径
是否有结果验证方式
是否有最小评测集
是否估算了模型和工具成本
是否定义了记忆写入和删除规则

我的判断

Agent 产品经理真正要交付的不是一个“会回答问题的模型”，而是一套能让模型进入真实任务、真实工具和真实责任边界的产品系统。

如果 Context 不清楚，Agent 会答偏。 如果 Tool 不受控，Agent 会误操作。 如果 Workflow 不可验证，Agent 无法上线。 如果 Evaluation 缺失，迭代只能靠感觉。 如果 Memory 不可控，长期关系会变成长期风险。