Anatomy Skill本地实测：1.7B小模型的全链路失败

一场注定不对等的实验

把一个为前沿模型设计的 Agent Skill，塞给一台没有 GPU 的 Debian 机器，再配上一个 17 亿参数的本地模型，会发生什么？开发者用 Anatomy 这个项目做了一次相当诚实的压力测试，结论分两层：工具本身是真的，但小模型驾驭不了它。

Anatomy 是一个 MIT 协议的 Agent Skill，从 10 月 8 日新建仓库到 13 日早上已积累 6,632 颗 GitHub 星。它能在 Claude Code、OpenCode、Codex 和 Antigravity 里运行：你输入 /anatomy 加一个想法，Agent 就要发明一台物理机器，让它的运转机制本身表达那个抽象概念，然后用几十个带阴影的小零件拼成一个可交互的等距投影 SVG。

测试者的硬件是一台 8 vCPU、16GB 内存（测试时只剩约 4GB 空闲）、无 GPU 的 Linux 盒子。上面没有 Claude Code，没有 Codex，也没有云 API key。于是实验变成：OpenCode 1.19.0 指向 Ollama 里的 qwen3:1.7b，纯 CPU 推理。

安装过程截图

Agent Skill 是一种在 Claude Code、Codex 等 Agent 框架中按需加载的能力包，通常由一个 SKILL.md 主文件加上若干参考文档、脚本和示例目录组成。它与普通「提示词模板」的区别在于三点：一是 Agent 可以在运行时按需读取其中的子文档，二是其中可以封装确定性的可执行脚本（构建、检查、截图），三是它定义了一整套工作流，要求 Agent 按步骤调用工具而非凭记忆直接输出结果。这种设计让强模型能做出稳定、可验证的产物，但代价是提示词体积大、调用链长，对模型的长程指令遵循能力要求很高。理解这一点，是理解本文「工具层跑得通、模型层跑不动」这一结论的前提。

工具层表现：快、确定、会自我审查

在引入任何模型之前，测试者先跑通了不依赖智能的部分——这恰恰是 Anatomy 最令人惊艳的地方。

零依赖的确定性构建

三个示例项目用纯 Node 脚本重建，没有任何 npm 依赖，全部退出码为 0，git status 干净，重建产物与仓库中提交的版本字节完全一致。最重的 Raptor 引擎示例耗时 115 秒，与文档中「几分钟」的说法吻合。

这种字节级可复现性，意味着工具链本身是可验证的，不会因为环境漂移产生随机输出。

几何审计是真正的亮点

不只是渲染图形。它要证明没有任何零件穿过另一个零件，并且每个重叠都以正确顺序绘制。街机柜示例的审计输出：15 根管线、243 个实体、349 个项目、1,290 个重叠对、1,290 条绘制顺序规则，11 秒内完成并通过。

这个审计机制解决的是生成式图形工具里最容易被忽略的问题：当模型画出一堆看似合理的图形时，没人知道它们内部逻辑是否自洽。Anatomy 用确定性的检查填补了这个空白。

等距投影（isometric projection） 是一种特殊的轴测投影：三条坐标轴在画面上以相等的角度（通常各相隔 120°）展开，且不产生近大远小的透视收缩。它常被用于技术插图、游戏素材和工程装配图，因为同一尺寸的物体在画面任何位置都保持同样大小，便于表达「零件与零件之间的机械关系」。本文中的 Anatomy 要求 Agent 用几十个带阴影的小零件拼出等距投影 SVG，正是在借助等距投影的这一特性：零件间的遮挡、层叠和穿插关系必须被显式排序，才能画对——这也解释了为什么几何审计要统计「重叠对」和「绘制顺序规则」，而非仅仅渲染出图形。

无头浏览器检查

截图脚本能产出带实时读数的画面（比如「读数为 13.8 px」），线端检查确认 367 条线中没有一条漂浮悬空，控制台干净无报错。这些数字都来自图形自身的模型——这正是该 Skill 的核心承诺：每一个数字都源自图形自己的模型，而非凭空生成。

模型层表现：三次全线失败

当实验进入真正需要模型驱动的阶段，情况急转直下。Skill 本身是一份 31,600 字节的 SKILL.md，外加约 300KB 的九份参考指南，运行时按需加载。光是注入的提示词就有约 7,700 输入 token，CPU 上读取这段提示要花 45 到 70 秒，生成速度约每秒 4 到 5.5 token。

三次测试无一产出合格图形：

