当一个企业里同时跑了多个 AI Agent，比如一个负责查客户档案，一个负责写合同草稿，一个负责发通知邮件，问题马上就会出现：到底谁能调用谁的工具，谁的输出可以直接被另一个 Agent 拿来用，出了错算谁的。
这不是一个新问题，但在多 Agent 同时上线之后会被迅速放大。一个 Agent 的权限没划清，轻则浪费预算，重则把内部数据发给外部服务。
企业里常见的三种划边界方式，可以按时间顺序记。
第一种是事前划清，也就是在 Agent 启动之前就把能调用哪些工具、能访问哪些数据、能给哪些 Agent 发消息全部列在一张 ACL 表里。它的好处是责任最清楚，出问题可以一眼看到是越权还是漏配；代价是每加一个 Agent 就要改一次表，跨部门流程变长。
第二种是调用中划清，也就是让 Agent 在真正调用外部工具之前，先过一道熔断和审计。熔断负责在金额、频次、敏感字段上做硬约束，审计负责把每一次调用的上下文、提示词片段、返回结果、调用方 Agent 都落表。它的好处是不需要在前期把权限想得很细，业务跑起来再补；代价是依赖日志完整度，一旦日志断点就难以追责。
第三种是事后划清，也就是默认 Agent 可以互相调用，只在发现异常结果时回溯责任。这种方式适合内部实验期或低风险任务，不适合直接面对客户或对外付款的场景。
判断该选哪一种，先回答两个问题。
第一个问题是 Agent 一旦出错会直接影响什么。如果会动钱、动合同、动客户数据，事前 ACL 不可省；只动内部报表或文档摘要，可以在调用中加审计。
第二个问题是团队规模和 Agent 数量。一个 Agent 加一个内部工具，可以靠调用中熔断；超过三个 Agent 互相调用、又涉及不同部门，事前 ACL 才会让协作不再卡在 IM 群里扯皮。
责任矩阵是另一种容易被忽略的产物。建议给每个 Agent 写明三件事：它主要负责的动作、它可以代为触发的动作、它必须把决定权交回给人的动作。
这张表不需要复杂格式，写在共享文档即可。它的价值是把谁负责从 Agent 的提示词里抽出来，变成可以被法务、合规和客户经理直接看的内容。
比较稳妥的做法是把三种方式组合起来，而不是只选一种。事前用一张精简的 ACL 写明不能越权的事；调用中用熔断和审计把高频动作卡住；事后用日志和责任矩阵做月度复盘。
如果某个 Agent 长期只触发低风险工具，可以从事前 ACL 里临时下放，事后再收回。这样既不会让流程僵化，也不会在关键时刻丢失责任链。