评测与优化智能体

建立调试与评测方法，系统掌握 Prompt、知识库与 RAG、Workflow、Multi-Agent 的问题定位和调优路径。

4.1智能体调试与评测基础

智能体调优不是等应用全部搭完后再“统一验收”。真实项目里，更常见的做法是：搭建过程中先在测试环境里一条一条试问、逐个节点排查；应用基本成型后，再用评测集做批量验证、效果对比和回归评测。

4.1.1 什么是智能体调试与评测

智能体调试与评测不是同一件事。调试更像“边搭边修”，评测更像“阶段验收”。前者解决当前链路是否跑通、某个问题为什么答错；后者解决一批样本下整体效果是否稳定、某个版本是否比另一个版本更好。

（1）为什么不能等搭完再测？

智能体应用往往由 Prompt、知识库、工作流节点、工具接口、变量、模型参数等共同组成。如果等到全部搭完才开始测试，问题会叠在一起，排查成本会非常高。

• 问题来源会变得难以归因：同一个错误可能来自 Prompt、知识没命中、节点变量为空、工具返回异常或模型输出格式不稳定。
• 修改成本会被放大：越晚发现问题，越可能牵连后续节点、数据结构和业务流程。
• 演示样例容易产生误判：少数几个问题答对，不代表真实用户的大量问法都能稳定处理。
• 上线风险不可控：缺少单次调试和批量评测，无法说明应用是否达到了业务验收标准。

（2）单次调试与批量评测的区别

单次调试和批量评测不是替代关系，而是先后衔接。单次调试解决“当前问题为什么不对”，批量评测解决“整体效果是否稳定”。

实际项目中的推荐节奏是：先用单次调试把主链路跑通，再用小样本做专项验证，最后使用评测集做批量评测。

4.1.2 单次调试：边搭边测、逐轮验证

测试环境的价值，是让搭建者在不影响正式用户的情况下，反复输入问题、观察链路、修改配置并验证结果。单次调试不是随机问一句，而是带着明确目的去试。

（1）单次调试的五步法

1. 明确本轮调试目标：是看知识是否命中、Prompt 是否有效、工具是否可用，还是流程节点是否能跑通。
2. 输入一条可解释的问题：问题不要太随机，最好能对应某个知识点、流程节点或边界条件。
3. 观察完整链路：不仅看最终回复，还要看中间变量、检索结果、节点输出和工具返回。
4. 记录问题与修改动作：每次只改一个主要变量，避免同时改 Prompt、知识库和流程导致无法归因。
5. 重新试跑验证：确认问题是否被修复，同时用一两条相邻问题检查是否引入新问题。

常见的调试问题类型可参考下表：

（2）如何根据单次结果定位问题

每次在测试环境里进行单次调试时，最终回复只是整条执行链路的最后结果。一个回答不符合预期，并不一定意味着 Prompt 写得不好，也不一定说明模型能力不足。智能体运行过程中还包含意图识别、知识检索、变量传递、节点执行、工具调用、格式生成、异常兜底等多个环节，任何一个环节出错，最后都可能表现为“回答不对”。

因此，单次调试的重点不是反复追问，直到某一次回答看起来满意，而是要根据问题现象反推最可能出错的环节。比如，同样是“回答错误”，可能是意图识别走错了分支，也可能是知识库没有命中；同样是“流程失败”，可能是变量没有提取出来，也可能是节点条件判断写错；同样是“输出格式不稳定”，可能是 Prompt 没给清楚格式约束，也可能是后续解析逻辑缺少容错。

下面这张表可以作为搭建过程中的单次调试快速诊断表。使用时，先观察本轮试跑中最明显的问题现象，再根据表格中的“优先怀疑”判断应该先检查哪一层配置，最后按照“排查动作”进入对应位置查看日志、变量、检索结果、节点输出或工具返回。

4.1.3 评测集：批量测试

（1）什么时候需要评测集

评测集的作用，是用一批相对稳定、可重复运行的样本，验证智能体在核心场景下的整体表现。它不是用来替代搭建过程中的单次调试，也不是越早建立、越大越好。

在应用刚开始搭建时，需求、Prompt、知识库、Workflow、工具调用方式往往都还在变化。如果这时就投入大量精力设计完整评测集，很容易出现两个问题：一是评测样本很快过期，二是评测结果难以归因。比如应用主链路还没跑通时，批量评测失败并不能说明模型效果差，可能只是变量没传、知识没接好、工具没配置成功。

因此，评测集更适合在应用主链路基本稳定、核心场景已经明确后建立。它主要用于三类任务：

