怎么造「真正好用的 AI Agent」？Anthropic 这篇工程长文，把套路说透了

贵慜_Derek
4 阅读11分钟

「Agent」在业内的叫法很杂：有人指长跑全自动系统，有人指按剧本走的流水线。Anthropic 先把帽子统一成 agentic systems，再切开 Workflows（代码写死路线）与 Agents（模型在循环里自己决定下一步工具）。[1]

劝退句也写得直白：能用最简单的办法，就别上 Agent——多轮自主往往换来更高延迟与账单，只为换任务表现；值不值要先用数据想清。[1]

读前提示

  • 主线：为什么区分 Workflow/Agent → 积木与六种模式 → 成本与调试 → 对你团队 意味着什么。
  • 深度：文内 ### 深度解析 与 材料勘读；文末 结论与讨论 与 延伸阅读。

一、先把概念焊死：Workflow vs Agent

1.1 厨房类比（帮助记忆）

  • Workflow：像中央厨房的 SOP：第 1 步洗菜、第 2 步切丁、第 3 步下锅——路线是产品经理/程序员画好的，模型只是其中某些环节的「巧手」。
  • Agent：像弹性很大的主厨：顾客说「今晚家里来客人，你看着办」，主厨自己决定要逛几个菜场、买啥、做几道菜、中途要不要打电话问忌口——下一步不是写死在代码里的 if-else 树，而是由模型结合工具返回的「地面真况」再规划。[1]

1.2 为什么要纠缠这个区分

因为调错架构会浪费钱：该用「单次模型 + 检索 + 几个示范」就能解决的，你上多轮 Agent，只会更慢更贵还更难 debug。[1]

flowchart LR
  subgraph simple [SimpleFirst]
    A[Single_LLM_call]
    B[Plus_retrieval_and_examples]
  end
  subgraph wf [Workflows]
    C[Predefined_code_paths]
  end
  subgraph ag [Agents]
    D[Model_directs_tools_in_loop]
  end
  simple --> wf
  wf --> ag

二、何时上 Agent、何时根本不该上

2.1 默认答案：越简单越好

Anthropic 的建议可以翻译成三句「厂规」：

  1. 先找最小可行方案：也许根本不需要 agentic system。[1]
  2. 真要加复杂度：Workflow 适合「任务边界清楚、要稳定一致」；Agent 适合「步骤数量事先说不清、要靠模型临场决策」。[1]
  3. 很多应用：把单次 LLM 调优（加检索、加 in-context 示例）就够用——别一上来就堆编排框架。[1]

2.2 中文业务例子

场景更像 Workflow更像 Agent
报销单字段抽取 + 规则校验抽取 → 规则引擎 → 输出（分支固定）通常不必
「去若干内部系统里查清这笔订单为啥失败」可先做半自动 Workflow信息源不可预知时偏 Agent
客服：闲聊 + 查库 + 改工单 + 触发退款常是 Agent + 强工具对话开放、动作多

三、框架：省力，但可能让你看不见「齿轮」

文里点了包括 Claude Agent SDK、Strands（AWS） 、Rivet、Vellum 等——价值是快速拼 LLM、工具、链式调用。[1]

但有两个坑（原文精神）：

  1. 抽象层糊住 prompt 与 response，出问题难调试。[1]
  2. 让你忍不住加复杂度，而简单方案本可过关。[1]

实践建议（转述） ：先用 LLM API 直连把模式跑通；要用框架，搞懂底下在干啥；错假设是客户踩坑高发源。[1]

四、核心积木：Augmented LLM（增强型大模型）

4.1 三块外包给模型自己用

基础积木是：LLM + 检索 + 工具 + 记忆（以及让模型自己会查、会选工具、会决定记啥）。[1]

4.2 接口要像给人看的文档一样讲究

文中强调：这些能力要对场景定制，且提供简单、文档化清楚的接口。[1]

4.3 MCP 是什么（一句话 + 链接）

Model Context Protocol（MCP） 被作为「用简单 client 对接越来越多第三方工具生态」的一条路径举例——本质是把「工具与应用」的接法标准化，减轻重复集成。[1][2]

白话：以前每个 App 给模型接工具都像独家定做插头；MCP 像统一的插口规格，开发者按规格做一端，另一端用标准线一连。

五、六种常见打法：每种给你「比喻 + 中文例子 + 何时用」

以下六种是 Anthropic 总结的生产中常见模式，不是圣旨，可裁剪组合；核心仍是能量化就评测，能简单别复杂。[1]

