Routa 桌面版发布：内建 Harness 工程的 AI Coding 研发协作工作台

当 Coding Agent 的 CLI 模式开始显著改写整个行业时，我们逐渐意识到：这场变化真正重要的，并不只是把 Coding Agent 搬进命令行。随着对多 Agent 协同的持续探索与实践，越来越确认一件事——单个 Coding Agent 已经不再是最关键的问题，真正重要的，是如何让多个 Agent 在同一套工程体系里协同工作。

概述

在人工看守的本地模式和远程 Agent 自动化模式下，「完成」的定义明显不一样：在基于 Spec 的模式里，DoD（Definition of Done）定义的是开发完成，也就是验收标准已经满足；在基于 Kanban 的模式里，DoD 定义的是交付完成，也就是这张卡片已经具备进入 done 列的条件。简单来说，Spec 模式里的 done，只是 Kanban 里的开发完成。从开发完成到交付完成，中间还隔着验证、门禁、证据和状态流转。

Kanban 作为任务协议

一旦 DoD 从「开发完成」变成「交付完成」，Kanban 就不再是看进度的工具，而是变成一套任务级的协议。卡片往哪一列走，不是位置变化，而是状态切换；状态一变，输入、输出、验证方式以及后续动作都会被重新定义。Backlog、Todo、Dev、Review、Done、Blocked 这些列，不只是流程节点，而是不同阶段的工程语义，也是 specialist 接力协作的边界。每个下游阶段先验证上游有没有交出它该交的东西，不合格就退回去。

泳道专家体系：多 Agent 协作的接力设计

多 Agent 最容易被误解成一个并行问题——好像只要同时开更多 Agent，系统自然就会更强。可工程现实往往正好相反。Agent 越多，如果职责边界不清、阶段责任不明、交接关系含糊，系统只会更快地产生噪音。在这套设计里，真正参与交接的是 Kanban workflow 里的各个 Lane specialist：Backlog Refiner 负责把粗糙卡片压成可执行 story；Todo Orchestrator 负责校验并补齐执行计划；Dev Crafter 负责实现与补齐开发证据；Review Guard 作为最终质量门禁进行独立验证；Done Reporter 负责补充完成总结。

重新定义完成：系统何时放行，何时拒绝

对于一个会持续被 AI Agent 改写的代码库来说，「完成」通常要意味着两件事：技术 done——交付的代码已经通过了所有质量门禁，可以被合并到主干；业务 done——交付的代码已经包含了所有验收标准，可以被发布到生产环境。团队需要提前想清楚：哪些模块边界不能被打穿，哪些验证在进入主干之前必须完成，哪些回归风险需要在合并之前被识别出来，如何通过渐进式披露能让 Agent 持续读懂、定位和修改代码。

如有侵权，请联系删除。