摘要
昨天我处理了一个看起来很小、实际很基础的问题：一个技能已经存在了，为什么当前工作台还是用不上？
这类问题如果只看表面，很容易变成“找一下文件在哪里”。但我更关心的是另一件事：一个技能从“躺在某个目录里”到“被多个 agent 稳定发现和调用”，中间到底少了哪一层？我最后把它理解成一个能力注册问题，而不是一个文件管理问题。
这篇文章讲的是我的处理思路：先确认源技能，再确认发现机制，最后把它接入统一索引。长期看，这能减少重复复制、版本漂移和每次重新解释的成本。
目录
- 问题不是有没有文件，而是能不能被发现
- 我怎么拆这类技能接入问题
- 为什么我更倾向于链接而不是复制
- 这样做的好处
- 长期收益
- FAQ
问题不是有没有文件，而是能不能被发现
我一开始面对的问题是：某个知识库类技能在一个系统里存在，但在当前工作台的技能列表里看不到。这个时候最容易犯的错，是只回答“有”或者“没有”。
但对一个多 agent 工作台来说，“存在”其实有几种状态。
一种是源文件存在。也就是说，技能说明、脚本和相关资料都在某个地方。
第二种是当前 agent 能发现它。这里涉及 manifest、索引、技能目录和启动时注入的信息。
第三种是用户真的能自然触发它。也就是说，它不只是被列出来，还要有清楚的描述、触发语和适用边界。
如果只满足第一种，这个技能其实还不能算接入完成。它只是“有”。但用户需要的是“可用”。
我怎么拆这类技能接入问题
我会按三步看。
第一步，看源技能是否存在。这个阶段只确认事实，不急着改东西。我需要知道这个技能的主说明、版本、描述和原始位置。
第二步，看当前工作台的发现层。也就是它有没有出现在技能清单、索引文件或 manifest 里。如果没有，那问题就不是技能内容，而是注册机制。
第三步，看它是不是适配当前生态。比如有没有面向不同 agent 的元数据，描述是否能被检索，是否有足够明确的触发条件。
这三步拆开以后，事情就清楚了：不是“这个技能坏了”，而是“它没有进入当前工作台的发现路径”。
为什么我更倾向于链接而不是复制
我没有选择把源技能复制一份。原因很现实：复制是最容易开始、最容易欠债的做法。
今天复制一次，明天源技能更新了，副本就可能落后。后天另一个 agent 又复制一份，三份内容慢慢长得不一样。等真正出问题时，你甚至不知道该相信哪一个版本。
所以我更倾向于建立一个指向源技能的链接，再补上索引和注册信息。这样做的核心思想是：源头只有一个，发现入口可以有多个。
这更像“把能力注册进工作台”，而不是“搬运一份文件”。
这样做的好处
好处首先是维护成本低。源技能更新后，接入侧不用重新同步一份静态内容。
其次是边界更清楚。源技能负责能力本身，当前工作台负责发现和调用。两个职责分开，后面排查问题也更容易。
还有一个不太显眼但很重要的好处：用户不用知道背后的目录结构。只要技能能被工作台识别，用户就可以用自然语言触发它。
长期收益
长期来看，这件事是在给多 agent 工作台建立统一的能力层。
当每个新技能都能按同一种方式进入索引、被发现、被调用，后面增加能力就不会变成一次次手工接线。知识库、发布工具、研究流程、内容生成流程，都可以用同一种方法接入。
这会带来一个很实在的收益：我不用每次都重新解释“这个能力在哪里”，agent 也不用每次都重新猜“我能不能用它”。
FAQ
技能存在，为什么还不能直接用？
因为存在只是第一步。当前 agent 还需要能发现它，并且知道什么时候应该调用它。
为什么不直接复制一份？
复制会产生版本漂移。链接或统一注册更适合长期维护。
这类接入最应该检查什么？
我会先看三个东西：源技能、当前工作台索引、触发描述。三者缺一，体验都会断。