15.1 什么是 Runtime（运行时）？
很多程序员第一次看到 Runtime 这个词，会想到：

Java Runtime。

.NET Runtime。

Node.js Runtime。

这些 Runtime 都有一个共同特点：负责管理程序整个运行过程。

例如：

.NET Runtime 会负责：

加载程序集；
管理内存；
垃圾回收；
调度线程；
捕获异常。
程序真正运行的时候。

真正工作的其实不是入口函数 Main()

而是：.NET Runtime。

Agent 也是一样。

LLM不会自己运行。

Tool不会自己调用。

Memory不会自己搜索。

Skill也不会自己加载。

真正协调它们工作的就是：Agent Runtime。

15.2 Agent Runtime 到底负责什么？
我们先一句话总结一下,Runtime等于Agent 的总调度中心。

它负责：

接收任务
↓
理解目标
↓
制定计划
↓
调用 Skill
↓
调用 Tool
↓
获取结果
↓
继续推理
↓
判断是否结束
↓
输出最终结果
整个 Agent 生命周期,其实全部由 Runtime 控制。
15.3 Runtime 为什么必须存在？
我们还是从例子开始

用户输入:修复这个 Bug。

LLM第一步：

分析 Bug。

结束。

那么问题来了。

怎么继续？

模型不会自己继续。

所以这里,Runtime收到模型输出。

发现需要：Read File

于是调用文件工具。

得到具体代码文件内容。

然后继续调用模型。

模型则继续分析。

输出：Search Symbol

Runtime则继续调用。
…

这整个过程模型一直在思考。

Runtime 则一直在执行。

因此,真正循环工作的不是LLM。

而是Runtime。

15.4 Agent Runtime 的核心机制：事件循环（Event Loop）
前面我们已经知道，Agent Runtime 是整个智能体系统的控制中心。那么，它究竟是如何驱动整个 Agent 持续工作的？

答案其实就是 事件循环（Event Loop）。

很多开发者第一次接触 Agent 时，容易认为它只是"连续调用很多次 LLM"。(当然,如果是简单理解 也没毛病)

上面我们也讲到了，真正持续运行的并不是大模型，而是 Runtime。

我们可以把 Runtime 想象成一位项目经理。

它不会亲自完成开发工作，而是不断地：

把任务交给大模型思考；
根据思考结果调用工具；
收集工具返回的结果；
再把新的信息交给大模型继续思考；
重复这一过程，直到任务完成。
整个过程就像一个不断运行的循环。

开始任务
│
▼
加载 Context
│
▼
调用 LLM
│
▼
解析输出
│
▼
是否需要执行 Action？
│
┌────┴────┐
│ │
否 是
│ │
▼ ▼
结束 调用 Tool
│
▼
获取 Observation
│
▼
更新 Context
│
└──────────────┐
│
▼
再次调用 LLM

整个过程中，LLM 并不知道自己处于第几轮推理，也不知道之前执行了哪些工具，它只是不断根据当前的 Context 推理"下一步应该做什么"。真正维护整个执行过程的，是 Runtime。

举个例子
假设用户提出这样一个任务：帮我分析这个 GitHub 项目的整体架构，并生成一份技术报告。

Runtime 接收到任务后，不会一次性把所有工作都交给模型，而是逐步完成。

第一轮，LLM 根据用户目标判断：我需要先了解项目目录结构。

于是输出：

{
“action”: “list_files”,
“path”: “./”
}
Runtime 识别到这是一个工具调用请求，于是执行文件工具，返回项目目录。

第二轮，LLM 看到目录结构后，又判断：需要先阅读 README 文件。

于是继续输出：

{
“action”: “read_file”,
“file”: “README.md”
}
Runtime 再次执行。

随后模型可能继续要求：

搜索 Controller；
查看数据库配置；
分析依赖关系；
统计模块数量；
直到最后输出：

{
“finish”: true,
“answer”: “项目整体采用分层架构……”
}
Runtime 收到 finish=true 后，结束整个循环，并把最终结果返回给用户。

