前言

在开发大模型应用时，我们很容易把 Agent 理解成：

LLM + Tool

模型负责思考，Tool 负责执行动作。

这种理解并没有错，但只适合解释一个非常简单的 Agent Demo。

当 Agent 真正进入生产系统之后，一个任务可能持续几十秒、几分钟，甚至更久。执行过程中，它可能需要读取历史对话、加载 Skill、检索 Memory、执行 RAG、调用多个工具、启动子 Agent、等待人工审批、生成文件，并把整个执行过程实时推送到前端。

此时真正需要解决的问题已经不是：

怎么让模型调用一个工具？

而是：

怎么让一个 Agent 任务稳定地从开始运行到结束，并且能够管理它的上下文、状态、工具、记忆、事件、错误、暂停和恢复？

负责这一切的，就是 Agent Runtime。

如果一定要给 Agent Runtime 一个直观的定义，可以把它理解成：

Agent Runtime 是 Agent 的运行时执行系统。它负责承载一次 Agent Run，并在整个任务生命周期中协调 LLM、Tool、Context、RAG、Memory、Skill、Subagent、Human-in-the-loop、Event 和持久化等能力。

从这个角度看，LLM 更像 Agent 的“大脑”，Tool 是 Agent 的“手和脚”，Memory 和 RAG 是它获取信息的能力，而 Runtime 更像：

Agent 的操作系统。

---

一、为什么 Agent 需要 Runtime

最简单的大模型调用可能只有：

response = llm.chat(messages)

调用过程非常短：

用户问题
   ↓
LLM
   ↓
回答

如果应用只是做问答，这已经足够。

但是假设用户给 Agent 一个任务：

帮我分析这份招标文件，找出资格条件和评分办法，再结合公司的历史项目生成一份投标策略。

这个任务背后可能发生：

读取招标文件
      ↓
解析 PDF
      ↓
理解用户目标
      ↓
生成执行计划
      ↓
提取资格条件
      ↓
提取评分办法
      ↓
查询企业知识库
      ↓
匹配历史案例
      ↓
调用风险分析工具
      ↓
启动子 Agent
      ↓
汇总分析结果
      ↓
生成投标策略
      ↓
生成 Word 报告

这里已经出现了很多新的问题。

例如，Agent 调用了一个工具以后，工具结果应该放在哪里？下一次调用 LLM 时，要不要把工具结果继续塞进去？

如果工具执行失败，是直接结束任务，还是重试？如果重试三次仍然失败怎么办？

如果用户刷新页面，Agent 是否继续执行？如果继续执行，用户重新进入页面后怎么恢复当前状态？

如果执行过程中需要用户确认，Agent 怎么暂停？用户十分钟以后确认，又怎么从原来的位置继续？

如果 Agent 创建了三个 Subagent，父 Agent 怎么知道它们什么时候完成？

如果一次任务调用十几次模型，Token、耗时和成本应该如何统计？

这些问题都不是 LLM 本身会解决的。

因此生产级 Agent 需要一个独立的运行时系统：

Agent Runtime

它负责把整个 Agent 从“调用一次模型”升级成“运行一个持续存在的智能任务”。

---

二、Agent Runtime 的核心不是模型，而是 Run

理解 Agent Runtime，第一个非常重要的概念不是 LLM，而是：

Run

Run 可以理解为：

Agent 执行一次用户任务的实例。

例如一个 Conversation 中可能发生：

Conversation: conv_001

用户：
你好

Assistant：
你好，有什么可以帮助你的？

用户：
帮我分析这份文件

        ↓

Run: run_001

从这一刻开始，“分析这份文件”不再只是一次 HTTP 请求，而是一个真正的后台运行任务。

Run 可以拥有自己的状态：

queued
running
waiting_tool
waiting_user
paused
completed
failed
cancelled

例如：

run_001

status = running
conversation_id = conv_001
input_message_id = msg_100
output_message_id = msg_101

started_at = ...
finished_at = ...
last_event_id = ...

为什么一定要引入 Run？

因为 Agent 的生命周期通常比一次 HTTP 请求长得多。

用户发送消息以后：

POST /messages

服务端可以快速返回：

{
  "runId": "run_001",
  "status": "running",
  "streamUrl": "/api/runs/run_001/events"
}

但 Agent 仍然在后台继续执行。

这就实现了：

HTTP Request 生命周期
        ≠
