大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



上一篇文章《Multi-Agent系统Harness Engineering架构的思考与实践》我们从 agent 与 MAS 的技术脉络、单 agent 到多 agent 的工程化边界、协调拓扑选择，结合multi-agent项目实践整理，提出了一套针对multi-agent项目场景的harness engineering四层治理架构。

这个项目的大部分代码也是用vibe coding实现和搭建的，在持续用 vibe coding 推进项目时，陆续也发现了不少问题，主要问题涉及存在helper、adapter、fallback在逐步膨胀，甚至成为与主路逻辑并列的实现， 还有不同的状态歧义也会从局部症状逐步升级为 ownership、同时还存在authority、contract、handoff等层次界限不清晰的问题，经过深度定位分析后，这些问题背后主要原因不是一开始架构没设计对或者某个模块没有按要求实现，而是使用vibe coding把项目代码实现推进得太快，而代码review和框架治理实际并没有跟上。

结合使用vibe coding agent(主要是codex)搭建agent项目(已经有点自复制的意思了)的经验做了对应的思考和复盘，当一个项目开始长期依赖 vibe coding 推进时，最先发生变化的往往不是某一次明显报错的失败，而是没有被review到的隐藏问题逐渐积累叠加，系统开始越来越难回答一些架构层面的基本问题：谁在推进状态，谁在发布边界，谁在定义当前真值，谁又只是历史兼容路径的残留。短期看，这些问题会表现为 helper、adapter 和 fallback 等旁路逻辑的快速无序增长。从而长期看，它们会把问题推向项目运营的工程治理问题：如何为 agent 项目建立能够持续约束边界、契约和演化方向的 harness。

到了这个阶段，harness 已经不再只是架构图上的抽象名词，也不是某个 SDK 的外壳，或者作为一个抽象的概念存在。它开始转向更具体的工程治理工作，目标是如何让agent系统在长期演化里仍然守住架构不同层之间的边界、契约和协同，让vibe coding agent交付的工程项目保持在相对受控的范围内进行持续迭代和进化，这也是harness在vibe coding场景应用的价值意义之所在。

如果你最近在一个比较复杂的项目里大量使用 coding agent，这个场景大概率并不陌生：前期搭建你会觉得速度惊人，中期开始发现 helper 变多了，然后各种adapter 和 fallback 开始增殖，再往后你会发现前后端甚至开始出现对“当前到底哪个状态才算唯一的SoT(Source of Truth)”已经说不清楚，因为不同的模块实现和改动无形中构造出很多旁路逻辑和多套真值映射路径。这个阶段最常见的解释是“AI 容易写屎山”，但这个解释并没有深入到问题本质，更准确的说，问题不在 helper、adapter 或 fallback 本身，也并不是模型“凭空写坏了代码”，而在于它把系统里原本就没有冻结好的边界、契约和归属，以更快的速度随不受控的迭代放大了。

以上判断来自一个我近期实际参与的内容创作方向的多智能体项目。这个项目也不是从零开始，前期开始在架构上进行过一些收敛，后面确定了中心化主从结构的mas架构，在已有mas主体架构的基础上，基于agent的orchestration、memory、runtime以及前后端队列等组件进行持续迭代，直到某天测试开始发现了不对劲，某个bug一直没法解决，一路溯源，发现暴露问题在A模块，但追溯到B再到C，改了多次也没有解决，最后回到了架构上，发现不是架构设计错了，而是架构边界不清晰，导致coding agent不受控的钻了"约束不严格"的空子(这个倾向在codex中经常发生，某些模糊边界容易走捷径)，导致架构分叉出现旁路逻辑，SoT映射不同步等偏离架构的行为发生。这种问题如果不经过深入溯源就很难发现原因所在，而如果只是沿着表象的原因去做重构，就会出现技术债叠加，甚至导致项目越修越偏而更加难以维护。

在这个项目中，随着一轮轮重构推进，由于没有严格review(一般人工review很难跟上)，在架构框架约束上做得不够深入和系统，导致发生了多次实现偏离，项目也一直没有收敛到规范的工程实现上，其中架构层面的偏离主要发生了三次，重新定位根因之后进行了对应的三次根因修复，才将代码拉回到正确的架构约束和规范实现上。第一次，把“orchestrator 太厚、adapter 太多”的表层问题定位为根因是 ownership 越层与 canonical host 缺位；第二次，把“系统 SoT 不清晰”这种偷懒表述，拆解成四类不同语义对象被投影和 fallback 混读；第三次，前端那些看似只是脏兜底的逻辑，被重新识别为 backend contract 没有冻结的结果。

把它再说得具体一点，这个项目三次修复有价值的点，并不是某个单点bug是如何解决的，而是需要对vibe coding的代码连锁反应(某个问题多轮迭代持续传递)进行深入分析后，确定根因主要是架构层面的框架约束问题，包括架构层次不清晰，边界模糊，状态管理抽象不够等，例如负责编排的主线开始顺手承担边界发布和状态推进，历史兼容代码继续留在主路径，下游输入有时读 runtime carrier、有时又悄悄回退到短期记忆映射，前端为了“先让它能用”开始合并多个状态，最后系统虽然还能跑，但其实都是在做表层代码的整合，根因没有从框架约束上入手，始终属于随时可能偏离的状态，这样最直接的问题就是，关于架构和技术实现上的这些基本问题，你问coding agent，甚至变得无法回答：这个问题的根因到底是什么，到底哪个事实来源是唯一标准， 这也是为什么问题必须从工程实践里展开，而不能只停留在抽象概念上，否则问题根因都没有办法得到暴露。

当然并不是agent编程场景都需要一整套厚重 harness。对一次性、短生命周期、单消费面的任务，简单 workflow、清晰工具边界和扎实测试往往已经足够。真正容易把问题放大的，是更复杂的系统工程：任务跨多个阶段，状态要跨回合延续，有多个 consumer 读取不同表面，还背着历史兼容层与旧路径债务。在这类系统里，harness 才会从“有帮助的工程增强”变成“真正承重的结构”。上面所讲的自身经历的项目，也正是这一类问题。

如果把这件事与近期公开的**实践放在一起看，就会发现很多业界分享和上述笔者自身的项目实践也是比较吻合的。Anthropic 在关于 agent、tools、long-running harness 和 evals 的一系列工程文章里反复强调：成功的 agent 系统往往依赖简单、可组合的模式，而不是越来越厚的框架；工具边界、长程环境工件、阶段治理和评估机制的重要性，并不亚于模型本身。[1][2][3][4][27] 其中，Anthropic 在 2026 年 3 月 24 日那篇工程文章开头也直接点明：“Harness design is key to performance”。[27] 文章还用 frontend design 和 long-running autonomous software engineering 两类任务说明，对于long-running任务，真正把模型往前推的，不只是更好的提示词，而是更好的 harness。

OpenAI 关于 harness engineering 的工程文章，关注点也已经转向环境、验证、反馈回路和 repository-local knowledge(外部知识库资料加入到上下文管理中，让agent可以直接访问) 这些 agent 可直接消费的工程对象[30] ，提到agent在严格边界条件的环境下工作更有效，通过结构测试来对代码交付进行验证。

