自主软件开发这两年讨论很多，但大多数工具解决的问题集中在单次任务：你给我一个 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 变成可长期运行的工程方案。
