深度解析Comet 0.4.0架构：纯Node.js运行时上的确定性Skill引擎是如何构建的

深度解析Comet 0.4.0架构纯Node.js运行时上的确定性Skill引擎是如何构建的【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/cometComet 0.4.0 是一个只依赖纯 Node.js 运行时的 Agent Skill 平台它内置了一套确定性 Skill 引擎把 AI 编码 Agent 的长任务变成可恢复、可校验、可评测的工作流。本文面向新手用尽量少的代码带你拆解这套引擎背后的 4 个关键设计。一、为什么 0.4.0 是架构跃迁 先说结论0.3.x 是脚本编排层0.4.0 是运行时平台。在 0.3.x 时代Comet 靠 7 个 Bash 脚本comet-state.sh、comet-guard.sh等串联 OpenSpec 与 SuperpowersWindows 用户必须额外安装 Git Bash 或 WSL还要踩 BSD/GNU 命令兼容的坑。0.4.0 把这些脚本全部替换为由 TypeScript 源码生成的独立.mjsNode 命令脚本运行环境只剩Node.js 22.16 / 24。这一步带来的用户价值很直接维度0.3.xBash 脚本0.4.0纯 Node.js 运行时运行依赖Bash / Git Bash / WSL只需 Node.jsWindows 支持需要额外环境易踩坑原生可用脚本来源手工维护的 .shTypeScript 源码统一生成跨平台行为一致状态解析每个脚本各自解析 YAML共享同一份状态与转移语义安装后的效果是这样的——在项目里输入/comet即可进入五阶段工作流生成的脚本入口清单维护在 config/repository-layout.json可以看到 Classic、Native、Entry 三套运行时分别由哪些 TypeScript 入口编译而来。二、确定性 Skill 引擎4 个关键设计 0.3.x 的 Skill 只是Markdown 文档 脚本Agent 按文档自由发挥0.4.0 把 Skill 变成可执行、可校验、可恢复的包。确定性来自下面 4 层设计1. 状态分离用户状态与引擎状态各管各的旧版把用户字段和引擎字段混在一个.comet.yaml里Agent 稍一误改就可能破坏运行状态。0.4.0 做了三分法.comet.yaml只保留用户可读可改的投影workflow、phase 等.comet/run-state.json引擎独占的运行态当前步骤、迭代、待处理动作.comet/state-events.jsonl追加式审计日志记录每次状态转移的来源与结果这样自动推进为什么发生完全可追踪而comet-state set会拒绝写入引擎字段从源头防止误改。2. 转移表一份语义多处共享Classic 工作流的所有阶段转移由 domains/comet-classic/classic-transitions.ts 中的转移表统一定义status、guard --apply、归档路径共享同一份转移语义而不是各命令各写一套推断逻辑——这是确定性的第一个来源。3. 执行循环决策由引擎做出而不是 Agent 猜测引擎核心是一个极简但严格的执行循环位于 domains/engine/loop.tsRun State持久化当前步骤、迭代次数和待处理动作Trajectory / Checkpoints把执行轨迹和检查点落到磁盘trajectory.jsonl、checkpoint.jsonGuardrails在执行前校验每个动作的授权范围越界动作直接被拒所以长上下文被压缩、甚至会话中断后引擎能从快照精确恢复到中断点而不是靠 Agent 重新读文档猜进度。4. 不依赖 LLM 的确定性基准测试引擎自带一套 Runtime Evals迁移、重试路由、handoff 恢复、归档恢复、畸形状态拒绝、幂等、契约保持共七类场景全程不依赖 LLM 和网络保证升级不漂移。三、双运行时Native 与 Classic 如何分工 ⚖️0.4.0 提供两条相互独立、共享配置与 Dashboard 的工作流Native面向强模型。需求确认后Agent 自主决定如何规划、实现、测试和评审Comet 只负责状态检查、验收与可恢复归档Classic保留完整的 OpenSpec Superpowers 五阶段治理模型约束更强/comet入口只读取项目.comet/config.yaml确定性地转发到其中一条工作流绝不按任务大小猜。对于复杂需求Native 还支持Supervisor Change把一个目标拆成带依赖关系的子任务 DAG让多个 Agent 在 Runtime 创建的隔离 worktree 中并行实现与验证再按依赖顺序集成、做父任务最终验收。四、在浏览器里看见引擎统一 Dashboard 确定性引擎的另一个好处是可观测性。Comet Dashboard 用三栏布局把 Native 与 Classic 的进度、Git worktree、验收结果和归档状态放进同一个浏览器页面还能管理 Personal Memory 与 Project Knowledge当前处于哪个阶段、下一步该跑哪条命令、哪些证据缺失都直接来自引擎的状态与转移表而不是各页面自己拼。五、用数据验证确定性Eval 评测体系 Comet 0.4.0 用 Rubric Passk Pass^k 的科学评分验证引擎效果。16 个任务 × 3 组处理 × 5 样本的基线对比显示Pass5 全部饱和到 1.00但 Pass^55 次全部通过暴露了严格可靠性差距——Comet 0.4.0 在整体、业务、工作流三个维度全部为 1.00而 0.3.9 只有工作流一项达标更细的 Rubric 画像显示0.4.0 的优势集中在Recovery resilience恢复韧性 0.44和 Gate guard门禁守卫 0.17——正好对应本文讲的可恢复执行轨迹与确定性守卫两个设计点评测还支持接入 LangSmith把评估放进真实生产环境并可用双 Agent 架构自动执行六、延伸阅读想深入源码从哪里看 按依赖关系app → domains → platform分层推荐阅读顺序架构总览docs/architecture/ARCHITECTURE.md引擎执行循环与决策domains/engine/loop、resolver、guardrails、run-storeClassic 转移表与守卫domains/comet-classic/Native 运行时与 Supervisordomains/comet-native/Skill 包加载/校验/快照domains/skill/工作流契约与 Bundle 分发domains/workflow-contract/、domains/bundle/领域依赖边界含互斥规则config/repository-layout.json一句话总结Comet 0.4.0 的确定性不来自把 Prompt 写得更严而是来自纯 Node.js 运行时之上的一条事实链——状态分离、共享转移表、Guardrails 授权、可恢复轨迹以及不依赖 LLM 的确定性基准测试。这也是它能支撑 Skill 创作、分发与科学评测的底层原因。【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/comet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考