Comet: 不止Skill

脚趾剑匣 2026-08-18 17:03 1

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


前言


作为Comet的作者,本帖我解答下Comet到底是在做什么,以及我们的设计理念是什么


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



可以进入文档站详细了解下,以及最新的帖子


同时发布的还有一系列视频,由于最近没时间推广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是如何和海内外大厂拥有同样的实践思路的




下图来自于阿里的技术公众号


在这个月我们集中打磨了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将源码进行了开源


详细的介绍贴可见



本帖使用社区开源推广,符合推广要求。我申明并遵循社区要求的以下内容:

我的帖子已经打上 开源推广 标签: 是
我的开源项目完整开源,无未开源部分: 是
我的开源项目已链接认可 LINUX DO 社区: 是
我帖子内的项目介绍,AI生成、润色内容部分已截图发出: 是
以上选择我承诺是永久有效的,接受社区和佬友监督: 是

以下为项目介绍正文内容,AI生成、润色内容已使用截图方式发出
07-13更…


除此之外,我进一步的将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检测这部分依赖关系,能够并行的并行,有依赖的等待


Supervisor Change模式一览



Native工作流还迎来了一些更加自由的,RaAct式的实现机制


我们在使用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




目的是让Agent能够在用户无感知的情况下,在多轮会话中更懂用户的特点


当时(2025.12月初)这还是一个非常小众,只跑在论文上的方向,在社交平台上偶尔能够撇见一两篇,但都是浅尝即止


再后来的故事大家都知道,2026.2月的时候Hermes的火爆彻底引爆了这些方向


不过在设计上我们仍然不想把这些东西做到Skill里面去,或者说不做那么深


因为Memory、RAG方向的内容更多的是系统化工程,涉及到非常多的内容,在Skill侧的这两个方向无法真正的走向生产环境,因为Memory需要评估,需要后台运行,有不少公司专门做这个方向的垂类,实际上他以后更多的是一个独立系统,Coding Agent只需要插件式接入他即可。RAG也同样需要评估召回率,准确率,LLM as Judge的内容,还同时需要存在embedding model、处理复杂文档切片


我们可以看到每个方向单独展开都是一大片的内容,在Skill上完整实现没有太多必要,由于市面上做这个方向的开发者对Eval不关注,缺失Benchmark,导致很多工作其实是无效的,有很多顶会论文指出自进化记忆、自进化Skill产出的东西大多数都是不好用的,这仍然是一个值得深入研究的方向



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


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



  1. 关于CLI


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


欢迎贡献


五、最后的最后


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

最新回复 (10)
  • 洛卡卡了 08-18 17:11
    1

    大佬 我在用 native 的过程中有个问题,就是如果项目是前后端多个独立仓库的话,放在同一个父目录下面的话,comet 有没有更好的协作方式呢? 我是前后端分别初始化然后各自维护 change 还是可以跨仓库管理呢。这点我还没实践过但是目前没太好的思路。

  • 后仰跳投 08-18 17:57
    2

    怎么着?我完整看完还能抢到2楼~~~写的很用心,感觉是个好东西,看的我蠢蠢欲动的,这就踹这就try

  • 脚趾剑匣 楼主 08-18 18:46
    3

    如果是一个父目录下来有多个git仓库,其实在父目录去初始化comet就可以用了,不过如果需要change跟着某个仓库跑,那么需要在这个仓库中去初始化,尤其是在各自仓库里面有独立演进式的需求的时候,我在开发comet的时候里面有挂载一个gitsubmoudle的git仓库,用于同步一些文档,那个仓库就是没有初始化过comet的,但是comet主目录有初始化过,一般在主目录里面描述要去子目录做的事情也能做到

  • 洛卡卡了 08-18 18:56
    4

    感谢大佬解答 晚点我试一下看看效果咋样,还有个情况就是native模式如果针对单文件修改、配置调整或者小bug的时候有没有轻量入口呀?意思就是直接跳过完整的 runtime和归档流程这种。我在使用过程中好像只要用/comet 就会走这样的。目前有更好的方案吗还是我的方法不太对?

  • qyy 08-18 18:59
    5

    看起来有点牛啊,我想用那个批量澄清功能

  • 灿烂甜菜 08-18 19:10
    6

    佬我感觉你已经站在前沿角度和更长远考虑推出了Comet Native,想问下和Trellis的核心区别和适用场景是什么呢

  • 脚趾剑匣 楼主 08-18 20:29
    7

    我其实觉得如果太小的调整不需要记录的话直接改就行了,git提交记录就是最好的答案,如果确实是需要记录的,直接告诉native并说跳过澄清,他能够把你的内容记录澄清文档里面,由于验收的内容比较少我理解跑完流程也不需要多少时间,native就是根据前期记录的文档多少当成依据的

  • 脚趾剑匣 楼主 08-18 20:30
    8

    欢迎体验comet佬,感受下批量澄清的特点~ ^-^

  • 脚趾剑匣 楼主 08-18 21:23
    9

    佬我没有深度使用过Trellis的skill,所以在Skill上其实我不太了解Trellis,从文档的观感上我觉得Trellis强调的是团队化的规范,有一些共同的观点比如跨设备跨会话的恢复要在Skill侧做,其他的有些类似的技术,比如自动推进等等。其实通过对比文档和具体实现过程我觉得还是能感受到两者的设计仅仅是一些使用技术的类似,想要解决的问题是各不相同的,Comet从诞生开始到后续围绕打造的东西更想要的是科学的通过指标驱动迭代,沉淀可复用的Runtime/Harness、稳定Skill执行链路,这是一套系统工程,这些在大家面向工作场景上时会很有帮助


    整体Comet就分为3个部分:




    • Comet的Skill部分适合于按需求/功能(Change)推进一项任务,也适合于真实大型PRD拆分型任务,记录相关的文档并保存需求,让Agent在长程任务上能够跑的稳




    • Comet的Eval部分适合于评估任意Skill,用指标去驱动Skill的迭代




    • Comet Any部分适合于想要组合任意Skill,又不想思考过多的Runtime/Harness技巧,达成类似Comet在长程任务稳定的效果



  • 甘尼克斯 08-18 23:21
    10

    一直有关注comet,确实感觉在快速迭代中,所以想等沉淀出一个好用的版本后再开始用

* 帖子来源Linux.do
返回