从 Demo 到上线，Agent 还差一套工程化底座

海外 Agent 基础设施正在快速平台化。Vercel、Cloudflare、GitHub 这些开发者平台不只是在接模型，而是在补部署、长任务运行、沙箱、观测、模型网关、权限和成本治理。

国内现在不缺模型，也不缺 Agent 框架，缺的是一套足够顺手的工程化底座。很多团队能把 Demo 做出来，但一到上线，就要自己拼前端托管、后端函数、Agent runtime、沙箱、认证、trace 和模型入口。

最近腾讯最新推出的 EdgeOne Makers 正好可以放在这个背景下看。

从官方文档看，它把 Agent runtime、沙箱工具、会话存储、调用追踪、模型接入、Serverless Functions、Git 部署和认证方案放到一个平台里，更像一套 Agent 应用部署底座。

先说结论

现在做 Agent Demo 已经不难。一个前端页面，一个模型 API，一点提示词，再加上几个工具调用，很快就能跑起来。真正麻烦的是下一步：

Agent 运行在哪里？
多轮任务怎么保持会话？
长任务怎么不被普通请求超时卡住？
工具执行是不是有沙箱？
模型 Key 怎么管理？
调用链路能不能追踪？
用户能不能直接绕过前端打 Agent API？
Git 提交后能不能自动部署？
模型供应商变了，业务代码要不要跟着改？

这些问题，对应到 EdgeOne Makers 官方文档里的几项核心能力：

能力	官方文档里的定位
Managed Runtime	承载 LLM 调用、Agent loop 编排和业务逻辑，并按会话路由、自动扩缩容
Sandbox Tool	在隔离沙箱里运行浏览器、代码执行、Shell 和文件操作
Conversation Storage	适配多种 Agent 框架，提供会话与消息管理
Observability	自动收集调用链路，支持本地和云端面板查看 trace 数据
Built-in Models	自动注入模型密钥，并提供限时每月免费模型额度

这说明 EdgeOne Makers 关注的不是单次模型调用，而是 Agent 上线后的运行、工具、状态、观测和权限边界。

项目模型

EdgeOne Makers 把普通 Web 应用和 Agent 应用放进同一个项目结构。官方文档里写到，同一个项目下可以有两类后端运行模式：

目录	运行模式	适合场景
`agents/`	Session mode	LLM 调用、Agent loop、长任务编排
`cloud-functions/`	Request mode	非 LLM 业务逻辑、数据查询、辅助 API

cloud-functions/ 是普通 Serverless 请求模型。agents/ 更适合长任务：它会按 conversation_id 做会话粘性，把同一个会话的请求路由到同一个实例，复用上下文、缓存和连接。官方文档也写到，单次执行最长可配置到 60 分钟，适合多轮 Agent loop、重复工具调用和深度研究。

这个设计的意义在于，Agent 不再是旁路服务。

过去很多团队做 AI 应用时，会把 Web 前端、普通后端 API、Agent 服务、模型调用层、工具执行服务、任务队列和日志系统拆开。一开始看着灵活，后面容易变成运维和权限治理负担。EdgeOne Makers 的思路更像是：

Web 应用、普通 Functions、Agent Runtime、模型入口和部署流程应该尽量收进同一个平台模型。

这和 Vercel、Cloudflare 最近的方向接近：开发者平台不再只托管静态页面或函数，而是在补齐 AI 应用需要的运行原语。

沙箱边界

Agent 和 Chatbot 最大的差别之一，是 Agent 要执行动作。它可能要：

打开网页；
读写文件；
执行代码；
运行 Shell；
分析 CSV、PDF、图片；
修改项目并返回预览结果。

这些动作一旦进入真实环境，风险就比普通问答大很多。沙箱不是锦上添花，而是基础设施的一层。

EdgeOne Makers 官方文档里提到，Sandbox Tool 同时提供给 LLM 和开发者使用，浏览器、代码执行、Shell、文件操作都运行在隔离沙箱环境里。

它的重点不是“Agent 终于会执行命令”，而是把工具执行从开发者主机、业务后端和真实生产环境里隔离出来，让 Agent 的动作有明确边界。

Agent 越能动手，越需要沙箱、权限和可观测性。