LangChain 在 2026 年3 月关于 agent harness 的文章里，则把 harness 直接定义为模型之外那整套让 agent 真正变得可用的代码、配置和执行逻辑。[33] 而 OPENDEV 这篇论文给出的也不是抽象定义，而是一组更具体的 harness 实践：工作负载特化的模型路由、规划与执行分离的双代理架构、自适应上下文压缩、跨会话记忆和事件驱动提醒，本质上都在回答同一个问题：如何围绕模型建立能够支撑长程软件工程任务的外部工作系统。[28]

这些放在一起看，vibe coding构建复杂项目的问题可以总结为，在这类长期演化、状态需要持续延续、又背着兼容路径债务的主路径工程系统里（以agent工程为例），helper、adapter之类旁路代码的增加，并不是只单纯的让代码变脏，而是因为它们往往意味架构和工程目标的失控开始发生：边界没有被稳定发布，状态没有被单一对象推进，问题与对象之间原本应该唯一的回答关系开始松动。到了这一步，后面真正需要修复的，就不再只是局部重构怎么实现，而是如何把这些原本分散在架构、契约、上下文和评估里的约束重新组织成一套能够持续约束 agent 实现方向的工程工作，也就是 harness engineering。

如果从问题表面进行分析，上面提到这个vibe coding项目容易被贴上的这样的标签：orchestrator 变厚了，helper 变多了，adapter 变多了，legacy wrapper 没清干净，前端又写出了一堆 fallback。那解决的思路自然就是继续做旁路收拢，继续删旧逻辑，把调用链收薄来进行代码清理。

但问题在于，系统并没有因为“继续薄化”而回归到合理的架构和治理路径上。相反，每往前走一步，大概率都会冒出新的并列问题：有些逻辑看起来从 orchestrator 抽出来了，但只是平移到了另一个 helper；有些状态看起来从 runtime read-model 统一到了 memory 或 summary object，但下游仍然可以从另一个 projection 得到一个“差不多对”的答案；有些前端 fallback 看起来只是用户体验兜底，但再深挖一点，发现其实是后端 contract 没有严格定义清楚状态范围，fallback逻辑转移到了前端。换句话说，系统问题不是单纯代码多实现或者错实现了某个模块，而是没有一套明确定的架构设计和框架规范约束来保证正确合理的推进方向。

从问题分析角度进行切入，“屎山”当然存在，但它只是观察结果，需要对问题进行诊断分析。进行诊断分析分别对应三个问题：第一，问题对应的输入和状态是不是存在多路径的依赖，导致SoT存在多路径来源，导致无法实现状态同步，引起异常断链；第二，这些路径分别属于 runtime truth、facts truth、边界约定还是状态映射；第三，哪条路径原本只是过渡态，却在实现中被默认升级成了正式宿主。如果这些问题不先被说清楚，后续的“继续重构”的指令执行都很可能只是换一个地方继续堆叠，而无法从根本上进行约束修正。

Anthropic 在 long-running agent harness 的工程总结里记录的首要失败模式，不是“代码写得不够漂亮”，而是 agent 试图一次做太多事情、在上下文切换时留下半实现状态、并让后续 session 在不完整线索上猜测前情；即使系统具备 compaction，问题也不会自动消失。[3] OPENDEV关于 terminal coding agents 的论文则更直接地把 context bloat、reasoning degradation、strict safety controls 和 context management 放到了同一层来讨论，扩宽了harness包括的范围。[28] 换句话说，使用coding agent来搭建复杂任务，表层迹象问题当然也重要，但它真正提供的只是入口；如果不能继续追到 authority、contract、host ownership 和跨 session harness 这些更高层对象，后面的清理动作就很容易停留在症状管理。

总结一句话就是，在vibe coding实现的复杂工程项目里，需要被工程化的对象不是“让模型更快更多的代码”，而是“让系统只能沿着正确的 architecture、authority 和 contract 推进和实现”。 一旦这个前提不成立，vibe coding 的生产力越高，架构漂移就会越快。

这个项目后面之所以能逐步收敛，不是因为又修掉了几个零散 bug，而是因为围绕架构设计和框架规范，先后做了三次根因修复。它们表面上对应的是三类不同问题：orchestrator 变厚与 helper / adapter 膨胀、SoT 与状态语义混乱、前端 fallback 与并列答案来源的消费；但往下进行剖析，需要被本质修复的并不是三个彼此独立的局部问题，而是同一类框架约束不稳，模块边界不清晰在不同架构层次上的共性问题。也正因为如此，这三次修复虽然发生在持续推进的过程里，却更适合被理解成一次沿着架构层次不断逼近根因的纠偏：从宿主归属与职责边界，一直追到语义归属与authority contract(不同模块之间的权威对接contract，如果这个定义不清晰，vibe coding经常会倾向于扩展动态添加，导致contract分散和偏移)，再追到“哪个对象回答哪个问题、哪些接口只是用于映射、前端是否还能 fallback/merge”这组后端 contract。放在本文的语境里，它们也让 harness 在 vibe coding 场景里的承重点一步步显现了出来。

要看清这三次根因修复到底修了什么，还需要先回到这个项目的框架设计上。对这个agent项目而言，harness 顶层只有四层：编排层、控制层、门控层、治理层(上篇文章提到过)。运行时底座(runtime)属于控制层底座，后文会反复出现的几个词，也都建立在同一组核心分工上：shared WM(工作记忆) 承载 live facts 与连续性，控制面承载 runtime SoT，published deliverables（把节点产出固定成后续节点统一消费的正式交接版本，不是另一套 live SoT）作为阶段边界输入，agent-local trajectory 承载 agent 的观察与规划，而 runtime read-model 则是控制面的正式读视图。如果借用更广义的 agent memory system 视角，这里并不是把 memory 从基底位置拿掉，而是把原本容易被笼统归入 memory 的几类对象进一步拆开，使 shared WM 不再越权承担运行控制、边界输入或轨迹语义的宿主职责。支撑能力当然重要，但它们服务主线，不重新定义真值。下面提到的“正式宿主”“SoT”“语义归属”“权威对象”和 authority contract，都要是从这套基线出发去理解的

如果把这套参照系压缩成一张图，大致如下：

Single-Episode Harness

在 harness 外

在 harness 外

仅 agent 本地保留

编排层Orchestrator / ExecutionIntent

控制层workflow_session / node / attempt / gate / decision

门控层GateResult / decision input

治理层contract / diagnostics / quality gates

支撑能力Context/Contract Assemblerpublished deliverable projection / adapter

runtime substrate控制层底座

project wrapper复用 single-episode engine

external scheduler启动 / 排队 / worker bootstrap

runtime read-model

frontend read-model consumers

业务事实workflow_state / shared memory facts

阶段边界输入 / published deliverablesExecutionContract / runtime carrier

agent 本地轨迹local observation / trace

编排层依赖这些对象推进主线，但不把它们揉成一个含混的大对象；控制层推进运行态，门控层处理边界决策，治理层负责契约与诊断，runtime read-model 则只承担控制面的正式读职责，不升级成第二套状态机。上面提到的三类问题，看上去像三类零散问题，往下追溯可以收敛到更高一层的架构约束上，先是宿主归属与职责边界，然后是语义归属与权威对象，最后是 authority contract 与消费边界。后面这三次根因修复，展开的也就是这个过程。

第一阶段：从表层症状转向宿主归属诊断

第一轮深挖时，实际上可以这样描述和定位存在的问题：“orchestrator 太厚”“adapter 太多”“兼容缝还在主路里”。这些判断都没有错，但它们还停留在表层。真正让问题开始变清楚的，是我们第一次不再把这些现象当成“代码还需要继续薄化”，而是把它们理解成“职责和正式宿主没有先冻结”的结果。

