第 22 章测验

对应章节：多智能体 v09

共 8 题，答对率 ≥ 80% 即通过。请完成全部题目后点击「提交」。

Q1第 22 章「subagent = 独立的 loop 实例」的含义是什么？需要引入一个全新的 Agent 框架来创建 subagent subagent 就是把第 7 章手写的 runAgent 再实例化一次——喂全新消息历史、白名单工具、独立预算、自己的 sessionId；多 Agent 不是新架构，是同一个 loop 的多份实例加一层委派编排 subagent 必须用不同的模型供应商 subagent 是主 Agent 的一个子函数，共享主循环的迭代计数

Q2下列哪一项「不是」subagent 的隔离维度？消息上下文：从全新的 [system, user(task)] 开始，主对话不泄漏、两个 subagent 互不可见工具集：只复制白名单内的工具（spec + impl 原样复制），其余工具从 subagent 视角消失预算：subagent 用自己独立的 maxIterations，与主循环互不共享使用独立的模型 API 端点，每个 subagent 都要单独配置 API key

Q3delegate 元工具的名字与 schema 归谁所有，执行逻辑归谁决定？名字和 schema 由主循环（loop.mjs）拥有，注入的 spawnSubagent 工厂决定「跑起来做什么」（上下文/白名单/预算都在工厂里）全部由工具注册表（tools.mjs）决定全部由模型在 prompt 里自己定义名字归用户，schema 归前端

Q4「结果回收」在协议层面的具体形态是什么？ subagent 的终答字符串作为一条 tool 消息（tool_result）回填到主 Agent 的消息历史，主 Agent 下一轮像看待普通工具结果一样读它 subagent 的完整消息历史整体合并进主会话新增一种 delegate_result 事件类型专门承载子任务结果 subagent 直接向用户发消息，绕过主 Agent

Q5orchestrator-worker 与 handoff 两种编排模式的关键区别是什么？ orchestrator-worker 中央分派、worker 并行隔离、结果回填汇总；handoff 把控制权和对话状态整体移交给下一个 Agent（串行接力）——我们实现的是前者的简化版（委派 + 结果回收，不做状态整体转移） orchestrator-worker 只能串行，handoff 才能并行两者没有区别，只是名字不同 handoff 不需要工具，orchestrator-worker 才需要工具

Q6主循环并发执行一批 delegate 调用时，如何保证模型看到的工具结果有序、且不破坏 ch18 的审批语义？一批调用全部并发（Promise.all），结果按调用顺序回填；approve 级工具永远不进并发批，仍逐个暂停走审批门所有调用（包括 approve 级）都并发执行，审批可以批量进行只并发 delegate 调用，其余工具永远串行结果按完成时间回填，谁先完成谁先进历史

Q7subagent 耗尽自己的迭代预算（budgetExceeded）时，工厂的行为是什么？返回 { ok: false, error: 'subagent budget exceeded after N iterations' }——失败可见，半成品不当作真话回填；主 Agent 读到的是普通工具错误，可自行恢复静默回退到最后一句 assistant 文本，当作完成结果回填抛异常中断整个主 Agent 的运行自动把预算翻倍重试

Q8关于多智能体的代价与级联失败，下列说法正确的是？ token 翻倍（每个 subagent 有自己的 system prompt + 历史，结果还要回填汇总）；延迟受最慢 worker 与编排往返约束；错误可能被主 Agent 洗白进答案多 Agent 一定比单 Agent 便宜，因为工具调用更少级联失败靠「让所有 worker 共用一个 try/catch」解决委派层数没有限制，递归委派越深越好