03 · Agent System 如何运行？ - Execution Mechanism

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：执行机制、状态管理与可靠性工程研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent System 如何把一次任务请求转化为可控的执行过程？任务、Run、Agent 决策、工具执行、状态更新、事件、调度、暂停恢复和终止如何衔接？如何通过状态机、事件轨迹、执行契约与工程实验验证其运行机制？

专题导读

本篇属 Fundamentals。静态组件图无法回答一次任务在失败、取消、恢复或并发条件下究竟发生了什么。Agent System 的执行机制涉及任务身份、决策循环、授权边界、外部副作用、状态推进和终止语义；尤其需要避免把“模型说要调用工具”误认为“工具已经成功执行”。

本篇沿 Task - Run - Step - Event 的时间轴研究执行过程，并补充交付语义、恢复方式和故障注入的可验证条件。原有标准库示例只覆盖其明确断言的行为，不能据此推断真实模型、分布式存储或生产环境具有相同可靠性。

一、从静态组件图转向动态执行过程

理解 Agent System 不能停留在“Agent + LLM + Tools + Database + Queue”的结构图。系统运行意味着：外部请求被转化为任务，任务被分配给一次或多次执行，执行器根据 Agent 的行动意图调度真实操作，将观察结果写回状态，再判断继续、暂停、失败还是完成。最关键的研究对象不是某个组件，而是状态在时间上的变化、控制权的转移和外部副作用的发生。

一个最小闭环可以写作：Task accepted → Run started → Decision produced → Action authorized → Action executed → Observation recorded → State updated → Next decision / terminal。其中“Decision produced”可能来自模型、规则或混合决策；“Action executed”由可信执行代码承担。二者不能混同：模型声称“已经发送邮件”不等于邮件实际发送成功。

本篇区分三种粒度：Task 是业务请求及其完成契约；Run 是一次具体执行尝试，包含其身份、配置快照和运行状态；Step/Turn 是 Run 内部的一次决策或执行单元。一个 Task 可能对应多个 Run（如重新执行、补偿后的新尝试），一个 Run 可能包含多个模型轮次、工具调用与暂停恢复。框架对 turn、step、run 的具体定义可能不同，跨系统追踪时必须显式映射。

二、运行契约与状态对象

2.1 最小对象模型

对象	关键字段示例	所有权与约束
Task	task_id, input, success_criteria, deadline, requester	任务服务持有；定义业务目标和最终结果
Run	run_id, task_id, agent_version, status, attempt, started_at	运行管理器持有；一次执行尝试
ExecutionState	run_id, step, context, observations, pending_actions, budget	执行引擎更新；可选择持久化
ActionIntent	action_id, kind, arguments, requested_by	决策结果；尚未发生外部操作
ActionResult	action_id, status, output/error, duration	执行器返回；关联原始行动
Event	event_id, run_id, sequence, type, payload, timestamp	观测/审计；需考虑事件排序和脱敏
Checkpoint	run_id, version, serialized_state, cursor	恢复边界；必须记录与外部操作的关系

一个重要区别是业务状态、执行状态和观测事件。业务状态表示报告是否完成；执行状态表示当前在检索、等待审批还是准备写作；观测事件表示“第 17 步开始调用搜索工具”。事件日志可用于重建部分状态，但只有当事件格式、排序、持久化和重放语义满足条件时，才能将其视为权威事件源；普通日志不具备这样的保证。

2.2 Run 状态机

stateDiagram-v2
    [*] --> CREATED
    CREATED --> QUEUED: accept
    QUEUED --> RUNNING: acquire lease
    RUNNING --> WAITING_APPROVAL: risky action
    WAITING_APPROVAL --> RUNNING: approved + resume
    WAITING_APPROVAL --> CANCELLED: rejected/cancelled
    RUNNING --> WAITING_EXTERNAL: callback/timer
    WAITING_EXTERNAL --> RUNNING: signal/resume
    RUNNING --> SUCCEEDED: completion validated
    RUNNING --> FAILED: unrecoverable error
    RUNNING --> CANCELLED: cancellation acknowledged
    RUNNING --> TIMED_OUT: deadline exceeded
    RUNNING --> QUEUED: retryable worker failure
    SUCCEEDED --> [*]
    FAILED --> [*]
    CANCELLED --> [*]
    TIMED_OUT --> [*]

