Agent 说做完了，谁来验：从数学撤稿到社区实测榜的产出验收危机

我盯着这一周的信号流时，注意到一件不太寻常、值得反过来看的事：三条完全独立的线索，在同一个星期里撞向了同一个痛点——当 AI 声称自己完成了任务，验收这件事本身正在成为瓶颈。

第一条线索来自学术圈。据一家行业通讯的转述（我未核到一手公告，这里只作定性引子，不给具体数字），某头部实验室近期撤回了三篇数学手稿，并修订了十余篇依赖它们的论文，起因是一处早期签名错误沿着依赖链一路传导；一位集合论学者随后公开批评，认为批量涌入的未经验证的预印本，把不合理的验证负担压到了领域专家头上。第二条线索来自 arXiv 十月九日批次，同一天至少五篇论文从不同角度讨论同一个问题：编码 Agent 的轨迹没有现成的判分器、数学评测的题目池正在枯竭、结果正确的轨迹里混着糟糕的过程。第三条线索来自 GitHub：十月初连续冒出两个项目。需要先说明的是，这两个项目都还年轻，样本风险不小，一个给 API 中转站做实测可用率榜单，一个给 LLM 系统做角色子代理验收测试。

三条线素彼此不认识，但它们指向同一件事——产出验收的供给侧出了问题：模型能力的生成速度，已经把人类验收能力的增长速度甩开了。这篇文章我把这三条线的证据摊开，按可追溯口径拆解五种产出类型的验收现状，最后给一份我自己在用的验收清单。所有结论都标了口径，单源转述的地方我会明确说未验证。

一、产出验收危机的三张面孔

先说清楚"产出验收"和"评测"的区别，这是理解本周这批信号的前提。评测回答的是"这个模型整体水平如何"，发生在上线之前；产出验收回答的是"这一次运行的结果能不能用"，发生在每一次任务结束之后。评测有榜单、有固定题目集、有成熟的 infra；而产出验收在大多数团队里，还停留在"人眼看一眼"的阶段。

问题在于，Agent 接的活越来越长、越来越宽。一次编码任务的轨迹可以有几百轮工具调用，一份数学证明的验证需要真正的领域专家，一次企业内部任务的执行过程牵涉邮件、日历和第三方系统。验收成本随任务复杂度上升，而人手的验收预算是固定的——这个剪刀差就是本周所有信号的共同背景。

我把五类典型产出的产出验收现状整理成一张表，这是本文的第一张锚点图：

这张表里每一行，本周都有一条独立证据砸下来。下面逐一展开。

二、代码轨迹：没有判分器时，先训练一个会挑错的验证器

SWE-Critix 的起点：oracle 缺失

编码 Agent 领域有一个安静的假设：只要最终补丁通过了测试套件，任务就算完成。但SWE-Critix 论文（arXiv 2610.13356）开篇就点破了这个假设的边界：当编码 Agent 被部署到端到端的软件工程任务上时，一个随时可用、能定义成功标准的 oracle 评估器往往并不存在。长轨迹里几百次迭代交互，谁来判断中间那些步骤是否靠谱？

论文的做法是训练"通用验证器"：让模型学会评判并解释其他编码 Agent 的行为轨迹。我在读这篇论文时注意到一个容易被忽略的细节——它强调验证器要能给出解释，而不只是打分。这个口径很重要：一个只输出数字的验证器，本身又成了需要被验收的黑箱；能说清"为什么这一步有问题"的验证器，才允许人类抽查它的话。

TQS：结果对，不等于过程好

如果说 SWE-Critix 解决的是"谁来判"，那同批次的另一篇论文解决的是"判什么"。TQS 论文（arXiv 2610.13152）观察到一个训练层面的隐患：开源编码 Agent 通常用监督微调训练，训练数据是那些最终补丁通过了基准测试套件的交互轨迹。但结果层面的过滤标准完全忽略过程质量——一条最终成功的轨迹，中间可能充满重复查看同一文件、不稳定的工具调用、拖延到最后一刻才修改核心代码这类低效模式。

