研发支持工作流中存在大量碎片化、重复性高且依赖个人经验的问题严重影响效率和质量。阿里工程师构建了可持续运营的智能Agent系统通过将高频问题抽象为“业务答疑”和“问题诊断”两类核心能力结合“排查文档技能化质量评分闭环”机制实现了解释与排查工作的前置自动化。该系统显著缩短了响应时间和解决时长提升了服务一致性并沉淀了可复用的经验资产有效解决了知识断层和人员流动带来的挑战。一、背景研发支持的真实工作流为什么痛对于开发者而言研发过程中最消耗精力的往往不是写代码而是被不断打断。一个典型的工作日清晨你正准备推进昨日因会议中断的开发任务打开钉钉却发现消息如潮水般涌来产品经理转发一段聊天记录询问某个功能入口的具体逻辑测试同事发来一条舆情链接请求协助判断是否属于异常行为一线客服催促处理未闭环的工单称商家已多次追问……为何研发的一天总是这样开始根本原因在于随着业务长期演进与人员流动加剧知识逐渐碎片化甚至出现断层。信息多散落在代码注释、历史讨论或个别专家脑中缺乏有效的组织沉淀机制。以工单处理为例系统运行多年却始终没有形成可复用的经验资产后续人员面对相似问题仍需从零排查。同时应用架构日益复杂一个功能常横跨多个服务及数十个二方包排查过程如同“长征”。这并非个例现象。根据内部调研数据后端开发人员约有 20% 的时间用于运维类事务如答疑、排障等大量碎片化投入严重影响了主职研发效率。因此我们要解决的不是一个具体的技术问题而是如何让研发支持变得可规模化、可复用、可运营二、问题抽象归纳将千奇百怪的问题收敛为两种能力形态尽管用户提问形式多样但从“研发支持”的本质出发可以将其归结为两大类典型任务2.1 形态一业务答疑解释型能力典型问题示例“为什么我看到 A用户却看到 B”“看板数据和明细对不上怎么办”“这个字段的状态到底代表什么”工程化定义输入是现象或疑问输出应包含规则/口径说明 查证路径 结论边界。常见成因包括AB 实验策略、人群圈选、灰度发布、权限控制、版本差异、统计口径延迟等。核心模式理解用户意图 → 从知识库召回相关文档 → 模型综合分析 → 输出结构化解答。这类场景相对成熟本文不做重点展开。2.2 形态二问题诊断诊断型能力典型问题示例“订单状态卡住了”“退款金额不一致 / 对账失败”“接口超时 / 单笔交易异常”工程化定义输入通常是携带具体 ID 的异常事实输出需包含证据链 定位步骤 可执行动作如补偿、恢复、升级。常见根因链路异常、依赖超时、补偿未触发、消息堆积、状态机阻塞、数据一致性问题等。核心模式分析意图 → 调用工具按 SOP 执行排查流程 → 综合结果生成结论 → 提供操作建议。相较于答疑类诊断类任务要求更高需要一定的决策能力和外部系统协同。2.3 为什么要进行这种抽象因为这两种场景对应的 Agent 构建范式存在差异。我们的目标不仅是“回答问题”更要稳定地替代工程师完成一段标准化的支持流程。当问题被抽象为上述两种能力形态后Agent 的输出即可统一规范为以下结构结论 分析解释规则/口径 排查计划可选 动作建议 文档引用这一结构化的输出为后续评估、运营与迭代提供了坚实基础。三、为什么值得做收益空间来自“重复 切换 不一致”研发支持的隐性成本远不止单次排查所花的时间主要体现在三个方面重复劳动高频问题反复出现造成资源浪费上下文切换成本在不同系统间跳转打断专注状态口径漂移不同人给出不同答案引发信任损耗。更重要的是它解决了因人员流动带来的知识断层风险实现了关键经验的有效沉淀支撑团队的可持续发展。四、系统总览一个“可运营”的问诊 Agent 需要什么我们的核心理念是Agent 建设必须具备可沉淀、可复用、可评估、易迭代的能力。基于此我们将系统划分为四个层次4.1四层架构设计层级职责接入层Channels工单、舆情平台、IM 群、合作方咨询入口。特别注意输入冗余与多模态内容如图片、视频的预处理以节约 token 成本。编排层Orchestration意图识别解释型 / 诊断型、路由至对应 Agent。实现层Agent包含 LLM、RAG、排查技能文档、公共知识库、上下文组装、工具调用策略等实际执行组件。运营评估层Ops Eval问答管理、跟进项跟踪、质量评分、报表监控、反馈闭环。架构示意4.2 设计原则小域专精避免大而全以交易后链路为例其涵盖订单正向、逆向退款、物流服务、商家支持、评价互动等多个子领域。各子域服务对象、问题特征差异较大耦合度低。因此我们放弃“统一多 Agent”模式转而采用按子域独立建设专用 Agent 的策略。优势如下✅ 最大程度复用已有技术支持文档与业务资料✅ 提升准确性避免 RAG 向量召回时上下文污染✅ 减少路由复杂度降低相互干扰提升开发效率。示例问诊小助手内部结构五、Agent 构建演进从“流程编码 提示词堆砌”到“技能化 原子化”5.1 平台选择我们选用内部 IdeaLab 平台进行搭建避免重复造轮子。该平台支持多种构建方式早期主要使用“智能助手”和“流程编排”两种模式。1初阶模式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如果信息来自多个请都列出。 你需要在回答中注明参考文档的来源以便用户可以进一步查看相关资料。 如果没有能回答问题的参考文档你需要直接回答“抱歉这个问题我无法回答请联系值班同学”。优点灵活性增强减少编码依赖。缺点多技能共存导致提示词膨胀“提示词爆炸”问题突出上下文混乱指令跟随能力下降运行稳定性差可维护性差新增技能即需修改主提示词。3Workflow 模式workflow模式虽更利于原子工具组合但每次新增技能均需重新编排开发调试成本并不低。举例线上workflow编排一角更重要的是它强依赖人工编排能享受到模型提升带来的红利有限也没能解决长久的可维护性问题。综上我们需要一种既能保证输出质量又能低成本快速迭代的新范式。5.2 新范式把排查能力封装成“可召回的排查文档SOP Doc”受 React 框架启发我们提出新思路以“场景排查文档”作为最小能力单元通过 RAG 精准召回动态注入上下文引导模型严格按手册执行自主对工具调用进行纠错。核心思想转变文档即技能闭包强约束减少幻觉与自由发挥新增能力 新增文档无需改动提示词或流程实现解耦维护对象下沉从“改代码/调 prompt”变为“写和维护排查手册”贴近一线。该模式与当前主流 Skills 架构理念相通——按需加载、技能固化提升 Agent 运行的可控性与稳定性。排查文档模板格式# 适用范围 简单描述适用场景 并给出指令使用示例 # 字段说明可选 给出场景依赖字段的说明 如pjyl 字段为1 表示权益已发放 # 核心日志格式可选 针对核心日志做些说明 避免模型胡诌 # 排查思路 描述具体的排查步骤 期间使用工具时给出使用的参数提示示例评价有礼问题诊断文档# 评价有礼问题诊断 ## 适用范围 命中关键字《评价有礼》后面是订单id 支持的参数类型订单ID 使用示例 评价有礼诊断4927155483760273522 解释通过订单进行评价有礼问题诊断 ## 字段说明 | 字段名 | 描述 | 备注 | | ------------------ | --------------------------------------------------------- | ---------------------------------------------------------- | | rewardType | 表单渲染时 评价有礼权益类型 | | | rewardStatus | 表单渲染时 是否命中评价有礼活动 | 不能用该字段判断评价有礼是否发放 | | rewardNumberFormat | 表单渲染时 权益金额 | | | pjyl | 权益是否发放 对应的枚举值br1: 已发放 | **该字段是判断评价最终是否发放权益的唯一标准** | | giftFail | 评价有礼未发放原因说明 具体的值参考RateGiftReasonEnum说明 | | | ttid | 客户端设备信息 | taobao或者淘特ltao 满足brtmall 或者不存在 不满足发放条件 | | 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 \[traceId2147811917670710230915204e119e\] 未查询到权益投放根本原因是营销侧有其他规则卡口 建议联系营销业务pd 绾wǎn吟 或者 技术: 朝暄 进行排查给出具体原因 结束诊断 2、c.a.r.l.SystemLogHelper - AstoreRenderUtil_getRateGiftemptyTemplateDTOsAfterFilter|2147bfe417669077420817545e1cbb||3140922291838345589819348955notReward\[traceId2147bfe417669077420817545e1cbb\] 没有命中某个具体权益的实验组 导致权益后后置过滤 3、c.a.r.u.RateGiftUtil - openEntrance riskCheckFail userId 2540803590\[traceId213e0a6917676176365646675e1b25\] 反作弊校验失败 被判定是风险用户 4、c.a.r.u.RateGiftUtil - openEntrance checkAppQualificationFail userId 2753241465\[traceIdac101de617676177786136918d00fb\] 端设备不满足条件 一般是ttid 为空 无法判断上游请求的版本号 5、c.a.r.u.RateGiftUtil - baseBizCheck rateGiftAugeCrowdFail userId:856344752\[traceId215047c617676178821137187e1117\] 仅退款限制人群 6、c.a.r.u.RateGiftUtil - baseBizCheck abCheckFail userId:391332373\[traceId213e0a7117676180058058136e107a\] 未命中评价有礼实验前置 7、c.a.r.u.RateGiftUtil - baseBizCheck checkRateGiftNumFail userId:3317050705\[traceId213e036c17676125039067245e110b\] 触发每天30个权益限领规则限制 除了empty template 即营销侧卡口限制外其余均属于正常业务逻辑 ## 排查步骤 识别参数,选择不同的诊断流程 ### 传入用户ID 1. 通过用户近期评价查询工具查询最近评价 2. 检查评价扩展字段判断发放情况 3. 提取订单ID按订单ID排查流程进行 ### 传入订单ID 严格按照以下顺序进行.找到原因可提前终止诊断流程 1、查看评价详情 检查扩展字段中评价有礼相关字段状态 pjyl 1 表示已发放 2、检查ttid taobao 或者淘特ltao 满足 天猫客户端tmal 不满足透出条件 3、错误码为rateGiftNotGift 使用星环运维日志查询工具BSPapp: rateplatform query: ${orderId} AND (preCheck OR template OR AstoreRenderUtil_getRateGift) 并输出完整的关键日志需包含traceId - 如果没有查询到日志 则提示未找到关键日志 建议联系值班同学处理 并终止流程 - 否则严格根据查询到的日志对照上述日志说明分析具体原因 - 如果未查询到有效日志则获取preCheck false的记录使用traceId再次检索 查询关键字 ${traceId} 再次进行分析 4、如果上述步骤仍然未确定具体的问题 则终止诊断 建议联系值班同学处理主 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 架构增加兜底路由将新能力导向新范式对原智能助手将提示词中的技能描述拆出迁移到独立文档即可完成改造。六、知识体系双层召回降低冗余与幻觉尽管“排查文档”有效提升了规划能力但在知识组织上仍有挑战6.1 问题1背景知识重复冗余字段定义、状态机、错误码等内容若分散在多个场景文档中极易造成不一致与维护困难。例如多个技能都依赖“评价详情接口”字段说明重复出现。6.2 问题2跨子域共性知识难以共享最直接的例子就是参数识别如“如何识别输入是订单 ID 还是用户 ID”这类通用问题在各子域中描述各异质量参差不利于共建复用。6.3 解决公共知识库 场景技能文档 双层召回类型内容特点公共知识库系统级常识、领域通用概念、字段说明、状态机、错误码等稳定、通用、一次定义多处复用场景技能文档具体问题的诊断流程、工具调用顺序、分支逻辑聚焦、精准、低冗余召回策略优先精确命中场景技能文档强约束辅助召回公共知识通过 tag 筛选 自主识别支持人工干预与权重调节。为便于管理我们正在建设简易后台系统支持专家编写与 AI 自动生成进行中相结合的混合模式。能力新建流程从完整的能力构建视角一次能力创建包含以下步骤虚线部分进行中七、质量评估与闭环让 Agent “可运营”一个智能 Agent 系统能否真正落地并持续创造价值不仅取决于其初始能力的构建更关键的是是否具备可衡量、可迭代、可持续进化的运营机制。为此我们建立了以“质量评估—反馈回流—知识优化”为核心的闭环体系确保系统不是一次性的自动化工具而是一个越用越聪明的“活体”。7.1 多维度评估框架从 F1 到 Q-score在传统信息检索领域我们常用 Recall召回率 和 Precision准确率来衡量系统的性能并通过 F1-Score 进行综合评价Recall衡量 Agent 是否覆盖了已知问题的知识面即“有没有答出来”Precision判断答案内容是否准确无误是否存在误导或幻觉F1-Score两者的调和平均用于整体能力打分。然而在实际研发支持场景中问答结果往往复杂多元一次响应可能涉及多个排查步骤、多种工具调用、多份参考文档。此时简单的“对/错”二值判断难以反映真实服务质量。例如结论正确但分析过程有瑕疵分析详尽但最终建议不完整知识库无答案Agent也识别出无答案这类回答属于正确召回但并没有解决实际问题回答虽未完全解决问题但已提供足够线索供工程师快速收口。因此我们引入了更加细粒度的质量评分机制——Q-scoreQuality Score采用 0–10 分制 对单次问答进行综合性打分。✅ 实践标准我们将 Q-score ≥ 7 定义为“有效回答”。这类回答即使不够完美也能显著降低人工介入成本具备实际生产可用性。该评分机制兼顾了实用性与容错性为后续自动化评估与迭代优化提供了坚实基础。7.2 自动化评估的价值聚焦坏样本驱动快速迭代初期阶段少量问答可通过人工标注完成质量评估。但随着系统上线运行月均交互量迅速突破千条纯人工打标已不可持续效率瓶颈凸显。我们的策略并非追求“全自动精准裁判”而是利用 AI 实现低投入、高回报的异常检测目标是快速识别出低质量问答坏样本而非为每一条输出打准十分。基于此我们构建了专用的 “评分 Agent”其核心逻辑如下输入历史问答记录 当前知识库状态处理结合少量高质量正例与典型负例few-shot learning辅以领域规则与扣分项模板输出生成 Q-score 及对应的扣分明细如“跳步执行”、“引用过时文档”、“未按手册顺序操作”等。这套机制的优势在于✅ 快速发现明显缺陷如幻觉、流程错误✅ 显著减少人工复核工作量仅需聚焦 ≤6 分的低分样本✅ 支持高频监控与趋势追踪及时感知能力退化。7.3 闭环机制从反馈到进化的正向循环为了实现“越用越准”的目标我们依托运营系统设计了一套完整的反馈回灌流程将每一次低质量暴露转化为系统升级的机会线上问答 → 评分 Agent 打分 → 聚焦低分样本≤6→ 人工复核 → 根因归因 ↓ 更新排查文档 / 补充公共知识 / 优化提示词 → 回灌至训练集这一闭环带来了三大收益知识沉淀加速每一次失败都成为新知识的来源。例如某次因日志格式变更导致诊断失败后我们在技能文档中补充了新版日志说明避免同类问题重复发生。模型行为收敛将典型错误样例持续注入评分 Agent 的 few-shot 示例库使其识别能力不断增强形成“防错—纠错—免疫”的正向演进。运营透明可控所有修改均有迹可循配合管理后台的版本对比与变更记录保障系统演进过程始终处于受控状态。 本质转变Agent 不再是静态部署的一次性产物而是一个依托数据反馈持续生长的“有机体”。八、实战成效多个领域落地验证已覆盖几大核心场景买家订单管理物流查询商家问题答疑评价场域支持 含问大家、买家秀、种草逆向流程诊断部分因数据链路同步导致的问题疑难杂症如今运营小二可一键重置研发零干预案例 1评价场域问诊系统的投放使用情况案例 2逆向领域问题排查案例3商家相关问题诊断案例4物流场景问诊案例5 订单相关问题诊断问诊Agent相关服务指标问诊小助手近几期的服务次数趋势研发月度工单受理数问答平均质量分AVG(Q-score)备注部分小助手评分低是因为样本太少稍微有一两个负面case 分数直线下降问答有效率AvailbleQ-score 7分召回率Recall 精准率PrecisionF1目前自动化链路构建中以1月份人工标注数据计算问诊助手召回率精准率F1买家订单管83.33%83.33%83.33%物流查询小助手100%75.00%85.71%商家问题答疑小助手80%75%77.42%评价小助手90%85%87.43%逆行者2.090%80%84.7%问诊Agent管理后台概览九、总结与展望边界与下一步本系统围绕“研发支持的问诊痛点”介绍了一种运维友好型问诊Agent构建范式及运营体系。通过将大量高频的重复解释规则、口径与问题排查追链路、查日志、对指标、做补偿工作自动化以标准化排查文档的形式快速接入已有的问诊Agent显著提升能力迭代效率使新同学也能快速上手。当前边界依赖专家经验高质量 Skill Doc 的撰写仍需领域专家投入长尾问题覆盖不足完全依赖模型推理的部分可靠性待提升知识固化 vs 模型泛化随着模型能力增强是否还需显式文档需持续观察下一步方向降低产出门槛探索基于链路标注、代码注释、接口文档 自动生成 Skill Doc 初稿人工审核后快速上线加速沉淀增强实时反馈能力当前纠偏依赖月度复盘 → 目标实现分钟级异常检测与自动告警探索“AI Native”知识组织方式若未来模型具备足够领域理解力能否将代码转化为“可执行语义指令”推动知识表达从“人类为主AI为辅”向“AI为主人类为辅”的演进。 “让新人也能像老将一样从容应对复杂问题这才是真正的工程提效。”最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容最后1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
收藏 | 新手程序员必看！阿里工程师如何用智能Agent搞定研发支持中的问诊痛点？
研发支持工作流中存在大量碎片化、重复性高且依赖个人经验的问题严重影响效率和质量。阿里工程师构建了可持续运营的智能Agent系统通过将高频问题抽象为“业务答疑”和“问题诊断”两类核心能力结合“排查文档技能化质量评分闭环”机制实现了解释与排查工作的前置自动化。该系统显著缩短了响应时间和解决时长提升了服务一致性并沉淀了可复用的经验资产有效解决了知识断层和人员流动带来的挑战。一、背景研发支持的真实工作流为什么痛对于开发者而言研发过程中最消耗精力的往往不是写代码而是被不断打断。一个典型的工作日清晨你正准备推进昨日因会议中断的开发任务打开钉钉却发现消息如潮水般涌来产品经理转发一段聊天记录询问某个功能入口的具体逻辑测试同事发来一条舆情链接请求协助判断是否属于异常行为一线客服催促处理未闭环的工单称商家已多次追问……为何研发的一天总是这样开始根本原因在于随着业务长期演进与人员流动加剧知识逐渐碎片化甚至出现断层。信息多散落在代码注释、历史讨论或个别专家脑中缺乏有效的组织沉淀机制。以工单处理为例系统运行多年却始终没有形成可复用的经验资产后续人员面对相似问题仍需从零排查。同时应用架构日益复杂一个功能常横跨多个服务及数十个二方包排查过程如同“长征”。这并非个例现象。根据内部调研数据后端开发人员约有 20% 的时间用于运维类事务如答疑、排障等大量碎片化投入严重影响了主职研发效率。因此我们要解决的不是一个具体的技术问题而是如何让研发支持变得可规模化、可复用、可运营二、问题抽象归纳将千奇百怪的问题收敛为两种能力形态尽管用户提问形式多样但从“研发支持”的本质出发可以将其归结为两大类典型任务2.1 形态一业务答疑解释型能力典型问题示例“为什么我看到 A用户却看到 B”“看板数据和明细对不上怎么办”“这个字段的状态到底代表什么”工程化定义输入是现象或疑问输出应包含规则/口径说明 查证路径 结论边界。常见成因包括AB 实验策略、人群圈选、灰度发布、权限控制、版本差异、统计口径延迟等。核心模式理解用户意图 → 从知识库召回相关文档 → 模型综合分析 → 输出结构化解答。这类场景相对成熟本文不做重点展开。2.2 形态二问题诊断诊断型能力典型问题示例“订单状态卡住了”“退款金额不一致 / 对账失败”“接口超时 / 单笔交易异常”工程化定义输入通常是携带具体 ID 的异常事实输出需包含证据链 定位步骤 可执行动作如补偿、恢复、升级。常见根因链路异常、依赖超时、补偿未触发、消息堆积、状态机阻塞、数据一致性问题等。核心模式分析意图 → 调用工具按 SOP 执行排查流程 → 综合结果生成结论 → 提供操作建议。相较于答疑类诊断类任务要求更高需要一定的决策能力和外部系统协同。2.3 为什么要进行这种抽象因为这两种场景对应的 Agent 构建范式存在差异。我们的目标不仅是“回答问题”更要稳定地替代工程师完成一段标准化的支持流程。当问题被抽象为上述两种能力形态后Agent 的输出即可统一规范为以下结构结论 分析解释规则/口径 排查计划可选 动作建议 文档引用这一结构化的输出为后续评估、运营与迭代提供了坚实基础。三、为什么值得做收益空间来自“重复 切换 不一致”研发支持的隐性成本远不止单次排查所花的时间主要体现在三个方面重复劳动高频问题反复出现造成资源浪费上下文切换成本在不同系统间跳转打断专注状态口径漂移不同人给出不同答案引发信任损耗。更重要的是它解决了因人员流动带来的知识断层风险实现了关键经验的有效沉淀支撑团队的可持续发展。四、系统总览一个“可运营”的问诊 Agent 需要什么我们的核心理念是Agent 建设必须具备可沉淀、可复用、可评估、易迭代的能力。基于此我们将系统划分为四个层次4.1四层架构设计层级职责接入层Channels工单、舆情平台、IM 群、合作方咨询入口。特别注意输入冗余与多模态内容如图片、视频的预处理以节约 token 成本。编排层Orchestration意图识别解释型 / 诊断型、路由至对应 Agent。实现层Agent包含 LLM、RAG、排查技能文档、公共知识库、上下文组装、工具调用策略等实际执行组件。运营评估层Ops Eval问答管理、跟进项跟踪、质量评分、报表监控、反馈闭环。架构示意4.2 设计原则小域专精避免大而全以交易后链路为例其涵盖订单正向、逆向退款、物流服务、商家支持、评价互动等多个子领域。各子域服务对象、问题特征差异较大耦合度低。因此我们放弃“统一多 Agent”模式转而采用按子域独立建设专用 Agent 的策略。优势如下✅ 最大程度复用已有技术支持文档与业务资料✅ 提升准确性避免 RAG 向量召回时上下文污染✅ 减少路由复杂度降低相互干扰提升开发效率。示例问诊小助手内部结构五、Agent 构建演进从“流程编码 提示词堆砌”到“技能化 原子化”5.1 平台选择我们选用内部 IdeaLab 平台进行搭建避免重复造轮子。该平台支持多种构建方式早期主要使用“智能助手”和“流程编排”两种模式。1初阶模式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如果信息来自多个请都列出。 你需要在回答中注明参考文档的来源以便用户可以进一步查看相关资料。 如果没有能回答问题的参考文档你需要直接回答“抱歉这个问题我无法回答请联系值班同学”。优点灵活性增强减少编码依赖。缺点多技能共存导致提示词膨胀“提示词爆炸”问题突出上下文混乱指令跟随能力下降运行稳定性差可维护性差新增技能即需修改主提示词。3Workflow 模式workflow模式虽更利于原子工具组合但每次新增技能均需重新编排开发调试成本并不低。举例线上workflow编排一角更重要的是它强依赖人工编排能享受到模型提升带来的红利有限也没能解决长久的可维护性问题。综上我们需要一种既能保证输出质量又能低成本快速迭代的新范式。5.2 新范式把排查能力封装成“可召回的排查文档SOP Doc”受 React 框架启发我们提出新思路以“场景排查文档”作为最小能力单元通过 RAG 精准召回动态注入上下文引导模型严格按手册执行自主对工具调用进行纠错。核心思想转变文档即技能闭包强约束减少幻觉与自由发挥新增能力 新增文档无需改动提示词或流程实现解耦维护对象下沉从“改代码/调 prompt”变为“写和维护排查手册”贴近一线。该模式与当前主流 Skills 架构理念相通——按需加载、技能固化提升 Agent 运行的可控性与稳定性。排查文档模板格式# 适用范围 简单描述适用场景 并给出指令使用示例 # 字段说明可选 给出场景依赖字段的说明 如pjyl 字段为1 表示权益已发放 # 核心日志格式可选 针对核心日志做些说明 避免模型胡诌 # 排查思路 描述具体的排查步骤 期间使用工具时给出使用的参数提示示例评价有礼问题诊断文档# 评价有礼问题诊断 ## 适用范围 命中关键字《评价有礼》后面是订单id 支持的参数类型订单ID 使用示例 评价有礼诊断4927155483760273522 解释通过订单进行评价有礼问题诊断 ## 字段说明 | 字段名 | 描述 | 备注 | | ------------------ | --------------------------------------------------------- | ---------------------------------------------------------- | | rewardType | 表单渲染时 评价有礼权益类型 | | | rewardStatus | 表单渲染时 是否命中评价有礼活动 | 不能用该字段判断评价有礼是否发放 | | rewardNumberFormat | 表单渲染时 权益金额 | | | pjyl | 权益是否发放 对应的枚举值br1: 已发放 | **该字段是判断评价最终是否发放权益的唯一标准** | | giftFail | 评价有礼未发放原因说明 具体的值参考RateGiftReasonEnum说明 | | | ttid | 客户端设备信息 | taobao或者淘特ltao 满足brtmall 或者不存在 不满足发放条件 | | 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 \[traceId2147811917670710230915204e119e\] 未查询到权益投放根本原因是营销侧有其他规则卡口 建议联系营销业务pd 绾wǎn吟 或者 技术: 朝暄 进行排查给出具体原因 结束诊断 2、c.a.r.l.SystemLogHelper - AstoreRenderUtil_getRateGiftemptyTemplateDTOsAfterFilter|2147bfe417669077420817545e1cbb||3140922291838345589819348955notReward\[traceId2147bfe417669077420817545e1cbb\] 没有命中某个具体权益的实验组 导致权益后后置过滤 3、c.a.r.u.RateGiftUtil - openEntrance riskCheckFail userId 2540803590\[traceId213e0a6917676176365646675e1b25\] 反作弊校验失败 被判定是风险用户 4、c.a.r.u.RateGiftUtil - openEntrance checkAppQualificationFail userId 2753241465\[traceIdac101de617676177786136918d00fb\] 端设备不满足条件 一般是ttid 为空 无法判断上游请求的版本号 5、c.a.r.u.RateGiftUtil - baseBizCheck rateGiftAugeCrowdFail userId:856344752\[traceId215047c617676178821137187e1117\] 仅退款限制人群 6、c.a.r.u.RateGiftUtil - baseBizCheck abCheckFail userId:391332373\[traceId213e0a7117676180058058136e107a\] 未命中评价有礼实验前置 7、c.a.r.u.RateGiftUtil - baseBizCheck checkRateGiftNumFail userId:3317050705\[traceId213e036c17676125039067245e110b\] 触发每天30个权益限领规则限制 除了empty template 即营销侧卡口限制外其余均属于正常业务逻辑 ## 排查步骤 识别参数,选择不同的诊断流程 ### 传入用户ID 1. 通过用户近期评价查询工具查询最近评价 2. 检查评价扩展字段判断发放情况 3. 提取订单ID按订单ID排查流程进行 ### 传入订单ID 严格按照以下顺序进行.找到原因可提前终止诊断流程 1、查看评价详情 检查扩展字段中评价有礼相关字段状态 pjyl 1 表示已发放 2、检查ttid taobao 或者淘特ltao 满足 天猫客户端tmal 不满足透出条件 3、错误码为rateGiftNotGift 使用星环运维日志查询工具BSPapp: rateplatform query: ${orderId} AND (preCheck OR template OR AstoreRenderUtil_getRateGift) 并输出完整的关键日志需包含traceId - 如果没有查询到日志 则提示未找到关键日志 建议联系值班同学处理 并终止流程 - 否则严格根据查询到的日志对照上述日志说明分析具体原因 - 如果未查询到有效日志则获取preCheck false的记录使用traceId再次检索 查询关键字 ${traceId} 再次进行分析 4、如果上述步骤仍然未确定具体的问题 则终止诊断 建议联系值班同学处理主 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 架构增加兜底路由将新能力导向新范式对原智能助手将提示词中的技能描述拆出迁移到独立文档即可完成改造。六、知识体系双层召回降低冗余与幻觉尽管“排查文档”有效提升了规划能力但在知识组织上仍有挑战6.1 问题1背景知识重复冗余字段定义、状态机、错误码等内容若分散在多个场景文档中极易造成不一致与维护困难。例如多个技能都依赖“评价详情接口”字段说明重复出现。6.2 问题2跨子域共性知识难以共享最直接的例子就是参数识别如“如何识别输入是订单 ID 还是用户 ID”这类通用问题在各子域中描述各异质量参差不利于共建复用。6.3 解决公共知识库 场景技能文档 双层召回类型内容特点公共知识库系统级常识、领域通用概念、字段说明、状态机、错误码等稳定、通用、一次定义多处复用场景技能文档具体问题的诊断流程、工具调用顺序、分支逻辑聚焦、精准、低冗余召回策略优先精确命中场景技能文档强约束辅助召回公共知识通过 tag 筛选 自主识别支持人工干预与权重调节。为便于管理我们正在建设简易后台系统支持专家编写与 AI 自动生成进行中相结合的混合模式。能力新建流程从完整的能力构建视角一次能力创建包含以下步骤虚线部分进行中七、质量评估与闭环让 Agent “可运营”一个智能 Agent 系统能否真正落地并持续创造价值不仅取决于其初始能力的构建更关键的是是否具备可衡量、可迭代、可持续进化的运营机制。为此我们建立了以“质量评估—反馈回流—知识优化”为核心的闭环体系确保系统不是一次性的自动化工具而是一个越用越聪明的“活体”。7.1 多维度评估框架从 F1 到 Q-score在传统信息检索领域我们常用 Recall召回率 和 Precision准确率来衡量系统的性能并通过 F1-Score 进行综合评价Recall衡量 Agent 是否覆盖了已知问题的知识面即“有没有答出来”Precision判断答案内容是否准确无误是否存在误导或幻觉F1-Score两者的调和平均用于整体能力打分。然而在实际研发支持场景中问答结果往往复杂多元一次响应可能涉及多个排查步骤、多种工具调用、多份参考文档。此时简单的“对/错”二值判断难以反映真实服务质量。例如结论正确但分析过程有瑕疵分析详尽但最终建议不完整知识库无答案Agent也识别出无答案这类回答属于正确召回但并没有解决实际问题回答虽未完全解决问题但已提供足够线索供工程师快速收口。因此我们引入了更加细粒度的质量评分机制——Q-scoreQuality Score采用 0–10 分制 对单次问答进行综合性打分。✅ 实践标准我们将 Q-score ≥ 7 定义为“有效回答”。这类回答即使不够完美也能显著降低人工介入成本具备实际生产可用性。该评分机制兼顾了实用性与容错性为后续自动化评估与迭代优化提供了坚实基础。7.2 自动化评估的价值聚焦坏样本驱动快速迭代初期阶段少量问答可通过人工标注完成质量评估。但随着系统上线运行月均交互量迅速突破千条纯人工打标已不可持续效率瓶颈凸显。我们的策略并非追求“全自动精准裁判”而是利用 AI 实现低投入、高回报的异常检测目标是快速识别出低质量问答坏样本而非为每一条输出打准十分。基于此我们构建了专用的 “评分 Agent”其核心逻辑如下输入历史问答记录 当前知识库状态处理结合少量高质量正例与典型负例few-shot learning辅以领域规则与扣分项模板输出生成 Q-score 及对应的扣分明细如“跳步执行”、“引用过时文档”、“未按手册顺序操作”等。这套机制的优势在于✅ 快速发现明显缺陷如幻觉、流程错误✅ 显著减少人工复核工作量仅需聚焦 ≤6 分的低分样本✅ 支持高频监控与趋势追踪及时感知能力退化。7.3 闭环机制从反馈到进化的正向循环为了实现“越用越准”的目标我们依托运营系统设计了一套完整的反馈回灌流程将每一次低质量暴露转化为系统升级的机会线上问答 → 评分 Agent 打分 → 聚焦低分样本≤6→ 人工复核 → 根因归因 ↓ 更新排查文档 / 补充公共知识 / 优化提示词 → 回灌至训练集这一闭环带来了三大收益知识沉淀加速每一次失败都成为新知识的来源。例如某次因日志格式变更导致诊断失败后我们在技能文档中补充了新版日志说明避免同类问题重复发生。模型行为收敛将典型错误样例持续注入评分 Agent 的 few-shot 示例库使其识别能力不断增强形成“防错—纠错—免疫”的正向演进。运营透明可控所有修改均有迹可循配合管理后台的版本对比与变更记录保障系统演进过程始终处于受控状态。 本质转变Agent 不再是静态部署的一次性产物而是一个依托数据反馈持续生长的“有机体”。八、实战成效多个领域落地验证已覆盖几大核心场景买家订单管理物流查询商家问题答疑评价场域支持 含问大家、买家秀、种草逆向流程诊断部分因数据链路同步导致的问题疑难杂症如今运营小二可一键重置研发零干预案例 1评价场域问诊系统的投放使用情况案例 2逆向领域问题排查案例3商家相关问题诊断案例4物流场景问诊案例5 订单相关问题诊断问诊Agent相关服务指标问诊小助手近几期的服务次数趋势研发月度工单受理数问答平均质量分AVG(Q-score)备注部分小助手评分低是因为样本太少稍微有一两个负面case 分数直线下降问答有效率AvailbleQ-score 7分召回率Recall 精准率PrecisionF1目前自动化链路构建中以1月份人工标注数据计算问诊助手召回率精准率F1买家订单管83.33%83.33%83.33%物流查询小助手100%75.00%85.71%商家问题答疑小助手80%75%77.42%评价小助手90%85%87.43%逆行者2.090%80%84.7%问诊Agent管理后台概览九、总结与展望边界与下一步本系统围绕“研发支持的问诊痛点”介绍了一种运维友好型问诊Agent构建范式及运营体系。通过将大量高频的重复解释规则、口径与问题排查追链路、查日志、对指标、做补偿工作自动化以标准化排查文档的形式快速接入已有的问诊Agent显著提升能力迭代效率使新同学也能快速上手。当前边界依赖专家经验高质量 Skill Doc 的撰写仍需领域专家投入长尾问题覆盖不足完全依赖模型推理的部分可靠性待提升知识固化 vs 模型泛化随着模型能力增强是否还需显式文档需持续观察下一步方向降低产出门槛探索基于链路标注、代码注释、接口文档 自动生成 Skill Doc 初稿人工审核后快速上线加速沉淀增强实时反馈能力当前纠偏依赖月度复盘 → 目标实现分钟级异常检测与自动告警探索“AI Native”知识组织方式若未来模型具备足够领域理解力能否将代码转化为“可执行语义指令”推动知识表达从“人类为主AI为辅”向“AI为主人类为辅”的演进。 “让新人也能像老将一样从容应对复杂问题这才是真正的工程提效。”最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容最后1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
