面向小型智能体的分层诊断与精准增强方法

在零售、出行、通信、医疗咨询等服务场景中，智能助手早已不只是“回答问题”的对话模型。它需要持续理解用户意图，记住多轮对话中的关键信息，查询业务数据，调用外部工具，并严格遵守退款、改签、身份核验、隐私保护等规则。

这类系统更接近一个受约束的任务执行智能体。它的最终质量不只取决于语言是否流畅，更取决于业务目标有没有正确完成。

大型模型通常具备更强的综合推理能力，但在企业实际部署中，成本、时延、数据安全和本地化要求都可能成为限制。小型模型更容易私有化部署，也便于针对特定领域进行优化，但其失败模式往往更加复杂。若不先分析错误来源，就直接增加提示词、扩充上下文或进行训练，可能投入大量资源却收效有限。

因此，更合理的方法不是为所有模型套用同一组增强手段，而是建立“测量—诊断—干预—复验”的闭环：先确认模型究竟在哪个环节失效，再选择成本最低、针对性最强的修复方案。

一、为什么任务型智能助手更容易失败

传统问答系统通常只需根据当前输入生成一段文本，而任务型智能助手必须同时处理多类约束。

1. 对话状态约束

用户的重要信息可能分散在多轮交流中。例如，用户先说明订单编号，随后补充商品状态，最后才提出退货要求。系统需要将这些信息合并为完整状态，而不能只依据最后一句话作答。

需要保存的状态通常包括：

• 用户身份及授权状态；
• 当前处理的业务对象；
• 用户明确表达的目标；
• 已确认和未确认的信息；
• 已执行的工具操作；
• 仍需补充的必要字段；
• 用户提出的偏好、限制和禁忌。

如果状态管理不稳定，系统可能重复询问、遗漏限制条件，甚至操作错误的业务对象。

2. 业务规则约束

企业服务通常包含大量硬性规定。例如，某类操作只能在规定期限内执行，高风险动作需要再次确认，特定信息必须完成身份核验后才能展示。

这些规则不是一般性的语言知识，而是业务执行边界。模型即使理解了用户意图，也可能因为忽略规则而产生不合规操作。

3. 工具调用约束

智能助手常常需要调用订单查询、库存检索、预约修改、工单创建等外部能力。工具调用不仅要求选对工具，还要求：

• 参数名称与数据类型正确；
• 参数值来自可信的对话状态；
• 调用顺序符合业务流程；
• 正确解释工具返回结果；
• 对超时、空结果和权限不足进行处理；
• 避免重复执行具有副作用的操作。

因此，“回复看起来正确”不等于“任务执行正确”。

4. 动态恢复约束

真实业务流程并不总是顺利。用户可能突然改变需求，工具可能返回异常，目标对象可能不存在，原计划也可能因规则冲突而无法继续。智能助手必须识别当前路径已经失效，并重新规划，而不是机械重复同一操作。

二、先建立可观测的错误分类体系

要实现精准增强，第一步不是训练模型，而是将笼统的“任务失败”拆解为可测量、可归因的错误类别。

一个实用的分层体系可以包含以下五类问题。

1. 记忆与状态错误

典型表现包括：

• 忘记用户之前提供的信息；
• 混淆多个订单或多个服务对象；
• 将模型自己的推测当作用户事实；
• 在用户修改需求后仍沿用旧状态；
• 重复询问已经明确回答的问题。

诊断时应区分两种情况：模型没有看到信息，还是模型看到了但没有正确使用。前者通常属于上下文组装或状态存储问题，后者才更接近模型理解能力问题。

2. 语义理解错误

此类错误主要表现为意图、对象或约束识别不准确。例如，用户说“不要取消，只想改时间”，系统却触发取消流程；用户询问是否符合条件，系统却直接执行操作。

可进一步拆分为：

• 主意图识别错误；
• 否定关系理解错误；
• 时间、数量和范围解析错误；
• 指代对象识别错误；
• “咨询”与“执行”混淆；
• 隐含约束遗漏。

3. 规则遵循错误

模型可能理解用户需求，却没有遵守业务政策。常见情况包括：

• 未核验身份就展示敏感信息；
• 未获得明确确认就执行高风险动作；
• 在条件不满足时仍承诺办理；
• 自行编造例外政策；
• 多条规则冲突时选择了错误优先级。

