Marico's space

最近在项目中引入 AI 代理（Agent），踩了几个坑，这篇把问题说清楚。

AI 代理的能力越来越强了。

能搜信息、能跨数据推理、能调用工具、能操作应用，越来越频繁地替我们干活。

机会是巨大的。

但也引出了一个我觉得值得更多关注的问题：

AI 代理“能”访问某样东西，就意味着它“应该”访问吗？

当我们从主要生成回答的 AI 助手，走向能执行动作的代理时，负责任的 AI（Responsible AI）越来越变成一个架构问题——不只是模型问题，也不只是策略问题。

其中最重要的架构决策之一，可能是精确界定：代理能看什么、能做什么、在什么条件下可以做。

别把代理当成应用程序本身

想象一个典型的企业应用。

这个应用可能有权访问：

• 公开信息
• 内部文档
• 机密业务数据
• 个人或敏感信息
• 管理服务
• 能修改数据的 API

一个常见的错误是：允许在这个应用中运行的 AI 代理继承所有这些能力。

我的观点是：代理应该被当作独立的身份实体，有自己的访问边界。

Enterprise Application │ ├── Public Data ├── Internal Data ├── Confidential Data ├── Sensitive / Regulated Data └── Administrative Services ↓ AI Agent Access Only what is required for the specific task

应用边界和代理边界不一定要重合。

用分层思维看待数据

一个实用的做法是：先对信息分类，再决定 AI 代理应该访问什么。

比如：

具体的分类标准因组织而异。

原则比分类本身更重要：

AI 的访问权限应该跟随数据敏感度，而不是技术上的可获取性。

如果代理技术上“能”查询某个数据库，这不意味着它能查询其中的每一张表。

把“能读”和“能操作”分开

另一个重要区分是信息访问权限和操作权限。

代理可能合理地被允许：

读取一条记录。

但这不自动意味着它应该被允许：

修改这条记录。

能修改也不一定意味着应该被允许：

删除、导出或审批它。

权限应该渐进式考虑：

READ ↓
CREATE ↓
UPDATE ↓
EXECUTE ↓
DELETE / EXPORT / APPROVE

越往下风险通常越高。

高影响操作可能需要额外控制——或人工审批。

给代理建立独立的身份

这是我认为会越来越重要的一个领域。

不要让代理通过宽泛的共享应用凭证来操作，而是把代理当作一个独立的身份实体。

这样我们才能回答：

• 哪个代理访问了信息？
• 代表谁访问的？
• 用了什么权限？
• 调用了什么工具？
• 结果是什么？

没有清晰的身份，追溯和问责就很难实现。

而没有问责的负责任 AI，很难真正落地。

工具也需要边界

代理越来越多地与各种工具交互：

Agent │ ├── Search ├── Database ├── Email ├── APIs ├── Workflow └── External Systems

让代理访问所有可用工具会造成不必要的暴露。

更好的做法是：只暴露代理目的所需的那部分工具。

比如，一个知识助手可能需要：

✓ Search documents
✓ Retrieve approved knowledge ✕ Send email
✕ Modify records
✕ Execute administrative actions

一个运营代理可能合理地需要更多能力——但那些权限应该是刻意配置的。

安全护栏应该放在 Prompt 之外

我们经常把 AI 安全护栏理解为指令，比如：

"不要访问机密信息。"

"不要执行未授权的操作。"

这些指令有用。

但指令不等于授权控制。

更强的架构是这样的：

User Request ↓
AI Agent ↓
Policy / Authorization Layer ↓
Approved Tool ↓
Approved Data / Action

代理可以请求操作。

周围系统决定这个操作是否被允许。

随着代理获得更多自主性，这个分离变得越来越重要。

人工监督应该是风险驱动的

人在回路不代表要对每个 AI 操作都审批。

那样会失去自动化的很大一部分价值。

更合理的做法是：监督力度与影响程度成比例。

Low Risk
Automatic Medium Risk
Automatic + Monitoring High Risk
Explicit Approval Critical / Irreversible
Human Decision

举个例子：

搜索已批准的文档可能不需要干预。

发送外部通信可能需要额外验证。

修改敏感信息或执行不可逆操作可能需要明确审批。

目标不是最大化人工参与。

而是适当的人工参与。

别忘了代理的记忆

代理也可能维护记忆或状态。

这就引入了另一个数据层。

值得思考的问题包括：

• 什么信息可以被存储？
• 保留多长时间？
• 不同用户之间的记忆是否隔离？
• 敏感信息能进入记忆吗？
• 恶意内容能影响后续行为吗？

记忆不应该仅仅因为能提升代理体验，就变成一个不受控的数据存储。

可观测性本身就是护栏的一部分

预防性控制不可能拦截所有问题。

所以我们也需要了解代理实际做了什么。

有用的遥测数据可能包括：

• 访问了哪些数据
• 调用了哪些工具
• 尝试了哪些操作
• 被拒绝的操作
• 权限变更
• 异常执行模式
• 人工审批记录
• 最终结果

这改变了可观测性的问题域：从

"AI 可用吗？"

变成：

"AI 的行为是否在我们设定的边界内？"

一个简单的代理护栏模型

综合以上想法，我是这样思考代理安全的——分多个层次：

 RESPONSIBLE AI / GOVERNANCE │ HUMAN OVERSIGHT │ POLICY & AUTHORIZATION │ ┌───────────────┼───────────────┐ │ │ │ IDENTITY TOOL ACCESS DATA ACCESS │ │ │ └───────────────┼───────────────┘ │ AI AGENT │ MODEL / REASONING │ MONITORING & AUDIT

没有单一层次能提供足够的保护。

安全来自多层组合。

负责任的 AI 也是架构 discipline

负责任 AI 的讨论通常正确地聚焦在：

• 公平性
• 透明度
• 可解释性
• 隐私
• 问责

随着 AI 变得更加 agentic（代理化），我认为另一个维度变得同等重要：

控制。

我们能否清晰定义：

AI 能访问什么？

能做什么？

在谁的授权下？

什么时候需要人工介入？

以及事后能否还原发生了什么？

这些都是负责任 AI 的问题。

但同时也是架构、安全和工程的问题。

最后

代理变得越来越强大，我不认为答案是阻止它们访问企业系统。

那样会限制它们的大部分价值。

真正的挑战是有意识地设计访问权限。

给代理足够的能力来完成它的使命——但不要给到不受限制的权限，从而产生不必要的风险。

换句话说：

目标不应该是最大化的 AI 访问权，而应该是最小必要的访问权，加上最大化的问责。

这可能会成为组织从“回答问题的 AI”走向“采取行动的 AI”过程中，最重要的护栏之一。