章节导航 第 17 章 / 共 21 章
第 17 章 第二部分：架构原理

main_agent 源码精读

通用 tool-calling 循环的完整实现、迭代控制、并行工具调用、Compaction 集成、Span 指标

Nexus main_agent Tool-Calling ReAct 源码精读

为什么精读 main_agent

main_agent 是 Nexus 最通用、使用最广泛的 Agent。理解它的实现，就理解了 Nexus Agent 编排的核心机制。

源码位置：nexus/extensions/agents/main/agent.py（597 行）+ utils.py（3.7KB）+ processor.py（5.2KB）。

核心循环

@agent_registry.register('main_agent')
async def run_main_agent(agent_input: MainAgentInput) -> MainAgentOutput:
    ctx = require_context()
    client = ctx.openai_client

    # 1. 准备工具
    tools = [tool_registry.get(name) for name in agent_input.tools]
    tool_executor = ToolExecutor(tools)

    # 2. 加载 MCP 工具（如果配置了）
    if agent_input.mcp_servers:
        await ctx.load_mcp_tools(agent_input.mcp_servers)

    # 3. 应用 Tool Schema Override
    # ...

    # 4. 构建初始 messages
    messages = [
        {'role': 'system', 'content': agent_input.system_prompt},
        {'role': 'user', 'content': agent_input.user_prompt},
    ]

    # 5. 迭代循环
    for iteration in range(agent_input.max_iterations):
        # 5a. Compaction 检查（每轮开始时）
        if ctx.compaction_manager:
            messages = await ctx.compaction_manager.check_and_compact(messages, ...)

        # 5b. LLM 推理
        with span_context('agent.inference'):
            completion = await client.create_completion(
                messages=messages,
                tools=tool_executor.get_tool_schemas(),
            )

        assistant_msg = completion.choices[0].message

        # 5c. 无工具调用 → 结束
        if not assistant_msg.tool_calls:
            exit_status = MainExitStatus.FINISHED
            break

        # 5d. 执行工具调用
        with span_context('agent.observation'):
            if agent_input.parallel_tool_calls and len(assistant_msg.tool_calls) > 1:
                results = await tool_executor.parallel_call([...])
            else:
                results = [await tool_executor.call(tc.name, tc.args) for tc in ...]

        # 5e. 构建 tool result messages
        messages.append(assistant_msg_dict)
        for tc, result in zip(tool_calls, results):
            messages.append({'role': 'tool', 'tool_call_id': tc.id, ...})

        # 5f. Post-iteration hook（可选）
        if agent_input.post_iteration_hook:
            hook_result = await invoke_hook(...)
            # hook 可以替换或追加 tool messages（如注入自动截图）

    return MainAgentOutput(
        exit_status=exit_status.value,
        iterations=iteration + 1,
        main_trajectory=messages,
        final_answer=extract_final_answer(messages),
    )

关键设计细节

7 种退出状态

class MainExitStatus(str, Enum):
    FINISHED = 'finished'                    # LLM 不再调用工具
    MAX_ITERATIONS = 'max_iterations'        # 达到最大轮数
    TOOL_ERROR = 'tool_error'                # 工具调用反复失败
    INFERENCE_ERROR = 'inference_error'      # LLM 推理异常
    CONTEXT_LENGTH_EXCEEDED = 'context_length_exceeded'  # 超长
    INFERENCE_TIMEOUT = 'inference_timeout'  # 推理超时
    OBSERVATION_TIMEOUT = 'observation_timeout'  # 工具执行超时

每种状态映射到一个 termination_reason 字符串（如 ENV_DONE、MAX_STEPS），用于 Processor 和评估。

工具参数错误重试

invalid_tool_args_retries：当 LLM 给出的工具参数不符合 schema 时，不直接失败，而是把错误信息反馈给 LLM 让它重试。

工具执行错误重试

tool_call_error_retries：工具执行抛异常时的重试次数。

