日产万行业务代码背后，我们真正修的是一条 Harness 公路
原创作者：吴穹
导语：前几日，吴穹博士在全球AI生态与创新峰会上分享了主题为《日产万行业务代码背后的 Harness 之路》的演讲，本文根据演讲内容整理。如您想获取演讲PPT，请至我们的官网下载：https://www.agilean.cn/events/ 。
很多团队现在都有一个很微妙的感受：
工程师确实变快了。
代码解释、代码生成、单测补齐、接口联调、文档整理，过去要花很久的事情，现在 AI 可以先把一大半脏活干掉。
但回到组织层面，事情没有那么乐观。
个人速度上去了，组织交付却不一定跟上。甚至有些团队会发现：提交更多了，返工更多了；代码更快了，质量压力更大了；每个人都觉得自己提效了，但需求排期、联调、验收、发布和线上风险，并没有同比下降。
这就是我这次演讲想讨论的问题：
AI Coding 进入组织之后，真正稀缺的不是“让 AI 多写代码”，而是让 AI 写出来的东西可以被组织稳定接住。
换句话说，业务代码日产万行不是靠“提示词更猛”撑起来的，而是靠一整套 Harness 工程底座托起来的。
先说结果：这不是一个 Demo
过去两个月，我们的自研产品Kanban2 进入了一段非常高强度的建设期。
不是一个玩具项目，也不是一个局部试验，而是一个有前端、后端、CLI、测试、文档、Agent 运行时、环境脚本和交付流水线的百万行级工程。
按当时最新统计，三类代码已经到了175万行：
业务代码约 88.8 万行
测试 + CLI 约 60.3 万行
文档约 26.2 万行
测试、CLI、文档并不是“附属物”，已经成为交付系统本身的一部分。
这两个月里，我们大概稳定增长了100万行级别的代码量。里面当然包括业务、测试、CLI、文档和 Harness 相关建设，但这恰好说明了一件事：AI 带来的高吞吐，不会只冲击业务代码，它会把整个工程系统一起推到极限。
代码越多，越难验收； 提交越快，越容易返工； Agent 越多，环境越容易互相踩； 上下文越长，越容易丢失决策。
所以，这场分享表面上讲的是“日产万行业务代码”，底层讲的是：
当 AI 把个人生产力放大之后，组织要先补哪一段工程底盘。
最近行业里也开始频繁讨论 Harness Engineering。
我自己的理解很朴素：Harness 不是一个测试脚本，也不是一个 Agent 框架，而是让 AI 能够在真实工程里稳定观察、行动、验证、恢复和协作的一整套运行底座。
它至少包含几类能力：
让 Agent 知道该读什么、按什么顺序行动
让 Agent 能造数据、跑测试、查日志、开环境
让 Agent 的修改有静态红线和动态闸门
让长程任务有计划、状态、证据和验收记录
让多 Agent 并行时不互相踩环境、踩端口、踩上下文
让人最终验收的是“结果包”，不是一堆解释
我们这次做的不是完整的 Harness 终局。
比如更高级的智能体编排、跨智能体工作流、长期记忆系统、Agent 自我优化、Meta-Harness，这些都还只是下一阶段方向。
但我们至少把一件事做实了：先让 Agent 不再裸奔。
这条路怎么修：
9 步 Harness 建设
我们最后把这条路整理成了 9 个步骤：CLI、数据、测试、观测、环境、验收、上下文、技能、优化。
它不是一开始设计得这么完整，而是在高强度交付里一段一段长出来的。
第一步：先把 CLI 做成可编程验收机
很多人听到 CLI，会以为是给人敲命令的工具。
但我们做的 CLI，更准确地说，是一个“以命令行形态出现的可编程验收机”。它的主要用户不是人，而是 Agent、脚本和 fullcheck。
命令行只是最薄的一层皮，真正有价值的是背后的 setup、verify、session、fixture 和断言体系。
为什么要先做这个？
因为 Agent 写业务代码很快，但如果每次验收都靠人手点、手工造数据、人工看接口，那组织吞吐根本起不来。
所以第一步不是写更多功能，而是先把验收能力变成 Agent 可以调用的工具。
第二步：利用CLI构造稳定测试数据
只有命令还不够。真实业务系统最大的问题之一，是“数据状态”。
一个看板、一张卡、一个字段、一个公式、一个权限、一个成员关系，都不是孤立的。很多功能必须在一个完整业务宇宙里才看得出来。
所以我们建设了 setup / verify 体系，让 CLI 可以从零种出测试组织，再围绕这个组织跑大量断言。
这一步的价值是：让 Agent 不再依赖人工造数。
没有它，验收会变成“你先帮我配个环境，我再看一下”；有了它，Agent 可以自己把现场搭起来。
第三步：构建分层 fullcheck 闸门
CLI E2E 长出来之后，下一步不是“再写更多测试”，而是把它收进统一的 fullcheck。
fullcheck 最后变成 L0 到 L9 的分层闸门：
前面挡契约、编译、单测
中间挡组件级正确性
后面才碰真 Gateway、真运行时、真业务链路
这里有一个很重要的设计：L7 和 L8 不是重复。
L7 更像“一场景一组织”的 API 契约网，追求快、隔离、可并行。
L8 更像“一宇宙多 verify”的产品样板间，追求厚、可调试、可演示，还能接 UI 验收。
这也是 Harness 和普通测试最大的差别：普通测试回答“这个函数绿不绿”； Harness 要回答“这个改动能不能进入交付系统”。
第四步：让 Agent 看得见环境
测试能告诉你“能不能合”，但出了问题以后，Agent 还要能自己看见现场。
所以我们补了可观测性：
本地 Loki + Alloy
共享 dev 环境日志查询脚本
Agent 只读查日志
按 path / ERROR / ACCESS 反查 traceId
环境入口写进 docs / AGENTS / skills
这块不要和 fullcheck 混在一起。
fullcheck 回答“能不能合”； Loki 和环境契约负责“出了问题能不能自己查”。
以前是人去翻日志、问端口、猜 profile。后来变成 Agent 自己查日志、定位 traceId、确认环境入口。
这一步看起来不酷，但对长程 Agent 很关键。因为一个不能看见环境的Agent，只能不断问人。
第五步：让 Agent 自己管环境，而不是等环境
能查日志只是“看得见”，还不够。Agent 改完代码之后，还要能自己把环境跑起来。
以前启停全栈是纯手工活：重启哪些服务、用什么 profile、端口有没有被占，全靠人记、人猜、人盯。
我们把“启停全栈”写成了 Agent 可执行的契约：
dev:restart:touched读代码 diff，只重启改到的服务，不搞全量重启
agent:ui:open预检 session / profile，缺UI时自动拉起 preview
check:services / detect:ui-profile让环境状态可自证，不靠猜端口
这一步的收益在多 Agent 并行时最明显：每个 Agent 自己起、自己停、自己锁，不再互相踩环境。
再往后，管道和容器也进了 Harness。
管道即代码：.cnb.yml 纯 YAML，触发器、阶段、密钥 imports 都能进 PR 评审。
环境即容器：Nacos / MySQL / Redis / Kafka / ZGraph / Loki 都可以一键重建。
部署不靠人点：YAML 触发部署、重启、种测试组织，Dev 环境留给人验收。AI 写完代码不用再“等人点部署”，才算真正端到端闭环。
改完后端自己重启，验收前端自己点亮——环境自治是多 Agent 不互相踩脚的前提。
第六步：让 Agent 能进 UI 现场验收
API 和 CLI 绿了，不代表用户真的能点。所以我们又补了一层 UI 现场验收：
Playwright MCP 控制真实浏览器
feature map 告诉 Agent 功能在哪个页面
agent:ui:open 负责免登录直达
acceptance recipes 记录交互步骤和断言
CNB 下关键改动还要求截图证据
这里的关键不是“页面能打开”。而是本次交付的能力，是否真的在 UI 上可见、可点、可验证。
我们不只给 AI 测试脚本，还给它一张功能地图和一把免登录直达钥匙。
第七步：给 Agent 完整文档上下文
前面六步解决的是“改动做对了没有”。但还有另一个问题：Agent 做的是不是该做的？下次换一个 Agent，还能不能接着做？
所以第七步，是把上下文从聊天记录搬进文档文件系统。
我们的原则是：文档系统不是附录，而是 Agent 的只读内存。它分四块：
设计定真相：docs/design 承接需求、产品意图和 durable 设计，Agent 改行为前先对齐 SSOT
计划定节奏：大任务先拆成可执行计划，放进docs/plan/active，不散落临时目录；计划驱动落地，而不是即兴改
评审挡跑偏：计划评审和专题 review 进 docs/review，把方向问题前置；CNB 下由计划 hook 负责关门
归档接得上：做完归档archived + state.md，当前事实沉到 state / quality / security / observability，下个 Agent 能从同一状态继续
没有这套文档系统，上下文搬运只能靠聊天，换 Agent 就失忆。代码可测试，决策也要可追溯；否则高吞吐会变成无文档乱写。
第八步：给 Agent 预装地图、技能和红线
到这一步，CLI、数据、闸门、观测、环境、验收都齐了，但还差一层：Agent 怎么知道这些东西的存在，又该按什么顺序用？
不能指望每次都在聊天里把背景重新讲一遍。我们把“怎么用这个系统”也工程化了：
文档是地图：AGENTS.md + agent-entry-guide 定阅读顺序，design / api / dev / testing / plan / review 分层承接知识
Skills 是驱动：碰到 UI、日志、fullcheck、gateway 这些场景，直接按预装的 SOP 执行，少即兴发挥
L1 是内核检查：20+ 静态守卫在测试之前，先把违规代码拦住
这一步解决的是“换 Agent 就失忆”的问题。
经验如果只留在人脑和聊天记录里，每个新会话都要重新发明一遍流程；写成文档和 Skill 之后，流程是被预装的，换一个 Agent 也能接着干。
文档定入口，Skills 定流程，L1 定红线——先让 Agent 不迷路、不乱来，再谈日产万行。
第九步：持续优化，让 Harness 自己长厚
九步不是一次修完就结束的路。Harness 铺好之后，真正拉开差距的是日常优化。
我们的原则，是把每次失败反馈固化成可复用、可诊断、可强制的 fullcheck 能力：
正确性先收口：L1-L9 分段闸门把契约、编译、运行时分开挡，失败报告直接告诉 Agent 哪层挂了、怎么复跑
稳定性吃掉 flake：L8-retry、稳定性登记册、锁泄漏修复，让偶发失败可诊断，而不是“再跑一遍试试”
降成本也要强制：path-aware 只跑受影响的分层，降低无效运行；CNB stop hook 让同一份 diff 必须过闸才能收尾
没有这一步，Harness 会停在脚手架阶段：flake 和慢反馈一直耗人，大家慢慢就不信了。
有了这一步，每一次失败都在给系统加一条护栏，Harness 才会产生复利。
反过来看：没有这些 Harness 会怎样？
没有 CLI，就只能手工验收。
没有数据底座，就只能手工造数。
没有 fullcheck，就只能靠人肉判断质量有没有回退。
没有 Loki 和环境契约，就只能到处拷贝日志、猜端口、猜 profile。
没有 UI 现场验收，就只能忍受“接口对了，页面不知道”的不确定性。
没有文档、Skills 和上下文体系，就只能反复把背景搬给下一个 Agent。
没有 stop hook 和强制闸门，就只能靠自觉。
所以 Harness 的价值，不是让流程变复杂，而是把原来那些不可见的人工成本，变成 Agent 可以执行、机器可以检查、人可以复核的工程资产。
使用心得1：
把流程也变成 Harness 的一部分
很多团队讲 AI Coding，只讲“怎么让模型写代码”。但真正落地以后，你会发现写代码只是中间一环。
我们的基本流程是：意图输入 → 低成本模型生成计划 → 强模型评审计划 → Agent 在开发机执行 → fullcheck / UI 验收 → 部署 Dev → 人工验收 → 单主干小步前进。
这里有几个细节很重要。
第一，计划要落盘，不是聊完就散。计划进入 docs/plan/active，评审产物进入 review，做完再归档。
第二，执行机上要明确谁关门。CNB 模式下，Agent 回合结束前必须过 fullcheck，必要时还要补 UI 验收。
第三，人工验收前，Agent 应该交付“证物”：fullcheck 结果、关键截图、改动说明、计划链接、必要时还有日志线索。
这才是一个能进入组织流程的 AI 交付方式。
使用心得2：
重构不能欠，债务会被 AI 放大
这两个月还有一个很强的体感：AI 让你写代码更快，也会让技术债扩散更快。
如果计划评审时发现架构不对、边界不稳、命名不清、上下文不一致，不能因为“先跑起来”就放过去。
我们在高强度交付里做了大量 refactor，不是为了洁癖，而是为了让系统继续可被 Agent 理解、可被测试守护、可被人接管。
AI 时代对架构能力的要求不会下降，反而会上升，因为模型很擅长沿着已有结构继续生成。结构好，它会加速复利； 结构坏，它会加速腐烂。
怎么落地：
先别急着造智能体
我给团队的建议很简单：
先选一个中等复杂度的系统。太简单，看不出效果；太复杂，周期太长。
最好找一个 Pair：一个人懂业务系统，一个人架构设计能力强。如果一个人两者都强，那当然更好。
第一阶段，不要急着建专用智能体。先从零补一条端到端链路：
能造数据
能跑验收
能查日志
能启停环境
能定位 UI 页面
能把计划、评审和证据沉淀下来
先守护基本系统能力，再开始重构。等两个人都能人工达到比较高的交付吞吐，再考虑建设专用智能体和 Skill。因为很多智能体不是“建出来”的，而是“长出来”的。
很多企业现在的问题是：Harness 还没稳，就急着做 Loop Engineering、Graph Engineering、智能体编排。
这些方向当然先进，也一定会来。但如果人都不能稳定提效，却希望直接上一个能自动运行的智能体，大概率会变成空中楼阁。
我们还没做完什么？
最后需要说的是，我们现在做的只是 Harness 的一部分。
已经做得比较实的，是：
文档入口、Skills、L1 invariants
CLI setup / verify
测试数据底座
fullcheck 分层闸门
Loki 可观测与环境契约
UI 现场验收
多 profile 与启停自治
CNB 强制闭环
基础设施 YAML 化、环境 Docker 化
但未来还有很多要补：
智能体编排
跨智能体工作流
长期记忆系统
Agent 自我优化
任务轨迹沉淀与评估
Harness 自身的持续演进
这也是我对 Harness 的判断：它不是 AI Coding 的一个附属品，它会变成 AI 软件工程时代的基础设施。
结语
业务代码日产万行，听起来像一个产能故事。但我真正想分享的，不是AI 写得多快，而是组织怎么接得住。
如果没有 Harness，高吞吐只是更快地产生混乱。有了 Harness，AI 才有机会从个人工具，进入组织交付系统。
这条路不神秘。从一条端到端链路开始，把测试、数据、日志、环境、验收、文档和计划一点点补起来。先让 Agent 不迷路，不乱跑，不裸奔。然后再谈更高级的智能体编排和自我优化。
这大概就是我这两个月最大的体会：先修公路，再上高速。