知识与集成

企业级 AI Agent“主动澄清与混合主动权交互”(Active Clarification & Mixed-Initiative Interaction)架构实战:破解模糊意图幻觉臆断、关键槽位缺失与破坏性误调用

针对企业复杂业务场景中用户输入模糊简略、关键业务槽位缺失容易引发大模型幻觉臆造参数并导致破坏性接口误调用的致命痛点,深度拆解“主动澄清与混合主动权”工程架构:基于信息熵与置信度差值的歧义侦测引擎、轻量化交互式选择卡片生成、避免盘问骚扰的自适应澄清策略,以及用户澄清后的执行图上下文无缝缝合(Context Splicing & State Resumption),并提供生产级 TypeScript 核心引擎实现。

百信 AI Agent发布于 约 8 分钟
现代企业工程师在工作台操作 AI Agent 主动澄清与混合主动权交互系统示意图
现代企业工程师在工作台操作 AI Agent 主动澄清与混合主动权交互系统示意图

在企业真实生产环境中,终端业务人员向大模型智能体下达的指令往往具有极高的口语化与不完备性特征(例如“帮我把刚才张总那笔急单处理一下”、“把昨天的质检不良品退货并扣减供应商应付款”)。这类输入通常缺失关键上下文(如具体的工厂代码、物料批次编号、退货原因代码),且存在严重实体歧义(如“张总”在企业通讯录与客户库中可能匹配多位高管或供应商)。传统 AI Agent 架构在面对此类模糊输入时普遍陷入两大工程极端:要么盲目自信(Over-confident Hallucination),根据大模型幻觉自作主张臆造默认参数去调用外部写接口,引发毁灭性数据脏写;要么死板被动(Passive Rigidness),遇到参数校验失败就直接机械式报错中断,或稍微遇到不确定性就连续输出大段自然语言对用户进行“查户口式”盘问。为了破解这一落地死结,“主动澄清与混合主动权交互”(Active Clarification & Mixed-Initiative Interaction)架构成为企业级智能体的核心标配。本文结合百信企业智能体平台的研发实践,深入剖析歧义与槽位缺失度量引擎、自适应澄清时机决策(Clarification Policy)、交互式结构化卡片渲染以及用户反馈的执行图上下文无缝缝合(Context Splicing)机制,并提供生产级 TypeScript 核心引擎的完整实现方案。

企业长工具链中的“模糊性陷阱”:从大模型幻觉臆断到不可逆业务破坏

在消费级聊天场景中,大模型的模糊回答通常仅带来阅读体验的轻微瑕疵;但在严肃的企业企业级系统集成(如对接 SAP、用友、金蝶 ERP、MES 制造执行系统或 OA 审批中枢)中,智能体肩负着调用真实 API 乃至执行财务划扣、物料调拨、采购下单等不可逆写操作的职责。此时,模糊意图所引发的工程风险将呈指数级放大:

1. 参数幻觉与高危破坏性物理脏写

大语言模型天然具备补全概率最高的上下文的倾向。当智能体调用一个要求提供 warehouse_id(仓库编号)、batch_no(物料批次)与 deduction_type(扣款模式)的 ERP 写入接口,而用户 Prompt 仅仅模糊提及“扣减供应商款项”时,若没有严格的前置澄清协议,模型在经过几轮思考链(CoT)推理后,极有可能根据上下文最相似的历史记忆自动脑补出一个虚构的“默认仓库代码”。一旦该 API 被实际触发,将直接导致底层数据库账目失真、实物库存与系统台账严重脱节,且无法通过简单的事务回滚进行事后修复。

2. 静态 Schema 校验与死板报错的体验崩塌

为防止上述参数幻觉,部分系统引入了基于 Pydantic 或 Zod 的严格类型校验。然而,单纯依赖静态校验会导致系统表现出极高的机械性脆弱性:一旦检测到必填参数缺失,直接给用户抛出冷冰冰的 ValidationError: missing required field 'supplier_tax_code'。用户面对晦涩的底层技术报错往往茫然不知所措,不知道该补充什么信息,彻底破坏了人机协作的流畅性。

