OpenConnector
将用户已授权的 SaaS 账户安全接入 AI 工作流。
按维度查看评分与理由
证据显示：README 和 SECURITY.md 描述了凭据存储、加密、令牌、策略和日志脱敏，但未提供具体实现细节。CI 工作流使用最小权限（contents: read）。扣分：用户确认机制未明确，依赖安全仅列出依赖，未提供漏洞扫描或审计证据。
证据显示：README 和文档提供了多种部署方式，CI 包含 lint、typecheck 和测试。扣分：失败消息未详细说明，依赖可用性未验证。
证据显示：README 描述了多种使用场景（SDK、CLI、MCP、HTTP）和部署选项（本地、Cloudflare、Fly.io、OOMOL）。扣分：触发精度（如 Action 调用）未详细说明，环境适配未提供具体配置示例。
证据显示：README 提供了安装、使用、部署文档，有 LICENSE.txt（Apache-2.0），有版本号（1.3.5）。扣分：已知限制未明确列出，版本变更日志未提供。
证据显示：README 描述了输出（Action 结果、日志）和边际价值（连接一次，多处使用）。扣分：成本效益未量化，输出可用性未提供具体示例。
证据显示：README 中的声明（如 1000+ providers）有链接支持，但未提供独立验证。扣分：跨来源佐证不足，事实与推断未明确区分。
- 静态审查，未执行代码，所有结论基于文档和配置文件。
- 依赖安全未提供漏洞扫描或审计证据，需自行检查依赖。
- 用户确认机制未明确，需确认实际操作是否要求用户确认。
- 已知限制未列出，需自行评估。
这个 Agent 能做什么，适合哪些场景？
OpenConnector 是一个面向 AI 应用的开源连接器网关，用于连接用户已授权的 SaaS 账户与可执行操作。它提供包含 1,000 多个服务商和 10,000 多个预构建 Action 的目录，并支持 API Key、OAuth2、自定义凭据和免认证服务。应用或代理可通过 Connector SDK、oo CLI、MCP、HTTP API 或生成的 OpenAPI 文档发现和调用 Action。网关在运行时处理连接别名、作用域、运行时令牌、Action 允许/阻止策略、临时文件传递与脱敏运行日志，避免将服务商密钥直接交给代理进程。它可本地以 Docker 或 Node.js 运行，也可部署到 Fly.io、Cloudflare Workers/D1/R2，或使用 OOMOL 托管运行时。
客户端先浏览服务商目录，读取 Action 的请求/响应 schema、所需 scopes 与执行器信息；随后选择连接别名并通过网关执行。自托管实例可用 PUT /api/connections/github 写入 GitHub 凭据，再以 POST /v1/actions/github.get_current_user 调用 Action；免认证验证可调用 POST /v1/actions/hackernews.get_top_stories。MCP 客户端可连接 http://localhost:3000/mcp，HTTP 客户端可调用 /v1/actions/*，并从 /openapi.json 获取接口描述。Web Console 用于浏览连接器、配置凭据、创建 runtime token、检查 schema、调试 Action 和查看近期运行记录。
- 正在构建企业助手的开发团队，需要让助手在用户授权后操作 GitHub、Gmail、Notion、Slack 或 Airtable，而不把凭据注入助手进程。
- 为现有 AI 产品增加工具调用的工程师，需要通过 HTTP 或 OpenAPI 调用统一的 SaaS Action 接口。
- 使用 MCP 主机的本地开发者，需要从 http://localhost:3000/mcp 向主机暴露已连接应用的 Action。
- 希望在自身 Cloudflare 账户运行连接器服务的团队，需要使用 Workers、D1、R2 和静态控制台部署运行时。
- 需要排查授权、作用域或 Action 调用问题的运维人员，需要在 Web Console 中查看 Action schema、调试调用和脱敏运行日志。
这个 Agent 有哪些优点和局限？
- 同一套服务商 ID、Action ID、schema 和契约可用于开源自托管与 OOMOL SaaS 部署。
- 同时提供 SDK、
oo connector、MCP、HTTP 和 OpenAPI，便于嵌入不同类型的代理或应用。 - 运行时明确提供连接身份、作用域、令牌、Action 策略和脱敏日志等可检查控制面。
- 部署选择覆盖本地 Docker/Node.js、Fly.io、Cloudflare Workers，以及 OOMOL 托管运行时。
- 自托管 OAuth 服务商需要自行注册、配置和管理 OAuth 客户端凭据。
- Cloudflare 部署依赖 Workers、D1、R2 和 Static Assets 等 Cloudflare 资源。
- 本地或 Fly.io 路径使用 SQLite 持久化，生产部署需要自行处理相应的存储与运行环境。
- README 宣称目录覆盖 1,000 多个服务商和 10,000 多个 Action，但未在所给材料中列出每个服务商或 Action 的支持范围。
如何安装或部署这个 Agent？
本地自托管可直接运行：
docker compose up该命令拉取 ghcr.io/oomol-lab/open-connector:latest。若要从源码构建：
docker compose -f docker-compose.yml -f docker-compose.build.yml up --build运行后控制台位于 http://localhost:3000，API 文档位于 http://localhost:3000/docs。开发源码需要 Node.js 22 或更高版本，并执行 npm install 和 npm run dev。OAuth 服务商需要自行在相应服务商处注册并配置 OAuth 客户端凭据；GitHub 示例可使用个人访问令牌。
如何使用这个 Agent？
先验证运行时：
curl -s -X POST http://localhost:3000/v1/actions/hackernews.get_top_stories \
-H 'content-type: application/json' \
-d '{"input":{}}'配置 GitHub 后调用当前用户：
curl -s -X PUT http://localhost:3000/api/connections/github \
-H 'content-type: application/json' \
-d '{"authType":"api_key","values":{"apiKey":"github_pat_..."}}'
curl -s -X POST http://localhost:3000/v1/actions/github.get_current_user \
-H 'content-type: application/json' \
-d '{"input":{}}'也可使用 Connector SDK、oo connector、MCP 端点或 /v1/actions/* HTTP 接口；通过 /openapi.json 检查生成的 OpenAPI 描述。
这个 Agent 与同类方案有什么区别？
项目将自己定位为 Pipedream 和 Composio 的替代方案。其资料强调自托管运行时、可检查的 Action 契约，以及在自托管与 OOMOL 托管环境之间复用同一服务商和 Action 标识；未提供与这些产品的功能矩阵或迁移工具说明。
常见问题
代理会直接拿到服务商密钥吗？
自托管时是否能直接使用 OAuth？
可以怎样调用连接器？
oo connector CLI、MCP 的 http://localhost:3000/mcp、HTTP /v1/actions/*，或生成的 /openapi.json 使用。