在腾讯云 EdgeOne Makers 上部署一个「健康管理智能体」

原创

鲈鲈鲈鲈鲈鱼

修改于 2026-06-22 20:11:41

4500

很多人都想认真管一下自己的饮食，但真正坚持下来的不多。原因往往不在于不懂道理，而在于记录太麻烦：吃一顿饭，要拍照、要查热量、要换算份量、要手动填进某个 App，几天下来就放弃了。用户真正想要的，其实是一个容易交流的助手应用：随口说一句“中午吃了一碗牛肉面加个蛋”，它就能帮你估出热量、记下这一餐，并随时告诉你“今天还能吃什么”。把这件事做成一个随时在线、可访问、能持续迭代的智能体服务，显然比反复人工答疑更理想。

而 Makers 正是这样一套面向 Agent 应用的托管底座。它把 Agent 从开发到上线过程中最容易分散精力的基础能力先托住：运行沙箱负责执行必要命令，上下文记忆和流式响应保证对话体验，工具调用链路让 Agent 能完成指定任务，AI 网关把模型选择从业务代码里解耦出来；上线后，追踪观测、版本管理、自定义域名等功能都集中在一个控制台中，让 Agent 可以稳定地被用户访问和持续迭代。开发者要做的不是从零搭一套 Agent 基础设施，仅需在这套托管链路上填入自己的业务能力，可以把主要精力放在经验的结构化、业务工具的接入以及最终用户体验的打磨上。

在这个案例里，我们就以「轻食记 · 健康饮食助手」为例，梳理把它从一个想法做到能上线的 MVP 的思路，看看一路上会踩到哪些坑，Makers 又是怎么在这些地方帮上忙的。

Step 1 · 借助模板起步

作为一个开发者，抱着对产品的构想，真正动手时才会发现，第一步不是写最有话说的「健康饮食」的经验或逻辑，而是搭建最基础的工程：有一个能跑起来的 Agent：用户能发消息，模型的回答能一个字一个字地流出来，调用工具时前端能看到状态，用户不想等还能随时打断，多轮对话的上下文也得存得住。这些东西从零写，很耗费时间和精力，偏偏又和你想做的业务没半点关系。

Makers 在这里的优势，是直接给一套现成模板把这条链路先跑通。这次我们用的是 Claude Agent Starter（Python），它基于 Claude Agent SDK，已经把「流式聊天 → 工具调用 → 会话记忆」整条路打通了。

体验模板

你可以先在Makers 里体验一下默认对话模板实现的能力。

点击开始部署，Makers 会自动创建并填入运行所需的基础环境变量。部署成功后即可点击预览来体验模板。

这是一个最小但贴近生产形态的 Claude Agent SDK + EdgeOne Makers Python 模板。完整跑通了流式响应、沙箱工具调用、会话存储这条链路，方便你直接 fork，把精力放在替换 Prompt 和工具上，而不是搭水管。

如果你决定从这个模板起步，那么可以点击下面链接获取模板。

GitHub - TencentEdgeOne/claude-agent-starter-python · GitHub

当然，如果你前面已经部署体验过模板，那么此时模板代码已经克隆在你自己的仓库里了。

如果你不熟悉代码，可以先把需求描述清楚，再把需求和 Agent 模板一起交给 WorkBuddy，它可以直接帮你完成代码改造和自动部署。

你只需要跳转到本文的部署上线部分，就能学会如何把 Agent 托管上线。但如果你想了解它背后的改造思路，也可以继续往下看。

Step 2 · 计算营养数字

骨架搭好，第一个问题就来了：轻食记最核心的能力，是把类似“我中午吃了一碗牛肉面加个鸡蛋”这样的问题，变成一组可信的热量数字。最快的办法或许是让模型直接给出数字，但很快就会发现这样并不靠谱。因为模型预估的热量并不完全精准，也容易编造热量。另外，一碗到底是 300 克还是 450 克、加了多少米饭，全靠它估，几样食物一加总，误差就被放大了。退一步把整张营养表塞进系统提示也不行：资料越堆越长、上下文越来越贵，模型还是拿不准什么时候该查、什么时候该算。

