你有没有遇到过这种场面一个能写代码的 AI 助手单次需求完成得又快又像样可一旦让它跨越多天连续开发同一个项目第二天就会开始“失忆”——忘记昨天定的命名规范搞丢上周修好的行为逻辑甚至把已经通过测试的老功能改坏。最近看到 “Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement” 这个标题时我第一反应是多日自主开发终于不再只谈“单次生成能力”而是开始认真面对“长期运行稳定性”了。这篇文章我想把这个概念拆开讲清楚它到底解决什么问题为什么值得关注以及我们在真实项目里如何借鉴这套思路。1. 为什么单次生成不是真正的“自治开发”先说一个我的判断当前很多所谓的 AI 编程工具本质上还停留在“一次生成、一次修错、一次成功”的阶段。它们很强但还不能叫“自治开发”。真正的自治开发是具备跨时间、跨文件、跨任务持续工作能力的系统而 Harness-of-Harness 这类设计恰恰是在往这个方向补位。1.1 从一次修改到跨天维护差距在哪一次修改的场景非常简单你给 AI 一个明确的小任务比如“给这个函数增加错误处理”它读文件、改代码、跑测试基本就能结束。这里最大的难点往往是单次生成的正确率它只在一段有限上下文中做判断不需要维护长期状态。但跨天维护完全不同。今天是“增加错误处理”明天是“调整调用方的逻辑”后天是“重构整个模块”。这三个任务之间是有隐式依赖的第二天的修改必须理解第一天的设计选择第三天的重构则要保证前两天的行为不被破坏。这种能力已经不是“生成代码”的问题而是“在连续变化的代码库上长期保持正确”的问题。Harness-of-Harness 的“Harness”在这里非常关键。Harness 在软件工程里常被翻译成“夹具”或“控制层”在 agent 领域里通常指模型与工具之间的执行框架而 Harness-of-Harness 则是给这层执行框架再套一层跨天流程控制。你可以把它理解成内层 Harness 负责每一次“生成-执行-反馈”外层 Harness 负责多日任务的计划、状态维护、验证和持续改进。1.2 任务规划不等于状态管理很多团队做多日自治开发时第一反应是让 AI 做任务规划第一天做什么第二天做什么全部列成清单。这确实有用但远远不够。任务规划只是“计划”多日开发的难点还有“状态”。一个多日项目运行到第三天系统里起码要维护这些状态当前代码库的快照或变更记录前一天任务是否真的完成、测试是否通过有没有引入新的技术债或者临时 hack之前踩过的坑、废弃的方案、被否定的设计当前正在推进的目标是什么以及进度边界在哪里。状态一旦缺失系统就会陷入一种“每天从头开始探索”的尴尬。今天做的决策明天不知道明天重试相同错误后天再踩一遍。这个问题不是靠一个更大的上下文窗口就能解决的它需要明确的记忆管理和流程闭环。2. “层层装配”到底装的是什么Harness-of-Harness 听起来像套娃但它不是无意义地嵌套。它的核心逻辑是分层控制底层管好每一次代码操作上层管好整个多日流程。这不只是架构选择也是一种责任分离思想。2.1 内层生成器、执行器与反馈器先看内层 Harness。它负责单个任务的完整执行闭环通常至少包含三个角色生成器读取任务描述和当前代码生成补丁或新文件执行器运行命令、执行脚本、跑测试把结果带回来反馈器把执行结果、报错信息、测试失败信息整理成模型能理解的反馈。这个内层最有价值的设计是“执行结果必须回到模型手里”。很多人一开始只做到“生成代码 - 保存文件”却漏掉了“运行测试 - 返回结果”这一步。结果就是模型只能靠静态分析猜问题根本不知道自己生成的代码是否真的有效。内层 Harness 把“生成”和“验证”绑在了一起没有验证的生成就不算完成。2.2 外层计划、记忆与评测构成的闭环外层 Harness 则负责管理多日运行的节奏。它可以理解成一套操作系统内层 Harness 每运行一轮外层 Harness 都在记录、判断、调整下一步。比较典型的外层结构包括模块职责多日价值任务仓库存储 issue、任务清单、验收条件让系统知道“今天要做什么”状态记录保存变更日志、测试结果、决策记录让系统记住“昨天做到哪一步”记忆管理长期摘要、上下文压缩、关键信息抽取防止上下文无限膨胀回归验证跑全量或关键路径测试确保新改动不破坏老功能改进循环把失败案例、修复经验转成新任务或新规则让系统越跑越稳这个框架最核心的思路不是“让模型更聪明”而是“让流程更有韧性”。单次生成哪怕只有 60% 正确率只要验证和反馈循环足够快系统仍然有机会在多轮尝试中收敛到正确结果。而如果流程断裂哪怕模型能力再强也会在跨天运行中迷失方向。3. 多日运行怎么实现持续改进标题里的 “Continual Improvement” 是整篇内容中最容易被低估的部分。多日自治开发真正让人期待的不是“能跑几天”而是“越跑越好”。但持续改进不是天然发生的它需要被刻意设计。3.1 每天结束前必须产出“可复用的经验记录”第一天写代码、跑测试、修复问题这些过程如果不沉淀下来第二天就会归零。我更建议在每个运行日结束时生成一份轻量级的“决策摘要”内容包括今天完成了哪些任务哪些没有完成卡点是什么有没有使用临时方案后续需要重构的地方在哪里这次修改影响了哪些模块关联的测试是什么哪些尝试是失败的失败原因是什么下次不要再走同一条路。这份摘要不一定要很长但一定要能被下一轮运行读取。它可以是一个 markdown 文件、一份 JSON 状态也可以是一条向量检索记录。关键是信息必须落盘并且有明确的读取入口。3.2 失败样本要变成下一轮的训练素材持续改进的另一条路是把失败样本转成新的学习数据。例如系统尝试修复一个测试失败试了三次都没成功最后一次成功了。这个“问题描述 错误信息 成功补丁”的组合就是非常有价值的微调样本。如果团队有条件做模型微调可以把多日运行中积累的高质量样本拣选出来定期做一轮轻量训练。即使不做微调也可以维护一个“失败模式库”把常见错误、错误特征和解决策略记录下来放在后续任务的上下文中作为参考。这样系统就不再是每天从零开始而是带着前几天的经验在运行。3.3 至少需要一个“回顾—筛选—固化”的流程我见过不少实验项目跑得很快但一直没有形成改进机制原因很简单它们只做了任务执行没有做经验固化。持续的改进必须有一个人工介入或规则驱动的筛选过程回顾每天结束后自动汇总所有执行记录、测试结果和失败原因。筛选挑出有复现价值的失败案例和高频错误类型。固化把经验压缩成规则、提示片段或训练样本进入下一轮系统可读取的上下文或模型参数。这个过程听起来复杂但哪怕是人工每天花半小时整理也比完全不做要好得多。只要坚持一两个星期系统稳定性和任务完成率都会明显提升。4. 落地时先跑通最小级联再谈完整框架大而全的 Harness-of-Harness 架构听起来很好但我不建议任何人直接照搬完整方案尤其是资源有限的个人开发者或小团队。更好的路径是从一个最小级联开始先证明“多日运行 验证 反馈”的基本闭环能跑通再逐步加厚。4.1 最小可运行结构长什么样一个最小可运行的多日自主开发系统不一定需要微调模型、向量数据库、分布式测试集群只需要四样东西任务计划文件描述每天要完成的目标代码仓库带版本控制可执行的测试命令一个能驱动模型执行任务并读取反馈的脚本。用伪代码描述大概是这个样子# 示例结构用于理解多日闭环不要直接照抄 for day in range(1, total_days 1): tasks load_tasks(fplan_day{day}.md) for task in tasks: while attempt max_attempts: patch agent.generate(repo_path, task) apply_patch(repo_path, patch) result run_tests(repo_path) log_to_day_record(day, task, patch, result) if result.passed: commit_changes(repo_path, fday{day}-{task.id}) break else: rollback_patch(repo_path, patch)这里有几个核心决策点非常关键。第一每次失败必须回滚补丁。因为多轮尝试时代码库不能被污染否则后续尝试会在错误的代码基础上继续。第二测试必须可重复、可快速执行。如果每次验证都要五分钟多日运行根本无法收敛。第三每天的任务量要小。宁可一天只拆 5 个小任务每个都能跑通测试也不要规划一个超大任务最后连日志都看不明白。4.2 单日任务配置和多日任务配置的差异很多现成的 agent 框架只适合单次任务因为它们的默认配置里没有状态管理。真要改成多日模式至少需要调整下面这几个维度配置项单日任务多日任务上下文来源任务描述 当前文件长期记忆 历史决策 当前文件验证策略单点测试回归测试 目标测试日志粒度和维度单次执行即可按天、按任务、按尝试次数记录失败处理尝试修复直到成功或中止失败要登记到经验库避免重复踩坑代码保护机制可接受直接修改必须有分支、回滚、变更快照不要小看“上下文来源”的差异。单日任务把任务描述塞进 prompt 就够了多日任务则必须从记忆系统里检索相关历史信息否则第二天就可能忘记第一天的约定。4.3 从实验脚本到工程化服务跑通最小级联之后再考虑工程化。工程化不是加几个 Redis 或者换一个更强的模型而是要解决几个非常具体的问题并发任务怎么隔离多个任务同时改同一个文件会产生冲突要有任务锁或模块隔离。资源消耗怎么控制每次生成都调用大模型会很烧钱要有预算、失败重试上限、token 消耗统计。结果审计怎么做要让使用者能回溯“这个改动是谁生成的、为什么生成、测试结果是什么”。安全边界怎么限定AI 执行命令时绝不能无限制地访问文件系统、网络或运行危险命令。这些能力不会出现在标题里但往往决定了一个多日自治开发系统能否真正长期运行。5. 这套思路的适用边界与常见误判写到这里我想把边界说清楚。Harness-of-Harness 代表的“多日自治”思路不是万能药它适合某些场景也讨厌另外一些场景。误判边界比不会写代码更危险。5.1 适合什么不适合什么适合的项目通常有这些特征有比较完整的自动化测试能快速判断改动是否正确代码模块边界清楚增量改动不会引发大量连锁修改任务可以拆成独立的小步每一步都有可验证结果允许一定程度的反复尝试和资源消耗使用者有能力在关键节点做审核和回滚。不适合的项目则恰恰相反没有测试或者测试本身不稳定是一个巨大的单体系统改动牵一发动全身涉及敏感权限、真实用户数据、资金交易等高危场景任务目标模糊无法拆解成可验收的小任务不允许失败要求一次成功、零容错。这里最容易被忽略的是“没有测试”的项目。很多人的直觉是测试太少没关系AI 可以帮我写测试。但在多日自治开发里AI 生成的测试如果没有被人工审核很容易出现“测试通过但行为错误”的假象。没有可信测试作为锚点整个多日闭环就会失去验证基础。5.2 真正需要人工介入的三种情况即使系统再强我也建议保留三种人工介入点。一是目标变更时。多日开发中需求经常变化不能让 AI 在旧目标上一直往前跑自动跑几天后发现需求已经变了。二是大规模重构前。重构会跨模块、跨目录一次失败可能影响几十个文件。至少让人工先看一遍重构计划和影响面。三是关键交付前。正式发布、合并主干、提交给用户前都必须有人工 code review。这个不是不信任系统而是责任必须有人承担。5.3 常见问题排查链路如果多日自治开发跑着跑着出了问题建议按下面的顺序排查而不是一上来就重训模型或者换大模型先看任务计划是否清晰。任务粒度如果太大系统很难验证成功可以先拆小。再看测试是否稳定。测试如果随机失败系统会一直做无意义的重试。再看上下文记忆是否丢失。第二天是否忘了第一天约定如果是记忆管理和摘要策略要改。再看失败重试逻辑。每次失败是否回滚干净重试之间是否重叠修改。最后看资源消耗和输出日志。token 消耗异常高、日志缺失、任务根本没有推进都说明流程层出了问题。大多数情况下问题出在流程设计而不是模型能力。6. 多日自主开发的下一步也是流程设计的下一步Harness-of-Harness 并不是某一天突然出现的魔法而是把几个已经成熟的工程理念重新组合测试夹具、任务调度、状态管理、持续集成、反思式学习、反馈闭环。它真正提醒我们的是AI 编码能力的下限由模型决定上限则由流程设计决定。想要多日自治开发真正可用就要把每一个“单次生成”放进一个能验证、能记忆、能改进的系统里而不是期待模型自己长出项目管理能力。如果你现在正准备做类似实验我的建议很直接不要先搭大框架先找一个有测试、任务清楚的小仓库写一个只运行三四天的最小循环把记忆、验证、回滚、日志跑通。等这个最小闭环能稳定经历多次跨天运行再讨论更大的规模。多日自治开发的门槛不在模型而在于你愿不愿意把流程当作一等公民来设计。