A2 · Agent 如何获得认知与推理能力？ - Model

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：02 · Agent 的能力由哪些部分构成？ - Internal Architecture
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：模型如何在 Agent 的执行循环中把任务与观察转换成可验证的行动提议？模型调用、结构化输出、工具选择、多模型路由和推理预算如何实现？怎样用数据契约、可运行代码和对照实验区分模型能力与系统能力？

专题导读

在模型驱动型 Agent 中，语言模型承担理解目标、解释环境、提出行动、组织推理与生成结果的认知工作，但模型并不直接等于 Agent。一次模型推断只根据当次请求中可见的消息、工具描述和参数产生输出；输出可能是答案，也可能是结构化的行动提议。真正让行动发生的是运行时：它验证提议、执行工具、接收观察、更新任务状态并决定是否再次调用模型。研究 Model 组件的关键，不是泛泛罗列“理解、推理、生成”等能力，而是解释模型如何被调用、如何表示决策、如何从概率输出转化为可执行动作，以及模型不可靠时系统如何建立可测量的控制边界。

本文沿着一次 Agent 执行的完整路径展开：首先界定模型权能和推断边界；然后拆解模型调用协议、采样与约束解码、工具调用选择、观察反馈、多模型路由和预算分配；进一步研究 ReAct、Toolformer、PAL、Chain-of-Thought 等代表性技术的实际机制及其与运行时架构的区别；最后给出状态机、JSON 数据契约、可运行的 Python 最小控制器、测试方法和评估实验。贯穿案例是一个研究助理 Agent：用户提出框架技术选型问题，模型必须决定何时检索、何时计算、何时澄清、何时形成结论，且每一步都必须被系统记录和验证。

核心观点：模型为 Agent 提供可泛化的语义推断与行动提议能力；可靠的 Agent 能力则产生于模型推断、结构化协议、外部执行、状态管理和验证反馈的组合。

01 · Model 在 Agent 架构中的职责与边界

1.1 模型不是运行时

模型可理解为在给定输入条件下生成输出的推断组件。它可能被本地部署，也可能由远程服务提供；既可能是文本模型，也可能支持图像、音频或其他模态。Agent Runtime 则是一个持续的执行系统：它持有任务状态、决定调用时机、接收模型结果、校验工具参数、执行外部操作并记录结果。

用户目标 + 任务状态
        │
        ▼
Context Builder（[A4](./a4-context)） ──► Model Invocation
                              │
                    ┌─────────┴─────────┐
                    ▼                   ▼
                Final Answer       Action Proposal
                    │                   │
                    │                   ▼
                    │           Runtime Validation
                    │                   │
                    │                   ▼
                    │             Tool Execution
                    │                   │
                    │                   ▼
                    │              Observation
                    │                   │
                    └────► State Update ◄┘
                               │
                               └── 继续 / 终止

模型说“已查询数据库”并不能证明数据库被查询；模型生成合法 JSON 也不能证明其参数指向正确记录；模型建议停止也不等于任务达到验收标准。这些差异要求工程上把模型输出视为候选决策，而不是系统事实。

1.2 四层能力不可混淆

层次	可观测对象	测量方式	典型错误
模型潜在能力	特定测试条件下的答题、推理、编码能力	基准测试、受控样本	用公开榜单代替业务测评
单次调用表现	请求输入与模型输出	调用日志、结构与内容检查	将一次成功视为稳定表现
Agent 决策质量	行动类型、工具、参数与停止选择	决策标注、轨迹评审	将工具意图视为工具成功
任务完成质量	真实环境中的可验证结果	任务验收、外部状态核查	将流畅报告视为完成任务

这四层具有不同的失败来源。比如模型正确选择 search_documents，但工具不可用，属于执行层失败；模型选择 delete_file 来回答普通问答，则是决策层失败；模型选择正确工具但传入错误的文档 ID，属于参数构造失败。

1.3 模型在 Agent 中的六类工作

模型可参与任务语义理解、证据解释、候选推理、工具与行动选择、结果生成、反馈解释与策略修正。但“参与”不意味着每项职责都必须由模型独立完成：日期解析可以交给确定性程序，文档检索交给检索器，权限交给策略引擎，任务完成交给验收器。优秀架构的目标不是让模型包办全部操作，而是让模型处理最适合语义推断的部分。

