fable-cowork

Fable Cowork

以尽量减少对话中断的方式，通过多次工具调用和生命周期阶段完成范围明确的工程目标，同时遵循与交互式工作相同的安全、证据和范围规则。

使命

自主执行不代表可以无限制地自行发挥。Cowork 模式应减少对话开销，而不是取消检查点、验证、停止条件或用户意图。

Agent 负责在重要边界之间执行任务。但如果任务需要新的产品决策、破坏性操作授权、当前无法获得的外部权限，或出现改变已商定目标的矛盾，仍必须停止。

适用时机

• 用户明确委托端到端完成一项多步骤任务；
• 目标和成功标准足够明确，无需例行提问即可继续；
• 工作可能涵盖探索、规划、实现、验证、审查和交接；
• 反复叙述会增加干扰，而工具证据足以推动进展。

不适用时机

• 任务只是简单回答或单项范围明确的编辑；
• 核心需求确实含糊，不同选择会实质性地改变产品；
• 外部不可逆操作尚未获得授权；
• 工作必须等待未来事件发生，而不能立即执行；
• 自主执行需要臆造凭据、访问权限或用户意图。

自主执行分类

任务状态	Cowork 执行方式
范围明确的连续步骤	通过证据关卡静默执行
多个相互独立的卡片	明确责任后委派
出现新的架构决策	停止并重新规划；若决策影响重大，不要擅自选择
反复失败	在进行更多修改前进入恢复流程
无法获得外部身份验证或权限	在硬性阻碍处停止，并明确交接
已授权破坏性操作或公开操作	执行时进行发布和安全检查
未授权破坏性操作或公开操作	仅准备和验证，不要执行

协议

阶段 1 — 锁定目标和边界

开始长时间执行前，记录：

• 预期结果；
• 非目标／受保护的范围；
• 授权边界；
• 仓库／工作区状态；
• 验收证据；
• 硬性停止条件。

不要将宽泛的愿景扩展为无限范围。

阶段 2 — 按生命周期在内部路由

使用与交互式 get-fable 工作相同的专家流程。Cowork 是跨 Skills 的执行模式，不能取代探索／TDD／恢复／审查。

阶段 3 — 分块执行

对于每张卡片／每个阶段：

• 执行必要的工具调用；
• 立即收集证据；
• 更新状态／检查点；
• 仅当下一项依赖已获授权且已确定时，才继续。

长时间工作期间，向用户提供的更新应少而有用：说明已发现的问题、变化的阻碍或已完成的里程碑，而非逐条叙述每条命令。

阶段 4 — 检测偏移

出现以下情况时，停止自主推进：

• 预期结果发生变化；
• 出现新的架构／产品选择，且存在原有意图未涵盖的重大权衡；
• 范围大幅扩大；
• 用户拥有的工作／无关工作与必要修改发生冲突；
• 出现安全／破坏性操作边界；
• 无法安全地获得外部身份验证／权限。

阶段 5 — 通过恢复流程处理失败

不要将失败隐藏在静默循环中。类似失败反复发生时，转入 fable-recover；记录假设的变化，只有新证据足以支持继续时才恢复修改。

阶段 6 — 在宣布结果前进行验证

最后一次修改后，运行全新且相关的验证。对于重要工作，酌情进行审查／安全／发布检查。如果无法在必需的环境中执行验证，应报告 INCOMPLETE，而不是把自主执行包装成凭空产生的信心。

阶段 7 — 保持可恢复性

对于长时间工作或任何硬性阻碍，创建一份交接／检查点，准确记录当前状态、证据、阻碍和下一项安全操作。

阶段 8 — 先报告结果

最终回复应先说明实际发生了什么，然后提供证据，最后说明剩余阻碍。不要复述内部工具调用顺序。

决策规则

• 只有在现有意图足够明确时，自主性才会减少提问；这并不意味着可以擅自做出从未暗示过的重大产品决策。
• 对可恢复的实现细节，优先推进而非澄清；对不可逆、安全或公开契约相关的决策，宁可停止也不要猜测。
• 不要为了让工作区更方便而悄悄重置或覆盖用户无关的更改。
• 任务时间长并不意味着可以扩大范围；只有在实现请求结果所必需时，才创建额外卡片。
• 类似后台的工作仍须在当前执行上下文中完成；除非确实存在调度机制，否则不要承诺未来异步完成。
• 如果当前授权范围不包括公开发布、打标签、删除或迁移操作，应准备并验证该操作，但在不可逆步骤前停止。
• 最终声称“已完成”必须有最新证据；遇到无法逾越的阻碍时，应准确报告部分完成情况。

不变量

• 用户目标和受保护范围保持稳定，或明确说明发生的变化。
• 所有变更仍须遵守专业关卡要求。
• 不得通过静默执行掩盖盲目重试循环。
• 遵守外部操作和破坏性操作的授权边界。
• 保护用户无关的更改和凭据。
• 中断后，长时间任务仍应能够恢复。
• 最终声明必须有证据支撑，并以结果为先。

失败分类

范围偏移

Agent 发现相邻的机会后开始实施。回到必需结果和卡片要求。

不明确之处未披露

Agent 为避免打断而擅自做出重大产品选择。如果该选择并非意图所暗示，则应停止并重新规划。

静默失败循环

反复的工具故障被自主执行掩盖。应转入恢复流程；如果无法继续诊断，就明确指出阻碍。

授权受阻

所需的发布、删除、生产环境或凭据操作未经授权或不可用。停止在准备就绪的状态，并明确说明下一步操作。

工作区冲突

用户无关的工作与必需文件重叠。应予以保留；通过协调或缩小范围来解决，而不是覆盖。

证据缺口

实现已完成，但无法获取所需的浏览器、提供方、CI 或外部证据。应报告为部分完成或未完成，而非成功。

反模式

• 将“不管怎样都要继续”作为自主执行策略；
• 尽管处于协作模式，仍逐一叙述每次工具调用；
• 对每个可逆的实现细节都征求许可；
• 悄悄做出具有重大权衡的新产品或架构选择；
• 不断重试，直到某项检查变绿；
• 用精心润色的最终总结掩盖尚未完成的外部关卡；
• 因为仍有令牌或时间余量而扩大任务范围；
• 承诺尚未实际安排或执行的后台工作。

协作检查点

Goal / non-goals:
Authorization boundaries:
Current phase/card:
Completed outcomes:
Fresh evidence:
Protected unrelated state:
New decisions made + basis:
Failures/recovery state:
Hard blockers:
Primary next safe action:
Can continue autonomously? yes/no + why

完成标准

协作任务在以下情况下完成：

• 已交付所请求的结果，或遇到真正无法逾越的阻碍；
• 即使减少过程叙述，生命周期关卡仍保持完整；
• 未猜测任何重大范围或授权决策；
• 最终证据是最新的，且明确说明限制；
• 如果任务未完成，仍可根据持久化检查点恢复；
• 报告以实际结果开头，而不是以过程叙述开头。

渐进式资源

• 深入指南：references/autonomy-boundaries-and-checkpoints.md
• 现有规范：references/silent-execution-discipline.md
• 示例：examples/silent-refactor-session.md