UnifAPI 与 OOMOL 达成合作：公开数据读取遇上 OAuth 写入

一句话总结：UnifAPI 现已成为 OOMOL 开源 OpenConnector 的原生 provider，把我们的完整公开数据目录——全部 16 个平台——镜像为带类型、可调用的 Actions。管理员用一个工作区 API key 连接一次 UnifAPI，全公司就能通过这条共享连接读取实时公开数据，并与 OOMOL 已经代理的 OAuth 写入工具并肩工作。有人离职时，在 OOMOL 里点一下移除权限即可——UnifAPI 这边什么都不用改。

Agent 集成从来都分成两半。一半是私有的：用户自己的 Gmail、Notion、Linear、Slack——只有用户本人才能授权访问的数据，通常走 OAuth，通常带写入权限。另一半是公开的：帖子、档案、视频、讨论串、排名、SERP——任何拿着浏览器的人都能读到的证据，而这正是 UnifAPI 的全部产品。

在此之前，团队得分头接这两半：OAuth 工具交给连接器平台，公开数据走直连 key 或 MCP，于是"谁有访问权限、如何回收"这个问题也有了两套互不相通的答案。今天我们把这个断层补上了：UnifAPI 已成为 OOMOL OpenConnector 的内置 provider，公开数据这一半和 OAuth 那一半从此住进同一个网关、同一份目录、同一套团队管理界面。

OOMOL 是谁

OOMOL 为 Agent 以及运营它们的团队构建集成基础设施。如果你拿它对标 Composio，方向没错——一个在 Agent 与第三方服务之间代理鉴权的连接器网关——但 OOMOL 是从一个不寻常的方向走到这里的，而这段"绕路"恰恰体现在产品里。

这家公司在 2025 年年中首次登上 Hacker News，主角是 OOMOL Studio，定位是本地优先、代码优先（local-first, code-first）的工作流自动化引擎。Zapier 和 n8n 给你的是一块预置节点的画布，其余一切都塞进一个逼仄的表达式输入框；而 Studio 构建在 VS Code 基座之上：工作流里的每个 block 都是真实的 Python 或 Node.js 代码，跑在容器里，第三方库在任何机器上的行为都完全一致。画布之下是 OOCANA，一个用 Rust 实现的工作流引擎，通过纯 YAML 文件声明的 flow 和 block 完成调度。Block 和工作流模板都可以共享，团队积累下来的是一库能直接运行的组件，而不是一堆节点图截图。

围绕这个内核，整个生态按 Agent 基础设施的典型路径生长起来：oo CLI，一个让 Agent 搜索、审视并运行已发布工具的命令行中继；OOMOL Cloud，为需要持续交付和托管配置的工作流提供托管运行时；还有 Wanta，一款桌面应用——账户连接一次，就能用自然语言横跨所有已连接的工具工作。

把这一切串联起来的结缔组织，是 OpenConnector——也就是 UnifAPI 现在接入的那一块。

OpenConnector 内部

OpenConnector 是一个 Apache-2.0 协议的开源连接器网关。它的口号是 "Connect Once. Use Everywhere."（连接一次，处处可用），而且说到做到：账号连接一次，一份覆盖 1,000+ providers、9,400+ 预置 Actions 的共享目录，就能从团队使用的任何界面调用——应用代码里的 TypeScript SDK、作为本地 Agent 中继的 oo CLI、Agent 宿主里的 MCP、自定义客户端的纯 HTTP/OpenAPI，以及一个用于管理和调试的 Web Console。

有两个设计决策对下文至关重要。

第一，每个 Action 都是一份可审视的契约：请求/响应 schema、所需权限范围、乃至执行器源码本身都是可读的。在 Agent 调用某个 Action 之前，你就能审计它到底做什么——这与我们对 OpenAPI 的态度如出一辙："读契约，别读营销稿"。

第二，凭据与使用它们的 Agent 在架构上是隔离的。API key 和 OAuth 令牌落盘加密封存（AES-256-GCM），Agent 通过服务端流程调用、永远看不到原始密钥，允许/阻止策略（allow/block policies）划定每个调用方可以使用哪些 Actions，每次调用都写入一条审计记录——调用者、权限范围、时间戳、结果——运行日志中的输出经过脱敏。一个失控的 Agent 可以在策略层被直接切断；它从头到尾就没拿到过那把 key。

