Grab 用 LLM-Kit 对 500 多个内部智能体服务进行了标准化。LLM-Kit 是一个脚手架与集成工具集，可为新建服务直接提供基础智能体执行循环，同时内置评估、链路追踪、密钥管理以及工具服务器连接能力。智能体会在运行时从 50 多个 MCP 服务器中发现可用工具，并通过统一的网关访问模型。因此，新增能力和新增模型服务商只需要进行注册或配置，不需要重新部署。
现在，在 Grab 把一个全新的 AI 智能体服务接入生产环境大约需要 1 小时，而过去需要两周甚至更久。效率提升的关键点不在于智能体本身的推理循环，而是周围的配套系统：密钥、追踪、服务发现和评估。Grab 在一篇关于 LLM-Kit 的工程博客文章中介绍了这一变化。该框架目前为这家东南亚网约车和外卖公司的 500 多个服务提供支撑，其中包括每天被数百万商家、司机和消费者使用的智能体。文章写道：“推理循环的开发只花了一个下午，而生产环境适配封装却要两周。”
LLM-Kit 消除的是每项服务都要单独做技术方案决策的负担。它没有被设计成一种新的智能体抽象或领域特定语言，而是围绕 Grab 已有的基础设施而搭建的脚手架。Grab 的思路发生了转变：不再逐个服务重复解决同类问题，改为集中统一一次性解决所有问题，LLM-Kit 正是在这个思路下搭建而成。工程师填写一个表单，就会得到一个 GitLab 代码库，里面是一个可运行的 FastAPI 服务，已经内置了 LangGraph Agent 模块、OpenTelemetry 追踪、Vault 密钥管理和服务发现，并且从第一次代码提交开始就带有一个评估端点，可用 ROUGE、BLEU 以及另一个模型作为评分器进行打分。
图 1：FastAPI 服务项目目录结构（来源：Grab 博客）
工具并不是预先绑定好的：智能体会在运行时从 50 多个已注册、支持 Model Context Protocol 的服务器中获取工具。因此，一项能力只需注册一次就能被所有智能体使用。模型服务商同样不是预先接好的。每一次模型调用都会经过兼容 OpenAI 接口的 GrabGPT Gateway。该网关前置接入了五家服务商，并注入凭证，因此应用代码永远不会硬编码某个服务商的信息。
选择框架而不是平台，是有意为之。文章解释了原因：
平台会将团队束缚在固化的预设方案中，而这些方案很快就会过时。采用框架的形式则可以适配开发者现有的工作方式。
分析师 Kai Waehner 曾在今年 4 月份提出，”Agentic AI 的技术锁定比 API 锁定更持久，因为它会同时在多个层面累积。“他提到的层面包括模型、框架、运行时，以及团队基于这些组件搭建出来的开发范式。他的文章并非针对 Grab，但这个分析框架同样适用：网关覆盖的是模型层，而框架、运行时与开发范式则很难封装到单一接口背后，并且是 LLM-Kit 上所有服务共用的部分。
另外，Grab 网络安全团队在今年 6 月份介绍的 Palana 让团队能够”在实验自主智能体的同时不放弃对身份、密钥、网络访问和运营可见性的控制“。分析团队还自建了一套多智能体工程支持系统。
LLM-Kit 解决的是构建和交付单个智能体的问题，但当智能体数量达到 500 个时，Grab 发现问题已经从框架层面转移到了平台层面。网关管理着所有人调用哪个模型，远程 MCP 框架让团队能够复用彼此的工具，评估平台则用来判断一次提示词修改究竟让智能体变得更好了，还是只是变得不一样了。这个平台层中的大部分能力现在已经可以直接采购而不是自行构建：Amazon Bedrock AgentCore 和谷歌的 Agent Runtime 可以托管用现有框架编写的智能体，并提供身份、网关和可观测性能力。对于正在权衡同类方案的团队来说，一个有价值的结论在于找到真正的成本所在：如果核心业务逻辑开发只需要一个下午，而底层通用基础设施要耗费两周，那么选择的关键不在于挑选哪一个智能体库，而在于由谁来负责凭证管理、链路追踪与评估体系。
查看英文原文：https://www.infoq.com/news/2026/09/grab-agent-platform/