02 · 一次模型调用在技术上如何运行

2.1 输入是请求快照，而不是 Agent 的全部世界

典型调用输入包含消息序列、可用工具规格、输出约束、模型标识、生成参数与可选多模态负载。它们被转换为模型可处理的内部表示；具体序列化和特殊标记由模型与提供商实现决定。运行时在调用前组装上下文，模型并不自动读取任务数据库、全部历史或外部网页。

{
  "model": "model-id",
  "messages": [
    {"role": "system", "content": "你是研究助理；缺少证据时先检索。"},
    {"role": "user", "content": "比较两个框架的恢复机制。"},
    {"role": "tool", "name": "search_docs", "content": "已找到两段官方说明"}
  ],
  "tools": [{"name": "search_docs", "input_schema": {"type": "object"}}],
  "generation": {"temperature": 0.2, "max_output_tokens": 1200}
}

此 JSON 是供应商无关的概念契约，不是任何单一 API 的准确请求格式。实际接入必须遵守所选 SDK 的字段定义和版本。

2.2 推断、解码与停止

自回归语言模型通常逐步预测下一个 token 的条件分布：

$$P(y\mid x)=\prod _{t=1}^{T}P(y_t\mid x,y_{<t})$$

其中 $x$ 是当前调用可见输入，$y_t$ 是第 $t$ 个输出 token。模型给出概率分布，解码策略将分布转成具体序列。temperature 改变 logits 的相对尖锐程度（在适用实现中，温度缩放形式为 $p_i\propto \exp (z_i/T)$）；top_p 通过累计概率截断候选；输出 token 上限限制单次响应长度。不同模型与服务可能采用不同采样、内部推理和参数支持方式，不应假设这些旋钮跨模型具有完全一致的效果。

在 Agent 中，解码影响的不仅是文风，也影响工具名、参数、动作顺序与停止决策的稳定性。较低温度可能减少部分随机波动，但不能保证事实正确、工具安全或 JSON 语义有效。结构化输出约束与运行时校验应单独设计。

2.3 三种终止原因

一次调用可能因为正常完成、输出长度限制、或产生工具调用而停止。运行时必须区别处理：正常完成可进入验收；长度截断通常需要标记不完整或受控续写；工具调用则应进入校验与执行路径。不能将任意非空文本都视为最终回答。

03 · 模型输出如何成为行动：结构化决策协议

3.1 从自由文本到判别联合类型

直接让模型输出“下一步做什么”的自然语言会造成歧义。更稳妥的方法是将结果约束为明确的决策类型：

Decision =
    Final(answer, evidence_ids)
  | ToolCall(tool_name, arguments, rationale_code)
  | Clarify(question)
  | Refuse(reason)

这是代数数据类型（sum type）的思想：每次决策必须属于一种明确分支，每个分支有自己的必需字段。它比一个拥有十几个可选字段的“大 JSON”更容易验证。

{
  "kind": "tool_call",
  "tool_name": "search_docs",
  "arguments": {"query": "checkpoint resume persistence"},
  "rationale_code": "missing_primary_source"
}

关键在于语法验证与语义验证分开。Schema 可以验证 query 是字符串，却不能判断该查询是否与任务有关；可以验证工具名属于允许集合，却不能判断当前用户是否授权执行该操作。

3.2 三道校验关口

1. 协议校验：JSON 是否可解析？分支字段是否齐全？是否存在未知工具？
2. 策略校验：该工具是否对当前角色和任务开放？是否超过调用预算？是否要求人工批准？
3. 前置条件校验：目标资源是否存在？参数是否符合业务约束？是否已经执行过等价操作？

校验失败应产生结构化错误反馈，而不是把未经检查的模型输出交给工具执行。尤其对写入、删除、付款、发布等副作用操作，必须由运行时执行硬性约束。

3.3 结构化生成的局限

