在日常研发支持中，工程师们常常需要频繁穿梭于工单、群聊、舆情反馈与问题排查之间：一边向业务方解释复杂的业务规则与口径，另一边又要埋头追踪技术链路、查看海量日志、核对监控指标、执行数据补偿。这类工作通常高度碎片化、重复性强，且严重依赖工程师的个人经验，最终导致团队响应效率低下、问题处理质量不稳定、新人上手极其困难。
为了解决这个痛点，我们围绕“研发支持中的问诊难题”，构建了一个可持续运营的智能 Agent 系统。通过将一线高频问题抽象为两类核心能力形态（业务答疑与问题诊断），并结合“排查文档技能化”与“质量评分闭环”的创新机制，我们实现了将大量解释与排查工作前置并自动化。这套系统的目标不仅是“能运行”，更要能持续迭代进化，从而显著缩短首次响应时间与平均问题解决时长，提升服务的一致性与工程团队的整体效能。
一、背景：研发支持的真实工作流（为什么痛）
对于开发者而言，研发过程中最消耗精力的往往不是写代码，而是被不断打断。
想象一下典型的工作日清晨：你正准备推进昨日因会议中断的核心开发任务，刚打开钉钉，消息提示就如潮水般涌来：
- 产品经理转发了一段聊天记录，急切询问某个功能入口的具体逻辑；
- 测试同事发来一条舆情链接，请求协助判断用户反馈是否属于系统异常行为；
- 一线客服反复催促处理一个未闭环的工单，称商家已多次追问……
为什么研发同学的一天总是这样开始？根本原因在于，随着业务长期演进与人员流动加剧，知识逐渐变得碎片化甚至出现断层。大量关键信息散落在代码注释、历史讨论或个别专家脑中，缺乏有效的组织与沉淀机制。以工单处理为例，系统可能已稳定运行多年，却始终没有形成可复用的经验资产，导致后续人员面对相似问题时仍需从零开始排查。同时，现代应用架构日益复杂，一个业务功能常常横跨多个微服务及数十个二方包，排查过程堪比一次“技术长征”。
这并非个例。根据内部调研数据，后端开发人员约有 20% 的时间用于处理运维类事务（如日常答疑、故障排查等），大量碎片化的投入严重影响了主职研发效率。
因此，我们要解决的并非某一个具体的技术难题，而是更根本性的问题：
如何让研发支持工作变得可规模化、可复用、可运营？
二、问题抽象归纳：将千奇百怪的问题收敛为两种能力形态
尽管用户提问的形式五花八门，但从“研发支持”的本质出发，可以将其归结为两大类典型任务：
2.1 形态一：业务答疑（解释型能力）
典型问题示例：
- “为什么我在后台看到A，用户在前端却看到B？”
- “业务看板上的汇总数据和明细对不上怎么办？”
- “这个订单字段的状态值‘5’到底代表什么？”
工程化定义：
输入通常是某个现象或疑问；输出应包含：规则/口径说明 + 查证路径 + 结论边界。
常见成因包括：AB实验策略、人群圈选、灰度发布、权限控制、版本差异、统计口径延迟等。
核心模式：
理解用户意图 → 从知识库召回相关文档 → 模型综合分析 → 输出结构化解答。
这类场景相对成熟，已有较多实践，本文不做重点展开。
2.2 形态二：问题诊断（诊断型能力）
典型问题示例：
- “订单状态卡住了，一直不更新。”
- “退款金额不一致 / 平台与商家对账失败。”
- “这个接口调用超时 / 单笔交易流程异常。”
工程化定义：
输入通常是携带具体ID（如订单ID、用户ID）的异常事实；输出需包含：证据链 + 定位步骤 + 可执行动作（如执行补偿、发起恢复、升级处理）。
常见根因：服务链路异常、依赖调用超时、补偿任务未触发、消息队列堆积、状态机阻塞、数据一致性问题等。
核心模式：
分析问题意图 → 调用工具按标准作业程序（SOP）执行排查流程 → 综合各步骤结果生成结论 → 提供明确的操作建议。
相较于答疑类任务，诊断类对Agent的要求更高，需要其具备一定的逻辑决策能力和与外部系统的协同能力。
2.3 为什么要进行这种抽象？
因为这两种场景对应的Agent构建范式存在显著差异。我们的目标不仅仅是“让AI回答问题”，更要稳定地替代工程师完成一段标准化的支持流程。
当问题被抽象为上述两种能力形态后，Agent的输出格式即可统一规范为以下结构：
结论 + 分析解释（规则/口径）+ 排查计划（可选）+ 动作建议 + 文档引用
这种结构化的输出，为后续的自动评估、系统运营与能力迭代提供了坚实的基础。
三、为什么值得做：收益空间来自“重复 + 切换 + 不一致”
研发支持的隐性成本远不止单次排查所花费的时间，它主要体现在三个方面：
- 重复劳动：高频问题反复出现，造成人力资源的持续性浪费。
- 上下文切换成本：工程师需要在不同业务系统、监控工具、日志平台间频繁跳转，严重打断其深度专注状态。
- 口径漂移：不同工程师对同一问题可能给出不一致的答案，引发业务方的信任损耗。
更重要的是，一套自动化系统能够有效解决因人员流动带来的知识断层风险，实现关键经验的有效沉淀与传承，支撑技术团队的可持续发展。
四、系统总览：一个“可运营”的问诊Agent需要什么？
我们的核心理念是：Agent建设必须具备可沉淀、可复用、可评估、易迭代的能力。
基于此，我们将整个系统自上而下划分为四个清晰的层次：
4.1 四层架构设计
| 层级 |
职责 |
| 接入层（Channels） |
对接工单系统、舆情平台、IM群聊、合作方咨询入口等。需特别注意输入信息的冗余处理与多模态内容（如图片、视频截图）的预处理，以节约大模型token成本。 |
| 编排层（Orchestration） |
进行意图识别（判断属于解释型还是诊断型问题），并将问题路由至对应的领域Agent。 |
| 实现层（Agent） |
包含大语言模型（LLM）、检索增强生成（RAG）模块、排查技能文档库、公共知识库、上下文组装、工具调用策略等实际执行组件。 |
| 运营评估层（Ops & Eval） |
负责问答记录管理、跟进事项跟踪、回答质量评分、数据报表监控、反馈闭环处理等，确保系统持续优化。 |
4.2 设计原则：小域专精，避免大而全
以电商交易后链路为例，其涵盖订单正向履约、逆向退款、物流服务、商家支持、评价互动等多个子领域。各子域的服务对象、问题特征差异较大，耦合度低。
因此，我们放弃了构建“统一全能Agent”的模式，转而采用按业务子域独立建设专用Agent的策略。这种“小域专精”模式的优势显而易见：
- ✅ 最大程度复用已有资产：可以直接复用各团队已有的技术支持文档与业务资料。
- ✅ 提升回答准确性：避免在RAG向量召回时，不同领域的知识互相污染，干扰上下文。
- ✅ 降低系统复杂度：路由逻辑更简单，各Agent独立进化，相互干扰少，整体开发和维护效率更高。
示例：问诊小助手内部模块交互架构
五、Agent构建演进：从“流程编码”到“技能化”
5.1 平台选择与早期模式
我们选用内部的IdeaLab平台进行快速搭建，以避免重复造轮子。该平台支持多种Agent构建方式：
早期我们主要尝试了两种模式：
（1）初阶模式：Java编码驱动流程
在提示词中编写指令，但实际的排查工作流完全依赖内部预先用Java代码编排好的工具链。
# Role
你是一位严谨的工程技术支持人员，需要根据用户的问题提供详细而准确的回答。
# Background knowledge
guangguang叫逛逛
# WorkFlow
问题理解：你需要理解用户提出的问题，并根据问题的内容进行分析和归纳，必要时提取用户提供的关键输入作为工具的输入参数。
工具诊断：你需要根据用户的问题，选择合适的关联工具进行诊断，如果用户遗漏关键的参数信息则需要对用户进行提示
信息整理：你需要将从参考文档中检索到的信息进行整理，将相关信息与问题进行关联，形成回答内容，最终需要附上参考文档链接。
回答生成：你需要根据整理的信息，生成详细而准确的回答，包括问题的详细回答、分析、流程和注意事项等。
# 诊断能力描述
重置置顶缓存：调用<重置置顶缓存> 工具 参数itemIds 示例：重置置顶缓存[780788648052,861343465303]
买家秀入口诊断：调用<买家秀入口诊断> 工具 参数itemId 示例：买家秀入口诊断848816927344
买家秀内容诊断：调用<买家秀内容诊断> 工具 参数contentId 示例：买家秀内容诊断464560595421
商品维度数据订正：调用<重置买家秀入口> 工具 参数itemId sellerId 示例：重置买家秀入口8488169273442211962305636
# 限制
你只能根据参考文档回答用户的问题，不能提供参考文档中没有的信息。
你需要确保回答的准确性，不能捏造或创造答案。
你需要在回答中提供参考链接，链接包括来源的标题和URL，如果信息来自多个，请都列出
你需要在回答中注明参考文档的来源，以便用户可以进一步查看相关资料。
如果没有能回答问题的参考文档，你需要直接回答“抱歉，这个问题我无法回答，请联系值班同学”。
特点：排查逻辑由Java代码完全实现。
缺点：模型仅作为“意图识别器”和“工具调用器”，其强大的推理能力未被充分利用；流程完全固化，灵活性差，难以快速迭代。
（2）进阶尝试：提示词内嵌SOP
将完整的排查流程直接写入提示词，并将工具能力原子化。
# 角色
你是一位严谨的工程技术支持人员，需要根据用户的问题和参考文档：${REFERENCE_DOC}，提供详细而准确的回答。
# 工作流
前置知识：订单id 一般有18或者19位 如4227378732121862513 评价id 相对比较短 如1263242509876
问题理解：你需要理解用户提出的问题，并根据问题的内容进行分析和归纳，必要时提取用户提供的关键输入作为工具的输入参数。
工具诊断：你需要根据用户的问题，选择合适的关联工具进行诊断，必要时需判断用户输入到底是订单id还是评价id，如果用户遗漏关键的参数信息则需要对用户进行提示，对于诊断不通过的场景需要给出工具的原始输出作为引用
数据订正：根据用户的问题，选择相应的工具进行订正，如果用户输入的参数不对，则需要进行提示。数据订正的结果需要全部返回，并针对结果做简要的分析
信息整理：你需要将从参考文档中检索到的信息进行整理，将相关信息与问题进行关联，形成回答内容，最终需要附上参考文档链接。
回答生成：你需要根据整理的信息，生成详细而准确的回答，包括问题的详细回答、分析、流程和注意事项等。
# 能力描述
待评价状态订正：调用<待评价状态订正>工具 参数订单id 用户id
示例：待评价状态订正 3690598644532059518 923051895
订单是否可评校验：调用<订单待评价校验>工具 检验改订单是否能够评价 示例订单是否可评3690598644532059518
评价有礼渲染校验：调用<评价详情接口>工具 根据返回的数据检测字段rewardNumberFormat对应的值是否为空，如果不为空则输出“校验通过，渲染时透出评价有礼相关信息”，并给出透出的具体金额；如果返回的评价信息不空，则返回“渲染时无评价有礼信息”；如果没有返回评价信息，则输出“没有查到评价信息，请检查订单号是否有误，或者改评价是否已超过两年”
评价有礼未发放：调用<评价详情接口>工具 根据返回的数据检测字段pjyl对应的值是否为空，如果不为空则输出“该评价已发放红包”；否则输出“改评价不满足发放条件”，并结合评价有礼问题排查手册，给出具体原因
# 限制
你只能根据参考文档回答用户的问题，不能提供参考文档中没有的信息。
你需要确保回答的准确性，不能捏造或创造答案。
你需要在回答中提供参考链接，链接包括来源的标题和URL，如果信息来自多个，请都列出。
你需要在回答中注明参考文档的来源，以便用户可以进一步查看相关资料。
如果没有能回答问题的参考文档，你需要直接回答“抱歉，这个问题我无法回答，请联系值班同学”。
优点：灵活性增强，减少了对硬编码的依赖。
缺点：当多个技能共存于一个提示词时，会导致“提示词爆炸”问题；上下文变得混乱，模型的指令跟随能力下降，运行稳定性变差；可维护性极差，每新增一个技能都需要修改主提示词。
（3）Workflow模式的局限性
虽然Workflow模式更利于原子化工具的组合编排，但每次新增技能都需要重新进行可视化编排，开发和调试成本依然不低。
更重要的是，它强依赖人工预先编排，难以享受到底层大模型能力提升带来的“红利”，也未能从根本上解决系统的长期可维护性问题。
综上所述，我们需要一种既能保证高质量、稳定输出，又能支持低成本、快速迭代的新范式。
5.2 新范式：把排查能力封装成“可召回的排查文档（SOP Doc）”
受ReAct（Reasoning and Acting）框架启发，我们提出了新的构建思路：以“场景排查文档”作为最小的能力单元，通过RAG技术进行精准召回并动态注入上下文，从而引导大语言模型严格按手册步骤执行，并让其自主完成工具调用与过程纠错。
核心思想转变：
- 文档即技能闭包：用强约束的文档减少模型的“幻觉”与自由发挥。
- 新增能力 = 新增文档：无需改动核心提示词或编排流程，实现能力与系统的解耦。
- 维护对象下沉：工程师的维护工作从“修改代码/调整prompt”变为“编写和维护业务排查手册”，更贴近一线实际。
这种模式与当前主流的Agent Skills架构理念相通——按需加载、技能固化，极大地提升了Agent运行的可控性与稳定性。
排查文档模板格式示例：
# 适用范围
简单描述适用场景 并给出指令使用示例
# 字段说明（可选）
给出场景依赖字段的说明 如pjyl 字段为1 表示权益已发放
# 核心日志格式（可选）
针对核心日志做些说明 避免模型胡诌
# 排查思路
描述具体的排查步骤 期间使用工具时，给出使用的参数提示
示例：评价有礼问题诊断文档
# 评价有礼问题诊断
## 适用范围
命中关键字《评价有礼》，后面是订单id
支持的参数类型：订单ID
使用示例：
评价有礼诊断4927155483760273522 解释：通过订单进行评价有礼问题诊断
## 字段说明
| 字段名 | 描述 | 备注 |
| ------------------ | ------------------------------------------------------------- | -------------------------------------------------------------- |
| rewardType | 表单渲染时 评价有礼权益类型 | |
| rewardStatus | 表单渲染时 是否命中评价有礼活动 | 不能用该字段判断评价有礼是否发放 |
| rewardNumberFormat | 表单渲染时 权益金额 | |
| pjyl | 权益是否发放 对应的枚举值<br>1: 已发放 | **该字段是判断评价最终是否发放权益的唯一标准** |
| giftFail | 评价有礼未发放原因说明 具体的值参考RateGiftReasonEnum说明 | |
| ttid | 客户端设备信息 | taobao或者淘特ltao 满足<br>tmall 或者不存在 不满足发放条件 |
| csiReceive | 1 表示已进行安审处理 | |
## 枚举类
publicenumRateGiftReasonEnum {
RATE_GIFT_REASON_0("rateGiftNoRender", "渲染时候无评价有礼"),
RATE_GIFT_REASON_1("rateGiftMaxRetry", "失败重试达到最大次数"),
RATE_GIFT_REASON_2("rateGiftSafeFail", "安全校验失败"),
RATE_GIFT_REASON_3("rateGiftMaxTime", "红包一天获取达到最大次数"),
RATE_GIFT_REASON_4("rateGiftContentFail", "不满足图文数要求"),
RATE_GIFT_REASON_5("rateGiftAppVersionFail", "版本未达到最低限制"),
RATE_GIFT_REASON_6("rateGiftABFail", "没有命中一休实验"),
RATE_GIFT_REASON_8("rateGiftNotGift", "没有查询到优惠"),
RATE_GIFT_REASON_10("rateGiftSwitchFail", "开关关闭"),
RATE_GIFT_REASON_11("rateGiftCsiFail", "csi校验失败"),
RATE_GIFT_REASON_12("rateGiftTtidFail", "ttid校验失败"),
RATE_GIFT_REASON_15("rateGiftStatusFail", "评价状态异常"),
RATE_GIFT_REASON_16("rateGiftNoToken", "没有安全码的token"),
RATE_GIFT_REASON_17("rateGiftNoWord", "没有文本"),
RATE_GIFT_REASON_18("rateGiftBlackUser", "黑名单用户"),
RATE_GIFT_REASON_19("rateGiftContentQualityFail", "算法判定优质内容失败"),
RATE_GIFT_REASON_20("contentDuplication", "算法判定图片重复"),
RATE_GIFT_REASON_21("rateGiftOrderShield", "官旗远近一体订单屏蔽"),
RATE_GIFT_REASON_22("rateGiftTppFail", "算法校验失败"),
RATE_GIFT_REASON_23("rateGiftAlipayAccountUnBind", "支付宝账号未绑定")
;
}
### 常见日志详解
1、c.a.r.RateGiftClient - getRateGift empty template userId 2217131088093 outTransactionId 3150208885052089380 [traceId=2147811917670710230915204e119e] 未查询到权益投放，根本原因是营销侧有其他规则卡口， 建议联系营销业务pd 绾（wǎn）吟 或者 技术: 朝暄 进行排查给出具体原因 结束诊断
2、c.a.r.l.SystemLogHelper - AstoreRenderUtil_getRateGift@emptyTemplateDTOsAfterFilter|2147bfe417669077420817545e1cbb||3140922291838345589@819348955@notReward[traceId=2147bfe417669077420817545e1cbb] 没有命中某个具体权益的实验组 导致权益后后置过滤
3、c.a.r.u.RateGiftUtil - openEntrance riskCheckFail userId 2540803590[traceId=213e0a6917676176365646675e1b25] 反作弊校验失败 被判定是风险用户
4、c.a.r.u.RateGiftUtil - openEntrance checkAppQualificationFail userId 2753241465[traceId=ac101de617676177786136918d00fb] 端设备不满足条件 一般是ttid 为空 无法判断上游请求的版本号
5、c.a.r.u.RateGiftUtil - baseBizCheck rateGiftAugeCrowdFail userId:856344752[traceId=215047c617676178821137187e1117] 仅退款限制人群
6、c.a.r.u.RateGiftUtil - baseBizCheck abCheckFail userId:391332373[traceId=213e0a7117676180058058136e107a] 未命中评价有礼实验（前置）
7、c.a.r.u.RateGiftUtil - baseBizCheck checkRateGiftNumFail userId:3317050705[traceId=213e036c17676125039067245e110b] 触发每天30个权益限领规则限制
除了empty template 即营销侧卡口限制外，其余均属于正常业务逻辑
## 排查步骤
识别参数,选择不同的诊断流程
### 传入用户ID
1. 通过<用户近期评价查询>工具查询最近评价
2. 检查评价扩展字段判断发放情况
3. 提取订单ID，按订单ID排查流程进行
### 传入订单ID
严格按照以下顺序进行.找到原因可提前终止诊断流程
1、查看评价详情
检查扩展字段中评价有礼相关字段状态 pjyl =1 表示已发放
2、检查ttid
taobao 或者淘特ltao 满足
天猫客户端tmal 不满足透出条件
3、错误码为‘rateGiftNotGift’
使用星环运维日志查询工具（BSP）app: rateplatform query: ‘${orderId} AND (preCheck OR template OR AstoreRenderUtil_getRateGift)’ 并输出完整的关键日志需包含traceId
- 如果没有查询到日志 则提示未找到关键日志 建议联系值班同学处理 并终止流程
- 否则严格根据查询到的日志，对照上述日志说明分析具体原因
- 如果未查询到有效日志，则获取preCheck = false的记录，使用traceId再次检索 查询关键字 ‘${traceId}’ 再次进行分析
4、如果上述步骤仍然未确定具体的问题 则终止诊断 建议联系值班同学处理
主Agent提示词重构：聚焦“执行规范”
在新的范式下，主Agent的提示词不再包含具体的业务技能描述，而是聚焦于如何严格地执行被召回的排查文档。
## 角色
你是一位评价技术人员，专门负责理解和解答用户的问题，通过分析和查询知识库或使用诊断工具，给出详细且准确的答复。
## 传参指导
订单id 一般是18或者19位 如4225314782712469106
评价id 一般14位 如 1266388224142
时间戳 13位的是毫秒格式 10位是以秒为单位 转为日期格式的时候要额外注意
## 技能
1、意图识别：识别用户问题分类，选择合适的排查工具/方法
2、工作流程（严格遵守）：
**STEP 1: 知识库解析（必做）**
在回答前，你必须：
1. 检查是否收到了${REFERENCE_DOC}（知识库内容）
2. 如果没有，立即停止并告知用户"知识库未提供，无法进行诊断"
3. 从知识库中提取排查手册的完整步骤清单，格式化为：
【步骤清单】
- 第1步：[具体操作]
- 第2步：[具体操作]
- ...
**STEP 2: 严格按序执行（核心约束）**
按照上面列出的步骤顺序，逐步执行：
- 每次调用工具前，必须说：【执行手册第X步】根据手册要求，我现在执行：[具体操作]
- 基于结果，确定是否继续下一步
**严格规则（不允许违反）：**
- ❌ 不允许跳步
- ❌ 不允许改变顺序
- ❌ 不允许添加手册外的步骤
- ❌ 不允许自主决定是否执行某一步
- ✅ 只有当步骤无法执行时，才能停止并说明原因
**STEP 3: 结果聚合与输出**
遵循特定的格式，将答复划分为背景、结论、分析和参考文档等模块
3. 多轮对话：对于不清楚的问题，能够通过提问进一步明确用户需求，避免误解。
4. 信息简化：能够判断哪些信息是必要的，并在必要时省略无关模块。
## 限制和约束（必须遵守）
1. **你不是诊断专家，你是手册执行者**
- 不允许用自己的知识替代手册
- 不允许说"根据经验..."或"通常..."
- 必须说"根据手册..."
2. **手册是唯一的真理来源**
- 如果手册说做A，你就做A
- 如果手册没说某个步骤，你就不做
- 如果无法按手册操作，告知用户"抱歉，这个问题我无法回答，可点击[创建工单]进行咨询"
3. **思考过程必须透明**
- 用户必须能看到你的每一步思考
- 用户必须能追踪你的执行逻辑
4. **条件判断要显式化**
- 如果手册有分支（"如果X则执行A，否则执行B"）
- 你必须明确说："因为X条件为真，所以执行A"
## 回答格式
1. **背景**：提炼输入文本中的关键信息。
2. **结论**：提供清晰的解决方案或问题根源分析。
3. **分析**：详细阐述结论的依据，按步骤解释（应包含【执行手册第X步】的标注）。
4. **参考文档**：列出所有相关的文档链接（如果有）。
5. **标准化格式**：保持结构化回答， 不同部分之间用一行空格分隔，不要输出格式无关内容。
6. **结束语**："若仍有疑问，可点击[创建工单]进行咨询，将有专人跟进处理"。
💡 平滑迁移方案：
- 对于原有的Workflow架构：可以增加一个兜底路由，将新识别出的能力场景导向新范式处理。
- 对于原有的智能助手架构：只需将原来写在提示词里的复杂技能描述拆分出来，整理成独立的排查文档，即可快速完成能力迁移。
六、知识体系：双层召回，降低冗余与幻觉
尽管“排查文档”范式有效提升了Agent的逻辑规划能力，但在知识组织上我们仍面临挑战：
6.1 问题1：背景知识重复冗余
例如，订单字段定义、状态机流转逻辑、错误码枚举等内容，如果分散在数十个不同的场景排查文档中，极易造成信息不一致和维护困难。
6.2 问题2：跨子域共性知识难以共享
最典型的例子就是“参数识别”，比如“如何判断用户输入的是订单ID、用户ID还是商品ID”。这类通用逻辑在各子域的文档中描述各异，质量参差，无法有效共建复用。
6.3 解决方案：公共知识库 + 场景技能文档 双层召回
为此，我们设计了双层知识体系：
| 类型 |
内容 |
特点 |
| 公共知识库 |
系统级常识、领域通用概念、字段字典、状态机说明、错误码大全等 |
稳定、通用、一次定义，多处复用 |
| 场景技能文档 |
针对具体问题的诊断流程、工具调用顺序、分支判断逻辑 |
聚焦、精准、低冗余 |
召回策略：
- 优先精确命中场景技能文档：提供强约束的排查步骤。
- 辅助召回公共知识：通过Tag筛选或模型自主识别，补充必要的背景信息。
- 支持人工干预与权重调节：确保召回的准确性与相关性。
为便于知识的管理与生产，我们正在建设一个简易的后台系统，支持“专家编写”与“AI辅助生成”相结合的混合模式。
从完整的能力构建视角来看，一次新能力的创建包含以下标准化步骤（虚线部分为正在建设中的能力）：
七、质量评估与闭环：让Agent“可运营”
一个智能Agent系统能否真正落地并持续创造价值，不仅取决于其初始能力的强弱，更关键的是是否具备可衡量、可迭代、可持续进化的运营机制。为此，我们建立了以“质量评估—反馈回流—知识优化”为核心的闭环体系，确保系统不是一个静态的自动化工具，而是一个越用越聪明的“有机体”。
7.1 多维度评估框架：从F1到Q-score
我们引入了细粒度的质量评分机制——Q-score（Quality Score），采用 0–10 分制 对单次问答进行综合性打分。该评分综合考虑了答案的准确性、完整性、逻辑性、可操作性等多个维度。
✅ 实践标准：我们将 Q-score ≥ 7 定义为“有效回答”。这类回答即使不够完美，也能显著降低人工介入成本，具备实际生产可用性。
7.2 自动化评估的价值：聚焦坏样本，驱动快速迭代
随着系统上线，月均交互量迅速增长，纯人工评估已不可行。我们的策略并非追求“全自动精准裁判”，而是利用AI实现低投入、高回报的异常检测：
目标是快速识别出低质量问答（坏样本），而非为每一条输出打准十分。
基于此，我们构建了专用的 “评分Agent” ，其核心逻辑是：结合高质量正例与典型负例进行Few-shot学习，辅以领域规则，对历史问答记录进行自动化打分，并输出扣分明细（如“跳步执行”、“引用过时文档”）。
这套机制的优势在于：
- ✅ 快速发现明显缺陷，减少人工复核工作量（仅需聚焦 ≤6 分的低分样本）。
- ✅ 支持高频监控与趋势追踪，及时感知能力退化。
7.3 闭环机制：从反馈到进化的正向循环
我们设计了一套完整的反馈回灌流程，将每一次低质量暴露转化为系统升级的机会：
线上问答 → 评分Agent打分 → 聚焦低分样本（≤6）→ 人工复核 → 根因归因
↓
更新排查文档 / 补充公共知识 / 优化提示词 → 回灌至训练集
这一闭环带来了三大核心收益：
- 知识沉淀加速：每一次失败都成为新知识的来源，避免同类问题重复发生。
- 模型行为收敛：将典型错误样例注入评分Agent的示例库，使其识别能力不断增强。
- 运营透明可控：所有修改均有迹可循，保障系统演进过程始终处于受控状态。
🔁 本质转变：Agent不再是静态部署的一次性产物，而是一个依托数据反馈持续生长的“有机体”。
八、实战成效：多个领域落地验证
目前，该问诊Agent系统已在交易后链路的多个核心场景成功落地：
- 买家订单管理
- 物流查询
- 商家问题答疑
- 评价场域支持（含问大家、买家秀、种草）
- 逆向流程诊断
部分因数据链路同步导致的“疑难杂症”，如今运营小二可通过Agent一键诊断并执行重置，实现了研发零干预！
案例1：评价场域问诊
案例2：逆向领域问题排查
案例3：商家相关问题诊断
案例4：物流场景问诊
案例5：订单相关问题诊断
问诊Agent相关服务指标
问诊小助手近几期的服务次数趋势：
研发月度工单受理数显著下降：
问答平均质量分（AVG(Q-score)）：
（注：部分小助手评分低是由于样本量太少，个别负面案例对平均分影响较大。）
问答有效率（Available，Q-score >= 7分）：
| 召回率（Recall）、精准率（Precision）与F1值（基于近期人工标注数据计算）： |
问诊助手 |
召回率 |
精准率 |
F1 |
| 买家订单管理 |
83.33% |
83.33% |
83.33% |
| 物流查询小助手 |
100% |
75.00% |
85.71% |
| 商家问题答疑小助手 |
80% |
75% |
77.42% |
| 评价小助手 |
90% |
85% |
87.43% |
| 逆行者2.0 |
90% |
80% |
84.7% |
问诊Agent管理后台概览：
九、总结与展望：边界与下一步
本系统围绕“研发支持的问诊痛点”，介绍了一种运维友好型问诊Agent构建范式及运营体系。通过将大量高频的重复解释与问题排查工作自动化，并以标准化排查文档的形式快速接入，我们显著提升了能力迭代效率，使团队新成员也能快速上手处理复杂问题。
当前边界
- 依赖专家经验：高质量Skill Doc的撰写仍需领域专家投入。
- 长尾问题覆盖不足：完全依赖模型自由推理处理未知问题的可靠性仍有待提升。
- 知识固化vs模型泛化：随着底层大模型能力的不断增强，是否仍需如此显式的固化文档？这是一个需要持续观察和平衡的问题。
下一步方向
-
降低产出门槛
- 探索基于代码注释、接口文档、链路日志自动生成Skill Doc初稿，经人工审核后快速上线，加速知识沉淀。
-
增强实时反馈能力
- 当前纠偏依赖月度复盘，下一步目标是实现分钟级异常检测与自动告警，让系统响应更敏捷。
-
探索“AI Native”知识组织方式
- 若未来模型具备足够的领域理解力，我们能否探索将部分代码逻辑直接转化为“可执行的语义指令”？
- 推动知识表达从“人类为主，AI为辅”向“AI为主，人类审核”的范式演进。
💬 “让新人也能像老将一样从容应对复杂问题，这才是真正的工程提效。”
我们相信，通过持续迭代 系统设计 与运营闭环，智能问诊Agent将成为研发团队不可或缺的“数字同事”，不仅解放工程师的生产力，更成为组织知识传承与效能提升的核心引擎。欢迎在 云栈社区 交流更多关于Agent落地的实践与思考。
发表于 14 小时前
|
查看: 3|
回复: 0
