三伏天正是减肥天：我在 EdgeOne Makers 上从 0 到 1 上线了一个 AI 健康教练

三伏天正是减肥天：从零到一，我用 EdgeOne Makers 上线了一个 AI 健康教练

今年入伏那天的冲击，不是来自高温，而是来自体重秤上那个数字。67.5kg，比年初重了快4斤。这个数字比任何养生文章都更有说服力，也成了启动一个搁置已久的项目的直接导火索。

其实早就想做一个自己的健康管理工具。之前做过一版对话式的打卡小项目，卡片UI都画好了，但一直卡在“能跑”和“能用”之间。想让朋友和自己真正用起来，就得自己拼模型、搞记忆、部署SSE流、配域名证书，想想就头疼，项目就一直躺在文件夹里吃灰。

恰好那阵子看到腾讯云EdgeOne在推一个叫“Makers”的新东西，专门托管Agent。翻了下文档，发现它恰好对症：运行时是现成的，对话记忆平台替你存着，还有内置免费的模型。我那个项目里最烦的几件事，它基本全包圆了。行，就借着三伏四十天的由头，把项目从0到1重做一遍，顺便逼自己认真减个肥。

于是就有了这个项目：“瘦得漂亮 AI”——一个部署在 EdgeOne Makers 上的私人健康教练 Agent。

做成什么样？就三条

我对它的要求很明确，就三条：

1. 说人话就能打卡。
   不想点一堆按钮填表单，直接说“今天67.5kg，早餐吃了燕麦粥和水煮蛋”，它自己估热量、自己记账。

2. 真的记得住。
   今天记的体重，过几天换个对话窗口问“我这周瘦了多少”，它还答得上来。这要求Agent有跨会话的长期记忆。

3. 数据要好看。
   热量收支、体重趋势这些数字，用卡片和折线图展示出来，而不是一坨文字。

拆解下来就是7个工具：记体重（支持补录历史）、记饮食、记运动、生成健康日报、看体重趋势、定减重方案、排一周食谱。分工上有个关键设计：大模型负责“估”，工具负责“记”。用户说吃了什么，模型先根据常识估算每种食物的份量、热量和营养水平，再把结构化数据交给工具入账。工具负责从存储里聚合历史数据，算日环比、画趋势，把数据卡片吐给前端。模型干模糊推理的活，代码干精确计算的活，各司其职。

两种上手方式：网页点点，还是终端一把梭？

EdgeOne Makers 创建项目有两条路，都走了一遍，各有各的爽点。

方式一：控制台网页创建（适合第一次尝鲜）

打开腾讯云控制台，进 EdgeOne 的 Makers 标签页，能看到一排 Agent 模板：OpenAI Agents SDK、Claude Agent SDK、LangGraph、CrewAI、Deep Agents 都有，Node 和 Python 双版本，每个模板都带 Demo 和 GitHub 源码链接。

选一个模板，关联 GitHub 授权后，平台会基于模板在你的仓库下建一个新仓库并自动完成首次部署。后面往主分支推代码，就自动触发重新部署，全程不用碰终端。

方式二：CLI 创建（我最后选的这条）

我平时习惯待在终端里，所以正式开工走的是 CLI。EdgeOne 的命令行工具直接从 npm 装：

npm install -g edgeone

edgeone -v # 我装的是 1.6.14

登录有个小细节，国内账号要指定站点：

edgeone login --site china

浏览器弹出来授权一下就好。CLI 登录成功后会自动在控制台生成一个 API Token。如果你在 CI/CD 这种非交互环境部署，也可以在控制台手动创建一个，通过 -t 参数或环境变量传给命令。

然后四条命令走完从创建到上线的全流程：

edgeone makers create --template openai-agents-starter-node

edgeone makers link

edgeone makers dev

edgeone makers deploy -n slim-agent

makers dev 有个我很喜欢的细节：本地起服务的同时，送了一个 /agent-metrics 可观测面板，每次对话的模型调用、工具调用、耗时全链路都能看，调试工具调用不生效的问题时特别管用。这个能力是 Makers 运行时内置的，不用装任何 APM。

