AI Agent 的工作原理：架构、规划和失败模式

大多数智能体故障都是架构故障。当任务偏离轨道时，模型往往会受到指责，但十有八九，真正的问题在于没有人充分思考规划、工具使用和反思应该如何协同工作。即使你换一个更好的模型，仍然可能会遇到同样的崩溃——因为模型周围的支架从未被设计成处理模型被要求完成的任务。

本文是一份关于智能体内部实际工作原理的实用指南：核心组件是什么，规划在哪里出错，反思循环如何帮助（以及何时会损害），以及当你为生产而非演示构建多智能体系统时它们会是什么样子。

智能体到底是什么

剥去炒作的外衣，其定义几乎简单到乏味。智能体是一个感知其环境并通过工具采取行动的系统。它由两件事定义：它所操作的环境（文件系统、浏览器、数据库、互联网）以及它能执行的动作集（读取文件、运行查询、发送 API 请求、编写代码）。

与普通的 LLM 调用关键区别在于循环。智能体不是回答一次就停止——它会循环进行感知、规划、行动、观察和重复，直到任务完成（或者以某种有趣的方式失败）。正是这个循环使得智能体能够执行多步骤任务，也使得它们难以正确构建。

2025-2026 年大多数人所说的“智能体”更准确地说是一种基础模型智能体：一个以 LLM 作为规划和决策核心的系统，周围环绕着为其提供工具、内存和跟踪进度的基础设施。这与通过奖励信号学习的强化学习智能体不同——尽管这两种方法正在趋于融合。

三大核心能力

每个有用的智能体都需要做好三件事：工具使用、规划和反思。其中任何一项出错，整个系统都会退化。

工具使用

工具是智能体与模型自身知识之外的世界互动的方式。它们分为两大类：

知识增强工具用于获取模型不具备的信息：网络搜索、SQL 查询、文档检索、内部 API。它们解决了任何模型的训练数据都有截止日期且不包含你的专有数据的根本问题。

能力扩展工具弥补模型表现不佳的方面：用于算术的计算器、用于复杂数据分析的代码解释器、用于调度计算的时区转换器。关于工具增强模型的研究一致显示出显著的提升——将检索与计算和代码执行结合起来，可以创建一个比任何单一工具或基础模型本身都强大得多的系统。

写入操作工具才是真正关键的地方：发送电子邮件、修改数据库、执行金融交易。这些工具实现了真正的端到端自动化，但也意味着错误不再是假设性的。一个格式不佳的 SQL 查询，如果只是读取数据，是无害的。但如果涉及写入，则不然。

实际挑战不在于添加工具——而在于知道应该包含哪些工具。更多的工具意味着更强的能力和更高的复杂性。更大的工具库增加了模型选择错误工具、生成错误参数或尝试调用不存在工具的可能性。正确的方法是先从最少工具开始，然后根据智能体实际失败的地方添加工具，而不是基于理论上似乎有用的东西。

规划

规划是大多数有趣（且痛苦）的工程工作发生的地方。智能体必须将高层次目标转化为一系列具体的工具调用，同时要考虑到依赖关系、条件判断以及早期步骤可能失败的可能性。

控制流的基本模式有：

• 顺序执行：行动 B 总是跟随行动 A
• 并行执行：A 和 B 同时执行，结果合并
• 条件（路由）：根据 A 的结果选择 B 或 C
• 迭代执行：重复直到满足某个条件

大多数实际任务都会结合这四种模式。一个研究工作流可能会并行运行多次网络搜索，根据发现的内容路由到不同的总结策略，迭代直到获得足够的信息，然后顺序生成输出章节。

关于自回归 LLM 是否能在计算意义上真正进行规划，或者它们是否只是在进行某种类似规划但缺乏我们期望的底层属性的操作，目前仍有争议。实际的答案是：这并不那么重要。重要的是它们以可预测的方式失败，而你可以在这些失败之外进行工程设计。

最有用的结构性决策之一是将规划生成与规划执行解耦。生成一个规划，根据基本启发式规则（它是否使用了真实的工具？步骤是否过多？是否违反了约束？）对其进行验证，然后才执行。这可以防止你将 API 成本浪费在那些从一开始就注定失败的规划上。

反思

反思是智能体从刚刚发生的事情中学习的机制。在采取行动并观察结果后，智能体（或一个独立的评估组件）决定是继续、回溯还是尝试不同的方法。

ReAct 模式——将思考、行动和观察交织成一个循环——是最常见的实现方式。智能体在决定下一步做什么之前，会明确地推断自己做了什么。这个简单的循环捕捉到了许多本来会悄无声息地累积的故障模式，令人惊讶。

一种更复杂的做法是将反思功能与执行者分离。一个专门的评估器对结果质量进行评分；一个自我反思模块分析失败的原因；执行者利用这些见解生成更好的计划。这就是 Reflexion 模式，它对于具有明确成功标准、且失败具有指导意义而非终结性的任务特别有用。

反思的成本是真实存在的。更多的推理令牌、更高的延迟、更多的 API 调用。对于简单的任务，这是一种浪费。对于需要正确完成的复杂任务，它物有所值。校准何时以及多大程度上进行反思，是智能体设计中一个被低估的工程决策。

计划为何会失败

当智能体未能正确完成任务时，故障通常属于以下五种类别之一：

