大家好我是你们的博主。最近在跟进自主软件开发这个方向时发现了一个很值得关注的新框架——Harness-of-Harness。这个框架的核心在于“多日自主软件开发”和“持续改进”这两个词放在一起意味着AI编程不再是单次生成片段而是有能力在长时间、多任务、多轮迭代中稳定工作。今天这篇文章我会围绕Harness-of-Harness的概念、架构逻辑、与现有方案的差异、核心机制拆解、实践思路以及未来挑战展开完整梳理它对自主软件开发范式的影响。无论你是研究AI Agent的开发者还是对智能编程工具感兴趣的工程师相信这篇文章都能给你带来一些新的思考。1. 背景与核心概念1.1 为什么需要 Harness-of-Harness在聊Harness-of-Harness之前我们先回顾一下当前AI辅助软件开发的现状。早期的GitHub Copilot、通义灵码这类工具核心能力是“单点补全”你在IDE里写了一个函数开头它帮你补全后面的逻辑。后来出现了以ChatGPT、Claude为代表的对话式编程模型可以在多轮对话中理解需求并生成整个文件甚至给出修改建议。再到2023年以后AutoGPT、MetaGPT、ChatDev等项目将“AI参与软件开发”推向了更高的层次——它们不再是简单地回答问题而是尝试将任务拆解、逐步执行、循环验证形成一套完整的自动化流程。但是这些已有的方案存在一个明显的瓶颈它们绝大多数是“单轮会话”或“短周期任务”。你给模型一个复杂需求它在一次会话中完成若干步操作后生成一个结果然后结束。如果这个过程中出现bug、需求变更、环境问题或者需要增加新功能模型很难在后续的会话中继续改进同一个项目。每一次独立对话就像一次“孤军奋战”没有对之前决策的记忆回溯也没有对全项目状态的理解。Harness-of-Harness正是为了解决这个问题而提出的。它的名字本身也很有意思——“Harness”原意是“驾驭、控制”在这里可以理解为一种“工作框架”或“约束系统”。两个Harness叠加说明这个框架的“控制层”是复合的、多层级的。核心思路是不仅让AI执行软件开发任务还让它在一个长期运行的环境中持续工作、反复测试、自我修正、逐步完善代码直到整个项目达到预期目标。1.2 Harness-of-Harness 是什么从概念上讲Harness-of-Harness简称HoH是一种面向“多日自主软件开发”的Agent框架设计范式。它通过外部控制循环outer harness和内部任务循环inner harness的双层结构让AI能够在一个项目上持续运行数天期间不断学习、改进、验证并最终产出可运行的软件系统。这里的“外部控制循环”负责整体规划、状态跟踪、质量评估和任务调度“内部任务循环”则负责具体编码、测试、修复、重构等子任务。两层循环结合形成了“规划→执行→验证→优化→再规划”的闭环链路。和传统单次生成任务不同HoH强调的不是“生成结果”而是“持续改进结果”。1.3 持续改进的含义“持续改进”是HoH框架的另一个关键词。传统软件开发有持续集成、持续交付CI/CD它们强调的是代码提交后的自动化构建、测试和部署流程。而HoH中的持续改进是指在AI开发Agent的运行周期内反复让模型审视自己生成的代码通过静态分析、单元测试、同行评审模拟、用户反馈注入等方式发现问题、修正问题、优化设计。这种改进不是一次性的而是多轮次的并且每一轮的改进结果都会被记录下来作为后续决策的参考。1.4 常见应用场景那么HoH适合用在哪里从目前的研究方向和应用前景来看主要有以下几类首先是复杂项目原型开发。比如从零搭建一个含前后端、数据库、认证逻辑的Web应用HoH可以连续运行多个周期逐步完善功能而不是一次性生成一份“看起来完整但跑不起来”的代码。其次是企业内部代码库的持续维护。对于已有项目HoH可以接收Issue、Bug描述或者Feature Request自动定位相关代码模块完成修改然后跑测试如果失败就继续修直到全绿。第三是自动化测试生成与修复。HoH在持续改进过程中可以不断生成测试、执行测试、分析覆盖率、修复被测试出来的问题形成一个自动化的测试闭环。第四是教学与研究。在软件工程教育中HoH可以用来自动评估学生项目的完整性和规范性也可以用于软件工程自动化研究的实验平台测试不同模型、不同策略在长周期任务中的表现。2. 核心架构双层 Harness 的拆解2.1 Outer Harness外部控制层Outer Harness是HoH的最外层控制逻辑负责整个软件开发项目的生命周期管理。它更像是一个“项目经理”的角色主要职能包括维护全局任务状态当前项目处于哪个阶段、哪些模块已完成、哪些任务待处理、哪些任务存在阻塞。规划任务列表根据项目需求和当前进度动态拆解下一步要执行的任务。质量评估与门禁在子任务完成后通过测试、构建、静态扫描等手段评估产出结果判断是否可以进入下一阶段。状态回滚与重试如果子任务执行失败Outer Harness会根据失败原因决定是重试、重新规划还是人工介入。外层控制的一个重要特点是“长期记忆”。它需要在多日的运行周期中记住之前做过什么决策、为什么这么决策、遇到了哪些坑。所以Outer Harness通常会维护一个持久化的状态存储比如数据库、Git提交历史、任务清单文件等。2.2 Inner Harness内部执行层Inner Harness是完成具体开发任务的执行层。它接收Outer Harness分配的子任务比如“修复用户登录模块的token过期问题”然后进行代码分析、修改、测试、提交。它包含代码编辑工具直接修改项目文件。命令执行工具运行测试、构建、lint等。信息检索工具检索项目结构、读取相关文档、搜索历史提交记录。Inner Harness的核心目标是高效地完成单个任务同时尽可能减少对外层的依赖。因为它会频繁执行所以速度和资源控制是关键。2.3 双层之间的交互流程整个过程可以大致描述为Outer Harness接收项目需求初始化项目状态生成初始任务列表。按优先级取出一个任务交给Inner Harness执行。Inner Harness调用大模型、代码工具、Shell命令等尝试完成任务。Inner Harness将执行结果、日志、代码diff返回给Outer Harness。Outer Harness验证结果跑测试、检查质量、对比需求。如果通过更新项目状态取下一个任务如果失败分析失败原因调整任务描述后再次执行或者标记为需要人工介入。整个项目达到停止条件如全部测试通过、需求覆盖完整后Outer Harness生成最终交付报告。这种双层结构与传统Agent的“ReAct循环”相比增加了更明确的质量门禁和长期记忆管理更适合软件工程这种高复杂度、长周期、强约束的任务场景。3. 为什么不只是“用大模型写代码”3.1 大模型写代码的短板现在用大模型写代码已经非常普遍但它有几个本质短板一是上下文窗口有限。即使模型支持128K甚至200K上下文面对一个真实的中大型项目仍然不够。模型无法记住每一个文件的每一个细节容易出现“拆东墙补西墙”的情况。二是缺乏验证能力。大模型生成的代码可能在语法上正确但逻辑上有bug或者依赖版本不对或者存在安全隐患。让它自己生成、自己运行、自己检查这是传统提示工程很难做到的。三是缺少长期目标感。常规对话中模型只会针对当前问题回答不会主动规划整个项目的后续步骤。即使你告诉它“这是一个项目”它在对话超长之后也会遗忘早期目标。3.2 Harness-of-Harness 如何补足短板HoH的思路是把“大模型写代码”升级成一个“带质量反馈的闭环系统”。在这个闭环中长任务通过Outer Harness被切分成短任务短任务通过Inner Harness被执行每个短任务的结果通过自动测试被验证验证失败的结论被输入给下一轮改进项目级状态被持续记录和更新。这样一来大模型的角色从“唯一决策者”变成了“执行引擎”而真正掌控项目的是围绕它构建的Harness体系。即便模型偶尔犯错外层控制系统也能在验证环节发现并纠正不让错误累积到最终交付结果中。3.3 HoH 与 AutoGPT、MetaGPT 的区别很多人会把HoH和AutoGPT、MetaGPT放一起比较。它们确实都属于多智能体或Agent自动化的范畴但侧重点有明显差异AutoGPT更偏向通用任务自动化给一个目标它自行拆解步骤并执行适用于很多非软件工程场景但它对代码工程的约束性、测试门禁、长期记忆管理相对薄弱。MetaGPT强调“软件公司”的流程模拟定义了产品经理、架构师、工程师、测试等角色通过角色协作生成文档和代码。它更关注“角色分工”和“文档产出”但从工程角度看它的自动化验证和持续改进机制仍然偏弱。Harness-of-Harness最大的不同在于它把“工程化管理”作为框架的第一原则任务队列、状态管理、质量评估、失败重试、长期记忆这些机制都被显式建模并且强调多日运行的稳定性。它不是“模拟一个软件公司”而是“构建一个真正能长时间写代码的自动化系统”。4. 核心机制拆解基于规则的奖励模型与持续改进4.1 基于规则的奖励模型HoH中一个非常关键的设计是“基于规则的奖励模型”Rule-based Reward Model。这个概念与强化学习中的奖励模型类似但HoH中的规则并不是抽象的数学函数而是工程上可计算、可检查的硬性标准。比如代码是否能通过预定义的单元测试项目是否能成功构建代码规范检查lint是否通过关键路径是否达到指定测试覆盖率是否引入了已知安全漏洞。你可以把它理解成一套“机器可判断的验收标准”。Inner Harness每次完成代码修改后系统就会运行这些规则得到一个奖励分数或通过/失败信号然后根据这个信号决定下一步行为。相比依赖大模型自己判断“我改得好不好”基于规则的验证更客观、更稳定也更接近真实软件开发中的CI门禁。4.2 多轮迭代与代码改进闭环在HoH中一次任务通常不会只跑一轮就结束。它会先进行初始实现然后运行单元测试发现失败用例分析失败原因定位到具体代码位置修改代码修复问题重新运行测试确认修复是否有效如果还有失败继续循环如果没有失败再执行更严格的质量检查比如覆盖率是否达标、是否有重复代码、是否需要重构。这个闭环就是“持续改进”的微观体现。在传统开发模式中这个闭环是靠开发者和CI系统互相配合完成的在HoH中它被设计成完全自动化的流程。4.3 探索-利用平衡与错误记忆在多日开发中AI会面对大量可选方案。比如一个功能可以用不同算法实现一个bug有多种修复路径。HoH需要平衡“利用已知可行方案”和“探索新方案”的关系避免过早陷入局部最优。同时HoH还会维护“错误记忆”。也就是说如果之前某次修改导致测试失败这个失败经验会被记录下来。当模型再次遇到类似任务时Outer Harness会把历史失败信息注入上下文中提醒模型不要重复同样的错误。这有点像软件工程里的“复盘机制”只不过它是自动化的、结构化的。5. 从“单次任务”到“多日开发”实践路径5.1 搭建基础环境如果你想亲身体验HoH思想的实践不需要一上来就复现论文中的整套系统。可以先从搭建一个“最小可行版本”开始。建议环境如下操作系统LinuxUbuntu 22.04以上或macOS编程语言Python 3.10大模型APIOpenAI、Anthropic或本地部署的DeepSeek等代码仓库Git自动化工具pytest、flake8、pre-commit数据库可选SQLite或PostgreSQL用来存储项目状态和任务历史。需要说明的是这里不涉及具体模型版本因为不同时间模型能力差异很大你可以根据自己的实际情况选择。重点在于“把大模型的生成能力接入到有验证的工程回路中”。5.2 一个简化的HoH流程示例假设我们要开发一个“待办事项管理API”。HoH的最小闭环可以写成这样一个伪流程# 文件路径hoh_simplified.py # 这个示例演示 HoH 的核心思想 # 规划 - 生成 - 验证 - 修复 - 记录循环执行 import subprocess import json import os class SimpleTask: def __init__(self, task_id, description, test_file): self.task_id task_id self.description description self.test_file test_file self.attempts 0 def run_validation(self): 运行测试文件返回是否通过 result subprocess.run( [pytest, self.test_file, -v], capture_outputTrue, textTrue ) return result.returncode 0, result.stdout result.stderr class HOHCore: def __init__(self, initial_tasks): self.tasks initial_tasks self.history [] def call_generate_model(self, prompt): 调用大模型生成代码。 实际项目中请替换为 OpenAI / Claude / 本地模型等接口。 这里用占位符表示调用时你也可以直接输出测试代码。 # 假设我们通过某些SDK调用模型 # response openai.ChatCompletion.create(...) # return response.choices[0].message.content return # 这里是由模型生成的代码 def execute_task(self, task: SimpleTask): 执行一个任务的完整闭环 task.attempts 1 # 1. 构建 prompt让模型生成代码修复方案 prompt ( f请完成以下任务{task.description}\n f相关测试文件{task.test_file}\n 请直接输出修复后的完整代码。 ) generated_code self.call_generate_model(prompt) # 2. 将生成的代码写入目标文件示意 target_file ftodo_api_{task.task_id}.py with open(target_file, w, encodingutf-8) as fp: fp.write(generated_code) # 3. 验证结果 passed, log task.run_validation() self.history.append({ task_id: task.task_id, attempts: task.attempts, passed: passed, log: log[:500] }) # 4. 如果失败可以在这里继续调用模型修复简化为最多3次 while not passed and task.attempts 3: task.attempts 1 repair_prompt ( f测试日志如下{log[-2000:]}\n 请修复代码以通过测试直接输出完整代码。 ) generated_code self.call_generate_model(repair_prompt) with open(target_file, w, encodingutf-8) as fp: fp.write(generated_code) passed, log task.run_validation() return passed, log def run_all(self): results [] for task in self.tasks: passed, log self.execute_task(task) results.append({task_id: task.task_id, passed: passed}) return results if __name__ __main__: # 初始化任务列表 initial_tasks [ SimpleTask( task_id1, description创建一个基于Flask的待办事项API支持增删改查, test_filetest_todo_api.py ) ] core HOHCore(initial_tasks) final_results core.run_all() print(json.dumps(final_results, ensure_asciiFalse, indent2))上面这段代码是一个非常粗略的示意并不建议直接用于生产环境但它展示了HoH的一个核心循环规划任务、生成代码、运行验证、失败修复、记录结果。在实际系统中Outer Harness的任务规划会更复杂Inner Harness的调用工具也更多样。5.3 推进到多日运行的关键点如果要在真实项目中跑多日你需要额外解决几个问题一是任务的可恢复性。系统需要能够在任意时刻暂停并恢复比如深夜任务跑了一半断电第二天能接着未完成的任务继续跑。这需要把状态持久化到磁盘或数据库。二是大模型API费用控制。多日运行意味着大量的模型调用必须有budget管理和调用频控。三层结构里keep prompt尽量短上下文尽量精简优先复用已有结果。三是工具集的安全隔离。AI自主修改代码本身有风险不能让它随意执行危险命令。建议将所有执行命令限制在Docker容器或沙箱环境内并设置权限白名单。四是人工审核接入点。持续自主不意味着完全无人参与关键节点比如数据库变更、依赖升级、架构重构仍然需要人工审批。HoH框架应当预留这样的“human-in-the-loop”入口。6. 核心差异Harness-of-Harness 带来的技术启发6.1 重新定义“AI写代码”HoH的意义在于它把AI从“代码生成器”变成了“软件工程执行体”。过去我们问“AI能写好代码吗”现在应该问“AI能在约束条件下持续交付可运行的软件吗”。在HoH的框架里代码生成只是最底层的一环真正重要的是它和质量门禁、状态管理、错误回溯、引入新功能等机制的协同。6.2 对开发工具链的影响可以预见HoH的理念会影响未来的开发工具链设计。IDE插件不再只是一个补全助手而可能演变为一个“项目级长期协作者”。它阅读你的代码库、理解项目历史、自动生成任务清单、执行修改、运行测试、提交代码甚至根据CI反馈继续修复直到绿线亮起。这个闭环比今天任何一个智能编码助手都更接近“虚拟工程师”的定位。6.3 对软件工程教育的影响HoH还有很强的教学价值。软件工程课程中的“项目设计、编码、测试、重构”等环节可以被复用到自动评估和反馈系统中。学生提交一个项目后系统可以自动判断它是否满足功能要求、代码质量是否达标、测试是否完备并在多轮迭代后给出改进建议。这有助于学生在大型项目开发中养成“验证驱动”的习惯。7. 技术挑战与未来展望7.1 当前面临的主要挑战虽然HoH的框架很有吸引力但它落地的难度也不小。首先是“长周期稳定性”问题。多日运行意味着模型会输出海量代码、执行大量操作。任何一个环节的错误累积都可能让整个任务崩溃。解决这个问题需要非常完善的异常捕获、日志记录、状态重置机制。其次是大模型的幻觉问题。模型在修改代码时可能“自以为”某个功能是正确实现但实际运行结果却不符合预期。Hop中的规则验证可以减少这种情况但无法完全杜绝。第三是自动化验证的覆盖面有限。HoH依赖“基于规则的奖励模型”但现实项目的需求往往难以全部转成可运行的测试。如果某些需求没有被测试覆盖AI可能会在“测试通过”的情况下做出错误实现。这需要引入需求追踪、人工验收、行为仿真等更丰富的验证手段。第四是安全与合规问题。让AI自主运行数天按代码仓库、生产环境中的操作风险非常高。权限控制、审计日志、操作白名单、异常熔断机制都必须在设计阶段就纳入考量。7.2 未来发展方向HoH的演进方向可能包括更强大的状态表示将项目代码、Git历史、模拟运行记录统一编码让模型可以从全局视角理解项目。多智能体分工协作在Outer Harness下挂载多个Inner Harness分别负责前端、后端、测试等形成更强的并行开发能力。自学习奖励规则奖励模型不再只依靠硬编码规则而是能从历史项目数据中学习哪些代码模式更容易带来成功从而制定更动态的质量标准。跨项目记忆多个项目跑完后系统能沉淀一套“开发经验库”在新项目中复用过往的成功策略。8. 高频问题与最佳实践建议8.1 常见问题清单问题现象常见原因解决思路同一个bug反复修不好模型缺少对失败历史的理解提示将前几次失败的具体原因注入Prompt生成代码能跑但逻辑不符合需求验证规则只覆盖了“能不能跑”增加功能级验收测试和业务场景测试多日运行后状态越来越乱缺少状态持久化和任务优先级管理引入数据库存储任务状态设计好启动/恢复逻辑调用API费用过高每轮都使用大上下文重发项目全量信息缓存历史结果只发送diff和相关文件摘要自主修改代码破坏了其他模块缺少变更影响分析修改前读取依赖关系运行受影响模块的测试无法判断是否应该交给人工质量门禁没有明确分级设定三级门禁自动通过、需人工复核、强制终止8.2 工程实践建议如果你准备在自己的项目里实验HoH思想建议按下面几个原则来第一从“窄而深”的场景开始。不要一开始就让AI去开发一个“电商全栈项目”。先让它在单个模块上运行闭环生成、测试、修复、再测试稳定之后再扩展任务范围。第二测试先行。你要给AI清晰的验收标准没有自动化测试HoH就是无源之水。先把CI系统搭好再考虑让AI进入开发环节。第三保持人工监督。尤其是在数据库操作、外网请求、生产配置变更等高风险任务上设置强制审批点。第四做好日志与审计。每一轮AI的决策、Prompt、代码diff、测试结果都要记录这样你才能复盘整个开发过程找到瓶颈并进行针对性优化。第五控制上下文长度。多日运行期间不要让模型每次都“重读全文”。合理做法是让外层维护一个结构化状态文件比如{ project: todo-api, current_stage: feature/user-auth, completed_tasks: [init-project, todo-crud, database-schema], pending_tasks: [user-login, jwt-auth, api-docs], known_issues: [ test_login.py fails when token expired ] }这样Inner Harness每次只需要拿到当前任务和最少量的上下文效率和准确性都会高很多。9. 总结从“会写代码”走向“会做工程”Harness-of-Harness不是一个步行可用的“AI工具下载链接”而是一种关于如何构造自主软件开发Agent的设计哲学。它的核心贡献在于把“大模型代码生成”和“工程化质量循环”融合成了一个可持续运行的系统结构。对于开发者而言了解HoH有助于你重新理解AI在软件研发中的角色它不只是一个“代码生成器”而是一个“可以被约束、被验证、被持续改进的工程执行者”。如果你对自主软件开发、智能体框架设计、AI工程化落地感兴趣HoH是一个值得深入研究的切入点。建议下一步可以继续关注大模型Agent的长期记忆与状态管理机制自动化测试生成与失败定位的技术进展多Agent协作下的任务调度与冲突消解基于代码仓库级验证的奖励建模方法。如果你正在酝酿自己的Agent项目不妨试试“双层Harness”的思路外层管项目、内层管实施用规则验证保证质量。哪怕第一次跑通的时间比“一次性生成”更长结果的可控性和可维护性也会完全不一样。好了这篇关于Harness-of-Harness的技术拆解就到这里。希望它对你理解自主软件开发的新范式有所帮助。如果你实际搭建了类似的闭环系统或者遇到了有意思的问题欢迎在评论区交流。