Agent Runtime 到底是什么：看一个 Agent 如何真的把事做完

什么是Agent runtime#

假设你对一个运维 Agent 说：

查明支付服务刚才为什么发布失败。如果需要回滚，先让我审批；回滚后再确认服务恢复。

如果应用只调用一次大模型，模型可能回答：

我需要先查询发布记录和错误日志。

这句话看起来很聪明，但任务没有前进。日志还没有被查询，回滚也没有发生。模型只是提出了下一步。

现在加入一段程序，让同一个任务继续运行：

1
1. 程序保存用户目标，并创建 run_01
2
2. 程序调用模型
3
3. 模型提出：get_deployment("payments")
4
4. 程序检查权限，真正调用部署平台
5
5. 程序把查询结果交给模型
6
6. 模型提出：query_logs(...)
7
7. 程序执行查询，再把日志交给模型
8
8. 模型判断需要回滚，并提出 rollback_deployment(...)
9
9. 程序发现该动作必须审批，于是保存现场并暂停

两小时后，你点击批准：

1
10. 另一台 Worker 读取 run_01 的现场
2
11. 程序确认批准的仍是同一次回滚、同一组参数
3
12. 程序执行回滚并记录外部操作 ID
4
13. 程序再次调用模型，模型提出健康检查
5
14. 程序执行检查，把结果交给模型
6
15. 模型生成结论，程序将 run_01 标记为成功

第 2、3、6、8、13、15 步里，模型在判断“下一步做什么”。其余那些让任务继续、暂停、恢复和结束的步骤，就是 Runtime 在工作。

**Agent Runtime 是让模型能够连续行动的运行程序。**它反复调用模型，接住模型提出的动作，校验并执行工具，把结果写回状态，再决定继续、暂停还是结束。

总结为一句话：

模型决定下一步想做什么；Runtime 负责让这一步安全地发生，并把结果带进下一步。

OpenAI Agents SDK 把这个核心过程称为 runner loop：调用模型；遇到工具调用就执行并把结果追加回去；遇到 handoff 就切换 Agent；得到最终输出或超过轮数才结束。[1] 不同框架的名称会变化，但这个循环是理解 Runtime 的起点。

它到底是一种什么“东西”#

Runtime 不是一种模型，也不一定是一款独立产品。它首先是真实运行的代码。

在小型应用里，它可能只是后端进程中的一个函数：

1
app/
2
├── agent_definition.ts   # 指令、模型、工具和输出格式
3
├── run_agent.ts          # 循环调用模型与工具
4
└── tools/

在生产系统里，它可能扩展成一组服务：

1
runtime/
2
├── runner               # 推进每一轮
3
├── state_store          # 保存 Run 与检查点
4
├── tool_executor        # 执行工具
5
├── policy_engine        # 权限、审批和预算
6
├── scheduler            # 排队、超时、取消和重试
7
└── trace_exporter       # 记录整条执行轨迹

规模不同，职责没有变。Runtime 总是位于模型和真实世界之间。

“Agent”这个词常被用来指整套系统，因此容易造成混淆。本文把“指令 + 模型 + 工具集合”称为 Agent 定义，把真正推动一次任务运行的程序称为 Runtime，把两者连同状态库和外部系统组成的整体称为 Agent 应用。

它的核心确实只是一个循环#

先把审批、恢复和并发全部拿掉，一个最小 Runtime 可以写成下面的概念伪代码：

1
state = create_run(user_goal)
2

3
while not state.finished:
4
    model_input = build_context(state)
5
    decision = call_model(model_input)
6

7
    if decision is final_answer:
8
        state.finish(decision)
9
        break
10

11
    action = validate_tool_call(decision)
12
    result = execute_tool(action)
13
    state.append(action, result)

这段循环完成了四件事：

1. 把当前任务状态整理成模型输入；
2. 让模型选择下一步；
3. 把选择变成真实工具调用；
4. 把新事实放回状态，再问模型一次。

