企业官网建设流程全解析

1. 电信工单系统的现状与智能Agent的切入点

电信运营商的工单系统，可能是国内To B领域里最复杂、最庞大、也最容易被低估的一类系统。我过去几年参与过几个省级运营商的工单中台改造项目，一个省公司每天产生的工单量级在几十万到上百万之间，涵盖宽带装移机、故障报修、投诉处理、资源调度、基站巡检、政企专线开通等几十种业务类型。这些工单从客服系统、网管系统、营业厅、App、公众号、外部接口等十几个渠道涌入，格式五花八门，优先级参差不齐，而且往往带着大量非结构化文本——用户口语化的描述、客服的简写、系统自动生成的告警摘要混在一起。

传统做法是靠规则引擎加分派策略表来路由，再靠人工坐席逐单研判、派发、跟踪、回访。这套体系在工单量可控的年代还能撑住，但现在的问题很直接：规则越堆越多，维护成本指数级上升；新业务上线要改几十条规则，改完还容易互相冲突；一线人员流动大，经验沉淀不下来；跨专业工单（比如一个投诉同时涉及无线、传输、核心网）的定界定位全靠老师傅拍脑袋。说白了，规则引擎处理的是"确定性"，而工单世界里大量的"不确定性"它接不住。

这就是智能Agent切入的地方。我这里说的Agent不是简单的"调个大模型API做文本分类"，而是指具备感知、决策、执行、反馈闭环能力的智能体系统。它要能读懂工单内容、判断业务类型和紧急程度、决定路由目标、必要时调用工具查资源查历史、在处置过程中持续跟踪状态、遇到异常能升级或转人工、最后把处置结果回写并形成经验。这套东西落到电信工单场景，核心价值就三件事：把分类路由的准确率从规则时代的七八成拉到九成以上，把跨专业工单的定界时间从小时级压到分钟级，把闭环处置里那些重复性的查询、通知、回单动作自动化掉。

适合读这篇的人，我判断是三类：一是运营商内部做IT支撑、工单中台、客服系统的技术负责人，正在评估要不要上Agent、怎么上；二是做企业级AI落地的架构师和开发，想找一个真实的高并发、强合规场景做参考；三是关注多智能体协同和私有化部署的技术管理者，想搞清楚电信这种体量的系统到底怎么选型。下面我按实际项目里踩过的路，把技术路径和选型逻辑拆开讲。

2. 整体架构设计与核心思路拆解

2.1 为什么不做单体大模型，而选多智能体协同

一开始最容易想到的方案是：搞一个大模型，把工单文本丢进去，让它直接输出分类、优先级、派单目标。我试过，在小批量测试上效果还行，但一上生产就露馅。原因有几个：第一，工单处置是个多阶段流程，分类只是第一步，后面还有定界、派发、跟踪、回单、质检，每个阶段的输入输出和工具调用完全不同，一个模型扛所有阶段，prompt会膨胀到无法维护；第二，不同专业领域的知识差异极大，无线专业的工单和政企专线的工单，判断逻辑几乎不重叠，硬塞进一个模型里会互相干扰；第三，可观测性和可干预性差，出了错你根本不知道是哪一步的判断偏了。

所以最终走的是多智能体协同路线。拆成几个职责单一的Agent：受理理解Agent负责把非结构化文本结构化，抽取业务类型、地址、账号、故障现象、时间要求等要素；分类路由Agent基于结构化结果做业务分类和优先级判定，输出路由建议；定界定位Agent针对故障类工单，调用资源系统、告警系统、历史工单库做交叉分析，判断故障段落；处置执行Agent负责调用具体工具完成派单、通知、预约、回单等动作；跟踪闭环Agent负责监控工单状态流转，超时预警、异常升级、结果回写。这几个Agent之间通过一个编排层协调，共享一个工单上下文对象。

这么拆的好处很实在：每个Agent的prompt和工具集都能收敛到可控范围，单独迭代不影响其他环节；每个环节的输入输出都能落库，出问题能精确定位；不同专业可以挂不同的知识库和规则，互不污染。代价是编排复杂度上去了，Agent之间的状态同步和异常传递要设计好，这个后面细讲。

2.2 私有化部署与信创适配的硬约束

