Grab 公司通过使用LLM-Kit框架，实现了对500多个内部智能体服务的标准化。这一创新不仅提高了AI智能体的生产部署效率，还简化了技术决策过程。LLM-Kit是一个集成工具集，为新建服务提供基础智能体执行循环，并内置评估、链路追踪、密钥管理和工具服务器连接能力。智能体会在运行时从多个MCP服务器中自动发现可用工具，并通过统一的网关访问模型。这使得将全新的AI智能体服务接入生产环境的时间从两周缩短至一个小时内。
--91likeyou---
LLM-Kit 消除的是每项服务都要单独做技术方案决策的负担。它没有被设计成一种新的智能体抽象或领域特定语言，而是围绕 Grab 已有的基础设施而搭建的脚手架。Grab 的思路发生了转变：不再逐个服务重复解决同类问题，改为集中统一一次性解决所有问题，LLM-Kit 正是在这个思路下搭建而成。工程师填写一个表单，就会得到一个 GitLab 代码库，里面是一个可运行的 FastAPI 服务，已经内置了 LangGraph Agent 模块、Open 追踪、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 可以托管用现有框架编写的智能体，并提供身份、网关和可观测性能力。对于正在权衡同类方案的团队来说，一个有价值的结论在于找到真正的成本所在：如果核心业务逻辑开发只需要一个下午，而底层通用基础设施要耗费两周，那么选择的关键不在于挑选哪一个智能体库，而在于由谁来负责凭证管理、链路追踪与评估体系。
查看英文原文：
🔥 热词：#智能体openclow框架 · #智能体框架harness · #智能体langchain框架必学知识 · #智能体运行框架 · #智能体开源框架 · #agno智能体框架 · #智能体框架图 · #github智能体