支撑企业多域 Agent 群落：ooderAgent 部署与治理架构解读

一、背景：从"几个 Agent"到"多域 Agent 群落"

当企业开始规模化使用 Agent，最先出现的不是"模型不够聪明"，而是"Agent 太多、管不住"。典型形态是：财务上线了几个 Agent，人事紧接着要上，BI 团队在做经营问答，CRM 团队又提了商机预警——每个团队各自起一个 Agent 进程、各存一份流程定义、各写一套文件处理逻辑。三个月后，没人能说清"公司现在有多少个 Agent、在跑什么、产出了什么、谁负责"。

下表抽象了四类典型业务域的 Agent 负载特征，它们看似无关，实则共享同一套基础设施诉求：

把这些放在一张图上看，企业真正需要管理的对象不是一个"Agent 应用"，而是一个 Agent 群落（Agent Colony）：

• 群落里有多种角色的 Agent（执行型、审批型、检索型、巡检型）；
• 它们共享定义治理、产物存储、知识索引、事件通道与控制面；
• 它们彼此隔离（不同域、不同部门、不同数据边界），但受同一套规则约束；
• 它们可被统一观测与调度（谁在线、能做什么、正在做什么、产出了什么）。

ooderAgent 的部署架构，本质是为"Agent 群落"准备的运行与治理底座。本文围绕这条主线展开：先讲群落模型，再讲群落的八大管理能力，最后落到承载它的部署拓扑与事件机制。

业务域 · Agent 群落成员财务 Agent 组单据处理 · 对账 · 税务测算文件密集 · 强留痕人事 Agent 组入职 · 假勤 · 审批流转流程驱动 · 人工密集BI Agent 组日报 · 指标问答 · 归因检索密集 · 知识依赖CRM Agent 组跟进 · 商机预警 · 提醒事件驱动 · 周期触发共享底座（Shared Substrate）FOS 定义治理单一权威源 · 版本AMS / AST 产物元数据 + 内容KIS 知识索引检索增强IDS 身份组织角色 · 归属 · 权限BUS / MESH 事件跨网段 + 同网段共享语义：定义集中治理 · 产物集中留痕 · 知识集中检索 · 事件统一通道 · 身份统一判定ARN 控制面（Cluster Control Plane）节点台账 · 能力路由 · 健康与心跳 · 技能/配置下发 · 可观测STU 工作台：设计定义、使用 Agent、观测进度（边缘/办公网侧）

图 1 · 多域 Agent 群落全景：四域 Agent 共享一套底座，统一由控制面治理

二、概念模型：什么是 Agent，什么是 Agent 群落

2.1 一个 Agent 的四要素

"定义"决定 Agent 怎么做，"产物"是它做的结果，"知识"是它判断的依据，"身份"决定它是谁、能干什么、属于谁。四者缺一，Agent 就退化成"一个会调模型的脚本"，无法纳入企业级治理。

图 2 · Agent 四要素与群落共享面：身份 / 定义 / 产物 / 知识 → 共享底座 → 控制面

三、群落管理：八大能力（核心章节）

3.1 注册与台账：先知道"有哪些 Agent"

每个 Agent 节点向控制面注册并周期心跳，上报：节点标识、角色、能力清单、域与组织、地址与服务端口。控制面据此维护一张活的资产台账，按超时剔除僵尸节点，对外提供在线视图。价值：从"问三个人才知道有几个 Agent 在跑"变成"一张表、一个接口、实时"。

3.2 能力与路由：让"谁能干"驱动"谁去干"

节点注册时声明 capabilities（如"文档解析""规则计算""检索增强""表单流程"）。任务到来时按能力清单路由，而不是把目标地址写死在调用方——这让新增同类 Agent 即可分担负载，也让技能包按能力定向下发（登记 → 升级 → 回滚）。

任务 / 请求来自人或系统带能力需求ARN 能力路由匹配 capabilities在线 + 健康 + 域匹配解析型 Agent文档解析 / 抽取计算型 Agent规则计算 / 测算检索型 Agent知识检索 / 归因技能下发登记 · 升级 · 回滚按能力定向能力台账回写更新版本留痕闭环：任务按能力路由 → 命中选择 → 技能按需下发 → 能力台账回写，支撑下一轮更准的路由收益：新增同类 Agent 即可分担负载；技能升级/回滚对调用方透明

图 4 · 能力驱动路由与技能下发闭环

3.3 域与租户隔离：多部门共用一套底座

domain-id 与 org-id 决定"谁和谁是一个群落"：只有域、组织匹配的节点才互认为成员。配合三件事形成隔离闭环：数据隔离（按域分库）、配置隔离（配置空间决定加载的表单与服务视图）、事件隔离（topic 前缀划分，节点定向前缀与人员前缀分离）。

图 5 · 域与租户隔离：同一底座上多域并行，靠数据 / 配置 / 事件三重隔离

3.4 定义治理：单一权威源 + 版本与灰度

Agent 的行为来自流程定义。定义只在编排服务有一份权威副本：设计器写入、执行方消费，其他节点不落地副本。由此自然长出版本、灰度与回滚：改定义 → 发新版本 → 小流量灰度 → 全量 → 异常则回滚上一版本。

图 6 · 定义治理与生命周期：单一权威源支撑版本、灰度与回滚

3.5 产物与知识治理：留痕、去重、可复现

• 产物分层：元数据服务管"在哪里"，存储服务管"内容是什么"；内容按哈希去重、无会话，便于水平扩展与长期留痕。
• 知识集中：领域规则、制度、历史案例进入知识索引，Agent 运行时检索注入——既避免每个 Agent 各存一份知识，也让"为什么得出这个结论"可被追溯。

3.6 事件与可观测：让过程看得见

