跳到正文

从 Vercel 的 Agent 教程开始：普通开发者怎么做一个能落地的 AI Agent（3）：从本地 demo 到可恢复的生产任务

从 Vercel 的 Agent 教程开始：普通开发者怎么做一个能落地的 AI Agent · 1 · 2 · 第 3 篇（当前）

客服助手已经能查订单并生成草稿以后，接入真实业务会增加几种约束：模型可能在工具执行后失败，第三方凭据会过期，人工审批可能跨过请求与进程的生命周期，重试也可能重复提交已经成功的动作。

这里沿用本地客服助手的模型与工具循环，集中讨论路由、隔离、授权、恢复和治理。模型选择下一步，业务代码继续校验资源权限和审批状态；托管网关或工作流承担的能力需要分别判断。

fallback 和模型路由是生产能力

开发 demo 时，一个模型挂了，大不了刷新重试。生产 Agent 不一样。用户可能已经等了几十秒，Agent 也可能已经完成了几个工具步骤，最后一次模型调用失败会让整个任务显得不可靠。

Vercel AI Gateway 的价值之一，是把多模型路由、fallback、日志、费用和认证集中起来。它的 AI Gateway 文档 里也把统一凭据、请求日志、预算控制、provider fallback 和 model fallback 放在同一类运营能力里。

在应用代码里，fallback 最好集中成一层模型策略，用配置管理模型选择。

type ModelPolicy = {
  primary: string;
  fallbacks: string[];
};

function requiredEnv(name: string): string {
  const value = process.env[name]?.trim();
  if (!value) throw new Error(`缺少环境变量 ${name}`);
  return value;
}

const productionChatPolicy: ModelPolicy = {
  primary: requiredEnv('CHAT_MODEL'),
  fallbacks: [process.env.CHAT_FALLBACK_1, process.env.CHAT_FALLBACK_2]
    .filter((id): id is string => Boolean(id)),
};

如果用 Vercel Gateway，fallback 可以交给 gateway provider options；如果用 LiteLLM，也可以用它的 Router 或 Proxy Server 做 retry、fallback、budget 和日志。LiteLLM 的官方文档把它定位成统一调用 100+ LLM 的接口，并提供自托管 LLM Gateway、virtual keys、cost tracking 和 admin UI，这更适合想把网关掌握在自己基础设施里的团队。

选不选 gateway，可以按这几个问题判断：

  • 是否要同时接多个模型供应商。
  • 是否需要统一 key、日志、成本、限流和预算。
  • 是否需要 provider outage 时自动 fallback。
  • 是否希望业务代码尽量不感知供应商差异。
  • 团队是否愿意维护自建代理、数据库、监控和升级。

只有一个 demo、一个模型、一个开发者时，直接调供应商 API 也可以。到了团队和生产流量，再补统一网关会更省心。

执行模型生成的代码要隔离

数据处理、代码修复、测试生成、脚本编写等任务，可能需要运行模型生成的代码。这些代码应按不可信输入处理：它可能死循环、读取敏感文件、访问不该访问的网络、删除文件，也可能只是写错了。

Vercel 原文用 Vercel Sandbox 处理这件事。它给 Agent 一个隔离环境运行代码，原文还提醒一次性执行时要关闭持久化，避免不需要的文件系统快照继续计费。

如果不用 Vercel，也要明确代码会在哪里执行、能访问什么。下面几种方案的信任边界和维护成本不同，不能仅按名字判断隔离强度：

  • 不执行代码，只生成补丁：适合文档、简单脚本、人工 review 后再跑的任务，代价是自动化程度低。
  • 本地 Docker 容器：适合内部开发、低风险 demo、离线数据处理，隔离强度和资源限制要自己配。
  • gVisor / Firecracker / Kata Containers：适合多租户、外部输入、不可信代码，基础设施会明显复杂一些。
  • Vercel Sandbox / OpenAI-hosted sandbox / Cloud sandbox：适合希望少维护隔离层的团队，平台绑定、价格和权限要提前评估。
  • 自建临时工作区 + allowlist 命令：适合 Coding Agent 和内部仓库修复，文件范围和可执行命令必须限制得很严。

最小安全原则是：模型可以生成代码，但不能直接在生产环境里执行它。

临时目录和命令 allowlist 不是独立沙箱。允许 node script.mjs 或 pnpm test，仍然可能执行任意项目代码；这些代码能碰到什么文件、网络和凭据，要由容器或其他隔离层限制。不要把宿主机密钥、Docker socket 或不必要的可写目录交进去。

