Building Effective AI Agents — Anthropic

What

Workflow和Agent的差异还是很大的

Antropic将其都归纳为一个Agentic Systems

• Workflow：由代码决定每一步应该做什么，LLM只是其中的一环
• Agent：LLM自主决定每一步应该做什么

When and When Not

Timing

Antropic并不建议什么情况下都去做一个复杂的Agentic System

应该先尝试最简单的方案，再逐渐增加复杂度

• 质量上升的同时，成本、延迟也会逐渐上升

决策顺序

• 第一层：单次LLM调用
  • 多数应用 retrieval and in-context examples就足够了
• 第二层：Workflow
  • 任务步骤多、且明确、可预期
• 第三层：Agents
  • 任务需要灵活决策
  • 任务没有固定路径，需要动态决定每一步
  • 成本上升、难以预测、响应慢

帮我调研某个市场，找出潜在客户，比较竞品，并输出进入策略。

复杂度是需要有收益的

Frameworks

当简单的方案足够解决问题时，复杂的框架可能会带来不必要的复杂性

能够通过LLM API直接实现，就尽量不要做太多事情

使用框架应该确保能够理解底层代码

Building Blocks, Workflows, and Agents

从简单的组合工作流到自主智能体

Block

定义为一个能够调用外部能力的最小单元

augmented LLM = LLM + 增强能力

• 检索能力
• 工具调用
• 记忆读写

或者说是一个增强的LLM，The Augmented LLM

不管是workflow还是agent，都需要其作为最小单元进行组成

Block并不等于Agent。取决于外层组织方式

• 总结这篇文章：系统让LLM检索文章内容并且总结（Block）
• 完成调研：LLM需要先决定要查询资料、整理资料、总结分析，在这个基础上开始决定查什么资料、调用什么、多轮分析给出完整报告（Agent）

总结一下：

• 裸 LLM：只根据 prompt 输出文本
• 增强型 LLM：可以检索、调用工具、使用记忆
• Workflow：把多个增强型 LLM 调用按固定结构组织起来
• Agent：让增强型 LLM 在循环中自主规划、调用工具、根据反馈调整

• 增强LLM：针对当前任务，自己决定需要检索什么、调用什么……完成单次任务
• Agent：具备任务流程基本的控制权，能够决定整个任务如何继续推进

构建这样的LLM需要：

• 明确LLM工具集，应该接近任务本身，不要给无关的工具
• LLM工具接口简要、清晰、文档明确

例如：MCP

后文提到的所有workflow和agent，每次LLM调用都默认是带有检索、工具、记忆能力的augmented LLM

Workflow

workflow并不是简单地多次调用模型

每次模型调用都应该有清晰的输入、职责、可用能力

提供五种workflow设计模式

Workflow1: Prompt Chaining

最简单的workflow，数据沿着链条通过每一个LLM的prompt

任务能够被切分为顺序的一系列步骤

每个LLM处理前一个LLM的输出

可以在任意步骤之间添加一个Gate，保证任务正常流动

具备以下特点的任务常使用此workflow

• 任务可以轻松且清晰地分解为固定子任务
• 能够通过让LLM每次处理更简单的子任务，以延迟换取更高的准确性

任务示例

• 生成营销文案，然后将其翻译成另一种语言。
• 撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档。

Workflow2: Routing

在纯Chain的基础上增加了一些分支结构

显然有时候单份提示词并不能充分完成一个任务

或许我们可以对任务进行分类，不同类型任务使用不同提示词完成

• 按任务类型进行分类：使用不同提示词
• 按任务难度进行分类：使用不同模型节约成本

Workflow3: Parallelization

• 如果能将任务拆分成独立的子任务
• 希望获取同一任务的多样化输出结果（投票）

那么我们可以并行化

• 独立子任务
  • 一个LLM处理查询
  • 一个LLM处理安全审核与防护
• Voting
  • 使用多个不同提示进行code review
  • 多个提示词不同方面or不同阈值做评估

Workflow4: Orchestrator-workers

似乎就是Planner

当子任务无法预先定义的时候，我们可以考虑设置一个Orchestrator做分工

Orchestrator：管弦乐演奏家；管弦乐编曲家

可以理解为编排器、指挥、协调器

与并行化最大的区别：子任务由协调器根据具体输入动态确定

• 对多个文件进行复杂修改
  • 需要分工出不同线路对不同文件单独做不同修改
• 从多个来源做信息搜集

这里会觉得像Agent？

但是仍然是定死了先编排，再分工

Agent可以自己决定使用哪一套workflow与任务安排

Workflow5: Evaluator-optimizer

似乎就是Reflection

一个 LLM 调用生成响应，而另一个则在循环中提供评估和反馈

• 拥有明确的评估标准，迭代可以带来价值优化
  • 人类能为LLM输出提供反馈
  • LLM能通过人类反馈进行打磨提升

满足这两个条件，就可以考虑让模型做评估优化

• 文学翻译：LLM不断发现细微之处进行改进
• 多轮搜索：LLM决定是否继续搜索

Agent

• Step1：根据人类指令或互动讨论开始工作
• Step2：自主规划，开始运作（必要时返回给人类）
• Step3：执行过程中，必须从每个步骤处获取真实情况（工具调用结果or代码执行结果），评估进展
  • 在检查点or障碍处进行暂停，询问人类
• 任务完后终止，或设置停止条件（例如最大迭代次数）

何时使用：

• 难以预测步骤数量
• 无法硬编码固定路径
• 开放问题

同时：Agent高度自主，因此最好在沙盒中，设置防护措施

防止错误累积

核心：基于环境反馈循环使用工具

因此工具集和文档的设计至关重要

Summary

Combining and Customizing

其实不需要过度在意所谓的规范，应该根据实际场景使用具体范式

关键：衡量性能与实现

只有能切实改善结果时，才会增加系统复杂性

Principles

从简单的提示词开始，通过全面评估进行优化

遵守三项原则

• 简洁性
• 透明度：展示智能体的规划步骤
• 把工具设计成模型容易理解、容易正确使用、容易从错误中恢复的形式
  • 一定要方便调试

Appendix

Customer support

与客户交互天然适合使用Agent，非常推荐从chatbot升级到agent

• 客服：天然是聊天界面
• agent 比普通 chatbot 多了工具能力

同时agent通过与客户交互过程中了解用户需求，明确动作

• 对于客户数据、订单历史记录和知识库文章
  • 可以通过工具调用进行获取，获取信息后作为上下文
  • 但这里的操作比较松弛
• 对于退款、更新工单等写操作
  • 非常危险，需要由业务代码进行校验
  • 应当设计一个代码接口（内部需要进行非常严格的参数校验，必须由程序化代码来保证权限、规则、确定性和审计）
  • 最后暴露给模型的一般是一个函数接口

并且该类任务容易获取是否成功：通过客户反馈

Coding Agent

• 代码方案可以设计测试代码检验
• 通过测试结果反馈迭代
• 问题定义明确
• 输出指令可以客观衡量

Tool

对于工具集文档的书写非常重要，甚至比任务提示词更重要

这里可以称为：Agent-Computer Interface

• 降低认知负荷
  • 让模型在输出格式化结果前，有足够的token进行思考
  • 避免复杂格式限制
    • json里写代码需要对换行、双引号进行痛苦转义
• ACI接口要让人类都能看得懂
  • 清晰的边界、对待初级程序员
• 防呆设计（例如CPU的防呆卡槽会让你无法装反CPU）
  • 从工具的底层逻辑和参数设计上，让模型“根本没有犯错的机会”
  • 例如：模型不擅长相对路径，那就要求模型全部输出绝对路径