团队好不容易把经验写成Skill，希望Agent下次别再反复问同样的问题。流程也写得很完整：读资料、填字段、核验，最后“自动批准并合并”。当它被另一个Agent找到，或者用在一项新任务里，省下的解释就可能变成新的歧义：这句“自动批准”，到底是工作方法，还是这次操作的允许？
问题不只出现在不可信的外部资料里。团队自己的旧流程也可能指向另一个Base，沿用过去的审批约定，或者比本次“先给我草稿”的要求更宽。Agent找到的方法越多，越需要清楚哪份内容指导步骤，哪份委托决定范围。
Busabase的Agent Playbooks文档明确把方法和权限分开：当前用户要求优先，playbook不能增加Key能力，也不能单独授权合并。要让经验真正可复用，需要把找到的Skill、本次任务与实际写入能力，对到同一笔变更上。
搜索命中说明了什么
Busabase 把 Skill 和节点自定义场景都视为 playbook。Agent 会把请求改写成多个表达，按名称、描述和场景内容查找方法；它只能发现当前 Key 能读取的内容。名称或描述接近，有助于找到候选，并不证明每项操作适用于本轮任务。
先看方法名称、所在节点和命中原因，再读完整内容。假如你明确说“只生成待审草稿”，一个习惯直接写正式内容的流程应按本次要求收窄。也不要因为全局搜索找到了某个部门的方法，就把其中 Base 名称照搬到另一个业务空间。
把三份依据放在一起
方法回答“怎样做”：读哪些来源、使用哪些字段、按什么标准验收。对话委托回答“这次做什么”：对象、范围、产物以及哪些动作需要人决定。凭据与空间角色回答“系统允许做什么”：可读范围和能否提出、审核、合并。
这三份依据都应对应到当前工作。Skill 可以保存已经约定的步骤，用户也可以持续授权某类有限操作；每次运行仍要确认授权适用范围，而不是把 Skill 中一句笼统的“自动批准”当作新增委托。Key 有 Write 能力，同样不意味着用户批准了所有内容。
先决定动作，再决定写入方式
若本次只需要整理事实，产物可以是说明或草稿，不必修改正式记录。若任务授权提出变更，Agent 应说明目标 Base、记录和字段，使用适合的提案路径。若还允许合并，要核对具体范围及当前凭据能力，不能把对一项任务的允许扩展到其他记录。
API Key 文档区分 Read、Change Request、Write 和 Manage。Change Request 级别不能自行合并；Write 的默认写入可以立即合并。需要待审时，应在调用中明确保留 autoMerge: false，或使用适合只提案的凭据，而不是仅在 Skill 中写一句“请等待”。
via playbook 是来源轨迹
Agent 使用方法后应说明并给出链接。ChangeRequest 和 Inbox 中的 via playbook 标记，可以帮助审阅者回到该方法。写入方声明来源，Busabase 检查方法存在且 Key 能读取，再记录名称。
这个标记不是审批凭证，也不证明 Agent 正确理解了所有步骤。文档还说明，来源声明未通过检查时，写入仍可能成功，只是不显示标记。因此，没有标记也不能推出没有写入；有标记也不能推出已获得业务批准。两者都要继续查看差异和真实状态。
审一笔变更，沿着证据回走
从目标记录的 before/after 开始，核对改了什么。再打开引用的方法，看其用途是否适合本轮请求；对照用户要求，确认目标、字段和合并动作都在范围内。最后检查实际 CR 状态以及合并后的 canonical 值。
交接给另一位同事时，保存方法链接、当前任务范围、目标记录、CR 链接和仍需决定的事项就足够。不要把 Key 值或不相关的私人对话塞进交接清单，也不要把检查表描述成自动防住所有提示注入的安全系统。
方法冲突时，回到当前请求
若 Skill 指向 Leads，而本次要求写 Partners，文档明确当前用户指令优先。若冲突涉及尚未授权的发布、删除或合并，保留已经准备好的结果，并把具体待决定动作指出来。方法能减少重复解释，不能替人做新的范围判断。
安装模板时哪些资源生效讨论安装边界；搜索覆盖与旧提取讨论能否找到资料。找到、安装、使用与获准合并，是不同的产品动作。
常见问题
Key 已经是 Write，还需要管 Skill 中的授权句吗？
需要核对本次委托。Write 决定系统能力，当前指令决定允许执行的工作。若要人工审核，还要确保请求本身保留待审。
没有 via playbook，就说明 Agent 没读过方法吗？
不能这样判断。它也可能没有声明来源，或来源检查未通过。先问清使用了什么，再核对来源与写入差异。
怎样提高方法被正确发现的机会？
用团队实际会说的任务名称和描述，检查 Key 能否读取所在节点，再用 Playbooks 的查找预览验证命中。发现准确之后，仍保留任务范围和权限核对。