AI 技能和连接器为什么要分开管理

“查询项目风险”是一项技能，“读取某套项目系统”是一条连接器。技能可以换数据源复用，连接器必须单独管理账号、权限和日志。二者分开后，企业才能在不改任务逻辑的情况下替换系统，也能准确追踪AI到底调用了什么。具体产品能力仍以当前官方资料和企业实测为准，不能只根据名称、演示效果或功能数量作决定。

不少AI平台把“能查数据库”“会写周报”“可以发消息”都放在技能列表里。用户看起来只需点一下，管理员却很难回答：这项能力使用了哪个账号，能读哪些数据，失败后由谁处理。

技能和连接器应该分开管理。技能描述任务方法，连接器提供系统通道。前者关心怎么做，后者关心连到哪里、凭什么访问。

库存查询失败时，究竟该改提示词还是修接口？

运营运行“生成本周低库存商品补货建议”。流程在读取 ERP 时失败，页面只提示“任务执行异常”。运营改了三次提示词，依然无结果。最后 IT 才发现：连接 ERP 的凭据已过期，且该账号原本就无权读取采购在途数量。

如果把“查库存”整体做成一个不可拆的 AI 能力，故障时就无法判断是连接、数据、步骤还是模型问题。把连接器和技能分开，实际上是为了让权限、测试和故障定位有明确对象。

一个具体例子就能看清区别

“生成版本风险报告”是一项技能：读取版本目标、需求、缺陷和测试结果，按规则识别阻断项，输出带来源的结论。它的业务逻辑可以复用。

数据可能来自嘟哩项目，也可能来自企业已有的Jira、TAPD或自建系统。每个数据源的接口、字段和权限不同，对应不同连接器。替换系统时，企业应主要调整连接映射，而不是重写整套风险分析方法。

混在一起会出现三类问题

第一，技能被某个系统绑死，无法复用。第二，用户只看到“可用”，不知道背后使用的是个人账号还是管理员账号。第三，审计日志只能记录技能成功，却说不清读取了哪些接口和字段。

更严重的是凭据扩散。每个技能都保存一份系统密钥，人员变更或接口升级时，管理员要逐个修改，也无法快速确认哪些能力仍在使用旧权限。

连接器要管凭据、范围和失败

连接器至少应记录所属企业、目标系统、认证方式、可调用工具、字段范围、调用限额、维护人和最近状态。高风险工具，如批量删除、发送外部消息、修改财务状态，应默认关闭或单独审批。

如果源系统支持用户级授权，AI应尽量继承发起人的权限；如果只能使用服务账号，平台需要在连接器层再限制项目或字段，并明确这不是源系统原生授权。

技能要管输入、步骤和产出

技能说明适用场景、必需输入、执行步骤、输出格式、异常处理和所需连接器。一个技能可以声明“需要项目读取连接器”，而不把具体厂商写死。

这样企业可以先测试技能逻辑，再由管理员为不同环境绑定连接器。开发环境使用测试账号，生产环境使用受控账号；员工看到的是同一项工作能力，管理员看到的是不同的数据边界。

嘟哩里怎样形成可管理组合

嘟哩AI的技能中心负责复用任务方法，连接器负责接入嘟哩业务和外部系统，专家或专家团在任务中选择技能。平台还需要展示授权阻塞、调用状态和结果来源。

真正可用的页面不应只列“已安装100个技能”，而应让管理员点开任一技能，看到它依赖哪些连接器、哪些部门可用、过去调用了多少次、失败集中在哪一步。

上线前做一次断开测试

主动撤销连接器权限，再运行相关技能。系统应明确提示缺少哪个授权，而不是生成一份看似完整但实际缺数据的结果。随后替换为另一数据源，验证技能是否仍能按相同格式工作。

能清楚失败、能更换数据源、能追踪调用，技能和连接器的分工才真正成立。

把同一任务拆成“通道”和“做法”