Agent Run 生命周期

即使用户刷新页面，原来的 SSE 连接断开：

SSE disconnected

Run 依然可以是：

run_001
status = running

因此，Run 是 Runtime 中真正的执行主体。

Runtime 的第一项核心工作就是：

创建 Run、驱动 Run、保存 Run 状态，并最终让 Run 进入 completed、failed 或 cancelled 等终态。

---

三、Runtime 本质上是一个持续运行的执行循环

如果把 Agent Runtime 的复杂能力暂时全部拿掉，它最核心的机制其实是一个循环：

构建上下文
    ↓
调用 LLM
    ↓
理解 LLM 的决定
    ↓
执行动作
    ↓
拿到结果
    ↓
继续构建上下文
    ↓
再次调用 LLM

伪代码可以简化成：

while not run.finished:

    context = build_context(run)

    response = llm.generate(
        context=context,
        tools=available_tools,
    )

    if response.has_tool_call:
        result = execute_tool(
            response.tool_call
        )

        append_tool_result(
            run,
            result,
        )

        continue

    save_assistant_message(
        response.text
    )

    run.complete()

这个过程就是典型的：

Think
 ↓
Act
 ↓
Observe
 ↓
Think
 ↓
Act
 ↓
Observe

但生产环境里的 Runtime 会在这个循环外面增加大量控制能力：

状态机
上下文构建
Tool 调度
事件发布
权限控制
重试
超时
取消
暂停
持久化
恢复
Subagent
审批
监控

因此可以认为：

Agent Runtime 的真正核心是 Execution Loop + State Machine。

Execution Loop 决定 Agent 下一步继续执行什么。

State Machine 决定 Agent 当前到底处于什么状态，以及哪些状态之间可以发生转换。

---

四、Context Builder：Runtime 每一轮真正给模型什么

Agent 每次调用模型，并不是简单发送用户最后一句话。

真正的 Prompt 可能包含：

System Prompt

Agent Instructions

用户当前问题

历史 Conversation

当前 Run 状态

当前 Plan

已经执行过的 Tool Call

Tool Result

RAG Context

Knowledge Evidence

Memory

Skill

用户身份

租户信息

当前 Artifact

当前时间

所以 Runtime 中一个极其重要的模块通常叫：

Context Builder

或者：

Context Manager
Context Assembly
Context Manifest

它负责回答一个问题：

这一轮 LLM 推理，到底应该让模型看到什么？

例如：

┌────────────────────────┐
│ System Prompt          │
├────────────────────────┤
│ Agent Instructions     │
├────────────────────────┤
│ Loaded Skills          │
├────────────────────────┤
│ Retrieved Memory       │
├────────────────────────┤
│ Conversation History   │
├────────────────────────┤
│ RAG Context            │
├────────────────────────┤
│ Current Plan           │
├────────────────────────┤
│ Tool Results           │
├────────────────────────┤
│ Current User Message   │
└────────────────────────┘
            ↓
           LLM

这部分经常被低估。

实际上，很多所谓“Agent 能力不稳定”，并不是模型本身不够聪明，而是 Context 构造出现了问题。

比如历史消息无限增长：

Conversation History
越来越长

最终可能导致：

• Token 成本不断增加；
• 关键信息被淹没；
• 上下文窗口不足；
• 模型关注错误的信息。

又比如 RAG 一次召回大量文档：

20 个 Chunk
每个 2000 Token

直接塞给 LLM，就可能产生几万 Token 的上下文。

再比如 Tool Result 返回了一大段 JSON，完整注入模型：

{
  "result": "...几十万字符..."
}

不仅浪费 Token，还可能让模型失去重点。

所以成熟 Runtime 的 Context Builder 通常还会负责：

裁剪
压缩
摘要
优先级
去重
Token Budget

最终目的不是“给模型越多越好”，而是：

在有限的 Context Window 中，把当前决策真正需要的信息组织得足够清楚。

---

五、LLM Adapter：Runtime 不应该和某一家模型绑定

Agent Runtime 中，LLM 是最核心的推理能力，但 Runtime 本身不应该直接依赖某个具体厂商 API。

否则代码很容易变成：

if model == "openai":
    ...

elif model == "qwen":
    ...

elif model == "deepseek":
    ...

elif model == "vllm":
    ...

最终所有模型差异都会污染 Runtime。

更合理的结构是：

Agent Runtime
      ↓
