跳到正文

迁移指南从 自建的 AI 代理

从自建代理,到一个无需你运维的控制平面

很多团队在 OpenAI 和 Anthropic 前面写了一个小服务:它持有密钥、负责重试和日志、按成本表统计 token,并对每个团队执行配额。本页把这些工作逐一对应到 INFRO,说明哪些仍由你的代码负责,并展示如何在代理继续运行的同时一次迁移一个服务。

你自己放在提供商前面的服务:密钥、重试、日志、配额

INFRO 账号可自助开通。 模型目录、文档和 API 契约已公开,网关已部署,v1 之后的所有功能都标注为“后续”。 套餐与试用

现状

这类代理通常做什么

持有提供商密钥,为每个团队签发内部密钥,重试和故障转移,记录请求,根据手工维护的价格表为 token 计价,并拒绝超出配额的团队。

维护它们的成本

总得有人负责价格表、新模型、每家提供商的新参数、日志背后的数据库,以及代理本身的值班。

两种迁移方式

替换它:服务调用 INFRO,由 INFRO 调用你的提供商。或者暂时把它保留在 INFRO 后面:把代理作为 openai-compatible 连接接入,然后逐个迁移它的上游。

你自己写的代理完全满足你的需要,这本身是有价值的。如果它存在的原因是以下之一,就保留它。

  • 它会修改请求:提示词模板化、向上下文注入检索内容、用你自己的模型进行 PII 脱敏,或对响应进行后处理。INFRO 的护栏是模式规则和决策模型检查;它不会在请求路径中运行你的代码。
  • 它必须运行在你的网络内或指定区域内。INFRO 的套餐托管在 Cloudflare 的网络上;自托管或混合部署通过企业协议提供。
  • 它提供的是任何提供商 API 都不提供的模型,比如你在内部 GPU 上托管的权重,除此之外别无其他。INFRO 可以把该服务器作为 openai-compatible 连接进行路由,但服务器仍归你所有。
  • 它很小,有人负责,也没人要求预算、归因或故障转移。那么网关就是一次没有收获的迁移。

需要的修改,每项一行。未在此列出的内容都保持不变。

 你的代理INFRO
基础 URL你的代理的内部主机。https://api.infro.io/v1(OpenAI 格式)、/v1/messages(Anthropic 格式)、/v1/responses(OpenAI Responses)。
密钥由你的代理为每个团队或服务签发的内部密钥。每个服务一个 INFRO 网关密钥,各自带有模型允许列表、提供商列表、IP 范围、环境和支出限额。
模型 ID你的代理定义的任何别名。vendor/model,或路由规则名称:路由规则是一个别名,解析为你连接的有序列表,在控制台中编辑。
请求头你自己的团队、用户或功能请求头。X-INFRO-Feature、X-INFRO-User-Id、X-INFRO-Trace-Id,或请求体中的 metadata.user_id、metadata.session_id、metadata.tags。

之前 · 你的代理

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://llm-proxy.internal.example.com/v1",
  apiKey: process.env.LLM_PROXY_KEY,
  defaultHeaders: { "X-Team": "search" },
});

await client.chat.completions.create({
  model: "default-chat",
  messages: [{ role: "user", content: "Hello" }],
});

之后 · INFRO

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.infro.io/v1",
  apiKey: process.env.INFRO_API_KEY, // one key per service
  defaultHeaders: { "X-INFRO-Feature": "search" },
});

await client.chat.completions.create({
  model: "default-chat", // a route with the same name
  messages: [{ role: "user", content: "Hello" }],
});

保留你的别名

为代理定义的每个别名创建一条同名路由规则,服务就能继续发送同样的 model。密钥可以固定到指定的路由规则,从而无法直接调用模型。

一次迁移一个服务

把代理本身作为一个 openai-compatible 连接接入,并添加为路由目标。服务可以先切换到 INFRO;之后再把上游从代理迁移到直连。

团队变为项目

每个团队的配额变为项目预算和每个密钥的支出限额。成员可以被限定在他们负责的项目中。

你当前设置的功能与 INFRO 的对照,并已按网关实际实现的内容核对。 有一行显示 INFRO 没有对应项。

你的代理它在那里的作用在 INFRO 中
密钥保管库形式相同提供商密钥存放在代理的配置或密钥存储中。提供商连接,静态加密封存,每个提供商可有多个密钥,备用密钥排在最后。
内部密钥形式相同代理为每个团队或服务签发的密钥。网关密钥,带有模型允许列表、提供商列表、IP 范围、环境、支出限额、轮换和停用开关。
重试和回退形式相同代理中的代码。按优先级或权重分配目标的路由规则,针对请求的条件规则,以及按故障类型的规则(429、5xx、超时、连接、凭据、内容审核)。
配额形式相同每个团队的 token 或美元计数器。按组织、项目、成员、密钥和终端客户设置的预算,在达到上限时以 402 拒绝,并发情况下同样有效。
价格表不同一张手工维护的按 token 计价表。来自 INFRO 目录的厂商公开价、你录入的协商价,两者都未知时为 unpriced,绝不为零。
请求日志不同你自己数据库中的记录。控制台中的请求日志和追踪记录、GET /v1/requests、导出,以及发送到你的 OpenTelemetry 采集器的 span。提示词采集在你开启之前一直关闭。
提示词和响应转换无对应使用你自己的逻辑进行模板化、检索和脱敏。不提供。护栏按模式和决策模型检查进行拦截、遮盖或标记;INFRO 不运行你的代码。
自托管模型不同代理后面的 vLLM、TGI 或 Ollama。一个指向该服务器的 openai-compatible 连接,像其他提供商一样路由。服务器仍由你自己运行。
自行运行不同它运行在你部署它的地方。托管服务。自托管或混合部署通过企业协议提供,而不是一个套餐。Enterprise — 通过企业协议提供,而非自助开通。

INFRO 不做的事

  • 在请求路径中运行你自己的代码:提示词模板化、检索、自定义转换。
  • Batch、Files、微调和 Realtime,或在 OpenAI、Azure OpenAI、Mistral 或 OpenAI 兼容端点之外的提供商上使用嵌入。
  • 区域固定;数据驻留在路线图上,目前不提供。
  • 没有企业协议的自托管部署。

哪些无法迁移过来

  • 你的代理的日志。没有导入工具;把它们留在原处即可。
  • 它的价格表。改为在控制台中录入协商价;公开价来自目录。
  • 自定义转换。它们保留在你的代码中,在调用 INFRO 之前执行。

问题

INFRO 能放在我们现有的代理前面吗?
能。把代理作为 openai-compatible 连接接入,填入它的基础 URL 和密钥,在迁移其上游期间像任何提供商一样路由到它。
我们的提供商合同会改变吗?
不会。你连接自己持有的提供商账号,你的提供商继续按你自己的价格直接向你收费。INFRO 是订阅制,对模型支出加价 0%。
哪些仍由我们的代码负责?
任何会修改提示词或响应的操作:模板化、检索、自定义脱敏、后处理。

和我们一起迁移,或自行迁移

迁移计划会在一次通话中把你的 自建的 AI 代理 设置映射为 INFRO 的连接、路由规则和预算,并和你一起迁移第一个服务。你的提供商继续直接向你收费;INFRO 是一项订阅,对模型支出零加价。

来源

本页中关于 SDK 行为的内容来自以下来源,阅读于 2026年10月19日。