3. 大段文本盘问引发的“认知过载”与反问骚扰

另一类初级智能体虽然学会了“反问”,但处理方式极其粗糙:一旦遇到不确定,便在回复中堆砌一大段口语化反问,如“请问您是指张伟还是张强?采购单号是多少?您是要走银行电汇还是承兑汇票?请把这几项逐一告诉我”。要求在移动端或高频业务前线作战的用户手动敲击大段文本进行回复,会给用户带来巨大的认知负担与时间成本,最终导致业务人员放弃使用智能体并回退到传统手工操作。

交互范式不确定性处理机制业务写操作安全等级用户心智与交互成本系统综合成败归因
传统单向执行 (Blind Action)模型自行脑补默认值或幻觉填空极高危:易发生破坏性脏写表面零成本,实则背负巨大排错成本不可控,严禁用于生产企业中枢
机械阻断报错 (Rigid Validation)抛出底层 Schema 异常直接终止安全:阻断了非法调用极高:用户面对底层错误不知所措体验极差,智能体沦为“脆弱执行器”
口语化连续反问 (Chatty Interrogation)生成大段自然语言提问清单中等:取决于后续用户输入解析极高:迫使用户打长字解答所有细节用户疲劳度高,容易被弃用
混合主动权澄清 (Mixed-Initiative)信息熵判定 + 结构化卡片主动反问极高:阻断高危写操作,保留只读探针极低:一键点选单选项或带建议表单兼顾安全性与极致流畅性,企业标杆

混合主动权交互(Mixed-Initiative Interaction)核心范式:打破单向命令与死板盘问

混合主动权(Mixed-Initiative Interaction)最早源自人机工程与人机协同理论,在企业级智能体架构中,它强调在任务执行的不同阶段,对话的主动权(Initiative)能够在用户与智能体之间进行动态、自主的双向流转:

1. 主动权的动态转移逻辑

  • 用户持有主动权阶段:用户表达宏观意图(Goal Specification),提出期望达成的高阶业务结果;
  • 智能体持有主动权阶段:智能体在解析意图时,发现多候选实体歧义或必要业务槽位缺失。智能体并非死板报错,而是主动接管对话权,向用户输出针对性问题、推荐选项或微型交互卡片;
  • 主动权安全归还阶段:用户通过极轻量的单选或表单提交明确意图后,智能体将增量输入精准缝合回上下文,并继续推进后续工具链执行,重新将最终业务结果呈现给用户。

2. 混合主动权的三大黄金工程原则

  1. 高危写操作绝不猜测(No Guessing on Mutating Calls):凡涉及资产增减、状态扭转、外发邮件或审批提单的动作,关键槽位必须 100% 具备确凿证据支持,否则坚决触发澄清;
  2. 只读探针先行推演(Read-First Probing):对于查询类辅助操作,智能体可利用上下文已有线索先行发起只读查询,将真实候选列表拉取至本地,从而为用户生成精准的候选单选卡片,而非要求用户凭空回忆;
  3. 最小认知摩擦(Minimum Cognitive Friction):澄清方式必须优先采用 UI 结构化交互(如单选钮、日期范围快捷选择器),严禁要求用户手动输入格式严苛的 UUID 或技术编号。

歧义与槽位缺失检测引擎:基于 Schema 约束、信息熵与置信度差值判定

要实现精准的主动澄清,首要前提是建立一套严密的数学与工程判定体系,能够实时量化当前上下文的“不确定性程度(Uncertainty Degree)”。

1. 槽位类型与依赖拓扑建模(Slot Dependency Graph)

