企业官网建设流程全解析

简介：Anthropic 官方报告《Building effective agents》的完整中文译本，以单份PDF文件呈现，压缩包大小约878KB，适合希望深入理解AI代理设计与落地原则的开发者、产品经理及技术决策者阅读。该译本从词源学角度厘清Agent内涵，系统区分工作流与代理两类代理型系统，并结合数十个行业团队的合作经验，强调“Less is More”的构建思路：先寻找最简单的LLM方案，仅在必要时引入复杂性，善用简单可组合模式而非堆砌框架。内容同时覆盖何时使用代理、框架选型建议、查询路由与工具集成等常见架构模式，并附有实践应用附录，能够帮助读者建立从原理到应用的完整认知框架。这份PDF目前已有444人学习，适合用于团队共读、技术分享或作为系统架构设计时的案头参考。

1. 为什么"Less is More"才是构建 AI Agents 的第一原则

过去一年里，官方团队与不同行业的数十个团队合作，得出一个反直觉的结论：最成功的 AI 代理（AI Agents）系统，并不是建立在复杂框架之上，而是采用简单、可组合的设计模式。Claude 官方发布的这份《构建高效的 Agents 指南》全文翻译中文版，把研究报告的核心内容完整收录进来——从 Agent 词源辨析、工作流与代理的架构分界，到提示链、路由、并行化、编排者-执行者、评估者-优化者五种工作流，再到工具提示工程与三个核心原则。

如果你正在做自动化工作流，想把大语言模型接进业务流程，或者已经被各种 Agent 框架绕得晕头转向，这份指南值得逐节通读。它不教你怎么堆框架，而是教你怎么在"简单优先"的前提下，做出能用、可控、能上线的代理系统。

报告里最值得反复咀嚼的一句话是：只有在确实能够改善结果的情况下，才考虑增加复杂性。带着这句话去读后面的每一种模式和示例，你会少走很多弯路。

2. 先统一对 Agent 的理解：工作流与代理不是一回事

做 Agent 项目最容易翻车的地方，往往不在技术选型，而是团队内部对"Agent"这个词的理解根本没对齐。有人觉得只要是能自动跑一段流程的系统都算 Agent，有人把"智能体"三个字当成万能包装。官方团队在报告里花了不小篇幅做概念澄清，读翻译版时这部分建议不要跳过，因为它直接决定你后面选工作流还是选代理。

2.1 从词源到架构：Agent 的本义是"代表他人行动"

"Agent" 源自拉丁语 "agere"，本义是"行动、执行、推动"，引申为"代表他人做某事"。进入英语后，这个词一直保留着"代表某人或某个组织行动"的核心含义。你在现实生活里早就见过它的用法：执法机构特工代表政府执行任务，旅行代理人代表旅客安排行程，保险代理人代表保险公司办理业务。这些角色有一个共同点——它们不是主人，而是替主人办事的执行者。

所以报告里特别提醒：把 AI Agent 生硬翻译成"智能体"，其实丢掉了"代理"这个核心概念。更准确的译法应该是"AI 代理人"或"AI 执行者"，它强调的是这类系统的本质：代表人类执行特定任务的数字化代理人。理解了这层本义，你就能明白为什么报告反复强调"接管已有的人工环节"，而不是"创造全新的自动化场景"。

落到实际操作，判断一个需求值不值得用 Agent，可以走这三步检查：

• 第一步，把现有工作流程完整画出来，标出哪些环节人力消耗最大、哪些任务团队反复抱怨。不是所有流程都值得改造，只有痛点集中的地方才有代理的用武之地。
• 第二步，确认这个环节是"已经存在且有价值的人工流程"，并且可以被接管。Agent 的核心价值在于从手动到自动的转变，重点在"接管"，而不是"创造"。那些本来就是自动化的系统，比如自动调温的空调，硬贴 Agent 标签没有意义。
• 第三步，算投资回报率。把手动流程自动化之后，到底能省下多少人力成本、提升多少效率？这是衡量项目是否值得投入的关键指标。包装得再漂亮的 Agent，算不过 ROI 这关就不该立项。

这三步走完，你基本能判断一个需求是真实痛点，还是为了用 AI 而用 AI。官方团队强调的 "Less is More"，起点就在这里：真正有价值的 AI Agent 往往始于对具体问题的深入理解，而不是华丽的技术包装。

2.2 工作流与代理：预定义路径和动态自指导的分界线