一个自建版本可以先做得很朴素：

  • 每次任务创建临时目录。
  • 只挂载必要输入文件。
  • 容器禁用或限制网络。
  • 设置 CPU、内存、磁盘和超时。
  • 命令使用 allowlist，比如只允许 node script.mjs、python main.py、pnpm test。
  • stdout、stderr、exit code 全部记录下来。
  • 任务结束后销毁工作区。

这种方案比平台沙箱麻烦，但思路完全相同：prompt 只能提醒模型不要做危险事，隔离环境才是最后的安全边界。

第三方 API 要用短期授权

一个 Agent 如果只能查公开资料，权限问题还不明显。只要它开始帮用户做事，比如发 Slack 消息、建 GitHub PR、查数据仓库、更新 Notion、提交 Jira issue，权限就变成主问题。

最粗糙的做法是把长期 API key 放进环境变量，让 Agent 的工具函数随便用。这能跑，但风险很大：

  • key 长期有效，泄露后影响大。
  • key 往往代表整个应用或团队，不容易按用户隔离。
  • 很难给不同工具分不同 scope。
  • 撤销、审计和审批都麻烦。

Vercel 原文用 Vercel Connect 处理第三方 API 授权。它的思路是运行时申请短期 token，并区分「代表应用」和「代表用户」两类身份。即使团队不用 Vercel Connect，这条原则也很通用：Agent 调外部服务时，权限应该短期、可撤销、可审计、可按 scope 限制。

长期服务凭据放在后端环境变量里本身不是错误，问题是权限过宽或被模型直接接触。凭据应留在服务端工具执行层，模型只提交业务参数；短期 token 和 refresh token 同样不能放进 prompt、普通工具结果或日志。撤销与用户退出后的行为也要验证。

自建时可以按这套结构设计：

第三方服务授权与短期 token 调用链

权限模型里还要区分几种动作：

  • 只读：查资料、读 issue、搜索消息。
  • 可撤销写入：发草稿、加评论、创建待确认任务。
  • 不可逆或高风险写入：删除数据、扣款、发布、邀请外部用户、改权限。

只读工具可以自动化程度高一点。可撤销写入可以用审批或预览。不可逆动作默认要有人类确认，最好还要有二次校验和审计日志。

自建权限模型需要明确调用身份（subject）、权限范围（scope）、审批状态（approval）和审计日志（audit log），后续新增工具也要遵守这些约束。

长任务要能恢复

短聊天接口可以靠一次 HTTP 请求完成。真实 Agent 经常不行。

比如这些任务都可能超过单个请求的生命周期：

  • 读十几个接口文档，整理迁移方案。
  • 搜索代码、修改文件、运行测试、根据失败继续修。
  • 订机票、等用户确认、再执行下一步。
  • 调多个外部 API，任何一个失败都要重试。
  • 后台研究任务跑半小时，中间用户刷新页面。

如果所有状态都在内存里，进程重启或运行时终止会让任务丢掉；用户断开连接是否会终止任务，还取决于服务端如何处理请求取消。Vercel 原文把长任务交给 Workflow SDK 和 WorkflowAgent：工具调用变成可持久化步骤，失败后从 checkpoint 继续，需要人工审批时可以暂停。

不使用 Vercel 时，也要解决同一个问题。常见方案有三类。

第一类是用 Agent 框架自己的持久化能力。LangGraph 的官方概览把它定位成用于长时间、带状态 Agent 的低层编排框架，强调 durable execution、human-in-the-loop、streaming 和 persistence。它适合把 Agent 写成图：哪些步骤确定执行，哪些步骤交给模型，哪些地方允许人工介入。

第二类是用平台原生的有状态运行时。Cloudflare Agents 的官方文档把 Agent 建在 Durable Objects 上，每个 Agent 实例像一个有身份的微型服务，可以保存状态、处理 WebSocket、调度任务，并在客户端断开后继续让用户回到同一个实例。它适合边缘网络、实时连接和每个用户 / 会话一个有状态 Agent 的场景。

第三类是用通用工作流引擎托住 Agent。Temporal 的文档把 durable execution 解释成应用在崩溃、网络失败或长时间等待后能恢复到原来的进度。把 Agent 的 LLM 调用和工具调用拆成 workflow activity，可以得到重试、幂等、信号、人工等待和可观测性。代价是架构更重，适合已经有工作流复杂度的团队。

