前阵子有个做后端的老同事跑来问我，说他们团队准备上一个“智能客服助手”，老板听完产品经理的汇报，张口就要“接入大模型、自动拆单、自动跟进、自动复盘”，恨不得把整个客服部变成一个全自动的 Agent。他问我：Anthropic 那篇《Building Effective Agents》到底讲了啥？为什么网上抄来抄去的架构图长得都不一样？是不是照着那张经典的五步工作流图搭一套东西，就能叫“构建有效的智能体”了？

这个问题特别典型。现在“智能体”（Agent）这个词有点被用滥了，什么功能都往里装，最后项目上线没两天，不是 token 烧得飞快，就是结果不可控，根本不敢让它在线上自动跑。但如果认真读过 Anthropic 的官方架构笔记，你会发现人家通篇在讲两件事：第一，大多数“看着像智能体”的场景，其实用“工作流”就能解决；第二，真正的智能体，它的价值在于处理那些路径不确定、需要动态决策的开放问题，而不是把一切问题都推给一个“万能的 Agent”。

这篇文章我就把 Anthropic 那份架构笔记的核心脉络拆开来讲，结合我自己的实现体会，把“工作流”和“智能体”的边界、五种工作流模式的适用场景、真正 Agent 的环境构成、以及怎么按复杂度阶梯做选型，全部讲清楚。无论你是刚入门想搭第一个 Agent 的开发者，还是已经踩过一些坑、想回头把架构理清楚的技术负责人，这篇文章应该都能给你一个可以下单的决策框架。

1. 先认清一件事：工作流和智能体根本不是一回事

1.1 为什么这个区分如此敏感

Anthropic 建架笔记里最开始就抛出了两个定义，我读完之后觉得这可能是全文最重要的两句话，没有之一：

• 工作流（Workflows）：通过预定义的代码路径来编排 LLM 和工具的系统。你写死步骤，模型在固定的轨道里跑。
• 智能体（Agents）：由 LLM 动态地自我指导其流程和工具使用，并对如何完成任务保持控制权。模型自己决定下一步干嘛。

听上去很简单，但现实中绝大多数团队在这上面栽跟头。我见过一个项目，产品经理要求“必须上 Agent”，开发同学就直接把一段 RAG 查询逻辑包装成一个“ResearchAgent”，里面三个 Worker 并行去查库，外面再套一个 Orchestrator 汇总。结果呢？明明是一个固定的“查资料—生成摘要”流程，硬生生被做成了带不确定性的多轮调度，日志乱成一锅粥，每个 Worker 各写各的，出问题根本定位不了。最后发现，把这段逻辑改成一个 30 行的 Prompt Chaining 工作流，又快又稳，还便宜。

这个例子非常典型，因为它说明了一个核心道理：智能体不是一种“更高级”的工作流，它们是两类完全不同的系统。工作流的核心特征是“确定性”——路径是写好的，每一步做什么清清楚楚，适合那些“你本来就知道正确步骤是什么”的任务。智能体的核心特征是“不确定性”——你只给目标，模型自己规划路径，适合那些“你也不知道中间要经过哪几步”的开放问题。

1.2 一些容易混淆的系统边界

顺着这个区分，有几个常见场景经常让人犯迷糊，我把它拉到台面上说清楚：

• 工具调用（Tool Calling / Function Calling）：模型输出一个 JSON，告诉系统“我要调用某函数，参数是什么”。这只是一个基础能力，不等于智能体。它和工作流、智能体都兼容，你可以在一个固定工作流里让模型调用工具，也可以在一个 Agent 循环里让它反复调用工具。
• RAG（检索增强生成）：检索 + 生成。如果检索和生成的顺序是固定的，它就是工作流；如果模型决定“我先查 A，再查 B，还是先写大纲再检索”，那才是智能体的行为。很多人把 RAG 当 Agent 卖，其实大部分 RAG 只是工作流。
• ReAct 模式的循环：这是一种典型的 Agent 循环——模型观察结果、思考、行动、再观察。它可以是智能体，也可以被封装成一个固定循环当成工作流用。判断标准取决于循环内决策的自由度有多大。