这类错误风险较高，应与普通回答质量问题分开统计。

4. 规划与决策错误

模型知道目标，也掌握规则，但无法生成正确的步骤序列。例如，本应先查询状态、再校验条件、最后请求确认，模型却跳过查询直接执行。

规划错误通常包括：

• 工具选择错误；
• 调用顺序错误；
• 缺少必要前置步骤；
• 已有结果却重复调用；
• 遇到失败后无法选择替代路径；
• 在任务结束前过早向用户宣布成功。

5. 工具交互错误

这一层关注模型与外部系统之间的接口行为，包括参数缺失、字段格式错误、返回结果误读和重复提交等。

尤其需要关注“语言正确、执行错误”的情况。例如，模型向用户说明操作失败，但后台实际上已经成功提交；随后再次调用同一工具，就可能形成重复订单或重复退款。

三、建立自动化诊断流程

错误分类不能完全依赖人工阅读日志，否则评估成本会随测试规模快速上升。更可行的方式是为每个测试任务定义结构化预期。

一个任务样本至少应包含：

任务输入：
  初始用户需求
  可用业务数据
  可用工具列表
  业务规则集合
预期约束：
  必须执行的步骤
  禁止执行的动作
  必须获取的确认
  最终允许的状态
运行记录：
  每轮对话内容
  状态变量变化
  工具调用及参数
  工具返回结果
  最终业务状态

评估器不应只检查最终回复文本，还应核对完整执行轨迹。可以将任务成功定义为：

任务成功 =
  目标状态正确
  且无禁止操作
  且必要确认已完成
  且工具调用无严重错误

在此基础上，再分别计算：

• 任务完成率；
• 规则违规率；
• 工具调用正确率；
• 多轮状态一致率；
• 异常恢复成功率；
• 平均交互轮数；
• 无效或重复调用次数；
• 高风险误操作次数。

这些指标能够避免单一总分掩盖关键问题。两个模型即使任务完成率接近，也可能一个主要失败于记忆，另一个主要失败于规则执行，对应的优化方法完全不同。

四、根据病因选择最小化干预

完成诊断后，应优先使用成本较低、可解释性较强的增强手段。只有在外部机制无法弥补时，才考虑训练层面的改造。

1. 针对记忆问题：引入结构化状态

不要把所有历史对话原样堆入上下文。更稳妥的方法是维护一个独立状态对象：

会话状态：
  用户目标：修改预约时间
  服务对象：某条预约记录
  身份状态：已核验
  原时间：已确认
  目标时间：待确认
  风险操作确认：未获取
  最近工具结果：记录存在，可修改

每轮交互后，只更新发生变化的字段，并保留字段来源。这样可以减少长上下文中的信息干扰，也便于审计模型为什么作出某项决策。

对于用户明确修改的信息，应采用新值覆盖旧值，同时记录变更历史，避免模型继续引用失效状态。

2. 针对规则问题：将硬规则移出生成模型

高风险规则不应只写在自然语言提示中。更可靠的做法是增加确定性的规则校验层，对关键动作进行前置拦截。

示意逻辑如下：

如果动作具有资金、账户或隐私影响：
    检查身份核验状态
    检查业务条件
    检查用户是否明确确认
    任一条件不满足，则禁止执行
否则：
    允许进入普通工具调用流程

生成模型负责理解用户意图和组织交流，规则层负责保证边界。两者职责分离后，即使模型偶尔推理错误，也不应直接造成高风险操作。

3. 针对规划问题：限制动作空间

小型模型面对过多工具和过长说明时容易混淆。可以根据当前业务阶段，只暴露必要的工具。例如，在身份尚未核验时，只允许调用身份核验和普通查询能力；完成核验后，再开放修改类操作。

同时，可以将复杂任务拆分为固定阶段：

1. 识别目标；
2. 收集必要信息；
3. 查询当前状态；
4. 校验业务条件；
5. 获取用户确认；
6. 执行操作；
7. 验证最终结果；
8. 向用户反馈。

阶段化编排可以显著减少越级执行和调用顺序错误。

4. 针对参数错误：使用严格的数据模式

工具参数应具备明确的数据类型、必填字段和取值范围。模型生成调用请求后，先通过校验器检查，再决定是否真正执行。