电信运营商的系统，私有化部署不是可选项，是硬性前提。工单数据里包含用户姓名、地址、账号、通话记录等敏感信息，绝对不可能走公有云API。这就意味着模型必须本地部署，而且要考虑信创适配——服务器可能是鲲鹏、飞腾这类国产CPU，操作系统可能是麒麟、统信，数据库可能是达梦、OceanBase。这些约束直接决定了技术选型。

模型层面，我实测下来，7B到14B参数量的开源模型经过领域微调后，在工单分类和要素抽取任务上能达到可用水平，再大就面临推理成本和显存的双重压力。推理框架要选支持国产硬件加速的，比如针对昇腾的CANN、针对飞腾的适配版本。这里有个坑：很多开源推理框架在x86上跑得好好的，迁到ARM架构上性能直接腰斩，甚至编译不过。选型阶段一定要拿真实硬件做压测，别信纸面参数。

信创适配还有个容易被忽略的点是加密和审计。工单数据在Agent之间流转、调用工具、写回数据库，每个环节都要有审计日志，而且要符合等保要求。我们当时的做法是在编排层统一做数据脱敏和访问控制，Agent本身不直接接触原始敏感字段，只拿脱敏后的上下文。

2.3 高并发下的架构取舍

省级工单系统的峰值并发是个绕不开的问题。早高峰和突发事件（比如大面积断网）时，工单涌入速度可能是平时的五到十倍。Agent系统如果每个工单都同步跑一遍完整的多Agent流程，延迟会堆到不可接受。

我们的处理思路是分层削峰。第一层是接入层做批量聚合，把短时间内同区域、同类型的工单合并处理，减少重复的定界计算；第二层是Agent执行层做异步化，分类路由这种快任务走同步返回，定界定位这种慢任务走消息队列异步处理，结果通过回调更新工单状态；第三层是模型推理层做批处理和缓存，相同或相似的工单文本命中缓存直接返回，没命中的攒批送推理。实测下来，这套组合能把峰值时的平均处理延迟控制在秒级，P99在十几秒，对工单场景来说完全够用。

这里要强调一个选型逻辑：不要追求每个工单都走完整Agent链路。很多工单其实规则就能处理，Agent只处理规则搞不定的那部分。我们统计过，规则能覆盖大约六成的简单工单，剩下四成才是Agent的主战场。把Agent用在刀刃上，既省算力又降延迟。

3. 核心细节解析与实操要点

3.1 受理理解Agent的要素抽取设计

受理理解是整个链路的地基，抽错了后面全错。工单文本的脏乱程度超出想象，我举几个真实例子："家里网断了打不开网页"、"宽带昨天还好今天不行了"、"师傅上门说端口坏了要换"、"投诉10000号没人处理"。这些文本里，业务类型、故障现象、紧急程度都是隐含的，需要模型结合上下文推断。

要素抽取我定义了固定的schema：业务大类（装移机/故障/投诉/咨询/巡检）、业务子类、用户标识（宽带账号/手机号/专线编号）、地理位置（省市区+详细地址）、故障现象描述、期望时间、情绪等级。抽取用的是一个经过领域SFT的模型，训练数据来自历史工单的人工标注。这里的关键经验是：不要指望模型一次抽全，要设计成可增量补全的结构。比如第一轮抽出了业务类型和地址，但账号没抽到，就触发一个追问Agent去关联查询用户系统，而不是直接判失败。

实操中还有个细节：地址标准化。用户写的地址千奇百怪，"XX小区3栋"和"XX花园三期3号楼"可能是同一个地方。我们接了一个地址库做归一化，Agent抽出的原始地址先过地址库匹配，匹配不上的走模糊匹配加人工确认。这一步不做，后面的资源调度和派单会大量出错。

3.2 分类路由Agent的决策逻辑

分类路由看着简单，其实是最考验设计的地方。规则时代我们用的是决策树加优先级表，Agent时代不能简单换成模型分类就完事，因为路由决策要考虑的因素远不止业务类型：还要看工单来源渠道、用户等级（政企客户优先级高）、历史投诉记录、当前各班组负载、SLA时限要求。

我的做法是把路由决策拆成两步：先由模型输出一个"业务标签+置信度"，再由一个策略引擎结合实时负载和SLA做最终派发。模型负责它擅长的语义理解，策略引擎负责它擅长的规则计算，各司其职。置信度低于阈值的工单，直接转人工复核，不硬派。

