四、Agent 智能体设计

这一章是 Agent 岗面试的主战场：从"什么是 Agent"的概念主干，到主循环设计、死循环治理、HITL 人机协同、长任务持久化等生产级工程细节。复习时建议把第 43 题（主循环设计）和第 49 题（Agent 与 Workflow 边界）当成必答核心，其余题目围绕"怎么做、为什么、有什么坑"结合自己项目展开。

39. 什么是 Agent？它和普通 Chatbot、固定工作流（Workflow）的本质区别是什么？

必刷 · 基础

参考答案

Agent 是以 LLM 为决策核心，围绕目标自主进行"规划—工具调用—观察反馈"循环，直到完成任务或触达终止条件的系统。最小定义：LLM + 工具 + 循环。

三者本质区别在控制权归属：

维度	Chatbot	Workflow	Agent
控制权	用户一步步驱动	开发者预先编排	模型运行时自主决策
执行路径	无路径，一问一答	固定、可穷举	动态生成、不可预知
工具与副作用	基本没有	有，但按既定顺序	有，何时调、调什么由模型决定
典型失败模式	答错话	节点报错，易定位	跑偏、死循环、乱调工具

一句话：Chatbot 回答问题，Workflow 执行流程，Agent 解决问题。Agent 用确定性和成本换自主性，所以自主性越高越需要护栏（步数上限、权限分级、HITL）。

面试官可能追问

• LLM + 检索 + 工具调用的 Chatbot 算 Agent 吗？（关键看下一步做什么是否由模型动态决策，检索只是工具之一）
• Agentic Workflow 和真 Agent 的区别？（流程骨架固定、局部节点自主，控制权大部分仍在开发者手里）

40. Agent 的核心组件有哪些？（规划、记忆、工具、反思）分别对应哪些实现？

必刷 · 基础

参考答案

四大组件及对应实现：

• 规划（Planning）：任务拆解与调度。实现：Plan-and-Execute 式全局计划、ReAct 式逐步决策、失败后的局部 replan；
• 记忆（Memory）：短期记忆 = 上下文窗口内的消息轨迹 / scratchpad；长期记忆 = 向量库、文件、数据库，存用户画像、历史事件、技能库（如 Voyager 的代码技能库）；
• 工具（Tools）：与外部世界交互的手段。实现：Function Calling、代码沙箱执行、检索（RAG 可作为 Agent 的一个工具）、浏览器 / 内部 API；
• 反思（Reflection）：对自身输出与执行结果做评估修正。实现：Self-Critique、失败错误回传重试、独立 Critic 模型或规则校验器。

底座是 LLM 推理核心（理解 + 决策），外层还需要执行环境（沙箱、权限体系）和轨迹管理（trace）。面试建议按"组件—实现—项目里怎么用"三层展开。

面试官可能追问

• 短期记忆超窗怎么办？（裁剪、滚动摘要、中间产物外置，可延伸第七章）
• 工具数量到几十上百个怎么组织？（工具检索、分组路由、动态注入，延伸第五章）

41. 讲一下 ReAct 模式。它和纯 CoT 的区别是什么？为什么"边想边做"更可靠？

必刷 · 基础

参考答案

ReAct = Reasoning + Acting（Yao et al., 2022），让模型交替输出思考与动作：

Thought:      我需要先查这个 SKU 的库存
Action:       query_inventory(sku="A123")
Observation:  库存 3 件
Thought:      库存不足，应建议用户换货或预约补货
Final Answer: ...

与纯 CoT 的区别：CoT 的每步推理只发生在"模型脑子里"，中间结论没有外部校验；ReAct 在 Thought 之间插入 Action，把真实环境的 Observation 带回推理链。

"边想边做"更可靠的原因：

1. 接地（grounding）：事实来自工具返回而非参数记忆，压低幻觉；
2. 可中途纠错：某步 Observation 不符预期，下一步 Thought 立即调整策略，错误不滚雪球；
3. 轨迹可观测：每步 Thought 落在轨迹里，出问题能定位到步，而不是面对一段最终答案猜原因。

代价：多次工具往返带来延迟与 Token 成本，循环本身需要护栏（步数上限、重复检测）。

面试官可能追问

• Thought 要展示给用户吗？（分层展示：过程可见性提升信任，但噪音大，通常折叠）
• Thought 和 Observation 怎么在消息结构里区分？（role 严格分离，工具结果用 tool message 回传，防止模型把观察当成自己的思考）

