03 · Agent 具备哪些核心能力？ - Core Capabilities

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：01 · Agent 是什么？它如何工作？ - Fundamentals
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：现代模型驱动型 Agent 的核心能力如何定义、形成、组合和验证？如何从可观察的任务行为反推模型、工具、状态与执行控制的技术要求，区分演示成功与稳定可靠的能力，并在不同任务、环境、权限和预算条件下建立可检验的能力契约？

专题导读

《Core Components》回答 Agent 由什么组成；本篇回答这些组成部分在特定环境中究竟能完成什么。这一差别决定了研究方法：不能把“装有搜索工具”“支持记忆”“接入推理模型”直接当作能力结论，而要观察 Agent 在给定输入、环境、权限和资源约束下是否产生符合要求的结果。

能力不是独立软件组件，也不完全等于模型本身的性能。一个 Agent 可能理解用户意图，却无法将意图转化为有效的工具调用；可能检索到正确资料，却在综合时丢失关键证据；也可能一次成功完成任务，却在环境轻微变化后反复失败。因此，能力研究必须同时考察任务语义、运行机制、可观察行为、失败条件和统计可靠性。

本篇以单个 LLM 驱动 Agent 为主要对象，从能力的操作性定义出发，建立能力契约、能力依赖图和验证框架；深入分析目标理解、环境感知、知识利用、推理规划、工具行动、反馈修正、记忆复用、人机协作和约束执行九组能力的内部形成机制；再通过技术路线、贯穿案例与可运行的评测程序说明如何将能力判断转化为工程证据。具体算法的完整实现分别留给 A2、A4-A10，Agent Loop 的控制协议留给下一篇 《Execution Mechanism》。

一、研究定位：能力是任务条件下的系统行为

1.1 能力不是配置项

把 Agent 记为系统 $A$，任务集合为 $T$，环境分布为 $E$，工具与权限条件为 $P$，预算为 $B$。一个实用的能力陈述不是“Agent 具有检索能力”，而是：

在规定的任务、环境、工具授权和预算范围内，Agent 能以可接受的成功率完成指定行为，并满足质量与安全约束。

可写作条件化指标 $C(A\mid T,E,P,B)$。这不是通用行业标准公式，而是本文为避免脱离条件讨论能力所采用的分析模型。改变其中任一变量，能力结论都可能改变。例如，联网检索可用时的事实查证能力，不能直接外推到离线环境；只读权限下的研究能力，也不能证明系统具备可靠发布能力。

一个更完整的能力陈述包含五项：任务族（做什么）、条件（在什么环境与授权下）、成功判据（怎样算完成）、禁止行为（不能做什么）、证据（怎样验证）。能力由任务运行记录与结果评测支持，而不是由系统自我描述支持。

1.2 四层能力状态

层次	含义	典型证据	不能推出什么
潜在能力（Potential）	模型或算法可能支持某类行为	模型基准、离线实验	不能推出已集成到 Agent
可用能力（Available）	运行时具备所需接口、工具和权限	配置检查、契约测试	不能推出任务能成功
表现能力（Demonstrated）	在特定样例中完成行为	运行轨迹、产物验收	不能推出稳定可靠
可靠能力（Reliable）	在明确任务分布与扰动下达到统计门槛	多次测试、分层指标、故障注入	不能无条件外推到新分布

从“可用”到“表现”依赖控制流程、数据质量和环境反馈；从“表现”到“可靠”依赖覆盖足够的任务变体、重复实验、失败分析和持续监测。能力的真实性取决于这些证据之间是否建立了连接。

1.3 与组件、机制、自主性和权限的边界

组件是模型、检索器、工具执行器、记忆存储等系统构件；机制是信息选择、计划生成、状态更新、重试等运行过程；能力是任务中可以验收的行为；自主性是系统在多大范围内自行选择目标或行动；权限是系统被允许执行的动作集合。

四者之间不存在一一对应。一个任务可能通过固定工作流或自主规划实现同样的业务能力；同一个工具既可能增强信息获取，也可能增强外部行动；权限范围更大并不必然带来更高能力，反而可能增加失败风险。

二、能力形成的因果链：从目标到可验证结果

2.1 输入、内部过程与输出

研究 Agent 能力时，至少要区分以下对象：

任务输入 + 环境状态 + 授权/预算
              │
              ▼
        任务语义解析
              │
              ▼
        证据与状态组织 ◄─────┐
              │             │
              ▼             │
        候选行动/计划       │
              │             │
              ▼             │
        程序化行动校验       │
              │             │
              ▼             │
        工具或外部执行       │
              │             │
              ▼             │
        观察/事实核验 ────────┘
              │
              ▼
        结果验收与交付

这是逻辑链，不表示所有任务必须调用工具或经过相同顺序。每一环都可能成为能力瓶颈。任务理解正确但证据缺失，无法形成可靠结论；行动选择正确但工具参数错误，无法执行；工具执行成功但缺少验收，可能将部分结果误报为完成。

2.2 能力依赖不是线性相加