最典型的例子，是脚本 review 路径上曾经存在的一类混合 helper：同一条调用链里，既发布阶段成果，又回写运行时载荷，还把结果重新投影回工作记忆，最后再打开审核门控。从局部看，这只是把相关逻辑顺手放在了一起，但从架构上看，它已经同时侵占了支撑能力、控制面写入和读取侧投影三类职责。类似的问题也出现在输入装配路径上，本应由统一的支撑能力处理的阶段输入和执行契约组装，实际却仍由编排主循环按 agent 类型分发 builder，导致执行链路分散，一旦报错无法找到统一宿主。

这里并不是说 helper 或 adapter 本身不该存在。跨层桥接、上下文装配、只读投影和兼容过渡，本来就需要辅助能力。真正需要被约束的是它们的边界：可以服务主线，但不能和主线共同定义真值、推进状态或发布边界；一旦开始承担这些职责，它们就不再是辅助工具，而是在侵占正式宿主。

所以对于这类问题，我们不再把它理解成“函数太长”或“层次不够好看”，而是开始追问：这段逻辑到底属于哪一层，它的正式宿主应该是谁，仓库里哪些历史 helper、compat adapter 和 wrapper 仍在充当默认扩展点。也正是在这一轮里，问题第一次从表层症状被翻译成了宿主归属、职责越层和宿主回迁的问题。很多看起来像“重构”的动作，实际做的可能只是布局调整；如果正式宿主没有先被冻结，旧代码的形状就会持续反向定义新实现的落点。

这是vibe coding归因分析或bug溯源很重要的一步，对应模块代码都应该从架构中找到对应的宿主，否则很多问题根本无法找到本质原因。

第二阶段：从“多真值”转向“多类语义对象被混读”

接下来暴露出来的是 SoT 问题。项目文档后来把这件事做了梳理冻结：shared WM 继续承载实时迭代事实，runtime 的 SoT 归输于控制面，已发布交付物作为阶段边界输出，而后续的 SoT clarity 收敛又进一步把 facts SoT、runtime SoT、围绕 published deliverables 的边界输入，以及 agent-local trajectory 显式拆开。也就是说，这个项目真正确认下来的，是多类语义对象的分工，而不是继续让投影多路混读。

解决这类问题的核心在于系统不再用一个粗粒度的 SoT 说法覆盖所有语义，而是聚焦在“当前这类语义到底该落到哪个对象上”。在这个项目里，至少有四类对象需要被明确区分：承载业务事实与交付事实的记忆，承载运行控制的运行时状态，承载边界已发布输入版本的 published deliverables，以及 agent 自己的观察与规划轨迹。问题并不在于这些对象并存，而在于同一种语义开始被不属于同一层的不同路径同时承载。

最典型的例子，是“当前运行态”这类语义。项目文档后续已经把它收回到控制层：runtime/session/node/gate/decision 的 SoT 只允许归控制面，runtime read-model 只是控制面的正式 projection，不允许前端 read-model consumer、summary surface 或兼容投影重新承载当前运行态语义。类似的漂移也出现在阶段边界输入上：下游节点本该读取 published deliverables 这条边界输入，却仍可能从工作记忆投影那里拿到一个能用但并不权威的版本。于是问题不再是“状态有点乱”，而是“同一种语义究竟允许落到哪些对象上”。

这一步非常关键，因为它直接改变了后续的修复思路。项目收敛并不是把所有语义压回一个 store，而是先冻结“语义到对象”的映射：事实与连续性继续由工作记忆承载，运行态语义继续归控制面，runtime read-model 只是在读取侧暴露控制面视图，边界输入版本只由 published deliverables 这条正式发布路径承载，而 agent 轨迹语义则保留为独立对象；它可以被写入记忆、追踪、日志、检查点等工件，但不因此自动升级成工作流事实真值、运行态真值或边界输入。到了这里，第二轮分析完成的已经不是一次对 SoT 的粗粒度归并，而是一次把几类语义对象重新拉回正确位置的收口。

第三阶段：从“前端 fallback 越权”转向“后端权威契约没冻结”

如果说前两轮还主要发生在架构与后端边界上，那么第三轮真正暴露出来的，是消费侧分支背后的契约问题。最开始看上去，这些现象都很像典型的消费侧 fallback / merge 逻辑，前端包括单场景和多场景两个模式，单场景接收后端的状态信息要保留 fallback，多场景某些接口要自己在两套接口之间判断，还会把运行态和中间摘要状态在消费端合并。只看表面，很容易把责任归到消费端“分支太多”。

但继续往下看，问题恰恰相反。前端之所以会写出这些分支，往往不是因为它想重建一套真值逻辑，而是因为后端契约仍在允许同一种语义通过两套接口暴露，允许权威结果有时缺席，或者让非权威路径在缺值时仍继续参与回答。比如 active run 的 runtime endpoint 仍可能返回“session not found”，那前端几乎必然会退回 coarse status；再比如多项目场景同时暴露 editorial/script 状态和 execution/runtime 状态，却没有先把两者拆成稳定 contract，那消费端也几乎一定会开始 merge truth。很多看起来像 UI 临时补丁的问题，本质上都不是前端在“判真值”，而是前端被迫承担了真值路由。

那真正需要先收口的，不是消费端分支本身，而是后端的 authority contract：哪些语义必须由单一权威对象承载，哪些 surface 只是 projection，哪些缺席态根本不应继续出现在权威接口上。只有契约先被冻结，前端那些 fallback、merge 和路由逻辑才有可能被真正删除；否则，任何“让 UI 写得更干净”的努力，都只是把 contract 的缺口换一种方式继续留在系统里。

这一轮之后，三次根因修复连起来才形成了一个更完整的判断：最开始看上去只是表层症状的问题，真正往下追，会先落到宿主归属与职责边界，再落到语义归属与权威对象，最后落到后端 authority contract。走到这里，重构的焦点也已经从局部实现本身，转到了系统如何定义真值、发布边界和推进状态。

把这三次根因修复连起来看，视线就不会再停留在“为什么这里又多了一层 helper”或者“为什么那里又出现了一条 fallback”上，而会自然转向另一个问题：为什么同一类偏差会在持续使用 coding agent 的过程中反复出现，并且越来越容易沿着相似方向扩散。也就是说，问题已经不只是怎么纠偏，而是为什么 vibe coding 会系统性地放大这种失配。

前面这三次根因修复说明，问题并不是零散 bug 的堆积，而是一类会沿着固定方向不断扩散的工程失配。接下来我们来深入分析，这种失配为什么会在 vibe coding 环境里放大得这么快。多次实践下来得出的结论是，coding agent的默认优化目标与架构收敛需要的动作，天然不是同一个方向。

首先，现阶段LLM 更擅长沿着局部上下文寻找一条最容易完成当前任务的路径，而不是主动追求全局架构最优。对模型来说，最自然的动作通常是“在已有扩展点上继续长逻辑”：包一层 helper，加一层 adapter，保留一层 fallback，把旧路径继续接到新路径上。这类动作局部风险小、改动面集中、回归容易通过，也最符合当前上下文里“什么东西看起来最像可用宿主”。相反，架构收敛真正需要的动作往往是回迁 ownership、删除旧 reader、合并 contract、引入 breaking change、让兼容层退出主路径。这些动作对局部实现来说更难，对 agent 来说也更不符合默认的最小阻力策略。

