ServiceNow AI Agent 多 Agent 协作架构和通信机制设计（第二部分）

---

一、整体架构：多智能体协作的四层模型

ServiceNow AI Agent 架构可分为四个核心层次，借助治理拓扑中的技术域思想，构建可扩展、高安全、强治理的智能体协同系统。

1. 感知层（Perception Layer）

功能定位：采集环境信号、系统事件、指标、用户输入等。实现方式：基于 Now Platform 的事件监听器（如 Flow Designer Event Registry）日志流接入（Log Analytics with Agent Client Collector）Telemetry Agent：收集运行态上下文典型 Agent：MetricsAgent：监听性能指标变动（例如 CPU > 80%）TicketAgent：监控工单动态（新工单、升级、分派等）

2. 分析层（Analysis Layer）

功能定位：进行语义分析、上下文建模、意图识别、优先级判断。实现方式：基于 LLM（例如 ServiceNow Now Assist OpenAI 接口）自定义推理引擎（Prompt Router Knowledge Graph）内置 Workflow AI 模块典型 Agent：PriorityAgent：根据事件优先级和业务影响评估是否需要升级CostAnalysisAgent：分析资源/服务成本结构并生成 FinOps 报告

3. 执行层（Action Layer）

功能定位：具备任务执行能力，能调用系统接口、修改配置、派发工单等。实现方式：Scripted REST APIsFlow Designer Action SetsAgent-Orchestration Engine典型 Agent：AutoScalerAgent：动态调整资源规模WorkflowExecutorAgent：跨多个系统执行工作流

4. 协同层（Coordination Layer）

功能定位：统一调度 Agent、解决冲突、合并决策，支持多智能体之间的通信与任务共享。实现方式：使用 ServiceNow Event Bus Redis Pub/Sub 进行低耦合通信引入 Multi-Agent Orchestration Framework（可自定义 Finite State Machine）引入 Governance Topology 模型为 agent 分层赋权典型 Agent：AgentManager：负责 agent 之间协调、调度及管控GovernanceAgent：对 agent 行为进行策略限制与审计跟踪

---

二、通信机制设计：多 Agent 协作的三种通信范式

1. 事件驱动（Event-Driven Communication）

使用场景：低耦合 agent 通知（例如 MetricsAgent 通知 AlertAgent）实现方式：使用 Now Platform Event Registry或 Redis/Kafka 做中间件，格式采用 JSON Schema代码语言：javascript

复制

{"source_agent": "MetricsAgent","event_type": "CPU_THRESHOLD_EXCEEDED","payload": {"host": "vm-01","cpu": 92,"threshold": 80}}

2. 意图调度（Intent-Based Routing）

使用场景：高层 agent 将任务分派给下游 agent 执行实现方式：类似于 ReAct/Plan-and-Execute 框架利用 LLM 识别目标意图 → TaskList → AgentDispatch代码语言：javascript

复制

用户意图：优化当前运行的云资源成本→ 解析为：生成账单 → 识别高成本资源 → 提交优化建议 → 自动执行资源缩减→ 调用顺序：CostAnalysisAgent → FinOpsAdvisorAgent → OptimizationAgent

3. 黑板机制（Blackboard Communication）

使用场景：多个 agent 基于同一共享上下文进行协作实现方式：构建 Blackboard 数据结构（如 Redis Set）agent 写入事实、读取条件、生成行动建议代码语言：javascript

复制

blackboard.set("current_cpu", 88)if blackboard.get("current_cpu") > 80:alert_agent.generate("高负载警告")

---

三、安全与治理机制设计

1. Agent 权限边界设计

参考 Governance Topology 的 Platform Management 子域，采用以下措施：

每个 Agent 都是一个 CMDB Configuration Item（可追踪、审计）定义 Agent 的 Role-Based Access Control（RBAC）敏感 API 操作需走 Service Catalog 审批流程

2. 风险隔离与策略治理

引入以下治理组件：

PolicyAgent：根据 CMDB Service Mapping 实施访问策略DataGuardAgent：保障数据读取符合数据主权合规（GDPR/国密）OpsAuditAgent：所有决策链条保留审计记录至 Audit Trail

3. 多 Agent 生命周期管理

所有 Agent 均注册于 Agent Registry（包含运行状态、权限、任务统计等）支持热插拔、灰度发布、A/B Test利用 Application Portfolio Management（APM）视角管理智能体，如评估其 ROI、运行状态、废弃路径

---

四、工程实践案例：多 Agent 协作解决 FinOps 问题

场景：企业云支出持续上升，CTO 要求 DevOps 团队用自动化方式对云资源进行优化

Agent 角色分配：

Agent 名称	职责说明
MetricsAgent	实时采集各类资源利用率指标
CostAnalysisAgent	关联资源与成本模型，形成账单视图
FinOpsAdvisorAgent	识别出浪费资源、未关资源、低利用率资源等
OptimizationAgent	提交优化建议至审批流
ApprovalAgent	根据策略审批是否允许执行优化
ExecutionAgent	执行资源停用、缩容等操作

执行链路（事件流）：

MetricsAgent 发现多个测试环境运行 30 天未使用CostAnalysisAgent 关联账单，发现其占成本 8%FinOpsAdvisorAgent 给出“可删除建议”ApprovalAgent 提交建议给项目负责人审批ExecutionAgent 在获批后自动执行缩容本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。原始发表：2026-05-24，如有侵权请联系[email protected] 删除