在互联网企业的日常研发运维工作中，线上故障排查、跨团队技术答疑是高频且消耗人力的核心场景。传统工单模式流程僵化、信息零散，工程师频繁切换多系统查阅监控、源码、工单与文档，大量时间耗费在信息收集、问题分流、基础排查等重复工作上，长尾故障处置效率低、极度依赖资深工程师经验。

如何依托 AI 大模型与智能体技术，改造传统工程支撑体系，实现故障提报、信息归集、自动排查、工单流转的全流程智能化升级？全球在线旅游平台 Agoda 给出了一套可落地、可复用的完整解决方案。本文将拆解 Agoda 从标准化工单工具，到对话式 AI 交互，再到领域智能体自治排查的迭代全过程，分享其技术落地细节、真实业务数据、避坑经验与评测体系搭建思路，为企业智能化运维升级提供参考。

以下为该团队的实践分享：

在安可达（Agoda），我们使用 Slack 作为跨团队沟通协作工具。工程师遇到内部服务或平台相关问题寻求协助时，也常会在 Slack 发起咨询。问题对话虽然始于 Slack，但排查故障所需的各类资料往往分散在其他系统中。

举个例子，有工程师发来这样一条消息：“我的应用宕机了，无法连接数据库，应该从哪些方面排查？”

即便看上去简单的问题，背后也可能存在多种诱因：最近一次部署变更、集群异常、下游服务不可用等等。响应问题的工程师往往需要查看监控仪表盘、链路追踪数据、源代码、工单、技术文档，以及 Slack 历史对话，才能逐步缩小故障范围。

正式排查之前，团队通常先要收集基础背景信息，并确定该请求流转至哪个负责团队。我们希望简化这一流程，同时完全沿用工程师已经在使用的工具与工作流。

下文介绍我们应对这项挑战的思路、工程技术支持工作流的演进历程，以及落地过程中积累的经验。

OpsBot：将服务台工作流接入 Slack

项目的第一步是打造 OpsBot，这是原生运行在 Slack 内、面向工程团队的服务台工具。它的作用类似 Zendesk，但所有求助请求、沟通对话、工单转交都保留在 Slack 环境内完成。

借助 OpsBot，各团队可以标准化接收求助工单、采集关键信息、自动分派工单，必要时自动创建正式工单。每个业务团队都能自定义所属业务域的工作流程，工程师无需切换至其他客服支撑系统。

工程师只需在 Slack 中输入 OpsBot 指令即可发起求助。频道内预先配置的 YAML 规则会匹配对应的支持流程，并弹出信息填报表单。工程师选择问题分类、填写相关信息后，OpsBot 就会把请求分派给责任团队，配置好自动化脚本时，还可以自动执行 Python 自动化任务。

这套方案让处理流程更加规范，但表单模式有一个局限：它默认工程师清楚哪些技术信息是排查必需的。一旦发生线上故障，求助人手里可能只有报错信息、Grafana 监控链接或者一条 Slack 历史对话，并不清楚需要提供哪个集群、容器 Pod、监控面板或者下游服务的相关信息。

于是新的难题摆在面前：既要保留 OpsBot 带来的流程规范性，又要支持工程师仅凭手头已有的零散信息发起求助。

OpsBot 升级：从表单填报转向自然语言对话式交互

如果求助者明确知道需要提供哪些资料，表单模式会十分高效；但当求助人信息不全时，大语言模型就提供了另一种采集上下文信息的方案。升级后的 OpsBot AI 支持用户用自然语言描述问题，直接上传手头已有的各类线索材料发起求助。

OpsBot AI 会结合初始提问、Slack 上下文对话、用户附上的各类链接综合理解诉求。如果缺少必要排查信息，它会精准追问缺失内容。原有表单定义、工单分派规则、建单逻辑、问题升级机制全部保留，只是求助人员不必在提交请求前填完所有表单字段。

YAML 配置依旧用来定义问题分类、必填信息、分派策略、工单规则以及可选的 Python 自动化任务。用户用自然语言描述问题后，OpsBot AI 自动解析诉求、补齐必要上下文、分派至对应责任团队并生成工单。

这改变了问题处理的起点：求助人只需要描述看到的故障现象，而对接处理的工程师收到工单时，大部分排查所需的上下文信息已经自动收集完毕。

在支持工作流中接入领域智能体（Domain Agents）

简化求助提报只解决了一半问题。工单虽然可以精准流转到对应团队，附带信息也更加完善，但负责处置的工程师依然需要从零开始开展故障排查。