长流程（多步、含人工确认）需要实时进度。用双通道解决：Agent Mesh（同网段广播 + Gossip，零配置低延迟）与 Cluster Event Bus（跨网段 MQTT，topic 命名空间投递）。两条通道双发、共用去重键，任一通道到达即消费；Broker 不可达自动降级。事件最终汇聚到工作台，转为 SSE 推送（进度、步骤、确认卡片）。

3.7 生命周期与健康：上线、暂停、下线都要可控

3.8 安全与合规：最小权限与审计

身份组织服务提供"谁是谁、属于哪个组织、担任什么角色"；事件按前缀隔离投递；产物留痕可追溯；定义变更有版本。四者叠加，才谈得上"Agent 的所作所为可被审计"。

能力归属：控制面（ARN）承担 ①②③④，编排面（FOS）承担 ⑤，数据面（AMS/AST/KIS）承担 ⑥，治理面（IDS）与协同面（BUS/MESH）分担 ⑦⑧。STU 工作台贯穿全程：设计定义（⑤）、使用 Agent（②⑥）、观测进度（⑧）、查看台账（①）。

图 3 · 群落管理八大能力及其归属面

四、部署底座：四层拓扑与事件总线

4.1 逻辑拓扑（地址已泛化）

拓扑由三层构成（完整图形见下方图 7，启动依赖与时序见图 8）：

• 入口层：公网 <gateway> 的反向代理按 server_name 分发到内网服务；上传类接口单独放宽请求体上限。
• 服务层：内网服务网格 <intranet> 承载 ARN / FOS / AMS / AST / IDS / KIS / BUS；STU 位于边缘或办公网侧。
• 数据与消息层：数据层 <mysql-host>:<mysql-port> 按域分库，事件总线 Broker <broker-host>:<broker-port> 独立部署。

图 7 · 部署底座四层拓扑：入口层 / 服务层 / 数据与消息层

4.2 启动顺序（有依赖）

图 8 · 启动顺序与依赖时序：控制面先起并等待就绪，其余服务按序拉起

1) ARN  运行时与控制面     ← 控制面先起，等待注册表/子系统就绪（约 25s）2) FOS  流程编排3) IDS  身份组织4) AMS  产物元数据5) AST  产物存储6) KIS  知识索引

停服按端口定位进程 → 优雅停止 → 超时强杀；启动后台拉起并落日志。生产建议改为系统服务/容器编排托管，用依赖声明固化顺序与健康检查。

4.3 环境变量（占位版）

# 数据源（按域分库）export <PREFIX>_DB_URL='jdbc:mysql://<mysql-host>:<mysql-port>/<cluster-db>?…'export ORG_DB_URL='…/<org-db>'export VFS_DB_URL='…/<artifact-db>'export BPM_DB_URL='…/<flow-db>'# 服务互联（内网直连 + 对外地址声明）export CLUSTER_BOOTSTRAP_URL='http://<intranet>:<arn-port>'export ORG_SERVER_URL='http://<intranet>:<ids-port>'export BPM_ORG_ACCESS='remote'export <SERVICE>_ADVERTISED_HOST='<intranet>'export CLUSTER_AGENT_ENABLED='true'# 外网域名下发（与反向代理 server_name 一一对应）export OODER_SYS_URL_DERIVED='true'export EXTERNAL_<SERVICE>_URL='https://<service>.<domain>'# 事件总线export OODER_EVENT_MQTT_ENABLED='true'export OODER_EVENT_MQTT_BROKER_URL='tcp://<broker-host>:<broker-port>'export OODER_EVENT_MQTT_USERNAME='<user>'export OODER_EVENT_MQTT_PASSWORD='<pass>'

4.4 事件总线节点：跨网段的那根"神经"

问题：Agent 在机房执行多步长流程（解析 → 映射 → 校验 → 审计 → 人工确认），办公网的使用者要实时看到进度。同网段广播过不去，就需要跨网段事件通道。

图 9 · 事件与可观测链路：双通道发布、去重消费、降级与 SSE 呈现

五、多域串讲：一个"月末经营日"里的 Agent 群落

把四类 Agent 放进同一天、同一套底座，看它们如何并存又互不干扰：

图 10 · 月末经营日多域 Agent 并发时序（示意）

它们共享什么：同一套定义治理（编排服务）、同一套产物与知识（元数据/存储/索引）、同一条事件总线、同一个控制面台账、同一套身份与权限。

它们隔离什么：各自的域与组织、各自的数据边界（分库与产物路径）、各自的定义版本（灰度互不干扰）、各自的事件命名空间。

控制面在这一天做了什么：① 记录四域 Agent 节点在线与心跳；② 按能力把"文档解析/规则计算/检索增强/事件推送"路由到对应节点；③ 把财务 Agent 的新定义版本灰度到部分实例，观察无异常后全量；④ 汇总当天事件吞吐、失败重投与降级次数，供运维复盘。这就是"群落管理"的日常：不是管一个 Agent 跑没跑通，而是管一片 Agent 是否可控、可观测、可演进。

六、结语

企业落地 Agent 的分水岭，不在于"能不能做出一个惊艳的 Demo"，而在于当财务、人事、BI、CRM 的 Agent 同时上线时，是否还管得住。

ooderAgent 的答案是把 Agent 当作群落来治理：用身份与能力建立台账，用域与组织划清边界，用单一定义权威源保证"设计即运行"，用产物与知识保证可追溯、可复现，用双通道事件保证跨网段可观测，用控制面把注册、健康、下发、灰度串成闭环。

这套底座不生产智能，但它决定了智能能否被规模化、被信任、被长期运营。

附录 A：命名对照

ooderAgent 多域 Agent 群落架构解读 · v3.0 · 2026-09-04 · 地址/端口/域名已泛化占位 · 9 张内联 SVG