大数据技术专家是如何练成的：大数据助手 Agent Team 实践

原创 爱奇艺大数据团队 2026-09-10 12:00 北京

面对跨计算、存储、调度和平台的复杂问题，我们通过 Agent Team 让多个领域智能体分工协作，探索更及时、更高效的大数据服务支持方式。

爱奇艺大数据体系涉及 20 多个服务及相关开发分析平台，日常的使用咨询和问题排查比较多，占用大数据团队大量人力。例如，用户常问的“这个 Spark 任务为什么失败了”“这个 Flink 作业为什么重启了”“StarRocks 查询为什么变慢”，运维人员需要读对话上下文、查询平台数据、检索日志和告警、分析指标，再结合历史处理经验，最后才能总结出问题原因。更复杂的是，问题出现在哪一层，并不代表根因就在哪一层：一个计算任务失败，可能与任务调度、数据存储、网络环境或下游系统有关，需要多个技术领域共同对齐时间线和证据，处理周期也会随之变长。

这些问题的排查有一套常用流程和工具，我们曾将其固化为基于规则的自动化工作流，但真实故障现场往往信息不完整，涉及多个服务，排查路径还需要根据中间结果不断调整，预设规则难以完全覆盖。AI Agent 适合处理这类任务：它能够围绕排障目标分析当前线索，自主选择和组合工具，并根据执行结果修正判断、推进后续排查。因此，我们设计了“大数据助手”，将不同领域的服务接口、自动化工具，以及分散在文档和专家经验中的知识沉淀为可复用能力，再由多个领域 Agent 分工完成跨服务问题的联合排查。

我们的目标不是用 AI 替代技术专家，而是让常规信息收集、证据关联和初步判断更自动化，使用户更快获得响应，也让服务负责人把精力集中在真正需要人工决策的环节。

大数据助手跨领域协同诊断能力示意

大数据助手是一个面向大数据服务综合场景的智能助手系统，采用由一个指挥者 (Coordinator) 和多个技术专家 (Service Agent) 组成的 Agent Team 架构，支持以团队协作方式来解决跨多个服务的综合性问题。

当前系统已经覆盖大数据领域主流服务 Agent：

• 调度平台 Agent：支持工作流查询、任务诊断和服务接口调用

• 批计算 Agent：支持 Spark 应用诊断、YARN 日志分析和告警关联

• 实时计算 Agent：支持 Flink 作业诊断，包括运行失败、处理延迟等场景

• 机器学习 Agent：支持基于知识库的服务问答和训练任务定位

• 数据湖 Agent：支持数据湖平台知识查询、服务状态查询和表相关问题分析

• 数据分析 Agent：支持StarRocks库表信息查询、读写异常诊断和集群健康检查

大数据体系的其他 Agent 还在陆续接入中。

它不是把所有能力简单塞进一个全能 Agent。不同领域的 Service Agent 更像技术团队中的专家成员：各自维护专业知识和工具边界，需要时围绕同一个问题协同工作。

举个例子，一个 Flink 任务将数据写入 StarRocks，最近经常失败。用户提问后，大数据助手的协作流程是：

1.Coordinator（团队调度者）先将问题交给Flink Agent；

2.Flink Agent 从日志中确认异常集中在下游写入阶段，并提取超时证据；

3.Coordinator 将问题转交给StarRocks Agent，同时携带待核对的时间窗口和节点线索；

4.StarRocks Agent 对齐事务与资源状态，确认写入请求积压、节点响应变慢；

5.Coordinator 合并两侧证据，向用户说明根因、影响范围和下一步处理建议。

跨服务协同排障示意案例

大数据助手经历了从 Workflow 到单 Agent，再到 Agent Team 的逐步升级。

第一阶段：具备 AI 能力的 Workflow 

在早期阶段，受限于模型推理和工具调用的稳定性，大数据助手主要通过 Workflow 实现智能巡检等需求，并在部分处理节点引入大语言模型（LLM），使流程具备比传统自动化 Workflow 更强的判断能力。我们上线了计算任务智能分析、自动巡检，为 1500+ 关键计算任务提供修复和改进措施。链路巡检日报还帮助内容热度、效果广告、会员云包场、直播电商、CDN 点直播实时统计等业务的 90+ 条关键链路识别隐患，并及时通知处理。

