本文作者：泊舟（@bozhou_ai）。版权归作者所有，未经授权禁止转载。
6 个检查项——手把手带你发布自己的 Agent 产品
「导读」：一次实操教学，带你开发自己的 Agent 应用
- 6 大关键瓶颈解读
- 手把手实操讲解
端午前，姐姐想让我用 AI 给我那俩小侄子做个成长记录小程序。前置工作落我头上：先部署好一套 Agent 写 App 的服务。说干就干——本以为很简单，毕竟 Agent 教程我出了那么多期。
但真正开始做才发现，把一个本地跑通的 Agent 变成别人能用的线上产品，中间要补的东西比我想象的多得多：会话记忆存哪里、代码执行怎么隔离、Token 成本怎么控、前端页面和域名谁来管……
这次经历让我意识到一件事：Agent 商业化的第一道门槛，不是模型能力，而是交付能力。
从 0 开始开发太累了，去 Product Hunt 上看了下，发现了一个日榜和周榜双料 Top 1 的 Agent 开发部署产品，叫 EdgeOne Makers，查了下发现是腾讯云的。
我的原则是能不用造轮子就绝对不造轮子，所以我直接用 EdgeOne Makers 来完成我姐姐的要求，结合具 Agent 编写 APP 等实际场景，手把手带大伙从零跑通并上线一个 Agent。
让我们专注于实战，不去说怎么写一个 Agent Demo，而是讲一个 Agent 上线前，至少要过哪 6 个检查项。后半部分我会实际跑一遍，看看这些工程问题如何去解决。
检查项 1：会话记忆是否可持续
本地 Demo 阶段的记忆方案非常简单——一个 Python dict、一个全局变量，或者直接把历史消息塞在 prompt 里。进程一重启，记忆清零；用户刷新页面，上下文全部丢失。Demo 演示的时候你只需要关心眼前这一轮对话，出错了大不了重启。
但真实产品里，用户会回来、会继续上次的任务、会期待 Agent 记住之前聊过的上下文。你想想自己用 ChatGPT 的时候，是不是经常翻回旧对话继续问？你的用户也一样。
产品化的记忆要解决三层问题，每一层都有对应的技术方案：
短期记忆——当前会话的上下文。
用户追问「那刚才那个呢？」时，Agent 要知道「刚才那个」指什么。这不是靠无脑在 prompt 里塞历史消息就够的。GPT-4 的上下文窗口是 128K token，Claude 可以到 200K，看起来够大，但你的 Agent 每次都要把完整历史重新发给模型——每一次调用都在烧 Token。而且上下文越长，模型的注意力越分散，回答质量反而可能下降。
所以真正可用的短期记忆需要做：滑动窗口截断（只保留最近 N 轮）、摘要压缩（用一个小模型把历史对话压缩成一段摘要）、或者混合策略（近期消息保留原文，远期消息只保留摘要）。这些逻辑看起来不复杂，但你要自己手写一套可靠的实现，光边界 case 就能出不少 bug。
长期记忆——跨会话的偏好和知识。
用户说过「我是一个后端开发，只关心中文回答」，三天后再打开，Agent 应该还记得。这通常需要接一个向量数据库——把用户的历史对话、偏好、关键信息做 embedding 存下来，每次新对话时检索相关记忆片段注入上下文。
技术栈选型蛮多的：轻量可以上 Chroma（Python 一行 pip install），需要 scale 可以上 Pinecone 或 pgvector。但问题不在于选哪个库，问题在于你要额外维护一套向量数据库服务，处理 embedding 调用的成本和延迟，还要在检索回来的片段和当前对话之间做相关性排序。又是一套系统。
多用户隔离——A 的记忆不能串给 B。
Demo 阶段只有一个用户——你自己。产品阶段，一百个用户同时在线，每个人的对话历史和偏好要严格隔离。最简单的方案是 user_id 做分区——所有存储操作以 user_id 为前缀，Redis 里存 session 用 session:{user_id}:{session_id} 做 key，向量数据库里存记忆用 user_id 做 namespace。方案成熟，但每一层你都得亲手接。
这三层加在一起，如果你从零开始搭——Redis 做短期会话、向量数据库做长期记忆、user_id 做隔离分区——整套搭下来，调试通了，一两天就过去了。
检查项 2：工具调用是否有沙箱
Agent 越有用，越会接触外部世界：联网搜索、读写文件、执行代码、调用浏览器、访问第三方 API。这些能力正是 Agent 区别于普通聊天机器人的核心。
Demo 阶段，这些能力直接跑在你的本地机器上——你自己的电脑，权限全开，出错了 ctrl+c 就行。
产品阶段，你需要面对一个基本的安全问题：用户提交的代码，凭什么能在你的服务器上跑？
这不是危言耸听。一个 Agent 被 prompt injection 诱导执行了 os.system("rm -rf /") ——这种事在 AI 安全圈已经不是新闻了。即便不是恶意输入，用户正常使用——「帮我处理这个 CSV 文件并生成图表」——背后可能是几百行 Python 脚本在跑，万一写了个死循环或者把内存吃满了，你不能让整个服务跟着挂掉。
自己搭沙箱的常规路径是 Docker 容器隔离：每个用户会话起一个独立容器，限制 CPU 和内存（--cpus=1 --memory=512m），设置超时 kill（比如代码执行超过 30 秒直接终止），网络隔离防止访问内网资源。能搭出来，但你要写的不是 Agent 逻辑，而是容器编排、资源监控、异常处理——这些跟你的业务代码一点关系都没有。
更麻烦的是资源效率。如果你把 Agent 逻辑本身也打包进同一个容器，那每次改一行 Agent 逻辑，你都得重建包含完整工具链的镜像。并发场景下，每个对话独占一个完整沙箱，10 个用户就是 10 个容器，100 个用户呢？资源开销堆得很快。
这也是为什么更成熟的架构会做解耦：Agent 逻辑、工具沙箱、会话状态各自独立，按各自生命周期调度。沙箱按需创建、空闲回收，Agent 逻辑可以独立更新。但这又涉及沙箱生命周期管理、跨组件的状态同步——你在搭基础设施，不是在写产品。
检查项 3：调用链路是否可追踪
Agent 跟普通 API 最大的区别在于：一次用户请求背后可能是一个多步推理链。
一个简单的「帮我查一下 EdgeOne Makers 支持哪些模型」可能经过这样的链路：
用户输入 → Agent 决策（该不该调工具？） → 调用 web_search 工具（搜索"EdgeOne Makers 支持的模型"） → 工具返回搜索结果（5 条网页摘要） → Agent 再决策（信息够不够回答？） → 调用 LLM 生成最终回复 → 返回给用户
中间任何一个环节出问题——搜索返回了空结果、工具超时、LLM 理解错了搜索结果——最终呈现给用户的都是一个「回答错了」。但到底是哪一步错了？Demo 阶段你肉眼盯着终端日志就能看出来。产品阶段，用户报告一个错误，你看到的只有最终输出。
没有全链路追踪，Agent 产品上线后就是一个黑盒。
自己搭追踪系统的技术路径不复杂——OpenTelemetry 做 instrumentation，Jaeger 或 Grafana Tempo 做后端，给每个请求生成一个 trace_id，在每个调用节点注入 span。但问题是：你要给 LLM 调用加 span、给每次工具调用加 span、给 session 读写加 span、给 RAG 检索加 span……你是来写 Agent 的，不是来写 APM 的。
而且，Agent 的调试需求跟传统微服务不一样。你看的不只是「哪个接口慢了」，你需要知道的是：那个工具调用返回了什么具体内容？模型在那个节点看到了什么上下文？ 这要求追踪系统能记录工具调用的输入输出、LLM 请求的完整 prompt 和 response——不是简单的 latency 数据，而是完整的执行轨迹。
检查项 4：模型成本是否可控
Demo 可以不算账，产品必须算账。
你写 Demo 的时候一个月烧几十块钱 API 费用无所谓。但产品上线后，每个用户每次对话都在消耗 Token。假设你用的是 Claude Sonnet，一个中等长度的对话大概 2000 input token + 500 output token，按 Anthropic 现在的定价，一次对话差不多 $0.01。看起来不多。但如果你有一千个日活用户、每人每天平均 5 轮对话——一天就是 $50，一个月 $1500。这还没算工具调用里附带的大段上下文、RAG 检索注入的文档片段。
成本控制需要几层能力：
用量可见性。 每个用户、每次对话、每个环节消耗了多少 Token？有没有办法看到用量分布？哪些用户是「重度用户」占了 80% 的 Token？没有数据就不存在优化。
模型分层路由。 简单问题用便宜的模型（比如 Haiku 或 DeepSeek），复杂问题才上 Claude Sonnet 或 GPT-4。很多 Agent 产品的实际 token 消耗里，70% 是简单问候、确认、总结这类低难度任务——用最贵的模型回答「好的，请稍等」是纯粹浪费。
自有 Key 接入。 如果你的团队有 bulk 折扣的 API Key，能不能用自己的 Key 而不被平台锁定？这一点直接关系到规模化后的利润率。
成本预警。 别等到月底收到账单才发现超支。常见的做法是设置日预算上限和告警阈值——但这又意味着一套监控告警系统。
你在设计 Agent 的时候就该想这些事——prompt 的长度、上下文窗口如何管理、工具调用的次数是否必要——每一项设计决策都在影响最终的账单。
检查项 5：Web 和 Agent 是否是一套交付链路
这是一个很容易被忽视的问题。因为它跟「Agent 写得好不好」完全无关——但它直接决定了用户能不能用上你的 Agent。
用户不会直接调用一个后端 API。他们看到的是一个网页：有登录注册、有输入框、有对话历史、有按钮、有域名。Agent 是后端能力，用户接触的是前端产品。
传统玩法往往是拆开的：静态前端放在 COS、S3、OOS 这类对象存储或纯静态托管服务上，Agent 后端再单独跑在一台云服务器上，中间靠 HTTP API 通信。麻烦随之而来：
- 域名要单独配 CORS——前端在 app.example.com，后端在 api.example.com，跨域请求要手动配。
- 用户认证要自己搭——前端 JWT、后端验证、token 刷新，又是一套 boilerplate。
- 日志要看两个地方——前端报错在 Vercel 的 dashboard，后端报错在服务器日志里，排查问题时两个面板来回切。
- 部署是两次操作——前端改了 UI，部署一次；Agent 逻辑改了，再部署一次。一旦前端和后端接口不兼容，用户就看到白屏或者 500。
你要的是一个统一的项目交付体验：前端页面和 Agent 逻辑在同一个项目里，一次部署同时上线，同一个域名对外服务，日志、监控、域名都在一个地方管。
自己不是不能做到——前端放在 web/ 目录、Agent 放在 agents/ 目录，写一个 monorepo 的构建脚本，用一个反向代理统一路由。但你算算配置和调试的时间，再看看你做 Agent 的初衷——你是想写 Agent 逻辑，还是想写 DevOps？
检查项 6：平台是否锁框架、锁语言、锁模型
Agent 框架变化极快。去年大家还在用 LangChain，今年 LangGraph 和 CrewAI 起来了；上个月 OpenAI 发新模型，这个月 Anthropic 更新 Claude Sonnet。你的 Agent 可能现在用的是 OpenAI SDK，三个月后你可能想切 Claude Agent SDK，因为你发现在某些任务上 Claude 的效果更好。
如果你选的部署平台强制你必须用它的 SDK、只能用它支持的框架、只能调用它指定的模型——你就被锁住了。
要检查的项目非常具体：
框架自由度。 你的代码里是不是必须 import { Agent } from '@platform/agent-sdk'？还是你可以直接使用 @anthropic-ai/sdk 或 openai 的 npm 包，平台在运行时注入环境变量和基础设施能力？前者意味着换平台要重写代码，后者意味着你的 Agent 代码可以带着走。
语言自由度。 JS/TypeScript 和 Python 都支持吗？Agent 开发圈子里 Python 生态仍然是最活跃的，大部分 AI SDK 和工具链都是 Python-first。如果平台只支持 JS，Python 开发者就得重写代码或者找 bridge 方案。
模型自由度。 你能不能在 OpenAI、Anthropic、DeepSeek、混元之间自由切换？切换成本是改一行 model name，还是得换整个 provider 适配层？平台有没有内置的模型网关帮你统一调用接口？
迁移成本。 如果将来你想把 Agent 迁移到自建服务器或其他平台，你的代码里有多少行是业务逻辑（可以带走），多少行是平台胶水代码（带不走）？
选平台最重要的一条，不是「它提供了什么」，而是「它有没有剥夺你的选择权」。
实操：从 0 到 1 部署一个代码生成 Agent
从注册到项目创建
6 个检查项，每一项单独拎出来都不算难，都有成熟的开源方案。但六项加在一起——记忆、沙箱、追踪、成本、前端集成、框架自由度——你要同时搞定这些，一两周就过去了。
首先进入 EdgeOne Makers 官网，直接访问就行：https://pages.edgeone.ai/
登录或者注册用户，我这里直接选择谷歌登录，非常方便。
进入控制台，选择「立即开通」，创建新项目。在管理端，这个项目算得上是极致便捷类：Web 前端和 Agent 后端在同一个项目体系下创建和管理，不需要分开处理。你不会遇到前端在 Vercel、后端在服务器、域名要单独配 CORS 的拆分问题。
在这里选择「创建 Agents」。
选择模板，确认框架自由度
进入后选择模板，由于我的目标是实现一个可以制作小程序的 Agent 产品，我这里选择「内容生成」板块下的「代码生成助手」。
Makers 的模板市场覆盖了主流 Agent 框架——Claude Agent SDK、OpenAI Agents SDK、LangGraph、CrewAI、DeepAgents 都有对应的 starter。Python 和 JavaScript 都不限制，你可以按自己的技术栈来。
关键的一点：Makers 没有自己的 Agent SDK。你在 handler 里用的是原生框架的 API——from anthropic import Anthropic 或是 import OpenAI from 'openai'——平台通过 context 对象把基础设施能力（网关密钥、会话存储、沙箱等）注入给你，不要求你 import 任何平台专属包。这意味着你的 Agent 核心逻辑是可迁移的——将来如果想换平台，业务代码不需要重写。
配置与创建：三项能力一次性获得
然后进入创建与配置环节，我这里选择的 Git 是 GitHub：
我们直接选择「立即创建」即可：
配置过程几乎是一键式完成。
在创建完成后，项目实现了一键式部署，可以看到，一个项目可以同时包含前端页面和 Agent 逻辑——项目目录里 web/ 放前端代码，agents/ 放 Agent handler，一次部署同时上线，同一个域名对外服务。
模型成本控制：
平台内置了 AI 网关。部署后你的 Agent handler 会通过环境变量自动注入 AI_GATEWAY_API_KEY 和 AI_GATEWAY_BASE_URL，直接传入 OpenAI SDK 或 Anthropic SDK 就能走平台网关调用模型。不需要自己去各个模型厂商分别申请 Key、分别管理账单。
平台限时赠送模型 Token 额度（Beta 期间 50 万/月免费）。如果使用 EdgeOne Makers 内置模型，Base URL 需要指定为 https://ai-gateway.edgeone.link/v1，模型可以从 @makers/deepseek-v4-flash、@makers/hy3-preview、@makers/minimax-m2.7 中选择。后续如果绑定自己的模型 Key，也可以通过统一网关接入其他厂商模型；如果直接调用其他厂商接口，则 Base URL 和模型名要按对应厂商配置。
会话记忆：
Agent 默认具备会话记忆能力。handler 里通过 context.store.openaiSession(conversation_id) 拿到的就是框架原生的 Session 对象，传给 run() 后对话历史读写全被平台接管。底层由平台的 Blob 存储做持久化——刷新页面、换设备、隔几天再来，上下文都在。不同 conversation_id 之间的记忆天然隔离，不存在用户 A 看到用户 B 对话的问题。用 LangGraph 或 Claude Agent SDK 也一样，context.store 上挂有各自框架原生的会话存储适配。
工具沙箱：
Agent 调用代码执行、网页搜索等工具时，平台自动启动隔离沙箱。沙箱不是传统的 Docker 容器——是更轻量的微 VM，首次调用工具时懒加载，同一对话内复用，超时闲置自动回收。这意味着你不用写一行 Dockerfile，不用配 --cpus 和 --memory，沙箱隔离和资源管控是平台的事。
这三件事如果自己搭——AI 网关、会话持久化、沙箱隔离——每一项都是按天计算的工作量。这里一次创建全部就绪，对我来说是实实在在的加分项。
部署与追踪验证
一键式跑完以后，自动生成了项目目录。可以看到，一个项目可以同时包含前端页面和 Agent 逻辑——项目目录里 web/ 放前端代码，agents/ 放 Agent handler，一次部署同时上线，同一个域名对外服务。
部署好的 Agent 是一个 APP 开发 Agent，你向它提出需求，它实现代码，并且能够在前端直接预览 APP 效果。来看一下部署好的初始模板，简洁的黑绿色设计，避免了常见的紫黑色科技风 AI 味风格，我还是挺喜欢的。不过后续不知道姐姐的意见是怎么样，反正前端模版多的是，换成她喜欢的就好：
为了防止出现意料之外的问题，我决定先亲自测试一下这个项目的实际能力。让我们来尝试一下功能是否健全，来一个最经典的番茄钟任务：
左侧可以看到完整的 Agent 输出流：
在项目代码实现后，用户可以点击「预览按钮」，一键预览实现的效果：
可以看到，项目的完成度相当不错，页面干净清晰，功能实现完整，且视觉元素十分的和谐。
不过就像前文说的，我不需要一个 demo 形式的纸壳子，我需要的是能够完整交付的项目级产品。让我们回到调用链路，检查一下刚刚任务的调用链路是否清晰。进入后台，部署完成后，控制台里可以看到完整的调用链路追踪。
但这里的追踪不是只给你看「哪个接口慢了」——Agent 跟传统 API 不一样，一次用户请求背后是一次多步推理。Makers 的追踪面板记录的是完整的执行轨迹：每一轮对话里 Agent 调了哪个模型、输入和输出分别是什么、中间调用了哪些工具、工具返回了什么内容、Session 读写的耗时和状态。本地开发时可以看到完整链路，部署到平台后也能继续通过平台能力查看运行过程，不需要额外接一套复杂埋点。
Agent 上线后出问题，你不需要只对一个「回答错了」瞪眼——你可以拆开来看：是模型在这一步的推理出错了？还是 web_search 工具返回了一个空结果？还是上一步的上下文没有正确传入？
全链路可见，问题可定位，才能持续优化。
适合谁，不适合谁
适合：
- 已经有一个 Agent 想法，准备给真实用户使用的人。你不用先花两周搭记忆、沙箱、追踪和部署管线——用 Makers 一个下午就能把 Agent 上线，先验证想法再说。
- 想把经验、咨询、知识库、自动化流程产品化的人。你的核心竞争力在业务逻辑和 prompt 设计上，不在搭沙箱和配监控。Makers 让你专注于 Agent 本身，基础设施是透明的。
- 不想被特定框架和语言锁定的开发者。Makers 没有平台 SDK，你写的 Agent 代码用的是原生框架 API——将来即使迁移到自建服务器，核心逻辑不需要重写。
不适合：
- 只是本地玩 prompt，还没有明确用户和产品形态的人。先做出一个能给其他人用的 Demo，等你有「这东西要上线」的念头时再来看这篇文章。
- 只想快速试模型效果，不关心部署和交付的人。Makers 的价值在「把 Agent 变成线上服务」——如果你还没到需要交付这一步，它帮不了你太多。
- 对基础设施有极端定制要求、已经有完整运维团队的人。如果你需要自定义 K8s 集群、自建向量数据库集群、精细到容器级别的资源调度——那自建基建可能更适合你的场景。
写在最后
我觉得 EdgeOne Makers 这种开发最适合的，不是「还在本地玩 Agent 的人」，而是已经有一个 Agent 想法，准备把它给真实用户使用的人。
Agent 商业化的第一道门槛不是模型能力——现在的模型已经够强了。真正的门槛是交付能力：你的 Agent 能不能作为一个稳定的、可追踪的、成本可控的线上服务，7×24 小时不停歇地跑着？
如果你想验证一个 Agent 能不能变成产品，第一步不是继续堆 prompt，而是先把它部署成一个真正的线上服务。
你现在手头有没有一个停在 Demo 阶段的 Agent？如果有，先拿着这 6 个检查项对照一遍，看看差在哪——然后在评论区告诉我，你最头疼的是哪一项。
顺便分享一个粉丝福利：EdgeOne Makers 平台上线，每个用户免费享有 50 万 / 月 Token，还可叠加多项任务福利，最高可领 5000 万 Token。通过我的专属邀请码（69266955）进入并完成部署，再额外增送 +50 万 Token。
体验入口链接：
- 中国站：https://cloud.tencent.com/act/pro/edgeone-makers-agent?from=30155
- 国际站：https://pages.edgeone.ai/solutions/ai-agent?activity=bozhou
#腾讯云 #EdgeOne #AIAgent #EdgeOneMakers