于是我们把思路反过来：模型只做它擅长的——理解这句话说了什么、判断该通过哪些工具获取精准值、份量不清就追问；至于会影响结果的算术，一律交给沙箱里跑的脚本。Makers 把这部分底层工作直接托住了。它内置的 Agent 运行沙箱，底层是腾讯云的隔离实例，按对话维度创建和复用，用完后自动回收。命令执行、文件读写、浏览器访问、临时代码运行这些能力，都已经作为基础能力封装好，开发者不用再从零搭一套运行环境。同时，Makers 也把同一个沙箱包装成了两种使用方式：一层给模型用，一层给开发者用。模型看到的是 context.tools.*，也就是一组可以自主调用的工具。开发者看到的是 context.sandbox.*，可以在代码里直接使用命令执行、文件读写、浏览器访问、运行代码等能力。这两层 API 共用的是同一个沙箱实例。模型通过工具完成的动作，和开发者在代码里直接调用的能力，是在同一个运行空间里协同完成的。这样一来，Agent 既可以让模型灵活调用工具，也可以把确定性的处理逻辑写进代码里，整个执行链路是连贯的。

具体到能力，我们把核心收进两个 Skill：一个 nutrition-engine 负责把文字变成结构化食物项、再算出热量和三大营养素，另一个 health-profile 用公式算基础代谢率与每日总能量消耗、给出每日目标。nutrition-engine 里有个最值得借鉴的设计：三级数据来源，按可信度逐级回退。常见食物像米饭、鸡蛋、面条，内置营养库里直接调取；库里没有的，就用沙箱的浏览器工具联网查这道菜「每 100 克」的营养；连网上都查不到，就退到按食材拆解。

这样一来，营养知识就不再是散落的大段文字，而成了 Agent 能稳定调用、数字还能追溯的内部能力；以后想扩充食物库或调算法，改对应 Skill 就行，既不用动系统提示，也不影响对外接口。

Step 3 · 让 Agent 记住吃了什么

轻食记得是个有记忆的Agent，因为真实对话里用户不会一口气把话说全，先说想记午饭、再补一碗面、又问那今天还能吃多少。此外，对于最后一个问题，Agent 还得知道「你是谁、你的目标是多少、你今天已经吃了什么」，才能回答「我还能吃多少」。如果每次对话都让用户重新报一遍身高体重、再把今天的记录或者上面的对话复述一遍，就显然不是一个健康管理搭子该有的样子。但让开发者来处理记忆能力，光是实现「把上下文存住、再取回来」也要耗掉大半精力。

于是这件事我们同样交给 Makers 托底。它已经把会话级的上下文接好了，模型在同一通对话里会记得用户的前文。这套持久化是平台内置的，开箱即用，开发者无需手动配置，只需要决定“记什么”。顺着这层能力，轻食记在每通对话开始时，会先把用户的档案读进来。通过在 handler 里加了一步 load_profile，让对话正式开始前，先用 context.store 按用户 id 取出他存好的档案（性别、年龄、身高体重、每日热量目标等），拼进系统提示词，再交给模型。带来的体验也很顺畅，模型会直接拿目标值回答用户「你今天还能吃多少」。

对开发者而言，整段读取逻辑只是几行代码调用，既不用自己设计存储，也不用操心会话怎么对齐。这样一来，「上下文」就从一件需要开发者反复操心的体力活，变成了 Agent 顺手可用的能力底座。开发者少操一份心，产品就能早一步成型，这便是 Makers 铺好的路。

Step 4 · 模型网关自由切换

Agent 项目上线后，模型选择通常不会一成不变。早期为了效果，可能选择能力更强的模型；用户量上来后，可能要考虑成本和速度，把部分任务切到更轻量的模型；新模型上线后，也可能希望做灰度测试或 A/B 对比。甚至在同一个摄影师智能体里，说明书问答和创作建议也可能适合不同的模型。如果在开发的时候就把模型厂商、模型 ID 和 API Key 都写死在业务代码里，每次切换都要改代码、测试、重新部署。模型选择就会从一个产品策略问题，变成一次工程处理问题。

Makers 底层接入 AI 网关，可以把模型调用从业务代码里解耦出来。开发者在代码里保留统一的模型接入方式，具体使用哪个模型、哪个厂商、哪个版本，通过网关侧配置和环境变量调整。只需要在项目的环节变量中增加下面的配置：

