1. 多Agent系统概述

单一Agent vs 多Agent协作

单一Agent架构（如上一章节所述）适合边界清晰、工具链固定的任务场景。但在大型企业级应用中，单Agent面临能力上限、单点故障、职责混淆三大瓶颈：

• 能力上限：一个Agent可管理的工具数量和上下文窗口有限，当任务涉及跨领域知识（如信贷审批需要同时理解风控规则、征信数据、财务报表），单一Agent容易超出认知负荷
• 单点故障：单一Agent出现异常（如推理偏差、Token超限）时，整个任务链中断，缺少容错和降级路径
• 职责混淆：安全和效率存在天然矛盾——既要求Agent有足够的权限完成任务，又要求其严格受限。单Agent难以在两者间取得平衡

多Agent系统通过角色解耦、并行协作、故障隔离解决上述问题。每个Agent专注于特定领域的任务，通过编排层实现协同，形成"各司其职、统一调度"的工作模式。

多Agent架构模式

当前业界主流的三种多Agent架构模式各有适用场景和测试重点：

银行场景的多Agent应用

银行业务天然适合多Agent架构——业务流程长、参与角色多、合规要求严。典型的多Agent协作场景包括：

• 信贷审批：OCR识别Agent → 征信查询Agent → 风控评估Agent → 审批决策Agent，形成"录入—校验—评估—决策"的完整链路
• 对公尽调：企业信息采集Agent → 财务分析Agent → 法务审核Agent → 报告生成Agent，各Agent调用不同外部系统（工商、税务、法院、舆情）
• 智能客服：意图识别Agent → 业务路由Agent → 领域回答Agent → 满意度评估Agent，实现复杂多意图问题的并行处理和结果聚合

2. 编排测试

Agent角色分配是否正确

编排层（Orchestrator）的核心职责之一是将任务分配给合适的Agent。角色分配测试需验证以下方面：

• 意图识别准确性：编排层能否从用户请求中准确识别需要的Agent类型。例如，用户说"我想申请一笔贷款"，编排层应识别出需要信贷评估Agent而非客服Agent
• 多意图拆分：当用户请求包含多个意图时（如"帮我查一下余额，然后看看有没有合适的理财产品"），编排层是否正确拆分为多子任务并分配给不同Agent
• 角色边界清晰度：当存在两个功能相近的Agent（如零售风控Agent和对公风控Agent）时，编排层是否能根据上下文（客户类型、业务范围）精确选择
• Agent不可用时的降级：目标Agent不可用时，编排层是否将任务分配给降级Agent（如备用路径），还是直接返回失败并给出清晰说明

任务分解与分发逻辑

编排层将复杂任务分解为Agent可执行的子任务，分解质量直接影响整体执行效果：

• 分解粒度测试：子任务是否拆分到适合单个Agent处理的粒度。过粗导致Agent内部仍需进一步推理（效率低），过细则增加编排层和通信开销
• 依赖关系正确性：编排层是否正确识别子任务间的依赖关系（串行/并行）。例如，信贷审批中"征信查询"必须在"风控评估"之前执行，而"企业工商信息查询"和"企业舆情查询"可以并行
• 并行度优化：编排层是否最大化利用Agent间的并行执行能力。可并行的子任务是否被正确标记为并行，避免不必要的串行等待
• 子任务描述完整性：分发到每个Worker Agent的任务描述是否包含足够的上下文（前序结果、约束条件），避免Agent因信息不足而错误执行

Agent间通信正确性

多Agent系统中，Agent之间的消息传递是核心通信机制。通信正确性直接影响协作质量：

• 消息格式兼容性：各Agent产出的结果格式（JSON Schema、字段命名）是否被接收方正确解析。跨团队开发的Agent尤其容易出现字段不一致
• 消息语义一致性：同一字段在不同Agent中的含义是否一致。例如，风控Agent返回的risk_level: "high"，审批Agent是否能正确映射为"拒绝"
• 消息丢失与重复：编排层是否保证消息的可靠投递（至少一次/恰好一次语义），在Agent异常恢复后是否重复处理已完成的任务
• 上下文传递完整性：上游Agent的推理过程、中间结论、置信度等辅助信息是否随结果一起传递，帮助下游Agent做出更准确的判断

编排流程的完整性

编排流程的完整性关注从任务接收到最终结果输出的全链路是否闭环：