5.1 Prompt chaining（提示链）——流水线 + 质检闸口

比喻：火锅后厨，一棒接一棒；某一棒不合格打回上一棒，别端到桌上才翻车。

原文结构：任务拆成固定子步骤；每步 LLM 吃上一步输出；中间可加程序化检查（文里叫 gate）。[1]

中文例：先生成营销文案 → 再翻译成英文；或先写大纲 → 程序检查大纲是否满足字数/章节约束 → 再扩写正文。

何时用：子任务清晰可切块；愿意用延迟换更高准确率（每步 LLM 任务更简单）。[1]

5.2 Routing（路由）——分拣中心

比喻：快递站：先扫码归类，再送进不同流水线；不然「为 A 类优化的提示词」往往伤 B 类。

中文例：客服进线先分类——退换货 / 技术支持 / 账务——再走不同话术与工具集。

何时用：输入明显几大类，且分类可靠（模型或小模型/规则都可）。[1]

补充例子（原文） ：简单题路由到 Haiku 类小模型，难题给 Sonnet 类强模型，做成本与效果折中。[1]

5.3 Parallelization（并行化）——多人同时搬砖或多人投票

两个变体：[1]

  • Sectioning（分段并行） ：任务切成互不拖累的几块，一起跑，再聚合。
  • Voting（投票） ：同一任务多次生成，程序按规则合并/裁决。

中文例（分段） ：一路模型专做内容审查，另一路专做正式回答（比「一个调用又审又答」往往更稳）。[1]

中文例（投票） ：多份 prompt 检视同一段代码的安全问题，任一 flagged 再进入人工或深检。[1]

何时用：子任务可并行提速；或需要多角度/多次尝试换更高置信度。[1]

5.4 Orchestrator-workers（编排器-工人）——包工头派活

比喻：装修：包工头看完户型和诉求，动态决定拆多少墙、改几路线；工种和工程量事先写不进固定表——这和「并联三段固定脚本」不同。[1]

中文例：改代码跨很多文件、每 issue 改动面不同；或多源检索后再综合。

何时用：子任务数量与形态随输入变化大，没法提前写死 DAG。[1]

5.5 Evaluator-optimizer（评估-优化回路）——写稿 + 责编循环

比喻：记者写稿，责编批注「证据不足、口径不对」，打回改；直到达标。

何时用：评估标准清楚，且「多轮打磨」能量化带来收益；且模型给得出像样的 critique。[1]

中文例：文学翻译润色；复杂检索要评估「还需不需要再搜一轮」。[1]

5.6 Agents（智能体）——带地图的探险队

特征（归纳原文） ：从用户拿到目标后，自己规划、多轮使用工具；每一步尽量从环境拿地面真况（工具结果、代码执行输出）；可在卡点找人；要有停步条件（如最大轮数）。[1]

风险：自主性带来更高费用与错误累积；要沙箱测、上护栏。[1]

原文例子：解 SWE-bench 类多文件代码任务；computer use 参考实现等。[1]

六、拼装与三条「成功军规」

  1. 简单：设计保持简单，只为可证明的收益加复杂度。[1]
  2. 透明：尽量显式展示规划/步骤（用户与工程都好 debug）。[1]
  3. ACI：把 Agent-Computer Interface（智能体-计算机接口）当 HCI 那样认真做——工具描述、例子、边界、测试。[1] 文中在附录展开为「Prompt engineering your tools」。[1]

深度解析：六种模式与「编排框架」不是一一对应

