L4 · Agent 如何被驱动并持续执行任务？ - Agent Engine

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：02 · Agent System 是如何构建和运行的？ - Technical Architecture
文档类型：Agent 执行引擎技术原理、运行时架构与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent Engine 如何把任务、Agent 定义、模型响应和工具执行组织为有边界、可观测、可中断且可恢复的运行过程？一个 Agent Run 如何经历创建、决策、行动、等待、恢复和终止，如何处理状态、并发、审批、预算、外部副作用与失败，并通过明确的执行契约连接 L3 Model Services、L5 Orchestration & Collaboration 和 L2 Platform Services？

专题导读

本篇属 Technical Architecture。一个 Agent 即使具备模型、工具、记忆与规划能力，也不会自动形成可靠的持续执行过程。模型接口返回的是一次推理结果，工具接口完成的是一次受约束的操作，而用户提交的是一个可能跨越多次推理、多个外部动作、等待和失败恢复的任务。连接这三者的运行时机制，就是本篇研究的 Agent Engine（Agent 执行引擎）。

本篇以“技术研究助理 Agent”为贯穿案例：用户要求研究一项技术，Agent 需要确定检索方向、读取证据、比较观点、形成报告，必要时等待人工确认。在最简单的实现中，Engine 可以是一个进程内的循环；在复杂系统中，它可能结合持久化状态、执行队列、工作者租约、人工审批与恢复调度。两者的共同点不是采用同一种框架，而是明确谁拥有 Run 的控制权、谁决定下一步、谁能实施外部副作用，以及如何证明任务合法结束。

本篇承接 Fundamentals 中的 Core Components、Execution Mechanism 和 Architecture & Design Principles，并衔接 L1 的运行环境、L2 的基础服务、L3 的模型调用能力。重点研究单个 Agent Run 的执行控制与运行语义；跨 Agent 的任务分解、团队通信与协作协议留给 L5；系统级状态治理、可靠性和安全的完整制度分别留给 H4、H7 和 H2。本篇给出可执行的标准库参考实验、测试断言及其局限；工程示例不应被误读为生产级 Agent 框架。

一、研究定位：Agent Engine 的职责与边界

1.1 从模型调用到任务执行

一次模型调用通常接受输入并返回文本、结构化数据或工具调用意图。它并不天然保证：工具已被授权、工具确实执行、执行结果已回传、任务状态已保存、重复请求不会重复扣款、审批后能够继续、取消后不会留下失控子进程。Agent Engine 需要在这些事件之间维护可检查的控制关系。

建议把 Engine 定义为：根据任务契约和 Agent 配置，驱动一个或多个有界决策步骤，协调模型调用与受控动作执行，维护 Run 的运行状态和终止语义，并将可观察结果交付上层的执行控制组件。 这里“一个或多个”不意味着 Engine 必须自行完成多 Agent 编排；单个 Engine 可以被 L5 调度，也可以在单 Agent 应用中直接接受用户任务。

1.2 职责分配

参与者	主要职责	不应混淆的边界
L6 Application	接受请求、展示状态与结果	不直接绕过 Engine 执行动作
L5 Orchestration	分配任务、协调 Agent	不必接管单 Run 的每个步骤
L4 Agent Engine	Run/Step 控制、动作调度、停止与恢复	不承担模型供应商协议适配
L3 Model Services	模型请求、路由、计量与错误映射	不决定外部工具是否获授权
L2 Platform Services	存储、队列、身份、事件服务	不替 Agent 制定任务策略
L1 Infrastructure	计算、网络、进程与隔离	不等于 Agent 决策逻辑

Engine 与 Agent 的边界尤其重要：Agent 的角色、指令、工具声明、记忆策略等属于 Agent Definition；Engine 是执行这些定义的机制。多个 Agent Definition 可以复用同一个 Engine，某个 Agent 也可能在不同环境使用不同 Engine。Agent Runtime、Agent Runner、Execution Loop 等术语在各框架中并非完全等价，实际判断必须回到职责与源码，而不能仅按名称推断。

