从 Tool Discovery Agent 到“工具市场”：构建一个可搜索、可评估、可部署的 AI 工具基础设施

过去一年，AI 工具的增长速度已经远远超过大多数团队的吸收能力。每天都有新的文生图产品、新的视频工作流、新的 agent 框架、新的 GitHub 开源项目出现。问题早就不是“有没有工具”，而是“面对海量工具，团队如何建立一套稳定、可复用、可持续演进的发现与接入机制”。

很多团队在这个阶段都会掉进两个典型误区。

第一个误区，是把“工具发现”理解成简单的信息收集。于是大家每天收藏链接、转发帖子、保存 GitHub 仓库，最后沉淀出一个越来越庞杂的书签池。它看起来很丰富，但几乎不能直接支持业务决策。真正关键的问题，比如“这个工具适不适合品牌营销链路”“能不能本地部署”“是否可以给业务方一个开放访问链接试用”“能否被纳入现有 agent 架构”，往往并没有被结构化回答。

第二个误区，是直接把工具发现做成一个“工具目录页面”。页面上堆满 logo、标题、简介和外链，看起来像市场，但它并不解决团队最痛的部分：评估、部署、试用、落地、复用。一个真正有价值的工具市场，不是把工具摆出来，而是把“工具与业务场景之间的关系”讲清楚，把“工具与交付链路之间的关系”固化下来。

基于这个判断，我们设计了 Tool Discovery Agent，并把它的外部呈现形态定义为“工具市场”。这个工具市场不是一个独立资讯站，而是宿主平台中的一个工具搜索单页。宿主平台本身承担创作、自动化、文生图、文生视频、图生视频、agent 等多种能力，而工具市场在其中扮演的是前置发现入口：帮助用户快速搜索工具、理解价值、判断是否适合试用、明确部署方式，并最终决定是否将其纳入自己的工作流或架构体系。

这篇文章会从技术角度完整拆开这套系统，讨论它的核心设计思路、数据模型、运行链路、导出协议，以及它为什么必须被设计成“能力基础设施”，而不是简单的内容页面。

一、问题本质：我们做的不是普通搜索，而是“带决策语义的工具发现”

如果只看表面，工具市场像一个搜索页：用户输入关键词，系统返回若干候选工具卡片。但从系统设计角度看，这不是一个通用搜索引擎，而是一套“带评估语义的工具发现系统”。

通用搜索引擎关心召回率和相关性，核心目标是“尽量把用户想找的东西找出来”。而工具市场除了“找出来”，还必须回答更深的一组问题：

这个工具解决的是哪一段问题链路。
它更适合创作、营销、自动化还是 agent 编排。
它能直接打开试用，还是必须先本地或云部署。
它是一个终端产品，还是别的业务链路中的一个组件。
它能不能通过 API、MCP、源码、Docker 镜像等方式融入既有架构。
它真正解决了什么，同时没有解决什么。
它有没有足够的市场验证和第三方使用反馈。

这意味着系统不能只存“工具名 + URL + 简介”。它必须建立一套面向决策的数据模型。也正因为如此，Tool Discovery Agent 从一开始就不是一个网页抓取器，而是一个“研究到推荐”的 agent。

它接收任意形式的输入，包括查询语句、URL、仓库地址、账号句柄等；将这些输入归一化为研究请求；根据请求选择不同 provider，从公开网页、GitHub、本地架构、社媒线索中抽取样本；再把样本转换成结构化候选项，执行规则化评分，最终输出同时适合机器和人消费的结果。

这个设计决定了工具市场不是一个静态 CMS，而是 agent 系统的一个“可热插拔输出层”。

二、系统总架构：把“工具发现”拆成五层

整个系统可以拆成五层，每一层都解决一类不同的问题。

1. 输入归一化层

用户输入的形式是高度异构的。有人会输入“storyboard generator website”，有人会直接丢一个 GitHub 仓库地址，也有人会发一个社媒帖文链接，甚至有人查询的是“某个本地架构如何组织记忆存储”。

