今天下午，我在 Routa 的看板里点开一张已经进 Done 的卡：[Sub-issue] 为 GATE-first 专家提示注入单次 trace 状态摘要。

它表面上已经结束了。状态是 Done，完成汇报员的 session 是 COMPLETED，评审表格里的 AC、测试、类型检查、工作树、提交也都已经打勾。按一般项目管理工具的语义，这件事应该已经收工。

但这张卡没有用同一种意义结束。

同一页里，Evidence Bundle 还挂着“证据未齐”；顶部还有一条红色提示：embedded ACP process 的 ownership lease 已经过期，不能在另一个实例上恢复。再往前翻，上一轮 Review 也并没有直接放行，系统明确拦下了 worktree 不干净、变更未提交，以及 PR-ready branch 尚未确认。

任务完成了，证据没有同时完成；交付状态结束了，会话边界没有同时消失。

Gate First 就是从这种分叉里长出来的。 一支 Agent Team 真正难的，从来不是把任务“做完”，而是把“完成”拆开：任务完成，证据完备，会话可恢复，交付可归档，这几件事在单人开发里经常被默认等价；一旦你开始认真运行多 Agent 流程，它们就会迅速分叉。

一张卡，先被系统拆成几种“完成”

这张卡最值得看的地方，不是它最后 Done 了，而是系统一路都在明确区分：什么叫故事准备好了，什么叫实现完成了，什么叫证据够了，什么又只是流程状态推进了。

在 Todo 阶段，系统先做的不是“催开发”，而是先复核故事合同。截图里写得很清楚：canonical YAML 通过，关键 INVEST gate 通过，artifact gate 为空，Dev 可执行说明被写回卡片，然后卡片才被推进到 dev。这里的 Todo 不是一个等待实现的缓冲区，它更像一个编排入口：先确认这张卡能不能被下一位 Agent 无损接手，再允许它进入实现。

Gate First 的第一层含义就在这里。流程还没推进，就先确认：下一位 Agent 接手时，到底能不能继续推进，而不是先补课。

很多团队做 Agent 编排时，会把 Spec 当输入，把 Gate 当输出，中间默认交给模型自己补全。demo 阶段这条路很好看，真实交付里却很容易反复返工。返工次数主要取决于一件事：任务在进入下一阶段前，有没有先被系统清洗成一份可执行合同。

返工不是例外，返工为什么发生才该被留下来

这张卡一共跑了 8 次 runs。 从链路上看，它几乎是一条完整的微型交付流水线：Backlog 梳理、Todo 编排、开发执行、评审守卫、再次开发、再次评审，最后再由完成汇报员收口。

这条链路最有价值的地方，在于系统没有把前面的失败抹掉。

第一次 Review 并没有直接放行。评审守卫当场给出阻塞理由：Worktree 不干净，变更未提交。也就是说，代码实现和测试结果已经部分成立，但交付门禁仍然不允许它进入 Done。随后才有后续的开发修补、再次评审，以及最后那张带着 commit hash、clean worktree 和测试通过记录的完成表。

多 Agent 协作里，系统最该留下来的是上一轮被拦住的原因，不是最后一轮的漂亮输出。

这和很多 Agent Team 的默认做法正好相反。很多系统只保留最后一轮漂亮的输出，把失败的尝试、缺失的验证、重复触碰的文件、被 Gate 打回的原因全部冲掉。这样看起来很顺，实际上只是不断用新的上下文覆盖旧的问题。

返工不是异常，它是默认输入。问题在于返工发生之后，系统有没有把原因记账，并让下一轮少踩一次同样的坑。

证据不是附件仓库，而是可继续消费的状态

这张卡还有一个很成熟的建模细节：它明明已经在 Done，系统里也已经挂了 7 个 artifacts，仍然没有把它自动认定成“证据完备”。

左侧证据摘要页写得很直白：必需 artifact 无，但“验证缺失”“缺少完成总结”。也就是说，截图、测试结果、代码差异这些材料都已经上传了，系统仍然拒绝直接把它们视为一个完整的 Evidence Bundle。

这不是 UI 矛盾，而是非常重要的系统选择。

Agent 最擅长生产材料，系统必须学会拒绝把材料误认成结论。