其次，代码库里既有的实现本身会变成一种架构先验(architecture prior)。只要历史 helper、兼容 adapter、summary surface、legacy wrapper 仍然没有清理干净，它们会被agent认为“可以继续挂逻辑的合法位置”，后续的实现仍然会继续基于这个位置做扩展和修改。这也是为什么在agents.md中已经注明正式宿主在哪里，新增逻辑却还是会长到别处去。因为在局部上下文里，agent 看到的不是抽象架构图，而是一堆可调用、可复用、看上去还没完全退役的代码对象。没有被真正退役的过渡层，最终就可能会成为新的默认宿主。

另外由于当前模型RL训练限制，无法批量实现复杂代码项目这种长时运行的rollout训练，大多数agent的review仍然会系统性奖励局部成功，而不是架构和长时交付正确性。只要功能实现了、测试过了、回归没有炸，一条落错宿主的逻辑就会显得“足够好”。这在手写开发时代已经是常见问题，在 agent 参与之后会被放大，因为 agent 正是在不断追求这种“局部上看起来足够好”的实现路径，放在训练中可以理解为获得可验证的奖励。只要评审顺序还是 works -> tests -> cleanup later，而不是 belongs -> authority -> contract -> behavior，系统就扔就会产生更多旁路。

还有一个经常被低估的因素，是兼容层的吸附作用。代码中遗留的兼容层只要不被持续压缩，就会开始吸附新逻辑。一开始它可能只是一个投影桥，一个老接口的 wrapper，一个过渡适配器；但很快在用vibe coding实现推进的过程中，就会出现这些情况：从中读取多个状态，为了兼容新的调用方再往里加一个字段，为了解决某个 consumer 的问题再加一个 fallback。等到下一轮重构开始，这层兼容层已经不再只是过渡路径，而是一条语义上并列的主路。

最后，optional authority 往往比完全没有 authority 更危险。如果一个接口明确没有 runtime truth，问题反而清楚；但如果它“理论上有权威载荷，只是有时候没有”，前端几乎一定会补上一层合并和兜底：有 runtime 就用 runtime，没有就回退到别的状态字段；有 workflow_status 就立刻更新，没有就继续 refresh；同时满足 task 和 workflow_status 才承认当前 run 存在。写成代码时，这些分支看起来只是普通的空值判断或 fallback；放回架构里看，它们其实是在让前端替后端决定“哪个对象才算权威结果”。到了这一步，再去关注前端“为什么添加了各种fallback逻辑”，已经没有意义，因为 contract 本身就在把 authority-routing 下放给消费侧。

把这些因素串起来，就能看到一种在vibe coding场景下的工程因果链：边界没有冻结，agent 就会沿最省力的路径继续扩展。这些扩展因为局部可用而通过评审；通过评审的局部扩展又会反过来成为下一轮实现的默认先例；随着先例增多，系统越来越难区分 canonical host 和兼容宿主，最后连“这段逻辑到底算不算越层”都开始变得含糊了。 这也是为什么 vibe coding 环境下的架构漂移往往不是突发失控，而是一种越来越平滑、越来越难在早期被叫停的偏差累积过程。

Mario Zechner 在 2026 年 3 月 25 日的博客《Thoughts on slowing the fuck down》也从另一个角度描述了类似机制：当人不再充当实现速度的天然瓶颈时，那些原本零散、可局部修补的小错误会以更高速度累积；而 agentic search 的低 recall 又会进一步放大重复实现、局部绕行和复杂度扩散的问题。[32] 这和我实践碰到的问题基本也是一致的：系统被写散，往往不是因为一次明显失败，而是因为局部偏差在高速度、低全局视野的环境里持续复利。

当然，这并不意味着所有使用 coding agent 的项目都会以相同速度滑向同一种失配。漂移最容易被放大的，通常是那类同时具备四个条件的系统：任务跨 session 或至少跨多个明显阶段；同一业务问题会被运行态、摘要、投影和前端 helper 等多个路径读取；存在仍未退役的兼容层；以及消费端为了保住可用性而被迫自己做真值路由。vibe coding 本身不是问题，但由于推进太快，review和约束不够，你的项目就很可能在一个边界尚未冻结、长出多个旁路逻辑的迭代系统中越走越偏了。

把这个项目的经验放到过去一年到现在的社区agent 实践里看，会发现它并不是一个孤例。随着模型能力提升，coding agent 被推向了更长链路、更复杂、也更接近真实工程的任务；与此同时，原本分散在上下文管理、工具设计、执行环境、handoff 和 eval 里的约束，也开始更频繁地被放到同一层面上讨论。尤其从 2025 年底到 2026 年，公开实践里关于 harness 的讨论明显升温。不同来源虽然语境不同，但讨论最后往往都会落到相近的一组工程约束上：长时运行自动化、执行环境、handoff、evals、边界与权威归属等侧重于保障agent稳定运行的工程化实施。

Anthropic、OpenAI、Hermes、OpenDEV等研究实践所强调的问题虽然落点不同，但都在研究同一类工程难题：如何把 boundary、handoff、evaluation、execution environment 和 authority discipline 组织成一个长期可运行的执行外壳。但这也并不意味着社区已经形成了一套完全一致的理论，而是说明随着 agent 被用于更复杂的工程项目，harness 相关的约束正在从局部实现问题变成显性问题。放回本文的语境里，这也是为什么这个项目里看似分散的宿主、边界、fallback 和 eval 问题，最后会不断收束到同一类工程问题上。

Anthropic 关于 long-running harness 和 evals 的几篇文章，直接回答了“为什么不应停留在 prompt engineering”这个问题。《Effective harnesses for long-running agents》非常明确地指出：仅有 compaction 不足以支撑长程软件工程任务，真正有效的办法是为 agent 准备清晰的环境工件、增量进展机制和 clean-state discipline。[3] 而 Anthropic 在 2026 年 3 月 24 日发布的工程文章《Harness design for long-running application development》又把这个判断向前推了一步：它明确区分了 compaction 和 context reset + structured handoff，指出后者能给 agent 一个真正的 clean slate；同时把 self-evaluation 失真、独立 evaluator、以及 planner / generator / evaluator 三角色和 sprint contract 这种阶段协商机制，一并纳入 harness 设计本身。[27]

《Demystifying evals for AI agents》则把评估对象从“模型输出”升级成了“agent 在环境里的完整行为”，包括 transcript、tool calls、trial、grader、capability eval 和 regression eval。[4] 。对应去前面提到的问题，我们也可以归纳为在 agent 系统里，评估的对象不应该只是“最后功能有没有实现”，而必须包括“它是否走了正确的 authoritative surface”“是否制造了 dual-surface contract”“是否把 truth routing 推给了 consumer”。否则，系统就会在功能正确但架构持续恶化的轨道上越走越远。

OpenAI 的《Harness engineering: leveraging Codex in an agent-first world》则把更深入的阐明框架约束的价值，agent在边界清晰、结构可预测的环境中效率最高，光有设计文档还不够，必须把架构边界和工程偏好编码成可机械执行的约束。[30] 他们把业务域切成固定层次，限制依赖方向和允许的跨层边，把这些规则写进 custom lints 和 structural tests；就连 structured logging、schema/type 命名、文件大小和平台可靠性要求，也都被做成了带 remediation 指令的 lint 规则，直接回注到 agent 上下文里。[30] 这和上面提到的架构设计约束里面也不谋而合：对于 coding agent，架构不是留给人类心领神会的“**实践”，而必须被做成 agent 可见、可判定、可持续执行的外部约束。