[事实：原文用六种模式描述常见组合，而非某个开源项目的专有名词。原文观点：从 Augmented LLM 到 Agent 循环是复杂度递进。本文解读：生产里常见混用（例如 Orchestrator-workers 里嵌 Evaluator-optimizer）；若你的框架把「Agent」只实现成固定 DAG，要警惕与文里 Agents（模型主导工具循环） 的定义漂移——评测时应按实际决策权在谁来归类，而不是按营销标签。

七、附录精读：客服 vs 编程，为何 Agent 特别合身

两类场景共同点（归纳）：既要聊又要干、成功标准相对清、能形成反馈闭环、需要人机协同。[1]

维度客服编程 Agent
为何自然偏 Agent对话流 + 外部信息与动作（订单、知识库、退款API）测试与运行结果是强反馈
成功怎么量解决率、账单按成功收费等商业设计（文中所述现象）自动化测试、基准集；但人审仍重要

个人延伸（非 Anthropic 结论） ：企业内部若要抄作业，别只抄「接大模型」，先问：成功判据能量化吗？反馈从哪来？人在哪几个闸口签字？

八、「重要指标与工程考量」——原文偏定性，我们列成清单

文里少有「必须 92.3%」式 KPI，但工程上你应持续看：

考量说明
延迟多步 / Agent 轮次 ↑，体感与时延 ↑ [1]
成本多模型、多工具、长上下文 = 钱 [1]
错误累积Agent 自主权越高，单步小错可能滚雪球 [1]
可调试性框架/黑盒过厚会遮蔽 prompt 与 tool 轨迹 [1]
沙箱与护栏上线前隔离测试 + 停条件 + 权限边界 [1]
工具质量坏接口让模型写 diff、写 JSON 里嵌代码，会指数级变难 [1]

和人扯皮时的止血句：先跑 baseline（简单调用），再上 workflow/agent；用数据证明复杂度值得。

九、工具接口设计：几个「格式坑」（附录 2 压缩）

Anthropic 说：同一操作可有多种 tool 表达，但对模型难度完全不同；建议思路包括：给模型足够“想清楚”的空间、格式贴近模型在互联网文本里自然常见的形态、避免离谱的格式负担（例如难以维护的大段 diff 头、JSON 里疯狂转义代码）。[1]

人话规约：把 tool 当Junior 同事的 API 文档写：参数名自解释、给示例、写边界、做 poka-yoke（从参数上减少误用）。[1]

原文轶事：SWE-bench Agent 里曾花更多时间优化工具而非总 prompt；相对路径踩坑后改成强制绝对路径，模型就稳了。[1]

材料勘读：发布稿里没写清的事：工程观点 vs 可复现数字

[事实：本文为 Anthropic Engineering 博文，侧重设计原则与模式命名。原文观点：简单优先、透明、ACI；列举第三方框架名作为生态参照。本文解读（推断） ：文内定性指标多于可横向对比的基准分数——「别上 Agent」的结论应结合自家延迟/成本/错误率数据；提及的 SWE-bench 轶事是叙事案例，复现时以论文/基准官方设定为准，勿把单篇博文当完整实验报告。

十、思辨延伸（个人思考，非原文结论）

  1. Workflow 与 BPM：很多公司已有审批流、规则引擎——Agent 不是替代 BPM，而是覆盖「未定路径的信息劳动」；重叠区要故意设计，否则两套真相。
  2. 评测先行：哪怕没有完美 offline eval，也可以固定 20 条黄金任务周更回归，专门盯「工具误用率、越权调用、瞎编引用」。
  3. 透明度 vs 商业机密：展示「规划步骤」对调试极好，但某些场景要脱敏——产品是折中叙事而不是二选一。
  4. 组织成熟度：ACI 本质是你家 API 与运维成熟度；接口烂，Agent 只是更快地把烂接口调用摊在用户面前。

十一、一张总图：从简单到放飞（复杂度递进示意）

flowchart TB
  B[Augmented_LLM]
  P1[Prompt_chaining]
  P2[Routing]
  P3[Parallelization]
  P4[Orchestrator_workers]
  P5[Evaluator_optimizer]
  Ag[Agent_loop_with_tools]
  B --> P1
  B --> P2
  B --> P3
  B --> P4
  B --> P5
  B --> Ag

结论与讨论

技术坐标

此文把 2024–2025 业界混用的「Agent」收束为 agentic systems 下的 Workflow vs Agent，并给出可组合的模式菜单与 ACI 约束——在工程叙事上接近 「参考架构 + 反模式清单」，而非单一产品白皮书。

批判性问题

  1. 六种模式是否覆盖你业务里人机协同（审批、责任归属）——文内偏技术闭环，落地时谁签字？
  2. 「简单优先」与组织 KPI（「必须有 Agent demo」）冲突时，baseline 是否敢写进汇报？
  3. 工具优化比总 prompt 更值的结论，是否在你域成立——还是数据形态根本不适合当前 tool schema？

独立判断（事实 / 原文观点 / 本文解读）

类型内容
事实原文 URL 与 MCP 链接；Workflow/Agent 定义与六种模式为文内框架。
原文观点越简单越好；透明；工具当 API 设计；框架可能遮蔽调试。
本文解读最值得带走的是 「决策权在代码还是在模型」 这一问；模式名称不如这条判据稳。

造 Agent，最难的不是「接一个框架」，而是选对你到底需要 Workflow 还是 Agent，以及别把工具接口写得像谜语。能力以 Anthropic 最新文档与产品为准；若与官网更新冲突，以官网为准。

参考文献与延伸阅读

avatar
文章
阅读
粉丝