• 覆盖性验证：确认高频问题、复杂问题、边界问题是否都能稳定处理。
• 版本对比：确认 Prompt、模型、知识库或 Workflow 调整后，新版本是否真的更好。
• 回归验证：确认修复旧问题后，没有引入新的错误。

下面这张表可以作为判断是否需要建立或更新评测集的参考。

（2）评测任务

a.新建评测任务

新建评测任务主要分为两个步骤：基准评测配置和对比评测配置，在下文中进行详细说明。

第一步：基准评测配置

基准评测配置支持选择评测集，根据应用配置批量运行以获取结果，并设置评分方式，支持裁判模型、规则或代码等多种评分方式。无论选择哪种评分方式，运行后的结果均支持批量下载和界面人工标注。

裁判模型打分：

通过大模型评估评测集批量运行结果，包含裁判模型和裁判提示词两部分：

裁判模型：选择作为大模型裁判的模型，支持选择不同模型，并可配置模型参数。

裁判提示词：用于对评测结果进行打分的模型提示词，支持通过快捷键引入评测集中的查询（query）、预置列、自定义列、应用的输出内容以及其他系统变量。请确保裁判模型提示词与评测集内容的匹配程度，以保证裁判模型能够正确打分。例如，若按照参考答案进行打分，则需要在评测集中上传参考答案（例如：reference_output）。同时支持点击模板，查看提示词模板库中更多适合的提示词。

规则打分：

按照预定义的规则对输出结果进行打分。支持单条规则和多条规则组合 。

代码打分：

通过编写代码对输出结果进行打分，目前支持Python语言。可直接引用评测集中的 query 、预置列和自定义列。

仅输出结果不打分：

仅批量运行评测集，不进行任何打分，直接输出结果。选择此方式时，相当于执行任务批处理。

第二步：对比评测配置

对比评测功能用于在同一应用内对多组模型或多个提示词进行效果对比，帮助快速评估不同配置在相同任务下的表现差异。支持的对比方式包括：

• 不进行对比评测
• 多模型对比评测
• 多提示词对比评测

该功能仅支持标准模式的应用。在选择进行对比评测时，可对对比结果进行以下处理方式：

• 仅输出多个结果：生成多个结果，不进行对比打分。
• 对比打分：使用裁判模型对每条样本的多个结果进行评分。

不进行对比评测（默认） ：

按照当前应用的测试环境配置运行，不进行模型或提示词的对比。

多模型对比评测：

支持添加最多2组对比模型，与当前配置模型进行对比。如果对比模型与当前配置模型相同，系统会提示错误。

多提示词对比评测：

支持添加最多2组对比提示词，与当前配置提示词进行对比。如果对比提示词与当前提示词相同，系统会提示错误。

是否进行对比打分

• 仅输出多个结果，不进行对比打分（默认） ：仅输出多组对比结果，不进行优劣判断。
• 对每条样本的多个输出结果，使用裁判模型进行对比打分：基于多个版本的运行结果，使用裁判模型进行对比打分，判断优劣。需要选择对比打分裁判模型和对比打分裁判提示词，和裁判模型以及裁判提示词类似。

b.查看评测报告

跑批完或评测完后可以查看报告，报告中包含基本信息、评测配置信息、基准评测结果、对比打分评测结果、基准评测性能报告、对比评测性能测试报告等内容并支持输出图表，将已有的测试结果数据进行可视化展示。

c.评测结果标注

评测任务完成后，用户可对运行结果进行人工标注，以提升评测的准确性和参考价值。标注后的结果将体现在评测报告和下载的结果文件中。

4.1.4 调试—优化—评测—回归的完整闭环

一个稳定的智能体，不是一次搭建出来的，而是在不断调试、优化和回归中逐步稳定下来的。

从“可评测”到“可上线”：交付与运维清单

4.1 小结

• 调试发生在搭建过程中，重点是单次验证和链路排查。
• 评测发生在应用基本成型后，重点是批量样本、指标分析和上线依据。
• 单次调试不要只看最终回复，还要看知识命中、变量、节点、工具和性能。
• 评测集应来自真实业务问题、调试记录和线上 Badcase，而不是凭空编一批题。
• 每次重要优化后都要做回归，确保整体效果持续变好。

4.2Prompt 调优

从问题定位、提示词优化到效果验证，提升智能体回答稳定性

当智能体出现答非所问、格式不稳定、知识不引用、工具参数错误或语气不一致时，优先不要只判断“模型不行”。更有效的做法是先定位问题来源，再通过 Prompt、上下文、模型配置和测试样本逐步优化。

4.2.1 Prompt 为什么效果不好