如果把视角再往研究侧推进一点，最近也已经出现了更直接把 harness 当作 coding agent 核心对象的工作。OpenDev 论文《Building Effective AI Coding Agents for the Terminal》把终端原生 agent 的 scaffolding、harness、上下文工程、跨 session 记忆和严格安全控制放进了同一个设计问题里来讨论。[28] 框架仍然是 work in progress，不能替代前面那些更稳定的工程来源，但它释放了一个值得注意的信号：在 coding agent 语境里，harness 已经不再只是工程团队内部的经验词汇，而开始成为可以被单独命名、单独分析的研究对象。另一篇更新的论文《Natural-Language Agent Harnesses》则把这个方向又往前推了一步，提出agent harness 的高层控制逻辑不应继续埋在 controller code 和 runtime-specific conventions 里，而应被外化成一种可移植、可检视、可执行的 artifact。[29] 他们用自然语言来表达 harness 行为，再用共享运行时去执行这些 harness，并在 coding 与 computer-use benchmark 上评估其可运行性、模块消融和 code-to-text harness migration。[29] 把 harness 从“实现细节”提升成了一个可以跨系统迁移、比较和研究的独立对象。

如果把视角从官方文章再往开源社区推进一步，可以看到不同项目正在把 harness 的不同面做成显式、可复用的工程对象。

langchain-ai/deepagents 把 harness 原语做成了一个独立可安装的库。GitHub README 直接把它定义成 “the batteries-included agent harness”，官方 docs 则把 planning、file systems、subagent-spawning、long-term memory，以及 LangGraph runtime 提供的 durable execution、streaming 和 human-in-the-loop 摆成同一组 core capabilities。[17][18] 更具体一点，deepagents 内建 write_todos 来显式外化任务分解与进度追踪；虚拟文件系统支持 in-memory state、local disk、LangGraph store、sandbox 和 local shell 等多种 backend，并允许把不同路径路由到不同存储或执行环境里。[18][19] 它的意义不在于某一项能力有多新，而在于 planning、context management、subagent、checkpoint 这些原本散落在不同项目里的 harness 原语，开始被打包成可以直接复用的独立组件。

OpenHands 把 software agent 把执行环境、控制回路和评估接口一起纳入了核心架构。官方文档明确把 runtime、sandbox / workspace abstraction、controller loop、state、security 和 evaluation harness 都当作 SDK 的核心对象来描述；评估文档则直接把 benchmark 集成、runtime 初始化、controller 运行、状态返回和历史轨迹导出纳入同一套开发接口。[20][21][22][23] 它继承了 SWE-agent 提出的 ACI（Agent-Computer Interface）概念-agent 与计算机环境的交互界面本身需要被设计,并在此基础上进一步把 sandbox 隔离、执行观察回路和评估基础设施做成了框架的一级公民。OpenHands 说明对于 software agent，真正需要工程化的绝不只是 prompt 或 tool list，而是"模型如何在受控环境里执行、观察、被评估和被约束"这个完整回路。

Meta-Harness 则把这个方向又往前推了一层：它不再把 harness 当成手工维护的外围脚手架，而是把 harness code 本身当成可搜索、可量化比较的优化对象。论文指出，在在线文本分类上，Meta-Harness 相比SOTA context management 系统提升了 7.7 个点，同时只用了原来四分之一的 context tokens；在 retrieval-augmented math reasoning 上，自动搜索得到的 harness 在 200 道 IMO-level 问题上，平均又提升了 4.7 个点；在 agentic coding 上，搜索得到的 harness 超过了 TerminalBench-2 上最好的手工 baseline。[24] 公开 的artifact 则给出了一个很具体的 coding sample：在 agent loop 启动前自动收集 sandbox 环境快照，包括工作目录、文件列表、可用语言/工具、包管理器和内存，再注入初始 prompt，以节省 agent 通常花在环境探索上的 2-5 个早期 turn；README 报告的当前结果是 Terminal-Bench 2.0 上 76.4%（89 tasks × 5 trials，Claude Opus 4.6）。[25] 这里最重要的不只是分数，而是 harness 已经被明确当成了可以端到端搜索、实证比较和持续优化的系统变量。

无论是 Anthropic 和 OpenAI 把 harness design 写成明确的工程原则，SWE-agent 把接口质量提升为性能变量，还是 Deep Agents、OpenHands、Meta-Harness 把 harness 做成库、运行时与可优化对象，最后共同显性化的，都是同一层问题：agent 系统的关键已经不再只是模型会不会回答和实现特定功能，而是围绕模型建立起来的那套执行外壳，能不能稳定地定义边界、组织 handoff、约束行为并支撑起验证评估。

前面的公开实践也说明，harness 正在从经验性的脚手架和内部基础设施，变成一层可以被单独命名、复用、评估和优化的工程对象。那Agent Harness与传统软件架构、平台工程到底是什么关系呢？如果不把这个关系说清楚，“agent harness engineering” 很容易被理解成一种把旧问题重新包装的新概念。当系统的执行主体变成“模型 + 工具 + 状态 + 自动化环境 + 人类审批/监控”的复合执行系统后，软件架构定义的边界与质量属性、平台工程提供的自助路径与 guardrails，都需要通过一套面向概率执行者的控制、验证、观测与恢复机制被持续落实出来，这一层就是 harness。

如果把三者放在一起，更有区分力的不是“面向服务的对象是谁”，而是三件事：谁定义约束，约束以什么形式存在，以及这些约束如何在执行中持续生效。

harness 不是悬浮在架构和平台之外的新层，而是两者在 agent 进入主线之后的重新落地方式；而人类治理也没有消失，而是上移到一个负责边界、取舍和责任的层次上。

先看它和传统软件架构的关系。在软件架构领域，一个被广泛接受的判断是：架构关注的是系统中真正重要的结构决策，质量属性和演化成本首先受这些决策支配，而不是受局部代码技巧支配。[13][14] 这套判断在 agent 时代并没有失效，相反变得更重要了。只是“重要的东西”发生了扩展：除了组件边界、接口、依赖方向和质量属性之外，现在还必须包括权威归属、契约、兼容层退出管理、工具边界和只读视图语义。也就是说，agent harness 不是替代架构，而是把原本停留在图纸和代码结构里的架构决策，继续向前推进到“一个概率性执行者如何在这些边界内行动”。

再看它和平台工程的关系。Microsoft 对 platform engineering 的定义很典型：它强调 product mindset、self-service、governed framework、golden paths 和降低开发者认知负担。[15][16] 这一点和 harness 有很强的相似性，因为 harness 同样在做 paved path，同样强调 guardrails、接口、一致体验和反馈回路。现在的讨论平台工程，会开始把 agent 纳入消费者范围，但其实不在于服务对象里有没有 agent，而在于它们对执行者能力的默认假设不同。平台工程通常假设执行者具备持续的记忆和判断力：开发者读过文档、模板和 paved path 之后，能够在较长周期里持续遵守；做错了，系统通过接口约束、CI policy 或 guardrails 报错。Harness 不能做这个假设。它之所以必须在每一步重新注入边界信息、把进展外化成工件、把 handoff 结构化、并把验证外置到 runtime、evaluator 和 reviewer 这一侧，根因正是 agent 不具备可依赖的持续记忆。平台工程关心的是让开发者在 guardrails 内高效自助，harness 工程关心的是让一个不完全可预测的执行者在 guardrails 内持续不偏航。

