当我们谈论 AI Agent 时,我们谈论的是同一个东西吗?（企业视角下的 Agent 分类、部署与权限设计）

一、一个叙事,各自表述

AI Agent 是今年最火的叙事。从 OpenClaw 到 Hermes,再到 WorkBuddy、Claude Code、Claude Cowork,新形态几个月就迭代一轮。

但当我在技术社区里跟大家聊 Agent 的时候,发现了一个有意思的现象:每个人嘴里的 "AI Agent",指的都不是同一个东西。

大多数人在讲 Coding Agent——怎么用它写代码、修 bug、提 PR。少部分人在讲办公 Agent——写文档、整理邮件、做周报。几乎没有人聊 Data Agent,更没有人聊 SRE Agent、安全分析 Agent、售后 Agent 这些企业场景里真正会产生价值的形态。

换一个角度说:大家聊的几乎都是个人 Agent,几乎没有人在聊企业能用的 Agent。

这个偏差不是小问题。当一家企业真的要落地 Agent 时,第一个卡住的往往不是模型能力,而是一连串没人回答过的架构问题:

• 这个 Agent 应该部署在哪个网络分区?
• 该给它什么权限?生产数据能不能碰?
• 哪些事 Agent 可以自主做?哪些必须人类审批?哪些只有人类才能做?
• 出了事,审计日志能不能说清楚是谁干的?

要回答这些问题,得先把 Agent 分清楚类。因为不同类型的 Agent,答案完全不同——把 Coding Agent 的部署经验套到 Data Agent 上,会直接出事故。

这篇文章做三件事:先给企业 Agent 一个可操作的分类框架;再逐类回答部署、隔离、权限三个问题;最后回到 OpenClaw、Hermes、WorkBuddy 这类产品——它们到底是什么物种,在企业里有没有位置,如果要安插一个位置,该怎么做。

二、分类框架:看三个面,不看产品名

给 Agent 分类,不要按厂商的产品名分,也不要按"智能程度"分。真正决定部署和安全策略的是三个东西:

• 数据面:它访问什么数据?文档邮件、源代码、业务数据库,还是日志指标?
• 执行面:它有多大的执行权限?只读查询、生成内容,还是任意 shell 命令、生产变更?
• 出网面:它需要什么样的对外通道?调用大模型 API 时,prompt 里携带的是什么敏感度的内容?

按这三个面,企业场景下的 Agent 可以收敛为四个基本类型:

一条贯穿全文的原则先立在这里:

Agent 的部署位置跟着它的数据面走;Agent 的权限设计跟着它的执行面走;Agent 的出网管控跟着它携带的内容走。

三、四类企业 Agent:部署、隔离、权限逐个拆

企业内网通常按安全等级和业务用途划分为六大核心区域:生产环境、DMZ 隔离区、测试环境、预发布、开发环境、办公内网,外加配套的运维/管理区。下面逐类回答:每种 Agent 该放进哪个格子。

3.1 办公 Agent:部署在办公内网,出口收到 DMZ

很多人的第一反应是"AI 应用放 DMZ"或者"新东西先放测试环境"。都不对。

办公 Agent 的数据面是文档、邮件、IM——这些系统本身就活在办公网。把 Agent 放到别的区域,等于要跨区开一堆到办公系统的访问权限,反而扩大攻击面。所以它就该在办公网。

真正要管住的不是它在哪,而是它的出口:

• LLM API 出网必须收口。不能让办公网机器裸调公网模型 API。标准做法是在 DMZ 部署统一的 LLM 网关,所有 Agent 的模型调用都走这个网关——顺便完成审计、脱敏、限流、成本归集四件事。
• 权限跟人走。Agent 拿到的是"这个员工的授权范围",通过 OAuth 委托授权实现,而不是一个共享的服务账号。否则任何员工都能借 Agent 的嘴,读到本来无权读的文档。

3.2 编码 Agent:部署在研发网,模型私有化或走受控通道

有人会问:Claude Code 直接在开发者本机跑、裸调公网 API,不行吗?——很多团队现在就是这么用的,但在有代码安全要求的企业,这过不了安全评审。更严重的是另一种普遍现象:走第三方 API 中转站写代码。裸调公网 API 至少数据只经过模型厂商一方,而中转站意味着全公司的源代码流经一个身份不明、无合同约束、无审计能力的中间人——它能看到每一个 prompt 的完整明文,留不留存、转不转卖,你既不知道也无从追责。这已经不是"过不了评审"的问题,而是主动把代码资产交给了一个不受任何约束的第三方。

