2026年初，Cursor团队发布了一篇关于Scaling Agents的研究报告，其中披露的实验数据令人瞩目：

• 浏览器项目：约1000个文件，代码量超过100万行，运行了将近一周时间
• Windows 7模拟器：累计14600次提交，代码量120万行
• Excel公式引擎：12000次提交，160万行代码

“上百个Agent可以在同一个代码库上协同工作数周”——这是他们的原话。整个实验消耗了数万亿个token。几乎同一时间，OpenAI在其harness engineering文章中透露：一个3至7人的小团队，利用Codex Agent Loop运行了5个月，成功合并了约1500个PR，产出了100万行代码，而且完全零手写代码。

社区自然也不甘落后。OctopusGarden自称“开源软件暗工厂”，通过无限循环生成代码直至满意度达到95%；WorkOvernight让Claude Code在你睡眠时自动编写代码；YC W26的Emdash则专注于并行Agent编排。

这些实验看似都很成功。但仔细阅读Cursor那篇文章，会发现他们坦承了不少问题：Agent的注意力会随时间漂移，flat peer-to-peer协调会导致吞吐量坍缩——20个Agent的实际产出可能只相当于2-3个。Agent在没有层级管理的情况下，倾向于做小而安全的改动，回避真正的难题。

那么问题来了：在完全无人监督的情况下，给AI无限的时间，它到底能把一个项目推进到什么程度？

两种死法

为了回答这个问题，一个极简的无限循环框架——AutoForge的第一个版本——被开发出来。

设计思路很简单：写一个种子文件（seed.md），描述项目目标，然后让AI Agent无限循环、无人监督、无时间限制地自主开发。每一轮，Agent分析项目现状，生成任务，执行任务，再进入下一轮。理论上，只要模型够强，时间够长，它就应该能不断推进项目。

实际运行后，两种截然不同的失败模式浮出水面。

收敛——注意力坍缩

第一种死法是收敛。Agent在跑了若干轮之后，任务列表开始萎缩。diff从几百行缩到几十行，再缩到几行。Agent开始反复调整同一个模块的细节——改改按钮样式、优化一下日志格式、重新排列一下import顺序。

从Agent的视角看，它觉得项目“已经很好了”，找不到新事情可做。但从人类视角看，项目可能还有大量功能未实现——Agent的注意力坍缩到了一个局部最优点，无法跳出来。

这和Cursor团队描述的现象高度吻合：他们也发现Agent在长时间运行后会发生drift，需要定期重启来避免。

发散——注意力扩散

第二种死法恰好相反：发散。Agent每一轮都往不同方向撒点——这轮加个用户系统，下轮搞个动画引擎，再下轮又去写网络模块。没有方向，没有聚焦，到处开花但哪朵都不结果。

代码库快速膨胀，模块之间缺乏协调，质量完全失控。本质上，没有约束的创造力等于噪声。自由度太高，反而什么都做不好。

一个残酷的结论

无论是收敛还是发散，结论都指向同一个事实：无限时间 + 无限自由 ≠ 无限能力。

裸模型不会因为跑得更久就变得更强。给它再多的时间，它也不会自发地产生“退后一步看全局”的能力，也不会自动平衡注意力的分配。Cursor团队在实验中也得出了类似的结论——他们从flat peer-to-peer协调演进到了Planner-Worker分层架构，本质上就是在给Agent加约束。

那么，约束应该怎么加？

问题出在环境，不在模型

带着这个问题查资料，找到了OpenAI 2026年2月那篇harness engineering文章。读完后感受很直接：原来人家那100万行代码不是模型裸跑出来的。

他们的核心发现是：瓶颈不在模型的代码能力，而在于缺少结构、工具和反馈机制。他们把模型之外的所有这些东西统称为harness——Agent的“缰绳”。

Agent = Model + Harness。模型是马，harness是缰绳。没有缰绳的马只会乱跑。

Martin Fowler随后在《Harness Engineering for Coding Agent Users》中给出了更系统化的框架。他借用了控制论的概念，把harness分为两类控制：

• Guides（前馈控制）：在Agent行动之前引导它。比如CLAUDE.md配置文件、架构文档、角色定义。
• Sensors（反馈控制）：在Agent行动之后检测和纠正。比如linter、测试套件、代码审查。

每种控制又可以是计算性的（确定性的，比如跑测试）或推理性的（非确定性的，比如让另一个LLM审查代码）。

简单来说，Prompt Engineering管的是“问什么”，Context Engineering管的是“给LLM看什么上下文”，而Harness Engineering管的是“整个运行环境怎么设计”——它是最上层的学科，前两者是它的子集。

回过头看之前的实验，AutoForge v0的失败原因就清楚了：不是模型不行，是harness压根不存在。给了一匹好马，但忘了给缰绳。

给野马套缰绳：AutoForge的进化