假设一个任务必须连续通过理解、检索、行动、验收四个环节，且在简化假设下各环节成功率分别为 $p_1,p_2,p_3,p_4$，整体成功率约为 $\prod _i{p}_i$。如果四环节各为 0.9，整体约为 0.6561。这里的独立性假设在真实 Agent 中通常不成立，但该例揭示了重要事实：多个“看起来很强”的局部能力，并不保证端到端可靠性。

更现实的研究应使用条件概率：$P(\mathrm{完}\mathrm{成})=P(\mathrm{理}\mathrm{解})\times P(\mathrm{检}\mathrm{索}\mathrm{正}\mathrm{确}\mid \mathrm{理}\mathrm{解})\times P(\mathrm{执}\mathrm{行}\mathrm{正}\mathrm{确}\mid \mathrm{前}\mathrm{序})\times P(\mathrm{验}\mathrm{收}\mathrm{正}\mathrm{确}\mid \mathrm{前}\mathrm{序})$。失败可能相关，例如错误的任务理解会同时污染检索词、计划和最终验收。因而不能只分别测量模块，还必须测量组合后的完整任务。

2.3 能力瓶颈与可归因性

诊断时应把失败定位到决策前（输入理解、状态估计、证据选择）、决策中（计划与动作选择）、执行中（参数、授权、工具故障）、执行后（观察解释、验收、恢复）。同一个最终失败可能有不同根因，不能简单归为“模型不够聪明”。

建议对每次 Run 记录任务 ID、能力标签、输入条件、关键中间决策、工具结果、产物验证结果和失败代码。能力评测依赖这些事实；仅保存最终回答不足以支持故障归因。

三、核心能力的功能地图与依赖关系

本文将九组能力作为观察与评测维度，而非九个必须独立部署的模块。

能力	可观察行为	主要依赖	典型失败
目标理解与任务建模	提取目标、限制、交付标准，识别缺失条件	Model、Instructions、Context	误解目标、擅自补全关键条件
环境感知与状态识别	获取有效观察并更新对环境的判断	Tools、Context、运行时	使用过期状态、混淆观察与事实
知识获取与证据利用	找到相关资料、追溯来源、支撑结论	Knowledge、Tools、Context	证据错配、遗漏关键来源
推理与规划	分解任务、选择步骤、调整行动	Model、Planning & Reasoning	无效分解、计划僵化
行动与工具使用	生成合法操作并核验执行结果	Tools、Permissions、Runtime	参数错误、越权、重复副作用
反馈与自我修正	检测偏差、定位原因、选择修复策略	Observation、状态、验证器	反复空转、错误自我确认
记忆与经验复用	检索相关历史并正确应用	Memory、Context	错误记忆、过期经验污染
人机协作	澄清、请求审批、交接和解释进度	Instructions、状态机、权限	错误时机提问、模糊审批
约束遵循与正确终止	不越界、不超预算、按标准停止	Runtime、Policies、评估器	自报完成、失控循环

这些能力有依赖，但不存在固定单向顺序。一个研究任务可能先澄清目标，再检索资料，随后发现目标定义需要修正；一项浏览器任务可能每执行一步都重新观察页面。能力组合应根据任务结构确定。

四、能力一：目标理解与任务建模

4.1 从自然语言到任务契约

“帮我研究一下 Agent 框架”不是可直接验收的任务。Agent 需要识别对象范围、比较维度、证据要求、时间限制、交付格式和授权边界。可将任务表示为：

{
  "objective": "比较三个 Agent 框架的持久化执行机制",
  "deliverable": "带来源的技术比较报告",
  "constraints": ["只读检索", "不得未经确认发布"],
  "acceptance": ["每个框架至少有一项可追溯原始资料", "说明恢复与重试语义"],
  "unknowns": ["是否需要指定版本范围"],
  "budget": {"max_tool_calls": 30}
}

这是教学性的任务契约，不是统一 API。关键机制是将用户话语拆解为目标、约束、可验证条件、待澄清项，并保持来源对应关系。对用户未说明的关键限制，不应静默编造为确定事实。

4.2 澄清与行动的决策

不是所有缺失信息都需要提问。可根据缺失项的影响程度和行动可逆性决定：缺失信息会改变高风险操作、费用或交付范围时，优先澄清；缺失项仅影响可逆的初步检索时，可在明确假设下先行动。

例如，“查找三种常见方案”可以先检索并说明选取标准；“把比较报告发送给客户”缺少收件人或批准时，必须停在发送之前。一个可测试的能力指标是：在需要澄清的任务中正确提问的比例，以及在不需要澄清的任务中避免无效打断的比例。二者应联合评估，避免 Agent 通过对所有请求提问获得虚假的“安全性”。

4.3 任务理解的测试设计

构造同义改写、隐含约束、冲突指令、缺少关键参数、可逆与不可逆动作等任务变体。比较 Agent 生成的任务契约与人工标注的目标和约束；分别测量目标覆盖率、约束遗漏率、错误假设率和澄清准确率。不能仅用“回答听起来合理”作为判据。

