执行与评估TAO 工具选择与让 Agent “知道自己错在哪”配套课程执行层TAO ReAct 评估反馈主线。对应考点为什么选错工具、怎么判断用户喜不喜欢、怎么把失败变优化。1. 执行层TAO 不是“走一步看一步”的口号课程 08/09 讲的核心是TAO 是 Task→Action→Observation 的紧凑循环ReAct 更强调显式推理轨迹。但面试真正的坑是 09 讲标题——为什么你的 Agent 总是选错工具本系统的答案用可解释的工具选择器而不是把动作文本丢给 LLM 让它“自己看着办”。TOOL_KEYWORDS{retrieve:[检索,资料,知识,查一下],compare:[对比,比较,排序,维度,差异],calculator:[计算,算,公式,价格,费用],booking:[下单,预订,订,购买,预约],recommend:[推荐,建议,结论,引导,澄清],...}defselect_tool(action_text,available):scores{t:sum(kinaction_textforkinTOOL_KEYWORDS[t])fortinavailable}returnmax(scores,keyscores.get),scores每一步执行都打印tool_scores所以“为什么选这个工具”是可解释的[exec] TAO select toolcompare scores{retrieve:1, compare:2, calculator:1}如果 Plan 给的工具名和实际动作不匹配以打分器为准纠偏——这就是“选错工具”的解法不是不犯错而是犯错可被发现、可被纠正。2. 工具注册表Agent 的“手”exec_agent.py内置一组工具其中retrieve直接调 MemoryAgent跨机booking故意在缺参数时失败以触发 ReplanTOOL_IMPL{retrieve:_t_retrieve,# 调 memory_agent 的 RAGcompare:_t_compare,# 按“最划算”排序booking:_t_booking,# 缺 entity/destination 时返回结构化失败calculator:_t_calculator,recommend:_t_recommend,...}工具返回的是结构化结果或结构化失败不是一段自然语言——这样上层才能做根因分类和自愈。3. 评估反馈把一次运行量化成指标课程评估反馈主线的两问“用户喜不喜欢” “Agent 知道自己错在哪”eval_agent.py把一次Trace量化成 6 个可解释指标metrics{intent_accuracy:# 意图识别准确率置信度 是否澄清plan_quality:# 计划是否具备 G4C依赖图 每步预案tool_selection:# 工具选择可解释、纠偏次数retrieval_relevance:# 检索是否命中recovery_success:# 是否从失败中自愈Replan 后成功context_efficiency:# 上下文是否被有效压缩}S2 实测指标总分 0.945良好指标值intent_accuracy0.92plan_quality0.95tool_selection1.0retrieval_relevance1.0recovery_success1.0整体0.9454. 反馈闭环失败 → 根因 → 优化依据评估不只是打分还要沉淀。本系统把每次失败的类型 根因 修复动作写进看板dashboard.py并支持显式反馈点赞/点踩deffeedback(self,session_id,rating,comment):self.feedbacks.append({...})# 形成下一次优化的依据这就是课程说的把一次失败变成下一次优化的依据逐步降低同类失败率。5. 看板面试作战地图m4上的dashboard(8006)把最新一次运行的指标、全链路事件时间线、Replan 标记渲染成网页。面试时打开它指着时间线讲“这里下单失败→这里回溯根因→这里自愈”比 PPT 有说服力。6. 面试话术模板“执行层我用 TAO 循环但工具选择不靠 LLM 玄学——我有一个动作-工具打分器可解释、可纠偏。评估侧我把每次运行量化成意图准确率、计划质量、工具选择、检索相关性、自愈成功率、上下文效率六个指标并把失败按‘类型根因修复’沉淀成反馈闭环让 Agent 知道自己错在哪、下次怎么改。”下一篇面试话术与简历把项目讲专业
执行与评估TAO 工具选择与让 Agent “知道自己错在哪”配套课程执行层TAO ReAct 评估反馈主线。对应考点为什么选错工具、怎么判断用户喜不喜欢、怎么把失败变优化。1. 执行层TAO 不是“走一步看一步”的口号课程 08/09 讲的核心是TAO 是 Task→Action→Observation 的紧凑循环ReAct 更强调显式推理轨迹。但面试真正的坑是 09 讲标题——为什么你的 Agent 总是选错工具本系统的答案用可解释的工具选择器而不是把动作文本丢给 LLM 让它“自己看着办”。TOOL_KEYWORDS{retrieve:[检索,资料,知识,查一下],compare:[对比,比较,排序,维度,差异],calculator:[计算,算,公式,价格,费用],booking:[下单,预订,订,购买,预约],recommend:[推荐,建议,结论,引导,澄清],...}defselect_tool(action_text,available):scores{t:sum(kinaction_textforkinTOOL_KEYWORDS[t])fortinavailable}returnmax(scores,keyscores.get),scores每一步执行都打印tool_scores所以“为什么选这个工具”是可解释的[exec] TAO select toolcompare scores{retrieve:1, compare:2, calculator:1}如果 Plan 给的工具名和实际动作不匹配以打分器为准纠偏——这就是“选错工具”的解法不是不犯错而是犯错可被发现、可被纠正。2. 工具注册表Agent 的“手”exec_agent.py内置一组工具其中retrieve直接调 MemoryAgent跨机booking故意在缺参数时失败以触发 ReplanTOOL_IMPL{retrieve:_t_retrieve,# 调 memory_agent 的 RAGcompare:_t_compare,# 按“最划算”排序booking:_t_booking,# 缺 entity/destination 时返回结构化失败calculator:_t_calculator,recommend:_t_recommend,...}工具返回的是结构化结果或结构化失败不是一段自然语言——这样上层才能做根因分类和自愈。3. 评估反馈把一次运行量化成指标课程评估反馈主线的两问“用户喜不喜欢” “Agent 知道自己错在哪”eval_agent.py把一次Trace量化成 6 个可解释指标metrics{intent_accuracy:# 意图识别准确率置信度 是否澄清plan_quality:# 计划是否具备 G4C依赖图 每步预案tool_selection:# 工具选择可解释、纠偏次数retrieval_relevance:# 检索是否命中recovery_success:# 是否从失败中自愈Replan 后成功context_efficiency:# 上下文是否被有效压缩}S2 实测指标总分 0.945良好指标值intent_accuracy0.92plan_quality0.95tool_selection1.0retrieval_relevance1.0recovery_success1.0整体0.9454. 反馈闭环失败 → 根因 → 优化依据评估不只是打分还要沉淀。本系统把每次失败的类型 根因 修复动作写进看板dashboard.py并支持显式反馈点赞/点踩deffeedback(self,session_id,rating,comment):self.feedbacks.append({...})# 形成下一次优化的依据这就是课程说的把一次失败变成下一次优化的依据逐步降低同类失败率。5. 看板面试作战地图m4上的dashboard(8006)把最新一次运行的指标、全链路事件时间线、Replan 标记渲染成网页。面试时打开它指着时间线讲“这里下单失败→这里回溯根因→这里自愈”比 PPT 有说服力。6. 面试话术模板“执行层我用 TAO 循环但工具选择不靠 LLM 玄学——我有一个动作-工具打分器可解释、可纠偏。评估侧我把每次运行量化成意图准确率、计划质量、工具选择、检索相关性、自愈成功率、上下文效率六个指标并把失败按‘类型根因修复’沉淀成反馈闭环让 Agent 知道自己错在哪、下次怎么改。”下一篇面试话术与简历把项目讲专业
，以及不调库的 RAG)
