> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comet: 不止Skill

> 回顾 Comet 从 OpenSpec 与 Superpowers 编排层走向 Runtime、Eval、Native 工作流的演进，以及背后的设计理念。

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

## 前言

本文解答下Comet到底是在做什么，以及我们的设计理念是什么

Comet最早让大家认识应该是在5月份刚开源的时候

[https://linux.do/t/topic/2232510/52](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](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](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做你想做的任何事情