Comet: 不止Skill

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

​

前言

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

​

开源历程

一、5月-初始开源OpenSpec+Superpowers组合 在5月份这个节点上，市面上还没有出现Fable5、GPT5.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. 没有跨设备0上下文恢复经常需要交代上下文、没有可靠的状态扭转、没有意图识别、没有强制的门禁守护，全凭Agent自觉

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

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

我带着这些问题，优先将Comet的OpenSpec+Superpowers的链路进行了连接，着重解决了长程嵌套Skill上怎么做稳定Skill触发、跨设备上下文恢复、状态机、意图识别、阶段门禁守护，然后进行了开源工作。也就是大家看到的初版Comet，其中思考的问题是如果我们能够基于这套长程任务Skill拿到可以复用的Skill Harness实践，那后续组合Skill并稳定执行这个问题就可以很好的解决了 二、6-7月-大厂相同实践开始宣发，Comet开始着手Eval评估和Skill组合，拥有了更多的渐进式加载最佳实践 在6-7月我们观察到有许多海内外大厂和组织如LangChain、Apache、腾讯、阿里、字节开始宣发类似思想的Skill实践，在我们开源之际，类似的文章还是没有的 所以后来我们专门写了一篇文章，让大家了解Comet是如何和海内外大厂拥有同样的实践思路的 https://docs.comet.rpamis.com/zh/tech-blog/comet-vs-industry 在那两个月我们集中打磨了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原始的5阶段工作流， 或者根据用户自己的Skill偏好生成一套类似Comet流程的Skill，自带Comet沉淀下来的Runtime运行时经验 三、7月-8月-Comet Native工作流诞生 随着Fable5和GPT 5.6的发布，我很快感受到，模型能力来到了一个新的阶段。GPT 5.6中展示出来了几乎和Superpowers类似的思维链，这印证了我之前多个视频的观点，“如果一个Skill的轨迹是相对固定的，那他一定能够被评估，只要我们做好评估侧的工作，将指标作为GroudTruth，就能够形成数据集，模型就是可以训练的”。 在发现这点之后，得益于之前已经打造好的Runtime，我在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 name和desc，判断要不要调用，而不是强制在流程中 在使用Native Skill的时候我们有非常多的自由用法，你可以不用Native的澄清，直接用grill me with docs产出的文档，纯粹把Native当做执行器，在自己的Loop循环内他能够完成你的文档内容

​

设计理念

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

1. 自进化记忆、自进化Skill、自动文档沉淀

这几个都是非常火热的方向，我在自进化主题的研究开始于Agent Skill这项技术成为正式公开标准之前，相关的PR提交给了Spring AI Alibaba DeepResearch https://github.com/spring-ai-alibaba/deepresearch/pull/20 目的是让Agent能够在用户无感知的情况下，在多轮会话中更懂用户的特点，并实时引导Agent的回答 当时(2025.12月初)这还是一个非常小众，只跑在论文上的方向，在社交平台上偶尔能够撇见一两篇，但都是浅尝即止 再后来的故事大家都知道，2026.2月的时候Hermes的火爆彻底引爆了这些方向 不过在设计上我们仍然不想把这些东西做到Skill里面去，或者说不做那么深 因为Memory、RAG方向的内容更多的是系统化工程，涉及到非常多的内容，在Skill侧的这两个方向无法真正的走向生产环境，因为Memory需要评估，需要后台运行，有不少公司专门做这个方向的垂类，实际上他以后更多的是一个独立系统，Coding Agent只需要插件式接入他即可。RAG也同样需要评估召回率，准确率，LLM as Judge的内容，还同时需要存在embedding model、处理复杂文档切片 我们可以看到每个方向单独展开都是一大片的内容，在Skill上完整实现没有太多必要，由于市面上做这个方向的开发者对Eval不关注，缺失Benchmark，导致很多工作其实是无效的，有很多顶会论文指出自进化记忆、自进化Skill产出的东西大多数都是不好用的，这仍然是一个值得深入研究的方向

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

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

3. 关于CLI

我相信很多开发者对于CLI有一个误解，就是做CLI是为了方便安装多个平台的，但其实在Comet中CLI的定位是Runtime/Harness的入口，我们把能够代码化的部分放到CLI快捷命令中，并在Skill内让Agent自己识别需不需要调用某个CLI，来做复杂但需要确定化的东西，比如对Comet的状态进行转化，这样做的好处是我们能够大幅缩减需要在Skill中描述的内容，让需要稳定执行的地方变成了代码，Agent不需要知道过多的信息，只需要了解作用即可。这就好像我们平时在使用电器的时候一样，我们不需要知道电器的具体原理和内部构造，只需要知道按某个地方是开，按另外一个地方是关就可以了。

​

欢迎贡献

五、最后的最后 Comet非常欢迎广大开发者们来参与贡献，哪怕是文档的改进工作都是可以的，我们希望大家在Comet中能够真正学到在工作中可以用的知识，而不仅仅是切换了一个看起来好用的Skill，如果各位对Comet有疑惑，Just try it，使用/comet 发起Skill做你想做的任何事情