第 1 章 · Anthropic 官方怎么说

本章观点

本章不是为了证明 Anthropic 的定义“绝对正确”。Agent 这个词在行业里本来就没有唯一标准，不同公司会根据自己的产品形态给出不同定义。

我们采用 Anthropic 的定义，是因为它适合工程教学：它把问题从“Agent 到底有多智能”转成了一个更可判断的问题：

任务路径到底由谁决定：代码，还是 LLM？

这个问题足够具体，能指导设计。它也有局限：现实系统常常不是纯 Workflow 或纯 Agent，而是混合体。一个好的工程师不应该只会贴标签，而应该能说明：哪些环节交给模型动态决定，哪些环节仍然必须由代码和人控制。

1.1 原文出处

本章所有引用来自 Anthropic 官方工程博客：

《Building Effective Agents》 —— 2024-12-19 发布 URL: https://www.anthropic.com/engineering/building-effective-agents

这是目前业内最被广泛引用的 Agent 工程定义。Anthropic 是 Claude 的开发商，也是 MCP 协议和 Agent SDK 的发布方。他们既是 agent 理论的提出者，也是 agent 产品的实现者——所以他们的定义有"既是裁判又是运动员"的权威性。

1.2 核心定义

Anthropic 把"用 LLM 做事"的系统分成两大类：Workflow 和 Agent。原文是这样说的：

"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."

翻译过来：

Workflow（工作流）：LLM 和工具的调用路径是开发者预先写死的。LLM 只在被调到时干活，干完把结果交回流程，下一步去哪是代码决定的。
Agent（智能体）：LLM 自己决定下一步干什么、调用什么工具、什么时候停。开发者只给目标和工具，不写路径。

这是全教程最重要的一句话。我们后面所有的讨论都建立在它上面。

1.2.1 把定义拆成 4 个工程关键词

predefined code paths：路径提前写死。比如“先分类，再检索，再总结，再发给用户”。每一步什么时候执行，由代码决定。LLM 只负责某一步的判断或生成。

dynamically direct：路径运行时才决定。LLM 看到工具返回后，可以决定继续查、换工具、回退、总结或停止。开发者给的是目标和边界，不是每一步的固定路线。

tool usage：Agent 不是只在脑子里想。它必须能通过工具接触外部世界，例如搜索、读文件、查数据库、调 API、写代码、生成邮件草稿。

maintaining control：控制权不等于无限权限。它指的是 LLM 控制任务推进方式，而不是系统放弃安全边界。生产级 Agent 仍然需要权限白名单、预算、日志和人工确认。

把这 4 个词合起来，Agent 的工程定义就很清楚：在受控边界内，让 LLM 根据环境反馈决定下一步行动。

1.2.2 这个定义和 ReAct / Reflexion 的关系

Anthropic 的定义强调“LLM dynamically direct their own processes”，也就是控制权：任务路径不再完全由代码预设，而是由模型根据上下文和工具反馈动态决定。

ReAct 补充了“动态决定”如何发生：不是先一次性想完整计划，再机械执行，而是在 Thought -> Action -> Observation 的短循环里不断修正。这个结构让 Agent 的决策过程更可检查，也让外部观察结果能及时进入下一步推理。

Reflexion 则补充了“失败以后怎么办”：如果一次完整轨迹失败，Agent 可以把失败原因总结成语言经验，写入 episodic memory，并在下一次尝试时避免同类错误。它把 Agent 从“单次任务执行器”推进到“能从经验中改进的系统”。

所以，本教程对 Agent 的完整理解是：

Agent 是由 LLM 动态控制路径、通过工具行动、通过观察修正、通过反思积累经验，并在权限和停止条件内运行的系统。

1.3 Workflow vs Agent：一个关键类比

想象你在做菜。

Workflow 像菜谱：

第一步：洗菜（调用 LLM 写一段"洗菜步骤说明"）
第二步：切菜（调用 LLM 生成"切菜尺寸建议"）
第三步：下锅炒（调用 LLM 给出"火候建议"）

