跳到主要内容
Agent Runtime

第1章:Agent Runtime 是什么

从 5 行 demo 到生产级 agent 的鸿沟,Runtime 的 4 大职责,Agent Stack 全景图,以及生产 agent 的 8 类失败模式

Agent Runtime Agent Stack Production Failure Modes

5 行 demo 写出来的 agent,和真正稳定服务千万用户的 agent,中间隔着的是什么?是Runtime——一套把 LLM 调用、工具调用、状态、错误、审计、监控全部串起来的工程基础设施。本章先把这条鸿沟具体化:列出生产 agent 的 8 类失败模式,定义 Runtime 的 4 大职责,画出 Agent Stack 五层模型,讲清 Memory 与 Runtime 的边界。读完这章你会知道:剩下 8 章每一章都在解决”5 行 demo 撑不住”的某一类问题

📑 目录


1. 5 行 demo vs 生产 agent

1.1 5 行 demo

新人写第一个 agent 通常是这样的:

from openai import OpenAI
client = OpenAI()
while True:
    msg = input("> ")
    resp = client.chat.completions.create(model="gpt-4o", messages=[{"role":"user","content":msg}])
    print(resp.choices[0].message.content)

漂亮、直观、能跑。问题是:这样写的 agent 撑不过任何一个生产场景

1.2 生产 agent 至少要回答的问题

问题5 行 demo 的答案生产 agent 的答案
进程崩了怎么办?全部丢失从最近 checkpoint 恢复
多步操作中第 5 步失败?状态污染Saga 补偿,回滚到一致状态
用户中途加新需求?重新开始Human-in-the-loop 暂停-恢复
怎么调用 100 种工具?写 100 个 if/elifMCP 标准协议
多个 agent 协作?不支持Supervisor / Swarm 编排
用户跨周再来?完全不记得长期 Memory(模块五)
慢请求怎么诊断?看不到OTel trace 全链路
LLM 输出格式错了?崩溃Structured output + retry
API 限流?用户看到错误退避 + 队列
安全性?任意 prompt injection沙箱 + 权限 + audit

🌟 结论:Runtime 不是可选项,是把 demo 变成 service 的工程基础设施


2. 生产 Agent 的 8 类失败模式

下面 8 类失败,每一类都对应本教程的 1-2 章:

2.1 进程崩溃 / OOM(对应第 5 章)

LLM 调用 30 秒、工具调用 10 秒、第 N 个 turn 突然 OOM。5 行 demo 全丢,生产 agent 必须能恢复

2.2 多步操作中途失败(对应第 6 章) ⭐

下单 → 扣库存 → 调支付,支付失败时库存已经扣了——必须有 Saga 补偿。

2.3 长时间任务被中断(对应第 5 章)

agent 等 24 小时人工审批,期间机器重启 3 次——Workflow as code,Temporal Event History 保证不丢

2.4 LLM 决策反悔(对应第 6、2 章)

LLM 第 3 步决定”调用 A”,第 5 步突然改主意”应该调用 B”——A 的副作用要不要补偿?

2.5 多 Agent 死锁 / 无限路由(对应第 3 章)

Supervisor 把请求路给 Worker A,A 又路给 B,B 又路回 Supervisor——无限循环。需要路由深度限制 + 状态机

2.6 工具协议混乱(对应第 7 章)

每个工具的参数格式不同、错误格式不同、auth 方式不同——需要 MCP 标准化

2.7 灰盒难调试(对应第 8 章)

用户报”agent 给了奇怪回答”,你只看到一句日志——OTel trace 让你回放全部 LLM call、tool call、memory read/write

2.8 安全 / 注入攻击

恶意 prompt 让 agent 读敏感文件、执行任意代码——需要沙箱、权限、permission scope(第 7、9 章会涉及)。


3. Runtime 的 4 大职责

把上面 8 类失败抽象一下,Runtime 要做 4 件事:

┌─────────────────────────────────────────────────────────┐
│              Agent Runtime 4 大职责                      │
└─────────────────────────────────────────────────────────┘

       ┌────────────┐                ┌────────────┐
       │ ① 状态     │                │ ② 控制流    │
       │ State      │                │ Control    │
       │            │                │            │
       │ Memory     │                │ ReAct       │
       │ Checkpoint │                │ Plan-Exec  │
       │ Workflow   │                │ Reflexion  │
       │ Variables  │                │ Graph DAG  │
       └────────────┘                └────────────┘

       ┌────────────┐                ┌────────────┐
       │ ③ Durability│                │ ④ Observable│
       │            │                │            │
       │ Replay     │                │ Trace      │
       │ Resume     │                │ Metric     │
       │ Saga       │                │ Audit      │
       │ Retry      │                │ Cost       │
       └────────────┘                └────────────┘

3.1 ① 状态管理(State)

agent 必须有”持久的世界观”:Working state(当前 turn)、Conversation state(本会话)、Long-term memory(跨会话)。State 的 schema 设计、lifecycle、并发安全,都是 runtime 要解决的。

3.2 ② 控制流(Control Flow)

LLM 怎么”思考”?ReAct 循环?Plan-Execute?Graph DAG?多 agent supervisor?这是 Runtime 第二重要的设计——决定 agent 行为的”形状”。

3.3 ③ Durability(可恢复性)

任何步骤失败、进程崩溃、机器重启,都能从最近一致状态恢复。这是 Temporal、Restate、LangGraph durable execution 的本职工作

3.4 ④ Observability(可观测性)

每一次 LLM 调用、tool 调用、memory 读写、subagent 委派,都有 trace。OTel GenAI 把这些字段标准化

