构建有效的AI智能体

一个定义先厘清：智能体到底指什么

"Agent"这个词在客户之间的理解并不统一。有人指的是能长时间独立运行、自主调用多种工具完成复杂任务的完全自主系统；也有人指的是遵循预定义流程的、更具规定性的实现。Anthropic 把两者统称为"智能体系统"（agentic systems），但在架构上做了一刀切的二分，这个二分是全文所有建议的地基。

工作流（Workflow）：大模型和工具通过预先写好的代码路径被编排起来。智能体（Agent）：大模型动态指导自身的流程和工具使用，自己掌控如何完成任务。判断标准只有一条——路径由谁决定。代码决定就是工作流，模型决定就是智能体。这条线画清楚了，后面所有关于成本、可控性、调试难度的讨论才有落点。

什么时候不该用智能体

首要原则是找最简单的解，只在必要时才增加复杂度。Anthropic 在这里加了一个中文转述里经常被漏掉的边界条件：这甚至可能意味着完全不构建智能体系统。对很多应用来说，优化单次模型调用，再配上检索和几个上下文示例，就已经够用了。

代价这件事必须摆在台面上说。智能体系统本质上是拿延迟和成本去换任务表现。这笔交换在你的场景下值不值，需要具体算，不能靠"更先进"这种感觉来决定。任务定义清晰、需要可预测性和一致性时，用工作流；需要灵活性、需要模型驱动决策、且要规模化时，才用智能体。

能用工作流的地方都用工作流，只在必须的地方用智能体。

关于框架的一段冷静提醒

文章点名了四个框架：Claude Agent SDK、AWS 的 Strands Agents SDK、拖拽式 GUI 工作流构建器 Rivet，以及同为 GUI 工具的 Vellum。它们的价值在于简化调用模型、定义与解析工具、串联调用这些低层标准动作。

但批评也很直接：额外的抽象层会遮蔽底层的提示词和响应，让调试变得更困难；它同时容易诱导你在简单方案已经够用时去加复杂度。Anthropic 的建议是直接从模型 API 开始——很多模式其实只要几行代码。如果确实要用框架，那就必须理解它底层的代码。客户最常见的错误来源，正是对底层机制的错误假设。

五种工作流模式

在讲这五种模式之前，还有一个基础单元：增强型大模型——模型加上检索、工具、记忆三类增强。当前的模型已经能主动使用这些能力：自己生成检索查询、自己选工具、自己决定保留哪些信息。两条实现建议是针对具体用例做裁剪，以及提供清晰、文档完备的接口。模型上下文协议（MCP）被点名为一种接入第三方工具生态的实现路径。

提示词链（Prompt Chaining）：把任务拆成固定的顺序步骤，每次调用处理上一步的输出。可以在中间步骤加程序化检查（原文称为"gates"），验证流程仍在轨道上。它用牺牲延迟来换准确率，靠让每一次调用都变简单来提升整体正确率。适用场景是任务能被干净地拆成固定子任务，比如先生成营销文案再翻译成多语言，或者先写文档大纲、校验大纲达标、再基于通过的大纲写正文。

路由（Routing）：对输入先分类，再导向专门化的后续任务。它带来的是关注点分离——你可以为每一类输入写更专门的提示词。反例说得很清楚：不做路由时，为某一类输入所做的优化会损害其他类输入的表现。前提条件是类别边界明确，且分类本身能被准确完成。除了客服工单分流，一个很实际的用法是模型分级：简单常见的问题交给更小更省的模型，困难罕见的问题才交给更强的模型。

并行化（Parallelization）：多个模型同时处理，输出以程序方式聚合。分两种变体——分段（Sectioning）把任务拆成互相独立的子任务并行跑；投票（Voting）把同一任务跑多次，拿到多样化输出。这里有一条重要论断：对有多重考量的复杂任务，把每个考量交给单独的调用处理，通常表现更好，因为每次调用能聚焦在一个具体侧面。护栏就是典型例子——一个实例处理用户请求，另一个实例筛查不当内容，这比让同一次调用既管护栏又管主回复效果更好。

编排器—工作者（Orchestrator-Workers）：一个中心模型动态拆解任务，分派给工作者模型，再综合结果。它和并行化在拓扑上相似，关键区别在于子任务不是预先定义的，而是由编排器根据具体输入决定的。判据很具体：写代码时，需要改动多少个文件、每个文件改什么性质的东西，都取决于具体任务，你无法预先枚举。