原因是编码 Agent 的两个特征:

• 代码就是数据。"源代码不出研发网"是国内很多企业的红线。所以模型调用要么私有化部署(这也是 CodeBuddy 等国产工具在企业市场的核心卖点),要么走 VPC 内网 endpoint 或专线的受控通道。
• 执行面是任意命令。Agent 能跑任意 shell,理想情况应运行在容器/VM 沙箱中,而不是直接继承开发者本机的全部权限——至少要保证它够不到生产凭证。

部署位置:开发环境(研发网)。CI 集成场景(自动 PR review、自动修复)延伸到测试环境,Agent 跑在 CI runner 上,持有的是 CI 的受限凭证,天然受控。

3.3 数据 Agent:数据在生产,但它绝不是生产的一部分

这是最容易掉进陷阱的一类。"Data Agent 查的是生产数据,所以部署在生产环境"——听起来顺理成章,恰恰是错的。

数据 Agent 的执行面是 LLM 生成的查询,而 LLM 生成的查询是不可预测的。一个全表扫描、一个笛卡尔积,就能把交易库拖垮。它的数据面又是全公司最敏感的一档:客户 PII、交易流水、经营数据。

正确的架构分三层:

部署位置:数据平台区(独立于生产 OLTP 的分区)。查询目标按安全性递减有三个选择:

1. 数仓/数据湖(最推荐):数据本来就为分析准备,已经过 ETL、可在入仓时脱敏,且与 OLTP 天然隔离——Agent 写出再烂的 SQL 也拖不垮交易系统。
2. 只读副本:实时性要求高时使用,但必须配独立资源(专供 Agent,不与 BI 报表共享)和查询熔断(超时杀、扫描行数上限)。
3. 语义层/指标层(最安全):Agent 不写 SQL,只能调用预定义的 metrics API。牺牲灵活性换确定性,金融类客户基本只接受这一种。

权限:行级/列级权限必须跟人走。Agent 以提问者本人的数据权限执行查询,而不是一个全域服务账号。否则 Data Agent 就成了权限绕过工具。如果底座是 Elasticsearch,DLS/FLS(文档级/字段级安全)可以直接吃透传的用户身份,权限模型不需要重建。

出网:比前两类更严。因为 prompt 里携带真实业务数据,LLM 网关除了审计限流,还要加外发内容检测和 PII 脱敏。敏感行业的实际选择往往是模型私有化部署在数据平台区内,数据不出域。

一句话记住这一类:它的数据在生产,但它绝不是生产的一部分。

3.4 SRE Agent:部署在运维区,权限拆成"诊断"和"处置"两档

SRE Agent 的数据面不算最敏感(日志、指标、trace),但执行面是所有 Agent 里最危险的:重启服务、扩缩容、回滚、改配置,每个动作都直接作用于生产。而 Agent 的本质是"不可预测的自动执行",这与生产环境"变更必须可控可审批"的原则直接冲突。

部署位置没有悬念:运维/管理区,复用现有的堡垒机通道。真正的设计功夫在权限分层:

诊断层(默认,只读,可自主):查日志、查指标、看拓扑、做根因分析。这一层可以完全放开,因为它读的其实不是生产系统本身,而是独立的可观测性平台。这里有一个很顺的架构红利:如果监控数据集中在独立的 o11y 集群,SRE Agent 90% 的工作根本不需要碰生产——只需要访问监控集群。这天然就是最好的隔离。

处置层(写操作,human-in-the-loop):Agent 可以生成处置方案,但执行必须过审批。两个关键设计:

• 审批卡在 IAM 权限边界上,不是卡在 prompt 里。Agent 的凭证本身没有生产写权限,执行时通过变更工单系统换取一次性授权。Prompt 里写一句"请先询问用户"不是安全机制——prompt 约束是纸做的,权限约束才是真的。
• 处置动作收敛为预定义 runbook 的参数化调用,而不是让 Agent 现场生成任意命令。Agent 选 runbook、填参数,可预测性和任意 shell 完全是两个量级。

3.5 阶段小结

明确不该放 Agent 的地方:生产环境和预发布。生产区通常禁止公网出访,Agent 连模型都调不了;更根本的是,"自主执行"和"变更受控"在原则上就是矛盾的。需要触达生产的 Agent,走的是运维区堡垒机模式,而不是"部署进生产"。

四、当 Agent 需要调用 Agent:跨区协作的设计

分类框架立住之后,马上会遇到下一个问题:真实的工作流是跨类型的。