报告里给了一个非常重要的架构区分：工作流（Workflow）和代理（Agent）都属于"代理型系统"，但两者有本质差异。工作流是通过预定义代码路径来编排 LLM 和工具的系统，每一步做什么、下一步接什么，都由开发者提前写死；代理则是 LLM 能够动态指导自身处理过程和工具使用的系统，它自主控制任务完成的方式，路径不是预先固定好的。

两者的适用边界也很清楚：对于明确定义的任务，工作流能提供更好的可预测性和一致性；当需要大规模灵活性、依赖模型驱动的决策时，代理是更好的选择。报告专门提醒了一个取舍逻辑：代理型系统通常用延迟和成本换取更好的任务表现，你需要自己判断这笔交易划不划算。

我实际做项目时会再压缩成三个问题来问自己：

• 任务步骤是否可提前枚举？能枚举，优先工作流；枚举不了，才考虑代理。
• 失败容错有多高？每步结果都要可预期，工作流更稳；允许试错和纠偏，代理才有发挥空间。
• 成本敏感度如何？代理的多轮工具调用会显著增加 token 开销和延迟，预算有限的场景优先用工作流压成本。

报告里还有一句容易被忽略的话：对于许多应用来说，优化单个 LLM 调用（配合检索和上下文示例）通常就足够了。这意味着你的第一个方案可能根本不需要"Agent 系统"，先把单次调用的提示词、检索内容、示例调好，很多问题就解决了。这跟很多人一上来就搭框架的习惯正好相反。

对比维度直接放在这里，选型时对着看：

2.3 增强型 LLM：检索、工具使用与记忆是代理系统地基

不管最后选了工作流还是代理，底层都离不开同一个构建模块：增强型 LLM。它是在基础模型之上，叠加了检索、工具使用和记忆三种能力的大语言模型。官方团队指出，现在的模型已经能主动使用这些能力——自己生成搜索查询、选择合适的工具、决定保留哪些上下文信息。这跟早期把检索和生成硬拼在一起的做法完全不同。

实现增强型 LLM 时，报告建议重点关注两个方面：第一，把这些功能针对性地适配到你的具体用例上，不要照搬通用方案；第二，为 LLM 提供简单、文档完备的接口，让模型能清晰理解每个工具是干什么的。模型上下文协议（MCP）是其中一个落地方式，它允许开发者通过简单的客户端实现，集成不断增长的第三方工具生态，避免每个工具都单独写一套对接逻辑。

很多人以为"增强"一定要上框架才能做，其实常见的做法是先用 API 直连把检索和工具调用接进来，几行代码就能跑通。下一步怎么选框架、什么时候才该上代理，正好是第 4 章要展开的内容。

2.4 客户支持与编码代理：代理系统最先跑通的两个领域

报告附录里点了两个已经被验证有实际价值的代理落地领域。第一个是客户支持，原因是支持交互天然遵循对话流程，同时需要访问外部信息和执行操作；通过工具可以集成客户数据、订单历史、知识库文章，退款和工单更新能程序化处理，而且"用户问题是否解决"是清晰可衡量的成功标准。已经有公司按使用量定价，只对成功解决的案例收费，这本身就是对代理效能的一种信心背书。

第二个是编码代理。代码解决方案可以通过自动化测试验证，代理能拿测试结果当反馈迭代修复；问题空间定义明确且结构化，输出质量可以客观衡量。在代码修复基准测试中，基于拉取请求描述，代理已经能解决真实问题。当然，自动化测试只能验证功能，人工审查仍然是确保方案符合系统整体要求的关键环节。

这两个领域有个共同特征：需要对话和行动相结合、有明确成功标准、能形成反馈循环、并且可以整合有意义的人类监督。如果你的业务场景同时具备这四个特征，那么代理大概率比固定工作流更合适；缺任何一个，都建议先退回工作流或单次 LLM 调用。

3. 五种工作流模式：从提示链到评估者-优化者的选型清单

报告把生产环境中常见的代理型系统模式收敛成五种可组合的工作流：提示链、路由、并行化、编排者-执行者、评估者-优化者。它们不是强制规范，更像一套乐高积木，按不同场景组合使用。这一章按复杂度从低到高逐个拆，每个都给出使用时机和典型例子。

3.1 提示链：拆成固定子步骤，用延迟换准确率

提示链把任务分解成一系列步骤，每个 LLM 调用处理前一个调用的输出，形成一条串行链路。链路中间可以插入程序化检查（报告里叫 gate），用来确保流程还在正轨上。这个检查点特别关键，它让每步输出在进入下一步之前先经过规则校验，避免错误在链路上被放大。