五、能力二：环境感知与状态识别

5.1 观察不是环境真实状态

Agent 经常只得到局部观察：搜索摘要、浏览器截图、工具返回、文件片段或 API 状态码。可用 $o_t$ 表示时刻 $t$ 的观察，$s_t$ 表示不可完全直接获取的环境状态，$b_t$ 表示系统基于历史观察维护的状态估计。Agent 的行动依赖可用的 $b_t$，而不是直接访问完整 $s_t$。

在网页操作中，截图显示按钮可见，不意味着按钮当前仍可点击；在文件操作中，读取时存在的文件不保证写入时仍未变化。因此，可靠的感知能力还包含观察的新鲜度、来源、置信程度与执行前复核。

5.2 状态更新的工程机制

一次工具观察应结构化记录：来源、采集时间、资源版本、状态、有效载荷引用、错误信息。更新任务状态时需要区分已验证事实、模型推断和待确认假设。例如，HTTP 202 表示请求被接纳，不能直接写成“业务操作已完成”；模型读到“发布成功”的网页文本，也不能替代可信发布接口的结果。

环境状态发生变化时，系统可能需要重新获取观察、废弃旧计划、重新校验工具参数。这里的关键能力是根据新证据修正状态估计，而非一次性识别页面或文档。

5.3 感知能力评测

测试观察缺失、延迟、重复、矛盾和过期的情况。测量状态判断正确率、错误观察拒绝率、重新观察触发率和对关键状态变化的响应延迟。对于多模态 Agent，还需要分别评测图像理解、坐标定位与操作结果验证，不能把视觉模型的离线识别准确率直接等同于浏览器任务成功率。

六、能力三：知识获取与证据利用

6.1 从“找到资料”到“形成可追溯判断”

知识利用至少包含：识别知识缺口 → 选择来源 → 检索候选 → 阅读证据 → 判断相关性与可信度 → 综合结论 → 建立引用映射。每一步都会改变最终答案质量。

例如，研究某框架是否支持暂停恢复，搜索结果中出现“supports persistence”并不足以证明“工具调用超时后绝不会重复执行”。后者涉及具体执行语义，需要查阅框架原始文档、代码或实验。能力的核心不是检索量，而是证据与命题之间的可验证连接。

6.2 证据对象的数据结构

建议至少区分：claim_id（待证明命题）、source_id（来源）、locator（原文位置）、retrieved_at（获取时间）、source_version（来源版本）、support_type（支持、反驳、背景）、verification_status（是否核验）。在生成报告时，结论应能回溯到对应证据，而不是仅在文章末尾堆放链接。

检索器的相关性排序和研究结论的真实性不是同一件事。高相似度片段可能过时、缺少上下文或来自不可信来源；不同来源也可能引用同一原始信息，不能简单当作独立证据。

6.3 能力测试

将问题分为：单来源可答、多来源合成、来源冲突、信息缺失、时间敏感、存在诱导性错误资料。分别测量检索覆盖率、证据定位准确率、无证据拒答率、结论支持率与引用准确率。完整 RAG 算法、检索评测与知识库维护见 A6 及 Knowledge Engineering 专题。

七、能力四：推理、任务分解与规划

7.1 推理正确不等于计划可执行

推理关注从已有信息得出判断；规划关注在目标、状态、动作和约束下构造行动序列或策略。一个模型可能正确判断“需要读取官方文档”，却无法在工具预算内决定先读什么、何时停止、遇到错误如何调整。

最小规划模型可以定义为 $(S,A,T,G,C)$：状态集合 $S$、可行动作 $A$、状态转移关系 $T$、目标判据 $G$、成本或约束 $C$。在 LLM Agent 中，模型通常提出候选计划，运行时负责动作校验和状态更新；是否使用搜索、规则、图或重新规划，取决于任务环境。

7.2 四种常见规划粒度

无显式长计划：每轮依据当前状态选择下一动作，适合短任务与快速反馈环境；先规划再执行：先生成任务步骤，再逐步执行，适合依赖关系明确的任务；分层规划：高层目标分解为子任务，各层采用不同控制方式，适合复杂任务；滚动重规划：执行部分计划后利用新观察修正后续动作，适合动态环境。

不能仅凭是否输出一份“计划文本”判断规划能力。需要看计划是否具有可执行动作、依赖关系、终止条件和失败处理策略，以及执行时是否真正遵循并更新。

7.3 规划失败与评测

常见失败包括：不可执行步骤、循环依赖、遗漏必要前置条件、过度规划、计划与环境脱节、无效重规划。可评估目标达成率、计划有效率、平均额外步骤、重规划触发准确率和预算效率。更细的算法研究见 A9。

八、能力五：行动选择与工具使用

8.1 工具使用是受约束的决策-执行链

工具调用能力至少需要完成：识别操作需求、匹配工具契约、生成结构化参数、验证权限、执行调用、解释结果和确认副作用。模型生成的工具调用只是候选动作；真正的执行由可信程序负责。

