AI Coding Agent 的能力加载，已经从「启动时读几份规则文件」发展成一套完整的上下文控制面。

这套控制面要处理发现、触发、注入、隔离、压缩恢复、权限和分发。Skill 只是其中一个可复用单元，不等于整个上下文系统。

事实核验截止日期：2026-07-17。文中版本与日期均链接到官方 Changelog、官方文档或官方仓库；living docs 没有发布日期时，只按本次访问结果描述当前行为。

先把四个层次分开

不少比较把模型、API、Agent Harness 和最终产品混在一起，结论因而从起点就错位。

  • 模型层决定上下文窗口、注意力分布、推理能力和工具调用能力。
  • API 层提供 instructions、tools、input items、prompt cache、compaction 等原语。
  • Harness 层扫描规则与 Skill，组装上下文，调度工具、子 Agent 和压缩流程。
  • 产品层再叠加编辑器、CLI、插件市场、权限界面、团队策略和云端执行。
flowchart TB
    M["模型层<br/>窗口、注意力、推理、工具调用"]
    A["API 层<br/>instructions、tools、cache、compaction"]
    H["Harness 层<br/>发现、路由、注入、恢复、调度"]
    P["产品层<br/>IDE、CLI、权限、插件市场、团队治理"]

    P --> H
    H --> A
    A --> M

    R["Rules / AGENTS.md / CLAUDE.md"] --> H
    S["Agent Skills / Commands"] --> H
    X["Hooks / Subagents / MCP"] --> H

这个分层直接订正了一个常见误判：Kimi K2 是模型系列，Kimi Code CLI 才是 Coding Agent Harness。模型拥有更大的上下文窗口，不能推出产品会在启动时全量注入 Skill 正文。

Kimi K2 官方仓库与 Kimi K2-0905 公告描述模型能力；Kimi Code 官方仓库和 Kimi Code Skills 文档描述 Harness 行为。两组材料回答的是不同问题。

静态 Rules：把稳定约束放进启动上下文

第一代能力扩展很朴素：在仓库或用户目录放一份 Markdown，Agent 启动时读取，随后把它当作持久指令。

Claude Code 使用 CLAUDE.md 与 .claude/rules/，Codex 使用分层 AGENTS.md，OpenCode 原生读取 AGENTS.md 并兼容 CLAUDE.md。Cursor 早期使用 .cursorrules，后来迁移到 .cursor/rules/。

Rules 适合稳定事实：构建命令、目录边界、编码约定、验证入口和禁止事项。它们的优势是确定、可审查、能随仓库版本化；代价是长期占用上下文，内容越大，当前任务所需部分越难突出。

「静态」也不等于所有规则都无差别常驻。当前产品已经提供多种作用域：

  • Codex 从项目根目录走到当前工作目录，按层拼接 AGENTS.md，默认总预算为 32 KiB。
  • Claude Code 的无路径规则在启动时加载，带 paths 的规则在读取匹配文件时加载。
  • Cursor Project Rules 支持 Always、按模型判断、按 glob 附着和手动调用。
  • OpenCode 可在配置里组合额外 instruction 文件，也可以让 AGENTS.md 指向按需读取的材料。

Cursor 的演变很有代表性。0.45.x 在 2025-01-23 引入 .cursor/rules，允许一个仓库保存多份规则并由 Agent 选择；0.49 在 2025-04-15补上文件读写时的 Auto Attached 规则，并修复 Always Rules 跨长对话摘要后的持续生效。

这一步把单一全局文件拆成了可分片、可匹配、可嵌套的规则集合。它解决了「什么范围生效」，还没有解决复杂流程如何复用。

Commands：把触发时机交给用户

Rules 之后出现的是自定义 Commands。它通常是一段可带参数的 Markdown Prompt，由用户通过 /deploy、/review 之类的命令显式展开到当前对话。

Command 的价值在于时机明确。部署流程不必每轮常驻，进入部署任务时再把检查清单放进当前上下文即可。

它的边界也很清楚：单文件 Prompt 很难自然携带脚本、模板、参考资料、权限声明和隔离执行配置。复杂 Command 往往继续膨胀，变成另一份大文档。

