Loading... > * 最近遇到一个【Agent 能力多端同步】的问题 > * 本文想探讨一种【中间层】的解决方案，这个中间层可以无缝地接入任一更高层级的服务 or 平台，从而做到实现 Agent 能力的多端同步 > * 结合最近业内的进展，Anthropic 包括各大 code agent 框架将 skills 作为了一种标准的 agent 能力包装范式，因此考虑能否以 skills 作为能力同步的中间层来解决上述问题 # Skills 的 know what Skill 的定义： * **物理意义上，skill 是一个结构化的文件夹**。文件夹的核心是一个包含 YAML 元数据的 SKILL.md 文件，以及一些支持 skill 运作的资源（文档、代码等） * **逻辑意义上，skill 只是约定了一种上下文渐进式披露的策略**。skill 定义了三个 level 的上下文加载阶段 * Level 1 - 技能发现，具体就是 YAML 元数据会常驻在系统的 system prompt 中 * Level 2 - 核心逻辑，具体就是 SKILL.md，这部分内容会在 skill 调用的时候加载到 context * Level 3 - 能力本身，对应附带的文档、代码等资源。这部分遵循**仅在需要时按需加载**的原则 Skill 的主要目的： * 解决上下文膨胀的问题 * 细粒度能力的专业化 * 提高任务执行的一致性与性能 # Skills 的 know how Claude-code 关于 skill 的实现没有开源，但我们可以看看 Opencode 中关于 skill 是如何实现的  Opencode 实现 skill 时引入了一种 Synthetic Message Injection 的做法（怎么更好地将 skill 加载进来的上下文传递给 llm，而又不破坏 prefix cache）。目的是： * 防止 llm 对 skill 加载这个 function call 进行无意义的回复（例如模型直接回“我已经加载了skill xxx”） * 与上下文压缩机制配合，标记了 skill 的上下文会在压缩阶段被 llm 重视 可能的误区阐明： * Skill 并不是一次性的概念，它一旦加载就会持续生效 * 我之前理解 skill 是一种特殊的 function call，它所有的上下文会被约束到这个 call 的内部 * skill 只是一种加载特定上下文的策略 * 所以在和 code agent 连续对话的过程中，不需要额外关心 skill 上下文维护的问题 * Skill 真的适合我们吗？我的目标 feature 特别明确，就是要在玩家按下特定的按钮触发布局、代码、体素等功能，那还有必要引入 skill 吗？ * 这其实是关于 sub agent 和 skills 选型的争议，首先明确引入 skill 是有优势的 * Skill 的 Level 1 2 3 渐进式披露策略已经得到了社区的验证，有一定的优越性 * Skill 在逻辑解耦上与 sub agent 相差不大，区别就是一个是封装成了一个文件夹，一个是封装成了 agent * Skill 在复用性方面有优势。目前基本主流的 code agent（claude code, codex, gemini-cli, opencode, cursor 等都已适配 skill 的范式），也就是开发一个 skill 可以做到多平台的无缝迁移 * 结合我们当前遇到的【Agent 能力多端同步】问题，这个可迁移的 feature 很适配 * Skill 和 MCP 的区别 * MCP 或 function call，只是一种 llm 动态获取/操作数据的标准范式 * Skill 是一种最初为解决上下文膨胀而提出的策略，skill 底层也是通过 function call 来实现的 最后修改：2026 年 01 月 14 日 © 允许规范转载 打赏 赞赏作者 赞 如果觉得我的文章对你有用，请随意赞赏