约束解码可以限制生成结果符合某种形式语言或 Schema，但不能保证值的真实性。模型输出 {"confidence":0.99} 不意味着真实正确率为 99%；模型输出合法的 SQL 不意味着查询有正确的权限边界；模型输出存在的文档 ID 也不意味着它是本任务需要的文档。协议提高可执行性和可检查性，不自动提高事实性和授权正确性。

04 · 工具选择机制：模型究竟在选择什么

4.1 工具说明如何影响决策

模型通常从工具名称、描述、参数 Schema 和当前上下文中推断工具用途。例如 search_docs(query) 与 get_document(document_id) 分别对应“发现候选资料”和“读取已知资料”。如果两个工具描述含糊、能力重叠，模型可能反复选择错误工具。工具设计实际上改变了模型可用的行动空间。

任务目标
  ↓
候选动作集合 A(s)
  ↓
模型提出 action ∈ A(s)
  ↓
Runtime 检查 action 是否允许、是否可执行
  ↓
工具返回 observation
  ↓
更新状态 s → s'

这里的 $A(s)$ 是运行时根据当前状态筛出的允许动作集合。模型可以在其中提出候选，但不应被允许自行扩张权限集合。

4.2 何时不该使用模型选择

对于已经知道确定流程的场景，直接用代码路由更简单。例如“收到文件后先校验扩展名，再计算 SHA-256”，不需要模型决定下一步；“输入 invoice_id 就调用精确数据库查询”，也不需要让模型从十几个工具中猜测。模型路由适用于语义意图开放、策略需要灵活调整的环节，而不是替代所有条件分支。

4.3 工具结果如何反馈

工具观察必须带上调用 ID、状态、数据、错误类别和可重试性：

{
  "call_id": "c-018",
  "tool": "search_docs",
  "status": "error",
  "error": {"code": "RATE_LIMIT", "retryable": true},
  "elapsed_ms": 320
}

运行时应先根据确定性错误码处理退避和重试，再决定是否需要模型重新规划。把“429 限流”原样交给模型，让模型任意重复调用，容易形成无效循环。

05 · 推理策略：为什么更长的思考不总是更好

5.1 内部推理与外部可见轨迹

需要区分模型内部推断过程、模型可见的解释文本，以及 Agent 的外部行动轨迹。工程系统通常能够可靠记录的是输入、工具选择、工具结果、最终输出和状态变化；不应假设可以读取或验证模型全部内部推理。某些模型提供不同的推理预算或推理模式，但接口、计费和可见性因服务而异。

5.2 Chain-of-Thought 的启发与边界

Wei 等人的 Chain-of-Thought Prompting 研究表明，在一定模型与任务条件下，中间推理示例可提升复杂问题求解表现。但生成中间步骤不等于正确推理：步骤可能包含错误，模型也可能事后构造看似合理的解释。对 Agent 的直接启发是：把复杂任务拆为可验证的中间产物，而非仅追求更长的文字思考。

例如技术比较任务可以拆成：待核验问题 → 原始证据 → 能力矩阵 → 条件分析 → 选型建议。每个阶段的输出都能被独立检查，比一段长篇“思考过程”更容易审计。

5.3 PAL：把计算交给程序

Program-Aided Language Models（PAL）研究强调让模型生成程序，再通过解释器完成精确计算。其机制不是模型直接“想出”数值，而是把问题转化为程序表达：

自然语言计算任务
   ↓
模型生成受约束的程序
   ↓
静态检查 / 沙箱执行
   ↓
得到计算结果
   ↓
模型解释结果

例如比较两个方案的月成本，模型可以生成公式或受限表达式，实际数值由确定性计算器执行。此法能够减少某些算术错误，但代码生成错误、单位混淆和输入错误仍需检查。执行模型生成的任意代码存在风险，应采用隔离环境、资源限制和白名单能力。

5.4 推理预算分配

不是所有步骤都值得使用同等昂贵的模型调用。可将问题按复杂度、错误代价和可验证性分类：简单字段抽取使用低成本模型或规则；多文档冲突解释使用更强模型；关键结论增加独立验证。预算分配应由任务价值与失败代价决定，而不是机械地“所有调用使用最强模型”。

06 · 代表性研究：ReAct 如何组织推理与行动