想明白这一点后，开始系统性地给AutoForge加上各种harness机制。每一个机制的加入，都是被实际遇到的问题逼出来的。

三角色流水线

AutoForge v0最大的问题之一是角色混乱——一个Agent既要分析项目、又要写代码、还要评估质量。这就好比让同一个人出题、答题、阅卷，结果可想而知。

于是职责被拆成了三个独立角色：

• Analyst：分析项目现状，从特定视角出发，生成5-10个任务写入任务队列。它只有readonly权限，看得见代码但碰不了。
• Builder：从队列中领取一个任务，专注执行。拥有完整的文件读写权限。
• Reviewer：独立审查Builder的产出，给出APPROVE / REQUEST_CHANGES / REJECT三种判决。同样是readonly。

这种权限隔离不是靠prompt来约束的——Analyst配置了 --allowedTools Read,Glob,Grep，在CLI层面就被限制了写入能力。如果规则重要，就别交给AI来遵守。

每个角色还可以使用不同的模型。分析任务用Sonnet省钱，构建任务用Opus保质量，审查任务用另一个模型增加视角多样性——这样还能降低关联性错误的概率。

确定性门禁

三角色分离解决了职责混乱的问题，但还有一个更隐蔽的陷阱：Agent会撒谎。

不是说它故意骗人，而是LLM有时候会在输出中声称“我已经运行了测试，全部通过”——但实际上它可能根本没跑。这在有人监督时还好发现，在无监督场景下就是灾难。

OpenAI在harness engineering中提出了一个原则：“if a rule matters, enforce it mechanically”——如果规则重要，就用机械方式强制执行。

AutoForge的Hooks系统就是这个原则的落地。它在流水线的三个阶段插入shell命令：

• post_build：Builder完成后，自动运行构建验证和测试
• pre_merge：并行模式下，合并到主分支前的检查
• post_merge：合并后的集成验证

这些hook是shell命令，不是prompt指令。它们是确定性的——跑就是跑了，没跑就是没跑。即使hook返回了exit code 0，系统仍然会扫描stdout中的 error、FAILED、BUILD FAILED 等模式作为双重保险。required: true 的hook失败直接阻断流水线，required: false 的只记录警告。

用Fowler的框架来说，这是一个计算性的反馈sensor——确定性的、不依赖模型的质量门禁。

干净上下文审查

Writer-Reviewer模式本身不新鲜，但AutoForge的实现有一个关键细节：Reviewer在完全干净的上下文中运行，看不到Builder的任何对话历史。

这解决的是认知污染问题。如果Reviewer能看到Builder的推理过程——“我之所以这样写是因为……”——它很容易被带偏，变成橡皮图章。干净上下文意味着Reviewer只看到任务描述和git diff，必须独立判断代码质量。

Reviewer给出REQUEST_CHANGES时，反馈会被存储为任务的失败原因。下次重试时，Builder能在prompt中看到这些反馈，从而有针对性地改进。这形成了一个跨Agent的反馈回路。

还有一个务实的安全设计：如果Reviewer自身超时或输出解析失败，默认判定为APPROVE。审查基础设施的故障不应该阻断生产流水线。

反收敛：解决最难的问题

前面的机制解决了“做对”的问题，但在无监督场景下，还有一个更根本的挑战：如何让Agent持续做新的事？

这是harness engineering文献中尚未被充分讨论的方向。OpenAI和Fowler的框架都聚焦于质量保证，但对于一个要无限运行下去的系统来说，反收敛才是生死攸关的问题。

AutoForge为此设计了四层防御体系：

第一层：9视角轮换。Analyst每次运行时，会被分配一个特定的分析视角：Feature Gap（功能缺口）、Bug Hunt（缺陷排查）、Test Coverage（测试覆盖）、Performance（性能审计）、Code Quality（代码质量）、Content（内容完整性）、UX（用户体验）、Integration（系统集成）、Resource Pipeline（资源管线）。每轮自动切换到下一个视角。

这是一个前馈引导——在Agent分析之前就限定了它的观察角度，强制它从不同维度审视项目。

第二层：任务指纹去重。对每个任务的标题和描述做SHA256哈希，截取前16位作为指纹，在数据库层通过UNIQUE约束去重。语义相同的任务无论被多少轮Analyst生成，都只会被执行一次。

这是一个计算性的反馈sensor——确定性的、零误判的。

第三层：区域注意力均衡。数据库中维护了一张area_attention表，记录每个代码区域被触碰的次数和最后触碰时间。任务分配时优先选择最少触碰的区域。这样做的效果是实现了一种类似round-robin的覆盖策略，防止Agent沉迷于某一个子系统。

第四层：收敛检测 + 逃逸。系统持续监控三个指标：

1. diff萎缩：如果最近几轮的git diff行数都低于阈值，且呈下降趋势
2. 文件重叠：如果最近几轮修改的文件高度重叠（重叠率 > 80%）
3. 代码停滞：如果总代码行数的波动范围低于阈值