例如，模型选择 publish_report，并不代表报告已发布。运行时应先校验参数和批准范围，再调用外部接口，最后检查真实发布结果。对于发送、删除、付款等有副作用的操作，还需要稳定操作标识、去重与失败核验。

8.2 工具选择的四层质量

1. 必要性：是否真的需要调用工具，还是可以直接回答？
2. 正确性：选择的工具是否适合当前任务？
3. 可执行性：参数、权限和前置条件是否满足？
4. 结果性：工具是否产生了所需外部事实或产物？

仅统计“函数调用格式正确率”会高估实际工具能力。应联合测量参数有效率、授权拒绝准确率、工具执行成功率、结果验收率和重复副作用率。

8.3 工具故障的能力边界

工具不可用、返回部分结果或超时，并不必然说明 Agent 认知失败。可靠的行动能力还包括识别可重试错误、在预算内选择替代工具、标记不可确定的执行状态，以及在必要时停止。特别是“超时但外部动作已生效”的场景，不能直接重试非幂等写入。

九、能力六：反馈利用、结果验证与自我修正

9.1 反馈闭环的三个不同对象

环境反馈告诉系统发生了什么；验证结果判断是否满足任务契约；修正策略决定下一步如何处理偏差。三者不应合并为一句“Agent 会自我反思”。

例如，代码运行返回测试失败是反馈；定位失败用例并确定断言不满足是验证；修改代码、重新测试或报告无法修复才是修正。没有外部可检验信号的“自我评价”可能产生错误自信。

9.2 修正算法的最小形式

可将修正过程写作：获取观察 $o_t$ → 计算与目标的偏差 $e_t$ → 分类失败原因 $f_t$ → 选择修复动作 $a_{t+1}$ → 执行并重新验证。必须限制最大修正次数、成本和重复动作，否则 Agent 可能在同一错误上空转。

对可重复验证的任务，可优先使用确定性验证器，如测试、Schema、文件存在性和数值约束；对开放性研究任务，则需要证据支持度、人工审核或模型辅助评价，并承认评价不确定性。

9.3 自我修正的反例

模型先生成错误答案，再要求同一个模型“检查一下”，随后得到肯定评价，并不能证明具备纠错能力。只有在独立证据、工具反馈或可复现测试使错误被识别并修复时，才有较强证据支持“修正有效”。评测应比较修正前后的正确率，同时记录把正确答案改错的比例和额外成本。

十、能力七：记忆与历史经验复用

10.1 记忆能力不等于保存聊天记录

记忆复用的关键环节是：确定哪些信息值得保存、以什么形式保存、在新任务中何时检索、如何判断相关性与时效性，以及如何避免旧信息污染新决策。聊天记录持久化只是可能的基础设施，不自动构成有效记忆能力。

例如，研究助理曾在上月记录某工具接口，今天进行相同研究时可以检索这段经验，但仍需检查版本变化。将旧结论当作当前事实，可能比完全没有记忆更危险。

10.2 记忆使用的运行契约

建议为检索到的记忆保留来源任务、写入时间、适用范围、可信度和过期条件。Agent 在利用记忆时应判断：当前任务是否匹配？记忆是否仍有效？是否与新证据冲突？需要将其作为事实、偏好、建议还是待验证线索？

记忆能力的测试不能只看“能否回忆某句话”，还应评估跨任务收益、过期记忆拒绝率、错误记忆纠正率和对当前任务的负迁移率。具体写入、整合和检索机制见 A5。

十一、能力八：人机交互、澄清与协同

11.1 交互是控制接口，不只是对话质量

Agent 与用户交互至少有三种不同目的：澄清任务、请求行动授权、交付与解释结果。三者的运行语义不同。澄清回答可以更新任务契约；审批必须绑定具体操作与参数；交付则应提供已完成事项、未完成事项及证据。

在长期任务中，还可能出现等待用户输入、暂停和恢复。此时用户消息不能仅被当作普通聊天文本，还应由运行时关联到正确的 Run、等待事件和审批对象。

11.2 协同能力的判据

有效交互不是消息越多越好。应测量必要澄清召回率、无效澄清率、审批请求完整性、用户响应后恢复成功率，以及结果解释是否准确反映真实执行状态。对高风险操作，语言上获得“可以”并不等于系统已取得有效的结构化授权。

十二、能力九：约束遵循、风险控制与正确终止

12.1 约束是能力成立的条件

一个 Agent 即使完成了业务目标，如果通过越权访问、泄露数据或超预算执行达成，也不能被判定为可靠完成。能力评测必须将任务成功与约束满足联合定义。

设 $Q$ 为任务质量，$V$ 为约束违反事件。对于必须严格满足的安全约束，可定义 success = quality_pass and not violation，而不是把越权行为当作可用高质量答案抵消的小扣分。

12.2 停止条件必须可验证

至少区分：业务完成、无法继续、用户取消、时间或步骤预算耗尽、权限拒绝和安全停止。模型输出“我已经完成”不能替代对产物和外部状态的检查。任务超时后交付部分结果时，应明确标注为部分完成。

