本轮不再扩大范围:不讨论 K8s / worker / sidecar,不追求包管理器全面 bun 化,不新增 CI/CD 或安全组件。

前置

• R1(pi 内核门禁)、R2(数据层)已完成——本轮的验收就是拿 bun 复刻这两轮的门禁。
• bun 1.4.0(2026-08-20 发布);encore CLI 1.57.13(该版本二进制内已含 bun-runtime 实验位,无需升级 CLI)。
• LLM 凭据:真实对话门禁需要一把可用 key(R1 用 DeepSeek 官方;130 上用 openai-completions 兼容网关代替,对运行时结论无影响)。

交付物

验收

禁止

• 不改前端页面样式(CLAUDE.md 规则 7)。本轮 apps/web 的改动仅限新增 Dockerfile / .dockerignore,不动任何页面、className、design token。
• 不加设计稿没有的功能(规则 8)。
• 不写 if (isBun) 分支——一套代码两个运行时是本轮的前提,不是可协商项。
• 不做压力测试 / soak test / 性能 benchmark。本轮只回答「行为是否对等」,不回答「谁更快」。
• 不切包管理器(理由见下),不做 bun build --compile standalone 二进制。
• 不顺手修 Google Fonts、Next 代理 400 等跨轮问题——记 BACKLOG。

包管理器为何不切

pi SDK(@earendil-works/pi-coding-agent)自带 npm-shrinkwrap.json 锁定它自己的传递依赖,bun 不读依赖包内的 shrinkwrap。切 bun install 会丢掉这层供应链锁定,而换来的收益接近零(依赖已装好、无 CI 流水线、安装耗时不在关键路径上)。因此:bun 只做运行时与脚本执行器,依赖解析仍归 npm ci + package-lock.json。packageManager: "bun@1.4.0" 字段的唯一作用是让 encore test 以 bun 执行 test 脚本。

代码审查

• 审查方式:/codex:review(branch diff vs main),2026-08-31。--background 模式两次因宿主进程中断/companion 提前退出而失败,改前台 --wait 完成(job review-mtglxzwh-d1o97v);非 codex 硬失败,未降级。
• 本机 Windows 复核(PR 存档注明 dev.ps1 未在 Windows 实跑):dev.ps1 check ✅;dev.ps1 test 16/16 ✅(实证经 bun --bun vitest 执行)。dev.ps1 build 跑到「api 编译完成、镜像写入 daemon 中」被所有者叫停(2026-08-31:等真部署时再构建)——脚本侧已验证的部分:脏工作区拒绝、git SHA tag、encore build docker --config/--base/--services 正确发起、linux/amd64 交叉编译成功、基座从本地 daemon 解析;镜像落地与 web 构建顺延到首次真实部署(R9 前置步骤)。另:encore 拉基座不走 docker daemon 的 registry mirror,国内网络下要先 docker pull oven/bun:1.4.0-slim 再 dev.ps1 build,已实测。本机 bun 1.3.14 与钉版本 1.4.0 不一致——不影响镜像(基座由 --base 钉死),仅本机脚本执行器,dev.ps1 test 已加漂移告警,对齐:npm i -g bun@1.4.0。

findings 处理(4 P1 + 4 P2,全部采纳,均为最小改动,无新增机制)

整改验证:bash -n ✅;migrate.sh 六条失败路径行为测试全过(未知参数/多余参数/无 .env/latest/命令注入不执行/引号值解析);dev.ps1 BOM 完好且带参实跑 ✅;docker compose config -q ✅;dev.ps1 check ✅、dev.ps1 test 16/16 ✅。

复审(缺陷门禁)

复审第 1 轮(2026-08-31,整改 commit 1047b70 后,/codex:review 前台):上一轮 4 P1 + 4 P2 全部未再出现,阻塞级 findings 清零;新报 3 条 P2,全部采纳(仍为最小改动):

复审第 2 轮(2026-08-31,整改 commit 6e6a450 后):第 1 轮 3 条 P2 全部未再出现,阻塞级持续清零;新报 3 条 P2,全部采纳(最小改动):