1.3 Engine 的最小成立条件

最小可用 Engine 通常需要：任务入口、Agent 配置、决策调用、动作执行路径、有限步数或终止规则、可辨认的执行结果。持久化数据库、分布式队列、多个 Agent、容器沙箱并非定义性必要条件。 但只要存在长任务、外部副作用、多人协作或生产级可靠性目标，就需要逐步补充状态恢复、权限网关、并发约束和运行证据。

二、运行时对象模型与契约

2.1 不能混用的核心对象

• Task：用户或上层提交的目标、输入、约束与验收要求；任务可能跨多个 Run。
• AgentDefinition：角色、指令、模型策略、允许工具、行为边界的版本化声明。
• Run：一次执行实例，有唯一标识、配置快照、状态、预算和终止原因。
• Step：一次可识别的执行阶段，可能包含一次模型决策或一个受控动作；不同框架的 Step 粒度不同。
• ActionProposal：模型或规则提出的动作意图，不等于已执行的动作。
• ToolInvocation：经过解析和授权后提交的动作请求，具有唯一调用标识。
• ToolResult：可信执行路径产生的结果、错误或待审批状态。
• Checkpoint：足以恢复某个一致执行位置的持久化状态快照，不等于普通聊天记录。
• RunEvent：可追踪的运行事实，例如状态变化、工具请求、审批、预算耗尽。

2.2 建议的数据契约

以下 JSON 是中立的参考 Schema，不对应任何供应商原生接口。

{
  "run_id": "run-20261028-001",
  "task_id": "task-research-001",
  "agent_definition": {"id": "research-agent", "version": "1.4"},
  "state": "RUNNING",
  "step_index": 3,
  "budget": {"max_steps": 12, "max_tool_calls": 8, "deadline_ms": 180000},
  "usage": {"steps": 3, "tool_calls": 2},
  "checkpoint_version": 5,
  "terminal_reason": null
}

一个 ToolInvocation 至少需要 run_id、call_id、tool_id、参数、调用身份、授权上下文和可选幂等键。高风险工具还应绑定审批记录与目标资源版本。不要将模型生成的任意字符串直接当作可信的调用身份或授权证明；授权信息应由 Engine 所在的可信执行层注入。

2.3 Run 状态与 Step 状态分别建模

建议的 Run 状态：CREATED → READY → RUNNING；运行中可进入 WAITING_TOOL、WAITING_APPROVAL、PAUSED；终态区分 SUCCEEDED、FAILED、CANCELLED、BUDGET_EXCEEDED、DENIED、INSUFFICIENT_EVIDENCE。状态名是本文参考设计，并非行业统一枚举。

CREATED → READY → RUNNING ──────→ SUCCEEDED
                     │  │  │
                     │  │  ├──→ FAILED / BUDGET_EXCEEDED / DENIED
                     │  └─────→ WAITING_TOOL ───→ RUNNING
                     └────────→ WAITING_APPROVAL → RUNNING
                                          │
                                          └────→ CANCELLED
RUNNING → PAUSED → READY → RUNNING
RUNNING / WAITING_* → CANCELLED

Run 状态与 Step 状态不能简单等同：Run 可以在 RUNNING 时执行多个 Step；某个工具 Step 失败，也可能通过补偿或替代策略继续执行。终态必须携带明确原因，不宜把所有情况统一写成 done。

三、执行循环：决策、行动与反馈

3.1 典型单 Agent 循环

任务提交
  ↓ 验证任务、Agent 配置、身份和预算
创建 Run + 配置快照
  ↓
加载上下文与当前状态
  ↓
构造模型请求 ──→ L3 Model Services
  ↓
