企业官网建设流程全解析

1. 为什么“技能检索”成了 LLM 智能体落地绕不开的老大难

这两年做大模型应用有个特别直观的变化：大家不再满足于让模型“会聊天”，而是想让模型“会干活”。所谓干活，就是让 LLM 在收到用户需求之后，自己决定调用哪个工具、访问哪个知识库、执行哪条工作流。这个链路里面，模型本身当然重要，但真正决定体验上限的，往往是夹在中间的那个环节——技能检索。

技能检索要做的事情，说穿了就是从一堆工具描述、API 文档、业务流程模板里，找到当前用户请求最需要的那一个。听起来跟传统 RAG 差不多，但实际跑起来完全是另一回事。传统 RAG 检索的是知识片段，内容相对独立，答案对不对可以直接比照原文。技能检索呢？它检索出来的是一个可执行的“动作入口”，这个东西一旦选错，就算大模型再聪明，也只能拿着一个错误的工具做错误的推理，最后给用户一个“看起来很有逻辑、实际上完全没用”的结果。

我自己在做智能体项目的时候，最开始用的方案特别朴素。把所有工具的描述存进向量库，用户一来，Embedding 算一下相似度，Top-K 丢给大模型。结果上线之后发现，用户问“帮我查一下昨天订单”的时候，模型有时候会去调天气接口，有时候会去调客户信息接口，看起来每个接口都沾点边，但就是不对。后来排查半天，发现根子不在模型推理，而在技能召回阶段就已经偏了。

这个问题在行业里其实已经成了一个共识性的痛点。国内外的智能体平台，从 Dify、Coze 到各类企业级 Agent 框架，几乎都在花大力气优化工具调用和技能路由。但是有一个环节一直被忽视：大家嘴上都说“我们的技能检索效果好”，可到底怎么衡量？靠人工看几个案例，靠模型自己给自己打分，还是靠用户点赞率？这些方式要么样本太小，要么太主观，要么信号太滞后，都撑不起一个严谨的评估结论。

我关注到一篇论文，提出的 RAE 方法就是专门来补这个缺口的。它把“评估技能检索的真实效果”这件事本身变成一个可执行的、自动化的流程，目标不是看检索结果长得像不像，而是看这个检索结果放到真实任务环境里，能不能真的帮用户把事办成。这篇文章我想把 RAE 的来龙去脉、设计逻辑、实操步骤和踩坑经验一次性讲透，给正在做智能体技能库、工具调用路由、以及 Agent 质量评估的同学一个可以直接参考的路线。

1.1 智能体不是模型，而是一套路由系统

很多人误解智能体，以为 Agent 就是“一个更强的模型”。但实际做工程的人会告诉你，智能体的本质是一套路由系统。模型只是大脑，而技能库、检索器、工具执行器、记忆模块这些外围设施，才是让大脑真正“动手”的手脚。

技能检索在这个路由系统里处在最前端。它决定了后续所有行为的上限。检索阶段如果出了错，后面模型推理再厉害也只是在错误的地基上盖楼。所以评估智能体的整体表现，第一步必须先盯住技能检索这个环节。这也是 RAE 方法最有价值的地方——它把评估的颗粒度沉降到了“技能能否被正确找到并执行”这个底层动作上。

1.2 传统 RAG 的评估经验，不能直接搬到技能检索上

很多团队最初做智能体功能评估时，都是把传统 RAG 的评测套路拿过来用：准备一批问答对，算召回率、准确率、命中率。但技能检索和文档检索有一个本质区别：文档检索的目标是“找到包含答案的文本”，而技能检索的目标是“找到能够完成任务的工具”。

两者看上去都叫检索，可是评价标准完全不同。文档检索里，检索结果和标准答案有字面重合就能算对；技能检索里，检索结果和真实需求是否匹配，只有把工具真正执行一遍才知道。举个特别典型的例子，用户说“把这份文件转成 PDF”，技能库里有一个“文档格式转换”工具，描述里写的是“支持 docx、xlsx、ppt 转 pdf”，按向量相似度它是命中的，但执行时发现该工具只支持 10MB 以内的文件，而这个文件是 50MB。文档检索视角下这已经算满分命中，但真实效果呢？任务没完成。RAE 做评估时，这类情况会被明确地计为失败。

这也是我觉得 RAE 方法最值得学习的地方：它把评估的终点从“检索器找得准不准”拉长到了“任务完没完成”。把评估范围放大的同时，反而让评估结果更真实了。

2. RAE 方法到底做了什么：把“检索效果”放进真实的任务环境里称重