可以看到，整个任务实际上经历了几十轮甚至上百轮推理，而不是一次 Prompt 就完成的。

为什么不能一次完成？
有人可能会问：

为什么不能一次告诉模型：“请先分析目录，再分析代码，最后生成报告。”

原因在于，真实世界的大多数任务都具有不确定性。

例如，在开始分析项目之前，模型并不知道：

项目有多少个模块；
使用什么开发框架；
有没有 README；
是否存在配置文件；
是否需要查看数据库脚本。
这些信息都必须在执行过程中逐步获取。

因此，Agent 的工作方式更像人类解决问题：观察环境 → 决定下一步 → 获取反馈 → 再决定下一步。

而不是提前把所有步骤全部规划好。

这种动态决策能力，也是 Agent 比传统工作流更加灵活的重要原因。(也是今年Agent这么火的原因之一)

15.5 Agent 的核心闭环：Action 与 Observation
如果说 Event Loop 是 Agent 的运行框架，那么 Action（行动） 与 Observation（观察） 就是 Agent 与现实世界交互的核心机制。

很多人误以为，大模型会直接调用工具。

实际上在Agent中,这是错误的。

LLM 并不会真正执行任何操作，它只负责告诉 Runtime：“我下一步希望执行什么。”

真正执行并调用工具的，始终是 Runtime。

什么是 Action？
Action 可以理解为模型输出的一条"执行指令"。

例如，当模型分析代码时，它可能输出：

{
“action”: “read_file”,
“path”: “Program.cs”
}
或者：

{
“action”: “search_symbol”,
“keyword”: “CreateOrder”
}
再或者：

{
“action”: “execute_shell”,
“command”: “dotnet test”
}
这些都属于 Action。

请注意，它们只是模型的决策结果,然后需要 Runtime去执行后续的动作.

模型并不会真的去读取文件、执行命令或者查询数据库。

什么是 Observation(观察结果)？
Runtime 收到 Action 后，会调用对应的 Tool。

例如：

dotnet test
执行完成后，返回：

Total Tests: 128
Passed: 127
Failed: 1
NullReferenceException
这段返回结果，就是 Observation（观察结果）。
Runtime 会把 Observation 加入新的 Context，再交给模型继续推理。

于是模型看到：测试失败，异常类型是 NullReferenceException。

它就可以继续思考：下一步应该查看异常堆栈。

于是再次生成新的 Action。

整个过程形成了一个完整的闭环。

LLM 思考
│
▼
生成 Action
│
▼
Runtime 执行
│
▼
得到 Observation
│
▼
加入 Context
│
▼
LLM 再次思考
Agent 其实正是依靠这种不断循环的方式，逐步完成复杂任务。
ReAct：现代 Agent 的基础思想
这种"推理—行动—观察"的模式，在学术界被称为 ReAct（Reason + Act）。

它的核心思想非常简单：

Thought(思考)
↓
Action(行动)
↓
Observation(观察结果)
↓
Thought(思考)
↓
Action(行动)
↓
Observation(观察结果)
例如，当用户要求：帮我定位这个 Bug。

模型第一次思考：我需要查看日志。

于是生成 Action：Read Log。

Runtime 执行后返回日志。

模型继续思考：日志显示数据库连接失败，需要检查配置文件。

于是再次生成新的 Action：Read appsettings.json。

整个过程中，每一次 Observation 都会影响下一次推理。

因此，Agent 并不是一次性生成完整方案，而是在不断获取反馈、不断修正自己的判断。

为什么很多产品不再展示 Thought(思考过程)？
早期很多 Agent 产品都会直接展示完整的思考过程，例如：

Thought:
我应该先查看配置文件……
Action:
read_file(appsettings.json)
后来，越来越多的商业产品开始隐藏这部分内容。

原因主要有三个：

第一，内部推理过程可能包含大量无意义的中间推断，反而增加用户理解成本。

第二，思考过程可能暴露系统 Prompt、内部规则等敏感信息，存在安全风险。

第三，不同模型的推理方式并不完全相同，直接展示容易造成误解。