任何一个指标触发，系统就会强制切换分析视角，并进入EVOLVE阶段——让Analyst完全重新规划，打破当前的注意力困局。

这里有一个巧妙的防死锁设计：EVOLVE阶段之后，系统会跳过收敛检测。原因是Analyst只分析不写代码，它产生的git diff必然为零——如果不跳过，收敛检测会立刻再次触发，形成无限EVOLVE循环。

用Fowler的2×2矩阵来对照，这四层恰好覆盖了控制论的全部象限：

• 视角轮换：前馈 × 推理性
• 指纹去重：反馈 × 计算性
• 注意力均衡：前馈 × 计算性
• 收敛检测：反馈 × 计算性

不是刻意设计的——是被失败逼出来的。

阶段轮换

AutoForge的执行流程不是线性的，而是一个环形状态机：BUILD → TEST → FIX → EVOLVE → BUILD → ...

每个阶段完成一定数量的任务（tasks_per_phase）后自动切换到下一个。EVOLVE是一个特殊的元阶段——它不执行代码，只让Analyst退后一步重新规划任务。当任务队列耗尽时，系统也会自动进入EVOLVE行为，不会因为没活干就停滞。

4个阶段 × 9个视角 = 36种组合。这意味着系统在每36轮循环中会从完全不同的角度和阶段组合来审视项目，大幅减少了盲区。

并行构建

当单个Builder的吞吐量不够时，AutoForge支持多Builder并行。这里用的是Git Worktree方案——每个Builder在独立的worktree中工作，真正的文件系统隔离。

并行带来的最大风险是合并冲突。AutoForge用了三层防御：

1. 区域级并发控制：同一个area同一时间只允许一个Builder工作。从源头减少冲突的可能。
2. 全局merge lock：所有合并操作串行执行。先尝试rebase保持线性历史，rebase失败则回退到merge。
3. 自动冲突解决：对常见的“双方都在添加新内容”类型的冲突，用正则匹配冲突标记并保留双方内容。解决不了的才放弃。

另外还有一个实用的优化：后台预取。当任务队列快要见底时，Builder还在工作的同时，Analyst已经在后台线程中生成下一批任务了。这样流水线不会因为等待分析而停滞。

Cursor团队在Scaling Agents中也得出了类似的架构演进结论——他们从flat peer-to-peer演进到了Planner-Worker分层架构，和AutoForge的Analyst-Builder分离不谋而合。

做得到什么，做不到什么

AutoForge加上这些harness机制之后，效果和v0有了质的区别。在给定一个清晰的种子文件的情况下，它可以持续数百轮不收敛、不发散地推进项目，每一轮都产生有意义的代码增量。

但它也有明确的局限：

• 它不能替代人类的架构判断。seed文件的质量决定了天花板。一个模糊的种子文件只会产出模糊的代码。
• 它不能自主发现需求。它能很好地把需求拆解成任务并执行，但“用户到底想要什么”这件事，仍然需要人来定义。
• 它在处理跨模块的深层依赖时仍然会出错，尤其是当修改需要同时协调多个子系统的设计时。

回到最初的问题：AI真能自己写出整个Windows系统吗？

Cursor的实验证明了规模上是可行的——120万行的Windows 7模拟器确实被生产出来了。但他们的文章同时也揭示了大量的工程挑战：drift、注意力坍缩、Agent回避难任务、协调机制的瓶颈。

结论有三条：

1. 模型能力是必要条件——没有足够强的模型，什么harness都救不了。
2. Harness是充分条件——同样的模型，有没有harness，产出天差地别。
3. 需求清晰度是前提条件——AI能忠实地执行你描述的东西，但它不会替你想清楚你想要什么。

那些演示视频里看起来AI在“自主”开发，实际上背后都有大量的harness工程在支撑。省略了这些，就制造了“模型裸跑”的假象。

如果对无监督自主开发这个方向感兴趣，AutoForge是完全开源的，它实现了上述所有的harness机制，可以直接拿来跑实验。

结语

Harness不是在限制AI，恰恰相反，它是让AI的能力能够可持续地释放出来的基础设施。没有缰绳的马跑得很快，但跑不远，也跑不准。

模型在快速迭代，各家的能力在趋同。但harness的设计——怎么拆分角色、怎么设计反馈回路、怎么对抗收敛、怎么保证质量——这些才是真正需要工程经验积累的部分。

OpenAI给出了harness engineering的理论框架，Cursor提供了规模化实验的数据，而AutoForge则是一次把这些理论落地为可运行框架的实践。

这个方向还有很多未解的问题：行为正确性的自动验证仍然是最大的难题；harness本身的复杂度如何控制；随着模型能力增强，哪些harness可以逐步拆掉。但至少有一件事是确定的：未来的AI工程师，与其说是在写代码，不如说是在设计缰绳。