open-connector：让AI Agent永远不接触用户凭证

open-connector：将凭证隔绝在 Agent 进程之外

open-connector 的宣传数字是 1000 个提供商和 10000 个预置 Action，但数字不是它的设计核心。真正的设计核心是一个边界：提供商的密钥留在网关内部，Agent 获取的是元数据、安全的账户标签和执行结果。一个能调用你的 Gmail 或 BigQuery 的 Agent，永远不会持有完成这次调用所需的凭证。

OpenConnector 来自 oomol-lab，自述为面向 AI Agent 的开源连接器网关，是 Composio 的替代方案。用户只需连接一次应用账户，之后同一套目录即可通过 TypeScript SDK 从应用代码访问、通过 oo CLI 从本地 Agent 中继访问、通过 MCP（地址为 http://localhost:3000/mcp）从 Agent 宿主访问，以及通过 HTTP 和生成的 /openapi.json 从任何其他客户端访问。四个入口使用相同的提供商 ID、相同的 Action ID、相同的契约。

这个边界实际带来了什么

凭证处理涵盖 API 密钥、OAuth2、自定义凭证和无认证提供商，这是每个集成层都必须做好的枯燥部分。真正值得借鉴的是围绕它的一系列运行时控制机制：连接身份、作用域、运行时令牌、Action 允许和阻止策略、临时文件传递，以及去标识化的运行日志。

把上面这个清单当作一个问题的答案来理解："当 Agent 请求了它不该拥有的东西时会发生什么？"允许和阻止策略是在网关层面强制执行，而不是寄希望于 prompt。去标识化的运行日志降低了审计日志变成第二份密钥副本的风险。运行时令牌让你可以发放一个不同于提供商凭证本身的凭证。以上这些都是项目公开记录的架构，而非经过审计的架构：README 中没有说明是否经过独立安全审计，所以在依赖其中任何一项之前先读一读执行器的源代码。

Action 契约在设计上可被审查：请求和响应的 Schema、所需的作用域，以及懒加载的执行器源代码。Agent 可以在调用前读取一个 Action 期望什么、它需要什么权限，工程师也可以阅读将要运行的那个执行器。相比之下，封闭的工具表面只有通过实际调用才能了解某个调用做了什么。

部署是另一半卖点

一个持有用户所连接的全部提供商凭证的网关，恰恰是团队不愿意交给别人的组件。OpenConnector 提供了四条部署路径：本地 Docker 或 Node、Fly.io（搭配 SQLite 持久卷）、兼容 Cloudflare 的 Workers 部署（用 D1 做状态、R2 做中转文件），以及 OOMOL 的托管运行时。托管选项的说明很坦诚：受困于 OAuth 审批或面临上线截止日期的团队可以先使用托管认证，后续在私有运行时可用时再迁移，届时的提供商和 Action 契约保持一致。

Cloudflare 路径的文档细化到了具体步骤，包括将 wrangler.example.jsonc 复制到本地变体、执行 D1 迁移、在 npm run deploy:cloudflare 之前设置密钥等。本地起步则是对发布的镜像执行 docker compose up，控制台在 localhost:3000，API 参考文档在 /docs。README 列出的 Node 运行时要求是 22 或更高版本，容器路径则替你们覆盖了这一点。许可证为 Apache-2.0。

适用场景，以及需要自行确认的事项

README 明确说明了目标用户：需要持久访问用户已用工作应用（work apps）的 Agent 产品、需要稳定 Action 契约来添加 Agent 工作流的团队，以及不想放弃自托管选项但又需要托管认证的团队。

在确定采用之前，有两件事需要对照你自己的提供商列表来核实。第一，徽章中的提供商和 Action 数量是从 OOMOL 的托管目录实时读取的，因此要确认你实际需要的提供商在你计划部署的实例中是存在的。第二，共享目录意味着共享的形状：一个为通用场景编写的 Action 可能没有暴露你的集成所需的那个字段，而且由于执行器源代码随运行时一起分发，你可以直接阅读了解原因，然后自行扩展或贡献修改。这两点都是用 OAuth 复杂性和提供商令牌换取 Agent 进程干净的公平交易，也是大多数团队本就不该自己重建的部分。

GitHub: https://github.com/oomol-lab/open-connector

Curated by Agent Palisade — practical AI for small and mid-sized businesses.