★ FEATURED ARTICLE 简介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 系统先把单次调用的提示词、检索内容、示例调好很多问题就解决了。这跟很多人一上来就搭框架的习惯正好相反。对比维度直接放在这里选型时对着看维度工作流代理编排方式预定义代码路径LLM 动态决定步骤任务特征明确、可预测开放、步骤不可预写可预测性高输入输出可预期低存在错误累积风险成本与延迟相对可控更高多轮工具调用调试难度较低每步可见较高需要完整日志跟踪典型场景提示链、路由、并行化代码修复、长链路检索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 章会给出一个可运行的骨架代码。五种工作流整理成选型速查表方便直接对照工作流核心机制适用时机典型例子提示链串行步骤 gate 检查固定子任务可分解大纲→检查→成文路由输入分类导向专用提示类别清晰需分开处理客服分流、大小模型分流并行化分段/投票并行子任务 / 多次采样子任务可并行、需多视角安全防护、漏洞审查编排者-执行者中央 LLM 动态拆解分配子任务不可预知多文件编程、搜索聚合评估者-优化者生成 评估迭代闭环有明确评估标准、迭代有价值文学翻译、复杂检索4. 框架不是银弹裸调 API 与自主代理的构建策略很多开发者在读这份指南前默认构建 Agent 就该选一个编排框架。报告明确指出框架确实能简化底层标准任务比如调用 LLM、定义和解析工具、链接多个调用但也带来三个隐藏成本。这一章把框架的利弊、自主代理的运作原理、以及官方团队反复强调的三个原则一次讲透。4.1 框架的诱惑与三个隐藏成本目前主流的框架大致分三类基于图编排的框架把节点和边组织成工作流、拖放式的 LLM 工作流构建工具、图形化的复杂工作流测试界面。它们让入门变快的路径是相同的——把底层的提示构造、工具调用、链路编排都封装起来开发者只需要配置几个参数。但封装是有代价的。报告点名了三个问题第一抽象层可能会掩盖底层的提示和响应遇到效果不符合预期时你根本不知道模型实际收到了什么提示、返回了什么内容调试变成了猜谜。第二框架容易诱使开发者增加不必要的复杂性明明一个简单的提示链就能解决框架的节点和边结构反而逼着你设计出更重的方案。第三对框架内部机制的错误假设是客户常见的错误来源你以为框架帮你处理了某个细节实际上它并没有最终在线上暴露出来。官方团队的建议非常直接直接从使用 LLM API 开始许多模式只需要几行代码就能实现。如果确实要使用框架请确保理解底层代码——把框架的源码或文档读透不要让框架替你决定提示和响应怎么流动。我自己的习惯是先用 API 跑通最小验证确认效果后再决定要不要引入框架需要引入时也只用它做链路编排不允许它遮蔽关键中间结果。两种路线的对比放在这里对比项直接调用 LLM 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_asciiFalse) }) # 达到最大迭代仍未完成按停止条件强制终止 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}], temperature0.7 ) review {} for round_no in range(max_rounds): # 评估者用较低温度保证评分和意见稳定可复现 review llm_call( [{role: system, content: EVALUATOR_PROMPT}, {role: user, content: draft}], temperature0.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]} )}], temperature0.7 ) return draft, review这段代码的关键参数有三个max_rounds 控制最大迭代轮数防止无限循环烧钱temperature 区分生成者和评估者的行为模式评估者低温保稳定生成者高温保多样性quality_threshold 是质量阈值达到 0.85 立即退出让成本和质量达成平衡。EVALUATOR_PROMPT 里至少要包含打分标准和具体修改意见两个输出字段OPTIMIZER_PROMPT 则要求生成者只根据反馈修改不重写无关部分。我之前做翻译类 Agent 时总想一步到位上最重的编排架构结果在调试上耗掉的时间比写代码还多。从那以后我每次接到 Agent 需求都强制自己先按简单性、透明度、精心设计工具接口这三条原则走一遍从最小的可运行闭环开始验证再决定复杂度加在哪一层。这份翻译版和原版 PDF 建议一起收着遇到选型纠结时翻到对应章节重读一遍往往比上网搜各种碎片教程更管用。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