什么时候用提示链？报告说得清楚：最适合那些可以轻松、清晰地分解为固定子任务的情况。它的核心收益是用延迟换准确性——单个 LLM 调用处理更简单的子任务，出错的概率比让它一口气处理复杂任务低得多。

报告给了两个实用例子：生成营销文案后翻译成其他语言；先写文档大纲，检查大纲符合特定标准后再基于大纲撰写文档。我见过很多团队把这类需求直接丢给一个大 prompt，结果输出质量波动很大。改成提示链后，每步的输出可控性明显提升，成本反而更省。一句话判断：任务能拆成固定顺序的环节，且每环有明确产出，就用提示链。

3.2 路由：把输入分类，引导到专用提示

路由会对输入进行分类，然后把它引导到专门的后续任务。它实现的是关注点分离——如果没有路由，为某一类输入优化的提示很可能会牺牲其他类型输入的性能。路由本身可以用 LLM 分类，也可以用传统分类模型或算法。

适用场景是那些有明显不同类别、需要分开处理的复杂任务。报告里给的两个例子很典型：一是把不同类型的客服查询（一般问题、退款请求、技术支持）引导到不同的下游流程、提示和工具；二是把简单常见问题路由给较小的模型，把困难问题路由给更强大的模型，用路由来优化成本和速度。

我一般会把路由想成"分流器"：它不负责解决问题，只负责把问题送到最擅长解决它的地方。一个常见的错误是让路由模型兼任回答者，结果分类不准和回答质量混在一起，排查成本翻倍。路由模型的职责越单一，效果越稳。

3.3 并行化：分段与投票的两种打开方式

并行化让 LLM 同时处理多个任务，再程序化汇总输出。报告强调了两个关键变体，它们解决的问题完全不同。

分段是把任务拆成并行运行的独立子任务。典型例子是安全防护：一个模型实例处理用户查询，另一个实例专门筛查不当内容，这比让同一个 LLM 调用同时处理安全防护和核心响应效果更好，因为每个模型的注意力不互相干扰。另一个例子是自动化评估 LLM 性能，每个调用只评估一个方面的表现。

投票则是多次运行相同任务，获得多样化输出后再汇总。典型例子是代码安全审查：多个不同的提示分别审查代码漏洞并标记，比单次审查覆盖更全。还有内容审核场景，通过调整投票阈值来平衡误报和漏报。

分段的收益是速度，多个子任务同时跑，总耗时远小于串行；投票的收益是置信度，多个视角降低了单次调用的随机性。报告里的选型逻辑很直接：需要独立子任务提速，选分段；需要多视角降低误判风险，选投票。如果两者都想要，也完全可以组合使用。

3.4 编排者-执行者：让中央模型动态拆解任务

编排者-执行者模式里，一个中央 LLM 动态地分解任务，把子任务分配给执行者 LLM，最后综合它们的结果。它在结构上跟并行化有点像，但有一个关键区别：并行化的子任务是预先定义好的，这个模式的子任务由编排者根据具体输入动态确定，可以随时调整。

什么时候非它不可？报告点得很明确：那些无法预测所需子任务的复杂任务。比如编程场景，要改哪些文件、每个文件改什么，完全取决于任务描述；还有搜索任务，需要从多个来源收集和分析可能相关的信息，每个搜索路径都要动态判断。这种场景下，如果硬用预定义工作流去写，代码复杂度会失控。

我在实际项目里的体会是，编排者-执行者最大的坑在于编排者 prompt 的质量。它是整条链路的"大脑"，如果它拆解任务的方式不对，后面所有执行者的工作都白费。建议单独花精力调试编排者的输出格式，让它的分解结果结构化、可验证，再喂给执行者。

3.5 评估者-优化者：用反馈闭环提升输出质量

评估者-优化者工作流是一个 LLM 调用生成响应，另一个 LLM 在循环中提供评估和反馈，生成者根据反馈迭代改进。这很像人类作者的迭代写作：初稿总有瑕疵，外部反馈越具体，修改稿质量越高。

判断要不要用它，报告给了两个标志。第一，人类明确表达反馈时，LLM 的响应能明显改善；第二，LLM 本身能够提供有用的反馈。两个条件同时满足，这个模式就有价值。报告里的例子包括文学翻译——译者 LLM 最初可能捕捉不到细微差别，评估者 LLM 的批评能显著提升译文质量；以及需要多轮搜索的复杂检索任务，评估者判断是否要继续搜。