42. ReAct 和 Plan-and-Execute 各自的优缺点？什么场景选哪个？

高频 · 中等

参考答案

	ReAct	Plan-and-Execute
决策方式	每步现场决定下一步	先生成全局计划，再逐步执行
优点	灵活、实时响应环境变化；实现简单	全局视角；步骤可并行、计划可复用；执行步可换小模型降本
缺点	短视（局部贪心）、长任务易跑偏；步数多、Token 成本高	计划僵化，环境变化需 replan；对 Planner 规划能力要求高
失败模式	死循环、目标漂移	计划脱离实际、子任务粒度失衡

选型经验：

• 选 ReAct：步数少（十步以内量级）、环境不确定、需边探索边决策——开放信息检索、故障排查、交互式数据分析；
• 选 Plan-and-Execute：任务结构清晰、步数多（几十步）、成本敏感——批量数据处理、多阶段报告生成；
• 混合是生产主流：Planner 出全局计划，单个子任务执行器内部跑 ReAct 微循环；某步失败触发局部 replan 而不是推翻整个计划（LangGraph 的 plan-and-execute 参考实现即此思路）。

判断口径：先问"路径能否预先穷举"——能穷举连 Workflow 都不用；路径依赖中间结果但阶段清晰，用 Plan-and-Execute；路径完全动态，用 ReAct 并配好护栏。

面试官可能追问

• replan 的触发条件怎么定？（子任务失败、断言不过、外部环境变化）
• 执行器为什么能换小模型？（子任务被计划约束成"照章执行"，指令遵循要求高但决策要求低）

43. 一个生产级 Agent 的主循环（Agent Loop）你会怎么设计？包含哪些状态、出口和护栏？

高频 · 中等

参考答案

核心思路：把主循环当成带预算系统的状态机来设计，而不是一个 while True。

状态设计：控制面状态机 RUNNING / WAITING_HUMAN / DONE / FAILED / CANCELLED；数据面包含消息轨迹（trajectory）、步数计数、预算余量（Token / 费用 / 时间）、当前计划与子任务状态。

主循环骨架：

while state == RUNNING:
    if step >= MAX_STEPS:                     # 硬熔断, 经验 15~30 步
        exit(MAX_STEP)
    if not budget.ok():                       # 费用/时间熔断
        exit(BUDGET_EXCEEDED)

    action = llm.decide(trajectory)           # 单步决策
    if action.type == FINAL_ANSWER:
        exit(OK)                              # 正常出口
    if action.type == ASK_HUMAN:
        persist(); 转 WAITING_HUMAN           # 挂起, 等审批后恢复

    if not schema_check(action):              # 前置护栏: 参数校验
        注入校验错误; continue
    if not policy.allow(action):              # 前置护栏: 权限白名单
        注入拒绝原因; continue

    obs = executor.run(action)                # 超时 + 重试 + 幂等
    trajectory.append(obs)
    checkpoint(step, trajectory)              # 每步落盘, 崩溃可恢复
    if loop_detector.hit(trajectory):         # 后置护栏: 重复检测
        注入警告或升级干预

出口设计：必须多出口且语义分明——正常完成、步数上限、预算耗尽、整体超时、人工接管、用户取消、致命错误。每个异常出口都配兜底动作（返回部分结果、降级固定流程、转人工），绝不静默失败。

护栏分层：前置（schema 校验、工具白名单、参数危险值检查）→ 执行中（单工具超时秒级到分钟级、指数退避重试 2~3 次、幂等键）→ 后置（输出断言、重复检测、审计日志）。全链路 trace 记录每步输入输出与耗时，问题可回放归因。

面试官可能追问

• MAX_STEPS 设多少合适？（按线上任务步数分布的 P95 定，经验 15~30：太松烧钱、太紧截断正常任务）
• 模型幻觉出一个不存在的工具名怎么办？（schema 层直接拦截，错误信息回传让它重选）
• 每步 checkpoint 存什么、怎么恢复？（轨迹 + 结构化状态 + 预算余量，细节见第 52 题）

44. Agent 陷入死循环或反复调用失败工具，怎么治理？说说你用过的熔断和干预手段。

必刷 · 中等

参考答案

先分类形态，再按梯度治理。