这套流程适合单一服务的知识问答、巡检等较简单场景。例如，每小时进行异常巡查、汇总异常情况，需要人工介入时通知运维人员，缓解了过去告警轰炸的痛点。但是要解决的问题变成多服务联合排障、日志指标多维分析、多轮追问时，Workflow 就力不从心了，整个 Workflow 的节点数量膨胀到 50 多个，灵活度越来越低，难以持续维护迭代。

第二阶段：基于 MCP 的 Agent

为了支持异常诊断这类更复杂的场景，我们随后基于飞书的低代码智能体平台 Aily 构建了单 Agent。主流程比较简洁：接收对话后进入推理循环（reasoning loop），根据中间结果持续选择工具，最后组织回复。服务信息查询和诊断能力主要通过 MCP 接入；MCP 解决的是智能体与外部工具、数据源之间的标准化连接问题。

这套架构支撑了几个月，较好满足了单服务异常诊断、知识问答等场景。随着使用深入，新的瓶颈逐渐出现：工具调用和上下文管理对我们来说仍是黑盒，难以针对真实问题深入调优；图形化开发模式也不利于复用代码工程中的测试、版本管理和自动化能力。

第三阶段：基于 Skill 的 Agent Team

随着 Skill 的流行，Agent 扩展业务能力变得很简单且规范。模型 + Harness 构建 Agent 核心流程，再用 Skill 实现业务能力，这套架构具备良好的可扩展性，也给越来越强的大模型极大的发挥空间。因此，我们把 Agent Runtime 从飞书 Aily 切换到 LangGraph，并从单 Agent 架构升级到 Agent Team 模式。对接的服务也从单个扩展到多个。通过实现一套 Agent Team 流程，让不同服务能力可以按职责独立扩展，并在统一团队协议下协作。

当前的大数据助手采用分层架构，核心思想是：入口统一、编排统一、服务能力分治。

• 入口层：负责接收来自本地命令行、Web 或即时通讯等渠道的请求，只处理协议适配和展示，不承担业务逻辑。

• 调度层：由 Coordinator（团队调度者）理解整体目标、拆解任务，并指派给具体的 Service Agent。

• Runtime 层：承载 Service Agent 的多步执行流程和运行状态，使其能够连续调用工具完成任务。

• 能力层：由各领域 Agent 的 Skill 和共享 Tool 组成，例如执行命令、访问服务 API、查询服务知识库。

• Harness 层：治理运行时上下文、文件读写、管控工具调用、执行预算、异常处理与重试。

1、Agent Team协作流程

从 Agent Team 视角，目前有如下角色：

团队黑板是 Agent Team 的共享协作空间，也是一套结构化交接契约。Coordinator 在黑板中写入待办任务和必要上下文；Service Agent 领取任务、持续更新进展，并在完成后写入结论和证据；Dialoguer 最后读取已经收敛的信息，向用户给出答复。通过把“谁在处理什么、处理到哪一步、依据是什么、下一步由谁接”记录下来，多个 Agent 可以共享必要事实，同时将各自的详细执行历史留在独立工作区，避免上下文互相污染。

2、成员 Agent “边执行，边讨论”

当一个问题可以拆成相互独立的领域任务时，Coordinator 会同时把子任务派发给多个 Service Agent，让它们并行执行，提升效率。各 Agent 在独立工作区执行，避免工具输出和推理过程互相污染；阶段性线索和证据持续写入团队黑板，其他 Agent 会在后续推理时读取新增信息并调整方向。因此，协作不是等所有任务结束后再做结果拼接，而是边执行、边交换证据、边校准判断。用户在执行过程中补充的信息也会进入团队黑板，由 Coordinator 判断需要影响哪些 Agent。

举个例子，这个案例是用户询问某iceberg表数据延迟是否已恢复。Flink Agent核对 Flink 作业日志和 Checkpoint 状态，同时Iceberg Agent检查表文件，元数据信息。两者实现边执行，边讨论。