哪一种更好，要看任务形态。

  • 一次聊天里只调用一两个只读工具，用普通 HTTP route + in-memory loop 就能起步。
  • 复杂状态机里同时有确定步骤和模型步骤，LangGraph 更自然。
  • 每个用户 / 会话需要一个长期在线状态体，可以看 Cloudflare Agents / Durable Objects。
  • 多天流程、审批、重试和强审计，更适合 Temporal、Vercel Workflow 或类似工作流引擎。
  • 简单后台任务如果失败重跑也能接受，Queue + 数据库状态通常就够用。

长任务需要记录每一步的输入、输出、副作用和恢复点，进程中断后才能据此恢复进度。

持久化不等于副作用只执行一次。如果退款已经成功，进程却在写入 checkpoint 前中断，恢复后可能再次调用退款工具。幂等键、已提交结果查询和必要的补偿，要由业务接口与工作流共同实现；不能只因为框架支持重试就假定不会重复扣款。

Vercel 在这条链路里的位置

本地项目需要一个 HTTP 入口、一个模型入口和一段 Agent 逻辑。Vercel 为其中部分职责提供托管产品，应用可按需要接入。

AI Gateway 是模型入口层。应用把模型 ID、prompt、工具调用请求发给 Gateway，Gateway 处理凭据、路由、日志、预算和 fallback，再把请求转给 OpenAI、Anthropic、Google、阿里云、DeepSeek 或其他模型提供方。真正生成 token 的仍然是模型提供方；Gateway 解决的是入口统一、凭据托管和观测治理。Agent 可以直连模型厂商，也可以从本地代码调用 AI Gateway，还可以换成 OpenRouter、LiteLLM 或自建 OpenAI-compatible proxy。

Vercel Functions 是线上 HTTP 入口：接收请求，读取环境变量，访问数据库和内部 API，再调用 AI SDK。它的定位接近普通 API route / serverless function；本地 Node.js、Next.js dev server、Express / Hono 服务也能做同样的事。上线到别处时，这个入口可以放进 AWS Lambda、Cloudflare Workers、Docker、Kubernetes 或普通 VPS。

客服售后这种任务通常不止一轮模型请求。查订单、查支付、读退款政策这些动作，可以在 AI SDK 里分别定义成 tools；需要第三方账号或 MCP 工具时，可以用 Vercel Connect 处理 OAuth 授权、用户同意和短期凭据；任务要等待人工确认、跨部署恢复或失败重试时，可以交给 Vercel Workflows；如果 Agent 要执行模型生成的脚本、跑测试或处理文件，就放进 Vercel Sandbox 这类隔离环境。

下图展示 Vercel 这套工具在客服售后 Agent 里的主链路：

Vercel Agent 工具链示例

从这条链路可以看出，Vercel 提供的是一组工程位置：AI SDK 写调用和工具，AI Gateway 管模型入口，Functions / Fluid Compute 跑后端，Workflows 管长任务，Sandbox 管隔离执行，Connect / MCP 管外部工具授权。业务上真正要查什么订单、什么动作需要人工确认、什么日志必须落库，仍然要由你的应用代码决定。

模型 token 怎么付费，取决于你接入模型的方式：

  • 直接调模型提供方：你自己去 OpenAI、Anthropic、阿里云、DeepSeek 等平台申请 API key，放在后端环境变量里，费用也由对应模型提供方收取。这个方案适合只接一两家模型、暂时不需要统一网关的项目。
  • 用 Vercel AI Gateway 的系统凭据：你在 Vercel 创建 AI_GATEWAY_API_KEY，或者应用部署在 Vercel 上时用 OIDC token；Gateway 再用它自己的系统凭据调用上游提供方。Vercel 文档说这条路按上游 provider list price 计价，不加 markup，并且提供 Free Tier / free credits；free credits 会从第一次 Gateway 请求开始计算，本地请求和线上请求都属于 Gateway 请求。
  • BYOK，也就是 Bring Your Own Key：你把自己的 provider key 配到 Vercel team，或按请求传给 Gateway。成功走 BYOK 时，通常按你和模型提供方的合同 / 账户计费；Vercel 不额外加 token markup。需要注意：如果 BYOK 失败并 fallback 到系统凭据，会消耗 Vercel Gateway credits。

BYOK 这条路尤其要写进团队的成本说明：provider 侧会产生费用，Gateway fallback 也可能产生费用，预算和告警要同时覆盖这两边。

