连接器把 Agent 接进知识库、CRM、ERP、日历、邮箱和审批系统，也是企业 AI 最容易被低估的运行责任。授权成功只是开始，真正的管理周期包括申请、授权、验证、使用、续期、扩权、降权、失效和撤销。
每个连接器都要有一张真实状态卡
| 字段 | 为什么需要 |
|---|---|
| 连接的系统与账号 | 防止把测试账号当生产账号 |
| 授权主体与所属组织 | 确认是谁代表谁授权 |
| 已申请与已授予权限 | 区分想要什么和实际拿到什么 |
| 允许读取/写入的对象 | 把权限翻译成业务语言 |
| 最近成功验证时间 | 避免只看“已连接”假绿 |
| 到期与续期状态 | 提前处理令牌失效 |
| 使用中的 Agent/技能 | 扩权或撤销前判断影响范围 |
| 最近错误与重授权入口 | 让 IT 能直接处置 |
状态不能只靠数据库里“connected=true”。应定期执行无副作用的真实能力验证，例如读取本人信息或一个授权范围内的样本对象，并记录返回的权限事实。
最小权限要跟随能力选择
企业启用“读取日历”时，不应顺手申请发送邮件、管理通讯录和删除文档。正确链路是：用户选择能力，服务端将能力映射到允许的权限白名单，授权页展示用途，回调后保存实际授予范围，运行时再次校验。
新增“创建日程”后，需要申请增量权限并重新授权；关闭能力时，如果平台或第三方支持降权，应收窄范围，否则至少在后端停止使用对应权限。前端展示目录和真实授权范围必须一致。
失效不能等到任务报错才发现
连接器失效会让定时任务、长任务和共享 Agent 同时受影响。平台应在到期前续期或提醒；连续验证失败时暂停相关写操作，列出受影响任务，并把错误分为令牌失效、权限不足、接口限流、对象不存在和第三方故障。
不应把所有失败统一提示成“系统繁忙”。管理员需要明确知道是重新授权、申请扩权、修复映射还是等待第三方恢复。
撤销前先处理在途任务
撤销连接器属于有业务影响的动作。页面应展示正在运行的任务、依赖该连接器的 Agent 和下次定时触发。确认后停止新任务获取能力，让在途任务安全挂起或转人工，再撤销令牌。历史审计、动作回执和业务对象关联应按保留策略继续存在。
权限的后端交集可参考企业 Agent 权限三重校验；系统接入前的事实准备见业务系统怎样成为 Agent 事实源。需要梳理现有系统的连接与授权边界，可从企业知识中枢开始。
共享连接与个人连接要分开
组织级连接器代表企业访问公共知识或业务系统，应由组织管理员配置，并使用专门的服务身份；个人连接器代表员工自己的邮箱、日历或文件，权限随本人身份变化。不能为了省事，把某个员工的个人授权当成全公司的长期凭据。
共享 Agent 执行动作时，还要校验请求人的业务权限。即使服务账号能读取全部客户，普通员工提出请求时也只能得到其本来有权看到的范围。连接器的技术能力不等于用户授权。
数据映射也属于连接器契约
连接成功不代表数据可用。客户 ID、订单状态、金额口径、时间区和枚举值怎样映射，都应形成版本化契约。第三方新增字段通常问题不大，字段改义、状态停用和分页行为变化才会造成静默错误。
每次升级先在样本数据上对比旧新结果，再放入少量真实任务。出现映射冲突时停止写入，把原始对象、转换结果和规则版本送入异常队列。
定期盘点“有授权、无人使用”的连接
长期没有任何 Agent 或员工使用的高权限连接器，会增加攻击面和续期成本。管理后台应列出最近使用时间、调用者和依赖任务，经过 Owner 确认后降权或撤销。相反，频繁失败但业务仍依赖的连接器要优先修复，不能因为看板仍显示已连接就忽略。
