最近我同时接触了几套 agent workflow。

一套是我自己在做的 Zenith 组件迁移 workflow。这个 workflow 里面有很多 subagent，每个 agent 通常会调用一两个 skill 去完成自己的局部工作。另一套是比较出名的 Trellis。它的 coding workflow 明显更完整，除了 agent 和 skill，还有很多专业的脚本、插件、hooks、任务状态、上下文注入、检查和沉淀机制。

Trellis 很有启发，但我不敢直接把它那套 workflow 放进当前做 Zenith 组件迁移的项目里。不是因为它不好，而是因为它太完整了。一旦放进去，两套 workflow 的 agents、skills、hooks、commands、plugins 和运行产物很容易挤在一起，项目会变得非常乱。

最近和朋友聊天时，又想起一个词：优绩主义。

它听起来像是在讨论社会制度、教育筛选和精英叙事，但落到日常里，常常只是一些很小的瞬间：一句阴阳怪气的话，一个听说别人没拿奖学金后的眼神，或者看到同学多做成一点事后，心里冒出来的酸意。

比较本身不一定有问题。真正麻烦的是，比较会慢慢变成价值判断：别人做得好，就像更配；自己暂时没做到，就像低人一等。于是人与人之间很容易从互相参照，滑向互相审判。

如果你第一次打开这个仓库里的 .trellis/ 目录，很容易被里面的 workflow、tasks、spec、workspace、scripts 以及 .opencode/ 适配层弄晕。它们看起来像一组零散的脚本和文档，但真正理解以后你会发现：Trellis harness 是一套把“需求澄清、实现、检查、沉淀、收尾”串起来的轻量工作流系统。

这篇文章面向想研究本项目 Trellis harness 的开发者。目标不是列一份冷冰冰的文件清单，而是给你一条可执行的学习路线：先读什么、再看什么、哪些命令值得亲手跑一遍，以及如何建立一套稳定的心智模型。