周末，我使用 Claude Code 的 /workflows 做了两个实验，结合我使用 Codex /goal 做的一系列实验，把两个能力放在一起看， 感觉比单独看任何一个工具都更清楚。

我用 /goal 一次跑了了一个接近 30 小时的 timetravel-agent：一个模仿 Wallaby.js 思路的 JavaScript time travel debugger 原型。它已经有插桩、运行时记录、trace 查询、replay、HTTP 服务和 React/Next demo。另一个是 Claude Code 的 dynamic workflows：把并行 subagents 的编排逻辑写进 JavaScript 脚本，再由本地 runtime 调度执行。

它们看起来是两类不同的问题。timetravel-agent 是一个长时间目标，Claude Code workflows 是一个多 Agent 并行机制。但放在一起看，它们其实指向同一个工程麻烦：

Agent 可以工作很久，也可以一起工作很多，但工程系统要能判断它什么时候真的可以停。

Bun 的 Zig 到 Rust 迁移说明，已经让我们看到 Agent 可以参与系统级的大规模重写；Claude Code 的 dynamic workflows 把编排逻辑放进 JavaScript 脚本里，让多个 subagents 并行工作；/goal 则让一个任务可以围绕完成条件持续推进，越过单轮对话的边界。

AI Coding 开始进入长任务阶段。新的问题不是 Agent 能不能继续做，而是它继续做之后，系统有没有能力收敛。

/goal：长任务不能只靠持续接班

我之前用 /goal 做过一个实验：让 Agent 模仿 Wallaby.js，实现一个 JavaScript 的 time travel debugger。这个任务天然适合长时间运行：它要做插桩、轨迹记录、状态回放、调试 UI 和测试验证。

但结果没有成功收敛。

问题不在 /goal 本身。/goal 的价值是让 Agent 围绕一个目标持续推进，并在每轮结束后判断是否满足完成条件。但它更像接班机制，不是验证系统。 它能把任务继续交给下一轮，却不能替工程系统证明：执行轨迹是否完整、 变量状态是否可回放、分支和异常是否覆盖、step forward / backward 是否真的改变快照。

所以，当目标只是“实现一个 time travel debugger”时，Agent 很容易生成一个看起来像完成了的项目：有结构，有 UI，有 README，有浅层测试。问题是，time travel debugger 的完成条件不在这些外观上，而在 trace、replay、状态恢复和语义一致性上。

我后来重新打开 timetravel-agent 的 demo，反而更能看清这个问题。UI 已经能展示 compiled artifact、source 到 instrumented output 的映射、probe 数量、source map 和 integrity 状态。这些都是很好的证据入口，但它们还不是完整的完成证明。

这也是我们之前在 Routa Kanban 里讨论 Gate 的原因。长任务不能只有 Start 到 Done 的线性链路，而应该在关键状态之间设置 Gate：

Goal -> Plan -> Build -> Verify -> Review -> Done

对 timetravel-agent 来说，Gate 可以拆得更具体：Trace Gate 检查事件是否完整，Replay Gate 检查状态是否能恢复，UI Gate 检查调试面板是否真的能驱动问题定位，Mismatch Gate 检查生成代码和源代码之间的语义差异，Evidence Gate 则要求最终留下可复查的命令、报告和截图。

这样，/goal 不只是让 Agent 一直跑，而是让任务在 Gate 之间持续流动。/goal 解决接班问题，Gate 解决收敛问题。

/workflows：多 Agent 并行之后，关键在结果归约

如果 /goal 暴露的是长任务的纵向收敛问题，那么 dynamic workflows 暴露的是并行任务的横向归约问题。

Claude Code 的 dynamic workflows 很有意思。它把长上下文硬撑这件事，转成了一个 JavaScript 编排脚本，由 runtime 在后台执行，调度多个 subagents。workflow 把 plan 放进 code，脚本保存循环、分支和中间结果，Claude 的上下文只接收最终结果。它可以用于 codebase-wide bug sweep、500-file migration、cross-checked research 这类任务。

