从“堆 Agent”到可验证交付：重新理解 Anthropic 的有效 Agent 框架

Anthropic 在 2024 年的《Building effective agents》给出了一套至今仍有参考价值的判断框架。需要先说明边界：原文也已提示，其所列工具生态在发布后发生了变化；因此本文不把它当作某个 SDK 的实施手册，而把它视为一套架构判断方法。

先分清：工作流不是 Agent

两者都会把模型、工具和上下文串在一起，差异在“下一步由谁决定”。

• 工作流（workflow）：程序预先定义路径，模型在固定环节完成判断或生成。它更可预测，也更容易评测、排错和控制成本。
• Agent：模型根据环境反馈自行决定下一步、调用什么工具以及何时结束。它适合路径无法预先写死的任务，但需要更严格的权限、预算和人工检查点。

这个区分能避免一个常见误区：多次 LLM 调用不自动等于 Agent。若退款、分类、资料查询的分支早已确定，把它做成可观察的工作流，通常比让模型“自由规划”更可靠。

从最简单方案开始的升级阶梯

推荐的起点不是多 Agent，而是一个经过充分优化的模型调用：清楚的任务指令、少量高质量示例、需要时加入检索、记忆或工具。只有当它无法稳定完成任务时，再逐级增加结构。

这里最重要的不是记住模式名称，而是把“复杂度”视为要用证据购买的能力。若增加两轮调用没有提升通过率、人工返工率或完成时间，就应回退，而不是继续叠加组件。

用任务特征选结构，而不是用流行词选架构

可以从四个问题开始诊断。

1. 路径能否预先写出？ 能写出时优先工作流；不能写出、且每次任务差异明显时，才考虑由模型动态拆解。
2. 结果是否可验证？ 自动测试、字段校验、引用检查、状态回读等“环境真值”越可靠，越适合让系统多轮执行。
3. 错误的代价是什么？ 一旦涉及支付、删除、对外发送或生产环境变更，必须缩小工具权限，并在人类批准点暂停。
4. 收益是否覆盖开销？ 把成功率、端到端耗时、每次任务成本、人工接管率和失败原因一起看；只看模型输出是否“看起来聪明”会误导决策。

例如，客服入口可先用路由把“查订单”“技术排障”“退款申请”分流，再为退款设计固定校验与人工授权；没有必要从一开始就赋予模型任意行动能力。相反，跨多个仓库定位问题、修改代码并反复运行测试时，具体要读哪些文件和走几轮修复难以预测，带有明确测试反馈和停止预算的 Agent 才有实际价值。

可靠性来自控制面，而不来自“更自主”

开放式 Agent 的核心循环很朴素：模型提出动作，工具返回环境结果，模型据此调整下一步。但生产系统必须在循环外加上控制面：

• 为每个任务定义可检验的完成条件，而非只要求“尽力解决”；
• 为轮次、时间、成本、工具调用和重试次数设置上限；
• 把工具返回、关键决策、失败和人工接管记录为可追溯事件；
• 让高风险动作通过最小权限、参数校验、沙箱和人工批准；
• 在卡住、冲突或证据不足时允许系统停止并请求信息，而不是编造进展。

这一点也解释了为什么“工具接口”常比总提示词更值得投入。工具名称、参数、示例、输入约束和错误提示，本质上是模型使用外部世界的操作界面。接口含糊时，模型很容易选择错误动作，或在失败后以错误方式恢复。

把评测前置，才能知道是否真的需要 Agent

在增加自主性之前，先准备一组覆盖真实业务边界的任务集：正常案例、模糊输入、缺失资料、冲突数据、工具失败和高风险请求都要包括。然后为不同方案比较同一套指标：任务完成率、人工修正率、平均时延、调用成本、违规动作数，以及失败是否可恢复。

如果一个固定工作流已经稳定达到目标，继续替换为 Agent 通常只会放大运维负担。只有当真实任务的步骤和工具选择确实无法预先枚举，同时系统又能通过测试、检索结果、数据库状态或人工审核获得可靠反馈时，Agent 的弹性才值得成本。

对 AI Agent 项目的一个落地建议

我们倾向把 Agent 设计从“画一张复杂架构图”改成一张决策记录：任务为何不能用更简单方案完成、允许调用哪些工具、什么证据算完成、何时交给人、如何在指标上证明新增复杂度有效。这样做会让架构更容易演进：先从可观测的工作流上线，再由数据决定是否把某一段升级为动态编排，而不是把自治能力当成默认配置。

真正有效的 Agent，不是能调用最多工具的系统，而是能在明确边界内持续交付、被验证并被维护的系统。