Claude 5.1 与长任务:怎样衡量 Agent 是否真正完成工作
长时间运行并不等于可靠完成。借 Claude Fable 5.1 与 Mythos 5.1 的发布,本文从环境状态、工具反馈、失败恢复和人工审核,建立一套能够解释结果的 Agent 验收方法。

THE BRIEF
博客要点
Anthropic 的九月公告介绍 Claude Fable 5.1 与 Mythos 5.1,说明二者基于同一模型,但采用不同的保护措施与访问安排:Fable 普遍开放,Mythos 通过受信任计划提供。[1] 这不是两个账户可用性完全相同的选项;本文关注的是如何评估长任务交付,不把厂商榜单当作本站实测。
来源公告日期 ·
首先定义一个发生在环境中的结果
“Agent 说已经完成”和“任务确实完成”之间,可能隔着一个没有保存的文件、一次失败的工具调用,或者一份与要求不符的报告。Anthropic 的评估文章也将运行轨迹与最终环境结果区分开来。[3] 对团队而言,验收应该优先指向可观察的产物,再用对话和日志解释它是怎样产生的。
例如,让 Agent 修复一个报表导出问题。完成标准可以包括:特定输入能够得到正确文件,已有功能没有被破坏,使用说明与实现一致,修改内容可以审阅。最终回答里的“测试通过”并不足够,评估程序应读取实际测试结果和交付文件。把这些条件写在任务开始之前,可以避免看到一个漂亮答案之后,临时降低对完成的要求。
比较的是模型与 harness 的组合
Agent harness 负责把输入、工具、上下文和执行反馈组织成循环。Anthropic 的早期工程文章区分了预定义流程与由模型动态决定步骤的 Agent,并建议按照任务需要控制复杂度。[2] 因此,只替换模型名字而不记录工具与环境,很难解释一次长任务表现为什么变化。新工具、不同权限或者更好的错误提示,都可能改变完成概率。
建立对照时,可以让候选模型使用相同任务快照、同一组工具和干净工作区,再记录具体模型标识、推理设置与停止条件。对于必须访问外部系统的任务,优先用测试环境或可回放响应,避免比较时两个候选看到不同的数据。若生产环境本身发生变化,应单独标注这组结果,而不是混入完全可比的样本。
这也解释了为什么不应只用“运行了多少小时”衡量自主性。长时间运行可能代表任务困难,也可能代表模型反复尝试同一条失效路径。更有用的记录是任务推进了哪些可验证步骤、哪些地方需要人工补充、是否在没有进展时及时停止。持续运行的能力只有与反馈和停止机制配合,才可能转化为稳定交付。
为失败设计可解释的分类
我们建议至少区分四类失败:没有理解需求、选择了错误工具、工具执行没有成功,以及验收标准本身不清楚。分类的目的不是找一个责任方,而是确定下一步应修改什么。若日志显示文件根本没有读到,继续润色模型提示词可能没有帮助;若工具执行成功但交付内容错误,则需要检查任务理解和结果验证。
对可重试错误,也要观察重试是否改变了条件。重复调用一个必然返回权限错误的接口,只会延长任务并增加成本。更合理的行为是识别限制、保留已经完成的工作,并说明缺少哪项权限或输入。实验可以加入一个可恢复故障和一个不可恢复故障,观察 Agent 是否分别选择等待重试与停止求助,而不是对所有失败采取同一种反应。
恢复能力需要单独的测试
在没有外部副作用的任务中,可以安排一次中断:让 Agent 完成部分文件修改后停止,再从保存状态继续。检查它是否能识别已有产物,是否重新验证关键结果,以及是否重复执行已经完成的步骤。不要只检查恢复后又出现了文字;真正的目标是工作能够从一个明确状态继续推进。
带外部动作的任务则需要应用保存执行凭据。例如某项业务记录是否创建,应以系统中的实际记录为准。模型不应该通过猜测上次是否成功来决定是否再次提交。把操作结果与请求标识关联,并让不可逆动作有清楚的确认边界,是应用层的设计责任。它不会因为模型推理能力提升就自动完成。
把质量、成本和人工介入放在一起
单一成功率会隐藏不同类型的结果。一次任务可能完全自动完成,也可能是在人工纠正了多次方向之后才成功。建议分别报告首次完成、重试后完成、需要人工介入和最终失败,并为每类结果记录用时与资源消耗。这样才能比较模型是否降低了团队的实际负担,而不是仅仅让最终状态更容易被标为成功。
评分方式也应跟着任务走。代码和文件格式适合程序化检查;研究结论、解释是否充分等问题需要有明确标准的人工或模型辅助评审。使用模型评审时,应抽查它与人类判断是否一致,尤其保留争议案例。[3] 不要让同一个模型既生成答案又毫无校验地宣布自己优秀,也不要因一个难以解释的总分就迁移全部生产任务。
从一类可验收任务开始落地
在 Token AI Cloud 的 Agent Cloud 工作流中,任务可以从 Room 对话发起,并通过事件日志查看进度。实际使用时,先写清交付物、权限范围和完成条件,再对最终文件与执行记录进行核对。账户是否支持某个 Claude 型号需要单独确认,厂商公告不能替代平台中的可用模型清单。
最稳妥的试点通常是一类重复出现、结果容易检查的工作。保留旧方案作为比较,持续积累失败样本,再决定是否扩大自主执行范围。Claude 5.1 的发布提供了重新评估的理由,但升级的结论应由自己的任务证据支持。值得购买的是可靠完成工作的能力,而不是更长的运行时长或更自信的结束语。
封面为 Token4AI 原创的任务结果、执行证据与恢复检查示意。本文给出评估方法,没有运行自有 Claude 性能基准,也没有模拟真实用户研究。
实践清单
- 将完成条件写成可观察的环境状态或交付物。
- 固定模型、harness、工具和测试环境,保留失败样本。
- 分别注入可恢复与不可恢复故障,检查重试判断。
- 记录人工介入、耗时、资源消耗和最终验收结果。
- 先在一种任务上验证,再决定是否扩大自主执行范围。
参考来源
- [1] Anthropic · Claude Fable 5.1 and Mythos 5.1 ↗2026-09-01
- [2] Anthropic · Building effective agents ↗2024-12-19
- [3] Anthropic · Demystifying evals for AI agents ↗2026-09-10
Token4AI 独立技术分析。文中厂商能力与本站模型可用性分别核验;实际接入范围与价格请以控制台为准。