该图是教学用参考状态机，不是所有系统必须实现的标准。真实系统可能有 PAUSING、CANCELLING、COMPENSATING、SUSPENDED 等中间状态。尤其要区分取消请求与取消已生效：请求取消时，某个外部工具可能仍在执行，不能立即宣称副作用已撤销。

状态转移必须由系统校验。例如 SUCCEEDED → RUNNING 一般不应直接允许；恢复一个已经完成的业务任务通常应创建新的 Run 或明确的新版本执行。对并发更新，可使用版本号/CAS 防止两个 Worker 同时推进同一 Run。

三、一次任务的端到端时序

sequenceDiagram
    participant U as User/API
    participant T as Task Service
    participant Q as Scheduler/Queue
    participant R as Agent Runtime
    participant M as Model/Policy
    participant G as Guard/Tool Executor
    participant S as State Store
    participant O as Observability
    U->>T: Submit(task, idempotency_key)
    T->>S: Persist task + initial run
    T-->>U: task_id/run_id
    T->>Q: Enqueue(run_id)
    Q->>R: Dispatch(run_id, lease)
    R->>S: Load state/version
    R->>M: Decide(context, goal, budget)
    M-->>R: ActionIntent(tool,args)
    R->>G: Authorize and validate
    G-->>R: allowed
    R->>S: Record pending action
    R->>G: Execute(action_id,args)
    G-->>R: ActionResult
    R->>S: Commit observation + state
    R->>O: Emit trace/event
    R->>M: Decide(next state)
    M-->>R: Final candidate
    R->>R: Validate completion criteria
    R->>S: Commit terminal status
    R-->>T: Result
    T-->>U: Result/status

这是一个可能的异步部署时序；小系统可以把 Task Service、Scheduler、Runtime 合并在一个进程。序列图中 Record pending action 与实际执行之间仍有故障窗口；它不能凭空提供“恰好一次外部副作用”。要实现安全重试，需要下游幂等键、去重记录、状态协调或补偿策略。

3.1 接收与初始化

任务入口应完成身份鉴别、输入校验、任务契约确定和初始状态创建。task_id 标识业务请求，run_id 标识具体执行，idempotency_key 用于防止客户端网络重试意外创建重复任务。接受任务不等于完成任务：异步系统通常先返回标识符，再通过轮询、事件或回调报告进度。

3.2 获取执行权

单进程实现可以直接调用 Runtime；多 Worker 实现通常由调度器分配任务。关键问题包括任务优先级、租约（lease）、心跳、并发配额、重复投递和 Worker 崩溃后的重新领取。队列交付的是执行机会，不保证下游业务操作只发生一次。若 Worker A 租约到期而工具调用仍未结束，Worker B 可能重新接管，必须防止并发副作用。

3.3 形成决策与校验行动

Runtime 读取任务状态，构造 Agent 可见上下文，并调用模型或规则策略。决策结果应转换为受约束的行动意图：工具名、参数、预期结果类型和行动标识。随后进行工具白名单、参数模式、资源范围、预算、审批与风险校验。安全校验必须由模型之外的可信代码实施；提示词本身不能替代权限执行。

3.4 执行与反馈

工具执行器执行实际操作，返回结构化结果或明确的错误类型。执行结果必须与 action_id 关联，避免并发工具调用时结果串线。执行失败需要区分参数错误、授权失败、限流、超时、临时网络异常和不可逆的业务失败；不同错误不应统一无条件重试。

3.5 更新状态与选择下一步

运行时将结果写入状态并形成下一轮可见上下文，随后继续决策、等待事件或完成任务。对于长任务，必须控制上下文增长，并区分 Agent 可见信息与系统内部完整事件记录。只有在满足任务契约、结果校验和必要的输出审查后，才能将 Run 标记为成功。达到步数、预算或截止时间时，应产生明确的终止原因，而不是无限循环。

四、控制流、数据流与状态流的三重视角

控制流回答“谁决定下一步、谁有权阻止”。常见控制者包括任务调度器、Agent Runtime、Agent 决策策略、审批系统和超时控制器。一个 Agent 可以建议调用工具，但授权系统可以拒绝；调度器可以暂停 Run，但不应随意篡改 Agent 的任务语义。

数据流回答“哪些信息从哪里来、流向哪里”。用户输入、检索结果、模型响应、工具返回、报告草稿和最终产物具有不同的敏感度和保留要求。不能将完整工具响应无条件复制到所有 Agent 的上下文中；应考虑截断、脱敏、引用标识和来源追踪。