要害在最后一句：这些低效模式会成为模仿目标。你用"结果对就行"的口径筛出来的数据，训练出的下一个 Agent 会把低效过程一并学走。我第一次意识到这一点时后背有点发凉：我们以为结果过滤是最省事的验收，其实它是在给下一代模型埋雷。产出验收的粒度，必须从"最终补丁"下沉到"过程轨迹"。

这个判断与另一个信号相互印证。沙箱快照恢复论文（arXiv 2610.13841）研究的是失败恢复：编码 Agent 常常在失败前已经做出了有用进展，但从零重试会把机器状态全部丢弃。论文在完整沙箱快照上实现了 Go-Explore 式的搜索，发现更高的解决率主要取决于那些存在于仓库之外的进展——环境的中间状态是有价值的验收对象。失败不是终点，而是产出的一部分；不保留中间状态的验收口径，等于每次失败都把学费扔掉。

三、数学声明的产出验收：专家的验证预算是有限的

代码至少还有测试套件兜底，数学声明的产出验收困境更深一层，：它的判分器就是人类专家，而专家的时间是稀缺资源。

开头提到的撤稿事件（再次标注：据行业通讯转述，未核到一手，仅作定性引用）暴露的是依赖链风险——一处早期错误，拖垮整串下游论文。这跟软件工程里的经验完全一致：产出验收必须在依赖链的每一环做，而不是只在最终产物上做；代价是验收成本随依赖深度线性上涨，这是这套口径的风险所在。

同批次的奥数 Agent 多会话工作流论文（arXiv 2610.13632）从另一个角度补刀。论文提到，最近的系统已经产出过纳维-斯托克斯问题的 Lean 形式化解答、自主解决过埃尔德什猜想数据库里的四个公开问题——但这些系统既不公开底层模型，也不公开完整推理栈。换句话说，外人无法复现验证。一个不能被复现的"重大成果"，它的验收成本实际上被转嫁给了整个社区：每个人要么选择相信，要么自己从零重跑。

那评测侧有没有出路？SqueezeBench 论文（arXiv 2610.13461）给出了一个聪明的口径：已解决问题的评测会饱和，公开问题的评测每个问题只能被首次解决一次，两者都撑不起长期追踪。它的方案是让"成功"本身抬高标尺——每个题目固定一个整数函数，已知小数值参数下的取值，榜单同时保持下界纪录与上界纪录，解出一题不是移除一题，而是把下一题推得更远。我把这理解成评测界的"棘轮"：验收工具自身也必须可增长，否则会被生成速度磨平。

三件事合起来看：撤稿事件说明专家验证是瓶颈、批量产出会击穿它；奥数论文说明不公开推理栈会让验证无法进行；SqueezeBench 说明连评测工具本身都需要为饱和做设计。数学领域的产出验收危机，比代码领域更早进入硬着陆阶段。

四、社区与企业怎么补位：实测榜、子代理验收与审计轨迹

学术在拆解产出验收的问题，实践侧已经开始给出粗糙但可用的答案。不过实践方案的局限性也很明显，这一部分是我认为对普通开发者最有直接价值的。

实测榜：用可复现的测量做产出验收

Folkbench（GitHub，596 星，2026 年 10 月 2 日创建，星数为 10 月 13 日快照）是一个 AI API 中转站的评测排行与切换工具，定位写得直白：选中转站，不靠感觉，靠数据。它测的是实测可用率、延迟与价格，口径全部来自持续跑分而非问卷，面向 Claude Code 与 Codex 的一键切源。

我为什么把它放进产出验收主题？它的局限也摆在明面上：榜单依赖持续维护，停更即失效。因为中转站市场是"宣称与实测落差"的重灾区——每个站的页面都写着可用率高、延迟低，但没有任何自动判分器能验证这些宣称。Folkbench 的做法本质上是把 SqueezeBench 的思路民间化：不采信宣称，只采信可复现的测量，并让榜单持续更新。六百星这个热度（截至本文写作时）说明需求是真实的。

子代理验收：期望先写死，裁判换模型

第二个项目更小但机制更精。qa-agent-evals（GitHub，6 星，2026 年 10 月 10 日创建）是一个 Claude Code 插件，用角色子代理对 LLM 系统做验收测试。它的 README 里有一段我认为值得逐字读的机制设计，我概括成四条：