常见形态：同参数重复调用同一工具；A 失败→调 B→又回 A 的乒乓；失败工具无限重试；目标漂移（不死循环但越跑越偏、不出结果）。

治理梯度（由轻到重）：

1. 检测层：对（工具名 + 归一化参数）做哈希，在最近 5~10 步滑动窗口查重；连续失败计数（同工具连败 3 次）；无进展检测（关键状态指纹连续 N 步不变）；
2. 提示注入：命中重复时向轨迹注入系统提示："你已用相同参数调用 X 两次且失败，禁止再重试，请改用其他方法"——多数循环这一步就能打断；
3. 错误信息增强：把堆栈和原始报错翻译成模型能理解的结构化错误（错误类型 + 原因 + 建议动作）。反复失败重试的很大一部分根因是错误信息模型读不懂；
4. 工具级熔断：某工具连续失败 3~5 次后在本任务内禁用，并明确告知模型"该工具当前不可用"，同时写告警；
5. 环级熔断：步数上限（15~30 步）、预算熔断、整体超时；触发后走兜底——返回已完成的部分结果、降级固定流程或转人工。

根因预防：工具做幂等设计与超时兜底；system prompt 显式写明"失败后先分析原因，同类调用最多重试一次"；高危工具（发邮件、改数据）不做自动重试。

面试官可能追问

• 怎么区分"合理重试"和"死循环"？（看参数是否变化、是否吸收了上次错误信息、状态是否有实质进展）
• 熔断触发后用户体验怎么兜底？（部分结果 + 失败原因说明 + 转人工入口，而不是直接报错）

45. Agent 的任务拆解（Planning）怎么做？拆解错了如何自纠？子任务间依赖怎么表达？

必刷 · 中等

参考答案

拆解方法：

1. 一次性计划：Planner 单次输出完整任务列表，适合结构清晰的任务；
2. 滚动拆解：只规划最近 2~3 个子任务，执行完再规划下一步，适合路径不确定的长任务；
3. 质量约束（写在 Planner 的 prompt 里）：子任务原子化（一个子任务对应一次可验证的工具调用）、带完成判据（done 条件）、数量受限（如 ≤10 个，防碎片化和"一步到位"两个极端）。

拆错了如何自纠：

• 每个子任务完成后跑断言校验（预期产物是否存在、返回值是否合法）；
• 失败则把"原计划 + 失败原因 + 已完成部分"回喂 Planner 触发局部 replan：只重规划受影响的后继子任务，已完成的直接复用；
• replan 设次数上限（2~3 次），超过则升级人工或降级固定流程。

依赖表达：DAG + 结构化输出：

{ "id": "t3", "desc": "汇总分析", "depends_on": ["t1", "t2"],
  "tool_hint": "python_exec", "done_when": "产出 report.md" }

调度器做拓扑排序，同层无依赖子任务并行；每个子任务维护 pending / running / done / failed / skipped 状态，失败时按依赖边标记下游 skipped 或等待 replan。

面试官可能追问

• Planner 和 Executor 用同一个模型吗？（可分开：Planner 用强模型保规划质量，Executor 用便宜模型省成本）
• 并行子任务结果冲突怎么办？（合并前先校验一致性，冲突步骤串行化重跑）

46. 反思（Reflection / Self-Critique）机制怎么设计？会不会显著增加成本？值不值？

中频 · 较难

参考答案

反思机制设计四要素：

1. 何时反思（触发）：不要每步都反思。触发条件设为：子任务失败、结果与预期不符、Critic 置信分低于阈值、任务交付前终检。选择性触发的性价比远高于全量反思；
2. 谁来反思（角色）：三档——self-critique（同模型换视角，最便宜，但"自己查自己"有自我认同盲区）；独立 Critic 模型或专门 Critic prompt（更客观，多一次调用）；规则 / 确定性校验器（测试、schema、数值检查，零幻觉，应最优先用）。生产通常三层混用：规则先行、模型兜底；
3. 反思什么（输入）：完整轨迹 + 任务目标 + 明确的评分标准（rubric）。没有标准的反思会退化成空话式检讨；
4. 输出什么（动作）：必须落到可执行动作——重做当前步、换工具、修改计划、补充信息、或判定不可行。只打分不给动作的反思没有工程价值。

成本账：一次反思 ≈ 轨迹重放 + 一到两次额外 LLM 调用，全量反思会让 Token 成本翻 2~3 倍、延迟同步放大。

