当AI管理AI：谁来给写代码的机器人当经理？

2026年的今天，AI写代码这件事已经不新鲜了。你打开一个编程助手，扔给它一个任务，它就会开始翻代码、跑测试、改文件，一步步把活干完。

但有一个问题越来越明显：这些编程助手现在很少是被人一步步盯着的。

更常见的做法是，开发者搭一个"循环"，让这个循环自动决定编程助手每一步该干什么、什么时候该停。这个做法有个专门的名字，叫**循环工程**。

Loop Engineering：一种围绕编程智能体组织开发工作的实践方式，不再是人工逐条写提示词，而是设计一套自动化流程来监督进度、分配任务、运行检查、决定下一步。

这套流程听起来挺美好，省心又高效。但DreamX团队的研究者们盯上了一个被大家忽略的漏洞：如果最后任务失败了，到底是编程助手能力不行，还是这套"循环"本身指挥错了？

这个问题乍一看有点抽象，但换个场景你就懂了。假设你请了一个装修工人，又雇了一个包工头来指挥这个工人干活。最后房子装修得一塌糊涂，你能立刻判断出是工人手艺差，还是包工头瞎指挥吗？大概率不能，因为你只看到了最终结果，中间谁的责任大你根本分不清。如果不把这两者分开评估，你永远没法对症下药，工人可能被冤枉背锅，真正瞎指挥的包工头却全身而退。

这正是这篇论文想解决的核心矛盾。研究者们提出了一个叫**LoopArena**的评测基准，专门用来回答一个问题：一个模型指挥另一个编程智能体干活的能力，到底怎么样？

核心问题：谁在给谁打工

在LoopArena的设定里，出现了两个角色。

一个叫**Controller**：也就是被测评的那个模型，它不亲自写代码，只负责看报告、下指令、决定继续还是收工。

另一个叫**Worker**：也就是真正干活的编程智能体，它是固定不变的，每次评测都用同一个Worker，这样才能确保结果的差异来自Controller，而不是Worker换了个更强或更弱的版本。

这个设计的关键在于"控制变量"。研究者们把coding领域一个长期存在的评测盲区暴露出来了：以前的编程基准测试，比如著名的SWE-bench，衡量的都是"整个系统"跑完一个任务后行不行，从来没人单独把"指挥官"的水平拎出来量化。

SWE-bench：一个广泛使用的编程智能体评测基准，通过让AI解决真实的GitHub issue来打分，衡量的是整个编程系统的端到端能力。

这就好比一场足球比赛，你只看比分，却从来不单独评价教练的临场指挥水平和球员的个人能力谁更该背锅。而LoopArena要做的，就是把"教练"单独拎出来打分。

那么具体怎么打分？研究者设计了三种互补的评测方式，分别对应不同的执行成本和评测精度。这三种方式共同构成了这篇论文最核心的方法论创新。

三种测试方式：从便宜到贵，从局部到全局

第一种叫**Type I：合同选择**。

在某个任务执行到一半的关键节点上，Controller会拿到一份关于当前进度的结构化摘要，然后面对四个候选指令选一个，选完就完事了，不需要真的跑代码去验证。

这里有个巧妙的地方。这四个候选指令里，正确答案不是研究者事先拍脑袋定的，而是提前把这四个候选指令都拿去真跑一遍，看哪个指令带来的最终结果最好，那个才是"标准答案"。

这就好比考试出题的人，先把四个选项都实际操作了一遍，用真实结果确定哪个是对的，再把这道题拿去考学生。学生做题的时候不需要重新操作一遍，直接选就行，省下了大量时间和计算资源。如果不这样提前验证，那出的题目本身可能就是错的，你测出来的"正确率"根本没有意义。

Loop Contract：Controller下达给Worker的一份结构化指令，里面规定了下一步该干什么、什么时候该停、需要满足哪些条件。

第二种叫**Type II：任务切片**。

这次是真刀真枪地跑，但只跑一个任务的某一段，比如从"已经写了一半代码"这个中间状态开始，让Controller指挥Worker把剩下这一段搞定。

第三种叫**Type III：完整任务**。

这是最贵最全的测试，从任务最原始的状态开始，一路指挥到底，覆盖从最初的探索、到实现、到验证、再到最终决定"收工"的全过程。

这三种设置有一个精妙的设计，Type II和Type III用的是同一批任务，只是切片的长短不同。这样就可以直接对比：用便宜的Type II测出来的排名，和用昂贵的Type III测出来的排名，是不是一致的？如果一致，以后就可以只用便宜的Type II来省钱评测了。