工具输出截断

tool_output_truncation: 10000：超过 10000 字符的工具输出被截断。防止单次工具返回（如 cat 大文件）撑爆上下文。

OOM Recovery

oom_runtime_recovery: true：如果 Runtime 因 OOM 崩溃，尝试重新获取 Runtime 并继续。

Post-Iteration Hook

每轮工具执行后的回调机制。import path 指定：

agent_config:
  post_iteration_hook: "my_module::my_hook"

hook 可以返回 PostIterationHookResult——替换 tool messages 或追加额外 messages（常见用途：每轮后自动截取浏览器截图）。

Span 指标体系

main_agent 在每个阶段创建独立 Span：

agent.main_agent (总 Span)
  ├── agent.iteration (每轮)
  │   ├── agent.inference (LLM 调用)
  │   ├── agent.observation (工具执行)
  │   └── agent.compaction (上下文压缩，如果触发)
  └── agent.iteration
      └── ...

总 Span 的 attributes 包含：exit_status、iterations、各种计数（tool_calls、errors 等）。MainAgentMetricsProcessor 从这些 Span 中提取结构化指标。

与 base Agent 框架的关系

nexus/extensions/agents/base/ 提供了另一套 Agent 框架——更结构化，基于抽象基类。

base/
├── base.py       # ToolCallingAgent 抽象基类
├── toolcall.py   # 工具调用处理（11KB）
├── react.py      # ReAct 循环
├── prompt.py     # Prompt 模板系统（10KB）
├── schema.py     # Agent 配置 schema（7.5KB）
├── final_answer.py  # FinalAnswer 工具（6.2KB）
├── evaluation.py # 内置评估
└── utils.py      # 工具函数

base 框架和 main_agent 的关系：main_agent 是独立实现的，不继承 base。base 更适合需要精细控制 prompt 模板和 ReAct 循环的场景；main_agent 更简洁直接。

推测执行：突破串行瓶颈

main_agent 的核心循环是串行的——for iteration in range(max_iterations)，每步必须等 LLM 返回 + 工具执行完成。这在长链条任务中成为显著瓶颈。

研究前沿

Speculative Actions（ICLR 2026 正会论文，Columbia 大学）提出推测执行框架：用更快模型预测 Agent 下一步行动并提前执行，预测正确则获得并行加速（最高 55% 下一步预测准确率），预测错误则丢弃——保证无损。

PASTE（Microsoft Research, 2026.03）进一步利用 Agent 请求中稳定的应用层控制流（重复 tool-call 序列）和可预测的数据依赖（参数传递），在 LLM 推理的同时推测执行未来工具调用，减少平均任务完成时间 48.5%，工具执行吞吐量提升 1.8x。

B-PASTE（arXiv:2604.16469）扩展 PASTE 至资源受限场景，维护有界 beam 的未来执行子图，在边缘环境上获得 1.4x 端到端加速。

Skim（ICLR 2026）从成本效率视角补充了推测执行光谱：不同于 Speculative Actions 的”预测高价值步骤”策略，Skim 采用”跳过低价值步骤”（skimming）策略，在预算约束下最大化吞吐——实现 1.9x 成本降低 + 33.4% 延迟降低。三种策略形成完整维度：

