OpenClaw 这类 Agent 框架一旦接入外部系统，连接器就会变成风险最集中的地方。读知识库、查表格、写工单、发消息、改权限，这些动作单独看都不复杂，但只要组合起来，就必须能回答一个问题：谁读了什么，写了哪里，为什么这样做。
连接器审计不是企业大团队才需要。只要 Agent 能访问真实业务系统，就应该留下可追踪证据。前面讲 权限与凭证管理 时强调过最小权限，讲 工具权限模型 时也拆过只读、草稿、执行和回滚。连接器审计就是把这些规则落实到调用记录里。
先把读写权限分开
最基础的做法，是把连接器按 read、draft、write、admin 分层。读资料和写外部系统不是一回事，生成草稿和直接发送也不是一回事。很多事故不是因为 Agent 能力太强，而是因为一个连接器同时拥有过多权限。
比如知识库查询可以默认只读，任务系统可以先生成草稿，邮件发送和权限修改必须人工确认。这样即使 Agent 判断错了，也不至于马上影响外部系统。
调用日志要记录到参数级
只记录“调用了某个工具”远远不够。审计日志至少要包含任务 ID、连接器名称、动作类型、参数摘要、数据范围、返回状态、触发人、确认人和时间。对敏感字段可以脱敏，但不能完全丢掉证据。
这和 OpenClaw 日志复盘 是同一条线。没有参数级记录，后面很难判断是输入错、工具错、权限错，还是外部系统返回了异常。
数据范围要有边界
连接器不是越开放越好。查 CRM 时，只给当前任务需要的客户范围；查文档时，只给相关项目空间；写表格时，只允许写入指定工作表和字段。范围越清楚，审计越容易，误伤也越少。
如果 Agent 经常需要跨系统检索，可以先让它提出需要访问的数据范围，再由人或规则确认。这样比直接开放全量权限更稳。
异常告警要贴近业务
审计不是为了事后翻日志而已，还要能提前发现异常。比如短时间内大量读取客户资料、夜间批量写入、同一任务重复发送、调用了平时不用的高风险连接器，都应该触发告警或进入人工复核。
这里可以接上 失败重试与幂等设计。如果一次写入已经成功，下一次重复调用就不应该静默执行，而要检查幂等键或进入确认状态。
总结
OpenClaw 连接器审计的核心，是让每次外部系统访问都可解释、可追踪、可复盘。读写权限分开，调用记录到参数级，数据范围有边界，异常有告警，Agent 才能更稳地进入真实业务流程。