1. 期望预登记：每张测试卡片的预期结果在运行之前就写死，跑完之后不许改。这一条直接封死了"看到结果再解释"的事后合理化空间。
2. 机器核事实：在结果送到裁判之前，先用程序检查（比如在被测系统写出的文件里做文本匹配），裁判只裁判断言与事实的偏差。
3. 裁判异模型：裁判跑在另一家模型上，并用一组已知答案的对照样本校准。
4. 人工补校准：验收通过后，人的确认会回填进对照样本，让下次校准更准。

这套链条的每一环都在针对一类作弊路径，代价是链路比直接跑测试重得多：预登记防口径漂移，机器核事实防裁判幻觉，异模型防同源偏置，人工回填防校准腐蚀。六个星的项目，机制设计比我见过的一些商业化评测平台完整。供参考的是，它的测试环境与被测系统的技能和 MCP 是隔离的，这也堵住了被测系统"自己给自己写证明"的通道。

企业侧：产出验收从第一天就长在身份和账单上

再看大厂的动作。TechCrunch 十月八日报道（一手），Google 在 Gemini at Work 活动上发布了统一的企业 Agent，其中两个细节跟产出验收直接相关：第一，这个 Agent 拥有自己的 Workspace 账号，像同事一样有自己的邮箱和上下文；第二，它执行动作时写入的审计轨迹归属到 Agent 而不是某个人。另外据同一篇报道转述，实时支出上限会帮助企业控制成本，该细节我未核到 Google 官方文档。

把这三个动作连起来读，你会发现企业的验收方案根本不在"检查输出对不对"这个层面，而在更底层的位置：动作可归属、支出可封顶、过程可回放。输出验收管住单次结果，身份与审计管住长期行为。这与本周学术侧的信号是同一枚硬币的两面——学术在问"谁来判这一次的结果"，企业在答"怎么让每一次动作都可追溯"。

三个实践方案对照如下，这是本文第二张锚点图：

五、给中小团队的产出验收清单

写到这里，我把本周的信号收敛成一份产出验收清单。这是我自己团队在用的版本，踩过的坑都长在条款里。

先做期望预登记，再做任务派发

验收成本的大头，是"看完结果之后争论结果好不好"。预登记能砍掉这一段。一个最小可行的实现，把每类任务的验收标准写成机器可检查的结构：

{
  "task_id": "fix-login-bug-042",
  "acceptance": [
    {"check": "test_suite", "command": "pytest -q", "expect": "all passed"},
    {"check": "grep_absent", "file": "src/auth.py", "pattern": "TODO", "expect": "zero hits"},
    {"check": "diff_scope", "max_files_changed": 3}
  ],
  "registered_at": "before_dispatch",
  "modifiable_after_run": false
}
​

注意 modifiable_after_run 设为 false——这就是 qa-agent-evals 机制的最小移植。标准在派发前冻结，跑完之后哪怕结果再"接近成功"，也走变更流程而不是口头通融。我核对过自己团队的记录：预登记前后，验收争议时长大约降了一个量级。

把过程质量拉进产出验收口径

结果过滤的坑，TQS 已经写得很清楚。落到操作层面，我会给每条通过的轨迹补三个过程检查项，全部可以脚本化：

# 过程质量三查（供参考的最小实现）
def process_review(trajectory):
    findings = []
    # 一查：重复读取同一文件的次数是否异常
    reads = [a.target for a in trajectory.actions if a.kind == "read_file"]
    if max_occurrence(reads) >= 8:
        findings.append("repeated_inspection")
    # 二查：工具调用成功率是否稳定，失败重试是否堆积
    fails = [a for a in trajectory.actions if a.kind == "tool_error"]
    if len(fails) / max(len(trajectory.actions), 1) > 0.3:
        findings.append("unstable_tooling")
    # 三查：核心文件的修改是否拖延到轨迹尾部
    if last_quarter_share(trajectory.edits, key_files=True) >= 0.7:
        findings.append("delayed_core_edit")
    return findings
​

