你在一个编码助手里配好了文档查询和图片处理，换到另一个助手写页面时，它却只能让你手工找资料、处理图片。工具并没有消失，只是新助手不知道连接在哪里。你又开始翻配置文件，分辨哪些路径只在旧电脑有效，哪些密钥不能复制。
先别急着重新接一遍。如果两个客户端支持相同的 MCP 服务，导入受支持的配置，再确认访问权限，可能已经足够。只有几个稳定的本地工具，也未必需要额外服务。问题在于工具分散在多台设备、由不同人维护时，每份客户端配置都会逐渐变成另一份需要更新的清单。
可以把工具实现与助手连接分开。比如图片处理仍在你维护的设备上运行，文档查询仍访问原来的资料源；将准备共享的能力接入 EasyNet 后，在受支持的助手中配置 EasyNet 的 MCP 入口，而不是让每个助手重新配置所有业务连接。
这个入口会把当前可见的能力描述提供给助手，并在调用时重新检查可见性。新助手因此有机会发现原有工具，但仍要完成连接和身份授权。不能假定任意聊天网站都支持这种接入，也不能因为旧助手有权限，就替新调用者沿用旧身份。
拿同一个任务比较两端：找一段项目文档，再处理一张样例图片。确认两边看到的工具描述、参数和结果都能理解；图片如果只在新电脑本地，还需要处理程序能够访问的文件传递方式。清单里出现了一个工具，不等于整个任务已经跑通。
随后撤掉一项测试权限，检查新助手是否确实不能继续调用，并确认它遇到提供方离线时不会把失败说成完成。连接方式可以复用，不同模型如何选择工具、如何解释结果，仍可能不同，需要在实际客户端里验证。
值得保留下来的，是已经接好的工具和资料访问，而不是把自己锁在某个助手里。下次换助手时，如果只需连接入口、确认授权并跑一次任务测试，就能继续使用原有能力，这次整理才减少了迁移负担。
- 01
保留提供端
现有文档和图片函数继续维护。
- 02
接入新客户端
使用它自己的身份和受支持入口。
- 03
复跑同一任务
核对结果、文件和拒绝状态。
两个助手使用同一条测试任务
人工执行的迁移检查单，不是通用客户端配置。
# Assistant migration check
Task: retrieve the approved product specification.
Client A: record source and document version.
Client B: use its own login; repeat the same request.
Compare: source, version, and ability to open the file.
Then revoke B's access: the request must be denied.
Do not copy the provider's credentials.预期结果：正常任务能对应同一来源；B撤权后失败而A不被借用。
接入时的检查项
- 两个受支持客户端能使用同一目标能力。
- 迁移过程不要求复制提供方密钥。
- 工具不可见或未授权时给出明确原因。