每一步都调 LLM，但步骤顺序是你写死的。LLM 不能说"我觉得今天这道菜应该先焯水"——它只能在给它那一步里发言。

Agent 像给工作伙伴一个厨房：

用户给出目标："做一道好吃的番茄炒蛋。"
伙伴（LLM）自己看冰箱有什么（调 check_fridge 工具）→ 发现没鸡蛋 → 自己下楼买（调 buy_eggs 工具）→ 回来打蛋 → 发现番茄坏了 → 换成番茄罐头 → 炒 → 装盘 → 通知你"做好了"。

路径是伙伴临时决定的，不是你写死的。 这是 Agent 和 Workflow 的本质区别。

注意这并不意味着 Agent 比 Workflow "高级"。Anthropic 在博客里明确说：

"Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop."

——Agent 看似复杂，实现常常很直白：就是一个 LLM + 工具 + 循环，根据环境反馈决定下一步。复杂的是它的行为，不是它的代码。

1.3.1 从代码视角看区别

Workflow 的代码通常长这样：

python

category = classify(user_input)
if category == "refund":
    answer = refund_flow(user_input)
elif category == "complaint":
    answer = complaint_flow(user_input)
else:
    answer = general_qa(user_input)

这里虽然用了 LLM，但下一步去哪是 if/else 决定的。你能提前画出完整流程图。

Agent 的代码更像这样：

python

while not done:
    action = llm.decide(task, state, available_tools)
    result = run_tool(action)
    state = update_state(state, action, result)
    done = should_stop(state)

这里你只能提前定义“有哪些工具、哪些权限、最多跑几步”，不能准确预知它每一轮会选哪个工具。这就是灵活性的来源，也是风险的来源。

1.3.2 边界案例：看起来像 Agent，但可能不是

系统	是不是 Agent	判断理由
客服机器人先分类再走固定流程	通常不是	路径由代码预设，LLM 只是分类器或回复生成器
RAG 问答系统先检索再回答	通常不是	检索步骤由系统固定触发，LLM 没有决定下一步
代码助手能读文件、改文件、跑测试、根据报错继续修改	更接近 Agent	它会根据测试反馈动态选择下一步
自动发邮件脚本里，LLM 只负责润色文案	不是	自动化来自脚本，不来自 LLM 决策
研究助手能搜索、阅读、比较、追问自己缺什么信息	是	工具选择和停止条件都依赖运行时判断

判断时不要看名字。很多产品叫 Agent，但本质是 Workflow；也有些产品不叫 Agent，却已经具备 Agent 的运行方式。

1.4 五种 Workflow 模式

Anthropic 在博客里列了五种常见的 Workflow 模式。这些模式是预先写好路径的，但用 LLM 增强每一步。理解它们有助于你看清"什么时候该用 Workflow，什么时候该上 Agent"。

模式 1：Prompt Chaining（提示链）

把任务拆成串行步骤，每一步的输出是下一步的输入。

例子：写一篇技术博客

LLM 调用 1：生成大纲
LLM 调用 2：根据大纲写正文
LLM 调用 3：审校润色

适合：任务能干净地拆成固定步骤，每步可独立验证。

模式 2：Routing（路由）

第一步用一个 LLM 做分类，把输入路由到不同的专门处理。

例子：客服系统

LLM 调用 1：判断用户问题是"退款 / 投诉 / 咨询"
根据分类，调用专门的退款 agent / 投诉 agent / 咨询 agent

适合：输入有明确的类别，每类需要不同的处理逻辑。

模式 3：Parallelization（并行）

多个 LLM 同时处理一个任务，结果聚合。分两种变体：

Sectioning：把任务拆成几块并行做（比如同时给一篇文档写中文摘要、英文摘要、关键词）
Voting：让多个 LLM 对同一问题给出答案，投票取多数（提升正确率）

