一个我一直在回避的问题#

过去几年做自动化，我的默认路径基本固定：先找接口。有官方 API 就用 API，没有就看有没有 MCP，没有就翻 SDK 和 webhook，一个都没有，就退到自己写爬虫，或者干脆放弃，把它列进「暂时自动化不了」的清单。

清单一直在变长。政府办事门户、保险理赔材料、供应商后台、还在用传真的诊所表单，这些东西的共同点是：它们不会有接口，而且不是「暂时没有」，是永远不会有。

MindStudio 在 9 月 23 日发布的一篇访谈里，OpenAI 负责 Codex 桌面应用的工程师给了一个不同的答案：这类工作不需要接口，让 Agent 自己看屏幕、移动指针、点按钮就行。他们把这项能力称作 universal connector，通用连接器。

这个说法值得认真对待，因为说它的人不是在做概念营销，而是在解释一个已经跨过临界点的产品能力。

计算机使用到底是什么#

先把定义说清楚，避免和「写代码」混在一起。

计算机使用指的是 Agent 像一个真人那样操作软件：移动光标、点击按钮、滚动页面、在真实的应用和网站里填表，而不是在背后调用某个接口。它和 MCP、和传统的 API 集成，回答的是两类不同的问题。

在 Codex 里，这件事的起点是开发者工具。早期版本会把 Agent 实际执行的脚本、选择器、点击坐标直接铺在屏幕上，工程师可以盯着看、可以调试。透明度对调试自动化的人来说是优点，一旦受众换成只想要结果的普通人，这套呈现方式就不成立了。

Codex 从命令行工具长成桌面应用之后，设计跟着变了。屏幕上不再显示代码，只有一个指针在点来点去，有时配一个画中画的预览窗口，让你能看到动作发生在哪里。

关键的一点是：底下干活的模型基本没换，还是编码 Agent 那套架构。换掉的只是呈现方式。机制看得更少了，对结果正确的信任要求更高了。

真正的转折点是速度，不是能力#

如果只看能力清单，计算机使用很多年前就能演示。工程师的原话是，有很长一段时间它只是一个 impressive party trick，令人印象深刻的派对把戏：能跑通，但慢到你不会想在日常工作里用第二次。

过去一年左右跨过了临界点。这里有一个我觉得比速度本身更有意思的细节：快到一个程度之后，人们开始不再注意到 Agent 什么时候从直连接口悄悄切换成了点界面。任务完成了，用什么方法完成的，没人再关心。

这是自动化真正被接纳的标志。不是它能做，而是它做的时候你不再盯着看。

对做 Agent 产品的人来说，这条观察有一个不太舒服的推论：可见性在调试期是资产，在规模期是负担。同一个特性，在验证阶段是卖点，在交付阶段是干扰。什么时候把机制藏起来，比把它做出来更难判断。

长尾才是它真正的市场#

MCP 和直连接口的优势很实在：更快，更省 token，契约稳定。但这些优势有一个前提，那就是集成已经存在。

现实中大多数人每天要打交道的系统，是不会有集成的。文章里举的例子很具体：政府门户、保险材料、还在走传真的儿科诊所表单、老企业内部系统。这些系统不会有人专门为它们写 connector，写的人既没有动机，也没有权限。

那位工程师说他最初低估了「计算机使用的 scaling law 潜力」，他原本以为机器可读的接口总会赢。等到计算机使用变得够快够可靠，它就成了一个对任何有屏幕的东西都成立的兜底方案：不用管有没有人做过集成。

对今天在 Agent 上做东西的人，这条推论可以直接落地：不要等厂商发 API。只要一个任务能通过浏览器或桌面应用完成，Agent 就有可能被直接指过去做。

那还要不要写 connector#

要写。这不是我的判断，是 OpenAI 自己的做法。

他们的框架很清楚：一个服务如果足够常见、足够重要，就值得专门投入做 connector；剩下那条长长的尾巴，交给计算机使用。两条路线是同一时期一起扩张的，不是谁取代谁。

文章里还有一个不太被提及的观察：模型质量的提升让已有 connector 的价值大幅上升。原因是早期模型即使插件就摆在面前，也不见得会用。这句话对做集成的人是好消息，也让「集成没用」这种论调站不住脚。

把两边的取舍整理成一张表，判断会清楚很多：