一个典型场景:业务负责人让办公 Agent 写季度复盘,需要拉华东区的销售数据做对比。任务前半段是文档工作(办公网),后半段是数据查询(数据平台区)。如果办公 Agent 触达不了数据,用户就得自己去 BI 系统导数、手工贴回来——Agent 的价值链在最关键的一环断掉了。

反过来让数据 Agent 学会写文档也不对,那是能力重复建设。正确答案是 Agent 调用 Agent:各守各的区,各管各的权限。这就是 A2A(Agent-to-Agent)协作在企业网络分区约束下的落地形态。四个关键设计点:

1. 办公 Agent 永远拿不到数据库凭证。 它调用的是数据 Agent 暴露的服务接口,跨区流量走两区之间的 API 网关。数据 Agent 对上游是黑盒服务,不是可以透传 SQL 的管道。

2. 身份透传是整个方案的命门。 最容易犯的错:办公 Agent 用自己的服务身份调数据 Agent,所有查询都以一个超级账号执行——行级权限直接失效,普通员工借 Agent 的嘴就能问出无权看的数据。正确做法是 On-Behalf-Of 模式(OAuth token exchange,RFC 8693):用户身份 token 随调用链透传,数据 Agent 以最终用户的数据权限执行查询。审计日志记录完整链路:"张三 via office-agent via data-agent",三层身份都留痕。

3. 交互协议用粗粒度任务,不用细粒度查询。 上游传的是自然语言任务加上下文("华东区 Q2 销售额,按月拆,对比去年同期"),不是 SQL。查询的生成、校验、执行全部封装在数据 Agent 内部,数据平台区的所有安全控制(语义层、熔断、脱敏)对上游自动生效。这也是 MCP tool 该有的抽象层级:query_sales_data(question, dimensions, time_range),而不是 execute_sql(raw_query)。

4. 全链路可观测性不是锦上添花,是审计刚需。 跨区 + 跨 Agent + 权限透传,出了问题必须能回放完整链路:哪个用户、通过哪个会话、发起了什么任务、生成了什么查询、返回了多少行、脱敏规则是否触发。OTel trace context 的跨 Agent 传播,在这个场景里从"成本归集工具"升级为"合规审计基础设施"。

五、OpenClaw、Hermes、WorkBuddy:企业还没准备好位置的物种

现在回到开头那几个名字。前面四类企业 Agent 的共同点是单一数据面——办公 Agent 碰文档、编码 Agent 碰代码、数据 Agent 碰数仓、SRE Agent 碰运维。而 OpenClaw / Hermes / WorkBuddy 这类产品的定义性特征恰恰是没有边界:

• 执行面是整台机器:shell、浏览器、文件系统。本质是给了 Agent 一台电脑,而不是一组 API。
• 触发面是常驻的:cron 定时任务 + IM 消息随时唤醒。它不是"用户打开会话才存在",而是 7×24 自主运行。
• 数据面跟着主人走:主人给它什么凭证,它就有什么能力——聊天记录、邮箱、个人账号,横跨公私。

所以正确的类比不是"一个应用",而是"一个远程办公的私人助理,你把自己的部分账号密码交给了他"。翻译成企业安全的语言:一个持有员工凭证、行为不可预测、常驻在线的非人类身份(Non-Human Identity, NHI)。

这个定位一立住,三个问题的答案就顺了。

5.1 部署:企业视角下,它默认是影子 IT

先说残酷的现实:员工把这类 Agent 部署在个人 VPS 上,再把公司邮箱、企业 IM、内部系统的凭证喂给它——这就是标准的影子 IT,而且比传统影子 IT 更危险,因为它会自主行动。安全团队的第一反应应该是"发现和纳管",而不是假装它不存在。

纳管之后放哪?它不属于六区中的任何一个。合理做法是开一个独立的 Agent 沙箱区,特征是:

• 与所有生产性区域默认不通,访问任何企业系统都要逐条申请、走网关;
• 每用户一个隔离实例,VM 级隔离——它有任意执行能力,容器逃逸的赌注太大;
• 出网走白名单:LLM 网关、明确批准的 SaaS,其余全断。这是底线,因为常驻 Agent + 任意出网 = 完美的数据外渗通道。

错误示范正好是最常见的用法:跑在办公电脑上,继承整台机器的登录态和 VPN 通道。正确的个人实践是把它放在一台独立的、与工作环境物理隔离的节点上,凭证范围逐项手工控制。

5.2 隔离:三层,缺一不可

计算隔离:独立 VM。Agent 被打穿,攻击者拿到的也只是一台空机器,它的持久化记忆和文件与主人的真实设备零共享。