适合：任务可拆分、或需要降低单次调用风险。

模式 4：Orchestrator-Workers（编排-工人）

一个中央 LLM 动态拆任务、派给 worker LLM、再综合结果。

例子：写一份市场调研报告

Orchestrator LLM：分析任务，决定要查"竞品 / 用户画像 / 价格"
派 3 个 worker 分别去查
Orchestrator 把 3 份结果合成报告

注意：这个模式看起来像 Agent，但路径是 Orchestrator 决定的——它依然是 Workflow，因为 Orchestrator 的"拆任务"逻辑是 prompt 里写好的，不是真自主循环。

模式 5：Evaluator-Optimizer（评估-优化）

一个 LLM 生成结果，另一个 LLM 评估并给反馈，循环优化。

例子：代码生成

Generator LLM：写代码
Evaluator LLM：跑测试 → 失败 → 给反馈"第 5 行有 bug"
Generator LLM：根据反馈改代码
循环直到测试通过

适合：有明确评估标准、可迭代优化的任务。

1.5 什么时候用 Workflow，什么时候用 Agent

Anthropic 给了一个清晰的取舍：

场景	选择	原因
任务步骤可预测、可拆解	Workflow	路径明确，写死更可靠、更便宜
任务步骤不确定、需要临时决策	Agent	LLM 自主决策才能应对
任务对延迟和成本敏感	Workflow	路径短，token 消耗可控
任务开放性强、目标模糊	Agent	自主循环才能探索

经验法则：先用 Workflow，不够了再上 Agent。Agent 的代价是 token 消耗和不确定性——Anthropic 自己说，多 agent 系统用的 token 是普通聊天的约 15 倍（来源：Multi-agent research system）。

1.5.1 一个实际选型例子

假设你要做“自动整理会议纪要”。这个任务可以拆成三个版本：

版本 A：固定 Workflow

上传录音或文字稿。
转写成文本。
LLM 总结议题、结论、行动项。
输出到文档。

这个版本路径很稳定，适合 Workflow。它便宜、可控、容易测试。

版本 B：带工具的 Workflow

总结会议内容。
根据行动项查项目管理系统。
把任务同步到 Jira 或飞书。
高风险操作前让用户确认。

这仍然可以是 Workflow，因为“查系统”和“写任务”的顺序是固定的。

版本 C：Agent

用户只说：“帮我把这次会议后续事项都处理掉。”系统需要自己判断：哪些是任务，哪些要查历史文档，哪些要问负责人，哪些可以创建任务，哪些需要等待用户确认。这里路径不确定，才有上 Agent 的理由。

这就是选型原则：不是任务听起来复杂就用 Agent，而是路径不可预测时才用 Agent。

1.6 为什么用 Anthropic 的定义作为基线

市面上关于 Agent 的定义五花八门。有人把任何"会调函数的 LLM"叫 agent，有人把"有记忆的 LLM"叫 agent，还有人把"能自主决策的系统"叫 agent。

我们选 Anthropic 的定义作为全教程基线，理由有三：

来源权威：Anthropic 是 Claude 的开发商，也是 MCP 和 Agent SDK 的发布方。他们的工程博客是业内引用最多的 agent 文献。
工程化而非概念化：Anthropic 的定义刻意把 agent 和 workflow 区分开，强调“agent 是 LLM 自主决策”，而不是把 agent 泛化成所有智能自动化系统。这种克制对工程实践更友好。
与工具生态对齐：本教程后面要讲的 MCP、Agent SDK、Skills 全是 Anthropic 主导的。用他们的定义做基线，概念之间是无缝衔接的。

如果你看完别的教材觉得“agent 定义怎么各家都不一样”，可以先采用本教程的统一口径：以 Anthropic 的定义为基线，再结合状态、权限和停止机制做工程补充。

1.6.1 我们对这个定义的补充

