多 Agent 编排实战：Facade、Chain 和 4 层输出校验
一个 Agent 能干活，但面试这件事需要五个 Agent 配合。怎么让它们不打架？
目录
- 从一个场景说起
- [Agent 之间的本质差异](#Agent 之间的本质差异)
- [Facade 模式：灵活协调](#Facade 模式：灵活协调)
- [LiteFlow Chain：固定规则裁决](#LiteFlow Chain：固定规则裁决)
- [Facade vs Chain 怎么选](#Facade vs Chain 怎么选)
- [Prompt 管理的 4 种方式](#Prompt 管理的 4 种方式)
- [4 层输出校验](#4 层输出校验)
- 完整编排清单和总结
从一个场景说起
这是「Agent 架构认知升级手册」系列的第 2 篇。上一篇 解决了 Agent 是什么的问题------从数据库里的一行配置，到 Resolver 解析、Facade 协调、AI 调用的完整链路。
但一个 Agent 只能干一件事。面试这件事天然需要多人协作：一个人看简历出题，一个人负责提问，一个人专门打分，一个人决定要不要追问。在代码里，这就是 5 个 Agent 的编排问题。
这篇聚焦一件事：多个 Agent 怎么配合工作。
Agent 之间的本质差异
5 个 Agent 的代码结构几乎一样------都是查配置、调 AI、解析结果。那它们的区别在哪？
在于 Prompt 不同，导致输入输出格式不同，处理逻辑不同。
| Agent | 输入 | 输出 | 职责 |
|---|---|---|---|
| 面试出题官 | 简历 PDF | 面试题列表（JSON） | 分析简历，生成针对性面试题 |
| 面试提问官 | 当前题目 + 对话历史 | 提问文本 | 读题后向候选人提问 |
| 用户答案评分官 | 题目 + 候选人回答 | 分数 + 评语（JSON） | 对回答进行评分 |
| 追问官 | 分数 + 评语 + 知识点 | 是否追问 + 追问内容 | 判断是否需要深挖 |
| 神态分析官 | 视频帧 / 音频片段 | 仪态评分（JSON） | 分析候选人的表情和仪态 |
代码骨架一样，但每个 Agent 的 Prompt 定义了它的角色、输入格式和输出格式。换一个 Prompt，就是换一个 Agent。
Facade 模式：灵活协调
什么时候用： 流程可变、步骤之间有状态管理、需要异常处理。比如面试的整体流程------上传简历、出题、提问、评分、生成报告------中间任何一步都可能失败，需要状态回滚或重试。
InterviewSessionFacade 就是这个协调员：
java
@Service
public class InterviewSessionFacade {
private final InterviewWorkflowService workflowService;
private final InterviewSessionService sessionService;
public InterviewQuestionRespDTO extractInterviewQuestions(
String sessionId, MultipartFile resumePdf, Long userId) {
// 1. 状态管理：标记上传中，防止重复提交
sessionService.markUploading(sessionId, userId);
// 2. 调用工作流服务（内部找到出题官 Agent，调 AI）
InterviewQuestionRespDTO response =
workflowService.extractInterviewQuestions(requestParam);
// 3. 成功了，标记准备就绪
sessionService.markReady(sessionId, userId, response);
return response;
}
}前端只调一行 facade.extractInterviewQuestions()，不用知道里面有状态管理、Agent 解析、AI 调用、结果解析这些步骤。Facade 把这些封装起来，前端只管要出题，内部怎么协调它不关心。
类比：你找婚礼策划师，策划师去对接酒店、摄影、化妆。你不用挨个打电话。
LiteFlow Chain：固定规则裁决
什么时候用： 流程固定、规则明确、不需要 LLM 动态决策。比如追问决策------评分官打完分后，追问官要决定是否需要追问。这个决策不需要 AI 自己判断，而是按一套固定的规则链依次检查。
项目用 LiteFlow 规则引擎实现了追问决策链：
xml
<chain name="default_followup_chain">
THEN(
loadFollowUpContext, // 1. 加载上下文（分数、评语、知识点）
completedStateGuard, // 2. 完成状态守卫（面试已结束？跳过）
followUpLimitGuard, // 3. 追问次数限制（问过太多次了？停）
aiSuggestionJudge, // 4. AI 建议判断（AI 觉得需要追问？）
lowScoreJudge, // 5. 低分判断（分数低于阈值？追问）
missingPointsJudge, // 6. 遗漏点判断（有知识点没覆盖？追问）
followUpDecisionFinalize // 7. 最终裁决（综合以上，决定追不追）
);
</chain>每个节点是一个独立的判断逻辑，比如 aiSuggestionJudge 节点：
java
@LiteflowComponent("aiSuggestionJudge")
public class AiSuggestionJudgeNode extends NodeComponent {
@Override
public void process() {
InterviewFollowUpRuleContext ctx = getContextBean(InterviewFollowUpRuleContext.class);
if (ctx.isTerminated()) return; // 已终止，跳过
if (ctx.isFollowUpNeededFromAi()) {
ctx.markNeedFollowUp("AI_SUGGESTED", "AI 建议追问");
}
}
}所有节点共享一个上下文对象 InterviewFollowUpRuleContext，里面存着当前分数、低分阈值、AI 是否建议追问、遗漏的知识点等信息。每个节点读上下文、做判断、写结论，最后一个节点综合所有结论做出最终裁决。
7 个节点按顺序执行，支持短路终止------如果第 2 步发现面试已经结束了，后面 5 步全部跳过。
Facade vs Chain 怎么选
| 维度 | Facade | LiteFlow Chain |
|---|---|---|
| 适用场景 | 流程可变、需要状态管理 | 流程固定、规则明确 |
| 决策方 | 代码逻辑 + AI | 规则引擎，不依赖 AI |
| 灵活性 | 高，可以加 try-catch、重试、回滚 | 中，改规则需要改链定义 |
| 性能 | 取决于内部调用 | 快，纯内存规则判断 |
| 复杂度 | 中等 | 低，节点职责单一 |
面试平台的选择：整体用 Facade （上传→出题→提问→评分→报告，流程灵活），追问决策用 Chain（7 个规则节点，固定流程）。
一句话：流程可变选 Facade，流程固定选 Chain。 不是二选一，是各管各的。
Prompt 管理的 4 种方式
Prompt 是 Agent 的灵魂。管理 Prompt 的方式有四种，灵活度递增：
| 方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 硬编码在代码中 | 最简单 | 改 Prompt 要改代码、重新部署 | 快速原型 |
| 配置文件（yml） | 改配置不用改代码 | 仍然要重启 | 小项目 |
| 数据库 | 动态修改、版本管理、A/B 测试 | 需要设计表结构和管理界面 | 多 Prompt 管理 |
| 星辰工作流 | Prompt 写在平台配置里，可视化编辑 | 绑定特定平台 | 本项目 |
本项目用的是星辰工作流------Prompt 直接写在星辰大模型平台的工作流配置里，代码里不存任何 Prompt。改 Prompt 去平台上改就行，代码不用动，也不用重启。
这种方式适合 Prompt 调试频繁的阶段。等 Prompt 稳定了，可以考虑迁移到数据库管理，获得版本控制和 A/B 测试能力。
4 层输出校验
AI 返回的格式不一定符合预期。有时候它返回了纯文本而不是 JSON，有时候 JSON 里缺了关键字段。如果代码直接解析，大概率会报错。
解决方案是 4 层保障，从源头到兜底层层防护：
第 1 层：Prompt 约束（源头控制）
-> 在 Prompt 里明确要求返回 JSON 格式，并给出 Schema 示例
第 2 层：JSON 提取（格式容错）
-> AI 返回的可能不是纯 JSON（前后有解释文字），用正则提取 JSON 部分
第 3 层：解析校验（结构容错）
-> 用 Jackson/Gson 解析 JSON，校验必要字段是否存在
第 4 层：容错兜底（最终保障）
-> 解析失败时返回默认值或触发重试，不抛异常阻断流程第 1 层解决 80% 的问题------大部分 AI 模型在 Prompt 明确要求 JSON 时会遵守。第 2-3 层处理 AI 偶尔的格式偏差。第 4 层是最后的安全网，确保即使 AI 完全胡说八道，系统也不会崩。
完整编排清单和总结
要实现一个多 Agent 编排系统，至少需要以下 4 步：
第 1 步：基础设施准备
- 注册 AI 平台账号（如星辰大模型）
- 创建多个工作流（出题、评分、追问等）
- 获取每个工作流的 API Key、Secret、Flow ID
第 2 步：数据库设计
- Agent 配置表（
agent_properties）：存名字、密钥、工作流 ID - Prompt 模板表（如果用数据库管理 Prompt）
第 3 步：代码实现
- 实体类 + 场景枚举 + 解析器 + AI 客户端
- 各业务 WorkflowService（出题、评分、追问）
- Facade 协调 + Controller 接口
第 4 步：编排设计
- 整体流程用 Facade 协调
- 固定规则用 Chain 裁决
- 4 层输出校验保底
系列导航：
- 第 1 篇：Agent 到底是什么------从配置到自主决策
- 第 2 篇：多 Agent 编排实战------Facade、Chain 和 4 层输出校验（本篇）
一句话总结： 多 Agent 编排的核心不是技术框架选型，而是想清楚每个 Agent 的边界------谁干什么、谁协调谁、出错了怎么办。