RAE 的全称是 Retrieval-Augmented Evaluation，也就是“检索增强的评估方法”。名字听起来有点绕，但思路其实很直白：你不用一堆静态的、文档式的指标去衡量检索好坏，而是搭建一个和真实使用场景一致的测试环境，让技能检索的结果真正流向大模型和执行器，最终看端到端的任务完成情况。它评估的是“整个技能调用链路的效果”，而不仅仅是“检索器这一步的效果”。

为什么要这么做？因为企业做智能体最终追求的一定是“用户的任务能不能被可靠地完成”，而不是“检索器在离线集合上的 F1 分数有多高”。离线指标和端到端效果之间的相关性，在实际项目中低得惊人。我见过太多检索器在离线评测上漂漂亮亮，一上真实流量就露馅的例子。RAE 的思路就是为了堵住这个漏洞。

RAE 的整体流程可以拆成四个部分：构造技能库、生成任务查询、执行技能调用、判定任务结果。每一个环节都有讲究，下面我把我实际理解和复现时的一些想法说一下。

2.1 RAE 的四段式评估链路

第一段：技能库构造。这一步需要一套与目标系统一致的技能清单。每个技能不仅要有名称、描述、参数、接口地址，还要有对应的模拟执行环境。没有模拟环境，任务就没法真正跑起来。

第二段：任务查询构造。RAE 构建了一批贴近真实用户表达的查询请求，可以是人工编写的，也可以由 LLM 辅助扩充。重点是这些查询要和技能库中的技能形成多对多的映射关系，既有一对一的简单场景，也有一对多、多对一的复杂场景。

第三段：技能调用执行。检索器根据查询返回技能列表，然后送给大模型做进一步选择和调用，最终调用动作会在模拟环境里真实执行。这一步是 RAE 和普通离线评测拉开差距的关键：检索结果不是停在候选列表，而是被真实地消耗掉。

第四段：任务完成判定。调用完成之后，RAE 会基于“预期结果模板”或“自动判定器”，检查执行结果是否满足用户意图。满足，算成功；不满足，哪怕是技能本身很好，也算失败。

这套链路说出来没什么玄乎的，但它把评估视角真正统一到了一个核心问题上：用户的需求到底被满足了没有。

2.2 为什么端到端判定比传统的“检索命中”更公平

传统技能检索评估看的是：检索结果里包不包含目标技能。听起来很合理，但实际操作中有个致命的问题——标注人员很难保证自己的标注是完整且唯一的。

举个例子，用户需求是“提醒我明天早上九点开会”。技能库里有一个“日程提醒”技能，还有一个“语音播报”技能，还有一个“定时任务”技能。从人工标注的视角看，也许只有“日程提醒”是正确结果。但从系统实现的角度看，“定时任务”配合“语音播报”同样能完成用户需求。这种情况下，离线标注就会产生偏差。而 RAE 绕开了这个标注问题：它不看“你召回了哪个技能”，它只看“用户的任务最终成没成”。只要最终闹钟响了、提醒弹出来了，就算成功。这在设计上是非常聪明的取舍。

2.3 RAE 的核心指标设计：不是所有“成功”都等价

RAE 里对任务完成度的判定也不是简单的是/否二分，而是分成了好几个层次，这部分我觉得特别有工程参考价值。

• 完全成功：用户意图的所有关键要素都实现，结果可直接交付。
• 部分成功：核心动作完成，但有次要信息遗漏或格式不对。
• 功能成功但体验失败：工具调用成功、接口返回正常，但结果不符合用户的隐性预期。
• 完全失败：检索错误、工具报错、或执行结果和用户需求完全无关。

这个分层的价值在于，它能帮团队定位问题到底出在哪个环节。如果系统中“完全失败”占比高，多半是检索器召回质量不行；如果“功能成功但体验失败”占比高，那问题可能出在提示词或模型推理上，而不是检索。这个分层做出来之后，团队开会时就不会再笼统地说“智能体效果不好”，而是能精确地说“检索环节的误召回导致 30% 的请求走到了错误的工具上”。

3. 从论文到落地：RAE 评估流程的可复现实操

理论说得再漂亮，落不了地也是白搭。我根据论文思路，结合自己在项目里跑智能体技能评估的经验，整理了一套可以直接照着做的实操流程。这套流程不需要太多基础设施，只要能跑通大模型 API、有一个向量数据库、有一份技能清单，就可以开始。

3.1 第一步：构造一份“有陷阱”的技能库

很多人做评估时有个习惯，就是技能库越干净越好。但我建议反着来：评估用的技能库一定要“有陷阱”。这里的陷阱包括：描述相似的技能、功能重叠的技能、名称和功能容易混淆的技能。只有把这些真实世界中存在的“脏”情况放进去，评估才有意义。

我在构造技能库时一般会准备三批技能：

