当多个 AI agent 需要访问同一个知识库时，如何让每个 agent 用自己的身份安全地读写，同时不让凭证散落在各处？本文介绍一种基于 Model Context Protocol（MCP）的薄代理模式。
问题：多 agent 共享知识库的凭证困境
假设你有一个知识库 API，多个 agent 需要访问它。最直觉的做法是给每个 agent 发一个 token，让它们各自带着 token 去调 API。
这看起来没问题，但实际操作中会碰到几个坑：
凭证散落——每个 agent 的配置文件里都写明文 token。配置文件可能被提交到版本控制、被日志打印、被其他 agent 读到。凭证一旦泄露，整个身份体系就失效了。
身份混用——为了省事，多个 agent 共用同一个 token。这导致审计链无法区分「是谁写的」——不可抵赖性从根上就破了。
手工拼装易错——每次调 API 都要手动拼 curl、管 token、解 JSON、处理编码。步骤越多，出错概率越高，而且出了错很难定位是拼写问题还是逻辑问题。
薄代理：只转调，不决策
解法是在 agent 和知识库 API 之间加一层 MCP 薄代理。
「薄」的意思是：它只负责把 MCP 协议的工具调用翻译成 REST API 调用，不做任何业务决策。身份验证、权限控制、版本对齐、写入拦截——这些全部仍由后端 API 判定。代理层挂了，agent 仍然可以直接调 REST API（只是要手工拼装）。
具体来说，薄代理把「读钩子 → 拼 curl → 管 token → 记路径」这一串手工步骤收口成一组原生工具。agent 只需要调用工具、传参数、拿结果，不需要知道底层是 HTTP 还是 stdio。
两种传输形态
薄代理支持两种传输方式，适用于不同场景：
stdio（本地进程）——代理作为本地进程启动，通过标准输入输出与 agent 通信。适用于 agent 和知识库在同一台机器（或同一内网）的情况。token 从本地文件读取，不经过网络。
streamable-http（常驻服务）——代理作为常驻 HTTP 服务运行，agent 通过 HTTP 调用。适用于远程 agent。凭证由客户端在每个请求的请求头中携带，服务端不存储任何凭证。
两种形态的工具集完全一致——agent 不需要因为传输方式不同而改变调用逻辑。
逐请求身份
这是这套模式最关键的设计：身份按请求隔离，多 agent 绝不共用凭证。
每个请求都带有 agent 名称和 token。后端根据 token 确定身份，根据名称确定归属。换一组凭证，身份就变了——这意味着身份不是会话级的，而是请求级的。
这个设计带来两个好处：
第一，审计可追溯。每次写入都知道是谁干的。不存在「某个 agent 用了别人的 token 写了东西，查不出来」的情况。
第二，泄露影响可控。如果一个 agent 的 token 泄露了，只需要撤销这一个 token，不影响其他 agent。共用 token 的情况下，一个泄露全部失效。
工具数红线
薄代理暴露的工具数量有硬上限。这不是技术限制，而是治理约束——工具越多，攻击面越大，出错概率越高。
新增工具需要经过共议流程，不能由单个 agent 或开发者自行添加。这个约束看起来像是给自己添麻烦，但在多 agent 环境中，「谁能加新工具」本身就是一个权限问题。
Parity 四测
每次接入新 agent 时，必须通过四项实测来验证代理层工作正常：
无凭证拒绝——不带任何凭证调用写类工具，应该被拒绝。如果返回 200，说明身份验证没生效。
正确凭证通过——带正确凭证调用，应该返回 200 且身份标识与预期一致。
身份隔离——换一组凭证调用，身份标识应该变成新的 agent。如果仍然是上一个 agent 的身份，说明身份没有按请求隔离。
版本对齐——携带错误的 manifest 版本号调用写入，应该返回版本冲突。如果返回 200，说明版本门禁没生效。
这四项测试的价值不在于它们本身有多复杂，而在于它们分别验证了四条安全约束。任何一项不通过，都意味着对应的约束没有生效——不是「可能有问题」，而是「确定没拦」。
回退设计
薄代理的一个设计原则是：它挂掉不影响核心功能。
因为代理层只做协议翻译，不做业务决策，所以它和后端 API 是解耦的。代理挂了，agent 可以退回直接调 REST API——只是要手工拼装请求。REST 双通道永久保留，不会因为 MCP 上线就拆除直接通道。
回退操作也很简单：本地进程形态删掉配置条目重启即可；常驻服务形态停掉服务即可。没有状态需要迁移，没有缓存需要清理。
混合模式
实践中，不同 agent 的客户端能力不同。有些客户端支持从文件读取凭证（安全），有些只支持在配置里写明文（不安全）。
对于不能安全持有凭证的客户端，采用混合模式：读类工具走 MCP（后端读侧不要求凭证，实测可用），写类工具仍走 REST 脚本链路（token 只在本地文件、经环境变量注入）。功能无损失，只是少省了几次脚本往返。
判据很简单：先确认客户端能否安全持有凭证，再决定接入方式。不要为省事把凭证安全卖了。
小结
这套 MCP 薄代理模式的核心是三个设计选择：
薄代理——只翻译协议，不决策业务。代理挂了核心不受影响。
逐请求身份——每个请求带独立凭证，身份按请求隔离。审计可追溯，泄露可控。
parity 实测——接入不是配置完就完了，必须实测验证四条安全约束都生效。
它不是一个复杂的架构——本质上就是一个协议翻译层。但它在多 agent 环境中解决了几个真实的问题：凭证散落、身份混用、手工拼装易错。