OpenSpec+Superpowers 选型实战：Trellis 的轻 vs Comet 的重，什么时候用哪个

后台有同学说介绍下Trellis和它们之间的区别，所以就有了这篇文章

我同时给同一个项目初始化了 Trellis 和 Comet。

跑完第一轮，我发现两套东西做的事情看起来差不多：都能帮你结构化地拆需求、写代码、验证、归档，都挂上了 OpenSpec 这套 Spec 生命周期，都号称能跨平台、能断点恢复。

但用着用着，差异开始暴露——而且暴露得非常彻底。

Trellis 的核心直觉是：Agent 变靠谱，前提是它看得见你的规范。 所以它的设计重心放在 Spec 管理、任务编排、每次会话自动注入相关上下文。

Comet 的核心直觉是：Agent 变靠谱，前提是你给它一个可被机器强制执行的流程。 所以它的设计重心放在状态机、Guard 脚本、阶段守护和审计日志。

两个项目站在同一个起点——OpenSpec + Superpowers 的融合——但往前迈出的方向完全相反。一个在强化「Agent 该知道什么」，一个在强化「Agent 该怎么做」。

这不是功能清单的对决，是两条工程哲学的对决。

第一层：规范怎么管——注入 vs 状态机

Trellis 的规范管理很直观。

团队把规范写进 .trellis/spec/，然后用 implement.jsonl 和 check.jsonl 把「实现时要看哪些 Spec」「验证时要对哪些 Spec」串起来。每次 /trellis:brainstorm 开始，系统自动按当前任务注入相关 Spec，Agent 不需要每次被提醒「我们团队的命名规则是什么」——它一上来就能看到。

四阶段循环也很清楚：

Plan → Implement → Verify → Finish

其中 Finish 阶段特别值得注意：trellis-update-spec 会把本轮新发现的规则「反哺」回 .trellis/spec/。这意味着规范是活的，每做完一个任务，团队的知识就沉淀一份。

相比之下，Comet 的规范管理走了一条完全不同的路。

Comet 的五个阶段是这样的：

Open → Design → Build → Verify → Archive

Open 和 Archive 归 OpenSpec 管，Design 和 Build 归 Superpowers 管，Verify 两头都用。光这个阶段划分就比 Trellis 多了一层「Deep Design」——在 Build 之前，强制先做设计文档和 delta spec。

但真正拉开差距的，是下面这件事。

真正的差异在于 Comet 用状态机代替了「注入」。你看这一段 .comet.yaml：

phase: build
auto_transition: true
build_mode: subagent-driven-development
build_pause: plan-ready
verify_result: pending
archived: false

Agent 在任何时刻都知道自己在哪个阶段、该做什么、不该做什么。状态推进不是靠 Agent「自己判断」，而是靠 comet-guard.mjs --apply 强制校验前置条件。你从 open 切到 build，Guard 会检查 proposal 和 tasks 是否已有；你从 build 切到 verify，Guard 会检查 verification_report 是否已存在。

这里隐含的分歧非常深：Trellis 相信「如果把规范喂给 Agent 看，它自然会遵守」；Comet 相信「Agent 会 drift，所以流程本身必须对 Agent 不可绕过」。

拿两个项目各自跑一遍，优缺点就会这样出来：

两派各有各的脆点。

注入派的好处是低摩擦，坏处是「Agent 不一定会看」。状态机派的好处是强制执行，坏处是多了大量认知开销——当你还在摸索阶段划分时，你的同事可能已经用 Trellis 跑了三个任务了。

第二层：记忆怎么存——journal vs 审计日志

第二层：记忆怎么存——journal vs 审计日志

Trellis 的记忆机制叫 journal。

它放在 .trellis/workspace/ 里，每次 /trellis:finish-work 归档任务时会同时更新。下次新会话开始时，Agent 会读到上次做了什么、到了什么状态、有哪些 open 的 context。

这个设计很工程直觉：像写工作日志一样，把上一次会话的脉络保留下来。

但它有一个隐含弱点：journal 的粒度由 Agent 控制。Agent 在归档时「自以为总结好了」，但实际上可能漏掉了关键上下文。而下一个 Agent 只能相信这个总结——它没法验证。

Comet 的做法要「硬」得多。

它的状态不是一段文本，而是一个确定性的 YAML 文件加上一个追加式审计日志：

.comet.yaml          → 当前工作流状态（phase、build_mode、verify_result…）
.comet/state-events.jsonl  → 每次状态转移的审计记录（来源、前后状态、字段变化）

