摘要：当 Agent 开始结队工作时，真正的挑战就不再是“它们能不能写代码”，而是“我们能不能管理它们”。Routa Kanban 的意义，不在于把传统看板套上一层 AI 外壳，而在于把任务流、执行上下文、运行历史、验证证据和队列压力，收敛成一个可观察、可调整、可约束的 control plane。而要让这样的界面真正成立，关键不在 UI，而在它背后的 Harness Engineering。

导语：前两篇文章里，我分别讨论了 Routa 作为开放多 Agent 编排平面的设计，以及 Agent Team 在约束下的构建方式。到了 Routa Kanban 这里，问题已经从“如何组织 Agent”继续往前推进了一步，变成了“如何管理 Agent Team”。这篇文章想讨论的，不只是一个看板页面，而是一种新的工程判断：在 AI4SE 时代，如果我们希望多 Agent 协作真正进入日常软件交付，就必须同时建设管理界面与工程护栏，而不是只建设聊天能力。

在不少 AI Agent 产品里，协作仍然主要以会话的形式存在。我们看到的是聊天窗口、Prompt 历史、Session 列表，以及一些零散的日志输出。这种形态当然能工作，在演示里甚至常常显得很聪明，但它很难运营。你看不清系统当前有多少任务正在运行，看不清哪些任务因为资源受限而排队，看不清某张卡到底绑定了哪个仓库和哪次运行，也看不清失败发生在规划、实现还是验证阶段。对于真正的软件交付来说，这样的系统仍然过于“会话化”，而不够“工程化”。

这也是我开始认真思考 Routa Kanban 的原因。在我看来，它并不是把一个传统任务看板加上一层 AI 皮肤，而是尝试把多 Agent 协作从“消息驱动”推进到“流动驱动”，再进一步推进到“管理驱动”。一旦把问题放在这个尺度上，Kanban 的意义就变了。它不再只是展示任务状态的界面，而开始接近 Agent Team 的 control plane。

看板为什么在 AI 时代重新变得重要

传统敏捷实践中，看板的价值首先在于可视化工作流。Backlog、Doing、Done 这些列帮助团队理解任务如何流动、阻塞出现在哪里、在制品是否过多。但在 Agent Team 的语境里，这种理解已经不够了。因为当执行主体从人扩展为 Agent 之后，一张卡不再只是“有人要处理的工作项”，一列也不再只是“任务当前所在的位置”。它们开始承载更重的运行时语义。

在 Routa Kanban 的现有实现里，一张卡片已经逐渐接近一个可运行的工作单元。它不仅有标题和目标，还绑定了 board、column、provider、role、specialist、codebase、session、worktree 与验证状态。列本身也不再只是视觉分组，而是在演化为一个带策略的 stage。进入某一列，意味着谁应该接手；停留在这一列，意味着任务应当运行在什么上下文里；离开这一列，则意味着是否已经满足某种验证条件。

从这个角度看，Routa Kanban 的价值，不是“把 Jira 做成 AI 版”，而是把多 Agent 协作里原本散落在 Prompt、约定和日志中的隐性约束，逐步显性化。它把“谁来做”“在什么地方做”“做完以后如何证明”这些事情，从聊天上下文里拉回到一个可以被持续观察和调整的管理界面里。对于一个真正想进入团队日常工作的 AI 系统来说，这个变化比单纯提升交互体验要重要得多。

管理界面真正要管理的，是运行时事实

一个多 Agent 系统最容易制造的幻觉，就是让人误以为只要消息足够多、对话足够长，协作就已经发生了。事实恰恰相反。真正决定系统是否可管理的，从来不是消息本身，而是运行时事实。

首先是队列与并发。一旦 Agent 不再串行处理工作，而开始并发接手多张卡片，系统就立刻进入了新的复杂度层级。此时，最关键的信息不是某个 Agent 刚刚说了什么，而是哪几张卡正在运行，哪几张卡还在等待，当前并发上限是多少，哪些工作因为资源压力被延后。这也是为什么我认为 Routa Kanban 里对 running、queued 与 session concurrency limit 的呈现非常关键。它让看板第一次开始承担“系统压力可视化”的职责，而不是只承担“业务状态展示”的职责。

其次是仓库上下文。软件任务从来不是一个脱离代码现实的纯文本问题。一个任务是否真的可执行，往往取决于它在哪个代码库里执行、绑定了哪个分支、是否已经创建对应的 worktree，以及当前 Session 是否仍然处于正确的目录中。没有这些上下文，所谓多 Agent 协作很容易退化成一组脱离代码现实的对话。Routa Kanban 当前已经开始把 codebase、repo health、worktree 与任务卡绑定在一起，这一点尤其重要，因为它让卡片从“描述单元”开始转向“执行单元”。

再次是运行历史。没有 run history 的多 Agent 系统，是无法真正调试的。你可以看到一张卡现在位于 Review，但你看不到它之前经历了什么、被哪个 specialist 接手过几次、为什么 rerun，以及某次失败之后系统是否进入了预期的补偿路径。对于 Agent Team 来说，run history 的意义和传统分布式系统里的 tracing、audit trail 并没有本质差异。它不是锦上添花，而是系统可运营性的基础。

也正因为如此，我越来越倾向于把 Routa Kanban 理解为 Agent Team 的运行时视图，而不是任务清单。它管理的不是消息，而是事实；不是聊天，而是流动；不是单次交互，而是持续交付。

Kanban 能不能成立，取决于它背后的 Harness

但如果我们只盯着界面，很容易错过更关键的一层。Routa Kanban 能否真正成立，根本不取决于看板本身，而取决于它背后的 Harness 是否足够扎实。

