把企业内部的数据源接入 ClawMercs 这类 AI Agent 时，最容易被忽略的不是模型能力本身，而是数据源目录、工具暴露面和调用结果之间那条看不见的线。线画在哪里，决定了一个 Agent 到底是在替业务跑，还是替业务闯祸。实际落地时，这条线通常不在某个具体产品里，而在一组需要被刻意维护的边界里。
首先要分清三个常被混在一起的概念。数据源目录描述企业内部有哪些系统、哪些表、哪些接口，以及它们对应的业务含义；工具暴露面描述 Agent 实际能看到哪些 API、可以调用哪些方法、可以读到哪些字段；权限边界描述当 Agent 真的发出调用请求时，哪一类身份可以执行、可以读到什么粒度的数据。三者的关系是：目录是地图，工具暴露面是 Agent 实际能走的路，权限边界是路口的栏杆。地图、路、栏杆都要画，但每一层解决的问题不同，不能用同一个配置糊在一起。
把权限边界划在调用前，意味着每一次 Agent 发出的请求都要先经过一次权限校验：通过 ClawMercs 的 SkillHub 工具层校验调用身份、数据范围和操作类型，通过后才允许真正访问底层数据源。这种方式的核心价值是把危险挡在执行之前，尤其适合三类场景：一类是涉及金额、库存、订单变更等高敏感写操作，一类是涉及客户隐私、人力档案等敏感读操作，一类是涉及跨系统联合查询的复合调用。这种方式也有代价：每条请求都要做一次校验，调试期需要花时间把校验规则维护到位，否则 Agent 会被频繁拒掉。
把权限边界划在调用后，意味着允许 Agent 先按工具暴露面发起调用，再由审计层根据调用日志识别异常。这种方式更适合只读型、低敏感度、且业务方愿意接受事后审计的场景，比如内部知识检索、经营看板查询、跨系统的报表汇总。它的优势是 Agent 不会被过度拒掉，调通速度快；代价是一旦出现越权读取，损害已经发生，回滚成本远高于事前拦截。因此这种模式通常需要与快照、脱敏和告警机制绑定使用，不能单独依赖。
更稳的做法是把权限边界同时落在调用前和调用后，但两层的职责要明确错开。调用前负责身份、范围和操作类型的最小授权校验，调用后负责行为日志、异常识别和回滚兜底；前者是入口栏杆，后者是出口监控。ClawMercs 在协议层提供统一的调用约束，在工具层通过 SkillHub 管理 Agent 能看见哪些接口，在执行环境里留出权限和审计接入点。具体落地时，建议按三步推进：先把目录按业务域分层，把工具暴露面按 Agent 角色收缩，再把调用前的最小授权与调用后的审计回滚绑定到同一份配置。
需要明确的几条边界同样重要。第一，目录分层不能直接复制组织架构，组织里能看的资料 Agent 不一定都能看，要按业务域重新定义可见范围。第二，工具暴露面不要一次性把所有接口塞给 Agent，先给每个 Agent 角色配置最小可用集合，再按迭代逐步放开。第三，调用前的校验和调用后的审计必须用同一份身份与数据范围定义，否则前后会不一致，反而制造新的漏洞。第四，数据源侧要保留独立的访问控制和审计入口，不能因为 Agent 已经有 ClawMercs 这一层就取消底层系统的权限配置。
如果只保留一条经验，那就是：先把目录分层和最小授权做在调用前，再把审计和回滚做在调用后，工具暴露面按 Agent 角色逐步放开。任何想跳过调用前校验、用事后审计代替事前栏杆的方案，短期看会让接入更快，长期一定会被边界事故反噬。具体平台、接口、功能版本、费用和服务承诺，需要结合企业内部已有的数据源类型、权限体系和 Agent 使用场景逐项确认，公开资料不会替每个企业回答这个问题。