对象	连接器负责	技能负责
核心问题	怎样安全地读写 ERP	怎样从库存、销量和在途数量得出补货建议
主要配置	地址、凭据、工具白名单、超时、重试	输入字段、计算步骤、阈值、输出格式、人工确认点
权限对象	哪个源账号能调哪个接口	哪些用户能运行、能看哪些输出
版本变化	ERP 接口、字段或鉴权方式变化	补货规则、业务阈值或报告模板变化
失败信息	401、403、超时、字段缺失、写入冲突	输入不足、阈值冲突、无法得出建议、待人工确认

在嘟哩 AI 中，一个“低库存分析”技能可以调用 ERP 连接器，但不应自己保存一套隐藏账号。同一连接器也可为不同技能提供受控工具。这样轮换凭据时不需要重写业务步骤，修改补货规则时也不会破坏其他 ERP 任务。

上线前一定要拔掉一次连接

主动让测试凭据失效、删掉一个必填字段，再把 ERP 响应延迟到超时。检查页面能否说清失败在连接器还是技能步骤，是否禁止基于残缺数据继续给出补货结论，以及重试是否会造成重复写入。

技能和连接器分开，权限才不会混在一起

运营想让 AI 生成直播复盘，同时读取 ERP 库存和客服问题。这里至少有两件事：复盘分析是技能，读取 ERP 和客服系统是连接器。把两者混成一个“电商专家”，后面很难审计。

环节	要记录什么	通过标准
技能	分析模板、提示策略、输出格式、适用场景	决定 AI 怎么思考和写结果
连接器	系统账号、接口、读写范围、授权期限	决定 AI 能碰哪些数据
任务授权	本次目标、参数、确认人	决定这次能不能调用
输出治理	保存位置、可见范围、人工确认	决定结果能不能进入业务

技能可以复用，连接器必须受控。一个优秀的短剧分析技能不应该自动拥有云盘全部权限，一个电商复盘技能也不应该默认能写 ERP。

怎么验收

验收时用同一技能配两个不同权限账号，看结果是否变化；再用同一连接器配两个不同技能，看是否能限制读写动作。分不开，就会埋下越权风险。

真正落到产品页面时，要看到这些东西

选型小组进入AI 产品选型看板时，第一眼应该看到一次产品对比试用的当前状态，而不是一段功能介绍。入口动作也要直接：先放入同一组脱敏资料，再让不同产品处理同一条任务。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
技能	分析模板、提示策略、输出格式、适用场景	当前状态、责任人、来源链接、更新时间	AI 检查“决定 AI 怎么思考和写结果”，并给出缺口待办
连接器	系统账号、接口、读写范围、授权期限	当前状态、责任人、来源链接、更新时间	AI 检查“决定 AI 能碰哪些数据”，并给出缺口待办
任务授权	本次目标、参数、确认人	当前状态、责任人、来源链接、更新时间	AI 检查“决定这次能不能调用”，并给出缺口待办
输出治理	保存位置、可见范围、人工确认	当前状态、责任人、来源链接、更新时间	AI 检查“决定结果能不能进入业务”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

涉及竞品时不要用想象下结论。页面应把结论分成当前可验证、需配置验证、需等待版本确认三类，避免把路线图写成已经具备的能力。

读者真正会感受到的变化

以前选型会议容易变成功能清单比赛；现在是把同一条任务放进不同产品里现场跑。业务方看到实际产物，IT 看到接入成本，安全负责人看到权限和审计，最后能接受“适合、需配置、不适合”三种结论。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

MCP属于技能还是连接器？

MCP更接近标准化的工具与数据连接协议；具体业务方法仍应由技能或Agent流程定义。

一个技能可以使用多个连接器吗？

可以，例如电商复盘同时读取订单、直播和客服数据，但每个来源都要单独校验权限和状态。

普通员工需要看到技术凭据吗？

不需要。员工应看到能力、数据范围和授权状态；密钥等敏感配置由管理员管理。