外观
多 Agent、Memory 与 Loop 专项面试题
目录
1. 使用说明
- 对应知识主题：多 Agent、Memory 与 Loop；
- 角色：资深面试官从概念边界追问到协作拓扑、Memory 生命周期、嵌套 Loop 和项目评测，高级技术应聘者负责给出可验证回答；
- 回答顺序：先说 30 秒专业短答，再展开机制与工程证据，最后用急诊会诊场景给小白解释并指出类比边界；
- 技术选型单一事实源：L4、L6 和 L7 引用主文档的
TP-MAL-*技术清单、横向对比、架构图和技术调用流程图，不复制整套表格； - 事实纪律：多 Agent 不保证更强，Memory 不等于聊天历史，模型的完成信号不等于 Runtime 验收通过；
- 题目数量：7 题，严格覆盖 L1～L7。
事实红线｜ 本题库中的生产事故调查系统是示例设计，仓库没有真实上线指标；框架动态能力以主文档列出的 2026-07-14 官方资料为边界。
阅读图例｜
L1～L2概念与边界 ·L3～L4原理与实现 ·L5工程 ·L6架构 ·L7项目复盘答案层级｜ 必答结论 · 机制展开 · 小白解释 · 评分信息 · 下一问
2. 递进路线
图：多 Agent、Memory 与 Loop 的 L1～L7 递进路线
替代文本： 面试从多 Agent 的定义开始，依次区分 State、Context 与 Memory，解释嵌套 Loop，再落到 Task、Artifact 和 Memory Schema；之后排查循环风暴与记忆污染，比较协作拓扑，最后用生产事故调查示例完成项目复盘。
图表加载中…
读图结论： 这组题不是从“用了几个 Agent”一路背到框架 API，而是先划清责任与信息边界，再验证循环能否收敛，最后用受控基线证明架构价值。
每一题承接上一题：L1 先证明系统是否真的需要多个决策边界，L2 决定信息放在哪里，L3 决定信息怎样推动状态，L4 将机制变成可校验契约，L5 用故障暴露控制面漏洞，L6 比较架构代价，L7 才允许讲项目亮点。
图：多 Agent 的任务、Memory 与终止责任链
替代文本： Orchestrator 把目标和预算变成 Task Envelope；Worker 在独立 Loop 中经工具产生 Observation 和 Artifact；Verifier 校验证据与冲突；Runtime 决定继续、暂停或终止；成功后只提交经过验证的 Memory 候选，失败时保存 Checkpoint 和未知项。
图表加载中…
读图结论： Worker 可以建议动作和完成，Orchestrator 可以追加任务，但只有 Runtime 与 Verifier 共同满足预算、安全和结果断言时才算真正结束；长期 Memory 写入位于验收之后。
回答任何一题都可以回到这条责任链：目标由谁持有，任务怎样约束，Observation 怎样形成 Artifact，冲突怎样验证，Memory 在何时提交，以及谁能强制停止。
3. 一问一答
第 1 题｜L1 概念｜什么才算多 Agent，它与一个 Agent 调多个工具有什么区别？
核心考察点｜独立决策边界、协作协议、共同验收与伪多 Agent
面试官提问
不要按“有几个角色名”回答，请从上下文、权限、循环和产物边界说明。
30 秒专业短答
多 Agent 至少包含两个可独立运行决策循环的 Agent，它们具有可区分的指令、上下文、工具、权限或 State，并通过显式协议共同完成一个目标。一个 Agent 连续调用多个工具仍是单 Agent，因为决策责任和 Loop 没有拆开；同一模型生成多段角色意见也不自动构成多 Agent。是否拆分要看可并行性、上下文隔离、专门权限和独立验证是否能覆盖协调成本，而不是看角色数量。
深入展开
我会用三个门槛判断。第一，Worker 是否拥有独立输入和局部验收，而不是复制同一 Prompt；第二，任务、结果、控制权和失败是否通过 Task/Result Envelope、Artifact 或 Handoff 明确传递；第三，是否有 Orchestrator 或其他责任主体对总目标收口。如果只有多个普通函数或并行工具，更准确的是 Workflow；如果多个同源采样简单投票，更接近 Self-Consistency，不能把多数意见当成外部事实。
小白解释
一名医生同时使用听诊器、心电图和血压计，仍是一名医生在用多个工具；只有心内科、药师等分别获得任务、独立检查并提交会诊单，才像多 Agent。医生人数对应 Agent 数量，会诊单对应协作协议，主治医生最终签字对应共同验收；但真实医生有专业资质，模型角色不因此自动获得独立真相。
事实与证据边界
多 Agent 是架构组织方式，不是质量保证。应在同模型、同工具、同权限和同总预算下与单 Agent 或固定 Workflow 对比，不能用一次 Demo 推导普遍优势。
- 合格线｜ 说清独立 Loop、边界、协议和最终责任；
- 加分项｜ 区分角色化 Prompt、并行工具、Self-Consistency 与真正多 Agent；
- 高频误区｜ 认为 Agent 越多准确率越高，或只要有三个角色名就是多 Agent；
- 下一问｜ Agent 边界明确后，多个参与者之间哪些信息应进入 State、Context 或 Memory？
第 2 题｜L2 边界｜State、Context、Checkpoint、Event Log、Memory 和知识库怎样区分？
核心考察点｜信息用途、生命周期、恢复、复用、审计与知识治理
面试官提问
为什么不能把全部聊天历史向量化后统称长期 Memory？
30 秒专业短答
State 保存当前可恢复的结构化执行事实，Context 是本轮模型可见的有限视图，Checkpoint 是某一步的恢复快照，Event Log 记录发生过什么，Memory 是经过选择和治理、可在以后复用的信息，知识库则是组织认可且独立治理的外部知识。全量历史同时包含噪声、推测、隐私和过期内容，向量化只解决相似检索，不会自动提供来源、作用域、TTL、纠错、删除和 ACL，因此不能等同长期 Memory。
深入展开
多 Agent 还要区分
agent_private、run_shared、user/tenant和global作用域。Checkpoint 解决“进程重启从哪里继续”，Store 解决“跨 Run 要复用什么”，Event Log 解决“为何变成现在的 State”。Memory Item 至少需要来源、类型、作用域、置信依据、状态、版本、过期时间、取代关系和 ACL；强制规则应进入版本化配置、策略或测试，而不是只写进 Memory。
小白解释
会诊时，当前生命体征是 State，医生桌上的本轮资料是 Context，抢救到某一步的记录是 Checkpoint，完整监控记录是 Event Log，经确认的药物过敏史是 Memory，医院正式诊疗指南是知识库。把走廊里的每句讨论都存进病历，会把猜测和隐私变成长期负担；类比忽略了数字系统还需要租户 ACL、版本和删除传播。
事实与证据边界
LangGraph 官方文档把线程级 Checkpointer 与跨线程 Store 区分开，这是一个当前框架实现示例，不是所有系统必须采用的唯一存储方案。
- 合格线｜ 六类信息的用途和生命周期无混淆；
- 加分项｜ 提到 Namespace、来源、TTL、取代、撤权、纠错和删除；
- 高频误区｜ 把 Context 当数据库，把 Checkpoint 当长期知识，或认为有向量库就有 Memory；
- 下一问｜ 信息分层之后，解释单 Agent 内循环、多 Agent 外循环和 Memory 整理循环怎样推进与停止。
第 3 题｜L3 原理｜多 Agent 系统里有哪些 Loop，谁决定继续与终止？
核心考察点｜Worker 内循环、Orchestrator 外循环、Memory 整理循环与分层预算
面试官提问
请给出动作、Observation、State 转移、全局预算和软硬终止。
30 秒专业短答
单个 Worker 内部运行“模型动作、工具执行、Observation、State 更新”的内循环；Orchestrator 运行任务分解、调度、合并和追加工作的外循环；任务完成后还可能有 Memory 候选提取、验证、合并和过期的整理循环。模型的
DONE只是软信号，Runtime 必须用总步数、时间、Token、费用、并发、重复动作、权限、未决任务和最终结果断言硬终止，而且总预算必须向所有子 Loop 分配并汇总。
深入展开
我会把状态转移写成
s_{t+1}=T(s_t,a_t,o_t)，由确定性代码校验动作和 Observation 后更新。Orchestrator 不能每次 Worker 失败就无限新建 Agent，而要先分类可重试、不可重试和结果未知；Worker 的局部“有进展”也必须对应全局未决任务减少。Memory 写入应在最终验收后产生候选，否则中间假设会跨会话污染未来决策。
小白解释
每个专科医生会反复“检查、看结果、决定下一项”，这是 Worker 内循环；主治医生会“分诊、收会诊单、发现缺口再补查”，这是外循环；事后把确认经验写入病历规范，是 Memory 整理循环。医生说“我查完了”不等于会诊结束，系统还要看关键检查是否齐全和抢救时间是否超限。
事实与证据边界
OpenAI Agents SDK 官方 Runner 文档公开了模型、工具、Handoff 与
max_turns的循环语义；本文的费用、重复动作和全局预算传播属于应用侧工程控制，具体阈值必须实测。
- 合格线｜ 三层 Loop、State 转移、软硬终止和预算传播；
- 加分项｜ 说明取消传播、无进展检测、结果未知和 Memory 延迟提交；
- 高频误区｜ 只给 Worker 配
max_steps，却没有 Orchestrator 总预算； - 下一问｜ 循环原理清楚后，怎样用 Schema 和 Runtime 把它实现为可测试系统？
第 4 题｜L4 实现｜多 Agent Runtime 最少需要哪些数据结构和控制？
核心考察点｜Task/Result/Memory/Checkpoint Schema、Artifact、版本和幂等
面试官提问
请落到可实现字段，不要只说“加一个调度器和数据库”。
30 秒专业短答
Runtime 至少需要四类契约：Task Envelope 定义目标、输入、输出 Schema、工具权限、截止时间和局部预算；Result/Artifact 记录结构化结果、来源、版本、未知项和状态；Run State/Checkpoint 保存未决任务、父子预算、动作指纹和终止原因；Memory Item 保存作用域、类型、来源、置信依据、TTL、版本、取代关系和 ACL。控制面还要有工具白名单、超时取消、错误分类、幂等键、乐观并发、Verifier、Trace 与最终结果断言。
深入展开
主文档的
TP-MAL-PROTOCOL选择结构化 Envelope + Artifact，而不是自然语言消息承载关键字段；TP-MAL-MEMORY将 Checkpoint、Scoped Store 与 Event Log 分层；TP-MAL-LOOP使用确定性状态机和分层预算。共享 Artifact 写入要带expected_version，版本不匹配时重新读取或进入冲突队列；带副作用工具要带稳定call_id和业务幂等键，超时后先查外部状态。
小白解释
会诊不能只靠口头说“去查一下”，而要有检查单、结果单、病程快照和正式病历。检查单对应 Task，结果单对应 Artifact，病程快照对应 Checkpoint，确认后的过敏史对应 Memory；单号和版本能防止重复检查或覆盖新结果。类比没有展示真实系统的 Schema 演进和跨服务事务。
事实与证据边界
这些字段是框架无关的生产参考，不是某个 SDK 的强制接口。OpenAI Agents SDK、LangGraph 和 AutoGen 可以承载其中一部分能力，仍需应用侧补齐业务权限、幂等、Schema 和验收。
- 合格线｜ 四类结构、权限、预算、版本、幂等、Verifier 和 Trace；
- 加分项｜ 提到 Artifact 引用、乐观锁、Event 重放与 Schema 兼容；
- 高频误区｜ 让 Agent 用自然语言互传所有控制字段，或把共享 Python 字典当生产 State；
- 下一问｜ 实现完成后，如何定位 Loop Storm、Memory Poisoning 和 Handoff 信息丢失？
第 5 题｜L5 工程｜系统调用暴涨且答案反复跑偏，怎样区分 Loop、Memory 和 Handoff 故障？
核心考察点｜止损、版本固定、首次失败层、故障闭环与防复发
面试官提问
请按现象、影响、证据、根因、止损、修复、验证和监控回答。
30 秒专业短答
我先按
run_id取消异常 Run、限制新任务并固定模型、Prompt、拓扑、工具、Memory 和预算版本。随后按任务分解与 Handoff 输入、Memory 候选和实际注入、Worker 动作与 Observation、Artifact 合并、父子预算与终止原因逐层找首次异常：重复动作和错误重派更像 Loop，错误或跨租户内容被稳定召回更像 Memory，交接后缺关键约束或重复询问更像 Handoff。修复后用原失败轨迹和注入样本重放，同时验证质量、调用数、延迟、费用和泄漏。
深入展开
Loop Storm 常见根因是可重试分类错误、全局预算未向子任务传播或“结果未知”被当成失败；Memory Poisoning 要追
memory_id -> source run -> writer -> verifier -> usages，先冻结 Namespace，再纠错和传播删除；Handoff 丢失要做交接前后 Context Diff，检查必填字段、Artifact 引用和服务端权限。长期修复分别是分层预算与无进展检测、两阶段 Memory 提交、结构化 Handoff 契约与保真回归集。
小白解释
会诊室突然不停开检查单，可能是主治医生没收到“已检查”的回报，这是 Loop；也可能病历里写了错误过敏史，每个人都据此判断，这是 Memory；还可能换班时漏说“病人禁用某药”，这是 Handoff。先停下新增检查，再查记录首次在哪一步错，不能只换一个更资深医生继续猜。
事实与证据边界
这是一套排障方法，不代表仓库发生过真实事故。具体告警阈值应从任务基线和容量预算得到，不能直接照抄固定数字。
- 合格线｜ 先止损，固定版本，沿三条链路找首次失败并重放；
- 加分项｜ 动作指纹、Memory 使用链、Context Diff、删除传播和未知结果对账；
- 高频误区｜ 第一反应是加 Critic Agent、加 Prompt 或换模型；
- 下一问｜ 故障边界清楚后，怎样选择 Manager、Handoff、Group Chat 或保持单 Agent？
第 6 题｜L6 架构｜Manager-as-Tool、Handoff、Group Chat 与单 Agent 怎样选？
核心考察点｜控制权、上下文、并行性、责任、成本和切换条件
面试官提问
请给出适用、不适用和受控切换标准，不要回答“看业务复杂度”。
30 秒专业短答
路径稳定且副作用高时优先固定 Workflow；任务开放但单一上下文和权限足够时优先单 Agent。子问题可独立并行、需要上下文或权限隔离且最终责任应集中时选 Manager-as-Tool；需要专家持续接管用户对话时选 Handoff；只有参与者必须多轮互相回应、协商或批评时才用 Group Chat。切换必须用同模型、同工具、同权限和同总预算的任务集证明最终成功、墙钟时间或安全收益覆盖 Token、延迟、冲突和可观测成本。
深入展开
主文档
TP-MAL-TOPOLOGY默认采用 Manager + Worker + Verifier，因为它能最小化共享 Context 并保留最终 Owner。Handoff 要测试历史过滤、控制权回退和每个工具的 Guardrail；Group Chat 要限制发言轮次、选择器、共享历史增长和终止条件。AutoGen 官方 Teams 文档也建议先优化单 Agent，单 Agent 不足时再进入 Team，这只能作为工程建议来源，最终仍由本项目基准决定。
小白解释
固定挂号流程用办事指南，普通病症可由一位医生处理；多个检查能并行但主治医生要负责时用会诊 Manager；病人转到专科长期治疗是 Handoff；只有诊断确实需要多科反复讨论才开 Group Chat。会诊人数增加会带来排队和沟通成本，不能只看“专家更多”。
事实与证据边界
OpenAI Agents SDK 和 AutoGen 的官方资料能证明这些模式有公开实现，不能证明任一模式在用户项目中更优；框架版本、API 和默认行为发布前需重新核对。
- 合格线｜ 四种形态的控制权、上下文、适用边界和成本清楚；
- 加分项｜ 给出可测的切换条件，并提到总预算而非单 Agent 预算；
- 高频误区｜ “复杂任务就上多 Agent”，或把 Group Chat 当默认高级架构；
- 下一问｜ 最后用事故调查示例说明个人决策、故障闭环和真实证据边界。
第 7 题｜L7 项目复盘｜怎样设计并证明一个生产事故调查多 Agent 系统？
核心考察点｜业务约束、架构决策、Memory 治理、故障演练、评测和证据边界
面试官提问
请用“目标角色、约束难点、决策亮点、生产排障、验证证据、经验演进”回答，并说明现在能否声称效果提升。
30 秒专业短答
这是主文档中的示例设计：Orchestrator 根据告警拆出证据、变更和风险任务，多个只读 Worker 并行查询日志、指标与发布记录，用 Artifact ID 和来源交付结果，Verifier 检查时间窗、证据支持与冲突，Runtime 管理父子预算、Checkpoint、取消和终止；事故经验只有人工复盘或规则验收后才进入长期 Memory。它的亮点需要在同一脱敏事故集上与单 Agent 比较 End-State Success、Evidence Support、错误时间窗、危险建议、墙钟时间和成功 Run 成本；当前仓库没有实现和实测，所以不能声称效率或准确率提升。
深入展开
最难的不是并行查三个系统，而是在数据源时区、版本和权限不同的条件下同时保证证据一致与只读安全。我选择 Manager-as-Tool 而非自由群聊，因为调查任务可按证据域分解且最终责任必须集中；操作建议与执行 Workflow 分离，避免 Agent 直接变更生产。故障演练中，如果两个 Agent 使用不同时区却被合并成错误因果，我会先标记报告未验证、关闭自动建议，再根据 Artifact 时间窗和 Verifier Trace 定位；长期增加 UTC、显式时区和区间重叠校验，并重放夏令时、延迟日志和回滚样本。
小白解释
主治医生让不同科室并行检查，但每份结果都带时间、来源和签名；药物过敏史只有复盘确认后才进正式病历。若两张检查单时区不同，不能因为都写着“十点”就认定先后关系。这里的病历、会诊单和主治签字分别对应 Memory、Artifact 和 Verifier，但模型没有医生执照，最终生产操作仍需真实审批人负责。
事实与证据边界
目前只有设计、Schema、双图、最小控制代码和故障演练证据，没有真实系统、用户、事故和基准结果。下一步应实现只读原型，构建脱敏历史事故集，再进行单 Agent、多 Agent 无 Memory、多 Agent 有治理 Memory 的受控对比。
- 合格线｜ 背景、角色、约束、决策、故障闭环、指标和未验证边界完整；
- 加分项｜ 时间窗一致性、只读权限、Artifact 版本、End-State 评测和三组消融；
- 高频误区｜ 虚构效率提升，或把多个 Agent 的一致结论当成真实证据；
- 下一问｜ 本组题结束；后续可进入 Durable Workflow、事件溯源、分布式幂等和多 Agent 安全红队。
4. 自测与评分
4.1 自测清单
- [ ] 不看文档，用 30 秒区分多 Agent、单 Agent 多工具和固定 Workflow；
- [ ] 为 State、Checkpoint、Event Log、Memory 和知识库各写三个字段；
- [ ] 画出 Worker 内循环、Orchestrator 外循环和 Memory 整理循环；
- [ ] 设计 Task、Result、Artifact 和 Memory JSON Schema；
- [ ] 注入 Loop Storm、跨租户 Memory、Handoff 漏字段和并发覆盖；
- [ ] 用相同总预算比较单 Agent、Manager 和 Group Chat；
- [ ] 项目复盘主动声明“示例设计”与下一步取证计划。
4.2 五维评分
| 维度 | 1 分 | 3 分 | 5 分 |
|---|---|---|---|
| 准确性 | 把多个角色等同多 Agent | 基本区分拓扑和 Memory | 概念、控制权、信息和终止边界严谨 |
| 原理深度 | 只讲框架 API | 能解释 Action/Observation | 能解释嵌套 Loop、State 转移和冲突一致性 |
| 工程意识 | 只写 Prompt | 有超时、重试和存储 | 有幂等、版本、ACL、预算传播、Trace 与故障注入 |
| 项目表达 | 泛称“提升效率” | 有示例架构和指标 | 有基线、消融、失败闭环和证据边界 |
| 沟通结构 | 名词堆砌 | 能按流程讲 | 30 秒结论前置，追问再展开，最终用条件收口 |
建议合格线为 18/25。若准确性或工程意识低于 3 分，即使总分达到 18，也应先复习主文档的概念边界与生产问题章节。
5. 事实边界与参考资料
- 单一事实源：多 Agent、Memory 与 Loop；
- 前置：Agent 核心机制与Agent 工程化与安全；
- 主文档引用 OpenAI Agents SDK Running Agents/Handoffs、LangGraph Persistence、AutoGen Teams、Anthropic Multi-Agent Research 与 ReAct 论文；
- 动态框架能力的访问日期为 2026-07-14，面试或实施前应再次核对版本和 API；
- 所有“更适合”结论都以相同任务、模型、工具、权限、预算和验收条件为前提。
当前无法确认｜ 示例事故调查系统的真实实现、用户规模、成功率、延迟、成本、Memory 准确率和业务收益。
6. 总结
一句话记忆： 多 Agent 是否成立看协作边界，Memory 是否可靠看信息生命周期，Loop 是否可用看 Runtime 能否让状态在预算内收敛到可验收终点。
- 多个角色、工具或采样不自动等于多 Agent；
- Context 是本轮视图，Checkpoint 用于恢复，Memory 是受治理的跨任务复用信息；
- Worker、Orchestrator 和 Memory 整理各有 Loop，预算必须分层传播；
- Manager、Handoff 和 Group Chat 的核心差异是控制权、上下文和责任；
- 面试项目必须给出基线、Schema、Trace、故障闭环和未验证边界，不能只讲“Agent 协作效果更好”。