企业级 OpenClaw 方案：Agent 舰队、三区架构与安全红线

Deep Research 报告 | 2026-04-17 | 面向制造业 CTO、IT/OT 架构师、数字化转型负责人
📚 "AI + 工业"三部曲 · 第三篇
OpenClaw 工业落地指南：单个 Agent 能干什么、不能干什么
ISA-95 系统全景：工厂里 60+ 套系统怎么分层、AI 接入卡在哪
本篇 → 企业级 OpenClaw 方案：一群 Agent 怎么造、怎么部署、怎么管

为什么写这篇

前两篇文章拼出了"AI 进工厂"这幅拼图的两块：

ISA-95 那篇回答了"工厂里有哪些系统、AI 接入卡在哪"——60+ 套系统、五层架构、五大挑战
OpenClaw 那篇回答了"单个 Agent 能干什么、不能干什么"——四个已验证方向、六个风险、分阶段路径

缺的是最关键的一块：当你要在一个真实工厂里部署的不是一个、而是一群 Agent 时——

需要哪些 Agent？
每个怎么造？
部署在哪？
彼此怎么协作？
谁来调度？
谁来干、谁负责安全？

这篇逐一回答。

一、Agent 不是一个，是一支舰队

单个 OpenClaw Agent 能操作浏览器、调 API、填表单。但企业级不是"一个万能 Agent 干所有事"——应该是按 ISA-95 层级和业务域拆分的 Agent 舰队，每个 Agent 有明确的职责边界和最小权限。

Agent 角色	对应 ISA-95 层	职责	权限级别
经营分析 Agent	L4	自然语言查报表、经营看板问答	只读
采购协同 Agent	L4	供应商门户操作、订单录入、PDF 解析	读写（需审批）
排产建议 Agent	L3	读取 MES/APS 数据，生成排产建议	只读 + 建议
质量分析 Agent	L3	QMS/SPC 数据分析，异常趋势预警	只读 + 告警
设备运维 Agent	L2-L1	读取 SCADA/OPC UA 数据，预测性维护	只读（边缘侧）
视觉质检调度 Agent	L2	调度视觉检测任务、汇总结果、升级异常	只读 + 告警
行政助理 Agent	L4	OA 审批催办、会议纪要、文档检索	只读 + 通知

关键原则：不存在一个"超级 Agent"能操作所有系统。 就像工厂里不会让一个人同时当会计、车间主任和电工一样——分工越清晰，出事时影响面越小。

舰队画好了，接下来的问题是：每个成员怎么造出来？

二、每个 Agent 怎么造：从配置到容器

一个 Agent 的四个构成

在 OpenClaw 框架下，每个 Agent = 一个 OpenClaw Runtime 容器实例，带着四样东西启动：

构成要素	作用	举例（采购协同 Agent）
System Prompt	定义角色、边界、行为准则	"你是采购流程助手，所有写操作必须生成预览等人工确认"
Skills	Agent 能调用的能力插件	`browser-automation`、`pdf-parser`、`erp-purchase-api`
MCP 连接	Agent 能访问的数据源	ERP 采购模块 API、供应商门户
权限配置	能读什么、能写什么、禁止碰什么	读写 ERP 采购模块，禁止访问 HR/财务

核心思路：Agent 的能力边界不靠 Prompt 里"告诉它不能做什么"，而靠 Skill 白名单和 MCP 连接的物理限制——没给它的 Skill，它就调不了。

实际部署长什么样

Agent 部署全景

每个 Agent 是一个 Docker 容器，三个区各有自己的服务器/设备：

IT 区服务器（Docker Compose / K8s）
├── openclaw-gateway            # Gateway 中枢
├── openclaw-agent-bizanalysis  # 经营分析 Agent
├── openclaw-agent-purchase     # 采购协同 Agent
├── openclaw-agent-admin        # 行政助理 Agent
├── n8n                         # 工作流引擎
├── redis                       # 消息队列 / 共享状态
└── postgres                    # 审计日志 / Agent 记忆

DMZ 区服务器（独立机器，网络隔离）
├── openclaw-agent-scheduling   # 排产建议 Agent
├── openclaw-agent-quality      # 质量分析 Agent
└── api-gateway                 # MES/QMS 只读 API 代理