• 第一批是核心技能，跟测试任务直接相关，数量和描述都合理；这批技能是保证系统能跑通的基础。
• 第二批是干扰技能，和核心技能在描述上有一定重合，例如“发送邮件”和“发送消息”，让检索器不能靠表面相似度取胜。
• 第三批是边界技能，比如权限受限的、仅限内部使用的、需要额外参数的。用来测试智能体在技能可用性判断上的能力。

每份技能描述我一般控制在 50 到 150 字之间，包含：功能概述、适用场景、输入输出关键参数、使用限制。特别要注意的是，技能描述里的措辞要尽量做到“功能和场景分离”。什么意思？比如“发送定时消息”这个技能，描述里需要明确说“适用于需要延后发送的场景”，而不是笼统地只说“消息发送”。否则检索器很容易把所有和消息相关的 query 都召回这个技能。

3.2 第二步：准备任务查询集，重点覆盖“易混淆场景”

任务查询集是评估的输入。理论上应该直接从真实用户日志里抽样，但在没有日志积累的早期阶段，可以靠人工+LLM 辅助生成。查询集会分成几个类别：

• 简单直给型：用户需求和技能描述高度匹配，例如“发一封邮件给张三”。
• 复合任务型：用户需求需要多个技能协作完成，例如“把昨天销售数据汇总后发给李四”。
• 易混淆型：用户表述含糊，需要结合上下文或常识才能判断正确技能，例如“帮我把上次讨论的内容发到群里”，如果团队里没有“会议纪要发送”技能，就只有“消息发送”技能，那么应该记作失败还是成功？这类边界情况建议在评估设计阶段就定好规则。
• 无对应技能型：用户需求当前技能库无法满足，例如技能库里没有“预订机票”技能，用户却提出了预订需求。理想的系统应该明确表示“无可用技能”，而不是强行调用一个不相关的工具。

任务查询集的规模不一定要很大，但覆盖面要足够宽。我的经验是，每个技能至少覆盖 5 个查询，每个易混淆场景至少覆盖 3 个变体，这样跑一轮下来，既有统计意义，又能定位问题。

3.3 第三步：实现评估闭环中最关键的“执行与判定”环节

这是 RAE 和普通评测差异最大的地方。技能调用不能只停留在“检索到了”这一层，要让检索结果真正走到执行层。如果你是在做业务系统，可以裁剪成策略模式读接口返回数据，达成一个可控的验证环境。如果没有真实接入条件，就需要做一个执行模拟器。

执行模拟器的核心逻辑是：一个函数接收技能 ID 和参数，判断参数是否满足技能的前置条件，然后返回一个带状态的执行结果。例如：

def execute_skill(skill_id, params): skill = skill_registry[skill_id] # 前置条件检查 for condition in skill.preconditions: if condition not in params: return {"status": "failed", "reason": f"missing param: {condition}"} # 模拟执行 if skill.require_network and not network_mock_up: return {"status": "failed", "reason": "network error"} # 按技能真实业务规则模拟核心动作 return {"status": "success", "result": skill.mock_output(params)}

模拟器不需要覆盖每个技能的内部业务细节，但它至少要能区分出“参数缺失”“权限不足”“条件不满足”“执行成功”这几种状态。这些状态会直接影响最终的判定逻辑。

判定器方面，我建议用“规则模板 + LLM 二次判断”的双通道设计。规则模板先做硬性检查，比如参数是否完整、返回值是否包含必需字段；LLM 再做软性判断，比如“用户说要发给团队所有人，实际只发给了 leader，这算不算成功”。两边结果不一致的时候，记录为人工复核样本。

3.4 第四步：跑完一轮评估之后，看什么指标

RAE 跑完一轮之后，会输出几个关键指标。我建议重点关注下面这几个，它们分别对应了技能检索链路的不同环节。

这些指标单独看意义有限，组合在一起就能讲出完整的故事。比如某轮评估端到端成功率只有 40%，再看检索召回率有 90%，说明问题大概率不在检索而在模型选择或参数填充。如果检索召回率本身只有 60%，那就要回到技能描述和 Embedding 层面去优化。

4. 我在实际运行 RAE 时踩过的坑，给你提前排掉

思路说完，说点更实际的。我在复现这套评估流程的时候踩过不少坑，有些是设计上的，有些是执行细节上的。挑几个典型的说，能帮你省好几个星期的时间。

4.1 技能描述与实际行为不一致，导致评估结果虚高

最典型的坑：技能描述里写着“支持批量发送邮件”，但实际接口实现时一次只能发一封。检索器一看 query 里有“批量发送”字样，匹配得很准，执行器在模拟环境里也跑得通，因为模拟环境没实现批量逻辑，一次传一个参数也返回 success。最后评估结果虚高，一到真环境就崩。