更进一步理解，把 harness 看成架构与平台在 agent 进入主线之后的执行期落地：架构决定哪些边界重要，平台把常见能力产品化，而 harness 确保这些边界、路径和验证在长链执行中持续对 agent 生效。没有架构，harness 会失去边界依据；没有平台思维，harness 会退化成一堆零散脚本；而没有 harness，架构和平台在 agent 进入主线之后，也无法保证这些约束在 agent 的长链执行中持续成立并发挥应有作用。

以前面提到的项目为例，这个项目并不缺“架构设计”，也不完全缺少“平台式能力”，例如记忆与连续性、上下文装配、运行时状态、投影视图、前端 helper、交接工件这些东西其实都以某种形式存在。真正缺失的是：把这些对象重新组织成一套会在执行期持续重申边界、把进展外化成工件、并用外部验证替代执行者自检的约束体系。结果就是：架构边界存在，但不会自动阻止编排主线越层；平台式工具存在，但不会自动阻止消费侧自行合并同一语义的多个结果；状态对象存在，但不会自动回答“哪个对象才有权回答这个问题”。也正因为如此，harness 必须被单独拎出来，而不能被混同为“更好的架构”或“更好的平台”。

基于这个项目里的几轮收敛经验，以及前面提到的公开实践，暂且把这一类承重工程工作收束为 agent harness engineering。这里的 harness 不是“某个 SDK 的外壳”，也不是“一个帮模型调工具的 runtime”，而是一组共同约束 agent 增量实现方向的工程机制。它至少包含六个层面：第一，冻结正式架构边界，明确哪些职责属于编排、控制、边界发布与治理；第二，冻结 authority matrix，定义每类语义由哪个 authoritative object 承载；第三，冻结宿主归属，明确每类逻辑该落在哪个模块或能力层；第四，冻结 contract discipline，避免 dual-surface、optional authority 与 consumer-side truth merge；第五，管理 transition lifetime，确保 compatibility seam 有生命周期、而不是永久并列；第六，构建 eval harness，把“行为是否仍在正确轨道上”变成可验证对象。

这里也要避免把 harness 理解成“一次性全量建设一整套大平台”。对窄任务、短流程、低状态耦合的场景，这六个层面可以很轻，甚至有些只需要以明确约定和少量测试的形式存在；并不是所有团队都要立刻把它们产品化成显眼的基础设施。harness 真正变成承重结构，通常发生在系统已经开始出现多阶段边界、多类 consumer、可恢复执行、长期兼容债务和回归治理压力的时候。之所以把六个层面完整展开，不是因为它们在任何项目里都必须一样重，而是因为在这个案例里，它们已经全部变成了 load-bearing 问题。

这六个层面之所以值得单独列出来，是因为它们对应了这个项目里暴露过的工程缺口。正式架构边界没有在执行层生效，于是负责编排的主线会继续把状态推进、边界发布和输入路由都揽到自己身上；authority matrix 没冻结，于是 live status、boundary input 和 coarse summary 会同时承载同一类本应唯一的语义；宿主归属没冻结，于是 helper 和 adapter 会被默认当作扩展点；contract discipline 不够硬，于是前端必须处理 dual-surface 和 optional authority；transition lifetime 没被严肃管理，于是兼容桥会从短期债务长成并列主路；eval harness 不够强，于是系统只能知道“功能大概还能跑”，却不知道它是不是又沿着错误的 surface 生长了一层。也正因为如此，harness 不是附属优化，而是在 agent 进入主线之后，原本分散的问题被重新组织成的一套主问题。

Anthropic 在 2026 年 3 月 25 日介绍 Claude Code auto mode 时，出发点不是再谈一遍 agent 的抽象能力，而是一个很工程化的现实问题：Claude Code 用户实际上会接受大约 93% 的权限提示，长期下来，人工审批本身会滑向 approval fatigue。[31] 它给出的也不是“取消审批”，而是在人工审批与完全跳过权限之间插入一层自动化风险门控：工具结果进入主 agent 上下文前，先经过输入侧的 prompt-injection probe；真正越过安全 allow rules、具有真实副作用或授权歧义的动作，再交给输出侧的 transcript classifier 审查；subagent handoff 在任务委派和结果回传两个阶段分别接受检查；动作被拒后，session 默认也不是直接中断，而是通过 deny-and-continue 将拒绝结果返回给 agent，让它在既定边界内继续寻找更安全的执行路径。[31]

这套关系可以用一张简单的图来表示：

Product / User Problem

Canonical Architecture

Authority Matrixquestion -> authoritative object

Host Ownership Ruleslayer -> host -> contract

Agent Harness

Model

Tools / ACI

Context & Contract Assembly

Execution Environment

Guardrails

Progress Artifacts

Transition Retirement

Read Models / APIs

Consumers

Evals

Capability

Regression

Transcript / Contract Checks

agent 从来不应该直接对着一团模糊的代码库自由生长，而应该被放进 architecture、authority 和 contract 先于实现被冻结的环境里。 如果这个顺序反过来，agent 生成的每一次增量改动都可能变成新的语义噪音。

经历了这轮项目实践之后，也进行了相关Harness应用的经验总结，但也不是类似这样的建议-“以后别乱加 adapter”，这种表达虽然是正确的，但面向的思路错了，Harness 也不是靠零散规则一条条叠出来的。更有用的做法，是把这些经验沉淀为可以在实现前、评审中和收尾后持续发挥作用的实操指引、检查点与 handoff 工件，并在合适的场景下进一步封装成可复用的 skill、模板或治理能力也正是在这个过程中，人的角色开始发生变化：你不再只是执行者，而转向负责编排、引导、监督与治理的管理者。

最容易意识到但实践又容易忘记的一个点：窗口并不是免费的。 很多人会下意识地把一个对话窗口当成可以不断追加任务的无限工作台，仿佛只要上下文还没装满，就应该继续往里塞更多问题；但复杂工程任务并不是这样推进的。人做复杂工作时，不会指望在几个小时里同时解决所有相互牵连的问题，而是会把任务拆成难度适宜、边界清楚的阶段，一天只啃下当天能真正收口的一块。agent 其实也类似。一个窗口里同时堆入过多目标、过多未决判断和过多历史岔路，效果往往不是“连续推进”，而是把局部问题、旧结论和临时路径一起压成新的上下文噪音。即使 coding agent 会自动做 compaction，这也不等于窗口可以无限续命；在复杂任务里，多轮 compaction 往往会把细粒度约束、局部边界和未收口分歧不断压平，系统表面上还在延续，实际判断质量却会逐步变钝。因此更有效的方法，是让一个窗口只承载一件已经拆好的阶段性任务：做完就总结，留下显式痕迹，写入记忆或 handoff artifact，再在新窗口继续下一段。表面看这像是在增加切换成本，实质上却是在用阶段边界换取判断质量、用外部工件换取长期连续性。这既是一种更符合人类处理复杂问题的工作方法，也正是 harness 思想在日常工程里的具体体现。

在这套方法里，还有一个在老项目阶段性治理中非常有效的实践：session handoff 不是一个文书动作，而是一种长程 harness primitive。 特别是在重构、治理、架构收口问题很多的老项目里，把工作切成阶段，每一阶段结束时强制产出 handoff，再在新窗口继续下一阶段，乍看上去会增加窗口数和交接成本，但实际效果往往恰恰相反。因为 handoff 会迫使团队把当前阶段已经确认的 authority boundary、已退役的路径、仍受控的过渡态、下一步的真正目标和禁止重开的议题写成显式工件。这个过程会显著降低下一轮实现继续沿着旧偏差扩张的概率。