这个变化很重要。

任务状态从聊天窗口里移出来，进入脚本变量、阶段输出和 agent 结果。多个 subagents 可以并行搜索、审计、迁移、验证，最后由 workflow 合成结果。这很像 Agent 时代的 MapReduce：先切任务空间，再 fan-out 给 worker，再收集发现，再交叉验证，最后 reduce 成补丁、报告或结论。

这里最贵的部分落在 reduce。

我之前看过一次 /deep-research workflow 的运行数据。以 Node.js Permission Model 的研究为例，总 token 约 3.31M，其中 Verify 阶段约 1.76M，占比超过一半。这个比例很有意思。成本最高的部分不在 Search 和 Synthesize，而在 Verify。

workflow 如果只是并行搜索和摘要，其实不会带来足够可信的结果。几十个 subagents 一起跑，只是扩大覆盖面；如果没有交叉验证，也可能只是扩大错误面。只有当 claim 被抽取、证据被追溯、冲突被合并、失败被标记时，workflow 才开始具备工程价值。

未来 Coding Agent 的竞争，会落到一个更具体的问题上：能不能把 worker 的结果归约成可信证据。

并行只能扩大覆盖面。可信度来自验证关系。

长程验证：把“继续做”变成“持续证明”

把 timetravel-agent 和 Claude Code workflows 放在一起看，长任务的失败模式会变得很清楚。

纵向看，任务会漂移。一开始我们说的是“实现一个 time travel debugger”。跑着跑着，目标可能变成“搭一个 UI”；再跑一会儿，又变成“让 demo 页面能打开”；最后 README 写好了，截图也有了，项目看起来像个产品，但执行轨迹、状态回放、语义一致性并没有被证明。

横向看，错误会扩散。workflow 让几十个 subagents 同时工作，覆盖面迅速变大，但如果没有 claim 抽取、证据投票、冲突处理和最终归约，那么并行只是把不确定性放大了。它看起来很热闹，结果却未必更可靠。

长任务里最危险的地方在这里：Agent 没有失败，它只是把原始目标换成了当前最容易完成的目标；workflow 也没有失败，它只是把很多局部结果合成了一份看起来完整的答案。

所以，long-running task 的工程重点，不在于让 Agent 更努力，或者多跑几个 session。任务每推进一段，都要能被验证。执行只是过程，收敛才是结果。没有验证点，长任务很容易变成长时间生成；有了验证点，它才开始像一个工程系统。

我后来把这个问题叫做“长程验证”。

长程验证不该被放到任务结束后，当作一份测试报告补上去。它应该出现在任务开始前、执行中、进入 Done 之前。它至少包含四件事：

1. 任务开始前，要有可检查的 done-condition，而不是一句愿望式目标。
2. 执行过程中，要有 checkpoint，能说明当前状态为什么可以进入下一阶段。
3. 多 Agent 并行之后，要有 reduce 机制，把结果归约成证据，而不是直接归约成总结。
4. 进入 Done 之前，要留下 evidence bundle：命令、报告、截图、失败记录和未解风险。

这些东西听起来很笨，也不如“让 Agent 自己探索”那么迷人。但工程系统大多数时候就是靠这些笨东西站住的。

结语：让“完成了”留下证据

长任务接下来要补的是更稳定的验证结构。运行时间继续变长，只会把这个缺口放大。

/goal 让 Agent 不必一次做完，dynamic workflows 让 Agent 不必一个人做完。它们能不能进入工程交付，还要看另一组问题：目标是否有 done-condition，过程是否有 checkpoint，阶段之间是否有门禁，产物是否有凭证，失败是否能沉淀成下一次评估。

AI Coding 接下来要比拼的，可能是另一种能力：把“完成了”变成一组可以被证明的工程事实。

门禁很小，但它可能是 Agent Runtime 里最关键的单元。