云端的一回合

本机（npm）形态里，一回合就是一次普通的本地请求——内核常驻，随时响应。部署到 Vercel 之后，形态变了：没有常驻进程，每一轮聊天都要在 serverless 环境里扛住断线、平台超时和 token 上限。这一篇讲云端形态独有的执行机制；两种跑法共享的架构决定（提示词冻结、只追加写路径、安全模型）见架构。

一回合就是一次耐久运行

云端每一轮聊天都跑在一次耐久的 Vercel Workflow 运行里，从头到尾四步：

1. Housekeeping —— 解析或恢复活跃切片、应用切片规则、追加本轮消息；fitness 计分与切片边界上的进化检查也在这里。
2. 组装提示词 —— 分层前缀在切片存续期间逐字节冻结，细节见架构。
3. 主 Agent 循环 —— 每一次 LLM 调用、每一次工具调用都是一个独立耐久、自动重试的步骤。瞬时失败原地重试；撞上平台超时或 token 上限时，有界续跑机制用已完成步骤重建上下文，从断点接着跑。
4. finalizeTurn —— 本轮写进切片的共同记录，agent 的认知写进它自己的时间线，索引随之更新。

因为每一步都耐久，运行扛得住断线：刷新页面、网络闪断，客户端会重新挂上同一次运行，把错过的流补回来。你看到的"等待"，其实是一次可以在故障中存活的执行。

它学会自己收拾残局

耐久不等于不会出岔子，所以写路径上有两层自愈：

• 写冲突自愈 —— 两个写入者对同一回合提交了不同版本时，系统按 turnId 做只追加的回合合并，而不是互相覆盖。历史只增不改。
• 紧急落盘 —— 浏览器关闭或跳转前（beforeunload），客户端用 sendBeacon 把未保存的状态抢发回服务端。你关掉标签页的动作不会弄丢任何东西。

浏览器之外的调用方

变更端点有一道同源守卫：你自己浏览器里的调用自动放行；curl、脚本这类非浏览器调用方，在你设置了 ACCESS_SECRET 环境变量后需要带上 x-access-key 头。只在自己浏览器里用的话可以不设——但请记住，云端内核没有账号体系，拿到你部署链接的人就能使用你的实例，这道守卫是单用户部署值得考虑的一道锁。

相关文档

• 部署到 Vercel —— 把这套机制跑起来的实际步骤
• 架构 —— 两种跑法共享的内核决定
• 记忆模型 —— 耐久运行读写的那份数据结构