EdgeOne Makers 免费版额度文档里也列了资源边界，例如 Agents 每月执行次数、单次请求最长运行时间，以及 Sandbox 单实例最大运行时间、默认超时等限制。具体额度未来可能变化，但可以看出平台已经把“Agent 长任务”和“沙箱资源管理”当成产品化对象。

记忆与追踪

普通接口大多是一次请求，一次返回。Agent 更像一个循环：

接收目标；
调用模型；
判断下一步；
执行工具；
读取结果；
再次调用模型；
继续推进或停止。

因此，Agent 应用要观测的不是一个 HTTP 状态码，而是一条任务链路。

EdgeOne Makers 的 context.store 提供会话级对话存储，会根据 conversation_id 关联，并支持多种 Agent 框架的消息对象。

它的 context.tracer 则用于手动埋点，可以和平台自动采集的 trace 串到同一条链路里。

这类能力对生产环境很关键。Agent 出错时，团队需要知道它看到了什么、做了什么、为什么继续往下走：

当时模型看到了什么上下文；
它调用了哪个工具，工具返回了什么；
哪一步开始偏离目标；
是否需要重试、回滚或人工介入。

Agent 进入平台化以后，可观测性要从“看接口耗时和错误率”升级到“看任务过程和动作链路”。

API 认证