策略提交粒度优化目标核心机制关键指标
Speculative Actions单步延迟优先预测下一步并提前执行55% 准确率，2-5x 加速
PASTE/B-PASTE单步稳定控制流推测利用重复 tool-call 序列48.5% 时间减少
Skim跳步成本效率优先跳过低价值步骤1.9x 成本降低 + 33.4% 延迟降低
SPORK（2026-07）单步延迟优先 + 训练无关模型自我预测 + 前缀缓存分叉74.6-99.6% 准确率，GAIA P95 -18%，零辅助模型
Speculate with Memory（2026-07）单步跨任务持续改进三记忆系统（对比转发表/情节记忆/混淆跟踪器）19-39% 动作预测提升，2.5× 观察预测提升
AOSpec（2026-08）单步动作+观察协同推测EVD 优化预期隐藏时间 + JASV 长程动作-状态验证端到端延迟降 11.8-32.5%，p99 最高 42.8%
OoO-Spec（2026-08）单请求全参数槽乱序语义推测0.6B sidecar 并行预测函数+参数槽位2.46-5.34x 加速（均值 3.89x）
Speculate While You Reason（2026-07）单步自推测智能体joint agent-speculator RL 复用前缀缓存next-call Hit@1 44→61（未测端到端延迟）
SMC（2026-09）多步宏延迟优先 + 多步提交训练轨迹挖 multi-action skeleton → macro library，drafter 在隔离环境快照上预执行，actor 首动作匹配即整链提交（含 observations）τ²-Bench Telecom 相对串行 −18.59%、相对 SA −10.23%（准确率持平）；AppWorld 相对串行 −44.9%、相对 SA −7.7%（⚠️ TGC 70/168→68/168）
TomasuLLM（arXiv:2609.38201，2026-09-22）乱序 / 跨步长工具空档期的指令流重排草拟未来动作 → 在 copy-on-write 沙箱中乱序执行 → 追踪依赖与效应 → 按轨迹顺序在验证通过后才提交1.31×（100 个 SWE-bench Verified 任务）/ 1.35×（28 个 Terminal-Bench 2.0 任务）/ 1.27×（18 个 SWE-Marathon session，等进度口径）；4,010 条审计过的提交验证记录中零错误接受

⚠️ TomasuLLM 那一行要带两个限定读。它是预印本（arXiv:2609.38201，2026-09-22），无公开代码；三个加速比的样本量分别是 100 / 28 / 18，其中 SWE-Marathon 只有 18 个 session，且论文用的口径是 matched progress 而非完成率——三个加速比受样本量限制，不宜外推。真正硬的是最后一项：4,010 条经过审计的提交验证记录里零错误接受（zero false accepts）——注意是”没有把不该提交的提交进去”，不是”没有误判”，两者不是同一件事。这条恰好是推测执行最该被审计的那一环：加速比可以用小样本论证，正确性不能。

注：「提交粒度」列对 SMC 直接取自论文原文；对其余各行是依据本章已有描述做的编辑归纳，非各家论文自述。

SMC（Speculative Macro Commit，arXiv:2609.03236，Zeyu Liu 与 Peter A. Beerel（University of Southern California）、Souvik Kundu（Intel Labs），2026-09-03，代码公开）把推测的提交粒度从单步推到多步：两层 agent 系统里，大 actor 产出官方轨迹，快 drafter 在隔离的环境快照上持续预测并执行未来动作链；系统从训练轨迹中挖掘重复出现的多动作骨架存入 macro library，运行时拿 drafter 预测的动作链去匹配，一旦 actor 的下一个工具调用与某条 macro 的首动作吻合，就把剩余已预执行的步骤连同 observations 整链提交。实验配置为 actor = Qwen3.5-27B INT4、drafter = Qwen3.5-4B。在 τ²-Bench Telecom 上 SMC 与串行基线逐任务结果完全一致（两轮均为 2,274 正确 / 11 错误），相对 SA 修好一个任务、未回归任何任务——这一项收益是零代价的。AppWorld 则不然：−44.9% 的 wall time 收益伴随 TGC 从 70/168 降到 68/168。

⚠️ 论文里 MLSP 2026 已录用这一说法本轮在 abs 页与 HTML 全文中均零命中，不予采信。