复审第 3 轮(2026-08-31,整改 commit 6e90aab + 文档 commit cb2c523 后):零 findings——审查者结论原文:「未发现明确、可操作且由本次改动引入的缺陷。配置与脚本通过了基础语法检查,部署流程、Bun 运行时、数据库迁移及容器约束之间保持一致。」

审查结论

缺陷门禁 PASS,可合并 main。

• 阻塞级(high / 丢数据 / 漏凭据 / 泄资源 / 逻辑错误)findings:初审后连续三轮复审为零;第 3 轮连低危都没有。
• 全程 14 条 findings(4 P1 + 10 P2)全部采纳整改,均为最小改动(改判断/改文案),未新增任何机制(无新队列/协议/抽象/配置面/导出面),符合「审查边界」。
• 唯一动 docs/security.md 的整改(P1-1 引导凭据例外)为补记所有者 2026-08-29 已裁定的部署形态,非放宽约束;R7 收敛项已记 BACKLOG,提请所有者留意。
• 环境侧遗留(不阻塞合并):本机 bun 1.3.14 待对齐 1.4.0(npm i -g bun@1.4.0);dev.ps1 build 的镜像落地与 web 构建按所有者指示顺延到首次真实部署。

建议审查者重点看:① dev.ps1 build 的 --services 白名单是维护热点——R4/R5/R7/R8 新增服务时漏改会静默 404;② stop_grace_period 40s 与 graceful_shutdown.total 30s 的配比在 SSE 长连接下是否够;③ compose 里 ${IMAGE_TAG:?} 的强制是否会卡住某些正常运维路径;④ 「先迁移后起服务」的顺序在文档/compose/脚本三处是否已完全一致。

④ 原为「node 表述边界」问题(builder 阶段仍装 node/npm 与『任何镜像里不得有 node』冲突)。所有者 2026-08-29 收口时已确认并统一改为「Node 已从生产 runtime 与最终运行镜像中移除;构建阶段与依赖解析仍用 Node/npm」,该条已闭环,不必再审。

失败处理

同一验收项针对性整改后连续 2 次验证仍不过 → 写 rounds/round-bun/BLOCKED.md,停下呼人。禁止放宽验收标准自我通过。

本轮触发过一次「停下呼人」并已收口:验收项之外发现自托管镜像不执行数据库迁移(见「踩坑」第 4 条),该问题指向部署方案设计而非缺陷,按 CLAUDE.md「审查边界」未在本轮自行发明机制,而是列出三个候选交所有者裁定。所有者 2026-08-29 裁定采用方案一(部署脚本用 psql 施加镜像内 SQL),已实现为 deploy/migrate.sh 并实测通过。

本轮实测

环境:130 服务器(Arch Linux)· encore v1.57.13 · bun 1.4.0(1.4.0+34cbb9a40)· node v26.5.1(仅作对照)· pi 0.84.3 · Next 15.5.24 · vitest 4.1.11 · 2026-08-29

门禁结果

1–13 全部通过。要点:

• 实验位可从 encore.app 生效,不需要 ENCORE_EXPERIMENT 环境变量;app 进程实证为 /…/bun/bin/bun run …/main.mjs。
• 34/34 订阅、0 错误;纯对话场景实际触发 16 种事件,与 R1 在 Windows/Node 上记录的 16 种逐一对应、顺序一致。四模式计数 19/6/7/2 = 34,与 R1 一致。
• SSE ×2 均逐事件到达(开发形态 encore run):对话流跨 4.3s 逐 delta;轨迹流先回放 74 条缓冲(seq 0–73)再 live tail,第二轮对话事件实时到达。经 Next dev proxy 同样不缓冲(每秒 6 / 42 / 21 行)。

  ⚠️ 这组结果不能读作「生产镜像的 SSE 已验证」。生产镜像里当前没有任何 SSE 端点(spike 被 --services 排除,正式端点在 R3/R4),该项顺延。