解析模型输出
  ├─ 最终答案 ─→ 验证交付契约 ─→ 终止
  ├─ 工具意图 ─→ Schema 校验 ─→ 授权/审批
  │                              ↓
  │                         可信工具网关
  │                              ↓
  │                         结果写入状态
  │                              ↓
  ├──────────────────────────────┘
  └─ 无效/错误 ─→ 有界修复、失败或升级
  ↓
预算/取消/截止时间检查 → 下一 Step

模型可能一次返回多个工具调用。Engine 必须确定是否允许并行、是否存在依赖、怎样排序结果、部分成功后如何处理；不能仅因协议允许并行调用，就假定所有工具无副作用或彼此独立。

3.2 决策权与执行权分离

模型可以提出 search_documents(query)、read_document(id)、publish_report(path)，但 Engine 需要分别完成：参数解析、工具注册表查找、权限校验、审批策略、实际调用和结果登记。尤其是 publish_report 一类不可逆动作，应该在可信工具层设置强制门禁，而不是依赖 Prompt 中的“未经允许不要发布”。

3.3 模型响应的三种不同语义

1. Final：模型认为可以结束；Engine 仍需验证输出格式、任务硬约束与终止资格。
2. Action：模型建议调用工具；Engine 执行前必须检查工具声明、参数和授权。
3. Continuation：模型要求继续推理或补充信息；Engine 检查预算和循环检测策略。

Structured Outputs 和工具调用协议可以减少解析歧义，但协议有效不等于任务正确。模型服务层提供有效 JSON 也不能替代业务层对目标资源、权限、状态版本和副作用的验证。

3.4 循环停止与活性

停止条件至少包括：达到合法成功、明确失败、用户取消、超时、步数/费用预算耗尽、审批等待、不可恢复工具错误。可选的重复调用检测可以识别连续相同参数或无进展循环，但应防止误杀需要轮询的合法任务。停止策略需要同时满足安全性（不能越权、不能无限消耗）与活性（在可完成条件下能够推进）。

四、状态、上下文与检查点

4.1 三种状态不能混为一谈

• 业务状态：研究主题、证据、草稿、任务完成情况。
• 执行状态：当前 Step、等待中的工具、重试次数、预算、取消标记。
• 模型上下文：发送给模型的消息、摘要、工具描述和引用材料。

模型上下文通常只是执行状态的一个投影。对话被压缩后，不能因此丢失工具调用去重键、审批决定、已支付费用等可信执行事实。应为不同状态明确所有者、更新方式与保留策略。

4.2 Checkpoint 的一致性边界

一次 Checkpoint 应能说明“从哪里继续”和“哪些副作用已经发生”。对于无副作用的纯计算步骤，恢复可以重新计算；对于外部支付、邮件发送或文件发布，恢复必须先检查外部操作的提交记录或幂等状态。只保存消息历史无法保证安全恢复。

推荐将 Run 状态变更与待执行动作的提交意图在同一可信事务边界中记录；跨数据库和外部 API 时，通常需要 Outbox、幂等键、结果核对或人工仲裁。数据库事务无法自动覆盖第三方 API。

4.3 事件日志与状态快照

事件日志适合审计和重放诊断，状态快照适合快速恢复。Event Sourcing 是以事件作为主要事实来源的设计方式；并非所有事件日志都是 Event Sourcing。Workflow Replay 则可能重新运行确定性工作流代码，并复用历史记录的活动结果。三者不能作为同义词使用。

五、工具执行、授权与外部副作用

5.1 工具网关的执行链

模型动作意图（不可信）
 → 结构与类型校验
 → 工具注册表 / 版本解析
 → 身份与资源授权
 → 审批策略
 → 调用预算与限流
 → 幂等/去重检查
 → 沙箱或外部服务执行
 → 结果/错误分类
 → 审计事件 + 状态更新

工具结果也可能包含提示注入或恶意数据。Engine 应将其作为低信任输入交给模型，不应允许工具返回文本修改系统权限、注册新工具或绕过审批。

5.2 投递与执行语义