SPORK（Self-sPeculative fORKing，arXiv:2607.03333，Huajun Bai et al., 清华存储）代表全新范式——训练无关 + 自我预测：模型自身作为预测器，在生成开始时 fork 探针预测工具名称（Qwen3-32B 准确率 74.6-99.6%），将工具执行与剩余 CoT 解码重叠。前缀缓存分叉降探测成本、置信度门控过滤误预测、被拒绝探针转化为推测解码草稿。跨 4B-32B 模型大小 + dense/MoE 架构均有效，开源（github.com/baihuajun24/spork）。与现有五种框架不同：不需要辅助模型、不需要离线轨迹、不需要训练。

Speculate with Memory（arXiv:2607.12236，Yu Li et al., Salesforce）则为推测器装备三种在线记忆系统——对比转换表（跨任务动作序列统计）、情节记忆（检索上下文相似片段）、混淆跟踪器（抑制重复错误）。动作预测 19-39% 相对准确率提升，观察预测最高 2.5× 提升。关键洞察：推测器性能随记忆累积持续增长，且跨推测器模型泛化。这直接挑战了所有现有推测执行框架的”无状态”假设——证明有记忆的推测器显著优于无状态版本。

AOSpec（Action-Observation co-Speculation，arXiv:2608.00881，Hao Mark Chen et al., Imperial College London，2026-08-01）是首个把动作与观察在同一框架内协同推测的无损方案：Expected Value Decoding（EVD）把观察推测导向「预期延迟收益最大」的结果（优化 expected hidden time 而非 hit rate），Joint Action-State Verification（JASV）在隔离 fork 中预执行延迟关键的目标动作、并在复用前同时验证动作及其来源状态。在 Terminal-Bench 四种 harness、五种 actor 模型、五种服务速度下，平均端到端延迟降低 11.8-32.5%，p99 最高降 42.8%，观察模型可零重训迁移到 SWE-bench Verified。

OoO-Spec（Out-of-Order Semantic Speculation，arXiv:2608.00814，Zhiheng Zhang et al.，2026-08-01）是 ToolSpec 的直接演进：用一个 Qwen3-0.6B sidecar 在请求到达时并行预测函数选择 + 全部 schema 定义参数槽位（单次 request-level wave），target 继续解码并以非阻塞方式轮询 ready hint。sidecar 用 LoRA 在 Qwen2.5-32B teacher traces 上训练一次，即可跨 Qwen2.5/Qwen3/Llama target 复用。七个 target × 三个 benchmark 全部 21 个 cell 中实现 2.46-5.34x 加速（未加权均值 3.89x，vs ToolSpec 2.95x）。

Speculate While You Reason（arXiv:2607.25816，Jiabao Ji et al., UCSB + LinkedIn，2026-07-28）提出 self-speculating agent——单一模型既在 agent mode 解任务、又在 speculator mode 预测下一次 tool call，完全复用 prefix KV cache，无需外部 draft model 或 trace cache。joint agent-speculator RL 从 agent 自身 rollout 导出推测目标并交替更新：Qwen3-4B 的 next-call Hit@1 从 44.1→61.2，Qwen3.5-4B 从 48.9→66.3，任务成功率基本持平。⚠️ 注意：该文未做端到端 latency 测量，且 “single model” 表述有争议（Table 2 是两个分别训练的 checkpoint），引用时应标注这一限制。

范式演进判断：2026 下半年推测执行正从「动作单边推测」走向「AOSpec 的动作+观察协同推测」与「OoO-Spec 的乱序语义推测」，并出现「自推测智能体」（agent 即 speculator，无需独立 drafter）的第三种路线——这与 main_agent 的串行工具调用循环构成直接优化空间。

SMC 之后还要加第四条：多步提交。前三条路都在回答”下一步（或下一个请求）猜什么”，SMC 问的是另一个问题——这一串动作能不能作为一个整体被提交。它直接对应下面两条可行路径：依赖分析不能只判断”这两个操作是否独立”，还得判断”这条链是否可整链重放”；回滚机制也不只是缓存丢弃的问题（见下文）。

