jiuwenSwarm 多 Agent 协同经验分享 — 基于 AI 面试天团案例

本文以「AI 面试天团」为真实案例，分享 jiuwenSwarm 多智能体协同的构建过程、设计决策与踩坑经验。

一、背景与简介

1.1 为什么要做 AI 面试

企业招聘中，面试环节长期存在三个痛点：

AI 面试正是为了解决这些问题而生：标准化提问、量化评分、消除偏见、7×24 随时面。

1.2 单 AI 做面试的困境

我们最初尝试用单个大模型做面试，很快遇到了瓶颈：

一个 Agent 既要出技术题、又要问 HR 问题、还要评分生成报告
→ Prompt 膨胀到上万字，模型注意力涣散，后半段指令被忽略
→ 角色混乱：技术面试中途突然问"你的职业规划是什么"
→ 深度不够：技术追问和 HR 洞察都需要专业深度，一个模型难以兼顾
→ 无法并行：技术评分和 HR 评分混在一起，难以独立量化

核心矛盾：真实面试是一个团队协作过程——技术专家考技术、HR 专家考综合素质、第三方汇总出报告。单个 AI 试图一人分饰多角，违背了面试的本质。

1.3 多智能体协作：让 AI 也能组队面试

多智能体（Multi-Agent）的思路很简单：不要让一个 AI 什么都做，而是让多个专业 AI 各做各的，协同完成复杂任务。

映射到面试场景：

真实面试团队                    AI 面试天团
─────────────                  ─────────────
面试主持人（协调流程）    →     面试调度总控 (Leader)
技术专家（出题+技术评分）  →     技术面试官 Agent
HR 专家（综合素质评分）    →     HR 面试官 Agent
测评委员会（汇总出报告）   →     人才测评专员 Agent
破冰接待（让候选人放松）    →     通用聊天官 Agent

每个 Agent 只扮演自己擅长的角色，有自己的专属知识库、人设风格和评分标准，互不越界。

1.4 jiuwenSwarm 是什么

jiuwenSwarm 是一个开源的多智能体协作框架（由 openJiuwen 团队维护），专门用于构建多个 AI Agent 协同工作的系统。它的核心能力包括：

jiuwenSwarm 官网：https://gitcode.com/openJiuwen/jiuwenswarm

1.5 本文要分享什么

本文不是 jiuwenSwarm 的使用手册，而是一次完整的多 Agent 系统构建经验分享。我们以 AI 面试天团为案例，讲清楚以下几件事：

• 怎么想的：为什么这样拆角色、定流程、配信号（第二章）
• 怎么做的：Skill 怎么写、模型怎么选、知识库怎么分（第三章）
• 踩了什么坑：心跳刷屏、消息转发、状态跳转等真实问题（第五章）
• 最后才说为什么：为什么选 jiuwenSwarm 而不是其他方案（第七章）

二、构建思路

2.1 核心设计原则：先拆角色，再定流程，最后配信号

这是我们在实践中总结的三步法：

第一步：拆角色 → 谁参与？各自的专业边界是什么？
第二步：定流程 → 谁先谁后？依赖关系是什么？谁是唯一对用户说话的人？
第三步：配信号 → Agent 之间怎么交接？数据怎么流转？什么时候算完成？

2.2 第一步：拆角色

原则：每个 Agent 只做一件事，做到极致。

关键决策：为什么 Leader 不直接面试？

因为「协调」和「执行」是两种完全不同的认知模式。Leader 需要全局视野（管理状态机、处理信号、转发消息），如果同时让它出题评分，prompt 会膨胀，注意力分散。分离后，Leader 的 SKILL.md 只有 11KB，纯粹做调度。

关键决策：为什么测评专员不接触候选人？

面试和评分必须分离，避免「自己考自己打分」的偏差。测评专员只接收结构化数据，做纯计算，保证客观性。

2.3 第二步：定流程

原则：用任务 DAG 声明依赖，不要硬编码顺序。

破冰聊天 (可跳过)
    ↓
技术面试 ← 依赖破冰完成
    ↓
HR面试   ← 依赖技术面试完成
    ↓
生成报告  ← 依赖技术+HR评分数据