OT 边缘设备（工控机）
├── openclaw-agent-maintenance  # 设备运维 Agent（轻量版）
└── openclaw-agent-vision       # 视觉质检调度 Agent（轻量版）

七个 Agent 各怎么造

Agent	核心 Skills	现成 vs 自研	技术关键点	难度
经营分析	`sql-query`、`chart-generator`	现成	只读查询 BI/ERP 汇总表，自然语言转 SQL	★☆☆☆☆
行政助理	`browser-automation`、`notification`	现成	操作 OA 系统，催办超时审批	★★☆☆☆
采购协同	`browser-automation`、`pdf-parser`、`erp-purchase-api`	半自研	浏览器操作供应商门户 + 自研 ERP 采购 API 封装	★★★☆☆
质量分析	`qms-readonly-api`、`spc-analyzer`、`alert-webhook`	自研	自研 QMS 只读接口 + SPC 统计分析逻辑	★★★☆☆
排产建议	`mes-readonly-api`、`aps-query`	自研	自研 MES 只读接口，不同 MES 厂商 API 差异大	★★★★☆
视觉质检调度	`vision-system-api`、`statistics-analyzer`	自研	调度视觉系统任务，汇总检测结果	★★★☆☆
设备运维	`opcua-readonly-skill`、`time-series-analyzer`	自研	最难——自研 OPC UA Skill，安全约束最严	★★★★★

规律：越往 OT 侧走，自研工作量越大。 IT 区的 Agent 基本用 OpenClaw 现成 Skill 就能跑，OT 边缘的 Agent 核心是自研协议桥接插件。

自研 Skill 长什么样

以最关键的"MES 只读 API Skill"为例：

python

class MESReadOnlySkill:
    """封装 MES 只读 API，暴露给 OpenClaw Agent 调用。
    安全约束：只有 GET 方法，没有 POST/PUT/DELETE。"""
    
    def get_work_orders(self, line_id, date_range):
        """查询指定产线的工单列表"""
        return self.mes_client.get("/api/workorders", 
            params={"line": line_id, "from": date_range[0], "to": date_range[1]})
    
    def get_capacity_utilization(self, line_id):
        """查询产线产能利用率（OEE）"""
        return self.mes_client.get(f"/api/lines/{line_id}/oee")
    
    def get_material_readiness(self, order_id):
        """查询工单物料齐套率"""
        return self.mes_client.get(f"/api/orders/{order_id}/materials")

每家 MES 的 API 不一样（用友 U9、金蝶云星空、SAP ME 接口各不相同），所以这个 Skill 必须针对性开发。这是整个方案里最耗人力的部分，但也是最有价值的资产——一旦封装好，Agent 就能像操作员一样"看懂"MES 数据。

Agent 造好了，部署在哪里？

三、三区架构：跟工控安全对齐

企业级方案最核心的架构决策，是把 Agent 舰队按安全等级部署在三个隔离区：

三区部署架构

企业 IT 区（蓝色）：经营分析、采购协同、行政助理 Agent → 通过 Gateway 中枢 → 访问 ERP/CRM/OA/BI/PLM
生产 DMZ 区（黄色）：排产建议、质量分析 Agent → 只读 API → 访问 MES/APS/QMS/WMS
OT 边缘区（绿色）：设备运维、视觉质检调度 Agent → OPC UA/MQTT 只读 → 采集 SCADA/PLC/Historian 数据
两条红色安全边界：IT/OT DMZ 隔离 + OT 单向网闸（物理层面保证数据只出不进）

三个关键设计决策

1. IT 区的 Agent 可以读写业务系统（ERP/OA），但写操作必须经过 Gateway 的审批流——采购 Agent 填完订单后，必须有人点"确认"才生效。

2. DMZ 区的 Agent 只能只读生产系统（MES/QMS），输出是"建议"和"告警"，不直接修改 MES 数据。排产 Agent 给出的方案，最终由计划员确认执行。

3. OT 边缘区的 Agent 部署在边缘设备上，通过 OPC UA/MQTT 只读采集 SCADA/PLC 数据。单向网闸在物理层面保证数据只出不进——即使 Agent 被攻破，也不可能向 PLC 发送指令。

Agent 造好了、部署到三个区了，那不同区的 Agent 之间怎么协作？

四、Agent 间交互：四种协作模式

Agent 舰队不是各干各的孤岛，它们之间需要协作。但协作方式的选择直接影响安全性——同一个安全区内可以直接对话，跨区必须走间接路径。