我越来越认同一个判断：在 Agent-first 的软件系统里，真正的核心竞争力不是谁能生成更多代码，而是谁能为 Agent 提供更稳定的执行约束、验证回路和反馈机制。换句话说，管理界面只是表层，Harness Engineering 才是底座。没有这个底座，看板只是一层漂亮的皮肤；有了这个底座，看板才有机会成为 control plane。

对 Routa 来说，这个底座至少包含几类能力。第一类是结构化任务与明确边界。任务必须是对象，而不是一段聊天记忆。Objective、Scope、Acceptance Criteria、Verification Commands 这些字段存在的意义，不是为了让表单更完整，而是为了给 Agent 提供稳定的工作边界。第二类是事件驱动与状态持久化。系统必须知道任务何时进入某个阶段、何时触发某个 specialist、何时完成、何时失败，以及这些状态如何被保存和恢复。第三类是执行上下文隔离。代码库、分支、worktree、session 和权限模型必须在运行时保持一致，否则所谓自动化只会制造更多隐蔽错误。

而最关键的一类能力，是验证与硬门禁。一个多 Agent 管理界面如果只负责“发起任务”和“显示状态”，它最终仍然只是一个调度面板。只有当它背后连接着 fitness function、契约优先、lint、测试、API parity、可执行验证证据这些机制时，Kanban 才真正从“任务面板”升级为“交付面板”。在 Routa 现有实践里，这种倾向已经相当明确了。双后端语义一致性、fitness hard gates、可执行证据优先，这些东西都在传达同一个信息：AI 系统不能只靠能力堆叠，还必须靠约束收敛。

这也是为什么我更愿意把 Routa Kanban 放在 Harness Engineering 的语境里讨论。它不是为了给 Agent Team 增加一个更直观的入口，而是为了把原本分散在架构、测试、事件流与执行环境中的工程事实，汇聚成一个可以被人持续管理的界面。

这件事为什么仍然是软件工程

如果从 Thoughtworks 长期强调的软件工程传统来看，这件事其实并不陌生。DevOps 早就告诉我们，自动化一旦扩大，最重要的不是脚本数量，而是反馈回路是否完整。TDD 和 Refactoring 也早就告诉我们，验证不能是事后附加的善意动作，而必须成为系统结构的一部分。DDD 则提醒我们，真正能长期演化的系统，必须先把领域语义建清楚，再去谈界面和实现。

Routa Kanban 的有趣之处，就在于它让这些原则在 AI4SE 语境下重新变得具体。Board、Column、Task、Session、Artifact、Worktree 这些对象，不再只是工程实现里的数据结构，而是在共同定义一个新的交付域模型。在这个模型里，看板不是 PM 的装饰品，而是操作面；卡片不是沟通媒介，而是可运行契约；列也不是状态标签，而是流程策略的承载体。

如果把这个趋势再往前推一步，我们甚至可以看到它与 Legacy Modernization 之间的某种相似性。很多遗留系统的根本问题，不是功能不能跑，而是边界模糊、状态不可追踪、失败路径无人负责。今天不少 AI Agent 产品其实也面临类似问题。它们常常展示出惊人的局部能力，却缺少稳定的运行模型。Routa Kanban 如果继续沿着现在这条路演进，它真正现代化的，不只是开发界面，而是 Agent Team 本身的操作系统。

真正的难点，是把界面语言兑现为运行时语义

也正因为我把它看作 control plane，而不是普通功能页，所以我更在意它现在还没有完全闭环的地方。这次 review 代码时，我最强烈的感受并不是“这个页面做得很好”，而是“这个方向是对的，但必须继续把语义往运行时压实”。

例如，列级自动化已经允许配置 entry、exit、both 这样的触发语义，但运行时并没有完全兑现这套语言。又例如，当 Dev 阶段自动创建 worktree 失败时，任务虽然会被打入 blocked，但 blocked lane 的自动化补偿链路并没有在所有异常路径上完整接上。再例如，既然 Routa 明确是一套双后端系统，那么 board 配置语义就不应该长期停留在单一前端实现里，而应该尽快沉淀为真正共享的领域模型。

这些问题并不会削弱这篇文章的判断，恰恰相反，它们让这个判断变得更真实。因为一个管理界面如果只在成功路径上成立，就还称不上管理界面。只有当失败路径、补偿路径、重试语义、验证证据和跨实现一致性都被同等严肃地处理时，它才真正具备了工程上的可信度。

这也是我想保留的一点 Fowler 式诚实。好的架构文章，不是把系统写成已经完成的胜利，而是把系统正在逼近的问题说清楚，把真正值得继续投资的方向说明白。

结语：Kanban 是表层，Harness 才是护城河

所以，如果今天让我用一句话总结 Routa Kanban，我不会说它是“一个支持 Agent Team 的看板能力”。我更愿意说，它是在尝试回答一个更大的问题：当 Agent 不再只是个人副驾，而开始成为团队成员之后，我们该用什么样的工程方式来管理它们？

我的答案是，首先需要一个管理界面，但更重要的是，这个界面必须建立在 Harness Engineering 之上。它必须连接结构化任务、事件驱动状态、执行上下文隔离、验证证据、fitness hard gates 与契约一致性。只有这样，Kanban 才不是一张漂亮的任务墙，而是 Agent Team 的 control plane。

这也是我认为 Routa Kanban 值得继续写、继续做、继续打磨的原因。因为在 AI4SE 的下一阶段，真正决定系统能否进入日常生产的，往往不会是某次惊艳的代码生成，而是这套系统是否已经具备了被团队管理、被组织信任、被工程约束长期守护的能力。