模块 08 — 架构师问答题

先自己答，再对照讲解。讲解后附来源。

Q1. 用你自己的话说明 workflow 与 agent 的区别，并解释为什么官方把它们统称为 agentic systems。

🎯 学习重点：回答必须落到控制流归属，而不是是否使用工具或模型大小。

讲解要点：分界只有一条——控制流归属。工作流：LLM 与工具经预定义代码路径编排，「下一步做什么」是开发者写死的；智能体：LLM 动态指挥自己的流程与工具使用，「下一步做什么」是模型运行时生成的。统称 agentic systems 是因为两者都以 LLM 为核心引擎、都超出单次调用的范畴，只是自主性档位不同。加分点：官方后续工程文的极简口径「LLMs autonomously using tools in a loop」，以及「agentic 系统常用延迟和成本换任务表现」。 来源: https://www.anthropic.com/engineering/building-effective-agents（访问于 2026-08-30）

Q2. agent loop 的五要素与停止条件分别是什么？为什么停止条件必须放在应用层？

🎯 学习重点：五要素要完整，且要说明模型自我判断不能充当确定性安全边界。

讲解要点：五要素 = 目标、推理、规划、行动 (tool_use)、观察 (tool_result)；agent 每步从环境拿 ground truth 评估进展，可在检查点或遇阻塞时回人类。停止条件：任务完成、最大迭代次数（官方点名）、预算上限、人工检查点、阻塞升级。放在应用层的原因：模型的自我判断不是安全边界——循环控制、权限门、工具执行三样是确定性代码职责（呼应模块 04 的「什么由 Claude 决定、什么由代码决定」），交给模型等于让被监护人持有监狱钥匙。 来源: https://www.anthropic.com/engineering/building-effective-agents（访问于 2026-08-30）

Q3. 逐个说出官方五种编排模式的适用信号，并各举一个「不该用」的信号。

🎯 学习重点：每种模式都要同时给正向适用条件和反向边界条件。

讲解要点：

• Routing：输入类别清晰且分类可靠（客服分流/按难度选模型）；不该用：类别边界模糊或长尾无限类。
• Prompt chaining：任务能干净分解为固定顺序（文案→翻译；大纲→检查→成文）；不该用：步骤依赖运行时发现。
• Parallelization：子任务独立或需多视角（guardrails 分离实例/多 prompt 投票审漏洞）；不该用：子任务强依赖需串行。
• Evaluator-optimizer：清晰评估标准 + 人类反馈可度量改进（文学翻译）；不该用：无客观标准（评估器漂移）。
• Orchestrator-workers：子任务集合不可预知、随输入变化（多文件编码改动、跨信源搜索）；不该用：子任务可静态枚举（那是 parallelization/chaining，更便宜）。

来源: https://www.anthropic.com/engineering/building-effective-agents（访问于 2026-08-30）

Q4. Planner-executor 和 manager-worker 这两个 BEA 没有单列的模式，与官方模式是什么关系？

🎯 学习重点：避免把业界同族叫法误写成 BEA 官方五模式名称。

讲解要点：BEA 官方五模式不含这两个名字。管理者-工人是 orchestrator-workers 的同族叫法（官方定义就是「中央 LLM 分解、委托 worker、综合」）；规划器-执行器是它的「先规划后执行」显式化变体——区分判据是计划是否为静态契约：planner-executor 一次规划照单执行，orchestrator-workers 随环境反馈动态再分解。官方叙事中的对应物：Agent SDK 把「planning its own steps」写进 agent 定义；Claude Code 的 plan-first 工作方式（模块 09）。考试陷阱：别把业界叫法当成 BEA 原文术语引用。 来源: https://www.anthropic.com/engineering/building-effective-agents、https://code.claude.com/docs/en/agent-sdk/overview（访问于 2026-08-30）

Q5. 什么时候 multi-agent 才划算？给出官方的量化依据与反例。

🎯 学习重点：用 90.2%、4×/15×、最多 90% 三组数字解释收益、成本与适用边界。

讲解要点：四个前提同时满足才进入候选：开放式问题（步数不可预测）、子任务可高度并行、信息量超单一上下文窗口、任务价值高到能兜住成本。量化：多智能体架构在内部研究评估中比单 agent 高 90.2%；token 用量一项解释 BrowseComp 方差的 80%（架构本质是规模化 token 投入）；成本 agent ≈ 4× chat、multi-agent ≈ 15×；并行化曾把复杂查询耗时砍最多 90%。反例：需要所有 agent 共享上下文或强依赖协调的任务——多数编码任务；委派指令缺目标/输出格式/边界会导致 subagent 重复劳动。 来源: https://www.anthropic.com/engineering/multi-agent-research-system（访问于 2026-08-30）

Q6. 长时程任务超出上下文窗口，官方给出了哪些记忆/上下文工程手段？

🎯 学习重点：回答三件套并补充 memory tool 的 client-side 与路径穿越防护。

讲解要点：三件套——压缩：窗口逼近上限时摘要重启（保架构决策/未解 bug/实现细节；最轻量是旧工具结果清理）；结构化笔记：agent 把笔记写到窗口外的持久存储再取回；子代理架构：独立上下文窗口分身。产品化：平台 memory tool（memory_20250818）——client-side 执行、/memories 目录、必须做路径穿越防护；设计哲学是及时上下文：平时只留轻量标识符，运行时按需加载，因为 context rot（token 越多召回越差）使窗口成为有限资源。 来源: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents、https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool（访问于 2026-08-30）

Q7. 「为了 agentic 而 agentic」有哪些具体形态？官方的对抗建议是什么？

🎯 学习重点：从过度设计与反向硬编码两侧识别反模式，并回到最简单可行方案。

讲解要点：①复杂度没有可度量的结果改善就加多步 agentic 系统；②用框架抽象层遮住底层 prompt/response，难调试还诱导加复杂度；③步数明明可预测（分类清晰/流程固定）却上开放式 agent；④步数不可预测的研究任务却硬编固定 pipeline（反向反模式）。对抗建议：先找最简单的可行方案（单次调用+检索+示例常常就够）；API 直起步（许多模式几行代码）；用框架必须理解底层；「只在能证明改善结果时才增加复杂度」；持续测量再迭代。 来源: https://www.anthropic.com/engineering/building-effective-agents（访问于 2026-08-30）

Q8. 2026 年自建 agent loop 与用 Claude Managed Agents 的选型口径是什么？Managed Agents 的架构观对自建者有什么可迁移的启发？

🎯 学习重点：比较控制粒度与托管便利，并说清 session、harness、sandbox 三个接口。

讲解要点：官方口径——Messages API：自定义 agent loop、细粒度控制；Managed Agents（beta，header managed-agents-2026-04-01）：托管 harness + 沙箱 + session，适合长时程/异步、不想自建基础设施（注意：暂不适用 ZDR/BAA）。可迁移启发：把 agent 虚拟化为 session / harness / sandbox 三个可独立替换的接口；「session ≠ 上下文窗口」（事件日志可回放、可按位置切片取回）；brain 与 hands 解耦（容器从 pet 变 cattle，工具失败即 tool-call error 回传重试）；凭证永远不可从沙箱触达（git token 初始化时注入、MCP 凭证走 vault+代理）——这条对任何自建 agent 系统都是安全红线。 来源: https://platform.claude.com/docs/en/managed-agents/overview、https://www.anthropic.com/engineering/managed-agents（访问于 2026-08-30）