结果发现，两者的排名相关性达到了0.9747（这是一种叫Spearman等级相关系数的统计指标，1代表完全一致），而Type II平均能省下64.4%的推理成本。这意味着大部分情况下，你不需要每次都跑完整任务来验证一个Controller模型好不好，跑个切片就基本能看出苗头了。

这就像医生看病，有时候不需要把你全身做个核磁共振，抽个血化验一下关键指标，就能大致判断出问题在哪。当然，抽血不能代替所有情况的诊断，但对于大部分常规问题，它足够便宜也足够准。

Reporter：一个临时创建的报告员角色，它读取Worker的对话历史，用只读方式检查代码仓库当前状态，写出一份关于任务进展、已完成工作、验证证据、待解决问题的四段式摘要，本身不能改代码也不能执行任何操作。

Evidence Packet：由系统自动整理好的、给Controller看的结构化报告，里面包含Reporter写的摘要和它引用的关键对话片段。

这里有个细节值得单独说一下。Reporter每次生成报告的时候，用的是一份"临时对话副本"，不会污染Worker原本持续进行的对话记录。这个设计的用意是让报告这件事本身不影响正式的工作流程，就像医院里的护士记录病历，不会因为记录这个动作本身改变了病人的病情。

评测结果：24.69%，这就是目前最好的水平

论文里公布的实验结果相当扎实，也相当"打脸"。

研究者测了五个主流模型当Controller，包括Qwen3.7-Plus、DeepSeek-V4-Flash-0731、GLM 5.2、GPT-5.5和Claude Opus 4.8。

在最难的Type III完整任务测试里，表现最好的GPT-5.5的**严格成功率**（Strict Success Rate，简称SSR，指一次运行既通过评测又符合控制协议才算成功）只有24.69%。也就是说，即便用了当前最强的模型来当"指挥官"，指挥一个编程智能体从头到尾把一个真实任务做完美，成功率也不到四分之一。

这个数字乍一看不算震撼，但对比一下就明白它的分量了。研究者还设置了两个对照组。

一个叫**无控制**（No control）：Worker接到任务后完全自主运行，没有任何外部指挥。

另一个叫**固定控制**（Fixed control）：受Codex的"/goal"命令启发，每次到了决策点，系统就死板地重复一遍原始任务目标，让Worker继续干，完全不管当前实际进展到哪一步了。

结果发现，固定控制这个"死脑筋"策略，在Type II（切片任务）上把成功率从39.51%拉到了46.91%，看起来还有点用。但一到Type III（完整任务），固定控制的成功率是18.52%，和无控制的18.52%完全一样，一个百分点都没提高。

这个对比说明了一件很重要的事情。在短任务里，反复提醒一下"你的目标是什么"多少有点用，就像考试的时候监考老师隔一会儿喊一句"还有半小时"，能让人集中精神。但对于长任务，这种死板的重复完全无效，因为真正需要的不是重复目标，而是根据当前进展灵活调整下一步该干什么，是继续写代码、还是先去验证一下之前的工作有没有漏洞、还是干脆就该收工了。

这就好比爬一座很高的山，向导如果只会不停地喊"我们要爬到山顶"，这句话在半山腰有用吗？没用。真正有用的向导，得会看你现在体力怎么样、天气有没有变化、这条路是不是走岔了，然后临时调整路线。光喊口号的向导，跟没有向导差不多。

这也是这篇论文最核心的发现之一。

有效的循环控制必须能感知并适应任务的实时状态，而不是机械地重复一个静态目标。

再看看Type I的结果。这五个模型选四选一的**合同准确率**（Contract Accuracy）在72.22%到87.78%之间，GPT-5.5最高，达到了87.78%。研究者还特意测了几种"作弊式"的简单策略，比如完全随机选、只看选项长度、看文字重合度这些方法，结果这些偷懒策略最高也只能到31.11%的准确率，远远低于所有测试的模型。这说明，模型确实是在真正理解任务进展和候选指令的内容，而不是靠某种表面规律蒙对的。

成本的账，也得算清楚

这篇论文还有一个容易被忽略但很重要的贡献，就是把"推理成本"这件事量化了。

研究者用各家厂商公开的标准定价，把每次调用消耗的token数换算成美元，统计出了每种Controller模型完成一次任务平均要花多少钱。

结果显示，GLM 5.2在成本上最省钱，Type II只要1.63美元一次，Type III也只要4.86美元。而表现最好的GPT-5.5成本最高，Type III跑一次要18.84美元，是GLM 5.2的将近4倍。

这里就出现了一个很现实的权衡：花更多钱能不能换来更高的成功率？GPT-5.5虽然成功率最高（24.69%），但成本也最高（18.84美元/次）；GLM 5.2成功率最低（16.05%），但成本也最低（4.86美元/次）。这意味着在实际部署时，选择哪个模型当Controller，不能只看谁跑分最高，还得算算这笔投入产出比划不划算。

