Comet：不止 Skill

本文内容较长，如果你耐心读完相信会有收获。

​

前言

本文解答下 Comet 到底是在做什么，以及我们的设计理念是什么。 Comet 最早让大家认识应该是在 5 月份刚开源的时候：LINUX DO 社区讨论帖。 同时发布的还有一系列视频。由于最近没时间推广 Native 模式，老视频的热度很高，很多人对 Comet 的认识就是它是一个 OpenSpec + Superpowers 的编排层，但其实我们在第一个视频就已经指出了 Comet 组合他们两个从来不是目的；随着 Comet 的快速迭代，它已经不仅仅是一个 Skill 了。我们只是需要一个足够强大、链路足够稳定的 Skill 来沉淀出符合真实工作、生产环境可用的运行时（Runtime/Harness）。这里我以时间正序列举，Comet 各个大版本迭代是要去解决什么问题。

​

开源历程

一、5 月：初始开源 OpenSpec + Superpowers 组合 在 5 月份这个节点上，市面上还没有出现 Fable 5、GPT-5.6 这类具备 Superpowers 思维链的强模型。在这个前提下，OpenSpec、Superpowers 在当时的模型上还是非常有效的方法。在开源之前我已经深度使用了这类 SDD 很久（大概几个月的时间），此时 mattpocock/skills 还没有在国内火出圈，没有公众号铺天盖地的推广。 在当时的时间节点，我在使用这类 SDD 时主要面临着几个问题：

1. 有超过 90% 的时间我都在点 yes，有太多的 Skill 名字需要记忆，但很多流程是相对固定的，却需要手动调用。
2. Superpowers 没有原生管理需求的能力，OpenSpec 有原生管理需求的能力，但澄清维度不足。

所以因为想要偷懒，我将他们两个结合起来进行了 SOP 封装，最早他们是在 CLAUDE.md 中的纯文本编排。 但很快我就发现，长链路嵌套 Skill 调用带来了一系列问题：

1. Agent 在多次上下文压缩后，完全忘记了下一步该调用什么 Skill。
2. Agent 没有真实触发 Skill，但是做了类似 Skill 要求的事情，执行过程中容易出现遗忘。
3. Agent 跳过了关键 Skill 流程直接开始写代码（比如链路上要求澄清完毕之后才能开始写代码，Agent 没有问任何问题就直接开干了）。
4. 没有跨设备状态恢复（经常需要重复交代上下文）、没有可靠的状态转移、没有意图识别、没有强制的门禁守护，全凭 Agent 自觉。

与此同时我们还有另外的真实工作需求：

1. 对于个人：每个人都有自己的 Skill 偏好，比如一个人可能喜欢 grill-me，另外一个人喜欢 brainstorming，和评论区大多数佬友们一致，我们喜欢挑选好用的 Skill 来自己组装。
2. 对于团队：业务上我们经常需要对接其他团队的 Skill，这些 Skill 不是我们写的，但是编排链路一长，在当时的基础模型能力下怎么稳定执行就成了问题，很容易踩坑。
3. 对于业界：现成的好用 Skill 非常多，假如我们需要 Word、Excel 处理能力，用官方写的肯定比自己让 AI 临时写的好得多。

