模块 08 — 考试题型（Exam Style）

题干中文、考试术语保持英文。答案与逐项解析在文件末尾「答案与解析」独立小节。 场景题 S1–S4 均为 workflow vs agent / 编排模式选型 决策题，采用八要素格式。

单选题

🎯 学习重点：先锁定官方术语与唯一判据，再排除把工具、模型大小或部署形态当分界的干扰项。

1. 按 Building Effective Agents 的官方定义，workflows 与 agents 的分界是：

A. 是否接入了外部工具 B. 是否使用了更大的模型 C. 控制流是预定义代码路径还是由 LLM 动态指挥 D. 是否运行在云端

1. 官方对 agent 的极简定义（后续工程文口径）是：

A. LLMs autonomously using tools in a loop B. 任何带 RAG 的对话系统 C. 多个 LLM 投票达成一致的系统 D. 能自主微调自己权重的系统

1. 以下哪一项不是 agent loop 的标准组成要素？

A. Goal B. Reasoning / Planning C. Action（tool_use）与 Observation（tool_result） D. 自动降低模型 temperature

1. 官方建议 agent 必须配置的 stopping condition（并举例如 maximum number of iterations）是为了：

A. 提高输出质量 B. 在任务完成之外维持对开放式循环的控制 C. 让模型学会提前结束回答 D. 满足 rate limit 要求

1. Routing 模式的官方例子不包括：

A. 客服查询按类型分流入不同下游流程 B. 常见问题路由给更便宜的模型、疑难路由给更强模型 C. 把任务分解为「写大纲→检查→成文」的固定序列 D. 为不同类别构建各自专用的 prompt 与工具集

1. Prompt chaining 的核心权衡是：

A. 用更多 token 换更低延迟 B. 用延迟换准确率（每次调用都变成更简单的任务） C. 用安全性换灵活性 D. 用上下文窗口换工具数量

1. Orchestrator-workers 与 parallelization 的关键区别是：

A. workers 是否使用工具 B. 子任务是否预定义（前者由 orchestrator 按输入动态分解） C. 是否使用 subagent D. 前者只能用于编码任务

1. 按官方数据，multi-agent 系统的 token 消耗约为普通 chat 的：

A. 相同（1×） B. 4× C. 15× D. 100×

场景决策题（八要素格式）

🎯 学习重点：每题先标注步骤是否可预测、子任务是否独立、价值是否覆盖额外成本。

S1. 客服全量分流

🎯 学习重点：高频简单流量走最简路径，不可逆退款走固定 gate，只有开放长尾升级 agent。

• Scenario：你在为电商构建客服系统。流量构成：约 80% 是订单状态/退换货政策类高频简单咨询；15% 是需要查询订单并执行退款操作的请求；5% 是跨物流/支付/风控多系统的疑难投诉。全部会话平均要求 P95 首响 < 30 秒。团队已有准确率 98% 的意图分类器。
• Constraints：高流量、成本敏感；退款是不可逆资金操作；P95 延迟预算紧；分类器现成。
• Options：

A. 单个开放式 agent 带全套工具（订单/退款/物流/风控）处理全部流量 B. Routing 分类：高频简单类走单次调用（小模型）；退款类走固定步骤 workflow（含人工审批 gate）；疑难类升级为带停止条件的 agent C. 全量 prompt chaining：先生成回复草稿再润色 D. multi-agent：主 agent 动态拉起退款/物流/风控 subagent 处理每个请求

• Best choice：B
• Why：任务按类别清晰可分（routing 的官方适用信号）；高频简单流量用「最简单可行方案」（官方第一原则：很多应用单次调用+检索+示例就够）；不可逆操作留在确定性 workflow + 人审 gate 里；只有真正开放式的 5% 才配 agent。延迟与成本可预算。
• Why others are weaker：A——80% 流量为简单问题也跑多轮循环，延迟/token 双高、路径不可测，且不可逆操作暴露给全量流量；C——chaining 解决的是「固定顺序分解」的任务，与按类别分流的需求不匹配；D——官方口径 multi-agent 约 15× token，且需共享订单上下文的任务不适合多 agent，成本完全失控。
• Tradeoffs：B 引入三条路径的维护成本与分类错误的风险（错分到简单类的退款请求需要二次升级机制）；换来可预测性、成本可控与人审合规。
• What would change the answer：若简单类占比降到 30% 以下、且多数请求需要跨系统即席推理（步数不可预测），则 agent 主体化才划算；若 P95 放宽到分钟级且任务价值极高，D 可重新评估。