这个问题的解法是：技能库里的描述必须和真实行为严格对齐，评估前最好做一次一致性审查。你可以把每个技能描述给到开发同学，让他们逐条确认描述里的能力项是否真实存在。这一步虽然耗时，但是评估结果可信度的基础。

4.2 判定器会被“包装过的失败”带偏

还有一个我也没想到的坑：LLM 判定器经常会给出有偏差的判断。现象是，执行器返回了一个错误码，但错误信息被包装成“请稍后重试”，LLM 判定器看到“请稍后”就认为任务成功。或者执行器返回了一段使用说明，LLM 判定器以为这是真的结果数据。

后来我的办法是在判定提示词里明确约束：凡是执行结果中包含 error、exception、failed、denied 等关键词，一律进入人工复核通道，不再让 LLM 自行判断。如果调用结果是一个使用说明而不是业务数据，也要视为未成功。这个经验不大，但是很管用。

4.3 查询集合里的数据污染，会让你误判检索能力

这里的污染不是指脏数据，而是“无意中泄露了答案”。我在生成任务查询集时，有一轮直接用 LLM 辅助扩充查询，结果 LLM 自动把技能名称也写进了查询里。比如原查询是“帮我把周报发给老板”，扩充出来的变成“用周报发送功能帮我把周报发给老板”。检索器在这种查询上当然百发百中，但真实用户根本不会这么说。

解决这个问题有两种方式。第一种是建立“查询不得包含技能名称或技能描述关键词”的约束，生成后再人工抽检。第二种是拿真实线上日志做替换。我现在更推荐后者，哪怕样本少一些、乱一些，也远比看似整齐的模拟数据可靠。

4.4 干扰技能不是越多越好

有一个时期的评估集，我把干扰技能堆到了三十几个，结果所有技能的召回率一起下降。研究后发现，过去的数量增加了检索器的不确定性，同时也让大模型在选择工具时出现更多犹豫和误判。这个现象提醒了一个道理：评估集要和实际环境一致。如果你真实线上环境里就十几个技能，评估集放十几个就足够了。非要增加干扰技能，会增加系统性问题，也会增加很多与真实环境无关的问题。

4.5 参数填充错误的场景，必须单独统计

还有一个容易被忽略的维度是参数填充。检索器找对了技能，模型也选对了工具，但在生成参数时把字段传错了。比如“查昨天订单”传成了“查今天订单”，“发给张总”传成了“发给张工”。这类问题在端到端成功率里会体现为失败，但如果只看检索指标，完全看不出来。

所以我现在会把“检索成功、执行失败——参数错误”单独拉出来做一个类别，方便定位是模型参数生成能力的问题，还是接口设计复杂度过高的问题。部分接口参数之间关系太反直觉，完全靠模型推理确实容易错，这时需要在技能描述里补充参数示例。参数示例给得好不好，直接决定模型生成的准确率。

5. 后续扩展：把 RAE 的评估思路变成线上监控的一种变形

RAE 一开始是针对离线评估场景设计的方法，但是我在实际使用中发现，把它的核心逻辑变形之后，完全可以做成一个轻量级的线上巡检工具。

具体做法是：每天从线上日志里抽一小部分真实用户请求，放到 RAE 环境里重新跑一遍评估流程。这里不需要真实执行业务操作，只需要用模拟器复现执行链路，然后对比线上系统的返回结果和模拟环境的执行结果。如果两者不一致，说明线上技能库或者检索配置可能发生了漂移。

这个方法特别适合技能库更新频繁的团队。技能描述改了几个字、向量索引重建了一次、 Embedding 模型升级了版本，这些改动在形态上都很小，但造成的效果波动却很大。通过 RAE 的每日巡检，能在用户大规模感知之前提前发现异常。

我自己的体会是，做技能检索评估这件事，最忌讳的就是闭门造车。你用再多的离线指标，都不如让一个真实的用户请求走到真实的执行链路里，看看任务到底有没有完成。RAE 的方法本质上就是在帮团队建立这样一个“效果校验器”。它不能替代产品直觉，也不能替代用户体验反馈，但它能给团队提供一个稳定、可复现、可持续迭代的质量基线。先把基线立住，再谈优化和升级，这是我在多次迭代之后最信奉的一句话。

对这种评估方法有兴趣的团队，我建议先不要急着搭建复杂的平台，拿一个最小可用的脚本，把三五个技能、几十条查询先跑通评估闭环，看看输出的报告能不能帮团队定位实际问题。跑通之后，再根据实际需要逐步扩展技能库、查询集和自动化能力。踩过一次坑之后再回来读论文里那些设计细节，你会有完全不一样的理解。