LLM Adapter / Provider
      ↓
┌──────────────┐
│ OpenAI       │
│ Qwen         │
│ Claude       │
│ Gemini       │
│ DeepSeek     │
│ Local vLLM   │
└──────────────┘

Runtime 只使用统一接口：

response = llm_provider.generate(
    messages=context.messages,
    tools=context.tools,
    model=model,
)

Provider 再将不同厂商的格式统一成：

text
tool_calls
finish_reason
usage
reasoning_summary
provider_metadata

这样 Runtime 不需要知道：

OpenAI Tool Call 长什么样
Qwen Function Call 长什么样
Claude Tool Use 长什么样

这些差异全部由 Adapter 层解决。

这也是为什么生产 Agent 平台中，经常会看到：

Model Provider
LLM Gateway
Model Adapter

这些抽象。

---

六、Tool Runtime：Agent 从“会说”到“会做”的关键

如果没有 Tool，大多数 Agent 仍然只是一个聊天系统。

Tool 让 Agent 能够真正作用于外部系统。

例如：

search_documents
query_database
parse_document
browser
send_email
create_report
memory_search
execute_code

当 LLM 返回：

{
  "name": "search_documents",
  "arguments": {
    "query": "评分办法"
  }
}

Runtime 不应该简单地执行：

search_documents("评分办法")

生产级 Tool Runtime 至少还要经历：

Tool Call
   ↓
查找 Tool Registry
   ↓
Schema 校验
   ↓
参数标准化
   ↓
权限校验
   ↓
租户校验
   ↓
风险等级判断
   ↓
执行
   ↓
超时控制
   ↓
结果标准化
   ↓
写入 Run Context

因此真正的 Tool Runtime 通常是：

Tool Registry
      ↓
Tool Resolver
      ↓
Argument Validation
      ↓
Permission / Policy
      ↓
Tool Executor
      ↓
Result Normalizer

一个 Tool 可能包含：

name
description
input_schema
output_schema
executor

timeout
retry_policy
risk_level
permissions

LLM 看到的是：

我有哪些工具，它们分别有什么能力，需要什么参数？

Runtime 看到的是：

这个 Tool 到底对应哪个执行器？是否允许执行？失败怎么办？

这两个层面是不同的。

---

七、MCP 在 Runtime 中处于什么位置

当 Agent 工具越来越多时，不可能每个 Tool 都在 Runtime 内部直接写实现。

于是会出现 MCP 一类协议。

架构可能变成：

Agent Runtime
      ↓
Tool Runtime
      ↓
┌─────────────────┐
│ Internal Tool   │
│ HTTP Tool       │
│ MCP Tool        │
│ Browser Tool    │
└─────────────────┘

对于 Runtime 来说，MCP 更像一种：

外部 Tool Provider 协议。

Runtime 可以从 MCP Server 获取：

有哪些 Tools
Tool Schema
如何调用
调用结果

这样 Agent Runtime 与真正业务能力进一步解耦。

---

八、RAG 在 Runtime 中有两种完全不同的位置

很多系统都说自己的 Agent 集成了 RAG，但实际上有两种设计。

第一种是：

RAG as Tool

也就是 Agent 自己决定什么时候检索。

LLM
 ↓
决定需要知识
 ↓
调用 search_knowledge
 ↓
返回结果
 ↓
继续推理

这种模式的优点是 Agent 自主性更强。

第二种是：

Automatic RAG

Runtime 在调用 LLM 之前自动执行：

用户问题
   ↓
Query Rewrite
   ↓
Embedding
   ↓
Vector Search
   ↓
Rerank
   ↓
Context Assembly
   ↓
LLM

这种情况下，LLM 甚至不知道“搜索”是一项 Tool，而是直接看到 Runtime 注入的知识。

两者可以同时存在：

Automatic RAG
    负责基础知识增强

RAG Tool
    负责 Agent 主动进一步检索

Runtime 需要明确负责：

什么时候自动检索
使用哪个知识库
租户过滤
召回多少 Chunk
是否 Rerank
上下文如何压缩
Evidence 如何记录

因此 RAG 不只是一个外部服务，往往还是 Runtime Context 管理的一部分。

---

九、Memory：为什么 Runtime 不能简单把历史消息当记忆

Conversation History 和 Memory 很容易被混淆。

Conversation History 是：

当前会话之前发生了什么。

