144 lines
6.7 KiB
Markdown
144 lines
6.7 KiB
Markdown
---
|
||
tags: [test/review, ai, agent-design, multi-agent]
|
||
create time: 2026-08-09 12:00
|
||
---
|
||
|
||
# 多智能体协作模式 — 测试题
|
||
|
||
## 概述
|
||
本测试覆盖 Supervisor 主从分发模式、Critic 审查反馈循环、Planner 规划先行机制、消息传递协议以及各模式的对比分析。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
|
||
|
||
---
|
||
|
||
## 一、选择题（6道，由浅入深）
|
||
|
||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||
|
||
### Q1（基础）— 考察定义层面
|
||
|
||
多智能体系统相比单一大 Agent 的核心挑战不包括以下哪项？
|
||
|
||
A. 通信协议设计
|
||
B. 任务分解质量
|
||
C. 模型训练数据量
|
||
D. 冲突消解机制
|
||
|
||
### Q2（基础）→
|
||
|
||
Supervisor 模式中子任务的最佳粒度是：
|
||
|
||
A. 越细越好——每个原子操作都拆成独立子任务
|
||
B. 越粗越好——减少通信开销
|
||
C. 一般 3-7 个粒度最合适——匹配人类短期记忆容量（Miller 法则）
|
||
D. 固定为 2 个子任务以确保并行效率
|
||
|
||
### Q3（进阶）— 核心原理
|
||
|
||
Critic Agent 的角色定位是什么？
|
||
|
||
A. 负责生成候选方案并评估其可行性
|
||
B. 不生产内容，只评估已有内容的质量，给出评分和改进建议
|
||
C. 负责将最终结果格式化输出
|
||
D. 负责与用户交互收集需求
|
||
|
||
### Q4（进阶）— 比较/辨析
|
||
|
||
以下关于 Planner 模式动态 Planning（Replan）的描述哪个是正确的？
|
||
|
||
A. Plan 一旦制定就不能修改
|
||
B. 当某一步失败或结果不符合预期时，Planner 重新规划后续步骤
|
||
C. Replan 只在所有步骤完成后触发
|
||
D. Replan 会从头开始执行整个流程
|
||
|
||
### Q5（深入）— 场景推理
|
||
|
||
在 Gen2D 项目中采用的多 Agent 混合架构是：
|
||
|
||
A. 纯 Supervisor 模式
|
||
B. 纯 Planner 模式
|
||
C. Supervisor + Planner 混合模式
|
||
D. Swarm 模式
|
||
|
||
### Q6（深入）— 源码级/边界场景
|
||
|
||
原文中提到"为什么不做一个超级大的 Agent"的四个原因中，以下哪个**不是**其中的一个？
|
||
|
||
A. 上下文窗口有限，塞入太多能力会稀释注意力
|
||
B. 工具冲突概率随数量增加而上升
|
||
C. LLM 的单次推理成本随上下文长度指数增长
|
||
D. 调试困难——出问题时无法定位是哪个模块的问题
|
||
|
||
---
|
||
|
||
## 二、填空题（3道）
|
||
|
||
### F1 — 填空1
|
||
|
||
多 Agent 之间通过结构化消息通信，推荐使用 _____ Schema 定义契约。消息类型体系中，`task_assignment` 的方向是 S → Agent，_____ 的方向是 Agent → S（汇报完成结果）。
|
||
|
||
> **提示**: 第一个空填消息格式；第二个空是原文表格中的消息类型名称。
|
||
|
||
### F2 — 填空2
|
||
|
||
Critic 的质量取决于它的评估标准是否_____。纯自然语言的评判主观性太强，应该定义结构化评分维度：准确性、完整性、安全性各占权重。
|
||
|
||
> **提示**: 形容词，表示可以用数字衡量。
|
||
|
||
### F3 — 填空3
|
||
|
||
Swarm 模式的优点是简洁灵活、天然并行，缺点是缺乏全局协调、易产生不一致。它最适合的场景是_____和发散性的_____。
|
||
|
||
> **提示**: 两个词，描述一类任务的性质。
|
||
|
||
---
|
||
|
||
## 三、简答题（1道）
|
||
|
||
### S1
|
||
|
||
面试官问："在一个智能客服系统中，你需要同时处理用户咨询、订单查询和退款申请三个不同类型的请求。请设计一个多 Agent 协作方案，说明你会选用哪些模式组合，为什么这样选型，以及如何保证最终交付给用户的一致体验。"
|
||
|
||
> **答题框架提示**:
|
||
> 1. 整体架构模式选择及理由
|
||
> 2. 各 Agent 的职责划分
|
||
> 3. 通信与状态管理
|
||
> 4. 质量保障机制
|
||
|
||
---
|
||
|
||
## 参考答案与解析
|
||
|
||
### 选择题答案
|
||
|
||
| 题号 | 正确答案 | 解析 |
|
||
|------|---------|------|
|
||
| Q1 | C | 多智能体的三大核心挑战：① 通信协议设计；② 任务分解质量；③ 冲突消解机制。模型训练数据量是单Agent和多Agent都要面对的共同问题，不是多Agent特有的挑战。 |
|
||
| Q2 | C | Miller 法则指出人类短期记忆容量约为 7±2 个信息块。子任务拆得太细导致通信开销过大；太粗则失去并行价值。3-7 是最优区间。 |
|
||
| Q3 | B | Critic 不生产内容，只评估已有内容的质量。Producer-Critic 形成对抗循环，类似于 GAN 中的判别器角色。 |
|
||
| Q4 | B | 动态 Planning（Replan）的核心就是当某一步失败或结果不符合预期时，Planner 重新规划后续步骤。例如搜索结果为空时自动调整为扩大搜索范围。 |
|
||
| Q5 | C | Gen2D 采用 Supervisor + Planner 混合：入口 Supervisor 分解为前端/后端/测试三条线，每条线内由 Planner 制定步骤序列。避免单层 DAG 节点过多。 |
|
||
| Q6 | C | 原文提到的四个原因是：① 上下文窗口有限；② 工具冲突概率上升；③ 调试困难；④ 迭代成本高。单次推理成本随上下文增长虽然也是事实，但原文未将其列为核心理由。 |
|
||
|
||
### 填空题答案
|
||
|
||
| 题号 | 答案 | 解析 |
|
||
|------|------|------|
|
||
| F1 | `JSON`；`result_report` | JSON Schema 提供结构化的消息契约。消息类型体系包括 task_assignment（分配）、result_report（汇报）、feedback_request（反馈）、escalation（上报）、cancellation（取消）。 |
|
||
| F2 | `量化`（或"可量化"） | 纯自然语言评判主观性太强。Critic 必须定义结构化评分维度如准确性（准确率%）、完整性（覆盖率%）、安全性（违规数），各占明确权重。 |
|
||
| F3 | `探索性`；`头脑风暴` | Swarm 没有全局协调者，各 Agent 独立行动。这种模式适合无固定流程的探索性任务和发散性的头脑风暴，不适合需要严格顺序的步骤化任务。 |
|
||
|
||
### 简答题参考答案
|
||
|
||
S1：**参考答案要点**：
|
||
1. **整体架构**：选用 Supervisor + Critic 混合模式。Supervisor 负责接收用户需求并按类型分发给专业 Agent（咨询专家、订单专员、退款专员），Critic 负责最终输出质量的交叉检查。
|
||
2. **职责划分**：咨询 Agent 调用知识库 RAG；订单 Agent 查询数据库；退款 Agent 走审批流 FSM。每种类型的 Agent 工具集互不干扰。
|
||
3. **通信与状态**：结构化消息（JSON Schema）承载任务分配和结果汇报。共享 State 存储中间产物和用户上下文。
|
||
4. **一致体验**：Critic Agent 统一审核各 Agent 的输出——格式规范化、语气一致性、敏感词过滤。最终由 Supervisor 整合后交付用户。
|
||
5. **降级策略**：某个 Agent 不可用时（如订单系统宕机），Supervisor 切换到缓存版本或直接告知用户暂时无法服务，而不是让整个对话崩溃。
|
||
|
||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
|
||
|
||
## 关联笔记
|
||
- [[Eino DAG 工作流设计]]
|
||
- [[上下文工程与记忆管理]]
|