设计一个工单自动处理 Agent：分类、查询、升级转人工

先做意图分类，把工单分成几大类；能自动处理的走自动流程，比如查订单状态、查物流、改地址这些；处理不了的转人工。Agent 挂几个工具：查订单、查知识库、改工单状态、发通知。加护栏，比如退款金额超过一定额度必须人工审批。再做个监控，看自动处理率和用户满意度。

框架完整，及格。但它有三个软肋：分类用什么做没说、转人工的判据只有「处理不了」这一条、评测只有结果指标没有轨迹。这三点恰好是追问的主攻方向。

① 先问四个问题：工单量和类型分布是什么样——头部几类占多少？（这决定了值不值得上 Agent）现在人工的平均处理时长和一次解决率是多少？哪些操作是不可逆的——退款、改单、发通知给客户？以及最关键的：这个项目的目标是降人力成本，还是缩短响应时间？两者的设计完全不同：降成本要提高自动处理率、容忍一点错误；缩短响应时间可以先做「秒回一个准确的进度」，自动率不高也有价值。

② 基线：先不上 Agent。 工单场景的正确基线是规则分类 + 写死的 workflow——头部几类工单（查进度、查物流、改地址、开发票）流程是确定的，用 if/else 加三五个工具就能覆盖，而且可预测、可审计、便宜。我会先说这套基线能到什么水平：如果头部五类占了总量的六成，光这套就能自动处理其中的大部分。Agent 是用来吃剩下那四成长尾的，不是用来重写这六成的。

③ 加挂，每样说代价：

• 意图分类：先规则后模型，且要有「不确定」这一档。头部类目用关键词加规则（准、快、可解释），长尾用模型。代价：两套要维护；关键设计：分类必须能输出「不确定」，而不是强行归到最近的一类——强行分类是工单场景最常见的事故源，因为它会把一个投诉工单归到「查进度」然后自动回复一段模板。

• Agent 只用在长尾。解决什么：长尾工单的路径不确定，需要多轮查询和判断。代价：不可预测、贵、难审计，且每一轮都要调模型。什么时候不该用：路径确定的流程，用 Agent 只会更慢更贵更不稳。

• 分级自治控制写操作（这是本题的核心）。按不可逆程度而不是置信度分级：

  只读查询（查单、查物流、查知识库） → 自动执行，事后抽样
  可逆写入（打标签、加内部备注）     → 自动执行 + 通知
  难逆写入（改工单状态、改地址）     → 先确认，展示将要做什么
  不可逆（退款、发短信给客户、关单） → 人工签字 + 二次确认
  

  代价：确认环节会拉长处理时间，且确认多了人会开始盲点。所以确认页必须展示自然语言摘要而不是原始参数，否则人只会一路点「确定」。

• 工具层设不变量断言。护栏不能只写在提示词里，要写在工具的语义层：退款金额不得超过订单实付、状态机不得跳转到非法状态、同一工单十分钟内不得重复发通知。这类负向断言比「参考轨迹匹配」可靠得多——因为正确的路径有很多条，但不该发生的事是有限且明确的。

④ 评测：三层收尾。

• 用例层：真实工单回放，按类目分层，看最终结果对不对。
• 指标层：自动处理率、一次解决率、转人工率、平均处理时长，以及该转没转的比例（人工抽样标注）。
• 不变量层：跑一批对抗用例，断言「永远不会发生」的事——超额退款、越权改单、重复通知。这一层是发布闸门，任何一条命中就阻断。

评测层级要从端到端往下沉：端到端掉分了才看轨迹级（它多调了几轮、走错了哪一步），轨迹级定位不了才拆到组件级（分类器、检索、单个工具）。上来就做组件级评测是浪费。

⑤ 演进：出现「长尾里某一类反复出现且路径逐渐固定」→ 把它从 Agent 沉淀成 workflow（这是最重要的一条：Agent 的产出之一是发现新的确定性流程）；出现「转人工率长期偏高且集中在某几类」→ 扩知识库或扩流程，不是换模型；出现「人工确认环节成为瓶颈」→ 才考虑放宽某类操作的自治等级，且必须先有足够长的抽样数据。退路：如果不变量层出现任何一次真实违约，立刻把对应操作降回人工签字。