Anthropic 的定义解决了“路径由谁决定”的问题，但它没有单独强调三件事，而这三件事恰恰决定 Agent 能不能落地：

状态管理：Agent 要知道自己做过什么、失败过什么、还缺什么信息。
权限设计：Agent 能读和能写是两件事。读网页和发邮件的风险完全不同。
停止机制：Agent 必须知道什么时候完成、什么时候放弃、什么时候交给人。

所以本教程会把 Anthropic 的定义扩展成一句工程判断：

Agent = 动态路径决策 + 工具执行能力 + 观察反馈 + 反思记忆 + 明确停止与权限边界。

这不是为了造新概念，而是为了防止初学者只看到“动态决策”，忽略了“工程边界”。

1.7 常见误区

误区 1：Workflow 低级，Agent 高级。 不对。Workflow 更稳定、更便宜、更容易评估。很多生产系统应该优先用 Workflow。

误区 2：只要让 LLM 自己写计划，就是 Agent。 不够。计划如果只生成一次，后续没有根据工具反馈继续调整，就更像一次性规划，不是完整 Agent Loop。

误区 3：Agent 不需要流程设计。 正好相反。Agent 更需要边界设计：工具清单、权限、预算、最大步数、失败回退、人工确认点。

误区 4：多 Agent 是 Agent 的终点。 多 Agent 是一种昂贵架构，不是必经路线。单 Agent + 好工具 + 好评估，常常更适合入门和生产。

前人智慧 / Prior Art

本章把 Anthropic 的 Agent 定义作为全教程基线。这个选择不是盲从权威，是因为 Anthropic 的定义在三个维度上对工程实践最友好：来源权威、工程化而非概念化、与工具生态对齐。这一节拆解这个定义背后的几份关键文献。

《Building Effective Agents》：定义的原文

Anthropic 工程博客（2024-12-19）是本章所有引用的源头。这篇博客的核心贡献不是"发明了 Agent 概念"，而是把模糊的 Agent 词分成了两个可工程判断的类别：

Workflow：LLM 和工具通过 predefined code paths 编排
Agent：LLMs dynamically direct their own processes

这个二分的关键工程价值在选型：它给了开发者一个明确判断标准——"路径由谁决定"。在 Anthropic 之前，行业里"Agent"被用来指任何"会调函数的 LLM"或"有记忆的 LLM"，这种泛化让工程讨论没法进行。Anthropic 的克制定义让"什么时候上 Agent"成了一个可回答的问题。

五种 Workflow 模式的来源

博客里列的五种 Workflow 模式（Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer）不是 Anthropic 凭空造的，它们是对 2023-2024 年社区实践的命名和归纳：

Prompt Chaining：早期 LangChain Chain 的抽象
Routing：客服系统的标准做法
Parallelization (Voting)：Self-consistency 论文的工程化
Orchestrator-Workers：MapReduce 模式在 LLM 上的迁移
Evaluator-Optimizer：Reflexion 的简化版

Anthropic 的贡献是把这五种模式从框架实现里抽象出来，让它们成为可以独立于框架讨论的设计模式。本章 1.4 节的表格直接用了这套命名。

"先 Workflow 后 Agent"的工程智慧

博客里有一段常被引用的话：

"Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop."

这句话的工程智慧在克制：不把 Agent 神秘化，强调它本质就是 LLM + 工具 + 循环。这种克制让本章 1.5 节"先 Workflow 后 Agent"的选型原则站得住脚——如果 Agent 是神秘高级品，就要尽量上；如果 Agent 就是 LLM + 工具 + 循环，那就可以冷静判断"是不是真的需要"。

OpenAI 的对照视角

OpenAI 在 Agents SDK 文档里给了一个和 Anthropic 互补的视角：

"An agent is an LLM equipped with instructions and tools."

OpenAI 的定义更宽松——不强调"动态路径"，只强调"有指令 + 有工具"。差别在 OpenAI 把 Workflow 和 Agent 的界限模糊了（OpenAI 的 SDK 里 Handoff 机制本质是 Workflow）。