第五条是乱序执行。前四条都在回答「下一步（或下一段）该猜什么」，TomasuLLM 问的是另一件事——后面的步骤能不能现在就跑、稍后按依赖顺序落地。差别不在机制而在价值曲线：前四条的收益随工具延迟降低而衰减（工具够快就没必要猜），乱序执行的收益恰恰随工具延迟升高而升高，论文针对的正是编译、测试套件、repo 级指令这类秒级到分钟级的空档。

对 main_agent 的含义是这两者不重叠，别当成同一件事的两档：parallel_tool_calls 处理的是同一轮内的独立调用，乱序执行处理的是跨轮的长尾等待。前者已经落地，后者要求的运行时前提（CoW 沙箱 + 依赖追踪 + 提交前验证）本章下一节才展开。

IdleSpec（2026）则利用 Agent 等待工具返回的空闲时间进行推测性规划（idle-time speculative planning），在无额外推理成本的情况下提升任务准确率 +5.1%。当 main_agent 等待工具执行时，空闲计算资源可用于预规划后续步骤，与 Skim（成本效率）和 Speculative Actions（延迟优先）形成互补。

与 main_agent 的关联

main_agent 的 post_iteration_hook 机制可视为 PASTE 的简化版——PASTE 将推测执行从 hook 提升为系统级优化。在 Nexus 中实现推测执行的可行路径包括：

  1. speculative_executor 参数：在 Agent 配置中启用，当 parallel_tool_calls=true 时自动尝试推测后续工具调用。⚠️ 实现方式有讲究：若”启用推测”意味着给模型新增一个可选能力、让它自己决定用不用，这条路在开源模型上已被判过一次。SMC 论文报告，AWO 把挖掘出的工具调用序列做成确定性复合 meta-tool 供模型调用，结果是”open models like Qwen3.5-27B rarely select these mined macros”，作者据此认定”simply exposing mined action sequences as additional callable tools is unreliable”。取向应是系统侧透明匹配（drafter 预测 → 首动作匹配 → 整链提交），而不是模型侧主动选择——加参数可以，但要保证对模型透明。
  2. 依赖分析：并行执行的前提是操作真正独立——需要静态或运行时分析工具调用的数据依赖。SMC 补上了另一半：不仅要判断”这两个操作是否独立”，还要判断”这一串动作是否作为一个整体被重放”（macro 匹配）。TomasuLLM 补的是第三种粒度：它判断的是「这条链里各步骤之间的依赖能否被追踪、并在提交时验证」。三者不是同一种判断——SMC 是整链的布尔判断（首动作匹配就整链提交），TomasuLLM 是逐步的依赖图（可以验证到每一步）。只做整链判断的代价是：链内部分步骤被拒绝时无法部分提交，整链要么全要要么全丢。对 main_agent 来说，这意味着依赖分析的产出不该只是一个布尔值，而应是一张可逐步验证的依赖图。
  3. 回滚机制：推测执行结果暂时缓存，LLM 实际决策与推测一致则提交，否则丢弃。⚠️ “丢弃”在工具带副作用时不等于”撤销”。Nexus 的 ToolExecutor 会真实执行 shell / 文件操作，缓存里删掉一条记录不会回滚已经发生的写入。SMC 的做法是把推测放在隔离的环境快照上执行，错了连同快照一起丢，天然不需要回滚副作用——这需要运行时级快照，而不是应用层缓存（见下节）。这一族失效在生产环境里已有实证，而且不在推测执行路径上：Claude Code v2.1.271（2026-09-14）修的是”压缩后仍在运行的后台命令（watch 任务、dev server）被启动了第二份”。因果与丢弃来自推测失败还是压缩无关——只要进程还活着，副本就可能出现。Ch15「压缩的下游代价」把这条归为”副作用被重复触发”那一格，两处应互引：推测执行的回滚设计和压缩设计面对的是同一个”活进程不受消息层丢弃影响”的问题。
  4. 记忆化推测执行器：维护跨任务的常见 tool-call 序列缓存，推测准确率随使用量增长——Speculate with Memory 已证明三记忆系统可使动作预测提升 19-39%。SMC 的 macro library 正是这一设想的已发表实现，区别在于它离线从训练轨迹挖掘而非在线累积。两条路不冲突，可以并列：Speculate with Memory 主张在线记忆优于无状态，SMC 主张离线挖掘即可拿到多步收益；前者随使用量增长，后者开箱即用但需要一份轨迹语料。