Agent 间交互模式

模式 1：同区内直接对话

同一安全区内的 Agent 可以直接调用彼此。很多多 Agent 框架（AutoGen、CrewAI）天然支持这种模式。

经营分析 Agent 发现本月营收异常下降 → 直接调用行政助理 Agent → 行政助理 Agent 拉取 CRM 里最近丢失的大客户清单 → 经营分析 Agent 综合两份数据，输出分析报告

两个 Agent 都在 IT 区、都连着 IT 侧系统，直接对话不会破坏安全边界。这种模式响应快、实现简单，适合同区内需要紧密协作的场景。

但有一条硬约束：跨区不能直接对话。 IT 区的采购 Agent 直接调用 OT 边缘的设备运维 Agent，等于在三区隔离的墙上打了个洞——这是绝对不允许的。

模式 2：共享数据存储（跨区首选）

跨区 Agent 通过各自操作的业务系统间接联动，这是最安全的跨区协作方式。

采购 Agent 往 ERP 录入了采购订单 → ERP 里物料到货状态更新 → 排产建议 Agent 从 MES/ERP 读到物料到齐 → 生成排产建议

两个 Agent 并不"认识"彼此，只是各做各的事，业务系统本身就是天然的数据中转站。耦合度最低、最安全，绝大多数跨区场景够用。

模式 3：事件驱动，n8n 做总线

当一个 Agent 的输出需要主动触发另一个 Agent 时，用 n8n 做事件总线：

质量分析 Agent 输出 Cpk 异常告警 → n8n 监听到事件 → n8n 判断规则（连续 3 次异常？）→ 触发排产建议 Agent → Agent 建议减产或换线 → n8n 把建议推给计划员审批

Agent A 只负责输出事件，n8n 负责规则判断和转发，Agent B 被 n8n 触发后独立执行。跨区场景下，n8n 充当了安全边界上的"合法信使"。

模式 4：Gateway 编排

当一个用户请求需要多个 Agent 协同完成时，由 Gateway 拆分、分发、汇总：

用户问："这批产品的质量情况和成本分别是多少？" → Gateway 拆解为两个子任务 → 质量分析 Agent 读 QMS 数据 + 经营分析 Agent 读 ERP 成本数据 → Gateway 汇总两份结果 → 返回综合报告

四种模式怎么选

模式	适用范围	耦合度	实现复杂度	典型场景
同区直接对话	同区	高	低	IT 区内多个 Agent 紧密协作
共享数据存储	跨区	最低	低	Agent 各操作各的系统，数据自然联动
事件驱动（n8n）	跨区	低	中	一个 Agent 的输出需触发另一个 Agent
Gateway 编排	任意	中	高	一个请求需多个 Agent 协同完成

一条原则：同区可直接，跨区必间接。 起步阶段先用共享数据存储，场景复杂了再引入事件驱动和 Gateway 编排。

间接协作需要一个中枢来调度——这就是 Gateway 的角色。

五、Gateway 中枢：不是可选件，是生命线

OpenClaw 原生架构里有 Gateway 层，但企业级方案里它必须承担远超"请求路由"的职责：

Gateway 中枢能力

Gateway 能力	为什么必须有
统一认证	每个 Agent 用独立服务账号，绑定权限矩阵——采购 Agent 不能读 HR 数据
审批流	所有写操作必须经人工或规则引擎确认，超时未审批则自动取消
审计日志	Agent 每一步推理和操作全部记录，可追溯、可回放——出了事能查清楚
限流/熔断	防止 Agent 失控：单 Agent 每分钟 API 调用上限、异常检测自动停机
模型路由	简单任务用小模型（省钱），复杂判断用大模型（保质量）
成本核算	按 Agent / 部门 / 场景统计 token 消耗，让管理层知道"AI 花了多少钱"
版本管理	Agent 和 Skill 的灰度发布、一键回滚——生产环境不冒险

一个请求的完整调度流程

从请求进入 Gateway 到返回结果，经历七步：

Gateway 调度流程