语义	可能发生的行为	主要工程措施
At-most-once	失败时可能丢失动作	不自动重试、明确失败
At-least-once	故障后可能重复动作	幂等键、去重与对账
Effectively-once	重复请求的业务效果受控	业务幂等、状态核对
Exactly-once	仅在特定封闭边界可严格保证	明确事务范围与前提

“工作流引擎可以恢复”不意味着外部 API 只会执行一次。特别是调用已经到达外部系统、但响应在网络中丢失时，Engine 无法仅凭本地超时判断是否发生副作用。

5.3 人工审批的正确位置

人工审批应作用于具体动作及其参数，而不只是笼统批准“这个 Agent 可以操作”。审批记录至少包含 Run、工具、目标资源、参数摘要、申请者、批准者、过期时间和授权范围。恢复时必须校验审批是否仍适用于当前参数与资源版本；审批过期或参数变化应重新申请。

六、并发、调度与取消

6.1 单 Run 内并发

并行工具适合相互独立的只读检索，不适合默认并行修改同一文档、同一账户或同一外部资源。若允许并行，需要定义结果合并规则、共享状态冲突处理、部分失败策略与并发上限。

6.2 多 Run 并发

多用户或多任务同时运行时，Engine 应对每个 Run 提供独立状态和预算。任务队列可以提供分发，Worker 租约可以降低双重处理概率，但仍需针对租约过期和重复交付设计幂等保护。并发容量规划涉及 L1/L2；具体资源配额与成本治理延伸至 H8。

6.3 取消不是一个布尔值

取消可能发生在模型流式响应、工具排队、子进程运行、审批等待或外部 API 请求过程中。Engine 应传播取消意图并停止可控的后续步骤，但不能承诺撤销已经提交的外部副作用。终止前应记录哪些动作已完成、哪些状态未知、哪些需要补偿或人工检查。

七、故障分类与恢复策略

故障位置	典型故障	Engine 应对
模型调用	超时、限流、响应格式异常	分类、有限重试或失败
工具调用	连接中断、权限拒绝	不越权重试、保留证据
状态存储	冲突、写入失败	乐观并发控制、停机保护
Worker	崩溃、租约过期	检查点恢复、动作去重
人工审批	超时、撤销、参数变化	保持等待或拒绝
任务逻辑	无进展循环、证据不足	有界终止或升级

重试策略必须区分可重试与不可重试错误；对于非幂等外部操作，网络超时后的直接重试可能造成重复副作用。退避、抖动、最大尝试次数和截止时间是常见机制，但具体阈值必须通过任务需求和实验确定。

八、Engine 与 L3、L5、H 系列专题的边界

8.1 与 L3 Model Services

L3 负责模型端点、协议适配、路由、用量、供应商错误；L4 负责为什么调用模型、如何解释返回的动作、是否继续执行。L3 的“模型请求重试”不等同于 L4 的“重新执行一个 Agent Step”；两者叠加可能放大调用次数，应共享截止时间和可观察的重试预算。

8.2 与 L5 Orchestration & Collaboration

L4 管理一个 Agent Run 的内部步骤；L5 负责多个 Agent 或工作单元之间的依赖、任务分配、交接与聚合。实际框架可能将两层合并实现，这是一种部署或代码组织选择，不改变分析职责的区别。

8.3 与 H4/H7/H2

本篇说明 Engine 为状态恢复、可靠性和安全提供哪些执行钩子；H4 将系统化研究状态存储与一致性，H7 研究端到端可靠性目标与故障演练，H2 研究跨层威胁模型与安全控制。不要在 L4 中重复完整治理体系，但必须解释其与执行语义直接相关的硬边界。

九、真实框架与技术路线对照

9.1 OpenAI Agents SDK