ReAct（Yao 等，2022/2023）研究将语言推理与环境行动交替结合。与纯文本推理不同，模型可通过行动获得新的外部观察；与不含推理的行动策略不同，模型可依据中间解释调整行动。

状态 s0：需要确认框架的持久化条件
  ├─ Reason：缺少官方证据
  ├─ Act：search_docs("persistence backend")
  └─ Observe：发现存储配置章节
状态 s1：已知持久化方式，仍不清楚恢复边界
  ├─ Reason：需要定位恢复语义
  ├─ Act：get_document("resume-section")
  └─ Observe：获得恢复条件
状态 s2：证据足够 → 输出有条件结论

机制重点：观察改变后续决策所依赖的信息；动作空间通过工具接口受到约束；行动轨迹可被运行时记录。ReAct 本身不自动解决权限控制、持久状态、来源真实性和副作用幂等性。工程中可以采用其“推断-行动-观察”组织思想，而不声称复现论文的全部提示设计或实验条件。

07 · 代表性研究：Toolformer 与工具使用能力的形成

Toolformer（Schick 等，2023）探索模型如何通过自监督方式学习使用外部 API。其核心研究问题不是“如何给模型写一个工具说明”，而是模型能否学习在文本中的哪些位置插入 API 调用、传入什么参数，以及如何利用返回值。论文方法涉及生成候选 API 调用，并通过其对语言建模损失的影响筛选有益调用示例，用于进一步训练。

这与普通 Agent 的提示式工具调用有根本区别：提示式调用主要依赖已有模型能力和工具描述；Toolformer 研究的是工具使用行为如何进入模型的学习过程。两者可以形成互补，但不能将“给模型提供 JSON Schema”称为 Toolformer 训练。

对系统设计的启发是：工具选择质量既受模型训练能力影响，也受工具说明、参数契约和反馈质量影响。若模型频繁误用某类工具，可能需要改进工具接口、提供针对性示例或更换模型，而不只是增加“请谨慎使用工具”的提示。

08 · 代表性研究：函数调用、约束解码与验证器

现代模型服务常提供函数调用或结构化输出能力。需要拆开三种机制：

• 提示式格式遵循：要求模型输出 JSON，但输出仍可能不合法。
• 受约束解码：通过语法或 Schema 限制可生成 token，使结构更稳定；具体支持范围因实现而异。
• 运行时验证：对输出执行类型、枚举、业务规则和授权检查，即使格式正确也可能拒绝执行。

例如 send_email(recipient, body) 即使在 Schema 上完全合法，也需要检查收件人是否被明确授权、正文是否包含禁止外发的数据，以及是否已通过必要确认。模型的“我认为可以发送”不是授权依据。

在 Agent 内部，工具调用可以被视为一种模型-运行时通信协议，而不是模型直接执行函数。这个边界是多模型替换、审计和安全控制的基础。

09 · 模型选择：从任务画像到可测量决策

9.1 不要只按模型榜单选型

模型选型首先建立任务画像：输入模态、上下文长度、需要的工具调用能力、结构化输出稳定性、语言能力、延迟约束、数据处理边界、单位成本和目标错误率。对于研究 Agent，还要关注多文档证据整合、拒绝无证据结论、长任务中工具选择稳定性。

任务子类型	关键能力	更重要的评估
资料分类	标签理解、结构遵循	Macro-F1、成本
证据抽取	精确定位、原文忠实度	字段准确率、证据回链
检索策略	问题分解、工具选择	有效调用率、遗漏率
技术比较	多来源综合、条件推理	事实支持率、重大错误率
最终写作	组织表达、约束遵循	人工修改量、完整性

9.2 一个具体的模型能力测试集

为同一业务任务构造样本：已知证据足够、缺少关键证据、存在版本冲突、工具不可用、用户要求越权、输出长度不足。每个样本标注正确动作类型而不仅是正确答案。例如“缺少官方来源”样本的正确动作可能是 tool_call(search_docs)，而非编造结论。这样才能测试模型是否适合作为 Agent 决策组件。

9.3 避免污染评估