这里有个参数要重点调：置信度阈值。设太高，转人工的比例上升，Agent价值体现不出来；设太低，错派率上升，一线投诉。我们当时用历史工单做回测，画了一条准确率-覆盖率曲线，最终把阈值定在准确率92%对应的那个点，转人工率控制在8%左右。这个值不是拍脑袋，是拿数据算出来的。

3.3 定界定位Agent的工具调用

定界定位是Agent最能体现价值的地方，也是最难做的。一个宽带故障工单，可能的原因有：用户侧设备问题、接入网端口问题、汇聚层链路问题、上层认证问题。传统做法是派单到班组，师傅上门一层层排查，耗时耗力。Agent的做法是：先调资源系统查用户挂接的端口和链路，再调告警系统查该端口和链路上游有没有活跃告警，再调历史工单库查同区域近期有没有类似故障，三个信息交叉分析，大概率能定位到具体段落。

工具调用的设计要点是幂等和超时控制。资源系统、告警系统的接口响应时间不稳定，快的几十毫秒，慢的几秒。Agent调用工具必须设超时，超时了走降级逻辑（比如只凭已有信息给一个粗略定界），不能卡死整个流程。另外工具调用要幂等，同一个工单重试时不能产生副作用。

我踩过的一个坑：早期没做工具调用的结果缓存，同一个区域几十个工单同时进来，每个都去查一遍告警系统，把告警接口打挂了。后来加了区域级的结果缓存，同区域同时间窗口的查询结果复用，压力一下就下来了。

3.4 处置执行与闭环跟踪

处置执行Agent负责把决策变成动作：派单、发短信通知用户、预约上门时间、回单、触发回访。这些动作大多是对接现有系统的API，Agent的价值在于根据上下文决定调哪个、按什么顺序调、参数怎么填。

闭环跟踪Agent是个常驻的监控角色，它订阅工单状态变更事件，判断是否超时、是否异常、是否需要升级。比如一个工单派出去两小时没接单，它就触发升级流程，通知班组长；如果师傅回单说"已修复"，它就触发回访流程确认用户是否满意。这个Agent的设计关键是状态机要清晰，工单的每个状态和状态之间的合法迁移都要定义好，Agent只在合法迁移上做动作，避免状态混乱。

4. 实操过程与核心环节实现

4.1 环境搭建与模型部署

先说硬件。我们测试环境用的是一台国产ARM服务器，256G内存，配了四张推理卡。生产环境是集群部署，推理节点和编排节点分开。操作系统是麒麟V10，数据库是达梦，中间件是东方通。这套环境搭起来本身就花了两周，主要是各种依赖的ARM版本编译和适配。

模型选型上，我们对比了几个开源模型在工单分类任务上的表现。评测集是五千条人工标注的历史工单，指标是分类准确率和要素抽取F1。实测下来，经过领域微调的14B模型在准确率上比7B高约6个百分点，但推理延迟是7B的2.5倍。最终生产上用的是7B做在线实时推理，14B做离线批量复核和难例挖掘，兼顾了延迟和精度。

部署用的是容器化方案，推理服务封装成镜像，通过K8s编排。这里要注意国产硬件上的容器运行时适配，有些默认的运行时在ARM上跑不起来，得换成适配版本。模型文件通过共享存储挂载，避免每个Pod都拷一份。

4.2 Agent编排层的实现

编排层是整个系统的大脑，我们用的是基于状态机的编排框架，每个工单对应一个状态机实例，Agent是状态机上的节点。工单进入系统后，状态机从"受理"状态开始，依次经过"理解"、"分类"、"定界"、"派发"、"跟踪"、"闭环"等状态，每个状态由对应的Agent处理，处理完根据结果决定下一个状态。

状态机的定义用配置文件描述，不写死在代码里，这样业务调整时改配置就行。每个状态的超时时间、重试次数、降级策略都在配置里定义。比如"定界"状态超时30秒，重试2次，都失败就降级到"人工定界"状态。

Agent之间的上下文传递用一个共享的工单对象，每个Agent读写自己负责的字段。这里要特别注意并发安全，同一个工单可能被多个事件触发，要有锁机制防止重复处理。我们用的是基于工单ID的分布式锁，保证同一时刻只有一个处理流程在跑。

4.3 关键参数的计算与调优

