1. 先想清楚Agent时代为什么应用发现不能只靠搜索AI Agent能做很多让人兴奋的事但真正让我觉得“这玩意儿终于不再是聊天机器人”的反而是workbuddy里一个听起来不太起眼的模块——“发现应用”。它解决的痛点特别朴素你知道自己有个问题要解决但不知道用什么工具解决。放在以前你会打开搜索引擎输入几个关键词翻十几页结果逐个点开官网看功能对比再翻几篇测评最后凭感觉挑一个试错几天再换。这个过程少则半天多则一周。而workbuddy的“发现应用”本质上是把这个流程整体交给Agent去跑你只需要用自己的话描述场景它负责拆解需求、多路检索、交叉验证最后给你一份带证据、带取舍逻辑的推荐方案。这个模块适合谁来用我觉得覆盖面其实很广。做技术选型的人需要它产品经理调研竞品工具需要它甚至一个普通用户想找个好用的笔记软件、问卷调查工具、视频剪辑工具也会需要它。区别只在于需求复杂度。它不适合的是那种只想要“随便推荐几个”的场景——那用传统推荐系统就够了杀鸡不用牛刀。我在设计这个模块时最先做的一件事不是画架构图而是追问了一个问题为什么不能靠搜索解决答案比想象中更本质。传统搜索的前提是“用户知道自己要找什么”它的输入是关键词输出是候选列表剩下的筛选、验证、决策全部由人完成。但真实的工具选型场景里绝大多数人的状态是“我只知道我遇到的问题不知道市面上有什么方案”。举个很常见的例子一个团队想做一个内部用的问卷系统要求免费用、手机能打开、能导出数据、最好不用自己维护服务器。这句话里没有一个关键词能搜到正确答案因为“问卷调查工具”是个泛目录而“不用自己维护服务器”指向的是SaaS形态“能导出数据”指向的是数据主权“手机能打开”指向的是响应式设计——这些全都是约束条件不是关键词。搜索引擎擅长匹配词不擅长匹配约束。所以“发现应用”这个功能定调就不是“搜索的替代品”而是“工具选型参谋”。它要做的不是给你一百个链接而是像一位对行业工具链很熟的同事问你几个关键问题心里过一遍候选集再结合你所在团队的技术栈、预算、维护能力给你一个带顺序、讲理由、说代价的答案。这个定位决定了它的架构走向光有检索能力不够还得有解析需求的能力光有推荐能力不够还得有验证信息的能力。一句话总结就是它得具备完整的“规划—执行—验证”闭环而这也是我坚持用Agent范式来做、而不是单纯堆一个语义搜索引擎的原因。2. 核心设计拆解需求解析、多路发现与可信评估“发现应用”看起来是一个功能点拆开看其实是三层服务的串联。第一层是需求理解把用户那段口语化的描述翻译成可执行的约束集第二层是候选发现再根据约束集去不同的数据源把符合条件的工具捞回来第三层是可信评估把候选集按场景匹配度排序并给每个结论附上来源依据。每一层单独拎出来都不算新鲜但把它们串成一个服务并且让整个链路能在几十秒内跑完、结果还能让用户愿意相信这才是真正的难点。2.1 需求解析层把模糊语言变成可检索的约束集这一层的输入是用户的自然语言输出是一份结构化的约束清单。很多人会以为这不就是让大模型抽个关键词吗实际上工程上比这复杂。我遇到的第一个问题是“显式约束”和“隐式约束”的区分。显式约束是用户明说的比如“要支持导入OpenAPI文档”这个直接进硬约束隐式约束是用户没说但能从上下文推导出来的比如用户说“团队五六个人用”这背后隐藏着对协作能力、权限管理、免费版席位上限的约束团队规模这个东西检索用不上但它直接影响排序权重。为了解决这个问题我设计了需求解析的固定输出模板强制Agent按JSON Schema返回避免它天马行空。这个模板的核心字段包括字段含义示例purpose用户的根本目标团队协作调试接口object_type要找的东西是什么类型接口调试工具hard_constraints硬性约束缺一不可支持OpenAPI导入、支持团队协作soft_constraints软性约束影响排序最好有免费额度、界面中文context场景上下文影响评估权重团队5-6人、非生产核心链路risks用户可能没意识到的风险点免费版可能有请求数限制这里有个很关键的经验不要试图在解析阶段把所有事情都做完美。用户说的话里有歧义、有自相矛盾、有信息空缺这是常态。你的目标不是让Agent变成通灵师而是让它把“确定的”变成硬约束把“缺省的”标记为待确认项把“模糊的”拆成多个子假设。后续在结果输出时再针对待确认项给用户附带追问建议。比如用户说“最好免费”Agent就应该标记为软约束并在推荐结果里明确提示“该工具免费版限制为每月X次请求超出部分按量计费”而不是简单地把免费两个字当成硬性指标。2.2 多路发现层搜索引擎、开源社区与榜单数据的协同调度约束集出来后下一步是把它们变成检索动作。我踩过的第一个坑就是图省事把所有约束拼成一个长查询丢给搜索引擎。结果很惨烈查询词太长搜索引擎根本匹配不到什么有效结果召回率非常低。后来我把策略改成了“查询词生成 多路并行召回”效果立刻不一样。查询词生成不是简单把约束拼起来而是针对不同数据源分别生成不同的查询表达。同样是找接口调试工具丢给通用搜索引擎的查询是“API调试工具 推荐 对比”丢给开源社区的查询是“API调试 client 工具”丢给应用市场类数据源的查询则是“接口调试工具 协作 内置”。同一意图不同数据源的词汇偏好完全不同单一查询喂给所有渠道一定有一半渠道什么都搜不到。数据源的选择也是有讲究的我把它分成四类每一类承担不同的验证职责应用市场类数据源提供权威功能列表、版本信息、评分与下载量用来做功能匹配和平台兼容性判断。缺点是比较“官方腔”对真实使用体验描述不足。开源社区类数据源提供star数、issue数、最近提交时间、项目描述用来判断技术类工具的活跃度与健康度。缺点是对SaaS类工具覆盖很差。讨论社区类数据源提供真实用户的使用感受、踩坑经历、替代方案推荐用来补充口碑信息。缺点是信息密度低需要做观点聚合。官方站点类数据源提供定价、免费额度、功能对照表、文档结构用来验证成本和部署方式。缺点是营销成分重需要交叉验证。多路召回的工程实现上我用的是并发调度加超时控制的方案。每一路检索都是独立的执行单元设置统一的超时阈值默认3000毫秒超时就直接放弃该路结果用剩余路径兜底。所有路径返回后进入合并阶段合并的依据是“应用指纹”——名称加上发行方加上主版本号三个字段都一样才算同一条应用否则视为不同候选。听起来简单但实际操作中名称变体特别多比如一个工具官方叫A社区里叫“A神器”第三方文章里叫“A工具合集”去重逻辑里得做一层别名归一化否则同一个工具会在候选集里出现三次严重影响后面的排序环节。2.3 可信评估层用场景匹配度而不是下载量来排序候选集合并之后通常会有10到30条结果接下来是最容易出彩也最容易翻车的环节评估排序。我见过很多推荐系统偷懒的做法是把下载量、评分、知名度当成排序依据那本质上还是“从众推荐”跟场景没建立任何联系。workbuddy的做法相反排序依据是“场景匹配度”即这条候选是否真的适合当前这个用户当前这个场景。为了让匹配度可计算、可解释我把评估拆成六个维度功能匹配度、平台兼容性、维护活跃度、成本结构、迁移成本、口碑与风险。每个维度都有一组独立的验证动作。以“功能匹配度”为例Agent不只是看官方描述里有没有这个关键词而是会尝试从官方文档站拉取对应的功能说明页面比对描述细节。比如用户要求OpenAPI导入官方页面写的是“supports OpenAPI 3.0 import”这就算真匹配如果只写了“API support”那就只能算弱匹配需要到讨论区找用户确认。这种验证方式耗时会增加但换来的是推荐结论有据可查。权重的设计上我的经验是不做固定权重而是让权重跟着场景走。个人学习用途和团队生产用途对维护活跃度的要求完全不同。前者软件一个月不更新无所谓后者一个安全补丁推迟一周可能就是事故。所以workbuddy在评估层会先做一次场景分类然后根据场景类型加载不同的权重模板。个人场景里学习曲线和上手成本的权重最高团队场景里权限模型、审计能力、支持响应的权重会被拉高生产核心链路则更看重稳定性指标和商业支持能力。这是一开始就确定的参数不需要变得很复杂它保证的是一个方向正确性具体分数还是要靠人工设计的校验函数去算。另外要特别强调一个原则永远不要把“下载量大”当成“适合你”的证据。下载量大只能说明它被很多人试用过不能说明它已经被很多人持续使用更不能说明它适合你的约束。有些工具下载量巨大但口碑两极分化有些人用得很顺有些人被坑得很惨。workbuddy的策略是下载量和评分只作为候选集准入线进入评分环节后它们的影响力会被大幅稀释重点观察的是与场景直接挂钩的证据。2.4 关键参数与容错设计这里把我在实践中沉淀下来的一组参数分享出来这些数值不是拍脑袋定的基本都是试错试出来的。提示参数需要根据你的数据源响应速度和用户容忍度调整下面给出的是我实测下来比较稳定的基准值。候选集深度初始设为15也就是多路召回合并去重后保留前15条进入评估环节。太少了容易漏掉优质小众工具太多了评估耗时和token开销都吃不消。排序输出阶段控制在Top 5用户能消化的推荐数量基本在3到5个多了就是选择困难。评估阶段的兜底策略是“置信度三级制”从官方页面直接验证过的标为高置信度从社区讨论间接验证过的标为中置信度只有一个来源提到、其他渠道都查不到信息的标为低置信度低置信度结果直接排到最后并且在呈现时明确标注“信息来源单一建议进一步确认”。这个设计非常管用它让Agent在信息不全的时候敢于说“我不知道”而不是硬编一个答案出来。3. 完整实操复盘一次“发现应用”请求的完整流转说了这么多设计不如走一遍真实流程。我带大家完整复盘一次我在测试环境里跑通的典型请求。用户的原话是“找个方便团队协作的接口调试工具要能导入OpenAPI文档最好有免费额度团队五六个人用。”我们来看workbuddy从收到这句话到给出最终推荐中间到底发生了什么。3.1 意图拆解与检索策略落地需求解析层收到用户输入后先完成结构化输出。Agent提取出的结果是对象类型是接口调试工具硬约束为支持OpenAPI文档导入且支持团队协作软约束为最好有免费额度上下文中标记团队规模5至6人、非生产核心链路。这里有个值得注意的细节用户没有说部署方式Agent在risks字段里标注了“用户未明确SaaS或私有部署默认两种形态都纳入候选但在结果中分别说明差异性”。这个解析过程大概用时2到3秒然后进入检索策略生成。规则引擎根据对象类型和硬约束生成了五个并行检索任务。第一个任务是通用搜索查询词被构造成“接口调试工具 团队协作 OpenAPI 免费”第二个任务是商业应用市场检索查询词是“API调试工具 协作版 免费额度”第三个任务是开源社区检索查询词是“API调试 client openapi 协作”第四个任务和第五个任务分别是讨论区口碑挖掘和官方站点定向核查重点追踪前几路结果里出现频率最高的几个名字。3.2 候选集评估与排序逻辑五路检索在约15秒内全部返回经过指纹去重合并后得到12条候选。去掉明显不满足硬约束的4条剩下8条进入评估环节。让我印象最深的是其中一条结论的验证过程有一条候选工具官方功能页明确写着支持OpenAPI导入但在讨论区里有不少用户反馈说导入复杂文档时格式会错乱。workbuddy在做功能匹配度验证时除了看官方页还额外搜索了“该工具名OpenAPI导入问题”这样的负面词结果发现近一个月的版本更新记录里正好有一条“修复OpenAPI 3.1导入兼容性问题”。这说明官方已经在补这个坑但还没有完全解决。Agent最终对这条候选打了功能匹配“高”但同时给了一条风险备注“复杂文档可能存在兼容问题建议先拿实际文档做验证”。这种有出处的风险提示远比一句干巴巴的“不错”有说服力。排序阶段由于场景被归类为“团队协作、非生产核心链路”权重模板会自动把协作能力、免费额度、学习曲线放在前面维护活跃度权重适中商业化能力权重降低。最终得分排在前面的三个工具各有特色第一个是免费额度相对宽裕且协作功能完整的商业产品第二个是开源项目但界面和配置稍简陋第三个是一个较小众但导入兼容性口碑特别好的新工具。workbuddy不会只推一个结果它给的是一组带差异性的建议因为工具选型这种事本来就不是单解问题。3.3 结果编排与用户交互输出评估完成后Agent会生成一份结论文档但绝不是简单罗列三个名字。它的输出结构是这样的先说结论基于约束条件筛选出的Top选择是哪一个一句话说明为什么它最合适然后用表格对比三个候选在这六个评估维度上的表现让用户一目了然地看到取舍最后是风险提示包括那个OpenAPI兼容性问题、免费版请求上限、以及迁移成本评估——“如果你当前已经在使用另一款工具切换到这款工具的核心成本是数据迁移和成员学习预计需要一到两个工作日”。如果一开始解析出来的约束里有缺省项这里还会附上追问建议比如“您未说明是否需要私有化部署本推荐方案以SaaS形态为主如有私有化需求请告知以便重新筛选”。这意味着整个“发现应用”的请求实质上不是在回答“有哪些工具”而是在回答“在理解了你的处境之后哪个方案在哪些方面更适合你以及在接受这个方案时需要容忍什么”。用户拿到的不只是一串链接而是一个可以拿去直接决策的文档。4. 落地过程中的硬骨头踩坑记录与排查手册任何系统都要被真实流量锤过才知道问题在哪。workbuddy“发现应用”模块在测试阶段就暴露了不少问题这里挑几个最有代表性的记录一下希望能帮后面做同类功能的人少走弯路。4.1 需求歧义带来的检索漂移第一个比较棘手的问题是查询词假如过于宽泛检索结果会整体漂移。有次测试用户输入“找个好用的效率工具”注意这里的“效率工具”在技术语境里含义很模糊。需求解析层没有识别出歧义直接生成了“效率工具 推荐 免费”这样的查询词结果搜索引擎返回的全是各种软件合集文章候选集质量一塌糊涂。后来我在解析层加了一个“查询意图明确度”的预检逻辑如果解析出的object_type过于宽泛Agent必须先通过追问或自行语义补全来收敛。因为系统会自动推导“既然你在workbuddy里问效率工具最可能是办公场景”它会列出几个可能的子场景让用户确认或者直接对多个子场景并行检索、然后各给一组推荐。我自己更倾向于后者因为用户跑到Agent面前就是不想被追问太多轮的多开几个分支检索虽然会消耗一点资源但用户体验会好很多。4.2 数据时效性失效导致的错误推荐信息过期的问题很隐蔽且麻烦。我遇到过一个真实案例有一款早前很流行的工具实际上已经做了一次重大的商业模式调整免费版额度缩水得非常厉害。但我们当时用的缓存数据还是旧版本的信息于是Agent兴冲冲地把它推荐给一个对免费额度有要求的用户结果用户实际打开一看根本不是那么回事。这个问题靠缓存刷新是不够的场景频率决定了你不可能对每个候选工具都做实时全量校正。我是用两个手段处理的一是在评估阶段加了一个“最近变更检测”步骤也就是对进入Top 5的候选额外搜索其近三个月内的重大变更记录包括定价调整、功能下线、被收购等关键词二是建立一份“已知重大变更库”里面手动维护了一批主流工具近期的关键变动。这样即使缓存数据老了在推荐输出前也还有一道安全检查网。4.3 多路结果冲突的仲裁策略多路召回的另一个问题是信息冲突。常见的情况是开源社区对这个工具好评如潮但官方支持文档非常简陋或者商业榜单把它排得很高但讨论区里全是吐槽。这种情况下到底相信谁的我的方案是按场景类型做仲裁。工具如果面向开发者开源社区的真实使用反馈权重就要高于商业榜单工具如果面向普通办公用户官方文档和实际易用性评价权重更高。如果各路证据实在无法调和Agent的默认动作是“不武断下结论”而是把冲突点直接列给用户看让用户结合自身偏好决策。很多时候AI Agent并不需要永远给出唯一的正确答案给出有依据的两难处境反而是更高水平的帮助。4.4 性能瓶颈与缓存优化一次全流程的“发现应用”请求早期串行实现大概要45到60秒。大量时间花在等待各路HTTP请求返回上用户等得很焦虑。后来做了三个优化第一是检索阶段全面并发化把总耗时压缩到20秒以内第二是引入分级缓存对高频工具的基础信息做24小时缓存对评估结果做15分钟缓存热门检索场景直接从缓存取结果第三是把“初步推荐”和“深度验证”两阶段分离先基于解析结果和缓存信息给出前三名快速推荐深度验证包通过流式输出补充用户体感上会觉得Agent非常快而且还在持续思考。这个体验优化很值得大家借鉴。4.5 常见问题速查表我把测试期间遇到的高频问题整理成了速查表方便实现时对照检查。问题现象可能原因排查与解决思路检索结果与需求明显无关查询词生成过于宽泛检查需求解析层的object_type是否太抽象增加子场景分支检索同一条候选在结果里出现三次应用指纹归一化不完善补充别名变体映射名称加发行方联合判重推荐了已停更或已收费的工具缓存数据过期未验证增加Top候选的最近变更检测步骤维护已知变更库不同数据源结论互相矛盾缺少场景化仲裁规则按场景类型预设数据源优先级冲突时对用户透明呈现单次请求耗时过长串行调用过多检索并发化分层缓存快速推荐与深度验证分离对工具能力描述失实评估层出现幻觉强制所有能力结论附来源无法验证的标为低置信度5. 后续演进方向与一点个人体会“发现应用”做出来后我立刻发现它的边界不止于推荐。用户选好工具之后紧接着的问题是“怎么落地”——新工具的部署步骤、配置方法、数据迁移、团队开通这些都是确定的、可指导的流程完全可以接到Agent的后续动作上。workbuddy目前的规划是打通“发现—决策—落地”的闭环发现应用模块给出推荐之后用户确认选择Agent直接生成部署脚本、配置文件模板、团队开通指引甚至移动到目标应用的相关文档里提取具体配置参数。这样一来用户从“说一句话”到“工具真正跑起来”全程不需要跳出对话窗口。这个延伸听起来很顺理成章但实际做起来又是另一层复杂度尤其是不同应用的配置差异很大需要为每个高频落地场景单独维护模板和校验规则工作量并不小。就我个人的实际感受而言做这种工具选型类的Agent最大的心法其实是“克制”。你很容易在各种环节上过度发挥多塞几个数据源、多列几个评估维度、多生成几段分析文字。但用户真正需要的是围绕他那几个真实约束给出简洁、可验证、能直接行动的答案。多出来的信息在决策场景里都是噪音。我把这个原则内化成了实现里的很多默认行为候选集只留15条、Top推荐只给3到5个、结论必须带来源、风险必须透明呈现、不确定就明说。每一条都是在对抗“看起来聪明”的诱惑。最后再分享一个对团队很有价值的小技巧把重复出现的推荐场景沉淀成“发现模板”。比如“客户调研工具推荐”“招聘系统选型”“团队项目管理工具对比”这些高频请求值得把解析策略、权重模板、常用数据源事先固化下来下次用户再遇到同类问题时Agent可以直接走模板响应速度和结果稳定性都会好很多。这个思路本质上就是把一次性的智能行为变成可持续复用的组织资产。