如果测试题及其答案已被模型见过，离线分数可能偏高。应使用项目特有、时间敏感、可人工核验的隐藏任务集；定期更换部分样本；记录模型版本与提示版本。跨模型比较必须保持工具规格、证据集和预算尽可能一致。

10 · 多模型路由：算法、数据结构与代价

10.1 三种基本架构

单模型：一个模型完成全部语义步骤。优点是集成简单，缺点是成本和能力配置不够细粒度。静态路由：按任务类型选择模型，例如抽取使用小模型、复杂比较使用大模型。动态路由：根据问题难度、失败风险和前次结果调整模型选择。动态路由更灵活，但引入路由误差和额外评估成本。

10.2 成本敏感路由目标

一种概念性的路由目标是：

$$m^{\ast }=\arg \underset{m\in M}{min}(C_m(x)+\lambda L_m(x))$$

其中 $C_m(x)$ 是任务 $x$ 使用模型 $m$ 的预期成本，$L_m(x)$ 是预期错误损失，$\lambda$ 表示错误代价权重。这个表达式是本文的工程抽象，不是特定论文的精确算法。真正的难点在于估计 $L_m(x)$：模型自报信心往往不可靠，需要历史标注数据、任务特征与在线反馈。

10.3 路由器的最小数据契约

{
  "task_type": "evidence_synthesis",
  "risk_level": "high",
  "input_tokens_estimate": 8000,
  "requires_tools": true,
  "requires_multimodal": false,
  "deadline_ms": 12000,
  "model_candidates": ["small", "large"]
}

路由器输出模型选择与理由码，运行时记录真实 token 使用量、耗时、失败类型和最终质量，以便调整策略。若高成本模型也无法解决缺失证据问题，正确动作应是检索或澄清，而不是继续升级模型。

10.4 级联与回退

常见级联策略是先用低成本模型执行，只有在结构校验失败、证据不足或独立验证器发现问题时，才升级到更强模型。应避免仅凭模型说“我不确定”决定升级；对高风险任务，使用确定性规则与外部证据检查更稳妥。回退模型的工具接口能力可能不同，必须重新检查兼容性。

11 · 运行时状态机：模型调用与 Agent 执行如何衔接

建议把 Agent 的模型交互定义为显式状态机：

READY
  ↓
BUILD_REQUEST
  ↓
MODEL_PENDING
  ↓
PARSE_DECISION
  ├─ invalid ──► FEEDBACK / RETRY_LIMIT
  ├─ tool_call ──► VALIDATE_TOOL ──► EXECUTE ──► OBSERVE ──┐
  ├─ clarify ──► WAIT_USER                                 │
  ├─ refuse ──► STOP                                       │
  └─ final ──► VERIFY_RESULT ──► DONE / REPLAN             │
                 ▲                                         │
                 └─────────────────────────────────────────┘

状态转换必须可观察。推荐事件记录字段：task_id、step_id、model_id、prompt_version、request_hash、decision_kind、tool_call_id、tool_status、usage、latency_ms、validation_errors、state_version。避免在日志中无差别保存敏感上下文；需要根据实际数据策略决定记录原文、脱敏摘要或哈希。

失败分类必须具体：解析失败属于协议问题；工具 404 属于资源问题；工具 429 属于速率限制；工具成功但结果不相关属于检索或决策问题；最终报告没有证据支持属于知识利用问题。不同问题采用不同恢复机制。

12 · 最小可运行实现：模拟模型、验证决策、执行工具

下面的代码只使用 Python 标准库，展示真实的控制流和数据结构，不调用真实模型。它刻意将模型抽象为 ModelPort，使未来可以接入不同提供商。这个示例验证的不是模型本身的智能程度，而是“模型提出动作-运行时验证-工具执行-状态更新”的机制。

from __future__ import annotations

from dataclasses import dataclass, field
from typing import Any, Dict, List, Optional, Protocol, Tuple

@dataclass
class ToolCall:
    name: str
    arguments: Dict[str, Any]

@dataclass
class Decision:
    kind: str  # tool_call | final | clarify
    tool_call: Optional[ToolCall] = None
    answer: Optional[str] = None

@dataclass
class State:
    question: str
    observations: List[str] = field(default_factory=list)
    tool_calls: int = 0
    finished: bool = False