Memory 更接近：

从过去的信息中提取出来，并可以跨时间、跨 Run 被重新使用的信息。

例如：

某个项目的背景
用户曾经作出的选择
之前 Run 的关键结论
长期业务上下文

Runtime 一般会在执行前：

当前任务
   ↓
Memory Search
   ↓
召回相关 Memory
   ↓
注入 Context

执行结束后：

Run 完成
   ↓
Memory Extraction
   ↓
判断哪些信息值得保存
   ↓
Memory Write

因此完整的 Memory 能力通常不仅仅是：

search

而是：

search
write
update
delete

Runtime 负责决定什么时候读取 Memory，以及 Memory 应该如何影响当前 Run。

---

十、Skill：为什么 Skill 不是 Tool

Tool 往往表示一个原子动作：

搜索数据库
下载文件
发送邮件

Skill 更像：

完成一类业务任务所需要的一整套方法。

例如：

招投标分析 Skill

包含：

System Instructions
任务步骤
风险识别规则
输出结构
可以使用哪些 Tools
领域知识提示

于是 Runtime 可能进行：

用户任务
   ↓
识别 Skill
   ↓
加载 Skill
   ↓
把 Skill Instructions 注入 Context
   ↓
启用对应 Tool Set
   ↓
执行 Agent

所以可以简单理解：

Tool
=
Agent 能做什么

Skill
=
Agent 应该如何完成某一类任务

Runtime 则负责 Skill 的：

发现
选择
加载
版本固定
使用记录
失败处理

---

十一、Plan：复杂 Agent 为什么需要显式计划

对于简单任务，Agent 可以不断：

LLM → Tool → LLM → Tool

直到结束。

但复杂任务如果完全没有 Plan，很容易产生：

• 重复执行；
• 忘记目标；
• 顺序混乱；
• 用户无法知道进度。

于是 Runtime 会维护一个 Plan：

分析招标文件

✓ 读取文件
✓ 提取资格条件
● 分析评分办法
○ 匹配历史案例
○ 生成投标策略

但需要特别注意：

Plan 不是 Agent Runtime 的执行状态本身。

Plan 表示：

Agent 认为应该完成哪些步骤

Run State 表示：

系统当前实际上运行到了哪里

例如 Plan 可能认为：

Step 3 = running

但真实 Runtime 正在：

waiting_tool

因为某个工具还没有完成。

因此 Runtime 需要同时管理：

Logical Plan
+
Execution State

而前端看到的 Plan UI，一般是 Runtime 状态的一种投影。

---

十二、Subagent：Runtime 如何管理多个智能体

复杂任务可能进一步拆给多个 Agent：

Main Agent
    │
    ├── Document Agent
    ├── Research Agent
    └── Risk Agent

这里不能简单认为：

Subagent = 再调用一次 LLM

更准确地说，Subagent 通常拥有自己的：

Context
Run
Tools
Model
状态
事件
结果

所以 Runtime 中可能形成：

Parent Run
    │
    ├── Child Run A
    │      └── completed
    │
    ├── Child Run B
    │      └── running
    │
    └── Child Run C
           └── failed

主 Runtime 需要处理：

如何创建 Subagent
给它什么输入
允许使用什么工具
最大并发多少
什么时候取消
如何收集结果
子任务失败是否影响父任务

因此 Subagent Runtime 本质上是一套：

嵌套 Run 管理机制。

---

十三、Human-in-the-loop：Agent Runtime 必须知道什么时候停

生产中的 Agent 不应该所有事情都自动执行。

例如：

发送邮件
删除数据
提交审批
修改合同
发布内容
付款

都属于可能产生真实业务影响的操作。

当 Runtime 识别到高风险 Tool 时，可以：

running
   ↓
approval.required
   ↓
waiting_user

此时 Run 不应该结束。

它只是：

暂停

Runtime 需要把当前状态完整保存下来。

十分钟甚至十小时后，用户点击：

批准

Runtime 收到：

approval.approved

然后：

恢复 Context
    ↓
继续 Tool
    ↓
继续 Execution Loop

所以 Human-in-the-loop 的真正难点不在前端的：

[批准] [拒绝]

而在 Runtime 能不能：

暂停、持久化，然后从原来的位置恢复。

这也是 Runtime 是否真正生产可用的重要判断标准。

---

十四、Event System：Runtime 如何把执行过程暴露出来