令牌桶限流器（独立 HTML，浅色）：运行 16 分钟，退出码 0，但没有写出任何文件。模型把整个任务丢给了 OpenCode 的 explore 子代理，后者返回空结果。它花了 1,560 token 思考，最终没有回答。

CDN 边缘缓存命中/未命中（TTL 60 秒，只要 SVG）：8 分 23 秒，写出了一个文件——738 字节。三个普通圆圈，两个标注「Hit」和「Miss」，两个「60s」标签。它从未打开过工具包、示例或任何参考文档，也没跑过任何构建或检查，尽管 Skill 的工作流明确要求「像批评家一样验证」。它还在 SVG 的 transform 属性里用了 CSS 风格的 rotateX(-30deg)——SVG 根本不支持，Chrome 直接忽略，导致两个圆圈堆叠在左上角，大部分在画布外。更糟的是，文件被写进了 Skill 自己的安装目录，而不是项目目录。

数据库连接池（10 个连接，排队机制，深色主题）：10 分 37 秒。页面是黑底上的平面 2D SVG。「10 个连接」是两个画在同一位置的圆圈，后面跟着注释 。队列是一个圆圈加 。没有等距投影，没有工具包调用，没有读数，没有动效，没有任何检查。

上下文窗口（context window） 指模型在一次推理中能同时容纳的 token 总量，包括系统提示、注入的 Skill 文档、历史对话和待生成的输出。本文中光是 Skill 注入就占约 7,700 token，再叠加约 300KB 按需加载的参考指南，对 17 亿参数的小模型而言，可用预算被迅速挤占：一旦任务需要跨多轮读取文档、调用脚本、检查结果，早期指令就会被挤出窗口或稀释，模型逐步「忘记」自己在做什么。子代理（subagent） 则是 Agent 框架把子任务委派给独立上下文的一种机制，本来用于分担主上下文压力，但在弱模型下容易变成「甩锅」——把任务转交出去后自己不收回结果，本文第一次测试的「没有写出任何文件」正是这种失效模式。

崩溃点在哪里：工具包无法弥补弱模型

必须公平地说：这是一个 17 亿参数的 CPU 模型，被要求遵循一份 7,700 token 的工艺手册。Skill 让模型去收集真实数字、发明一个物件、编写零件清单、用工具包构建几何、审计并截图每个关节。这是一个很长的 Agent 循环，小模型根本维持不住。

但这些运行结果也清楚地表明一件事：Skill 里没有任何机制能弥补一个弱模型。工具包只有在 Agent 真正调用它时才有用。

这个发现对本地部署路线有直接的现实意义。很多人期待用一个便宜的本地小模型来驱动复杂的编码和生成任务，但当一个 Skill 的提示词本身就耗尽了你模型的大部分上下文窗口，当一次生成需要几分钟而模型只能维持在每秒几个 token 时，多步骤工作流就变成了一个几乎不可能完成的任务。

附带发现的工程问题

测试还暴露了一些与模型无关的工程摩擦：

npx skills add 在 Node 20 上直接崩溃，尽管 Anatomy 自身只需要 Node 20.10+。CLI 工具链要求 Node 22.20+，文档虽然提了，但藏在一个折叠段落里。
CLI 安装到了 ~/.agents/skills/anatomy，而文档里 OpenCode 对应的行写的是另一个路径。OpenCode 碰巧也会读 .agents 目录，所以还能工作，但文档与实际行为不一致。
225 个测试中有 5 个失败，全都是依赖 React 的测试文件，而 React 并未安装。文档说明 React 只在输出 React 时才是必需的，所以这是环境配置缺口而非 bug——但这 5 个测试应该干净地跳过，而不是失败。
opencode run 不加 < /dev/null 会卡在 init 状态长达 13 分钟，因为它在等 stdin。这个 300 秒的默认超时也会杀死慢速本地模型的长响应。

用还是不用

如果你已经用 Claude Code 或 Codex 配一个强模型，并且从事文档撰写或技术写作，值得一试。最值得关注的不是提示词，而是底下那套工具包——它是确定性的，并且以其他「帮我画图」工具里从未见过的方式自我检查。建议从构建 examples/dial-indicator 开始，读那大约 300 行代码，比看任何截图都更有信息量。

如果你指望用本地小模型驱动它，1.7B 级别不行。Skill 很长，工作流很长，文档自己都说它「故意很慢」。为一台有余力的机器准备一场长会话，并做好要检查它生成的 PNG 的准备。

一个更宏观的启发是：Agent Skill 的能力上限，很大程度上取决于它所依赖的模型能否维持长链条的指令遵循。工具层的工程质量可以做到很高，但真正的瓶颈往往在模型那一端。