Grab 给自己的 Analytics Data Warehouse 平台上了一套生产级的多 agent 工程支持系统,部署给 1,000+ 管理 15,000+ 张表的内部用户。架构:一个 supervisor agent 负责通信和任务分派;几个专长 agent 各管context 检索、代码搜索、方案生成。两条主工作流 —— 调查(查询分析、SQL 调试、日志检索、schema 查找)和优化(代码修复、自动 merge request)。工作流引擎走 LangGraph,FastAPI 服务负责路由、工具执行、状态管理。工具生态从 30+ 个工具收敛到一套精选:受控 SQL 执行、元数据访问、日志检索、基于 Git 的工作流。具体用了哪些模型没披露。汇报的影响:Head of Analytics 说「每个月省下几百小时工程时间」,而且团队从「被动救火」转向「平台开发工作」。
架构选择才是真正值得研究的地方。第一,**收紧 agent 的职责** —— 每个专长 agent 范围都被卡得很窄,降低推理上的歧义。这跟今早那篇 agent 安全里的「proposal-execution 拆分」是同一种本能:把 agent 能决定的事限制住,让 gate 能验证它真正做的事。第二,**所有代码改动都过 human-in-the-loop** —— 没有 agent 不经 review 就往生产里写。第三,**SQL 执行验证层加敏感数据保护** —— agent 不直接跑任意 SQL,它跑的 SQL 是过一道受控执行 gate,gate 先 scrub 敏感数据、先 validate,再放行。第四,**为了多步推理在 token 限制内,做结构化的 context 压缩** —— 长上下文这个问题(15K 张表意味着 schema 查找会很快把 context 预算吃光)是用显式压缩解决的,不是靠模型自己「想清楚什么有用」。30-工具-收敛-到-精选 这个动作本身就是运营层面的教训:tool sprawl 让 agent 不是更能干,而是更不靠谱。把工具集做精,本身就是工作。
对 builder 为什么重要。这种规模(1K 用户、15K 表)、这种具体度(明确说出 LangGraph + FastAPI 栈、明确说出 human-in-the-loop、明确说出工具收敛)的生产级多 agent 部署,在公开 reporting 里其实是稀缺品。大多数公开的 agent 案例都还是 demo 或者 pilot。Grab 的具体细节告诉你「生产级现在长什么样」:framework 选型(LangGraph 而不是 AutoGen / CrewAI / 自研)是真实信号 —— LangGraph 的 checkpointing 和 supervisor-pattern 原语在这种 use case 上是 battle-tested 的。Analytics Data Warehouse 这个 use case 也很可推广:任何地方,你有一个复杂的内部平台(数据仓库、内部 API 面、infra 自动化)在支撑很多工程师,而支持工作大量是重复劳动,Grab 这个 pattern 都适用 —— supervisor agent、专长 retriever、受控执行 gate、对所有写操作 human-in-loop。
周一上手:如果你在考虑搭一套多 agent 的工程支持系统,Grab 这个 pattern 是一个 strong template。具体起点。(1) 如果你的团队对 orchestration 层还没有强意见,先选 LangGraph —— supervisor-pattern 原语跟 investigation / enhancement 这种工作流拆分是 cleanly map 上的。(2) 审一下你现有的内部工具面;Grab 那个 30-收敛-到-精选 就是教训 —— 工具太多会让 agent 变差。从「能覆盖 80% 支持负载的 5 到 10 个工具」这个名单起步,然后再加。(3) 在让 agent 写任何东西到生产之前,把受控执行 gate 先搭起来。SQL 执行验证 + 敏感数据 scrub 是 Grab 用的具体 pattern;更一般的 pattern 是「policy 校验过的、不可绕开的执行」。(4) 所有代码改动的 human-in-the-loop,从第一天就规划进去 —— 后面再加比从一开始就建,要难得多。(5) 把「省下的工程小时数」当主指标,而不是「ticket 关闭数」或者模型准确率 —— agent 的 business case 就是 reclaim 工程时间,Grab 的 Head of Analytics 引用的也正是这个。Eval 指标要和 business 指标对齐。