第 2 章 Agent 的能力构成¶

第 1 章回答了“什么是 Agent，以及它的边界在哪里”。接下来必须继续追问一个更工程化的问题：一个 Agent 之所以能够工作，底层到底由哪些能力共同支撑？

如果把这个问题回答得过于简单，最常见的说法通常是“模型够强就行”。但在真实系统里，Agent 的表现几乎从来不是某个单一因素决定的。模型能力固然重要，但上下文装配、工具封装、状态管理、知识系统、执行编排和反馈机制同样关键。一个看起来聪明的 Agent，往往不是因为模型无所不能，而是因为系统给了模型足够合适的输入、约束和行动通道。

本章将从四个核心能力出发，拆解 Agent 的能力构成：推理能力、工具调用能力、规划与执行能力，以及状态维护与记忆能力。在这一基础上，再进一步讨论一个经常被忽略的问题：哪些能力来自模型，哪些能力来自系统设计。

2.1 推理能力¶

推理能力通常是开发者最先注意到的一种能力，因为它最接近人们对“智能”的直觉理解。一个模型能否正确理解任务、识别约束、分析候选路径并给出相对合理的下一步判断，会直接影响 Agent 的上层行为。

在 Agent 场景里，推理能力通常体现在以下几个方面。

第一，理解任务。用户给出的指令往往不是标准化接口调用，而是一段自然语言描述。模型需要把这些描述转化成更结构化的目标表示，区分主任务、子任务、边界条件和隐含要求。

第二，分析当前状态。Agent 在执行过程中并不是处于真空中，它需要结合当前上下文、已有结果、工具返回值以及系统约束，判断自己处于什么阶段、缺少什么信息、下一步最应该做什么。

第三，做动作选择。并不是每一步都需要调用工具，也不是每个问题都应该先搜索知识库。一个具备推理能力的 Agent 会在“继续思考”“向用户追问”“发起检索”“调用某个外部工具”之间做选择。

第四，拆解复杂任务。面对多步骤目标时，模型往往需要先形成某种任务结构，知道哪些步骤有依赖关系，哪些步骤可以并行，哪些步骤需要在关键节点引入人工确认。

但是，推理能力的重要性很容易被高估。推理并不能替代真实世界中的事实来源，也不能替代系统状态本身。一个模型即使非常擅长分析，也无法凭空知道企业内部数据库里的最新记录、监控系统中的当前指标，或者当前代码仓库中尚未提交的变更。它能做的是在已有信息基础上组织判断，而不是凭空制造现实。

这也是为什么在 Agent 系统里，必须严格区分“推理能力”和“知识能力”。推理能力回答的是“如何判断”，知识能力回答的是“依据什么判断”。如果一个系统把这两者混在一起，就很容易在信息不足时让模型强行猜测，从而导致路径偏移、自信但错误的结论，甚至后续动作的级联失误。

从工程角度看，推理能力不稳定时通常有几种常见表现：

忽略关键约束，只关注表面任务。
在多步任务中反复改变策略，导致执行路径漂移。
过早下结论，没有先补充必要信息。
中间推理和最终动作不一致。

这些现象并不一定意味着模型本身不够强，很多时候也可能说明系统没有把上下文组织好，或者没有给出足够明确的执行边界。因此，在 Agent 设计中谈推理能力，不能只讨论模型参数规模，更要讨论上下文、指令和控制逻辑如何帮助推理稳定发生。

工程提示¶

推理能力决定了 Agent 如何判断，但不能决定它掌握了什么真实信息。不要用“模型很会推理”来替代对外部知识和状态系统的设计。

2.2 工具调用能力¶

如果说推理能力决定了 Agent 如何思考，那么工具调用能力决定了 Agent 是否能够真正作用于外部世界。没有工具调用，很多 Agent 最终只能停留在解释、建议和猜测层面；有了工具调用，系统才可能完成检索、查询、修改、执行和提交等实际动作。

从工程实现上看，工具可以被理解为一组对外部能力的结构化封装。它的外观可能是函数调用、HTTP API、数据库查询接口、文件系统操作、命令执行器，也可能是内部业务系统的专用连接器。对于 Agent 来说，工具的价值不在于“调用成功”这一点本身，而在于它为语言模型建立了一条通向现实系统的动作通道。

一个完整的工具调用链路通常包含几个步骤。

首先，Agent 需要判断当前是否真的需要工具。如果用户只是要求解释一个概念，直接回答可能就够了；如果用户要求“帮我查看某个订单状态并生成处理建议”，那就必须访问外部系统。识别“什么时候该用工具”，本身就是能力的一部分。

其次，Agent 需要选择正确的工具。在工具较多的系统里，这一步并不简单。名称相似、能力重叠、权限不同、返回结构不一致，都会增加选择难度。工具设计越混乱，模型就越容易选错。