你可以很容易让一支 Agent Team 生成很多东西：命令输出、截图、日志、diff、临时说明。但对下一位角色真正有用的，是这些材料有没有被压成一个结构化结论——材料堆多高不重要。否则 Gate 还得重新解释，Done 还不能归档，下一轮也无法直接复用。

所以”7 个 artifacts”和”证据未齐”才会同时成立。前者说明验证动作发生过，后者说明系统仍然在等一份可消费的结论。

完成汇报员的意义，正在这里。它不是再写一份好看的摘要，而是把零散材料压成一张能继续被系统读取的交付记录：AC 是否满足，测试是否通过，工作树是否干净，提交是什么，最终交付物是什么。到这一步，证据才开始从“附件”变成“状态”。

Gate First 的关键变化，不是多一道卡，而是让 Gate 先看到运行状态

这张卡做的事情，本身就很能说明 Gate First 到底在变什么。

它交付的并不是一个面向终端用户的功能，而是把单次运行里的 trace 信号整理成确定性的 digest，然后在 specialist prompt 构造阶段，按角色注入不同的上下文。新增的 src/core/trace/run-digest.ts 做的是同一件核心工作：从 trace 里稳定地产生一份 TraceRunDigest，把 tool_call / tool_result 配对起来，汇总成功工具、失败工具、缺失结果、观察到的验证命令、触达文件、热点、重试与重复失败信号、tool-call context path、VCS 证据缺口。

然后，系统没有把这份 digest 当成第二份任务说明，而是按角色切分：

• 给 GATE 的，是更接近审计视角的 Trace State：它关心证据覆盖、失败/缺失结果、验证命令、触达文件、上下文路径、VCS 和证据缺口。
• 给 CRAFTER 的，是更轻量的 Trace Preflight：它只需要知道哪些文件已经碰过，最近失败过什么命令，哪里反复失败，哪里是高风险热点。

这一步很关键。 它把 Gate 从“事后读材料的人”，变成“拿着运行状态进入审查的人”；也把 Crafter 从“每次都得重新试一遍的人”，变成“开工前就收到风险提示的人”。

而且这套设计最成熟的地方，在于它同时限制了自己。 风险备注里专门强调，摘要不能长成第二份任务 spec；没有 tool_result 的 running call 不能被误判成失败；只有 trace 里结构化可读出的命令，才能算 observed verification commands；如果没有可读 trace、或者没有验证命令证据，系统要明确报 gap，但不能因此中断委派。

Gate First 真正在做的是：先让系统把可验证状态组织出来，再决定下一位 Agent 该看到什么、能推进什么。

Harness 防的不只是内容质量，还有运行时边界

顶部那条红色的 lease expired 提示，也很重要。

很多人第一眼会把它看成“失败”。但它真正暴露的是另一层更底的防御：运行时所有权。系统明确告诉你，这个 embedded ACP process 的 ownership lease 已经过期，不能在另一个实例上恢复。换句话说，卡片可以 Done，交付可以归档，但这不等于绑定的进程上下文还可以被任意接管。

这是 Harness 很容易被忽略的一层。 如果你只把 Harness 理解成流程规则、审查规则、artifact 规则，很容易漏掉运行时边界。可一旦 Agent Team 开始跨实例、跨 worktree、跨 provider 运行，真正保护系统不失控的，往往不是更聪明的 prompt，而是这些看起来不那么性感的约束：谁拥有这个 session，谁可以恢复，什么时候系统必须明确拒绝恢复。

Done 只表示交付状态结束，不表示运行时边界自动消失。

这条红色提示之所以重要，正因为它把“交付完成”和“进程可恢复”拆开了。系统宁可让界面看起来复杂一点，也不愿把一次本不该发生的跨实例恢复偷偷做成黑箱。

真正的壁垒，会从模型能力转向 Harness 设计

模型、工具协议、prompt 和 skill 都重要。但当多个 Agent 被放进同一条交付链里，问题会很快从能力问题变成系统问题。你需要的是一套 Harness：任务合同、返工账本、证据模型、运行时边界，缺一个，就会在某一环反复失速。

Gate First 是工程原则，不是角色偏好。先组织可验证状态，再组织协作。

当大家都能调到不错的模型、都能接上 MCP、都能让 Agent 写代码之后，真正的差距会落在另一件事上：你的系统能不能让一支 Agent Team 在返工、证据、审查和运行边界里持续工作，而不是每一轮都从头相信一次”这次应该没问题”。