Prompt 效果不好，通常不是因为某一句话写得不够长，而是任务、依据、边界、格式、上下文或模型配置中有关键要素缺失。调试时应先定位问题来源，再决定改 Prompt、改知识库、改工作流，还是调整模型配置。

可以把 Prompt 理解成给模型的一份“任务说明书”。如果说明书只写“帮我回答一下”，模型虽然会给出回复，但不一定知道应该面向谁回答、依据哪份资料回答、哪些内容不能推测、输出要不要给引用、后续节点是否需要固定字段。因此，Prompt 调优的第一步不是马上改写，而是先问：这个问题到底是“没听懂任务”，还是“没有拿到正确依据”，或者是“输出格式没有被约束”。

在 ADP 应用中，还要注意 Prompt 与知识库、工作流、模型配置等是一起生效的，例如知识库没有命中正确内容时，单纯加长 Prompt 通常不能解决根因。

先定位，再调优

调优前建议先做一次单轮排查：同一条问题下，分别查看用户输入、知识命中、节点输出、工具返回和最终回复。如果知识命中正确，但最终回复仍然扩展了无依据内容，重点改 Prompt；如果知识根本没有命中，重点改知识库、切分、检索参数或问法改写；如果最终回复正确但下游节点解析失败，重点改输出格式。

4.2.2 Prompt 调优的常用方法

（1）指令清晰：说清楚角色、任务、依据和限制

清晰的 Prompt 至少要回答四个问题：模型现在扮演什么角色、要完成什么任务、必须依据什么信息、不能做什么。角色决定回答口吻和责任边界，任务决定本轮要完成的动作，依据决定模型能使用哪些信息，限制决定哪些情况必须拒答、追问或转人工。

很多效果问题来自“看似合理但不够具体”的提示。例如“请专业回答”并没有说明专业体现在哪里；“请简洁回答”也没有说明字数、结构或是否需要下一步建议。对企业应用来说，Prompt 应尽量把隐含要求显式写出来，让模型少猜。

（2）添加示例：让模型模仿正确输出

当输出格式、判断标准或语气要求不容易说清楚时，添加 1–3 个高质量示例通常比继续堆规则更有效。示例会告诉模型“什么样的输入应该对应什么样的输出”，尤其适合信息抽取、标签判断、客服话术、JSON 输出等任务。

示例不是越多越好。示例过多会占用上下文，也可能让模型过度模仿某一个样例。更好的做法是选择少量典型样例：一个标准样例、一个边界样例、一个缺失信息样例。这样模型既能学会正常处理，也能知道遇到不完整或高风险输入时怎么兜底。例如：

（3）问题分解：把复杂任务拆成可验证步骤

复杂任务不要全部压在一个 Prompt 里。更稳定的做法是把任务拆成多个步骤，或在工作流中拆成多个节点。拆解的好处是：每一步目标更单一，输出更容易检查，出现问题时也更容易定位是意图识别、字段抽取、知识检索还是结果生成出了问题。

例如“处理客户投诉”可以拆成：识别是否投诉、提取客户诉求和关键信息、判断风险等级、查询处理规则、生成回复或转人工建议。不要让一个节点同时完成所有动作，否则调试时只能看到最终回答，很难知道中间哪一步发生偏差。

1. 先判断用户意图和任务类型。
2. 再提取必要字段，缺失时追问。
3. 然后查询知识库或调用工具。
4. 最后基于结果生成答案，并按格式输出。
5. 如果结果不确定，进入兜底或人工处理。

（4）控制输出：给模板、字段和校验规则

如果后续节点需要读取模型输出，Prompt 中必须明确输出结构。只写“请按 JSON 输出”通常不够，还要写字段名、字段含义、取值范围、缺失值处理和禁止输出多余解释。

在工作流中，输出格式不稳定会直接影响后续节点。例如上游输出多了一段解释文字，下游 JSON 解析就可能失败；字段名有时叫 intent、有时叫 user_intent，下游变量也可能读取不到。因此，凡是要进入后续节点的模型输出，都应尽量结构化、字段固定、规则明确。

（5）给模型留出中间选项

不要只给模型“对/错”“能/不能”的二选一。当业务场景存在不确定信息时，应允许模型输出“无法确认”“需补充信息”“建议转人工”等中间结果。例如：

再看四组 Before / After 对比，直观感受“稳定写法”比“随手一写”好在哪。Before 是常见的不稳定写法，After 是更稳定、可直接复用的写法。

对比一：知识问答

Before｜不稳定写法

After｜更稳定写法

对比二：信息抽取

Before｜不稳定写法

After｜更稳定写法

对比三：客服话术

Before｜不稳定写法

After｜更稳定写法

对比四：工作流节点

Before｜不稳定写法

After｜更稳定写法

