How Grab is Using AI Agents to Boost Team Productivity¶

📊 Level ⭐⭐⭐⭐ | 13.9KB

来源：原文存档（ByteByteGo, 2026-05-18）

核心要点¶

问题背景：Grab ADW（Analytics Data Warehouse）团队管理 15,000+ 张表，每月约 1000 人查询，最优秀工程师每周花 2 天回答同事的临时问题
核心架构：Classifier + Data Agent + Code Search Agent + On-call Agent + Summarizer 的多 Agent 协作系统
读写分离：Read-only 调查路径（4 个 Agent 并行协作）和 Write Enhancement 路径（单 Agent + 人工审核 gate）有根本不同的风险模型
四大生产挑战：①上下文累积导致 token 爆炸 ②工具定义过于冗余 ③PII/危险操作安全风险 ④用户信任建立
核心洞察：多 Agent 系统里，生产 Hardening 工作量远大于 Agent 开发本身；反馈回路的工程化是系统持续进化的关键

技术洞察¶

问题结构化：一致性比差异性更值钱¶

Grab ADW 团队的核心观察是：问题的答案各不相同，但回答的过程高度一致。工程师收到的问题每次不同（"为什么这个 ID 是乱码？"、"能给这个表加一列吗？"），但调查过程都是：搜索数据目录 → 追踪数据血缘 → 验证 SQL → 检查日志。这个一致性是自动化的前提信号——只要调查过程可重复，就能自动化。这给我们的启发是：在评估一个工作是否适合 Agent 化时，重要的不是问题看起来多复杂，而是解决过程的变异性有多高。变异性低（即使问题本身复杂），Agent 化的成功概率高；变异性高（即使单个问题简单），Agent 化难度大。

大脑与手的分离¶

Grab 的设计哲学是"Decoupling the Brain from the Hands"：

Brain = LLM，负责推理、决策、生成
Hands = Specialized Agents 和 Tools，负责实际执行（查询、代码搜索、状态检查）这个分离的价值是可调试性（Debuggability）。当系统输出错误答案时，团队可以定位：问题是推理层（Brain 给出了错误判断）还是执行层（特定 Tool 返回了错误信息）。这个定位能力在单一大模型系统里往往很难做到。

专业化 Agent vs 单体 Agent 的权衡¶

维度	单体 Agent	专业化 Multi-Agent
部署复杂度	低（一个模型调用）	高（多个 Agent 协调）
可调试性	低（黑盒）	高（每个 Agent 职责清晰）
可维护性	高（改一处）	低（改一处可能影响协调）
推理延迟	低	高（串行执行）
能力上限	受单模型能力限制	可叠加各 Agent 专长
Grab 明确选择了专业化路线：当你要替代一个需要几小时的人工调查时，多花几分钟获取精确答案仍然massive improvement。这个取舍逻辑值得借鉴——Agent 化系统的延迟代价只有在它相对于基线没有显著优势时才成问题。

技术栈选择¶

FastAPI：接收传入请求，管理 HTTP 层
LangGraph：管理多 Agent 协作的有状态逻辑（循环、条件分支、任务交接）
Redis：缓存和实时 Session 管理
PostgreSQL：对话历史和 Agent 元数据的持久化存储
Hubble：集中式元数据和数据目录
Genchi：数据质量可观测性平台（强制数据契约）
Lighthouse：Pipeline 执行状态和健康追踪注意 LangGraph 在这里的作用不是简单的工作流引擎，而是状态机——它处理真实的 Agent 循环、context switching 和任务交接，这些在 LangGraph 之前需要大量手写状态管理代码。

深度分析¶

Agent 间 Context 管理的工程挑战¶

多 Agent 系统的 token 累积问题比单 Agent 更严重：每个 Agent 的输出都是下一个 Agent 输入的一部分，context 在 Agent 间传递时会膨胀。 Grab 的解法是层级式 context 压缩：

tiktoken 实时追踪：每条消息都记录 token 计数，接近限制时自动摘要早期消息
Tool 输出剪枝：在将结果传递给下一个 Agent 前，用小模型提取相关片段和描述，而非传递完整输出
Orchestrator 中介：在每个 Agent 间加入清理和压缩逻辑这里有一个重要的架构洞察：上下文管理不是 LLM 的责任，是基础设施的责任。如果把所有 context 管理工作交给 LLM 判断，LLM 会消耗额外的推理能力处理自己的 context，而且判断质量不稳定。让基础设施层处理 context 压缩，LLM 只处理它最擅长的事情（推理和生成），这是合理的分工。

工具设计的工程价值¶

大多数 Agent 系统的工具设计是事后的——先有工具，再给工具写描述。但 Grab 的经验表明：工具设计是 Agent 系统性能的主要杠杆之一。初始设计有 30+ 工具，每个工具的描述都像通用 API 文档一样冗长。由于工具描述是 Agent prompt 的一部分，每个推理调用都要处理全部 30+ 工具的描述文本拖累了速度和输出质量。改进方案：Aggressive Simplification——只包含决策所需的工具描述部分，截断冗余输出，让每个工具的定义简洁可操作。结果是系统响应性显著提升。这个教训是：工具数量和工具质量之间存在负相关，特别是在 LLM 推理能力有限的情况下。一个设计良好的小工具集比一个臃肿的工具集更有价值。