安氏笔记给了一个特别好的比喻方向：工作流像工厂里的流水线，每个工位做什么是固定的，好处是可预测、好调试；智能体像一个被授权独立做决定的项目经理，你只告诉他“把这件事办成”，具体怎么找人、怎么推进、怎么调整，都是他自己说了算。这也是为什么智能体更灵活，但也更不可控——因为“项目经理”也有可能跑偏。

搞清楚了这层边界，后面那些模式才谈得上选型。否则，你拿着五种工作流的图去硬套智能体场景，或者反过来拿一个 Agent 循环去跑固定路径，都会得很别扭。

2. 五种工作流模式的工程画像与应用边界

Anthropic 笔记里列了五种工作流模式，这五个模式放在一起，其实是一个复杂度递增的序列。我先逐个拆解它们的结构、适用场景、优缺点，再给你我总结出来的选型经验。

2.1 Prompt Chaining：把大任务拆成有先后的流水线

Prompt Chaining 是最简单也最容易被低估的工作流模式。它的结构是：把一个任务拆成一系列步骤，每一步的输出成为下一步的输入，中间可以穿插程序化判断（比如网关检查、格式校验、关键词过滤）。

一个很实用的例子是“写周报”。

第一步，让模型把本周的原始工作日志整理成结构化条目；第二步（程序逻辑），检查结果里是否包含至少三条有效记录，不满足就报错重试；第三步，让模型把条目转成正式周报文案；第四步，另一个模型扮演“读者”，审一遍是否读起来像人写的，不像就退回重写。每一步各用各的 Prompt，每个模型职责单一，问题出在哪一目了然。

它的适用场景是：任务可以清晰地切割成多个阶段，且前一步的质量直接影响后一步的效果。比如内容生成、翻译后校对、文档润色、多阶段数据处理。好处是极大降低每个 Prompt 的复杂度，坏处是延迟会叠加（每一步都要等模型输出），而且步骤一旦设计错了，调整的代价也不小。

这里有一个很容易踩的坑：把 Prompt Chaining 当成“多个 Prompt 顺序调用”就行，而忘记在中间加程序化校验。

我见过很多实现，第一步模型输出一份 JSON，第二步直接塞给下一个 Prompt，结果第一步偶尔输出格式错误或内容空泛，第二步根本没法用。正确做法是在每步之间用一个轻量的校验函数做“网关”，不行就直接重试这一步，而不是让错误一路传导下去。这其实和生产环境里“每个服务之间要做契约测试”是同一个道理。

2.2 Routing：先分类，再分派

Routing 解决的是“一类问题有多种处理路径，需要先判断走哪条”的场景。它的结构是：先用一个分类器（通常是一个小模型或一个带分类指令的 LLM）判断输入属于哪一类，然后转发到对应的、专门优化的 Prompt 或模型。

我自己的博客站就是这么做的：用户的评论进来，先判断是“技术提问”“广告垃圾”还是“闲聊”，然后分别走到三个处理流程里——技术问答走一个带代码规范的 Prompt，广告垃圾直接程序化过滤，闲聊走一个轻量回复。就这么一个 Routing，整个评论区的处理质量提升了一大截，而且每个分支的 Prompt 都短小精悍，Token 成本也降下来了。

Routing 也常用于：客户支持工单分类后分派到不同处理流程、多模型策略（通用任务用小模型省钱，复杂代码任务用大模型）、内容审核分级。

它的关键在于那个分类器。你可以直接用 LLM 做分类（注意要用结构化输出，别让它自由发挥），也可以用一个小的微调模型甚至是关键词规则做预筛。实际工程里我经常先用规则把高置信度的样本分流掉，剩下的模糊样本才交给 LLM，省 token 又稳定。

2.3 Parallelization：并行干活，分“分片”和“投票”两种

并行化讲两种具体形式：分片（Sectioning）和投票（Voting）。

分片是把一个大任务切成多个相互独立的小块，让多个模型实例同时处理。比如“让 AI 审阅一份 100 页合同”，你可以切成十个部分，分别提示模型关注不同的重点（有的关注违约责任、有的关注知识产权、有的关注数据合规），最后程序汇总所有结果，生成一份总报告。这里有个要点：切分之后，每个分片之间不能有强依赖，否则就不是真并行，而是伪并行。

