模型是引擎，harness 是车：Fable 5.2 的 prompt 指南被压成了一个搭车工具

NO1ennn 发帖说 Fable 5.2 的 prompting 指南是 gold，并把它压成了一个 prompt。丢进 Claude Code，它会让 agent 从零搭出 harness：一个 orchestrator 把目标拆成任务，每个任务带完成检查；builder 用低 effort 跑，每个任务一份自包含 brief；subagent 只用于并行，因为每个都要花成本；读文件、跑测试、安全重试不需要审批，风险动作必须审批；reviewer 看 diff 不看总结，并重跑测试；eval 给每次改动打分，记录烧掉的 token。错误和超时不算阻塞，它会诊断、重试、换工具，继续走。原帖在 这里。

先补背景。模型是引擎，harness 是车。引擎放桌上没法带你走。harness 是模型外面的东西：上下文、工具、循环、eval、规则、人工交接。前五个让 agent 能干活，eval 告诉你它还能不能干。eval 就是一组可重复的测试，每次给 agent 打分。NO1ennn 引用的文章里，作者有 412 个 eval，每晚跑。

文章的作者把夜间 eval 交给了 Viktor，一个住在 Slack 里的 AI 员工。他写了六条工作说明：每晚 2 点跑完整套；读每一个失败 run；和昨晚对比；早上 8 点前发报告；每个回归附一个 PR；不要自己合并或改动。最后一条最关键。他重复了原文那句话：do not merge or change anything on your own。三个 PR 停在 Waiting for approval，直到他打开。原文在 这里。

第一份报告的数字：412 个跑完，通过率 88.6%，比昨晚低 2.4 个点。三个新回归。refund_multistep 从 0.91 掉到 0.74，原因是下午改 tool rules 的 prompt，agent 开始跳过退款前的订单查询。PR #128 恢复规则，加 6 个测试。invoice_extract 从 0.95 到 0.87，两种货币的发票总额解析错，64 个案例里 11 个挂在同一个字段。PR #129 把货币传给解析工具，分开给每个总额打分。calendar_reschedule 从 0.88 到 0.79，会议跨天时区丢失，只影响 UTC 以外用户。PR #130 保留用户时区，加 4 个跨天案例。两个 flaky 单独标出，不强行修：web_search_summary 五次重跑过三次，外部页面超时；pdf_table_read 同样输入两个分数，scorer 需要固定 seed。第二个是 harness 的问题，不是 agent 的问题。还有两个变好：email_triage 0.82 到 0.90，crm_update 0.86 到 0.89，连续 7 晚无回归。报告底部：今晚 2:00 再跑，批准的修复进今晚套件，没批的 PR 继续开着，明天报告里再出现。

这段实践和 Anthropic 的 Fable 5.2 prompting 指南对得上。指南说 effort 要按任务选：low 适合快速、明确、高并发的子任务；medium 适合日常；high 适合难 coding 和长无人值守；xhigh 和 max 留给最难的任务。subagent 会推高成本，所以描述里要先说成本，再说什么时候值得委派。审批规则要写清楚覆盖哪些动作，否则模型会按字面执行，可能把该做的日常请求也拦下。代码所有权那句话会让模型更主动合并重复代码、顺手修附近问题，也会让输出 token 增加，改动变多。还有 caution 会堆积：记忆、笔记、指令文件里留着的永远不要，会让模型过度谨慎，连重试都不敢。指南建议删掉不再需要的 caution，把例外写进规则本身。报告要写给低上下文读者，开头几句给结论。这些做法很土，但都是工程约束。指南在 Anthropic 文档。

反常识的地方在于，大家盯模型版本，真正决定 agent 能不能用的是 harness 和 eval。eval 会过期，因为 agent 每天都在变。下午改一个 prompt 修一个流程，另一个流程可能悄悄变差。没有崩，没有报错，分数只是滑下去。第一个发现的人通常是用户。作者说，他最忙的日子改 agent 最多，也最容易跳过跑 eval。风险最高的日子检查最少。

Viktor 的案例里，权限设计最值得看。它能读、能比、能诊断、能起草 PR，不能合并。每个重要动作等人点同意。原文是 Viktor 的合作内容，推广链接和优惠码都在原文。这个边界值得抄：agent 可以准备一切，不能自己推过去。所谓 autonomous，前面还有 not unsupervised。

Fable 5.2 发布信息也放在这里。AGTP 的帖子列了数字：比 Fable 5.1 快最多 30%，价格从每百万 input 10 美元、output 50 美元降到 8 和 40；FrontierCode 2.0 上 High effort 大约等于 Opus 5.5 Max，成本约一半；Xhigh 是已发布模型里最高；1000 个 Fable 5.2 agent 用 30 小时形式化了费马大定理，Opus 5.5 同样设置 18 小时只完成 26%。Anthropic 仍建议大多数 coding 和知识工作先用 Opus 5.5。Fable 和 Mythos 是同一底层模型，Fable 有更强防护，Mythos 只给通过审核的组织。帖子在 这里。

如果你今晚要动手，别先找神 prompt。写三件事：这套 eval 什么时候跑，报告长什么样，哪些动作必须等人批准。然后让 agent 去跑。跑完读失败 run，不看通过率就下结论。人类的位置在审批按钮前面。