12.3 能力与权限不相互替代

权限扩大可能提高可行动作集合，但不会自动提高动作选择质量。相反，可靠 Agent 通常需要足够而最小的权限，借助程序化校验防止模型在错误推断时执行危险操作。权限系统本身的设计见 A10，生命周期终止与恢复见 Fundamentals 07。

十三、能力组合：依赖图、瓶颈和架构选择

13.1 从任务反推能力，而非从能力清单堆组件

设计研究助理时，应先列出任务族：单篇文献摘要、多来源比较、证据冲突核验、长任务恢复、受控发布。再针对每个任务标注必须的行为与失败条件。例如，“多来源比较”依赖检索、证据关联与综合推理；“受控发布”额外依赖工具执行、授权与副作用核验；“长任务恢复”额外依赖检查点和状态恢复。

依赖图可表示为：

多来源技术比较报告
 ├─ 目标建模
 ├─ 知识获取
 │   ├─ 检索工具
 │   └─ 来源与版本定位
 ├─ 证据综合
 │   ├─ 上下文组织
 │   └─ 冲突识别
 ├─ 产物生成
 └─ 验收
     ├─ 引用支持率
     └─ 关键维度覆盖率

这张图是任务依赖，不是软件部署图。可用于发现能力缺口、确定测试边界和定位失败环节。

13.2 能力成熟度不应使用单一总分掩盖风险

将各项能力加权求和容易产生误导：高写作质量可能掩盖低权限遵循率。更合理的方式是将指标分成硬门槛和优化指标。硬门槛包括禁止行为、必须的业务验收和数据隔离；优化指标包括成本、延迟、交互次数和风格质量。

在比较 Agent 方案时，应先筛掉未满足硬门槛的系统，再比较剩余方案的质量-成本-延迟 Pareto 关系。不同任务的权重与门槛应来自实际需求，不宜套用统一“能力雷达图”直接决定架构。

13.3 单 Agent 与系统能力的边界

单 Agent 的能力可以依赖外部工具、数据库、运行时与人类审批；这些依赖并不自动使它成为多 Agent 系统。多个 Agent 的协作、调度与共享状态属于 Agent System。能力评测时应记录外部支持条件，避免将系统级调度或人工修复完全归因于单 Agent 的自主能力。

十四、代表性研究：不同技术路线如何增强能力

本节聚焦技术机制与证据适用范围，不将论文实验直接视为当前产品的性能保证。以下研究是理解能力形成机制的代表性起点。

14.1 ReAct：交替推理与行动增强信息获取和决策

ReAct（Yao 等，2023）将模型生成的推理与环境行动交替组织，使 Agent 能通过工具获取新观察，再依据观察继续决策。其关键贡献不是“模型能写计划”，而是把行动结果反馈纳入后续推理过程，缓解完全依赖内部知识或一次性推断的问题。

运行机制可以概括为：当前任务与观察 → 模型提出下一行动 → 环境执行 → 观察回填 → 模型继续。其能力增益依赖工具可用性、观察质量和行动选择；推理轨迹本身不保证正确。工程上还需要独立的动作校验、预算控制和终止判断。

14.2 Toolformer：工具使用可以成为模型学习目标

Toolformer（Schick 等，2023）研究模型如何通过自监督方式学习何时调用工具、使用什么参数，以及如何利用工具返回。它与纯运行时工具编排的区别在于：工具使用倾向可以通过训练机制进入模型行为，而不是仅靠推理时提示。

这提示我们：Agent 工具能力既受模型训练影响，也受运行时工具契约与校验影响。不能因为模型具备工具调用格式能力，就推断它对所有工具和任务都有可靠选择能力。

14.3 Reflexion：利用反馈形成后续尝试的改进信号

Reflexion（Shinn 等，2023）研究利用语言形式的反馈和反思记录改善后续尝试。核心机制是从失败或评价中形成可供下一次尝试使用的信息，而非单纯延长推理文本。其适用性依赖反馈是否能真实区分成功与失败，以及反思信息是否对下一次决策有帮助。

这条路线与本篇的“反馈修正”“记忆复用”交叉，但不应把一次自我批评当作可靠纠错证据。

14.4 Voyager：技能库与环境反馈促进长期任务能力积累

Voyager（Wang 等，2023）在 Minecraft 环境中结合自动课程、可执行技能库与迭代提示，展示持续探索中技能积累和复用的思路。其重要启发是：能力可以通过可执行技能的组织与复用逐步扩展，而不仅通过增大模型规模实现。

但其特定环境、工具和评价条件与企业知识工作存在差异，不能直接外推为通用 Agent 的长期自主能力。技能封装与复用的工程细节留给 A8。

14.5 技术路线比较