Agent 断点恢复时不是读一段自然语言，而是直接解析 YAML 和 JSONL——comet-state.mjs 负责这件事，Agent 通过它获取状态，不需要猜。

还有一个细节：Comet 的 comet-handoff.mjs 在 Design → Build 交接时，不是把完整 Spec 全扔给 Build 阶段的 Agent，而是只传 Design Doc + SHA256 hash，配合「上下文压缩」能把输入 token 降低 25%–30%。这意味着 Build 阶段的 Agent 能看得更「干净」，而不是被大量已确认的 Spec 文本淹没。

两句总结：Trellis 的 journal 更适合个人开发者保持脉络，Comet 的状态文件更适合团队里多人多 Agent 接力。 journal 的好处是「像人写的」，坏处是「Agent 可能会漏」；state-events 的好处是「机器可读」，坏处是「万一状态写坏了，恢复要手动改 YAML」。

第三层：扩展性——多平台适配 vs Skill 平台

第三层：扩展性——多平台适配 vs Skill 平台

Trellis 支持 16 个平台，Comet 支持 33 个。数量上有差距，但这不是重点。

重点是两者的扩展性走了完全不同的范式。

Trellis 的扩展思路是「让同一套规范结构在不同平台都能注入」。它会对每个平台生成适配文件（类似于 .cursorrules、AGENTS.md 的增强版），但核心仍然是「Spec 管理 + 任务编排」这套骨架。拓展新平台的核心工作是写好注入层的适配器。

Comet 的扩展思路是「让 Skill 本身成为可创建、可评估、可分发的一等公民」。

这就是 Comet 0.4.0 引入的三件套：

• **/comet-any**：用自然语言描述你想创建的 Skill，系统自动扫描项目偏好、复用已有 Skill、生成组合方案，输出带 guardrails、eval manifest、reference 的可分发 Skill Bundle。
• **comet eval**：基于 Rubric 的结构化评分 + Pass@k / Pass^k 指标，用双 Agent 架构自动化在生产环境评估你的 Skill。支持本地 HTML 报告和 LangSmith 集成。
• Skill 分发：生成的 Skill 可以像 comet init 一样一键安装到所有平台。

这意味着什么？

Comet 不只是在帮你规范 AI 编码——它在帮你「写出像 Comet 一样好用的 Skill，然后用科学的方式验证这个 Skill 确实好用」。

举个例子。你团队有一套「PR 评审流程」，你想让所有平台的 AI 都按这套流程来。Trellis 的做法是：把这个流程写成 Spec，放进 .trellis/spec/，每次实施时会自动注入。Comet 的做法是：调用 /comet-any，描述你的评审流程，系统给你生成一个带入口 Skill、guardrails、checks 和 eval manifest 的 Skill Bundle，装完后任何平台都能用，并且你可以跑 comet eval 验证它跑得通。

这层差异在选型时可能被低估，但在团队规模变大后会被放大。

• 如果你的痛点是「Agent 不知道团队规范」，Trellis 的 Spec 注入是更轻量的解法。
• 如果你的痛点是「要让流程本身可被不同 Agent 按同一轨道执行」，Comet 的 Skill 平台是更长的坡道。

第四层：可靠性的底层实现

第四层：可靠性的底层实现

Trellis 的核心推进逻辑，本质上是靠 Skill prompt 引导 Agent 行为。阶段切换、上下文注入、任务编排都写在 Skill 文本里。Agent 读取 Skill → 按照描述执行 → 调用子代理（如 trellis-implement 和 trellis-check）——全程依赖的是 Agent 对文本指令的理解和遵守。

这没什么问题。大多数时候 Agent 理解得足够好。

Comet 在这件事上却做了完全不同的选择：把流程控制从 Skill 文本里抽出来，放进 TypeScript 脚本。

看看 Comet 的脚本矩阵：

这套脚本在干一件事：把原本容易散落在 Prompt 里的流程控制，沉淀成可测试、可复用的基础设施。

对比两个典型场景：

• Agent 说「我做完了」，但其实漏了验证报告。 Trellis 依赖 Agent 诚实——它的 finish 阶段会做 final check，但如果 Agent 在 check 里也偷懒，没有硬拦截。Comet 的 Guard 在 phase=verify 且 verify_result=pending 时直接禁止推进到 archive，verification_report 必须指向一个真实存在的文件。
• 长会话中 Agent 忘记自己在哪个阶段，开始做一些不该做的事。 Trellis 靠 journal 提醒。Comet 靠 comet-phase-guard.md 每轮注入阶段感知规则 + comet-hook-guard.mjs 直接拦截不该在特定阶段发生的文件写入。