4.2.3 Prompt 模板设计

Prompt 模板的价值，是把一次有效的调优经验沉淀成可复用结构。实际编写时，可以使用“角色—背景—目标—依据—步骤—边界—输出”的结构。它不要求每次都写很长，但能帮助你检查关键要素是否缺失。

模板不是固定话术，而是一张检查清单。简单问答场景可以只保留角色、依据、边界和输出；复杂工作流节点则需要写清输入变量、处理步骤、输出字段和异常情况。模板设计的重点是让不同搭建者在同类场景下写出的 Prompt 保持一致，便于复用、评审和后续维护。

（1）通用模板

（2）模板使用建议

不同任务的模板重点不同。不要把所有场景都套成同一个长模板，而要根据任务类型保留最关键的约束。下面这些建议可以作为设计 Prompt 模板时的快速检查。

• 知识问答类模板重点写清“依据”和“无法确认时的回复”。
• 信息抽取类模板重点写清字段定义、取值范围和缺失字段处理。
• 客服回复类模板重点写清语气、禁用表达、风险边界和可复制话术长度。
• 工作流节点模板重点写清输入变量、输出变量和下游节点可解析格式。

4.2.4 Prompt 效果验证与迭代

Prompt 改完后，不能只看当前那一条问题是否变好。正确做法是用固定样本复测，确认同类问题改善，同时没有引入新的问题。

很多调优失败，是因为每次同时改了太多内容：既改 Prompt，又改模型配置，还改知识库和检索参数。这样即使效果变好，也不知道是哪项修改起作用；如果效果变差，也很难回滚。因此建议每轮只改一个主要变量，并保留优化前后的对比记录。

验证样本不需要一开始就很大，但要覆盖关键类型。比如一个客服助手，至少应包含标准问法、口语化问法、资料不足问法、边界问法和高风险问法。上线前再把这些样本扩展成更完整的评测集。

建议记录字段

4.2.5 基于 ADP 的 Prompt 设计与问题处理案例

在 ADP 中，Prompt 不只出现在一个输入框里。标准模式、知识问答、工作流节点和 Multi-Agent 都可能包含不同层级的指令。处理问题时，应先判断应该改哪一层。

如果是全局回答风格、业务边界或身份定位不清，通常优先调整角色指令；如果是知识问答中“命中了但不会用”，要检查用户输入模板和依据规则；如果是工作流某个节点输出不稳定，应调整该节点提示词；如果是工具调用失败，要同时检查工具说明、入参字段和异常返回处理。

案例一：标准模式知识问答回答不稳定

场景：门店员工咨询退换货政策。知识库中已有政策文档，但智能体有时会补充文档里没有的承诺。这个问题的关键不是“模型不会回答”，而是模型没有被明确要求只使用知识库内容，也没有被要求在资料不足时停止推测。

优化后的Prompt：

案例二：工作流参数提取节点经常漏字段

场景：订票流程需要收集出发地、目的地、出发时间。用户用口语表达时，节点有时会误填或自行补全字段。参数提取节点的目标不是“尽量猜出答案”，而是稳定识别已提供字段，并把缺失字段交给后续追问。

优化后的Prompt：

案例三：Multi-Agent 任务协作边界不清

场景：一个复杂资料分析应用中，检索、分析和复核都由多个 Agent 参与，但经常出现重复检索、直接下结论或遗漏复核。Multi-Agent 的 Prompt 重点不是把每个 Agent 都写得很“聪明”，而是让每个 Agent 知道自己负责什么、不负责什么、什么时候需要把任务交给其他 Agent。

4.2 练习：优化一个门店客服助手 Prompt

某连锁零售企业正在搭建门店客服助手。当前角色指令如下：

调试时发现三个问题：用户问退换货政策时，智能体会凭经验补充知识库没有的内容；用户描述投诉时，智能体没有提示转人工；输出有时很长，不适合客服直接复制。请按本节方法优化这个 Prompt。

优化后示例

安全补充：Prompt 不是安全边界

把“不要泄露数据、不要调用危险工具”写进系统 Prompt 很有必要，但它只能约束模型行为，不能替代系统层的安全控制。可靠方案应把系统指令、输入过滤、知识与工具权限、入参校验、输出校验和人工审核组合使用。

4.2 小结

• Prompt 效果不好时，先定位任务、依据、边界、格式、上下文和模型配置中的问题。
• 常用调优方法包括清晰指令、添加示例、问题分解、输出约束和中间选项。
• Prompt 模板应沉淀角色、背景、目标、依据、步骤、边界和输出格式。
• Prompt 优化后必须用固定样本复测，并进行回归验证。
• 在 ADP 中处理 Prompt 问题时，要找准配置位置：角色指令、用户输入模板、工作流节点、工具说明或 Multi-Agent 角色配置。