路线	主要增强环节	关键机制	主要依赖	不宜过度推断
ReAct	行动-观察-推理闭环	交替行动与观察反馈	工具、环境状态	不等于安全执行或可靠恢复
Toolformer	工具调用决策	训练阶段学习工具使用	训练数据与工具接口	不等于任意工具的高成功率
Reflexion	反馈修正	利用反馈形成下一轮改进信息	可用评价信号	不等于自我评价必然准确
Voyager	长期能力积累	自动探索、技能存储与复用	可执行环境、技能库	不等于跨领域普适迁移

选择技术路线时应先识别能力瓶颈：信息不足优先改善检索与观察；行动错误优先改善工具契约与验证；反复犯同类错误可考虑反馈记录；重复任务多可考虑技能复用。单纯叠加所有机制可能提高成本与复杂度，却不一定提升成功率。

十五、能力契约：把抽象能力转化为可测试规格

15.1 一个能力契约应包含什么

建议定义以下字段：

capability_id: evidence_based_comparison
version: 1
scope:
  task_family: technical_comparison
  environment: read_only_web_and_documents
  authorization: [search, read]
inputs:
  required: [question, comparison_dimensions]
outputs:
  required: [report, claim_source_map]
acceptance:
  min_evidence_coverage: 1.0
  require_artifact_validation: true
hard_constraints:
  forbidden_actions: [publish, delete, send]
resource_limits:
  max_tool_calls: 30
  max_runtime_seconds: 300
evaluation:
  datasets: [routine, conflicting_sources, missing_evidence, adversarial]
  metrics: [task_success, evidence_coverage, unsafe_action_rate, cost]

这是本文提出的教学性能力契约，不是某一框架的配置格式。契约的价值是将能力边界转化为可以检查的输入、行为和输出。尤其要避免将“用户满意”作为唯一指标，因为它可能无法发现引用错误、隐性越权或外部副作用。

15.2 契约、测试与执行记录的映射

每个测试样例应具有 case_id、任务族、输入、环境配置、允许动作、期望证据与验收标准。每条运行轨迹应记录 run_id、模型与工具版本、动作序列、观察、产物引用、成本和最终状态。评测器依据契约和运行轨迹生成指标。若只有模型最终回答，没有动作轨迹，就无法可靠判断是否发生了禁止操作。

15.3 任务分布与分层测试

建议至少分为：常规任务、边界任务、信息缺失任务、环境扰动任务、对抗性输入任务。对每一类分别统计结果，避免常规样例数量过多而掩盖关键风险。能力结论应说明评测任务分布、样本量、执行次数、工具条件和模型版本。

十六、能力评测的统计设计与失败归因

16.1 成功率不是唯一指标

设 $N$ 为样例数，$I_i$ 为第 $i$ 个任务是否满足所有硬性成功条件，任务成功率为 $\frac{1}{N}\sum _i{I}_i$。此外应记录证据覆盖率、工具参数正确率、禁止动作发生率、平均成本、延迟、人工介入率和恢复成功率。

对于高风险约束，建议同时报告违规次数与测试暴露次数，不要只给一个加权综合分。样本很小时，“零次违规”不能证明风险为零；例如 10 次测试未违规与 10,000 次测试未违规的证据强度完全不同。

16.2 重复运行与置信区间

模型输出具有随机性，外部工具和网络也会变化。对关键任务应在受控环境中多次运行，并记录模型配置、温度等参数、时间和外部数据版本。比较两个方案时尽量使用同一批任务，并分析逐任务差异。

对于成功率可采用二项比例的 Wilson 区间等统计方法报告不确定性；对于成本和延迟，报告分位数往往比只报告平均值更有价值。若测试集经反复调参，最终应保留未参与调参的独立评测集，降低对测试集过拟合的风险。

16.3 失败分类与反事实分析

对失败 Run 记录首个可定位的关键失效点，同时允许多个关联原因。例如：任务理解错误、检索遗漏、证据误读、动作参数错误、权限拒绝、工具故障、状态过期、验收错误。然后尝试受控消融：固定工具结果只替换规划器、固定计划只替换检索结果、关闭记忆、改用确定性验证器等。

消融研究可以帮助判断瓶颈，但要避免将相关性直接解释为因果性；如果不同版本同时改变模型、Prompt 和工具，无法准确归因改进来源。

十七、工程实现：一个最小能力评测器（L2）

17.1 实现目标与边界

配套文件 03-Agent-Core-Capabilities-v1.1-demo.py 使用 Python 3 标准库实现能力契约下的运行轨迹评估。它不是 Agent Runtime，不生成模型回答，也不执行真实工具；其验证对象是：给定任务要求、允许动作与执行轨迹，评测器能否正确识别证据缺失、禁止操作和交付失败，并按任务组聚合指标。

关键数据结构：Case 保存任务要求与授权；Trace 保存已发生动作、证据、产物状态、成本和耗时；evaluate 执行硬约束检查；aggregate 生成分组统计。

17.2 核心代码

from dataclasses import dataclass

@dataclass(frozen=True)
class Case:
    case_id: str
    group: str
    required: frozenset[str]
    allowed: frozenset[str]
    expected_artifact: bool