因此，现在更多产品会展示类似：

正在分析项目……
正在读取代码……
正在运行测试……
正在生成报告……
而不会完整显示内部推理内容。

需要说明的是，这并不代表模型没有推理过程，而是这些过程由 Runtime 在后台协调完成，并不一定需要全部呈现给用户。

Action、Observation 与 MCP 的关系
在第十一章，我们介绍了 MCP（Model Context Protocol）。

现在可以把几章内容串联起来。

当模型生成 Action,比如:查询医院库存

Runtime 首先判断：这是一个 Tool 调用。

随后通过 MCP Client 找到对应的 MCP Server，由 MCP Server 调用医院库存系统，获取真实数据。

整个过程如下：

用户
↓
LLM
↓
Action
↓
Runtime
↓
MCP Client
↓
MCP Server
↓
医院库存系统
↓
Observation
↓
Runtime
↓
LLM
可以看到：LLM 负责决策，Runtime 负责调度，MCP 负责连接，Tool 负责执行。

四者各司其职，这才能共同组成现代 Agent 的完整执行链路。

15.6 Runtime 如何知道任务完成？
这是 Runtime 最重要职责。

例如,模型输出：继续搜索。

Runtime：继续。
模型输出：修改代码。

Runtime：继续。
模型输出：运行测试。

Runtime：继续。
直到模型输出：Task Complete

Runtime：停止循环。
然后给用户返回最终答案。

所以Runtime不仅负责执行。

还要负责结束。

15.7 Runtime 如何管理 Context？
假设Agent已经运行50 步。

Context越来越长。

怎么办？

Runtime通常会自动进行：Context Management。

例如：

历史消息
↓
总结（Summarize）
↓
压缩
↓
保留关键结论
↓
继续执行
否则,上下文很快超过模型最大窗口。

因此Context Management,其实也是 Runtime 工作之一。

除了总结，现代 Runtime 还可能采用：

滑动窗口（Sliding Window）保留最近上下文；
将历史内容写入 Memory，需要时再检索回来（RAG）；
保留关键状态而丢弃中间细节。
这些策略的目标都是一致的：让有限的上下文窗口承载尽可能多的有效信息。

15.8 Runtime 如何调度 Skill？
上一章我们介绍了 Skill，并提到它可以把某一领域的专业知识、最佳实践和工作规范封装起来，供 Agent 按需使用。

那么，一个新的问题来了：Runtime 是如何决定什么时候使用 Skill 的？

很多人第一次接触 Skill 时，容易产生一种误解：Runtime 会把所有 Skill 一次性全部发送给大模型。

实际上，现代 Agent 几乎都不会这样设计。

原因很简单。

假设一个企业拥有：

Java Skill
.NET Skill
Python Skill
SQL Skill
Kubernetes Skill
Docker Skill
产品设计 Skill
测试 Skill
运维 Skill
每个 Skill 都包含几千甚至上万 Token。

如果启动 Agent 时就把所有 Skill 一次性放入 Context，不仅会迅速耗尽上下文窗口，还会增加推理成本，降低模型对当前任务的关注度。

因此，现代 Agent 普遍采用一种更加高效的方式,也就事我们上一章也讲过的——渐进式披露（Progressive Disclosure）。

Runtime 并不会隐藏 Skill，而是按需加载 Skill
这里我们在简单回溯一下，渐进式披露并不是让模型完全不知道有哪些 Skill。

通常情况下，Runtime 会先向模型提供每个 Skill 的基础信息，例如：

Available Skills：

• Java Development
  用于 Java 项目开发与代码分析
• SQL Optimization
  用于数据库设计与 SQL 优化
• Docker Expert
  用于容器构建与部署
• Kubernetes Expert
  用于 Kubernetes 集群运维
  也就是说，模型知道：

当前有哪些 Skill 可以使用；
每个 Skill 大概解决什么问题。
但是，它并不知道每个 Skill 内部包含哪些详细内容。

例如，一个 SQL Skill 里面可能包含：

