【AI 营销】从 Tool Discovery Agent 到“工具市场”:构建一个可搜索、可评估、可部署的 基础设施
# 从 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 仓库地址，也有人会发一个社媒帖文链接，甚至有人查询的是“某个本地架构如何组织记忆存储”。 系统的第一步不是抓取，而是先把这些输入统一成稳定结构，例如： 这一步看似基础，实际上是整个系统稳定性的起点。输入归一化做得好，后续 provider、评分器、导出器都能稳定工作；做不好，后面所有模块都会被输入噪声拖着走。 ### 2. Provider 路由层 统一输入后，系统进入 provider 层。不同来源的数据结构完全不同，因此不能用同一套抓取逻辑硬吃所有来源。 第一，不同来源的字段抽取逻辑被隔离了，因此系统能逐步增强，而不会相互污染。 第二，对受限平台不做“静默失败”。例如某些平台如果没有登录态，系统不应该假装“没搜到”，而应该显式创建一个 `handoff`，告诉上层：这里需要人工或浏览器代理继续接手。 这保证了系统在现实世界中的行为是可解释的，而不是黑盒。 ### 3. 样本抽取层 Provider 拿回来的原始数据还不是资产。真正可复用的是归一化后的研究样本，也就是 `ResearchSample`。 这组字段的意义，在于把一条帖子、一个网页、一个仓库，从“内容对象”转化为“研究对象”。 `problemFrame`：工具到底解决了什么问题。 `toolPositioning`：它是终端产品、工作流组件、接口能力，还是架构参考。 `workflowDepth`：它是单点工具，还是全链路方案。 `reuseSignal`：它更适合直接使用、借思路、借架构，还是适合本地化部署。 如果没有这一步，后面的推荐就会退化成“看起来很厉害”的表面判断。 ### 4. 候选构建与评分层 样本并不直接面向业务决策。真正被业务使用的是候选项，也就是 `CatalogCandidate`。 其中最实际的一层，是产品拆解。它直接回答下面这些问题： 而另一层同样关键的结构，是第三方评价信号。用户不只想知道“官方怎么介绍自己”，还想知道“别人用过之后怎么说”。因此系统必须显式区分： 在这套结构之上，系统再根据固定维度执行评分。当前评分维度覆盖： 最后给出明确结论：`watch / evaluate / adopt / integrate / reject`。 ### 5. 导出与分发层 前面四层解决的是“如何发现并判断”。最后一层解决的是“如何对外提供稳定结果”。 而为了接入宿主平台中的“工具市场”单页，我们又增加了一层专门的市场导出格式。它不再只是研究报告，而是一套能被页面直接消费的“工具市场数据协议”。 ## 三、为什么必须引入“工具市场导出协议” 如果直接在前端里临时拼接字段，短期很快，长期一定失控。你很快就会遇到这些问题： 增加一个“是否支持本地部署”的维度，需要前后端同时重构。 未来不止一个宿主页面要接这套数据，但当前结构已经绑死。 同一个工具既要用于卡片摘要，也要用于详情页说明，却没有统一字段模型。 访问量和下载量未来会来自不同来源，但页面没有指标状态位。 所以我们把这部分独立成了 `ToolMarketExport` 协议。 每个 `ToolMarketEntry` 至少包含以下部分。 ### 基础信息 包括名称、摘要、分类、来源平台、营销链路、当前结论等。这部分主要服务搜索结果卡片，是用户的第一层认知入口。 ### 访问信息 包括官网、开放访问链接、访问模式、是否需要登录。这一层直接服务“先试一试”的需求。 ### 分发信息 包括 Web、源码、Docker、桌面包等安装方式。这部分服务“怎么拿到这个工具”和“是否适合交给技术侧部署”的问题。 ### 部署与操作指南 这是工具市场最不能缺的部分。每个工具至少都要输出： 也就是说，页面不只是展示工具，而是明确告诉用户：值不值得试、试之前怎么准备、如何部署、如何实际使用。这使它从“目录页”变成“可执行入口”。 ### 指标层 这里有一个非常现实的系统设计取舍：很多公开产品并不会直接暴露访问量或下载量。如果为了“数据完整”而用模糊估算去填充，反而会污染判断。所以系统引入了 `collectionStatus`，把指标区分为： 这意味着页面可以诚实地展示：哪些数据是真抓到的，哪些只是代理信号，哪些还没有采集到。 ## 四、“工具市场”在宿主平台中的角色，不是展示层，而是能力前厅 如果从产品表层理解，工具市场像一个搜索单页。但从系统边界理解，它更像宿主平台的“能力前厅”。 宿主平台本身承担的是创作、自动化、文生图、文生视频、图生视频、agent 等真实工作。用户不是来“看工具资讯”的，而是来完成任务的。因此工具市场必须承担三件事。 ### 第一，做能力发现 用户可能知道自己要“做一个分镜生成工作流”，但不知道该从哪些工具开始。系统需要通过关键词、分类和场景筛选，快速给出一组候选工具。 ### 第二，做能力解释 用户看到一个工具后，不会只关心它叫什么，而会关心： 因此工具市场不能只显示简介，还必须显示价值说明、工作流角色和限制项。 ### 第三，做接入前的缓冲层 并不是每个被发现的工具都应该立刻接入主工作流。很多工具需要先试用、先部署、先验证，才能决定是否纳入平台体系。因此工具市场本质上是一层“能力缓冲区”： ## 五、为什么这套系统不能依赖大模型临场发挥 很多团队在做工具推荐时，会习惯性把问题直接丢给大模型：“帮我找几个适合做短视频分镜的工具”“帮我推荐几个可以本地部署的视频工作流”。这样做短期有用，但长期一定漂移。原因很简单： 固化的方式不是“完全不用模型”，而是把真正关键的部分工程化： 模型可以参与总结和补充，但不能成为主链路的唯一判断器。否则工具市场就会退化成“每次都重新生成的推荐页面”，而不是一个可靠的能力基础设施。 ## 六、当前实现的价值与边界 从系统落地状态看，这套机制已经完成了一个关键跃迁：从“工具发现 agent”变成“可供产品前端直接消费的工具市场输出端”。 第一，访问量和下载量的真实采集器还没有完全补齐。结构已经预留，但很多工具当前只能输出 `missing`，或以 GitHub stars 作为代理信号。这是合理的阶段性状态，但不能被误解为最终完成。 第二，系统当前已经能稳定输出“工具市场数据”，但还没有完全展开成最终前端实现。也就是说，后续仍需要一个页面层，把这些 JSON 映射成真正的搜索栏、筛选器、工具卡片、详情抽屉和试用入口。 换句话说，底层协议和数据结构已经稳定，下一步应该优先做的是页面承载和指标采集，而不是重新发明一套字段模型。 ## 七、这套设计真正的长期价值 从长期看，这个系统最重要的价值，不在于它能不能列出 1000 个工具，而在于它能不能成为组织级的“工具认知操作系统”。 一个成熟团队在使用 AI 工具时，最稀缺的并不是信息，而是判断。判断哪些工具值得投入，哪些只适合参考；判断一个工具适合品牌营销、内容营销还是真人营销；判断一个工具是终端产品，还是应该被拆成 agent 中的一步；判断它应该交给内容团队、增长团队、技术团队还是自动化团队。 如果这套判断每次都重新依赖临场搜索或大模型对话，结果一定会漂。如果把这些判断逻辑、字段结构、导出协议和运行链路逐渐固化成稳定系统，那么工具发现就不再是一件依赖“某个特别懂工具的人”的手工工作，而会变成一种可被团队继承的基础能力。 这正是 `Tool Discovery Agent` 和“工具市场”组合的真正意义： 后者负责把结构化资产变成可搜索、可试用、可评估、可接入的统一入口。 一旦这两层打通，工具市场就不再只是一个页面，而会变成整个智能工作台的能力入口层。 ## 结语 AI 工具生态接下来只会更复杂，不会更简单。创作类工具、自动化类工具、agent 框架、模型接入层、部署方案、垂直工作流组件会继续高速分化。对于任何一个想把 AI 真正变成生产力的平台来说，最需要的不是再做一个“推荐列表”，而是建立一套从发现到评估、从试用到部署、从部署到接入的稳定机制。 `Tool Discovery Agent` 的意义，在于把“工具发现”从资讯工作变成工程工作；而“工具市场”的意义，则在于把这些工程化结果真正暴露给用户，让用户能够以更短路径完成认知、试用、判断和接入。 如果说过去我们面对 AI 工具像是在逛展会，那么这套系统真正想做的，是把展会变成仓库，把仓库变成标准接口，再把标准接口变成工作流的一部分。 当这件事真正做成，工具市场就不再只是一个内容页，而会成为整个统一智能工作台中的能力前厅和决策基础设施。
夜雨聆风