这件事的价值，不只是“方便续上下文”。真正重要的是，它把阶段性重构从一种连续但模糊的探索，变成了一系列有边界、有验收、有重启入口的局部问题。Anthropic 在 long-running harness 的文章里强调，长程任务真正需要的不是无限延长上下文，而是能帮助后续轮次继续推进的环境工件与进展记录。[3] 在 2026 年 3 月 24 日那篇关于 long-running application development harness 的工程文章里，他们甚至更进一步地区分了 compaction 与 context reset + structured handoff：前者保留连续性，但未必能摆脱上下文焦虑；后者虽然增加了 orchestration 开销，却能通过明确 handoff artifact 让下一轮在 clean slate 上继续工作。[27] session handoff 在工程里的价值正是如此：它不是为了保留聊天记录，而是为了把“这一阶段已经冻结的判断”从模型上下文里抽离出来，变成下一轮必须遵守的操作约束。在这个项目里，这些 handoff artifact 不是泛泛总结，而是会明确写出哪些 summary surface 已经退役、哪些 compatibility bridge 只能保持 diagnostics-only、哪些问题下一窗口禁止重开，从而把“不要再滑回旧解释路径”这件事真正落到操作层。

这也引出了另一个很值得认真对待的变化：程序员的角色正在部分地从 implementer 迁移为 orchestrator，而且更准确地说，是 governance-oriented orchestrator。 在当前阶段，很多本该由系统自动完成的动作，仍然需要人来做：决定当前阶段的边界，判断哪些问题已经收口、哪些只是被兼容层掩盖，确认哪个问题应该先由后端 contract 解决、哪个问题才轮到 consumer cleanup，以及何时应该开新窗口而不是在旧上下文里继续堆实现。换句话说，人暂时在承担一部分 orchestration 与 governance 的工作，而 agent 更像是在被严格限定边界后的执行者。

这种角色定位预示着下一步值得自动化的对象，不只是“继续让 agent 写更多代码”，而是让系统逐步接管 phase planning、state handoff、artifact audit 和 scope guard 这些 orchestration 行为。到那个时候，人不会从回路里消失，而是更接近一个 governance-oriented orchestrator：不再手工搬运大量上下文，而是负责冻结边界、批准 breaking change、处理跨阶段 trade-off、审视评估结果，并对整个系统的架构方向负责。OpenAI 在 2026 年 2 月关于 harness engineering 的工程文章里，也给出了比较接近我们观点的描述：当 agent 成为主要执行者后，工程团队的重心会从直接写代码转向设计环境、指定意图、建设反馈回路，并把 repository-local knowledge、plans 和 enforcement 机制做成 agent 可消费的工作系统。[30] 换句话说，程序员并不是被 agent 替代，而是在向更高层的 orchestration 与 governance 位置上移。

传统程序员直接实现者

过渡态的人类 orchestrator分阶段推进、做 handoff、控 scope

governance-oriented orchestrator冻结边界、批准变更、审视评估

更多 orchestration 自动化phase planning、handoff、artifact audit

主要工作:写实现、连调用、局部调试

主要工作:切阶段、做 handoff、判断先后顺序

主要工作:定义 authority、批准 breaking change、看收敛质量

系统接管:状态整理、上下文续接、范围守卫、例行审计

从角色变化的角度来看，orchestration 这件事本身正在被重新分层。短期内，人还要承担大量 orchestration 负担；中期，系统会逐步自动化其中可重复、可结构化的部分；长期，人更像在治理层上工作，负责那些仍然需要判断、取舍与责任归属的事情。这个变化和前面的判断是一致的：当 agent 成为执行主体后，真正被重新定义的，不只是实现流程，而是整个工程系统里的职责分布。

如果要让这些方法真正进入日常使用coding agent场景，它们最终会落在四个基本研发工程节点上：计划、评审、handoff 和验收。计划阶段要先冻结业务问题、authoritative object 与宿主归属；评审阶段要先看 belongs、authority 和 contract，再看 behavior；handoff 阶段要把已退役路径、受控过渡态和下一窗口禁止重开的议题写成显式 artifact；验收阶段则不能只问“功能是不是通了”，还要问“它是不是沿着正确的 surface 和 contract 通的”。只有当这四个节点都被 harness 化，前面那些原则才不会重新退化成“大家都知道，但下一轮还是容易忘”的口头共识。

从这个意义上说，下面这些实践积累总结的规则并不只是“写给 agent 的提示词补丁”，而是把前文描述的harness诊断修复过程压缩成相关实践方法论：平时vibe coding的过程中究竟要在什么时刻问什么问题，才不至于在实现速度上升之后，权威归属、契约和宿主归属又重新滑回局部惯性主导的状态。

第一条规则：修复或重构逻辑实现前，先回答三个问题。 这段逻辑承载的到底是哪类语义？它位于架构的哪一层？它的正式宿主是谁？如果其中任何一个问题答不出来，就不应该让agent开始写代码。因为在agent项目里，很难修正的不是模型输出错误，而是团队在“这类语义到底该落在哪个权威对象上”这个层面已经模糊，却仍然允许实现继续推进。

第二条规则：新增 adapter、helper、bridge 或 fallback，必须附带 retirement plan。 这不是****，而是为了防止每一个过渡态都变成新的永久宿主。调用方是谁，什么条件下退出主路径，如果退不掉是否必须降级成仅保留诊断，这些都应该在新增之初就被说清楚。没有退役计划的兼容层，本质上就是尚未承认的长期架构债务。

第三条规则：评审顺序应该从 belongs -> authority -> contract -> behavior 开始，而不是从“能不能跑”开始。 功能正确当然重要，但在复杂工程系统里，它已经不是第一优先级。真正应优先确认的是：这段逻辑是不是写在正确宿主上，它承载的是权威语义还是投影语义，它是否让同一种语义通过两套接口暴露，是否让权威结果处于有时缺席的状态。只有这些都成立后，才轮到行为正确性。否则，评审机制会持续奖励“功能通了但边界更乱”的改动。

第四条规则：消费侧 fallback 默认视为架构债务，而不是 UX 优化。 只要前端或其他下游开始自己合并真值、推断权威对象、决定终止状态，后端契约通常就已经失败了。体验层当然可以有展示策略，也可以在契约明确降级为粗粒度提示的前提下承担有限兜底，但它不应承担真值判断。这一点在上文第三轮分析重点提到过，所有看起来“只是前端保守一点”的分支，最后大概率都指向了后端权威对象契约没有冻结。

第五条规则是：用阶段顺序防止“边修边歪”。 从这次项目经验看，比较稳的顺序不是一边看到哪儿乱就一边清哪儿，而是先冻结职责归属，再冻结 authority contract，再让正式宿主落位，然后让兼容层退出主路径，接着删除消费侧 fallback，最后再去清理旁路 wrapper 和语义噪音。

冻结职责归属

冻结 authority contract

让正式宿主落位

让兼容层退出主路径

删除消费侧 fallback

清理 wrapper 与残留路径

顺序之所以重要，是因为很多看起来像“后期清理”的问题，其实依赖前面的问题先收口。如果 authority contract 还没有冻结，就过早进入 wrapper / noise cleanup，最后很容易只是在外围做看似正确的减法，而把真正的 contract偏差继续留在主线中。