在企业级业务中,参数之间往往不是扁平的,而是存在复杂的级联依赖关系。我们将槽位抽象为三种类型:

  • 绝对必需槽位(Mandatory Slots):如创建采购单时的供应商代码 supplier_id。缺失则完全无法进入后续步骤;
  • 条件依赖槽位(Conditionally Dependent Slots):如若付款方式 payment_method 选择“银行承兑”,则承兑汇票号 acceptance_bill_no 自动变为必需槽位;若选择“现金电汇”,则该槽位为非法或忽略;
  • 默认继承槽位(Derivable Slots):如工厂所属税率 tax_rate,若未提供,可根据供应商注册地与商品类别从企业知识库中自动推导,仅在推导结果冲突时才触发澄清。

2. 候选实体语义歧义度计算(Confidence Margin Analysis)

当用户在输入中提及某个命名实体(如“上海仓”、“老李”),通过向量检索或知识图谱实体链接(Entity Linking)可能会召回多个候选结果。我们引入置信度差值(Margin)与标准化香农熵(Normalized Shannon Entropy)来度量歧义烈度:

歧义度量公式与工程规则:
设实体链接召回的候选集合为 C = [c1, c2, ..., ck],各候选归一化置信度得分降序排列为 s1 >= s2 >= ... >= sk。
Top-1 置信度差(Confidence Margin): Delta = s1 - s2
候选分布香农信息熵(Candidate Entropy): H(C) = - SUM(s_i * log2(s_i))
判定规则:
1. 若 s1 >= 0.88 且 Delta >= 0.35:视为无歧义(Unambiguous),系统自动绑定高置信实体 c1;
2. 若 0.65 <= s1 < 0.88 或 Delta < 0.35 且 H(C) >= 1.2:判定存在严重实体混淆,必须触发针对性歧义澄清卡片,将 Top-N 候选展示给用户一键选择;
3. 若 s1 < 0.65:判定为未知实体,提示用户重新输入或在全局知识库中检索。

自适应澄清时机决策(Clarification Policy):何时自主行动、何时主动反问(Ask vs. Act)

在智能体系统中,“动辄就问”会让用户烦躁,而“闷头蛮干”会导致重大事故。构建企业级自适应澄清决策器(Clarification Policy Engine)的核心任务,就是在这两者之间找到最优解。

1. 效用理论与操作风险矩阵(Decision Risk Matrix)

我们将智能体即将调用的动作按破坏性与回滚代价划分为四个等级:

  1. Tier 0(纯只读查询,Read-Only):如查询 ERP 库存、检索通讯录。回滚成本为 0。即使槽位存在轻微模糊(如未提供具体库位),智能体应自主使用最宽泛条件检索,并在回复中提示“已为您默认查询全仓汇总”;
  2. Tier 1(可幂等安全更新,Idempotent Safe Mutation):如修改个人工作备忘、保存草稿单据。回滚成本极低。智能体可携带建议默认值执行,并明确通知用户;
  3. Tier 2(业务状态流转,Workflow State Transition):如提交审批流、触发生产排产计算。不可直接物理删除,需走驳回流程。回滚成本中等。若置信度低于 0.85 必须向用户澄清确认;
  4. Tier 3(高危破坏性资产写入,Destructive Financial/Physical Mutation):如确认支付、取消正式采购合同、报废入库物料。回滚成本极高,甚至造成法律纠纷。无论模型推理置信度多高,若缺少关键约束,必须强制阻断并触发交互式确认与澄清卡片。

2. 澄清决策有限状态机(Clarification FSM)

决策引擎将评估结果归纳为四种行动指令:

  • EXECUTE_IMMEDIATELY:全量槽位齐备且动作风险可控,直接推进执行;
  • SPECULATIVE_EXECUTE_WITH_HINT:只读类低风险操作,执行前置探针并在结果中友好提示缺省条件;
  • REQUEST_CLARIFICATION:阻断当前执行流,挂起等待用户完成结构化卡片选择;
  • ESCALATE_TO_ADMIN:检测到恶意注入或严重权限冲突,直接转交人工安全管理员审计。

