257 lines
20 KiB
Markdown
257 lines
20 KiB
Markdown
# AI 真能自己写出整个 Windows 系统吗？我做了一场无监督实验
|
||
|
||
**回答者:** Duang
|
||
**日期:** 未知
|
||
|
||
---
|
||
|
||
> [Cursor 团队](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=Cursor+%E5%9B%A2%E9%98%9F&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJDdXJzb3Ig5Zui6ZifIiwiemhpZGFfc291cmNlIjoiZW50aXR5IiwiY29udGVudF9pZCI6MjczMTcyNTIwLCJjb250ZW50X3R5cGUiOiJBcnRpY2xlIiwibWF0Y2hfb3JkZXIiOjEsInpkX3Rva2VuIjpudWxsfQ.E2Id1Y_2QCdeGRmlkuE5IW0cPt6lg6fduRbi_r_Nzlk&zhida_source=entity)用上百个 Agent 跑了几周，产出了 120 万行的 Windows 7 模拟器和 100 万行的浏览器。[OpenAI](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=OpenAI&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJPcGVuQUkiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzMxNzI1MjAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.Xq-iSgUi89a4hi0IBnUwdGroVo-YsNleipW1OUQZnD4&zhida_source=entity) 内部用 Agent Loop 五个月写了 100 万行代码。我决定自己验证一下——造了一个框架，给个种子文件，让 AI 无限跑下去。结果发现，真正的难点根本不在模型能力。
|
||
|
||
|
||
|
||
AutoForge 管线架构
|
||
|
||
## 他们真的在用 AI 写 Windows
|
||
|
||
2026 年初，Cursor 团队发表了一篇 [Scaling Agents](https://link.zhihu.com/?target=https%3A//cursor.com/cn/blog/scaling-agents) 的文章，其中的实验数据相当震撼：
|
||
|
||
• **浏览器**：约 1,000 个文件，超过 100 万行代码，跑了将近一周
|
||
|
||
• **Windows 7 模拟器**：14,600 次 commits，120 万行代码
|
||
|
||
• **Excel 公式引擎**：12,000 次 commits，160 万行代码
|
||
|
||
"上百个 Agent 可以在同一个代码库上协同工作数周"——这是他们的原话。整个实验消耗了数万亿个 token。
|
||
|
||
与此同时，OpenAI 也在自家的 [harness engineering](https://link.zhihu.com/?target=https%3A//openai.com/index/harness-engineering/) 文章中透露：一个 3 到 7 人的小团队，用 [Codex](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=Codex&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJDb2RleCIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3MzE3MjUyMCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.3R9EtMtVTpjyFVWrrEAmoV7khNlBd1p6iFnIsGE1fVw&zhida_source=entity) Agent Loop 跑了 5 个月，合并了约 1,500 个 PR，产出了 100 万行代码——**零手写代码**。
|
||
|
||
社区也没闲着。[OctopusGarden](https://link.zhihu.com/?target=https%3A//github.com/foundatron/octopusgarden) 自称"开源软件暗工厂"，用无限循环生成代码直到满意度达到 95%；[WorkOvernight](https://link.zhihu.com/?target=https%3A//workovernight.com/) 让 [Claude Code](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=Claude+Code&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJDbGF1ZGUgQ29kZSIsInpoaWRhX3NvdXJjZSI6ImVudGl0eSIsImNvbnRlbnRfaWQiOjI3MzE3MjUyMCwiY29udGVudF90eXBlIjoiQXJ0aWNsZSIsIm1hdGNoX29yZGVyIjoxLCJ6ZF90b2tlbiI6bnVsbH0.XJ19kmsFLvKq67oOrWyrw1drkmB3kofiLC8q4aGxxHw&zhida_source=entity) 在你睡觉时自动写代码；[YC W26](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=YC+W26&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJZQyBXMjYiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzMxNzI1MjAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.5QmHyyteqNQBCFnmiAHHeCcLJo68y0-3oqP_eDt_aBc&zhida_source=entity) 的 [Emdash](https://link.zhihu.com/?target=https%3A//github.com/generalaction/emdash) 在做并行 Agent 编排。
|
||
|
||
这些实验看起来相当成功。但如果仔细读 Cursor 那篇文章，你会发现他们也坦承了不少问题：Agent 的注意力会随时间漂移，flat peer-to-peer 协调会导致吞吐量坍缩——20 个 Agent 的实际产出可能只相当于 2-3 个。Agent 在没有层级管理的情况下，倾向于做小而安全的改动，回避真正的难题。
|
||
|
||
我想亲自验证一下：**在完全无人监督的情况下，给 AI 无限的时间，它到底能把一个项目推进到什么程度？**
|
||
|
||
## 两种死法
|
||
|
||
为了回答这个问题，我造了 [AutoForge](https://link.zhihu.com/?target=https%3A//github.com/realDuang/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 万行代码不是模型裸跑出来的。**
|
||
|
||
他们的核心发现是：
|
||
|
||
> "The bottleneck was never the agent's ability to write code, but rather the lack of structure, tools, and feedback mechanisms."
|
||
|
||
换句话说，瓶颈不在模型的代码能力，而在于缺少结构、工具和反馈机制。他们把模型之外的所有这些东西统称为 **harness**——Agent 的"缰绳"。
|
||
|
||
Agent = Model + Harness。模型是马，harness 是缰绳。没有缰绳的马只会乱跑。
|
||
|
||
Martin Fowler 随后在 [Harness Engineering for Coding Agent Users](https://link.zhihu.com/?target=https%3A//martinfowler.com/articles/exploring-gen-ai/harness-engineering.html) 中给出了更系统化的框架。他借用了控制论的概念，把 harness 分为两类控制：
|
||
|
||
• **Guides（前馈控制）**：在 Agent 行动**之前**引导它。比如 CLAUDE.md 配置文件、架构文档、角色定义。
|
||
|
||
• **Sensors（反馈控制）**：在 Agent 行动**之后**检测和纠正。比如 linter、测试套件、代码审查。
|
||
|
||
每种控制又可以是**计算性的**（确定性的，比如跑测试）或**推理性的**（非确定性的，比如让另一个 LLM 审查代码）。
|
||
|
||
简单来说，Prompt Engineering 管的是"问什么"，Context Engineering 管的是"给 LLM 看什么上下文"，而 **Harness Engineering 管的是"整个运行环境怎么设计"**——它是最上层的学科，前两者是它的子集。
|
||
|
||
|
||
|
||
三层学科定位
|
||
|
||
回过头看我的实验，AutoForge v0 的失败原因就很清楚了：不是模型不行，是 harness 压根不存在。我给了 Agent 一匹好马，但忘了给它缰绳。
|
||
|
||
## 给野马套缰绳：AutoForge 的进化
|
||
|
||
想明白这一点之后，我开始系统性地给 [AutoForge](https://link.zhihu.com/?target=https%3A//github.com/realDuang/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](https://zhida.zhihu.com/search?content_id=273172520&content_type=Article&match_order=1&q=Git+Worktree&zd_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJ6aGlkYV9zZXJ2ZXIiLCJleHAiOjE3NzY2NDI1MjUsInEiOiJHaXQgV29ya3RyZWUiLCJ6aGlkYV9zb3VyY2UiOiJlbnRpdHkiLCJjb250ZW50X2lkIjoyNzMxNzI1MjAsImNvbnRlbnRfdHlwZSI6IkFydGljbGUiLCJtYXRjaF9vcmRlciI6MSwiemRfdG9rZW4iOm51bGx9.h5RQPoOFF-ihWydyqul7uu6CXyfZ4Eb1vNkGZabapWo&zhida_source=entity)** 方案——每个 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](https://link.zhihu.com/?target=https%3A//github.com/realDuang/autoforge) 是完全开源的，它实现了上述所有的 harness 机制，可以直接拿来跑实验。
|
||
|
||
## 结语
|
||
|
||
Harness 不是在限制 AI，恰恰相反，它是让 AI 的能力能够**可持续地释放**出来的基础设施。没有缰绳的马跑得很快，但跑不远，也跑不准。
|
||
|
||
模型在快速迭代，各家的能力在趋同。但 harness 的设计——怎么拆分角色、怎么设计反馈回路、怎么对抗收敛、怎么保证质量——这些才是真正需要工程经验积累的部分。
|
||
|
||
OpenAI 给出了 harness engineering 的理论框架，Cursor 提供了规模化实验的数据，而 AutoForge 则是我个人把这些理论落地为可运行框架的一次实践。
|
||
|
||
这个方向还有很多未解的问题：行为正确性的自动验证仍然是最大的难题；harness 本身的复杂度如何控制；随着模型能力增强，哪些 harness 可以逐步拆掉。但至少有一件事是确定的：**未来的 AI 工程师，与其说是在写代码，不如说是在设计缰绳。**
|