Hermes Agent 容器镜像瘦身实战把 15 分钟冷构建压进 3 分钟【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agentHermes Agent 是一个带闭环学习能力的自进化 AI 代理官方发布镜像里塞着 Python 工具链、Node 前端、浏览器、s6 进程监督这一整套家当容器镜像优化就成了两笔账镜像体积决定拉取快慢分层质量决定构建快慢。下面按为什么会慢 → 根子在哪 → 怎么改 → 省多少的顺序把仓库里Dockerfile正在用的四招拆开讲。冷构建为什么每次提交都重跑一遍把依赖层和源码层拆开现象很直接CI 里 docker.yml 触发的冷构建要 15-45 分钟而多数提交只是改了几行 Python。根因在于分层顺序写反了。如果COPY . .放在uv sync/npm install前面那么每次源码变更都会污染整个构建上下文把后面 4-5 分钟的依赖解析和下载全部作废。这里的关键在于缓存命中与否只取决于这一步输入的文件是否变了。Dockerfile 的做法是把清单单独先拷进去# 只拷锁定文件不拷任何源码 COPY package.json package-lock.json ./ COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-install-project --extra all --extra messaging --extra otlp前端也一样web/和ui-tui/的构建层排在源码COPY之前改 Python 不会重打前端。实际跑下来纯源码提交的热构建只剩前端打包加一次源码拷贝冷构建时间能压到 2-3 分钟量级而 s6-overlay 那段还故意用curl --retry替代ADD因为 CDN 抖一下就能废掉一次 15-45 分钟的构建。构建工具链别漏进运行时多阶段构建的正确姿势镜像里最贵的死重往往不是业务代码而是构建工具链gcc、cmake、头文件、编译器跑起来根本用不上却每个都几十 MB 起步。单阶段构建的问题就在这——编译完不删东西镜像就永远带着它们。Hermes 的解法是把造轮子的和用轮子的放进不同阶段最终镜像只做COPY --fromFROM debian:13.4 AS sqlite_build # 只为编译修 WAL bug 的 SQLite FROM ... AS uv_source # 只借 uv 可执行文件 COPY --fromuv_source /usr/local/bin/uv /usr/local/bin/ COPY --fromsqlite_build /opt/sqlite-fixed/lib/libsqlite3.so.3.53.4 /usr/local/lib/注意 SQLite 是从源码编译的Debian 13 自带版本有 WAL-reset 损坏 bug但最终镜像里只留下一个.so文件Node 26 也是从上游 slim 镜像拷二进制加 npm而不是 apt 装一整棵树。这套构建依赖隔离下来最终层里没有任何编译器和头文件体积上少的是 300MB 量级且 apt 层统一--no-install-recommends加rm -rf /var/lib/apt/lists/*系统依赖本身也被压到最小。依赖裁剪能省多少别用 --all-extras依赖装多了不涨冷启动时间涨的是体积、拉取时间和供应链风险。坑点是 Python 的--all-extras它会顺带拉进[rl]torch、wandb 等 git 依赖、[yc-bench]、[termux-all]这些生产容器根本不用的东西体积直接翻几倍。所以 Dockerfile 里是点名的 extra 白名单# 排除 [dev]排除 [rl]/[yc-bench]/[termux-all]只装生产需要的 RUN uv sync --frozen --no-install-project \ --extra all --extra messaging --extra otlp \ --extra anthropic --extra bedrock --extra azure-identity \ --extra hindsight --extra matrixnpm 侧同理装完立刻npm cache clean --forcePhoton 边车的依赖树单独一层、单独清缓存。更巧的一招在运行时那些低频后端 SDKFirecrawl、Exa 之类走HERMES_LAZY_INSTALL_TARGET/opt/data/lazy-packages装到数据卷上而不是镜像层镜像保持干净按需才付这个成本。构建上下文与运行时布局最后一层隐形优化体积问题收尾后还有两笔容易被忽略的账上下文和运行时。先看 .dockerignore——它排除.git、node_modules、tests/、docs/、*.md甚至apps/整个桌面端目录只放行apps/shared/这个 workspace 依赖。上下文小了COPY . .传输快而且构建时生成的产物如ui-tui/dist/被排除后反而不会反向击穿前面的 npm 安装层缓存。运行时布局上镜像把/opt/hermes整层封成 root 只读可变状态全放进/opt/data卷COPY --link --chmod把 30k 个文件的权限在拷贝时一次性烙好省掉此前全树chmod的 21samd64到 222sarm64HERMES_DISABLE_LAZY_INSTALLS1加上 s6-overlay 监督让容器重启行为完全确定冷启动路径里没有运行时偷偷装东西这一步。收个尾维度优化前优化后冷构建15-45 分钟2-3 分钟量级依赖安装每次提交重复 4-5 分钟锁文件不变则整层缓存命中全树 chmod21s / 222s拷贝时一次完成构建工具链泄漏进运行时零编译器残留体积决定拉取速度分层质量决定构建速度运行时不可变布局决定启动确定性——这三件事做完容器镜像优化基本就到位了。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Hermes Agent 容器镜像瘦身实战：把 15 分钟冷构建压进 3 分钟
Hermes Agent 容器镜像瘦身实战把 15 分钟冷构建压进 3 分钟【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agentHermes Agent 是一个带闭环学习能力的自进化 AI 代理官方发布镜像里塞着 Python 工具链、Node 前端、浏览器、s6 进程监督这一整套家当容器镜像优化就成了两笔账镜像体积决定拉取快慢分层质量决定构建快慢。下面按为什么会慢 → 根子在哪 → 怎么改 → 省多少的顺序把仓库里Dockerfile正在用的四招拆开讲。冷构建为什么每次提交都重跑一遍把依赖层和源码层拆开现象很直接CI 里 docker.yml 触发的冷构建要 15-45 分钟而多数提交只是改了几行 Python。根因在于分层顺序写反了。如果COPY . .放在uv sync/npm install前面那么每次源码变更都会污染整个构建上下文把后面 4-5 分钟的依赖解析和下载全部作废。这里的关键在于缓存命中与否只取决于这一步输入的文件是否变了。Dockerfile 的做法是把清单单独先拷进去# 只拷锁定文件不拷任何源码 COPY package.json package-lock.json ./ COPY pyproject.toml uv.lock ./ RUN uv sync --frozen --no-install-project --extra all --extra messaging --extra otlp前端也一样web/和ui-tui/的构建层排在源码COPY之前改 Python 不会重打前端。实际跑下来纯源码提交的热构建只剩前端打包加一次源码拷贝冷构建时间能压到 2-3 分钟量级而 s6-overlay 那段还故意用curl --retry替代ADD因为 CDN 抖一下就能废掉一次 15-45 分钟的构建。构建工具链别漏进运行时多阶段构建的正确姿势镜像里最贵的死重往往不是业务代码而是构建工具链gcc、cmake、头文件、编译器跑起来根本用不上却每个都几十 MB 起步。单阶段构建的问题就在这——编译完不删东西镜像就永远带着它们。Hermes 的解法是把造轮子的和用轮子的放进不同阶段最终镜像只做COPY --fromFROM debian:13.4 AS sqlite_build # 只为编译修 WAL bug 的 SQLite FROM ... AS uv_source # 只借 uv 可执行文件 COPY --fromuv_source /usr/local/bin/uv /usr/local/bin/ COPY --fromsqlite_build /opt/sqlite-fixed/lib/libsqlite3.so.3.53.4 /usr/local/lib/注意 SQLite 是从源码编译的Debian 13 自带版本有 WAL-reset 损坏 bug但最终镜像里只留下一个.so文件Node 26 也是从上游 slim 镜像拷二进制加 npm而不是 apt 装一整棵树。这套构建依赖隔离下来最终层里没有任何编译器和头文件体积上少的是 300MB 量级且 apt 层统一--no-install-recommends加rm -rf /var/lib/apt/lists/*系统依赖本身也被压到最小。依赖裁剪能省多少别用 --all-extras依赖装多了不涨冷启动时间涨的是体积、拉取时间和供应链风险。坑点是 Python 的--all-extras它会顺带拉进[rl]torch、wandb 等 git 依赖、[yc-bench]、[termux-all]这些生产容器根本不用的东西体积直接翻几倍。所以 Dockerfile 里是点名的 extra 白名单# 排除 [dev]排除 [rl]/[yc-bench]/[termux-all]只装生产需要的 RUN uv sync --frozen --no-install-project \ --extra all --extra messaging --extra otlp \ --extra anthropic --extra bedrock --extra azure-identity \ --extra hindsight --extra matrixnpm 侧同理装完立刻npm cache clean --forcePhoton 边车的依赖树单独一层、单独清缓存。更巧的一招在运行时那些低频后端 SDKFirecrawl、Exa 之类走HERMES_LAZY_INSTALL_TARGET/opt/data/lazy-packages装到数据卷上而不是镜像层镜像保持干净按需才付这个成本。构建上下文与运行时布局最后一层隐形优化体积问题收尾后还有两笔容易被忽略的账上下文和运行时。先看 .dockerignore——它排除.git、node_modules、tests/、docs/、*.md甚至apps/整个桌面端目录只放行apps/shared/这个 workspace 依赖。上下文小了COPY . .传输快而且构建时生成的产物如ui-tui/dist/被排除后反而不会反向击穿前面的 npm 安装层缓存。运行时布局上镜像把/opt/hermes整层封成 root 只读可变状态全放进/opt/data卷COPY --link --chmod把 30k 个文件的权限在拷贝时一次性烙好省掉此前全树chmod的 21samd64到 222sarm64HERMES_DISABLE_LAZY_INSTALLS1加上 s6-overlay 监督让容器重启行为完全确定冷启动路径里没有运行时偷偷装东西这一步。收个尾维度优化前优化后冷构建15-45 分钟2-3 分钟量级依赖安装每次提交重复 4-5 分钟锁文件不变则整层缓存命中全树 chmod21s / 222s拷贝时一次完成构建工具链泄漏进运行时零编译器残留体积决定拉取速度分层质量决定构建速度运行时不可变布局决定启动确定性——这三件事做完容器镜像优化基本就到位了。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考