Claude Code 已把自定义 Commands 合并进 Skills：.claude/commands/deploy.md 仍然兼容，但 .claude/skills/deploy/SKILL.md 能增加支持文件、自动匹配和子 Agent 执行。Claude Code Skills 当前文档明确说明了这条兼容路径。

Commands 没有消失。它仍是人工触发能力的好入口，只是不再适合作为复杂能力包的唯一结构。

Agent Skills：从正文常驻变成渐进披露

开放的 Agent Skills 格式把能力组织成一个目录：

1
2
3
4
5
my-skill/
├── SKILL.md
├── scripts/
├── references/
└── assets/

Agent Skills 规范定义了三层渐进披露：

  1. 会话启动时只暴露 name 和 description 等目录信息。
  2. 用户或模型选择 Skill 后，完整 SKILL.md 才进入上下文。
  3. 脚本、参考资料和资产继续按任务需要读取或执行。
sequenceDiagram
    participant FS as 文件系统
    participant H as Agent Harness
    participant L as LLM
    participant T as Tools

    H->>FS: 扫描 Skill 目录
    FS-->>H: name + description + path
    H->>L: 注入轻量能力目录
    L->>L: 根据任务判断相关性
    L->>H: 选择或调用 Skill
    H->>FS: 读取 SKILL.md
    FS-->>L: 返回完整流程说明
    opt 需要外部资源
        L->>T: 读取 reference 或执行 script
        T-->>L: 返回所需结果
    end

这个结构把「知道有什么能力」与「把能力细节放进上下文」分开。启动成本主要由目录决定，执行成本只由本次实际选择的 Skill 决定。

截至核验日期，五个工具已经出现明显收敛，但实现细节并不相同：

工具 发现与触发 正文加载 当前特征
Claude Code 描述供模型匹配，也支持 /skill-name 调用时作为一条消息进入会话 支持动态上下文、热变更检测、context: fork、compact 回灌
Codex 初始目录含名称、描述和路径；支持显式与隐式调用 选中后读取 SKILL.md 初始目录有 2% context 或未知窗口时 8,000 字符的预算
OpenCode skill tool 描述列出可用 Skill skill({name}) 返回正文 原生按需工具，支持 Skill 级 allow / ask / deny
Cursor Agent 自动发现，也可从 slash 菜单调用 相关时读取 Skill 与资源 Skills 与 Rules 并存，强调动态上下文发现
Kimi Code 描述和 whenToUse 供模型判断，也支持 /skill:<name> 调用时把正文送给 Agent 项目、用户、额外目录、内建四级发现，支持 flow 型手动 Skill

Claude Code 当前并不会在启动时加载所有 Skill 正文，也没有官方依据证明它每轮追加完整 Skill catalog。官方 Skills 生命周期给出的行为是：正文在调用时进入会话，后续轮次保留，但不会自动重新读取文件。

OpenCode 的行为更显式。官方 Skills 文档显示，模型先在 skill tool 描述里看到名称与描述，随后通过 skill({ name: "..." }) 取回完整内容。Skill 权限还能按名称模式配置为 allow、ask 或 deny。

Codex 同样采用渐进披露。官方 Build Skills 文档说明，启动目录只放名称、描述和路径，选择后再读取正文；references 与 scripts 继续按需使用。

Cursor 在 2.4 版本，2026-01-22正式支持 Agent Skills 与 Subagents。官方把 Skills 定位为动态、程序化的 how-to，把 Rules 留给长期声明式约束。

Kimi Code 的官方文档也明确支持模型自动调用与 /skill:<name> 手动调用。它扫描 .kimi-code/skills/、.agents/skills/、用户目录和额外目录，说明 Kimi Code 采用的是目录发现加按需调用，并非借助 Kimi K2 的窗口做正文全量启动注入。

动态上下文发现：文件成为能力索引

渐进披露仍有一个前提：Harness 要让模型知道去哪里找细节。

Cursor 在 2026-01-06 的 Dynamic Context Discovery中把这个思路扩展到 Skill 之外：

  • 长工具输出写入文件，模型用 tail、搜索或分段读取找需要的部分。
  • 摘要后的完整聊天历史保留为文件，缺失细节可以回查。
  • Skill 只前置名称和描述，正文通过文件搜索发现。
  • MCP 工具描述同步到目录，需要时再加载具体 schema。
  • 集成终端历史也作为文件暴露，而非全量塞进 Prompt。