其官方文档描述 Runner/运行循环、工具调用、handoff、guardrails、sessions 等能力。适合研究进程内 Agent 执行与工具调用编排。具体版本的运行循环行为、会话存储和错误语义应以对应版本源码与文档为准；不应据此推断所有外部工具天然支持持久化恢复或精确一次副作用。

9.2 LangGraph

其官方文档围绕图状态、节点执行、持久化 Checkpointer、interrupt 与 durable execution 展开。适合研究显式状态转换、暂停恢复与工作流控制。持久化是否生效取决于配置与存储实现；恢复后外部副作用仍需按照幂等与任务语义设计。

9.3 Temporal

Temporal 是通用的持久化工作流执行技术，不等同于 Agent Engine 的认知决策层。它可以承载长任务、活动重试、计时器与恢复机制；模型推理和工具动作可以作为活动接入，但 Workflow 代码的确定性要求、活动副作用及幂等仍需单独处理。

9.4 三种常见组合

组合	优点	主要代价
自建轻量循环	结构透明、依赖少	恢复与治理需自行实现
Agent SDK / 图执行框架	开发效率高、执行抽象成熟	需理解框架语义与版本
Agent 层 + 持久化工作流	适合长任务与外部协作	系统复杂度和运维成本增加

选型原则：先从任务时长、外部副作用风险、暂停恢复需求、并发规模、团队维护能力和验证成本出发，而不是从框架流行度出发。

十、贯穿案例：技术研究助理的执行设计

用户任务：“研究某种 Agent 运行框架，给出可核验资料和技术比较。”

1. 任务入口：记录问题、允许来源、预算、交付格式、截止时间。
2. Run 创建：绑定 Agent Definition 版本与模型策略，生成 Run ID。
3. 决策步骤：请求 L3 模型，提出检索、阅读或写作动作。
4. 工具执行：工具网关验证检索权限和参数，记录来源 ID。
5. 证据更新：把来源、摘要、主张映射写入业务状态，而不是仅追加自然语言消息。
6. 质量检查：对引用可访问性、证据支持和报告结构进行校验。
7. 人工门禁：如需公开发布，进入 WAITING_APPROVAL，不得自动越过。
8. 结束与交付：记录成功、证据不足、取消或失败等明确终态。

该案例可先用单进程 Engine + 本地数据库实现。若需要数小时运行和人工审批，再增加持久化检查点；若需要大量并发任务，再引入任务队列和 Worker；若存在不可信代码执行，则在工具侧增加独立沙箱。扩展顺序应由实际需求触发。

十一、可复现实验：最小 Agent Engine

本节给出单文件 Python 标准库实验，验证 Run 状态、动作校验、授权、预算、工具执行、事件和终止行为。它不接入真实 LLM，使用确定性决策替身；因此只证明 Engine 控制逻辑的局部性质，不证明模型推理质量、持久化恢复或分布式执行安全。配套文件 L4-Agent-System-Agent-Engine-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 L4-Agent-System-Agent-Engine-v1.1-demo.py。

11.1 参考实现

from __future__ import annotations

from dataclasses import dataclass, field
from enum import Enum

class Status(str, Enum):
    CREATED = "CREATED"
    RUNNING = "RUNNING"
    SUCCEEDED = "SUCCEEDED"
    DENIED = "DENIED"
    BUDGET_EXCEEDED = "BUDGET_EXCEEDED"

@dataclass
class Run:
    run_id: str
    max_steps: int = 3
    status: Status = Status.CREATED
    steps: int = 0
    events: list = field(default_factory=list)