4.3知识库质量与 RAG 调优

当知识问答效果不稳定时，先判断问题出在知识、切分、检索，还是生成。

智能体知识问答的效果，不只取决于模型回复能力，更取决于知识是否准备得清楚、是否被正确切分、是否能被检索到、是否能被稳定传入模型上下文。学完本节，当知识库里明明有资料，智能体却没答对、答不全、引用不准或命中了旧内容时，你将能够从 ADP 的知识库设置和调试结果出发，判断如何从知识质量、切分方式、检索召回、问答 和引用配置中定位原因。

4.3.1 先判断：是不是知识与检索问题

RAG 的完整含义是“检索增强生成”。在知识问答场景中，模型并不是自动阅读整个知识库后回答，而是先根据用户问题从知识库中检索出相关片段，再把这些片段作为上下文交给模型生成答案。因此，知识库里“有答案”和智能体“能答对”之间，还隔着检索、切分、重排、上下文拼接和生成约束等多个环节。

一个典型的 RAG 链路可以理解为：用户问题进入应用后，系统先理解问题并可能结合上下文改写；随后在知识库中召回相关文档、问答或数据库内容；再通过匹配度、重排等机制筛选更相关的片段；最后把片段、提示词和用户问题一起传给模型生成答案。如果任何一环出现问题，最终回答都会受影响。

知识问答效果不好时，最容易走偏的做法是直接改 Prompt 或换模型。实际上，很多问题的根因并不在生成，而在前面的知识准备和检索环节。你可以先用三个问题做快速判断。

常见现象

最后把 RAG 最常见的四类问题现象与优先排查项整理成一张对照表。排障时先定位现象，再按顺序逐项排查：

4.3.2 知识库质量：把资料整理成可用知识

知识库质量决定了后续调优的上限。文档本身如果过期、重复、标题混乱、表格不规范，即使检索参数调得再细，也容易出现命中错误或回答不稳定。

这里的重点不是“上传更多资料”，而是让资料更适合被检索、被引用、被维护。建议先把知识按业务主题整理成清单，再决定哪些放文档、哪些做 问答、哪些适合数据库。

（1）三类知识的准备规范

文档、问答和数据库都可以作为知识来源，但它们适合解决的问题不同，准备规范也不同。调优时不要把所有资料都当作文档上传，而要先判断知识的形态。例如，制度、手册、SOP 更适合文档；高频标准问题更适合问答；需要按字段查询、聚合或筛选的数据更适合数据库。

• 文档类知识要重点关注“可解析”和“可追溯”。如果文档到期后仍被检索，可能导致过期答案；如果没有打开参考来源，学员在测试时可能无法判断答案来自哪里。
• 问答类知识要重点关注“可校验”和“无冲突”。从文档生成的问答必须经过人工校验后再采纳，冲突问答需要合并处理。
• 数据库类知识要重点关注“字段可理解”。表名、列名、单位和描述写得越清楚，模型越容易判断应该查询哪张表、哪个字段。

（2）不要直接上传的典型资料

• 只适合人看的活动海报、复杂宣传页、截图合集。
• 大量设计元素混在一起的 PPT 页面。
• 拍照模糊、倾斜、遮挡或表格线不清晰的扫描件。
• 多人反复修改后没有版本标识的制度汇总。

4.3.3 Chunk 切分：让片段既能命中，也能看懂

Chunk 是知识检索时被命中的基本片段。切分调优的目标不是追求越细越好，而是让每个片段都围绕一个相对完整的问题：既容易被用户问题命中，又能提供足够上下文让模型回答。

判断切分是否合适，可以看命中片段本身是否“能独立支撑回答”。如果片段只命中了结论，却没有条件；只命中了表格数据，却没有表头；只命中了流程步骤，却缺少前置条件，说明切分还需要调整。

ADP 中常用切分方式

4.3.4 检索召回：让合适的内容排到前面

切分解决“知识怎么存”，检索召回解决“用户问的时候怎么找”。调优时不要只盯着一个参数，而要看召回数量、匹配度、检索策略、重排、检索范围是否共同影响了结果。

检索参数的调整要围绕测试样本进行，而不是围绕单条问题反复试。召回数量调大，可能让某条问题命中，但也会带入更多噪声；匹配度调低，可能提高覆盖率，但也可能让弱相关片段进入上下文。更稳妥的做法是固定一组样本，看整体命中率、引用准确性和最终答案质量是否改善。

（1）先看召回结果，再调参数

