企业选 AI Agent，别先数连接器：权限、审计与人工接管才是生产门槛

聊天机器人答错一句话，用户可以忽略；Agent 如果以你的身份发错邮件、批错退款或删除云资源，问题就不再是“AI 幻觉”，而是一次真实的业务事故。

这正是企业级 AI Agent 与普通聊天机器人的根本区别。

前者主要“说”，后者开始“做”：读取客户资料、查询订单、发送邮件、提交报销、修改数据库，甚至操作生产系统。当 AI 能够代表员工执行动作，企业争夺的就不再只是一个聊天窗口，而是一个连接身份、数据、流程和业务系统的新入口。

问题也随之改变：过去我们关心模型回答得准不准，现在必须进一步追问——它凭什么执行？执行了什么？出错时谁能叫停？最终责任算谁的？

企业选择 Agent，真正决定其能否从演示工具进入生产环境的，不是接入了多少工具，而是能否做到：权限最小化、过程可追溯、异常可中断、责任可界定。

Agent 的竞争，正在从模型能力转向企业入口

近期，云平台、办公软件、CRM、客服系统和自动化平台都在将 Agent 嵌入自己的产品。

表面看，这是“大家都在做 AI 助手”；更深一层看，它们争夺的是三项控制权：

1. 谁可以调用企业工具

2. Agent 以谁的身份执行

3. 执行结果最终写回哪里

办公平台天然掌握邮件、文档和会议入口；CRM 掌握客户、商机和服务流程；云平台连接数据库、计算资源与生产环境；自动化平台则拥有跨系统执行能力。

因此，Agent 的竞争正在从“谁的模型更聪明”，转向“谁能安全地接管企业工作流”。

这种转变已经出现在企业采用数据中。

McKinsey 在《The State of AI in 2025》中调查了来自105个国家和地区的1,993名受访者。报告显示，23%的受访者表示其所在组织已在至少一个业务环节扩展使用 Agentic AI，另有39%仍处于试验阶段。

另一份由 LangChain 发布的《State of AI Agents 2024》面向1,300余名从业者展开调查。报告中，51%的受访者表示已在生产环境使用 Agent，78%表示正在积极规划相关应用。不过，这是一份面向开发者和 AI 从业者的生态调查，样本本身对 Agent 的关注度较高，不能直接代表所有企业。

两组数据口径不同，却共同说明一件事：大量 Agent 正在试点，但“做出 Demo”和“稳定进入生产”之间仍有明显距离。

LangChain 的调查中，模型表现质量与安全性是受访者最集中的担忧之一；而从 OWASP 的大模型应用风险分类看，提示词注入、敏感信息泄露、过度授权和资源消耗失控，也已经成为 Agent 系统必须正视的风险。

“能调用多少工具”，为什么正在变成虚荣指标

“支持100个连接器”“一句话操作所有系统”，非常适合产品演示。

但工具数量只说明 Agent 理论上能够触达多少系统，并不能回答它是否可以安全、稳定地完成任务。

接入一个 API，至少还要处理：

• 参数是否识别正确
• 调用失败后是否会重复执行
• 接口超时后如何判断任务是否已经成功
• Agent 是否有权访问相关数据
• 返回结果中是否包含敏感信息
• 写入错误后能否撤销
• 多个工具连续调用时，权限是否被放大

例如，一个 Agent 同时接入邮箱、企业网盘和 CRM，看起来能力很强。如果它默认继承员工的全部权限，那么一封包含恶意指令的外部邮件，就可能诱导它检索内部文件、读取客户信息，再通过邮件或其他工具发送出去。

这不是纯理论风险。

2025年公开披露的 EchoLeak 漏洞展示了间接提示词注入的现实攻击链：攻击者可以将恶意指令藏在邮件内容中，诱导 Microsoft 365 Copilot 处理并尝试泄露其可访问的数据。微软随后修复了相关问题。这个案例并不等同于一次公开确认的企业资金损失，但它清楚说明：Agent 读取的内容本身，也可能成为攻击指令。

反过来看，如果一个 Agent 只连接三个工具，但被严格限定为：

• 只能读取分配给当前员工的客户
• 只能查看订单状态与物流字段
• 只能生成回复草稿
• 退款必须经过人工确认
• 授权30分钟后自动失效

那么它反而更接近生产可用。

演示型 Agent 与生产型 Agent

连接器决定 Agent“能不能做”，治理能力决定企业“敢不敢让它做”。

企业首先应该检查权限，而不是连接器列表