评估器—优化器（Evaluator-Optimizer）：一个模型生成回答，另一个提供评估与反馈，形成循环。适配信号有两个，可以直接当判断清单用：一是当人类把反馈说清楚时，模型的回答能被明显改进；二是模型自己也能给出这样的反馈。文学翻译是典型场景——译者模型初次可能抓不到的细微之处，评估器模型能给出有用批评。

智能体真正成立的条件

智能体的运行循环并不复杂：起点是人类的指令，或与人类的交互式讨论来澄清任务；任务明确后，智能体独立规划与执行。执行过程中最关键的一点是，每一步都要从环境获取"ground truth"——工具调用的结果、代码执行的结果——用来评估自身进展。它可以在检查点或遇到阻塞时暂停，索取人类反馈。

实现上其实很简单，本质就是"模型在循环里根据环境反馈使用工具"。但前提是你要对模型的决策有一定程度的信任。风险也说得很实在：自主性意味着更高的成本，以及错误累积的可能。因此建议在沙盒环境中广泛测试，并配好合适的护栏；工具集与文档必须清晰、经过深思熟虑地设计。

三条核心原则

文章收束在三条原则上：简单（保持智能体设计的简单）、透明（明确展示智能体的规划步骤）、精心打造智能体—计算机接口（ACI）（通过充分的工具文档与测试）。总纲是：这个领域的成功不在于建最复杂的系统，而在于建适配需求的正确系统。推荐路径是从简单提示词开始，用全面的评估去优化，只有当更简单的方案确实不足时，才引入多步智能体系统。

附录里藏着最实用的一段：给工具写提示词

人们通常在整体提示词上花很多心思，却忽略了工具定义本身也需要提示词工程。同一个动作有多种工具格式，在软件工程上只是外观差异，但对模型的难度差异巨大：写 diff 需要在写新代码之前就知道行数变化，这对模型很难；把代码写进 JSON 需要额外转义换行和引号；相比之下，写整个文件或用 markdown 包代码就容易得多。

三条格式选择法则：给模型足够的 token 去"思考"，别让它把自己写进死胡同；格式尽量贴近模型在互联网上自然见过的写法；确保没有格式开销——不用数准行数、不用做字符串转义。

ACI 这个概念是本文的原创提法。类比很直接：业界在人机界面（HCI）上投入了多少精力，就应该在智能体—计算机接口上投入同等精力，方法是站在模型的角度看工具好不好用。好的工具定义通常包含示例用法、边缘情况、输入格式要求、以及与其他工具的清晰边界。还有一条防呆原则：改变参数设计，让错误更难被犯出来。

最有说服力的是团队自己的经历：在做 SWE-bench 智能体时，他们在优化工具上花的时间比在整体提示词上还多。他们发现模型在相对路径下会出错，尤其在智能体移出根目录之后；改成要求绝对路径后，模型的使用就完美了。

两个已被验证的落地场景

客户支持适配的理由有四条：支持类交互天然是对话流，但同时需要访问外部信息与执行动作；可以集成工具拉取客户数据、订单历史、知识库文章；退款、更新工单这类动作可以程序化处理；成功能被清晰度量——按用户定义的"已解决"来算。一个有说服力的旁证是，已有若干公司采用按成功解决量计费的模式，这体现了他们对自家智能体有效性的信心。

编码智能体适配的理由同样是可验证性：代码解法可通过自动化测试验证，智能体能以测试结果为反馈迭代解法，问题空间定义良好，输出质量可客观度量。目前智能体已能仅凭拉取请求的描述，解决 SWE-bench Verified 中的真实 GitHub issue。但边界条件必须一并说：自动化测试能验证功能性，人类审查仍然关键，用于确保解法符合更广的系统要求。

汉兴评述：这篇文章在中国企业语境下的用法

这篇文章的中文读者最容易读偏的地方，是把它当成"智能体不行"的证据。它不是。它给的是一套分流规则：先判断任务属于确定性工作流还是真正需要自主探索的场景，再决定投什么。一个组织如果连这道分流都没做，投多少钱做智能体化改造，都是在为不确定的收益支付确定的成本。

值得中国管理者特别留意的，是文中反复出现的"可度量"这个前提。客户支持之所以是好场景，不是因为它技术上简单，而是因为"是否解决"有清晰口径；编码之所以是好场景，是因为测试能给出客观反馈。反过来说，一个连成功标准都说不清的业务环节，先补的应该是度量，不是智能体。

最后一条可以直接拿去用的，是那句关于工具的经验：在真实项目里，打磨工具接口的收益往往高于打磨提示词。这对正在建设内部智能体平台的团队意味着，接口文档、参数命名、错误信息这些看起来是"工程杂活"的东西，恰恰是决定系统上限的地方。

延伸阅读：Building effective agents（Anthropic Engineering 官方原文）