状态流回答“哪些变化必须被记录，如何保证恢复后的执行一致”。例如 step=3 并不足以恢复任务，仍需知道第三步的工具是否已经执行、审批是否已经通过、结果是否已写入状态，以及模型下一轮需要看到什么。

运行问题	控制流视角	数据流视角	状态流视角
调用搜索	谁允许调用	查询与结果如何传输	记录查询、结果和行动 ID
等待审批	谁批准	展示什么风险信息	保存 pending action 和审批状态
工具超时	谁触发取消	部分输出如何处理	标记未知结果/可重试条件
任务恢复	谁重新调度	从何处重新加载上下文	检查点与副作用去重
任务完成	谁验证完成	最终结果如何交付	原子化记录终态与产物引用

五、执行语义：同步、异步、流式与事件驱动

同步调用适用于短任务，客户端等待结果；实现简单，但受请求超时和连接生命周期限制。异步任务先返回任务标识，后台继续执行；适合长任务和批量处理，但需要任务状态、结果查询与通知机制。流式输出提供 token、步骤或事件的增量可见性；流式事件是展示渠道，不等于持久化事件日志。事件驱动依靠定时器、外部回调或消息触发后续执行；需要处理重复事件、乱序和过期事件。

这些方式可以组合。例如长任务以异步方式执行，同时通过 Server-Sent Events 推送状态，等待人工审批时暂停，并在收到审批事件后恢复。设计时应分别确定客户端连接生命周期、任务生命周期、Agent Run 生命周期，三者并不必然相同。

六、暂停、恢复、重试与外部副作用

6.1 暂停不是终止

审批、定时等待和外部回调通常属于预期暂停。暂停时应保存可恢复的执行状态、待处理动作及其标识、审批上下文、预算消耗与版本信息。恢复时必须继续同一个逻辑执行上下文，不能简单地重新提交用户原始请求，否则可能重复模型决策或外部操作。

6.2 Checkpoint 与 Event Replay 是不同机制

Checkpoint 恢复保存某个时间点的状态快照，恢复时从快照继续。事件历史重放保存决定执行轨迹的有序事件，通过确定性重放恢复工作流状态。二者可以结合，但不能混称。

Temporal 官方文档说明其 Workflow 利用 Event History 重放确定性工作流逻辑；外部交互通常放在 Activity 中，重放已完成 Activity 时复用记录结果。这里的“重放不重新执行已完成 Activity”不意味着实际 Activity 在所有故障条件下只能运行一次：Activity 的重试和外部副作用仍需幂等设计。来源：Temporal Workflows、Tasks 官方文档（见第十二节）。

6.3 至少一次执行与幂等

在常见的故障恢复方案中，任务或工具动作可能被重新尝试。假设执行器向支付接口发起请求后进程崩溃，但尚未保存返回结果，恢复时无法仅凭本地状态判断支付是否成功。安全做法可能包括：传递稳定的业务幂等键、查询下游操作状态、记录 outbox/inbox、避免盲目重试，或在无法保证原子性时采用补偿流程。

必须区分“消息至少一次投递”“工具调用至少一次尝试”和“业务副作用恰好一次”。这三者不是同一承诺。所谓端到端 exactly-once 通常需要严格限定范围和下游系统的协作，不能由队列或 Agent Runtime 单独保证。

6.4 失败分类与恢复决策

故障	建议策略	主要风险
模型 API 429/短暂 5xx	有界退避、预算控制、可选切换	重复收费、延迟累积
工具参数校验失败	返回可诊断错误或重新决策	无意义重试循环
工具执行超时	判断结果是否未知，必要时查询下游	副作用已发生但本地未知
Worker 崩溃	租约回收、恢复检查点	重复执行、双 Worker
审批被拒绝	记录拒绝并调整计划/结束	绕过审批
任务截止时间到达	取消可取消步骤、报告部分进度	取消不等于撤销外部操作
输出未达验收标准	有界返工或失败交付	无限制自我修复

七、多 Agent 执行的系统级变化

单 Agent 运行主要关注单条决策 - 行动链；多 Agent 系统还需处理控制权分配、任务依赖、消息传递、共享状态与结果整合。典型模式包括：主管分派、顺序交接、并行扇出/汇总、共享黑板、事件订阅。模式名称不能替代协议定义：需要明确消息结构、相关 ID、超时、重试、终止与责任归属。

Task
 ├─ Research Run A ─┐
 ├─ Research Run B ─┼─ Join/Validate ─ Report Run ─ Review ─ Deliver
 └─ Research Run C ─┘