• 流程覆盖：编排层是否确保所有必要的Agent都已被调度执行，不存在"漏调"某个Agent的情况
• 结果聚合：多个Agent返回结果后，编排层是否将结果正确聚合为一个完整、连贯的最终输出（而非简单拼接）
• 终止条件判断：编排层是否正确判断"所有子任务已完成"并终止编排，不会出现"部分Agent已返回但编排层仍在等待"的悬挂状态
• 中间状态透明：编排层是否在整个流程中向用户提供合理的进度反馈（如"正在查询征信报告，预计需要30秒..."），而非全程黑盒等待

3. 协作测试

信息共享与传递

多Agent协作中，信息的准确、完整、及时传递是协作成功的前提：

• 共享上下文（Shared Context）：多Agent是否维护一致的共享上下文。例如，信贷审批中身份核验Agent获取的客户姓名，后续所有Agent是否都使用同一份客户信息而非各自重新查询
• 信息时效性：当某个Agent更新了共享信息（如客户修改了贷款金额），其他Agent是否能及时感知变更，还是继续使用过时的数据
• 信息粒度控制：不同Agent是否需要的信息粒度不同（风控Agent需要详细交易流水，审批Agent只需要风险等级摘要），编排层是否做了合理的信息裁剪和聚合
• 知识库共享：多个Agent是否共享同一知识库，知识库的更新（如政策变更）是否同步影响所有相关Agent的推理

冲突检测与解决

多个Agent可能对同一问题给出不同甚至矛盾的结论，冲突检测与解决是多Agent协作的核心挑战：

• 结果冲突检测：编排层是否能识别不同Agent返回的矛盾结果（如风控Agent认为"低风险"，合规Agent认为"需人工复核"）
• 冲突解决策略：检测到冲突后，编排层的解决策略是否合理：
  • 优先级策略：合规Agent的结论覆盖风控Agent（安全优先）
  • 投票策略：引入第三个Agent（如资深审批Agent）做仲裁
  • 人工升级：超出自动解决能力范围的冲突，正确升级至人工处理
• 隐性冲突：Agent虽然给出了看似一致的结果，但推理依据相互矛盾（如两个Agent都建议"通过"，但一个基于信用评分、一个基于收入水平，两者逻辑互斥），编排层是否检测到这种深层矛盾
• 冲突记录与追溯：所有冲突及其解决过程是否被完整记录，供事后审计和改进

共识机制验证

在需要多个Agent达成一致意见的场景（如信贷审批委员会模式），共识机制的正确性需要严格测试：

• 共识算法正确性：编排层采用的共识策略（一致同意/多数同意/加权投票）是否按预期执行
• 共识阈值合理性：例如"至少3个风控Agent中2个认为低风险则通过"——阈值在实际业务数据上的表现是否符合风控要求
• 僵局处理：当Agent无法达成共识时（如2:2平局），编排层是否有合理的打破僵局机制（如交给更高权限的Agent裁定）
• 共识结果偏差：是否存在"群体思维"——多个Agent由于训练数据、知识库的相似性而集体偏向同一错误结论

任务切换与上下文保持

多Agent系统中的任务切换和上下文保持能力测试关注：

• 上下文传递：任务从Agent A切换到Agent B时，任务上下文是否完整传递。包括：原始用户请求、已完成步骤及结果、待完成步骤、约束条件
• 断点续传：Agent异常中断后，编排层将任务重新分配给备用Agent时，新Agent是否能从上一次断点继续而非从头开始
• 多任务并发：同一编排流程中多个子任务并行执行时，编排层是否正确维护了每个子任务的独立上下文，不存在上下文串扰
• 会话持久化：长时间运行的多Agent任务（如尽调报告生成可能耗时数分钟），会话上下文是否正确持久化，支持编排层重启后恢复

4. 异常处理测试

单Agent故障的容错

多Agent系统必须具备在单个Agent故障时继续运行的能力：

• 故障检测：编排层是否能及时检测到Agent故障——超时、返回异常、持续重试、输出格式错误等
• 故障隔离：单个Agent的故障是否被限制在局部，不影响其他正常Agent的执行。例如，尽调流程中"舆情查询Agent"超时，不应阻塞"财务分析Agent"的并行执行
• 故障恢复策略：
  • 重试：对瞬时故障（如网络超时）是否需要重试，重试次数和间隔是否合理
  • 备用Agent切换：是否有同能力的备用Agent可接管故障Agent的任务
  • 降级执行：无可替换Agent时，编排层是否以降级模式继续——跳过非关键步骤，用默认值或历史数据替代
