过去一年，我们习惯用“AI 编码 2.0”来描述这一波技术跃迁：从代码补全走向 Agent 驱动，从同步交互走向异步执行，从一次性生成走向“生成—验证—回滚”的闭环。在那个阶段，一个共识逐渐清晰：AI 不再只是辅助，而开始参与执行。但如果只停留在这里，我们其实低估了变化的深度，因为真正发生转移的，并不是“谁在写代码”，而是——谁在负责软件交付这件事本身。

引子：当看板开始做决策

最近在实现 Routa 的 Kanban 模块时，我原本以为这不过是一个再熟悉不过的工程任务——定义列、支持拖拽、同步状态、补上自动化触发，这些事情在过去的项目中已经重复过太多次，以至于几乎可以在没有设计的情况下直接实现出来；直到我尝试把 Agent 接入看板，让它们根据列的变化自动执行任务，这个系统才开始表现出完全不同的性质。

问题并不是一开始就显性的，相反，它们往往出现在那些我们过去从不认为需要被建模的“边角”位置：卡片究竟在什么条件下才允许移动，如果当前列中仍然存在未完成的执行步骤，是否还应该允许进入下一列，当 Agent 执行失败时系统应该停留、重试还是回退，这些问题在人类主导的协作体系中通常不会被精确定义，因为团队会通过经验、语境和即时沟通不断修正这些决策，甚至不会意识到这些决策本身的存在。

但一旦执行者变成 Agent，这些原本依赖默契维系的部分就会立刻暴露出来，并且从“可以忽略的细节”转变为“系统必须回答的问题”，因为 Agent 不理解模糊，也不会替系统补全语义，它只能在明确的边界内执行，一旦边界不存在，系统就无法继续运行。

于是你会逐渐意识到，看板正在发生一件微妙但本质的变化：它不再只是一个用于展示工作状态的界面，而开始演化为一个参与决策的控制系统——每一次拖拽不再只是 UI 操作，而是在触发一次状态转移判断；每一个列也不再只是阶段标签，而是在承担执行语义；每一个状态都必须是可判定的，否则整个系统就无法向前推进。

这并不是一个实现层面的复杂度问题，而是一个结构层面的变化。

也正是在这个过程中，我意识到，我们其实已经不再讨论“AI 如何写代码”了，而是在讨论另一件完全不同的事情——系统如何组织 AI 完成软件交付。

AI 编码 2.0 是生成系统，AI 编码 3.0 是执行系统

AI 编码 2.0 解决的是生成问题。我们关注如何让 AI 写出更正确的代码，于是不断强化模型能力，引入更完整的上下文工程与工具链，并通过测试、构建与回滚机制来约束结果。这一切努力，本质上都围绕“输出质量”。但当 Agent 真正进入交付流程，问题的重心开始发生偏移。系统不再只是判断代码是否正确，而是必须回答一组更基础的问题：什么时候执行，是否允许推进，失败后是否重试，何时算完成，以及整个过程是否可信。这些问题不再属于生成，而属于执行系统设计。

这正是 AI 编码 3.0 的起点。AI Coding 2.0 优化生成，AI Coding 3.0 定义执行。生成是局部能力，可以通过模型提升；执行是系统行为，必须通过工程体系来约束。一旦我们接受这一点，就会意识到：继续堆叠模型能力，并不能解决系统层面的问题。

当 Agent 进入流程，协作必须被重新建模

在传统开发中，流程由人驱动。人决定开始、推进与结束，也在模糊中做出判断。这种机制之所以有效，是因为人类可以处理不确定性，可以在规则不完整时继续前进，并通过沟通不断修正偏差。但 Agent 不具备这种能力。一旦 Agent 成为执行者，系统就不能再依赖“理解”，而必须依赖“判定”。那些原本存在于团队默契中的隐含规则——什么算完成，什么时候可以交接，失败后该怎么办——都必须被显式表达，否则系统将表现为一种熟悉但不可控的状态：看似在运行，但无法预测。

这意味着一个关键转变：协作必须从经验驱动，转向模型驱动。协作不再是人与人之间的协调行为，而开始成为系统需要执行的一部分结构。如果这部分结构没有被建模，那么无论引入多少 Agent，本质上都只是把不确定性放大。

Harness Engineering：让执行从“能做”变为“可证明地做”

在 AI 编码 2.0 中，我们已经开始引入测试、lint、构建等机制来约束 AI 输出，但这些机制仍然是“辅助验证”。进入 3.0 阶段之后，它们的角色发生了变化：不再只是质量保障工具，而成为执行系统的一部分。这正是 Harness Engineering 的核心。Harness 并不是让 AI 更强，而是让系统更可控。它通过一组可执行约束，将原本依赖经验判断的过程，转化为可验证的工程行为，使系统从“看起来没问题”转向“被证明可以通过”。

