这是 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 检索、任务终止等。
为什么 Claude Code、Codex、OpenClaw 看起来越来越像？
因为它们虽然产品形态不同，但 Runtime 的核心思想正在逐渐收敛：都是围绕"持续完成任务"来设计。
