[LINUX DO 精选] Lattice：血缘链路与本地 Ticket 驱动的 Agent 工作流

Lattice 试图解决团队使用编码 Agent 时最容易断裂的一环：需求、架构决策、任务、代码和评审结果分别存在，却无法快速回答“这次改动为什么做、来自哪项需求、满足了哪些验收条件”。它用本地 Ticket 和 Lineage 把这些节点连起来，同时把流程控制得足够薄。

Lineage 解决的是什么

这里的 Lineage 可以理解为软件交付的血缘链路：一个 Spec 拆成哪些 Tickets，Ticket 落入哪个 PR，PR 对齐哪条验收标准或 ADR，Review 又留下了什么结论。节点之间有明确引用后，后来接手的人或 Agent 可以沿链路回查，而不必依赖聊天记录或模糊记忆。

原作者希望给模型一套“既有迹可循、又不被捆住手脚”的纪律底座。它固定必要的交付节点，但没有把架构和代码实现写成大量僵硬规则。

五步交付链

Lattice 的核心由几个可移植 Skills 组成，典型顺序是：

/create-spec 或 /create-review
        ↓
  /create-tickets
        ↓
   /start-work
        ↓
   /create-pr
        ↓
  /finish-work

这条链可以这样理解：先创建需求说明，或从一次 Review 结论开始；再拆成可执行 Tickets；选择一张 Ticket 开始开发；完成后创建 PR；最后收尾并把实现、验收和评审状态回写到链路中。

它的价值不在命令数量，而在每一步都产生可定位的结构化依据。团队检查结果时，看的不只是 Agent 的总结，还能回到 Spec、Ticket、PR、ADR 和验收记录本身。

为什么优先使用本地检索

Lattice 将大部分长期上下文保存在本地，包括验收标准、Review 结论以及 Spec、Ticket、PR 之间的对应关系。这些内容可以通过 cat、grep 等本地工具快速查询，并随 Git 历史一起审查。

只有远端才掌握的实时事实，例如 Issue 或 PR 当前状态、最新评论和 CI 结果，才通过 gh API 联网读取。这样把“稳定的项目知识”和“会变化的远端状态”分开：本地内容便于追踪和复现，联网查询负责补足最新事实。

在现有项目中怎样落地

第一步是确定节点格式和唯一标识：Spec、ADR、Ticket 与 PR 分别放在哪里、如何命名、怎样互相引用。第二步是在开始编码前强制建立来源关系，让每张 Ticket 能回到需求或 Review。第三步是在 PR 中列出关联 Ticket、验收条件和关键决策。第四步把 CI 结果、人工 Review 结论和未解决事项写回交付记录。

采用时可以先选一个小型需求试运行，检查四件事：能否从 PR 回到 Ticket；能否从 Ticket 找到 Spec 或 ADR；验收标准是否有实际测试结果；远端状态是否标注了查询时间。链路断裂时优先修正文档引用，而不是让 Agent 猜测缺失关系。

适用范围与局限

它适合已经使用 Spec、Issue、PR 或 ADR，却经常发生上下文丢失的团队，也适合希望 Agent 工作可审查、但不想引入重量级编排平台的项目。对于只有一两个文件、无需协作和审计的一次性脚本，这套链路可能反而增加维护成本。

原帖给出了理念、命令链和本地优先查询方式，但没有展开完整安装步骤、文件 Schema、迁移方法和故障回退流程。这些细节应以项目仓库 README 的当前版本为准，不能仅凭帖子补全。仓库地址为 GitHub - percena/lattice · GitHub 。

原作者：M1n9X
原帖：https://linux.do/t/topic/2691361