S2. 跨 50 个信源的行业研究报告

🎯 学习重点：开放、可并行、超单窗口且高价值四项同时满足，才支持 multi-agent。

• Scenario：咨询团队需要每周产出 AI 编码助手行业研究报告：需综合官网、新闻稿、论文、监管公告等约 50 类信源，信源集合每周变化，重要主题不可预判。单份报告对客户价值高（五位数美元级）。此前用「单 agent 顺序搜索」耗时数小时且常漏关键信源。
• Constraints：信息量远超单一上下文窗口；任务价值高；信源间彼此独立；报告有明确的质量评审维度（覆盖度/信源质量/引用准确）。
• Options：

A. Prompt chaining：固定「查市场→查技术→查风险」三步 pipeline B. Evaluator-optimizer：生成器写报告、评估器按 rubric 打分循环精修 C. Multi-agent（orchestrator-worker）：主 agent 动态分解查询、并行拉起 subagent（各自独立上下文做压缩）、汇总后决定是否追加研究 D. 单次调用 + RAG 预检索全部信源

• Best choice：C
• Why：开放式问题 + 步数不可预测 + 子任务可高度并行 + 信息量超单窗口 + 高价值兜得住成本——五项条件同时满足，正是官方多智能体研究系统的同款架构（orchestrator-worker pattern）；subagent 的独立上下文天然解决「搜索的压缩」问题。
• Why others are weaker：A——固定 pipeline 无法覆盖不可预判的主题，路径写死即漏报；B——精修环节值得做但只解决「写得好」不解决「查得全」，更适合作 C 的内嵌组件；D——50 类动态信源无法靠预检索静态覆盖，且单窗口装不下。
• Tradeoffs：约 15× token 成本、行为更难预测、评估要用 LLM-as-judge + 人工抽查（官方经验：约 20 条小样本起步即可）；换来覆盖度与并行速度（官方同款架构报告复杂查询耗时最多降 90%）。
• What would change the answer：若信源集合固定且报告模板稳定（步数可预测），退回 A/B 组合的 workflow 即可；若任务价值降到几百美元，15× token 可能不经济，考虑 B。

S3. 文学翻译精修

🎯 学习重点：清晰 rubric 与有效反馈是 evaluator-optimizer 的两个决定性信号。

• Scenario：出版社要把一部小说译成中文。初译常丢语气与双关；编辑反馈（「这里要更口语」「这个双关要保住」）总能显著改进译文；社内有一套明确的翻译质量标准（信达雅 rubric + 术语表）。
• Constraints：任务步骤固定（初译→评审→修改）；无并行子任务；有清晰评估标准；人类反馈可度量地改进输出。
• Options：

A. Evaluator-optimizer：翻译 LLM 生成，评估 LLM 按 rubric 给反馈，循环精修 B. Multi-agent：主 agent 拉起 10 个翻译 subagent 各译一章再拼合 C. 开放式 agent 带词典/语料工具自主决定翻译流程 D. 单次调用：一次性给出译文

• Best choice：A
• Why：官方给的两个适用信号全中——①有清晰评估标准；②人类 articulated 的反馈能显著改进输出、且 LLM 能提供这种反馈。文学翻译正是 BEA 官方原例。
• Why others are weaker：B——章节间语气一致性要求共享上下文，多 agent 各译一章风格会割裂；且该任务无可并行收益；C——流程其实固定可枚举，开放式 agent 是拿延迟成本换不需要的灵活性；D——无精修回路，丢语气问题无解。
• Tradeoffs：循环有轮数上限（设 2–3 轮），延迟随轮数线性上升；评估器质量依赖 rubric 维护。
• What would change the answer：若改为「多语种同时出版」，各语种彼此独立，可升级为按语种并行的 parallelization + 每语种内嵌 A。

S4. 内部文档问答

🎯 学习重点：答案已在索引且无需多步动作时，单次 augmented LLM 优先于任何 agentic 编排。

• Scenario：公司要让员工查询内部规章制度（约 2 万篇文档，更新频繁）。需求就是「问什么答什么，附出处」。没有多步操作、没有跨系统动作、答案就在文档里。
• Constraints：日查询量大；延迟敏感；文档已有向量索引。
• Options：