值不值的判断：

• 错误代价高且可验证的任务（代码有测试反馈、数据操作有校验回执）→ 值得；Reflexion 类"失败—反思—重试"（Shinn et al., 2023）在代码类基准上提升明显；
• 低代价、低可验证任务（闲聊、简单摘要）→ 不值得，纯增成本；
• 关键防线：反思后的结果必须过同一套校验，不过则回滚取原结果——防"越改越糟"，这是很多团队上线反思后效果反降的根因。

落地建议：从"失败触发式反思"起步，盯修复率与成本比（经验上修复率能到三四成就值得保留），再决定是否扩展到终检。

面试官可能追问

• Self-critique 的自我认同偏差怎么缓解？（换视角 prompt、独立模型、规则校验优先）
• 反思的 rubric 怎么写？（从 bad case 反推，标准必须可判定，不写"质量好"这种模糊项）

47. Agent 的记忆系统怎么设计？和 RAG 的知识库有什么本质区别？

中频 · 中等

参考答案

分层设计：

• 短期记忆：当前任务的消息轨迹 / scratchpad，生命周期 = 一次任务；管理手段是裁剪、滚动摘要、中间产物外置到文件（把上下文当缓存，不当存储）；
• 长期记忆（跨任务持久化），按内容分四类：
  • 画像类：用户偏好与约束，键值 / 文档存储；
  • 情景类：带时间戳的历史事件，数据库 + 向量索引；
  • 语义类：领域知识、任务 SOP、技能库；
  • 工作类：进行中任务的中间产物，文件系统；
• 写入：任务结束时统一提取写入（不是每轮写），写入前做向量相似度 + 规则去重，新旧冲突时新信息覆盖并版本化；
• 召回：按当前任务语义检索 + 时间衰减 + 重要性加权，top-k 注入 system 区。

与 RAG 知识库的本质区别：

	RAG 知识库	Agent 记忆
内容性质	静态事实、全局共享	动态经验、按主体（用户 / Agent）隔离
读写模式	读密集，低频离线更新	写密集，运行时高频增删改
作用	为生成提供引用素材	参与决策，直接影响行为
关键指标	召回率、忠实度	时效性、个性化、冲突消解

一句话：知识库是"图书馆"，记忆是"日记本"；前者回答"世界是什么样"，后者回答"这个用户 / 这个 Agent 经历过什么"。

面试官可能追问

• 为什么不每轮写记忆？（噪音多、成本高、去重难，任务结束统一提取质量更高）
• 跨会话记忆的隐私合规怎么做？（用户可见可删、明确告知、写入前脱敏，延伸第七、十一章）

48. 如何评估一个 Agent 的好坏？轨迹评估和结果评估分别怎么做？

必刷 · 中等

参考答案

分四层，结果评估和轨迹评估是主干。

结果评估（端到端）：

• 任务成功率：有明确验收标准的任务（测试通过、工单关闭、答案匹配）直接判 pass / fail；
• 部分给分：按关键步骤完成度给分，适合开放性任务；
• 无标准答案时用 LLM-as-judge 打分 + 抽样人审校准；
• 可参考公开基准定位水平：SWE-bench（代码）、τ-bench（工具使用 + 政策遵循）、WebArena（网页任务）。

轨迹评估（过程）：逐 step 检查决策质量——工具选没选对、参数对不对、有无冗余步、有无违规操作。三种做法按成本递增：

1. 规则断言：必经节点、禁用工具、步数上限，全自动跑；
2. LLM-as-judge 按 rubric 逐步打分（工具选择合理性、参数正确性、效率）；
3. 人工逐步标注，贵但准，用于校准 judge 的一致性。

组件级评估：单工具调用准确率（选对工具 + 参数合法率）、Planner 拆解质量、记忆召回质量——用于定位"坏在哪一层"。

线上指标：任务完成率、人工接管率、平均步数与单任务成本、P95 延迟。

要点：结果对 ≠ 过程对（可能绕路或碰运气），轨迹评估才能定位坏步；先建几十到几百个任务的离线评估集，线上靠全量 trace + 抽样人审回流 bad case。

面试官可能追问

• LLM-as-judge 评轨迹可信吗？（需与人工抽样对齐校准，judge 自身有位置偏差、长度偏差）
• 评估集怎么建、怎么演化？（线上任务抽样 + 标注期望路径，版本化管理，新 bad case 持续补入）