class Engine:
    def __init__(self, allowed_tools):
        self.allowed_tools = dict(allowed_tools)

    def execute(self, run, proposals):
        run.status = Status.RUNNING
        run.events.append(("RUN_STARTED", run.run_id))
        for action in proposals:
            if run.steps >= run.max_steps:
                run.status = Status.BUDGET_EXCEEDED
                run.events.append(("BUDGET_EXCEEDED", run.steps))
                return run
            run.steps += 1
            if action["type"] == "final":
                run.status = Status.SUCCEEDED
                run.events.append(("RUN_SUCCEEDED", action["text"]))
                return run
            if action["type"] != "tool" or action.get("name") not in self.allowed_tools:
                run.status = Status.DENIED
                run.events.append(("ACTION_DENIED", action))
                return run
            result = self.allowed_tools[action["name"]](action.get("args", {}))
            run.events.append(("TOOL_RESULT", result))
        run.status = Status.BUDGET_EXCEEDED
        run.events.append(("NO_FINAL", run.steps))
        return run

if __name__ == "__main__":
    engine = Engine({"search": lambda args: ["doc-001"]})
    good = engine.execute(Run("good"), [
        {"type": "tool", "name": "search", "args": {"q": "agent engine"}},
        {"type": "final", "text": "报告已完成"},
    ])
    assert good.status == Status.SUCCEEDED and good.steps == 2
    denied = engine.execute(Run("denied"), [
        {"type": "tool", "name": "publish", "args": {"path": "report.md"}}
    ])
    assert denied.status == Status.DENIED
    limited = engine.execute(Run("limited", max_steps=1), [
        {"type": "tool", "name": "search", "args": {}},
        {"type": "final", "text": "late"},
    ])
    assert limited.status == Status.BUDGET_EXCEEDED
    print("3 checks passed")

本地执行通过：输出 3 checks passed。

11.2 实验边界与扩展方向

代码仅用于说明控制权不在模型输出中。它没有持久化状态、真实工具参数 Schema、异常分类、异步取消、审批、租约、幂等键或并发安全机制；allowed_tools 只是白名单演示，不是完整的资源级授权。生产实现至少需要补充：工具参数验证、可信身份、状态存储、异常捕获、取消传播、审计日志、外部副作用保护、配置版本和集成测试。

11.3 应当进一步开展的实验

实验	关键断言	适用边界
模型返回未知工具	不发生工具副作用	工具注册表
达到 Step 上限	明确预算终止	资源治理
审批中断与恢复	无批准不执行动作	人工门禁
Worker 崩溃后重启	从一致检查点继续	持久化层
外部响应丢失	不产生重复业务效果	幂等/对账
并行修改同一状态	冲突被检测或串行化	并发控制
用户取消子进程	可控进程停止、状态可诊断	运行环境

以上表格是待实施验证计划，不是已完成的测试报告。

十二、工程实施与验收方法

12.1 建议的实施顺序

第一阶段建立 Task/Run/Step/Action 的数据契约和最小执行循环；第二阶段引入可信工具网关、预算和终止语义；第三阶段增加状态持久化、事件记录、审批与取消；第四阶段针对真实长任务引入队列、Worker、幂等和恢复机制；第五阶段开展故障注入、真实模型对照、成本评估和安全验证。每阶段都应有可检查的验收标准，而不是仅以“功能可以演示”为完成依据。

12.2 发布前检查清单

• [ ] Run ID、Agent Definition 版本、模型策略与任务约束可追溯。
• [ ] 模型提议与实际工具执行事件严格区分。
• [ ] 工具参数校验、资源授权和审批在可信执行层强制实施。
• [ ] Run 终态可区分成功、失败、取消、拒绝与预算耗尽。
• [ ] 模型与工具重试均有上限，并共享有效截止时间。
• [ ] 对不可逆动作有幂等、对账或人工恢复策略。
• [ ] Checkpoint 的恢复点与副作用提交关系已明确。
• [ ] 并行工具和多 Run 的共享状态冲突有处理规则。
• [ ] 取消能够传播到受控任务，并记录无法撤销的动作。
• [ ] 测试覆盖正常、故障、权限、预算、恢复和重复执行。
• [ ] 运行日志按数据敏感性脱敏、限权并设定保留期。

十三、研究结论与下一专题