AI_GATEWAY_BASE_URL=https://ai-gateway.edgeone.link/v1
AI_GATEWAY_API_KEY=sk-xxx......xxx
AI_GATEWAY_MODEL=@makers/modelname

后续要切模型，只需要修改模型名称即可。这样，业务代码可以始终保持稳定，模型能力也可以随着效果、成本和速度要求继续调整。这一点对 Agent 长期迭代非常重要。

Step 5 · 调整前端

Agent 的核心打磨好了，但用户最终面对的是界面。为了做出一个直观的前端页面，开发者需要自己配框架和路由，实现流式输出，处理好加载、中断和报错；再补上消息历史回放、状态提示、移动端适配……这些和业务毫无关系，却依然得。否则用户最直接的体验会很糟糕。

这一段 Makers 同样默认备好了。所有模板自带一套开箱即用的前端，组件、路由、状态都摆得清清楚楚。轻量调整，比如换名字、改文案配色、替换欢迎语和预设问题，动几行代码就行；结构性扩展也一样顺手：我们在原本只有聊天页的模板上，加了登录注册和注册后填资料的引导页、带营养环图和七天趋势的个人中心，在输入框旁挂上拍照识图入口，在聊天流里插入可编辑可确认的营养卡片。这些都不是从头开始，而是在模板原有的组件上扩增出来的。

至此回头看，从运行沙箱、上下文存储、模型网关到这套流式前端，每个 Agent 都要用、却最不该让人重复造的部分，Makers 默认都给齐了，开发者得以把精力放在真正能决定产品体验的地方。Makers 替你铺好第一块地基，要盖成什么样由你决定。

Step 6 · 本地测试

现在，轻食记 Agent 已经能听懂你说的「中午吃了一碗牛肉面加个鸡蛋」、判断该查库还是联网、份量不清就追问，再把确定性的营养计算交给沙箱脚本理解、取数、算账、记到今天。剩下的优化就看你想把它打磨到什么程度：内置营养库可以持续补充，让更多家常菜秒回、少触发联网；追问和卡片的话术可以反复打磨；识图、个人中心的数据看板、按天回看这些体验，也都能慢慢做得更顺手。但 MVP 最重要的事已经完成了：借助 Makers 平台，你跳过了运行沙箱、上下文存储、会话记忆这些复杂的基础工程，把「怎么把一句话算成可信热量数字」这件真正核心的领域逻辑，封装成了能稳定调用、数字还能追溯的服务。接下来要做的，就是把它部署上线，让更多人来记录每一餐，并借此收集真实的使用反馈。

Step 7 · 部署上线

1. 准备环境变量

如果你已经部署过默认模板，那么 Makers 已经帮你生成好了运行所需要的基础变量。你也可以参考下面的步骤来获取。

首先是调用平台自带模型网关的 API Key。回到 EdgeOne Makers 平台，选择「Models」，点击左侧的「API Key」选项卡，然后点击「创建 API Key」按钮。

自定一个名称，并设置过期时间，如果你的 Agent 准备长期在线，可以选择默认的永不过期。

创建完成后，你会获得一串"sk-xxx......xxx"的Key，对应的就是AI_GATEWAY_API_KEY 这个环境变量。请复制并妥善保管。出于安全原因，API Key 界面上不会再次显示，丢失后需重新创建。

然后点击左侧的「快速开始」选项卡。

下滑，在第四步 创建并运行脚本的第 5 行有一个 baseURL，引号里的值就是 AI 网关的地址，对应的就是 AI_GATEWAY_BASE_URL 这个环境变量，我们复制下来。

（可选）模板默认提供的模型是deepseek-v4-flash。如果你想更换其他模型的话，可以在「模型与密钥」选项卡里，查看AI_GATEWAY_MODEL 这个变量对应的模型ID。例如，如果你想使用腾讯混元3.0模型，则变量名则为 @makers/hy3-preview。除了平台内置模型，你也可以接入第三方模型，只需要点击列表右侧的添加，并填入该模型的API Key 即可获取对应的模型 ID 变量值。

（可选）如果 Agent 需要联网搜索的能力，可以自行在控制台开通联网搜索API，创建并获取WSA_API_KEY。

现在，部署所需的基础环境变量就已经准备好了。

