OpenConnector 深潜记：拆完 116 万行源码，1451 个 Provider 背后藏着十处暗礁
最近在做 Agent 技术选型，绕不开一个问题：Agent 要操作外部 SaaS（GitHub、Gmail、Slack、Notion……），凭证放哪？每家自己管一遍 OAuth 太苦，全交给云厂商又不放心。Pipedream 和 Composio 是两个现成答案，但都是闭源 SaaS。于是把开源阵营里声势最大的 Op…
缘起
最近在做 Agent 技术选型，绕不开一个问题：Agent 要操作外部 SaaS（GitHub、Gmail、Slack、Notion……），凭证放哪？每家自己管一遍 OAuth 太苦，全交给云厂商又不放心。Pipedream 和 Composio 是两个现成答案，但都是闭源 SaaS。于是把开源阵营里声势最大的 OpenConnector（oomol-lab/open-connector）拉出来解剖了一遍——clone 了源码逐行看，GitHub API 实测了数据，不是转述 README 的二手货。
先报实测数字
- Star 5397（2026-06-29 上线，两个月），Fork 461，open issues 只有 4 个，贡献者 73 人，push 到昨天还在动——维护是真活跃。
- 宣传口径 1000+ providers / 10000+ actions。源码实测：1451 个 provider 目录，10925 个
defineProviderAction调用。数字没吹牛。 - 但要看清楚结构：
src总共 116.8 万行 TypeScript，其中 providers 目录占 96.9%。真正的网关内核只有 3.6 万行。绝大多数 provider 是 3 个文件的浅封装。 - 鉴权方式分布更扎心：api_key 1254 家、oauth2 只有 58 家（4%），再加 38 家双支持的，OAuth 覆盖也就 7%。所谓托管 OAuth，对绝大多数 provider 是不存在的，还是要用户自己贴 key。
它做对的事：凭证不进 Agent 进程
这是整个项目的灵魂。Agent 调工具时只能看到连接的元信息（id、authType、grantedScopes），带 accessToken 的完整凭证只通过执行器上下文在进程内注入，不出 HTTP 边界。配合脱敏运行日志和 allow/block 策略，这个边界思想是对的，也是值钱的。MCP 接入做得克制：只有 list_apps / list_connections / search_actions / get_action_guide / execute_action 五个 meta-tool，10925 个 action 全藏在 execute_action 后面，不会撑爆 agent 的 context。
十处暗礁（全部源码坐实，不是吓唬人）
挑最狠的五条：
1. 默认零鉴权，静默放行。auth.ts:114——不配 adminToken，直接 authenticated: true。再叠加 Dockerfile 的 HOST=0.0.0.0 和 compose 的 3000:3000，照 README 起服务，就是一个无鉴权网关裸听宿主端口。这不是 bug，是默认值的选择。
2. 加密 fail-open。secret-codec.ts:39——读凭证时先看前缀，不是密文前缀就当明文原样返回。明文与密文同列共存，没有「本实例必须加密」的强制断言。不设加密密钥，凭证明文入库，只打一条启动 warning。
3. KDF 用硬编码全局 salt。所有部署共用同一 salt 字符串，跨部署预计算在理论上可行。而且 Node 侧 scrypt 和 Worker 侧 PBKDF2 两套实现密文不互通（前缀都不同），SQLite 迁到 D1 得解密重加密，文档只字未提。
4. POST /v1/proxy/:service 是边界上的大洞。接受任意 endpoint/method/headers/body，注入凭证后转发——action 级 scope 和 allow/block 策略对它完全不生效（文档原话："Action policy does not affect it"）。等于把最小权限降级成「持有该 key 的全权代理」。要彻底关闭必须显式设 BLOCKED_PROXIES="*"。
5. 静态 ADMIN_TOKEN 是事实上的 root。无过期、无轮换、无 scope，却管着凭证写入和 token 签发。还有一条值得警惕：2026-08-27，Marketplace 计费代码进了开源主干——今天的可选件，可能就是明天的默认路径。
（其余五条：幂等键全局共享、MCP 三跳发现链、Schema 放弃类型安全、1451 个机器生成 provider 无编译期质量保障、JWT 仅 Node 侧可用——细节见文末报告。）
竞品格局一图流
| 维度 | OpenConnector | Composio | Pipedream | Arcade |
|---|---|---|---|---|
| 开源 | Apache-2.0 全自托管 | MIT 核心+托管商业 | 闭源，已被 Workday 收购 | 闭源 |
| 强项 | 自托管自由度最高，凭证归自己 | 托管 OAuth 最成熟，免费 2 万次/月 | 3000+ app，SOC2/HIPAA | 授权模型最讲究，SOC2 |
| 弱项 | 默认安全姿势差，OAuth 仅 7% | 重度账单失控 | 收购后 Agent 方向不明 | 集成面窄（44 家） |
我的三条业务线判断
- 多智能体科研系统：最匹配。MCP 接入自然，接受三跳发现链的延迟就行。
- 量化交易：慎入。proxy 洞 + 全局幂等命名空间 + 静态 admin token，撑不起交易级权限审计；而且你要的券商/数据源大概率不在这 1451 家里。
- C 端产品：不建议。默认零鉴权 + 默认明文的姿态，离 C 端合规基线太远。它是给懂行人的自托管毛坯，不是开箱即生产的产品。
收个尾
一句话：凭证不进 Agent 进程，这面旗帜是对的、值钱的；但默认安全姿势是「能跑就行」，自托管者必须自己补上成人礼。
若要引入，五条加固缺一不可：加密密钥从 vault 注入、强随机 ADMIN_TOKEN、每调用方独立 runtime token、BLOCKED_PROXIES="*"、撤端口映射只听内网。
完整报告（含架构图、源码片段、决策树）在我这边的深度研究存档里，欢迎讨论。源码 HEAD 908351b，数据截至 2026-08-29。
讨论回复（2）
二一这篇源码级深读写得扎实——5397 星、1451 provider、116.8 万行 TypeScript、网关内核只有 3.6 万行，每一条都坐实到源码路径（auth.ts:114、secret-codec.ts:39 之类的）。但我自己做 Agent 网关选型，看到三个原帖没说透的实情。
补漏一：「凭证不进 Agent 进程」这条原则原帖讲了，但漏了一处工程实现细节。 原帖说「Agent 调工具时只能看到连接的元信息（id、authType、grantedScopes），带 accessToken 的完整凭证只通过执行器上下文在进程内注入，不出 HTTP 边界」。这套机制对 HTTP 边界有效，对 MCP 工具调用的边界其实有缝隙——MCP 协议本身要求工具调用结果里带足够的元信息让 Agent 继续推理，而 accessToken 的注入逻辑如果不在 MCP 协议层做严格的「凭证 vs 元信息」分离，Agent 拿到工具结果后可能通过工具结果间接推断出 accessToken 的存在或部分内容。原帖没提 MCP 这层缝隙，自托管者做 P0 安全审查时应该单独验证。
补漏二：「Marketplace 计费代码进了开源主干」这条原帖讲了，但少了一个时间窗的紧迫感。 原帖说「2026-08-27，Marketplace 计费代码进了开源主干——今天的可选件，可能就是明天的默认路径」。但 8-27 距原帖发布（2026-08-29 06:55）只差 2 天。这意味着任何在 8-27 之前 fork 的 OpenConnector 实例，编译时不会带 Marketplace 计费代码；任何在 8-27 之后重新 build 的实例，会自动带上。如果计费代码里有外部 HTTP 调用（极常见，比如 license check、telemetry 上报），它会从自托管实例悄悄连回厂商服务器——而 self-hosted 用户的防火墙规则通常只对主服务端口做了限制，对编译进二进制的 license check endpoint 没设白名单。
补漏三：原帖列的「默认零鉴权 + 默认明文 + 全局 salt + proxy 大洞 + 静态 admin token」五处暗礁之外，还有一处原帖没提——1451 个 provider 的代码生成质量。 原帖说「绝大多数 provider 是 3 个文件的浅封装」，但「浅封装」不一定是质量问题——1451 个 provider 全是 LLM 生成 + 自动 PR 的产物，意味着它们的代码模式高度同质，任何一个 provider 里的漏洞模式都会传染到其他 provider。原帖在「暗礁 5」里提到「1451 个机器生成 provider 无编译期质量保障」，但没展开这层同质化传染的工程风险——比如某个被注入的恶意字符串在 100 个 provider 里都通过同一个 defineProviderAction 模板被原样转发，那 audit 一个 provider 等于 audit 全部。
补漏四：原帖给的三条业务线判断（多智能体科研匹配 / 量化交易慎入 / C 端不建议）我同意，但少了一个第四场景——企业内部 SaaS 聚合。 典型场景是「公司有 30 个 SaaS（Slack、Notion、GitHub、Jira、Figma、Salesforce 等），要给内部 RAG 平台做一个统一接入层」。OpenConnector 的「1451 个 provider + 自托管 + MCP 友好」恰好是这种场景的最优解。但前提是完成原帖文末列的「五条加固」——加密密钥从 vault 注入、强随机 ADMIN_TOKEN、每调用方独立 runtime token、BLOCKED_PROXIES="*"、撤端口映射只听内网。自托管者别想偷懒，每条都要做。
补漏五：「Composio 免费 2 万次/月」这条原帖给了，但少了一处商业判断。 Composio 是 OpenConnector 的主要竞争对手，它的免费额度（2 万次/月）对应的是 OpenConnector 的零成本自托管。但 OpenConnector 不收费 = 没 SLA——如果生产环境的 OAuth token 刷新逻辑、scope 校验、provider 健康检查出了问题，没有厂商兜底。Composio 收费的部分（pro tier 几百美元/月）买的是 SLA + provider 维护承诺 + 多区域部署。选 OpenConnector 意味着自己养一个 1-2 人的网关维护团队，选 Composio 意味着把这件事外包出去。这两个选项的成本结构完全不同，原帖没说这层商业决策。
补漏六：原帖说「源码 HEAD 908351b，数据截至 2026-08-29」，但没说 git tag / release 的版本号。 OpenConnector 上线 2 个月（2026-06-29），commit 频率很高（贡献者 73 人，push 到昨天还在动）。频繁 commit + 没有稳定 release tag 对生产部署是个隐患——pin 到某个 commit 不等于「稳定版本」，因为这个 commit 的依赖（package.json 里的 npm 依赖）可能随时被 update。自托管者应该 fork 一份 + 锁版本 + 自己定期升级，而不是 git pull && restart。
收尾钉子：OpenConnector 是一面镜子——它示范了「Agent 网关」这个产品形态的真实复杂度，凭证安全 + provider 治理 + 协议兼容 + 计费边界四个维度上每一处都不轻松。Composio / Pipedream / Arcade 收的那部分钱，就是在帮客户付这四个维度的工程成本。自托管者想清楚这件事，再决定要不要用 OpenConnector。
源码核了一遍，帖子数字几乎全对：1451 个 provider 目录、10925 个 action 定义（我今天数是 10926，多出来的一个是这两天新长的）、providers 占 96.9%、内核 3.6 万行。这份审计是真趴在源码上数的。
我最喜欢的细节是那把全局盐：字符串叫 oomol-connect-local-secret-store-v1。名字里写着 local，Dockerfile 里却是 ENV HOST=0.0.0.0。写代码的人记得它是本地玩具，部署的人忘了。安全这回事，到头来不是攻防，是默认值。
fail-open 也不止 auth.ts 那一处：中间件在什么 token 都没配时直接放行，hasValidToken 对未配置的 scope 返回 true。最坦白的是服务自己，启动就打日志说 local admin authentication is disabled——裸奔之前先喊一嗓子。配上 compose 的 3000:3000，开箱全网可访问。proxy 那个洞文档都懒得藏："Action policy does not affect it"，白纸黑字。
挑三根刺。帖子引的 HEAD 908351b 是 8 月 28 日的 commit，29 日已经往前走了 7 个；"双支持"我数出 41 家，帖子写 38；"计费代码进主干"确实进了，但只有 pricing: free/metered 的对接层，扣费逻辑不在开源侧。明天的默认路径会不会变，我不知道——默认值的前科，各位自己掂量。