一个 Agent Run 内部会不断发生变化：

Run 开始
LLM 开始生成
产生文本增量
Tool 开始
Tool 完成
Plan 更新
Subagent 创建
Artifact 创建
Run 完成

这些变化如果只存在 Runtime 内存里，前端和监控系统都无法感知。

因此 Runtime 通常会将变化转换成统一 Event：

run.created
run.started

message.item.created
message.item.delta
message.item.completed

plan.updated

tool.started
tool.completed
tool.failed

subagent.started
subagent.completed

approval.required

artifact.created

run.completed
run.failed

于是架构变成：

Agent Runtime
      ↓
    Event Bus
      │
      ├── Event Log
      ├── SSE Gateway
      ├── Timeline Projection
      ├── Trace
      ├── Metrics
      └── Audit Log

同一个 Runtime Event 可以同时驱动多个下游能力。

例如：

tool.completed

可以同时：

• 更新数据库中的 Tool 状态；
• 写入 agent_stream_event；
• 通过 SSE 推给前端；
• 出现在 Trace 页面；
• 进入运行指标；
• 参与最终 Timeline 构建。

这也是为什么成熟 Runtime 往往围绕 Event 架构，而不是到处直接调用前端逻辑。

---

十五、SSE 和 streamUrl 不属于 Runtime 本身，但它们观察 Runtime

这里需要明确边界。

Runtime 的职责是：

执行

SSE Gateway 的职责是：

把 Runtime 产生的事件推给客户端

因此：

Runtime
   ↓
Event Log / Event Bus
   ↓
SSE Gateway
   ↓
streamUrl
   ↓
Agent UI

这意味着：

关闭 SSE
≠
停止 Runtime

页面切换或者刷新时，客户端的 streamUrl 连接可能消失，但 Agent Run 仍然继续。

这就是：

Run 生命周期
和
网络连接生命周期

解耦。

对于 Agent 系统，这是非常重要的设计。

---

十六、为什么 Runtime 必须有 Snapshot 和 Event Log

如果 Runtime 的状态只存在内存：

process memory

服务一重启：

Agent 全丢

显然无法生产使用。

因此 Runtime 必须进行持久化。

通常至少有两种数据：

Snapshot
+
Event Log

Snapshot 表示：

当前 Run 现在是什么状态。

例如：

run.status = waiting_user

message.content = "经过分析……"

tool_call.status = completed

plan.step_3 = running

Event Log 表示：

Run 是如何一步步变成现在这个状态的。

例如：

1001 run.started
1002 message.item.created
1003 message.item.delta
1004 tool.started
1005 tool.completed
1006 approval.required

两者结合，可以同时解决：

快速恢复
+
事件追踪
+
断线补发

例如用户刷新页面：

读取 Snapshot
    ↓
立即恢复完整 UI
    ↓
拿到 lastEventId
    ↓
从 Event Log 补发遗漏事件
    ↓
重新进入 Live Stream

这也是：

Snapshot + Event Log + Live Stream

模型的来源。

---

十七、Artifact：Agent 的结果不应该全部塞进 Message

Agent 最终产生的结果不一定是文本。

它可能创建：

Word
PDF
Excel
图表
HTML
代码
数据文件

这些更适合作为 Artifact。

Runtime 可能执行：

Agent 决定创建报告
      ↓
Artifact 创建
      ↓
写入内容
      ↓
保存 MinIO / S3
      ↓
更新 Artifact Status
      ↓
artifact.created
      ↓
前端展示

Artifact 可以拥有：

artifact_id
run_id
message_id
type
title
version
status
object_key
metadata

于是 Conversation 中可以只展示：

已经生成《项目风险分析报告》

[打开] [下载]

真正的报告则在 Artifact Workspace 中展示。

这说明 Runtime 不只是生成 Message，也负责管理任务产生的业务成果。

---

十八、Retry、Timeout 与 Cancellation：Runtime 如何处理失败

Agent 的执行高度依赖外部系统：

LLM API
数据库
搜索系统
MCP
Browser
对象存储
第三方 API

失败是必然发生的。

因此 Runtime 必须有明确的 Failure Policy。

例如：

Tool Timeout
   ↓
Retry 1
   ↓
Retry 2
   ↓
Retry 3
   ↓
仍然失败

此时 Runtime 可以：

让 LLM 选择其他 Tool

或者：

将当前 Step 标记失败

