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 SymbolRuntime则继续调用。…这整个过程模型一直在思考。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 收到 finishtrue 后结束整个循环并把最终结果返回给用户。可以看到整个任务实际上经历了几十轮甚至上百轮推理而不是一次 Prompt 就完成的。为什么不能一次完成有人可能会问为什么不能一次告诉模型“请先分析目录再分析代码最后生成报告。”原因在于真实世界的大多数任务都具有不确定性。例如在开始分析项目之前模型并不知道项目有多少个模块使用什么开发框架有没有 README是否存在配置文件是否需要查看数据库脚本。这些信息都必须在执行过程中逐步获取。因此Agent 的工作方式更像人类解决问题观察环境 → 决定下一步 → 获取反馈 → 再决定下一步。而不是提前把所有步骤全部规划好。这种动态决策能力也是 Agent 比传统工作流更加灵活的重要原因。(也是今年Agent这么火的原因之一)15.5 Agent 的核心闭环Action 与 Observation如果说 Event Loop 是 Agent 的运行框架那么 Action行动 与 Observation观察 就是 Agent 与现实世界交互的核心机制。很多人误以为大模型会直接调用工具。实际上在Agent中,这是错误的。LLM 并不会真正执行任何操作它只负责告诉 Runtime“我下一步希望执行什么。”真正执行并调用工具的始终是 Runtime。什么是 ActionAction 可以理解为模型输出的一条执行指令。例如当模型分析代码时它可能输出{“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: 128Passed: 127Failed: 1NullReferenceException这段返回结果就是 Observation观察结果。Runtime 会把 Observation 加入新的 Context再交给模型继续推理。于是模型看到测试失败异常类型是 NullReferenceException。它就可以继续思考下一步应该查看异常堆栈。于是再次生成新的 Action。整个过程形成了一个完整的闭环。LLM 思考│▼生成 Action│▼Runtime 执行│▼得到 Observation│▼加入 Context│▼LLM 再次思考Agent 其实正是依靠这种不断循环的方式逐步完成复杂任务。ReAct现代 Agent 的基础思想这种推理—行动—观察的模式在学术界被称为 ReActReason Act。它的核心思想非常简单Thought(思考)↓Action(行动)↓Observation(观察结果)↓Thought(思考)↓Action(行动)↓Observation(观察结果)例如当用户要求帮我定位这个 Bug。模型第一次思考我需要查看日志。于是生成 ActionRead Log。Runtime 执行后返回日志。模型继续思考日志显示数据库连接失败需要检查配置文件。于是再次生成新的 ActionRead appsettings.json。整个过程中每一次 Observation 都会影响下一次推理。因此Agent 并不是一次性生成完整方案而是在不断获取反馈、不断修正自己的判断。为什么很多产品不再展示 Thought(思考过程)早期很多 Agent 产品都会直接展示完整的思考过程例如Thought:我应该先查看配置文件……Action:read_file(appsettings.json)后来越来越多的商业产品开始隐藏这部分内容。原因主要有三个第一内部推理过程可能包含大量无意义的中间推断反而增加用户理解成本。第二思考过程可能暴露系统 Prompt、内部规则等敏感信息存在安全风险。第三不同模型的推理方式并不完全相同直接展示容易造成误解。因此现在更多产品会展示类似正在分析项目……正在读取代码……正在运行测试……正在生成报告……而不会完整显示内部推理内容。需要说明的是这并不代表模型没有推理过程而是这些过程由 Runtime 在后台协调完成并不一定需要全部呈现给用户。Action、Observation 与 MCP 的关系在第十一章我们介绍了 MCPModel 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 CompleteRuntime停止循环。然后给用户返回最终答案。所以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 SkillPython SkillSQL SkillKubernetes SkillDocker Skill产品设计 Skill测试 Skill运维 Skill每个 Skill 都包含几千甚至上万 Token。如果启动 Agent 时就把所有 Skill 一次性放入 Context不仅会迅速耗尽上下文窗口还会增加推理成本降低模型对当前任务的关注度。因此现代 Agent 普遍采用一种更加高效的方式,也就事我们上一章也讲过的——渐进式披露Progressive Disclosure。Runtime 并不会隐藏 Skill而是按需加载 Skill这里我们在简单回溯一下渐进式披露并不是让模型完全不知道有哪些 Skill。通常情况下Runtime 会先向模型提供每个 Skill 的基础信息例如Available SkillsJava 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 CommitClaude模型只是不断思考下一步。真正执行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 输出 ActionRuntime 执行并返回 Observation形成闭环。Runtime 还负责哪些工作包括 Context 管理、Skill 路由、Memory 检索、任务终止等。