投票则是让多个模型实例对同一个任务各自独立生成结果，然后通过评分、多数表决或加权平均来选出最优答案。这个思路适合那些“主观性强、需要综合不同视角”的任务，比如代码审查找 bug、开放性问题头脑风暴、多选题答案的共识验证。

我这里要补充一个实操心得：投票模式虽然听起来很“民主”，但成本是成倍上升的（N 个模型实例就是 N 倍 token），而且不一定每次都能选出更好结果。我建议投票只在“错误代价高”的场景用，比如生成发布公告、重大决策建议这种需要“多一人看一眼”的地方。日常内容生成没必要用投票，Parallelization 里更常用的是分片。

2.4 Orchestrator-Workers：动态拆解与分派

当任务不能提前拆好、必须动态决定怎么拆的时候，就需要 Orchestrator-Workers 模式了。结构是三层的：一个 Orchestrator（主控模型）负责分析任务、分解出子任务、把子任务分派给多个 Worker（每个 Worker 配一个 Prompt 或一个工具），并汇总最终结果。Worker 的反馈可以影响下一轮拆解，Orchestrator 是唯一的全局统筹者。

这个模式是五种工作流里最接近“看起来像智能体”的一种，很多平台所谓的“多 Agent 编排”实际上还是 Orchestrator-Workers，因为真正自由的 Agent 循环不会预先定义“我们一共有几个 worker 角色、每个角色负责什么”——那是编排好的角色，而不是动态涌现的分工。

Orchestrator-Workers 适合哪些场景呢？

• 代码工程里动态确定需要修改哪些文件、写哪些测试；
• 复杂研究报告，先让 Orchestrator 列出大纲再分头去查；
• 数据分析，主控模型先决定子任务序列，然后动态分派给“写 SQL 的”“画图表的”“写结论的”。

它的最大优势是“任务分解动态化”，能处理那些结构不完全确定的任务；最大缺点是贵且慢，因为一次任务往往要很多层 LLM 调用。调试也难，因为你看到的是 Orchestrator 先生成的一个“计划 JSON”，然后每个 Worker 各自输出，一个问题可能出在任何一层。

有一类典型错误是：把本来一个 Prompt 能干的活（比如“帮我整理这五份资料的大纲”）硬拆成 Orchestrator + Workers，结果计划生成的 token 比实际干活的 token 还多。搞数据的人喜欢说“杀鸡焉用牛刀”，其实这里要反过来劝一句：牛刀也是钱，能不用就不用。

2.5 Evaluator-Optimizer：一个写，一个审，循环打磨

Evaluator-Optimizer 是五种工作流里最强调“质量循环”的一个。它包含两个角色：生成器（Generator）负责产出内容，评估器（Evaluator）负责对生成的产出给出反馈，如果评估不通过，生成器依据反馈重新生成，如此循环，直到评估通过或达到最大轮次。

最常见的应用是“文章润色”：生成器写初稿，评估器按照“逻辑连贯性、信息密度、口语自然度、结构完整度”四个维度打分，低于阈值就打回重写。我试过跑几轮之后，文本质量确实肉眼可见地提升，尤其在长文任务上。另一个典型是代码修复：生成器改代码，评估器用测试用例验证是否通过，或者让另一个模型做 code review，不合格就继续改。

这个模式有一个前提条件，只有用在“评估标准可以明确表达”的任务上才能生效。如果评估器自己都说不清什么是“好”，那循环就会变成两个模型之间的无限扯皮——生成器改一版，评估器说不行，再改一版，还说不行，token 烧完也没个结果。所以，如果你没法写出清晰的评估标准，就别上这个模式。

另外，工程上要给这个模式加一个“最大循环次数”的硬上限，防止死循环。我习惯设成 3 轮，到了一定还不行就保留当前最优版本，让程序终止而不是无限跑下去。这是评估器-优化器模式里最容易忽略的生产级细节。

2.6 五种模式怎么选：一张选型表

我整理了一张简单的选型表，是我在实际项目里用来快速判断的：

这张表不是“越高越好”，恰恰相反，Anthropic 笔记里反复强调的选型铁律就是：从最简的模式开始，能满足需求就不加复杂度。大多数情况下，一个 Prompt Chaining 加一个 Routing，就已经能覆盖市面上很多号称“智能体”的典型应用了。