网络隔离:出向白名单之外,有一个极易被忽略的方向——入向。IM 通道意味着任何能给这个账号发消息的人,都在给 Agent 输入 prompt。这是所有 Agent 形态中最大的注入面。所以 IM 入口要做发信人白名单,消息内容按不可信输入处理,不能直接进入高权限执行上下文。

身份隔离:最反直觉的一条——虽然它是"我的" Agent,但它不应该是"我"。

5.3 权限:三个原则

给影子身份,不给主身份。 为 Agent 单独建一套账号、API key、子账户。它以 "lex-agent" 的身份行动,而不是 "lex"。好处:出事时一键吊销、不影响本人;审计日志天然区分人和 Agent 的操作;权限可以给得比本人小得多。

按任务给凭证,不给常备全权凭证。 cron 跑日报只需要某个只读 API,就只给那个 scope。最忌讳图省事给一个全权 token——常驻 + 全权 + 可被 IM 注入,三个条件凑齐就是定时炸弹。

写操作降级确认,确认机制实现在 harness 层。 读和分析放开;花钱、对外发送、删除数据这类不可逆动作,回到 IM 找主人确认。关键是确认逻辑写在代码里(没拿到确认就不调用工具),而不是写在 prompt 里。

六、一个真实案例:Agent 的自我认知,墙还是承诺?

理论讲完,看一个活体样本。我问 WorkBuddy:"如果我要在企业里用你,该部署在哪、给什么权限、怎么隔离?"它给出了一份相当漂亮的回答——正确指出自己是本地桌面进程而非可部署服务,给出了 L0-L5 的权限分层表,画了三层防线图,最后还主动降级:"以我当前形态,合适的定位是开发辅助,不是生产运维 Agent。"

读完第一反应是:这个 Agent 很靠谱。而这恰恰是风险所在。

细看它的每一条"安全机制":

• "涉及危险操作,我会先停下来跟你核对"
• "生产环境硬隔离,不给我直接访问权限"
• "密钥明文我不直接接触"

注意执行主体全是"我"——也就是模型自己。但它跑在主人的 shell 里,主人 sudo 能做的它技术上都能做(它自己也承认了这一点)。那么"我会先确认"和"我够不到"是两个安全等级完全不同的东西:前者是承诺,一次成功的 prompt 注入就能穿透;后者才是墙。

它的三层防线图里写着"WorkBuddy 本身不直接访问生产网络"——但按它自己的描述,它跑在一台连着 VPN 的办公终端上,主人 ssh 能到哪它就能到哪。它描述的不是现状,是它承诺遵守的规矩,却用了"能力隔离"这个词。把自我约束包装成安全架构,这是这类产品自我认知中最危险的含混。

它还有两个系统性盲区:入向攻击面缺席——它谈了"不安装不受信任的 MCP",却没意识到它读的每个文件、每个网页都是进入高权限上下文的不可信输入,这才是它的头号威胁模型;身份问题缺席——它说"我不该拿比你更大的权限",但真正的问题是它根本不该以"你"的身份行动,它做的每件事在审计日志里都记在主人名下。

评价这类产品自我陈述的最终标准只有一条:它说的每一句"我会先确认",在 harness 层有没有对应的强制卡点?有,这段话是架构说明;没有,这段话是性格描写。

七、结语:权限的前提是可观测

把全文收进三句话:

第一,先分类,再落地。 "AI Agent" 不是一个东西,是至少五个物种。数据面决定部署位置,执行面决定权限设计,出网内容决定管控强度。用 Coding Agent 的经验去部署 Data Agent,是事故的开始。

第二,安全边界只认三样东西:网络分区、IAM 权限、harness 卡点。 Prompt 里的约束、Agent 的自我承诺,都不是防线。人类审批要卡在权限边界上——Agent 的凭证本身没有那个权限,而不是 Agent "答应了"不去用。

第三,权限的前提是可观测。 你之所以敢给一个常驻 Agent 授权,不是因为它把安全边界讲得头头是道,而是因为你看得见它的每一次工具调用、每一条查询、每一分成本。当 Agent 成为常驻的数字分身、当 Agent 开始调用 Agent,全链路 trace 就不再是运维的锦上添花,而是整个信任体系的地基。

企业的网络分区体系是为"人 + 应用"设计的。Agent——尤其是 OpenClaw、Hermes 这类没有边界的个人数字分身——正在长出企业还没准备好位置的形态。非人类身份管理(NHI)正在成为安全行业的显学,原因就在这里。位置终究要给它们安插出来;这篇文章,希望是安插时手边的一张图纸。