安全四层防御的纵深设计¶

Grab 的多 Agent 系统接入数据库和代码生成能力，存在真实风险。他们的 4 层防御体系值得详细分析： Layer 1 - Input Classification：Classifier Agent 在执行前检测 PII 请求和超出范围查询。这个 layer 解决"问的问题本身是否合法"——而不是"答案对不对"。 Layer 2 - SQL Validation：每个查询在被执行前检查：是否访问了 PII 列？是否包含危险操作（DELETE/DROP）？是否缺少分区过滤器（这会导致全表扫描）？Schema 合法性验证。这个 layer 解决"执行的查询是否危险"。 Layer 3 - Timeout Protection：所有数据库查询都有严格执行时间限制，防止失控操作。 Layer 4 - Enhancement Controls：Enhancement Agent 不能直接提交到主分支，所有变更需要人工审核，所有代码先在 staging 环境运行。这个 layer 解决"变更是否经过适当授权"。四层防御的逻辑是每层的盲点由其他层覆盖。Input Classification 可能有漏网的 PII 请求，但 SQL Validation 会拦住访问 PII 列的操作。每个 layer 独立负责一个维度的安全，但共同构成纵深防御。

信任建立的动态调整¶

最初设计：所有 AI 生成的回答在工程师审核前不发布。这安全但慢——在高峰期问题堆积，无人审核。

改进后的设计：立即发布答案，但标注为"未经审核"。用户获得快速响应，同时知道答案的置信状态，可以选择性地进行人工复核。这个设计演变的深层逻辑是：信任不是静态的，是随着系统性能证据积累动态扩展的。系统上线初期，信任资本有限，高的审核率是合理的；随着系统性能数据积累（rejection rate 低，user feedback 好），信任边界可以扩展，释放人工审核资源用于更高价值的 work。这个模式对所有 AI Agent 系统有普遍参考价值：不要在系统上线初期就追求"无人化"，也不要永远停留在"全人工审核"阶段——建立性能指标驱动的动态审核策略。

实践启示¶

识别 Agent 化机会的第一步：画出调查路径¶

不是所有重复工作都适合 Agent 化。第一步是把工作过程的调查路径画出来（不需要写代码，用白板或文档）。如果路径是高度一致的（每次都是：搜索 → 追踪 → 验证 → 检查日志），即使问题本身看起来千变万化，Agent 化成功概率高。如果路径本身不确定（不同问题需要完全不同的调查方式），Agent 化复杂度会大幅上升。

从"帮手"到"主要工作者"的渐进策略¶

不要在初期就设定"AI Agent 替代人工"的目标，这会造成政治阻力。更好的叙事是：让最好的工程师把时间从回答问题中解放出来，专注于只有人才能做的事。这个叙事让干系人更容易接受系统上线初期需要人工复核的设计，因为最终目标不是"消灭人工"而是"人工用在更有价值的地方"。

生产 Hardening 的优先级排序¶

当一个 Agent 原型在 demo 效果很好时，下一步不是上线，而是问"上线后会出什么问题"。Grab 发现的 4 类问题（context 爆炸、工具冗余、安全风险、信任建立）是有普遍性的。建议的上线前 Hardening 检查清单：

Context 压力测试：模拟长会话（20+ 轮次），观察 token 累积对输出质量的影响
工具边界测试：用边界条件调用（空输入、超大输入、恶意输入），观察 Agent 的错误处理
安全边界测试：尝试注入 PII 请求、危险 SQL、越权操作，验证每层防御是否有效
信任校准测试：让真实用户使用系统，收集第一批反馈，不急于扩大 AI 的自主范围

反馈回路的工程化¶

很多 AI Agent 系统在第一版上线后性能冻结——因为没有机制让系统从 production 使用中学习。Grab 的 annotation 系统值得学习：

随机抽样测试：随机选择 annotation 作为离线测试用例，确保系统在真实 failure 上测试
模式分析：问"Classifier 是否持续路由到错误的 Agent？"——这是系统性问题，不是单次失误
质量指标趋势：跟踪 rejection rate 的时间序列——突然上升意味着某处发生了变化
定向改进：基于分析结果，改进 Agent prompt、增强 Guardrail、为特定查询类型增加示例这个反馈回路的设计关键：annotation 不只是记录，而是驱动改进的输入。如果 annotation 只存在于数据库里没有人分析，它的价值接近于零。

写操作 Agent 的人工 Gate 设计¶

对于改变 production 数据的 Agent 操作（Enhancement Pathway），Grab 的设计是半自动化：AI 生成变更，但每一步都需要人工审核和批准。这个设计值得推广。关键原则：AI 生成的内容接触 production 的 gate 数量取决于内容的风险等级：

读操作（调查、查询）→ 轻量监督或无监督
写操作（数据变更、代码修改）→ 强制人工审核
高风险写操作（删除数据、修改 schema）→ 强制多人审核 + staging 验证这个分层授权机制可以在任何企业 Agent 系统中复用。