我带着这些问题，优先将 Comet 的 OpenSpec + Superpowers 链路连通，着重解决了长程嵌套 Skill 场景下怎么做稳定 Skill 触发、跨设备状态恢复、状态机、意图识别与阶段门禁守护，然后进行了开源工作。也就是大家看到的初版 Comet，当时思考的核心是：如果我们能够基于这套长程任务 Skill 沉淀出可复用的 Skill Harness 实践，那后续组合 Skill 并稳定执行的问题就能迎刃而解了。 二、6-7 月：大厂相同实践开始宣发，Comet 开始着手 Eval 评估与 Skill 组合，拥有了更多的渐进式加载实践 在 6-7 月我们观察到有许多海内外大厂和组织（如 LangChain、Apache、腾讯、阿里、字节）开始宣发类似思想的 Skill 实践；在我们开源之际，类似的文章还是很少的。 所以后来我们专门写了一篇文章，让大家了解 Comet 是如何与海内外大厂拥有同样实践思路的：Comet 与业界实践对照。 在那两个月我们集中打磨了 Comet 的渐进式加载，引入了更多可原子化的 Reference，包括用户停顿点（HITL）、自动推进 Skill 协议、上下文恢复协议、工作区标准等等。 这些文件内容都不大但思路是很清晰的，大家可以在对应的机制中学到东西 同时随着 Comet Skill 的高速迭代，我们迫切需要一个能够评估 Skill 的机制来衡量：每一次 Skill 变更的方向到底有没有副作用，Skill 是否真的变好了。 随着我们的用户增多，我们不能够凭手感来做这件事情。过去我见过非常多的 Skill 作者，大家用 AI 迭代得很快，但功能不稳定，效果好不好全凭手感，这不是一个良好的迭代模式。 彼时我们依旧没能在社交平台上看到很多 Eval 工作，很多都跑在论文上，有的评测过于简单，并不适合于 Coding Agent 这种经常需要和用户交互的场景。 我们在 Eval 上做了很多扎实的工作，包括怎么用用户最常使用的 Claude Code、Codex 去评估任意的 Skill，怎么让整个评估过程全自动化，怎么使用 Rubric、Pass@k、Pass^k 评分评估 Skill、怎么接入 LangSmith、Langfuse。 为了让 Skill 迭代变成一个系统性的工程，我们克服了非常多的困难，用实打实的真实 Token 消耗进行了评估，并将这部分命名为 Comet Eval，开放了全部源码。 除此之外，我进一步将 5 月待解决的问题——“如何组合 Skill”进行了深入开发。我没有选择做一份类似 Dify 的 Skill 编排可视化系统，我觉得那样做不够 AI 原生，可能很快面临着过时的风险。所以最终它变成了 /comet-any 这种 AI Native 的 Skill，能够改造 Comet 原始的五阶段工作流，或者根据用户自己的 Skill 偏好生成一套类似 Comet 流程的 Skill，自带 Comet 沉淀下来的 Runtime 运行时经验。 三、7-8 月：Comet Native 工作流诞生 随着 Fable 5 和 GPT-5.6 的发布，我很快感受到，模型能力来到了一个新的阶段。GPT-5.6 中展示出来了几乎和 Superpowers 类似的思维链，这印证了我之前多个视频的观点：“如果一个 Skill 的轨迹是相对固定的，那它一定能够被评估；只要我们做好评估侧的工作，将指标作为真实状态（Ground Truth），就能够形成数据集，模型就是可以训练的。” 在发现这点之后，得益于之前已经打磨好的 Runtime，我在 GPT-5.6 发布几天后就开源了 Comet Native Skill，我的核心思考是：

1. 当模型能力足够强大之后，Skill 即将迎来类似过去 Agent Loop 从 Workflow 式核心全面走向 ReAct 核心的转变。
2. Superpowers 的工程铁律对于强模型而言容易与原生思维链发生冲突，但还是有很多我们可以考虑留下的实践，比如 TDD、Brainstorming。
3. Skill 更应该注重要记录什么、要做什么、怎么验收，具体怎么做我们不再需要硬性规定，几个极其轻量的文档足矣。

这样做出来的 Native Skill 只用了 100+ 行 Skill 内容就完成了核心工作。同时我们原生支持了 grill-me 式的高强度澄清，分为线性澄清和批量澄清两种模式；与之带来的是在 benchmark 上减少了 75% 的 Token 消耗和 45% 的时间，同时没有发生准确率下降。核心采用 Loop Engineering 驱动，并带有 Supervisor Change 模式，真实贴合工作环境：通常我们在工作时都是一个大型需求下派发子需求，Native 能够通过 DAG 检测这部分依赖关系，能够并行的并行执行，有依赖的自动等待。 Native 工作流还迎来了一些更加自由的、ReAct 式的实现机制。 我们在使用 Native 工作流时没有指定任何实现方法，但当你在本地安装了 TDD、BDD 这样的方法型 Skill 时，Agent 会自己在实现过程中判断并发起 TDD 实现。 这让我们回到了 Skill 的本质：模型根据 Skill 的名称和描述判断要不要调用，而不是被强制锁死在死板流程中。 在使用 Native Skill 的时候我们有非常多的自由用法：你可以不用 Native 的澄清，直接用现有文档，纯粹把 Native 当作执行器，在自己的 Loop 循环内它就能完成你的文档目标。