• 故障通知：Agent故障时，编排层是否向用户/监控系统发送清晰的告警，包含故障Agent名称、失败原因、影响范围

通信超时的降级

Agent间通信是多Agent系统的"神经系统"，通信异常的处理需要精确的降级策略：

• 消息超时策略：编排层向Agent发送消息后，等待响应的超时时间设置是否合理（不同Agent因任务复杂度不同可能需要不同的超时阈值）
• 异步通信的可靠性：异步消息（如消息队列）场景下，消息是否保证不丢失、不重复、不乱序
• 通信中断恢复：编排层与Agent之间的通信中断后，恢复时是否能正确同步状态——编排层是否知道哪些任务已分派但未确认完成
• 心跳机制：编排层是否维护与Agent的心跳检测，及时发现"僵尸Agent"（进程存在但不响应）

循环依赖检测

多Agent系统中的循环依赖是隐蔽且危险的编排缺陷：

• 直接循环依赖：Agent A的输出依赖Agent B的结果，而Agent B的输入又依赖Agent A的输出（A → B → A）
• 间接循环依赖：更复杂的链路如 A → B → C → A，可能跨越多层Agent，难以通过人工审查发现
• 条件循环依赖：仅在特定条件下触发的循环依赖（如"审批不通过时返回风控重新评估"可能形成 风控→审批→风控 的循环），是最难检测的类型
• 检测机制验证：编排层是否具备循环依赖的静态检测能力（在任务分解阶段就能识别潜在的循环）和动态检测能力（运行时检测到步数/时间异常增长）

死锁与活锁

多Agent并发执行时存在经典并发问题，在AI系统中同样需要关注：

• 死锁（Deadlock）：两个Agent各自持有一项资源并等待对方释放另一项资源。例如：Agent A锁定了客户资料表等待征信结果，Agent B（风控）锁定了风控模型等待客户资料——形成互相等待
• 活锁（Livelock）：Agent不断调整策略以响应对方变化，但始终无法达成一致。例如：审批准入Agent提高门槛后风控Agent降低评估等级，导致准入Agent再降低门槛，循环往复
• 资源饥饿：高优先级任务持续占用Agent资源，低优先级任务永远得不到执行
• 死锁检测与解除：编排层是否能检测死锁状态（如通过超时机制或资源等待图分析），并主动解除（如强制释放其中一个Agent的资源）

5. 性能与扩展性

多Agent并发性能

多Agent系统的性能瓶颈往往不在单个Agent，而在编排层和Agent间的协调开销：

• 编排层吞吐量：编排层每秒能处理的任务分解与分发请求数量。编排层自身可能成为性能瓶颈（尤其当使用LLM做编排决策时，每次编排推理都有延迟和Token消耗）
• 并行加速比：增加Agent数量后任务完成时间的缩短比例。理想情况下N个Agent的并行加速比接近N，但实际受串行依赖和协调开销的影响
• Agent间通信延迟：消息传递的端到端延迟（编排层→Agent→返回结果→编排层）。在跨网络、跨服务的分布式多Agent架构中，通信延迟可能成为主要性能开销
• Token消耗总量：多Agent系统在一次完整任务中的总Token消耗（所有Agent的输入+输出之和）。需要建立Token消耗的基线和异常阈值

Agent增加对性能的影响

多Agent系统的扩展性（Scalability）需要量化评估：

• 线性扩展测试：在任务量固定的情况下，Agent数量从N增加到2N，系统整体吞吐量的变化曲线。需要识别扩展瓶颈出现在哪个数量级
• 编排层扩展瓶颈：当Agent数量增长时，编排层的调度复杂度通常呈 O(n²) 增长（需要考虑更多的Agent间组合和依赖关系）。测试编排层能有效管理的最大Agent数量
• 通信开销增长：全连接的对等模式中，Agent间通信量的增长速率；主从模式中，编排层与Worker Agent间的通信增长速率
• 边际收益递减点：找到Agent数量增加对整体性能提升的边际收益递减临界点，为架构设计提供数据支撑

资源竞争

