Problem**: 解决什么，设定是什么
1️⃣ 考察意图
面试官想看你是否具备“从模糊需求到可执行问题”的拆解能力，而非只会调API。这是系统设计类考察，刁钻点在于：多数候选人能背RAG/Agent流程，但说不清“为什么这个场景要定义成多跳推理而非单步检索”，以及“约束条件如何影响方案选型”。答好了能展示问题建模硬实力——这是P1+级别工程师和初级调包侠的分水岭。
2️⃣ 标准答
核心：Problem Formulation 是把业务需求翻译成技术约束的翻译器。 我分三步走：
第一步：一句话定义核心挑战
- 例：给定用户指令“帮我订明天去北京的机票，预算1500以内”，核心挑战是“让LLM在有限工具调用次数内，完成多步推理并返回可执行动作”。
- 关键：用“在……条件下，完成……并返回……”句式，把输入、输出、约束一次说清。
第二步：设定场景（输入/输出/约束）
- 输入：自然语言指令 + 工具列表（如航班查询API、支付API）+ 历史对话（可选）
- 输出：工具调用序列（如
search_flights(dest="北京", date="明天")→filter_price(max=1500)→book_flight(id=xxx)） - 约束（必须量化）：
- 实时性：用户等待<3秒，所以不能用全量CoT，得用ReAct+缓存
- 资源限制：单次推理token预算<2000，所以不能用全量上下文，得用滑动窗口
- 错误容忍：工具调用失败率<5%，所以必须加retry+fallback逻辑
第三步：分析动机（现有方法为什么不够）
- 纯Prompt工程：CoT在复杂任务上误差累积，比如第一步查错航班，后面全错
- 单步RAG：无法处理“先查航班再查天气”的依赖关系
- 所以需要结构化Agent：把问题分解成子任务，每个子任务有独立评估点
第四步：确定评估指标
- 任务完成率（Success Rate）：最终是否订到票
- 推理路径正确率（Path Accuracy）：每一步工具调用是否合理
- 步数效率（Step Efficiency）：平均调用次数，理想值<5步
- 关键取舍：不能只看最终结果——比如蒙对答案但路径错的case，在Agent场景下是灾难（下次类似问题会崩）
第五步：实际落地的坑 + 解法
- 坑：用户指令模糊（如“订机票”没说目的地），导致Agent死循环
- 解法：加一个“意图澄清”子模块，当置信度<0.7时主动反问用户，而不是瞎猜
- 坑：工具返回格式不一致（有的API返回JSON，有的返回XML）
- 解法：统一用
pydantic定义输出schema，每个工具返回前做类型校验，失败则重试
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，问题定义——用‘在约束条件下完成目标’句式把核心挑战说清楚；第二，场景设定——量化输入、输出和约束（比如实时性<3秒、token预算<2000）；第三，评估体系——用任务完成率+路径正确率双指标，避免‘蒙对答案’的假阳性。总结一句：Problem Formulation的本质是把业务模糊性翻译成可验证的技术约束。”
4️⃣ 高频追问 & 应对
追问 1：如果用户指令是“帮我安排下周的出差行程”，你怎么定义问题？约束条件怎么定？
核心是把模糊指令拆成可枚举的子问题。我会先做意图分解：① 出差地点（需用户确认）② 交通方式（飞机/高铁）③ 住宿标准（预算？）④ 时间窗口（周一到周五？）。约束条件：① 实时性<5秒（因为要多次交互）② 工具调用次数上限10次（防止死循环）③ 必须包含“确认环节”（用户确认后再执行）。评估指标：子任务完成率+用户确认次数（越少越好）。
追问 2：如果评估指标里任务完成率很高但路径正确率很低，说明什么问题？怎么修？
说明Agent在走捷径——比如直接调用“一键订票”API绕过中间步骤，或者用LLM幻觉生成假结果。解法：① 在工具层加“依赖检查”，比如订票前必须调用过“查航班”工具，否则拒绝执行 ② 在评估层加“路径惩罚”，路径错误的任务即使结果对也扣分 ③ 用过程奖励模型（PRM） 给每一步打分，而不是只看最终结果。
追问 3：你提到用ReAct+缓存解决实时性，具体怎么实现？trade-off是什么？
ReAct是循环调用LLM直到任务完成，每次循环都走一次推理。缓存策略：对相同输入的工具调用结果缓存（比如“查北京到上海航班”），TTL设30秒。Trade-off：缓存提升速度但牺牲实时性（如果航班价格变了，缓存返回旧数据）。解法：对价格敏感型工具（如机票）不缓存或短TTL，对静态数据（如机场代码）长缓存。
5️⃣ 避坑 · 常见错误答法
- ❌ 直接说“这个问题是让LLM做多步推理”，然后开始讲Agent架构 → ✅ 先定义问题边界（输入/输出/约束），再讲架构，否则面试官觉得你只会背流程
- ❌ 评估指标只提“准确率” → ✅ 必须区分“任务完成率”和“路径正确率”，并解释为什么后者更重要（防止Agent作弊）
- ❌ 忽略约束条件，只说“用ReAct就能解决” → ✅ 必须量化约束（实时性、token预算、错误容忍），否则方案无法落地
6️⃣ 简历呼应
- 如果你有RAG项目：从“多跳问答”切入，对比单步RAG的误差累积，展示你在HotpotQA上定义问题（两步推理+路径评估）的经验
- 如果你只做过传统NLP：用“意图分类+槽位填充”类比，说“Agent的Problem Formulation本质是结构化输出约束，和序列标注一样需要定义标签空间”
- 如果你是校招无项目：聚焦论文复现——比如ReAct论文里如何定义“WebShop”任务（输入是商品描述，输出是点击序列，约束是步数上限），展示你读过原始论文
- ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2023)
- Tree of Thoughts: Deliberate Problem Solving with Large Language Models (Wei et al., 2023)
- Process Reward Models for Mathematical Reasoning (Uesato et al., 2022)
- HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering (Yang et al., 2018)
- LangGraph官方文档：StateGraph的节点定义与约束设计