交互式澄清卡片与组件生成:将多义歧义转化为结构化低认知操作

主动澄清的成败,80% 取决于前端交互形式。如果智能体仅仅吐出一段 Markdown 文本,用户依然需要手动打字,交互转化率将暴跌。企业级智能体平台应支持动态生成富交互澄清组件(Generative UI / Clarification Cards):

1. 单选消歧卡片(Disambiguation Selection Card)

当多个实体相似度接近时,后端将候选实体转化为 JSON 描述符,前端将其渲染为带辅助属性的单选卡片。例如:

📋 匹配到多个符合条件的采购订单,请确认您要操作的具体单据:
PO-2026-0918-01苏州精密加工中心 / 金额 ¥48,000 / 状态: 待入库
PO-2026-1002-04无锡液压传动部件 / 金额 ¥126,500 / 状态: 质检中

2. 槽位快速补填表单(Mini Slot-Filling Form)

当仅缺失 1~2 个关键字段时,直接在消息气泡内内嵌一个包含预填推荐值的微型表单组件。用户点击“确认”后,前端自动构造标准化的澄清响应载荷,无需经过自然语言大模型重新解析,直接注入状态引擎。

澄清输入的上下文无缝缝合(Context Splicing)与执行图状态恢复

当用户在前端完成澄清选择后,系统如何将这一增量信息注入到长程工作流中?传统方案往往是将用户的选择作为一条新自然语言灌入对话历史重新唤起 LLM,这种做法会带来三大弊端:算力浪费(重复跑前半段推理)、状态漂移(模型可能推翻之前的正确结论)以及可能引发二次歧义。

1. 执行图挂起与快照切片(StateGraph Suspend & Slice)

在百信企业智能体平台的架构中,工作流编排引擎采用类似 LangGraph 的状态图模型。当决策器判定需要澄清时:

  • 原子检查点持久化:系统在当前执行节点保存不可变快照(Checkpoint),包括当前已验证的槽位字典 validatedSlots、挂起的工具调用签名 pendingToolCall 以及中断令牌 interruptToken;
  • 会话状态置为挂起(Awaiting Clarification):进程释放工作线程,仅在 Redis / PostgreSQL 中保留持久化状态与 TTL 超时设定;
  • 幂等性保障:前置已经完成的只读查询结果(如前置知识检索、ERP 单据初步探针结果)被严密锁定在快照中,恢复时严禁重复触发外部接口。

2. 上下文无缝缝合算法(Context Splicing Algorithm)

当收到用户提交的澄清结果后,状态管理器执行以下三步无缝恢复操作:

  1. 结构化响应解析:直接校验用户回传的 clarificationPayload 是否满足目标槽位的严格模式约束;
  2. 增量状态打补丁(State Patching):将补齐的槽位与快照中的 validatedSlots 进行浅合并,形成完整参数上下文;
  3. 原地热恢复(In-place Warm Resumption):绕过前端意图识别模型,直接将合成后的工具调用参数派发给执行器,驱动工具链继续向前执行,实现零 Token 浪费与 100% 确定性复原。

工业级 TypeScript 核心引擎实战:主动澄清调度器与状态缝合完整实现

下面给出百信企业智能体平台核心模块——主动澄清调度引擎(Active Clarification & Context Splicing Engine)的生产级 TypeScript 完整参考实现。代码涵盖槽位依赖校验、置信度差值计算、风险决策分流与执行图挂起恢复闭环:

/**
 * 企业级 AI Agent 主动澄清与混合主动权调度引擎核心实现
 * 覆盖:槽位验证、歧义置信度分析、决策策略、交互卡片生成与上下文缝合
 */

