问题的本质

多 Agent 系统在企业落地时，最常见的误区是：先跑起来再说，权限和安全以后补。

但现实是——当 Agent 开始调用数据库、写文件、操作生产系统时，权限设计就不是可选项了，而是生死线。

权限隔离：从共享沙箱到命名空间

最小权限原则

每个 Agent 应该只拥有完成其职责所需的最小权限。这听起来简单，但在 Agent 框架中实现却不容易，因为 Agent 的 Tool 调用往往是动态的——一个对话内，Agent 可能调用 3 个不同的 Tool，每个 Tool 的权限边界不同。

实操方案

1. 命名空间隔离

每个 Agent 运行在独立的逻辑命名空间中，Namespace 决定了：

• 能访问哪些 Tool
• 能读写哪些数据源
• 能调用哪些外部 API

2. RBAC + ABAC 双层校验

• RBAC（角色级）：定义 Agent 的角色（如"只读分析员"、“写操作员”、“管理员”）
• ABAC（属性级）：在每次 Tool 调用时，检查调用者的属性（时间、IP、来源上下文、风险等级）

双层校验的关键在于：RBAC 划定范围，ABAC 做实时决策。单纯 RBAC 会导致权限过粗，单纯 ABAC 则管理成本过高。

3. 人工确认网关

对于涉及敏感操作（如写入数据库、发送邮件、执行命令）的 Tool 调用，设计一个"人工确认"中间层。Agent 发出请求 → 等待人工确认 → 放行或拒绝。这个机制在高风险场景中是不可或缺的，也是用户信任 Agent 的基础。

风险治理：全链路可观测性

护栏模型（Guardrails）

Guardrails 不是简单的关键字过滤，而是部署一个专门的"Agent 监控 Agent"，实时审查：

当智能体有了"自主权"，谁为它的行为负责？

前几篇文章讨论的问题——幻觉、工具调用失败、崩溃、协调混乱——都是技术可解的。但有一类问题超越了技术范畴：当智能体越来越多地代替人做决策和行动时，谁来为后果负责？

McKinsey 2026 年 AI 信任成熟度调研覆盖了数千家企业，核心发现是：企业对 AI 的信任没有跟上 AI 能力的增长。随着 Agent 从"辅助工具"走向"自主行动者"，治理和问责缺位成了最紧迫的系统性风险。

这不是"以后再考虑"的问题。2025 年已经有多起因 AI Agent 自主行动导致的业务事故：

• 客服 Agent 自作主张给用户全额退款
• 营销 Agent 向错误人群发送敏感促销
• 数据处理 Agent 把内部数据写入了外部系统

每一件事的直接原因都是技术层面的（幻觉、工具错误），但根本原因是治理框架缺失——没有人为 Agent 的行动设定边界。

四大治理挑战

挑战一：权限边界模糊

核心问题

智能体能干什么？哪些决策它可以自己做？哪些必须请示？

大多数 Agent 系统根本没有清晰定义权限边界。系统 prompt 里写了"帮用户处理订单"，但没有写：

• 你可以取消订单吗？
• 你可以修改价格吗？
• 你可以给超过 100 元的订单退款吗？
• 你可以查看其他用户的数据吗？

为什么重要

权限不清时，Agent 的两种倾向都会出问题：

• 过度谨慎：什么都问用户，失去自动化的意义
• 过度激进：什么都自己做，出了事不可控

现实中的 Agent 往往走向后者——因为"帮用户解决问题"的指令天然偏向行动，而非克制。

类别

权限至少需要从三个维度定义：

1. 数据维度：能访问什么数据？能读哪些？能写哪些？
2. 操作维度：能执行哪些操作？取消订单 vs 修改地址 vs 查看物流？
3. 金额维度：操作有财务影响时，上限在哪里？

挑战二：审计追踪缺失

核心问题

Agent 做了一个决策，事后能否完整回溯"它为什么这样做"？

目前多数 Agent 系统的回答是：不能。

• 推理过程只存在于 LLM 的上下文中，运行结束后消失
• 工具调用的参数和返回值可能记录了，但"为什么选择调这个工具"没有记录
• 多步推理中，前面步骤的中间结论影响了后面决策，但这些因果链没有被显式记录

后果

没有审计追踪 = 没有问责基础。