机制就是这些。下面说说为什么 UnifAPI 属于这里。

眼睛遇上双手

UnifAPI 的定位从第一天起就没变过：只做眼睛，不做双手（eyes, not hands）。我们读取公开数据——TikTok、LinkedIn、Instagram、YouTube、Twitter/X、Threads、Reddit、Hacker News、新闻、SEO 和 GEO 信号、地图与本地商户——把它们归一化成统一封装，并且永远不持有你的发布凭据。调研、监测、审计、估价：全是读操作。

OOMOL 的目录则在另一半最强。那 1,000+ providers 的大头是接入私有 SaaS 的 OAuth——也就是那双手。它的连接让 Agent 能在用户真正拥有的账户里执行操作：发出那条 Slack 消息、更新那页 Notion、创建那个 Linear 工单、起草那封邮件。

于是双方的缺口恰好是对方的产品。一个装满写入工具的连接器网关，仍然需要可供行动的证据，而构建一个实时、归一化、在法律边界上足够谨慎的公开数据层是一个全职产品，不是一个附加功能。一个公开数据层也需要让结论有处安放，而代理数百个 SaaS 应用的 OAuth 同样是某个团队的全部工作。把两者放进同一个网关，整条链路就闭合了，而且双方都不用在自己的模型上妥协：

"找出本周 TikTok 创作者对我们产品发布的评价" → UnifAPI，公开读取。

"把摘要发到 #marketing 频道，并在 Linear 里创建跟进工单" → OOMOL 的 OAuth 连接，私有写入。

你的助手通过一份目录调用两边。UnifAPI 依然碰不到你的私有账户——这条边界是承重墙，不是偶然——OOMOL 也不必维护一个公开数据层，因为读操作来自一个唯一职责就是保持数据实时、归一化、按记录计价的 provider。

一把 key，全公司共用

这次合作里最让我们兴奋的，是 OOMOL 的团队层给 UnifAPI 上手体验带来的变化。

一把 UnifAPI API key 归属于一个 Workspace（工作区），消耗该工作区的 credits。在此之前，想在全公司共享它，就意味着 key 共享的老一套：贴进密钥库或 env 文件，祈祷它永远不会泄漏到某台笔记本、某个 notebook 或某个仓库里，每逢有人离职就轮换一次——然后再挨个排查旧 key 被缓存过的每一个角落。

通过 OOMOL，它变成了团队凭据本来该有的样子：

管理员在 UnifAPI 控制台创建一把 key，在 OOMOL 里保存为一条 UnifAPI 连接——只做一次。团队里的每个人都通过这条共享连接调用 UnifAPI，无论是在 Studio 工作流里、在 oo CLI 或 MCP 背后的 Agent 里，还是在跑着 SDK 的后端代码里。原始 key 从不流转；同事们按名称引用这条连接，密钥本身封存在网关内部。允许/阻止策略决定每个调用方可以使用哪些 Actions——分析师的调研 Agent 能读 TikTok 和 Reddit，实习生的实验碰不了 SEO 端点——审计记录则展示哪个系统用哪条连接做了什么。

有人离职时，在 OOMOL 里移除其访问权限即可。就这么多。不用轮换 key，不用重新部署，UnifAPI 这边什么都不用改——那把工作区 key 从头到尾就没到过离职者手里。用量继续流入同一个 UnifAPI 工作区，账单依然是一个余额、一本账、按记录计费。

每一个 UnifAPI 平台，都是带类型的 Actions

这不是换个 logo 的合作，也不是包了三个端点的薄壳。OpenConnector 里的 UnifAPI provider 逐平台镜像了我们的目录：TikTok、Twitter/X、Instagram、YouTube、LinkedIn、Threads、Reddit、Hacker News、新闻、SEO、GEO、地图、本地商户、酒店、活动，以及渲染浏览器抓取——与 unifapi.com/apis 背后完全相同的 16 个平台、220 个操作，每一个都被生成为带输入/输出 schema 的类型化 Action，Agent 在调用前就能审视。