为此，我们在工作流里新增了领域智能体能力。OpsBot AI 会把 Slack 对话内容发送给该业务流程绑定的领域智能体。智能体严格遵循团队制定的排查规范，调用经过授权的工具，自动补充更多故障上下文。

针对服务宕机类问题，智能体可以调取 OpenTelemetry 指标与链路追踪数据、检索历史同类故障工单、查阅技术文档，或是查看源码里相关依赖调用链路。如果检测到已有正在处置、影响该服务的故障事件，它可以直接引导求助人查看事件更新。遇到复杂度更高的场景，智能体会给值班工程师输出一份汇总报告，包含已核查项、发现结果以及后续排查方向。

领域智能体独立部署运行在安可达自研的智能体平台（Agoda’s Agents Platform）之上。如果工单依旧需要人工介入处置，OpsBot AI 原有工单流转与升级机制依旧正常可用。

由各业务域团队自主搭建专属智能体

安可达内部早已搭建智能体平台，这也让 OpsBot AI 能够将每一条技术支持流程和对应的领域智能体打通关联。

依托该平台，各个业务团队可以自主创建、运维专属智能体：选择底层大模型、编写领域业务指令、配置自动化排查能力、对接已审批工具与模型上下文协议（MCP）服务端，并通过兼容 Open Responses 标准的 API 对外提供能力。业务域归属团队全权决定智能体的运行逻辑。

OpsBot AI 对接智能体平台，平台上托管着 BI 商业智能、基础设施、DevOps 等多个业务线的智能体。平台将智能体能力与经过审批的 MCP 集成能力结合起来。

BI 团队熟悉自身数据模型与高频咨询问题；基础设施团队清楚哪些运维指标需要重点关注，以及何时启动问题升级；平台团队熟知服务依赖关系与典型故障模式。各团队都可以把沉淀的业务经验转化为智能体指令与可复用的排查规范。

根据业务场景不同，智能体可对接多款审批通过的工具，包括 Sourcegraph 代码检索、Atlassian 工单系统、Grafana 监控、Tempo 链路追踪、Pyroscope 性能剖析、Glean 知识库检索以及历史工单检索等。

排查能力（Skills）本身并不存储业务领域知识，它的作用是引导智能体完成排查流程：告知智能体需要查阅哪些资料、执行哪些校验、什么时候转交人工工程师处理。部分团队还搭建了自动化流水线，保障这些排查能力能够跟随业务工作流迭代持续更新。

智能体平台还会留存每一次运行的全链路追踪记录。当 OpsBot AI 在 Slack 返回分析结论时，拥有权限的用户可以通过追踪链接查看智能体调用过的全部工具。方便业务负责人复盘智能体分析了哪些信息、遗漏了哪些关键点，迭代优化下一版智能体配置。

落地成果：BI 产品团队先行验证，效果显著

商业智能产品部（BI Product）率先在营销、客户互动组（CEG）、供应链三大业务板块上线 OpsBot AI 支持智能体。每个板块都配置独立智能体，拥有专属领域指令、排查能力、工具权限与工单支撑流程。

三大板块智能体一共封装了 134 项领域排查能力：营销板块 50 项、客户互动组 43 项、供应链 41 项。这些能力用于标准化高频故障排查，保证智能体可以稳定调用 Confluence 文档库、OpenMetadata 元数据平台以及各类数据工具开展分析。

统计周期2026年6月1日至 8 月 24 日，BI 产品四大核心技术支持渠道累计产生 556 条真实求助会话，其中 402 条会话有智能体参与处理，覆盖率达 72.3%。这里的参与定义为：智能体在会话中至少输出一次回复；覆盖率代表智能体参与处置的工单占全部真实求助会话的比例。求助方与处置工程师都可以对智能体给出的回复打分。在收到有效反馈的 286 条会话里，241 条评价为非常有用或部分有用，好评率 84.3%。

其中 87 条求助会话，智能体直接给出最终答复：独立完成全部排查工作，问题无需人工分析即可闭环，运维工程师仅需要关闭工单。

营销板块的运维人力投入也得到明显优化。智能体上线后，工单总量上涨 19%，但运维人员平均处置耗时下降 15%，由原来 45.3 分钟缩短至 38.5 分钟。针对耗时较长的复杂排查场景，P90 分位处置时长从 120 分钟降到 60 分钟，中位数耗时维持在 20 分钟不变。

