模型拿到65分，为什么还不能替你交付工作？

把一个任务交给 Agent，最让人上头的时刻，往往不是它写出第一段像样的代码，而是它开始自己找资料、开文件、拉数据、把一堆散乱的东西整理成一份看起来能交的结果。

这时候很容易冒出一个念头：既然它已经能做这么多，是不是可以把整件事直接交掉？

Epoch AI 最近把这个念头拿去做了一个不太客气的实验。他们没有再给模型一套收敛得很漂亮的公开题库，而是把图表设计、数据洞察、数据探索、AI 数据中心研究、研究设计这些日常工作塞进 Agent 的上下文里，再用同一套员工交付标准打分。公开报告里，Claude Fable 5.1 和 GPT-6 Astra 的平均成绩都是 65%。

数字不低，甚至会让不少团队开始算人力账。但 Epoch 给出的解释很重要：65% 指的是模型满足了约 65% 的评分项。它不是“这份工作完成了 65%”，更不是“公司可以少配 65% 的人”。在那套标准里，能放心自动化的门槛是 100%。

图：Epoch Automation Reports 的任务评分。最高平均分为 65%，原图与任务口径见 Epoch 公开报告。

这个结论不是在给 Agent 泼冷水。相反，它把很多团队已经遇到的尴尬说得很准确：模型可以把一项工作推进得很远，但交付最难的那一小段，常常正好落在“有没有看出前提错了”“这个结果能不能给客户看”“失败时该停在哪里”上。

65 分不是一条自动化进度条

如果把一项工作拆成一张清单，模型先拿下格式固定、规则清楚、可以快速验证的条目，很自然。它能跑脚本、补字段、做汇总、给出几个研究方向。清单上看起来已经涂掉了很多格子。

麻烦在于，剩下的格子未必和前面一样重。一个没有被发现的配置错误，就足以让整项结论失效；一张信息塞得太满的图，也足以让读者错过真正该看的信号。清单完成率不会自动告诉你这些格子的后果差了多少。

Epoch 的研究设计试跑就是一个很具体的例子。GPT-6 Astra 给被评估模型设定的 token 预算太低，造成 22% 的运行没有返回答案，随后却把这个现象当成了被评估模型的能力结论。它不是不会执行，而是没有把“实验设置是否合理”当成需要先复核的前提。

这类错很像线上排障时把超时、限流、脏数据和真实业务异常混在一张监控图里。图表照样有，结论也能写，只是它们不能直接进事故复盘，更不能拿去改策略。模型最危险的地方，有时不是停住，而是很顺地把错误前提一路推到一份完整报告里。

真正该拆的是交付门槛

把任务按“模型能做什么”分配，通常会得到一张越来越长的功能表。更有用的切法是按“什么状态可以交付”分层。

第一层是边界清楚、可逆、可以程序化验收的动作。比如固定格式的数据清洗、已有模板的周报初稿、字段完整性检查、重复计算、已定义规则下的分类。这类任务不必等模型在所有地方都完美，关键是让它的输出有明确的校验器和回滚路径。通过校验，才算完成；没通过，就回到队列里，不要把它包装成“差不多好了”。

第二层是模型可以大幅提速、但人仍需对质量负责的动作。设计图表、归纳开放反馈、整理研究方向、写给外部读者的分析，都属于这一层。模型可以先展开多个方向、找引用、整理差异，甚至把第一版图做出来；人要保留判断重点、选择证据、删掉噪音的权利。这里最值钱的不是一键通过，而是把人工复核从“重新做一遍”变成“只看真正有风险的地方”。

第三层是错一次就很贵、很难撤回，或者必须承担责任的动作。改生产配置、提交合同、删除数据、给客户发送最终承诺、把研究结论变成决策依据，暂时都不该因为一个平均分变高就直接放行。模型可以准备材料、提出建议、把风险项标出来，但最后的提交权需要落在有上下文、能说明理由的人身上。

这三层不是权限表演。它会直接决定一个 Agent 项目是“越用越省事”，还是“每次都得盯着它收拾残局”。也会让团队把预算花在更容易验证的环节，而不是把所有希望押在一次漂亮演示上。