从 demo 到生产要补哪些东西

最小项目已经跑通了 Web UI、HTTP 接口、模型调用、工具调用和工具步骤展示。接入真实客服系统时，还要用工程护栏约束这些能力；给 prompt 加几句「请谨慎」并不足够。

Agent 从 demo 到生产的能力栈

生产系统需要约束来自多个环节的风险：

  • 模型不确定：它可能理解错、输出格式错、选择错工具。
  • 工具不确定：外部 API 会超时、限流、返回脏数据，工具本身也可能有 bug。
  • 权限不确定：同一个用户在不同组织、项目和资源上的权限不同。
  • 任务不确定：长任务会中断，用户会刷新页面，进程会重启，后台任务会失败。
  • 成本不确定：一次 Agent run 可能包含多次模型调用、工具调用和沙箱运行。

日志和追踪

每次 Agent run 至少记录这些信息：

  • run id。
  • 用户或会话 id。
  • 模型、provider、fallback 命中情况。
  • prompt 版本。
  • 工具调用名称、参数摘要、执行结果、耗时。
  • token 和费用。
  • 最终状态：成功、失败、等待人工、超时、取消。

不要把敏感参数、完整用户数据和 token 明文写进日志。工具参数可以做摘要或脱敏。追踪的目标是复盘行为，不是复制一份用户隐私。

工具权限

每个工具都要标出风险等级：

  • read：不修改业务状态；通过数据权限、隐私和成本检查后，才可以自动调用。
  • draft：生成草稿，不产生外部副作用。
  • write_requires_approval：写操作，需要人工确认。
  • dangerous：高风险动作，只允许在后台受控流程里执行，默认不给普通 Agent。

工具权限最好写成代码配置，并在文档里同步解释。

type ToolRisk = 'read' | 'draft' | 'write_requires_approval' | 'dangerous';

type ToolPolicy = {
  risk: ToolRisk;
  allowedRoles: string[];
  timeoutMs: number;
};

const toolPolicies: Record<string, ToolPolicy> = {
  getOrderStatus: {
    risk: 'read',
    allowedRoles: ['support', 'admin'],
    timeoutMs: 5_000,
  },
  draftRefundRequest: {
    risk: 'draft',
    allowedRoles: ['support', 'admin'],
    timeoutMs: 5_000,
  },
};

测试和评估

Agent 的测试至少要覆盖几类样例：

  • 正常请求：能调用正确工具。
  • 缺少参数：会追问，不会乱猜。
  • 高风险请求：只生成草稿或要求确认。
  • 工具失败：能解释失败，不会假装成功。
  • 恶意输入：不会泄露 system prompt，不会越权调用工具。
  • 成本边界：不会无限循环调用工具。

最初可以用一组固定输入做回归测试。等流量变大，再引入离线评估、真实会话抽样、人工标注和自动 grader。

成本控制

Agent 的成本来自模型调用、工具调用、外部 API、沙箱运行、存储和日志。生产系统要设置几层预算：

  • 单次 run 最大 token。
  • 单次 run 最大工具次数。
  • 单用户每日预算。
  • 单项目 / 单团队预算。
  • provider fallback 的成本上限。
  • 沙箱运行时长和快照存储上限。

Vercel Gateway、LiteLLM 这类网关能集中处理一部分成本和预算。自建时，就要在数据库里记录 run 级别成本，并在调用前检查余额或限额。

人工介入

有些任务更适合保留人工确认。更好的体验是让 Agent 准备好材料，再交给人确认：

  • 发邮件前生成邮件草稿。
  • 建 PR 前生成 diff 和说明。
  • 退款前生成申请单。
  • 发布前生成 release checklist。
  • 删除数据前列出受影响对象和回滚方案。

人类确认属于 Agent 产品的一部分。高风险动作越多，审批状态、超时恢复和审计日志越重要。

模型 SDK、路由网关、工具授权、持久状态和任务调度是不同职责。不使用 Vercel 时，可以分别替换这些能力，再按实际需要组合。完整内容见不依赖 Vercel 的搭建路线弹窗。

平台选择应围绕工具权限、模型失败、长任务恢复、隔离和成本等约束，框架与部署位置也要分开比较。完整内容见Agent 平台与框架对照弹窗。

