网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

这两年，AI Agent 开始从简单的聊天机器人，逐渐变成真正能够执行任务的软件系统。

以前的 AI：

用户
 ↓
大模型
 ↓
回答

现在的 AI：

用户
 ↓
Agent
 ↓
理解任务
 ↓
规划步骤
 ↓
调用工具
 ↓
执行任务
 ↓
获取结果
 ↓
继续决策
 ↓
最终完成任务

问题也随之出现，如果 Agent 只执行一次任务，事情其实很简单。

但如果一个 Agent 需要：

调用 10 个工具
执行 50 个步骤
运行 30 分钟
同时处理 1000 个任务

甚至未来：

同时运行 100 万个 Agent

那么问题就不再是：

大模型够不够聪明？

而变成了：

谁负责让这些 Agent 稳定运行？

这就是 Agent Runtime 要解决的问题。

可以先用一句话理解：

Agent Runtime，就是让 AI Agent 真正“跑起来”的执行基础设施。

如果把 LLM 看成 Agent 的“大脑”，那么 Runtime 更像是：

Agent 的操作系统 + 任务调度器 + 执行引擎。

一、为什么 AI Agent 需要 Runtime？

我们先看一个最简单的 Agent。

用户输入：

帮我查询订单 10086，如果订单延期，就通知销售。

Agent 可能需要完成：

① 查询订单
② 获取订单状态
③ 判断是否延期
④ 查询对应销售
⑤ 生成通知内容
⑥ 发送消息
⑦ 返回执行结果

简单一点可以表示成：

用户
 ↓
Agent
 ↓
查询订单
 ↓
判断状态
 ↓
查询销售
 ↓
发送通知
 ↓
返回结果

看起来没什么问题，但真实系统很快就会遇到各种情况：

订单 API 超时了怎么办？

数据库连接失败怎么办？

发送消息失败怎么办？

一个任务执行到一半服务器重启怎么办？

两个工具可以同时执行吗？

一个 Agent 能调用哪些工具？

一个任务应该运行多久？

同时有 10 万个 Agent 怎么调度？

这时候，如果所有逻辑都直接写在 Agent 代码里：

agent()
tool()
retry()
state()
scheduler()

最终一定会变成一团复杂的业务代码。

因此需要把这些通用能力抽出来：

Agent
  ↓
Agent Runtime
  ├── Scheduler
  ├── Execution Engine
  ├── Tool Registry
  ├── State Manager
  ├── Memory
  ├── Retry
  ├── Checkpoint
  └── Observability

这就是 Runtime。

二、Agent Runtime 到底是什么？

传统程序通常是：

代码
 ↓
Runtime
 ↓
CPU / Memory
 ↓
程序结果

例如 Java：

Java Code
 ↓
JVM
 ↓
CPU
 ↓
Result

Node.js：

JavaScript
 ↓
Node.js Runtime
 ↓
CPU
 ↓
Result

Agent 的运行模式则完全不同：

Goal
 ↓
LLM
 ↓
Decision
 ↓
Tool
 ↓
Result
 ↓
LLM
 ↓
Decision
 ↓
Tool
 ↓
...

因此 Agent Runtime 需要解决的不是单纯的“执行代码”。

而是：

执行一个由 AI 动态决策出来的任务流程。

这句话非常重要。

传统程序的执行路径通常是确定的：

A → B → C → D

Agent 的执行路径可能是动态的：

A → B → D

也可能：

A → C → Tool1 → Tool2 → B

甚至：

       ┌→ Tool A ─┐
LLM ───┼→ Tool B ─┼→ LLM
       └→ Tool C ─┘

因此：

Agent Runtime 的核心，就是管理这种动态执行过程。

三、Agent Runtime 最核心的架构

一个比较完整的 Agent Runtime，可以抽象成：

                    User
                     │
                     ▼
                Agent API
                     │
                     ▼
              Task Scheduler
                     │
                     ▼
             Execution Engine
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
   LLM Gateway   Tool Registry  State Manager
        │            │            │
        ▼            ▼            ▼
      Models       Tools       Checkpoint
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
        Search       DB         API
                     │
                     ▼
               Observability

这里可以把 Runtime 拆成几个关键模块：

Task Scheduler
Execution Engine
Tool Registry
State Manager
Memory
Retry / Timeout
Checkpoint
Observability

四、Task Scheduler：谁先执行？

假设系统突然来了：

Task 001
Task 002
Task 003
...
Task 10000