系统的第一步不是抓取，而是先把这些输入统一成稳定结构，例如：

• id
• kind
• value
• platformHint
• goal
• marketingLane
• requestedBy
• notes

这一步看似基础，实际上是整个系统稳定性的起点。输入归一化做得好，后续 provider、评分器、导出器都能稳定工作；做不好，后面所有模块都会被输入噪声拖着走。

2. Provider 路由层

统一输入后，系统进入 provider 层。不同来源的数据结构完全不同，因此不能用同一套抓取逻辑硬吃所有来源。

当前 provider 大致分为几类：

• local：发现本地仓库中的架构、流程、协议
• github：发现开源项目、README、接口能力、部署信息
• web：发现公开网站、产品页、价格页、API 页、文档页
• youtube / bilibili / x：发现 creator 级样本、工具介绍方式、第三方使用反馈
• wechat-channels：不做隐式跳过，而是生成显式接管任务

这里最重要的设计点有两个。

第一，不同来源的字段抽取逻辑被隔离了，因此系统能逐步增强，而不会相互污染。
第二，对受限平台不做“静默失败”。例如某些平台如果没有登录态，系统不应该假装“没搜到”，而应该显式创建一个 handoff，告诉上层：这里需要人工或浏览器代理继续接手。

这保证了系统在现实世界中的行为是可解释的，而不是黑盒。

3. 样本抽取层

Provider 拿回来的原始数据还不是资产。真正可复用的是归一化后的研究样本，也就是 ResearchSample。

每个样本至少包含以下信息：

• 来源平台
• 作者或站点
• 内容类型
• 原始链接
• 标题
• 开场钩子
• 问题定义
• 工具定位
• 演示切入方式
• 证明类型
• 工作流深度
• 营销链路归类
• 转化设计
• 复用信号
• 原始证据

这组字段的意义，在于把一条帖子、一个网页、一个仓库，从“内容对象”转化为“研究对象”。

其中最关键的是这几个字段：

problemFrame：工具到底解决了什么问题。
toolPositioning：它是终端产品、工作流组件、接口能力，还是架构参考。
workflowDepth：它是单点工具，还是全链路方案。
reuseSignal：它更适合直接使用、借思路、借架构，还是适合本地化部署。

如果没有这一步，后面的推荐就会退化成“看起来很厉害”的表面判断。

4. 候选构建与评分层

样本并不直接面向业务决策。真正被业务使用的是候选项，也就是 CatalogCandidate。

每个候选项包含：

• 摘要
• 价值场景
• 工作流角色
• 集成模式
• 产品拆解
• 第三方评价信号
• 外部情绪摘要
• 评分结果
• 采用结论
• 限制项

其中最实际的一层，是产品拆解。它直接回答下面这些问题：

官网是什么。
价格页是什么。
是否有 API。
是否有文档。
是否需要登录。
是否支持本地部署。

而另一层同样关键的结构，是第三方评价信号。用户不只想知道“官方怎么介绍自己”，还想知道“别人用过之后怎么说”。因此系统必须显式区分：

• 官方内容
• 第三方博客
• 社媒信号
• 视频评测
• 目录引用
• 真实使用反馈

在这套结构之上，系统再根据固定维度执行评分。当前评分维度覆盖：

• 问题是否清晰
• 工作流位置是否明确
• 起效速度是否快
• 集成适配度是否高
• 是否有实用证明
• 是否具备差异性
• 是否与业务目标强相关
• 是否对营销生成力有帮助
• 是否容易借鉴
• 是否具备部署弹性
• 边界是否清晰

最后给出明确结论：watch / evaluate / adopt / integrate / reject。

5. 导出与分发层

前面四层解决的是“如何发现并判断”。最后一层解决的是“如何对外提供稳定结果”。

系统当前至少需要产出两种结果：

• 面向人的 Markdown digest
• 面向机器的结构化 JSON

而为了接入宿主平台中的“工具市场”单页，我们又增加了一层专门的市场导出格式。它不再只是研究报告，而是一套能被页面直接消费的“工具市场数据协议”。