这里之所以把模型接入放到控制台配置里，是为了让后续模型切换更灵活。在 Agent 项目里，模型选择往往会持续变化。今天可能因为效果选择模型 A，之后可能因为成本或速度切换到模型 B，过一段时间又想试试新上线的模型 C。如果模型调用写进业务代码里，那么每次切换都要改代码、重新测试、重新发布，迭代节奏很容易被拖慢。

Makers 底层接入了 AI 网关，把模型调用从业务逻辑中抽离出来。代码里只需要保留统一的模型接入配置，具体使用哪个模型、哪家厂商、哪个版本，可以在网关侧统一调整。后续如果要切换模型、做 A/B 测试，或者按不同场景路由到不同模型，都不需要重新改造业务代码。对开发者来说，这意味着 Agent 的“大脑”是可替换的：业务逻辑保持稳定，模型能力可以持续跟随平台和行业迭代。

2. 代码上传

下一步，将本地代码上传到 Makers 平台托管。如果上传的仓库是从 Makers 克隆到你账号下的，那么默认的网关环境变量已经预填好了。如果是新建项目，可以从以下方式中选择：

2.1 代码仓库上传

你已经有了代码仓库，比如 Github，最省事的方式就是先上传到仓库中，这里我们选择新建一个仓库：

git add .
git commit -m "feat: build health diet agent"
git push

等上传完以后，回到 Makers 的控制台，选择「项目」标签，点击「导入 Git 仓库」。

如果是第一次使用，需要绑定对应的仓库平台。我们以 Github 为例，点击「Github」。

这里会弹出一个弹窗，登录 Github 账号，安装 EO Pages，默认会授权访问所有仓库，你也可以修改为只允许访问指定仓库。然后点击「Install」。

这样，就授权完成了。可以在仓库列表中选择刚才上传好的仓库。

默认选择的是仓库的 main 分支，如果打算托管特定的分支也可以手动搜索修改。

然后根据自身需求选择加速区域。需要注意的是，如果加速区域保包含中国大陆，则腾讯云账号必须完成实名认证，且仅支持完成 ICP 备案的自定义域名绑定。如果您没有提供中国大陆区域访问的需求，可以选择全球可用区（不含中国大陆）。

点击环境变量，在这里填入我们上面提到的几个变量名和变量值。

AI_GATEWAY_BASE_URL=https://ai-gateway.edgeone.link/v1
AI_GATEWAY_API_KEY=sk-xxx......xxx
AI_GATEWAY_MODEL=@makers/hy3-preview
WSA_API_KEY=......

如果你的 Agent 运行还需要额外的环境变量，可以在这里一并填入。

填写完成后点击「开始部署」，接下来等待部署完成即可。

部署成功后，就可以点击右上角「预览」按钮，获取临时预览链接。

2.2 Workbuddy上传

如果你是在 Workbuddy 上开发的 Agent，那么可以安装我们提供的 Skill：

npx skills add TencentEdgeOne/edgeone-makers-tools

这个 Skill 会先检查你有没有装 EdgeOne CLI，没有的话自动帮你配置。接着，它会问你两个问题：你用的是腾讯云国内站账号还是国际站账号，以及你打算怎么登录。

通常情况下，Workbuddy 会在浏览器中弹出腾讯云登录页，完成授权即可。如果你在特殊环境或者浏览器没法弹出，则会切换到 Token 登录模式，可以自行在 Makers 控制台的设置中生成 API Token，粘贴回来即完成授权。

登录完成后，需要手动在项目设置页里上传环境变量，并再重新部署一次。

部署成功后，就可以点击项目右上角「预览」按钮，获取临时预览链接。

3. 自定义域名

为保障内容合规，临时链接仅提供3小时限时预览，这个时候可以先对 Agent 做快速的正常运行测试。如果有对外提供访问或者长期使用的打算，建议及时添加自定义域名以确保服务持续可用。

点击「自定义域名」，或者直接点击左边的「域名管理」选项卡，就能来到域名管理页面。在这里能看到 EdgeOne 提供的默认临时域名。

点击「添加自定义域名」按钮，可以绑定你自己拥有的域名。

添加完域名后，需要手动调整域名的 CNAME 解析和配置 HTTPS。

如果你的域名注册在腾讯云的话，可以一键添加 CNAME 解析，等待一分钟即可生效。或者去你所使用的域名控制台手动修改解析。