判断维度写 connector用计算机使用
调用频率高频、日常核心流程偶尔一次、没有固定周期
延迟与成本更低，token 消耗可控逐步点击，更慢更贵
稳定性接口契约明确，可监控依赖界面，改版即失效
覆盖面通常只是服务能力的子集界面上能做的全部，包括没打算开放的部分
前置条件有人愿意做，且有权限做只要有屏幕就能试
适用场景Slack、邮件这类通用服务长尾系统，永远等不到集成

我的读法是：前两行决定值不值得投入，后两行决定能不能用。很多团队卡住的不是不想写 connector，而是那个服务根本不给你接口，这时候表格的最后一列就成了唯一选项。

真实使用长什么样#

访谈里举的例子基本都不在写代码的范围内，这一点比想象中重要。

一位工程师提到，Codex 帮忙审查个人报税文件时发现了一处错误，方向对用户有利，价值数千美元。他做的只是让 Agent 读一遍材料。其他人描述的场景更琐碎：填表、翻 PDF、在互不相通的系统之间找信息、读信息、再手工转录。这些活没有技术含量，但消耗人的注意力和时间。

内部渗透也不是齐头并进的。编码团队先跑起来，因为他们的工作本来就在命令行里，Agent 能直接操作。法务这类团队要等到条件满足才跟上：模型对大量材料的推理能力够用，并且能拿到文件访问权限。每个团队有自己的临界点，取决于模型在它那类工作上是否够好，以及当时能拿到什么数据。

这句话我认为比「某公司四个月渗透率到 90%」这类数字更有价值。它解释了为什么同一条技术曲线，在不同职能之间会差出几年。不是意愿问题，是临界点位置不同。

最难的那部分不是技术#

工程师总结的行为转变很朴素：任务来了，第一反应是自己动手做掉。真正改变结果的习惯是在那一下拦住自己，先把它路由给 Agent，然后检查结果，而不是默认自己干。

这是整篇访谈里最实用的一句，也是最难执行的一句。因为它要求你在最忙、最急、最想立刻推进的时刻，停下来做一个额外的交付动作，而回报要等几分钟甚至几小时才出现。理性的判断和身体的反应用的是两套系统。

我自己在这件事上的实际经验是：能不能坚持下去，取决于第一次尝到甜头的速度。找一个你每周都要做、流程固定、结果好验证的小任务先跑通，比一开始就上大工程有效得多。

三点补充#

原文是访谈报道，下面这三点是我自己的延伸，原文没有展开，需要和原文观点区分开：

第一，把计算机使用当最后手段，不是第一选择。 它慢、贵、脆。合理的顺序是：官方 API 或 SDK，然后 MCP connector，然后才是点界面。OpenAI 自己的框架也是这个顺序，通用连接器的定位是兜底，不是主力。把它当主力用，你会在延迟和 token 账单上先受一次教育。

第二，点界面绕开的是接口自带的权限边界。 Agent 在你的浏览器里点，等于用你的登录态在点。接口可以用密钥范围、调用配额、审计日志把权限框住，屏幕操作没有这些天然边界。批准策略、凭据隔离、可回滚，这三件事得先想清楚，再让它碰真实账号。这条是常识层面的推论，不是访谈里的原话，但它是落地时最先出问题的地方。

第三，方法越不透明，验证越要前置。 当机制被藏起来，你剩下的可见性就只有结果。判定标准写清楚、关键动作留痕、输出可复核，这三件事的价值比过去更高。这也是我一直主张把「它能做完」和「我能确认它做对了」当成两个独立问题来评估的原因。

还有一条给做产品的人：如果你的产品是别人流程里的一环，值得问一句，没有 API 的 Agent 会怎么用你。界面语义清晰、错误信息可读、关键操作可回退，这些要求过去是提给人的，现在同时也是提给 Agent 的。

结语#

universal connector 这个说法本身是一个赌注：赌长尾软件的总量大到值得为它准备一条缓慢但通用的路径。

我认为这个赌注是成立的。企业软件的历史一直在证明同一件事：接口的供给永远追不上需求的样子。每开放一批 API，就有新的系统长出来，而这些系统在诞生的时候，根本没打算被人自动化。

所以更现实的做法可能是接受两条并行的路径。常见服务走 connector，把速度和成本压到最低；那些永远等不到接口的系统，就让 Agent 抬起它的虚拟鼠标。

参考来源#