3. 真正的智能体是什么：动态决策链的三块拼图

聊完工作流，终于到主角了。Anthropic 笔记对智能体的定义，我高度浓缩成一句话：智能体是一个运行在特定环境里的循环系统，模型在循环中反复决策“下一步做什么”，并通过工具与环境交互，直到任务完成。

它有三块拼图缺一不可：环境（Environment）、工具（Tools）、Agentic 循环（Agentic Loop）。很多人搭智能体失败，本质上是把这三块看成了可选项，搭出来的东西其实是“套了 Agent 壳的工作流”。

3.1 环境是智能体存在的前提，不只是“API 地址”

先讲环境。一个真正的智能体必须存在于一个它可以施加影响的环境里——它可以读文件、跑命令、发请求、操作界面、查询数据库。如果你只是给模型一个“邮箱地址”让它“假装发邮件”，那它其实没有环境，那个所谓的 Agent 只是一个文本生成器。

举个形象的例子：同样是“帮我整理文档”，工作流版的实现是“你上传文档，我按 1-2-3 的步骤帮你解析、提取、生成摘要”，最后得到一段文本；智能体版的实现则是“给它一个带文件系统的沙箱环境，让它自己找到待处理文件、安装依赖、写脚本解析、保存结果到指定目录”。区别的本质是：后者在一个“真实可操作”的环境里完成了任务闭环。

我之前见过一个比较失败的设计：团队想做一个“数据分析智能体”，但给模型的环境只有一个 API，让它“根据用户问题返回答案”。没有数据库、没有代码执行环境、没有可视化能力，模型只能“想”而不能“做”，最后出来的结果既不精确也不可验证，本质上就是个高级搜索引擎。这个案例说明，环境不匹配时，智能体就是空转的。真正要落地，至少要给它一个可执行的代码沙箱或一套可真实操作的工具集。

不过这里要提醒一句：环境赋予了智能体“做事”的能力，也意味着它能做“错事”。所以生产环境里给智能体的权限要闭环管理：专门的沙箱目录、受限的网络出口、以及对危险操作的程序级审批。这属于“环境安全域”的工程细节，很多人后面上线了才补，代价不小。

3.2 工具不是“插件墙”，而是智能体能力的边界

第二块是工具。Anthropic 笔记里强调：工具是智能体能力的接口，一个好的工具集合比一个复杂的 Prompt 更值钱。

工具的设计直接影响智能体的决策质量。我在实际项目中拆过两条工具设计原则：

第一，工具要小而正交。每个工具只做一件事，语义清晰。比如“search_web”“read_file”“write_file”“execute_python”四个工具各司其职，比一个“do_everything_tool”要好用得多。模型在循环里需要的是按需组合工具，而不是在一个巨型函数里传递各种各样的参数。大而笨重的工具，对模型而言很难用对。

第二，工具的输入输出描述要写清楚。尤其是输入和输出的 JSON Schema、字段含义、边界值，这直接决定了模型能不能正确调用。我见过不少团队的工具描述就一句话“查询用户信息”，也不写参数格式，模型在循环里经常调错。后来我统一维护一份工具的 OpenAPI 风格文档，并且每次迭代都要跑一遍“工具调用回归测试”，情况立刻好转。

这里顺带说一句：工具调用能力是智能体的“手”，而工作流模式同样也能用工具，但智能体场景下工具使用的选择权在模型手里，所以工具设计要更注意“容错”——当模型传入了不合理的参数时，工具本身要能给出明确、可诊断的错误信息，而不是抛一个裸异常。这个门槛，实际上比大多数人想象的高。

3.3 Agentic Loop：循环不是“循环调用”，是“决策-执行-观察”的闭环

第三块，也是最核心的一块：Agentic Loop。它不是一个 while 循环里的多轮 API 调用那么简单。这个循环有四步：

1. 决策：模型根据当前状态（用户目标、已有观察结果、工具反馈）决定下一步动作；
2. 执行：调用选定的工具，产生副作用（读文件、发请求、写数据）；
3. 观察：把执行结果（工具返回内容、报错、环境变化）反馈给模型；
4. 重复：回到决策步，直到模型判断任务已达目标，或者触发终止条件。

