近期有用户在后台询问，Trellis 和 Comet 之间究竟存在哪些区别，因此本文专门围绕这一话题展开详细说明。

我同时使用这两个项目，为同一个项目完成了初始化。跑完第一轮后，你可能会觉得它们完成的工作看起来相似：都能帮你结构化地拆解需求、编写代码、开展验证、执行归档，都采用了 OpenSpec 这套生命周期，都声称支持跨平台与断点恢复功能。

然而，随着使用深入，差异开始显现——而且非常明显。

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 的规范管理走了一条完全不同的路径。它的五个阶段如下：

Open → Design → Build → Verify → Archive

Open 和 Archive 阶段由 OpenSpec 管理，Design 和 Build 阶段由 Superpowers 管理，Verify 阶段则两边都参与。仅从阶段划分来看，Comet 就比 Trellis 多了一层「深度设计」——在 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 会偏离轨道，因此流程本身必须对 Agent 不可绕过」。

分别用两个项目跑一遍后，优缺点就会这样呈现出来：

两派各有各的脆弱点。注入派的优势是低摩擦，弱点在于「Agent 不一定去看」。状态机派的优势是强制执行，缺点则是增加了大量认知开销——当你还在摸索阶段划分时，你的同事可能已经用 Trellis 跑完了三个任务。

第二层：记忆如何存储——journal 与审计日志

Trellis 的记忆机制称为 journal，存放在 .trellis/workspace/ 目录下。每次执行 /trellis:finish-work 归档任务时，journal 会同步更新。下次新会话启动时，Agent 能读取上次做了什么、当前处于什么状态、还有哪些未完成的 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」。

第三层：扩展性——多平台适配与 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 脚本。

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

对比两个典型场景：

• Agent 说「我做完了」，但实际上漏了验证报告。 Trellis 依赖 Agent 诚实——它的 finish 阶段会做最终检查，但如果 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 产生幻觉或偷懒，没有硬性拦截。
• 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 更聪明，另一条路选择让工程流程更坚硬。

两条路都正确。但你需要想清楚，你们团队目前更需要哪一条。