A. Multi-agent 研究系统（主 agent + 多个检索 subagent） B. 单次 augmented LLM 调用 + RAG 检索 + few-shot 示例 C. 开放式 agent 带文档工具自主多轮探索 D. Prompt chaining：先检索再生成再校对的三步链

• Best choice：B
• Why：BEA 官方第一原则——找最简单的可行方案，很多应用「单次 LLM 调用 + 检索 + 上下文内示例」就够。任务步数固定为一，任何编排都是预支复杂度。
• Why others are weaker：A——15× token 成本为零收益，还引入不可预测路径；C——开放式循环解决的是「步数不可预测」，此处步数恒为一；D——三步链把延迟扩大三倍，仅当单次检索质量不达标（需要 rerank/校验环节）才考虑。
• Tradeoffs：B 的上限取决于检索质量（模块 07 的 RAG 工程）；若日后出现「对比多制度并给出操作建议」类复合问题占比上升，再沿决策阶梯升级。
• What would change the answer：文档间强冲突需要多轮取证仲裁、或需要联动工单系统执行动作时，C（agent）重新进入考虑；查询价值极高且需要广度覆盖时 A 才可能划算。

答案与解析

🎯 学习重点：复盘时不仅记正确项，还要能指出每个干扰项违反了哪个边界条件。

单选题答案

🎯 学习重点：先独立作答再核对，错误题回链到 README 的定义或数字来源。

逐项解析

🎯 学习重点：重点复述 workflow/agent、chaining、orchestrator-workers 与 multi-agent 的精确判据。

1. C。官方定义：workflows = LLMs and tools orchestrated through predefined code paths；agents = LLMs dynamically direct their own processes and tool usage。A 错——workflow 也可以用工具；B 无关；D 无关。（来源: Building Effective Agents，访问于 2026-08-30）

2. A。「LLMs autonomously using tools in a loop」，出自 effective context engineering 与 multi-agent research system 两篇官方工程文。B/C/D 均非官方定义。

3. D。五要素是 Goal / Reasoning / Planning / Action / Observation；temperature 调节是采样参数（模块 01），不是 loop 组成。

4. B。原文明说任务常在完成时终止，但「it's also common to include stopping conditions (such as a maximum number of iterations) to maintain control」——目的是对开放式循环保持控制。A/C 是混淆项，D 与 rate limit 无关。

5. C。「写大纲→检查→成文」是 prompt chaining 的官方例子。A、B、D 均为 routing 的官方描述（分类后分流、按难度路由到不同成本/能力的模型、各类专用 prompt 与工具）。

6. B。官方原话：chaining 的主要目标是「trade latency for higher accuracy」。A 反了；C/D 无关。

7. B。原文明说 orchestrator-workers 与 parallelization 拓扑相似，关键区别是灵活性——子任务不是预定义的，由 orchestrator 按具体输入决定。A/C 不是区分点，D 过窄（搜索任务同样适用）。

8. C。官方数据：agent 平均约 4× chat，multi-agent 约 15× chat。B 是单 agent 的倍数（干扰项）。

场景题解析

🎯 学习重点：把每个答案压缩为「场景特征 → 模式 → 代价 → 改判条件」四步论证。

S1 → B。考点：routing 的适用信号（类别清晰 + 分类可靠）+ 决策阶梯第一原则 + 不可逆操作的人审 gate。错误选项的命门：A 违反「最简单可行方案」且成本延迟双失控；D 在需共享上下文的任务上用 multi-agent（官方点名不适合）且 15× 成本。

S2 → C。考点：multi-agent 的四个前提（开放式、可并行、超单窗口、高价值）与 orchestrator-worker 实战架构；A 的硬编 pipeline 覆盖不了不可预判主题。注意 B（evaluator-optimizer）常作为 C 的内嵌组件出现——「为什么 B 单独不够」是高频追问。

S3 → A。考点：evaluator-optimizer 的两个官方适用信号；multi-agent 在「需共享上下文/语气一致」任务上是反模式。

S4 → B。考点：决策阶梯第一步——不上 agentic 系统本身就是选项。错误选项全是「为了 agentic 而 agentic」的典型姿势。

（全部场景的判定依据均来源: https://www.anthropic.com/engineering/building-effective-agents 与 https://www.anthropic.com/engineering/multi-agent-research-system（访问于 2026-08-30））