Harness 的实践：使用skill search 提高 skill 调用准确度
最近给自己的 Agent 做了一次关键的改造。表面上看，只是新增了一个 Skill Search 工具，但真正改变的，是 Agent 的工作方式。 以前 Skill 的调用非常不稳定。明明已经很明确告诉它"搜索天气"“搜索新闻”，也提供了相应的工具，但它就是不能自动触发。尝试优化提示词、改进 Skill 描述，做了很多尝试，效果都不理想。 后来看到 Claude Code 的源码，里面有一个 Tool Search 机制：每次使用工具之前，先查询一下有没有可用工具。受这个启发，我做了一个 Skill Search 工具，希望在 Agent 触发能力边界时——比如需要搜索网络、写脚本、调用外部命令时——先检查有没有现成 Skill 可以用，而不是从头造轮子。 核心问题 原来的 Skill 调用机制是这样的：把所有 Skill 的名字和描述都塞进系统提示词里，然后告诉模型"如果当前任务适合某个 Skill，就优先使用"。 这个思路一开始是成立的，模型确实"看得到"这些 Skill，也能在某些场景下主动调用。但真正用久了之后，问题就暴露出来了。 只有显式调用才稳定。当直接输入 /web-search 或明确指定某个 Skill 时，没问题——因为这时候不是模型在判断，而是用户替它做了决策。但真实使用中，用户更常见的表达是： “帮我搜一下这个话题” “去网上查一下最近有什么信息” “看看有没有现成工具能做这件事” “帮我处理一下这个文件” 这些输入对人类来说已经足够明确，大家都知道这时候应该优先检查 Skill。但模型不是每次都这么做。很多时候，明明已经有现成 Skill，它还是直接跳过去，自己动手。 根本原因不是 Skill 描述不够好，而是机制本身有问题。 原来的调用流程太长了：模型先看用户输入，再判断是否需要执行任务，再回忆提示词里有没有对应 Skill，再匹配描述，最后才决定要不要调用。只要其中任何一步松掉，它就会进入更省事的路径：自己来做。 随着 Skill 越来越多，问题还会继续恶化。Skill 越多，提示词越长，模型越容易漂移。这些 Skill 只是混在上下文里的动态信息，对模型来说不是强制执行的流程，只是可能参考的背景材料。 改造方案 核心上做了三件事。 1. 从隐式到显式 把 Skill 从"提示词中的隐式能力"变成"运行时中的显式能力"。新增真正的 skill_search，让 Agent 在面对非纯文本任务时，不是默认自己动手，而是先查有没有现成 Skill。 ...