Anthropic 在11月9日发布了 Fable 5.2，重点展示它处理高难推理和长程 Agent 任务的能力。发布材料引用了一项从 Python 向 Rust 迁移服务的测试：迁移后的服务启动速度提高了26倍。这里的26倍是该案例的服务启动表现，并不是模型生成代码的速度，也不是所有迁移都能获得的收益。
这样的能力让团队开始考虑把更大的迁移任务交给 Agent：它不仅改一个函数，还可能跨模块追踪依赖、重写实现，并不断用测试修正结果。工程师要接手的，也就不只有代码差异，还有执行过程中逐渐形成的一系列判断。
哪些兼容行为必须保留？某个旧接口为什么暂时不能移除？性能改善是否以牺牲某个部署环境为代价？这些结论会影响下一批代码，也可能影响另一个仓库或团队。一次任务的上下文能帮助当前 Agent 继续工作，却未必能告诉下一个人哪些判断已被团队接受。
大型迁移因此需要两种彼此关联的交付：可验证的实现，以及后续工作可以依赖的决策。先分清它们各自该在哪里审核，交接才不会变成另一轮从头推断。
PR回答“改得对不对”，决策记录回答“以后按什么做”
代码、测试、基准脚本和仓库内的架构决策记录（ADR），都可以继续留在 Git。PR 能把实现与讨论放在一起；如果所有使用者都在同一仓库里，维护得当的 ADR 就可能足够，不必为了换模型再增加一套知识库。
需要额外共享记录的时刻，是一项结论开始约束仓库之外的工作。例如兼容要求涉及另一支服务团队，部署约束同时影响运维，或者下一个 Agent 需要在不同项目中查找当前仍有效的方案。这时，除了找到原 PR，还需要能按范围、负责人和状态查到“现在该遵循哪一条”。
Busabase可以承接这层共享记录：保存精炼的决策、适用范围和证据链接，保留修改与合并历史。它不替代测试，也不把一份漂亮的总结变成架构批准。Git中的实现审核与Busabase中的知识接受，是两次目的不同的验收。
开始迁移前，先读约束，不让Agent猜历史
开始第一轮工作前，让 Agent 读取团队已有的设计文档、仍有效的 ADR 和接口约束。已经有可信来源的资料，直接关联原位置；不要把整套仓库文档复制一遍，让两份内容从此各自变化。
可以在Busabase建立一个迁移项目 Folder，把范围与验收约定写入 Doc，再用一个Base登记会跨团队复用的决策。下面是最小设置建议，不是产品内置模板：
| 资源 | 放什么 | 在迁移中做什么 |
| --- | --- | --- |
| Folder：迁移项目 | 项目的Doc与Base入口 | 明确本次工作的边界 |
| Doc：范围与验收约定 | 目标、兼容要求、Git入口、验收责任 | 给Agent和审阅人同一份约定 |
| Base：架构决策 | 结论、来源、范围、负责人、有效状态 | 查询与提议共享判断 |
| Skill或自定义Prompt | 读取约束、提出变更、回写证据的方法 | 让后续任务复用同一做法 |
给Agent的起始指令可以具体到：
先读取本项目的范围与验收约定，再查架构决策Base里适用于这个服务、且已接受的记录。列出必须保留的兼容要求和对应来源；把缺少证据、已过期或互相冲突的结论单列出来。先不要把这些未决项当成实施前提，也不要改动共享记录。
第一轮应得到一份约束清单，每条都能回到来源；没有确定答案的问题留给负责人判断。是否采用Fable、它在当前Claude Code环境里是否可选，需要另行确认，安装Busabase插件本身不提供模型访问权限。
新发现先成为提议，不立即变成团队规则
迁移过程中，Agent可能发现原先没有写清楚的行为，或者提出移除一段兼容逻辑。此时需要区分“观察到什么”与“决定以后怎么做”：测试结果是证据，采用何种方案才是需要承担后果的决策。
一条待审的决策提议应说明具体结论、支持它的代码或测试、受影响的服务与环境、尚未确认的边界，以及由谁确认。不要仅写“迁移成功，可以推广”；一个模块通过测试，并没有回答其他模块是否具有相同约束。
这里用“是否可以移除兼容路径”作为结构示意：它仍是一项待确认问题，不能预填成已经获准移除。Agent应链接实际PR与测试结果，再由负责人决定结论和适用范围。没有真实来源时，字段就保持未确认，不能拿示例链接补齐。
把业务状态与ChangeRequest状态分开
架构决策Base可以使用下列字段。它们是团队设计的记录结构，状态需要由约定的流程维护，不是Busabase自动判断架构正确与否：
| 字段 | 建议类型 | 审阅时要看什么 |
| --- | --- | --- |
| decision | 文本 | 下一轮究竟可以依赖哪条结论 |
| evidence | 文本或URL | 实际PR、测试、基准与相关ADR的定位 |
| scope | 文本 | 服务、仓库、版本和环境边界 |
| owner | 成员或文本 | 谁负责接受与维护这条结论 |
| state | 单选 | 待确认、已接受、有条件、已废弃 |
| supersedes | 同Base关联 | 哪条旧决策被替代，或留空 |
| review_condition | 文本 | 什么变化发生后必须重新核查 |
记录的state与ChangeRequest审核状态不是一回事。前者表达结论能否用于实施，后者表达这次字段修改有没有进入canonical记录。一次CR已经merged，也可能只是合并了一条state为“待确认”的提议，后续Agent不能据此执行。
如果团队要求架构结论先经过人工审核再成为正式记录，连接就应使用只能提出变更的权限；有Write权限时，默认写入可能直接合并，需要显式保留审核。不要只在Prompt里写“等待审批”，却让实际调用走即时合并路径。具体权限以API Keys和当前连接设置为准。
人工验收时，把实现和结论交叉核对
工程审阅人先在Git检查代码差异、实际运行的测试及未覆盖范围。共享决策的负责人再核对提议：证据是否支持结论，scope是否比测试范围更大，其他团队是否依赖将被替换的行为。
如果PR已合并，但跨团队兼容性还没确认，记录可以继续保持待确认或有条件；反过来，一条架构方向已被接受，也不表示代码已经实现、测试或部署。实现状态要回到Git和部署证据核对，不能用一枚“已接受”标签替代。
需要修改时，通过ChangeRequest收窄范围或补证据；批准后再合并，并回读当前记录确认最终值。若新的决策替代旧结论，显式维护替代关系和旧记录状态，保留过去曾采用它的依据，不要无痕覆盖。
给Agent的回写指令可以是：
把本轮会影响后续迁移的结论整理成架构决策提议。每条关联真实PR与测试，写明适用范围、未决项和负责人。复用同一决策的已有记录，不重复创建。只提交待审变更，不自行批准；返回CR链接与字段差异。批准合并后再回读，报告哪些结论已接受、哪些仍不可作为实施依据。
下一轮开工，读当前有效的记录
新Agent接手时，先确认项目与权限，再读取当前merged的记录，并筛选业务状态为已接受、范围匹配、未废弃且满足复核条件的决策。仍在审核的CR可以作为问题线索，但不能混进已接受清单。
如果两条决策互相冲突，不应仅按“最后修改时间更新”自动选一条。检查替代关系、范围与负责人；无法解释的冲突返回人工。记录没有自动获得事实新鲜度：PR变化、依赖升级或部署环境改变，都可能触发review_condition。
Busabase Playbooks可以把这一读取与提议方法保存为Skill或自定义Prompt，供后续任务查找使用。流程还应明确谁运行下一轮、何时读取、失败后怎样报告；保存一份方法并不会自动启动新的Agent或调度。
从一条真正要复用的结论开始
先选当前迁移中已经有PR和测试来源、又确实影响另一轮工作的结论，跑通读取、提议、人工审核、合并回读和下一轮复用。不必先整理所有聊天，也不必把每个中间推断提升为团队知识。
Claude Code知识库指南说明了共享记录与CLAUDE.md、auto memory及仓库资料的分工；Claude Code插件入口提供当前安装指令，让Agent读取维护中的接入指南，并在授权后先做只读连接检查。
Fable 5.2的能力来自Anthropic发布材料中的模型与任务。团队能持续接住这些产出，靠的是把实现证据、决策责任与后续读取连接起来：下一轮可以查到结论，也能查清为什么、在哪里、由谁接受。