多个Agent共享有限的系统资源（LLM API配额、计算资源、数据库连接）：

• API限流处理：多个Agent同时调用同一个LLM API时，触发API限流（Rate Limit）后编排层是否正确处理——排队等待 vs. 切换模型 vs. 提示用户
• 数据库连接池竞争：Agent并发访问数据库时，连接池耗尽后的等待策略和超时处理
• GPU资源分配：如果每个Agent依赖独立的模型推理资源（如专用小模型），GPU资源的分配和调度是否公平、高效
• 共享状态锁竞争：多Agent更新共享状态（如任务状态表）时的锁竞争，是否使用了合理的锁粒度（行级锁 vs 表级锁）

6. 银行业多Agent场景

信贷审批的多Agent协作

信贷审批是银行业最典型的多Agent应用场景，涉及多个专业领域的Agent协同工作：

• 流程编排：Master Agent接收贷款申请 → 并行调度「身份核验Agent」+「OCR识别Agent（材料提取）」→ 串行调度「征信查询Agent」→「反欺诈检测Agent」→「风控评分Agent」→「额度测算Agent」→ 汇总结果返回审批建议
• 测试重点：
  • 并行任务同步：身份核验和OCR识别并行执行，编排层需等待两者均完成后才能进入征信查询环节，是否存在"快任务等慢任务"时的状态管理问题
  • 条件路由：风控评分 < 阈值时，是否自动路由到"人工审核Agent"而非"额度测算Agent"
  • 合规红线：反欺诈Agent标记"高风险"后，后续Agent是否仍继续执行（应直接终止并拒绝）
  • 数据一致性：身份核验Agent获取的客户姓名/身份证号，是否被征信查询Agent和反欺诈Agent一致使用

对公业务尽调报告生成

对公业务的尽职调查报告生成是一个典型的信息聚合类多Agent场景：

• 流程编排：
  • 并行采集：工商信息Agent（企业基本信息）‖ 司法信息Agent（涉诉记录）‖ 舆情Agent（负面新闻）‖ 财务Agent（财务报表分析）
  • 串行分析：关联方分析Agent → 行业分析Agent
  • 最终汇总：报告撰写Agent（整合所有Agent的分析结果，生成标准尽调报告）
• 测试重点：
  • 并行结果的时序一致性：四个并行Agent返回时间不一致（工商1秒，财务20秒），先返回的结果在等待期间是否过期
  • 数据源可靠性：舆情Agent返回了疑似虚假负面新闻，关联方分析Agent是否能交叉验证
  • 报告完整性：报告撰写Agent是否遗漏了某个Agent的分析结果（如漏掉了司法信息）
  • 格式标准化：最终生成的尽调报告格式是否符合银行内部标准（含必要章节、风险提示、签章位置）

跨系统业务流程编排

银行业务往往涉及多个异构系统的协同，多Agent架构需要与现有系统深度集成：

• 典型场景：
  • 国际结算：SWIFT报文解析Agent → 反洗钱筛查Agent → 外汇额度检查Agent → 账务处理Agent
  • 理财产品跨系统销售：客户适当性Agent（CRM）→ 产品匹配Agent（产品系统）→ 风险揭示Agent（合规系统）→ 交易执行Agent（核心系统）
• 测试重点：
  • 异构系统适配：不同系统返回的数据格式、字段命名差异，Agent是否能正确解析和转换
  • 事务一致性：跨系统的操作是否实现了最终一致性。如理财产品购买中，核心系统扣款成功但产品系统份额登记失败时的回滚机制
  • SLA保障：跨系统调用涉及不同系统的响应时间，编排层是否对每个Agent设置了合理的超时和降级策略
  • 权限穿透：编排层调用的多个Agent可能运行在不同系统中，需要确保用户的权限在所有系统中得到一致的验证和控制

7. 实战演练

以下 2 个实战任务覆盖多Agent编排测试的核心维度。建议搭建一个简化的多Agent编排框架（可使用 LangGraph、CrewAI 或自建编排层），在本地环境完成实验。

任务1：多Agent信贷审批编排测试

本任务模拟一个简化的信贷审批多Agent流程，测试编排层的任务分解、Agent调度和异常处理能力。