// 业务操作风险等级定义
export enum ActionRiskTier {
  TIER0_READONLY = 0,   // 纯只读,容错率高,回滚成本为 0
  TIER1_SAFE_WRITE = 1, // 可逆轻量写,草稿/备忘
  TIER2_WORKFLOW = 2,   // 业务状态扭转,需走驳回流程
  TIER3_DESTRUCTIVE = 3 // 财务划扣/库存核销/合同作废,不可逆高危
}

// 槽位定义接口
export interface SlotDefinition {
  name: string;
  label: string;
  required: boolean;
  type: 'string' | 'number' | 'enum' | 'date';
  options?: string[]; // 枚举候选项
  description: string;
  defaultValue?: any;
}

// 实体匹配候选结构
export interface EntityCandidate {
  id: string;
  name: string;
  score: number; // 匹配置信度 0~1
  attributes: Record<string, any>;
}

// 澄清卡片类型枚举
export enum ClarificationCardType {
  DISAMBIGUATION = 'DISAMBIGUATION', // 歧义多选一
  SLOT_FILLING = 'SLOT_FILLING',     // 缺失字段微表单
  CONFIRMATION = 'CONFIRMATION'      // 高危操作最终确认
}

// 澄清卡片结构体
export interface ClarificationCard {
  cardId: string;
  type: ClarificationCardType;
  title: string;
  description: string;
  targetField: string;
  candidates?: EntityCandidate[];
  missingSlots?: SlotDefinition[];
  riskTier: ActionRiskTier;
  timeoutSeconds: number;
}

// 执行图中断检查点状态
export interface ExecutionCheckpoint {
  checkpointId: string;
  sessionId: string;
  toolName: string;
  riskTier: ActionRiskTier;
  validatedSlots: Record<string, any>;
  clarificationCard: ClarificationCard;
  createdAt: number;
  status: 'PENDING' | 'RESOLVED' | 'EXPIRED';
}

/**
 * 主动澄清策略与调度中枢引擎
 */
export class ClarificationPolicyEngine {
  private checkpoints: Map<string, ExecutionCheckpoint> = new Map();

  /**
   * 计算候选实体之间的歧义度与置信度差值
   * @param candidates 召回的实体列表(按得分降序排序)
   * @returns 是否存在严重混淆与推荐采取的动作
   */
  public evaluateAmbiguity(candidates: EntityCandidate[]): {
    isAmbiguous: boolean;
    bestCandidate?: EntityCandidate;
    confidenceMargin: number;
  } {
    if (!candidates || candidates.length === 0) {
      return { isAmbiguous: false, confidenceMargin: 0 };
    }

    if (candidates.length === 1) {
      return {
        isAmbiguous: candidates[0].score < 0.70,
        bestCandidate: candidates[0].score >= 0.70 ? candidates[0] : undefined,
        confidenceMargin: candidates[0].score
      };
    }

    // 计算 Top-1 与 Top-2 置信度差
    const top1 = candidates[0];
    const top2 = candidates[1];
    const margin = top1.score - top2.score;

    // 若 Top-1 得分足够高且与 Top-2 差距显著,判定为无歧义
    if (top1.score >= 0.88 && margin >= 0.30) {
      return { isAmbiguous: false, bestCandidate: top1, confidenceMargin: margin };
    }

    // 否则判定存在严重实体冲突,需要澄清
    return { isAmbiguous: true, bestCandidate: undefined, confidenceMargin: margin };
  }