class ModelPort(Protocol):
    def decide(self, state: State) -> Decision: ...

class MockModel:
    def decide(self, state: State) -> Decision:
        if not state.observations:
            return Decision("tool_call", ToolCall("search_docs", {"query": state.question}))
        return Decision("final", answer="根据已检索材料：" + state.observations[-1])

class Runtime:
    def __init__(self, model: ModelPort, max_calls: int = 3):
        self.model = model
        self.max_calls = max_calls
        self.allowed_tools = {"search_docs"}

    def execute_tool(self, call: ToolCall) -> str:
        if call.name not in self.allowed_tools:
            raise ValueError("tool not allowed")
        query = call.arguments.get("query")
        if not isinstance(query, str) or not query.strip():
            raise ValueError("query must be non-empty string")
        # 模拟检索：生产系统应替换为真实检索器，并保留来源元数据。
        return f"模拟文档：检索主题={query}；尚未核验事实"

    def run(self, question: str) -> Tuple[State, str]:
        state = State(question=question)
        while state.tool_calls <= self.max_calls:
            decision = self.model.decide(state)
            if decision.kind == "tool_call":
                if decision.tool_call is None:
                    raise ValueError("missing tool_call")
                if state.tool_calls >= self.max_calls:
                    return state, "停止：工具调用预算耗尽"
                observation = self.execute_tool(decision.tool_call)
                state.observations.append(observation)
                state.tool_calls += 1
            elif decision.kind == "final":
                if not isinstance(decision.answer, str):
                    raise ValueError("missing final answer")
                state.finished = True
                return state, decision.answer
            elif decision.kind == "clarify":
                return state, "需要用户补充信息"
            else:
                raise ValueError("unknown decision kind")
        return state, "停止：达到循环上限"

if __name__ == "__main__":
    state, result = Runtime(MockModel()).run("比较框架的持久化机制")
    assert state.tool_calls == 1
    assert state.finished is True
    assert "尚未核验事实" in result
    print(result)

12.1 示例实际证明什么

它证明运行时能够区分 tool_call 与 final，拒绝未知工具和无效参数，限制工具调用次数，并将观察反馈给下一次模型决策。它不能证明模拟检索结果真实、模型能够正确选择工具，也不能证明最终答案满足研究任务要求。尤其代码中的 MockModel 故意将“尚未核验事实”写入回答，用来提醒：控制循环正常运行与知识可靠是两个不同层次。

12.2 从示例到生产系统需要补什么

至少需要：真实 SDK 适配器、结构化响应解析、任务持久化、调用幂等键、工具超时与取消、重试退避、来源引用、最终验收器、可观测性以及数据访问控制。对于带副作用的工具，还需要审批和事务/补偿设计。每一项都应有对应的集成测试，而不能仅靠模型提示实现。

13 · 模型错误的机制与诊断

13.1 事实幻觉与证据越界

模型可能在没有足够证据时补全似是而非的细节，或将“某版本支持”概括为“所有版本都支持”。治理这类问题，最有效的入口通常不是增加笼统的“不要幻觉”提示，而是把结论拆成可核查的 Claim，并检查每个 Claim 是否有直接证据（详见 A6）。

13.2 工具选择错误

错误可能来自工具描述重叠、任务状态不完整、模型能力不足或动作空间过大。诊断时记录：模型可见工具集合、用户任务、选择的工具、期望工具、参数差异。先排除接口与上下文问题，再考虑更换模型。

13.3 长上下文信息使用失败

模型即使能够接收较长上下文，也不保证均匀利用其中信息。重要条件可能被忽略，互相冲突的片段可能被混合。应通过证据选择、位置敏感测试和上下文压缩实验评估（详见 A4），不能把“窗口够大”当作“理解可靠”。

13.4 反复调用与无效循环

模型在工具错误后可能重复同一动作，或在证据已经充分时继续检索。运行时应维护已执行动作的指纹、失败计数和预算，阻止没有新增信息的重复调用；模型负责解释反馈，运行时负责强制终止条件。

14 · 评估设计：如何判断模型真的提升了 Agent

