[{"data":1,"prerenderedAt":369},["ShallowReactive",2],{"blog-post-/zh/blogs/fable-5-managing-ai-autonomy":3},{"id":4,"title":5,"body":6,"description":351,"extension":352,"meta":353,"navigation":364,"ogImage":355,"path":365,"seo":366,"stem":367,"__hash__":368},"zh/blogs/zh/25.fable-5-managing-ai-autonomy.md","Fable 5 改变了 AI 工作的最小单位",{"type":7,"value":8,"toc":340},"minimal",[9,13,16,19,22,39,42,45,50,53,56,59,62,65,72,76,85,88,91,94,97,103,107,116,119,122,125,128,131,134,140,144,147,150,153,156,159,162,165,168,172,175,190,193,196,199,221,224,227,239,242,248,252,255,258,261,268,274,280,286,292,298,304,310,313,316,319,322,325,328,331,334,337],[10,11,12],"p",{},"我给 Claude Fable 5 一个需要跑几个小时的任务。第一次，我感觉自己不是在 prompt 一个模型，而是在启动一次工作运行。",[10,14,15],{},"这个差别只有真正体验过才明显。普通 chat 模式里，我还在工作内部。我问一个问题，看结果，纠正它，补 context，再问一轮，几分钟就要 steer 一次。但 Fable 的感觉不一样。我给它一个目标，它开始规划、分发、研究、综合，最后交付了一组很漂亮的页面。表面结果是页面，更重要的结果是那次 run。",[10,17,18],{},"我觉得这才是关键。",[10,20,21],{},"Fable 5 不只是产出了更好的 output。它把 AI 工作的最小单位，从 response 变成了 run。",[10,23,24,25,32,33,38],{},"Anthropic 在 ",[26,27,31],"a",{"href":28,"rel":29},"https://www.anthropic.com/news/claude-fable-5-mythos-5",[30],"nofollow","2026 年 6 月 9 日发布 Fable 5 和 Mythos 5","，强调它们比之前的 Claude 更适合长时间自主工作。三天后，Anthropic ",[26,34,37],{"href":35,"rel":36},"https://www.anthropic.com/news/fable-mythos-access",[30],"发布声明","，说美国政府发出 export-control directive，要求暂停 foreign nationals 对 Fable 5 和 Mythos 5 的访问。为了合规，实际结果是 Anthropic 暂时关闭了所有客户访问，并表示正在努力恢复。",[10,40,41],{},"发布和暂停访问，其实从两个方向说明了同一件事。发布说明：agent 可以跑得更久、更可靠地分发任务、更大范围地使用工具。暂停访问说明：一旦 agent 足够强，control、governance 和边界就不再是后置问题。",[10,43,44],{},"这篇文章真正想讲的，不是 Fable 很强。真正的启发是：当一个 agent 可以连续跑几个小时，稀缺能力就不再是写一个聪明 prompt，而是设计一个 operating contract，让这次 run 有边界、可检查、可回滚。",[46,47,49],"h2",{"id":48},"最小单位从-response-变成-run","最小单位从 response 变成 run",[10,51,52],{},"Response 很小。它是一段文字，可能加一次 tool call，可能改一个文件。如果错了，我纠正它。如果不完整，我再问一次。错误成本通常是一轮对话。",[10,54,55],{},"Run 不一样。Run 有持续时间，有状态，会消耗 token，会调用工具，会读文件、写 artifacts、分发 subagents、形成中间假设，并且可能走很远之后我才检查结果。一个坏假设的成本，不再是一段坏答案，而可能是一整条错误工作分支。",[10,57,58],{},"所以更长的 autonomy 改变了注意力的经济学。在 prompt 模式里，我的注意力就是 control loop。在 run 模式里，我的注意力前移和后移。运行前，我要定义目标、context、约束、权限、checkpoint 和 stop condition。运行后，我要检查 evidence，再判断结果能不能用。",[10,60,61],{},"模型更强了，但工作系统反而更不能随便。如果目标模糊，autonomy 会放大模糊。如果约束不清楚，autonomy 会探索错误空间。如果 agent 能无边界地行动，autonomy 会把能力变成 operational risk。",[10,63,64],{},"所以 \"管理 agent\" 这个说法还不够准确。真正的工作是 run design。",[10,66,67],{},[68,69],"img",{"alt":70,"src":71},"Response 和 run 是两种不同的 AI 工作单位","/blogs-img/2026-06-15-fable-01.webp",[46,73,75],{"id":74},"fable-让-control-surface-变得可见","Fable 让 control surface 变得可见",[10,77,78,79,84],{},"Anthropic 自己的 ",[26,80,83],{"href":81,"rel":82},"https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5",[30],"Fable prompting 文档"," 很有意思，因为它不只是讲 prompt。它讲 long runs、effort levels、progress claims、explicit boundaries、parallel subagents、memory systems 和 scaffolding changes。这已经是另一类指导。",[10,86,87],{},"如果一个模型可以跑几个小时，界面就不能只是一个 text box。界面需要 timeout behavior、progress indicators、asynchronous check-ins、基于 evidence 的状态报告，以及定义什么时候应该 pause 的机制。如果它可以分发 subagents，harness 就要决定什么时候 delegation 有用，subagents 如何沟通，它们的工作如何被 review。如果它可以维护 memory，系统就需要一个地方记录 lessons，同时避免坏假设污染后续工作。",[10,89,90],{},"换句话说，模型能力提升，会倒逼它周围的产品和 workflow 重构。",[10,92,93],{},"这也是我在 Fable 那次 run 里的真实感受。我不只是在看 \"模型答了什么\"。我其实在问另一组问题：它决定研究什么？它分发了什么？它带着哪些假设继续往前？它把 effort 花在哪里？什么 evidence 支撑最终结果？如果 run 跑偏，我应该在哪里介入？",[10,95,96],{},"这些不是 prompt 问题。这是 operating-system 问题。",[10,98,99],{},[68,100],{"alt":101,"src":102},"围绕 agent run 设计 operating contract","/blogs-img/2026-06-15-fable-03.webp",[46,104,106],{"id":105},"superpowers-是一种日常演练","Superpowers 是一种日常演练",[10,108,109,110,115],{},"这也是为什么 Fable 的体验立刻让我想到 ",[26,111,114],{"href":112,"rel":113},"https://github.com/obra/superpowers",[30],"Superpowers","。",[10,117,118],{},"Superpowers 不是另一个模型。它是一个给 coding agents 用的开源 skills framework 和 software development methodology。它的价值不是让模型突然变聪明，而是在模型周围加上一套更有纪律的工作方式。",[10,120,121],{},"这个模式很简单：澄清目标，整理 spec，把 spec 变成 implementation plan，通过 subagents 或结构化阶段执行，review 工作，并在声明完成前验证。Skills 变成了 agent 的 reusable operating contract。",[10,123,124],{},"这会改变我日常使用 Opus 4.8 和 Codex 5.5 的方式。我可以给 agent 一个有意义的目标，让它工作一到两个小时，因为它不是在自由发挥。它有流程。它会读代码、写计划、按计划执行、检查自己的工作，再把 artifacts 交给我 review。",[10,126,127],{},"模型是 engine。Skills 是围绕 engine 的 operating discipline。",[10,129,130],{},"这个区别很重要，因为它防止我们得出错误结论。结论不是 \"Fable 是未来，所以等更强模型就行。\" 结论是：模型越强，周围的工作系统越重要。Superpowers 的价值在于，它让我们在每个模型都能跑半天之前，先练习这种习惯。它让 autonomy 变得可读、可控、可检查。",[10,132,133],{},"所以 \"skill\" 这个词比表面上更重要。一个好的 skill 不是 prompt template，而是一块可复用的 operating judgment：什么时候澄清，如何计划，什么叫 verification，什么时候用 subagents，什么时候要求 review，什么 evidence 足够支持 \"done\"。",[10,135,136],{},[68,137],{"alt":138,"src":139},"Superpowers 给模型加上一套 operating discipline","/blogs-img/2026-06-15-fable-04.webp",[46,141,143],{"id":142},"这不只是-project-management","这不只是 project management",[10,145,146],{},"一个自然的反驳是：这听起来不就是 project management 吗？",[10,148,149],{},"某种程度上，是的。这正是重点。AI agents 越强，工作就越不像聊天，越像委托。委托一直都需要目标、context、review 和 accountability。",[10,151,152],{},"但 agent delegation 有三个差别，让旧习惯不够用。",[10,154,155],{},"第一，agents 以机器速度行动。一个人误解任务，通常很快会产生 friction：提问、延迟、明显偏差。Agent 可以安静地把大量 compute 花在错误理解上，然后交付一个看起来很完整、但方向错了的 artifact。",[10,157,158],{},"第二，agents 通过工具行动。它们不只是思考，还会读、写、调用 API、修改文件、发送消息，未来甚至可能花钱或发布内容。风险从 \"bad answer\" 变成了 \"bad action\"。",[10,160,161],{},"第三，agents 是没有原生 accountability 的概率性 worker。人可以在组织和社会关系里承担决定。Agent 可以产出工作，但责任仍然留在设计这次 run 的人或团队身上。",[10,163,164],{},"所以这不只是普通管理。它是面对一种新 worker 的管理：快、不累、有用、不稳定、能使用工具，但并不真正负责。",[10,166,167],{},"Operating contract 就是让这种 worker 变得可用的东西。",[46,169,171],{"id":170},"governance-是同一个问题的放大版","Governance 是同一个问题的放大版",[10,173,174],{},"Fable 暂停访问这件事，把这个问题放到了地缘政治层面。但同一个模式在每个尺度都存在。",[10,176,177,178,183,184,189],{},"Anthropic 的声明讨论了 safeguards、red-teaming、jailbreak resistance、monitoring、customer data retention 和 defense in depth。Databricks 介绍 Fable 5 时，也把它放在 ",[26,179,182],{"href":180,"rel":181},"https://www.databricks.com/blog/claude-fable-5-now-available-databricks-fully-governed-through-unity-ai-gateway",[30],"governance、audit logs、tool-call policies 和 cost controls"," 里讲。Gartner 在 ",[26,185,188],{"href":186,"rel":187},"https://www.gartner.com/en/newsroom/press-releases/2026-05-26-gartner-says-applying-uniform-governance-across-ai-agents-will-lead-to-enterprise-ai-agent-failure",[30],"2026 年 5 月"," 也提醒，不能对所有 AI agents 使用同一种 governance，因为组织必须区分 agent 的 autonomy level 和它被授予的 access scope。",[10,191,192],{},"这个区分非常关键。危险的组合不是 intelligence 本身，而是 autonomy 加 access，却没有相应的 control system。",[10,194,195],{},"一个只能 observe 的 agent，是一种风险。一个能 draft recommendation 的 agent，是另一种风险。一个可以在 approval 后行动的 agent，又是另一种风险。一个可以跨系统 autonomously act 的 agent，已经是完全不同的类别。",[10,197,198],{},"这同样适用于 individual builders。每次我让 agent 跑之前，都要知道自己授予了哪种 autonomy：",[200,201,202,206,209,212,215,218],"ul",{},[203,204,205],"li",{},"它只能读、总结和提建议吗？",[203,207,208],{},"它能改文件吗？",[203,210,211],{},"它能安装 dependencies 吗？",[203,213,214],{},"它能调用外部服务吗？",[203,216,217],{},"它能创建 branch、push code 或 publish content 吗？",[203,219,220],{},"它不确定时可以继续，还是必须在某些边界停下来？",[10,222,223],{},"这些问题不是 bureaucracy。它们就是工作的 control surface。",[10,225,226],{},"对每一次有意义的 agent run，我现在会问三个问题：",[228,229,230,233,236],"ol",{},[203,231,232],{},"它能做什么？",[203,234,235],{},"我怎么知道它做了什么？",[203,237,238],{},"如果它做错了，我怎么停止、回滚或修复？",[10,240,241],{},"如果答不上来，我就还没有设计这次 run。我只是启动了它。",[10,243,244],{},[68,245],{"alt":246,"src":247},"Agent governance 是 autonomy 和 access 的匹配问题","/blogs-img/2026-06-15-fable-07.webp",[46,249,251],{"id":250},"真正的新能力是设计-operating-contracts","真正的新能力是设计 operating contracts",[10,253,254],{},"我觉得 AI-native work 正在走向这里。",[10,256,257],{},"Prompt 仍然重要。好的 prompt 是 judgment 的接口。但当工作最小单位变成 run，prompt 就不够了。Run 需要 operating contract。",[10,259,260],{},"这个 contract 不一定复杂。我现在会从七个部分想：",[10,262,263,267],{},[264,265,266],"strong",{},"Objective:"," 什么结果重要？什么算成功？",[10,269,270,273],{},[264,271,272],{},"Context:"," 哪些文件、事实、docs、rules 或 examples 是 authoritative？",[10,275,276,279],{},[264,277,278],{},"Authority:"," Agent 能读什么、写什么、调用什么、花费什么、发布什么？",[10,281,282,285],{},[264,283,284],{},"Checkpoints:"," 它应该在哪里 pause、report 或 ask for approval？",[10,287,288,291],{},[264,289,290],{},"Evidence:"," 什么 proof 足够支撑 progress claims 和 final claims？",[10,293,294,297],{},[264,295,296],{},"Budget:"," 允许花多少时间、成本和探索空间？",[10,299,300,303],{},[264,301,302],{},"Rollback:"," 如果 run 产出错误结果，怎么处理？",[10,305,306],{},[68,307],{"alt":308,"src":309},"Agent run 的 operating contract stack","/blogs-img/2026-06-15-fable-08.webp",[10,311,312],{},"这比 \"prompt engineering\" 更有用。它更像设计一条小型工厂线。有些工作可以交出去，在后台运行。有些工作必须我深度参与。Leverage 来自知道这两者的区别。",[10,314,315],{},"这也是我最近更大的工作感受。AI 让我觉得自己更 powerful，因为更多项目可以同时动起来。我可以让一个 agent 起草，让另一个 agent research，让另一个 agent coding，让另一个 agent 把 plan 变成 distribution assets。但我的 focus 并没有变成无限。恰恰相反，focus 的价值更高了。",[10,317,318],{},"瓶颈从 \"亲自做每件事\"，变成了 \"正确路由工作\"。",[10,320,321],{},"这个环境里最强的 operator，不是盯着每一步的人，而是能把工作设计好的人：让该自动推进的部分自动推进，让重要判断仍然回到人这里。",[46,323,324],{"id":324},"真正留下来的东西",[10,326,327],{},"Fable 5 可能会回来。它可能会变化。也可能很快被另一个模型替代。具体产品周期不是最重要的。",[10,329,330],{},"真正重要的是：AI work 正在从 prompt-response loop，走向更长时间、更可委托、更可检查的 runs。一旦这个变化发生，优势就会从 access 转向 orchestration。",[10,332,333],{},"最强模型当然仍然重要。但最强模型放在一个弱 operating system 里，可能只会产出昂贵的混乱。稍弱一点的模型，放在一个有纪律的 workflow 里，反而可能产出可交付的工作。",[10,335,336],{},"这就是我想继续练习的能力：不是只学会要 output，而是学会设计 agent 做真实工作的条件。",[10,338,339],{},"未来不属于最会 prompt 的人。它属于那些能让 execution 跑在前面，同时不让 judgment 掉队的 builders。",{"title":341,"searchDepth":342,"depth":342,"links":343},"",2,[344,345,346,347,348,349,350],{"id":48,"depth":342,"text":49},{"id":74,"depth":342,"text":75},{"id":105,"depth":342,"text":106},{"id":142,"depth":342,"text":143},{"id":170,"depth":342,"text":171},{"id":250,"depth":342,"text":251},{"id":324,"depth":342,"text":324},"Fable 5 让我看到，AI 工作正在从一轮 response 变成一次长时间 run；未来稀缺的能力，是为 agent run 设计边界、检查点和 operating contract。","md",{"date":354,"image":355,"alt":356,"tags":357,"category":362,"youtube":363,"published":364},"15th Jun 2026","/blogs-img/2026-06-15-fable-cover.webp","一个操作者在控制台前监督多条 AI 工作流",[358,359,360,361],"AI","Agent","工作流","AI 治理","ai-native-systems","https://youtu.be/jPHR-73HJa8",true,"/blogs/zh/fable-5-managing-ai-autonomy",{"title":5,"description":351},"blogs/zh/25.fable-5-managing-ai-autonomy","KPbA461XaIC8kSk8LKlmMPhT6fLdILNZHMELKQp2QZs",1781532113142]