一个关键差异在于：工作流也有循环，但循环体内是“固定的重复步骤”；Agent 循环体内是“模型自由决策”。比如，写一个 while 循环让模型反复调用一个翻译接口直到成功，这其实是工作流里的“重试机制”；而让模型自己在“继续翻译”“先查术语表”“换个翻译策略”“直接给最终答案”之间选择，这才是 Agentic Loop。

另外，一个合格的 Agentic Loop 必须有完整的终止条件设计：任务完成的判断、最大步数限制、危险操作的熔断、用户取消的通道。我在笔记里看到过一句话启发很大：“智能体更像是把一个搜索引擎和编译器塞进一个循环里，但你得给它配好刹车。”

所以，真正的智能体 = 环境 + 工具 + Agentic Loop。三者缺一不可。很多平台的“自动化编排界面”其实只是让你搭工作流，不是真正的 Agent；而凡是自称“Agent 框架”的东西，核心就是帮你封装这个循环（通常叫 Runner / AgentLoop）。理解这一点之后，你在选型框架时就不会被“支持多智能体”这种营销词带偏了。

4. 构建有效智能体的选型铁律：最简方案优先

4.1 决策原则与复杂度阶梯

读 Anthropic 笔记，对我冲击最大的不是那几个模式的名字，而是一句几乎可以作为行业准则的话：“优先使用最简单的方案来满足需求。”

它给了一个复杂度阶梯，按性价比排列：

1. 单次 Prompt + 检索增强（或工具调用）
2. 五种工作流（Prompt Chaining 是最简单的一档）
3. 专用 Agent（一个模型负责一个领域，自循环决策）
4. 多 Agent 系统（多个 Agent 协作，各司其职）

从 1 到 4，能力越来越强，但成本、延迟、不确定性、调试难度也在同步上升。笔记里强调的核心思想是：不要为了“用上 Agent”而把问题复杂化，很多需求用更简单的方案反而得到更好结果。

实际项目里我是这么应用的：先问自己三个问题——

• 这个任务的正确步骤是已知的吗？如果是，用工作流。
• 这个任务的输入分支多不多？多的话加 Routing。
• 这个任务的中间步骤会随结果变化吗？如果会，才考虑 Agent。

这三个问题能干掉 80% 的“伪 Agent 需求”。

4.2 为什么大多数场景用智能体反而更糟

我讲讲为什么“无脑上 Agent”会出问题，以及它出问题的具体表现。

首先是不可预测性。工作流的路径是确定的，输入输出关系清楚；Agent 的路径是模型现想出来的，同一个问题跑两次，它可能走完全不同的两条路。这在业务上线时是致命的——你不知道它什么时候会输错、什么时候会突然绕远路。

其次是成本失控。Agent 循环里模型反复决策、反复调用工具，一个原本 500 token 的简单任务，跑成 3000 token 是常事。如果没有做步骤数和 token 的预算控制，月末账单会直接教做人。

再次是调试地狱。固定工作流出错了，你能看到是哪一步挂了；Agent 出错了，你得回放整个决策链——它为什么选了那个工具？为什么收到结果后又改了主意？这需要非常完善的可观测性设计。

所以我对团队的硬性要求是：在引入 Agent 前，必须先把同样需求用固定工作流跑通，拿到基线数据（准确率、延迟、成本），再来评估 Agent 是否有必要。如果固定工作流已经能达到业务指标，那上 Agent 只是自找麻烦。

4.3 一个可复用的架构决策清单

我把我的决策流程整理成了清单，你可以直接拿去用：

• [ ] 这个任务能否被拆成确定的步骤序列？是：用 Prompt Chaining，别想 Agent。
• [ ] 任务是否天然有多分支？是：在链路的头部加 Routing。
• [ ] 任务是否需要多个独立子任务并行？是：考虑 Parallelization（先判断子任务是否真独立）。
• [ ] 任务是否需要边做边调整步骤？是：考虑 Orchestrator-Workers 或 Agent。
• [ ] 任务的结果质量是否可以被明确评估？是：考虑 Evaluator-Optimizer。
• [ ] 任务是否必须由模型在真实环境里自主执行一系列不确定的操作？是：这才是真正的 Agent。
• [ ] 单 Agent 是否不够？同时需要多个不同目标的自主循环？是：才考虑多 Agent 系统。

