拓冰网站优化 
规划执行好 Plan 的 G4C与“失败点 ≠ 根因点”的 Replan配套课程第二章05~10 讲。对应考点Plan 机制、Replan 上下、TAO ReAct、面试场景设计。1. 面试官的两连问面试官你的 Agent 怎么制定计划候选人我用 LLM 生成一串 steps。面试官执行到一半工具报错了呢候选人……再调一次 LLM 重试。两处都挨打。课程的答案是Plan 要有可验证的结构G4CReplan 要能回溯根因而不是在失败层傻重试。2. 好 Plan 的 5 要素G4Cplan_agent.py的make_plan产出的不是一段自然语言而是一个结构化对象PLAN_TEMPLATES{book:{goal:为用户完成下单且符合其‘最划算’偏好,steps:[{action:检索候选方案与价格,tool:retrieve,depends_on:[],...},{action:按‘最划算’维度对比候选,tool:compare,depends_on:[0],...},{action:确认关键信息并下单,tool:booking,depends_on:[1],...},],},...}G4C 五个要素一一对应要素含义本系统落地G1 Goal目标可验证goal字段成功与否可判定G2 Grounding有哪些工具/资源grounding [search, retrieve, compare, ...]G3 Granularity粒度一步一动作每个 step 单一动作G4 Graph步骤依赖图depends_on表达先后与依赖G5 Contingency每步失败回退每个 step 带fallback实测 S2 生成的计划目标为用户完成下单且符合其‘最划算’偏好 1. 检索候选方案与价格 (toolretrieve) 2. 按‘最划算’维度对比候选 (toolcompare, 依赖 1) 3. 确认关键信息并下单 (toolbooking, 依赖 2)3. Replan上计划赶不上变化真实执行不会一帆风顺。S2 第 3 步booking直接失败[exec] tool s3 booking okFalse errormissing param: destination(缺少目的地/城市)如果只在失败层重试永远过不去——因为根因不在执行层。4. Replan下失败点 ≠ 根因点plan_agent.py的replan先做根因分类再下刀def_classify_root_cause(error,observed):ifmissing paramine:returninput,输入/前置步骤缺少必要实体或参数ifemptyineor0 条ine:returnretrieval,检索过窄/知识缺失iftimeoutine:returntool,工具不可用/超时...S2 的失败被分类为input根因在更早的收集/澄清步骤而非执行层。于是 Replan 不做无谓重试而是保留已完成步骤检索、对比不重做在依赖图里插入一个澄清步骤根因标注到该步失败步及其后续标记为待重跑。真实Trace节选[plan ] replan_request failed_steps3 errormissing param: destination [plan ] replan root_cause{type:input, desc:根因在更早的收集步骤} [gateway] clarification_resolved ctx_patch{destination:上海, entity:机票} [exec ] tool s3 booking okTrue → 订单号 ORD_xxx注意看失败点是 s3执行层根因被回溯到“缺参数”这件事本应在更早被发现。系统从用户画像补全了destination上海然后只重跑了 s3检索和对比的结果原样复用。这就是“随机应变”的工程实现。5. 顺带说 TAO ReAct执行层执行层的exec_agent.py用TAOTask→Action→Observation循环工具选择靠可解释打分器而非玄学defselect_tool(action_text,available):scores{tool:sum(kinaction_textforkinTOOL_KEYWORDS[tool])fortoolinavailable}returnmax(scores,keyscores.get),scores“按‘最划算’维度对比候选” →compare命中 2 个关键词 → 选compare。工具选错了能纠偏若 plan 给的工具名和实际动作不匹配以打分器为准而且选择过程可解释——这正是课程 09 讲“为什么你的 Agent 总是选错工具”的答案。6. 面试场景设计把业务场景当“主线剧情”课程第 10 讲强调准备一个复杂业务场景作为面试主线。本系统直接把“那个最划算的帮我订了”做成主线串起意图识别消歧“那个”“最划算”规划G4C执行TAO 工具选择注入失败缺目的地→ Replan 根因回溯 → 自愈评估反馈自愈成功指标 0.945一镜到底比背八股有力得多。7. 面试话术模板“Plan 我用 G4C 结构化目标可验证、明确可用工具、步骤拆到一步一动作、依赖图表达先后、每步带回退。执行失败的时不做无脑重试——我先做根因分类失败点在执行层但根因可能在输入层缺参数、检索层召回为空或工具层超时。本系统实测一次‘缺目的地’失败被回溯到输入层、从上下文补全参数、只重跑失败步最终自愈评估自愈指标1.0。”下一篇上下文与检索f(Context) 与零依赖 RAG 规划执行：好 Plan 的 G4C，与“失败点 ≠ 根因点”的 Replan
规划执行好 Plan 的 G4C与“失败点 ≠ 根因点”的 Replan配套课程第二章05~10 讲。对应考点Plan 机制、Replan 上下、TAO ReAct、面试场景设计。1. 面试官的两连问面试官你的 Agent 怎么制定计划候选人我用 LLM 生成一串 steps。面试官执行到一半工具报错了呢候选人……再调一次 LLM 重试。两处都挨打。课程的答案是Plan 要有可验证的结构G4CReplan 要能回溯根因而不是在失败层傻重试。2. 好 Plan 的 5 要素G4Cplan_agent.py的make_plan产出的不是一段自然语言而是一个结构化对象PLAN_TEMPLATES{book:{goal:为用户完成下单且符合其‘最划算’偏好,steps:[{action:检索候选方案与价格,tool:retrieve,depends_on:[],...},{action:按‘最划算’维度对比候选,tool:compare,depends_on:[0],...},{action:确认关键信息并下单,tool:booking,depends_on:[1],...},],},...}G4C 五个要素一一对应要素含义本系统落地G1 Goal目标可验证goal字段成功与否可判定G2 Grounding有哪些工具/资源grounding [search, retrieve, compare, ...]G3 Granularity粒度一步一动作每个 step 单一动作G4 Graph步骤依赖图depends_on表达先后与依赖G5 Contingency每步失败回退每个 step 带fallback实测 S2 生成的计划目标为用户完成下单且符合其‘最划算’偏好 1. 检索候选方案与价格 (toolretrieve) 2. 按‘最划算’维度对比候选 (toolcompare, 依赖 1) 3. 确认关键信息并下单 (toolbooking, 依赖 2)3. Replan上计划赶不上变化真实执行不会一帆风顺。S2 第 3 步booking直接失败[exec] tool s3 booking okFalse errormissing param: destination(缺少目的地/城市)如果只在失败层重试永远过不去——因为根因不在执行层。4. Replan下失败点 ≠ 根因点plan_agent.py的replan先做根因分类再下刀def_classify_root_cause(error,observed):ifmissing paramine:returninput,输入/前置步骤缺少必要实体或参数ifemptyineor0 条ine:returnretrieval,检索过窄/知识缺失iftimeoutine:returntool,工具不可用/超时...S2 的失败被分类为input根因在更早的收集/澄清步骤而非执行层。于是 Replan 不做无谓重试而是保留已完成步骤检索、对比不重做在依赖图里插入一个澄清步骤根因标注到该步失败步及其后续标记为待重跑。真实Trace节选[plan ] replan_request failed_steps3 errormissing param: destination [plan ] replan root_cause{type:input, desc:根因在更早的收集步骤} [gateway] clarification_resolved ctx_patch{destination:上海, entity:机票} [exec ] tool s3 booking okTrue → 订单号 ORD_xxx注意看失败点是 s3执行层根因被回溯到“缺参数”这件事本应在更早被发现。系统从用户画像补全了destination上海然后只重跑了 s3检索和对比的结果原样复用。这就是“随机应变”的工程实现。5. 顺带说 TAO ReAct执行层执行层的exec_agent.py用TAOTask→Action→Observation循环工具选择靠可解释打分器而非玄学defselect_tool(action_text,available):scores{tool:sum(kinaction_textforkinTOOL_KEYWORDS[tool])fortoolinavailable}returnmax(scores,keyscores.get),scores“按‘最划算’维度对比候选” →compare命中 2 个关键词 → 选compare。工具选错了能纠偏若 plan 给的工具名和实际动作不匹配以打分器为准而且选择过程可解释——这正是课程 09 讲“为什么你的 Agent 总是选错工具”的答案。6. 面试场景设计把业务场景当“主线剧情”课程第 10 讲强调准备一个复杂业务场景作为面试主线。本系统直接把“那个最划算的帮我订了”做成主线串起意图识别消歧“那个”“最划算”规划G4C执行TAO 工具选择注入失败缺目的地→ Replan 根因回溯 → 自愈评估反馈自愈成功指标 0.945一镜到底比背八股有力得多。7. 面试话术模板“Plan 我用 G4C 结构化目标可验证、明确可用工具、步骤拆到一步一动作、依赖图表达先后、每步带回退。执行失败的时不做无脑重试——我先做根因分类失败点在执行层但根因可能在输入层缺参数、检索层召回为空或工具层超时。本系统实测一次‘缺目的地’失败被回溯到输入层、从上下文补全参数、只重跑失败步最终自愈评估自愈指标1.0。”下一篇上下文与检索f(Context) 与零依赖 RAG