OpenClaw 接入业务系统时，连接器很容易越接越多：知识库、表格、CRM、工单、邮箱、审批、云盘、数据库。真正的风险不是连接器数量，而是团队没有一张清单说明每个连接器能读什么、能写什么、谁批准、出了问题怎么查。
连接器权限清单可以接上 权限变更申请、模型分层调用 和 审计日志。它的价值是把工具能力变成可讨论的权限表，而不是藏在代码和配置里。
先按系统列连接器
第一步很简单：列出 OpenClaw 当前能访问哪些系统，每个系统的用途是什么，谁是业务负责人，谁是技术负责人。不要只写“内部系统”或“数据平台”，要写到具体连接器。
这张表后面会变成排查入口。某个 Agent 输出异常，团队能先看它有没有调用相关连接器，而不是在日志、配置和聊天记录里翻半天。
再把读写动作拆开
连接器权限不能只写“可用”。至少要拆成查询、下载、创建、修改、删除、外发、审批、触发流程等动作。读和写是两类风险，删除和外发又是更高风险。
比如同样是邮箱连接器，读取最近邮件、生成回复草稿、自动发送邮件、群发客户通知，应该对应不同权限和确认要求。只有拆到动作级，才谈得上最小权限。
给每个动作标风险等级
风险等级不需要一开始很复杂，可以先分低、中、高。低风险动作允许自动执行，中风险动作需要条件满足，高风险动作默认人工确认或审批。
这里可以参考 异常阈值 的思路：一旦失败率、重复写入、成本或人工超时超过阈值，连接器动作要能暂停，而不是继续自动跑。
日志字段要提前约定
连接器权限清单最后要落到日志。每次调用至少记录任务 ID、连接器、动作、数据范围、模型建议、授权来源、执行结果和失败原因。否则权限表只是文档，不能支撑复盘。
如果要做 成本归因报表，也可以顺手记录连接器调用次数、重试次数和人工复核次数。安全、成本和质量最终都要回到同一条执行链路看。
总结
OpenClaw 连接器权限清单的关键，是先列系统，再拆读写动作，标风险等级，明确审批要求，并把调用过程写进日志。连接器越多，越不能只靠口头约定。
