Connect Your Business APIs Once, Share Them with Every Agent Client via MCP

项目：Baize —— 面向团队的 AI 助手运行时（Go 1.25+，MIT 协议） 仓库：https://github.com/rebornace/baize

1. 一个非常真实的痛点

当团队引入 AI 时，有一件事是不可避免的：每个人都使用不同的 Agent 客户端。

有人用 Cursor 编码，有人用 Claude Desktop，还有人用其他工具。业务 API 文档、登录凭证、回调 URL——如果你在每个客户端中重新配置它们，最终的结果就是：在 Cursor 中对接一次遗留系统，又在 Claude Desktop 中对接一次，凭证散落各处。一旦该遗留系统更改了认证方式，你就必须逐一修复每个客户端的配置。

Baize 位于这个“已对接业务系统”的一侧。OpenAPI 文档只需导入 Baize 一次，登录只需在 Baze 的控制台中完成一次，审批流程只需在 Baize 中审计一次。剩下的问题是：如何让团队已经使用的 Agent 客户端复用这些已对接的能力，而不是再次进行全部配置？

这就是 MCP 服务器导出的用途。

1. 决策发生的地方，以及不决策的地方

首先要明确一点：一旦 Baize 导出工具，决策权就不在 Baize 这边。

Cursor 中的模型、Claude Desktop 中的 Claude——它们仍然自行决定“这一轮调用哪个工具，使用什么参数”。Baize 导出的只有两样东西：工具目录（名称、描述、参数模式），以及调用这些工具时的执行通道。Baize 自身的主模型、ReAct 循环、决策层、记忆和上下文压缩都不参与此导出路径。

直接的好处是：决策层在客户端侧保持自由——你在 Cursor 中使用哪个模型与 Baize 无关——而执行层在 Baize 中保持集中。业务 API 集成、身份验证和审批都仅在一个地方维护。

1. 传输与认证

导出通道基于标准的 MCP Streamable HTTP，无状态。客户端连接时，会在请求头中发送 Bearer 密钥。

• 密钥错误或缺失 → 401。
• 密钥仅以哈希形式存储，绝不以明文形式存储。
• 每个密钥对应一个独立的导出身份（例如，“用于 Cursor 的密钥”和“用于 Claude Desktop 的密钥”是两个不同的密钥）。
• 密钥可随时撤销；撤销某个密钥会立即断开该客户端的连接。
• 整个导出功能有一个主开关；关闭后，所有请求均返回 503。

“一个身份对应一个密钥”并非形式主义——正是它使得后续的登录状态和隔离行为成为可能。

1. “只读”不是口号——而是四层硬性约束

将业务工具暴露给外部客户端最常见的反对意见是：写入操作怎么办？Baize 不仅在营销文案中说“只读”，它在导出策略中堆叠了四层约束：

第一层：HTTP 工具默认仅暴露 GET/HEAD。在导出工具之前，Baize 会检查其 HTTP 方法。任何非 GET 或 HEAD 的方法都不会被导出，除非该工具被明确标记为 force_allow。

第二层：来自 MCP 的写入工具会被硬性拒绝。Baize 本身也作为客户端连接到外部 MCP 服务器。来自这些服务器的工具——如果其名称或描述中包含 insert、update、delete、drop、truncate、execute_write 等类似字样——永远不会被导出，即使有人试图强制允许它们。

第三层：需要审批的工具不会被导出。在 Baize 中标记为“调用前需人工确认”的写入操作（例如创建记录）根本不会出现在导出表面上——因为导出通道没有审批卡片，暴露它将意味着绕过人工审核。

第四层：策略在调用时会重新检查。工具在注册到 MCP 目录时通过一次策略检查，在实际调用时再次通过。这意味着如果你在 Baize 后端禁用或未导出某个工具，下一次外部客户端调用将立即失败——不会出现“目录仍列出该工具但实际已关闭”的空档期。

1. 登录状态的处理方式

这是导出路径中最微妙的部分。传统 API 需要登录。凭证在 Baize 的控制台中配置，但当外部客户端（例如 Cursor）调用工具时，该调用使用的是谁的登录状态？

Baize 的做法是：每个导出身份都桥接到一个独立的内部身份。它拥有自己的会话命名空间（以 mcp-export-id: 加上导出身份 ID 为前缀），并且每次调用都被强制通过该身份进行。具体来说：

• 你在 Baize 中为“Cursor 身份”登录一次并配置其凭证。
• 当 Cursor 使用该密钥调用任何工具时，Baize 使用该身份访问传统系统。
• “Claude Desktop 密钥”通过不同的身份、不同的登录状态运行——两者互不干扰。

Cursor 中的用户永远不会看到传统系统的登录页面；凭证已在 Baize 端维护完毕。

1. 实际使用路径

1. 在 Baize 控制台中接入业务系统（导入 OpenAPI 文档、完成登录、配置审批规则）。
2. 在导出设置中创建导出身份并生成密钥。
3. 将 Baize 的 MCP Streamable HTTP 端点和 Bearer 密钥接入你的 Agent 客户端（Cursor、Claude Desktop——任何支持 MCP 的客户端操作方式相同）。

此后，在客户端输入内容；客户端模型选择要调用的已接入 Baize 工具，Baize 处理执行并返回结果。

1. 与上一篇文章的关系

在之前的文章（“如何零改动地将一个十年历史的 Java 遗留系统集成到 AI 中”）中，MCP 仅被简短提及一段——重点是如何在不触碰遗留系统的情况下将其接入。本文聚焦于 MCP 服务端：Baize 不仅将遗留系统转化为自身工具，还能将这些工具共享给团队已使用的任何 Agent 客户端。

结合双向 MCP，Baize 在生态系统中的定位变得清晰：在接入侧，它可以连接外部 MCP 工具服务器并将他人的工具拉入；在导出侧，它可以通过 MCP 暴露自身已接入的工具目录，使团队无需重复配置。

1. 结语

“一次性接入业务 API，让团队中每个 Agent 客户端都能使用”听起来只是“共享工具目录”。但要真正实现，则涉及一系列具体问题：如何阻止写入操作、如何管理密钥、如何隔离登录状态、如何让配置更改立即生效。Baize 将这些整合为三个领域：导出策略、密钥管理和身份桥接。默认设置偏向保守（只读、需审批的内容保持隐藏且可撤销）；开放任何功能都需要在每个步骤中采取明确的操作。

此导出功能仍在演进中，不同客户端对 MCP 的支持深度各异。欢迎试用并提交 Issue——或在评论区告知我你们团队如何将业务工具连接到自有客户端。我会持续迭代。

GitHub: https://github.com/rebornace/baize