如果调试时没有看到正确片段，优先检查检索范围和召回设置；如果正确片段出现了但排序靠后，再考虑重排；如果召回结果很多但都不相关，说明匹配度、知识质量或文档表达需要调整。

（2）典型调参判断

4.3.5 问答、引用与 Badcase 回归

（1）用问答稳住高频问题

问答适合解决用户真实问法和正式文档表达不一致的问题。高频问题、口语化问题、风险问题、需要固定话术的问题，都可以优先沉淀为问答。

设计问答时，不要只把制度标题改成问题。好的问答应该来自真实用户问法，并且答案要和正式文档保持一致。比如用户不会问“市内交通费报销规则是什么”，更可能问“打车票怎么报”“网约车发票能不能报”。这些问法都可以映射到同一条标准答案。

（2）引用是可信度的一部分

知识问答不是只要“答得像”就可以。对企业制度、售后政策、合规说明等场景，用户需要知道答案来自哪里。引用缺失会降低可信度，引用错误则说明检索、重排、文档版本或生成约束可能存在问题。

（3）常见Badcase

调试和评测过程中出现的 Badcase 不要只记录“答错了”，而要记录“错在哪里、优先怀疑哪一环、改了什么、改完是否真的变好”。建议至少保留四类信息：问题现象、优先归因、调整动作、调整后效果。这样后续再次做评测时，才能判断问题是否被真正修复，而不是只在某一次测试中偶然答对。

如果同一个 Badcase 多次复发，说明它不只是单条问题，而是某一类知识组织、切分或检索策略存在系统性问题，应把它升级为专项优化项。

4.3.6 ADP的知识库与RAG调优流程总结

在 ADP 中，建议按照“知识准备—导入配置—单次调试—批量评测—回归沉淀”的顺序推进知识库与RAG的调优。

4.3 练习：优化员工制度问答助手

某企业搭建员工制度问答助手，上传了考勤、报销、请假和福利制度。测试时出现以下问题，请判断优先优化方向。

参考调优路径

这个练习的关键不是一次性把所有参数都改掉，而是先把问题归类，再按归因逐项优化。文档旧、切分断、问答缺失、引用缺失，分别对应不同的处理动作。

1. 整理制度版本，删除或到期旧版文档，统一命名规则。
2. 检查关键问题对应 Chunk，确认条件、结论、例外没有被拆断。
3. 为高频口语问法补充问答，例如“打车票怎么报”。
4. 检查应用中的知识库检索设置：召回数量、匹配度、重排和检索范围。
5. 配置参考来源展示，并要求答案基于引用内容生成。
6. 把修复后的问题加入评测集，每次调整后做回归。

4.3 小结

1. 知识库质量与 RAG 调优的关键，是先定位问题发生在知识、切分、检索、引用还是生成。
2. 文档调优重点是结构清晰、版本准确、表格规范、标签和范围可控。
3. Chunk 调优重点是让片段既容易命中，又包含足够上下文。
4. 检索调优要结合召回数量、匹配度、重排和检索范围，不要只为单条问题调参。
5. 问答 适合沉淀高频、口语化、风险口径和跨文档答案。
6. 每个 Badcase 都应记录现象、归因、调整动作和复测结果，沉淀为后续回归样本。

4.4Workflow 调优

基于 ADP 工作流画布，把复杂业务流程调到稳定、可控、可复测。

本节将从工作流管理页、可视化画布、节点详情、连线、变量和调试结果入手，学习如何定位流程为什么跑不通、为什么走错分支、为什么插件报错，以及如何验证修改是否真正有效。

4.4.1 先看清：ADP 工作流在页面上长什么样

ADP 工作流在应用详情页的工作流管理中创建、配置、启用和调试。调优时不要只停留在“用户最后看到的回答”，而要回到工作流页面看流程本身：目标工作流节点是否连对，节点详情里的输入输出变量是否正确，调试结果显示哪个节点失败。

工作流页面可以理解为三层：第一层是工作流管理页，用于确认工作流是否存在、是否启用；第二层是画布，用于查看节点和连线；第三层是节点详情页，用于查看单个节点的输入、处理逻辑、输出和异常设置。调优时要按这三层逐步缩小问题范围。

4.4.2 调优从场景边界开始：输入、处理、输出要清楚

参考资料强调，工作流场景调研的核心是把客户业务需求翻译为智能体可执行的工作流目标。很多流程不稳定，不是因为平台节点能力不足，而是一开始没有说清楚流程要处理什么、不处理什么、依赖什么、怎么验收。

例如“做一个售后助手”太宽泛，不适合直接进入画布配置。更可执行的描述应该是：“用户提出退货、换货或投诉时，系统收集订单号和商品信息，查询订单系统和售后政策，生成工单或引导转人工。”这时你才能判断需要哪些节点、哪些字段、哪些异常路径。

如果边界不清，后续会出现两个典型问题：一是流程越搭越长，二是节点职责越来越混乱。所以正式调节点前，建议先把这张表补齐。

4.4.3 节点选型：先选对节点，再谈调优

ADP 工作流节点分为信息收集类、信息处理类、变量处理类和基础节点。调优时最常见的问题，是把一种节点当成另一种节点用。节点选错后，Prompt 写得再细也可能不稳定。

典型 Badcase：用标签提取节点收集参数

酒店客需送物场景中，需要收集用户需要的物品和数量作为插件入参。原配置使用大模型标签提取节点，当用户没有明确部分参数时，节点不会主动追问，导致插件入参缺失并报错。调整方案是改用参数提取节点。

这个案例说明：标签提取更适合把已有文本打上类别标签；参数提取更适合围绕后续工具调用收集必填字段。只要字段缺失会影响后续执行，就应优先考虑参数提取节点和缺失追问。

再如：

4.4.4 连线、变量和输出：让流程能被下游读懂

工作流节点之间通过连线表达执行流向。产品资料中说明，节点输入变量可以引用所有祖先节点的输出变量；在端到端调试时，画布会展示节点状态、输入输出变量详情以及连线状态。

调优时要特别关注变量。很多“流程失败”本质上不是节点不会处理，而是上游输出字段和下游引用字段不一致，或者分支判断拿到的是空值。建议关键节点都明确输出字段名称、字段类型和缺失值处理方式。

输出变量要服务前端识别

如果前端需要识别模型输出是标题、短攻略还是长攻略，不能只输出自然语言。参考资料中的旅游攻略场景，通过在回复节点配置输出变量，让前端稳定识别不同内容类型。

4.4.5 调试：单节点调试与端到端调试要结合

ADP 工作流支持单节点调试和端到端调试。单节点调试适合开发阶段验证某个节点是否能独立工作；端到端调试适合验证整条流程是否能从用户输入跑到最终回复。

不要把端到端调试当成唯一调试方式。如果端到端失败，应先定位失败节点，再回到该节点做单节点调试。这样可以避免在整条链路里盲目修改，尤其适合排查大模型节点、参数提取节点、插件节点和代码节点。

专项调优案例

语种输出不稳定：不要只在 Prompt 中写“中文问题中文回复，英文问题英文回复”。更稳定做法是在开始节点后增加大模型节点来判断语种，输出语言变量，后续节点引用该变量；固定拒答话术也应提前配置不同语种版本。

意图识别错误：当两个 query 语义接近但业务意图不同，例如“入住时间”和“完成入住的耗时”，可以通过意图示例进行强制干预。

4.4.6 常见 Badcase举例

4.4 练习：优化酒店客需送物流程

某酒店智能客服支持客需送物。用户可以说“帮我送两条毛巾到 1208 房间”，系统需要收集物品、数量、房间号并调用客需工单插件。测试时出现以下问题，请判断优先优化方向。

参考调优路径

这个练习的重点，是把问题定位到具体配置位置，而不是笼统地说“模型没理解”。参数缺失看参数提取节点，语种混乱看语言判断变量，意图错误看意图示例，前端识别失败看回复节点输出变量。

1. 先确认流程边界：输入、处理、输出和依赖插件。
2. 将物品、数量、房间号设置为参数提取节点关键字段。
3. 缺字段时进入追问，不继续调用插件。
4. 对语种、意图、多值参数等特殊规则单独配置。
5. 使用单节点调试验证参数提取和意图识别，再做端到端调试。

4.4 小结

1. Workflow 调优要基于 ADP 工作流画布：看节点、连线、变量、输入输出和调试详情。
2. 工作流问题先回到业务边界：输入是什么、处理什么、输出什么。
3. 节点选型要准确，参数收集优先用参数提取节点。
4. 语种、意图、多值参数、前端识别等特殊规则，应通过变量、意图示例和输出变量稳定实现。
5. 单节点调试用于定位节点能力，端到端调试用于验证完整链路。

4.5Multi-Agent 调优

基于 ADP Multi-Agent 的 Agent 配置、工具调用、协同方式和调试现象定位问题。

本节聚焦 Multi-Agent 调优：当 Agent 不兜底、乱调工具、工具返回解析错、输出格式不稳定或转交失败时，你需要回到 Agent 的名称、转交描述、提示词、工具配置、协同方式和高级设置中检查。

4.5.1 先看清：ADP Multi-Agent 的配置项