上述流程不必然需要四个 Agent，也可以由一个 Agent 的多次调用加工作流编排实现。是否拆分为多个 Agent，应比较专业分工收益与通信成本、状态同步复杂度、错误传播和可观测性负担。具体编排算法与协作协议留待 L5 专题深入研究。

八、真实技术路线对照：不要把不同 Runtime 混成一个模型

技术路线	已核对的官方机制	对本篇的启示	不能由此推断
OpenAI Agents SDK（Python）	Runner.run、run_sync、`run_streame…	Agent loop 可由应用内 SDK 承担；Run 内可能发生多个模…	SDK 自动提供所有分布式任务队列和业务 exactly-once
OpenAI Agents API	官方区分托管 Harness、应用内 SDK 与底层 Responses API	“谁持有 Runtime 和状态”是系统边界选择	托管服务与自建系统在数据、隔离和运行语义上完全相同
Temporal Workflow	基于 Event History 的确定性重放，外部工作放在 Activities	长任务可采用 durable workflow 模型管理恢复	任意 Python Agent loop 可以无改造直接安全重放

官方资料核查重点：OpenAI Agents SDK 文档明确说明 Runner 在模型输出为工具调用时执行工具并继续循环，handoff 则切换 Agent；官方审批文档说明中断后从保存状态恢复。Temporal 官方文档明确说明 Workflow 重放与 Activity 的边界。它们解决的问题有交集，但执行语义和抽象层级并不相同。具体版本与 API 以引用页面和项目锁定版本为准。

九、工程实验：用可执行状态机验证控制语义

以下标准库示例仅验证状态转移、审批暂停、行动去重、预算终止四项逻辑。它不调用真实 LLM、外部服务或持久化数据库，不能证明分布式故障恢复或生产级可靠性。配套文件 03-Agent-System-Execution-Mechanism-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 03-Agent-System-Execution-Mechanism-v1.1-demo.py。

from __future__ import annotations
from dataclasses import dataclass, field
import unittest

TERMINAL = {"SUCCEEDED", "FAILED", "CANCELLED"}
ALLOWED = {
    "CREATED": {"RUNNING", "CANCELLED"},
    "RUNNING": {"WAITING_APPROVAL", "SUCCEEDED", "FAILED", "CANCELLED"},
    "WAITING_APPROVAL": {"RUNNING", "CANCELLED"},
    "SUCCEEDED": set(), "FAILED": set(), "CANCELLED": set(),
}

@dataclass
class Run:
    status: str = "CREATED"
    steps: int = 0
    max_steps: int = 3
    completed_actions: set = field(default_factory=set)
    pending_action: str | None = None
    events: list = field(default_factory=list)

    def transition(self, new_status):
        if new_status not in ALLOWED[self.status]:
            raise ValueError(f"invalid transition: {self.status} -> {new_status}")
        self.events.append(("TRANSITION", self.status, new_status))
        self.status = new_status

    def propose(self, action_id, requires_approval=False):
        if self.status != "RUNNING":
            raise RuntimeError("run is not executing")
        if self.steps >= self.max_steps:
            self.transition("FAILED")
            return "BUDGET_EXHAUSTED"
        self.steps += 1
        if action_id in self.completed_actions:
            self.events.append(("DEDUPLICATED", action_id))
            return "ALREADY_RECORDED"
        if requires_approval:
            self.pending_action = action_id
            self.transition("WAITING_APPROVAL")
            return "APPROVAL_REQUIRED"
        self.completed_actions.add(action_id)
        self.events.append(("ACTION_RECORDED", action_id))
        return "RECORDED"

    def approve(self, approved):
        if self.status != "WAITING_APPROVAL" or not self.pending_action:
            raise RuntimeError("no pending approval")
        action_id = self.pending_action
        self.pending_action = None
        if not approved:
            self.transition("CANCELLED")
            return "REJECTED"
        self.transition("RUNNING")
        self.completed_actions.add(action_id)
        self.events.append(("ACTION_RECORDED", action_id))
        return "APPROVED_AND_RECORDED"

class ExecutionTests(unittest.TestCase):
    def test_approval_pause_resume(self):
        r = Run(); r.transition("RUNNING")
        self.assertEqual(r.propose("send:1", True), "APPROVAL_REQUIRED")
        self.assertEqual(r.status, "WAITING_APPROVAL")
        self.assertEqual(r.approve(True), "APPROVED_AND_RECORDED")
        self.assertIn("send:1", r.completed_actions)

    def test_rejection(self):
        r = Run(); r.transition("RUNNING"); r.propose("write:1", True)
        self.assertEqual(r.approve(False), "REJECTED")
        self.assertEqual(r.status, "CANCELLED")

    def test_deduplication(self):
        r = Run(); r.transition("RUNNING")
        self.assertEqual(r.propose("search:1"), "RECORDED")
        self.assertEqual(r.propose("search:1"), "ALREADY_RECORDED")

    def test_budget_and_terminal(self):
        r = Run(max_steps=1); r.transition("RUNNING")
        r.propose("search:1")
        self.assertEqual(r.propose("search:2"), "BUDGET_EXHAUSTED")
        self.assertEqual(r.status, "FAILED")
        with self.assertRaises(ValueError):
            r.transition("RUNNING")

if __name__ == "__main__":
    unittest.main(verbosity=2)

本地执行通过：4 项测试全部 OK。

实验边界： completed_actions 只表示当前内存中“记录了行动”，并未真实执行工具；其去重不能防止跨进程重复副作用。示例把审批通过后的动作视为“记录完成”，现实系统必须在审批后调用真实执行器，并区分 APPROVED、DISPATCHED、COMPLETED 和 UNKNOWN。状态迁移没有数据库事务和并发控制。此示例的价值是让控制语义可测试，而不是展示生产级执行引擎。

十、设计判断：如何选择执行机制

任务条件	可优先考虑	必须额外验证
短时、低风险、低并发	应用内 Runner + 内存状态	超时、预算、工具授权
长任务、需要暂停恢复	持久化状态/检查点或 durable workflow	恢复点、副作用幂等、版本兼容
大量并发任务	队列 + Worker + 租约 + 共享状态	重复投递、租约争用、背压
高风险外部操作	审批 + 权限执行点 + 审计	审批对象与实际参数绑定、TOCTOU
多 Agent 协作	显式任务图/协调协议	责任归属、共享状态、冲突处理
严格可审计	关联 ID、结构化事件、版本快照	脱敏、事件完整性、保留策略

这里的“可优先考虑”是设计建议，不是特定框架性能结论。系统架构应从任务契约、失败代价、并发规模和运维能力推导，而不是先选复杂框架再寻找使用场景。

十一、研究自检与常见误区

1. 把 Agent loop 当作完整系统运行机制。 Loop 解释单次执行如何推进，却不足以解释任务接收、调度、租约、恢复和交付。
2. 把模型输出当作外部事实。 必须区分行动意图、授权、实际执行和结果确认。
3. 把暂停当作新任务。 续接应保留原有状态、预算和 pending action；否则可能重复执行。
4. 把日志当作事件源。 普通日志可能丢失、乱序或被采样，不能直接支持确定性重放。
5. 把重试当作可靠性。 未考虑幂等和未知结果的重试可能扩大损害。
6. 把成功输出当作成功执行。 应验证任务契约、外部操作与系统状态。
7. 把多 Agent 当作天然更高级。 协作带来通信、同步、成本与错误传播问题。
8. 把演示程序当作生产验证。 内存状态机不能证明数据库一致性、网络故障处理和真实模型行为。

阅读完本篇，读者应能够：为一次任务绘制完整时序图；区分 Task/Run/Step/Action/Event；设计 Run 状态机及合法转移；解释模型决策与系统执行的边界；分析暂停、恢复、重试和副作用；根据实际需求选择同步、异步、事件驱动或持久化工作流；并指出一个实验究竟验证了什么、没有验证什么。

十三、与后续专题的衔接

下一篇 「04 · Agent System 有哪些类型？ - System Types」 将以本篇的执行模型为分类基础，比较单 Agent、多 Agent、工作流驱动、事件驱动、集中编排与分布协作等架构，重点说明不同分类维度之间并非互斥关系。随后 05 · Completeness & Maturity 研究系统能力与工程成熟度如何评价；06 · Architecture & Design Principles 研究如何根据约束形成可解释的架构选择。

补充研究：交付语义、恢复机制与故障注入

区分执行尝试与业务副作用

At-most-once 表示执行尝试至多一次，可能丢失操作；At-least-once 允许重试，因此可能重复；Effectively-once 通常通过幂等键、去重、状态约束或补偿使业务效果近似一次；Exactly-once 必须明确限定系统边界，不能把内部事件只处理一次扩展为跨任意外部 API 的端到端保证。尤其当调用已发送而响应丢失时，Runner 不能仅凭超时判断操作没有发生。

Checkpoint、Event Log 与 Replay 的不同职责

Checkpoint 保存某一时刻的状态快照，用于减少恢复成本；Event Log 记录发生过的事件，便于审计或状态重建；Event Sourcing 以事件作为主要事实来源，通过投影得到当前状态；Workflow Replay 则可能根据历史事件重新执行确定性的工作流逻辑。这些机制可以组合，但不能互相等同。对可能产生副作用的活动，恢复时应重用已记录结果或使用外部去重机制，不能简单重新发送。

故障注入的最小实验矩阵

注入点	应验证的行为	关键证据
工具调用前取消	不再开始新副作用	取消事件、调用日志
调用后响应丢失	标记结果未知并有界处理	调用标识、外部回执
Checkpoint 写入失败	不宣称恢复点已提交	存储错误、状态版本
同一事件重复投递	不产生未经许可的重复交付	去重记录、产物 ID
Worker 执行中断	按恢复策略继续或明确失败	历史事件、重启记录

上述矩阵属于待执行的测试设计。原有标准库状态机实验只能证明其覆盖的状态转换和断言，不能证明外部数据库持久化、分布式恢复、网络分区或真实工具副作用的安全性。

并发控制的工程判断

当同一任务存在并发 Step 时，应明确状态写入顺序、冲突解决、取消传播和资源预算归属。共享状态可以采用单写入者、版本号 CAS 或事务等策略；各策略的可用性取决于存储系统与任务语义。并发吞吐的提升不能以丢失任务身份、越权访问或重复不可逆操作为代价。

研究结论

Agent System 的执行是任务契约、决策、授权、实际行动、观察反馈和状态转移的连续协作。可靠性取决于控制权、状态所有权、失败传播与外部副作用的明确契约；状态机的局部测试不能替代持久化、并发和真实故障的集成验证。

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

十二、参考资料与核验说明

以下资料于 2026-10-28 检索，均为相关项目的官方技术资料。文章中的系统模型、术语对照、设计建议和风险分析属于本知识库的综合归纳；不应理解为任一项目发布的统一 Agent System 标准。

1. OpenAI, Running agents - Agents SDK：developers.openai.com/api/docs/guides/agents/running-agents （Agent loop、continuation、暂停）。
2. OpenAI, OpenAI Agents SDK Python - Running agents：openai.github.io/openai-agents-python/running_agents （Runner、tool call、handoff、turn limit、RunState）。
3. OpenAI, Guardrails and human review：developers.openai.com/api/docs/guide...ardrails-approvals （审批中断与恢复）。
4. OpenAI, Agents overview：developers.openai.com/api/docs/guides/agents （托管 Agents API、应用内 SDK 与 Responses API 的职责差异）。
5. Temporal, Workflows：docs.temporal.io/workflows （Event History、确定性重放与 Activity）。
6. Temporal, Tasks：docs.temporal.io/tasks （Workflow Task、Worker 重放和事件推进）。

验证记录： 官方文档已进行网页检索和内容核对；未安装或运行 OpenAI Agents SDK、Temporal 服务，也未进行真实模型、数据库或分布式故障实验。第九节是独立、无外部依赖的参考实现，需以本地测试记录为准。本文未提供生产级 exactly-once、安全隔离或持久化恢复保证。

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

• **研究基准日期：**2026 年 10 月 28 日。
• **本次修订检索状态：**未新增实时网页检索；保留原文来源及其原有核验声明，不将旧资料冒充重新核验的最新版本。
• **本次修订验证状态：**原文包含标准库参考实验。本次修订未重新执行；新增的故障注入矩阵是待验证方案，不构成真实持久化或分布式恢复实测。
• **结论适用范围：**定义、组件划分、架构选型及成熟度分级均需结合任务目标、风险等级、实际框架版本与目标环境进行核验。
• **实验声明：**本次修订不宣称新增实验已经通过；历史文档中的运行或测试表述仅代表原文所述范围，需由独立可重现的执行记录支持。

附录 C：宽表格原始信息备查

为避免网页横向溢出，正文超长表格单元格采用摘要显示；原始完整内容保留如下：

• ； OpenAI Agents SDK（Python） ； Runner.run、run_sync、run_streamed；循环处理最终输出、工具调用与 handoff；支持运行状态续接、最大轮次与审批中断 ； Agent loop 可由应用内 SDK 承担；Run 内可能发生多个模型调用和工具操作 ； SDK 自动提供所有分布式任务队列和业务 exactly-once ；