当 Agent 错误地选择了一个不合适的 Skill 导致任务失败，如何通过 feedback loop 优化 Skill 选择策略？

“这个问题本质是在问：怎么让 Agent 从错误中学习，下次不再犯同样的错。 我设计的不是一个简单的重试，而是一套从‘感知错误’到‘归因分析’再到‘策略更新’的三级反馈循环，最后还要能验证改进效果。

---

第一级：实时感知与止损 —— 怎么发现选错了？

首先要给 Agent 装上‘疼痛感应器’。任务失败不一定是选错 Skill，但以下信号组合在一起，大概率是路由决策的问题：

• 信号1：Skill 返回了结果，但可信度评分很低。 比如订机票 Skill 返回的航班日期和用户要求差了三天。

• 信号2：用户立刻纠正或否定。 ‘不对，我要的是头等舱不是经济舱’——这不是 Skill 执行失败，而是 Skill 的能力边界和用户需求不匹配。

• 信号3：用户放弃或重复发起相同意图。 用户说‘算了’然后重新描述需求，这是最强烈的信号。

• 信号4：任务完成后触发了补偿流程。 比如订完酒店又取消，说明当时选的酒店 Skill 可能没考虑用户偏好。

这些信号被实时采集，并作为负样本标签写入决策日志，标记为 routing_failure。它不和 Skill 执行失败（超时、报错）混在一起，而是单独归类——因为这是 Agent 的‘判断错误’，不是 Skill 的‘能力错误’。

---

第二级：归因分析 —— 为什么会选错？

标记为路由失败后，一个归因分析器自动启动，它会从四个维度排查根因：

维度1：意图理解是否有偏差？

把用户原始输入、上下文（对话历史、用户画像）和最终路由到的 Skill 元信息一起回顾分析。通常用一份专门的 prompt 问 LLM：给定这个用户意图和上下文，选 Skill A 是否合理？如果 LLM 判断 Skill B 明显更合适，说明意图到 Skill 的映射出了问题。

维度2：元信息是否有误导？ 检查被错误选中的 Skill，它的 trigger_examples 或 description 是否过于宽泛，导致抢了别人的活儿？比如‘订票’ Skill 的触发示例写了个‘帮我订一张去上海的票’，结果用户想订火车票也被它抢走了，而火车票 Skill 根本没机会参与匹配。

维度3：上下文权重是否失衡？

检查决策时各个评分维度的贡献。比如对话历史权重 0.2、槽位匹配权重 0.35、用户偏好权重 0.25。如果因为用户上三轮都在聊天气，导致‘天气查询’ Skill 的上下文分过高，抢在‘航班查询’前面被选中，说明权重配置需要调整。

维度4：是否存在候选 Skill 缺失？ 如果归因分析发现所有候选 Skill 都不太合适，那就不是选错了，而是根本没有合适的 Skill 可选。这会被标记为 skill_gap，推送给平台管理员考虑新增 Skill。

归因分析器的输出不是一段模糊的文字，而是一个结构化的归因报告：

{
  "failure_type": "routing_failure",
  "root_cause": "context_weight_imbalance",
  "selected_skill": "weather_query",
  "should_have_been": "flight_search",
  "misleading_factor": "对话历史中连续3轮天气话题导致上下文分过高",
  "suggested_action": "降低上下文相关性权重从 0.2 到 0.1"
}

第三级：策略更新与验证 —— 怎么让它不再犯？

有了归因报告，下一步是根据建议自动或人工调整路由策略。按严重程度和置信度分级处理：

自动调整（高置信度、低风险）：

• 降低被误选 Skill 在特定场景下的权重（比如在检测到用户意图包含‘航班’关键词时，天气 Skill 权重乘 0.3）。

• 更新 Skill 的匹配规则，在元信息中补充负触发示例（negative_examples: ["订机票", "买火车票"]），让这个 Skill 将来在这些意图出现时主动让路。

• 调整全局评分权重（如把上下文权重从 0.2 降到 0.1），这适用于系统级偏差修正。

人工审核（低置信度、高风险）：

• 如果归因分析认为 Skill 的 trigger_examples 设计有结构性缺陷，生成修改建议，推送给 Skill 开发者。

• 如果需要新增 Skill，推动 Skill 需求评审流程。

验证闭环： 策略更新后，需要验证是否真的有效。系统会从历史日志中找出所有 routing_failure 事件，用影子测试重放：用更新后的路由策略重新决策，看是否会选中正确的 Skill。如果影子测试的准确率提升，才把更新推到生产。同时，生产上线后持续监控 routing_failure 率，如果 72 小时内下降超过 50%，说明修复有效。

---