或者：

直接 run.failed

不同类型错误不能一律重试。

例如网络超时：

retryable = true

但权限不足：

retryable = false

因此 Runtime 往往需要：

Retry Policy
Exponential Backoff
Timeout
Circuit Breaker
Error Classification
Fallback

取消同样不能只是杀掉 HTTP 请求。

用户点击停止时：

cancel_requested = true

Runtime 应在安全位置检查：

Cancellation Point

然后依次取消：

当前 Tool
Subagent
后续计划

最终产生：

run.cancelled

---

十九、Runtime 还需要做资源和成本治理

Agent 与普通 Chat 最大的成本差异之一，就是：

一个用户请求可能产生很多次 LLM 调用。

例如一个 Run：

第一次：任务理解
第二次：生成 Plan
第三次：决定 Tool
第四次：处理 Tool Result
第五次：调用 Subagent
第六次：总结结果

最终可能调用模型十几次。

因此 Runtime 通常需要记录：

provider
model
prompt_tokens
completion_tokens
cached_tokens
reasoning_tokens

latency
TTFT

tool_cost
model_cost

最后汇总成：

Run Usage
Run Cost

这些数据可以用于：

• 租户计费；
• 用户限额；
• 成本分析；
• 模型路由；
• 性能优化；
• 运营监控。

例如：

简单请求
    → flash 模型

复杂任务
    → plus 模型

超复杂规划
    → reasoning 模型

这种 Model Routing 通常也是 Runtime 或其上层 Policy Engine 的能力。

---

二十、Trace 和 Observability 为什么是 Runtime 的必要组成部分

Agent 一旦出现问题，仅仅看到：

run.failed

几乎没有任何排查价值。

开发人员真正需要知道：

用户输入是什么
加载了哪个 Skill
检索了什么 Memory
RAG 召回了什么
调用了哪个模型
LLM 返回了什么 Tool Call
Tool 参数是什么
Tool 执行多久
Subagent 做了什么
在哪里失败

所以生产 Runtime 通常会生成完整 Trace：

Run
 ├── LLM Call 1
 ├── RAG Retrieval
 ├── Tool Call 1
 ├── LLM Call 2
 ├── Subagent Run
 │      ├── LLM
 │      └── Tool
 └── LLM Call 3

可以建立：

run_id
trace_id
span_id
parent_span_id

这样 Agent 执行就从一个“黑盒”变成可以观察和分析的执行图。

---

二十一、一个完整的 Agent Runtime 架构

把前面的能力放到一起，一个比较完整的 Runtime 可以抽象为：

                       Agent API
                           │
                           ▼
                  ┌────────────────┐
                  │  Run Manager   │
                  └────────┬───────┘
                           │
                           ▼
              ┌────────────────────────┐
              │     Agent Runtime      │
              │                        │
              │   Execution Loop       │
              │   State Machine        │
              │   Scheduler            │
              │   Policy Engine        │
              └───────────┬────────────┘
                          │
          ┌───────────────┼────────────────┐
          │               │                │
          ▼               ▼                ▼
   Context Builder    LLM Adapter      Tool Runtime
          │               │                │
    ┌─────┼──────┐        │         ┌──────┼────────┐
    ▼     ▼      ▼        ▼         ▼      ▼        ▼
   RAG  Memory  Skill   Model      MCP   Browser   API
                      Providers

                          │
          ┌───────────────┼─────────────────┐
          ▼               ▼                 ▼
      Subagent       Approval Runtime    Artifact
       Runtime

                          │
                          ▼
                     Event Bus
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
      Event Log        Snapshot       Trace / Metrics
          │
          ▼
      SSE Gateway
          │
          ▼
       Agent UI

这张图中最值得关注的不是模块数量，而是数据流。

Agent API 创建 Run。

Run Manager 把 Run 交给 Runtime。

Runtime 通过 Context Builder 组织信息，再调用 LLM。

LLM 可能返回 Tool Call，Tool Runtime 执行后把结果重新交给 Runtime。

复杂任务可以继续创建 Subagent，危险动作可以进入 Approval。

整个执行过程中不断产生 Event。

Event 一方面被持久化，另一方面通过 SSE 推送给 UI。

无论前端是否在线，Run 都可以继续存在。

这就是 Runtime 真正的运行模型。

---

二十二、Agent Runtime 和 Agent Framework 有什么区别

经常有人会把：