14.1 分层指标

层级	指标	样本标注要求
调用协议	Schema 合法率、拒绝率、截断率	合法字段与必需字段
行动决策	工具选择准确率、参数正确率、停止准确率	每步允许动作集合
知识使用	证据支持率、条件遗漏率	原文证据与主张对应
运行控制	失败恢复率、重复调用率	错误类型与预期处理
端到端	任务成功率、人工返工量、耗时与成本	可验证验收标准

14.2 三组对照实验

实验 A：模型能力与上下文能力分离。 固定模型，比较完整证据、部分证据和无证据三种输入。观察模型是否恰当地检索、澄清或拒绝断言。若无证据时仍高置信输出，说明需要改善决策与验证机制。

实验 B：单模型与路由策略。 使用同一任务集比较统一强模型、静态路由和动态级联。记录质量、token 成本、延迟分布和回退率。不要只比较平均成本，应特别观察复杂任务是否因错误路由产生重大失败。

实验 C：自由文本与结构化决策。 固定模型与任务，比较自由文本动作描述、JSON 提示式输出、支持时的约束结构化输出。分别记录解析错误、语义参数错误和任务成功率，避免将格式改善误判为推理改善。

14.3 错误归因方法

一条失败轨迹应按时间顺序记录“输入是否足够 → 模型是否选对动作 → 参数是否正确 → 工具是否成功 → 观察是否进入后续上下文 → 最终结论是否被证据支持”。这种归因能够指导改进位置：可能是模型、工具说明、Context 装配、Knowledge 检索或运行时，而非一概归因于“模型不够强”。

15 · 模型能力、系统能力与工程取舍

15.1 模型越强，不一定系统越好

更强模型可能改善复杂语义判断，但如果瓶颈是检索不到原始资料、工具权限不足或状态没有持久化，更换模型无法解决根因。工程投入应根据失败归因分配，而不是将全部问题转化为模型升级。

15.2 何时值得使用多模型

当任务具有明显的难度分层、不同模型能力差异可测量、调用规模足够大且路由维护成本可接受时，多模型路由可能带来收益。若任务量小、质量要求高度一致或模型切换带来复杂的接口兼容问题，单模型可能更合适。

15.3 何时需要人工参与

高风险操作、证据冲突严重、用户意图不明确、输出将直接影响现实资源时，模型可以整理可供判断的材料，但不应自动替代授权与责任主体。人工审核应设计成明确的状态转换和确认记录，而不是在提示词里写一句“请人工检查”。

16 · 研究助理 Agent：贯穿案例的完整调用轨迹

用户任务：“比较两种 Agent 框架的长任务恢复能力，并推荐适合研究 Studio 的方案。”

步骤 1：模型理解。 从任务中提取对象、比较维度与输出要求，识别“长任务恢复”存在歧义。若框架版本缺失且影响结论，应请求澄清或在报告中限定版本。

步骤 2：知识需求判断。 模型提出需要检查持久化后端、人工中断、故障恢复、工具副作用四类证据。Knowledge 模块将它们记录为待核验问题。

步骤 3：模型选择工具。 模型输出 search_docs 的结构化调用。运行时检查工具在允许列表、查询合法、预算充足，才真正执行。

步骤 4：观察与再决策。 工具返回官方文档摘要及定位信息。模型发现“支持 checkpoint”不足以证明“所有外部副作用恰好执行一次”，于是针对副作用处理补充检索。

步骤 5：计算与比较。 若需比较成本或吞吐量，模型提出公式，确定性计算工具返回结果；模型负责解释其对架构选择的意义。

步骤 6：结论验收。 模型生成比较表与建议；验收器检查每个关键能力结论是否关联证据、条件是否完整、未验证项目是否被明确标注。未通过则返回修订，而非直接发布。

任务 → 模型提出知识需求 → 运行时执行检索 → 获得证据
  → 模型发现新缺口 → 再检索 → 结构化比较
  → 验证器检查结论 → 交付 / 修订

这一轨迹说明 Model 的核心价值在于将新观察转化为下一步有意义的判断；执行事实与证据可信度则必须由其他组件共同保证。