三、为什么必须引入“工具市场导出协议”

如果直接在前端里临时拼接字段，短期很快，长期一定失控。你很快就会遇到这些问题：

后端 agent 输出字段变了，前端全线跟着改。
增加一个“是否支持本地部署”的维度，需要前后端同时重构。
未来不止一个宿主页面要接这套数据，但当前结构已经绑死。
同一个工具既要用于卡片摘要，也要用于详情页说明，却没有统一字段模型。
访问量和下载量未来会来自不同来源，但页面没有指标状态位。

所以我们把这部分独立成了 ToolMarketExport 协议。

这个协议明确规定：

• 外部名称仍然是“工具市场”
• 宿主类型是统一智能工作台
• 页面有固定标题、描述、支持的筛选器
• 每个工具条目有标准结构

每个 ToolMarketEntry 至少包含以下部分。

基础信息

包括名称、摘要、分类、来源平台、营销链路、当前结论等。这部分主要服务搜索结果卡片，是用户的第一层认知入口。

访问信息

包括官网、开放访问链接、访问模式、是否需要登录。这一层直接服务“先试一试”的需求。

分发信息

包括 Web、源码、Docker、桌面包等安装方式。这部分服务“怎么拿到这个工具”和“是否适合交给技术侧部署”的问题。

部署与操作指南

这是工具市场最不能缺的部分。每个工具至少都要输出：

• 评估结论
• 环境准备说明
• 部署步骤
• 操作流程

也就是说，页面不只是展示工具，而是明确告诉用户：值不值得试、试之前怎么准备、如何部署、如何实际使用。这使它从“目录页”变成“可执行入口”。

指标层

指标结构目前包括：

• 访问量
• 下载量
• GitHub stars
• 指标采集状态
• 指标来源说明

这里有一个非常现实的系统设计取舍：很多公开产品并不会直接暴露访问量或下载量。如果为了“数据完整”而用模糊估算去填充，反而会污染判断。所以系统引入了 collectionStatus，把指标区分为：

• reported
• estimated
• missing

这意味着页面可以诚实地展示：哪些数据是真抓到的，哪些只是代理信号，哪些还没有采集到。

四、“工具市场”在宿主平台中的角色，不是展示层，而是能力前厅

如果从产品表层理解，工具市场像一个搜索单页。但从系统边界理解，它更像宿主平台的“能力前厅”。

宿主平台本身承担的是创作、自动化、文生图、文生视频、图生视频、agent 等真实工作。用户不是来“看工具资讯”的，而是来完成任务的。因此工具市场必须承担三件事。

第一，做能力发现

用户可能知道自己要“做一个分镜生成工作流”，但不知道该从哪些工具开始。系统需要通过关键词、分类和场景筛选，快速给出一组候选工具。

第二，做能力解释

用户看到一个工具后，不会只关心它叫什么，而会关心：

它在我的链路里属于哪个环节。
它能否替代现有工具。
它需要什么前置环境。
它更适合 SaaS 试用还是本地化部署。
它真正解决了哪个问题，又没有解决哪个问题。

因此工具市场不能只显示简介，还必须显示价值说明、工作流角色和限制项。

第三，做接入前的缓冲层

并不是每个被发现的工具都应该立刻接入主工作流。很多工具需要先试用、先部署、先验证，才能决定是否纳入平台体系。因此工具市场本质上是一层“能力缓冲区”：

先发现。
再试用。
再评估。
再接入。

它让能力演进变成一个渐进过程，而不是一次性集成。

五、为什么这套系统不能依赖大模型临场发挥

这是一个很关键但常被忽略的问题。

很多团队在做工具推荐时，会习惯性把问题直接丢给大模型：“帮我找几个适合做短视频分镜的工具”“帮我推荐几个可以本地部署的视频工作流”。这样做短期有用，但长期一定漂移。原因很简单：

大模型每次都在重新组织判断过程。
输入表达稍微变化，输出逻辑就可能变化。
不同时间、不同上下文、不同提示词都会改变结论。
这不利于形成稳定的组织级能力。