认证鉴权 — 请求来自谁？服务账号是否有效？权限矩阵允许访问目标 Agent 吗？
意图路由 — 交给哪个 Agent？每个 Agent 注册时声明自己能处理的 Skill（如"供应商查询、订单录入"），Gateway 按声明匹配；匹配不到则用轻量 LLM 做意图分类兜底
限流检查 — 目标 Agent 是否过载？超过阈值则排队或直接拒绝
模型选择 — 简单查询用本地小模型（快、省），复杂分析用云端大模型（准、贵）
Agent 执行 — 转发到 Agent Runtime，Agent 开始多步推理。如果遇到写操作，暂停执行、发起审批
审批流（按需触发）— 推送到企业微信/钉钉/OA → 审批通过则放行继续 → 拒绝则终止回滚 → 超时（如 30 分钟）自动取消
审计记录 — 全链路日志：输入、每步推理过程、输出、耗时、token 消耗、操作结果

Gateway 是整个 Agent 舰队的"交通管制中心"。没有它，Agent 就是一群无组织的散兵。

但 Gateway 调度的不只是 OpenClaw Agent——还有另一个引擎。

六、双引擎互补：OpenClaw + n8n

不是所有工作都需要 AI 推理。 企业级方案里有两个引擎并行运行，各管一类任务：

双引擎协作

任务类型	用什么	举例
确定性、高频、规则驱动	n8n 工作流	每天 8 点同步 ERP→BI 数据、固定格式日报、定时巡检提醒
需要判断力、非结构化、低频	OpenClaw Agent	分析异常工单根因、解读 PDF 质检报告、自然语言查询
混合型	n8n 触发 → OpenClaw 处理 → n8n 分发	n8n 监测到 SPC 异常 → OpenClaw 分析根因并撰写报告 → n8n 发送给责任人

典型的"混合流"：

n8n 定时任务（每30分钟）
  │
  ▼
查询 MES 的 SPC 数据
  │
  ├── Cpk > 1.33 → 正常，不处理
  │
  └── Cpk < 1.33 → 触发 OpenClaw Agent
                      │
                      ▼
                    Agent 读取最近 200 条检测记录
                    Agent 分析偏移趋势和可能原因
                    Agent 生成根因分析报告
                      │
                      ▼
                    n8n 将报告推送到企业微信
                    n8n 在 QMS 中创建 CAPA 工单

确定性的"检测-判断-分发"交给 n8n，需要推理能力的"分析-归因-撰写"交给 OpenClaw。各司其职。

架构和工具都选好了，接下来的问题是：谁来干？

七、组织模型：谁来干，谁负责安全

Agent 项目天然是跨域的——一个采购 Agent 要碰 ERP（IT）、操作供应商门户（外部）、将来还要读 MES（OT）。没有一个现成部门能独立扛这件事。

三种组织模式

模式	适合谁	牵头方	优势	风险
IT 牵头 + OT 协同	大部分中型制造企业	CIO / 信息中心	IT 有集成经验，推进快	OT 部门不配合，碰不到车间
独立数字化团队	大型集团	CDO / 数字化转型办	跨部门权力大，能协调	组建成本高，中小企业养不起
外部实施 + 内部运营	中小制造企业	服务商实施，内部 IT 接管	启动快、风险低	依赖外部，知识沉淀慢

落到人头上

┌─────────────────────────────────────────────┐
│  决策层：项目 Sponsor                         │
│  谁：分管副总 / CIO                           │
│  干什么：拍板预算、协调部门墙、定 KPI            │
│  为什么必须是他：没有高层背书，OT 部门不会开门    │
└────────────────────┬────────────────────────┘
                     │
    ┌────────────────┼────────────────┐
    ▼                ▼                ▼
┌────────┐    ┌────────────┐    ┌─────────┐
│ IT 组   │    │ OT/自动化组 │    │ 业务组   │
│        │    │            │    │         │
│·Gateway│    │·OT 安全策略 │    │·场景定义 │
│ 部署运维│    │·OPC UA 接口 │    │·验收标准 │
│·Agent  │    │ 开放与审批   │    │·效果评估 │
│ 开发配置│    │·边缘设备    │    │·流程适配 │
│·MCP/API│    │ 部署与网闸   │    │·培训推广 │
│ 集成    │    │·SCADA 数据  │    │         │
│·模型选型│    │ 脱敏与授权   │    │         │
└────────┘    └────────────┘    └─────────┘
                     │
                     ▼
            ┌────────────────┐
            │ 安全组（独立）   │
            │·三区架构审核    │
            │·Agent 权限矩阵  │
            │·审计日志审查    │
            │·渗透测试       │
            │·等保/合规对齐   │
            └────────────────┘

