当 Agent 进入看板：从协作界面到可计算系统
摘要：当执行者从人扩展为 Agent，Kanban 要解决的问题就不再只是“让工作可见”，而是“让流转可判定、让约束可执行、让历史可追踪”。在 Routa 的现有实现里，这种变化已经开始发生：列不再只是标签，流转不再只是拖拽，Gate 也不再只是 checklist。看板正在从协作界面，演化为多 Agent 软件交付的 control plane。
导语：过去讨论 Kanban，我们更关心的是如何协作。列怎么分、在制品怎么控、阻塞怎么暴露、节奏怎么稳定。这一套实践在以人为执行者的团队里非常有效，因为人类天然擅长在不完整规则下工作。很多时候，流程之所以成立，并不是因为系统定义得足够严格，而是因为团队成员会在语境里自动补全那些没有被写出来的部分。
但一旦执行者开始变成 Agent，这种默认前提就不成立了。Agent 不会“差不多理解”，也不会“按经验处理一下”。它们依赖的是可判定的状态、明确的边界与稳定的反馈信号。也正因为如此，我越来越觉得，当 Agent 开始真正进入看板之后，Kanban 的本质就已经变了。它不再只是一个帮助团队理解进度的界面，而是在逐步变成一个可以被系统执行的语言。
看板不是工作流，除非系统真的理解它
传统 Kanban 的价值，首先在于可视化。Backlog、Doing、Done 这些列，把原本隐性的工作过程拉到台面上，让团队看见工作如何流动、阻塞出现在哪里、交付能力受什么影响。这种设计之所以成立，是因为列的含义很大程度上依赖人来解释。
但对 Agent 来说，问题不在“能不能看见”，而在“能不能判断”。
如果一个系统只能把列显示出来，却不能根据这些列决定接下来该做什么，那么它拥有的只是一个看板界面，而不是一个工作流系统。
工作流不是你在看板上看到的东西，而是系统能够据此做出判断的东西。
Routa 的实现已经相当清楚地表明了这一点。卡片移动到新列时，并不是单纯改一个字段，而是会发出 COLUMN_TRANSITION 事件；随后由 KanbanWorkflowOrchestrator 去读取 board 上的列自动化配置，决定这一列是否需要触发 specialist、是否要创建 session、是否要继续同列内的下一步、是否应该在成功后自动推进。换句话说，列已经开始承载运行时语义，而不是只承担视觉分组。
这件事的意义很大。因为一旦列开始被系统解释，看板就不再只是任务墙，而是状态机的外观。
列必须像状态，而不是像标签
很多团队其实默认把列当作标签。To Do 和 Backlog 差不多，In Progress 和 Doing 也差不多，只要团队内部能理解，问题似乎就不大。
但在 Agent 系统里，这种“差不多”会迅速变成系统性错误。
如果你的系统里同时存在两套状态模型，一套给 UI 看，一套给业务逻辑用，那么人类当然还能在脑中把它们对齐；Agent 做不到。Agent 只会在边界条件上不断碰撞，然后把这些不一致放大成大量异常路径。
如果系统里存在两套状态，系统实际上就没有真正的状态。
Routa 当前的代码很能说明这个问题。Board 明确有 backlog、todo、dev、review、done、blocked 等列，任务也会根据列映射到不同的 TaskStatus。但反过来，状态再映射回列时，却并不是完全对称的一一对应。这并不意味着实现失败，恰恰相反，它把问题暴露得很真实：一旦列开始承担自动化语义，列和状态就不能只是“差不多一致”，而必须是同一个工作流模型的两种投影。
这也是为什么我越来越倾向于把 Agent Kanban 理解为“可计算的工作流外观”，而不是“可以拖拽的任务面板”。只要列还是标签，系统就仍然依赖人类兜底；只有列变成状态，看板才会真正进入软件工程的语境。
每一次流转，都应该是一个显式契约
在人类团队里，卡片从一列移动到下一列，很多时候依赖的是软约定。你把卡拖过去，别人自然会理解成“差不多好了”；你在评论里留一句话，后面的人大概知道该接手什么。
这种方式在人类协作中完全合理，因为协作本身就建立在共识和补位能力之上。
但 Agent 不能靠共识工作。对它来说，流转必须是显式的契约。
一次状态转移，从来不只是“从 A 移动到 B”。它背后至少包含几件事情：是否允许进入目标列、进入之后是否需要自动触发某个 specialist、如果失败了如何补偿、如果同一泳道还有下一步，当前卡片是否根本不该离开这一列。
流转不是移动，而是一次决策。
Routa 在这里做了一个很正确的选择。任务手动移动列时，系统会先检查当前泳道是否还有未完成的自动化 step。如果当前 specialist 结束后，同一列里还有下一个 specialist 要接着跑，那么这张卡会被直接阻止离开当前列。这个设计看起来严格，实际上非常重要。因为它把“列内多步协作”从隐含约定提升成了运行时契约。
一旦流转变成契约，工作流才具备可预测性；而没有可预测性，多 Agent 协作就很容易退化成一串互相打断的会话。
Gate 不是 checklist，而是策略
很多团队都说自己有质量门，但真正落到系统里，常常只是 checklist。是否有测试结果，是否上传了截图，是否留了说明，满足这些形式要求后，任务就被视为“可以进入下一阶段”。
在人类团队里，这样的门禁勉强还能工作，因为人会继续解释上下文，也会在不合理时主动拦下来。
但在 Agent 系统里，Gate 不能只是“有东西”，而必须是“允许通过”。
证据的存在，不等于验证已经成立。
Routa 现在已经有了 Gate 的雏形。列自动化配置允许声明 requiredArtifacts，例如截图、测试结果、代码差异；任务进入目标列之前，系统会检查这些 artifact 是否存在。与此同时，dev lane 的监督模式还可以要求某个 session 不只是结束，还必须留下 completionSummary 或 verificationReport，否则即便 session 看起来成功，也不会被认定为真正完成。
这已经比“靠备注说明做完了”严肃得多。但它也非常清楚地提示出下一步方向：Gate 不应该停留在存在性检查上，而应该继续向策略判定演进。系统里已经有 verificationVerdict 这样的字段，这说明领域模型其实已经在为“通过”与“不通过”预留位置。真正需要补齐的，是让流转逻辑开始消费这些判定结果，而不是只消费“是否填了报告”。
一旦 Gate 被提升为策略，Kanban 才会从管理界面变成交付系统。
比自动化更重要的，是编排
引入 Agent 之后，一个非常常见的误区是：把每一列都变成自动化节点。Backlog 进一个 Agent，Dev 进一个 Agent，Review 再进一个 Agent，看起来整条链路已经全部自动了。
但问题也恰恰出在这里。系统开始做很多事，却没有谁真正负责决定什么时候该做、什么时候不该做、什么时候失败、什么时候需要恢复。
Kanban 的核心从来不是“自动化每一步”，而是“管理工作的流动”。当执行者变成 Agent，这个原则只会变得更重要。
自动化负责执行，编排负责决策。
Routa 当前真正有价值的，不是 specialist prompt 本身，而是 KanbanWorkflowOrchestrator 这种编排层的存在。它会监听 AGENT_COMPLETED、AGENT_FAILED、AGENT_TIMEOUT 和 REPORT_SUBMITTED 这些事件，维护 active automations，决定当前列是否需要恢复、是否应启动同列内下一步、是否应该自动推进到下一列。在 dev 阶段，它甚至还会配合 watchdog 和 ralph_loop supervision mode，对长时间没有活动的 session 进行恢复或重试。
这说明一个很重要的工程判断：在 Agent 系统里，提升效率的不是“有多少自动化步骤”，而是“谁在监督整条链路”。没有编排层，自动化很快就会失控；有了编排层，自动化才可能成为可治理的能力。
历史不能是副产品，而必须是一等公民
人在协作时，历史通常是副产品。评论是历史，提交记录是历史，即时通信也是历史。只有真的出问题时，团队才会回头去翻这些信息。
但对 Agent 系统来说，这样的历史形态太松散了。
每一次交接、每一个失败原因、每一次恢复尝试、每一条 lane 间请求，都必须变成结构化事实。否则系统根本无法解释自己为什么这么做，也无法告诉你它是在哪一步偏离了预期。
如果一项工作无法回放，系统其实并不理解它。
Routa 在这方面的设计是很值得肯定的。任务不是只保存一个当前运行中的 triggerSessionId，而是保存 laneSessions 与 laneHandoffs。前者记录某个 session 属于哪个列、哪个步骤、哪个 specialist、何时开始、何时结束、是否处于 recovery 模式；后者记录相邻泳道之间的请求与响应，例如环境准备、运行时上下文、澄清说明或命令重跑。
这会带来一个很重要的变化：多 Agent 协作不再只是聊天记录，而开始变成可重放的执行历史。再加上 Agent 通过 MCP 工具回写 completionSummary、verificationReport 等结构化字段，系统终于可以把“发生了什么”与“为什么这样判断”一起保留下来。
没有这层历史，Kanban 最多只是一个当前态界面；有了这层历史，它才真正具备 trace、治理与改进的基础。
在软件交付里，卡片永远离不开执行上下文
传统任务管理系统有一个容易被默认接受的前提：卡片描述的是工作本身，至于工作在哪里做、如何做、依赖什么环境，那是执行层的事情。
但软件交付从来不是这样。一个任务是否真的可执行，往往不只取决于描述是否清晰，还取决于它绑定了哪个仓库、哪个分支、哪个 worktree、哪个 session、哪个运行环境。
在软件工程里，工作永远不会脱离它的执行上下文。
Routa Kanban 之所以值得继续写，就是因为它已经开始把这些上下文从背景信息提升成显式对象。任务可以绑定 codebase，进入 dev 列时会尝试自动创建 worktree，任务还会关联 session、lane 历史与 artifact。更进一步，系统给 Agent 的 task prompt 里，还会明确规定当前列可以使用哪些 Kanban MCP 工具、什么时候允许 move_card、什么时候必须先补齐 artifact。
这件事的价值，不在于“提示更详细”，而在于它把执行上下文从聊天记忆里抽离出来，放回到了系统模型里。卡片因此不再只是描述单元，而开始接近一个真正的执行单元。
从可视化走向可计算
把这些变化放在一起，其实能看到一个非常清晰的演进方向。
Kanban 一开始解决的是可视化问题，让团队理解工作在哪里；随后，它通过 WIP 限制、流动管理和阻塞暴露来优化效率。而当 Agent 开始成为执行者之后，系统面对的核心要求变成了另一件事：所有关键环节都必须可判定、可执行、可验证。
协作可以容忍模糊，计算不能。
这会推动看板发生一系列根本性的变化：
- 列从标签变成状态
- 流转从操作变成契约
- Gate 从检查变成策略
- 历史从副产品变成系统资产
- 上下文从背景信息变成显式执行边界
软件工程的关注点也因此发生偏移。过去，我们更关心的是如何帮助人类团队沟通与协作；现在，我们必须同时定义系统自身的行为边界。
当 Agent 开始执行工作，软件工程就越来越变成一门关于可计算性的学科。
所以，如果今天让我概括这件事，我不会说“Kanban 正在拥抱 Agent”。我更愿意说，Kanban 正在被迫进入软件工程更深的层次。它不再只是帮助人理解工作的界面，而是在逐步变成一种让系统理解工作、约束工作、验证工作、追踪工作的语言。
这也是为什么我会觉得，Agent 时代真正值得投入的，不只是更强的模型能力，也不是更顺滑的聊天体验，而是这些能把能力收敛成系统行为的工程结构。因为只有当看板真的从协作界面演化为可计算系统，多 Agent 软件交付才有机会从演示走向日常生产。