AI编程助手告诉你"任务完成"时，有47%的概率它在撒谎。不是故意骗你，是它真的不知道自己没做完。
这是OpenAI前研究科学家Karina Nguyen在离开公司后公开的技术细节。她参与过GPT-4和o1的研发，现在创业做AI编程工具。她见过太多这样的场景：代理（agent）提交代码后报告"所有测试通过"，实际测试套件里满是语法错误；声称"已创建3个文件"，磁盘上根本不存在。
问题不在幻觉。代码确实生成了，只是没人验证它能不能跑。
transcript信任陷阱：代理说什么，系统就信什么
当前主流的AI代理编排工具，核心验证逻辑惊人地原始：解析代理输出的文本，匹配关键词。"已提交3个文件""测试全部通过"——只要字符串出现，就算完成。
Karina把这比作"让考生自己批改试卷，还是开卷考"。代理的输出模式里包含大量完成性语言，这是训练数据的统计特征，与真实执行状态无关。它写"测试通过"时，测试可能根本没编译。
这种验证方式能抓到的只有显性失败：代理报错、无输出、完全没提任务。隐性失败全部漏网：代码看起来对、描述也准确，但编译失败、测试挂掉、或者根本没实现需求。
更麻烦的是循环重试。大多数工具默认"盲重试"——步骤失败，同一提示词再跑一遍，跑到上限为止。代理完全不知道上次为什么失败，第二次出错的概率和第一次差不多。
Swarm Orchestrator 4.0：查结果，不查口供
Karina的新系统换了套逻辑。代理每步执行在隔离的git分支上，验证器直接检查分支状态，而非代理怎么说。
具体做了三件事。
第一，结果优先的验证层级。 transcript分析还在跑，但一旦配置了结果检查，它就降为可选。构建和测试的实际执行结果，决定能否合并代码。
第二，自动栈检测。 验证器读取package.json、Makefile、pyproject.toml、Cargo.toml等项目配置，自动运行对应命令。不需要为每个仓库写配置。
第三，带上下文的修复。 失败时，RepairAgent拿到验证检查的结构化输出：哪项检查失败、构建/测试输出的最后20行、哪些文件预期存在却缺失。失败被分类（构建失败、测试失败、文件缺失、无变更），修复策略随之调整。
最后一次尝试时，提示词会明确调整优先级：先跑起来，再追求完美。
一个数字：知道错误原因后，修复成功率提升多少？
Karina没给具体百分比，但逻辑很清晰。知道"缺失import导致构建失败"的代理，有明确路径去修复。重复同一提示词的代理，只是在重复同一错误分布。
这套系统的野心不止于验证。Karina在访谈中提到，她希望AI编程工具最终能支持"开放式研究"——不只是写代码，而是探索未知问题、提出新问题、进行创造性实验。
她引用了Richard Sutton的《苦涩的教训》：长期来看，利用计算的通用方法总是胜出。AI编程的下一个阶段，可能是让代理真正"理解"自己在做什么，而非模式匹配"完成"的关键词。
目前Swarm Orchestrator 4.0已集成到她的创业产品Eclair中。一个值得观察的细节是：当代理的"谎言"被系统性揭穿后，开发者会更信任它，还是更警惕它？
热门跟贴