3、可定制、可扩展的 Service Agent 实现

大数据服务的能力边界和工作方式差异较大，因此大数据助手没有把所有能力塞进一个全能 Agent。每个服务作为独立服务包接入，并约定统一接入规范，包括：

• Prompt：说明 Agent 的职责、边界

• Service Skills：服务私有的Skills

• 服务知识库：按需读取服务手册

• 独立工作区：执行本地命令，读写当前任务所需的文件

大数据助手启动时会自动发现已接入的服务包，并为每个 Service Agent 加载相应的prompt、领域 Skills 和知识库。

项目采用约定优于配置的方式。Agent开发者可以把重心放在开发 Skill 上。框架层统一负责用户沟通等通用流程，以及模型调用、命令执行、文件读写、异常处理等公共设施。另外，底层通用 Tool 和 Skill 由所有 Agent 共享，不需要每个服务重复开发，例如命令执行、HTTP 请求、文件处理和基础信息查询。

实践中，各服务Agent接入成本很低，数小时即可构建可运行的Service Agent。

多 Agent 系统的可用性，很大程度取决于 Harness。这里的 Harness 不是某个单独模型，而是一套围绕模型构建的运行控制层，负责上下文、工具、执行过程和观测。下面分享一些直接影响系统效果的设计。

1、事实源分层

不同层级的事实需要分开保存。混在一起会让模型难以判断哪些是用户原始信息、哪些只是某个 Agent 的中间推测。我们将事实分为三层：外部真实对话、团队内部的任务与证据、各领域 Agent 的私有工作区。不同角色只读取完成当前职责所需的部分，既避免内部执行细节污染用户意图，也便于分别治理上下文。

2、事实源多读少写

公共事实的生成和修改必须受到控制。各个 Agent 不直接随意改写共享上下文；每次调用模型时，由对应角色从真实对话、团队黑板和工作区中组装本次所需的临时视图。这个视图只服务于当前模型调用，不写入持久化会话状态，也不会自动变成长期事实。

3、冷热上下文分层治理

连续排障可能经历上百轮工具调用，上下文会迅速膨胀，模型的注意力也会被稀释；但如果每轮都从零开始，又会丢失必要的过程信息。为此，我们把上下文分为冷热两层：当前执行过程作为热上下文，直接保留在 Service Agent 中；更早的执行历史作为冷上下文转存到文件系统，并提供按需查询能力。这样既能保持任务连续性，也避免旧过程长期占用模型上下文。相比到达阈值后直接压缩整段文本，这种方式能够更完整地保留原始证据。

4、严格控制工具输出

工具输出往往是上下文占用的大头。一次范围过大的日志或 API 查询，就可能挤掉当前任务真正重要的信息。框架会拦截工具结果：当内容超过阈值时，将完整结果转存到本地文件，只向模型返回摘要预览、文件位置和必要元数据；需要继续分析时，模型再按需读取相关片段。这样既限制单次输出的影响，又保留完整原始证据。

 5、工具延迟加载

随着工具数量增加，工具自身的使用说明和参数结构也会占用大量上下文。框架因此采用延迟加载机制：低频工具默认只暴露名称和简短描述，模型确认需要后，再加载完整用法和参数约束。常规路径不必反复携带所有工具说明，工具选择也更加聚焦。

尽管有延迟加载机制，Tool 数量仍不宜过多。每增加一个 Tool 都可能会降低模型调用工具的准确度，并增加 token 成本。我们也经历了增加 Tool，再到减少 Tool 的过程。

  6、通过结构化契约提高 API 调用可靠性

在服务对接过程中，我们遇到一个实际问题：每个服务通常涉及大量 API。即使文档足够完善，模型仍可能拼错 URL、遗漏参数，或者为了查找调用方法而占用大量上下文。为此，我们设计了一套 Service API 调用流程，让结构化契约和模型各自负责更适合的部分：

1.在 API 目录中声明允许调用的接口，并为每项操作分配唯一标识；