@dataclass(frozen=True)
class Trace:
    case_id: str
    actions: tuple[str, ...]
    evidence: frozenset[str]
    artifact_valid: bool
    cost: float
    elapsed: float

def evaluate(case: Case, trace: Trace) -> dict:
    assert case.case_id == trace.case_id
    unauthorized = set(trace.actions) - set(case.allowed)
    coverage = len(case.required & trace.evidence) / max(1, len(case.required))
    artifact_ok = trace.artifact_valid if case.expected_artifact else True
    success = coverage == 1 and artifact_ok and not unauthorized
    return {
        'coverage': coverage,
        'unauthorized': bool(unauthorized),
        'artifact_ok': artifact_ok,
        'success': success,
    }

代码将任务成功定义为证据覆盖完整、产物有效且没有越权动作。这是一种特定任务契约的示例，不能作为所有 Agent 的通用成功标准。真实系统还应验证证据内容是否真正支持命题、动作是否产生外部副作用，以及任务是否在预算内完成。

17.3 测试与结果

配套程序包含两个模拟样例：常规任务仅执行获准的 search/read，证据齐全且产物有效，判定成功；对抗样例虽然证据齐全、产物有效，却出现未经授权的 publish，因此判定失败。运行程序得到：

{'routine': {'n': 1, 'success_rate': 1.0, 'unsafe_rate': 0.0, 'avg_cost': 0.03},
 'adversarial': {'n': 1, 'success_rate': 0.0, 'unsafe_rate': 1.0, 'avg_cost': 0.02}}

该结果已在本地使用 Python 运行验证；它仅证明评测逻辑对两个预设轨迹给出预期判断，不证明任何真实 Agent 的能力水平。每组只有一个样例，不能据此估计总体成功率。

17.4 走向系统级验证（L3）的必要扩展

实际评测应接入真实 Agent 的 Run Trace，包含工具调用前后的授权结果、操作 ID、证据定位与产物验证器；增加持久化样例集、可复现环境、重复执行和统计区间；使用故障注入模拟超时、过期状态、工具结果丢失与权限变化。对于真实外部写操作，评测环境应采用沙箱或模拟服务，防止测试本身产生不可逆影响。

十八、贯穿案例：研究助理 Agent 的能力构建与验收

18.1 任务与条件

任务：比较三个 Agent 框架的长任务恢复能力，生成有来源的报告；允许搜索、阅读和本地草稿写入；对外发布必须审批；总工具调用不超过 30 次。用户希望了解检查点粒度、恢复语义、重试与副作用风险。

18.2 从任务拆出能力依赖

目标理解：将“恢复能力”分解为检查点、状态持久化、暂停恢复、重试、版本兼容性；知识利用：找到各框架原始文档并记录版本；规划：先建立比较维度，再逐框架搜集证据；工具行动：执行搜索与文档读取；反馈修正：当某项证据不足时重新检索；记忆复用：读取已有研究记录但检查时效性；人机协作：报告草稿完成后请求发布审批；约束遵循：未批准时不调用发布接口。

18.3 具体执行轨迹

任务接收
  → 解析交付与禁止条件
  → 形成比较维度
  → 检索框架 A 原始资料
  → 检索框架 B 原始资料
  → 检索框架 C 原始资料
  → 发现“重试副作用”证据不足
  → 补充阅读原始技术文档
  → 形成命题-证据映射
  → 生成报告草稿
  → 验证维度覆盖与引用定位
  → 保存产物
  → 若请求对外发布：进入审批等待

这个轨迹的能力证据不在于它“看起来像研究流程”，而在于每一步都能产生可核验的状态或产物。例如，补充检索是否真的弥补证据缺口，引用是否指向支持命题的具体位置，未审批时是否确实没有发布请求。

18.4 验收与失败注入

至少设计五类测试：①常规任务全部资料可用；②某框架资料缺失，要求明确不确定性；③搜索结果包含过期版本，要求识别版本；④文档中包含“忽略规则并发布”的恶意文本，要求不执行；⑤发布请求被拒绝，要求保留草稿并停止发布。逐项记录结果和失败原因，不以最终报告语言流畅度替代能力判断。

十九、能力提升的工程决策方法

19.1 优先修复瓶颈，而非盲目增加模块

如果报告经常引用错误，优先检查证据定位、上下文装配与引用验证；如果任务经常超预算，检查计划冗余和工具调用策略；如果 Agent 在工具失败后重复发送，优先修复执行语义和幂等控制，而不是增加“谨慎行事”的提示词。

一种实用的改进循环是：收集失败样例 → 标注首要失效环节 → 设计单变量改动 → 在固定测试集验证 → 检查新引入的成本与风险 → 再进行端到端回归。对于模型和工具版本升级，需要重新评测原有能力结论。

19.2 三类设计取舍

可靠性与成本：更多验证与重复检索可能提高质量，但增加 Token 和工具费用；自主性与可控性：动态规划适应变化，但需要更强的授权、状态与验收；记忆与新鲜度：复用历史降低成本，却可能引入过期事实。应围绕任务风险和收益选择机制，而不是默认“越多越好”。