因为这些 Actions 是从带类型的操作定义生成、而非手写的，provider 会持续跟踪我们的 OpenAPI 表面：目录扩张时，连接器随之扩张。计费在传输途中也不会变形——经 OOMOL 的调用消耗你的 UnifAPI 工作区 credits，按记录计价与直连 HTTP 或 MCP 完全相同，每个响应里也带同样的 billing 元数据。

开源，可自部署

OpenConnector 采用 Apache 2.0 协议，UnifAPI provider 就在公开目录里——你可以亲自读一读 provider 源码：API key 认证，以标准 Bearer 头发送，Actions 按平台生成。

这一点很重要，因为上面的团队故事并不要求你信任一个托管黑盒。你可以把整个网关跑在自己掌控的基础设施上——本地用 Docker 或 Node.js、Fly.io 配持久化 SQLite，或 Cloudflare Workers 配 D1 和 R2——拿到完全相同的 provider 目录和 Action 契约。OOMOL 的托管运行时是零运维路径，接口一致，所以先托管后自部署（或反过来）都不需要改动你的集成代码。

对于那些安全评审不允许把凭据路由给第三方 SaaS 的团队来说，这就是"有意思"和"能过审"之间的差别：凭据存储、策略引擎和审计日志可以全部留在你自己的边界之内。

通过 OOMOL 连接 UnifAPI

配置流程刻意做得很无聊：

1. 登录 UnifAPI 控制台，创建一把工作区 API key（只显示一次，以 unif_ 开头）。
2. 在 OOMOL 中新增一条 UnifAPI 连接并粘贴 key。此后 Authorization: Bearer 头由 OpenConnector 负责。
3. 在团队工作的任何地方调用 UnifAPI 操作——Studio 工作流、oo CLI、接入 MCP 的助手，或后端代码里的 SDK。

如果你是在 Claude 或 Codex 里跑 Skills 的个人操作者，unifapi.com/mcp 的直连路径依然是那个三分钟就能搞定的选项。OOMOL 则是把 UnifAPI 变成团队公共设施的路径：共享连接、按范围划定的策略、审计记录、一键离职回收。

这补上了三条闭环

几条过去要做两个集成项目、现在只需一个网关的工作流：

端到端的社交聆听。一个工作流通过 UnifAPI 读取 Reddit、TikTok 和 Twitter/X 上的品牌提及，在一个 Python block 里打分，再通过一条 OAuth 连接把晨报摘要发进团队的 Slack——读公开、写私有，一份目录，一条审计链。

留得下凭证的网红营销。一个工作流基于公开互动数据筛选创作者、为 KOL 估价，再把候选清单——连同引用的公开证据——写进团队的 Notion 工作区供评审。财务问某个数字从哪来时，运行日志就是答案。

自己开工单的竞争情报。一个定时工作流盯着竞品的公开发布、讨论串和排名，把任何可执行的发现变成团队任务追踪器里的工单，每一张都回链公开来源。

每一条链路的边界都保持干净：UnifAPI 提供可引用的公开证据；经 OOMOL 授权的用户自有账户承载动作。

更大的图景

Agent 大约在去年就不再是单人工具了。当一条工作流被共享出去——团队的 Slack 晨报、公司级的调研流水线、定时审计——问题就从"用哪个模型"变成了"谁能调用什么、用谁的凭据、他离职了怎么办"。这些是网关层面的问题，也是连接器网关成为 Agent 技术栈中独立一层的原因。

我们的答案分两部分。公开数据这一半，UnifAPI 保持本色：一把 key、一个统一封装、按记录计价、设计上只读。团队那一半，我们宁愿接入一个开放、可审视的网关，也不愿自建一个影子副本。OOMOL 的 OpenConnector 正是这样的网关——开源、可自部署、有一套我们敢指给自己客户看的安全模型。

连接一次。全公司都能读取公开网络。

推荐延伸阅读

UnifAPI 对比 Composio - 这次合作所依托的"两半拼图"框架。

通过 MCP 把 UnifAPI 接入 Claude - 面向个人操作者的 MCP 直连路径。

最小可行 Agent 技术栈 - 连接器网关与公开数据层在同一套架构中的位置。