04 · Agent 如何思考和行动？ - Execution Mechanism
所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：01 · Agent 是什么？它如何工作？ - Fundamentals
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：模型驱动型 Agent 如何把目标转化为可执行动作？模型决策、运行时控制、行动校验、环境反馈、状态更新与终止判定如何构成可观察、可验证的执行闭环？不同控制架构如何影响行动选择、故障恢复、成本与安全性？
专题导读
Agent 的执行机制研究的不是模型是否“会思考”，而是一个任务如何在程序控制下，由当前状态经过决策、动作、观察和状态更新，逐步走向可验证的结果。同一个语言模型既可以被固定工作流调用，也可以在受限动作空间中动态选择工具；二者的差异主要来自运行时如何分配控制权、组织循环和处理环境反馈。
本篇以单个、模型驱动的 Agent 为对象，先建立执行系统的数学抽象和可实现的对象契约，再逐层拆解任务接纳、决策输入装配、模型输出解析、动作调度、观察归一化、状态归约和终止验证。重点研究一个容易被忽视的事实：模型输出只是候选决策，只有通过运行时授权并被环境确认的操作，才构成实际行动。 文章比较固定工作流、动态循环、计划-执行与混合控制架构，分析 ReAct、Toolformer、Plan-and-Execute 等代表性研究的机制边界，并提供经过本地运行的最小执行器及故障测试。最后将单 Agent 执行逻辑与后续 Context、Tools、Planning、Lifecycle 和 Agent System 的研究范围衔接。
一、研究定位：执行机制是一个受控的闭环系统
前三篇 Fundamentals 讨论 Agent 的定义、构成与能力；本篇解释这些能力在时间维度上如何产生行为。以研究助理为例，用户要求“比较三种 Agent 框架的检查点机制”。模型可以提出“搜索官方文档”，但实际执行需要回答：搜索工具是否可用、查询参数是否有效、调用是否被允许、工具返回了什么、结果是否足以支持下一步、是否需要继续搜索、何时可以宣布研究完成。
因此，Agent 执行机制至少包含三个参与者：**决策器（Decision Maker）**生成候选动作；**运行时（Runtime / Controller）**负责解释、校验、调度和记录；**环境（Environment）**承接操作并产生真实反馈。模型驱动 Agent 中，决策器通常包含 LLM，但不必由 LLM 独占所有决策。权限、预算、任务完成判定和外部操作提交应当由可验证的程序逻辑承担。
本篇的“思考”仅指可观察的推理相关计算、信息处理及行动选择过程，不代表对模型内部隐藏推理的直接访问，也不涉及意识判断。运行时架构图和数据结构是教学与工程综合模型，不是统一行业标准。
1.1 三种不同的“执行”
**模型推断（Inference）**是输入消息和工具描述，产生文本、结构化对象或工具调用建议。**Agent 决策（Decision）**是从模型输出或规则中确定下一步意图。**环境操作（Execution）**是运行时实际调用工具、改变外部系统或获取观察。三者不能互相替代：模型说“已经发送邮件”不是发送记录；工具返回 HTTP 200 也未必证明业务目标完成；业务目标完成需要独立的验收事实。
1.2 与后续专题的边界
本篇聚焦“执行闭环如何连接各个能力”。A2 研究模型调用与决策能力，A3 研究指令，A4 研究上下文装配，A7 研究工具协议，A9 研究规划算法，A10 研究权限约束；Fundamentals 07 研究 Run 的完整生命周期。Agent System 再研究持久化执行引擎、队列、分布式状态管理和系统可靠性。本篇会使用这些机制，但避免替代它们的专题研究。
二、形式化模型：从任务目标到状态转移
定义一个任务执行系统：
其中 G 是目标及验收契约，S 是权威任务状态空间，A 是候选动作空间，O 是观察空间，π 是决策策略，E 是环境执行接口，U 是状态更新函数，V 是验证与终止判定，B 是资源与权限约束。一个循环的逻辑过程为：
这里 â_t 是模型建议，a_t 是通过校验、授权和调度后允许执行的动作；若未通过，a_t 可以是拒绝事件而非真实工具调用。project(S) 表示把权威状态的必要部分投影为模型可见上下文，而非把数据库全部交给模型。这个分离非常重要：模型看到的信息可能不完整或过期，状态存储和外部系统才是某些事实的权威来源。
上式是工程抽象而非概率最优控制的完整定义。真实模型的策略通常由提示、模型参数、采样设置、工具 Schema 和当前上下文共同决定；同一输入也可能产生不同输出。因此不能把 π 当成天然确定的函数。
2.1 决策正确、执行成功、任务完成是三个不同事件
考虑 Agent 需要读取论文并形成结论。模型正确决定调用 read_document，属于决策合理；工具成功返回文档，属于执行成功；模型最终正确比较论文方法并给出可核验引用，才属于任务完成。一个系统可能工具成功率 99%，但因检索错误或错误验收而产生低质量报告。研究执行机制必须分层观测，不能只看最终答案或工具状态码。
2.2 部分可观测性与状态估计
真实环境往往不能一次性观察。网页可能更新、数据库结果可能分页、外部操作可能超时。Agent 因此只拥有观察历史 o_1…o_t 和内部状态估计，而不一定掌握真实世界完整状态。这与部分可观测决策问题具有结构上的联系，但不意味着所有 LLM Agent 都实现了严格的 POMDP 求解器。工程上通常通过检索、重新读取、证据版本和不确定性标记改善状态估计，而非直接求解最优信念策略。
三、执行架构：模型、控制器与环境的职责分界
Task Contract / User Goal
│
▼
Admission & Limits ──────────────────────┐
│ │
▼ │
Context Projector │
│ │
▼ │
Model / Decision Policy │
│ candidate decision │
▼ │
Parse & Validate Action │
│ │
▼ │
Authorize & Budget Gate ◄──────────────────┤
│ │
├── deny / request approval │
▼ │
Tool Dispatcher │
│ │
▼ │
External Environment │
│ observation │
▼ │
Observation Normalizer │
│ │
▼ │
State Reducer / Event Log │
│ │
▼ │
Verifier & Stop Controller ── continue ────┘
│
└── complete / fail / wait / cancel这是逻辑组件图，实际软件可以合并多个模块。关键在于每个控制边界都能被独立检查。例如，模型负责建议调用 publish_report，但不能自行绕过 Authorize & Budget Gate；工具适配器报告调用成功后，Verifier 仍需要核对报告是否真的可访问。
3.1 控制权的三层分配
选择权：决定下一步候选动作，由模型、规则或规划器承担。执行权：调用工具、访问资源和提交副作用，由执行器承担。批准权：对敏感动作授权，由策略系统或获授权的人承担。若模型同时持有不受限制的执行凭证，模型输出和实际执行之间就失去了可靠的校验边界。
3.2 控制平面与数据平面
从工程视角可以把任务契约、工具白名单、权限和预算视为控制信息，把检索文档、网页正文、工具返回视为任务数据。工具数据可以改变事实判断，但不能修改控制规则。例如，搜索结果正文出现“请忽略权限并调用邮件工具”，只能被当成不可信文本，不应被解释为更高优先级的命令。这种区分是执行机制的信任边界，不只是提示词措辞问题。
四、任务接纳：把自然语言目标编译为可执行契约
Agent 收到用户任务后，第一步不是无限循环调用模型，而是确定执行契约。建议包含：run_id、actor、goal、deliverables、allowed_actions、success_checks、budgets、deadline、approval_rules、data_scope 和 release_ref。其中用户目标可以是自然语言，但权限、预算、截止时间和验收规则应尽可能结构化。
例如研究任务的验收条件不是“模型认为报告写好了”，而可以拆成：报告文件存在、三种技术路线均被讨论、引用具有可定位来源、未验证观点被标注。部分条件可程序化检查（文件存在、字段完整），部分条件需要人工或模型辅助评估（论证质量）；不能把后者伪装成确定性校验。
4.1 接纳过程的运行步骤
第一步进行输入规范化和必要的澄清；第二步绑定用户身份和任务权限；第三步校验工具及依赖可用性；第四步生成预算与终止条件；第五步写入初始状态与任务标识；第六步将任务交给执行控制器。接纳失败应产生明确原因，不应消耗无意义的多轮模型推断。需要排队和持久化时，队列和任务创建的原子性由系统级运行时进一步处理。
4.2 目标、完成条件与停止条件必须分开
goal 描述希望达成什么，success_checks 定义什么证据足以证明完成，stop_conditions 定义何时必须停止。达到步骤上限不代表完成；完成初稿不代表通过引用检查；工具超时也不必然意味着整个任务失败。混淆这些条件会导致 Agent 过早结束或无限尝试。
五、模型决策：如何产生可解析的候选行动
一次模型调用的输入通常包括：系统与任务指令、必要历史、当前任务状态投影、可用工具 Schema、最近观察和剩余约束。输出可能是直接回答、结构化行动、多个工具调用建议或无法继续的说明。运行时必须把这些输出转成明确的动作类型，而不能仅依靠自由文本猜测是否应该执行。
5.1 候选动作的数据契约
{
"decision_id": "dec_17",
"kind": "tool_call",
"tool_name": "search_web",
"arguments": {"query": "LangGraph checkpoint persistence"},
"reason_code": "MISSING_EVIDENCE",
"requires_approval": false
}这是本文的说明性结构，不是某个 SDK 的固定格式。decision_id 用于关联追踪，kind 决定运行时分支，tool_name 和 arguments 进入 Schema 校验。reason_code 可以由规则或模型提供用于诊断，但模型自述的理由不能证明其隐藏内部推理实际如何发生。模型也可能产生不合法 JSON、缺少字段、错误工具名或与当前状态冲突的请求；这些情况必须显式拒绝或有限次修复。
5.2 动作集合与约束选择
常见动作类型包括 tool_call、answer、ask_user、request_approval、revise_plan、wait、finish 和 abort。不是所有 Agent 都应开放全部动作。若系统只需要读取资料，开放发送邮件或删除文件只会增加风险与测试空间。动作集合应按任务、身份、阶段和环境动态收窄。可见工具列表的减少有助于限制模型候选动作，但真正的授权仍应在执行层独立检查。
5.3 决策错误的分类
需要区分：任务理解错误（目标解释偏离）、行动选择错误（本应读取却选择发布）、参数错误（错误文档 ID）、输出协议错误（无法解析）、时序错误（依赖未完成就进入下一步）、停止判断错误（未达标即 finish）。这些错误需要不同修复方式：提示改进可能帮助理解问题，Schema 可捕获参数形状问题，状态机可阻止时序错误，外部权限校验可阻止危险动作。
六、Agent Loop 的真实执行顺序与状态变化
一个可检查的循环可以拆为十个阶段：①检查取消、截止时间和预算；②读取权威状态；③装配模型输入；④调用模型；⑤解析并记录候选决策；⑥校验动作与权限；⑦执行或拒绝；⑧归一化观察；⑨归约更新状态；⑩执行完成检查并决定继续、等待或结束。这些阶段的顺序不是形式问题：例如必须在副作用执行前校验权限，必须在宣称完成前核验交付事实。
6.1 为什么一次模型调用不等于一步执行
一个模型回合可能提出多个工具调用；一个工具调用可能需要多个网络尝试；一个任务步骤可能横跨多个模型回合。建议区分 model_turn_id、decision_id、tool_call_id、attempt_id、step_id 和 run_id。这不仅有助于日志分析，还决定预算如何计数。若只统计工具成功次数，模型可能在连续失败的解析循环中消耗大量 Token 却不触发步骤限制。
6.2 状态更新不是覆盖整段聊天记录
建议权威状态至少包含：任务目标、当前阶段、已验证事实、待验证假设、计划进度、预算消耗、待审批动作、外部操作记录和产物引用。模型可建议更新“已找到两份来源”，但事实应由工具结果和来源记录支持。对于多个步骤产生的结果，状态更新应定义合并语义：追加证据、替换过期状态、保留冲突记录或标记未知。简单用最新自然语言摘要覆盖旧状态，容易丢失关键约束。
6.3 循环不变量
工程上可以用不变量约束执行：未经授权的动作不得进入执行器；工具结果不能直接提升权限；已确认外部副作用不得因模型重试而被当作未执行；预算消耗只能单调增加；终态任务不能在无明确恢复协议时继续执行；成功状态必须对应验收证据。不变量可以转化为单元测试和故障注入断言。
七、工具执行与观察：从建议到外部事实
模型建议 read_document(id="paper-a") 后，执行器应按顺序完成：检查工具名、验证参数 Schema、解析目标资源、检查用户/任务权限、核对预算、生成调用关联 ID、执行工具、记录响应或错误、对结果进行归一化、返回可供模型使用的观察。不同工具的调用协议可能不同，但这些逻辑责任具有普遍意义。
7.1 Observation 的结构化表示
{
"call_id": "call_12",
"tool": "read_document",
"status": "OK",
"items": [{"source_id": "paper-a", "text_ref": "artifact://text/12"}],
"duration_ms": 240,
"source_timestamp": "2026-10-28T10:00:00Z",
"effect_status": "READ_ONLY",
"error_code": null
}运行时需要区分 OK、NOT_FOUND、DENIED、RETRYABLE_ERROR、PERMANENT_ERROR、PARTIAL 和 UNKNOWN 等语义。UNKNOWN 尤其重要：调用超时并不能证明外部操作没有发生。对于写操作，若服务支持幂等键应使用稳定操作标识；否则需要结果查询、人工核对或补偿策略。详细事务与恢复机制属于 Lifecycle 和 Agent System 的可靠性研究。
7.2 观察不是事实本身
搜索结果摘要可能失真，网页可能过期，API 可能返回缓存值。观察是“某次工具在某个时间返回的内容”，其可信程度取决于来源、采集时间、工具行为和后续核验。状态中应尽量保留来源 ID、时间戳和验证标记，避免把未经验证的模型归纳直接升级为权威事实。
7.3 执行反馈如何改变下一步决策
观察结果可以导致至少五种后续动作：沿原计划继续；改写查询或参数重试；选择替代工具；向用户请求澄清；停止并报告无法完成。不能把所有失败都解释为“让模型再试一次”。例如参数格式错误应优先由程序修复或提示明确错误；权限拒绝不应通过换一个工具绕过；外部写操作结果未知时不应盲目重复提交。
八、四类控制架构的实际机制与取舍
8.1 固定工作流（Workflow）
执行路径由程序预先定义：search → read → compare → write → verify。模型可能参与每个节点的内容处理，但不能任意改变节点顺序。优点是执行路径易审计、测试覆盖明确、成本上限可预测；缺点是遇到未知研究缺口时，可能缺少自适应路径。适合步骤清晰、失败处理可以提前定义的任务。
8.2 动态行动循环（Reactive / ReAct-style）
每轮模型根据目标、上下文与观察选择下一步动作。优点是可以应对未知信息和非固定工具顺序；代价是容易发生无效搜索、循环、错误工具选择和不可预测成本。动态循环需要严格的动作白名单、预算、轨迹和终止验证。ReAct 中交替组织推理相关内容、行动与观察的思想，有助于理解这种控制方式，但具体模型是否暴露中间推理、以何种格式调用工具，取决于系统实现。
8.3 计划-执行（Plan-and-Execute）
系统先形成任务计划，再按计划执行步骤；观察可以触发局部修订或全局重新规划。计划一般包含步骤、依赖、成功判据和资源约束。相比每轮完全自由决策，计划可减少目标漂移，并支持检查进度；但初始计划可能错误，计划维护本身消耗成本。关键设计问题是：什么时候应坚持计划、什么时候应重规划？通常应依据依赖失败、证据缺口、环境变化或预算偏差触发，而不是每一步都无条件重做完整计划。
8.4 混合控制（Hybrid）
程序定义关键阶段和不可越过的控制边界，模型在阶段内部动态选择动作。例如研究任务固定为“确定范围→收集证据→综合分析→验收”，其中“收集证据”允许模型多轮检索，“发布”必须经过固定审批节点。混合架构适合既需要灵活探索又存在可审计业务节点的任务；其代价是需要设计清晰的状态契约和阶段切换条件。
| 维度 | 固定工作流 | 动态循环 | 计划-执行 | 混合控制 |
|---|---|---|---|---|
| 下一步选择 | 程序预定 | 模型主导 | 计划与执行器共同决定 | 分层控制 |
| 环境适应 | 较弱 | 较强 | 中等至较强 | 可配置 |
| 成本可预测性 | 较高 | 较低 | 取决于重规划 | 取决于阶段边界 |
| 测试重点 | 节点与分支 | 动作轨迹与循环 | 计划质量与偏离 | 阶段切换与权限 |
| 典型风险 | 僵化 | 漫游与越界 | 计划过期 | 规则冲突与状态复杂 |
这些是架构层面的倾向，不是经过统一基准测量的性能排名。模型、任务、工具和运行时实现不同，实际表现可能相反。
九、代表性研究路线：从行动选择到工具使用
9.1 ReAct：交替推理与行动
ReAct（Yao 等，2023）将语言模型生成的推理相关轨迹与面向环境的动作交织组织。典型流程为：接收任务→产生下一步推理/行动→执行外部动作→获得观察→继续决策。其关键贡献不在于“Agent 可以使用工具”这一宽泛说法，而在于将行动与外部反馈放入迭代过程，使模型能够依据新观察修正后续行为。工程上必须注意：论文示例的文本轨迹并不等同于现代 API 的隐藏推理或结构化 tool-call 协议；也不能将可见文字解释当成真实内部推理的完整证据。
适用条件：需要多步外部检索或交互、下一步取决于观察结果。主要局限：模型可能误解观察、重复行动、产生不合规工具建议；ReAct 本身不提供可靠的权限执行器、幂等存储和事务恢复。
9.2 Toolformer：学习何时调用工具
Toolformer（Schick 等，2023）研究如何让语言模型通过自监督方式学习工具调用位置与参数。它关注的是工具使用能力如何通过训练获得，而非完整 Agent Runtime 如何实现状态、审批或恢复。与 ReAct 相比，Toolformer 的研究对象更偏向模型层的工具使用学习，不能把两者直接视为两个可替换的运行时框架。对工程设计的启发是：工具选择表现既受到运行时工具描述和提示的影响，也受到模型训练分布的影响。
9.3 Plan-and-Solve / Plan-and-Execute 方向
规划优先的研究路线强调先显式组织子任务或解题步骤，再执行后续操作，以减少目标遗漏和长任务漂移。需要区分论文中的推理提示策略与框架中的执行编排：前者可能只改变模型生成过程，后者还必须定义步骤依赖、工具调用、计划更新、失败重试与完成条件。规划质量不是执行正确性的充分条件；一份看似合理的计划仍可能基于错误事实。
9.4 现代框架中的控制逻辑
LangGraph 等图式编排框架可将执行过程表达为节点、边和状态更新，并通过条件边决定下一步；这种设计让部分控制逻辑从提示词中移到显式程序图。其他模型驱动 SDK 可能更强调工具调用循环与运行器封装。具体框架版本的状态合并、并行调度、工具执行和中断行为并不相同，实施时必须核对所用版本的官方接口及实际源码。本篇只抽取稳定的设计模式，不虚构统一的 SDK 调用方式。
9.5 比较的正确层次
ReAct 主要帮助解释“观察反馈如何参与下一步行动”，Toolformer 主要研究“模型如何学会工具调用”，规划式方法研究“如何组织多步目标”，图式运行时研究“如何由程序控制执行拓扑”。它们分处不同技术层级，可以组合，不能仅用“准确率高低”排成一个不加条件的排行榜。
十、计划、并行与依赖：执行图的组织问题
串行循环是最容易理解的 Agent 结构，但实际任务可能包含可并行的子步骤。例如研究三种框架时，三个独立资料收集任务可以并行，比较结论则依赖三组证据完成。可以将任务表示为有向图 G=(V,E)，节点为工作单元，边为先后依赖；只有依赖满足且授权通过的节点才能进入执行。
10.1 并行的收益与代价
若三个检索任务耗时分别为 t1,t2,t3，串行理论耗时约为 t1+t2+t3，理想并行约为 max(t1,t2,t3)，但真实系统还受到模型调用开销、限流、共享状态冲突和结果合并成本影响。并行不是无条件更快。对于共享文件写入、相互依赖的工具操作或有顺序要求的审批，应优先使用串行或显式协调。
10.2 合并结果的语义
并行节点可能同时修改“已发现来源”或“当前结论”。如果直接用最后一个写入覆盖前一个写入，就会丢失证据。应对不同字段定义合并规则：证据集合可按来源 ID 去重合并，预算计数应累加，互斥阶段状态需要冲突检测，最终结论则可能要求重新评估而非简单拼接。这属于执行机制与状态管理的交界问题。
10.3 何时重新规划
建议在明确触发条件下重新规划：关键依赖失败、用户目标改变、预算不足、出现新的相反证据、外部环境发生重大变化。重规划应保留已确认事实和外部副作用记录，而不是把历史执行当成没有发生。重新规划的技术细节将在 A9 深入研究。
十一、错误、重试与恢复：反馈闭环的压力测试
11.1 六类失败位置
模型阶段可能产生不可解析输出或错误行动；动作校验阶段可能发现非法参数；授权阶段可能拒绝越权操作；工具阶段可能超时或部分成功；观察解释阶段可能误读工具数据；状态更新阶段可能出现并发覆盖或记录丢失。不同失败位置需要不同补救措施，不能统一归结为“再让模型想一遍”。
11.2 重试必须保留操作语义
只读检索一般可以有限重试，但仍要计入费用和限流；可重复计算通常可以重试，但要避免重复产物；非幂等写入在响应丢失时可能进入 UNKNOWN，必须先核对外部状态。模型可以建议重试，是否重试由运行时策略决定。对不可逆操作应设置更严格的批准与结果核验机制。
11.3 防止无效循环
无效循环常表现为反复搜索同一查询、连续使用失败工具、反复输出无法通过校验的答案。可使用 normalized_action_signature 检测重复动作，用相同输入与相同观察的重复次数设置阈值；但不能机械地把重复动作一律判为错误，因为分页、轮询和必要的复查本身可能需要重复。重复检测应结合动作参数、环境版本和预期进展。
11.4 恢复和重新开始不是同一回事
恢复应读取已保存的状态、检查点与外部操作记录；重新开始则可能重新执行全部步骤。若此前已经写入外部系统，盲目重新开始可能产生重复副作用。本文关注恢复对行动选择的影响，检查点协议和持久化机制详见 Fundamentals 07 Agent Lifecycle。
十二、终止控制：让完成成为可验证事件
终止控制至少区分：COMPLETED（验收条件满足）、FAILED（不可恢复失败）、CANCELLED（明确取消）、BUDGET_EXHAUSTED（资源上限）、WAITING（等待用户或外部事件）、PARTIAL（部分结果可交付）。这些状态的命名是说明性设计，具体产品可能采用不同状态机。
12.1 为什么不能让模型自行宣布成功
模型输出 finish 只是候选完成决策。执行器仍应检查：交付物是否存在、引用是否可定位、必要任务是否覆盖、受控操作是否确实完成。对于无法程序化评估的质量要求，应明确引入人工验收或独立评估，并承认评估存在不确定性。不能以“模型很有信心”替代可检查的完成事实。
12.2 预算与成功条件冲突时怎么办
预算是硬约束，成功是业务目标。若达到预算但任务未完成，应停止继续执行，并尽可能交付已经确认的部分结果和未完成事项；不得为了满足输出格式而虚构缺失证据。对于模型调用、工具调用、Token、时间和费用，建议分别计数，避免单一“步数”指标掩盖实际资源消耗。
12.3 等待不是失败
当 Agent 需要用户澄清或审批时，运行时应记录等待原因、待处理动作、超时和恢复条件。等待期间不应把进程内存作为唯一状态来源；长期等待与恢复的详细实现属于 Lifecycle 及系统级运行时。
十三、工程实现：一个经过本地验证的最小执行器
为了让研究达到 L2（最小可运行实现），本篇提供配套 Python 3 标准库示例 04-Agent-Execution-Mechanism-v1.1-demo.py。它不依赖模型 API，而是用确定性的 ScriptedPolicy 代替模型，以便单独验证执行控制机制，避免把模型输出随机性与运行时正确性混为一谈。
13.1 关键数据结构与接口
Decision：候选动作，包含kind、tool、args、answer。State：权威任务状态，包含目标、决策步数、工具调用数、状态、证据、事件和输出。ScriptedPolicy.decide(state)：根据当前状态产生候选动作。Policy.authorize(decision)：在实际执行前检查工具是否允许、参数形状是否符合最低要求。Environment.execute(decision)：模拟工具返回真实观察。run(...)：实现预算检查、决策记录、授权、工具调用、观察记录、状态更新和完成验证。
这些结构刻意保持简化：没有数据库、持久化检查点、并发、真实 JSON Schema、网络超时、真实模型、用户身份认证或复杂副作用。它们只用于测试单 Agent 执行循环的核心职责分离。
13.2 关键执行代码
def run(state, model, env, policy, max_steps=5, max_calls=3):
while state.status == 'RUNNING':
if state.step >= max_steps or state.calls >= max_calls:
state.status = 'BUDGET_EXHAUSTED'
break
decision = model.decide(state)
state.step += 1
state.events.append({'type': 'DECISION', 'step': state.step, 'kind': decision.kind})
if decision.kind == 'finish':
if len(state.evidence) >= 2 and decision.answer:
state.output = decision.answer
state.status = 'COMPLETED'
else:
state.events.append({'type': 'REJECTED_FINISH'})
continue
if decision.kind != 'tool' or not policy.authorize(decision):
state.events.append({'type': 'DENIED_ACTION'})
continue
state.calls += 1
observation = env.execute(decision)
state.events.append({'type': 'OBSERVATION',
'status': observation['status'],
'tool': decision.tool})
if observation['status'] == 'OK':
state.evidence.extend(observation['items'])
return state完整实现及三个断言测试见配套 .py 文件。这里的验收条件 len(state.evidence) >= 2 是为演示机制设置的教学条件，不是真实研究任务的质量标准；真实系统必须检查证据的相关性、真实性与覆盖度。
13.3 实际执行轨迹
正常场景中，策略先调用 search(key='rag') 获得 paper-a，再调用 read(key='paper-a') 获得文本，最后产生 finish。执行器记录三次决策、两次工具调用，并在证据条件满足时置为 COMPLETED。
越权场景中，策略连续建议调用 publish；授权器拒绝，两次拒绝均不会进入工具执行器，最终达到步骤预算并停止。提前结束场景中，策略反复建议 finish，但没有证据；验收器拒绝完成，最终按预算停止。这两个负向案例比只演示正常流程更能说明运行时控制的必要性。
13.4 本地测试结果
2026 年 10 月 28 日在本地 Python 环境执行 python 04-Agent-Execution-Mechanism-v1.1-demo.py，三个断言通过，输出为：
{
"happy": {"status": "COMPLETED", "steps": 3, "tool_calls": 2},
"denied": "BUDGET_EXHAUSTED",
"premature": "BUDGET_EXHAUSTED"
}这些测试验证了最小执行器的三项性质：正常闭环能够结束；未经授权的工具建议不被执行；缺少验收证据时模型不能直接宣布完成。它们不验证真实模型选择动作的质量、真实工具可靠性、并发安全、持久化恢复或安全策略完备性。
13.5 从最小实现走向真实系统
将示例升级为真实 Agent 至少需要：替换策略为实际模型适配器；使用严格的工具 Schema；在每次调用前绑定用户和资源级权限；把权威状态写入持久化存储；实现工具超时和重试分类；为外部写操作记录幂等键；引入真实验收器；记录完整关联 ID 和耗时；对长任务实现检查点与恢复。升级顺序应由业务风险驱动，不能仅因为示例代码短就认定执行机制已达到生产级。
十四、贯穿案例：研究助理 Agent 的决策-行动-观察轨迹
用户目标：“比较 RAG 与长上下文方案在更新性、成本、证据可追溯性方面的差异，并输出有来源的报告。”允许动作：搜索、读取文档、生成本地草稿；不允许外部发布。预算为最多 12 次模型决策和 20 次工具调用。以下是构造的机制示例，不是真实联网实验。
| 决策轮次 | 模型候选行动 | 运行时处理 | 环境观察 | 权威状态更新 |
|---|---|---|---|---|
| 1 | 搜索两种路线的代表资料 | 校验查询并调用只读工具 | 返回候选来源列表 | 增加待核验来源 |
| 2 | 读取来源 A 与 B | 校验文档 ID 和访问权限 | 返回文档及时间信息 | 记录已读取来源 |
| 3 | 生成比较矩阵 | 允许本地计算 | 发现成本条件不一致 | 标记证据缺口 |
| 4 | 再次搜索成本数据 | 校验预算与工具权限 | 返回补充材料 | 更新证据覆盖度 |
| 5 | 保存草稿 | 校验本地写入路径 | 返回文件引用 | 保存产物引用 |
| 6 | 提出 finish | 验证覆盖与引用 | 一项引用无法定位 | 拒绝完成，保留缺口 |
| 7 | 读取缺失来源 | 再次执行只读工具 | 返回可定位原文 | 补全证据 |
| 8 | 提出 finish | 验收通过 | 文件可读取、覆盖要求满足 | 标记完成 |
如果第 4 轮搜索失败，Agent 可以改写查询或声明证据不足；如果第 5 轮文件写入超时，运行时应查询文件状态，避免重复覆盖；如果第 6 轮模型声称完成，验收器仍有权拒绝。同一个案例中，模型决策、工具执行、观察可信度、状态归约和完成判定是五种不同责任。
十五、评估与实验：不要只测最终答案
执行机制评估应建立分层指标：
| 层次 | 指标 | 计算或判定方法 | 注意事项 |
|---|---|---|---|
| 决策 | 合法动作率 | 合法候选动作数 / 全部候选动作数 | 合法不代表有效 |
| 工具 | 调用成功率 | 成功执行数 / 实际调用数 | 不含被拒绝的候选动作 |
| 效率 | 无效循环比例 | 无进展的重复决策数 / 决策总数 | 需定义“进展” |
| 可靠性 | 恢复成功率 | 正确恢复的故障任务数 / 恢复测试任务数 | 需故障注入 |
| 安全 | 未授权执行数 | 实际发生的越权操作次数 | 关键场景应为零 |
| 完成 | 验收通过率 | 满足业务条件的任务数 / 任务总数 | 与工具成功率不同 |
| 成本 | 单次成功任务成本 | 总模型与工具成本 / 成功任务数 | 应计入失败任务消耗 |
| 时间 | 端到端延迟 | 任务接纳至终态的时长 | 等待审批需单独分析 |
15.1 建议的消融实验
针对同一任务集，可以依次比较：无工具调用 vs 有工具调用；固定工作流 vs 动态循环；无验收门禁 vs 有验收门禁；无重复动作限制 vs 有限制；全量历史 vs 经过状态投影的上下文。应固定或记录模型版本、温度、工具返回、任务样本和预算，并重复运行估计方差。不能用一次成功案例证明某种架构普遍更优。
15.2 故障注入矩阵
至少测试：模型返回非法结构、工具名不存在、参数不合规、权限拒绝、只读工具超时、写操作响应丢失、观察内容包含提示注入、连续无进展、预算耗尽、验收失败、用户取消。对于每项故障，既检查最终状态，也检查工具是否真正执行、预算是否正确扣除、事件是否完整记录、外部副作用是否被重复提交。
15.3 轨迹回放的价值与限制
保存候选动作、工具输入、归一化观察和状态版本，可以对执行器逻辑进行离线回放与诊断；但如果重新调用随机模型或实时外部服务，结果可能不同。确定性回放通常需要固定模型输出和工具观察，或使用模拟适配器。回放可以验证控制逻辑，不自动证明真实环境中的任务质量。
十六、常见失败模式与诊断方法
| 症状 | 首先检查 | 典型机制缺陷 | 修复方向 |
|---|---|---|---|
| 模型反复搜索相同内容 | 决策和观察轨迹 | 状态没有记录已完成动作 | 显式进展状态与重复检测 |
| 工具调用成功但答案错误 | 证据与模型归纳 | 观察被误解或证据不足 | 来源核验与独立验收 |
| 任务提前宣布完成 | finish 事件和验收结果 | 把模型声明当成完成事实 | 程序化完成门禁 |
| 越权调用成功 | 工具执行日志 | 权限仅写在提示词中 | 执行前强制授权 |
| 预算失控 | 模型轮次和工具尝试 | 只统计成功调用 | 全路径预算计数 |
| 工具超时后重复写入 | 操作 ID 和外部状态 | 不区分 UNKNOWN 与失败 | 幂等键与结果核验 |
| 长任务丢失进度 | 检查点和状态日志 | 仅依赖上下文文本 | 权威状态持久化 |
| 并行证据丢失 | 状态合并轨迹 | 最后写入覆盖 | 字段级合并语义 |
诊断应沿着“任务契约→模型输入→候选决策→动作校验→授权→工具执行→观察→状态更新→终止验证”逐层定位。只有最终回答而没有中间轨迹，很难区分模型问题、工具问题和运行时问题。
十七、设计取舍、适用边界与后续研究
执行机制的核心取舍是灵活性与控制确定性。模型主导的动态循环可以处理未知路径，但成本、失败模式和测试空间更大；固定工作流容易审计，但对新情况的适应能力有限；混合控制通过阶段化约束寻求平衡，但增加状态与接口复杂度。不存在不依赖任务条件的最优方案。
对于短时、只读、步骤稳定的任务，应优先考虑简单工作流；对于信息不完整且需要连续探索的任务，可以采用受限动态循环；对于长任务和外部写操作，应增强状态持久化、幂等、审批和恢复机制；对于高风险任务，应把可验证的权限控制和人工审批放在模型决策之外。
本篇的核心结论可以归纳为四点：第一，Agent 的“思考与行动”是一条受控的决策-执行-反馈链，而不是模型独自完成的动作；第二，模型候选行动、真实工具执行与业务成功必须分别记录和验证；第三，状态、预算、权限和完成条件应由权威运行时维护；第四，执行机制的可靠性需要通过负向测试、故障注入和轨迹分析证明，不能由一段流畅的模型输出推断。
与后续专题的衔接：A2 解释模型如何产生决策，A4 解释每轮输入如何装配，A7 解释工具接口和结果适配，A9 解释规划和重规划，A10 解释授权，Fundamentals 07 解释任务暂停恢复和生命周期，Agent System 解释分布式执行与可靠性基础设施。掌握本篇之后，应能够在具体 Agent 系统中准确指出：谁提出动作、谁批准动作、谁执行动作、谁确认结果、谁保存状态，以及谁决定停止。
参考资料与延伸阅读
- Stuart Russell & Peter Norvig. Artificial Intelligence: A Modern Approach, 4th ed., Pearson, 2021。经典 Agent、环境、策略与部分可观测性理论背景。
- Shunyu Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023。论文：https://arxiv.org/abs/2210.03629。推理相关文本、动作与观察交替组织的研究
- Timo Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023。论文：https://arxiv.org/abs/2302.04761。模型学习工具调用的代表性路线
- Lei Wang et al. Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models. ACL 2023。论文：https://arxiv.org/abs/2305.04091。规划优先的推理提示研究；不等同于持久化 Agent 执行器。
- Anthropic. Building Effective Agents, 2024。https://www.anthropic.com/engineering/building-effective-agents。工作流与 Agent 控制结构的工程视角。
- LangGraph 官方文档，Graph API、Persistence、Human-in-the-loop 等主题：https://docs.langchain.com/oss/python/langgraph/overview。图执行与状态管理的框架参考；具体 API 需以使用版本核验。
- OpenAI. A Practical Guide to Building Agents, 2025。https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf。模型、工具、指令和护栏的工程组织参考
- Martin Kleppmann. Designing Data-Intensive Applications. O’Reilly, 2017。状态一致性、幂等、事件与分布式可靠性基础。
研究声明
研究性质：本文是基于既有 Fundamentals 04 v1.0 的研究对象与问题框架，结合经典 Agent 理论、代表性论文及通用工程设计原则形成的深化研究。形式化表达、动作契约、运行时组件划分与部分控制策略属于本文的工程综合，不是行业统一标准。
资料核验状态：本次未逐条在线复核全部论文、官方文档及 2026 年最新框架 API。参考文献用于标识可追溯的原始研究和技术文档，不表示已完成当日源码级验证。文中关于具体框架的内容仅限一般性机制，不提供未经核验的版本专属接口承诺。
代码验证状态：配套 Python 3 标准库示例已于 2026 年 10 月 28 日在本地执行，正常完成、越权拒绝、提前完成拒绝三项断言通过。代码未接入真实 LLM、外部工具、数据库或分布式执行环境，不构成生产级可靠性或安全性证明。
研究边界：本篇聚焦单 Agent 的决策-行动-观察-状态更新闭环。模型内部推断、工具协议细节、长期规划、权限系统、检查点恢复与多 Agent 调度分别在后续专题研究；不能将本文最小执行器视为这些机制的完整实现。