​

设计理念

四、最后是关于我们的设计理念 Comet 对于功能堆砌保持一定克制，以下是我们的思考。

1. 自进化记忆、自进化 Skill、自动文档提炼

这几个都是非常火热的方向。我在自进化主题上的研究开始于 Agent Skill 这项技术成为正式公开标准之前，相关的 PR 提交给了 Spring AI Alibaba DeepResearch：Spring AI Alibaba DeepResearch PR #20。 目的是让 Agent 能够在用户无感知的情况下，在多轮会话中更懂用户的特点，并实时引导 Agent 的回答。 当时（2025 年 12 月初）这还是一个非常小众、基本只停留在论文上的方向，在社交平台上偶尔能瞥见一两篇，但也都是浅尝辄止。 再后来的故事大家都知道了，2026 年 2 月 Hermes 的火爆彻底引爆了这些方向。 不过在设计上，我们仍然不想把这些东西全部硬塞到 Skill 里面去，或者说不做那么重。 因为 Memory、RAG 方向的内容更多的是系统化工程，涉及到非常多的链路：Memory 需要评估、需要后台守护运行，业界有不少团队专门深耕这个垂类，实际上它以后更应该是一个独立系统，Coding Agent 只需要插件式接入它即可；RAG 也同样需要评估召回率、准确率与 LLM-as-judge，同时还需要 embedding 模型与复杂的文档切片。 可以看到每个方向单独展开都是很大的体系，在单一 Skill 上完整实现没有太大必要。由于市面上部分开发者对 Eval 关注不够，缺失 Benchmark，导致不少工作容易流于形式。已有学术论文指出很多自进化记忆和自进化 Skill 产出的内容在实际任务中并不好用，这仍然是一个值得严肃研究的课题。

2. 跨 Agent 的团队 Harness 文件注入

这部分可以做的是补全各类 Coding Agent 缺失的 Rule 机制，可以通过 Hook 选择性注入相关规则文档。长期来看，对于各家 Coding Agent 团队而言规则注入并不难实现。其实依靠 linter 能够做到很多事情，比如将规则建立为 linter 插件，让不符合规范的代码在编译或检查时强制失败，Agent 看到报错后自然知道如何修复，这也是确定性后置约束的一种。

3. 关于 CLI

我相信很多开发者对于 CLI 有一个误解，以为做 CLI 只是为了方便适配多个平台。但其实在 Comet 中，CLI 的定位是 Runtime/Harness 的入口：我们把能够代码化的部分沉淀为确定性的 CLI 命令，并在 Skill 内让 Agent 自己识别需不需要调用某个命令，来完成复杂但需要固定规则的操作（比如对 Comet 的状态进行转换）。这样做的好处是我们能够大幅缩减需要在 Skill 中描述的篇幅，让需要稳定执行的地方变成可执行代码。Agent 不需要知道过多的底层细节，只需要了解它的作用即可——这就好像我们平时使用电器一样，不需要知道电器的内部电路构造，只需要知道按这个开关是开、按那个开关是关就可以了。

​

欢迎贡献

五、最后的最后 Comet 非常欢迎广大开发者参与贡献，哪怕是文档的改进都十分欢迎。我们希望大家在 Comet 中能够真正学到在工作中可用的工程知识，而不仅仅是切换了一个看起来新奇的 Skill。如果各位对 Comet 有疑惑，Just try it，运行 /comet 开始你的第一个变更！