然后，Agent 需要生成正确的参数。这一步既依赖模型的理解能力，也依赖工具接口本身的设计质量。如果参数命名不清、语义过载、必填项不明确，工具调用失败率通常会迅速上升。

接下来是调用与结果处理。工具返回的往往不是自然语言，而是结构化数据、错误码、日志片段、文件内容或执行状态。Agent 必须能正确解释这些结果，并据此决定下一步行为。一次调用成功并不意味着任务成功，真正关键的是系统能否把调用结果纳入后续决策。

最后，Agent 还要处理失败。网络错误、超时、权限不足、参数不合法、外部系统状态异常，都是工具调用中的常态，而不是例外。一个只考虑成功路径的 Agent 系统，往往在真实环境里极其脆弱。

从这个角度看，工具调用能力并不是“模型会不会 function calling”这么简单，而是一整套围绕动作执行构建的系统能力。它包含工具抽象、接口设计、权限管理、调用控制、结果解析和失败恢复等多个方面。

也正因如此，工具调用能力常常是 Agent 与普通问答系统的真正分水岭。前者不只是解释现实，而是可以触达现实、读取现实，甚至影响现实。

工程提示¶

优秀的工具设计会显著降低 Agent 的复杂度。与其希望模型自己“悟出”怎么用工具，不如先把工具描述、参数约束和返回结构设计得足够清晰。

2.3 规划与执行能力¶

Agent 与一次性生成系统的另一个关键差别，在于它经常需要把复杂任务拆成多个步骤来处理。这个过程中，规划与执行能力就变得非常重要。

所谓规划，指的是 Agent 在面对较复杂目标时，对任务结构做出某种形式的组织。它可能表现为显式列出步骤，也可能表现为在内部维持一个隐式行动顺序。无论形式如何，规划的作用都是把“大目标”拆成“可推进的小动作”，并管理这些动作之间的依赖关系。

执行则是规划的落地过程。它要求 Agent 不只是把步骤写出来，还要真正推进这些步骤，在执行中读取结果、识别偏差，并据此修正后续行动。很多系统看起来“会规划”，但其实只是会列清单；真正困难的是在不确定环境里持续把计划变成有效动作。

在实践中，常见的规划方式大致有三种。

第一种是隐式规划。模型不显式输出完整计划，而是在每一步根据当前状态决定下一步。这种方式速度快、开销低，适合简单任务和短链路任务，但在复杂任务中容易漂移。

第二种是显式规划。系统会先让模型给出任务计划，再按步骤执行。这种方式有助于提高透明度和可调试性，也方便在关键节点插入人工确认，但如果计划生成得过细，往往会因为环境变化而迅速失效。

第三种是反思式规划。系统允许 Agent 在执行中不断修正原计划，必要时回退、重排或追加步骤。这种模式更接近真实环境中的任务推进，但同时也更依赖状态管理和执行控制。

规划与执行能力的重要性，主要体现在以下几类任务中：

任务本身较长，单次输出无法完成。
需要调用多个工具，且存在先后依赖。
失败代价较高，必须在关键步骤前进行校验。
中间结果会显著影响后续路径。

与之相对，对于简单问答、单步查询、低风险检索等任务，显式规划未必有必要。过度规划不仅会增加延迟和成本，还可能让系统看起来复杂但没有实际收益。

这里有一个很重要的工程判断：规划并不是越详细越好。过于细碎的计划会让系统在面对小变化时变得僵硬，而过于粗糙的计划又无法真正约束执行行为。好的规划设计应该服务于执行，而不是为了展示“系统很会思考”。

工程提示¶

真正值得设计的不是“如何让 Agent 写出更长的计划”，而是“如何让计划在执行中可验证、可修正、可中断”。

2.4 状态维护与记忆能力¶

如果一个 Agent 只处理单轮、单步、一次性任务，那么状态问题不会太明显。但只要任务开始跨越多个步骤、多个回合甚至多个会话，状态维护能力就会迅速成为系统成败的关键。

所谓状态，指的是 Agent 在某一时刻对任务推进情况及其运行环境的结构化理解。它不只是“历史对话记录”，还包括当前任务阶段、已完成动作、中间结果、待验证信息、失败原因、用户约束以及外部系统反馈。状态让 Agent 不至于在每一步都像第一次见到任务一样重新开始。

状态维护的价值至少体现在三个层面。

第一，它让系统具备连续性。Agent 能够知道前面已经做过什么、拿到了什么结果、哪些结论还不可靠，从而避免重复劳动和前后矛盾。

第二，它让系统具备恢复能力。多步任务在真实环境里很可能被中断，例如工具超时、用户离开、流程转人工。如果没有中间状态持久化，系统往往只能整段重来。

