← 返回概念解读

Concept Fable精修版

连接器

Connector · Platform / integration

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

每座仓库门口都装上了同一种锁舌

港城的调度楼想接入城里的仓库、账房、日历、工单和邮件。每个地方都有自己的门、自己的锁、自己的暗号。

最初,工程师为每个系统手工打一把钥匙。接上一个仓库很快,接上十个系统后,钥匙串重得没人敢碰。

麻烦从维护开始。账房换了门闩,邮件改了暗号,仓库新增权限章。调度楼昨天能进去,今天就被挡在门外。

有人提议把所有系统搬进同一座大楼。听起来整齐,但每个部门都有旧流程、审计要求和供应商限制,搬不动。

一位桥匠改做连接器。每个连接器只负责一件事:理解外部系统的门,向调度楼暴露稳定的入口,并把身份、权限、参数和错误翻译清楚。

调度楼不需要知道每座仓库内部怎么摆货,只需要知道连接器能取什么、能改什么、需要谁授权、失败会返回什么。

连接器也不是万能通道。高风险动作要审批,敏感字段要遮蔽,速率限制和查阅痕迹要跟着每次访问走。

后来新系统加入时,工程师不再从零打钥匙,而是按同一种连接模式接入。旧系统变更,也能在连接器边界内消化。城主明白,连接器的价值不是让所有系统变一样,而是给 办事助手 一个可靠、可治理的接触面。后来,又来了一件更棘手的活。表面看只是旧问题放大,实际把藏在流程里的缝隙都逼了出来:谁先接手、谁能改动、出了错怎样回到上一步,过去靠熟人默契混过去的地方,现在都必须说清楚。主事人没有再催大家更用心,而是把现场重新走了一遍。他让人记录每次交接、每次失败和每次补救,哪些地方只是慢,哪些地方会误伤结果,哪些地方一旦错了就很难追回。新规矩推开后,最初几天并不顺手。有人嫌多了一道检查,有人觉得旧经验被冒犯。可当下一次异常出现时,大家第一次能沿着痕迹找到问题发生的位置,而不是围着结果互相猜。

揭示

这个故事讲的是:连接器

Connector 是把 AI 系统接入外部应用、数据库、文件、SaaS 或企业系统的适配组件。它负责 API 调用、认证授权、权限边界、参数转换、错误处理、速率限制和审计,使 Agent 能稳定使用外部能力,而不是依赖一次性胶水代码。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 仓库、账房、日历、工单和邮件:企业外部系统与 SaaS
  • 手工钥匙:一次性集成代码
  • 门闩和暗号变化:API、schema、权限和供应商行为变化
  • 连接器:稳定的 integration adapter
  • 取什么、改什么、谁授权:capabilities、permissions、OAuth scopes
  • 审批、遮蔽、日志:治理、安全和审计控制
  • 最后洞察:Connector 把外部系统的复杂性封装成 Agent 可安全调用的边界

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

IntegrationAPIMCPtool callingOAuthdata sourcepermissions