因此，Agent 并不是模型在一次请求里“连续思考了很久”。从系统视角看，它通常是多次彼此独立的模型调用，中间穿插程序执行的工具调用。连续性来自 Runtime 保存并重建输入，而不是来自某个一直存活的模型对象。

到这里，Agent Runtime 的主体已经解释完了：它就是控制这个循环的程序。

真正的工程问题来自下一句：如果这个循环要操作生产系统，而且可能运行几分钟、几小时甚至几天，只写一个 while 就不够了。

为什么一个 while 循环很快就不够了#

继续看 run_01，四个很普通的事件会迫使 Runtime 长出更多能力。

1
rollback_deployment(
2
  service = "payments",
3
  target_revision = "rev-184"
4
)

1
Runtime → 部署平台：回滚 rev-185
2
部署平台 → Runtime：回滚成功
3
Runtime 在写入“成功”之前崩溃

1
idempotency_key = run_id + tool_call_id + action_version

Runtime 保存的是 Run，不只是聊天记录#

聊天记录只说明“模型和用户说过什么”。Runtime 还必须保存“系统实际上做到了哪里”。

run_01 至少包含四类状态：

这也是为什么模型说“回滚完成”不能作为最终证据。Runtime 必须读取部署平台的状态，并把验证结果记录下来。

一次 Run 通常有显式生命周期：

1
QUEUED
2
  ↓
3
RUNNING ──→ WAITING_INPUT ──→ RUNNING
4
  │
5
  ├────→ WAITING_APPROVAL ──→ RUNNING
6
  ├────→ RETRYING ──────────→ RUNNING
7
  ├────→ SUCCEEDED
8
  ├────→ FAILED
9
  ├────→ CANCELED
10
  └────→ EXPIRED

WAITING_APPROVAL 不是成功，也不是失败；它表示 Runtime 已经保存现场，正在等一个外部事件。CANCELED 也只表示 Runtime 不再推进新步骤，不代表已经发生的外部动作会自动撤销。

A2A 的 Task 生命周期同样区分 input-required、auth-required 等中断状态和 completed、failed、canceled 等终态。[8] 这里的重要直觉是：Conversation 是交流上下文，Run 才是有开始、有状态、有终点的工作单元。

把模型放回整张图里#

现在可以完整地画出 Runtime 的位置：

1
                         ┌─────────────────────┐
2
用户目标 ───────────────→│    Agent Runtime    │
3
                         │                     │
4
                         │  1. 读取 Run 状态   │←────→ 状态库 / 检查点
5
                         │  2. 构建本轮上下文  │
6
                         │  3. 调用模型        │←────→ 模型 API
7
                         │  4. 校验候选动作    │
8
                         │  5. 执行或暂停      │←────→ 策略 / 人工审批
9
                         │  6. 记录结果并循环  │←────→ 工具网关
10
                         └─────────────────────┘          │
11
                                                        ↓
12
                                            数据库 / 浏览器 / 云平台

模型从来没有直接“伸手”进入数据库或云平台。它返回的是结构化建议；Runtime 决定这个建议能否成为动作，并控制动作使用什么身份、预算和超时。

工具结果也不能自动升级成指令。网页、工单和代码注释都可能包含提示注入文本。Runtime 与 context builder 应保留来源边界，把这些内容作为外部数据交给模型，而不是当成系统规则。

如果底层使用 replay 型工作流引擎，模型调用、网络请求、当前时间等非确定性操作还应放在可记录的 Activity 边界中。Temporal 明确把 API、LLM 和数据库调用归到 Activity，而要求 Workflow 控制代码保持可确定性重放。[14] 恢复时应重放已经记录的模型结果，而不是重新调用模型并期待它再次生成同一个计划。

MCP、A2A 和工作流引擎都不是 Runtime#

理解了上面的循环，这三个概念就容易放置了。

MCP 规范把 LLM 编排、权限、上下文聚合和用户授权放在 Host 一侧；Server 只暴露受控能力。[3] 因此，接入 MCP 不会自动得到运行循环、检查点或审批。