第三，它让系统具备更强的控制力。工程师可以基于状态定义更清晰的执行边界，例如哪些阶段允许调用哪些工具、什么条件下必须停止并请求人工确认。

与状态相关但不完全相同的，是记忆能力。状态更偏向当前任务运行时信息，而记忆更偏向能够跨轮次、跨任务复用的长期信息。例如用户偏好、长期工作背景、稳定的业务规则、历史任务经验，都可能以某种形式进入记忆系统。

从这个角度看，记忆并不是“多存一点聊天记录”这么简单。真正有价值的记忆，应该满足两个条件：第一，它对未来任务确实有帮助；第二，它不会因为错误积累而持续污染后续决策。这意味着记忆系统不仅需要写入能力，还必须有筛选、更新、纠错、淘汰和权限控制机制。

如果一个 Agent 缺少状态管理，常见症状包括：

重复调用相同工具。
忘记已经得到的中间结论。
在多步任务中突然切换目标。
无法从中断点恢复执行。

如果一个 Agent 缺少记忆管理，常见症状则包括：

每次交互都需要用户重新说明背景。
无法利用长期偏好提升体验。
相同问题反复从零开始处理。
错误信息没有被更新，长期污染后续行为。

后续章节会专门讨论 Memory 的分类、写入和读取机制，但在本章中，读者只需要先建立一个基本认识：Agent 要想真正承担持续任务，必须拥有对状态和长期信息的组织能力。

工程提示¶

不要把“历史消息拼进上下文”误认为完整的状态系统。上下文只是载体，状态需要被结构化、约束化和可恢复地管理。

2.5 能力来自模型，还是来自系统¶

当我们把 Agent 拆成推理、工具、规划和状态这些能力之后，一个更关键的问题自然会出现：这些能力究竟来自模型本身，还是来自系统设计？

答案是，两者都有，但分工完全不同。

模型本身主要提供的是语言理解、模式归纳、自然语言推理、文本生成，以及一定程度上的动作选择倾向。换句话说，模型擅长在上下文中做判断，并把判断表达出来。它是 Agent 中最接近“智能内核”的部分。

但一个 Agent 是否稳定、可控、可复现，更多取决于系统层面的设计。上下文如何装配，工具如何封装，任务如何编排，状态如何持久化，知识如何检索，结果如何评测，错误如何恢复，这些问题都不是单靠模型升级就能自动解决的。

很多初学者容易陷入一种直觉：只要换一个更强的模型，Agent 的问题自然会减少。现实往往恰好相反。如果系统设计本身混乱，模型越强，有时只会更“自信地做错”。因为系统没有给它稳定的输入边界、清晰的行动通道和明确的反馈机制。

从工程实践看，一个中等强度的模型配合良好的系统设计，往往比一个顶级模型配合混乱流程更可靠。原因很简单：生产系统真正需要的不是偶尔惊艳，而是长期稳定。

因此，在构建 Agent 时，更合理的能力分层方式是：

模型层负责理解、推理和表达。
编排层负责控制、调度、重试和回退。
工具层负责与外部环境交互。
知识层负责补充模型参数之外的信息。
状态层负责维持连续性与可恢复性。

只有当这些层次被清晰组织起来，模型能力才有机会稳定发挥。

2.6 能力之间如何协同¶

到这里可以看到，Agent 的核心能力从来不是孤立存在的。推理能力帮助系统判断该做什么，工具调用能力帮助系统真正采取行动，规划与执行能力帮助系统处理复杂任务，状态与记忆能力帮助系统跨步骤和跨轮次保持连续性。

它们的关系更像一个协作回路，而不是平铺罗列的功能清单。一个文档问答 Agent 可能更依赖知识系统和上下文工程；一个代码修复 Agent 可能更依赖规划、工具和状态管理；一个企业执行 Agent 则可能对权限、审计和失败恢复提出更高要求。不同类型的 Agent，能力侧重点不同，但底层协同逻辑是一致的。

对工程师来说，这一认识非常重要。它意味着构建 Agent 不是简单“打开几个能力开关”，而是要根据目标任务选择合适的能力组合，并为这些能力设计清晰的交互边界。

2.7 小结¶

Agent 的能力基础可以概括为四个核心部分：推理、工具、规划、状态。推理让系统能够判断，工具让系统能够行动，规划让系统能够处理复杂任务，状态让系统能够持续推进并避免遗忘。记忆则在更长期的尺度上帮助系统积累与复用信息。

但更重要的结论是：Agent 不是某个单一能力的放大，而是多种能力在系统层面被组织起来的结果。模型决定上限，系统设计决定稳定性和可用性。理解这一点，是后续讨论架构、RAG、Memory 和工程化问题的基础。