这项设计没有创造新的上下文类型。它把大块、低命中率内容移出常驻窗口，再给模型留下地址和检索工具。

Skill 与 MCP Tool 也不能混为一类。Skill 主要携带流程知识；MCP Tool schema 描述可调用动作。两者都能采用「轻目录 + 延迟加载」，但加载后的消费方式不同。

Subagents：把上下文切成独立工作集

随着任务变长，按需加载仍可能让主会话堆积大量搜索结果、工具输出和中间推理。Subagent 用独立上下文承接局部任务，只把任务描述和最终结果带回主会话。

Claude Code 的 Skill 可以通过 context: fork 在隔离上下文执行。Cursor 2.4 的 Subagents 使用独立 context；Kimi Code Subagents也明确只接收主 Agent 传入的任务描述，最终结论回到主上下文。OpenCode 则把 primary agent 与 subagent 做成可配置角色。

flowchart LR
    U["用户任务"] --> O["主 Agent<br/>规则、目录、计划"]
    O --> E["Explore 子 Agent<br/>独立上下文"]
    O --> R["Review 子 Agent<br/>独立上下文"]
    O --> X["Executor 子 Agent<br/>独立上下文"]
    E --> S["压缩后的发现"]
    R --> S
    X --> S
    S --> O

这种隔离会省下整个局部轨迹的上下文成本。搜索日志、失败尝试和大量只读材料留在子上下文中，主会话只接收可继续决策的结果。

Compact：压缩之后还要能恢复能力

上下文压缩是有损操作。摘要能保留任务状态，却可能删掉规则细节、Skill 参数、文件路径和失败原因。成熟 Harness 因而需要 rehydration，也就是压缩后的定向回灌。

stateDiagram-v2
    [*] --> Active: 启动并装配规则与能力目录
    Active --> Loaded: 调用 Skill / Tool / Subagent
    Loaded --> Pressure: 历史和工具结果增长
    Pressure --> Compact: 自动或手动压缩
    Compact --> Rehydrate: 恢复稳定规则与必要能力
    Rehydrate --> Active: 继续任务
    Rehydrate --> Recover: 从历史文件或状态文件补细节
    Recover --> Active

各家对恢复的公开承诺差异很大，不能把一种产品的细节套给另一种产品：

  • Claude Code 会在 compact 后重新附加最近调用的 Skill。当前上限是每个 Skill 取前 5,000 tokens，合计 25,000 tokens，并从最近调用的 Skill 开始填充。Context Window 文档给出了这组明确预算。
  • Cursor 在摘要后提供历史文件引用，Agent 可以搜索原始历史补回摘要丢失的细节。
  • OpenCode 允许插件在 experimental.session.compacting 阶段向 continuation summary 注入状态，甚至替换 compaction prompt。OpenCode Plugins 文档展示了这一扩展点。
  • Kimi Code 自动压缩临近上限的历史，也支持 /compact 手动提示保留重点。Sessions and Context说明了会话持久化与压缩；v0.8.0，2026-06-02又把 todo list 附进摘要。
  • Codex 支持自动和手动 compact，当前运行时使用 Responses compaction 原语。公开资料没有给出「compact 后每个本地 Skill 回灌多少」的产品契约，因此不能照搬 Claude Code 的 5k / 25k 规则。Codex Agent Loop只支持描述已公开的装配与压缩机制。

Claude Code 还有一个容易混淆的版本变化。v2.1.202（官方 npm 发布时间：2026-07-06）之后，相同渲染内容的 Skill 再次调用只追加简短的「已加载」提示；参数或动态内容改变时才追加完整正文。这是重复调用去重，每轮重新注入并未发生。

Hooks：把确定性动作移出自然语言

Rules 和 Skills 都要经过模型解释。审计、拦截、密钥检查、格式化和停止条件若要求确定性，应落到 Hook、权限或 sandbox。

Cursor 1.7，2025-09-29加入 Hooks 与 Team Rules；Claude Code、Codex、OpenCode、Kimi Code 也都提供不同粒度的生命周期扩展点。

