vercel-labs/fx0

fx0 更适合当作参考实现来读，而不是直接照搬的产品：它展示了 agent 循环可以多大程度交给 libfx，剩余部分又如何落在 Vercel 上。如果你正在这套技术栈上设计自己的聊天加生成类 Agent，它的源码值得花几个小时。

解决什么问题

你有一个设计助手的想法：用户描述一个页面，Agent 返回一个可直接预览、复制、下载的 HTML 文件。从零搭建意味着在做出 demo 之前就得先接好聊天、流式输出、工具调用、重试、会话持久化和计费。fx0 把这整条流程打包好了——描述页面、选择模型、生成 HTML 产物、随时重开任一历史版本——留给你的只剩想法特有的部分。最终得到一个已部署的应用，同时也可当作 libfx 集成方式的可读地图。

有什么不同

核心设计是委托：一次 createFxAgent() 调用提供 agent 循环、流式输出、工具调用、重试和持久会话，createFxEngine() 负责运行子 agent。按 README 的说法，fx0 自己没有任何恢复逻辑；持久性来自 libfx 默认接入 Vercel 的 World 存储和 Vercel Queues，即使执行该轮次的函数挂掉，这一轮也会继续。如果你本来就在 Vercel 上，这种分离很有吸引力：应用代码只关心提示词、追问、取消和转录记录。

代价是架构绑定和一条真实的延迟尾巴。提示词在发送请求里直接跑这一轮，所以回复不用排队就开始——但若该请求崩溃，续跑大约要等 13 分钟，因为 libfx 无法区分崩溃的函数和慢函数，会占住会话直到 800 秒上限。只是跑得久的一轮会在上限前 30 秒被停下并立即转交。fx0 还把一轮限制在 64 个模型步骤（含子 agent），以此约束循环带来的花费，代价是真正长的任务会被截断。生成的页面跑在 opaque origin 的沙箱 iframe 里，connect-src 'none' 切断网络请求，不过 README 明确说靠的是浏览器执行，而非密封的虚拟机。

谁值得试

适合：在 Vercel 上做 Agent 产品、想看到一个可运行的持久会话、按轮版本、带推理强度的模型选择以及 AI Gateway 计费示例的开发者。先在 fx0.vercel.dev 试试，是判断交互模式是否合你口味的最快方式。不适合：想要一个不依赖 Vercel 服务的独立工具，或纯本地的设计助手——按项目说明，本地运行同样需要 Sign in with Vercel 应用、Neon Postgres 和 Upstash Redis。如果你是在比较各家的 agent 框架而非 Vercel 栈，这个设计会显得绑定单一厂商。

使用条件与边界

本地开发需要 Node.js 24 以及三个外部服务：带 openid profile email offline_access scope 和 AI Gateway/团队权限的 Sign in with Vercel 应用、Neon Postgres 数据库、Upstash Redis 数据库。漏掉 offline_access 会导致登录失败，因为拿不到 refresh token——随手拼配置的人很容易在这里卡住。测试也分路径：部分检查需要本地 Redis 程序或 Chrome，journal 集成测试需要远程 KV 凭据。

日常维护主要围绕 Vercel 侧依赖。部署要在 Vercel 上设置同样的环境变量，使用 Marketplace 里的 Neon 和 Upstash 集成，并正确设置 APP_URL 和匹配的回调地址。每 IP 五条免费提示词是可选项，依赖 BotID 和仅存于服务端的 Gateway key。代码结构在仓库说明里有交代，但真正的门槛是这些服务依赖。

HotRepo 点评

HotRepo 在 2026-10-25 记录到 TypeScript 新项目榜 #12、总星 398，项目当时 5 天。这只是两个记录日期内的一个带日期快照，没有可比的日榜历史，因此尚不能判断热度能否持续。把 fx0 当作提交前先读的示范项目；在假设这套持久性方案可迁移前，先确认 libfx 文档覆盖了你的部署目标。