本篇属于 智能体面试与工程基础 系列。
A10｜P0：上下文到底由什么组成？
口述： 由指令、用户请求、必要会话历史、状态摘要、检索证据、工具描述及工具结果等按接口协议组织；不是固定四段字符串拼接。预算应同时为输出预留空间，状态不必全部塞给模型。
追问： 如何保留工具调用与结果的对应关系，防止摘要破坏协议？
A11｜P0：如何压缩上下文，又避免重复执行工具？
口述： 原始事件持久化，模型上下文只保留相关窗口和摘要；另存结构化任务账本，包括完成项、工具结果引用、未解决问题和副作用幂等键。摘要丢失时可以按需取回事实，不能把摘要当唯一执行依据。
追问： 记录显示已成功但摘要说待办，以谁为准，如何检测冲突？
A12｜P0：短期与长期记忆怎么存？
口述： 短期记忆服务当前会话或运行，长期记忆跨会话保存有价值的事实和偏好。结构化表保存权威字段与版本，文本保存解释和证据，向量索引辅助语义检索；同一事实应有稳定ID、来源和更新时间，避免多份互相覆盖。
追问： 什么可以进入长期记忆，什么时候过期或删除？
A13｜P1：记忆冲突与分层检索怎么解决？
口述： 区分用户更改偏好、过期事实与来源矛盾，结合主体、有效时间、来源与版本处理；关键冲突需澄清。先做权限和范围过滤，再用结构化/关键词/向量检索，按相关性与时效选择。向量不是唯一方案。使用 Mem0 等记忆组件时，也需要验证所用版本的写入、更新、删除和隔离行为。
追问： 语义相似但属于不同用户的记忆，在哪一层隔离？
A14｜P1：单Agent加多个Skill能否替代多Agent？
口述： 很多任务可以，先建立单Agent基线。独立上下文、权限、专业职责或可并行工作需要明确时才考虑多Agent；代价是协调、通信、结果冲突、成本及更难定位失败。
追问： 分成多个角色后，质量提升来自哪里，有没有等预算对照？
A15｜P1：Supervisor-Worker和Peer-to-Peer怎么选？
口述： 集中协调便于明确路由、预算与验收，但可能形成瓶颈；点对点适合更分散的职责，却需要处理冲突和终止协议。通信可以传结构化中间结果与证据引用，不必共享完整对话；是否可读其他历史应显式授权。
追问： 两个worker同时更新一个字段，谁负责合并？
常见协作模式： Pipeline 按依赖串接各阶段；Parallel 并行处理独立子任务后汇总；Supervisor 负责分配与验收；Debate 让不同候选互相质疑，但仍需独立的证据校验。多个 Agent 使用相同模型和相同材料，可能共享同一种错误，多数票不等于真实。
A16｜P1：子Agent失败、重复通信或上下文膨胀怎么办？
口述： 子任务有明确输入、交付格式、deadline、预算和父任务ID。失败后依据可重试性恢复、替代或返回部分结果；通信按事件ID去重、限制转发与循环，跨任务只传必要信息。各Agent应继承整体预算，不能各自无限扩张。
追问： 父任务取消后，子任务和外部工具是否仍在执行？
A42｜P1：StateGraph 的 State 与 Reducer 怎么设计？
口述： State 定义图执行需要保存和传递的字段，节点返回字段更新；Reducer 决定同一字段的旧值与新更新如何合并。没有合并规则的字段不能假定并发写会自动“最后一个胜出”。可以分开写不同字段，或定义业务明确的聚合逻辑。Graph API
例如两个检索节点分别返回 {document_id: evidence}，可按文档 ID 去重合并；同一 ID 的版本冲突按显式规则处理。列表相加只解决拼接，不能解决重复、稳定顺序或事实冲突。对于最终状态如“批准/拒绝”，应由单一汇总节点决策，而非随意覆盖。
设计检查： State 保存任务状态、结果引用与必要元信息；连接、凭证和大型原文不直接塞入。TypedDict 主要提供类型提示，不能代替外部输入的运行时校验。需要并行合并时，检查结合性与顺序影响；可能重复投递时另做幂等处理。
追问： 两个节点都对余额加一，重放其中一个会不会多加？Reducer 是字段合并规则，不是分布式事务锁。
A43｜P1：Checkpointer 如何持久化，如何恢复执行？
口述： 编译图时配置 checkpointer，并使用稳定且经过租户授权校验的 thread_id 定位执行历史。持久化后端需要配套 saver 实现和初始化；“换成 Redis/DB”并非只改连接字符串。按后端检查序列化、事务、版本兼容、保留时间与访问权限。
恢复流程： 先读取状态快照，区分异常待重试与人工中断。异常后的继续执行通常使用同一配置重新调用；interrupt() 的暂停使用 Command(resume=...) 提交恢复值。指定历史 checkpoint_id 是选择历史状态继续或分叉，不是任意跳到一个节点名。具体重放与 pending writes 行为应按实际版本验证。LangGraph 持久化
必须演练的故障： 工具已写入订单，checkpoint 尚未确认便崩溃。恢复前查询业务执行记录或用幂等键判断，不能只看模型历史。代码升级后也要考虑旧状态字段与节点名称是否兼容。
追问： 重新执行节点时，哪些语句可能再跑？数据库保存成功而返回包丢失，如何避免重复提交？
A44｜P0：Human-in-the-Loop 放在哪里，interrupt 如何使用？
口述： 是否审批由权限、影响范围与可逆性决定，例如对外发送、删除重要资源、修改生产配置或新增费用。展示具体操作、目标、参数与预期影响，在实际执行前暂停；恢复后再次校验身份、权限、参数版本及审批有效期。
LangGraph 可在节点中调用 interrupt(payload)，向用户提供可序列化的审批内容；使用持久 checkpointer 与同一个 thread_id，再通过 Command(resume=decision) 恢复。恢复时节点会从开头重新执行，故不要把不可重复的外部写入放在 interrupt 前，也不要用宽泛异常处理吞掉中断信号。Interrupts
工程边界： 建议审批节点与执行节点分离。执行仍使用幂等键，审批记录绑定 operation_id 与参数摘要。审批期间资源发生变化，应重新校验必要条件；有人点“同意”不代表以后所有操作都被批准。
追问： 审批重复点击、审批超时、权限撤销，分别进入什么状态？