项目长什么样？

模板生成的目录结构很清爽，约定优于配置：

agents/

chat/index.ts

_health-tools.ts

_health-store.ts

cloud-functions/

src/

edgeone.json

Web 和 Agent 共用一个项目、一次部署、统一域名，这就是 Makers 的“同构部署”，省掉了前后端分别上线再配跨域那套折腾。

记忆：给每个用户一本“日记”

跨会话记忆是这个项目的灵魂。我的做法是借用 Makers 的对话存储，给每个用户单独开一个固定 ID 的“日记”会话。所有体重、饮食、运动记录都以结构化 JSON 追加进去。任何聊天窗口里的工具都读写这同一本日记，所以不管用户开多少个新对话，数据永远是同一份。

工具：模型估算，工具入账

以记饮食的 log_meal 为例，参数 schema 用 zod 描述，模型把估算好的食物清单、热量、营养水平传进来，工具负责写库、聚合当天摄入、对比目标热量。

卡片：给 SSE 流加一个 card 事件

前端漂亮卡片的数据从哪来？我在 Agent 的流式输出里做了一层拦截：工具返回值里带 card 字段的，单独打成一个 SSE card 事件推给前端，前端按类型渲染成日报卡、饮食卡、趋势卡、方案卡。模型的文字回复只负责简短的确认和鼓励，不重复卡片里的数字。

上线第一天实测

上线后拿自己当第一个用户，完整跑了一天。

早上称重加早餐，一句话两件事，它先调 log_weight 记了体重，又调 log_meal 把燕麦粥、水煮蛋、无糖豆浆逐项估了热量，230 kcal 入账，卡片上蛋白质/碳水/脂肪的高低标签一目了然。

中午一份鸡胸肉沙拉加拿铁，330 kcal，注意卡片右上角“今日已摄入 560 / 1650”——它把早餐自动累加进来了。

下午我干了一件比较狠的事：点“新建聊天”，在一个全新的空白会话里问它“我今天总共吃了多少热量？还能吃多少？”。它翻出了日记，560 kcal、运动消耗 325 kcal、还剩约 1090 kcal 的额度，一样不落。这就是前面说的日记设计在起作用——记忆不属于某个对话，属于这个用户。

然后让它定减重方案。67.5kg 减到 62kg，它给的是 8 周温和减重、每天 1550 kcal，还特意在卡片里写了句“减重不是越快越好，8 周减 5.5kg 平均每周不到 0.7kg，既健康又不容易反弹”。

晚上剧情走向真实了——没忍住，两串炸串一杯奶茶。它的反应我很满意：先共情（“偶尔放纵也是生活的一部分嘛”），再干活（730 kcal 照记不误），最后给补救建议（明天多吃蔬菜多喝水）。既不审判你，也不惯着你。

我又试探了一下底线，问“我今天只吃一顿饭行不行？我想一周瘦 5 斤”。它直接温柔地拦了：一天一顿容易血糖不稳、代谢下降、报复性暴食；一周 2.5kg 减掉的多是水分和肌肉。然后引导我做“科学、舒服、不反弹”的计划。这段是人设 prompt 里明确写了的安全边界，实测确实兜得住。

最后是我个人最喜欢的功能——一周食谱。方案只给原则不够落地，“每天到底吃啥”才是减肥最大的执行难题。让它安排下周饮食，它先确认了体重和目标，然后产出两张卡：一张方案卡，一张周一到周日、每天三餐具体到菜品和热量的食谱卡，全是菜市场买得到的家常食材，七天不重样。

UI 的三次进化

聊聊界面这条线，因为它挺能代表“从模板到产品”的过程。

模板原生的界面是三栏的：左边会话列表，中间聊天，右边挂着一块教学用的代码面板，展示 Agent 的核心实现。作为学习材料这个设计很贴心，但作为产品它太“Demo”了——用户不需要看代码。