推测执行的可行性下界由运行时决定

上面四条路径都在 Agent 循环层，但推测执行能不能做、能做多深，取决于运行时能不能廉价地分叉出一个环境副本——drafter 必须有个地方安全地”先跑一遍”。SMC 用的是 isolated environment snapshot；AOSpec 也提到在隔离 fork 中预执行。三个前提缺一不可：

  1. 快照要便宜——分叉成本若接近被省下的时间，整条链路就是净亏；
  2. 副作用要能隔离——写操作不能落到真实环境，否则”丢弃”无从谈起；
  3. 提交要能合并——预执行产生的 observations 要能并回官方轨迹（SMC 整链提交时连 observations 一起并入）。

✅ 这三条不是本书的架构偏好。 本章在 2026-09-16 写下这三条前提时，依据只有 SMC 与 AOSpec 两条路线，本质上是一次编辑归纳。三周后 TomasuLLM（arXiv:2609.38201，2026-09-22）在完全独立的工作里把三条逐条实现了一遍：copy-on-write 沙箱对应”快照要便宜”、依赖与效应追踪对应”副作用要能隔离”、按轨迹顺序在验证通过后才提交对应”提交要能合并”。两条独立路线收敛到同一组约束，这条论断的性质就从”本书的判断”变成了”多条路线共同踩到的同一道坎”。

措辞因此可以加强：上面第 3 条说的”应用层缓存做不到”，不再只是本章的推断——已有两条独立路线各自得出同一结论。

Nexus 侧可对接的能力本书第二部分已经写过：Ch11 记录了 CubeSandbox v0.5 的 CubeCoW 快照克隆与跨机恢复、CRIU v4.2.1（2026-07-21）的进程级 checkpoint、OpenSandbox 的场景化沙箱；Ch10 讨论过 Docker Sandboxes 等选型。这条连线此前没被打通——第二部分讲沙箱快照，第三部分讲 Agent 循环，各自为战。反过来，这也给 Ch10 的沙箱选型表增加了一个评价维度：是否支持廉价分叉。📌 该表目前缺这一列，需跨章同步补上。补列时建议把它做成可勾选的三个子项，而不是一个是非题——CoW 语义（CubeCoW、TomasuLLM 用的沙箱）、进程级 checkpoint（CRIU v4.2.1）、block-granular 驱逐（KV-streams，⚠️ 无正式论文，见 Ch15 本轮待核清单）。三者回答的不是同一个问题：CoW 回答”文件系统层能不能便宜地分叉”，CRIU 回答”进程状态能不能存下来再恢复”，block 驱逐回答”缓存层能不能不重新 prefill”。推测执行真正需要的是前两个。

并行工具调用的性能量化

Zylos Research（2026.04 综述）系统梳理了 Agent 延迟优化数据：

  • 工具执行占 Agent 请求时间的 35-61%
  • 3 个独立工具调用：串行 900ms vs 并行 300ms（3x 加速）
  • LLMCompiler（ICML 2024）实测 3.7x 延迟加速 + 6x 成本节约（减少 LLM 推理轮次）

main_agent 已支持 parallel_tool_calls，但缺少推测执行层。这是 main_agent 性能优化的最明确方向。

退出状态的完备性

main_agent 定义了 7 种 MainExitStatus，但缺少两个常见的终止条件：

  1. Token Budget 退出：Nexus 当前缺少全局 token 预算控制。Agent 可能因上下文无限增长导致成本失控。
  2. 重复工具调用检测：防止 Agent 在两个工具间 ping-pong 循环（如反复 search → visit → search）。