Multi-Agent 模式支持创建单 Agent 应用，也允许添加多个 Agent，并选择不同协同方式。调优时要重点看这些配置项：名称、模型、转交描述、提示词、连接器与工具、转交关系、协同方式和高级设置。

其中，“转交描述”和“提示词”很容易混淆。转交描述是给其他 Agent 判断“什么时候该转交给我”的简要说明；提示词是给当前 Agent 执行任务时使用的详细工作规则。转交失败时优先看转交描述，执行过程不稳定时优先看提示词和工具说明。

4.5.2 协同方式选择：自由转交、工作流编排、Plan & Execute

ADP 支持多种 Agent 协同方式。不同协同方式不是优劣关系，而是适合不同任务。调优时如果发现转交不稳定，往往需要重新判断协同方式是否选对。

自由转交配置最轻，但依赖模型判断；工作流编排更稳定，但需要你明确路由条件；Plan & Execute 更适合复杂分析，但耗时更长、成本更高。选择协同方式时，要先判断任务是否固定、是否需要深度拆解、是否对响应速度敏感。

4.5.3 工具与插件：Agent 能不能正确调用，取决于工具说明是否清楚

在 Multi-Agent 中，Agent 需要根据工具名称和描述选择合适工具。工具名称、入参、出参不是后台字段，而是 Agent 理解工具能力的依据。

如果工具名称像 tool_01，Agent 很难判断使用场景；如果入参没有说明是否必填，Agent 可能在参数缺失时仍然调用；如果返回字段不具名，Agent 可能误解结果。因此工具调优要从“让 Agent 看懂工具”开始。

添加工具和提示词

工具返回要结构化

如果工具返回值字段不清晰，Agent 仍可能误解字段含义。参考资料中的例子是工具返回 [30,1]，Agent 可能混淆准确率和召回率。更稳定做法是返回具名 JSON 字段。

4.5.4 常见调优：不兜底、工具异常、格式不稳

A. Agent 不走兜底

当某些用户意图操作当前不支持时，只在提示词中写兜底可能不够。参考资料中建议顺着 Agent 调用的工具添加字段，再次告诉 Agent 相应操作不支持，形成“提示词 + 工具返回”的双重约束。

B. 调用工具异常

工具调用异常可能来自工具引用格式、工具名称、工具字段与代码不一致等。如下图示例中，检查提示词后发现没有采用引用格式调用插件，修正后可解决；另一个场景是工具返回字段填写错误，需要修改工具返回字段和代码一致。

C. 不按格式生成文本

如果要求 Agent 生成当前时间戳格式的项目名称，它可能生成一个看似正确但并非真实当前时间的名称。需要稳定、可复现的逻辑，不应只交给 Agent 自由生成。

更可靠的做法是把确定性逻辑放到工具中完成。例如时间戳、编号、金额计算、格式校验，都应由工具、代码或规则生成，再交给 Agent 使用。

4.5.5 Agent 转交失败：用协同方式提升稳定性

自由转交下，Agent 转交稳定性取决于名称、转交描述和模型判断。参考资料中有一个案例：明火检测能转交给巡检 Agent，但缺陷识别仍被巡检 Agent 处理，没有转给质检 Agent。

如果转交条件明确，建议使用工作流编排进行 Agent 转交。工作流先判断任务类型，再把任务交给对应 Agent，稳定性通常高于完全自由转交。

4.5 练习：优化多 Agent 质检助手

某企业搭建多 Agent 质检助手：入口 Agent 根据用户问题转交给巡检 Agent 或质检 Agent，并调用图像识别插件完成任务。测试时出现以下问题，请判断优先优化方向。

参考调优路径

这个练习的重点，是把 Agent 问题拆到具体配置项：转交失败看名称和转交描述，工具异常看入参出参和代码一致性，不兜底看提示词和工具返回，格式不稳定看是否需要工具化。

1. 先检查 Agent 名称、转交描述和职责边界。
2. 检查插件工具是否已正确录入，入参和出参是否清晰。
3. 把不支持任务写进系统提示词，并在工具返回中补充不支持字段。
4. 把时间戳、编号、格式校验等确定性逻辑放进工具。
5. 当自由转交不稳定时，用工作流编排做任务路由。

4.5 小结

1. Multi-Agent 调优要回到 Agent 的名称、转交描述、提示词、工具和协同方式。
2. Agent 不走兜底时，不能只靠提示词，应结合工具返回做双重约束。
3. 工具异常要检查引用格式、工具字段和接口代码是否一致。
4. 确定性逻辑应工具化，不要让 Agent 自由生成时间戳、编号或严格格式。
5. 转交失败时，应优先检查转交描述和协同方式；条件明确时可用工作流编排增强稳定性。