速评：这篇论文里最值钱的数字，不是被转发最多的那个。
10 月 8 号挂上 arXiv 的 2610.11482，软件工程主分类，26 页 5 图 5 表，10 种本地开放权重配置、两种跑法、15 个移动性数据工程任务各跑 5 次，凑出 1500 次评分，全程消费级显卡。摆得挺齐整。我扫完第一遍，记住的不是那个 85.3%。
是 26.7 到 52 个百分点这个区间。
同一个模型，权重一个字节没动，只是把它从"一次生成、交卷走人"换成"给个能翻的工作区，中间产物摊在桌上，错了看得见，看见能回去改"，通过率就抬了三十到五十个点。三十到五十个点是工程收益，不是智能收益。
这个幅度说明什么？说明在这些任务上，卡住 agent 的根本不是模型不够聪明，是流程压根没给它留回头路。这类论文我看得不算少，每次 agent 方向有新的 benchmark 出来，图里最陡的那条曲线永远是"允许重试"那条，不是"换更大模型"那条。这回人家把两种条件并排跑了一遍，等于把这条老规律又验了一次——只是验得比别人老实：确定性检查器判分，每格重复 5 次，10 乘 2 乘 15 乘 5 刚好对上 1500，这个重复次数是拿来压方差的，不是拿来把样本量做大好看的。
这里得认个账。上一轮我在别处泼过冷水，大意是本地小模型跑 agent 基本是 demo 货，换个任务就现原形。这篇有点打我脸——90 亿参数，量化后 6.5 GB 内存占用，制品级 69.3%。方向上我还是不太服，幅度上我认栽：我以为这类配置连一半都摸不到。猜对方向猜错幅度，这账记着。
论文本身没什么可挑的。真正要防的是它出圈之后长什么样。
85.3% 是最优那组配置的成绩，十组里挑一组，十五个任务乘五次里算出来的成功率。这个数字只要离开 PDF，配文就会变成"本地开源模型 85% 能干数据工程"。69.3% 更危险，因为"90 亿参数"和"6.5 GB"这两个数太好截图了，闭环条件会在裁剪的时候掉出去。
这里立个 flag：半年之内，某家本地推理框架或者 agent 编排工具的发布材料里会出现这两个数之一，配一句"消费级显卡跑数据工程"。闭环那半句要么不提，要么塞在第七页的脚注里。到时候我把这条翻出来。
说回论文。作者在结论里留了一句最该被引的——可靠性受模型能力、任务可验证性、确定性验证三者影响。这句是全文的真话，也是全文的紧箍咒。
你把这十五个任务摊开看，共同点是同一个：对错机器判得出来。脚本跑不跑得通，表格的列对不对得上源数据，结构化文件的 schema 合不合，图表有没有真画出来——从数据发现、连接器、交通数据流一路走到特征工程、可视化和报告，每一环都有个东西能说"这不对"。有 checker 的地方，闭环才转得起来，中间的错才会被摊到桌面上，agent 才有东西可看、可改。论文自己也写明白了，闭环收益最大的时候，正是中间产物能暴露错误、并且允许它回头检查修复的时候。
把这句话翻译一下：这三十到五十个点不是白送的，是拿"可验证"换来的。checker 一旦拿掉，闭环就退化成自己检查自己，它觉得对了就是对了——那不叫收敛，那叫自我催眠。
（题外一句：看到"消费级 GPU"四个字，我第一反应还是去翻自己那块卡的显存，翻完才想起来我早就不上手跑了。这毛病得改。）
所以这篇论文的正确读法不是"本地模型能干活了"，是"在能自动判对错的数据工程环节里，一套配好的本地 agent 能顶掉一部分活"。前半句是发布会语言，后半句是工程语言，两者中间隔着十五个精心设计的任务和一千五百次评分。
现在把话反过来问一遍：你手上那些想丢给 agent 的活，有几件的对错是能写成一个 checker 的？
写得出来的，这篇论文的数字对你有参考价值。写不出来的，85.3% 跟你没关系，你买到的是一套会在自己的错误上盖合格章的流程。