这五条规则如果要再往上抽一层，其实都在做同一件事：把“实现是否正确”之前的那些问题先显式化。谁定义这类真值，谁有权产生这个状态，谁只是过渡桥，谁应该先退役，谁负责把阶段结论交接到下一轮。这些问题在非vieb coding项目里也存在，只是常常被分散在架构图、代码 review 和工程经验判断里；而在coding agent 深度参与项目构建之后，它们不能再停留在默契里，而必须前置成显式的执行约束、检查点和交接工件，否则系统会用更快的速度把原本还能靠默契维持的边界再次冲散。

写到这里，我对“下一阶段的 AI 编程工程学”有了一些初步认识，coding agent落地使用产生差距的 ，不会只是更早把 coding agent 接进研发流程，也不会只是用哪个模型，哪种模式可以快速构建出项目。真正拉开差距的，是更早意识到：在coding agent 参与之后，软件工程的关键对象已经从“单次实现”迁移到了“长期保持系统边界，权责，功能稳定运行的 harness”。 这是由agent背后的概率统计，软件工程的复杂性，自动化和可验证的需求综合决定的。

这也是为什么“vibe coding”这个词本身已经不够了。它很好地描述了交互体验：即时、流动、带着探索感；但它描述不了生产级系统真正脆弱的地方。生产系统会出问题，不是因为模型第一次输出里多写了一个 helper，而是因为vibe coding的过程中没有把正式架构、问题到对象的映射、契约约束、兼容层退出管理，没有把评估和验证变成长期存在的工程制度。只要这些制度不存在，vibe coding 的效率越高，整个系统的失控速度反而会越快。

当然，“harness”本身也不应该被理解成某种新神话。它不会自动消除复杂性，也不会让系统从此不再出现错误宿主、错误契约或错误判断。它真正改变的是vibe coding容易导致的失败的形状：原本那些会以 helper 增殖、消费侧自行合并结果、兼容桥吸附和消费侧兜底的方式慢慢堆积的偏差，会更早地暴露成可命名、可审计、可回退的工程问题。对需要长期运营的系统来说，这种变化已经足够重要，因为它把“越来越难解释的失控”改写成了“仍然复杂，但同时以收敛”的更可控状态。

3 月 31 日的 Claude Code source map 暴露事件，把一个成熟工业级 coding agent 背后的部分工程实现突然暴露到了外部视野里。[40] 虽然这是由打包/发布失误引发的源码暴露事件，但对我们来说，也意外提供了一次学习 顶级agent如何在工程实践中使用harness的机会。结合对这批源码快照的初步拆解，可以看到几类关键 harness 机制同时在项目中进行了使用：上下文组织与压缩、权限门控、subagent 隔离，以及通过 hooks 等外部控制面把约束持续带回执行过程。也可以更加确信Claude Code的领先不只来自模型能力，也来自治理层与外部控制面的工程化harness的设计和实现。

一旦 harness 足够扎实去支撑，agent 带来的就不再只是“更快写代码”，而是“更快把系统推向正确结构”。那时，coding agent 就不再只是屎山放大器，而开始成为架构收敛机。而人类的价值，也会更清楚地从“手工设计实现每一层实现细节”上移到“冻结边界、治理 contract、批准重构方向、审视评估结果”这些更高阶的位置上。当 agent 成为coding 场景的执行主体后，人类正在转向治理为导向的编排者角色，而这个角色的职责之一，就是支撑起这种新分工的 harness。

官方工程文章

[1] Anthropic, Building effective agents, 2024. https://www.anthropic.com/engineering/building-effective-agents

[2] Anthropic, Writing effective tools for agents — with agents, 2025. https://www.anthropic.com/engineering/writing-tools-for-agents

[3] Anthropic, Effective harnesses for long-running agents, 2025. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

[4] Anthropic, Demystifying evals for AI agents, 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

[27] Anthropic, Harness design for long-running application development, 2026. https://www.anthropic.com/engineering/harness-design-long-running-apps

[30] OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026. https://openai.com/index/harness-engineering/

[31] Anthropic, Claude Code auto mode: a safer way to skip permissions, 2026. https://www.anthropic.com/engineering/claude-code-auto-mode

[36] Claude Code Docs, Automate workflows with hooks, 2026. https://code.claude.com/docs/en/hooks-guide

[40] Axios, Anthropic leaked 500,000 lines of its own source code, 2026. https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai

[43] Engineer’s Codex, Diving into Claude Code‘s Source Code Leak, 2026. https://read.engineerscodex.com/p/diving-into-claude-codes-source-code

研究论文与 Benchmark

[6] Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, NeurIPS 2024. Princeton overview: https://collaborate.princeton.edu/en/publications/swe-agent-agent-computer-interfaces-enable-automated-software-eng/

[28] Bui, Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned, arXiv 2026. https://arxiv.org/abs/2603.05344

[29] Pan et al., Natural-Language Agent Harnesses, arXiv 2026. https://arxiv.org/abs/2603.25723

工程博客与架构背景

[9] GitHub, Crafting a better, faster code view, 2023. https://github.blog/engineering/architecture-optimization/crafting-a-better-faster-code-view/

[10] Cloudflare, How we built it: the technology behind Cloudflare Radar 2.0, 2022. https://blog.cloudflare.com/technology-behind-radar2/

[11] Cloudflare, Building Cloudflare on Cloudflare, 2023. https://blog.cloudflare.com/building-cloudflare-on-cloudflare/

[32] Mario Zechner, Thoughts on slowing the fuck down, 2026. https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/

[33] Vivek Trivedy, The Anatomy of an Agent Harness, LangChain Blog, 2026. https://blog.langchain.com/the-anatomy-of-an-agent-harness/

[13] Martin Fowler, Software Architecture Guide, 2019. https://martinfowler.com/architecture/

[14] CMU Software Engineering Institute, Quality Attribute Workshop, 2018. https://resources.sei.cmu.edu/asset_files/FactSheet/2018_010_001_.pdf

[15] Microsoft Learn, What is platform engineering?, 2025. https://learn.microsoft.com/en-us/platform-engineering/what-is-platform-engineering

[16] Microsoft Learn, Self-service with guardrails to empower developers, 2025. https://learn.microsoft.com/th-th/platform-engineering/about/self-service/

开源项目与文档

[17] LangChain, deepagents GitHub repository, 2026. https://github.com/langchain-ai/deepagents

[18] LangChain Docs, Deep Agents overview, 2026. https://docs.langchain.com/oss/python/deepagents/overview

[19] LangChain Docs, Deep Agents backends, 2026. https://docs.langchain.com/oss/python/deepagents/backends

[20] OpenHands, GitHub repository, 2026. https://github.com/All-Hands-AI/OpenHands

[21] OpenHands Docs, Software Agent SDK, 2026. https://docs.openhands.dev/sdk

[22] OpenHands Docs, Runtime Architecture, 2026. https://docs.openhands.dev/usage/architecture/runtime

[23] OpenHands Docs, Evaluation Harness, 2026. https://docs.openhands.dev/openhands/usage/developers/evaluation-harness

[24] Lee et al., Meta-Harness: End-to-End Optimization of Model Harnesses, arXiv 2026. https://arxiv.org/abs/2603.28052

[25] Stanford IRIS Lab, meta-harness-tbench2-artifact GitHub repository, 2026. https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact