这个 Agent 我调了几天，同事却还得重新教一遍。

你花了几天把售前助手调好：知道公司的产品口径，会查报价，也知道哪些承诺不能做。你把提示词发给同事，以为他终于不用从头开始。结果他第一次询价就卡住了：报价工具不在他的环境里，资料链接也没有权限。

你想交给他的，其实是一个能完成工作的助手，而不只是角色说明。先决定交付哪一种：让同事使用你持续维护的助手，还是让他在自己的环境重建一份。后者还要重配模型、资料和工具；这里先讨论前者。

如果你们使用的平台已经支持团队共享助手和知识库授权，先用现成入口。只有报价工具在自建系统里、不同同事使用不同客户端时，才需要解决平台之外的接入。不要为了共享一个助手，反而让每个人多维护一套环境。

这里可以共享正在运行的助手，而不是让同事重新安装它。你在自己的 Runtime 中接入维护好的 Agent，将它的对话入口发布出来。同事发来“这批产品怎么报价”，请求交给你维护的助手处理，再把回答返回给同事。模型配置、报价程序和资料更新仍由你在提供端维护，不必每改一次就重新发一份配置。

同事以自己的身份申请并调用这个入口，助手仍在你维护的环境中执行；这不是把他的账号变成你电脑上的运行账号，更不能借给他你的个人密钥。工具访问与知识库访问也要分别处理：能查报价，不意味着能看所有客户资料。入口应当告诉他缺了哪项权限、向谁申请，而不是让他猜为什么助手只会说不知道。

仓库中的测试已覆盖两个独立 Runtime 之间接入外部 Agent、发现对话能力并远程调用的路径，但两端配对的是同一个用户。它说明请求能够到达并返回，还没有验证另一个同事的身份如何获准或被拒绝。测试程序返回确定内容，也不能证明真实售前助手的报价质量。接入实际团队时，还要换成两个不同用户检查授权，再用真实助手核对报价与资料范围。

让同事独立完成一次常见询价，再试一次超出权限的请求。如果前者不再需要你临时帮忙，后者会明确停下，你才真正交出了一部分已经调好的工作，而不是又发了一份配置说明。