Tobatsu 2.0 · 方案

Agent 自助自定义 Runtime

内部 Agent 通过 API 改一份 Dockerfile,系统自动构建 + 验证 + 上线;模板按名字引用,新任务自动用当前版本。

2026-06-20 · cc + codex 收敛 · 最小方案,不做完备平台

目标 + 前提

目标:一个模板缺依赖时,Agent 自己就能改 runtime——改 Dockerfile → 平台自动建 + 验证 → 候选 → 测试 → 升正式。没人手敲镜像、没人手改仓库。

前提(owner 定):用户都是信得过的内部 Agent。不做精细权限、不做 typed validation、不做依赖结构化模型。先把"能自助改 runtime 并自动构建"跑通。

模型:Runtime 是数据库里的 Dockerfile

Runtime = 数据库里一份 Dockerfile(现在的 docker/runtime-basic/Dockerfile 搬进库)。
一个共享 base。正常所有模板都跑 base(magi3 那样:一个环境一堆模板)。
特殊/冲突需求才分叉:从 base 拷一份成自己的 runtime,在上面改。平台能分叉,Agent 也能自己分叉。分叉可拉最新 base、也可钉住。
模板按名字/ID 引用 runtime(如 tobatsu-runtime-basic),不写版本号。
Dockerfile 一更新 → 自动触发 CI → 候选 → _test 验 → 升正式 → 引用它的模板新任务自动用新版。

现成 vs 要做(第一手核过)

好消息:下半截基本都在,只缺"Dockerfile 进库 + 接口 + 自动触发"。

✓ 已现成(不用动)

模板按名字引用 + 解析到 active:已实现,而且代码强制生产模板不许写版本号(runtime_version_pin_forbidden)。这块锁死了,不碰。
轮询 CI(poll_image_build_requests.py + 定时器)、构建脚本、runtime_profiles(名字+候选/正式)、候选→升级、worker 收敛——都在。

要做(四块)

① Dockerfile 进库:新 1 张表 + 扩现有构建请求表 3 个字段。
② 给 Agent 的接口:7 个(见下)。
③ 轮询/构建脚本从 DB 读 Dockerfile(现在读仓库固定文件)。
④ 改 Dockerfile 即自动触发 CI:API 同事务建构建请求(现在靠手填 commit)。

数据模型(就加 1 张表)

runtime_dockerfile_revisions

id · runtime_id(稳定ID) · name(稳定名字) · revision(内部递增,模板不引用) · dockerfile_content(完整文本) · parent_runtime_id(从谁分叉) · base_revision_id · content_sha256 · smoke_command(可空,Agent 自带的一条附加验证) · created_by/at

最新版 = 同 runtime_id 下 revision 最大那行;回滚 = 再插一条复制旧内容。一张表够,revision 行本身就是历史。

扩 image_build_requests 三个可空字段:runtime_dockerfile_revision_id / runtime_name / log_path。老的 commit-only 构建请求照常工作。

接口(7 个,开放给可信 Agent)

接口	干什么
GET /runtimes	列出所有 runtime + 最新版 + 构建状态 + 当前 active/canary
GET /runtimes/{name}	读一个 runtime 的 Dockerfile、父、构建状态
POST /runtimes	分叉:从某 base 拷一份成新 runtime,立即建
PUT /runtimes/{name}/dockerfile	主入口:改 Dockerfile → 插新版 → 同事务建 → 自动 CI
POST /runtimes/{name}/pull-base	拉最新 base(Agent 自己合好的 Dockerfile,不做自动 merge)
POST /runtime-profiles/{id}/set-canary	候选设成 canary(测试环境优先解析它)
POST /runtime-profiles/{id}/promote-active	验过升正式(旧 active 归档)

自动触发 CI(你最强调的)

1API 写入新 Dockerfile revision。

2同一个事务写入构建请求(指向这条 revision)。← 这就是"改了自动触发",不靠人手点。

3轮询服务认领 → 从 DB 读 Dockerfile 写临时文件 → 调现有构建脚本(传 RUNTIME_DOCKERFILE_PATH + 可选 smoke command)。

4构建脚本:现有 identity/doctor smoke + 可选的 Agent 自带 smoke(如 fc-match Montserrat)→ 注册候选 profile。

5候选 → set-canary → _test 验 → promote-active。

只让构建输入从"仓库固定 Dockerfile"变成"DB 里这条 Dockerfile",其余复用现有链路。

Mai 第一个用(走分叉,不动 base)

分叉把影响圈在 Mai,不让 MB/别的模板跟着换镜像。等字体确认是全平台通用,再合进 base。

POST /runtimes 从 base 分叉出 mai-runtime。
PUT .../dockerfile 加字幕字体 + fc-match smoke → 自动建候选。
set-canary → Mai 的 _test(配 runtime_name=mai-runtime,不写版本)发真单,快照钉 canary digest。
验过 promote-active → Mai prod 模板配同一个名字,新任务自动用 active。

明确砍掉(不做)

多表需求模型 · typed validation 框架 · 精细权限分级 · 安全沙箱策略矩阵 · 自动 Dockerfile merge · 模板按版本引用 · 每个包/字体的结构化依赖模型。

内部可信 Agent 直接改 Dockerfile,API 保存 + 触发 CI。先把闭环跑通。

风险(已知,owner 接受)

允许 Agent 写坏 Dockerfile —— 防线是:构建/验证失败不产生 active runtime,坏的上不了线。
smoke_command 是原始 shell、不是安全边界 —— 只给内部可信 Agent。
base 更新不自动合进分叉 —— 分叉默认钉住,需要时调 pull-base。

源:codex 最简稿 /tmp/codex-runtime-customization-plan.md + cc 代码核实。— 待 owner 拍 → 进入实现清单(DB migration → seed base → API → CI → Mai 首用)。