评估 Agent 权限时，可以拆成四个问题。

1. 谁在发起任务

企业需要确认任务来自真实员工、外部客户、定时程序，还是另一个 Agent。

如果外部用户可以间接触发内部工具，系统就必须在入口处进行身份验证、输入过滤和任务范围限制，不能因为请求经过了 AI，就默认它值得信任。

2. Agent 以谁的身份执行

常见方式包括：

• 直接继承员工个人账号
• 多个 Agent 共用服务账号
• 为每个 Agent 创建独立机器身份
• 按任务签发临时令牌

其中，共享账号与长期令牌尤其值得警惕。它们不仅权限容易过大，还会让审计系统难以判断：某个动作究竟由哪位员工、哪个 Agent、哪次任务触发。

更稳妥的方式是：让 Agent 拥有可识别的独立身份，再根据任务获得短期、最小范围的权限。

员工离职、转岗或权限变化后，Agent 继承的访问能力也应同步失效，而不是继续使用保存在连接器中的旧令牌。

3. 能访问哪些数据

“允许访问 CRM”仍然太宽泛。真正可执行的权限应继续细分：

• 允许访问哪些客户
• 可以读取哪些字段
• 是否能看到手机号、地址等敏感信息
• 能否跨部门查询
• 是否允许导出
• 测试环境与生产环境是否隔离

权限控制需要尽可能下沉到记录级、字段级和资源级，而不是只设置一个“允许使用 CRM”的总开关。

4. 哪些动作需要额外批准

查询物流与执行退款，显然不是同一风险等级。

企业可以根据操作影响设置审批规则：

• 只读查询：允许自动执行
• 生成草稿：执行后由员工确认
• 修改客户资料：执行前审批
• 退款、转账、删除资源：临时授权、多级审批
• 修改生产配置：限定资源、时间窗口，并保留回滚方案

下面是一段简化的权限配置：

{
"agent": "customer-service-agent",
"allowed_tools": [
"order.query",
"logistics.query",
"refund.create_draft"
],
"denied_tools": [
"refund.execute",
"customer.delete"
],
"constraints": {
"customer_scope": "assigned_customers_only",
"max_refund_amount": 500,
"token_ttl_minutes": 30
},
"approval_required": [
"refund.create_draft"
],
"audit": {
"record_tool_arguments": true,
"record_approver": true,
"retention_days": 180
}
}

需要强调的是，这段配置只是帮助理解治理思路。

模型生成的是意图，不是安全边界。

执行记录和人工接管，决定出错后能否被控制

很多 Agent 产品所谓的“历史记录”，实际上只保存了用户问题和最终回答。

这对企业远远不够。

一条完整的执行链，至少应包含：

• 任务来源与发起人
• Agent 身份及权限范围
• 使用的模型与版本
• 输入上下文及引用数据
• Agent 制定的执行计划
• 调用的工具与参数
• 权限判断结果
• 审批人与审批意见
• 工具返回结果
• 失败、超时与重试过程
• 最终写入或外发动作

企业 Agent 执行链路图

用户
↓
身份验证
↓
权限策略
↓
Agent 规划
↓
工具调用
↓
人工审批
↓
实际执行
↓
审计日志

这些记录不仅用于排查“模型为什么做错”，也服务于安全审计、合规检查和责任认定。

尤其要防止一种常见故障：接口已经成功处理请求，但返回时发生超时，Agent 误以为失败，于是再次调用。结果可能是重复提交订单、重复发送邮件或重复创建退款。

解决这类问题不能只靠模型判断，而要依赖业务系统的幂等键、状态查询、重试上限和去重机制。

人工接管不只是一个“停止”按钮

成熟的人机协作应该覆盖三个阶段：

1. 执行前：审批

Agent 给出计划、目标对象和工具参数，由员工确认后执行。

2. 执行中：暂停与修改

当调用对象、金额或资源范围发生变化时，系统能够暂停任务，允许人工修改参数，而不是只能等待整条链路结束。

3. 执行后：回滚与补救

对可逆操作提供撤销；对不可逆操作生成补救任务、通知责任人并冻结后续动作。

例如，客服 Agent 自动起草“您的订单正在配送中”，风险较低；但如果它准备把退款金额从50元修改为500元，就必须重新触发审批。

主流企业 Agent 平台治理能力对照

以下对照依据各平台公开文档中的现有能力整理。需要注意：同一平台在不同版本、云服务区域和授权套餐下可能存在差异，“支持”也不代表默认开启，采购时仍应以实际合同、后台配置和测试结果为准。

