★ FEATURED ARTICLE 简介这份PDF报告面向AI应用开发者、技术负责人与希望系统理解智能体架构的进阶学习者围绕如何构建有效的AI智能体展开重点解决工作流与智能体如何取舍、控制权如何分配、系统复杂度如何控制等设计难题。资源包内含1个PDF文件大小约5.32MB内容以图文并茂的方式呈现便于在电脑或平板上直接阅读与查阅。报告从Anthropic团队的实践经验出发梳理了增强型LLM这一基本构建块以及提示词链、路由、并行化、编排者-工作者、评估者-优化者等典型工作流模式并给出各自适用场景与权衡思路。读者可借此理解何时选择简单工作流、何时引入自主智能体掌握模块化与可扩展性的设计原则并避开框架抽象层带来的调试陷阱。目前已有445人学习适合需要将智能体方案落地到实际业务中的开发者参考。1. 从一份 Anthropic 内部报告说起为什么你的 Agent 总是想太多去年我接手一个客服工单自动分类的需求第一版直接上了某主流 Agent 框架工具注册了七八个提示词写了三百行结果上线三天就翻车——简单的一句我要退款被路由到技术排查链路绕了四五个 LLM 调用才回到正轨延迟从 800ms 飙到 6 秒。后来我把整个链路砍成一次分类调用加一次模板填充准确率反而涨了 4 个百分点。这份《如何构建有效的 AI 智能体》讲的就是这件事Anthropic 团队基于 Claude 开发和大量企业落地经验把 AI Agent 的设计原则拆成了可操作的工程判断。它不教你怎么调框架 API而是回答一个更前置的问题——什么时候该用工作流什么时候才轮到真正的智能体以及增强型 LLM 这个基本构建块到底该怎么拼。适合正在做智能体开发、被框架抽象层坑过、或者准备给团队定技术选型的人读。全文围绕控制权分配这条主线把提示词链、路由、并行化、编排者-工作者、评估者-优化者五种工作流讲透再落到自主智能体的适用边界。2. 控制权分配工作流与智能体的分水岭在哪很多人把用了 LLM 就是 Agent当成默认前提这是选型阶段最容易埋的雷。这份报告把系统分成两类AI 工作流是通过预定义代码路径编排 LLM 和工具的系统像一条铺好的铁轨LLM 在轨道上跑AI 智能体则是 LLM 动态指导自身流程和工具使用的系统像一个能自主导航的司机路径是运行时决定的。两者的本质差异不在用了多少工具而在控制权交给谁——交给预定义流程还是交给 LLM 本身。2.1 三种控制权层级与对应场景报告里给了一个很清晰的三级划分我把它整理成选型时可以直接对照的表层级控制权归属自主性典型场景人类控制完全由人定义无固定表单、规则引擎AI 工作流预定义流程有限分类、翻译、内容生成AI 智能体LLM 自身高人类监督复杂编码、多源搜索这个划分的价值在于它逼你在动手前先回答这个任务的控制权该给谁。我见过太多项目明明是一个输入分类加固定回复的活非要套一个 ReAct 循环结果 LLM 每次都在思考要不要调用工具token 烧得飞快稳定性还差。反过来一个需要根据中间结果动态决定下一步查什么的多源检索任务硬写成固定链路就会在遇到没预料到的分支时直接卡死。2.2 从直接调用 API 开始而不是从框架开始报告里有一句我特别认同的话建议开发者从直接使用 LLM API 开始许多模式只需要几行代码就能实现。工作流框架确实能简化标准底层任务让开发者轻松起步但它同时创建了额外的抽象层可能模糊底层的提示和响应增加调试难度还可能诱使你增加不必要的复杂性。我一般会这样起步先用最裸的 API 调用把核心逻辑跑通确认提示词和输出格式稳定后再决定要不要引入框架。下面是一个最小可用的分类路由示例不依赖任何框架import anthropic client anthropic.Anthropic() def route_query(user_input: str) - str: 对用户输入做一次分类返回路由标签 resp client.messages.create( modelclaude-3-5-haiku-latest, # 分类任务用轻量模型即可 max_tokens64, system你是一个查询分类器。只输出以下标签之一refund / tech / general。不要输出任何其他文字。, messages[{role: user, content: user_input}] ) return resp.content[0].text.strip() # 根据标签走不同的下游流程 label route_query(我上周买的东西想退掉) print(label) # 期望输出 refund这段代码的逻辑很直白一次 LLM 调用完成分类返回的标签直接驱动后续的 if-else 分支。参数上model选轻量模型是因为分类任务不需要强推理能力用 Haiku 级别就够成本和延迟都低max_tokens压到 64 是为了防止模型输出多余解释system里明确限定输出集合是路由工作流稳定性的关键——如果你不限定模型很可能返回这看起来是一个退款请求下游解析就崩了。提示路由工作流的分类提示词一定要把输出空间收窄到有限标签集否则你会在解析环节写一堆正则兜底那还不如不用 LLM。2.3 增强型 LLM所有工作流的公共构建块不管上面选哪种工作流底层都是同一个东西——增强型 LLM。报告把它定义为具备检索、工具使用和记忆能力的 LLM当前模型可以主动生成搜索查询、选择适当工具、决定保留哪些信息。模块化设计是这里的核心LLM 是中央检索、工具、存储是外围能力通过标准化接口接入。我自己的经验是增强型 LLM 的接口设计要遵循能力声明与调用分离的原则。工具描述写清楚这个工具能做什么、输入输出是什么但不要在描述里写什么时候该调用它——那是 LLM 在运行时根据上下文判断的。如果你在工具描述里硬编码调用条件等于把智能体的自主性又收回到了预定义流程那还不如直接写工作流。3. 五种工作流拆解提示词链、路由、并行化怎么落地报告把常见工作流归纳为五类提示词链、路由、并行化、编排者-工作者、评估者-优化者。这五类不是互斥的实际系统里经常嵌套使用。下面挑三个最常用的展开每个都给出可复现的实现思路和参数说明。3.1 提示词链用程序检查点兜住中间步骤提示词链的核心是把任务分解为一系列步骤每个 LLM 调用处理前一个调用的输出中间可以插入程序检查报告里叫门确保流程不跑偏。典型场景是营销文案生成——先生成中文文案再翻译成目标语言每一步由专门的 LLM 处理。def prompt_chain(topic: str) - str: # 第一步生成中文营销文案 draft client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens512, messages[{role: user, content: f为{topic}写一段100字以内的营销文案}] ).content[0].text # 程序检查点文案长度和关键词校验 if len(draft) 200 or topic not in draft: raise ValueError(f文案校验失败: {draft[:50]}...) # 第二步翻译成英文 translated client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens512, messages[{role: user, content: f将以下文案翻译成英文保持营销语气\n{draft}}] ).content[0].text return translated这里的门就是那个if判断。参数上第一步用 Sonnet 是因为创意生成需要较强语言能力检查点的阈值200 字、关键词包含要根据业务定不能照抄。提示词链的代价是延迟——两个串行调用意味着总延迟是两者之和所以它适合那些准确性优先于速度的任务比如文档写作、多语言内容生成。如果你的场景对延迟敏感就要考虑能不能把某些步骤并行化。3.2 路由工作流关注点分离与模型分级路由的本质是对输入分类后引导到专门的下游任务好处是关注点分离——为一种输入优化不会损害其他输入的性能。报告里提到一个很实用的用法模型选择优化把简单常见问题路由到较小模型如 Claude 3.5 Haiku把困难不寻常的问题路由到更强大的模型如 Claude 3.5 Sonnet以此优化成本和速度。def smart_route(user_input: str) - str: # 先用轻量模型判断复杂度 complexity client.messages.create( modelclaude-3-5-haiku-latest, max_tokens16, system判断问题复杂度只输出 simple 或 complex。, messages[{role: user, content: user_input}] ).content[0].text.strip() # 根据复杂度选择模型 model claude-3-5-haiku-latest if complexity simple else claude-3-5-sonnet-latest return client.messages.create( modelmodel, max_tokens1024, messages[{role: user, content: user_input}] ).content[0].text这个模式我实测下来在客服场景能省 40% 以上的推理成本因为大部分用户问题都是简单的查订单、改地址。但要注意一个坑复杂度判断本身也是一次 LLM 调用如果判断错了简单问题被路由到强模型只是浪费钱复杂问题被路由到弱模型就是答非所问。所以复杂度判断的提示词要反复调最好用一批标注数据验证准确率再上线。3.3 并行化分段处理与投票机制的选择并行化工作流有两种变体分段处理把任务拆成可并行运行的独立子任务适合文档分析、多维度评估投票机制多次运行同一任务获取多样化输出适合需要高置信度结果的场景比如内容审核。import asyncio async def parallel_review(code_snippet: str) - list: 多个提示同时审查代码各自关注不同维度 prompts [ 检查以下代码的安全漏洞只列出问题, 检查以下代码的性能问题只列出问题, 检查以下代码的可读性问题只列出问题 ] tasks [ client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens512, messages[{role: user, content: f{p}\n{code_snippet}}] ) for p in prompts ] # 并发执行汇总结果 results await asyncio.gather(*[asyncio.to_thread(lambda tt: t) for t in tasks]) return [r.content[0].text for r in results]并行化的关键参数是并发度控制。上面这个例子三个调用同时发但如果你的任务拆成二十个子任务一次性全发出去很可能触发速率限制。我一般会加一个信号量控制并发数比如asyncio.Semaphore(5)根据账号的 RPM 限制来定。投票机制则要注意投票阈值——报告里提到内容审核场景需要不同的投票阈值以平衡误报和漏报这个阈值没有通用值得用你的业务数据跑 ROC 曲线来定。4. 编排者-工作者与评估者-优化者复杂任务的两种组织方式前三种工作流处理的是相对线性的任务当任务复杂到需要动态分解、或者需要迭代改进时就要用到后两种模式。这两个模式也是实际项目里最容易过度设计的地方我见过不少团队在只需要提示词链的场景硬上编排者-工作者结果调试成本翻倍。4.1 编排者-工作者动态分解与结果综合编排者-工作者的流程是中央 LLM 接收复杂任务动态分解为子任务分配给专门的工作者 LLM最后收集整合输出。报告给的典型场景是复杂编码任务——需要对多个文件做复杂更改时编排者分析需求把任务分解为具体代码修改分配给专门的工作者。def orchestrator_worker(task: str) - str: # 编排者分解任务 subtasks_raw client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens1024, system将任务分解为3-5个独立子任务每行一个不要编号。, messages[{role: user, content: task}] ).content[0].text.strip() subtasks [s for s in subtasks_raw.split(\n) if s.strip()] # 工作者并行处理每个子任务 results [] for st in subtasks: r client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens1024, messages[{role: user, content: f完成以下子任务{st}}] ).content[0].text results.append(r) # 编排者综合结果 combined \n---\n.join(results) final client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens2048, messages[{role: user, content: f整合以下子任务结果输出完整答案\n{combined}}] ).content[0].text return final这个模式最大的坑是子任务之间的依赖。如果子任务 B 需要子任务 A 的输出并行执行就会出错。我一般会在编排者的分解提示词里加一句如果子任务之间有依赖请标注依赖关系然后在代码里做拓扑排序有依赖的串行执行无依赖的并行。参数上编排者和工作者可以用不同模型——编排者需要强推理能力做分解工作者如果任务简单可以用轻量模型降本。4.2 评估者-优化者迭代循环的终止条件评估者-优化者是一个 LLM 生成响应另一个提供评估和反馈形成循环。报告里的应用场景包括文学翻译、复杂搜索、创意写作。这个模式最关键的工程问题是循环什么时候停def evaluator_optimizer(task: str, max_rounds: int 3) - str: response client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens1024, messages[{role: user, content: task}] ).content[0].text for i in range(max_rounds): # 评估者给出反馈 feedback client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens512, system评估以下回答的质量指出具体改进点。如果已经很好只输出 PASS。, messages[{role: user, content: f任务{task}\n回答{response}}] ).content[0].text if PASS in feedback: break # 优化者根据反馈改进 response client.messages.create( modelclaude-3-5-sonnet-latest, max_tokens1024, messages[{role: user, content: f根据反馈改进回答。\n任务{task}\n原回答{response}\n反馈{feedback}}] ).content[0].text return response这里我强制加了max_rounds上限这是血泪经验——早期版本没设上限评估者偶尔会陷入还能更好的循环一个翻译任务跑了十几轮成本直接失控。终止条件有两个评估者输出 PASS或者达到最大轮数。参数上评估者的max_tokens可以比优化者小因为反馈通常比正文短max_rounds一般设 2-3 就够再多边际收益很低。5. 避坑与排查智能体落地时最容易翻车的五个点这一章是我自己踩过的坑结合报告里的原则整理出来。每条按现象 → 原因 → 解决写方便你对照排查。5.1 简单任务被过度工程化现象一个输入分类加固定回复的需求上线后延迟高、成本高、稳定性差LLM 经常思考要不要调用工具。原因选型阶段没做控制权分配判断直接套了自主智能体模式把本该由预定义流程控制的任务交给了 LLM 动态决策。解决回到报告里的选型原则——寻找最简单可行的解决方案只在必要时增加复杂性。先用工作流实现如果发现确实需要动态决策再升级。判断标准很简单如果你能画出完整的决策树就用工作流如果画不出来才考虑智能体。5.2 框架抽象层模糊了底层提示现象用框架搭的工作流输出格式偶尔不符合预期但看框架日志看不出 LLM 实际收到了什么提示。原因工作流框架创建了额外的抽象层可能模糊底层的提示和响应增加调试难度。解决关键链路先用裸 API 跑通确认提示词和输出格式稳定后再考虑引入框架。如果已经在用框架确保能打印出每次调用的完整 prompt 和 response这是排查问题的底线。5.3 路由分类的标签集没有收窄现象路由工作流上线后下游解析频繁报错日志里看到 LLM 返回了这看起来是一个退款请求而不是refund。原因分类提示词没有严格限定输出空间LLM 按自然语言习惯输出了完整句子。解决在 system prompt 里明确只输出以下标签之一xxx / yyy / zzz不要输出任何其他文字并在代码里加一层校验不符合标签集的输出直接走兜底分支或重试。5.4 评估者-优化者循环没有终止条件现象一个翻译任务跑了十几轮还没停成本远超预期。原因评估者的提示词没有明确的通过标准导致它总能找到还能更好的点循环无法自然终止。解决双保险——评估者提示词里明确如果已经很好只输出 PASS代码里强制max_rounds上限。另外评估标准要具体比如翻译任务可以定术语准确、语气一致、无语法错误三条全部满足就 PASS避免主观判断。5.5 并行化的并发度没控制现象批量处理任务时频繁触发速率限制报 429 错误。原因并行化工作流一次性发出大量请求超过了账号的 RPM 限制。解决加信号量控制并发数根据账号配额来定。我一般会先查账号的 RPM 和 TPM 限制然后设Semaphore(min(RPM/60, 5))这样的保守值。另外并行任务要做好错误重试单个任务失败不应该影响整体。6. 从工作流到智能体的升级判断一个可操作的检查清单报告最后落到自主智能体的适用边界这部分我想结合自己的经验给一个更具体的判断方法。什么时候该从工作流升级到智能体我的检查清单是三个问题第一任务的决策路径是否无法预先枚举如果所有分支都能画出来工作流就够了。第二是否需要根据中间结果动态调整策略比如多源搜索时第一轮搜索结果决定了第二轮查什么。第三错误的代价是否可控智能体的自主性意味着它可能做出你没预料到的决策如果错误代价高就需要更严格的监督机制。报告里提到智能体适合需要大规模灵活性和模型驱动决策的场景这个描述比较抽象我把它翻译成工程语言当你的工作流里出现了大量如果 A 则查 B如果 B 的结果包含 C 则再查 D这类运行时才能确定的逻辑且这些逻辑无法用规则穷举时才考虑智能体。否则工作流加程序检查点的组合在稳定性、成本和可调试性上都更优。验证方法上我一般会做一个小规模对照实验同一批任务分别用工作流和智能体跑对比准确率、延迟、成本三个指标。如果智能体在准确率上没有显著优势比如提升不到 5 个百分点但延迟和成本翻倍那就果断回退到工作流。这个实验的成本很低但能避免上线后才发现选型错误。还有一个容易被忽略的点智能体的监督机制。报告强调智能体是高度自主性人类监督这个监督不是摆设。我一般会在智能体的关键决策点加日志记录它选择了哪个工具、为什么选择、中间结果是什么。这些日志在排查问题时是唯一的黑匣子。另外对于高风险操作比如删除数据、发送邮件要加人工确认环节不能让智能体自主执行。从那以后我每次做智能体选型都强制走一遍控制权分配 → 最简单方案 → 对照实验这三步再也没出现过上线后回退的情况。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