两种定义没有对错，反映了两家公司的产品哲学：

Anthropic：克制，强调边界，适合需要稳定生产的环境
OpenAI：宽松，强调灵活，适合快速原型

本教程选 Anthropic 作为基线，是因为对入门开发者来说，先学会克制再放开比"一上来就放飞"更安全。

Multi-agent Token 成本的工程信号

Anthropic Multi-agent Research System 博客披露：多 Agent 系统用的 token 是普通聊天的约 15 倍。本章 1.5 节的"Agent 代价"引用了这个数据。

这个数字的工程意义不在"15 倍贵"，而在它把 Agent 的成本量化了。讨论"要不要上 Agent"时，有一个可参考的成本倍数，比"Agent 会增加成本"这种模糊说法有用得多。

工程化 vs 概念化的取舍

市面上 Agent 定义五花八门的根源，是概念化定义和工程化定义的混用：

概念化定义：Agent 是"能自主决策的系统"——宽泛，难工程判断
工程化定义：Agent 是"LLM 动态决定路径的系统"——具体，可判断

Anthropic 选了工程化路线。本教程继承这个选择，并在 1.6.1 节扩展成"动态路径决策 + 工具执行能力 + 观察反馈 + 反思记忆 + 明确停止与权限边界"——这是工程化定义的完整版。

读其他 Agent 教材时如果觉得"定义怎么各家都不一样"，多半是混用了两种定义。用本教程的口径（Anthropic 工程化基线 + 四权扩展）能避免这种混乱。

找一个你用过的 AI 应用，判断它是 Workflow 还是 Agent，并写出依据。
把“自动整理会议纪要”分别设计成 Workflow 版和 Agent 版。
选一个开放任务，列出它为什么不能简单写死路径。
为这个开放任务写 3 条安全边界：哪些工具能用，哪些操作必须人工确认，最多跑几轮。

1.9 小结

Workflow：路径开发者写死，LLM 只在被调到时干活。
Agent：路径 LLM 自己决定，开发者只给目标和工具。
Agent 的实现：LLM + 工具 + 观察反馈 + 反思记忆 + 停止边界，复杂的是运行轨迹不是单段代码。
五种 Workflow 模式：Prompt Chaining / Routing / Parallelization / Orchestrator-Workers / Evaluator-Optimizer。
选型：先用 Workflow，不够再上 Agent。

下一章我们用一个 30 行的伪代码，把这个"LLM + 工具 + 循环"的心智模型落到代码上。

第 1 章 · Anthropic 官方怎么说 ​

本章观点 ​

1.1 原文出处 ​

1.2 核心定义 ​

1.2.1 把定义拆成 4 个工程关键词 ​

1.2.2 这个定义和 ReAct / Reflexion 的关系 ​

1.3 Workflow vs Agent：一个关键类比 ​

1.3.1 从代码视角看区别 ​

1.3.2 边界案例：看起来像 Agent，但可能不是 ​

1.4 五种 Workflow 模式 ​

模式 1：Prompt Chaining（提示链） ​

模式 2：Routing（路由） ​

模式 3：Parallelization（并行） ​

模式 4：Orchestrator-Workers（编排-工人） ​

模式 5：Evaluator-Optimizer（评估-优化） ​

1.5 什么时候用 Workflow，什么时候用 Agent ​

1.5.1 一个实际选型例子 ​

1.6 为什么用 Anthropic 的定义作为基线 ​

1.6.1 我们对这个定义的补充 ​

1.7 常见误区 ​

前人智慧 / Prior Art ​

《Building Effective Agents》：定义的原文 ​

五种 Workflow 模式的来源 ​

"先 Workflow 后 Agent"的工程智慧 ​

OpenAI 的对照视角 ​

Multi-agent Token 成本的工程信号 ​

工程化 vs 概念化的取舍 ​

1.9 小结 ​