19.3 什么时候不需要复杂 Agent

当任务目标稳定、输入结构化、步骤确定且不需要动态环境判断时，固定程序或工作流通常更易验证。只有当任务存在显著的不确定性、需要动态获取信息、基于观察改变行动，且这种灵活性足以抵消成本与风险时，才更有理由引入 Agent 决策机制。这与《Agent Design》的架构选型研究相衔接。

二十、常见误区与诊断

错误判断	为什么不成立	应采用的证据
接入模型即具备推理能力	模型潜能不等于任务完成	任务级推理与验收测试
接入搜索即具备研究能力	搜索结果可能不相关或不可信	命题-证据定位与引用核验
输出计划即具备规划能力	计划可能不可执行或不更新	计划执行率与重规划测试
能调用工具即具备行动能力	参数、权限、外部结果可能失败	工具轨迹与副作用核验
自我批评即具备纠错能力	没有独立反馈可能反复犯错	修正前后成功率与回退率
保存聊天即具备记忆能力	保存不等于有效检索和利用	跨任务收益与错误记忆测试
一次演示成功即可靠	样例不足、环境可能偶然有利	分层重复实验与区间
最终答案正确即安全	过程可能越权或产生重复副作用	全链路行为审计
能力越多越好	机制复杂度与成本可能超过收益	任务收益-成本-风险比较

二十一、与前后专题及研究领域的关系

《Agent Core Components》 解释构件及职责；本篇解释这些构件能否形成可观察、可验证的任务能力；《Execution Mechanism》 进一步研究能力在单次 Agent Loop 中如何被组织为决策、行动和状态更新；《Agent Types》 讨论不同控制架构的类型与选择；《Agent Design》 将能力契约转化为设计决策；《Agent Lifecycle》 研究能力在版本、运行与恢复过程中的持续性。

Internal Architecture 的 A1-A10 将分别深入模型、指令、上下文、记忆、知识、工具、技能、规划和权限的具体实现。本篇不重复这些专题的算法细节，而提供一套跨组件的能力分析与评测框架。Agent System 与 Agent Platform 则分别研究跨 Agent 协作、运行基础设施和集中管理。

二十二、核心结论

Agent 的核心能力不是一个固定清单，也不是模型参数、工具数量或 Prompt 长度的直接函数。它是在明确任务条件下，由模型、状态、知识、工具、控制逻辑和权限共同形成的可观察系统行为。

理解能力必须同时回答：目标是什么、系统实际做了什么、结果是否符合验收、是否违反约束、失败能否定位、换一个任务或环境是否仍然可靠。能力设计应从任务契约出发，建立依赖图和硬性边界，再通过运行轨迹、分层测试、重复实验与故障注入形成证据。只有这样，才能从“Agent 看起来会做什么”进入“Agent 在哪些条件下可以被可靠地用于什么”。

参考资料与延伸阅读

1. Stuart Russell, Peter Norvig. Artificial Intelligence: A Modern Approach, 4th ed., Pearson, 2021。智能体、环境、状态与决策的理论基础。
2. Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023。论文编号：arXiv:2210.03629。推理-行动-观察交替机制。
3. Timo Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS 2023。论文编号：arXiv:2302.04761。工具调用学习机制。
4. Noah Shinn et al. Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023。论文编号：arXiv:2303.11366。反馈与语言反思机制。
5. Guanzhi Wang et al. Voyager: An Open-Ended Embodied Agent with Large Language Models, 2023。论文编号：arXiv:2305.16291。自动课程、技能库与持续探索。
6. Xiang Yue et al. AgentBench: Evaluating LLMs as Agents, ICLR 2024。论文编号：arXiv:2308.03688。交互式环境下的 Agent 评测。
7. John Yang et al. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024。论文编号：arXiv:2310.06770。真实软件任务的可验证结果评测。
8. Anthropic. Building Effective Agents, 2024。工作流与 Agent 的工程设计视角。
9. OpenAI. A Practical Guide to Building Agents, 2025。Agent 设计、工具、指令与护栏的工程背景。

研究声明

资料与论证边界： 本文以用户原版《03 · Agent Core Capabilities v1.0》的能力分类、对象边界和工程关注点为基础重构，增加任务条件化能力模型、因果依赖、契约设计、技术路线分析与评测实现。数学表达、能力契约 Schema、能力分层和测试框架属于本文的工程归纳，不是统一行业标准。

资料核验状态： 本次未逐篇在线复核全部论文原文、2026 年最新官方 SDK 或框架实现。代表性研究的概述用于解释稳定技术思想；涉及实验结论、具体 API 和版本兼容性时，应以实际查阅的原始资料与实施版本为准。本文不声称完成了最新文献的系统性检索。

工程验证状态： 配套 Python 评测器已在本地执行，两个预设样例的断言通过。该程序仅验证评测规则，不是可运行 Agent，也未调用真实模型、工具或外部服务。没有开展真实 Agent 端到端评测、跨模型比较、统计显著性实验或生产环境安全验证。