这些任务不可能全部同时执行，Runtime 首先需要一个 Scheduler。

它负责：

任务进入
 ↓
排队
 ↓
优先级判断
 ↓
分配 Worker
 ↓
开始执行

例如：

                 Scheduler
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
    Worker 1      Worker 2      Worker 3
       │             │             │
     Agent         Agent         Agent

Scheduler 需要考虑：

• 任务优先级
• 最大并发数
• Worker 负载
• CPU 使用率
• GPU 使用率
• 网络资源
• Tool 限流
• 用户等级
• 任务超时

所以 Scheduler 并不是简单的：

for task in tasks:
    execute(task)

而更接近一个：

面向 Agent 的分布式任务调度系统。

五、Execution Engine：任务到底怎么跑？

Scheduler 解决：

谁执行？

Execution Engine 解决：

怎么执行？

Agent 最基本的执行过程其实就是一个 Loop：

Observe
   ↓
Think
   ↓
Act
   ↓
Observe
   ↓
Think
   ↓
Act
   ↓
...

用伪代码表示：

while True:

    state = get_state()

    decision = call_llm(state)

    if decision.need_tool:

        result = execute_tool(
            decision.tool
        )

        update_state(result)

    else:

        return decision.answer

这就是 Agent 最基本的执行循环，真正困难的地方并不是这个 Loop。

而是：

如何让这个 Loop 长时间稳定运行。

六、Agent 本质上就是一个动态执行循环

从工程角度看，一个 Agent 并没有那么神秘。

它本质上就是：

目标
 ↓
观察当前状态
 ↓
LLM 决策
 ↓
执行 Action
 ↓
获得结果
 ↓
更新状态
 ↓
继续决策

如果任务很简单：

LLM
 ↓
Tool
 ↓
Answer

很快就结束，如果任务复杂：

LLM
 ↓
Tool A
 ↓
Result
 ↓
LLM
 ↓
Tool B
 ↓
Result
 ↓
LLM
 ↓
Tool C
 ↓
Result
 ↓
...

Runtime 就必须持续管理这个过程。

因此：

Agent Runtime 本质上是一个持续运行的 AI Execution Loop。

Agent Runtime 核心执行循环

Agent 不是“一次调用”，而是一个持续运行的 Loop。**

七、Tool Registry：Agent 到底有哪些工具？

一个 Agent 真正拥有能力，靠的是 Tool。

例如：

get_weather()
search_web()
query_database()
get_order()
send_email()
send_message()
create_task()
update_crm()
read_file()
write_file()

当工具越来越多，就需要一个统一管理工具的地方：

Tool Registry。

可以简单理解成：

Agent 的工具注册中心。

例如：

tools = {
    "get_weather": get_weather,
    "search_web": search_web,
    "query_database": query_database,
    "send_email": send_email
}

当 LLM 返回：

tool = "query_database"

Runtime 就可以：

function = tools["query_database"]

result = function(...)

八、为什么 Tool Registry 会越来越重要？

假设一个 Agent 有：

10 个工具

问题不大，但如果变成：

1000 个工具

就会出现新的问题，首先是 Context，工具描述本身就会占用 Token。

如果一次性把 1000 个工具全部发送给模型：

Tool 1
Tool 2
Tool 3
...
Tool 1000

上下文会迅速膨胀，其次是工具选择。

工具越多：

SearchOrder
SearchCustomer
SearchProduct
SearchShipment
SearchInvoice
...

模型选择错误工具的概率也会增加。

因此 Runtime 需要进一步做：

Tool Registry
      ↓
Tool Discovery
      ↓
Tool Filtering
      ↓
Permission
      ↓
Tool Selection
      ↓
Execution

这也是未来 Agent Runtime 的重要能力。

九、State Manager：Agent 必须知道自己做到哪了

Agent 还有一个特别重要的问题：

状态。

假设用户说：

查询订单 10086。

Agent 执行：

order_id = 10086
status = delayed

然后用户继续：

那对应的销售是谁？

系统必须知道：

当前订单 = 10086

所以 Runtime 需要保存任务状态：

{
  "task_id": "task_001",
  "order_id": "10086",
  "status": "running",
  "current_step": "query_sales"
}

这就是 State。

十、State 和 Memory 不是一回事

这是 Agent 架构里一个非常容易混淆的问题。

State

表示：

当前任务正在发生什么。

例如：

task_id
current_step
tool_result
status
retry_count
error

Memory

表示：

Agent 过去知道什么。

例如：