2.领域 Skill 只引用需要使用的操作标识，不携带整份 API 文档；

3.Agent 在调用前按需获取该操作的参数说明和约束；

4.大模型根据当前任务生成业务参数；

5.框架负责拼接请求、校验参数并调用目标服务。

通过这个流程，Skill 可以专注于业务步骤，模型只需要判断应执行哪项操作并生成业务参数，具体请求由框架按照统一契约完成。这样既减少了模型在大量 API 文档中查找和试错，也降低了上下文成本，提升了调用成功率。

7、控制执行进度

Agent 在持续执行过程中有时会在局部方向上投入过久，甚至偏离最初目标，用户看到的现象就是任务像“卡住了”。我们通过定期复盘和执行预算两类机制控制进度。

首先是定期汇报。Agent 每执行固定轮数会总结当前进展和剩余任务，借此重新检查方向，避免长时间埋头在一个局部问题中。

其次是模型调用预算。当调用轮数接近阈值时，框架会提醒 Agent 收敛并返回阶段性结果；达到阈值后强制结束本轮，作为避免无限执行的兜底。

8、基于 Langfuse Trace 的可观测与质量分析

仅靠传统日志很难还原 Agent 为什么做出某个判断。我们引入 Langfuse 记录从用户问题到最终回复的一次完整 Trace，串联角色分派、模型调用、工具执行、异常、耗时和结果，使每一步都有迹可循。在此基础上，系统从正确性、有用性和依从性等维度评估回答质量，并按时间汇总到看板中，用于观察质量趋势、定位异常波动。发现低质量回答后，还可以回到具体 Trace，判断问题发生在任务理解、服务路由、工具调用还是结论收敛阶段，并据此验证后续优化是否有效。

大数据助手目前提供了飞书聊天机器人和大数据平台 web 机器人两种交互方式。不同入口共用同一套 Agent Team 和领域能力，入口只负责承接上下文与展示结果，后续流程是通用的。

1、飞书消息私聊

支持连续对话。近期消息历史会自动读取，较早的消息会按策略遗忘。支持主动切换话题。

在飞书群中@大数据助手，它会自动读取历史消息，了解上下文，再回答。同样支持连续对话，目前后续对话需要继续@大数据助手，才会回复。

在大数据平台使用过程中遇到问题，可直接点击右下角 AI 悬浮球，唤醒大数据助手进行对话。不用跳转到飞书中，非常方便。首次开启对话，会自动携带当前页面信息作为上下文。

大数据助手已经成为大数据团队中不可或缺的一名智能伙伴，让复杂的大数据支持工作，从“找人、找文档、找平台”，逐步变成“描述问题，助手协同处理”，降低了用户寻找服务支持的成本，减少了服务负责人运维成本。

当前基于 Agent Team 架构的大数据助手已经运行一段时间，真实用户案例验证了方案的可行性。围绕并行协作、运行观测和质量分析等方向，系统也在持续完善。

1.质量评估和趋势分析已经建立，但从问题识别、原因归类到优化验证的闭环仍需继续完善。

2.受权限和风险管控限制，部分异常排查无法直接登录集群完成最终验证，仍需要服务负责人参与闭环。

3.用户侧任务管理能力仍较基础，定时触发、多问题管理和执行过程中的交互引导还有提升空间。

后续将围绕以下目标继续加强：

1.扩大服务覆盖范围，让更多大数据平台和领域能力接入，进一步发挥跨服务协同的优势。

2.完善质量优化闭环，让低质量案例能够被持续发现、归因、修正并通过回归验证。

3.完善任务管理和过程交互能力，支持定时触发、多问题管理以及执行过程中的及时补充和引导。

海外Agent实践：让问题直达源码，助力团队提效！

爱奇艺AI驱动漏洞闭环治理：让安全发现更智能、修复闭环更高效

爱奇艺大数据混合云存储

纳逗Pro全链路赋能、专项免费算力支持！爱奇艺AI影视创作营第二期来了

AI 时代的质量门禁左移：Agentic Quality Engineering 架构与落地模板

跳转微信打开