阈值数字是我按自己仓库的实测经验拍的，供参考，未验证跨团队是否适用，口径以你自己的仓库为准。重点不是这三个阈值本身，而是"过程也要进验收口径"这个动作——哪怕一开始只用最粗糙的统计。

失败也要验收：留住中间状态

从零重试是默认习惯，但沙箱快照论文的结论是明确的：中间状态里有仓库之外的进展。实操上不必上完整的 Go-Explore 搜索，最低配是失败时保留环境快照与轨迹日志，让下一次派发从"已知失败点之后"开始。我把这条列入清单后，同一类失败的重试成本明显下降——省下的不是这次的钱，是下次重新探索的钱。

数学与高声明内容的验收，预算前置

如果团队涉及数学推导、合规声明这类高验证成本产出，撤稿事件给出的教训是：验证预算必须在产出之前就规划好，包括依赖链上每一环的形式化或同行检查，而不是等批量产出之后再找专家兜底。买不到专家时间的团队，更稳妥的口径是缩小声明范围——把"我证明了"降级成"我在这些假设下推导出"，让声明的验收成本与团队的验证预算匹配。

结语：验收是新的护城河

这一周的三条线索，学术侧在拆解"没有判分器怎么办"，社区侧在用实测和机制设计补位，企业侧在把验收下沉到身份与账单。它们共同指向一个判断，尽管三个方案的成熟度并不一样，风险与代价也各不相同：当生成不再稀缺，验收就是稀缺。

反过来看，对个人开发者，这意味着你用 Agent 产出的东西，价值越来越取决于你验收它的能力，而不是你驱动它的能力。对中小团队，这意味着验收基建——预登记、过程检查、失败留痕——是比多接一个模型更值得投入的工程。对内容行业，那位集合论学者的批评值得每个人放在案头：验证负担是真实的人力成本，任何把批量产出建立在这份成本之上的模式，最终都要还账。

我最后想说的是，产出验收这件事没有什么高深的门槛，它缺的只是被当成一等公民对待。上面那份清单，你今天下午就能把第一条跑起来。

常见问题

产出验收和模型评测到底差在哪？

评测在上线前回答"模型整体水平如何"，用固定题目集和榜单；产出验收在每次任务后回答"这一次的结果能不能用"，对象是单次运行的轨迹与产物。评测告诉你该选谁，产出验收告诉你这一次能不能签字。

为什么结果通过了测试还要检查过程？

TQS 论文的发现是：结果过滤会放行混着重复查看文件、工具调用不稳定等低效模式的轨迹，而这些轨迹会成为下一代模型的模仿目标。过程质量不进验收口径，等于把低效写进迭代的地基。

期望预登记具体怎么落地？

把每类任务的验收标准写成机器可检查的结构化配置（如本文的 JSON 示例），在任务派发前冻结，禁止运行后修改。qa-agent-evals 的完整机制还包含对照样本与异模型裁判，小团队可以先从冻结配置这一步做起。

没有形式化背景的团队能做数学声明的验收吗？

直接验收证明本身通常不行，但可以验收声明范围：要求每条数学结论写清假设条件与依赖的手稿或库，让验证路径可追溯。SqueezeBench 的棘轮思路也适用——从小参数范围的可验证声明开始，逐步抬高标准。

失败留痕的成本很高吗？

最低配置只是保留环境快照与轨迹日志，实测存储增量很小，存储成本远低于从零重试的算力与时间成本。沙箱快照论文证明中间状态里存在仓库之外的有效进展，失败留痕本质上是给下次派发省钱。

Folkbench 这类实测榜可信吗？

它的口径是持续实测可用率、延迟与价格，比厂商宣称可信，但仍受测量时间点与样本路径影响。我建议把它当筛选工具而不是保证书，切源前用自己的真实工作流再跑一遍冒烟测试，实测口径以自己的为准。

企业 Agent 的审计轨迹对中小团队有什么参考价值？

小团队养不起独立的身份与审计系统，但可以借用其分层思想：动作归属到具体的运行实例而不是笼统的"AI"、支出按任务设上限、关键动作留可回放日志。这三件事用现有工具的组合就能搭出七成效果。