★ FEATURED ARTICLE 前阵子有个做后端的老同事跑来问我说他们团队准备上一个“智能客服助手”老板听完产品经理的汇报张口就要“接入大模型、自动拆单、自动跟进、自动复盘”恨不得把整个客服部变成一个全自动的 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 五种模式怎么选一张选型表我整理了一张简单的选型表是我在实际项目里用来快速判断的模式核心特征适合场景主要代价复杂度Prompt Chaining固定步骤串联每步输出为下步输入可明确拆阶段的任务、需要步骤间校验延迟叠加低Routing先分类后分派多分支路径、需要差异化处理分类错误会放大低Parallelization分片并发或投票共识可并行拆分的任务、高错误代价token 成本倍增中Orchestrator-Workers动态拆解、角色分派任务结构不确定、需要动态规划调试难、成本高高Evaluator-Optimizer生成-评估-再生成有明确标准、需要迭代打磨可能循环空转中这张表不是“越高越好”恰恰相反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 调用那么简单。这个循环有四步决策模型根据当前状态用户目标、已有观察结果、工具反馈决定下一步动作执行调用选定的工具产生副作用读文件、发请求、写数据观察把执行结果工具返回内容、报错、环境变化反馈给模型重复回到决策步直到模型判断任务已达目标或者触发终止条件。一个关键差异在于工作流也有循环但循环体内是“固定的重复步骤”Agent 循环体内是“模型自由决策”。比如写一个 while 循环让模型反复调用一个翻译接口直到成功这其实是工作流里的“重试机制”而让模型自己在“继续翻译”“先查术语表”“换个翻译策略”“直接给最终答案”之间选择这才是 Agentic Loop。另外一个合格的 Agentic Loop 必须有完整的终止条件设计任务完成的判断、最大步数限制、危险操作的熔断、用户取消的通道。我在笔记里看到过一句话启发很大“智能体更像是把一个搜索引擎和编译器塞进一个循环里但你得给它配好刹车。”所以真正的智能体 环境 工具 Agentic Loop。三者缺一不可。很多平台的“自动化编排界面”其实只是让你搭工作流不是真正的 Agent而凡是自称“Agent 框架”的东西核心就是帮你封装这个循环通常叫 Runner / AgentLoop。理解这一点之后你在选型框架时就不会被“支持多智能体”这种营销词带偏了。4. 构建有效智能体的选型铁律最简方案优先4.1 决策原则与复杂度阶梯读 Anthropic 笔记对我冲击最大的不是那几个模式的名字而是一句几乎可以作为行业准则的话“优先使用最简单的方案来满足需求。”它给了一个复杂度阶梯按性价比排列单次 Prompt 检索增强或工具调用五种工作流Prompt Chaining 是最简单的一档专用 Agent一个模型负责一个领域自循环决策多 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。
阅读完成 · 觉得有帮助？