1. 定义Agent角色：
   • IdentityVerificationAgent（身份核验Agent）：验证申请人身份信息，返回 { name, id_number, verified: true/false }
   • CreditCheckAgent（征信查询Agent）：查询征信记录，返回 { credit_score, overdue_count, has_blacklist }
   • RiskAssessmentAgent（风控评估Agent）：综合前序信息评估风险，返回 { risk_level: "low"/"medium"/"high", suggestion: "approve"/"review"/"reject" }
   • ApprovalAgent（审批决策Agent）：汇总所有信息输出最终审批结果
2. 编排层设计：实现一个 Master Agent，按以下 DAG 编排：

   IdentityVerificationAgent（并行）
       ↓
   CreditCheckAgent（串行，依赖身份核验结果）
       ↓
   RiskAssessmentAgent（串行，依赖征信结果 + 身份核验结果）
       ↓
   ApprovalAgent（串行，汇总所有前置结果）

3. 测试用例设计（至少覆盖以下场景）：
   • 正常流程：身份验证通过 → 征信良好 → 低风险 → 自动通过
   • 身份核验失败：身份验证Agent返回 verified: false，验证编排层是否提前终止流程并告知用户原因
   • 征信黑名单：征信查询返回 has_blacklist: true，验证风控Agent是否直接给出 risk_level: "high" + suggestion: "reject"
   • Agent超时：Mock CreditCheckAgent 延迟超过30秒，验证编排层是否触发超时重试或降级
   • Agent返回异常：Mock RiskAssessmentAgent 返回格式错误的JSON，验证编排层的容错处理
4. 记录指标：
   • 编排正确率 = 编排层按预期DAG执行的次数 / 总执行次数 × 100%
   • 异常处理正确率 = 异常场景下编排层正确处理的比例（提前终止/重试/降级）
   • 端到端延迟：记录每种场景下的完整执行时间
   • 结果一致性：对同一份输入数据重复执行10次，检查审批结果是否一致

任务2：多Agent信息聚合与报告生成测试

本任务模拟对公尽调报告生成的多Agent协作场景，重点测试并行Agent的协调和结果聚合能力。

1. 定义Agent角色：
   • BusinessInfoAgent（工商信息Agent）：查询企业工商注册信息，返回 { company_name, registered_capital, establish_date, shareholders }
   • JudicialAgent（司法信息Agent）：查询企业涉诉记录，返回 { case_count, plaintiff_count, defendant_count }
   • SentimentAgent（舆情Agent）：搜索企业负面新闻，返回 { negative_news_count, sentiment_score, key_events[] }
   • ReportAgent（报告生成Agent）：汇总前三者的信息，生成标准化尽调报告
2. 编排层设计：
   • 三个信息采集Agent（BusinessInfo / Judicial / Sentiment）并行执行
   • 编排层等待所有三个Agent返回结果后（设置最长等待时间60秒），将聚合结果传递给 ReportAgent
   • ReportAgent 生成报告后，编排层检查报告是否包含所有必要章节
3. 测试用例设计（至少覆盖以下场景）：
   • 全部正常：三个Agent均在5秒内返回完整结果，报告生成正确
   • 部分Agent超时：JudicialAgent 60秒内未返回，编排层以超时降级模式继续（只使用两个Agent的结果生成报告），并在报告中标注"司法信息查询超时，数据可能不完整"
   • 结果冲突：BusinessInfoAgent 返回"注册资本1000万"，但 SentimentAgent 返回的新闻中提到"该公司注册资本实际为500万"，验证 ReportAgent 是否标记冲突并建议人工核实
   • 空结果处理：SentimentAgent 返回空（无相关舆情），验证编排层和ReportAgent是否正常处理空结果而非报错
   • 报告完整性：使用 Checklist 验证生成报告的完整性：
     • 是否包含企业基本信息章节
     • 是否包含司法风险章节
     • 是否包含舆情风险章节
     • 是否有综合风险评估和结论
4. 记录指标：
   • 并行效率：对比三个Agent并行执行的总耗时 vs 串行执行的总耗时
   • 报告完整率 = 包含所有必要章节的报告数 / 总报告数 × 100%
   • 降级处理正确率 = 部分Agent超时时正确处理的比例
   • 信息准确性：报告中的每条数据是否能追溯到具体的Agent和数据源

多Agent编排测试维度总览

多Agent编排测试覆盖 编排 → 协作 → 异常 → 性能 四大环节，15+ 细分测试维度，3个 银行业典型场景