HTTPS 配置则需要进一步操作。点击 HTTPS 配置列的「配置」按钮，再点击「边缘 HTTPS 证书」方框里的「配置」。

EdgeOne 提供了两种配置方式。第一种是针对没有证书但想实现 HTTPS 访问的用户。选择「申请免费证书」，EdgeOne 提供可自动申请、自动续签、自动部署的免费证书。

第二种则适用于已有 SSL 证书的用户。选择「申请 SSL 托管证书」可以将托管在腾讯云内的 SSL 的证书部署至 EdgeOne。

完成这两项配置后，就可以从你的自定义域名访问 Agent 了。

4. 观测能力

Agent 部署上线以后，另一个很重要的问题是：它到底有没有按预期运行？

普通 Web 应用出问题时，我们通常还能看接口日志、错误堆栈、请求耗时。但 Agent 应用的执行链路更长：用户发起一次对话后，模型可能会先理解问题，再调用工具，工具返回结果后模型再继续组织回答。如果中间某一步表现异常，只看最终回复很难判断问题出在哪里。

Makers 提供的观测能力，解决的就是这个问题。它会自动记录 Agent 的运行过程，不需要开发者从零搭一套日志系统。无论是在本地调试，还是部署到线上，都可以通过观测面板看到 Agent 的调用情况。

我们可以在 Makers 平台中点击要查看的项目，在左侧标签中展开「Agent」，可以看到 Metrics 和 Traces 两个观测面板。

Metrics 更适合看整体状态。比如 Agent 一共被调用了多少次、模型调用了多少次、平均耗时是多少、Token 消耗情况如何、有没有出现错误。它适合用来判断服务整体是否正常：是不是调用量上来了、是不是某个阶段变慢了、是不是 Token 消耗异常。

而 Traces 则更适合看单次执行细节。

每一次 Agent 请求都会形成一条完整的调用链。展开后可以看到这次请求里模型调用了几次、调用了哪些工具、工具入参是什么、返回了什么、每一步耗时多久。如果某一步报错，也可以直接在对应节点看到错误信息。有了观测能力，开发者就不是靠猜来修 Agent，而是能沿着链路定位问题。对于 MVP 来说，这一点很重要：早期用户反馈往往很碎，只有把运行链路看清楚，才能判断是 Prompt 要改、工具要改，还是外部依赖要替换。

5. 构建版本

在构建部署页，你可以管理所有托管代码的版本，点击「更多」按钮还可以实现版本回滚。迭代过程中的每一次改动都有可能引入新问题，Makers 的构建版本和回滚能力，可以让开发者在新版本异常时先恢复到上一个稳定版本，再慢慢排查原因。这样 Agent 可以持续迭代，但线上服务不至于因为一次改动导致长时间不可用。

假设你对 Agent 代码进行了调整，想要同步到平台构建新版本，有两种方法能实现。

5.1 自动触发

如果你的代码托管在代码仓库，并且是使用代码仓库上传的形式部署的。那么只要再次往仓库的 main 分支推送新版本代码，Makers 平台会自动触发新建部署，无需额外操作。

5.2 手动构建

如果你的代码是本地上传，那么构建新版本时，需要进入项目的构建部署页。

点击「新建部署」按钮，上传新的代码文件或文件夹，再点击「开始部署」即可完成构建。

结语

到这里，一个健康饮食管理智能体就完成了从模板到上线的完整过程。

回过头看，这个过程并不是从零搭建一套复杂系统，而是基于 Makers 已经提供好的 Agent 模板，把饮食健康管理里的营养知识、食物识别和用户交互逻辑一步步接进去：先明确 Agent 要帮用户解决什么问题：吃了一顿饭，能不能快速知道摄入了多少热量和营养；再整理食物数据库、把每日饮食记录和营养分析串成完整的链路，最后通过部署、观测和持续迭代，让它真正变成一个用户每天愿意打开的轻量工具。

这也是 Makers 的价值所在。它没有把开发者锁定在某一种框架、语言或模型里，而是把模型接入、工具调用、上下文记忆、沙箱运行、观测排查和部署上线这些通用能力提前打通。开发者真正需要关注的，是自己的业务场景：用户会怎么吃、哪些营养数据值得沉淀、怎样让饮食建议更贴合个人目标而不是泛泛而谈。