效能提升主要体现在长尾复杂故障场景：这类高耗时排查，现在消耗人工工程师的时间明显减少。以上均来自项目灰度落地阶段的观测数据，不能证明效能提升完全由智能体带来，也不代表所有求助工单都可以实现自动化闭环。

落地过程中的经验总结

• 将隐性经验沉淀为共享知识库

搭建技术支持智能体，倒逼各团队把以往只保存在资深工程师脑中的经验梳理归档。故障排查流程因此更容易复现，降低团队对少数领域专家的依赖。

• 排查能力是操作流程，而非知识库

一项排查能力本质是一套操作步骤，并不是业务知识本身。业务知识依旧保存在 Confluence、GitLab、OpenMetadata、安可达数据平台等各类资料源当中。

排查能力同时承担工单分流逻辑：政策类咨询应当优先检索合规文档，而不是去检索代码与日志。绝大多数业务团队都会基于自身业务域维护工单分流逻辑。

前面提到的 BI 产品团队还搭建自动化流水线，定期复盘用户负面反馈，通过合并请求（MR）自动生成排查能力优化建议，所有修改都需要人工审核之后才会生效。

• 重视错误案例分析

调试优化智能体，离不开完善的可观测能力与大量时间投入。运行追踪记录能够还原智能体分析路径、工具调用记录以及排查失败节点。缺少追踪日志，很难解释为什么智能体给出无效回复。

错误案例分析也帮我们发现智能体的各类局限性：当 Slack 服务不可用时，我们接入 FeedMCP 监控 Slack 以及其他 SaaS 服务状态；当 Tempo 查询返回 12MB 超大结果超出智能体上下文窗口时，我们开始试验工具侧摘要压缩、代码执行模式、子智能体方案。

人工复盘故障案例只能单点优化，很难规模化迭代。排查能力或者大模型版本改动，有可能优化一类问题的处理效果，却造成其他场景异常。为此我们自研 Agent Eval 评测体系，把复盘沉淀的经验转化为可重复运行的自动化校验用例。

Agent Eval：构建闭环评测体系

各团队迭代智能体时，又遇到新挑战：如何验证版本优化确实提升效果，又不会造成其他场景能力退化？底层模型、排查能力或者工具集成的更新，有可能优化某一类问题答复质量，却影响其他场景的分析逻辑。

针对这个痛点，我们推出尚处于测试阶段的 Agent Eval 评测平台。OpsBot AI 会把已完成的技术支持会话以及用户有效性评价上报至数据平台。业务负责人筛选真实问答案例，构建评测数据集。用户反馈用于辅助数据集筛选，但是哪些案例纳入数据集、判定优质回复的标准，都由业务域负责人定义。

线上工作流中，OpsBot AI 通过智能体平台调用领域智能体，并将结果返回 Slack。整条交互记录与有效性标签存入数据平台。业务负责人就可以基于真实生产数据持续维护评测数据集。

Agent Eval 会回放数据集内历史案例，在智能体平台运行并记录输出结果与工具调用行为。针对每一条测试案例，团队预先定义校验标准，可以校验回复内容准确性、是否调用指定工具、工具入参是否合规。用同一套评测数据集同时跑当前线上版本与待上线新版本，就能直观看到改动对智能体各项能力带来的影响。

我们还在研发影子评测能力：同一条线上请求并行发送给两个版本智能体。线上正式版本负责回复用户，候选新版本后台同步运算评估，输出结果不会对外展示。团队可以基于真实业务流量，在新版本上线前完成效果验证。

未来规划

依托 AI 优化工程技术支持体系，我们已经投入多年研发，项目依旧持续迭代。AI 并没有完全替代整套技术支持体系，但从目前数据来看，这套方案确实同时改善了求助方与运维工程师双方体验。

下一阶段核心目标是实现体系持续自主优化：各业务团队搭建流水线自动评估智能体表现、维护排查能力库，所有变更上线前保留人工审核环节。以此逐步搭建可自我迭代的智能体调度框架，同时始终由业务域团队掌控智能体业务逻辑。

当故障问题需要人为判断、权责认定或者深度根因分析时，人工技术支持依旧不可替代。我们的核心目标，是把工程师从大量重复性排查工作中解放出来，让工程师可以把更多精力投入真正需要人工深度介入的疑难问题。

文章首发于 TesterHome 社区微信公众号：https://mp.weixin.qq.com/s/naKo449CCULZWLULmuGq4A