设备售后知识库智能体:从查手册到工单初稿
把设备手册、历史工单与故障台账放进知识库,售后工程师用自然语言提问,智能体给出排查步骤、备件建议与工单初稿,每句都能指回原文。
看案例档案 →客户项目多数受保密约束,我们的做法是:案例按客户许可逐条脱敏发布,许可下来一条放一条。每条案例都按同一套六项档案记录,方便你横向对比。
该方向暂无已发布案例,可先看其他方向,或直接把你的场景发给我们判断。
把设备手册、历史工单与故障台账放进知识库,售后工程师用自然语言提问,智能体给出排查步骤、备件建议与工单初稿,每句都能指回原文。
看案例档案 →把采购、销售与服务合同拆给抽取、比对、写作三个 Agent:先抽条款,再对照企业范本与历史风险案例,最后生成带引用位置的审查意见。
看案例档案 →把散在举报材料、笔录与资金流水里的涉案要素自动抽出来,做跨案串并,生成一份每句都能指回原始材料的研判初稿。
看案例档案 →把散在多个业务系统里的线索汇总成一份可复核的研判材料,每句结论都能指回原始材料与取数来源。
看案例档案 →检验报告、抽检表、笔录与现场照片统一解析入库,由智能体完成要素归一、跨材料比对与线索串联,只出候选不下判决。
看案例档案 →在内网信创环境里跑一个 7×24 的数字员工,承接数据整理、批量归档、内部资料调研这类重复事务,动作分级授权、全程可审计。
看案例档案 →用自然语言描述分析目标,智能体完成取数、清洗、聚合与出稿,指标口径固化成资产,每个数都能追到执行过的查询。
看案例档案 →面对几百上千页卷宗,用一句话提问就能定位到原文页码与段落,并可按体例生成文书初稿、标注全部引用位置。
看案例档案 →六项档案既是我们交付时的记录格式,也是你看案例时的检查清单。读完应该能判断出:这件事在你的单位里跑不跑得动。
只写行业与业务条线,不写客户名称与可识别信息。看案例时先确认是不是你的业务语境。
一句话说清“谁、在哪个环节、原来怎么做、要变成什么样”。说不清场景的方案,落地一定会变形。
卡点要具体到数据、系统或流程层面(数据缺失、口径不一、无接口、必须留痕)。写着“需求复杂”的,等于没写。
角色怎么切分、工具怎么编排、人在哪里复核、边界在哪里。这一项最能看出是真正做过还是套模板。
用户数、日均任务量、材料体量、部署形态(内网 / 专网、是否信创环境)。规模对不上,方案就得重新设计。
先把口径说清楚,再给数字:准确率怎么评的、耗时算的是哪一段、工时节省是怎么统计的。口径不明的效果等于广告。
从场景梳理到验收交接,每一步都有交付物。案例里的效果不是“上线之后就好了”,而是这八步走完的结果。
先判断这件事适不适合用智能体、该用单智能体还是多智能体;不合适的直接说不合适。产出《场景与边界说明》。
按现有条件选择通道:数据库只读账号 / 标准接口 / 文件通道。产出《数据与集成清单》,把前提条件写死。
确定有几个角色、各管哪一段、工具怎么注册、人在哪一步复核。产出《角色与工具编排图》。
用客户真实历史材料建评测集,先跑出基线。没有评测集的效果描述,一律不写进验收标准。
先在真实的少数任务上跑,人工双复核,记录每一个错例。产出《灰度报告与错例清单》。
上线后由交付工程师陪跑,跟着真实业务走,把口径与体例的偏差一条条改回来。
定期回归评测、跟踪指标漂移、按需扩容;模型与提示词的变更同样走回归。
按约定口径出验收数据,交文档、运维手册与培训,确保不依赖我们也能日常运行。
完整的交付流程、验收标准与服务保障见 智能体定制开发;公共安全与政企方向对应 行业解决方案 的五条线,企业侧案例对应智能体定制开发。
客户项目多数受保密约束,案例要逐条拿到客户书面许可才能写出来。我们的做法是:许可下来一条放一条,没许可的一条不放,也不拿别人的公开案例充数。
先约定指标口径(准确率、单条处理耗时、人工工时节省等),再用客户真实材料构建评测集,在同一个口径下取数;不能量化的就写成可核查的事实,不写“显著提升”这类词。
能,而且应该在签保密协议之后当面讲。我们会针对你的场景把工程细节讲清楚:数据怎么接、角色怎么切、评测集怎么建、坑大概在哪。
也接。案例库按行业分类只是为了方便检索,真正决定能不能做的是场景结构:是不是多步骤、要不要跨系统取数、允不允许设置人工复核卡点。
不会。案例里不出现客户名称、内部系统名称与可识别信息,只保留行业与业务条线——这也是我们能拿到发布许可的前提。
留下场景与部署环境,我们先判断这件事适不适合用智能体、该用哪一种,再谈怎么做。第一轮沟通不需要保密协议也能聊框架。