选择 Agent 时，演示通常能回答“它能做什么”。真正影响后续使用的，是客户资料、产品政策和已确认结论存在哪里，换一个执行工具后还能不能继续用。
先打开现有工具里的一份业务材料。它可能是上传到某个 GPT 的文件、随 Skill 一起安装的参考资料，也可能是通过连接器读取的外部记录。三者都能帮助 Agent 工作，但更新和交接的方法不同。选型应从这份材料的生命周期开始，而不是从市场里工具的数量开始。
市场里买到的，可能不是同一种东西
Agent、Skill、模板和连接器解决不同问题。Agent 是承担任务的执行配置；Skill 包装可复用指令及资源；模板提供起点；连接器负责访问另一个系统。一个商品可能组合几种能力，但“已安装”没有说明业务资料究竟保存在谁那里。
Anthropic 的 Skills 文档给出了具体例子：Skill 可以包含 SKILL.md、脚本、模板和参考文件，按需从文件系统读取。官方也明确，不同产品表面的自定义 Skills 不自动同步。把一份产品手册打包进 Skill，分发的是某个资料副本；以后手册变化，还要管理各环境的更新。
另一个机制是已有自定义 GPT 的 Knowledge。OpenAI 配置指南说明，上传的文件为对话提供参考材料，行为规则则放在 Instructions；编辑者通过 Update 应用改动。这是 GPT 配置中的参考资料，不是自动保持所有工具一致的外部业务记录。当前 GPT 创建与迁移存在账号和工作区差异，评估应以自己账号可编辑、可使用的入口为准。
这些实例没有高下之分。稳定的写作风格说明适合随 Skill 分发；单个 GPT 使用、很少变化的手册可以留在它的 Knowledge。频繁变化且要被多个执行器使用的业务字段，才需要进一步检查共享位置。
选择前，把四个问题问到具体文件上
第一，正式资料在哪里？请供应方指出文件、文档或记录的实际位置，以及谁有编辑权。“有记忆”不足以回答这个问题，因为它可能指单次会话、项目文件或独立数据源。
第二，Agent 如何读取？本地目录、上传文件、API 和 MCP 都是可能的入口。要确认当前工具支持哪一种、授权给哪个身份，以及换工具后能否访问相同来源。协议名称相同，只能说明存在连接路径，不能替代实际读取验证。
第三，修改何时生效？更新原文件后，需要重新上传、重新安装、重新索引，还是下一次读取就能看到？若多个副本分别维护，谁负责确认它们的版本？对会影响客户承诺的政策，读到新内容之前还需要什么批准？
第四，换工具后留下什么？导出的指令、源文件、任务产物和修改历史要分别检查。能复制一段提示词，并不意味着授权、连接配置和审核历史也会一起迁移。
把答案写成一份很小的资产清单：资料名称、正式位置、读取方式、更新负责人、生效步骤和替换工具时的处理方式。这份清单比“支持知识库”的功能勾选更能帮助采购与交接。
已经够用，就沿用现有资料位置
如果只有一个 Agent 使用少量稳定文件，工具自带的上传和版本管理可能已经足够。不要为了架构整齐，把一个简单流程拆成多个系统。先确认编辑权限、备份方式和更新后的结果即可。
当第二个工具需要相同政策、同一资料出现多个互相冲突的副本，或修改需要一个明确的接受决定时，独立共享层才有具体价值。它减少的是“哪份是当前正式资料”的歧义，同时也增加权限配置、连接维护和异常处理的工作。
有跨工具需求时，怎样用 Busabase 搭建一个起点
Busabase 可以承接由用户管理的业务资料和变更记录。按节点类型，Base 保存结构化记录，Doc 保存长文档，Skill 保存可复用执行方法。先按材料性质选择节点，不必把每份文件都转成表格。
下面是可调整的最小设计，不是现成行业模板：
| 节点 | 建议内容 | 用途 |
|---|---|---|
| Folder：业务资料 | 资料、修改规则和执行说明 | 集中导航 |
| Base：产品政策 | 政策名称、适用产品、当前正文、来源链接、生效日期、负责人 | 让多个任务读取同一条正式记录 |
| Doc：修改规则 | 谁确认事实、哪些变更需要审核 | 保留人工判断标准 |
| Skill：资料使用方法 | 读取顺序、来源要求、变更提交和回读步骤 | 让执行器遵循相同方法 |
通过当前客户端支持的MCP 与 OAuth或 API 接入，先完成身份与空间核验、读取测试，再开放修改能力。希望改动先等待人审时，给普通执行器选择 changeRequest 权限。write 权限的改动可能直接合并；审批边界应由真实授权保证。
可以给已连接的 Agent 这样一条指令：
读取产品政策中的当前记录，回答时附来源。发现材料冲突时，保留当前正文，提交包含原文、新建议和依据的 ChangeRequest；等待负责人决定。合并后重新读取记录，确认当前内容，再用于后续任务。
结果应是一条可检查的记录和一份有差异的修改提案，而不是聊天里一句“已更新”。ChangeRequest合并后，后续工具应读取当前记录；同一个任务内的旧缓存仍需按客户端机制刷新。
换工具前，先验证一条真实资料
不需要先搬完整个知识库。选一条已经批准的政策，验证工具 A 和工具 B 是否读取相同来源；提出一处可辨认的修改，检查它是否按预期等待审核；合并后重新读取，确认两边引用当前内容。最后撤销其中一个工具的授权，确认另一个仍按自己的授权工作。
这条路径能回答三个实际问题：资料是否独立保存，更新是否可控，执行器是否可以替换。只有这些答案符合需要，扩大迁移范围才有意义。
已安装 Skill 的参考文件要全部迁出吗？
不必。通用方法、格式样例与稳定参考可以随 Skill 保留。把需要持续更新、明确归属或跨工具共享的业务资料单独管理，再在 Skill 中说明读取位置。
接上 MCP 就能保证两个 Agent 使用相同资料吗？
还要核对目标空间、访问范围、实际读取对象和缓存。用同一条记录的当前内容做读取测试，再检查更新后的结果，比只看到连接成功更可靠。