科技人人都是产品经理·Aine··AI 生成
Skill 路由优化实战：基于真实业务请求的 description 自进化
作者把 Agent 选错 Skill 后的优化流程拆成两段：用本地首路由回放把反馈周期压到分钟级，再用「归因假设→description 改写→回归验证→经验沉淀」闭环迭代。核心案例是「会话内数据交付」与「向外部通知」两种相似能力的首入口混淆，最终候选在 34 条开发请求上命中 31 条（91.18%）。文中明确区分了开发集选优与真实成功率，并列出未验证边界：无独立留出集、双侧简介同时修改无法分离贡献、剩余 3 类冲突未解。原文 ↗原文 ↗
核心观点
- ▍Agent 首路由优化的瓶颈不是「改一句 description」，而是缺少可归因、可回归、可沉淀的迭代闭环；本地首路由回放能把反馈从完整业务耗时压到分钟级，但不能替代完整任务验收。
- ▍两种能力共享查询步骤时，区分首入口的关键不是补充关键词，而是把「交付目的」写进 description：会话内交付结果 vs 向外部渠道投递通知。
- 01最终选定候选在 34 条开发请求上命中 31 条，准确率 91.18%；每题回放 3 次按多数首路由计分，三次各不相同计为未命中，不挑正确一次计分。
- 02本地回放保留「消息历史→模型→前置工具→追加调用→模型」循环，模型被真实调用，检索/目录/简介读取由冻结材料提供，观察到首次 Skill 调用即停止。
- 0334 题实验中两次自动候选的生成、审校、小批和整体评测合计约 3 分 23 秒与 3 分 25 秒，回放并发为 8；计时不含初始基线、收口复测、历史种子重测、报告和人工验收。
- 04作者区分三类证据：业务正文/工具定义回答「能否做到」，人工确认的职责规则回答「应该由谁先承接」，回放轨迹回答「模型实际选了谁」，三者不能互相代替。
- 05description 设置 600 字符上限，并要求先替换错误边界、合并重复、删除冗余，再考虑新增，以防规则越加越窄的过拟合。
反方 / 局限
- — 91.18% 是开发集选优结果，当前没有独立留出集，历史题已用于诊断和选优，不能代表未见请求或线上完整任务的成功率。
- — 本次同时修改了两份简介，尚不能分离查询侧与通知侧描述、以及各句编辑的独立贡献；单侧与联合修改的对照是后续方向，不是已完成实验。
- — 剩余 3 题分别涉及综合分析与单项查询、组合编排与前置查询、计划创建与业务执行的冲突；首路由正确不等于后续执行成功，模拟器工具返回仍是受控模拟。
概念锚点
前置背景
平行视角
未来推演
延伸追问