EdgeOne Makers 官方文档单独写了 Agent Authentication。文档明确提到，如果没有登录认证，任何人都可以直接访问 Agent API，可能造成资源滥用，也可能绕过前端页面直接请求 /agents/* 等接口。

官方示例方案包括：

用 Cloud Functions 处理注册、登录、登出和当前用户查询；
登录后签发 JWT；
JWT 放到 HttpOnly Cookie；
middleware 在边缘节点提前拦截未认证请求；
Agent 入口里再做签名校验。

这个方案不复杂，但很必要。Agent API 被刷，不只是流量问题，还会消耗模型额度、沙箱资源、工具调用次数，甚至可能触发外部系统动作。认证、限流、权限、审计，都必须落到真实接口层。

模型接入

EdgeOne Makers 还有一个 Models 服务。官方文档说，它是部署在 EdgeOne 边缘节点上的统一模型接入服务，可以通过统一 endpoint 和一个 API Key 调用多个主流模型供应商。

它支持的点包括：

统一 endpoint，切模型时主要改 model 参数；
兼容 OpenAI SDK、Anthropic SDK、Vercel AI SDK，也支持 cURL、fetch 这类 HTTP 调用；
支持托管供应商 Key，调用时只带网关自己的 API Key；
有内置模型可直接使用，适合 Demo 和技术验证；
支持 SSE 流式输出。

官方示例里，OpenAI JS SDK 可以这样接：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.MAKERS_MODELS_KEY,
  baseURL: "https://ai-gateway.edgeone.link/v1",
});

const completion = await client.chat.completions.create({
  model: "@makers/deepseek-v4-flash",
  messages: [{ role: "user", content: "What can you do?" }],
});

这个能力适合平台内应用快速起步。开发者不用一开始就自己写模型适配层，也不用把不同供应商的 Key 散落在业务代码里。

但这里也要冷静看。

和 Vercel AI Gateway、Cloudflare AI Gateway 这类平台能力类似，平台内置模型网关的优点是集成顺滑，缺点是 Provider 选择和路由策略通常会受平台产品节奏限制。

真实团队里，模型接入往往比“调用几个主流模型”复杂：

有公有云模型；
有海外模型；
有国内模型；
有自托管模型；
有内部私有模型；
有不同业务线自己的 API Key；
有按用户、项目、路线、供应商分开的预算和审计；
有 OpenAI、Anthropic、Gemini 多种协议并存；
还有供应商故障、额度耗尽、价格变化后的路由切换。

这时，仅靠某个平台自带的模型入口，灵活性可能不够。

如果你希望把模型接入层独立出来，而不是完全绑定某个部署平台，也可以单独使用我的开源AI网关 OctaFuse Gateway：https://github.com/OctaFuse/octafuse-gateway

按照项目 README，OctaFuse Gateway 是一个开源 AI 网关，采用 Proxy + Admin + Core 结构，提供 OpenAI Anthropic Gemini 兼容的推理 Proxy，并支持 Cloudflare（D1）或自托管（Postgres/MySQL）部署。它关注团队和组织内部的模型流量治理，包括：

多协议入口：OpenAI、Anthropic、Gemini 兼容接口；
Provider、模型、Route、Route Group 管理；
用户和 API Key 管理；
预算上限和周期重置；
请求日志、用户审计和可观测性；
供应商、模型、用户维度的用量分析；
Cloudflare Worker + Pages + D1 或 Docker Node + Postgres MySQL 部署。

两者位置不同：EdgeOne Makers 更靠近应用部署平台，OctaFuse Gateway 更靠近独立模型接入和治理层。

如果 Agent 应用就跑在 EdgeOne Makers 里，并且内置模型入口已经满足需求，直接用平台能力最省事。

如果你有跨平台、跨业务线、跨供应商的模型治理需求，或者不希望模型路由、预算、审计完全绑定某个部署平台，把模型入口单独抽成 OctaFuse 这样的网关会更灵活。

Git 部署

部署体验上，EdgeOne Makers 也很像现代 Web 平台。官方文档写到，它支持导入 Git 仓库，目前可以集成 GitHub、GitLab、Bitbucket、Gitee 等 Git providers。

基本流程是：

登录控制台；
绑定 Git 平台；
选择仓库；
配置构建命令；
选择加速区域；
开始部署；
后续推送到部署分支时，平台自动拉取并部署最新提交。

它也支持从模板创建项目。官方文档说，基于模板创建项目时，会在你的 GitHub 账号下创建一个仓库，后续可以 clone 到本地继续开发，再通过 push 触发部署。

这说明 Agent 应用正在复用 Web 应用过去十年形成的交付路径：

Git 仓库即项目，push 即部署，平台负责构建、运行和加速。

如果 Agent 应用不能进入标准工程流程，就很难被团队长期维护，最后容易变成一堆 notebook、脚本、Demo 服务和没人敢动的临时项目。

适合场景

从当前官方文档看，EdgeOne Makers 更适合这些场景：

场景	为什么适合
Agent 原型和轻量产品	Web、Functions、Agents、模型入口和部署流程放在一起，启动成本低
多轮对话和长任务 Agent	Session mode、会话粘性和较长执行时间更贴近 Agent loop
需要工具执行的 Agent	Sandbox Tool 提供浏览器、代码、Shell、文件操作的隔离环境
需要公网访问的 AI 应用	官方提供认证方案参考，避免 Agent API 裸露
小团队快速验证	可以少拼一套 runtime、trace、storage、model gateway

它不是万能答案。如果团队已有成熟的 Kubernetes、私有云、内部权限系统、统一日志体系和模型网关，直接迁移未必合适。如果模型供应商选择、预算核算、审计要求很复杂，也可能需要独立 AI Gateway 承接。

另外，官方文档写到，当前免费版额度是目前生效的限制，商业版正在规划中，后续价格和配额会通过控制台公告更新。所以它更适合先做验证、原型、轻量应用和平台能力评估，而不是一开始就假设生产成本已经确定。

小结

EdgeOne Makers 的价值，不在于多提供了一个 Agent 框架，而在于它代表了一类平台方向：

Agent 应用正在被云平台重新包装成一种可部署、可观测、可认证、可运行长任务的应用形态。

模型会继续进步，Agent 框架也会继续变化，但真正决定团队能不能用起来的，往往是部署、沙箱、认证、Trace、会话存储、模型入口、预算审计和 Git 交付流程。

开发者看这类平台时，不必只问“它支持哪个模型”，更应该问这些问题：

我的 Agent 怎么上线？
长任务怎么跑？
工具执行在哪里隔离？
出错时能不能回放过程？
未登录用户能不能直接打接口？
模型接入是否被平台锁死？
后续是否需要独立 AI Gateway 做治理？

Agent 进入生产以后，比拼的不只是模型效果，而是谁能把运行、权限、成本和观测这些工程问题收拾干净。

资料来源

Makers Agents 官方文档：https://pages.edgeone.ai/document/agents
Makers Models 官方文档：https://pages.edgeone.ai/document/models
Git 仓库导入部署文档：https://pages.edgeone.ai/document/importing-a-git-repository
Agent Authentication 官方文档：https://pages.edgeone.ai/document/agents-authentication
免费版额度限制：https://pages.edgeone.ai/document/limits-and-quotas
OctaFuse Gateway：https://github.com/OctaFuse/octafuse-gateway