从“救火”到“筑基”：Grab 如何用多智能体系统重塑数据工程支持

在大型科技公司中，数据平台工程师常常陷入一种困境：一边是不断增长的业务需求，另一边是源源不断的运维支持请求。当故障排查、SQL 调试和临时数据查询占据了大量工作时间，真正推动系统演进的高价值开发任务反而被挤压。Grab 分析数据仓库（ADW）团队正面临这一典型挑战——他们服务于超过一千名内部用户，管理着逾一万五千张数据表，是支撑公司核心分析能力的关键基础设施。

然而，随着平台使用量的激增，工程团队发现，大量精力被重复性、低复杂度的支持任务消耗。这不仅降低了整体效率，也阻碍了团队向更高层次的系统架构优化迈进。为此，Grab ADW 团队设计并部署了一套基于多智能体架构的 AI 支持系统，旨在将工程师从“救火队员”的角色中解放出来，转向更具战略意义的平台建设工作。

多智能体架构：分工协作的“虚拟工程团队”

这套系统的核心是一个精心设计的多智能体工作流，其架构灵感来源于现实中的工程协作模式。系统将接收到的支持请求划分为两大核心路径：调查工作流与增强工作流。

调查工作流专注于问题诊断，由专门的智能体负责执行查询分析、日志检索、元数据查询以及问题归因。例如，当用户报告某张表查询变慢时，系统会自动调用日志检索工具定位异常时间点，结合执行计划分析性能瓶颈，并汇总成结构化报告。

增强工作流则更进一步，专注于生成可执行的操作输出，如修复 SQL 语句、生成补丁代码，甚至创建待审查的合并请求（Pull Request）。这种“诊断-执行”分离的设计，显著降低了单个智能体的推理复杂度，也提升了系统在复杂场景下的稳定性。

整个流程由基于 LangGraph 的工作流引擎驱动，配合 FastAPI 服务实现智能体间的路由调度、状态管理与工具调用。每个智能体职责明确、边界清晰，避免了在多任务处理中出现“越界”或“误判”的情况。

工具整合与上下文管理：让智能体“看得清、做得准”

在初期探索中，团队曾接入超过 30 个内部工具，涵盖数据访问、日志系统、代码仓库等。然而，工具数量过多反而带来了选择混乱和维护成本上升的问题。为此，团队进行了系统性整合，构建了一个统一、受控的工具层，包括安全的 SQL 执行接口、元数据查询服务、日志检索 API 以及与 Git 工作流的深度集成。

这一精简后的工具生态不仅提升了系统的可维护性，也大幅降低了智能体在决策时的不确定性。更重要的是，所有工具调用均受到严格的安全治理：SQL 执行前需通过验证层过滤，敏感数据访问设有自动检测与脱敏机制，确保自动化流程不会引发数据泄露风险。

另一个关键挑战是上下文管理。多步骤推理过程中，智能体需要在多次交互中保持状态连贯，同时受限于大模型的词元长度。为此，系统引入了结构化上下文压缩与选择性检索策略——只保留与当前任务最相关的信息片段，避免信息过载。例如，在分析一个历史查询性能问题时，系统会自动提取关键执行计划片段和错误日志，而非加载全部历史数据。

从自动化到人机协同：工程监督下的智能演进

尽管系统具备高度自动化能力，但 Grab 团队始终坚持“人在环路”（Human-in-the-loop）原则。所有由增强工作流生成的代码变更或 SQL 修改，在部署前必须经过人工审核。这不仅保障了系统输出的安全性与合规性，也保留了工程师对关键决策的最终控制权。

这种设计体现了现代 AI 系统在工程实践中的成熟思路：自动化不是取代人力，而是重新分配人力。通过将重复性任务交给智能体处理，工程师得以将更多时间投入平台架构优化、性能调优和长期技术规划。

据 Grab 分析部门负责人 Sneh Agrawal 透露，该系统每月可节省数百个工程工时，使团队逐步从被动响应的“救火”模式，转向主动构建的“筑基”模式。虽然官方尚未公布更详细的性能指标，但这一转变本身已释放出显著的组织效能提升信号。

未来，随着智能体能力的持续进化，此类系统有望进一步扩展至更复杂的场景，如自动容量规划、异常预测与自愈机制。而 Grab 的实践，为大规模工程支撑场景下的多智能体系统设计提供了宝贵的参考范式。

标签： 多智能体系统 数据工程自动化 LangGraph 人机协同 AI运维