Agent Engine 的核心价值，不是让模型“多调用几次工具”，而是把不确定的模型决策放入可执行、可约束、可追溯的任务生命周期。一个合理的 Engine 至少需要清晰的 Run/Step 契约、模型动作与可信执行的分离、有界循环、明确终止语义以及可观察的状态变化。长任务与生产场景则进一步要求检查点、授权、幂等、审批、取消、故障恢复和并发治理。

工程设计上应坚持三项判断：模型建议不是执行事实；持久化恢复不等于外部副作用精确一次；框架功能存在不等于系统已满足特定任务的可靠性要求。 Engine 可以是轻量循环，也可以与图执行框架或持久化工作流组合，但最终选型必须由任务风险、恢复需求、状态边界和维护成本共同决定。

下一专题 「L5 · 如何编排任务并组织多个 Agent 协作？ - Orchestration & Collaboration」 将在单 Run 执行控制之上，研究任务分解、依赖管理、Agent 间通信、协作协议、交接与汇总、冲突仲裁和多 Agent 系统的控制机制。

附录 A：参考文献与原始资料入口

以下为可供复核的官方资料入口。文章依据公开技术概念进行综合研究；本次未对各框架最新版本源码逐行核验，实际实施时应锁定版本并复核行为。

1. OpenAI Agents SDK - Running agents：openai.github.io/openai-agents-python/running_agents。研究 Runner、执行循环、工具调用与终止行为。
2. OpenAI Agents SDK - SDK Overview：openai.github.io/openai-agents-python。研究 Agent、tools、handoffs、guardrails 的抽象。
3. OpenAI Agents SDK - Sessions：openai.github.io/openai-agents-python/sessions。研究会话与历史管理；会话历史不等于完整执行检查点。
4. LangGraph - Persistence：docs.langchain.com/oss/python/langgraph/persistence。研究图状态、Checkpointer、线程与状态恢复。
5. LangGraph - Durable Execution：docs.langchain.com/oss/python/langgraph/durable-execution。研究持久执行、重放与副作用处理。
6. LangGraph - Interrupts：docs.langchain.com/oss/python/langgraph/interrupts。研究暂停、人工输入与恢复。
7. Temporal - Workflow Execution：docs.temporal.io/workflow-execution。研究工作流、事件历史与执行恢复。
8. Temporal - Activity Execution：docs.temporal.io/activity-execution。研究活动执行、重试与外部副作用。
9. MCP - Specification：modelcontextprotocol.io/specification。研究工具协议边界；MCP 本身不替代 Engine 的运行控制。
10. OpenTelemetry - Documentation：opentelemetry.io/docs。研究追踪、指标与日志的通用观测基础。
11. OWASP - GenAI Security Project：genai.owasp.org。研究 Agent 工具使用、提示注入与权限边界相关风险。

附录 B：研究证据与验证声明

研究性质。 本篇是 Agent Engine 的技术原理与工程实践研究，包含对公开框架设计的归纳和中立参考架构；所提出的对象命名、状态枚举、接口 JSON 和分层表格不是统一行业标准。

事实与推断。 对 OpenAI Agents SDK、LangGraph、Temporal 的描述为基于公开文档概念的架构级比较；具体 API、执行行为、错误处理和持久化保证应以锁定版本的官方文档及源码为准。本篇没有宣称完成这些框架的源码审计或实机对照。

实验范围。 第十一节提供纯 Python 标准库参考实验。实验使用脚本化动作替身和本地假工具，不调用真实模型、真实网络或持久化工作流。它用于检验控制循环、白名单拒绝与步数预算等确定性行为；不能证明真实模型任务成功率、分布式恢复、外部 API 幂等、安全沙箱或生产可靠性。

待验证事项。 审批恢复、并行一致性、Worker 崩溃、外部响应丢失、工具幂等、取消传播、真实模型与框架集成均需单独构建环境和运行实验。若将本篇用于生产架构决策，应补充版本锁定、风险评审、故障演练、成本测量及真实任务回归测试。