这种转变可以理解为一次边界重构：完成不再是主观判断，而是一个可验证状态；验证不再是事后动作，而是驱动流程推进的条件；失败不再是异常，而是系统可处理的分支路径。Harness 在这里承担的，不是增强能力，而是定义边界。它通过验证结果直接影响系统行为——决定是否推进、回退或中断，使“验证”成为执行系统中的控制机制，而不是附属步骤。

Kanban 作为控制平面：统一状态、流转与验证

在这个背景下，Kanban 的角色发生了变化。它不再只是展示状态的界面，而开始承担执行控制的职责。系统需要基于看板状态做出决策，而不是仅供人类观察。这意味着，看板中的每一个元素，都必须具备执行语义：列不再是阶段标签，而是状态机节点；卡片不再是描述，而是执行单元；流转不再是操作，而是状态变更；Gate 不再是说明，而是策略入口。

问题在于，在很多团队中，看板、状态模型与验证规则是三套松散系统。人类可以在它们之间建立隐式映射，但 Agent 不行。一旦三者不一致，系统行为就会变得不可预测。因此，执行系统必须收敛为一个统一模型：状态定义边界，流转定义路径，Gate 定义通过条件。这三者不能只是“基本一致”，而必须严格对齐。

这里的关键转变在于：流转不是移动，而是带约束的状态转移；Gate 不是检查项，而是决定是否允许转移的策略。Harness 在此提供验证能力，使 Gate 不再依赖人工判断，而由系统执行。没有验证的流转，本质上是不受控的执行；而一旦验证成为前置条件，看板就不再只是流程的表达，而成为系统可以计算的控制结构。

编排与约束：多 Agent 系统的真正核心

引入 Agent 后，一个常见误区是“自动化更多步骤”。但自动化只解决局部执行效率，并不能解决系统行为问题。系统真正需要的是在正确的时间做正确的事，而这依赖两个能力：编排与约束。编排决定执行顺序与推进时机，约束定义边界并防止系统进入非法状态。Harness 提供约束能力，而看板（作为控制平面）提供编排入口，两者结合，构成执行系统的核心。

如果缺乏这两个要素，系统会呈现出一种典型症状：局部自动化能力很强，但整体行为不可预测。多个 Agent 可以同时运行，却无法保证结果的正确性与一致性。换句话说，系统变得更“忙”，却没有变得更“可靠”。

多 Agent 协作，是一条被验证驱动的执行链路

当执行模型被统一、验证机制被引入、编排逻辑被明确，多 Agent 协作开始呈现出一种新的结构。它不再是松散的交互网络，而是一条被验证驱动的执行链路。每一个节点对应一个执行上下文，每一次流转对应一次条件满足，每一个推进都经过验证，每一次失败都有明确的恢复路径。

这条链路的关键，不在于有多少 Agent，而在于系统是否能够控制它们的行为。没有 Harness，Agent 只是能力的叠加；有了 Harness，Agent 才成为系统的一部分。系统不再依赖个体能力来维持正确性，而是依赖结构本身。

从“能完成”到“被证明可以完成”

回到最初的问题：AI 编码 3.0 究竟改变了什么？它并不是让 AI 写出更多代码，而是让软件交付从“能力问题”，转变为“系统问题”。过去，我们关心的是 AI 能不能完成任务；现在，我们必须关心系统是否可以证明任务已经被正确完成。这意味着每一次执行都需要被约束，每一次结果都需要被验证，每一次推进都需要有依据。

从“能完成”，到“被证明可以完成”，是 AI 编码 3.0 的本质跃迁。它标志着软件工程从依赖经验的实践，走向依赖可计算结构的工程 discipline。

结语：当协作成为系统行为

在 AI 编码 2.0，我们让 AI 学会写代码；在 AI 编码 3.0，我们开始让系统学会交付软件。这并不是简单的能力提升，而是工程范式的转变。当 Agent 进入流程，协作不再只是人类行为，而成为系统行为；而一旦协作成为系统行为，它就必须被定义、被约束、被验证。

Kanban 不再只是看板，Harness 不再只是工具，Agent 不再只是助手。它们共同构成了一个新的执行系统，一个将协作转化为可计算结构的系统。软件工程也因此从“组织人如何工作”，转向“定义系统如何工作”。

这是 AI 编码 3.0 真正开始的地方。