这个清单走完，你把结果记在文档里。它不只是一个技术选型，更是一个和产品经理对齐预期的沟通工具——因为多数情况下，产品口中的“智能体”，走完清单后你会发现只需一个 Prompt Chaining 加一个 Routing 就搞定了，还能和对方解释清楚为什么那样更稳。

5. 从笔记到落地：Anthropic 官方实践的验证逻辑

5.1 Claude Code 体现的架构思路

光说不练没用。Anthropic 自己的 Claude Code（也集成在很多商业工具里）就是“更倾向 Agent 化”的产品：它运行在终端环境里，可以读文件、执行命令、搜索代码、调用测试工具，几乎每一步决策都是模型自主做出的，有一个 Agentic Loop 在后台驱动。这正好是上面说到的“环境 + 工具 + 循环”的完整落地。

我看到很多团队对 Claude Code 的认知停留在“一个能写代码的命令行工具”，其实它的意义在于展示了：当智能体面对的真实环境是文件系统 + 命令行时，它的工具集设计、权限控制、循环终止条件该怎么做。比如它给每个操作类型设计了白名单和干预入口，允许用户随时打断或批准特定命令，这其实就是给 Agentic Loop 装了一个“人审刹车”——工程上非常务实的做法。

5.2 用官方 Agent SDK 搭建的最小闭环

除了产品和工具，Anthropic 还发布了 Agent SDK，可以把它理解成一套官方推荐的工程底座。SDK 抽象出几个核心角色，我觉得对理解架构也特别有帮助：

• Agent：一个封装了模型、工具、系统提示词的自治循环单元；
• Tool：可被 Agent 调用的能力单元，定义输入输出和权限；
• Workflow：预定义的多步骤流程，可以用代码组合 Agent、工具和外部逻辑；
• Runner / 循环驱动器：负责执行 Agent 循环，管理上下文、步数限制和终止条件。

用 SDK 搭一个最小闭环其实很简单：定义两个工具（比如搜索和写文件），定义一个 Agent，把工具挂上去，然后 Runner 跑起来。你写代码时最需要想清楚的是两点：Agent 的系统提示词（告诉它目标边界和操作原则）和工具的权限范围（它到底能碰什么）。这两点想清楚，后面基本不会出大乱子。

我自己也尝试复刻过一个极简版“代码仓库整理助手”：环境是一个临时 git 仓库，工具是 /read_file、/list_files、/exec_git_command 三个，循环上限 20 步，每步打印决策日志。跑下来发现，它能自己完成“找到改动文件、检查 diff、按规范提交流”这个小流程，而且日志管线清晰，每一步干了什么都能回放。虽然功能非常简单，但把 Agentic Loop 的“决策-执行-观察-循环”跑通了。推荐你也这样练手一遍，比你读十篇架构文章都管用。

5.3 我自己搭“搜索助手”的实测记录

我用 Python 写过一个叫“tech-research-bot”的小项目，功能是：给一个技术问题，让它自己检索、整理、输出报告。结构非常简单：

• 环境：一个支持 HTTP 请求和本地缓存的 Python 沙箱；
• 工具：web_search(query)、fetch_page(url)、save_note(title, content)、final_report(markdown)；
• Agent 循环：模型每步从工具列表里选一个，观察结果后决定下一步；
• 终止条件：模型自己判断资料已够，调用final_report结束，或者步数超过 15 步强制终止。

实测下来最有价值的发现是：给 Agent 一个“思考缓存区”（save_note）之后，输出质量明显提升。因为模型在多轮检索后容易遗忘前期结论，把阶段性发现缓存到本地，再次观察时可以直接读取，等于给循环加了一个外部记忆。这其实是很多生产级 Agent 都会用的小技巧——把内部上下文转储成外部工具可读的笔记，让模型在长任务中不至于“失忆”。

另一个发现是：工具返回内容的长度一定要控制。fetch_page 返回整页 HTML 时，模型经常被无关内容带偏；限制它返回“正文摘要前 1500 字符”，决策质量立刻稳定很多。这听起来像小事，但往往是 Agent 行为不可控的元凶之一。