安全到底谁负责

答案不是"某一个人"，而是分层负责、安全组兜底：

安全域	负责方	具体职责
Agent 权限安全	IT 组	定义每个 Agent 能调哪些 API、能不能写、token 上限
IT/OT 边界安全	OT 组 + 安全组	网闸配置、DMZ 隔离、OPC UA 只读策略
数据安全	安全组	Agent 不能触碰哪些数据（工资、配方、客户隐私），敏感字段脱敏
模型安全	IT 组	Prompt 注入防护、本地模型 vs 云端模型的合规选择
审计与合规	安全组	日志定期审查、等保三级对齐、Agent 行为异常检测
操作安全	业务组 + IT 组	写操作审批流——谁审批、超时怎么办、Agent 失控怎么熔断

一条铁律

安全组有一票否决权。 任何 Agent 上线前，必须经过安全组的架构审核和权限审查。Agent 的任何权限变更（比如从只读升级为读写），都要重新走安全审批。

这不是给项目添堵。Agent 跟传统软件有本质区别——传统软件的行为是确定的，Agent 的行为是概率性的。你不可能穷举测试 Agent 的所有行为路径，所以必须在架构层面用"最小权限 + 审批流 + 审计 + 熔断"四道防线兜底。

到这里，开头提出的六个问题都回答完了。但上面是面向中大型企业的完整方案——如果你是一个 200 人的工厂，IT 部就 3 个人，怎么办？

八、中小企业的务实路径

砍到最小可行架构：

只做 IT 区 — 初期只部署经营分析、采购、日报这几个 Agent，根本不碰 OT，也就不需要三区架构和 OT 安全
一个人兼多角色 — IT 主管同时管 Agent 开发 + 安全策略 + 业务对接
安全靠 Gateway 配置 — 不设独立安全组，但审批流和审计日志必须开
外部服务商补能力 — 初期实施找服务商，但内部至少一人能看懂 Agent 配置和日志

三条底线不能破，无论企业多小：

权限最小化——Agent 能做什么必须显式定义
写操作必审批——不存在"自动执行"的写入
日志必留——每个 Agent 动作都有记录

写在最后

回到开头的六个问题，对照回答：

问题	答案（章节）
需要哪些 Agent？	按 ISA-95 层级拆分的七个专职 Agent（一）
每个怎么造？	一个 OpenClaw 容器 = System Prompt + Skills + MCP + 权限（二）
部署在哪？	IT 区 / DMZ 区 / OT 边缘三区隔离（三）
彼此怎么协作？	同区直接对话，跨区走共享数据 / n8n / Gateway 编排（四）
谁来调度？	Gateway 七步调度 + n8n 确定性流水线（五、六）
谁来干、谁负责安全？	IT 牵头 + OT 协同 + 安全组一票否决（七）

回到三部曲的起点：ISA-95 告诉我们工厂里有什么系统、数据怎么流；OpenClaw 告诉我们单个 Agent 能干什么；这篇告诉我们一群 Agent 在企业里怎么造、怎么部署、怎么协作、怎么管。

从"能干"到"敢让它干"，中间的距离不靠模型能力来填，靠架构、工程和安全纪律来填。

企业级 OpenClaw 方案：Agent 舰队、三区架构与安全红线 ​

为什么写这篇 ​

一、Agent 不是一个，是一支舰队 ​

二、每个 Agent 怎么造：从配置到容器 ​

一个 Agent 的四个构成 ​

实际部署长什么样 ​

七个 Agent 各怎么造 ​

自研 Skill 长什么样 ​

三、三区架构：跟工控安全对齐 ​

三个关键设计决策 ​

四、Agent 间交互：四种协作模式 ​

模式 1：同区内直接对话 ​

模式 2：共享数据存储（跨区首选） ​

模式 3：事件驱动，n8n 做总线 ​

模式 4：Gateway 编排 ​

四种模式怎么选 ​

五、Gateway 中枢：不是可选件，是生命线 ​

一个请求的完整调度流程 ​

六、双引擎互补：OpenClaw + n8n ​

七、组织模型：谁来干，谁负责安全 ​

三种组织模式 ​

落到人头上 ​

安全到底谁负责 ​

一条铁律 ​

八、中小企业的务实路径 ​

写在最后 ​