AI 智能体工具可见性危机：53% 新装技能无法被发现

Next AI Labs 在一项人机协作研究中发现，多智能体系统中最隐蔽的失败模式不是「工具损坏」，而是「工具可用但无人能找到」。研究团队在一个会话内并行安装了 15 个 AI 技能，全部通过功能测试，但随后进行的「可发现性审计」显示，其中 8 个对任何后续智能体都完全不可见，占比 53%。

问题的提出：能力可见性差距

在人类团队中，机构知识的流失通常会通过流程故障、新人提问等方式被察觉；AI 智能体却缺少这一反馈回路。当某个智能体构建了一个其他智能体无法发现的工具时，系统不会报错，也不会发出告警。该工具静静躺在目录中，功能完整，却在后续遇到相同问题时被完全绕过——更糟的是，缺少安全审计的代码可能直接被发布上线。

研究团队将这一现象命名为「不可见能力」（invisible-capability），并提出「能力可见性差距」（capability-discoverability-gap）概念：用得越久，系统表面上越强大，实际效率却可能越低。

案例细节：三阶段并行安装

为了填补一个生产级 API 平台在安全、代码质量与可观测性方面的能力空白，研究团队设计了一个三阶段的并行安装流程：

• 第一阶段（4 个外部安全技能）：OWASP Top 10 检查、Trail of Bits 的六项审计方法（含不安全默认值检测、变体分析、差异评审、Sharp Edges 识别、静态分析、Semgrep 规则创建）、破坏性命令安全网，以及 Anthropic 官方技能库。
• 第二阶段（3 个基础设施工具）：用于实时调试的只读 MongoDB 连接器、用于端到端测试的 Playwright 浏览器自动化、用于智能体配置文件的配置检查器。
• 第三阶段（7 个基于代码库分析的自研技能）：控制器提取工作流（用于拆解 2,500 行大文件）、代码库专属的 React 组件模式、静默失败检测器、系统可观测性标准、API 错误处理规范、按端点的安全检查清单、规范化的测试夹具。

每个阶段都以并行子智能体运行，所有 15 个工具在单一会话内完成安装，并全部通过功能测试。

审计结果：自定义技能全部可见，外部技能全军覆没

研究团队随后对每个技能提出一个简单问题：未来遇到相关问题的智能体能否通过自动发现机制找到它？结果非常鲜明：

• 自研技能：7 个全部可发现，发现率 100%。
• 外部技能：8 个全部不可见，发现率 0%。
• 整体：15 个中可发现 7 个（47%），不可见 8 个（53%）。

差异的根源极为简单：自研技能在编写时就内嵌了「触发关键词」元数据，供匹配系统把智能体查询与对应技能连接；而来自安全研究机构与开源仓库的外部技能，恰恰缺少这三到五行 YAML 配置。例如，一个覆盖整个 OWASP Top 10 的安全技能，因没有触发关键词，在智能体编写认证代码时被完全忽略；如果加上「security vulnerability」「injection prevention」「XSS prevention」「security review」这类触发词，技能就会在遇到安全相关代码时自动激活。

五条发现通道，五种失效模式

研究还梳理出智能体发现工具的五条独立通道，并指出每条都有对应的失效场景：

• 通道一：协议自动列出——注册到协议服务器的工具会被自动展示；失效场景是使用智能体未挂载该服务器。
• 通道二：触发词匹配——元数据中的关键词与当前任务匹配；失效场景是缺少触发词导致零匹配。
• 通道三：工具注册中心（数据库支撑）——可通过 slug、标签、分类搜索，并可人工审计；失效场景是工具从未注册，未进入索引。
• 通道四：语义群体搜索——跨会话、研究、工具、意图的向量嵌入；失效场景是工具过新或描述过于泛化。
• 通道五：（原文在此处截断）

研究团队将「自审计可发现性」列为多智能体工具链中缺失的关键一环，并建议在每一次安装技能后立即运行发现审计，避免「看不见的能力」在系统中静默累积。