15.6 Runtime 如何知道任务完成?

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