参考 Taskade 的「5 种终止条件」框架（Final Answer / Step Budget / Token Budget / User Interrupt / Tool Error Budget），建议在 Nexus 的 Processor 层增加全局 token 预算和重复调用检测。

📌 长程场景下，第 1 条的性质会变。max_iterations 是轮数上限，它隐含假设”轮数与上下文增长单调对应”。在 SWE-Marathon 这类长程评测里这个假设不成立：一个 session 可以跨越多次 compaction（Claude Code 自 v2.1.284 起，压缩后请求仍超长会再压一次），轮数与上下文规模就此脱钩——跑完 50 轮的会话，上下文可能已被压过三四轮。因此”全局 token 预算”这条在长程场景下不应只是「建议补充」，而是必要条件：只数轮数会漏掉”轮数不多但每轮上下文都被压过一遍”的消耗形态。⚠️ 该限定依赖 SWE-Marathon 的任务定义，本轮未回源，仅作登记，不作断言。正如 Zylos 综述警告的：“Missing stop conditions is the single most common cause of runaway agent bills.”

循环检测与断路器

与 max_iterations 的粗粒度硬上限相比，OpenClaw 的 Doom Loop 检测提供了更精细的终止策略——不是”达到 N 次就停”，而是”检测到循环模式就停”：

  1. 哈希指纹：对连续工具调用序列计算哈希，检测重复模式（如 search → visit → search 循环）
  2. 滑动窗口：N 步窗口内相同哈希出现 M 次即触发告警
  3. 断路器模式：自动终止检测到的死循环，返回结构化错误信息而非超时

最佳实践是将两者组合使用：max_iterations 作为全局安全网，Doom Loop 检测作为精细终止策略。对于 Nexus，可在 post_iteration_hook 中实现哈希指纹检测，在检测到循环时主动设置 should_stop=True 并返回 MainExitStatus.MAX_ITERATIONS（或新增 LOOP_DETECTED 状态）。

运行时门控退出

📌 读作编辑判断，不是文献：本节下面描述的门控式终止范式，此前挂在 “Certified Speculative Execution（2026-07）” 这个名下。该来源已连续三轮检索无果——2026-07-23 首次标记为待验证、2026-09-16 复查未获来源、2026-10-06 第三次检索仍无（无 arXiv 编号、无作者、无机构）。三轮之后可以下一个结论：它不是一份可核的文献，读者应把它当作本书的编辑判断。设计与论证本身不受影响，但请不要在任何地方把它当引用使用。

门控式终止指的是把”提案生成”与”部署决策”分离——Agent 生成的 tool calls 被送入验证器，验证器检查约束条件（安全/资源/权限）后才部署执行。这在退出状态设计中体现为一种预防性终止：不是等错误发生再退出，而是在潜在问题出现前主动拦截。

对 Nexus 的启示：可在 post_iteration_hook 中实现运行时门控——每轮 tool calls 执行前经过一个 GateChecker，检查是否触发安全/资源/权限约束，触发则返回 GATE_BLOCKED 退出状态。这与当前 7 种退出状态的”事后终止”不同：TOOL_ERROR 和 OBSERVATION_TIMEOUT 是 action 失败后才退出，而门控是 action 执行前就拦截。设计上可新增 MainExitStatus.GATE_BLOCKED 作为第 8 种退出状态。

⚠️ 2026-09-16 复查：本轮仍未检索到 Certified Speculative Execution 的任何可核来源（无 arXiv 编号、无作者）。GATE_BLOCKED 这个建议本身是合理的工程实践——在 action 执行前拦截而非事后终止，与本节”预防性终止”的论证一致——建议保留该设计，但去掉”Certified Speculative Execution 提出”这句归属，改按”实践中常见的门控式终止”表述，直到能回源为止。上方 2026-07-23 的待验证标记继续保留。