这个模式的成本比前面几种都高，因为每轮迭代都是多次完整调用。我一般会给它加一个硬性最大轮数和质量阈值，达到阈值立即退出，而不是无限循环下去。第 6 章会给出一个可运行的骨架代码。

五种工作流整理成选型速查表，方便直接对照：

4. 框架不是银弹：裸调 API 与自主代理的构建策略

很多开发者在读这份指南前，默认构建 Agent 就该选一个编排框架。报告明确指出，框架确实能简化底层标准任务，比如调用 LLM、定义和解析工具、链接多个调用，但也带来三个隐藏成本。这一章把框架的利弊、自主代理的运作原理、以及官方团队反复强调的三个原则一次讲透。

4.1 框架的诱惑与三个隐藏成本

目前主流的框架大致分三类：基于图编排的框架（把节点和边组织成工作流）、拖放式的 LLM 工作流构建工具、图形化的复杂工作流测试界面。它们让入门变快的路径是相同的——把底层的提示构造、工具调用、链路编排都封装起来，开发者只需要配置几个参数。

但封装是有代价的。报告点名了三个问题：第一，抽象层可能会掩盖底层的提示和响应，遇到效果不符合预期时，你根本不知道模型实际收到了什么提示、返回了什么内容，调试变成了猜谜。第二，框架容易诱使开发者增加不必要的复杂性，明明一个简单的提示链就能解决，框架的节点和边结构反而逼着你设计出更重的方案。第三，对框架内部机制的错误假设是客户常见的错误来源，你以为框架帮你处理了某个细节，实际上它并没有，最终在线上暴露出来。

官方团队的建议非常直接：直接从使用 LLM API 开始，许多模式只需要几行代码就能实现。如果确实要使用框架，请确保理解底层代码——把框架的源码或文档读透，不要让框架替你决定提示和响应怎么流动。我自己的习惯是先用 API 跑通最小验证，确认效果后再决定要不要引入框架；需要引入时，也只用它做链路编排，不允许它遮蔽关键中间结果。

两种路线的对比放在这里：

4.2 自主代理：循环中持续获取"基准事实"

自主代理是报告里复杂度最高的一档。它从用户指令或交互对话开始，任务明确后独立规划并运行，必要时向用户寻求更多信息或判断。执行过程中，代理需要在每个步骤都从环境获取"基准事实"——比如工具调用结果、代码执行情况——来评估自身进展。遇到障碍时，它可以在检查点暂停等待人类反馈；任务完成时终止，但通常也包含停止条件（如最大迭代次数）来保持控制。

一个最小可运行的自主代理循环骨架长这样：

# 自主代理最小循环：指令输入 → 工具调用 → 环境反馈 → 判断终止 import json def run_agent(instruction: str, max_steps: int, tools: list[dict]) -> str: # 把用户指令放入消息历史，tools 是要暴露给模型的工具定义 messages = [{"role": "user", "content": instruction}] for step in range(max_steps): # 1. 调用 LLM，传入消息历史和工具定义，模型返回结构化响应 response = llm_call(messages, tools) # 2. 模型决定任务已完成，携带最终输出 if response.get("finish"): return response["output"] # 3. 否则模型请求调用某个工具，解析工具名和参数 tool_call = response["tool_call"] result = execute_tool(tool_call["name"], tool_call["arguments"]) # 4. 把工具结果作为新的基准事实追加进上下文，形成闭环 messages.append({ "role": "tool", "tool_call_id": tool_call["id"], "content": json.dumps(result, ensure_ascii=False) }) # 达到最大迭代仍未完成，按停止条件强制终止 raise RuntimeError(f"已达最大步数 {max_steps}，任务未完成")

这段代码的核心设计有三个：llm_call 必须返回结构化结果，区分"完成"和"继续调工具"两种状态；execute_tool 按工具名称分发到具体实现，返回结果统一序列化为 JSON；每次工具调用结果都追加进消息历史，模型才能基于环境反馈做下一步决策。闭环的关键就在于第四步——没有工具结果回写到上下文，代理就是在空转，根本无法判断自己做得对不对。

报告补充了两个重要实践提醒：代理的自主性意味着更高成本，以及错误累积的可能性，所以必须在沙盒环境中做广泛测试，配置适当的安全防护措施。代理适用于难以或无法预测所需步骤数量的开放性问题，以及无法硬编码固定路径的场景，但前提是你必须对模型的决策能力有一定程度的信任。