分类路由的置信度阈值前面提过，这里说下怎么算。拿历史工单跑一遍Agent，得到每个工单的预测标签和置信度，再和人工标注的真实标签对比。把置信度从0到1分成100个桶，每个桶算准确率，找到准确率开始明显下降的那个点，就是阈值。我们实测这个点在0.85左右，对应准确率92%。

定界定位的超时时间怎么定？统计资源系统和告警系统接口的响应时间分布，取P95作为单次调用超时，再乘以最大调用次数，加上模型推理时间，就是整个定界状态的超时。我们算下来是25秒，留了5秒余量设成30秒。

批处理的大小怎么定？这个要看推理卡的显存和模型的显存占用。7B模型FP16大概占14G显存，一张32G的卡能同时跑两个实例，每个实例的批大小设8，那单卡吞吐就是16路并发。根据峰值工单量反推需要多少张卡，再留30%余量。

4.4 信创适配的实操细节

信创适配最麻烦的是依赖库。很多Python的机器学习库在ARM上没有预编译的wheel，得从源码编译，编译过程中又可能缺各种系统库。我们的做法是建一个内部的wheel仓库，把所有依赖提前编译好，部署时直接从内部源装，不走公网。

数据库适配也要注意。达梦的SQL语法和MySQL有差异，比如分页、日期函数、JSON字段处理都不一样。Agent系统里所有涉及数据库操作的地方都要做适配层，不能直接写SQL。我们封装了一个DAO层，上层业务代码不感知底层数据库类型。

加密方面，工单数据落库要加密，传输要加密，Agent之间的通信也要加密。我们用的是国密算法，SM4做数据加密，SM2做密钥交换。这部分要和运营商的安全团队对齐，他们的合规要求很细，提前沟通能省很多返工。

5. 常见问题与排查技巧实录

5.1 分类准确率不达标的排查路径

上线初期最常遇到的就是分类准确率上不去。排查要按顺序来：先看数据，标注质量有没有问题，有没有标错的、标歧义的；再看模型，是不是训练数据分布和线上不一致，比如训练集里投诉类工单多，线上故障类多；再看prompt，要素抽取的schema是不是有歧义，模型理解偏了；最后看后处理，置信度阈值是不是设得不合理，把高置信度的错判也放过去了。

我遇到过一个典型案例：某类工单准确率一直上不去，查了半天发现是训练数据里这类工单的标注标准不统一，两个标注员对同一类工单的判定不一致。重新对齐标注标准后，准确率直接涨了十几个点。所以数据质量永远是第一位的，模型再强也救不了脏数据。

5.2 工具调用失败的降级策略

工具调用失败是常态，资源系统、告警系统、用户系统都可能超时或报错。降级策略要分层设计：单次调用失败先重试，重试还失败就走缓存，缓存没有就用已有信息给一个粗略结果，实在不行才转人工。关键是每一层降级都要有明确的触发条件和输出，不能让流程卡住。

我们做过一个统计，工具调用失败里大约七成是超时，两成是接口报错，一成是数据格式不对。超时可以通过调大超时时间或加缓存缓解，接口报错要和上游系统对齐，数据格式问题要在适配层做容错解析。

5.3 高并发下的性能瓶颈定位

峰值时系统变慢，定位瓶颈要看几个指标：推理服务的队列长度、编排层的状态机实例数、数据库的连接数和慢查询、消息队列的积压量。哪个指标先到瓶颈，哪个就是短板。

我们遇到过一次典型的瓶颈：推理服务队列堆积，但GPU利用率不高。查下来是批处理没生效，每个请求都单独推理，浪费了大量算力。调整批处理参数后，吞吐直接翻了三倍。所以性能问题不一定是硬件不够，很多时候是参数没调好。

5.4 常见问题速查表

5.5 独家避坑经验

第一条，别一上来就追求全自动。我们初期想做到端到端无人干预，结果错派率一高，一线直接抵制。后来改成"Agent建议+人工确认"的混合模式，先让一线建立信任，再逐步放开自动化比例。这个节奏很重要，技术再好，业务不买账也白搭。

第二条，可观测性要提前做。Agent的决策链路比传统系统长得多，出问题时如果没有完整的日志和链路追踪，排查起来就是灾难。我们从第一天就上了全链路追踪，每个Agent的输入输出、工具调用、耗时都落库，后来排查问题省了大量时间。