A2A 则面向内部不透明、能够维持任务状态的远端 Agent。[9] 官方比较把 MCP 描述为连接工具和资源，把 A2A 描述为连接能够推理并协作的独立 Agent。[10] 远端 Agent 内部怎样调用模型和工具，仍由它自己的 Runtime 负责。

工作流引擎最接近 Runtime 的执行底座，但两者关注点不同：工作流引擎擅长可靠执行已定义步骤；Agent Runtime 还要在每一轮让模型动态决定下一步。实践中常见的组合是“工作流引擎负责持久调度，Agent Runtime 负责模型循环和动作边界”。

Runtime 怎样把 Agent 变成生产系统#

回到 run_01，生产要求最终可以归结为两件事：每一步都必须受控，每一步都必须可追踪。

1
invoke_agent run_01
2
├── model_turn 1
3
├── execute_tool get_deployment
4
├── model_turn 2
5
├── execute_tool query_logs
6
├── approval_wait rollback_deployment
7
├── execute_tool rollback_deployment
8
├── execute_tool verify_deployment
9
└── model_turn 3

什么情况下才需要 Agent Runtime#

不是所有大模型功能都需要 Runtime。

当下面三件事同时出现时，Runtime 才真正有价值：

1. 模型会根据中间结果动态选择下一步；
2. 任务会读取或改变外部系统；
3. 任务需要跨多轮、跨进程或跨人工等待继续。

如果任务只是 input → model → output，不必先建一套 Runtime。如果任务已经变成 model → tool → model → approval → tool → recovery → model，那套负责推进箭头的程序，其实就是 Runtime。

用三个问题检查自己是否理解了#

结语：Runtime 是 Agent 的执行者#

Agent Runtime 并不神秘。它是位于用户目标、模型和外部系统之间的控制程序。

它先把当前状态交给模型，让模型提出下一步；再由程序检查权限、执行工具、保存结果，并决定继续、暂停还是结束。为了让这个循环进入生产环境，它又需要持久状态、审批、幂等、预算、取消、版本和 trace。

所以最准确的理解不是“Runtime 给模型增加了智能”，而是：

Runtime 把模型一次次不确定的建议，组织成一项能够真正完成、能够中断恢复、也能够追责的工作。

参考资料#

1. OpenAI, OpenAI Agents SDK: Running agents. https://openai.github.io/openai-agents-python/running_agents/

2. OpenAI, OpenAI Agents SDK: Human-in-the-loop. https://openai.github.io/openai-agents-python/human_in_the_loop/

3. Model Context Protocol, Architecture (2026-07-28). https://modelcontextprotocol.io/specification/2026-07-28/architecture

4. Model Context Protocol, Tools (2026-07-28). https://modelcontextprotocol.io/specification/2026-07-28/server/tools

5. LangChain, LangGraph Checkpoint. https://github.com/langchain-ai/langgraph/tree/main/libs/checkpoint

6. Temporal, Event History. https://docs.temporal.io/encyclopedia/event-history

7. Temporal, Error handling: Design Activities for idempotence. https://docs.temporal.io/best-practices/error-handling#idempotence

8. A2A Protocol, Life of a Task. https://a2a-protocol.org/latest/topics/life-of-a-task/

9. A2A Protocol, Core Concepts and Components in A2A. https://a2a-protocol.org/latest/topics/key-concepts/

10. A2A Protocol, A2A and MCP: Detailed Comparison. https://a2a-protocol.org/latest/topics/a2a-and-mcp/

11. OpenTelemetry, Semantic Conventions for GenAI agent and framework spans. https://opentelemetry.io/docs/specs/semconv/gen-ai/gen-ai-agent-spans/

12. OpenAI, OpenAI Agents SDK: Tracing. https://openai.github.io/openai-agents-python/tracing/

13. Model Context Protocol, Security Best Practices (2026-07-28). https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices

14. Temporal, Workflow Definition: Deterministic constraints. https://docs.temporal.io/workflow-definition#deterministic-constraints