4.3 三个核心原则与代理-计算机接口（ACI）

报告最后把构建代理的经验收敛成三个核心原则。第一条，保持代理设计的简单性，能用工作流就不用代理，能用单个 LLM 调用就不用工作流。第二条，确保透明度，通过明确展示代理的规划步骤，让用户和开发者都能看到它打算怎么走。第三条，精心设计代理-计算机接口（ACI），通过全面的工具文档和测试来打磨工具层。

工具提示工程是 ACI 的核心，报告给出的投入标准是：考虑到人机界面（HCI）需要投入多少努力，就计划在创建良好的 ACI 上投入同样多的努力。具体有四个可执行的做法：

• 站在模型的角度思考。只看描述和参数，这个工具怎么用是否显而易见？如果人需要琢磨，模型大概率也需要琢磨。好的工具定义应该包含使用示例、边界情况、输入格式要求，以及与其他工具的明确界限。
• 优化参数名称和描述。把工具定义当成给团队里初级开发者写的文档字符串。多个相似工具同时存在时，这个功夫尤其重要。
• 在测试环境里跑真实用例，观察模型会犯什么错误，然后针对性地迭代工具定义。
• 对工具做防错设计。改变参数结构，让模型更难传错。比如有一个真实案例：代理移出根目录后，使用相对文件路径的工具频繁出错，改成始终要求绝对文件路径之后，模型立刻完美使用。这就是防错设计的价值。

提示：工具定义得到的提示工程投入，应该和整体提示词一样多。报告里提到，构建代码代理时，花在优化工具上的时间比花在整体提示上的时间更多——工具层永远值得你优先打磨。

5. 避坑指南：构建 Agents 最常见的五个翻车现场

前四章把原理和模式讲完了，这一章全是实际操作里的血泪经验。我拆过不少 Agent 项目，也见过团队踩过各种坑，结合报告里明确提醒过的风险点，整理了五个最高频的翻车现场，每条按现象、原因、解决三个层次拆开，你可以对照自己的项目排查。

5.1 翻车一：没有真实痛点，硬造 Agent 需求

现象：项目立项叫"AI 智能体"，打开一看是把本来自动化的流程包装了一层壳。或者团队把实现手段当成目标，先定了要用 Agent，再回头找适合它的问题，结果找不到就硬凑。

原因：把 Agent 当概念追热点，忽略了它的本质是接管已有的人工环节。自动调温的空调贴上"数字孪生智能体"的标签，并不会真的产生业务价值。报告里强调的核心原则是"从实际工作流程出发"，流程里没有痛点，Agent 做得再花哨也是摆设。

解决：回到 2.1 节的三步检查流程。先把现有流程图铺开，只选人力消耗最大、团队抱怨最多的环节做改造；确认改造目标是"把手动变自动"而不是"创造新任务"；最后必须算清 ROI——省了多少人力、提了多少效率。三项全过，才允许进入技术选型；任何一项不满足，先停下来。

5.2 翻车二：框架抽象层把调试变成黑匣子

现象：基于编排框架搭好了整套链路，模型输出不符合预期。想排查是提示词问题、工具解析问题还是链路顺序问题，却发现框架把底层提示和响应层层封装，根本看不到原始输入输出，只能靠猜。

原因：框架过度抽象掩盖了关键中间结果。报告点得很直白：抽象层会掩盖底层的提示和响应，让调试变困难；框架还容易诱使你增加不必要的复杂性。很多团队踩坑是因为默认框架已经处理了所有细节，但框架内部机制和你的假设并不一致。

解决：先从 LLM API 直连跑通最小链路，确认每个环节的提示和响应都透明可见，再用框架做编排。如果必须用框架，先读源码或文档搞清它如何构造提示、如何解析工具响应。线上问题排查时，每步中间结果都要能导出，做不到这一点就别上生产。

5.3 翻车三：工具设计投入失衡，模型不知道怎么用

现象：给模型接了一批工具，但模型频繁选错工具、传错参数，或者被工具描述绕晕，一个简单操作要反复试很多轮才成功。团队往往把全部精力放在主提示词上，工具定义草草凑合。

原因：工具层的提示工程投入严重不足。报告里明确建议，工具定义和规范应该得到与整体提示同等的提示工程关注。工具描述含糊、参数命名抽象、缺少边界说明，模型就只能靠猜。