工程上怎么落地

聊到这里，回到一个很朴素的问题：真实团队到底该选哪个？

选 Trellis 的场景

• 个人开发者或小团队（1-3 人）。学习成本低，装完就能跑，不需要理解状态机。
• 痛点是「Agent 不知道规范」，而不是「Agent 不遵守流程」。比如团队已有成熟的 Code Review 流程，只是希望 Agent 写代码时自动遵循命名规范、目录结构、API 设计约定。
• 技术栈需要 Python 环境。Trellis 要求 Python 3.9+ + Node.js 18+，而 Comet 只依赖 Node.js 20+。如果你的项目本来就是 Python 技术栈，Trellis 的环境要求不是额外负担。
• 希望规范「活的」。Trellis 的 trellis-update-spec 反哺机制让规范随着项目演进自动更新，这在快速迭代的早期项目中价值很大。

选 Comet 的场景

• 中型团队（3-10 人），多人多 Agent 协作。状态文件和审计日志让 Agent 交接不再是靠「猜上一个人做了什么」。
• 痛点是「流程不可控」。你不仅希望 Agent 知道规范，还希望它按轨道走：必须先设计、再实现、再验证、再归档，不能跳过。
• 需要可审计的长程工作流。如果你的项目是 0→1 的大功能、一次任务跨越多个会话和天数，Comet 的断点恢复和上下文压缩是刚需。
• 想把团队经验沉淀为可复用的 Skill。一旦用 /comet-any 创建了一个经过 comet eval 验证的 Skill Bundle，团队所有人、所有平台都能安装使用。
• 希望 Skill 演进有科学依据。Rubric + Pass@k + Pass^k 的评估体系帮你说清「这个 Skill 改之前 pass rate 是 4/5，改之后是 5/5」，而不是「感觉比以前好用了」。

可以一起用吗？

不是不可以。Trellis 管理 Spec 和任务，Comet 管理工作流和状态机。但两者的 Spec 目录结构（.trellis/spec/ vs openspec/changes/）、任务文件格式、阶段定义都不一样，同时启用意味着 Agent 要面对两套指令体系。

当前更实际的策略：先独立试用一个，吃透它的设计理念，再决定要不要补另一个的长处。 不要一上来就两个都装。

边界：两个方案目前都不完美

说清楚边界。

Trellis 的局限：

• 流程可靠性完全依赖 Agent 对 Skill 文本的理解。Agent 如果 hallucinate 或偷懒，没有硬拦截。
• journal 的总结质量不稳定，断点恢复的精确度受 Agent 归档质量影响。
• 目前没有 Eval 体系和数据分析能力——你看不到 Spec 的版本对 Agent 产出的量化影响。

Comet 的局限：

• 学习曲线陡峭。状态机、Guard、YAML 字段、审计日志——这些对「只想让 AI 帮我写代码」的用户是巨大的认知负担。
• 目前以 Claude Code 为主平台，虽然支持 33 个平台，但最能发挥的阶段守护（hook guard）只在支持 PreToolUse hook 的平台生效。
• 版本尚在 0.4.0-beta，状态文件的 schema 已有多次迁移（如 run-state 从 YAML 迁到 JSON），生产环境使用需要对迁移风险有心理准备。

回到开头那个场景。

我同时给项目装了两个——不是因为贪心，是因为我想看清它们到底在解决同一个问题的不同侧面。

Trellis 解决的是「Agent 不知道该知道什么」。它让你把工程规范写成 Spec，注入给每一次会话，让 Agent 不再是白纸一张。

Comet 解决的是「Agent 做事没有轨道」。它用状态机、Guard 脚本、审计日志，把 AI 编码从「对话流」变成了「可恢复、可审计的长程工作流」。

往小了看，这是两个工具的对比。

往大了看，这是 AI 编码从「辅助」走向「工程化」的两条分叉路：一条路选择让 agent 更聪明，另一条路选择让工程流程更坚硬。

两条路都对。但你要想清楚你们团队现在更需要哪一个。

参考资料

[Trellis 官方文档](https://docs.trytrellis.app/zh)
[Trellis GitHub](https://github.com/mindfold-ai/Trellis)
[Comet GitHub](https://github.com/rpamis/comet)
[OpenSpec 规范](https://github.com/Fission-AI/OpenSpec)