Hook 可以观察 PreToolUse、PostToolUse、PreCompact、SessionStart 或 Subagent 事件。它还可能注入上下文，但自身是 Harness 执行的程序，不应被描述成另一种 Skill。

这一步让「建议模型遵守」与「运行时必须执行」分开。Skill 负责程序性知识，Hook 负责事件上的确定性控制，权限系统负责动作边界。

Plugins：能力加载进入治理阶段

Plugin 处在安装、版本和分发层；Skill 的加载算法仍由 Harness 决定。

flowchart TB
    P["Plugin<br/>版本、来源、命名空间、安装策略"]
    P --> S["Skills<br/>按目录发现与渐进披露"]
    P --> M["MCP / Apps<br/>外部工具与数据"]
    P --> H["Hooks<br/>生命周期控制"]
    P --> A["Subagents<br/>隔离角色与工具权限"]
    P --> R["Assets / Rules<br/>模板与声明式指导"]

    G["治理层<br/>信任、权限、启停、更新、审计"] --> P

Claude Code Plugin 可以打包 Skills、Agents、Hooks 和 MCP servers。官方 Plugins 文档把 standalone 配置定位为项目内快速迭代，把 Plugin 定位为可版本化、可跨项目分发的能力包。

Codex 的 Skill 仍是工作流创作格式，Plugin 则把 Skills、MCP 或 app connector、Hooks 和展示资产组合成可安装单元。Codex Build Plugins 文档列出了这些组件；生态分发不会改变 Skill 正文的渐进披露规则。

Cursor 2.5，2026-02-17推出 Marketplace Plugins，把 Skills、Subagents、MCP servers、Hooks 和 Rules 合成一次安装；后续 Customize 页面继续把用户、团队和工作区级配置收拢到统一管理面。

Kimi Code v0.4.0，2026-05-27上线 Plugin 系统。当前插件可声明 Skills、MCP servers、Hooks 与 session-start Skill，但每种组件仍按自己的生命周期工作。

OpenCode 的 Plugin 更接近 JS / TS 运行时扩展。它可以定义工具、订阅事件并干预 compaction；Skill 则继续由原生 skill tool 加载。两者可以协作，没有被合并成一个上下文注入动作。

Plugin 阶段新增的核心问题是信任：谁发布、谁批准、带了哪些工具、Hook 是否执行本地程序、外部系统需要什么 OAuth 权限、升级后行为是否改变。安装一个 Plugin 也不会自动绕过宿主的 sandbox 和审批策略。

能力演变的主线

flowchart LR
    R["静态 Rules<br/>启动时装配稳定约束"]
    C["Scoped Rules / Commands<br/>按目录、文件或人工触发"]
    S["Open Agent Skills<br/>目录先行，正文按需"]
    D["动态上下文发现<br/>文件索引、延迟工具、子上下文"]
    L["生命周期恢复<br/>compact、rehydration、hooks"]
    P["Plugin 治理<br/>版本、权限、分发、审计"]

    R --> C --> S --> D --> L --> P

几个官方时间锚点能看出这条路线：

各产品没有一张统一版本表。这些时间锚点共同显示出关注点的迁移：早期关心「把规则放进去」，现在还要回答「何时发现、谁来触发、压缩后怎样恢复、工具如何授权、能力包由谁分发」。

一套更稳定的分析框架

以后比较 Coding Agent 的 Skill 机制，可以固定检查这些问题：

  • 比较的是模型、API、Harness，还是某个产品 surface？
  • 启动上下文里是完整正文、轻量目录，还是一组文件地址？
  • 激活由用户、静态 matcher、模型判断，还是生命周期事件决定？
  • Skill 正文进入哪类消息，重复调用是否去重，文件修改是否追溯替换旧正文？
  • references、scripts、assets 和 Tool Schema 在什么时点加载？
  • compact 后哪些内容自动回灌，哪些只能重新匹配或回查历史？
  • 子 Agent 拿到完整主会话，还是只拿任务描述和显式传入的资源？
  • Plugin 只是分发容器，还是还携带 Hook、MCP、权限和供应链风险？

用这组问题重新看当前生态，单纯按「全量加载」和「按需加载」分类已经不够。主流工具大都采用轻量目录与延迟正文，具体差异落在路由、消息生命周期、恢复预算、隔离执行和治理表面。

系列文章

参考资料