例如：

修改请求：
  记录标识：必填字符串
  新时间：必填标准时间值
  用户确认：必填布尔值
  请求标识：必填且不可重复

如果参数缺失，应让系统回到信息收集阶段，而不是猜测字段值。对于具有副作用的操作，还应设置幂等标识，防止网络重试或模型重复调用造成二次执行。

5. 针对语义理解问题：使用针对性样本训练

如果错误集中在否定表达、指代消解或咨询与执行的区分上，可以构建覆盖这些边界情况的训练样本，而不是泛化地增加大量普通对话。

高价值样本通常包含：

• 相似表达但不同意图；
• 用户中途改变目标；
• 多个业务对象同时出现；
• 条件不满足时的拒绝流程；
• 工具异常后的恢复步骤；
• 必须等待明确确认的高风险动作。

训练数据还应包含错误示例及其修正理由，使模型学习“为什么不能这样执行”，而不只是模仿最终答案。

五、避免看似有效但风险较高的优化方式

1. 盲目增加提示词长度

提示词越长并不意味着规则遵循越好。过多说明可能导致重点稀释、规则冲突和上下文成本上升。应将提示内容分为角色目标、当前状态、可用动作和关键限制，避免重复描述。

2. 只评估最终话术

语言自然、态度礼貌的回答，背后可能对应错误操作。企业评估必须覆盖执行轨迹和最终数据状态，而不能只依赖文本相似度或人工观感。

3. 用一个修复方案处理所有模型

不同模型的主要瓶颈可能完全不同。对于记忆薄弱的模型，增加结构化状态更有效；对于规则意识不足的模型，应优先加强外部校验；对于工具参数不稳定的模型，则需要严格模式与调用约束。统一套用同一种增强方案，容易引入额外复杂度。

4. 让模型自行判断所有安全边界

模型可以参与风险识别，但不能成为唯一的安全控制点。涉及资金、隐私、账户和医疗建议等高风险场景时，必须设置独立、确定、可审计的控制机制。

六、形成持续迭代的工程闭环

精准增强不是一次性工作。业务规则会变化，工具接口会升级，用户表达方式也会不断出现新模式。因此，系统需要持续收集失败案例并进行回归验证。

推荐采用以下迭代流程：

1. 从线上日志中抽取失败和低置信度任务；
2. 对失败轨迹进行分层标注；
3. 统计各类错误的频率与业务风险；
4. 优先修复高频或高风险问题；
5. 将案例加入离线测试集；
6. 对修改前后版本进行同条件复验；
7. 观察任务成功率、违规率、时延和成本变化；
8. 通过灰度方式逐步扩大部署范围。

同时，应防止测试集被过度适配。除了固定回归集，还需要保留未参与调优的验证任务，并加入信息缺失、规则冲突、工具异常和用户反复变更需求等压力场景。

七、企业落地时的架构建议

一个可控的任务型智能助手通常可以拆分为以下层次：

• 交互层：负责接收用户输入并输出自然语言回复；
• 状态层：维护会话事实、用户目标和任务进度；
• 决策层：判断下一步需要询问、查询还是执行；
• 规则层：校验业务政策、权限和风险条件；
• 工具层：连接数据库、业务系统和外部接口；
• 审计层：记录输入、状态变化、调用轨迹和最终结果；
• 评估层：对任务成功、合规性和恢复能力进行持续检测。

这种分层设计的核心价值，是将模型从“包办一切的黑盒”转变为“受约束的决策组件”。模型仍然负责最擅长的语义理解与自然交互，但关键规则、数据状态和执行权限由可验证的工程机制控制。

结语

小型模型能否用于复杂企业任务，不能只看参数规模或通用问答能力。真正决定系统可用性的，是能否准确识别其失败模式，并以最小成本补齐关键短板。

一套成熟的方法应从错误分类开始，以完整执行轨迹为依据，将记忆、理解、规则、规划和工具交互问题分别测量。随后根据诊断结果选择结构化状态、规则校验、阶段化编排、参数约束或针对性训练，而不是直接叠加所有增强手段。

归根结底，可靠的智能助手不是单个模型，而是一套可观测、可约束、可恢复、可审计的任务执行系统。只有先知道问题发生在哪里，优化工作才可能从经验试错转变为可验证的工程过程。