17 · 技术选型与实施路线

建议从最小可观测系统开始，而非直接构建复杂的多模型自治网络。第一阶段确定单一模型、四种决策分支和两个只读工具，建立调用日志与决策测试集。第二阶段接入真实检索和证据回链，增加结果验收器。第三阶段根据失败数据引入模型路由、级联和专门验证模型。第四阶段在实际任务中进行对照实验，只有当新增复杂度能显著改善目标指标时才保留。

实施过程中要固定三类版本：模型版本、提示/指令版本、工具契约版本。同一模型在不同上下文、工具说明和参数下表现可能差异很大；缺少版本记录的线上效果比较很难得出可信结论。

18 · 核心结论

1. 模型为 Agent 提供语义理解、候选推理、行动提议和结果生成能力，但它不自动执行外部动作，也不保证事实和授权正确。
2. 一次模型调用是基于当前输入快照的推断；Context 装配和任务状态管理决定模型能够看到什么，而不由模型自动完成。
3. 结构化决策协议应采用明确的动作分支，并区分协议、策略与业务前置条件三类校验。
4. ReAct 展示推理与观察交替的控制思想；Toolformer 研究工具使用行为的学习机制；PAL 展示将可执行计算外包给程序的路径。它们解决的是不同层次的问题。
5. 多模型路由需要以业务任务集评估预期质量与成本，不应依赖模型榜单或模型自报信心。
6. Agent 的可靠性来自模型与运行时、工具、证据和验证机制的共同设计；必须通过行动轨迹和端到端验收衡量，而不能只评价最终文本。

参考研究与延伸阅读

以下列出与本文机制直接相关的原始研究及官方资源。链接供进一步核验；本次修订没有逐项在线核验最新版内容。

1. Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models（2022/ICLR 2023）- https://arxiv.org/abs/2210.03629 。用于理解推理-行动-观察的交替机制。
2. Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools（2023）- https://arxiv.org/abs/2302.04761 。用于理解工具调用数据的自监督构造与学习。
3. Wei et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（2022）- https://arxiv.org/abs/2201.11903 。用于理解中间推理示例的研究背景与条件。
4. Gao et al. PAL: Program-aided Language Models（2022/2023）- https://arxiv.org/abs/2211.10435 。用于理解语言模型与程序执行的职责分离。
5. Wang et al. Self-Consistency Improves Chain of Thought Reasoning in Language Models（2022/2023）- https://arxiv.org/abs/2203.11171 。用于理解多路径采样与答案聚合；增加采样成本且不保证事实正确。
6. Chen et al. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance（2023）- https://arxiv.org/abs/2305.05176 。用于理解模型级联与成本优化的研究思路。
7. OpenAI Platform 文档（模型调用、工具调用、结构化输出；实际字段与能力以现行版本为准）- https://platform.openai.com/docs/ 。
8. Anthropic 文档（工具使用、模型能力与提示工程；实际字段与能力以现行版本为准）- https://docs.anthropic.com/ 。
9. OpenAI. A Practical Guide to Building Agents（Agent 组成与工程实践）- https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/ 。
10. Anthropic. Building Effective Agents（工作流与 Agent 设计）- https://www.anthropic.com/engineering/building-effective-agents 。

研究声明

研究与验证说明

本篇基于原 A2 v1.0 的研究定位与结构重写，深化了模型推断边界、结构化决策、工具使用机制、推理策略、模型路由和运行时状态机。文中 Decision 联合类型、状态机、路由目标函数及最小控制器为本文提出的参考工程抽象，不应视为特定论文或供应商的标准实现。

最新性状态

更新日期为 2026 年 10 月 28 日。本次未在线逐项核验模型服务最新 API、定价、参数支持或论文修订版本。具体接入与技术选型应以实际使用时的官方文档和受控测试为准。

实验与适用边界

第 12 节是无需真实模型服务的标准库模拟实现，用于验证控制流、工具校验与状态转换；它不测量真实模型推理质量。本文未开展真实模型 API 对照实验、延迟基准或业务成功率测试；相关评估设计属于待实施方案。对生产系统，必须增加真实集成、证据验证、权限控制与故障注入测试。