第三条，模型版本管理要规范。模型迭代频繁，没有版本管理的话，线上出问题都不知道是哪个版本。我们给每个模型版本打了标签，记录训练数据、评测指标、上线时间，回滚时能精确切回上一个稳定版本。

第四条，和业务方对齐SLA。Agent系统的延迟、准确率、可用性都要和业务方明确约定，不能自己拍。比如分类路由的准确率承诺多少、定界的响应时间承诺多少，写进SLA里，后面验收和优化都有依据。

6. 多智能体协同的进阶思考

6.1 Agent之间的通信协议设计

多Agent协同最容易乱的地方是通信。我们早期用的是自由消息传递，Agent之间想发什么发什么，结果调试时根本理不清谁给谁发了什么。后来改成基于工单上下文的共享状态加事件通知，Agent不直接互相发消息，而是读写共享上下文，变更时发事件，其他Agent订阅自己关心的事件。这样通信路径清晰，也便于追踪。

事件的设计要克制，不能什么变更都发事件，否则事件风暴会把系统压垮。我们只对关键状态变更发事件，比如"分类完成"、"定界完成"、"派发成功"，其他中间状态只更新上下文不发事件。

6.2 冲突消解与优先级仲裁

多个Agent可能对同一个工单给出冲突的建议。比如分类路由Agent建议派给A班组，但定界定位Agent发现故障在B班组辖区。这时候需要一个仲裁机制。我们的做法是定优先级：定界结果优先于分类建议，因为定界是基于实时数据的，更准确。仲裁规则写死在编排层，不交给模型判断，保证确定性。

6.3 持续学习与经验沉淀

Agent系统上线不是终点，是起点。每个工单的处置结果都是训练数据，人工复核的修正都是标注。我们建了一个反馈闭环：人工修正的工单自动进入难例库，定期用难例做增量训练，新模型评测通过后灰度上线。这样系统越用越准，而不是一成不变。

经验沉淀还有个土办法但很有效：把老师傅的处置经验整理成规则，作为Agent的补充。模型擅长泛化，规则擅长精确，两者结合效果最好。我们让每个班组把常见故障的处置套路写下来，整理成规则库，Agent在定界时先查规则库，命中就直接用，没命中再走模型推理。

7. 选型逻辑的复盘与建议

7.1 模型选型的权衡

模型选型没有标准答案，要看具体场景。工单分类和要素抽取这类任务，7B到14B的领域微调模型足够用，没必要上更大的。更大的模型推理成本高、延迟大，在工单这种高并发场景下不划算。如果要做复杂的定界推理，可以考虑用大模型做离线分析，在线还是用小模型。

开源和闭源的选择上，私有化部署场景基本只能选开源。选开源模型要看几个点：有没有成熟的领域微调方案、推理框架支持不支持国产硬件、社区活不活跃、license允不允许商用。这几个点比模型本身的benchmark分数重要得多。

7.2 编排框架的选型

编排框架我们对比过几个方案：自己写状态机、用工作流引擎、用专门的Agent编排框架。自己写最灵活但工作量大，工作流引擎成熟但不够Agent友好，专门的Agent框架功能全但可能和信创环境不兼容。最终我们选的是自己写状态机加轻量级事件总线，核心逻辑自己掌控，依赖最少，适配最容易。

选型时有个原则：在信创环境下，依赖越少越好。每多一个第三方库，就多一份适配风险。能用标准库解决的，不引入第三方；能自己写几十行搞定的，不引入框架。

7.3 给后来者的实操建议

如果你正准备在电信或类似强合规场景落地Agent，我的建议是：先做小范围试点，选一个业务类型单一、工单量适中的场景，把端到端跑通，验证技术可行性和业务价值，再逐步扩展。别一上来就搞全业务覆盖，摊子铺太大收不住。

试点阶段重点验证三件事：分类准确率能不能达到业务要求、定界能不能真正减少上门次数、闭环自动化能不能减少人工操作。这三件事验证通过，再谈规模化。

最后说个我自己的体会：Agent系统在电信场景的价值，不在于技术多先进，而在于能不能真正嵌入现有流程、能不能被一线接受、能不能持续迭代。技术选型只是起点，后面的运营和优化才是长期功夫。我见过太多技术很漂亮但业务不用的系统，也见过技术一般但用得很顺的系统，差别就在有没有真正理解业务、有没有把人的因素考虑进去。