49. 什么任务适合做成 Agent，什么任务用固定 Workflow 更好？说说你的判断标准。

高频 · 较难

参考答案

结论先行：判断标准是路径可预知性 + 失败可承受性，不是任务复杂度。五条硬标准：

1. 路径可预知性（第一判据）：90% 以上请求能用一条固定流程覆盖 → Workflow；下一步做什么强依赖中间结果、无法预写 → Agent；
2. 分支组合度：分支少（≤3 条）且可枚举 → Workflow；分支组合爆炸 → Agent；
3. 可验证性：结果可自动验证（有测试、schema、回执）→ 适合 Agent，错了能自纠；不可验证且错误代价高（对外发文、资金操作）→ 固定流程 + 人工卡点；
4. 延迟 / 成本容忍：Agent 多步循环，延迟以十秒到分钟计、成本是单次调用的数倍；实时场景（搜索联想、毫秒级审核）直接排除；
5. 任务分布：高频同质 → 固化成 Workflow 并沉淀 SOP；长尾异质 → Agent 兜长尾。

典型归属：

• 适合 Agent：开放信息研究与汇总、多系统交叉的故障定位、带测试反馈的代码修复、探索式数据分析、跨系统工单协调；
• 适合 Workflow：内容审核流水线、标准文档解析入库、固定格式报告生成、标准 RAG 问答。

生产主流是混合体：Workflow 做骨架，少数"需要判断"的节点内嵌 mini-Agent（如检索策略选择、异常分类），节点结束回到固定流；异常路径再升级为完整 Agent 或转人工。把不确定性封装在局部，整体链路依然可测可控。

加分点

• 演进路径：先 Workflow 上线收集数据，从日志里找人工分支点和高频异常，逐点 Agent 化，而不是一步到位；
• 量化决策：Agent 化收益 = 自动化节省的人力 − 失败兜底成本（人工接管率 × 单次处理成本），算得过账再上；
• 反模式警示：为了技术先进性把确定性流程 Agent 化，用不确定性换零收益，还额外背上评估与护栏成本。

面试官可能追问

• 你们项目里有没有最后退回 Workflow 的环节？为什么？
• 混合架构里 mini-Agent 的边界怎么划？（单一职责、进出都有 schema，不让自主性溢出到节点外）

50. Agent 的确定性不足怎么解决？说说你在可控性与自主性之间做过的取舍。

中频 · 较难

参考答案

结论：确定性不足无法根治，治理思路是分层收窄自由度 + 失败模式可控——追求可检测、可恢复、可归因，而不是行为完全确定。

手段分层：

1. 非 LLM 化：路由用小分类器或规则、数值计算交给代码工具、格式转换用模板，LLM 只做必须由它做的判断；
2. 收窄决策空间：按阶段注入工具子集（检索阶段只给检索类工具）；决策输出限定 schema（用枚举字段代替自由文本）；用状态机限定每一步的合法动作集；
3. 约束采样与提示：temperature 0、固定 few-shot、要求决策前先引用规则再给结论；
4. 后置校验：每步输出断言（参数范围、业务规则引擎卡点）、终态 schema 校验，不过就打回重试或降级；
5. 观测与版本化：全链路 trace，模型 / Prompt / 配置全部版本化，同一任务可回放对比、问题可归因。

取舍案例（叙事框架）：数据分析 Agent——自然语言转 SQL 需要模型灵活性，保留 Agent；SQL 执行、图表渲染走固定管道；"删表、导出客户数据"从模型自主决定改为"模型建议 + 规则拦截 + 人工确认"。

自主性分级（可落地的模式）：

• 只读操作：完全自主；
• 写操作：自主执行 + 幂等设计 + 事后审计；
• 删除 / 资金 / 对外发送：模型只能提申请，规则强制人工批准。

经验总结：先问"这一步错了多严重"，再决定给它多大自由度；可控性的落地形态就是权限分级、校验卡点、审计回放三件套。

加分点

• 把"确定性预算"显式化：每个节点标注其对确定性的要求等级，评审时逐节点过，而不是拍脑袋整体放宽或收紧。

面试官可能追问

