文章开篇给出了整篇的基调。过去一年,Anthropic 与跨行业的数十个团队合作构建 LLM 智能体,他们观察到一个反直觉的规律:
最成功的实现并没有使用复杂框架或专用库,而是采用简单、可组合的模式(simple, composable patterns)。
这一句话是全文的论点,后面所有内容都是对它的展开:先定义术语,再讲什么时候根本不需要 agent,然后按复杂度从低到高逐一介绍各种模式,让你「按需取用」而不是「一步到位上最重的架构」。
「agent」这个词在业界有多种用法:有人指能长时间独立运行、调用各种工具完成复杂任务的完全自主系统;有人指遵循预定义流程的规范化实现。Anthropic 把所有这些变体统称为智能体系统(agentic systems),但在架构上做出一个重要区分:
这个区分是全文最常被引用的概念。判据很简单:控制流在谁手里。在代码手里就是 workflow,在模型手里就是 agent。
文章的建议出人意料地保守:构建 LLM 应用时,应当「寻找最简单的可行方案,只在必要时增加复杂度」(finding the simplest solution possible, and only increasing complexity when needed)。这可能意味着根本不构建智能体系统——因为智能体系统通常是用更高的延迟和成本去换更好的任务表现,你需要先确认这笔交易是否划算。
当确实需要更多复杂度时,选择的判据是:
市面上有许多让智能体系统更容易上手的框架。原文(现行版本)列举了 Claude Agent SDK、AWS 的 Strands Agents SDK、拖拽式 GUI 工作流构建器 Rivet、用于构建测试复杂工作流的 GUI 工具 Vellum 等(初版还提到过 LangGraph 与 Amazon Bedrock 的 agent 框架)。文章对框架的态度是「能用,但要警惕」:
由此给出两条具体建议:(1) 从直接使用 LLM API 开始——本文的许多模式几行代码就能实现;(2) 如果用框架,务必理解其底层代码——「对框架内部机制的错误假设,是客户侧错误的常见来源」。
所有智能体系统的基本构建块,是一个被检索(retrieval)、工具(tools)、记忆(memory)等能力增强过的 LLM。当前的模型可以主动运用这些能力:自己生成搜索查询、挑选合适的工具、决定保留哪些信息。(原文此处配有示意图:一个 LLM 节点,两侧接出 retrieval / tools / memory 三种增强通道,查询与结果双向流动。)
实现上有两个关键点:一是把这些能力针对你的具体用例定制,二是给 LLM 提供简单、文档完善的接口。一种实现途径是 模型上下文协议(Model Context Protocol, MCP),通过简单的客户端实现即可接入不断增长的第三方工具生态。文章后续默认每次 LLM 调用都具备这些增强能力。
这是全文的主干。每种模式原文都配有流程示意图,下文用文字转述图的结构。
机制:把任务分解为一串固定步骤,每次 LLM 调用处理上一步的输出;可以在中间步骤插入程序化检查——原文称为「门(gate)」——确保流程没有偏离轨道。(示意图:LLM 调用 1 → gate 检查 → LLM 调用 2 → LLM 调用 3 → 输出,gate 不通过则退出。)
何时用:任务能轻松、干净地分解为固定子任务时。本质是「用延迟换更高的准确率」(trade off latency for higher accuracy)——每次调用只做一件更简单的事。
原文例子:先生成营销文案、再翻译成另一种语言;先写文档大纲、程序化检查大纲是否满足标准、再基于大纲写全文。
机制:先对输入分类,再把它导向专门化的后续流程。价值在于关注点分离——可以为每类输入写专门优化的提示;否则为一类输入优化提示,常会损害其他类输入的表现。(示意图:输入 → 路由 LLM → 分发到多条互不相干的下游路径之一。)
何时用:任务存在明显可区分的类别、分开处理效果更好,且分类本身能被准确完成(用 LLM 或传统分类模型/算法皆可)。
原文例子:把不同类型的客服请求(一般咨询、退款请求、技术支持)导向不同的下游流程、提示和工具;把简单/常见问题路由给更小更便宜的模型(如 Claude Haiku),把困难/罕见问题路由给更强的模型(如 Claude Sonnet),以优化成本与速度。
机制:多个 LLM 同时工作,输出以程序化方式聚合。有两个关键变体:
(示意图:输入分发给多个并行 LLM,结果汇入一个聚合器(aggregator)再输出。)
何时用:子任务可以并行以提速,或者需要多视角/多次尝试来提高结果置信度时。对有多重考量的复杂任务,让每次调用只专注处理一个方面,通常表现更好。
原文例子——Sectioning:实现护栏(guardrails)时,一个模型实例处理用户查询、另一个并行筛查不当内容,比让同一次调用兼顾两件事效果更好;自动化评估(evals)时,让每次调用分别评估模型表现的不同维度。Voting:用多个不同的提示审查一段代码是否有漏洞,任一发现问题即标记;用多个提示从不同方面评估内容是否不当,并通过设置不同的投票阈值来平衡假阳性与假阴性。
机制:一个中心 LLM(编排者)动态地分解任务,把子任务委派给多个 worker LLM,最后综合它们的结果。(示意图:形状与并行化相似——中心节点分发、汇总——但分发的内容是运行时才决定的。)
何时用:无法预先知道需要哪些子任务的复杂场景。与并行化的关键区别在于灵活性:子任务不是预定义的,而是由编排者根据具体输入现场决定。例如写代码时,要改几个文件、每个文件怎么改,完全取决于这个任务本身。
原文例子:每次都要对多个文件做复杂修改的编码产品;需要从多个来源收集并分析信息的搜索任务。
机制:一个 LLM 负责生成回答,另一个 LLM 在循环中对其评估并给出反馈,生成者据此改进,直到评估通过。(示意图:生成器 → 评估器,评估器给出「接受」或「带反馈打回」的环。)
何时用:存在清晰的评估标准、且迭代改进能带来可衡量价值时。两个适配信号:(1) 当人类明确说出反馈意见时,LLM 的回答能被明显改进;(2) LLM 自己就能给出这类反馈。这类似人类写作者反复打磨文稿的过程。
原文例子:文学翻译——翻译 LLM 初稿可能漏掉语言的细微之处,评估 LLM 能给出有用的批评;复杂搜索任务——需要多轮搜索与分析才能收集全面信息,由评估者判断是否还需要继续搜。
随着模型在理解复杂输入、推理规划、可靠使用工具、从错误中恢复等关键能力上成熟,agents 开始进入生产环境。文章对 agent 的工作方式做了精炼刻画:
最有启发性的是这句去魅化的定义:
Agents 能处理复杂任务,但其实现往往非常直接。它们通常就是在循环中、基于环境反馈使用工具的 LLM(typically just LLMs using tools based on environmental feedback in a loop)。
正因如此,清晰、深思熟虑地设计工具集及其文档就变得至关重要(展开见附录二)。
何时用 agent:开放式问题——难以甚至不可能预测需要多少步、无法硬编码固定路径的场景。agent 会自主运行多轮,你必须对它的决策有一定信任。「agent 的自主性使其非常适合在可信环境中扩展任务规模」。代价:更高的成本,以及错误可能层层复合放大(compounding errors)的风险——因此建议在沙箱环境中大量测试,并配以适当的护栏。
原文例子(均来自 Anthropic 自己的实现):解决 SWE-bench 任务的编码 agent——依据任务描述对许多文件进行编辑;「computer use」参考实现——Claude 直接操作计算机完成任务。(此处配有编码 agent 的高层流程图:人类下达任务 → LLM 循环执行「调用工具→获得环境反馈」→ 完成后交还人类。)
文章特别声明:以上构建块不是规定性的(not prescriptive),而是开发者可以自由塑形、组合以贴合自己用例的常见模式。成功的关键(和任何 LLM 功能一样)在于度量性能并迭代实现。再次重申:只有当增加复杂度能被证明改善结果时,才去增加它。
Summary 部分给出全文结论:在 LLM 领域取得成功,不在于构建最复杂的系统,而在于为你的需求构建「正确的」系统。从简单提示开始,用全面的评估(evals)去优化,只有在简单方案确实不够时才引入多步智能体系统。实现 agent 时,遵循三条核心原则:
结尾的建议与开头呼应:框架可以帮你快速起步,但走向生产时,不要犹豫去减少抽象层、用基础组件直接构建。
Anthropic 与客户的合作揭示:agent 最有价值的任务通常具备四个共同特征——对话与行动相结合、有清晰的成功标准、能形成反馈循环、并纳入有意义的人工监督。两个典型场景:
客服把熟悉的聊天界面与工具集成能力结合,天然适合较开放的 agent:支持交互天然是对话流,又同时需要访问外部信息和执行操作;可以集成工具拉取客户数据、订单历史、知识库文章;退款、更新工单等操作能程序化完成;成功与否可以用用户定义的「解决(resolution)」标准清晰衡量。最有说服力的信号是商业模式:多家公司采用按用量计费、只对成功解决的案例收费(charge only for successful resolutions)的定价——这既体现了对自家 agent 的信心,也反过来验证了该场景的可行性。
软件开发从代码补全一路演进到自主解决问题,agent 在这里特别有效,因为:代码方案可以用自动化测试验证;agent 能把测试结果当作反馈来迭代改进;问题空间定义明确、结构清晰;输出质量可以客观衡量。在 Anthropic 自己的实现中,agent 已能仅凭 Pull Request 的描述,解决 SWE-bench Verified 基准里的真实 GitHub issue。但作者强调一个局限:自动化测试只能验证功能正确性,人工审查仍然关键——要确保方案符合更广泛的系统性需求。
这个附录是全文最「工程」的部分,核心主张:工具的定义和规格,应当获得与整体 prompt 同等分量的提示工程投入。
同一个动作往往可以有多种规格方式。从软件工程角度看它们只是「外观」差异、可以无损互转,但对 LLM 的书写难度完全不同:
一条经验法则:人们在人机界面(Human-Computer Interface, HCI)上投入多少功夫,就该在智能体-计算机界面(ACI)上投入同样多的功夫。具体做法:
构建 SWE-bench agent 时,Anthropic 团队花在优化工具上的时间,实际上比优化整体 prompt 还多。一个具体案例:他们发现 agent 一旦移动出根目录,使用「相对路径」参数的工具就频繁出错;解决办法不是在 prompt 里反复叮嘱,而是直接修改工具、强制要求绝对路径(absolute filepaths)——改完之后模型使用该工具「完美无误」(flawlessly)。这就是 poka-yoke 思想在 ACI 上的实例:与其教模型别犯错,不如让接口设计得没法犯错。