用户偏好
历史任务
历史对话
长期知识

可以简单理解：

State
=
现在

Memory
=
过去

例如：

State：

正在处理订单 10086

Memory：

用户习惯使用中文回答

两者承担的是不同职责。

十一、Checkpoint：Agent 挂了还能继续吗？

这是 Runtime 非常关键的能力，假设一个 Agent 正在执行：

Step 1 ✓
Step 2 ✓
Step 3 ✓
Step 4

突然：

Runtime Crash

如果没有保存状态：

全部丢失

任务只能重新开始，但如果 Runtime 有 Checkpoint：

Step 1 ✓
Step 2 ✓
Step 3 ✓
     ↓
Checkpoint

Runtime 重启之后：

Load Checkpoint
       ↓
恢复 Step 4

于是任务可以继续执行，这意味着：

Agent 可以拥有长生命周期。

这对于复杂任务非常重要。

十二、Retry：工具失败了怎么办？

现实世界里的 API 不可能永远成功。

可能出现：

Timeout
Connection Error
Rate Limit
Database Error
Permission Error
Service Unavailable

例如：

result = call_api()

突然：

Timeout

Runtime 不能简单地：

raise Exception()

而应该具备：

Retry
Backoff
Timeout
Fallback
Circuit Breaker

例如：

第一次失败
   ↓
等待 1 秒
   ↓
第二次失败
   ↓
等待 2 秒
   ↓
第三次失败
   ↓
Fallback

这才是生产环境里的 Agent Runtime。

十三、为什么 Agent 的 Retry 更复杂？

普通 API：

Request
 ↓
Response

失败之后重新请求即可。

Agent：

Step 1 ✓
Step 2 ✓
Step 3 ✗
Step 4 ?

Step 3 失败之后，到底怎么办？

可能有几个选择：

重新执行 Step 3

换一个 Tool

让 LLM 重新规划

从 Step 2 重新开始

终止整个任务

所以 Runtime 必须理解：

任务执行上下文。

这也是 Agent Runtime 和普通 API Gateway 最大的区别之一。

十四、并发执行：多个工具能不能同时调用？

假设用户说：

帮我查询北京、上海、深圳三个城市的天气。

最简单的方式：

北京
 ↓
上海
 ↓
深圳

如果每次 API 都需要 1 秒：

总耗时 ≈ 3 秒

但三个任务之间没有依赖关系。

完全可以：

北京 ──┐
上海 ──┼──→ 综合结果
深圳 ──┘

并行执行，那么：

总耗时 ≈ 1 秒

这时候 Runtime 就需要理解：

任务之间的依赖关系。

十五、从 Linear Workflow 到 DAG

简单任务：

A → B → C → D

复杂任务：

       A
      / \
     B   C
     │   │
     └───┘
       D

这就是 DAG：

Directed Acyclic Graph，有向无环图。

例如：

查询订单
   │
   ├──── 查询库存
   │
   └──── 查询物流
          │
          ↓
       综合判断
          │
          ↓
       最终结果

其中：

查询库存
查询物流

可以并行执行，Runtime 根据依赖关系决定：

哪些任务立即执行
哪些任务等待
哪些任务可以并行
哪些任务必须串行

十六、Agent Runtime 已经开始像分布式系统

到了这里，你会发现一个非常有意思的变化。Agent Runtime 已经越来越像传统分布式系统。

它需要：

Queue
Scheduler
Worker
State
Checkpoint
Retry
Timeout
Cache
Database
Observability

整体架构甚至可以变成：

                 Agent API
                    │
                    ▼
               Task Queue
                    │
                    ▼
                Scheduler
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     Worker 1    Worker 2    Worker 3
        │           │           │
      Agent       Agent       Agent
        │
        ▼
   Execution Engine
        │
   ┌────┼────┐
   ▼    ▼    ▼
  LLM  Tool  Memory

所以从技术演进来看：

Agent Runtime 正在从一个简单的 SDK，逐渐变成一种新的分布式计算基础设施。

十七、Observability：Agent 为什么这么做？

Agent 系统还有一个非常麻烦的问题：

为什么它会调用这个工具？

传统程序：

API
 ↓
Database
 ↓
Error

比较容易排查。

Agent：

User
 ↓
LLM
 ↓
Tool A
 ↓
LLM
 ↓
Tool B
 ↓
LLM
 ↓
Tool C
 ↓
Error

如果没有完整 Trace：

根本不知道问题在哪里。

所以 Runtime 必须记录：