🌟 简记:Runtime = State + Control + Durability + Observability。这 4 件事做不全,就不算”生产级 agent”


4. Agent Stack 五层模型

把上面 4 大职责落到具体技术栈,得到一个五层模型:

   ┌─────────────────────────────────────────────────────────┐
5: │  Observability  OTel GenAI / LangSmith / Langfuse       │ ← 第 8 章
   ├─────────────────────────────────────────────────────────┤
4: │  Runtime        Durable Execution(Temporal / Restate)  │ ← 第 5 章
   │                  Transactions(Saga / 2PC / Outbox)     │ ← 第 6 章 ⭐
   ├─────────────────────────────────────────────────────────┤
3: │  Workflow       LangGraph / CrewAI / AutoGen / ...      │ ← 第 4 章
   │                  编排模式(Supervisor / Swarm / ...)     │ ← 第 3 章
   │                  控制流(ReAct / Plan-Exec / Graph)     │ ← 第 2 章
   ├─────────────────────────────────────────────────────────┤
2: │  Tool Layer     MCP servers,A2A 同伴 agent              │ ← 第 7 章
   ├─────────────────────────────────────────────────────────┤
1: │  LLM Client     OpenAI / Anthropic / vLLM / 本地模型     │ ← 模块四
   └─────────────────────────────────────────────────────────┘

每一层都有自己的”事实标准”在形成中:

事实标准(2026)
5 ObservabilityOpenTelemetry GenAI Semantic Conventions
4 RuntimeTemporal(durable),SagaLLM 论文范式(transactions)
3 WorkflowLangGraph(graph)、CrewAI(role)双雄
2 ToolMCP(Anthropic→Linux Foundation,2025-12)
1 LLMOpenAI / Anthropic API + vLLM(开源)

🌟 这五层的标准化,是 2025 这一整年完成的——这就是为什么”现在”是写这个教程最好的时机。


5. Memory 与 Runtime 的边界

模块五 Memory 和本模块 Runtime 经常被混在一起聊,但它们解决的是不同问题:

维度Memory(模块五)Runtime(模块六)
解决问题”agent 知道什么""agent 怎么做”
时间尺度跨周、跨月持久化单次执行 + checkpoint
数据形态Facts、Episodes、SkillsState、Plan、Trace
存储介质Vector / Graph / KVPostgres / Redis / Event Log
关键算子Extraction、Retrieval、Consolidation、ReflectionPlan、Execute、Compensate、Replay
失败处理错误抽取 → 污染检索中途失败 → Saga 回滚
标杆论文MemGPT、A-MEM、ZepReAct、Reflexion、SagaLLM
标杆框架Mem0、Letta、ZepLangGraph、Temporal、CrewAI

5.1 协同关系

实际生产 agent 两者紧密协作:

# 伪代码:Workflow 启动时从 Memory 加载用户上下文
def order_workflow(user_id, item):
    # Runtime:启动 durable workflow
    state = WorkflowState()
    
    # Memory:加载用户偏好
    state.user_prefs = mem0.search(user_id, "shipping_preference")
    state.history = mem0.get_episodic(user_id, last_n=5)
    
    # Runtime:执行 plan
    plan = llm.plan(item, state)
    for step in plan:
        result = execute_step_with_checkpoint(step, state)
        if result.failed:
            saga_compensate(state.completed_steps)  # Runtime
            return
    
    # Memory:写回新事实
    mem0.add(f"用户在 {today} 买了 {item}", user_id=user_id)

Memory 是 Runtime 在 state 之外的持久化”知识基底”


6. 何时需要”完整 Runtime”

不是所有 agent 都需要全栈 Runtime。问自己:

问题Yes 越多越需要全栈
用户跨多次访问?
Agent 会调用 3+ 种外部工具?
任何一步失败需要补偿之前的步骤?
长时间运行(分钟到天)?
多个 agent 协作?
需要审计、合规?
千万用户级别?

如果 ≥ 4 个 Yes,走全栈 Runtime(LangGraph + Temporal + MCP + Saga + OTel)。 如果 ≤ 2 个,用 LangGraph 轻量栈即可(内置 checkpointer + tool calling)。 如果 0 个 Yes,就是 5 行 demo——也没问题,但不要叫”生产 agent”。


✅ 自我检验清单

  • demo vs 生产:能列出至少 6 个”5 行 demo 撑不住”的具体场景
  • 8 类失败模式:能默写 8 类失败,并指出每类对应本教程哪一章
  • 4 大职责:能用一句话说出 State / Control / Durability / Observability 各自管什么
  • 五层 Stack:能从下到上画出 5 层,标注每层的事实标准框架
  • Memory 与 Runtime 边界:能从 8 个维度对比两者
  • 协同伪代码:能写一段 30 行伪代码,展示 workflow 如何同时用 Memory 和 Runtime
  • 决策清单:面对 3 个不同业务,能判断要不要上全栈 Runtime
  • 2025 标准化:能讲出”为什么 2025 是 Agent Runtime 的标准化之年”

📚 参考资料

综述与博客

  • The Agent Stack — Part 4: Runtimes, Workflows, and Durable Execution:Substack
  • Durable Execution meets AI: Why Temporal is ideal for AI agents:Temporal Blog
  • Memory for AI Agents: A New Paradigm of Context Engineering —— The New Stack(模块五已引)

核心论文(后续章节会精读)

行业现状

  • AI Agent Observability — Evolving Standards (OpenTelemetry, 2025):opentelemetry.io
  • 120+ Agentic AI Tools Mapped Across 11 Categories (StackOne):博文