Agent Workflow 与评估

第二部 · Agent 实践 · 第11章

撰写日期：2026-07-02

结论

Agent 产品不是“多轮聊天”，而是一个可执行、可恢复、可评估的任务系统。

一个可进入生产环境的 Agent Workflow 至少要回答四个问题：

问题	说明
目标是什么	用户要完成的任务，而不是一句模糊请求
需要什么 Context	用户、业务、数据、工具和历史状态
如何执行	拆解步骤、调用工具、处理异常
如何验证	结果是否正确，过程是否可追踪

Workflow 的基本结构

用户目标
-> 目标澄清
-> Context 收集
-> 任务拆解
-> 工具调用
-> 中间结果检查
-> 异常处理
-> 最终交付
-> 评估与记忆写入

如果一个 Agent 只会回答，不会检查中间状态，它更像助手；如果它能持续推进任务并验证交付，它才接近产品系统。

Context 设计

Context 类型	示例	产品问题
用户 Context	用户角色、偏好、权限、历史选择	它是否知道“我是谁”
任务 Context	当前目标、进度、阻塞点	它是否知道“做到哪了”
业务 Context	流程、规则、指标、文档	它是否知道“业务怎么运转”
工具 Context	可用工具、参数、失败方式	它是否知道“能做什么”
记忆 Context	长期偏好、复用资产、历史判断	它是否能形成连续体验

Context 的产品价值不是让模型“知道更多”，而是让模型少猜、少跑偏、少重复问。

任务拆解

Agent 的任务拆解应该可观察，而不是藏在模型推理里。

拆解层级	示例
Goal	更新一个公开版 AI Product Playbook
Milestone	读取资料、筛选主题、生成文档、检查隐私、提交代码
Task	读取目录、提炼 Prompt 模板、更新 README
Action	调用文档 API、写入 Markdown、运行 git diff

好的 Workflow 会把“可失败的动作”显式化。只有显式化，才有权限、重试和验证。

权限与确认

风险等级	动作	默认策略
L1 只读	读取文档、搜索资料、查看仓库	自动执行
L2 本地草稿	写 Markdown、生成模板、整理摘要	自动执行并验证
L3 内部写入	更新内部文档、创建任务、提交 PR	视影响确认
L4 对外动作	发消息、发布公告、部署线上	必须确认
L5 高风险	删除数据、改权限、迁移生产内容	默认禁止或强审批

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

评估框架

维度	评估问题	例子
任务完成	是否完成用户目标	文档是否更新、链接是否可访问
正确性	内容是否符合事实和约束	是否漏掉限制条件
可追踪	能否说明依据和动作	是否有 diff、日志、测试结果
可恢复	失败后能否继续	是否保留中间状态
成本	时间、token、API 调用是否合理	是否重复读取同一内容
用户体验	用户是否需要频繁介入	是否只在必要边界追问

端到端测试清单

Agent Workflow 测试清单

目标：
输入：
可用工具：
必须遵守的约束：

成功标准：
1.
2.
3.

必须覆盖的异常：
1. 权限不足
2. 工具超时
3. 输入信息不完整
4. 中间结果不符合预期

验证方式：
- 结果检查：
- 过程检查：
- 用户可见交付物：

产品判断

Agent 的核心壁垒不只在模型，而在 Workflow：

1. 能不能稳定拿到正确 Context。
2. 能不能把任务拆成可执行动作。
3. 能不能调用真实工具完成交付。
4. 能不能在失败后恢复。
5. 能不能把经验写回系统。

模型能力会继续提升，但可控、可验证、可积累的 Workflow，才是 Agent 产品长期变好的基础。