Task ID
Agent ID
Step ID
LLM Request
LLM Response
Tool Call
Tool Result
Latency
Token Usage
Retry
Error

最终形成完整的：

Agent Trace。

例如：

Task: task_001

├── LLM Call
│   └── 1.2s
│
├── Tool: Search
│   └── 0.8s
│
├── LLM Call
│   └── 1.5s
│
├── Tool: Database
│   └── 0.2s
│
└── Final Response

这样才能知道：

到底慢在哪里？
Token 消耗在哪里？
哪个 Tool 经常失败？
哪个 Agent 成本最高？

十八、Agent Runtime 和普通后端有什么区别？

看到这里，很多开发者可能会产生一个疑问：

这不就是普通后端系统吗？

确实很像，它们都需要：

Scheduler
Queue
Worker
Database
Retry
Observability

但 Agent Runtime 多了一层：

LLM 驱动的动态决策。

传统系统：

程序员定义流程

A
 ↓
B
 ↓
C

Agent：

程序员定义能力

       ↓

LLM 动态决定

A
 ↓
？
 ↓
？
 ↓
C

所以 Agent Runtime 真正困难的地方是：

如何让“不确定的 AI 决策”，运行在“确定的计算基础设施”上。

这可能才是 Agent Infrastructure 最核心的问题。

传统程序 vs Agent Runtime

十九、为什么 Agent Runtime 会越来越重要？

因为 Agent 正在发生一个非常明显的变化。

过去：

一次问答

未来：

持续任务

过去：

用户
 ↓
AI
 ↓
回答

未来：

用户
 ↓
创建任务
 ↓
Agent
 ↓
执行几十个步骤
 ↓
调用多个系统
 ↓
持续运行
 ↓
最终完成任务

这时候 Agent 已经越来越像：

一个分布式任务执行系统。

甚至未来可能出现：

Agent
Agent
Agent
Agent
Agent
...

共同完成一个复杂目标。

那么：

Scheduler
Runtime
State
Memory
Tool Registry
Observability

都会成为基础设施。

二十、从 LLM 到 Agent Runtime

如果把整个 AI 应用架构的发展过程串起来：

LLM
 ↓
LLM API
 ↓
Tool Calling
 ↓
RAG
 ↓
Agent
 ↓
Multi-Agent
 ↓
Agent Runtime
 ↓
Agent Infrastructure

最开始：

AI 只是回答问题。

后来：

AI 可以调用工具。

再后来：

AI 可以自主完成任务。

最终：

AI 需要 Runtime 才能稳定地执行复杂任务。

这和过去的软件工程其实非常相似。

程序越来越复杂之后：

单机程序
 ↓
操作系统
 ↓
进程
 ↓
线程
 ↓
分布式系统
 ↓
云计算

Agent 也正在经历类似的演进：

LLM
 ↓
Agent
 ↓
Agent Runtime
 ↓
Agent Infrastructure

二十一、Agent Runtime 最终会变成什么？

如果未来真的出现：

100 万个 Agent

甚至：

1000 万个 Agent

那么系统面对的已经不是简单的：

HTTP Request

而是：

Agent Task
Agent State
Agent Memory
Agent Tool
Agent Event
Agent Schedule
Agent Dependency

这时候 Runtime 需要解决的问题会越来越接近操作系统：

进程管理
资源调度
任务调度
权限管理
状态管理
故障恢复
网络通信
日志追踪

所以未来的 Agent Runtime，很可能会逐渐成为：

AI 时代新的系统软件层。

二十二、总结

很多人现在研究 Agent，第一反应还是：

哪个模型最强？
Prompt 怎么写？
Agent Framework 怎么选？

这些当然重要。

但当 Agent 真正进入生产环境之后，问题会逐渐变成：

任务怎么调度？

工具怎么管理？

状态怎么保存？

失败怎么恢复？

多个 Agent 怎么协作？

任务怎么并发？

如何降低 Token 成本？

如何监控 Agent？

如何保证 Agent 不失控？

这些问题，都已经不是单纯的大模型问题。

而是：

Runtime 问题。

所以可以把 Agent 系统简单理解成：

LLM
=
大脑

Tool
=
能力

Memory
=
记忆

State
=
当前状态

Runtime
=
执行系统

真正成熟的 Agent，不只是“模型会思考”。

而是：

模型负责决策，Runtime 负责执行。

当这两部分真正结合起来之后，AI 才有可能从：

ChatBot

真正走向：

AI Worker
AI Agent
AI System