1. 无效的工具选择 — 智能体调用了一个不存在的工具。这是工具层面的幻觉：模型编造了一个听起来可信的函数名，但它并不在工具清单中。

2. 有效工具，无效参数 — 选择了正确的工具，但参数数量或类型错误。一个期望两个字符串的函数却收到了三个整数。

3. 有效工具，不正确的值 — 结构上正确的调用，但语义上错误。正确的查询结构使用了错误的日期范围。正确的 API 端点缺少身份验证头。

4. 目标失败 — 计划在技术上执行没有错误，但却实现了错误的事情。智能体对任务的理解与预期不同，满足了字面请求却偏离了实际目标。

5. 反思错误 — 智能体（错误地）认为任务已完成，但实际并非如此，反之亦然。终止条件是错误的。

类别 1-3 可以通过监控和模式验证来捕获。类别 4-5 则需要更好的评估，可以通过人工审查输出，或通过将大型语言模型（LLM）作为判断器来检查结果是否与既定目标匹配。

实际意义是：在开发过程中，始终打印每个工具调用及其输出。通过多次运行的模式分析，你可以发现哪些工具正在引发问题，哪些参数错误最常见，以及问题是出在提示、工具设计还是底层模型上。

多智能体系统

第一次接触时，这会让很多人感到惊讶：几乎任何非简单的智能体都已经是多智能体系统，即使它看起来不像。计划生成器实际上与计划执行器是不同的智能体。如果再添加一个评估器和一个反思模块，你就有四个松散耦合的组件，每个组件都有自己的行为和故障模式。

这个领域正在经历与软件微服务转型类似的变化：单一的、一体化的智能体正被由专业的子智能体组成的协调团队所取代。一个协调智能体分解高级任务；专业智能体处理网络研究、代码生成、文档综合和输出格式；一个验证智能体检查最终结果。

这种架构具有真正的优势：

• 每个智能体都可以针对其特定功能进行提示和调优
• 昂贵的前沿模型可以保留用于规划；更便宜的模型执行任务
• 故障是局部化的，更容易诊断
• 人工监督可以在特定的交接点介入

“计划与执行”（Plan-and-Execute）模式是一个具体的实现。一个能力强的模型生成完整的策略；一个成本较低的模型执行每个步骤。成本节约可能非常可观——在某些工作负载中 API 成本可降低 90%——因为大部分推理负载都落在规划阶段。

“人在环路”（Human-in-the-loop）集成自然地融入了多智能体架构。人类可以在任何阶段参与：在执行前验证生成的计划，批准有风险的写入操作，或者处理智能体正确识别为超出其权限的任务。关键在于明确这些交接点，而不是让智能体悄无声息地做出不该做的决定。

提升可靠性的工程实践

一个能运行的演示与一个能可靠运行的生产级智能体之间的差距，几乎完全取决于工程纪律，而非模型质量。

以下是一些在实践中经受考验的原则：

明确地分离关注点。 不要让你的规划逻辑、工具分派和评估逻辑混淆在一个庞大的提示中。具有清晰接口的独立组件更容易调试、更容易升级，也更容易单独测试。

在执行计划前验证计划。 启发式检查——如步骤计数限制、工具有效性、约束验证——快速且能在浪费计算资源前捕获明显的故障。基于 AI 的计划评估更全面但也更昂贵；将其保留给复杂任务。

版本化你的工具接口。 系统提示中的工具描述实际上就是一个 API。你描述工具方式的改变会影响模型使用它的方式。对待工具接口设计应像对待公共 API 一样严谨——清晰的语义、良好的文档、稳定的契约。

从一开始就为可观测性而构建。 每次工具调用都应该被记录。每次反思决策都应该被记录。当你的智能体在生产环境中失败时，你需要足够的历史记录来重构它在思考什么。这不是可选的监控——它使得系统得以改进。

使自主性与风险匹配。 写入操作比读取操作需要更多的人工监督。不可逆操作比可逆操作需要更多的确认。正确的自主性水平不是固定的——它取决于智能体正在做什么以及错误可能带来的后果。

2025 年 AI 工程师峰会的 IMPACT 框架清晰地概括了关键组件：意图（Intent）、记忆（Memory）、规划（Planning）、权限（Authority）、控制流（Control Flow）、工具（Tools）。在设计智能体系统时，要仔细考虑每个维度。跳过其中任何一个，都可能导致你的系统在演示时运行良好，却在凌晨两点的生产流量中崩溃。

真正的工作

让智能体开发真正困难的不是模型的能力——模型能力的提升速度超出了所有人的预期。而是构建能够优雅地失败、从错误中恢复、了解自身局限性并在部署后能得到有意义改进的系统所需的工程规范。

好消息是，这些问题都是可以解决的。模式正在浮现，工具正在成熟，那些在 2025 年构建了生产级智能体的团队拥有来之不易的经验可以分享。坏消息是没有捷径：智能体是包含大型语言模型的分布式系统，而分布式系统一如既往地需要同样的严谨性。

从最有可能奏效的最小智能体开始。根据观察到的故障添加工具。对所有东西进行检测。在故障可恢复且代价高昂的地方引入反思机制。当单智能体复杂性变得难以管理时，引入多智能体协调。这不是什么新颖的见解——它只是将优秀的工程实践应用于一个新的问题类别。