SQL 编码规范；
索引设计原则；
常见慢查询分析方法；
EXPLAIN 使用技巧；
数据库最佳实践；
企业内部开发规范；
示例代码。
这些内容通常有几千甚至上万 Token。

Runtime 不会在任务开始时全部加载，而是在真正需要的时候，再把完整内容加入 Context。

为什么这样设计？
这种设计主要有三个优点。

第一，减少 Context 占用。

绝大多数任务只会涉及少量 Skill。

例如，一个 SQL 优化任务，完全没有必要同时加载 Java、Docker、Kubernetes 等大量无关知识。

按需加载能够显著减少 Prompt 长度，提高推理效率。

第二，提高模型注意力。

模型一次接收的信息越多，真正与当前任务相关的信息比例就越低。

只加载当前任务需要的 Skill，可以让模型更加聚焦当前问题，减少无关内容对推理过程的干扰。

第三，方便持续维护。

Skill 通常以独立文件的形式维护。

例如：

skills/
├── java.md
├── dotnet.md
├── sql.md
├── docker.md
├── kubernetes.md
└── security.md
新增一个 Skill，只需要增加一个新的文件，而不需要修改整个 Agent 的 Prompt。

企业也可以根据自身业务，不断积累新的 Skill 库，实现知识资产的持续沉淀。

Claude Code 与 OpenClaw 都采用了类似思想
目前，越来越多的 Agent 产品都采用了类似的设计理念。

例如 Claude Code 的 Skills，以及 OpenClaw 新版 Skill 规范，都采用了**元数据（Metadata）+ 按需加载（Lazy Loading）**的模式。

Runtime 首先向模型提供 Skill 的基本信息，例如名称、描述和适用场景；当模型判断某个 Skill 可以帮助完成当前任务时，再由 Runtime 将该 Skill 的完整内容加载到 Context 中。

这种机制正是前一章介绍的**渐进式披露（Progressive Disclosure）**在 Agent Runtime 中的具体体现。

15.9 Claude Code 为什么可以连续工作几个小时？
很多人第一次看到Claude Code。

都会觉得太神奇了。

其实Claude模型本身没有连续运行。

真正连续运行的是Runtime。

例如：

读取项目
↓
搜索引用
↓
修改代码
↓
运行测试
↓
失败
↓
再次修改
↓
再次运行
↓
Git Commit

Claude模型只是不断思考下一步。

真正执行Shell、Git、文件、测试的,全部是Runtime。

所以Claude Code 并不是一个"会写代码的大模型"，而是一个由 Runtime 驱动、能够持续执行开发任务的 Agent 系统。

15.10 Agent Runtime 的完整架构
现在，我们终于可以把Agent相关的内容串起来了：

                用户目标
                    │
                    ▼
           Agent Runtime
                    │
    ┌───────────────┼────────────────┐
    ▼               ▼                ▼
Context 管理     Skill Router     Workflow
    │               │                │
    ▼               ▼                ▼
 Memory         加载 Skill        流程控制
                    │
                    ▼
          Prompt / Tool / MCP
                    │
                    ▼
                   LLM
                    │
             Thought / Action
                    │
                    ▼
               Observation
                    │
                    └───────────────┐
                                    │
                               回到 Runtime

请注意：Runtime 并不是 LLM 的一部分，而是整个 Agent 系统的控制中心。

LLM 负责生成下一步行动，Runtime 负责让这些行动真正发生。

本章总结
这一章，我们回答了六个关键问题：

什么是 Agent Runtime？
它是智能体的运行时系统，负责协调所有组件完成任务。
Runtime 为什么必不可少？
因为 LLM 不会主动调用工具、管理状态或持续执行任务。
Agent 是如何持续工作的？
Runtime 通过事件循环不断驱动"推理 → 执行 → 观察 → 再推理"。
Action 与 Observation 是什么？
LLM 输出 Action，Runtime 执行并返回 Observation，形成闭环。
Runtime 还负责哪些工作？
包括 Context 管理、Skill 路由、Memory 检索、任务终止等。