自主软件开发这两年讨论很多但大多数工具解决的问题集中在单次任务你给我一个 issue我改完提交 PR你 review 通过就结束。可实际工程项目不是单次任务一个需求从拆解到落地往往要跨好几天一个功能从开发到回归也要经历多次修改。真正难的不是“让 AI 写出一段代码”而是让一个自主开发系统在多日运行、多次修改、多模块变更之后仍然知道自己为什么改、改了什么、哪些改动不能回退、哪些经验能复用到下一个任务。Harness-of-Harness 这个方向就是冲着解决这类问题来的。它核心想做一个比普通 Agent 框架更高的控制层不直接让模型写代码而是管理“写代码的过程”——任务怎么拆、上下文怎么保存、验收怎么执行、失败怎么回退、经验怎么沉淀。这种“框架之上的框架”思路比单个 Agent 堆功能更能贴近真实团队的研发节奏。这篇文章我不准备把这个概念讲成纯学术综述而是按我理解的实际工程落地路径拆一遍为什么需要外层 Harness、多日任务会踩哪些坑、持续改进的闭环该怎么设计、最后怎么判断这套系统是真的在“改进”而不是越跑越乱。1. 多日自主开发难的不是写代码而是让 Agent 在三天后还知道自己为什么改代码先理解为什么“多日”这个词这么关键。短期自主开发任务比如让 Agent 给项目加一个登录接口模型可以在一次上下文中读完相关文件改完代码再跑一遍测试整个过程可能几十分钟到几小时。就算中间出了错重新读一遍代码也就恢复了。但多日任务完全不同。第一天 Agent 创建了一个核心模块第二天它要在这个模块上扩展接口第三天它发现之前的设计有缺陷需要重构第四天又接到一个需求要和这个模块联动。这时候真正需要回答的问题已经不是“这个代码怎么写”而是当前项目结构是什么样的哪些文件是核心依赖哪些是临时补丁前几天的任务遗留了哪些待办、哪些已知风险上一次重构的动机是什么哪些改动是刻意为之哪些只是绕过当时的问题哪些测试必须通过哪些测试已经过时需要更新代码里哪些注释是准确的哪些早就失效了这些信息如果只靠模型在每次任务开始时重新阅读代码基本不可能完整恢复。代码能告诉你看得见的结构但看不到背后已经发生过的决策过程。而工程项目恰恰是决策过程决定代码形态。更麻烦的是上下文窗口。不管模型上下文是 128K 还是 200K项目文件一多代码一长根本塞不进去。就算塞进去了早期文件的内容也会在后续对话中被稀释、被遗忘。一次会话连续干三天模型大概率会把第一天的需求理解偏甚至做出和之前成果矛盾的修改。所以多日自主开发真正的问题不是单次编码能力的强弱而是系统能不能在长时间、多变更、多上下文中保持对项目的整体认知不漂移。Harness-of-Harness 要解决的说白了就是把这种“容易漂移的长期记忆”从模型上下文里抽出来放到一个更结构化的、可写入可读取的系统层里。1.1 为什么单次任务工具跑得好不代表多日任务能跑好单次任务工具成功靠的是模型对单个局部问题的理解能力。你给它一个清晰的任务描述再给它相关文件它完成局部修改的概率比较高。但多日任务本质上是一个序列决策问题每一步的输入都取决于前面步骤的产出每一步的决策又会改变后续任务的状态。举个例子。某天 Agent 为了快速通过测试绕过了某个异常处理分支。这个选择放在当天是对的但两天后另一个任务在这个分支上继续扩展时就会感到设计缺失。如果系统没有记录“当时为什么绕开异常处理”后来者不管是人还是 Agent都会以为这里本来就该这样然后继续堆代码直到问题集中爆发。单次任务里这种“技术债”不容易暴露因为任务结束就结束了。多日任务里技术债会跨任务积累最后变成整个系统不可维护的根源。所以多日自主开发需要的不是更强的编程能力而是一套能把项目状态、决策动机、已知风险、遗留事项结构化落盘的机制。1.2 Harness-of-Harness 想做什么管理“开发过程”的控制层Harness-of-Harness 这个命名挺直白你要开发一个自主软件系统首先得有一个基础 Harness 去承载单个 Agent 的执行比如任务下发、环境运行、测试验证这些能力。但当系统要连续运行多日、完成多个互相依赖的任务时单个 Harness 就不够了需要在它之上再套一层去管理这些 Agent 的执行节奏、上下文状态、验收标准和经验沉淀。这层更高层的 Harness就是题目里说的 Harness-of-Harness。你可以把它理解成“带教老师”的角色。基础 Agent 是具体干活的工程师而外层 Harness 负责安排活、检查质量、复盘问题、记录经验。它不直接写代码但决定代码以什么顺序被写出来以及在写出来之后如何被验证、如何被记录。它的核心能力是四件事任务管理、状态保存、质量验收、经验回存。这四件事如果能稳定跑起来多日开发就不再是“一个大 Prompt 包办全程”而是变成一个每天循环迭代的工程流程规划任务、执行任务、验证结果、复盘问题、更新知识库、进入下一天。这也是这篇文章后续要展开的主线。2. 多日自主开发真正会踩的五个坑比参数调错更隐蔽在讨论怎么搭 Harness-of-Harness 之前先看清多日自主开发容易在哪些地方翻车。这些问题不是偶发故障而是长期运行的系统里必然出现的结构性风险。2.1 上下文漂移模型对项目结构的理解会逐渐失真上下文漂移是第一个坑也是最隐蔽的。Agent 在第一天对项目结构有清晰的认知知道src/core是核心模块、scripts/是工具脚本、tests/是验证目录。但到了第三天项目里新增了十几个文件Agent 已经无法在上下文中保留完整目录结构。它会开始凭印象操作可能把新代码放到错误目录可能修改了不该动的公共接口甚至可能把原来的核心模块误判成无关文件。这种漂移不是模型“变笨了”而是上下文容量和项目复杂度之间的矛盾。解决思路不能是“无限加大上下文”那只会提升成本不解决精确性问题。必须让系统在每次任务开始前重新建立准确的“项目地图”并在任务结束后把新增变更同步回地图。2.2 任务边界模糊一个需求被拆成了错误的多日任务多日开发必须拆任务。但拆任务的粒度一旦不对整个流程都会失控。任务拆得太大Agent 一次处理的信息量超限改到一半自己都理不清改了哪些地方任务拆得太小Agent 频繁切换上下文每天大量时间花在重新理解环境上真正的开发产出很少。更麻烦的是任务之间的依赖。有些任务必须先完成前置改造后续功能才能开始。比如先重构成模块化结构再加新功能先升级数据库版本再迁移业务代码。如果任务队列没有体现这种依赖关系Agent 就会出现“做到一半发现前置条件变了”的情况然后被迫返工。Harness-of-Harness 在任务拆分上的价值不只是把大需求切成小任务而是要在切分时同时记录任务之间的依赖关系、前置条件和预期产出让后续任务启动时能快速判断自己站在什么起点上。2.3 验证缺失或验证滞后代码写完了但没人知道对不对单次任务结束时验证相对简单跑一遍测试看一眼输出判断是否满足需求。多日任务里验证会变得复杂。第一天新增的模块可能在第二天的任务里才被真正调用如果第一天结束时只做了“测试通过”的轻量验证到第二天才发现接口设计有问题返工成本就高了。所以多日自主开发不是“写完代码再统一测试”而是要让每个任务都携带自己的验证清单单元测试是否通过、接口契约是否破坏、关键路径是否有改动、原有功能是否回归。这些验证结果要成为任务状态的组成部分而不是跑完就扔。2.4 资源失控任务跑得越久日志、依赖、中间产物越乱这里说的资源不只是 GPU、CPU还包括磁盘、日志、文件数量和内存占用。一个自主开发系统连续运行几天会在目录里留下大量临时文件、旧版本代码、日志输出、缓存数据。如果 Harness 不管这些项目会越来越臃肿Agent 每次读目录都要花费更多时间而且很容易被旧文件误导。我在实测类似系统时发现一个规律跑单次任务时垃圾文件的影响可以忽略但连续跑过十几次任务之后项目目录里可能堆了几百个文件其中一半是已经废弃的中间产物。系统必须对输出目录、临时文件、日志文件做周期性清理和归档否则越往后速度越慢模型判断越乱。2.5 经验没有沉淀同一种错误第二天又踩了一遍这是最可惜的坑。Agent 第一天解决了一个很棘手的兼容性问题过程很曲折调试花了两小时。但这个解决过程没有被总结成经验只变成了一段代码提交。第二天遇到类似问题时Agent 又从头开始排查完全想不起前一天踩过的坑。如果 Harness 没有经验沉淀机制多日系统和单日系统没有本质区别。Agent 只会“活着”不会“成长”。而 Harness-of-Harness 里最重要的一个词是 Continual Improvement意思是系统要能在多天运行中持续积累项目级知识让后续任务越来越轻松。3. Harness-of-Harness 到底管什么外层控制层与内层工具层的分工理解了多日任务的坑再来看 Harness-of-Harness 怎么通过分层设计去解决这些坑。它不是一个具体的代码库而是一种系统设计模式内层 Harness 管执行外层 Harness 管控过程。3.1 内层 Harness解决“单个任务怎么做”内层 Harness 是多数人已经熟悉的东西Agent 框架本身。它负责把一句话任务变成可执行步骤调用代码解释器、命令行工具、测试框架读取文件生成代码运行验证。它的优势在于单次任务闭环缺点是状态基本不保留任务结束就结束。内层 Harness 的结构一般包含任务输入解析、代码生成模块、执行环境、测试运行器、错误反馈循环。它把“从需求到代码”的过程自动化但不需要管理“多个需求之间的顺序和关联”。3.2 外层 Harness解决“多个任务如何持续推进”外层 Harness 管的不是写代码而是“写代码这件事的全流程”。它需要维护的数据包括项目状态当前目录结构、核心模块清单、关键文件列表、已完成的变更任务队列待办任务、执行中任务、已完成任务、被阻塞任务验证状态每个任务关联的测试结果、验收标准、已知问题经验库已沉淀的项目级注意事项、易错点、常用命令、特殊逻辑说明外层 Harness 还要负责给内层 Harness“喂上下文”。每次内层 Agent 启动时外层 Harness 会打包一份“项目当前状态 本次任务描述 相关历史经验”给模型而不是让模型自己去翻整个仓库。这就像给新接手项目的程序员一份有效的交接文档而不是只丢给他一个代码仓库让他自己看。3.3 为什么需要“Harness 之上再套 Harness”而不是直接改框架有人可能会问这些能力为什么不能直接做进 Agent 框架里非要再套一层原因很实际Agent 框架更新太快今天这个框架有这个功能明天换成另一个框架可能结构完全不同。如果你把项目管理、经验沉淀这些能力耦合在某个具体框架内部换框架的成本会极高。外层 Harness 的价值在于抽象出一个稳定的“开发过程管理层”与具体模型、具体框架解耦。内层换哪个 Agent 框架都可以外层仍然按照统一的节奏做规划、验收、沉淀。这就像团队里换工程师容易但只要项目管理流程稳定项目进度就不会崩。实测体验上这种分层最大的好处是排障清晰。任务失败时能快速判断是内层执行问题还是外层调度问题。如果是代码写错了内层调整如果是上下文丢失或者任务顺序不对外层修复。不用在一个大杂烩系统里到处翻日志。3.4 外层 Harness 需要持久化哪些状态持久化是外层 Harness 的命脉。系统重启、任务中断、网络错误都不能丢失关键状态。至少要有以下几类持久化项目快照每次任务完成后的关键文件清单、目录结构、依赖文件 hash任务历史已执行任务描述、改动摘要、验证结果、失败原因经验记录从任务过程中提取的注意事项、规避过的坑、可复用的方案待办队列尚未执行的任务、被阻塞任务的状态和恢复条件这些数据建议用结构化文件存储比如 JSON、Markdown或者轻量级数据库。不要只依赖模型上下文那是易失记忆。Harness-of-Harness 的核心就是把模型的“工作记忆”转成系统的“长期记忆”。4. 把一天拆成可验证的循环规划、执行、验收、沉淀的四段节奏有了整体架构接下来进入实操。多日自主开发落地最自然的单位是“每天一个循环”。和真实团队每天站会、开发、测试、复盘一样外层 Harness 也可以把每天拆成四个阶段规划、执行、验收、沉淀。4.1 规划阶段先让 Agent 回答“今天我要做什么、为什么做”每天开始时外层 Harness 不应该直接丢一个任务进去。先把当前项目状态读出来生成一段精简摘要包括已完成的模块、待办事项、昨日遗留问题、当前分支或版本状态。然后让 Agent 基于这些信息规划当天的任务顺序。规划结果应该包含三部分任务列表、每项任务的预期产出、任务之间的依赖顺序。这里不要做太重的文档输出只要让 Agent 能明确“今天要完成哪几件事、每件事成功长什么样”。实测时要注意规划阶段的重心是“对齐状态”不是写详细的方案文档。Agent 在规划阶段最常犯的错是计划太多、执行太少。控制在 5 到 10 个任务以内比较合适超过就说明拆分粒度还不够细。4.2 执行阶段每个任务必须带输入、输出和最大耗时限制执行阶段直接调用内层 Agent。但外层 Harness 要给每个任务设定三个要素输入上下文、输出交付物、超时上限。没有这三个要素的任务不能启动。输入上下文来自外层 Harness 组装项目摘要、相关文件路径、历史经验、本次任务说明。输出交付物可以是代码文件、测试报告、分析文档。超时上限用于防止 Agent 在某个任务里无限循环通常在 30 到 120 分钟之间具体看任务复杂度。任务执行时可以给 Agent 一个“可自检循环”写代码、跑测试、看结果、修复、再测试。但循环次数要有限制比如最多迭代 5 轮超过就必须停下来汇报。不要允许 Agent 无限试错那会消耗大量时间且越改越乱。4.3 验收阶段不只看“测试通过”还要看“变更是否可理解”验收是四个阶段里最容易被偷工减料的环节。不少自主开发系统只做“测试跑通过就结束”这在多日任务里远远不够。外层 Harness 验收时应该检查本次变更涉及哪些文件是否有预期外的文件被修改或删除新增代码是否和项目现有风格一致有没有复制粘贴的重复逻辑关键模块的接口是否有破坏性改动如果有是否同步更新了调用方测试用例是否覆盖了本次变更的核心逻辑还是只是跳过失败用例是否产生临时代码、硬编码路径、调试残余等垃圾这些检查不一定要让模型全自动完成可以把“人类 review 点”标记出来由项目负责人确认。多日自主开发不是完全无人化而是让人的介入更少、更有针对性。4.4 沉淀阶段把当天的错误、决策和注意事项写进经验库沉淀阶段是 Continual Improvement 的关键。每天执行完所有任务后外层 Harness 要问两个问题今天遇到了哪些新问题下次遇到类似问题时系统应该怎么做沉淀内容包括避坑记录、项目专属约定、遗留风险、明日建议。这些内容不需要太长但必须具体。比如“本项目测试数据库不能在本地直接启动需要先运行./scripts/init_test_db.sh”这类内容对后续任务极有价值。沉淀阶段的产出物建议写入统一的经验文件比如PROJECT_LOG.md或LESSONS.md。外层 Harness 在后续每个任务组装上下文时把与之相关的经验条目附加上去模型就能少踩很多重复的坑。4.5 一个多日循环的实际时间表参考如果按“一天 8 小时运行”来排一个典型的多日循环可以这样分配规划阶段约 15 到 30 分钟执行阶段约 5 到 6 小时按任务粒度拆成 4 到 8 个任务块验收阶段约 30 到 60 分钟沉淀阶段约 15 到 30 分钟这只是一个参考节奏核心原则是规划不要太长执行要有产出验收不能缺失沉淀不能省略。四个阶段里只要能坚持做到每天都沉淀多日系统的表现就会明显优于单次任务模式。5. 持续改进不是多跑几天而是让系统对项目形成持续积累的认知Harness-of-Harness 这个方向最有价值的部分不是多日运行本身而是“持续改进”。但很多人在落地时会把“持续改进”简单理解成“多跑几轮任务”。这里区别非常大。多跑几轮只是模型反复执行任务每次任务都面临同样的信息不足犯同样的错误。持续改进则要求系统在每一轮之后都变得更懂这个项目更快定位文件、更准确理解代码逻辑、更少重复踩坑、更高效地完成同类变更。5.1 持续改进的载体从“模型记忆”转移到“项目记忆”模型本身的权重在任务过程中不会更新也不能指望大规模微调。持续改进的载体必须落在项目外的结构化记忆上也就是外层 Harness 维护的经验库、项目快照和历史决策记录。每次任务完成后外层 Harness 都要把新的信息写回这些记忆文件。任务开始前再从记忆文件里检索相关部分组装成上下文。这样无论模型是什么版本、上下文多大系统都能站在项目长期积累的基础上工作而不是每次从零开始。这是我个人认为 Harness-of-Harness 最重要的设计思想它把“让 AI 更聪明”的问题变成了“如何积累和复用项目知识”的问题。前者依赖模型能力提升周期长后者可以通过工程手段持续优化见效快。5.2 经验库怎么组织后续任务才能用得上经验库不能写成流水账否则检索时找不到重点。建议按类型拆成几类环境类项目依赖、数据库、外部服务、常用命令的特殊说明代码类模块职责、接口约定、容易误改的地方、设计约束流程类测试规则、构建方式、提交规范、验收标准坑点类常见报错、失败原因、规避方案、WIP 状态提示每条经验尽量写成一两句可执行的话不要写长篇分析。后续任务组装上下文时外层 Harness 根据任务关键词检索相关经验粘贴到 Prompt 中。经验越精准模型误判越少。5.3 用“差分对比”代替“新增堆叠”避免知识库膨胀经验库会随时间增长但增长不等于有效。如果只是不断追加新内容知识库会变得冗长检索成本上升甚至一部分旧经验已经过时仍被引用。所以每轮沉淀阶段还要做“差分对比”哪些经验已经被验证覆盖可以简化哪些经验已经过时需要更新或删除哪些问题重复出现说明之前的经验没有被有效利用哪些模块已经重构旧的经验需要重写这个整理动作每天花不了多少时间但能让经验库长期保持高信噪比。没有差分对比持续改进会退化成“持续的笔记堆积”。5.4 什么时候需要人类介入别把 Harness 当成万能免维护系统多日自主开发可以自动化很多环节但有些决策节点建议保留人类介入权限尤其是这几类大规模重构涉及模块拆分、接口重设计时人工确认变更方向对外契约变更API、数据库结构、第三方依赖升级时人工 pass长期无法解决的阻塞问题Agent 多轮尝试失败后交给人类分析高成本操作大范围安装依赖、自动推送远端、覆盖式改写前人工确认Harness-of-Harness 最合理的使用方式不是让系统完全取代开发人员而是把系统当作一个高速实习生它在执行上很快但重大方向和结构性决策还是需要人类把关。系统做得越好人类介入的次数越少但介入的价值越高。6. 判断系统是否在改进六个可以每天跟踪的工程指标持续改进不能靠感觉判断。要建立可量化的指标每天观察趋势。这里列出六个我认为比较实用的指标不复杂但能反映系统是否在往好的方向走。6.1 无效修改率无效修改率指 Agent 提交的变更中最终被回滚、重写或没有进入最终代码的比例。有效变更率低说明 Agent 对项目理解不够经常改错方向。这个指标可以直接从任务历史中统计每个任务完成后标记“该任务产出是否保留”。6.2 缺陷复发率缺陷复发指同样的错误在后续任务中再次出现。比如某个测试用例第一天修好了第三天又因为类似改动被破坏。复发率高说明经验沉淀没有发挥作用。这个指标能直接暴露系统是否真的在“学习”。6.3 任务平均迭代次数每个任务从启动到验收通过Agent 内部循环了几次。次数越低说明定位问题越准确返工越少。如果这个指标持续下降说明经验库正在产生作用。6.4 上下文组装耗时外层 Harness 在每次任务开始前检索并组装上下文的时间。如果项目状态管理得好、经验库索引清晰组装耗时会保持稳定或下降。如果持续变慢说明项目快照或经验库组织方式需要优化。6.5 代码重构幅度连续多日后看代码结构中“被反复改动”的文件数量。如果系统越来越懂项目改动会集中在正确的位置而不是频繁动公共接口。重构幅度大说明前期设计判断不够准。6.6 人类介入频次最直观的指标——每完成十个任务有多少次需要人类介入修正方向。开始阶段介入次数多正常后面应该逐渐下降。如果介入次数居高不下说明外层 Harness 的任务拆解、上下文组装或验收标准有问题。这一组指标不需要专门做大数据平台每轮任务结束后记录几个字段用表格汇总就能看出趋势。持续改进有没有生效三个月后看这些指标的方向最靠谱。7. 落地建议先别急着跑满多日把单日闭环做稳再说最后聊一下怎么把这个方向落地到自己的项目里。最忌讳的是上来就想跑一个几十小时的全自动多日开发那大概率会在两三个小时后开始失控。我建议按照下面四个阶段逐步推进。7.1 第一步先做单日闭环第一天先不要追求“多日自动运行”先把一个完整的单日循环跑通。具体做法是手动拆好任务清单手动写项目状态文档让 Agent 逐个执行然后手动验收、手动写经验。这时候重点不是效率而是把“任务执行、结果验证、经验记录”这三个环节都稳定下来。7.2 第二步把状态持久化和上下文组装自动化单日闭环跑通后把项目状态、任务队列、经验库做成结构化文件。每次任务启动前写一个脚本或 Agent 流程来自动组装上下文。目标是不需要手动复制粘贴任务描述一进去上下文自动附带历史经验。7.3 第三步加入自主验收和失败回溯有了稳定的上下文组装再给任务增加验收和失败回溯机制。任务执行完自动跑测试测试失败时自动生成错误摘要系统根据错误摘要判断是返回重试、跳过还是标记为阻塞。这里要在 Harness 配置里加上“最大重试次数”和“失败处理策略”。7.4 第四步再扩展多日循环单日闭环稳定之后再让系统自己决定第二天的任务顺序并把当天的经验沉淀自动写回经验库。这一步才算是真正进入“多日自主开发”。前面的准备工作越扎实这一步越不容易翻车。注意多日系统最怕的不是代码写错而是状态丢失之后系统“以为自己还在正确轨道上”。所以每个任务结束后的状态快照必须强制保留这是整个系统最后的保险绳。7.5 小仓库起步先跑一个你自己很懂的 Demo 项目建议用一个小型仓库、你自己完全理解的项目来测试 Harness-of-Harness。原因很简单当系统把项目改乱时你能迅速判断到底是哪一步出了问题而不是在一个陌生代码库里花半天猜来猜去。小仓库也能让上下文组装、经验库、验收规则这些环节先在小规模条件下验证再逐步放到更大的项目上。8. 写在最后的几条实战判断Harness-of-Harness 不是某个具体框架的插件也不是一个可以直接 pip install 的工具它更像是一种工程思路多日自主软件开发要真的跑起来必须把模型能力和项目记忆解耦用外置结构管理过程状态和经验积累。如果你准备在自己的项目里尝试这个方向我个人的建议是不要一开始追求全自动、无人类介入。先让系统完成 70% 的常规工作把剩下 30% 的复杂决策留给人类这是当前阶段最容易获得稳定收益的使用方式。全自动多日开发听起来很吸引人但真实工程环境里的隐藏约束和隐性知识短期内还很难全部靠模型自动理解。持续改进这件事真正的杠杆也不在模型能力而在于系统能不能把每一次任务过程中产生的认知保留下来并在下一次需要时准确调用。谁先把这套“项目记忆系统”做稳定谁就能让多日自主开发从演示型 Demo 变成可长期运行的工程方案。