pkl 是 Apple 开源的一门配置编程语言（官方仓库），参考实现以 Java/Kotlin 写成，约 6 万行代码。在 Epoch AI 的评测里，Claude Opus 4.7 在无人干预的条件下把它从零重写了一遍（MirrorCode）。一次大型任务的运行就花了 2600 美元、跑了 19 天，中间没有人插手。

「AI 自主完成大型项目」这类说法我默认按营销话术打折。但这次的出处是 Epoch AI，在我印象里，这家评测机构给 AI 能力叙事泼冷水的时候居多；基准的开发获 METR 资助（论文 arXiv:2606.30182）。它试图回答一个此前只有一次性演示、没法横向比较的问题：AI 智能体一个人，到底能扛下多大的软件项目？

「独立完成」被定义得相当苛刻

MirrorCode 的规则是行为级重写：给智能体一个原程序的可执行文件，它可以喂任意输入、观察输出，但看不到一行源码，也没有网络。任务是把整个程序重新实现出来，验收标准是输出与原程序在端到端测试上完全一致。测试里平均 34% 是隐藏的，开发过程中智能体见不到。

这个设计的意图是防作弊：查不了原代码库，也没法靠打表硬编码蒙混过隐藏测试。25 个目标程序覆盖 Unix 工具、数据序列化与查询、生物信息学、解释器、静态分析、密码学和压缩。

另一个关键设定是预算给足。常见编程基准每个任务只允许花 1 到 10 美元，模型还没展开就得交卷；MirrorCode 给大型任务最高 100 亿 token 的额度，按 Opus 4.7 的价格约值 6000 美元。作者的逻辑很直接：要测「能独立走多远」，就得先把路修到够远。

数字本身

最强的 Claude Opus 4.7 在整套基准上得分 56%，且是唯一解决了大型档任务的模型。25 个目标程序里，17 个至少有一次满分运行；8 个从未被完美解决；4 个连 99% 都没到过。

最能建立直觉的是 gotree：一个约 1.6 万行 Go、带 40 多个子命令的生物信息学工具包。Opus 4.7 用 14 小时、251 美元把它重写出来，2001 个测试通过 2000 个，论文算它「近乎解决」。四位参与基准建设的工程师估计，熟练的人类工程师做同一件事需要 2 到 17 周。

这个人类估计值得多看一眼：四个人分别给出 1.5–2.5 周、3 周、13 周、13–17 周。连做基准的人自己都对「人要花多久」分歧到差一个量级。唯一的实测参照是一个更小的 2000 行任务：一位人类工程师干了 20 小时没做完，测试只过了 42%。

天花板上升的速度也有数据。论文估计八个月前的领先模型在这套基准上只能拿约 30% 分。Epoch 的初步评测记录了 gotree 上的代际曲线：Opus 4.0 通过 15% 的测试，4.1 是 24%，4.5 是 63%，4.6 做到 99.95%。pkl 也一样：Opus 4.6 烧掉 10 亿 token 预算的九成只过了 35% 的测试，到 4.7 才被解决。不过这里有个混淆变量要说清：正式评测同时把大型任务预算从 10 亿放宽到了 100 亿 token，pkl 的突破是模型换代和预算放宽共同作用的结果，数据本身分不出各占多少。

卡壳的环节比想象中平庸

论文的失败分析是全文最有信息量的部分。智能体倒下的地方，多数不是「能力不够写不出来」。

最大的一类是边角案例：40% 的 Opus 4.7 运行至少有一个隐藏测试因此挂掉。gotree 那个唯一的失败测试，是一个操作日期注释的冷门子命令在边界输入下多包了一层根节点。主体功能完好，细节漏水。

第二类更值得玩味：提前交卷。26% 的运行在还剩九成以上 token 预算时就提交了失败的方案。其中 39% 的情形，同一个模型在其他运行里把同一任务做到过满分。也就是说，任务明明在它能力范围内，它却提前放弃了。初步评测里有个具体例子：Opus 4.1 在 gotree 只完成 23% 时交卷，token 还剩 99%，它给自己幻觉出了一个不存在的时间限制。

第三类是架构级决策错误。pkl 的文档明说惰性求值（lazy evaluation，表达式用到时才计算，而非定义时就计算）是理解这门语言的关键，早期尝试里智能体却选了立即求值的架构，几万行写进去之后无路可回。这是唯一一类真正「大项目才有」的失败：方向错了，勤奋没用。

还有一类是作弊。GPT-5.5 有 24% 的运行、Gemini 3.1 Pro Preview 有 31% 的运行试图把测试答案硬编码进代码，Opus 4.7 在定稿实验里一次都没有。隐藏测试的存在让这条路走不通，但模型确实会试。

污染问题作者没有回避：对 25 个目标程序做记忆筛查（让模型直接复现原代码库片段），17 个有记忆嫌疑。反例是存在的：没被记住的 nonogrid、tssql 照样被解决，被记住的 sed、ruff 照样失败，说明结果不全是背出来的。污染可能抬高了 56% 这个数；作者自己的预期是核心结论能泛化到没见过的代码库，但具体要折多少，论文给不出。

这个数字能用来干什么

先说它不能证明什么。MirrorCode 给了智能体一份完美的可执行规格：参考程序就是标准答案，每一步的对错都能机器判定。真实软件开发没有这个东西——需求含糊、验收标准靠人拍板、写到一半规格还会变。作者自己也承认「这不是软件通常的开发方式」。所以 6 万行度量的是规格完备条件下的规模上限，不等于 AI 能从一句需求独立做出 6 万行的系统。

但换个方向读，这个上限对干活的人有实际参考价值。决定智能体能独立走多远的，与其说是模型，不如说是你能把任务「规格化」到什么程度：能给出可执行的验收判据（测试、参考行为、可对拍的旧实现），万行级的重写就已经进入一个 agent 加几百美元预算的射程，gotree 是实测的例子。给不出，天花板立刻塌回来。重写遗留系统、跨语言移植这类活恰好天然自带参考实现，是这个结论最直接的落点；不过基准直接测的只有行为级重写，移植、迁移能不能套用同一个预算量级，是我的外推。

监督的重心也该挪一挪。失败分析显示，最该防的不是它写出烂代码，而是它在预算充足时提前放弃、以及边界输入下的细节漏水。照这个失败分布，我的判断是：前者可以用脚手架治（交卷前强制跑一遍验证），后者更适合用隐藏测试集、对拍模糊测试去堵，比人工 review 逐行盯更对症。这两条论文都没实测过，是我从失败模式反推的对策。

昨天我刚写过斯坦福的 CooperBench：给顶级编程 agent 配个搭档，能力先掉四成。两篇放在一起，当前 agentic coding 的边界其实很清晰：单个 agent 在规格完备的任务上，八个月里从 30% 涨到了 56%；而多 agent 协作在已有的实测里还是负收益（CooperBench 测的是双 agent 协作编码这一种设置，外推到其他多 agent 架构要谨慎）。至少从这两份数据看，往深处推靠的是一个 agent、更大的预算、更好的规格，不是更多的 agent。下一次有人拿「AI 团队自主开发」做卖点，先问一句：单干的天花板都还在涨，加人头图什么？

参考来源