• 落库:239 条轨迹事件 seq 0–238 连续无缺口,bool_and(jsonb_typeof(data)='object') = t;进程 kill 后重启,会话标题与 4 条消息完整恢复。
• 凭据扫描:SSE 原始采样 + trace_events 全表,authorization|x-api-key|bearer|sk-|access_token|client_secret 0 命中;脱敏自测 6/6。
• 测试真跑在 bun 上:packageManager 字段能让 encore test 从 npm 切到 bun,但光有它不够——bun run 会尊重 node_modules/.bin/vitest 的 #!/usr/bin/env node shebang 静默回落到 node,三种 vitest pool(threads/vmThreads/forks)都一样。加 --bun 强制后 process.versions.bun 断言才通过,16 个原有用例同时全绿。

内存基线(bun 口径,单独建档)

未开 --expose-gc,自然回收口径。不要与 node 数字混用(JSC 堆 vs V8,RSS 语义不同)。

这些数字支持什么、不支持什么(刻意保持中性):

• ✅ 支持:在当前 Linux + 当前代码 + 当前 pi 版本下,bun 的基础 RSS 更低(基座低约 65MB / 29%)。deploy/docker-compose.yml 的 mem_limit: 1g 据此设为初始上限(替换原先的 2g)。
• ❌ 不支持写成「bun 的内存表现全面优于 node」。同一组数据里 10 轮 churn 残留 bun(1.75MB)反而高于 node(0.38MB);两者都无单调增长、量级也都在噪声范围,不构成泄漏证据,但足以说明现阶段不该做单向结论。
• ❌ 不支持用空闲会话增量(0.04MB)推真实活跃会话容量。空闲会话不持有上下文、消息历史、在途 provider 响应与流式写缓冲。
• ❌ 不支持「1g 已证明够用」。1g 是基于基座 + 事件缓冲结构性上限 + 主机总预算选出的初始上限,S_active_p95 仍是空值。
• 顺带纠正 R1 任务卡一个数字:R1 记的「import 约 16s」是 Windows 平台开销,不是运行时特性——同代码在 Linux/Node 上仅 512ms。该数字不应作为运行时结论引用。

镜像

踩坑与实测发现

1. 只开实验位会产出必然启动失败的镜像(上游缺陷)。 encore build docker 在 bun-runtime 下把 ENTRYPOINT 改成 bun run …,基座却仍是默认的 node:slim,镜像内没有 bun:

   text

   docker: ... exec: "bun": executable file not found in $PATH
   

   node 对照组同样构建能进到 Encore runtime,证明是 bun 分支单独坏的。补 --base oven/bun:1.4.0-slim 即修复,修好后容器正常启动并加载 Encore 原生运行时(encore-runtime.node,N-API)。已记 BACKLOG,建议给 Encore 提 issue。

2. encore.app 的 build.docker.base_image 对本地构建无效。 写进去后日志仍 resolving base image node:slim;schema 注释写明该字段 "used for building the application in Encore's CI/CD system"。基座只能靠 --base,故固化进 dev.ps1 build。另外 bundle_source: true 会把镜像从 592MB 撑到 1.4GB,不要开。

3. bun run 默认尊重 shebang 会回落到 node。 见上「测试真跑在 bun 上」。判据只能是 process.versions.bun,不能看输出格式。

4. 自托管镜像不执行数据库迁移 —— 已裁定并落地。 Encore 运行时里没有迁移逻辑(runtimes 全树无相关代码;encore db 也没有 migrate 子命令);迁移是本机 CLI(encore run/check 日志里的 "Running database migrations")或 Encore Cloud 控制面施加的。镜像里虽打包了 agent/migrations/001_init.up.sql,但容器启动不会应用。空库直起的表现极具迷惑性:

   text

   /health          → 200        ← 健康检查全绿、容器 healthy
   /agent/sessions  → 500        relation "sessions" does not exist
   

   所有者 2026-08-29 裁定:方案一(部署脚本用 psql 施加镜像内 SQL),实现为 deploy/migrate.sh。选它的理由是 SQL 直接取自正在部署的那个镜像,不存在「镜像 A 版、SQL B 版」的漂移,且服务器上不需要多维护一个镜像。

   关键设计与实测(见下「migrate.sh 验证」):版本记录沿用 Encore/golang-migrate 的 schema_migrations(version, dirty) 单行语义,与 encore run 本地库同构(实测两边都是 1|f),将来 encore CLI 连这个库读到的版本是对的;单事务应用,失败整体回滚;幂等;含 CONCURRENTLY 的迁移主动拒绝而非绕过事务保护。

