当企业内部的 AI Agent 从几个试验项目增长到数百个服务时，真正的瓶颈往往不再是提示词，而是工程基础设施：服务如何接入、模型如何切换、密钥如何管理、工具如何发现，以及上线后如何评估和运维。Grab 通过 LLM-Kit 统一了 500 多个内部 Agent 服务，并将新 Agent 的部署周期从约两周缩短到一小时。
这类实践的重点，不是再造一个聊天机器人框架，而是把 Agent 当成一种需要标准接口、运行时治理和持续评估的生产服务。
从“每个团队自建”转向统一运行底座
在没有统一框架时，一个 Agent 团队可能会自己选择模型 SDK、封装工具调用、编写鉴权逻辑和部署脚本。另一个团队则采用不同的协议。短期看，这种方式很灵活；当服务数量达到数百个后，维护成本会迅速上升：
- 模型供应商切换需要逐个修改服务；
- 工具接入方式不一致，难以复用；
- 密钥散落在代码仓库、环境变量或部署脚本中；
- 评估指标和日志格式不同，无法横向比较；
- 新服务上线前需要重复搭建大量基础设施。
LLM-Kit 的核心方向，是把这些共性能力集中到框架和平台层。Agent 服务只需要声明自己的能力，平台负责连接模型、工具、评估系统以及运行环境。这样，业务团队可以把更多精力放在任务流程和领域逻辑上，而不是重复实现基础设施。
运行时工具发现，让 Agent 不必携带所有集成代码
传统 Agent 往往在代码中静态注册工具，例如把数据库查询、订单查询和通知发送函数全部写进应用。工具数量一多，Agent 发布就会变得笨重，而且工具更新可能迫使整个 Agent 重新构建。
运行时工具发现提供了另一种思路：Agent 启动后从受控目录或服务注册中心获取可用工具，根据任务、权限和环境动态选择工具。平台可以集中管理工具的版本、访问范围和健康状态。
下面是一个可以改造成内部原型的配置示例。它不是 LLM-Kit 的官方配置格式，而是展示统一 Agent 平台可以如何描述模型、工具发现和密钥引用：
# agent.yaml
apiVersion: platform.example/v1
kind: AgentService
metadata:
name: order-support-agent
spec:
model:
provider: openai-compatible
name: support-reasoning-model
temperature: 0.2
toolDiscovery:
endpoint: https://tool-registry.internal/v1/tools
refreshSeconds: 60
allowed:
- order.lookup
- refund.policy
secrets:
- name: MODEL_API_KEY
source: vault://production/agent/order-support/model-api-key
evaluation:
dataset: support/regression-v3
requiredPassRate: 0.90
部署前可以用一个简单的 HTTP 接口验证工具注册中心是否可访问：
export REGISTRY_TOKEN="replace-with-short-lived-token"
curl --fail-with-body \
-H "Authorization: Bearer ${REGISTRY_TOKEN}" \
"https://tool-registry.internal/v1/tools?agent=order-support-agent"
生产环境中，访问令牌应由工作负载身份或密钥管理系统注入，不应提交到 Git，也不应直接写进 YAML。工具发现也不能等同于“允许调用所有工具”：平台仍需要基于 Agent、用户、环境和数据范围执行授权检查。
模型接入与评估需要成为平台能力
Agent 的模型选择通常会随着成本、延迟、上下文长度和任务效果变化。如果每个服务都直接绑定某一家模型供应商，后续迁移会带来大量改造工作。统一框架可以通过模型适配层屏蔽供应商差异，让 Agent 使用稳定的内部接口。
例如，业务代码只依赖一个内部推理端点，而不是直接依赖某个供应商的 SDK：
curl -sS https://llm-gateway.internal/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer ${LLM_GATEWAY_TOKEN}" \
-d '{
"model": "support-reasoning-model",
"messages": [
{"role": "system", "content": "You are a careful order support assistant."},
{"role": "user", "content": "Check the refund policy for order 12345."}
],
"temperature": 0.2
}'
同一个网关还可以统一记录请求耗时、令牌消耗、错误类型和模型版本。这样，模型替换就不只是开发者本地的代码改动，而是可以在平台层进行灰度、回滚和成本控制。
评估也需要进入发布流程。一个可行的最小门禁是：每个 Agent 都绑定一组回归样本，在部署前检查任务成功率、工具调用正确率和安全规则命中情况。只有达到阈值才允许进入生产环境。摘要中提到的服务标准化，价值正体现在这类能力可以被批量复用，而不是每个团队从零开始设计。
密钥治理和运维控制不能被“自动化”掩盖
Agent 平台越自动化，越需要明确控制边界。统一框架不应让业务团队绕过安全流程，而应把安全流程变成默认路径：
- 密钥引用而非密钥复制：配置只保存 Vault、云密钥服务或工作负载身份的引用。
- 最小权限工具访问：每个工具声明所需权限，Agent 只能获得任务必需的范围。
- 完整审计：记录调用者、Agent 版本、模型版本、工具名称和结果状态，避免记录不必要的敏感数据。
- 可回滚发布：模型、提示词和工具版本都应可追踪，出现异常时能快速恢复。
- 人工升级路径：涉及退款、账号关闭或高风险操作时，Agent 应转交人工，而不是无限重试。
Grab 的案例说明，规模化并不意味着放弃运营控制。相反，把基础设施集中管理，才能让运行时发现、模型灵活接入和快速部署在可控范围内发生。
落地时可以从一个“薄平台”开始
如果要在自己的组织中复现类似收益，不必一开始就建设完整的 Agent 操作系统。可以按以下顺序推进：
- 先定义统一的 Agent 服务协议：输入、输出、错误、工具调用和健康检查；
- 再建设模型网关，隔离供应商 SDK，并统一观测数据；
- 将密钥接入现有密钥管理系统，禁止在仓库保存长期凭证；
- 建立工具注册表和权限模型，优先覆盖高复用工具；
- 将离线评估作为发布门禁，再逐步加入线上质量监控；
- 最后再引入运行时工具发现、自动灰度和更复杂的路由策略。
衡量平台是否真的有效，可以观察三个指标：新 Agent 从代码完成到生产可用需要多久、跨服务复用一个工具需要多少改动、以及一次模型或安全策略变更需要修改多少应用。只要这些指标持续下降，平台就不是额外的抽象层，而是在把组织经验沉淀成可复用的生产能力。