图：按验收与回滚成本划分的Agent交付边界。本文根据Epoch报告的任务观察整理。

先写一张交付卡，再谈全自动

如果团队正在挑一个工作流给 Agent 试点，可以先不要问“它能不能做完”。把任务改写成一张很朴素的交付卡，很多模糊期待会自动浮出来。

任务：汇总本周客户反馈，产出产品问题清单
完成条件：每条问题都有来源、去重规则和负责人字段
自动通过：字段齐全，来源可追溯，重复项低于既定阈值
转人工：出现新类别、证据互相矛盾、涉及价格或承诺
禁止动作：不发送给客户，不改工单优先级，不删除原始反馈

这不是为了把 Agent 管成一个只会填表的实习生。恰恰相反，门槛写清之后，它才能在边界内跑得更快。否则，模型会努力猜你的“差不多”，而人会在最后一公里重新接管所有判断，自动化只留下一个很好看的演示。

交付卡还有一个好处：它能把评测从“模型 A 和模型 B 谁更聪明”拉回真实问题。你能记录的应该是每一层任务的通过率、人工退回原因、平均复核时长、失败能否回滚，而不是只记一次会话是否给出了流畅回答。这样跑几周，团队才知道该补模型、补工具、补上下文，还是补一个本来就缺失的验收规则。

高分模型也要看它卡在哪里

Epoch 的结果里，模型在编码和数据分析等定义清楚的任务上表现更好；在设计、从样例里辨别风格、提出并检验研究方案这些开放任务上更容易失手。图表设计任务中，模型拿到了多份 Epoch 风格样例，仍做出一张信息过满、重点不清的图；人类设计师的版本更干净。

这张图值得贴在所有“让模型自己做完”的讨论旁边。模型不是没得到上下文，也不是没产出内容。它卡在了信息取舍：哪些数据应该留，哪些应该删，读者到底要先看到什么。代码审查、研究分析、产品方案里也有同类问题，只是它们不一定长成一张图。

所以，评测时别只问“平均分是多少”，还要追问三个问题：它错在哪里？这个错能否自动发现？发现之后，谁有权把它退回去？前两个问题决定成本，最后一个问题决定事故会不会发生。

别把一场评测当成岗位替代率

Epoch 也把局限写得很清楚：任务来自他们自己的工作场景；每个模型每项任务只跑一次，分数会有噪声；部分标准包含人工判断；不同模型搭配的 Agent 工具链并不相同。比如某个模型的浏览器、文件工具和默认工作方式更顺手，拿到的结果就未必只反映模型本身。

这不是要把报告的数字打回“没有参考价值”。它真正有价值的地方，在于把“真实工作”放到了评测中心。公开基准能说明能力边界在移动，团队自己的交付卡才能说明边界有没有越过上线门槛。

做这类评测时，最好把一次长对话拆成几次可回放的动作。准备相同的输入、相同的工具权限和相同的验收规则，连续跑几次；把模型的原始产物、工具调用、失败原因和人工退回意见一起留下。模型偶然写出一份漂亮结果不算稳定，模型在输入变化、上下文变长或外部工具变慢时仍能知道该交什么、该停在哪，才接近可以交付。

很多工作流也不需要等到“整条链路全自动”才产生价值。把资料搜集、初稿整理、格式校验这些通过率高的动作先接出去，把异常归类、边界判断和最终确认留在升级队列，往往比一次性追求端到端代理更快看见收益。人不是每一步都要盯着，而是只在系统明确告诉你“这里不该自行决定”时接手。

对大多数团队来说，下一步不必是找一个能包办整条流程的 Agent。更实际的做法是挑一段有稳定输入、明确验收、可安全回滚的工作，让它先做到 100% 可以信任；再把人工注意力留给那些需要判断、解释和负责的地方。

模型拿到 65 分，不该让人失望。它提醒我们，自动化的单位不是“一个岗位”，而是一段能被验收的工作。你们团队里，哪一段任务已经够资格从“模型帮忙”变成“模型交付”？

小岛 AI

记录一线实战、踩坑与成长