第一刀，把代码面板砍了，聊天区居中放大。原来的 SSE 调试流没有删，写文章、排查问题时它真的有用，降级成顶栏一个 小按钮，点开才出现的抽屉。

第二刀是主题。最早整站是深色的，酷是酷，但我们做的是健康产品，天天面对一块黑漆漆的屏幕总感觉在熬夜写代码而不是在变健康。于是把默认主题换成了暖白加薄荷绿的浅色系，清清爽爽。深色也保留，顶栏一键切换，偏好存在本地。工程上的代价是把散落在各组件里的硬编码颜色全部收敛成 CSS 变量，两套主题共用一套组件。

顺手也做了移动端适配：侧边栏收进汉堡菜单变成滑入抽屉，卡片和气泡自适应窄屏——手机上随手发一句话打卡，才是这类工具真实的使用姿势。

上线之后：控制台里还有多少东西可用

上线才几天，构建列表里已经攒了七八条记录，每次都是全自动。

有几个控制台能力值得单独说：

新项目默认用 Makers Models 内置的模型，从开发到现在模型开销为 0。要换模型也简单，控制台“模型与密钥”页托管了多家厂商，添加对应 Key 后改一下环境变量重新部署即可，代码一行不用动。

如果想在别的项目里直接调 Makers Models 的推理服务，可以在控制台生成自己的 Key，OpenAI 兼容协议。

对话记忆背后是平台托管的存储，控制台能看到项目自动创建的命名空间，此外还有 Blob 和 KV 存储可以按需取用——后面想做食物照片识别，图片就有地方放了。

默认给的是预览域名，绑自己的域名就在“域名管理”里加一条 CNAME，HTTPS 自动配好。

踩过的四个坑

真实项目不可能一帆风顺，这几个坑帮后来人省点时间：

store.getMessages 的 limit 上限是 100。我一开始传了 500，直接抛 MemoryValidationError。文档里其实写了，但谁看文档呢（不要学我）。解法是按倒序取最近 100 条再反转，对一个打卡应用来说够用很久。

生产环境的存储是最终一致的。本地 dev 一切正常，上了生产后发现“先记一餐、紧接着看日报”时日报偶尔读不到刚写的那条记录——写后立读在分布式存储上不保证。解法是在单次请求的工具集里维护一个 pending 列表，本次运行刚写入的记录直接合并进后续读取结果，一次请求内自洽。

卡片刷新后会消失。卡片数据走的是 SSE 临时通道，/history 接口只存文本，一刷新页面卡片就没了。解法是前端把带卡片的消息快照存进 IndexedDB，从服务端恢复历史时按内容前缀把卡片重新接回对应消息上。

部署成功了但页面还是旧的。新版本资源明明已经在 CDN 上，首页 HTML 却还是旧哈希——边缘节点的 HTML 缓存没过期。等几分钟会自动好，着急的话控制台清一下缓存立刻生效。别急着怀疑自己的构建，先怀疑缓存。

四十天之后

项目从创建到线上可用，核心编码其实就一个周末。剩下的时间，都花在打磨卡片样式和跟自己的晚餐作斗争上。现在它每天的工作就是：早上收我一条体重，三餐收我几句话，晚上给我一张日报卡。出伏那天，它会给我画出一条完整的伏天体重曲线——希望是往下走的，这算是我和它的第一个共同 KPI。

回头看，EdgeOne Makers 最打动我的不是某个单点功能，而是它把“一个 Agent 想上线给真人用”路上的杂活全收走了：运行时、记忆、模型、可观测、部署、域名，一个平台闭环，而且不锁框架、不锁语言、免费起步。我的精力得以全部花在“健康教练该怎么想事、怎么说话”这种真正的产品问题上——这大概就是这类平台存在的意义。

项目的完整实现细节文中放不下，感兴趣的朋友可以直接基于 Makers 的模板起一个，半天就能搭出你自己的版本。三伏还剩三十多天，一起瘦得漂亮。