凌晨两点半，值班群炸了。一条骨干网光缆告警引发雪崩式工单涌入，短短四十分钟生成了两千多张工单。传统的规则引擎在那一刻彻底失守——关键字正则匹配错误率高，人工分拣根本跑不过来，同一故障被拆成十几张单子分给不同班组，重复处理、漏单、迟单一个不落。我就是在那个凌晨被拉进项目的。后来复盘时大家达成一个共识：运营商的海量工单场景，靠堆人力和硬编码规则已经走到头了，必须引入智能Agent，让它去做分类路由和闭环处置。
这篇内容就是我过去大半年在电信运营商工单智能化改造中踩出来的经验总结，核心围绕三件事：智能Agent怎么承担海量工单的分类路由、怎么把工单从派发到处置的链路真正闭环、以及在一堆模型和框架里到底该怎么选型。如果你是做运维平台、工单系统或者垂直行业Agent落地的工程师，这篇文章里的技术路径和选型逻辑可以直接拿去做方案参考，至少能帮你省掉几轮试错。
1. 先想清楚：电信工单场景到底难在哪
很多团队一上来就急着选模型、调Prompt，结果模型跑起来才发现根本的问题是工单场景本身的复杂度。我在动手之前把整个链路梳理了一遍，建议你也先做这一步——把困难拆开了，后面所有技术选型就都有了依据。
1.1 海量工单的系统性痛点拆解
电信运营商的工单系统和互联网公司的工单完全不是一个物种。互联网工单大多是用户提交的、文本规范、需求明确；电信工单则是多系统自动触发加人工录入的混合体，来源包括网管告警、投诉系统、客户电话、一线巡检App，甚至还有上个系统自动生成的重复单。
我统计过我们项目覆盖的工单数据，高峰期日均单量接近四万张，低峰期也有一万五以上。这些工单有几个非常棘手的特征。
第一个特征是字段极度不规范。同一类故障，有的工单写“光路中断”，有的写“光缆故障”，有的直接写几个告警编号加一串乱码，还有的带错别字。传统规则引擎靠关键词匹配根本兜不住这种表达漂移。
第二个特征是工单之间存在大量关联。一条主光缆断了，会同时触发传输告警、数据网告警、客户专线告警，十张工单描述的都是同一物理故障。没有关联识别能力的话，十张单子会分给十个不同班组，每个班组都派人去现场，资源彻底浪费。
第三个特征是处置路径有强状态约束。一张装维工单要经历受理、分派、上门、施工、回执、归档六个状态；一张故障工单则要看是否升级、是否有人力介入、是否需要备件调度。这些状态之间不是随意跳转的，Agent如果不懂状态机逻辑，就会出现重复派单或者跳状态的问题。
第四个特征，也是经常被忽略的，就是审计要求极高。运营商受合规监管，每一张工单的每一次状态变更、每一次Agent介入、每一个处置动作都要有完整留痕。这意味着Agent不能只做“聪明的判断”，它输出的每一个动作都必须可解释、可追溯、可回放。
这四个特征交织在一起，决定了它不是一个简单“调大模型做意图识别”的项目，而是一个需要把模型能力、规则引擎、工作流编排和审计体系整合在一起的系统工程。
1.2 为什么传统规则引擎和人工分拣已经走到瓶颈
我们原有系统不是没有做自动化，但它是清一色的硬编码规则分拣。老工程师写了三百多条规则，覆盖大概七成的常见工单类型，剩下的全靠人工兜底。
这套模式在最开始是有效的，但随着网络规模膨胀和业务复杂度上升，它的问题越来越突出。
规则的可维护性最先崩盘。三百条规则每一条都是别人花大量时间写出来的，逻辑里嵌套着各种历史包袱——不少规则是针对某一次特定故障打的补丁。新网络设备上线、新业务类型推出后，规则更新的速度根本跟不上工单类型增长的速度，到后期一条规则的变更要开会评审好几周，改完了还经常误伤其他类型。
规则的召回率也令人头疼。我举一个真实例子：有一种“家宽用户无法上网”的工单，在线路正常、设备正常的前提下，实际上是因为用户的路由器DHCP租约时间设置不合理。这种工单在传统规则体系里怎么归类？关键词既不是“断网”也不是“光路故障”，规则引擎最后把它随机分给了宽带维护班组，维护人员上门发现问题又不在自己职责范围，来回转了两天才真正派到对应岗位。
人工分拣同样有心无力。人均每天处理两百张工单已经是极限，高峰期的两千张工单需要十个人同时不分昼夜地盯。可人的注意力是有衰退曲线的，凌晨三点的分拣准确率比白天低不少，而且培养一个熟悉全业务工单体系的分拣员至少需要六个月。
这些瓶颈不是某个环节修修补补能解决的。规则的方式只能覆盖“已经见过的类型”，而电信网络世界里的工单形态几乎每天都有新变化。我们需要一个能够理解语义、具备推理能力、同时还能严格执行状态流转约束的体系——这就是智能Agent的价值空间。
1.3 智能Agent的价值边界与幻觉风险
Agent不是万能的，这一点必须先说清楚。在选型之前我们做了大量POC，也看了很多外部案例，最深的感受是：Agent在工单场景里的价值是“把需要人做判断的低延�度工作自动化”，而不是“完全取代人的决策”。
合理的边界有两个维度。一个维度是职责边界：Agent负责工单的识别、分类、路由、信息提取、初步诊断、常规处置建议和自动化执行，所有需要现场物理操作、涉及费用审批、触及客户敏感沟通的动作必须有人工介入。另一个维度是权限边界：Agent可以调用API去查询设备状态、拉取历史工单、生成处置报告，但不能直接修改计费数据、不能直接下发高危网管指令。
幻觉风险在工单场景里是致命的。模型如果一本正经地把某个不相关的历史故障当作当前原因写进工单，一线维护人员就极有可能拿着错误信息去处理，耽误故障恢复时间。所以我们的Agent体系里，所有模型输出的关键结论都强制要求附带“证据引用”——必须引用是哪条告警、哪个字段、哪段知识库内容支撑了这个判断。没有证据支撑的判断，宁可标记为“存疑”交人工复核，也不直接进入处置链路。
另外还要理解Agent和传统自动化并不是替代关系，它们是嵌套关系。底层把规则引擎和状态机保留为“确定性执行层”，Agent作为“智能决策层”在上层做语义理解和路由判断，当Agent的判断进入有明确规则的领域后再交给规则引擎去落地执行。这样设计的好处是，即使模型完全不可用，系统还能降级到规则模式，不至于生产瘫痪。
2. 分类路由：从“被动分拣”到“主动理解”
分类路由是整个智能工单体系的第一个核心环节，也是我最想展开讲的部分。很多介绍文章把分类路由简单说成“用大模型给工单打标签”，但真正落地时会发现它还牵扯到标签体系设计、置信度校验、路由策略引擎和兜底机制，每一步都有坑。
2.1 工单标准化与标签体系设计
在给模型喂数据之前，先要做的是工单标准化。源工单的格式五花八门，有的带表格、有的带附件、有的字段全为空、有的重复内容占了一半篇幅。我们写了一个预处理管线，按五个步骤处理原始工单。
第一步是字段提取，从各系统的接口数据中把工单号、来源系统、告警时间、设备编号、地理位置、客户等级、原始描述这些字段结构化提取出来。第二步是文本清洗，去掉重复的告警拼接内容、去掉系统自动追加的无意义后缀、修复明显的编码错误。第三步是附件解析，很多工单带截图和企业微信的聊天记录，我们借助OCR能力把它们也转成文本，作为上下文供模型参考。第四步是历史工单关联，根据设备编号和地理位置关联同设备、同位置最近三十天的历史工单，构成“该设备的故障画像”。第五步是标准化输出，把所有工单统一成标准JSON格式，后续所有环节只认这个格式。
标准化做完后再设计标签体系。这块有个容易犯的错误：一上来就搞精细的大而全分类，给工单打几百个细分类别。实际运营下来你会发现，过于精细的标签带来的问题比它解决的还多——细分类会分散样本量，模型学不准；同时路由班组数量是有限的，几十个班组根本不需要几百个分类标签。我们最后把标签体系设计成四层结构。
第一层是业务域，比如“家宽业务”“政企专线”“移动核心网”“传输承载网”“数据中心”这几个大域。第二层是故障类型，比如“物理链路故障”“设备硬件故障”“配置异常”“资源不足”“外部干扰”。第三层是故障状态，比如“已恢复”“持续中”“间歇性”“疑似光衰”。第四层是处置动作建议，比如“派单至XX班组”“自动重启设备端口”“下发配置模板”“转人工核实”。
这个四层结构在模型训练和推理时都很友好。业务域是粗粒度一级分类，准确率最容易做高；故障类型和状态是细粒度二级分类，需要较多样本；处置动作建议则是直接对接路由逻辑的关键字段。后面我会讲到，路由并不是直接用最细的标签去匹配班组，而是用“业务域+故障类型+状态”的组合来决策。
2.2 意图识别与分类方案的演进路径
标签体系定下来后，最核心的问题是：谁来把非结构化工单文本映射到这套标签上？
我们并不是一开始就直接上大模型，而是走了一条逐步演进的路径，这条路我认为最适合大部分存量系统。第一步做基于TF-IDF加逻辑回归的基线分类器，第二步换成BERT类预训练模型做微调，第三步才引入大模型做少样本与零样本分类，最后再用Agent做全链路编排。
第一步的基线分类器虽然准确率一般，但价值在于它够快、够稳、可解释，而且能在极短时间内跑通整个数据管线。第二步的BERT模型效果明显提升，对常见工单的分类准确率能达到92%左右，但换来的代价是每个业务域都要维护一套微调模型，训练样本需要持续运营。第三步的大模型方案解放了样本依赖，一个新出现的工单类型，只要在Prompt里给出几个示例就能正确归类，这对运营商这种每天都在出现新工单形态的场景非常关键。
我们最终的实现在大模型之上还叠加了一个“置信度双层校验”机制。第一层由模型在输出分类时同步给出每个标签的概率分，第二层由校验模块判断概率分是否高于阈值——高于0.85直接采用，0.6到0.85之间进入人工复核队列，低于0.6直接走兜底路由。这个机制把误分类率控制在很低的水平。
这里要说一个从实操里总结出来的经验：不要迷信“全用大模型分类”。大模型分类在语义理解上确实强，但它有两个短板，一是延迟不稳定，高峰期调用经常要2到3秒；二是如果你把所有细粒度标签都让它一次性输出，准确率会明显下降。我们的做法是“大模型做粗粒度意图理解，规则做细粒度约束校验，模型与规则共同投票”。比如大模型判断这是“光缆故障”，规则引擎再去校验设备类型和告警码是否匹配，一致才通过，不一致就标记为复核，这比任何单独方案都稳。
2.3 路由策略引擎与兜底逻辑
分类做出来之后，怎么把工单送到正确的班组，这中间还需要一层路由策略引擎。直接拿分类结果去匹配班组是远远不够的，因为真实的路由逻辑里面有大量业务约束。
路由策略引擎的核心是一个可配置的决策树加权重评分模型。它接收分类标签、工单要素、资源负载状态三个输入，输出的是一个班组优先级列表。举个例子，一张“政企专线中断”工单，标签是“政企业务域/物理链路故障/持续中”，策略引擎会按顺序检查设备归属区域、客户等级（VIP客户权重加高）、对应班组当前的在途工单量，然后生成一个有序推荐列表。如果最优班组在途单量超过阈值，引擎会把路由目标自动切换到次优班组。
路由引擎还要承接一个容易被忽视的任务：工单合并与拆单判断。一张拓扑关联的故障会产生多张工单，路由引擎会根据设备画像和历史记录判断这些工单是否属于同一故障源。判断为同一源的多张工单会被合并成一个故障事件，把多张子单挂在事件下面，避免重复派单。拆单则相反，一张工单里如果同时包含“用户侧问题”和“局端设备问题”两类独立工作项，引擎会提醒人工拆分为两张单。这一合并一拆分的逻辑，在实际运营里节省的工作量非常可观。
兜底逻辑是整个路由体系里最容易出错的地方，同样值得说一下。无论模型多强，总有新场景是它没见过的。我们设计的兜底分三条：第一条是“无法分类”兜底，凡是置信度不足的工单，统一进入“人工复核队列”，不尝试强行分类；第二条是“路由缺失”兜底，如果策略引擎找不到任何匹配班组，自动上升到调度主管工作台，由人决定往哪派；第三条是“分级升级”兜底，一张工单如果在指定时间内没有进入处置状态，系统会逐级向上通报。
这三条兜底层叠在一起，基本能保证无论上游模型怎么输出，工单都不会悬空，永远有一条确定的路径在管着它。Agent的智能是建立在这样一个严格兜底框架之上的——脱缰的智能对生产系统来说是不可接受的。
3. 闭环处置：从“开单派单”到“真正解决”
分类路由做好之后，很多团队就以为大功告成了。但要真正解决工单问题，必须把链路延伸到“闭环处置”这一环——即不仅要让工单去对的地方，还要确保事情被做对、做完、做可查。这是整个项目里工作量最大、牵扯系统最复杂的一部分。
3.1 处置状态机与Agent编排模型
闭环处置的地基不是AI模型，而是一张严谨的状态机。我见过一些Agent项目完全不定义状态，把整个处置流程交给模型自由发挥，这在工单领域几乎是必死——你没有任何办法追踪一张工单当前到底在哪个环节、下一步该干什么。
我们的状态机基于对原有人工处置流程的深度梳理，一共定义了九个主状态。初始态是“已受理”，接下来经过“诊断中”“处置中”“等待用户确认”“等待外部协同”“已恢复待验证”“验证通过”“归档”八个路径分支。特殊情况下有“升级态”和“退回重诊态”两个旁路分支。
Agent在这个状态机里做的事情是状态驱动的决策编排。每一个状态都绑定了一组Agent模型输出任务和一组工具调用能力。比如“诊断中”状态下，Agent要调用告警查询工具、设备状态拉取工具、历史工单检索工具，综合这些信息输出诊断结论；而“处置中”状态下，Agent会依据诊断结论选择执行自动化排查脚本或者生成人工操作指引。
这里有一个非常重要的编排原则：Agent不能自己决定状态流转，状态流转必须由状态机管理模块负责。Agent可以发起状态流转请求，但最终是否允许流转、按哪条路径流转、需要满足什么前置条件，都必须由确定性代码来判定。这样做有两个好处：一是避免模型“跳步骤”，二是所有流转记录天然成为审计日志的一部分。
我在实际编码时发现，状态机如果用传统的状态模式硬编码，到了十几个状态时会变得异常臃肿。我们最终采用了JSON配置化状态图加代码解释器的方式。所有状态和迁移条件都定义在一个配置文件中，解释器加载配置后动态执行，新增状态只需改配置，不用动代码。这个设计到后期给维护团队省了太多事。
3.2 工具调用与自动化执行闭环
Agent只动嘴是不行的，必须能动手。这里的“动手”在工单场景里体现为一系列受控的工具调用。我们给Agent封装了六个标准工具类。
第一个是诊断查询类，包括告警平台查询、设备状态查询、性能指标拉取、配置比对、历史工单检索。第二个是自动化操作类，包括端口重启、设备软复位、配置模板下发、路由策略刷新。第三个是工单操作类，包括更新工单状态、追加备注、修改优先级、触发升级。第四个是协同通知类，包括通知对应班组、通知客户经理、生成升级通报。第五个是报告生成类，包括自动生成故障分析报告、生成处置记录摘要。第六个是知识检索类，调用知识库问答接口，查询已知故障的处置手册。
工具调用最大的难点不是API对接，而是调用安全与调用策略。我们为每一类工具定义了触发条件，自动化的操作类工具必须满足“故障类型明确、影响范围可控、历史工单中有同类成功操作记录、人工确认开关打开”这四个条件才会放行。不满足条件时，Agent会转而生成“建议操作指令”，由人工执行。
工具调用策略还要考虑失败处理。模型经常会提出一个工具调用，但参数填错、或者上游系统接口超时。我们把工具调用包在一个统一的执行器里，执行器负责参数校验、超时控制、重试、失败信息格式化，并把执行结果回传给Agent。Agent根据回传结果决定是修正参数重试还是更换方案。这一步如果不做标准化，Agent每次调用工具失败的表现会各式各样，排错成本极高。
在编排Agent与工具的交互方式时，我强烈建议采用“ReAct模式加工具白名单”的组合。模型在每轮推理中输出Thought（思考）、Action（要调用的工具）、Action Input（调用参数），系统校验Action在工具白名单内才执行。这个模式最大的价值是它的交互轨迹可以完整记录——“模型为什么调用这个工具、传了什么参数、得到了什么结果、下一步怎么调整”全部有迹可循，对后面做审计和调优都是必需材料。
3.3 人机协同与质量回看机制
闭环并不等于全自动，人机协同才是生产级工单系统的现实形态。我们的系统把工单处理模式分成了四级：全自动、自动加监督、人机协同、纯人工。对这四级模式有一个很清晰的定义。
全自动模式适用于低风险高频操作，比如“家宽账务类通知工单”的系统自动回执；自动加监督模式适用于常规故障修复，Agent自动执行操作但每一步都有监控日志并在完成后向值班人员推送简报；人机协同模式适用于需要现场作业或跨部门协作的工单，Agent负责提供全套分析和建议，人做最终决策；纯人工模式则是政企VIP客户的重大故障，Agent只做辅助信息整理和报告生成。
在这个分级协同体系里，我们踩过最大的坑是Agent生成的建议没有人跟进。最初上线时人机协同模式下的建议命中率其实不错，但值班人员并没有养成每单必看建议的习惯，很多Agent生成的处置方案被晾在工单备注里，效果等于零。
后来我们加了一个“建议追踪模块”，所有Agent建议不再只是写进备注，而是生成一个独立的“建议工单”挂在主工单下，系统会跟踪建议是否被采纳、被采纳后的执行结果是成功还是失败。这些数据又反过来作为Agent模型微调的监督信号。这个改动让Agent建议的采纳率提升了将近三十个百分点。现在回头看，人机协同的本质不是“AI做判断、人执行”，而是“AI提建议、人决策、系统追踪结果”，追踪环节是把闭环真正封口的那一步。
质量回看也是闭环不可或缺的部分。我们每周会做一次抽样复盘，从已完成工单中抽取一定比例，人工回看Agent的每一步动作是否合理、建议是否有效、工具调用是否准确。回看结果分成“优秀、及格、需优化”三档，并形成一份质量报告。这份报告除了帮助调优模型和Prompt之外，还是向业务方证明Agent价值的直接材料——没有这套质量回看机制，业务方很难对Agent产生真正信任。
4. 选型逻辑：模型、框架、集成方案怎么排优先级
这一部分可能是很多人最关心的。坦白讲，我们在选型上走过的弯路不少，前后推翻了两次方案才走到当前这套体系。选型的核心不是选最先进的，而是选最匹配你现有架构和团队能力的。
4.1 模型选型：精度与成本的平衡
工单分类和诊断这个任务，对模型的核心要求有三个：语义理解能力、指令跟随稳定性、可解释性。我们对市面上主流的大模型做了四个维度实测：分类准确率、诊断结论与专家判断的一致率、单次推理端到端延迟、单token成本。
实测下来有个很明显的结论：参数量最大的模型未必是最优选择。我们工单场景的大多数分类任务其实并没有特别复杂的推理需求，一个经过良好Prompt设计的中小尺寸模型，配合工具调用能力，完全能达到要求，而它的延迟和成本优势非常突出。另一个确定性的结论是：在工单这种专业领域，通用模型如果不经过领域知识的注入，其诊断建议水平是远不够用的。
我们的最终方案是大小模型组合。入门级分类和路由建议用中小尺寸模型，追求低延迟和高吞吐；复杂诊断和跨系统综合分析用大尺寸模型，追求推理能力和准确性。组合部署之后，单张工单的平均处理成本比全大模型方案下降了大概七成，平均处理延迟从三秒多降到了一秒以内。
在模型部署方式上，我们选的是私有化部署加公有云API兜底的双通道模式。工单数据属于非常敏感的生产运营数据，大量数据走公有云API有合规风险，所以核心链路用私有化部署的模型处理；公有云API只作为突发高峰期的扩展兜底，并且只传脱敏后的工单要素。这个架构既保障了安全合规，又解决了私有化集群扩容周期长的问题。
4.2 Agent框架与编排工具的取舍
提到Agent开发，现在生态里已经有大量现成的Agent编排平台和开源框架。我们的选择逻辑可以给后来者一个参考：如果团队具备较强的工程化能力，用户场景高度垂直定制，那自研轻量化Agent编排框架是更具有长期主动权的一条路；如果目标是快速验证、业务形态还在剧烈变化中，那么成熟的低代码Agent平台反而能省下大量时间。
我们走的是“半自研半复用”的第三条路。底层的工具调用、状态管理、审计日志这些核心模块完全自研，这也是整个系统的地基，必须牢牢掌握在自己手里。上层Agent编排逻辑则复用了一些成熟组件，包括Prompt模板管理、模型路由、会话记忆管理这些能力。
这里提一下，目前市面上也有不少低门槛的Agent平台，比如类似“扣子”（Coze）这样以拖拽编排为特色的智能体开发工具，在快速搭建Agent原型时确实非常高效。坦白讲我们在早期POC阶段也借用了这类平台来验证“Agent做分类路由”的可行性——把意图识别、工具节点、输出模板拖到一起，几分钟就能跑通一个可交互的Demo。这类平台的优点在于降低了试错成本，意图识别节点改起来非常直观，快速验证期值得用。但进入生产环境后你就会遇到现实的问题：私有化部署要谈、数据合规要过、工具API要自定义开发、排队调度要自己控制。这些约束逼着我们最终把核心链路收回自研体系，而那个快速验证期产出的结论和积累的流程认知，还是为正式设计提供了很大帮助。
我的建议是：不要神化任何框架，也不要鄙视任何平台。从“快速验证”的角度，低代码Agent平台是很好的推进器；从“长期稳定运营”的角度，自研核心编排能力是不可跳过的。两条腿走路的方案在当前的场景下最稳妥。
4.3 与运营商BSS/OSS系统的集成难点
模型和Agent选得再好，集成到运营商的存量系统中时还是会遇到一连串硬骨头。我先说一个多数人没预料的点：运营商的工单系统接口版本极其混乱。不同省份、不同系统模块的接口规范不统一，同一个“查询工单”的接口在不同系统里有不同字段名和数据格式。如果Agent直接调用这些接口，每一次调用都得做一层适配，代码量非常庞大。
我们的解法是在Agent和外部系统之间加一个统一的系统适配层。这个适配层由标准化的数据模型和接口网关构成。Agent只面向适配层暴露的标准接口通信，适配层负责把请求转换为各个存量系统能理解的格式，再把结果统一为标准化响应回传。这样做带来的额外收益是，接口变更不会直接冲击Agent层，维护成本被隔离在适配层内部。
第二个集成难点是触发与回调机制。Agent不能主动去轮询工单系统，那样效率太低也不实时。我们搭建了基于消息队列的异步事件总线，工单系统有新单产生、状态变更都通过事件总线推送给Agent引擎，Agent完成处置后再把结果异步写回。异步架构避免了阻塞和重试风暴，也天然支持突发高峰期的削峰填谷。
第三个难点是身份权限与操作审计。Agent要在生产系统里执行操作，必须像人一样拥有一个“数字身份”，这个身份需要受权限管理系统的控制。我们为Agent创建了专用的服务账号，并限制其权限范围仅覆盖允许执行的操作白名单。每一步工具调用都会以该服务账号的名义记录在审计日志里，确保事后能追溯“哪条指令触发了哪个Agent的哪个操作”。
这些集成工作看起来不性感，但它们是整个智能工单体系能真正跑在生产环境的必要条件。模型决定这个系统的“上限”，集成决定“下限”——集成做不好，上限多高都白搭。
5. 实测中的坑与排查手记
最后分享一些我们上线至今遇到的实际故障和排查经验。这些内容几乎不会出现在任何官方文档里，是我最值得写出来的一堆代码细节。
5.1 结构化输出导致的幻觉污染
模型在输出工单诊断结论时，我们要求它必须附带证据引用。上线初期，一个很隐蔽的问题出现了：诊断模块偶尔会“凭空引用”一个根本不存在的告警编号，或者在引用历史工单时把两单的时间搞反。这类幻觉不仔细看根本发现不了，但会直接污染工单记录。
排查了很久才发现根因有两处。一是Prompt上下文过长时，模型在长上下文里对关键实体的注意力会衰减，为了完成“必须引用证据”的指令，它就自己编了合理但虚假的引用。二是在工具调用的结果列表中，历史工单检索结果有时会重复出现，模型引用了重复项中的一个，看起来像正常引用，但实际内容是错的。
解决方案有三步。第一步，给所有引用字段加上“引用类型”标记，必须注明是“告警系统返回”“历史工单返回”还是“知识库检索返回”，模型禁止生成引用类型标记以外的类型。第二步，在下游加一个引用校验器，它会把模型引用的告警编号和历史工单ID回查真实系统，查不到的直接拦截并触发“想法重新生成”，最多重试两次，仍失败的转人工。第三步，压缩无必要的历史上下文窗口，只保留模型完成推理所需的最小历史范围，减少长上下文的注意力漂移。
5.2 幂等性与重试风暴
有一次我们上线了一个自动恢复端口的小工具，事故很快就来了。某个区域网络抖动触发了几百张告警工单，Agent对其中不少工单发出了“重启端口”的操作请求。由于上游接口超时，Agent执行框架按默认策略做了三次重试，结果部分端口被重启了两次甚至三次，反而加剧了业务波动。
这是典型的重试导致的事故。排查之后我们对所有Agent工具调用加上了幂等校验。具体做法是：每个工具调用请求都携带一个全局唯一的任务ID，适配层在接受到请求后先查该任务ID是否已被执行过，执行过的直接返回上次结果，不重复执行。同时重试策略也不再是无脑三次全量重传，而是区分了“确定性失败”和“网络类失败”——参数错误这类确定性失败立即停止重试，只有超时和连接异常才允许最多重试一次。
这个问题的教训是：Agent的能力越强，底层工具的防御措施就越要严谨。模型不会像人一样对“我今天已经重启过这个端口”有记忆，它每轮推理都是全新的。工具层的幂等保障是Agent安全运行的底线。
5.3 调度模型欠载与资源风暴
上线初期我们明明按流量估算把模型推理集群扩容到了预期值的两倍，结果高峰期仍然出现了排队堆积。一查发现原因比较有趣：模型的推理集群是按“并发session数”计的，而我们的工单链路里一个分类任务要调用一次模型接口，一个诊断任务要调用四次调用，每个工单产生的session开销远超预估。
调整方案是给模型调用加了两层调度优化。第一层是“结果缓存”：同一设备的同类型工单在短时间内的诊断结果直接复用缓存，过期时间设为十五分钟，有效拦截了大量重复诊断请求。第二层是“批处理合并”：把同一时间窗口内多个工单的分类请求合并成一个Batch送入模型，模型批量输出后在系统内部拆回各工单。这两层优化让高峰期的模型调用量下降了近七成，资源压力明显缓解。
这里是很多Agent项目容易忽略的点：单次调用的算力优化做得再好，如果调用量的总体结构不合理，集群照样被打爆。先压缩调用次数，再优化单次效率，这个顺序不要反。
5.4 审计日志的完备性陷阱
还有一个相对隐形的坑。系统改造初期，我们的日志只记录了Agent的最终输出结果，对中间的推理过程和工具调用轨迹记录得很粗糙。业务安全部门在内部审计时提出了严重的质疑——他们要求的是“完整复现Agent决策链”，任何一个中间步骤缺失都可能无法通过审计。
后来我们改造了日志模块，从完整的对话链路中抽取出五个必需记录点：模型的完整输入Prompt、模型每一步推理轨迹（包括ReAct模式的Thought/Action/Action Input）、工具调用的请求与响应全量、状态机每次流转的前后状态与触发条件、以及最终写入工单系统的结果。这五个记录点串联起来，就能完整还原一张工单从进入到归档的全过程。
日志量确实变大了，但这是我们必须付出的成本。对于任何有合规要求的行业来说，Agent系统的“可追责性”不是一个可选项，它是一个硬约束。在这里我的建议是，日志模块的详细程度在设计初期就按最终审计标准来做，中途改造的代价远高于一开始做足。
最后再分享一个小技巧
写到这里，我想起一个最初踩过、但事后看又特别有意思的教训分享给你。第一次给业务方演示Agent自动分类路由时，我精心准备了一个“完美工单”作为案例——字段齐全、描述规范、故障典型，模型自然是秒级给出正确答案，现场一片掌声。但业务方随口问了一句：“你能不能拿一张真实工单试试？”结果真实工单一进去，模型表现起起伏伏，还有一次分类和专家判断不一致，场面一度尴尬。
从那以后我养成了一个习惯：每次方案演示前，先拿最近三天的真实数据跑一遍离线评测，统计出各维度数据再上台。这不是技术能力的差异，而是你是否掌握真实场景环境的问题。工单场景的Agent不是实验室里的玩具，它的价值要放在一个月、几万张工单面前才算数。
如果这篇文章能帮你少走一点弯路，那就是我花这些时间把它写出来的价值所在了。