解决：按 4.3 节的四招重新过一遍工具层——给每个工具写清楚使用示例、边界情况、和其他工具的区分；参数名改成人话，尽量让初中级开发者看到就能理解；在测试环境跑几十个样例，专门观察模型在哪个工具上出错，再针对性迭代。花在工具上的时间，至少要和花在主提示词上的时间持平。

5.4 翻车四：跳过沙盒测试直接上生产，错误累积失控

现象：自主代理上线后的某一天，突然发现它执行了一连串计划外的工具调用，产生了不想要的结果。查看日志才发现，问题早在几十步之前就出现了，后续每步都基于错误结果继续放大。

原因：代理的多轮循环属性决定了错误会累积。报告明确指出，代理的自主特性意味着更高成本，以及错误累积的可能性。没有在受限环境里做充分测试，代理的每一步决策失去校验，错误就会滚雪球。

解决：上线前必须在沙盒环境里跑完整任务集，覆盖正常路径和异常路径；给代理加最大迭代次数和明确停止条件；对关键操作（退款、删除、写操作）设置人工审批检查点；生产环境保留每一步工具调用的完整日志，方便事后回溯错误源头。先小范围灰度跑一段时间，确认稳定再全量放量。

5.5 翻车五：工具输出格式把模型"写进死角"

现象：让模型以 diff 补丁形式修改代码，它在需要精确计数的行号上反复出错；要求以 JSON 返回结构化代码块，换行符和引号的转义把输出搞成乱码；给模型的格式约束越精细，模型表现越差。

原因：某些格式对 LLM 来说是天然不友好的。报告分析得很透：生成 diff 需要模型在写入新代码前先知道块头里要改的行数，这要求精确计数；JSON 里写代码需要额外转义换行和引号，格式开销很大，还容易把模型逼进死角。

解决：选择 LLM 在互联网上自然遇到过的格式——Markdown 通常比 JSON 友好，重写整个文件比生成 diff 更少出错。给模型足够的 token 去"思考"，避免高难度的格式计算；同时减少格式开销，不让模型维护大量需要精确计数的状态。报告里那个相对文件路径改绝对路径的例子也说明，格式设计恰当与否，直接影响模型能不能稳定使用工具。

6. 把报告落到代码：一个最小可复现的评估者-优化者示例

前面讲了这么多模式，最终还是要落到能跑的代码上。这里给出一个评估者-优化者工作流的最小可复现骨架，接入你自己的 LLM SDK 即可运行。它的适用场景是：你有一个明确的评估标准，且迭代优化能带来可衡量的价值提升。

# 评估者-优化者循环：生成 → 评估 → 按反馈修订，达标即退出 def improve_with_feedback(prompt: str, max_rounds: int = 3) -> tuple[str, dict]: # 生成者用较高温度，保留多样性和创作空间 draft = llm_call( [{"role": "user", "content": prompt}], temperature=0.7 ) review = {} for round_no in range(max_rounds): # 评估者用较低温度，保证评分和意见稳定可复现 review = llm_call( [{"role": "system", "content": EVALUATOR_PROMPT}, {"role": "user", "content": draft}], temperature=0.2 ) # 达到质量阈值立即退出，避免无谓的 token 开销 if review["score"] >= 0.85: return draft, review # 把评估者的具体修订意见拼回上下文，让生成者针对性改进 draft = llm_call( [{"role": "system", "content": OPTIMIZER_PROMPT}, {"role": "user", "content": ( f"原始需求：{prompt}\n当前稿：{draft}\n" f"评估反馈：{review['comments']}" )}], temperature=0.7 ) return draft, review

这段代码的关键参数有三个：max_rounds 控制最大迭代轮数，防止无限循环烧钱；temperature 区分生成者和评估者的行为模式，评估者低温保稳定，生成者高温保多样性；quality_threshold 是质量阈值，达到 0.85 立即退出，让成本和质量达成平衡。EVALUATOR_PROMPT 里至少要包含打分标准和具体修改意见两个输出字段，OPTIMIZER_PROMPT 则要求生成者只根据反馈修改，不重写无关部分。

我之前做翻译类 Agent 时，总想一步到位上最重的编排架构，结果在调试上耗掉的时间比写代码还多。从那以后，我每次接到 Agent 需求，都强制自己先按"简单性、透明度、精心设计工具接口"这三条原则走一遍，从最小的可运行闭环开始验证，再决定复杂度加在哪一层。这份翻译版和原版 PDF 建议一起收着，遇到选型纠结时翻到对应章节重读一遍，往往比上网搜各种碎片教程更管用。希望帮到你。

本文还有配套的精品资源，点击获取