• temperature 0 就确定了吗？（只是近似，批处理与浮点舍入仍会引入抖动，见第一章）
• 举个你们把自主性收回去的真实案例和数据？（例如某写操作自主执行错误率 2%、改人工确认后损失归零、延迟增加多少）

51. 如何设计 Agent 的中断、接管（HITL 人机协同）机制？暂停后怎么恢复？

中频 · 较难

参考答案

中断设计：

• 中断来源：用户主动取消；系统触发——高危操作前置审批（删除、付款、对外发文）、置信度低于阈值、熔断、整体超时；
• 审批点分级：只读工具直接执行；写操作自动执行 + 事后审计；高危操作同步阻塞等审批。审批卡片要展示：意图说明、完整参数、预期后果、同类历史操作结果，人可选"批准 / 拒绝 / 修改参数后批准"——支持修改的挽回率明显高于二元审批；
• 异步等待：进入 WAITING 状态后立即持久化全量上下文、释放计算资源，通过 IM / 工单通知审批人；等待设超时（如 24 小时），超时自动取消或降级，不能无限占位。

恢复设计：

• 恢复 = 从 checkpoint 重建状态：完整消息轨迹 + 结构化状态（当前计划、子任务状态、步数、预算余量）+ 待执行动作队列。工程上 LangGraph 的 interrupt + checkpointer 是现成参照；
• 人的决定如何注入：批准 → 作为 observation 注入，继续循环；拒绝 / 修改 → 把反馈作为新约束注入，让 Agent 调整后续计划；也允许人直接编辑计划或状态后继续，跳过模型重新规划；
• 上下文处理：等待可能间隔数小时到数天，恢复时对早期轨迹做摘要，保留关键决策与最近 N 步原文；
• 状态对账：外部世界在等待期间可能已变（库存、价格、工单状态），恢复后先重验关键前提，失效则触发 replan 而不是盲目续跑。

审计：中断 / 恢复 / 人工干预全部落事件日志，事后可完整回放"当时 Agent 想做什么、人改了什么"。

面试官可能追问

• 审批会不会成为吞吐瓶颈？（分级 + 异步 + 批量审批聚合，只让高危操作阻塞）
• 人直接改状态和给反馈让模型自己改，怎么选？（高频标准化修正直接改状态更稳；开放性调整走模型，保留自纠能力）

52. 长任务 Agent（运行几十分钟、上百步）的稳定性怎么保障？中间态怎么持久化？

中频 · 较难

参考答案

威胁清单：进程崩溃重启、LLM API 限流抖动、上下文超窗、成本累积失控、外部工具状态漂移、用户中途离线。

稳定性手段：

1. 任务分解 + 阶段化：上百步任务拆成阶段，阶段间落盘；失败只重跑当前阶段，不整任务重来；
2. 重试与幂等：LLM 调用失败指数退避重试 2~3 次；工具调用带幂等键；恢复前先判断"最后一个动作是否已实际生效"（先写意图日志再执行，或执行前查重），避免恢复后重复发邮件、重复扣款——这是长任务最危险的一类事故；
3. 预算硬顶：总 Token / 费用上限、任务级硬超时（如 30~60 分钟）、心跳与进度上报，用户离线也能看到进度；
4. 上下文治理：滚动摘要 + 中间产物外置（文件 / 对象存储），轨迹分段归档；上下文只留当前阶段必需内容——几百步不治理必然超窗且成本爆炸。

中间态持久化（核心）：采用事件溯源（event sourcing）——每步产生的事件（LLM 请求 / 响应、工具调用 / 结果、状态变更、人工干预）追加写入数据库，任意时点状态可由事件回放重建；checkpoint 在阶段边界和关键点做快照，加速恢复。存什么：完整轨迹、结构化计划与子任务状态、预算消耗、模型 / Prompt / 工具配置版本号。

恢复流程：加载最近 checkpoint → 对账外部状态（关键前提是否仍成立）→ 决定回退粒度（重试当前步 / 回退到阶段起点 / 整任务重跑）→ 续跑。

一句话：把长任务 Agent 当分布式系统设计——假设任何一步都会挂，用持久化 + 幂等 + 对账换可靠性。

面试官可能追问

• 事件溯源和直接存快照怎么选？（事件可回放可审计但重建慢，快照快但丢失中间细节，生产上事件流 + 定期快照结合）
• 幂等键怎么设计？（任务 ID + 步骤 ID + 业务键，服务端按键去重）