  /**
   * 评估槽位完整度与风险,生成自适应决策
   */
  public evaluateExecutionReadiness(
    toolName: string,
    riskTier: ActionRiskTier,
    slotDefs: SlotDefinition[],
    providedSlots: Record<string, any>,
    ambiguousCandidatesMap?: Record<string, EntityCandidate[]>
  ): {
    action: 'PROCEED' | 'CLARIFY';
    clarificationCard?: ClarificationCard;
  } {
    const missingRequiredSlots: SlotDefinition[] = [];
    const ambiguousFields: { field: string; candidates: EntityCandidate[] }[] = [];

    // 1. 检查歧义实体
    if (ambiguousCandidatesMap) {
      for (const [field, candidates] of Object.entries(ambiguousCandidatesMap)) {
        const ambResult = this.evaluateAmbiguity(candidates);
        if (ambResult.isAmbiguous) {
          ambiguousFields.push({ field, candidates });
        } else if (ambResult.bestCandidate && !providedSlots[field]) {
          providedSlots[field] = ambResult.bestCandidate.id;
        }
      }
    }

    // 2. 检查必填槽位
    for (const def of slotDefs) {
      const val = providedSlots[def.name];
      const isMissing = val === undefined || val === null || val === '';
      if (def.required && isMissing) {
        missingRequiredSlots.push(def);
      }
    }

    // 3. 制定执行策略
    // 优先解决歧义实体(因为实体确定后可能衍生出默认槽位)
    if (ambiguousFields.length > 0) {
      const target = ambiguousFields[0];
      return {
        action: 'CLARIFY',
        clarificationCard: {
          cardId: `card-${Date.now()}-${Math.random().toString(36).slice(2, 7)}`,
          type: ClarificationCardType.DISAMBIGUATION,
          title: `请选择明确的${target.field}`,
          description: `系统检索到多个相似对象,请点击确认您要操作的具体项:`,
          targetField: target.field,
          candidates: target.candidates,
          riskTier,
          timeoutSeconds: 300
        }
      };
    }

    // 若存在缺失必填槽位
    if (missingRequiredSlots.length > 0) {
      // 若为纯只读操作且存在默认值,可走推测执行
      if (riskTier === ActionRiskTier.TIER0_READONLY) {
        let allHaveDefaults = true;
        for (const slot of missingRequiredSlots) {
          if (slot.defaultValue !== undefined) {
            providedSlots[slot.name] = slot.defaultValue;
          } else {
            allHaveDefaults = false;
          }
        }
        if (allHaveDefaults) {
          return { action: 'PROCEED' };
        }
      }

      // 高危写操作必须阻断并生成槽位补填表单
      return {
        action: 'CLARIFY',
        clarificationCard: {
          cardId: `card-${Date.now()}-${Math.random().toString(36).slice(2, 7)}`,
          type: ClarificationCardType.SLOT_FILLING,
          title: `缺少关键操作参数`,
          description: `调用【${toolName}】需要补充以下信息以保证业务执行安全:`,
          targetField: missingRequiredSlots.map(s => s.name).join(','),
          missingSlots: missingRequiredSlots,
          riskTier,
          timeoutSeconds: 300
        }
      };
    }

    // 高危 Tier 3 操作即使参数齐全,亦须弹出最终防呆确认卡片
    if (riskTier === ActionRiskTier.TIER3_DESTRUCTIVE) {
      return {
        action: 'CLARIFY',
        clarificationCard: {
          cardId: `card-${Date.now()}-${Math.random().toString(36).slice(2, 7)}`,
          type: ClarificationCardType.CONFIRMATION,
          title: `高危操作确认`,
          description: `此操作将直接影响企业账目/库存状态,不可物理撤销,请核对参数后确认:`,
          targetField: '_global_confirmation',
          riskTier,
          timeoutSeconds: 180
        }
      };
    }

    return { action: 'PROCEED' };
  }

  /**
   * 挂起工作流并持久化不可变检查点
   */
  public suspendWorkflow(
    sessionId: string,
    toolName: string,
    riskTier: ActionRiskTier,
    validatedSlots: Record<string, any>,
    card: ClarificationCard
  ): ExecutionCheckpoint {
    const checkpointId = `ckpt-${sessionId}-${Date.now()}`;
    const checkpoint: ExecutionCheckpoint = {
      checkpointId,
      sessionId,
      toolName,
      riskTier,
      validatedSlots: { ...validatedSlots },
      clarificationCard: card,
      createdAt: Date.now(),
      status: 'PENDING'
    };
    this.checkpoints.set(checkpointId, checkpoint);
    return checkpoint;
  }

