建 Agent 前的四问：复杂度、价值、能力瓶颈与错误成本 Four Questions Before You Build an Agent
以下内容与我的工作无关，仅为个人感想与学习笔记，不代表任何公司或机构的立场。
These notes are unrelated to my work. They are personal reflections and study notes only, and do not represent the views of any company or organization.
本文是对以下内容的阅读笔记：Barry Zhang 的演讲《How We Build Effective Agents》；Anthropic《Building effective agents》 These are reading notes on: Barry Zhang’s talk “How We Build Effective Agents”; Anthropic, “Building effective agents”
摘要
Agent 不是普通 Workflow 的高级版本，而是把部分控制流交给模型。只有当任务路径足够模糊、单次价值足够高、模型具备完成关键步骤的能力，而且错误能够被发现、限制和纠正时，额外的自主性才值得它带来的成本、延迟与风险。立项前先回答复杂度、价值、能力瓶颈和错误成本四个问题，可以避免把确定性流程包装成昂贵且难以控制的 Agent。
核心区别：控制流属于谁
“With a workflow, you own the plumbing. With an agent, the model owns the plumbing.”
- Workflow：开发者预先定义步骤、分支和调用顺序，模型只在指定节点工作。
- Agent：模型根据环境反馈动态决定下一步、选择工具并调整路径。
二者并非非此即彼。现实系统通常是混合结构：确定性主干由 Workflow 或 Harness 控制，只有真正需要判断和探索的局部交给 Agent。
Anthropic 的官方建议是从最简单的方案开始，仅在任务表现确实需要时增加自主性。预定义任务优先使用 Workflow；无法提前硬编码路径、需要模型动态决策的开放问题，才更适合 Agent。
四问决策表
| 问题 | 适合 Agent 的信号 | 不适合 Agent 的信号 | 可采取的降级方案 |
|---|---|---|---|
| 1. 任务是否足够复杂、模糊？ | 路径不能预先穷举，需要探索和动态决策 | 步骤固定、分支清楚、规则可以编码 | 普通程序、单次模型调用或 Workflow |
| 2. 单次任务价值是否足够高？ | 完成一次任务能创造明显业务价值，值得支付探索成本 | 高频、低价值、低毛利，延迟和 token 预算严格 | 批处理、小模型、缓存、路由或固定模板 |
| 3. 关键能力瓶颈是否已可用？ | 模型能够完成最难步骤，并能从失败中恢复 | 瓶颈在数据库、I/O、权限、基础模型能力或确定性计算 | 先修工具和系统瓶颈，缩小 Agent 范围 |
| 4. 错误代价多高、能否发现？ | 输出可验证、动作可回滚、存在人工或系统门禁 | 错误不可见、不可逆，且可能造成重大损失 | 只读、建议模式、人工审批、沙箱或禁用 Agent |
第一问：任务是否真的需要动态控制流
“复杂”不等于步骤多。一个包含一百个确定步骤的流程仍然可以是 Workflow；一个只有几步、但每一步都取决于新证据的研究任务，反而更适合 Agent。
判断关键是：
- 能否在执行前画出大部分决策树？
- 中间结果是否会改变后续步骤和工具选择？
- 是否需要在未知环境中搜索、试错和恢复？
- 固定流程是否已经能可靠覆盖主要场景？
如果路径可预先定义，就应把控制流留在确定性代码里。自主性不是目标，只是处理未知路径的手段。
第二问：任务价值能否覆盖 Agent 税
Agent 会引入额外成本：多轮推理、工具调用、上下文增长、执行延迟、失败重试、评估和运维。只比较 token 单价，会低估系统成本。
综合判断式
这不是 Barry Zhang 给出的正式公式，而是对四问的归纳：
Agent 净价值 ≈ 完成率提升 × 单次任务价值 − 推理与运维成本 − 预期错误损失
因此，应衡量单位成功任务成本，而不是单轮调用价格。这与《Token 经济：稳定接口如何解耦 AI 技术栈》对 token 计价边界的讨论相呼应。
第三问：先找出轨迹中最弱的一环
Agent 的总体表现会被关键步骤限制。开始搭完整系统前，应先单独测试：
- 模型能否理解输入和完成最难的推理？
- 工具接口是否让模型容易选对、填对参数？
- 环境能否返回足够明确的反馈？
- 失败后能否诊断原因并换一种路径？
- 状态、权限或 I/O 是否才是真正瓶颈？
如果关键能力尚未过线，增加循环和 Agent 数量通常只会放大成本与错误。更稳妥的顺序是：先验证最难步骤，再扩展任务范围，最后才增加自主性。
第四问：错误成本必须与可发现性一起看
风险不能只看“会不会错”，还要看“错了是否看得见、能否阻止和恢复”。
| 错误代价 | 可发现性 | 合适的自主等级 |
|---|---|---|
| 低 | 高 | 可允许自动执行，保留日志和预算上限 |
| 中 | 高 | 自动执行，但增加验证与回滚 |
| 高 | 高 | Agent 生成方案，确定性门禁或人工批准后执行 |
| 低 | 低 | 先建设可观测性和抽检，不宜直接扩张规模 |
| 高 | 低 | 不应交给自主 Agent |
可采用逐级放权：
- 只读：搜索、分析和解释，不产生外部状态变化。
- 建议：生成计划、草稿或变更集，由人执行。
- 可逆写入：允许在沙箱、分支或带版本记录的系统中修改。
- 门禁写入：验证通过并获得审批后进入生产。
- 无人值守：仅用于错误可及时发现、损失受限且具备自动回滚的场景。
《面向 Agent 的可验证架构：从 UI 驱动到自动回归闭环》解决的正是第四问：把环境反馈、确定性断言、评判器、回归集和发布门禁组合起来，让错误从“发生后才知道”变成“执行中即可拦截”。
为什么编程是典型 Agent 场景
编程通常同时满足四个条件：
- 从需求到修改方案的路径具有较高不确定性；
- 可工作的代码具有较高单次价值；
- 模型已具备读代码、修改、调试和调用工具的关键能力；
- 测试、类型检查、静态分析、代码评审和版本控制能提供反馈与回滚。
这不意味着所有编码任务都适合 Agent。简单格式修改、固定代码生成和机械迁移仍应优先使用脚本；生产变更也不能因为测试通过就跳过权限与业务门禁。
常见误区
- 把 Agent 当成产品卖点：先决定“要做 Agent”，再寻找适用任务。
- 用自主性掩盖流程不清：业务规则没有澄清，却希望模型自行补齐。
- 绕过真实瓶颈：数据库、工具或权限设计有问题，却继续升级模型。
- 只看平均准确率：忽略低概率但高损失的尾部错误。
- 先做多 Agent：单 Agent 的任务、工具和验证尚未跑通，就增加协调层。
- 把人工审批当万能解法：审批过多会退化为新的延迟和橡皮图章。
立项前检查表
- 任务路径无法被低成本地预先编码
- Agent 相比 Workflow 有明确的完成率或覆盖面提升
- 单次任务价值足以覆盖推理、延迟、评估和运维成本
- 已单独验证轨迹中的关键能力瓶颈
- 工具会返回足够明确的环境反馈
- 关键结果存在自动或人工验证方式
- 高风险动作具备权限门禁、回滚和审计记录
- 定义了最大轮数、时间、token 与费用上限
- 明确什么情况下退回 Workflow、人工处理或直接停止
如果其中任何一项无法回答，不一定意味着项目不能做，但说明当前应减少自主范围，而不是继续堆叠 Agent。
来源边界
四问来自 Barry Zhang 的《How We Build Effective Agents》演讲，并与他共同撰写的 Anthropic 官方文章《Building Effective Agents》在 Workflow / Agent 区分、成本延迟权衡和最小复杂度原则上相互印证。