新手最容易低估的几个边界

  • 工具命名：工具清楚比工具数量更重要。一个 Agent 有二十个描述含糊的工具，会比只有五个清楚工具更不稳定。优先做好最常用、最安全、最容易验收的工具。
  • 上下文：把所有文档、日志、历史消息都塞给模型，不等于让它更懂。Agent 的上下文应该像工程输入一样被整理：当前目标、可用工具、必要历史、关键约束和最近结果。旧结果要总结，长材料要检索，敏感数据要脱敏。
  • 副作用：只读工具和写工具应该分开。写工具里，草稿、可撤销动作和不可逆动作也要分开。不要让「创建草稿」和「正式提交」共用同一个模糊工具。
  • 模型切换：多模型 fallback 能提高可用性，但不同模型的工具调用风格、结构化输出稳定性、上下文长度和成本都不一样。fallback 会带来行为差异，要用测试样例验证。
  • prompt 版本：Agent 行为高度依赖 system prompt 和工具描述。生产系统要给 prompt 版本号，并记录每次 run 用的是哪个版本。否则线上问题很难复盘。
  • 评估：Agent 要有固定测试集，覆盖正常、缺参数、拒绝、工具失败、权限、越权、长任务和成本边界，不能只看一两次 demo 成功。
  • 安全：prompt injection、工具越权、数据泄露、代码执行和供应链风险都是真问题。只要 Agent 能访问外部系统，就要从第一版开始设计最小权限和审计。

总结

生产 Agent 需要维持完整任务的约束：模型失败要有可观测的路由策略，不可信代码要隔离，外部凭据留在服务端，长任务保存恢复点，产生副作用的接口负责幂等与结果查询。网关、沙箱、授权和工作流可以分别选用，平台提供的重试与持久化不等于业务动作只执行一次。

步数、工具次数、超时、token 和费用需要各自有预算。记录脱敏的 run，覆盖失败、权限、fallback 与人工等待，才有依据判断一次演示能否进入真实业务；框架与部署位置也应从这些实际约束出发。

上一篇：用 AI SDK 跑通一个本地客服助手。

不依赖 Vercel 的搭建路线

不用 Vercel 时怎么搭

不用 Vercel 时，可以按工程职责寻找对应能力：

  • AI SDK 解决模型调用、stream、工具和结构化输出。可替代方案包括 OpenAI SDK、Anthropic SDK、LangChain、LlamaIndex，或者自写 provider adapter。
  • AI Gateway 解决多模型路由、fallback、日志、成本和统一凭据。可替代方案包括 LiteLLM、OpenRouter 和自建 OpenAI-compatible proxy。
  • Sandbox 解决不可信代码隔离执行。可替代方案包括 Docker、gVisor、Firecracker、Kubernetes Job 和 OpenAI-hosted sandbox。
  • Chat SDK 解决 Slack / Teams / Discord 等平台接入。可替代方案包括 Botkit、Bolt for Slack、Microsoft Bot Framework 和各平台 SDK。
  • Connect 解决第三方 API 授权和短期 token。可替代方案包括自建 OAuth 2.0、WorkOS、Auth0 和自建 connector 服务。
  • Workflow SDK 解决长任务持久化、重试和人工等待。可替代方案包括 Temporal、LangGraph checkpointer、Cloudflare Workflows、BullMQ + 数据库状态。

如果团队想完全自建，一个可落地的架构可以是：

自建 Agent：请求入口、运行时与支撑能力

自建时可以按需要逐项加入，而不是把所有部件都当成起步条件：

  • 一个 API Server。
  • 一个模型供应商。
  • 几个只读工具。
  • 需要跨请求保存状态时，用 Postgres 记录会话和 run。
  • 任务超出请求生命周期时，用队列运行。
  • 需要执行不可信代码时，配置 Docker 等隔离环境。
  • 需要运维和审计时，提供查看日志、工具调用与成本的后台入口。
Agent 平台与框架对照

平台怎么选

Agent 平台和任务形态选型图

对使用 Next.js 的前端团队，沿 AI SDK、AI Gateway、Sandbox 和 Workflow 开发，可以减少模型入口、隔离执行和长任务等部件的自建工作。采用这些平台能力后，需要接受 Vercel 的定价与限制，尤其是 Sandbox、Connect、Workflow 这些运行时能力。

如果你主要用 OpenAI，并且想在 TypeScript 或 Python 里用 code-first 的方式组织 Agent，可以看 OpenAI Agents SDK。官方文档把它定位成在代码里构建 Agent，支持工具、其他 Agent、跨步骤上下文，以及 tracing、guardrails、handoffs 等能力。它适合应用服务器自己掌握工具实现、状态存储和审批逻辑的场景。