5. hosted_services 不能用来裁剪端点。 infra-config 里去掉 spike 后 /spike/mem 仍 200;schema 也写明该字段 "should not be set by the user, computed during build"。真正生效的是构建期 --services agent,system,实测让 /spike/* 全部 404 而 /health 正常——评审的 P1-6 由此从「计划保证」变成构建期硬门禁。

6. PORT 环境变量有效,镜像默认 8080 可改 4000,与 Caddyfile 的 api:4000 对齐(二选一已写死在 compose + Caddyfile 注释)。

7. infra-config 的 databases key 就是物理库名,故 compose 的 POSTGRES_DB 从 xray 改为 agent。

8. encore build docker 不消费 DATABASE_URL 等普通环境变量,不给 --config 直接硬失败(Your infra configuration is incomplete: Secrets DeepSeekApiKey / Databases agent)——评审 P1-1 属实,且是硬失败不是软警告。

9. Next standalone 可跑在 bun 上:bun --bun server.js Ready 89ms、首页 200。但仅验证了 standalone 运行;next build 本身仍以 node 执行(Dockerfile builder 阶段装了 node/npm),未验证用 bun 执行 Next 构建器。

完整 compose 部署实测(130,提前跑通了 R9 的大部分链路)

按真实部署形态在 130 上跑了完整四容器(含 caddy 占 80/443)。收口时按「先迁移、后起服务」的最终顺序重跑了一遍:

上线后端点:/api/health 200 · /api/agent/sessions 200(GET/POST 均可) · 前端 / 200 · /api/spike/mem 404。

初次探索时用的是「一把 up -d 起全部再迁移」的顺序,结果如下(正是这个中间状态促成了顺序调整):

migrate.sh 验证:

首版脚本有两处瑕疵已修:--status 会建出跟踪表(与「未改库」的声明矛盾)、CREATE TABLE IF NOT EXISTS 的 NOTICE 噪音。修后从干净库重跑,上表 1–5 全部通过。

与计划的偏离

• 原评审建议 R-BUN 作为「不阻塞 R9–R11 的实验轨」;所有者裁定改为直接统一切换(理由见「目标」段)。
• 原评审建议 encore.app 写 base_image + bundle_source: true;实测两条都不成立,改为 --base 固化进 dev.ps1 build、不开 bundle_source。
• 原评审建议 R-BUN 包含「package manager migration」;实测评估后明确不切,理由见「包管理器为何不切」。

目前证据不足(不要外推)

• 活跃会话真实内存增量:只测了空闲会话。长上下文、大量 Tool Output、高频事件队列的增量未知,S_active_p95 / S_stream_p95 仍是空值,须等 R3/R4 后用真实使用数据采。
• 长时间运行:最长连续运行约 20 分钟,长期泄漏口径未验。
• next build 在 bun 下执行:未验证(当前构建期仍用 node)。
• 生产镜像的 SSE 冒烟:当前无法演练。两条 SSE 只存在于 spike 里,而 spike 已被 --services 排除出镜像;正式的 /agent/ask、/trace/stream 分别在 R3、R4 落地。本轮的 SSE 门禁是在 encore run(开发形态)下验的,生产镜像形态下的 SSE 行为要等 R3/R4 才能验。
• 含 CONCURRENTLY 的迁移:migrate.sh 会主动拒绝,但该路径未实测(当前只有一个迁移文件,不含该语句)。
• 多数据库:migrate.sh 目前硬编码只认 agent 库,遇到别的库名会报错停下而不是猜。R5 建 notes 表若沿用同一个库则无影响;若新增数据库需要扩这个脚本。
• bun smol 模式:未测。Encore 曾在 bun 实验发布说明里提示 bun 内存占用偏高并建议 smol,但本轮实测 bun 反而比 node 低 29%,该建议是否仍适用未知。