这就像请私人教练健身，最贵的教练不一定练出的效果比中等价位的教练好20%那么多，你得看自己的预算和实际需求来选。

论文里还有个挺有意思的细节，DeepSeek-V4-Flash-0731和GLM 5.2这两个相对便宜的模型，有相当比例的回复会撞到输出长度上限（也就是Controller一次能说的话有个字数限制），撞上限之后这次任务就直接判定失败了。数据显示，在使用DeepSeek或GLM当Controller的167次评测里，有77次至少发生过一次撞上限的情况，占比高达46.11%。这说明便宜模型省钱的代价之一，可能是话说不完就被系统掐断，从而丢掉了本该拿到的分数。

这个思路后来被怎么用了

这篇论文发表于2026年8月，虽然时间还很新，但它提出的"把指挥能力和执行能力分开评测"这个思路，已经能看到它和此前几项工作的呼应关系。

比如论文提到的**LoopsBench**（Li et al., 2026年发布），研究的是"从Harness工程到Loop工程"的转变，比较的是不同编码模型和不同循环实现方式的组合表现，跟LoopArena的角度不完全一样，但都指向同一个大趋势：循环本身的设计，正在变得和模型能力一样重要。

再比如**ManagerWorker**这项研究（Liu, 2026年发布），探讨的是"一个AI模型能不能指挥另一个AI模型"这个更根本的问题，把组织结构本身当作探测训练局限性的一个切入点。这和LoopArena的核心假设是一致的：指挥别人干活，和自己亲自动手干活，需要的是完全不同的能力。

还有一项叫**LongHorizon-Harness**的工作（Ma et al., 2026年发布），提出了一种"管理者-执行者-审计者"三角色循环，用来处理长任务的状态管理问题，这跟LoopArena里Controller、Worker、Reporter的三角色设计有异曲同工之处，都是想办法把"干活"和"管理"这两件事从架构层面拆开。

写在后面

读这篇论文的过程中，最让我意外的一点，是"固定控制在长任务里完全失效"这个结果。

我原本以为，哪怕是死板地重复目标，多少也该有点用处，毕竟"提醒任务是什么"听起来总不是坏事。但数据摆在那里，18.52%对18.52%，一个百分点的差距都没有。这说明在真实的长期任务里，"重复"这个动作本身可能是没有信息增量的，甚至可能是一种噪音，因为它没有根据实际进展给出任何新的判断。

另一个让我停下来想了一会儿的细节，是那162次"撞到输出上限"的Controller调用。这些失败不是因为模型判断错了，而是因为它话还没说完，指令就被系统硬生生截断了。这种失败方式挺有意思的，它提醒我们，很多时候AI系统的短板不在于"想得不够好"，而在于工程层面的一些边界条件设置，比如输出长度这种看起来很技术性、很不起眼的参数，反而成了决定成败的关键因素之一。

论文里还有一个我觉得值得单独拎出来的地方，就是那个替换掉的Django依赖包的例子。四个候选指令里，正确答案不是"删掉一个还在被使用的依赖"，也不是"保留这个已经没用的依赖再检查一遍"，而是"删掉那个已经没人用的孤立依赖，同时保留其他正在使用的配置"。这个例子特别真实，因为它反映的正是软件工程里最常见的一种陷阱：表面上看起来"清理干净了"的操作，很可能误删了还在被使用的东西，而真正正确的做法，需要对整个系统的依赖关系有精确的理解，不能只看表面。

这篇论文最后留下的问题，其实比它回答的问题更让我好奇：如果连GPT-5.5这样的模型当指挥官，成功率也只有24.69%，那到底是什么东西还没被解决？是模型对"进展是否真实"的判断力不够，还是它压根就缺乏那种能感知任务全局节奏的直觉？这个问题，恐怕要等下一篇论文来回答了。

Q&A

Q1：LoopArena是什么？

A：LoopArena是DreamX团队提出的一个评测基准，专门用来测试一个AI模型指挥另一个编程智能体完成长任务的能力，而不是测整个系统端到端的表现。

Q2：为什么固定重复任务目标的策略在长任务里没用？

A：论文实验显示，固定控制策略在完整任务上的成功率是18.52%，和完全不加控制的无控制策略完全一样，说明机械重复目标不能提供任何有效的实时判断，长任务需要的是能根据当前进展灵活调整的指挥。

Q3：目前表现最好的Controller模型成功率是多少？

A：GPT-5.5在完整任务测试中表现最好，严格成功率为24.69%，是所有测试模型中的最高值，但整体来看长任务的循环控制能力仍有很大提升空间。