Trellis v0.5.0 Beta 上线了。这是自 0.4.0 GA 以来最大的一次架构重写，核心变化用一句话概括：AI 编排从「你告诉它做什么」变成「它看到上下文自己知道该做什么」。
对于一直在用 Trellis 管理 AI 编码工作流的开发者来说，这个版本的升级幅度足够让你重新审视自己的工作流配置。
先说最重要的：Skill-first 架构
在 0.4.x 时代，Trellis 的工作方式是命令驱动的——你需要手动输入 /trellis:before-dev、/trellis:brainstorm 这类指令来触发特定的编排行为。这套模式能用，但本质上还是「人驱动 AI」。
v0.5.0 把这个逻辑翻转了。
除了 /start、/continue、/finish-work 这三个核心流程命令保留不变，其余所有 Trellis 命令都被重构为 auto-triggered skill。什么意思？AI 在工作过程中看到合适的上下文，会自动激活对应的 skill，不需要你手动敲命令。
具体转换的 5 个命令：
before-dev— 开发前的准备检查brainstorm— 方案头脑风暴break-loop— 跳出死循环check— 代码检查update-spec— 更新规格文档
打个比方：以前你得在每次写代码前手动喊一声「帮我检查下需求」，现在 AI 看到你打开了一个新 task，自己就知道该先跑 before-dev。看到你在同一个问题上反复修改三四次，自动触发 break-loop 帮你换个思路。
当然，如果你是那种喜欢掌控每一步节奏的开发者，skill 仍然支持手动唤起。这不是一个非此即彼的设计，而是把自动化作为默认选项，手动控制作为可选项。
这个设计哲学的转变值得多说两句。当前 AI 编码工具的主流思路还是「人发指令，AI 执行」，Trellis 试图往前走一步——让 AI 具备上下文感知能力后自主决策该在什么时机做什么事。这跟 Cursor 的 Agent 模式、Copilot 的 multi-file edit 是同一个方向，但 Trellis 做的是更上层的编排，不是单点的代码生成。
文件结构的迁移
架构变了，文件组织方式自然也跟着变。每个平台下，原来放在 commands/<name>.md 的文件迁移到了 skills/trellis-<name>/SKILL.md。
升级时有 65 条 rename migration 会自动处理。如果你本地改过某些文件（很多重度用户都会自定义 prompt 模板），迁移脚本会在 confirm prompt 里让你逐个选择是保留自定义还是用新模板覆盖。
同时，所有平台的命令和 skill 模板合并到了单一源：
packages/cli/src/templates/common/
├── commands/ (3 个核心命令)
└── skills/ (5 个 auto-triggered skill)
这解决了一个老问题——以前 Trellis 支持多个平台，每个平台各维护一套模板，经常出现「A 平台更新了 B 平台没跟上」的漂移。现在单一源 + 跨平台输出 adapter，一次更新全平台同步。
对维护者来说这是个大减负，对用户来说意味着不管你用哪个平台，体验一致性有了保障。
7 个平台升级到 Agent-capable
这是 v0.5.0 的另一个重头戏。以下 7 个平台从「仅命令」升级到完整的 agent-capable：
- Qoder
- CodeBuddy
- Factory Droid
- Cursor
- Gemini CLI
- Kiro
- GitHub Copilot
「Agent-capable」具体意味着什么？两件事：
第一，Sub-agent 定义。每个平台现在可以生成三种 sub-agent：
implement— 负责具体的代码实现check— 负责代码审查和验证research— 负责调研和信息收集
这些 sub-agent 按各平台的原生格式生成。比如在 Cursor 里就是 Cursor 能识别的 agent 配置，在 Copilot 里就是 Copilot 的格式。你不需要关心底层差异，Trellis 帮你抹平。
第二，Hook 系统。基于 shared-hooks/ 目录下的 Python 脚本实现，包含三个核心 hook：
session-start— 会话启动时的初始化inject-subagent-context— 向 sub-agent 注入上下文statusline— 状态栏信息更新
单一实现 + 跨平台输出 adapter 的模式，跟模板合并是同一个思路。
值得注意的是，社区反馈里已经有人确认 Codex 的 sub-agent 也已经支持了。这意味着 Trellis 在 agent 编排层面的覆盖面正在快速扩大。
这东西到底解决什么问题？
退一步看，Trellis 在做的事情是 AI 编码工具的「编排层」。
现在市面上的 AI 编码工具——Cursor、Copilot、Kiro、Gemini CLI——每个都有自己的 agent 能力，但它们之间是割裂的。你在 Cursor 里配好的工作流，换到 Copilot 就得重来。你在一个项目里摸索出的最佳实践，换个项目又得重新配置。
Trellis 试图做的是：在这些工具之上提供一个统一的编排层，让你的工作流定义一次、到处运行。v0.5.0 的 Skill-first + Sub-agent 组合，本质上是让这个编排层从「被动响应」进化到「主动协作」。
这个定位有点像 Terraform 之于云平台——你不直接操作底层，而是通过一个抽象层来管理。区别在于 Trellis 管理的不是基础设施，而是 AI 编码的工作流。
升级注意事项
安装或升级：
# 全新安装
npm install -g @mindfoldhq/trellis@beta
# 从 0.4.x 升级（--migrate 必须加）
trellis update --migrate
--migrate 这次是强制的，不加会报错。原因很简单——文件结构变了，不迁移的话旧配置跑不起来。
几个升级时可能遇到的情况：
- 如果你自定义过 commands 目录下的模板文件，迁移脚本会逐个询问你的处理方式
- 65 条 rename migration 会自动执行，大部分情况下无需手动干预
- 迁移完成后建议跑一遍
trellis check确认配置完整性
另外社区里有人提到文档还没完全更新到 v0.5.0 的内容，这在 beta 阶段可以理解，但确实需要团队尽快跟上。对于习惯看文档上手的开发者来说，目前可能需要结合 changelog 和社区讨论来摸索新特性。
一些判断
说说我的看法。
Skill-first 的方向是对的。AI 编码工具的演进趋势就是从「工具」变成「协作者」，而协作者不应该每次都等你发号施令。让 AI 根据上下文自主决策该做什么，这是正确的产品直觉。
但 beta 阶段的风险也很明显：auto-trigger 的准确率如何？会不会出现「AI 觉得该 brainstorm 但你其实只是在随便改个 typo」的误触发？这类问题只有大量用户实际使用后才能暴露出来。
Sub-agent 的支持是另一个亮点。当前 AI 编码的一个痛点是单 agent 的能力天花板——一个 agent 又要写代码又要审查又要调研，context window 很快就不够用。拆成多个专职 sub-agent 协作，理论上能突破这个限制。Trellis 在编排层做这件事，比每个平台各自实现要高效得多。
7 个平台的覆盖也说明 Trellis 团队的策略很清晰：不跟任何一个 AI 编码工具绑定，而是做它们之上的抽象层。这个定位在当前 AI 编码工具百花齐放的阶段是有价值的——没人知道最终哪个工具会胜出，但编排层可以对冲这个不确定性。
社区里有人问会不会封装成 Cursor Composer 的 plugin，这个需求很合理。如果 Trellis 能以 plugin 形式嵌入各平台而不是作为独立 CLI 存在，使用门槛会低很多。但这也意味着要跟各平台的 plugin 生态深度集成，工程量不小。
跟同类工具的对比
目前做 AI 编码编排的工具不多，能拿来对比的主要是：
- Aider — 专注于 Git 集成的 AI 编码助手，但不做跨平台编排
- Claude Code 的
/project系统 — 项目级的上下文管理，但绑定 Claude 生态 - Cursor Rules — 平台内的规则系统，但只在 Cursor 内生效
Trellis 的差异化在于「跨平台 + 编排层」的组合。如果你只用一个 AI 编码工具，Trellis 的价值有限；但如果你在多个工具间切换，或者团队里不同人用不同工具，Trellis 的统一编排就很有意义了。
总结
Trellis v0.5.0 Beta 是一次有野心的架构重写。Skill-first 让编排从被动变主动，Sub-agent 让单一 agent 的能力天花板被打破，7 平台覆盖让跨工具协作成为可能。
作为 beta 版本，粗糙的地方肯定有——文档滞后、auto-trigger 的边界 case、迁移过程中的兼容性问题。但方向是清晰的，架构是干净的。
如果你正在用多个 AI 编码工具，或者对 AI 编码的工作流自动化有追求，值得现在就上手试试。毕竟 beta 阶段的反馈，对产品走向的影响力是最大的。
参考来源
- Trellis v0.5.0 Beta 版本发布讨论 — Linux.do 社区原帖，包含完整的更新说明和社区反馈