这张表最值得关注的，不是哪个格子里“支持”最多，而是这些能力能否组成一条完整的控制链。

采购演示时，应要求厂商展示真实后台，而不是只看聊天界面。建议至少截取和验证以下页面：

• 权限角色与资源范围配置
• Agent 或服务身份设置
• 工具调用参数与返回结果
• 审批请求及审批人记录
• 暂停、接管、撤销和停用操作

三类任务，应该采用三种治理方式

低风险：会议纪要 Agent

允许它：

• 读取指定会议记录
• 提取待办事项
• 生成纪要草稿

但不允许它直接群发。员工确认后，才将内容写入知识库。

这类任务适合成为企业试点入口，因为数据范围明确、结果可检查、写入动作也容易撤销。

中风险：客服 Agent

允许它：

• 查询当前客户的订单与物流
• 起草回复
• 创建退款草稿

但退款、补偿和客户资料修改必须人工审批，同时完整记录查询字段、回复内容、审批人与执行结果。

关键不是完全取消人工，而是让人工从“查资料、复制粘贴”转向“确认高风险动作”。

高风险：财务或运维 Agent

涉及转账、报销、删除云资源和修改生产配置时，应强制使用临时权限，并设置：

• 金额或资源上限
• 可操作对象白名单
• 执行时间窗口
• 多级审批
• 即时中断
• 变更前快照
• 自动回滚或补救流程

这类任务不能只依赖模型自行判断，更不能把长期管理员令牌直接交给 Agent。

一张企业 Agent 采购与试用清单

无论你是普通使用者、技术团队还是管理者，都可以用下面的问题进行验收：

• [ ] 是否默认采用最小权限，而不是继承全部员工权限
• [ ] 是否有独立、可撤销的 Agent 身份
• [ ] 是否支持记录级、字段级和资源级限制
• [ ] 临时权限能否在任务结束后自动回收
• [ ] 是否记录完整工具参数、返回结果和写入动作
• [ ] 高风险操作能否强制人工审批
• [ ] 执行过程中能否暂停、修改和接管
• [ ] 是否支持幂等键、重试上限和重复请求检测
• [ ] 错误写入后能否回滚或生成补救流程
• [ ] 是否能设置费用预警、用量上限或调用限流
• [ ] 数据保留时间、存储位置和删除机制是否明确
• [ ] 更换模型后，权限策略是否仍由外部系统强制执行
• [ ] 测试环境与生产环境是否隔离
• [ ] 是否有一键停用 Agent、撤销令牌和阻断工具的机制

如果供应商无法现场演示这些能力，却反复强调连接器数量和模型参数，企业就应该更加谨慎。

Agent 可以用，但不要一次性交出全部权限

最稳妥的上线顺序不是“接入所有系统，再观察效果”，而是：

1. 先选择低风险、可回滚的任务

2. 第一阶段只开放只读工具

3. 保留完整调用日志

4. 用真实异常测试重试与中断

5. 再增加有限写入权限

6. 最后引入分级审批和生产系统操作

在把 Agent 接入邮箱、数据库或业务系统之前，也可以先从纯 API 调用和低风险任务开始，测试不同模型在工具选择、结构化输出、异常处理和成本控制方面的表现。

读者可前往 api.884819.xyz 查看可用的 API 接入方式，并根据网站实际支持的模型与功能搭建最小测试环境。平台注册只需用户名和密码，不需要邮箱验证；没有月租和订阅，采用按量付费，国产模型如 Deepseek、千问等可免费使用，注册后也可直接使用内置 AI 对话功能。

需要说明的是，API 与模型调用能力不等同于企业级权限、审计或合规能力，相关能力应以网站实际页面和服务说明为准。

试运行挑战：让同一个 Agent 完成“查询订单—生成回复草稿—等待人工确认”三步任务，观察它是否会越权执行、是否保留调用记录，以及失败后能否安全重试。

真正有机会占据企业入口的平台，不一定拥有最多工具，而是最能让企业放心地把工具交给它。

但当权限边界划清之后，下一个问题会更加棘手：Agent 读取网页、邮件和文档时，如何识别藏在内容里的提示词注入，并避免被诱导调用高风险工具？

下一篇，我们将拆解 Agent 最典型的攻击链，并给出从模型、工具网关到人工审批的分层防护方案。

#AIAgent #企业AI #人工智能 #AI安全 #权限管理 #智能体 #8848AI #AI治理