我们的项目中，在行程规划后，我们需要对行程进行审核，检查时间是否正确，目的地是否正确， 是否符合差旅政策等等。 这个审核的节点，有很多实现方式，比如直接写在行程规划的智能体的prompt中，比如做成一个skill让行程规划智能体执行，比如做成一个subAgent。 那我们最终选择的是subAgent，为什么呢？从以下5个点考虑：
审核需要独立的判断立场
审核的本质是对规划结果做质疑和验证。如果审核逻辑跑在规划 Agent 自身的推理循环里（Skill 方式、prompt方式），就变成了"自己审自己"。 ItineraryPlanAgent 的 system prompt 里写满了"如何做好规划"的指令。它的思维模式是建设性的——倾向于"如何让方案更好"。而审核需要的思维模式是批判性的——倾向于"找出哪里有问题"。 用独立子智能体，我们可以给审核 Agent 一套完全不同的 system prompt：
## 行程方案多方案批量审核专家
你只负责客观维度的结构化校验，不考虑个人偏好。
审核仅对照差旅政策与客观维度，不引入个人偏好作为评判依据。
修复建议必须可执行——不要说"建议优化"，要说"将酒店从亚朵替换为全季"。
独立 prompt = 独立思维框架 = 真正有效的审核。
审核需要多步推理
审核不是"查一下就完了"。从源码可以看到，ItineraryReviewAgent 需要： 1. 先查差旅政策（query_travel_policy）——因为不同目的地政策不同 2. 再读方案并做五维校验（review_planner_result）——从 Redis 读取规划结果 3. 最终整合出结构化报告——要做方案间对比、选最优、给修复建议 这三步是有依赖关系的：不知道政策就没法判断是否超标。Skill 方式下，这些步骤会混入 ItineraryPlanAgent 本身的推理循环中，和"搜机票""打偏好分"等步骤抢占注意力——一个 15 轮上限的 ReAct 循环，已经被规划任务填得很满了。 子智能体的好处是独立的 8 轮迭代上限，专门用来做审核。不和规划任务抢资源。
审核需要独立模型
看模型配置：
// ItineraryPlanAgent 用 qwen3.7-max + thinking（12 元/百万 token）
.model(strongModelWithThinking)
// ItineraryReviewAgent 用 glm-5.1（6 元/百万 token）
.model(stableModel)
规划需要创造性思维和深度推理（怎么打偏好分？怎么解读用户需求？），所以用贵模型 + thinking。 审核需要的是稳定性和结构化评估（五个维度逐一检查，有就报有没有就过），不需要深度思考，但需要不"幻觉"。所以用更稳定的 glm-5.1。 Skill 方式下，审核逻辑必须跑在父 Agent 的模型上——你没法给一份 Markdown 说明书指定使用哪个模型。子智能体则可以独立配置最适合审核任务的模型。 而且，我们尽可能用不同的模型分别做设计和审核，才能避免单一模型的局限性。
审核工具集需要隔离
ItineraryPlanAgent 的工具集里有大量搜索相关工具（tuniu-cli、rgh 酒店搜索、签证查询、MCP 天气服务等）。如果审核逻辑跑在同一个 Agent 里（Skill 方式），LLM 在审核阶段仍然能"看到"这些搜索工具——它可能会手痒去重新搜索，而不是专注于审核已有方案。 子智能体的工具集是独立且最小化的：
// ItineraryReviewAgent 只有两类工具
toolkit.registration().tool(policyTools).apply(); // 查政策
toolkit.registration().tool(itineraryReviewTools).apply(); // 做审核
工具越少，Agent 越专注。 审核 Agent 看不到搜索工具，就不会跑偏去重新搜索。
上下文隔离
ItineraryPlanAgent 执行到审核步骤时，它的上下文里已经积累了大量内容：审批单信息、用户偏好、搜索结果（可能几百条航班/酒店数据）、打分逻辑等。如果审核是 Skill 方式（跑在同一个推理循环里），LLM 要在这些"噪音"中找到关键审核信息。 子智能体从一个干净的上下文开始。它收到的只是一条 message（"请审核"），然后自己去 Redis 读方案——上下文里只有政策 + 方案 + 审核结果。没有噪音。