在 jiuwenSwarm 中通过 create_task + depends_on 声明：

# Leader 创建任务 DAG
create_task: 破冰聊天
create_task: 技术面试 (depends_on: 破冰聊天)
create_task: HR面试   (depends_on: 技术面试)
create_task: 生成报告  (depends_on: HR面试)

框架自动管理状态流转：前序完成才解锁后续，不需要手写 if-else。

关键决策：单发言人控制

这是整个系统最重要的约束。如果不控制，多个 Agent 可能同时向候选人发消息，体验灾难性。

实现方式：Leader 的 SKILL.md 中定义严格协议：

1. Leader 是唯一对候选人说话的接口
2. 每次只激活一个 Agent，通过 send_message(to=agent) 下发指令
3. 等待该 Agent 返回 CONTROL_RETURN 信号后才激活下一个
4. Agent 之间不直接通信，所有数据通过 Leader 中转

2.4 第三步：配信号

原则：Agent 间用结构化信号通信，不用自然语言。

# 进度报告（每题评分后）
PROGRESS_REPORT|QUESTION_1|TOTAL_5|SCORE_9|评分依据

# 心跳（等待候选人作答时，每5秒）
HEARTBEAT|QUESTION_1|IN_PROGRESS

# 控制权返回（环节完成）
CONTROL_RETURN
TECHNICAL_SCORING_DATA|张三|AI算法工程师|9,9,9,9,9|45|9.0|文件路径

# 报告就绪
REPORT_READY|张三|AI算法工程师|8.4|强烈推荐|报告路径

为什么不用自然语言通信？

• 结构化信号可精确解析，不会误解
• Leader 可以自动提取数据字段做流转
• 可审计：日志中一眼看出流程进度
• Agent 的 prompt 更简单：只需按格式输出，不需要理解对方在说什么

三、具体怎么构建

3.1 Skill 设计要点

每个 SKILL.md 是一个 Agent 的完整行为定义，设计时有四个必填部分：

---
name: <skill-name>
description: <英文简述>
---
# Role          ← 我是谁，我的专业边界
# 核心规则       ← 我必须遵守的约束（出题顺序、评分标准、保存路径等）
# 信号格式       ← 我与 Leader 通信的协议
# 边界处理       ← 异常情况怎么办（答不出、检索失败等）

实践建议：

• SKILL.md 控制在 8-12KB，太长模型会忽略后半部分
• 知识库路径、保存路径等硬编码在 SKILL.md 中，不通过运行时传参
• 评分标准用三档（优秀/合格/不合格）+ 分数区间，比五档更容易执行

3.2 模型分配策略

原则：按任务特性选模型，不是全部用最贵的。

关键收益：技术面试官用 flash 模型，出题评分快；测评专员用 deepseek，报告质量高。如果全用 glm-5.2，成本翻倍但体验不会更好。

3.3 知识库设计

原则：每个 Agent 只看到自己需要的知识库，不交叉。

D:\zhishiku\
├── 公司介绍.pdf                    → 通用聊天官
├── 招聘简章.pdf                    → Leader
├── 技术面试题库.pdf                → 技术面试官
└── HR面试题库.pdf                  → HR面试官

技术面试官不需要看 HR 题库，反之亦然。隔离的好处：

• prompt 更短，注意力更集中
• 不会串题（技术面试官不会突然问 HR 问题）
• 知识库可独立更新，不影响其他 Agent

3.4 人设（persona）与提示词（prompt_hint）的区分

jiuwenSwarm 提供两层注入：

实践建议：persona 写简短的人设画像（1-2句话），prompt_hint 写完整的 SKILL.md 级别的行为规则。这样其他 Agent 知道"这个人是做什么的"，但不知道他的具体规则。

3.5 异常处理设计

在 SKILL.md 中必须定义边界处理，否则 Agent 遇到异常会卡住：

- 候选人答不出某题 → 按不合格档评分，继续下一题
- 候选人问非本环节问题 → "这个问题请咨询面试主持人"
- 知识库检索失败 → 报错并通知 Leader，等待指令
- 候选人要求跳过破冰 → Leader 取消破冰任务，直接激活技术面试

