架构决策训练 — agent/编排类（EX17–EX24）
主题：Workflow or agent、Agent or deterministic code、Single or multi-agent、synchronous or asynchronous、停止条件与编排模式。题目三要素在前，答案在文末。核心依据：Building Effective Agents（https://www.anthropic.com/engineering/building-effective-agents，访问于 2026-08-30）与多智能体研究系统实践（https://www.anthropic.com/engineering/multi-agent-research-system，访问于 2026-08-30）。
EX17 — 日均 5000 份合同审查（★☆☆）
核心张力：Workflow or agent?
Scenario 法务 SaaS 审查供应商合同：流程固定三步——合同分类（NDA/服务协议/采购合同）→ 抽取关键条款（金额/期限/违约条款）→ 按规则库生成风险清单。输入输出模式高度一致，日均 5000 份，夜间批处理为主，单份成本要压到最低。
Constraints
- 步骤固定、可枚举、顺序不变
- 高吞吐、成本敏感
- 输出格式结构化（进下游系统）
Options A. 开放式 agent：给 Claude 合同库访问工具 + 风险规则工具，自主循环完成审查 B. Prompt chaining workflow：三步固定管线（分类 → 抽取 → 风险），每步单次调用 + 结构化输出，Batch API 批处理 C. 单次调用：一个 prompt 完成全部三步 D. 多 agent：分类 agent、抽取 agent、风险 agent 各一个，主 agent 协调
EX18 — 退款审批的灰区判断（★★☆）
核心张力：Agent or deterministic code?
Scenario 平台退款审批：小额（<100 元）走纯规则自动通过；大额（>1000 元）走人审；中间灰区（100–1000 元）需要综合判断——用户历史信用、订单上下文、欺诈信号、政策例外条款。判断需要灵活推理（每个案例的权重不同），但执行退款必须走账务系统固定代码路径。
Constraints
- 灰区判断是真正的开放推理（无法穷举规则）
- 账务执行必须确定性、可审计
- 判断结论要附带理由（供申诉与审计）
- 延迟容忍：分钟级
Options A. 全规则引擎（把灰区也写成规则树） B. Claude 做灰区判断（输入：用户历史/订单/欺诈信号/政策 → 输出：结构化决策 + 理由），确定性代码执行退款与限额，边缘案例升级人审 C. 全交给 agent：给 Claude 账务系统工具，判断完自己执行退款 D. 灰区全走人审
EX19 — 每日并购尽调报告（★★☆）
核心张力：Single or multi-agent?
Scenario 咨询团队每日产出并购尽调摘要：需综合约 40 类信源（财报、监管公告、新闻、行业数据库、内部专家笔记），信源集合动态变化，子课题彼此独立（财务/法务/技术/人力各自成章），信息总量远超单一上下文窗口。单 agent 顺序处理耗时 4 小时且常漏关键信源。报告对客户价值高（六位数合同级）。
Constraints
- 子任务高度并行、彼此独立
- 信息量超单窗口
- 任务价值高，兜得住 token 成本
- 时效有要求（当日出报告）
Options A. 更强的单个 agent + 更大上下文（1M 窗口硬塞） B. Orchestrator-worker 多 agent：主 agent 分解子课题、并行拉起 subagent（各自独立上下文检索压缩）、汇总成稿并决定是否追加研究 C. 固定四路 prompt chaining（财务→法务→技术→人力顺序管线） D. 全部预建 RAG，单次调用生成报告
EX20 — 跨模块代码重构（★★☆）
核心张力：Single or multi-agent?（反例）
Scenario 大型单体仓库的重构：把过时的回调 API 改成 async/await。改动跨 8 个模块，且子任务强依赖——改 A 模块的签名会连锁影响 B/C 的调用点；每个决策都需要共享同一份「当前架构状态」的完整理解。团队想上多 agent 并行加速。
Constraints
- 子任务强耦合、顺序敏感
- 需要持续一致的架构视图（一处改动改变后续所有决策的上下文）
- 错误传播代价高（连锁编译错误）
Options A. 单 agent（长上下文 + 分阶段工具调用），按依赖顺序推进 B. Multi-agent：8 个模块各派一个 subagent 并行重构，主 agent 最后合并 C. Multi-agent + 频繁的上下文同步会议（subagent 互相广播改动） D. 每个模块独立建一个小 agent 团队
EX21 — 十分钟后要的文档摘要（★☆☆）
核心张力：synchronous or asynchronous?
Scenario 内部工具：用户上传会议纪要/长文档，选择「生成摘要并邮件发送」。用户不需要立即看到结果——他提交后就关闭页面去干别的。每天约 3000 次提交，高峰在下午。当前实现是同步等待 API 返回再发邮件，高峰期常超时。
Constraints
- 用户不在线等结果（提交即走）
- 结果十分钟后送达即合格
- 高峰期吞吐压力大
- 成本敏感
Options A. 保持同步，加大超时与并发配额 B. 异步队列 + Message Batches API（提交即入队，批量处理，完成后发邮件） C. 同步但换成最小最快的模型硬扛高峰 D. 限流排队，把高峰流量匀到夜间
EX22 — 实时客服 + 疑难工单分层（★★☆）
核心张力：synchronous or asynchronous?
Scenario 客服系统两层：① 在线对话——用户在聊天窗口等回复，首响 P95 < 5 秒，问题大多是订单状态/政策咨询（RAG 可答）；② 疑难工单——用户提交后接受「24 小时内答复」，需要跨物流/支付/风控系统多步调查，调查步数不可预知。
Constraints
- ①延迟硬约束（秒级）、路径可预测
- ②延迟宽松（小时级）、路径开放（真正的 agent loop）
- ②的执行要受预算与停止条件约束
- 同一套后端工具服务两层
Options A. 全部同步实时处理（①②都用在线 agent loop） B. 分层异步：①同步单次调用（小模型 + RAG + 缓存），未解决时转人工；②入异步队列，agent 带全量工具 + 步数/token 预算慢慢跑，完成后通知用户 C. 全部异步（连在线聊天也排队） D. ①用同步、②也用同步但砍掉工具循环（只做单次 RAG 回答）
EX23 — 研究型 agent 不收敛（★★☆）
核心张力：stopping conditions & budgets
Scenario 深度研究 agent 上线后监控发现：约 8% 的会话超过 30 步工具调用仍不收敛（反复搜索、绕圈、二次验证已有结论），单会话 token 消耗是均值的 6 倍，且最终产出质量并不比 15 步收敛的会话好。当前唯一的「停止机制」是 system prompt 里写了「完成任务后请尽快总结」。
Constraints
- 8% 长尾烧掉大量预算
- prompt 停止引导已存在但无效
- 不能误伤真正的深度任务（有些任务确实需要 25+ 步）
- 需要区分「深度」与「绕圈」
Options A. 加强 prompt 措辞：「绝对不要超过 20 步」 B. 应用层硬约束：最大步数 + token 预算双闸（触顶强制收尾并要求交付当前最优结论）；叠加重复检测（相同工具+相似参数连续出现即注入「你已查过此内容」信号） C. 直接全局砍 max_steps 到 15 D. 换更小的模型（便宜了就不心疼）
EX24 — 千条评论双视角分析（★★☆）
核心张力：parallelization pattern（fan-out/voting）
Scenario 产品团队要分析 1000 条应用商店评论：① 每条做情感分类 + 主题分类；② 最后要统计整体情感分布、Top 主题、以及「情感与主题的交叉结论」。单条评论独立可并行；但逐条调用 1000 次慢且贵，一次全塞又会超窗口且质量下降。
Constraints
- 评论彼此独立（无依赖）
- 需要聚合统计与交叉分析
- 预算：总成本可控、2 小时内出结果
- 分类口径要一致（同一 rubric）
Options A. 单次调用塞全部 1000 条（1M 窗口硬扛） B. Fan-out 分段：按 50 条/批并行调用做分类（结构化输出），确定性代码聚合成统计表，再一次调用做交叉结论分析 C. 1000 次逐条调用 D. 抽样 100 条分析后外推
答案与解析
EX17 — Best choice: B
Why
- 官方第一原则：从最简单的可行方案开始，很多场景单次调用+检索+示例就够；步骤固定可枚举是 workflow 的适用信号（Building Effective Agents：workflows = 预定义代码路径编排 LLM 调用）（来源: https://www.anthropic.com/engineering/building-effective-agents，访问于 2026-08-30）。
- 每步单次调用 + 结构化输出（模块 05）保证输出可进下游系统；夜间批处理走 Batch API 享 50% 折扣（来源: https://platform.claude.com/docs/en/build-with-claude/batch-processing，访问于 2026-08-30）。
Why other choices are weaker
- A：开放式 agent 为不存在的灵活性付延迟/成本/不可预测性——5000 份/日的吞吐下被放大 5000 倍。
- C：单次调用做三件事：分类错误的下游污染、每步无法单独优化与评估、失败重试代价全量。
- D：多 agent 约 15× token 成本（来源: https://www.anthropic.com/engineering/multi-agent-research-system，访问于 2026-08-30）；固定三步根本不需要协调者。
Tradeoffs
- 三步管线的中间格式契约要维护；分类步出错会传播（可加置信度路由到人工）。
What would change the answer
- 合同开始出现开放型问题（需要交叉引用外部判例、多轮推理）→ 局部 agent 化该分支。
- 量降到每天几十份且要求实时交互 → 不必批处理，同步 chaining 即可。
EX18 — Best choice: B
Why
- 灰区判断是真开放推理（规则无法穷举）→ 正是模型判断力的用武之地；账务执行是确定性要求（可审计、不可出错）→ 留在代码。判断与执行分离，各自用最强的工具。
- 结构化输出（决策 + 置信度 + 理由）让判断可审计可申诉——「Claude decides 判断、application decides 执行与限额」正是模块 04 §6 的分界线应用。
- 边缘案例（低置信度/政策空白）升级人审，模型不确定时要能说不知道。
Why other choices are weaker
- A：灰区之所以是灰区，就是规则树覆盖不了——规则引擎会在每个新骗术面前失效。
- C：把不可逆资金操作交给概率组件自主执行（判断+执行不分），审计与合规双双不可接受（模块 04 §6）。
- D：灰区占比高时人审团队被淹没；且放弃了自动化最有的价值区间。
Tradeoffs
- 模型判断需要高质量输入（历史/欺诈信号的取数管线）；判断错误率要靠评估集持续监控（模块 12）。
- 「决策+理由」的结构化输出要设计好 schema（理由质量决定申诉效率）。
What would change the answer
- 灰区占比缩到极小（规则修订后）→ A + 少量人审即可。
- 若监管要求「全自动决策必须可完全解释」且模型理由不达标 → B 的判断层也要换回规则/人审组合。
EX19 — Best choice: B
Why
- 官方多 agent 适用信号全中：开放式任务、步数不可预测、子任务可高度并行、信息量超单窗口、任务价值兜得住成本（orchestrator-worker 正是官方多智能体研究系统的同款架构；并行化最多降低 90% 耗时）（来源: https://www.anthropic.com/engineering/multi-agent-research-system，访问于 2026-08-30）。
- subagent 各自独立上下文天然解决「信息量超窗」——检索结果在 subagent 内压缩后再回传主 agent。
- 信源集合动态 → 主 agent 按当日课题动态分解，不预写死路径。
Why other choices are weaker
- A：1M 硬塞 = context rot + LitM（模块 07），「装下」不等于「用好」；串行速度也没解决。
- C：固定四路管线无法覆盖动态信源与不可预判子课题；且四路本可并行，串行白付 4× 时延。
- D：预建 RAG 覆盖不了「今日公告」类动态信源（索引滞后），单次调用也做不了跨章节综合。
Tradeoffs
- 约 15× token 成本；行为更难预测，需要 LLM-as-judge + 人工抽查评估（官方经验：约 20 条小样本起步）（来源: 同上，访问于 2026-08-30）。
- subagent 间信息不共享是双刃剑：独立性好，但跨章节一致性要靠主 agent 汇总时统一。
What would change the answer
- 信源固定且章节模板稳定 → 退回 C（workflow），成本大降。
- 任务价值降到千美元级 → 15× token 可能不经济，考虑 A 或 C 的混合。
EX20 — Best choice: A
Why
- 多 agent 的官方反边界：不适合子任务强耦合、需要共享上下文的任务（来源: https://www.anthropic.com/engineering/multi-agent-research-system，访问于 2026-08-30）——subagent 各自的上下文副本在强依赖任务里必然漂移。
- 重构的正确模型是「一个连贯的决策流」：单 agent 按依赖顺序推进，上下文里的「当前架构状态」始终一致。
- 并行收益本就不存在（顺序敏感），多 agent 只带来协调与合并成本。
Why other choices are weaker
- B：8 个 subagent 并行改强耦合代码 = 合并地狱 + 上下文漂移（A 模块的新签名在 B 的 subagent 视野里不存在）——错误连锁放大。
- C：同步会议（广播改动）在工程上极其脆弱：通信轮次随 agent 数平方增长，且每轮同步都在烧上下文；这是在手工模拟单 agent 已经免费拥有的东西。
- D：同 B 的病，且更贵。
Tradeoffs
- 单 agent 受上下文窗口限制：超大仓库要配合 compaction/结构化笔记/分阶段提交（官方长程任务技术，模块 08/07）。
- 速度不如真并行的独立任务——但这里没有独立任务。
What would change the answer
- 若重构能切出真正独立的模块（接口边界清晰、无连锁影响）→ 对独立子集可并行 fan-out，主 agent 守接口契约。
- 若任务变为「批量格式化/机械替换」（无判断依赖）→ 确定性代码工具（脚本）而不是任何 agent。
EX21 — Best choice: B
Why
- 官方 Batch 适配定义：不需要立即响应的大批量请求（来源: https://platform.claude.com/docs/en/build-with-claude/batch-processing，访问于 2026-08-30）——「提交即走 + 十分钟后送达」完全命中。
- 50% 计价折扣 + 削峰（队列化吸收高峰）；异步消灭了「高峰超时」这个故障模式本身。
- 邮件本就是异步送达渠道，全链路异步一致。
Why other choices are weaker
- A：为最差的使用模式（同步等不在线的用户）堆资源——超时/并发是症状，同步才是病。
- C：快模型硬扛能缓解延迟，但成本没降（甚至升）、吞吐天花板仍在、质量还降了。
- D：匀峰到夜间违反 SLA（用户要十分钟内邮件）；且夜间批不如 Batch API 直接半价。
Tradeoffs
- 批处理结果多数 <1h 返回但有长尾（24h 上限）；对「十分钟」承诺要么留缓冲话术，要么高峰期转小批量同步兜底。
- 队列系统是新增运维组件（可用托管服务降低成本）。
What would change the answer
- 用户开始要求「提交后页面内立等结果」→ 同步路径回归（那时再谈 A/C 的优化）。
- 单量降到每天几十份 → 队列不值得建，同步+小模型即可。
EX22 — Best choice: B
Why
- 两层的延迟预算与开放度完全不同：①秒级+可预测 → 同步单次（小模型+RAG+缓存），②小时级+开放 → 异步 agent loop。同步/异步的选择跟着延迟预算走，不是跟着技术偏好走。
- ②的全量工具循环必须配预算与停止条件（EX23 的教训前置），异步执行让「慢慢跑对」成为可能。
- 未解决升级路径（①→人工，②→人工）保持人在环。
Why other choices are weaker
- A：②的开放式调查塞进 5 秒首响约束里 = 要么砍工具（做不了），要么砸延迟（用户跑了）。
- C：在线聊天排队 = 用户对着「处理中」转圈，产品体验崩塌。
- D：砍掉工具循环的疑难工单处理 = 名存实亡（单次 RAG 答不了跨系统调查），不如老实告诉用户转人工。
Tradeoffs
- 两层架构两套运维（同步服务 + 异步队列/worker）；工具后端要设计好并发与配额隔离（同步层不能被异步层的重查询拖垮）。
- 工单从①转②的判定（何时放弃实时回答）要调优，误判会让用户重复描述问题。
What would change the answer
- ②的调查模式若后来被摸清（80% 工单是固定五步）→ 大部分转 workflow 化同步处理，只留真开放的长尾走 agent。
- 首响要求放宽到 30 秒 → ①②边界可重新谈判（①可容纳一步工具调用）。
EX23 — Best choice: B
Why
- 官方立场：停止条件必须放在应用层（agent loop 的循环控制是编排代码的职责，不是 prompt 的职责）（来源: https://www.anthropic.com/engineering/building-effective-agents，访问于 2026-08-30）。prompt 引导只是辅助，8% 长尾已经实证它不够。
- 双闸（步数+token）保证最坏情况有界；「触顶强制收尾交付当前最优」保留了长尾会话的价值（不是截断丢弃）。
- 重复检测区分「深度」与「绕圈」：相同工具+相似参数的重复是绕圈信号；真正的深度任务（不同工具、递进查询）不受影响——这正是「不误伤」约束的解。
Why other choices are weaker
- A：prompt 措辞加强是对已失败手段的加码——概率约束兜不住 8% 长尾（且过度抑制可能伤害正常深度任务）。
- C：一刀切 15 步误伤真深度任务（约束明说有些任务需要 25+ 步）；「全局砍」是没有诊断的暴力。
- D：小模型不解决不收敛（甚至更容易绕圈），只是让绕圈便宜点——问题本身还在。
Tradeoffs
- 步数/token 上限的取值需要用历史会话分布校准（如 P95 的 1.5 倍起）。
- 强制收尾的产出质量低于自然收敛——但对比的是「无限烧钱后同样质量的产出」，净赚。
What would change the answer
- 若监控发现重复检测误报率高（把合理复查判为绕圈）→ 调松重复阈值或改用「任务进度自评」注入。
- 若模型/产品迭代后长尾自然收敛到 <2% → 硬闸保留（兜底），重复检测可简化。
EX24 — Best choice: B
Why
- 官方 parallelization 两个用法在此叠用：分段（sectioning）——批量并行处理独立子集；聚合（aggregation）——统计合并交给确定性代码（数数这种事代码比模型可靠且免费）。
- 50 条/批 × 20 批并行：窗口舒适（无 context rot）、分类口径靠同一 rubric + 结构化输出保持一致；交叉结论只在聚合表上做一次分析——上下文小、信号密度高。
- 2 小时预算轻松达标，成本 = 20 次小调用 + 1 次结论调用。
Why other choices are weaker
- A：1000 条硬塞：token 成本最高、LitM 让中部评论被忽略（系统性漏检中段主题）、且统计数字由模型「数」出来不可靠。
- C：逐条调用口径一致性差（1000 次独立采样的方差）、慢、贵（每次都付 system prompt 的重复成本——除非缓存）。
- D：抽样外推牺牲完备性——产品分析要的是「全部负面评论的具体痛点」，抽样直接丢掉长尾洞察。
Tradeoffs
- 批间口径漂移仍可能（20 个批次独立）：用同一 prompt + few-shot + 缓存前缀压住。
- 批内评论互相影响（一条长评可能带偏同批分类）——批次大小是调参点。
What would change the answer
- 若只要方向性结论（正负比）→ D 的抽样够用，成本最低。
- 若评论量到 10 万级 → B 之上再加 Batch API（异步化）与分层抽样。
📚 目录