3.2k Star、npm下载量33k、G-Star毕业项目：Comet v0.5.0正式发布

Hi，这次我们更新了非常多的东西，经过前期近几个月Native、Classic双线Skill的打磨，现在总算能够实现最初想要做的东西了

太长不看系列，本次更新核心特性如下：

1. Comet Any：组合任意Skill、为不同用户偏好动态产生自带Hook、Rule、状态机、Guard的Skill，支持为Native、Classic增加阶段
2. Comet Dashboard：支持Comet-Any过程可视化、支持Comet-Any产出的自定义工作流像Native Classic一样可视化、支持Comet Eval可视化评估任意Skill
3. Comet SDK：复用于Native、Classic稳定执行的底层，将核心的Comet使用的特性通过SDK方式发布出去、包括执行Skill与工具、分支并行与合流、子工作流、用户审批、持久化等14个通用特性
4. 可观测：支持运行性能、Change链路、个人记忆、项目知识核心数据可观测
5. Comet Skill: 底层重构，基于统一SDK能力构建的Native、Classic的Runtime升级

研发心得

研发心得分割线，长文警告-----------------------------------------------------------------------------------------------------------------------------------------

很早以前我曾经说过，怎么让长链路的Skill跑得稳定，通常还需要配合Hook、Rule、CLI、状态机、Guard等等

在这上面我们着重打造了Comet Native和Comet Classic，对应着ReAct模式和Workflow模式的Skill执行特征，经过了数月的持续开发，我们积累了许多来自国内大厂的用户，也成功的推广进了企业内部，大家在内部基于Comet思想开发了许多类似的工作流

在制作Classic的时候，我们就想象了一个场景，Hook、Rule、CLI、状态机、Guard的确是让模型在Comet加持下跑得更稳了，不过每个人对Skill都是有自己的偏好的

许多用户在Comet的仓库下询问过，能不能在某个阶段加入某个Skill，能不能和Matt、GStack、GSD等等自己偏好的Skill结合，虽然Comet Native已经能够做到和任意Skill按用户记忆偏好，让Agent自主在对应阶段调用Skill了，但这种ReAct式的原生方式，偶尔还是存在一些概率偏差。

Tip: 在最近数月，Native都是Comet用户最喜欢用的模式、强大的灵活性和原生Agent Skill的用法让他拥有了很多可能。

但由于用户的偏好众多，特定的通用Skill肯定无法满足每个人、每个企业的想法，如果每个人为了Skill的稳定性都要去了解和实现Hook、Rule、CLI、状态机、Guard这一大堆，那也显得太麻烦了

所以能不能有一种方式，让用户可以自定义Comet、或者组合任意Skill。

这个想法实现得非常困难，Comet-Any早在Comet第一个视频发出时就已经有这个想法，直到这个版本，我们才初步实现了想法，中途他一直是实验性的标签，但其实我在背后开发了许多版本，又推倒重来了许多次。

对于组合任意Skill的用法，大家最容易想到的就是采用Dify、Coze这样的编排工作流去编排自己的节点，不过最近2年，市场已经开始从Workflow转向ReAct Agent了，如果我们现在在做一个画布，让用户再来进行Skill编排，可能有点太落后了。

所以我们换了一种更AI Native的用法，能够通过自然语言进行任意Skill的编排，用户只需要描述自己想要组合的Skill偏好，Agent帮你去查找你的Skill并将他们的组合方案给到你，背后的Hook、Rule等等都交给Agent实现，基于Comet SDK的扩展机制，能够很方便扩展出属于自己的编排。这里有个历史经验：过去我曾经尝试过，只是将Comet的Runtime交给Agent参考，让他动态写Guard等等，但是最终产出的效果并没有达标，因为没有扩展点的原因，Runtime碎片化的代码，很难让Agent抓住重点

当然，另外还有一个问题Agent很难在一轮迭代中产出一个非常好的Skill、Skill通常是需要打磨的，所以我们将Comet Skill进化时制作的Comet Eval也接入进了Comet Any，这样做的好处是，当Any产出Skill的时候，你可以非常快速的通过评估沙箱运行知道他跑起来到底好不好用，如果不好用就可以基于他制作下一个版本，以此形成Eval Loop驱动的Skill Creator。

至此、支持Comet的3个板块的手脚就完整了

1. Comet Skill：Native、Classic两种分别适配强弱模型的Skill
2. Comet Eval: Rubric、Pass@k、Pass^k驱动的评估Harness
3. Comet Any: 组合任意Skill、改造Native、Classic，联动Eval的Skill Creator

以及在背后支撑Native、Classic应用的Comet SDK、Comet Dashboard可视化体系

对Comet价值的思考

在模型越来越强的今天，我们在不断的思考Comet的价值，或许模型够强之后我们不再需要Skill，但我们依然需要一些工程化建设。我其实把他定位为的是Skill Harness，这一层很多东西和Agent Harness很像，比如checkpoint，DAG，恢复中断，最不同的就是所有的tool call和llm请求是不需要写代码调用的，因为Skill在Agent平台上工作。

由于围绕的核心不同两个的Runtime会有一些区别，比如Agent harness里面肯定会有llm调用的代码，围绕他打造的Agent harness本身也是把提示词和代码约束写在代码上，从机制上看

• Agent Harness=Agent Loop+Hook+Memory+Sandbox+Mcp+Skill

但Skill有点不同，Skill的Agent loop变成了不同的Agent平台，由于平台带有Hook和Rule，等价于Agent Loop的上下文增强外置到了用户可以自己实现的地方，而不用了解Agent harness的内容，比如Rule最终被编译为System Pompt，其实等价于在Agent中写了一段System Message的定义给他，这种效果无论外置用户自己写，还是在内置agent代码中写都是一样的，对于模型来说都是一段System提示。所以

• Skill harness=最小化平台原生Agent Loop+平台Mcp+Hook+Rule+外置所有代码实现

效果上能够几乎等价于Agent Harness内部去代码实现。

所以在回到Comet的价值上，我的理解是他是一个能够迅速让任意Agent接入的，自带强大的需求推进能力+Skill Eval+Skill Creator+可观测的平台+SDK。当你的Agent不具备这些能力时，只需安装Comet，而不需要改任何一行代码就得到直观的系统建设提升

致谢

非常感谢各位曾经体验过Comet、或为Comet提过意见，祝大家越来越好~