复杂状态机里同时存在确定步骤和模型判断时，LangGraph 更合适。它的强项是把 Agent 编排成图，把确定性逻辑和 LLM 步骤混在同一个可持久化流程里。

如果你已经在 Cloudflare 上，或者想让每个用户 / 会话有自己的有状态 Agent，Cloudflare Agents 很有吸引力。它依赖 Durable Objects，适合 WebSocket、边缘部署、状态同步和长连接体验。

如果你最关心自建模型网关、统一 key、预算和 provider 路由，LiteLLM 是很现实的选择。它可以作为库用，也可以跑成自托管 proxy。它不替你写完整 Agent，但能把多供应商调用这一层统一掉。

如果你的企业里已经有 Temporal，或者任务天然是多天、多步骤、审批、重试和审计，Temporal 可以做 Agent 背后的流程脊梁。Agent 也可以只是 workflow 里的一个 activity，由工作流系统负责整体控制。

如果项目有国内合规、数据留境、采购流程或云厂商绑定要求，也可以优先看国产平台。它们和 Vercel 的定位可能不同，但都在解决「模型、工具、知识库、工作流、权限、发布」这些 Agent 落地问题：

  • 阿里云百炼 Model Studio：提供智能体和工作流两类应用构建方式，能接知识库、外部工具、记忆和 MCP 服务。适合企业知识问答、任务助理、固定流程自动化和阿里云体系内集成。
  • 百度千帆·大模型服务及 Agent 开发平台：围绕 Agent 引擎、工具及 MCP、模型服务和企业级服务搭能力底座。适合已经在百度智能云、搜索、知识库或企业 AI 服务上投入较多的团队。
  • 火山方舟 Managed Agents / Agent Plan：控制台可以配置模型、系统提示词、Skills、Tools、MCP 和 Multi Agents，也有 AgentKit 这类更工程化的基础设施。适合要把工具执行、MCP、代码类任务和多 Agent 协作接到业务里的团队。
  • 腾讯云智能体开发平台 ADP：提供 LLM + RAG、Workflow、Multi-agent、知识库、插件广场、连接器与工具。适合企业知识库、业务流程、腾讯云生态和低代码智能体应用。
  • 华为云 AI 原生应用引擎 / AgentArts：强调 Agent 编排、工作流、数据连接、知识库、MCP 和企业云资源协同。适合政企、工业、云上数据治理要求较强的场景。
  • 智谱 AI 智能体开发平台：提供画布式节点、Agent 节点、LLM 节点、知识库、联网搜索、代码节点、工具节点和插件中心。适合 GLM 体系、低代码智能体、知识问答和需要批量调试的业务应用。
  • Kimi API 开放平台：提供文本生成、多轮对话、文件解析、联网搜索等能力，兼容 OpenAI API 格式。适合长文档、文件解析、知识工作和希望低成本迁移 OpenAI 风格接口的团队。
  • MiniMax 开放平台：覆盖文本、多轮对话、语音、视频、图片、音乐、音色管理等能力。它更偏多模态能力平台，适合语音客服、内容生成、视频 Agent 和需要音视频能力的产品。

如果只能先学一条路线，我建议从「普通 HTTP route + AI SDK / OpenAI SDK + 两三个工具 + 数据库记录 run」开始。这个组合最容易看清 Agent 的核心机制：模型怎么选择工具，工具结果怎么回到模型，权限和人工确认怎么插进去。等你真的遇到长任务、复杂图编排或多模型治理，再引入 LangGraph、Temporal、LiteLLM 或 Vercel Gateway 这类基础设施，会比一开始就堆全家桶稳很多。

一个简单选型口径是：

  • 个人 demo / 小产品：AI SDK 或 OpenAI SDK 直接起步。
  • Next.js 产品快速上线：Vercel AI SDK + AI Gateway，按需加 Sandbox 和 Workflow。
  • 多模型、多团队统一治理：LiteLLM 或 Vercel AI Gateway。
  • 复杂 Agent 编排：LangGraph。
  • 边缘、有状态、实时连接：Cloudflare Agents。
  • 长流程和强审计：Temporal 或 Vercel Workflow。
  • 强 OpenAI 生态和内置工具：OpenAI Agents SDK / Agents API。

先问你的任务最怕什么：模型供应商失败、工具越权、长任务丢状态、代码执行不安全、成本不可控，还是用户体验不实时。最怕的问题不同，平台选择就会不同。