因此，这套系统的底层逻辑必须尽可能固化。

固化的方式不是“完全不用模型”，而是把真正关键的部分工程化：

输入归一化规则要稳定。
Provider 路由规则要稳定。
样本字段结构要稳定。
评分维度要稳定。
导出协议要稳定。
第三方评价与官方内容的边界要稳定。
指标采集状态要稳定。

模型可以参与总结和补充，但不能成为主链路的唯一判断器。否则工具市场就会退化成“每次都重新生成的推荐页面”，而不是一个可靠的能力基础设施。

六、当前实现的价值与边界

从系统落地状态看，这套机制已经完成了一个关键跃迁：从“工具发现 agent”变成“可供产品前端直接消费的工具市场输出端”。

当前已经具备的能力包括：

• 多输入形式归一化
• 多 provider 发现链路
• 样本抽取与候选构建
• 规则化评分与采用结论
• 官方信息与第三方评价分离
• 工具市场 JSON 导出
• 评估、环境准备、部署说明、操作流程四类标准说明

但同时也要明确当前的边界。

最重要的缺口有两个。

第一，访问量和下载量的真实采集器还没有完全补齐。结构已经预留，但很多工具当前只能输出 missing，或以 GitHub stars 作为代理信号。这是合理的阶段性状态，但不能被误解为最终完成。

第二，系统当前已经能稳定输出“工具市场数据”，但还没有完全展开成最终前端实现。也就是说，后续仍需要一个页面层，把这些 JSON 映射成真正的搜索栏、筛选器、工具卡片、详情抽屉和试用入口。

换句话说，底层协议和数据结构已经稳定，下一步应该优先做的是页面承载和指标采集，而不是重新发明一套字段模型。

七、这套设计真正的长期价值

从长期看，这个系统最重要的价值，不在于它能不能列出 1000 个工具，而在于它能不能成为组织级的“工具认知操作系统”。

一个成熟团队在使用 AI 工具时，最稀缺的并不是信息，而是判断。判断哪些工具值得投入，哪些只适合参考；判断一个工具适合品牌营销、内容营销还是真人营销；判断一个工具是终端产品，还是应该被拆成 agent 中的一步；判断它应该交给内容团队、增长团队、技术团队还是自动化团队。

如果这套判断每次都重新依赖临场搜索或大模型对话，结果一定会漂。如果把这些判断逻辑、字段结构、导出协议和运行链路逐渐固化成稳定系统，那么工具发现就不再是一件依赖“某个特别懂工具的人”的手工工作，而会变成一种可被团队继承的基础能力。

这正是 Tool Discovery Agent 和“工具市场”组合的真正意义：

前者负责把世界上的工具信号转成结构化资产。
后者负责把结构化资产变成可搜索、可试用、可评估、可接入的统一入口。

一旦这两层打通，工具市场就不再只是一个页面，而会变成整个智能工作台的能力入口层。

结语

AI 工具生态接下来只会更复杂，不会更简单。创作类工具、自动化类工具、agent 框架、模型接入层、部署方案、垂直工作流组件会继续高速分化。对于任何一个想把 AI 真正变成生产力的平台来说，最需要的不是再做一个“推荐列表”，而是建立一套从发现到评估、从试用到部署、从部署到接入的稳定机制。

Tool Discovery Agent 的意义，在于把“工具发现”从资讯工作变成工程工作；而“工具市场”的意义，则在于把这些工程化结果真正暴露给用户，让用户能够以更短路径完成认知、试用、判断和接入。

如果说过去我们面对 AI 工具像是在逛展会，那么这套系统真正想做的，是把展会变成仓库，把仓库变成标准接口，再把标准接口变成工作流的一部分。

当这件事真正做成，工具市场就不再只是一个内容页，而会成为整个统一智能工作台中的能力前厅和决策基础设施。

如果你要，我可以继续把这版文章再处理成两种风格：

1. 更偏对外发布的公众号/技术品牌稿
2. 更偏工程团队内部评审的架构博客稿