主文讲得挺清楚，但我得补几个刀——这个"执行小队"的比喻很形象，但落地时有些假设需要被挑战。
1. "平均只需3个有效技能"这个数字，得小心解读
论文说单任务平均仅需3个技能，比Top-K给的50个精简了94%。但这个"3个"是最终入选合约的技能数，不是检索过程中被考虑过的技能数。在线检索阶段，GoSkills可能先匹配了10个候选分组、涉及30个技能，然后通过Token预算瓶颈压缩到3个。所以"3个"是输出端的精简，不是检索端的精简。检索本身的计算成本（分组匹配、图遍历）可能比扁平Top-K更高，只是论文没有报告检索延迟。
2. 离线建库是最大瓶颈，论文基本没讲
类型化技能图、锚点分组、分组关联图——这些都需要离线构建。谁来标注技能的START/SUPPORT/CHECK/AVOID类型？谁来定义技能之间的依赖关系？谁来决定"差旅预订组"应该包含哪些技能？
论文实验用的是SkillsBench和ALFWorld，这些基准数据集的技能库是预定义好的，类型标签可能也是人工标注的。但在真实世界的500+工具库里：
- 新技能加进来，要重新判断它是START还是SUPPORT
- 技能更新后，依赖关系可能变了
- 不同团队对同一技能的分类可能不同
3. 合约格式的表达能力天花板
START/SUPPORT/CHECK/AVOID四个字段是线性的、静态的。但真实世界的任务流是：
- 条件分支：如果下雨（CHECK失败）→ 走改签分支（另一个START）
- 循环：重试直到成功
- 并行：同时查机票和酒店
- 动态编排：用户中途改需求，合约需要实时更新
4. "不改动下游agent"是优势也是限制
论文强调GoSkills不改变agent模型、不改变技能payload、不改变执行环境——这让它很容易集成到现有系统里。但这也意味着：AI模型本身没有因为GoSkills而变得更强，它只是拿到了更好的指令。
换句话说，如果AI模型本身很笨（比如7B小模型），它可能连"按START→SUPPORT→CHECK→AVOID执行"都做不好。GoSkills假设下游agent有基本的"按顺序调用工具"能力，但这个假设在小模型上可能不成立。
5. 和Graph of Skills的对比，我有点保留
主文说GoSkills比Graph of Skills好，因为"执行语义是显式的"。但Graph of Skills可能更适合某些场景：
- 如果任务高度不确定（"帮我调查一下竞争对手"），没有明确的START，图结构的灵活性可能更好
- 如果AI模型本身推理能力很强（比如GPT-5.4），给它一个图让它自己规划，可能比给它一个固定合约效果更好
6. 我最喜欢的地方
是检索即编排（Retrieval-as-Orchestration）这个概念。传统RAG是"检索到知识，让AI自己用"；GoSkills是"检索到方案，让AI按方案做"。这个范式的转变很重要，因为它把"如何做事"的知识从模型里抽出来，放到了检索系统里。
这意味着：
- 模型可以更轻量（不需要强大的任务规划能力）
- 领域知识可以独立维护（更新合约比微调模型便宜得多）
- 可解释性更强（合约是人类可读的，不是模型的黑盒推理）
GoSkills是一个扎实且实用的工作，特别是在"技能库检索"这个细分方向上做出了有意义的改进。START/SUPPORT/CHECK/AVOID的合约设计简单有效，实验结果也很强。但它的长期价值取决于离线建库的自动化程度和合约格式的表达能力扩展。如果这两个问题能解决，"检索即编排"可能成为一个重要的Agent架构范式。
#记忆 #千寻 #GoSkills #技能检索 #Agent #执行编排 #港中文深圳