6. 读这份笔记时最容易踩的坑：三个误区与一个真相

6.1 误区一：把五种工作流当成五种“智能体”

这是传播最广的误解。网上一堆文章把 Anthropic 那张五种工作流的图改个颜色，重新起个名字就当“智能体架构”发出来。但人家原文明明白白写着：这五种模式是workflows，而agents是另一种需要独立设计的东西。

你可以这样理解：工作流是“编排”，智能体是“自主”。如果面试里有人把 Prompt Chaining 说成“这是一种 Agent 架构”，大概率和原创笔记的原意是偏离的。这就像把“流水线”叫“老板”一样，角色完全不同。

从工程实现来说，工作流和智能体的代码写法也不一样：工作流的每一步是显式代码控制的，你在写step1()、step2()、step3()；智能体是你在写一个循环，里面放一个model.decide()，然后根据它的输出执行不同工具。这种代码形态的巨大差异，造成的调试思维也完全不同。

6.2 误区二：Evaluator-Optimizer 就是“Agent 自省”

还有一个常见误解：把 Evaluator-Optimizer 当成“Agent 在自我反思”，并认为这就算是智能体了。

其实不是。Evaluator-Optimizer 是工作流，因为它有固定的角色分工（一个生成、一个评估），循环内容是预设的——生成一版、评估、不合格就回来改，这是一个“闭环但不是自主决策”的过程。Agentic Loop 里的模型是自主决定下一步去执行什么工具、改什么文件、查什么资料，而不是在一个“生成-评估”的封闭循环里原地打转。

一句话总结：Evaluator-Optimizer 是在一个维度的空间里前后摆动，Agent 是在一个高维的行动空间里自由选择方向。两者用的底层模型一样、工具可能也一样，但架构思想绝对不同。

6.3 误区三：多 Agent 一定比单 Agent 强

我见过太多团队一上来就要搞“多 Agent 协作系统”——CEO Agent、运营 Agent、客服 Agent、财务 Agent 一起开会。听起来很酷，但现实很骨感：多 Agent 系统的通信成本、状态一致性、错误传播全部是指数级增长的，调试一个多 Agent 事故的难度，约等于同时抓五只逃出笼子的章鱼。

Anthropic 笔记里也表达过类似态度：能用一个 Agent 解决的，不要用两个。多 Agent 只在“不同角色有不同目标、不同工具、不同权限边界”时才值得引入，比如一个 Agent 负责检索资料、另一个负责生成最终文档，并且两者之间只需要交换结构化结果。真正的生产系统里，绝大多数需要协作的任务，用 Orchestrator-Workers 这一种工作流就能覆盖，根本不触发多 Agent 的复杂度。

6.4 一个真相：智能体的价值不靠“聪明”靠“边界”

最后我想把整个笔记的精髓再压一压。很多人以为构建有效智能体靠的是更强的模型，但 Anthropic 笔记反复强调的其实是一个工程真相：有效智能体的价值来自清晰的任务边界、良好的工具设计、完备的循环控制和可观测性，而不是模型本身有多“聪明”。

换句话说，一个 1.5 万行的 Agent 系统，如果边界混乱，照样会在线上乱跑；一个 200 行的 Agent 循环，只要环境、工具、终止条件设计扎实，就能在业务里稳定创造价值。模型强一点当然更好，但它不是决定性的那一环。

这也是为什么我强烈建议你，第一次接触 Agent 时，不要从“搭一个复杂的多智能体”开始，而是先按笔记的分类法，把一个需求从“单次 Prompt”到“工作流”到“Agent”各实现一遍，亲身体验每上一个档位成本、可控性、调试复杂度发生了什么变化。这种体感，比任何架构图都靠谱。

最后分享一个我自己的习惯：现在我接手任何 LLM 项目，第一件事永远是拉一根决策链——把任务的输入、输出、可拆步骤、分支、回退逻辑画成一张最朴素的流程表，能画清楚就绝不引入 Agent。等哪天真遇到流程表画不明白，而任务又必须由 AI 完成，我才会郑重地在架构里写下那个词：Agent。