  /**
   * 上下文无缝缝合(Context Splicing)与原地恢复
   * @param checkpointId 挂起的检查点 ID
   * @param userInput 用户在卡片上提交的结构化数据
   */
  public resumeWithSplicing(
    checkpointId: string,
    userInput: Record<string, any>
  ): {
    success: boolean;
    toolName: string;
    finalExecutionPayload: Record<string, any>;
    message: string;
  } {
    const ckpt = this.checkpoints.get(checkpointId);
    if (!ckpt) {
      throw new Error(`未找到指定检查点: ${checkpointId}`);
    }
    if (ckpt.status !== 'PENDING') {
      throw new Error(`检查点状态已失效: ${ckpt.status}`);
    }

    // 检查超时
    const elapsedSeconds = (Date.now() - ckpt.createdAt) / 1000;
    if (elapsedSeconds > ckpt.clarificationCard.timeoutSeconds) {
      ckpt.status = 'EXPIRED';
      throw new Error('澄清卡片已超时过期,请重新发起指令');
    }

    // 执行状态浅合并打补丁(Context Splicing)
    const mergedSlots = {
      ...ckpt.validatedSlots,
      ...userInput
    };

    // 标记检查点完成
    ckpt.status = 'RESOLVED';

    return {
      success: true,
      toolName: ckpt.toolName,
      finalExecutionPayload: mergedSlots,
      message: `成功缝合澄清上下文,已恢复【${ckpt.toolName}】原地执行`
    };
  }
}

典型业务落地场景(ERP/MES/OA)与架构避坑指南

在百信企业客户的实际私有化部署项目中,主动澄清机制在多个高频严苛场景中发挥了决定性保障作用:

1. 场景一:ERP 采购变更与供应商歧义消除

业务痛点:采购经理口语下达“取消昨天同创科技的轴承订单”。然而在 ERP 供应商名录中,存在“同创精密科技(苏州)有限公司”与“同创智能工业装备(常州)有限公司”,分别涉及不同产线备件。
落地成效:智能体前置发起只读探针拉取两家供应商昨日生成的 PO 单据,通过单选消歧卡片向采购经理展示具体的单据编号、交期与物料品名。采购员一键点击确认后直接触发精准取消,杜绝了误撤正常生产单据的严重事故。

2. 场景二:MES 产线异常停机工单申报与参数补齐

业务痛点:车间班组长在平板上语音输入“3 号机床主轴报警停了,叫机修来看看”。MES 报修接口必须输入停机故障等级(轻微/严重/停产)、模具料号与受影响工序批次。
落地成效:系统识别出 fault_level 与 batch_no 缺失,但结合当前排产计划推导出候选料号,在平板端弹出微型带预选标签的确认卡片。班组长耗时不到 2 秒点击“模具已卡死,全线停产”标签,智能体直接生成一级抢修派工单,响应时效缩短 65%。

3. 架构实施避坑指南

  • 防范“反问循环死锁(Clarification Deadlock):”必须严格设定单轮任务最大澄清次数(建议最多 2 轮)。若用户连续两轮未能明确参数,智能体应主动降级,输出帮助指引或转交人工坐席;
  • 防御澄清通道中的 Prompt 注入攻击:用户在澄清卡片中的输入必须经过静态类型反序列化校验,严禁将未转义的用户输入作为执行参数直接拼接进动态 SQL 或脚本沙箱;
  • 建立跨会话澄清记忆缓存(Disambiguation Memory):若用户多次将“张总”明确为“供应商张伟(ID: SUP-9021)”,系统应将此偏好写入用户的私人工作记忆(Episodic Memory),后续对话自动提升该实体的先验概率,实现越用越聪明的正向闭环。