LangGraph
Agent SDK
CrewAI
AutoGen

直接称为 Agent Runtime。

这种说法在某些语境下没有问题，但严格来说二者还是有区别。

Agent Framework 更多提供：

Agent 定义
Graph
Tool
Workflow
Model 调用

而完整生产 Runtime 还需要：

Run 生命周期
事件系统
持久化
恢复
权限
租户
并发控制
取消
审批
成本
Trace
SSE
版本管理

所以企业实际建设时，经常会出现：

LangGraph / Agent SDK
        ↓
作为 Agent Execution Engine

自研 Agent Runtime
        ↓
负责生产运行能力

也就是说，没有必要把整个 Runtime 都自己重新造一遍。

可以使用成熟 Agent Framework 解决“怎么执行 Agent”，再在外层建立自己的：

Run
Event
State
Tool Policy
Persistence
Streaming
Observability

这些平台能力。

---

二十三、怎样判断一个 Agent Runtime 是否真正成熟

一个 Agent Demo 可能只需要做到：

LLM 能调用 Tool

但生产 Runtime 更应该回答下面这些问题：

当用户刷新页面以后，Run 会不会消失？

服务重启以后，正在运行的任务能不能恢复？

同一个 Tool 重复执行时会不会产生重复副作用？

高风险操作能不能暂停等待用户审批？

Subagent 能不能独立取消和重试？

模型 API 超时以后 Runtime 怎么处理？

Run 产生十万条流式事件以后怎么恢复？

一个用户最多允许启动多少个并发 Run？

不同租户能不能使用不同 Tool 和 Skill？

一次 Run 到底调用了多少 Token，花了多少钱？

出现问题以后能不能通过 Trace 定位？

如果这些问题都没有答案，那么它更多还是一个：

Agent Execution Demo

而不是完整的：

Agent Runtime

---

二十四、从 0 到 1 建设 Agent Runtime 的推荐路径

如果自己建设 Agent Runtime，不建议一开始就同时实现 Multi-Agent、Memory、Skill 和复杂 Workflow。

更合理的路线是先把最核心的一条链路做稳定。

第一阶段先做到：

Run
+
LLM
+
Tool
+
Event
+
SSE

确保：

用户发送消息
    ↓
创建 Run
    ↓
LLM
    ↓
Tool
    ↓
LLM
    ↓
完成

整个生命周期能够稳定运行。

第二阶段解决生产可靠性：

Snapshot
Event Log
Retry
Timeout
Cancellation
SSE Recovery
Trace

确保：

页面能刷新
网络能断
Worker 能重启
任务能失败
Run 还能正确恢复

第三阶段再扩展智能能力：

RAG
Memory
Skill
Plan
Artifact

第四阶段才适合增加：

Subagent
Human-in-the-loop
Generative UI
复杂 Workflow

这样的建设顺序比一开始追求“Agent 能力很多”更容易真正落地。

---

结语

Agent Runtime 最容易被误解成：

一个 while 循环
+
LLM
+
Tool

但生产级 Agent Runtime 实际解决的是：

如何让一个智能任务稳定、持续、可控、可恢复地运行。

从用户的一条请求开始：

用户任务
    ↓
创建 Run
    ↓
Runtime 构建 Context
    ↓
LLM 做出决策
    ↓
调用 Tool / RAG / Memory / Skill
    ↓
可能创建 Subagent
    ↓
可能暂停等待用户审批
    ↓
不断产生 Event
    ↓
保存 Snapshot 和 Event Log
    ↓
通过 SSE 推送运行过程
    ↓
处理异常、重试和取消
    ↓
生成 Message / Artifact
    ↓
Run 完成

整个过程真正的核心并不是某一次 LLM 调用，而是 Runtime 对整个执行生命周期的管理。

因此，可以用一句话总结 Agent Runtime：

LLM 负责决定下一步“想做什么”，Tool 负责提供“能做什么”，而 Agent Runtime 负责决定这些事情“什么时候做、怎么做、做到哪里了、失败怎么办、状态怎么保存、如何恢复，以及怎样把整个过程可靠地暴露给用户和系统”。

当 Agent 从简单问答逐渐走向长任务、工具调用、企业业务操作、Multi-Agent 和 Human-in-the-loop 时，Agent Runtime 就会从一个隐藏的技术模块，逐渐成为整个 Agent 平台最核心的基础设施。