详情

首页手游攻略 ServiceNow AI Agent 多 Agent 协作架构与通信机制设计 第二部分

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

佚名 2026-07-04 09:26:51


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] 删除
点击查看更多
推荐专题
热门阅读