本案例的真实经历：候选人说"我想直接进行面试"，Leader 立即取消破冰任务，技术面试任务自动从 blocked 变为 pending，流程无缝衔接。这就是任务 DAG 的价值——声明式依赖，框架自动处理状态流转。

四、架构模式总结

4.1 适用于本案例的模式：串行流水线 + 单发言人

Leader (唯一出口)
  → Agent A → CONTROL_RETURN
  → Agent B → CONTROL_RETURN + 数据
  → Agent C → CONTROL_RETURN + 数据
  → Agent D → REPORT_READY

特征：严格顺序、单点通信、数据逐级汇总。

4.2 jiuwenSwarm 还支持的其他模式

4.3 选择建议

能用串行流水线解决的 → 不要用并行
能用 DAG 声明依赖的 → 不要硬编码 if-else
能用结构化信号的 → 不要用自然语言通信
能用 Skill 隔离的 → 不要塞进一个 prompt

五、踩过的坑与经验

5.1 心跳信号处理

技术面试官在等待候选人作答时会持续发送 HEARTBEAT|QUESTION_N|IN_PROGRESS。Leader 需要识别这是心跳而非正式消息，不要每次都回复，否则会刷屏。

解法：Leader 的 SKILL.md 中明确：HEARTBEAT 信号静默忽略，只在收到 PROGRESS_REPORT 或 CONTROL_RETURN 时才行动。

5.2 候选人消息转发

候选人通过飞书/Web 发的消息，只有 Leader 能收到。Leader 需要及时将回答转发给当前活跃的面试官。

解法：Leader 维护"当前活跃 Agent"状态，收到候选人消息后立即 send_message(to=当前Agent, content=候选人回答)。

5.3 破冰跳过的状态处理

候选人要求跳过破冰时，需要：取消破冰任务 → 技术面试任务自动解锁 → 激活技术面试官。

解法：update_task(task_id=破冰, status=cancelled)，框架自动将依赖它的技术面试从 blocked 变为 pending。

5.4 评分数据持久化

每个面试官的评分数据需要：保存到本地文件 + 回传给 Leader + 最终汇总给测评专员。

解法：面试官保存 txt 到 D:\面试记录\，同时通过信号回传结构化数据。Leader 收到后写入 team-workspace 的 JSON 文件，测评专员从 JSON 读取做汇总。

六、一页纸清单

想用 jiuwenSwarm 构建多 Agent 系统，按这个顺序走：

1. 拆角色：列出所有参与方，明确各自的唯一职责和不做什么
2. 定流程：画 DAG，标注依赖关系，确定谁对用户说话
3. 选模型：按任务特性分配，协调用强模型、执行用快模型
4. 写 Skill：每个 Agent 一个 SKILL.md，含角色/规则/信号/异常处理
5. 配信号：定义 Agent 间的结构化通信协议
6. 备知识库：按 Agent 隔离知识库，不交叉
7. 配团队：在 config.yaml 中定义 predefined_members + agents 模型分配
8. 配渠道：飞书/Web/钉钉，开启 send_file_allowed
9. 验证：发一条消息走完全流程，检查信号日志和输出文件

七、为什么选择 jiuwenSwarm

7.1 我们要解决的问题

AI 面试是一个典型的多角色、多阶段、有严格流程约束的复杂任务：

• 多角色：破冰聊天、技术面试、HR 面试、人才测评，每个角色有完全不同的专业领域和人设风格
• 多阶段：收集信息 → 选岗位 → 破冰 → 技术面试 → HR 面试 → 生成报告，阶段间有严格依赖
• 单发言人约束：同一时刻只能有一个面试官与候选人对话，避免混乱
• 数据流转：各环节评分数据需汇总到测评专员做加权计算
• 知识库隔离：技术题库和 HR 题库是不同的 PDF，各面试官只看自己的题库

如果用单 Agent 做，要么 prompt 巨长导致注意力涣散，要么角色混乱（技术面试官突然问 HR 问题），要么难以维护。

7.2 jiuwenSwarm 的核心优势

7.3 对比其他方案

jiuwenSwarm 多 Agent 协同经验分享 v1.0 | 基于 AI 面试天团案例 | 2026-07-15