那天在群里看到一句老话翻新：“本地 2B 小模型就是玩具，跑着玩可以，干活没戏。”我本打算嘲笑两句就完事，结果第二天手贱：翻了台旧机器出来，i5-8400、16GB 内存，没有独显，只有一块 UHD 630 核显；再从网上下一个二十亿参数级别的开源小模型，量化成 GGUF，挂进一套 agent harness 工具链，把文件读取、提示词优化、skill 工作流、代码回退这些装备全部装上。两个晚上，这台连风扇都懒得转的“古董”真的替我把三类真实任务干完了：整理技术笔记写综述、生成批处理脚本、批量提取文档信息。这篇文章不是跑分评测，是我完整的过程记录，包括装插件失败、读文件权限崩溃、改坏 skill 回退这些破事，你会看到一台只有核显的机器，到底怎么把“玩具模型”用出生产力。
1. “2B 就是玩具”这句话错在哪
1.1 “玩具论”是怎么来的
先说句公道话：会喊出“2B 是玩具”的人，大概率是拿 7B、14B、70B 的标准去要求它了。这很自然。早期的 2B 级别模型确实拉胯：生成能力弱、指令跟随不牢、上下文稍微长一点就开始复读、逻辑推理更是漏成筛子。你让它在手机里当个聊天彩蛋，它干得不错；你让它“帮我写一份市场分析报告”，它给你输出三段车轱辘话。这时候任何人都会有一个直觉判断：这玩意儿就是玩具。
问题在于，很多人把“跑过一次不理想”跟“这模型能力不行”直接画了等号，然后转身去下 70B，得出“只有大模型才能干活”的结论。我过去也是这么想的，直到我发现一件事：我们使唤小模型的方式，根本就是大模型的使用方式。大模型冗余能力强，一句含糊的 prompt 它能自动猜补齐、自己规划出结果；小模型没有这个冗余，你让它猜，它就瞎编。
1.2 小模型不是能力弱，是“任务设计”经常不对
我举个我没少干过的例子。你直接对 2B 说：“把这份材料里的核心问题找出来，汇总成一个报告。”2B 会干什么？它会真的尝试一次性读完整个材料，然后给你一个凯莉式的总结，里面有一半是它自己补的。为什么？因为这个任务本身包含了好几个子任务：读取、理解、筛选、归纳、结构化输出，再加上一个隐含的“判断什么重要”的能力。大模型能一口气扛下来，2B 扛不住。
但如果你换个姿势，把任务拆成单步的、带明确输入的子任务，比如：“读一下你刚收到的文件前 500 字，只输出三个关键实体，不要解释。”2B 完成得很好。再比如：“给你三段文本，把里面所有数字提取成 JSON。”2B 依然完成得很好。
这就是我在整篇文章里始终反复强调的一个核心观点：2B 不适合“面面俱到的大包大揽型任务”，但它非常适合“明确输入、明确输出、单步操作、格式受限”的任务。前者像让新人做项目经理，必崩；后者像让新人做流水线工序，可以非常稳。
1.3 2B 真正能干的活：单步、抽取、格式化、工具联动
结合我这几天的实测，2B 干得好的任务基本就这几类：
- 信息抽取：从一小段文本里提取人名、时间、文件名、路径、参数。这种任务对推理要求不高，对格式要求高，2B 的输出结构反而比大模型更规矩，因为它没有太多“自由发挥”的空间。
- 改写与缩写：给它一段 500 字的段落，要求压缩成 50 字，不增删事实。成功率相当高，因为这是语言模型最基本的统计能力。
- 函数参数生成：根据工具描述和用户意图，输出一条合法的调用参数。这是 harness 的黄金搭档场景，我在第 5 章会细讲。
- 分诊分类：判断用户问题属于哪一类、应该路由到哪个 skill，这种低维度分类任务 2B 表现不错。
你看，这些任务有个共同特点：不需要漫长的多步推理，不需要强大的世界知识，不需要超高层次的抽象归纳。它们只需要模型老老实实做“规定动作”。问题来了，谁能保证 2B 老老实实做规定动作？这就需要 harness 出场了。
2. harness 到底是什么：它不是 agent，是给 agent 的“马具”
2.1 先理清概念：harness 和 agent 到底啥关系
最近社区里被问烂的一个问题就是“harness 和 agent 区别”。我先给一个直白定义：
agent，是让模型自己扮演“大脑加双手”，自己去规划、选工具、执行、纠错。harness，是模型外面那一整套“车架子”：模型只是引擎，harness 负责给你方向盘、刹车、仪表盘、油路和外壳。你问“哪个重要”，答案是缺一不可。实际产品里两者是嵌套的：harness 作为一个运行框架，内部承载 agent 决策逻辑；agent 是你要实现的目标，harness 是让这个目标成真的基础设施。
一个更好的类比：引擎决定了这台车最高能跑多快，但方向盘、悬挂和轮胎决定了它能不能平稳到达目的地。2B 这台引擎排量小，速度上限低；可如果其他部件全部齐备，依然能稳稳跑完一段路。70B 是大排量引擎，但没装悬挂就上赛道，一样翻车。社区里大家在讨论的“deepseek harness”“agent harness”，本质上就是这个“车架子”，只是每个人装的零件配置不一样。
2.2 harness 的核心装备：五件套
我这次用的 harness 配置，可以总结成五件套，你在任何同类工具里都能找到对应概念：
- 模型端点管理：统一管理模型连接，可以指向本地、内网或者外部 API。我全部指向了本地 llama.cpp server，所以完全不依赖云服务、不需要任何外网请求。
- 提示词/指令管线：把用户那堆杂乱需求（“帮我看看这文档顺便改改”）重写成结构清晰的短指令，再喂给模型。这一层对 2B 是续命的，别省。
- 工具注册：把文件读取、目录列举、代码执行、网络请求这类能力挂成一个一个函数，让模型按需调用。工具就是 harness 给模型装的“手”。
- Skill 包：预置的“工作流模板 + 工具约束 + prompt 模板”套餐。例如“写综述 skill”“批量提取文档信息 skill”。skill 的核心价值是把经验固化下来，2B 不需要每次重新摸索。
- 会话记忆与权限墙：控制模型能读写哪些路径、能否执行 shell、工具调用需要什么审批。这一层既是安全边界，也是质量边界——不给模型太多自由度，反而它能干得更好。
2.3 为什么 2B 特别需要 harness
大模型裸跑能成事，是因为模型自己把“任务理解”“规划”“纠错”都做完了；2B 做不到，它的语言能力本来就捉襟见肘，如果再让它把宝贵的上下文拿去理解混乱的人类指令，那真就没什么余力了。
harness 做的事情是“把重活提前干完”：任务怎么拆、流程怎么走、工具调哪个、结果怎么拼，全部由代码、模板、规则固化下来。模型真正要做的只有一件事：在给定节点做输出。这等于把 2B 从“项目经理”降级成“流水线工人”，而流水线工人恰恰是它最擅长的角色。
我自己的实测结果非常直观：裸跑 2B，让它“整理一份 Markdown 笔记成摘要”， 10 次里大概有 3 次能看外面；套上 harness 再跑同样任务，成功率直接拉到八成以上。模型没变，变的只是它周围的那套“马具”。
3. 核显不是不能跑，是得会算账：UHD 630 的硬件现实
3.1 UHD 630 到底什么水平
先把关于核显的幻想剥干净。Intel UHD 630 是 2017 年前后的核显，集成在第八代酷睿桌面 CPU 里，规格大致如下：
| 项目 | UHD 630 典型值 | 对比参考 |
|---|---|---|
| 执行单元（EU） | 24 | RTX 3060 有 3584 个 CUDA 核心 |
| 最大动态频率 | 约 1.1-1.2GHz | 独显普遍 1.5GHz 以上 |
| FP32 算力 | 约 0.4-0.5 TFLOPS | RTX 3060 约 12.7 TFLOPS |
| 显存 | 从系统内存中共享，通常在 128-512MB 之间 | 独显有独立 GDDR 显存 |
| 内存带宽 | 共享 DDR4 双通道带宽约 30-40GB/s | 独显显存带宽 300GB/s 起步 |
结论很残酷：UHD 630 这代核显的算力只有主流入门独显的 3% 左右，而且没有独立显存，数据全靠 CPU 挤内存带宽。指望它加速本地大模型，基本是给骆驼身上装火箭，插了翅膀也飞不起来。
3.2 核显机型跑模型的正确算账方式
但“核显不能加速”不等于“核显机器不能跑模型”。我花一分钟给大家算笔账，你就明白为什么核显机器其实很适合跑 2B 小模型：
推理过程耗资源最大的两件事，一个是“把模型权重从内存搬到计算单元”，一个是“做矩阵乘法”。前者吃内存带宽，后者吃算力。2B 模型量化成 Q4_K_M 之后权重大约 1.5GB，每生成一个 token 都要把所有权重过一遍。DDR4 双通道的理论带宽 38GB/s 左右，实际能跑 25-30GB/s，这意味着光搬权重一个 token 就要 50 毫秒左右，换算下来上限也就 20 token/s 左右。再算上计算效率损失，最终 8-12 token/s 是一个正常区间。
这恰好是 CPU 的舒适区：现代 CPU 的 AVX2 指令集在矩阵乘上相当高效，而且 CPU 直接吃内存，数据不用在“系统内存”和“显卡显存”之间来回拷贝。反过来，如果硬要 UHD 630 的 OpenCL/Vulkan 参与计算，它虽然能算，但算力低，还要把权重先复制到它那点共享显存里，再算完复制回来，来回折腾几次，反而更慢。
3.3 我的具体配置与选择逻辑
我这台机器是 i5-8400 六核六线程，支持 AVX2，16GB DDR4 双通道内存，系统 Windows 10。选它没有任何特殊理由，就是一台淘汰下来的办公机。如果你的机器是单通道内存，建议先加一根内存条组成双通道，对推理速度的提升非常明显——严格来说它比换 CPU 还重要。
模型方面，我选了一个 2B 级别的指令微调开源模型，GGUF 量化格式。量化档位我建议直接用 Q4_K_M：权重体积约为 1.5GB，质量损失在可接受范围；如果你想再保一点精度，Q8_Q 也就 2.7GB，CPU 依然跑得动，但速度会再降一截。FP16 原版就算了，CPU 上慢一倍还不值得。
内存账面我算过一次，非常值得记下来：
| 占用来源 | 预估值 |
|---|---|
| 2B Q4_K_M 模型权重 | 约 1.5GB |
| KV cache（8192 上下文，依模型结构浮动） | 0.7-1.1GB |
| 推理引擎运行时 buffer | 0.2-0.3GB |
| harness + 节点进程 + 前端 | 0.5-1GB |
| 操作系统自身 | 3-4GB |
合计约 7-8GB。这就是为什么我说 8GB 内存也能挣扎跑，16GB 才是舒服线——跑起来后系统还有一半内存余量可以做别的事，不会让整个机器卡成 PPT。
3.4 实测：纯 CPU 和核显加速的真实差距
我在 llama.cpp 上分别跑了三种模式：
| 模式 | 预填充速度（pp） | 生成速度（tg） | 稳定性 |
|---|---|---|---|
| 纯 CPU，AVX2，6 线程 | 150-250 token/s | 8-12 token/s | 连续跑一周无崩溃 |
| 开启 Vulkan（UHD 630） | 80-120 token/s | 4-6 token/s | 偶发报错，分辨率越高越不稳 |
| 开启 OpenCL | 更低 | 3-5 token/s | 直接放弃 |
实测下来结论非常清晰：在这台只有 UHD 630 的机器上，核显的作用就是“显示桌面”，真正的推理全交给 CPU。8-12 token/s 听起来不快，但对于第 5 章那种单步任务，每次响应也就三四秒，完全够用。如果你手头是较新的核显，比如 Intel Iris Xe 或者 AMD 780M，那另当别论，它们确实能开 GPU 加速并拿到明显收益；UHD 630 这个级别，别折腾。
4. 跑通 harness 的完整链路：从安装到模型接入
4.1 安装时的第一个失败：插件 web boot 报错
安装 harness 本身不难，难的是装第三方插件。我第一次装一个社区插件时，启动日志直接给我来了一句：
failed to load plugins web boot: 1 entry did not activate huayu-yuan先解释一下这个报错拆解：插件系统启动时会扫描插件目录，每个插件会声明一个“入口文件”，日志里这个入口没成功激活。通常有三个原因，按概率排序：第一，插件入口指向的源码文件（比如 src/main.tsx）没有被构建成可加载的产物（dist 目录缺失）；第二，manifest 里入口路径写错了，或者大小写不对；第三，插件版本和 harness 版本不匹配，API 结构变了。
我当时的表现是：先暴力重启，没用；再卸载重装，还是没用；最后老老实实去看插件目录下的 manifest 文件，发现 entry 指向src/index.ts，而实际项目里根本没有构建过 dist 目录。解决办法也很朴素：进插件目录跑一次构建，把 entry 指向改成构建产物，重启。针对这类问题的通用排障顺序是：看日志定位是哪个插件 → 打开插件目录检查 manifest 和入口文件 → 确认构建产物存在 → 再查版本兼容。别一上来就重装系统。
4.2 把 harness 指向本地模型：不登录、不依赖云服务
很多朋友在评论区问“deepseek harness 怎么接免费模型”“claude code harness 可不可以不登录用其他模型”。原理其实就一句话：只要你用的 harness 支持自定义模型端点，并且本地有一个 OpenAI 兼容的端点，就能接进来。我用的配置是这样的：
model_provider: base_url: "http://127.0.0.1:8080/v1" api_key: "local" # 本地端点不需要真实 key，占位即可 model: "local-2b-q4"对应的本地推理进程是 llama.cpp 自带的 server：
./llama-server \ -m ./models/2b-instruct-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8080 \ -c 8192 \ -t 6 \ --mlock几个参数我解释一下：-c 8192是上下文长度，2B 模型配 8K 足够日常任务；-t 6是线程数，i5-8400 六核刚好；--mlock是把模型权重锁在内存里，防止系统把它换入换出导致响应忽快忽慢。这个组合非常稳，全程不需要任何外网请求，也不涉及任何登录。
4.3 Skill 包部署到内网服务器的完整流程
另一个高频实用场景是“deepseek harness 附带 skill 怎么部署到内网服务器”。这里有一个背景：很多公司内部环境是完全离线的，harness 本体装好容易，skill 部署却常常卡在“离线没有插件市场”。
我的做法是把 skill 当成一个普通目录整体搬运。一个 skill 本质上是三样东西：一个 manifest.json、一个 prompt 模板、一组允许访问的路径白名单。比如我写的“写综述 skill”目录结构大概是：
skill_review/ ├── manifest.json # skill 名称、描述、版本、入口 ├── prompt.md # 系统提示词模板 └── allowed_paths.txt # 允许读取和写入的目录白名单离线部署时，把整个目录拷进内网机器上 harness 指定的 skills 目录，再在 manifest 里注册一下即可。注意两点：一是模型文件一定要校验哈希，避免从移动硬盘拷到一半损坏，我踩过一次，表现是模型加载到 80% 报校验失败；二是离线环境不要试图连接公共插件市场，手动放置更靠谱。
4.4 提示词优化插件：小模型的命根子
在所有可选插件里，对我这套组合提升最大的不是花哨的工具包，而是一个“提示词优化插件”。它的作用很朴素：把用户一句又长又乱的原始请求，改写成一个“短、结构化、任务明确”的指令，再喂给 2B。
我举个例子。用户说：“帮我看看这个文档有没有问题，顺便把格式改一下，反正是新人写的代码，你应该能看懂吧。”这种话喂给大模型没问题，它能自动忽略废话抓重点；喂给 2B，它容易犯迷糊。提示词优化插件会把它改写成这样：
1. 读取文件：D:\workspace\code\api_client.py 2. 检查是否存在明显的语法错误和变量未定义 3. 以列表形式输出问题所在行号和修复建议 4. 不要修改原始文件实测效果：接上这个插件后，我的任务成功率从六成左右上升到八成以上。原因很简单，2B 的语义理解容量有限，你把它有限的注意力集中在真正重要的指令上，它自然干得更准。这也解释了为什么社区里推荐“deepseek harness 实用插件”时，提示词优化类永远排在最前面。
5. 用 2B 干真活的现场记录
5.1 任务一：把一堆零散笔记整理成综述
我的第一个任务是把 30 篇 Markdown 技术笔记整理成一份 3000 字的综述。如果直接丢给 2B：“把这些笔记写成综述。”它只会哀嚎。所以我先在 harness 里写了一个“综述 skill”，核心思路是“拆、分、合”三步：
- 拆：把 30 篇笔记按章节拆成约 120 个小片段，每个片段控制在 1000 字以内。
- 分：每个片段单独请求 2B，只让它做一件事：抽取“这个片段讨论的主题 + 一到两个关键结论”，不要生成任何延伸内容。
- 合：再用 2B 把这些抽取结果按时间线/主题分组，生成一份目录骨架，最后脚本把全文拼接，加上我定好的格式模板。
效果出乎意料地好。事实性的结论几乎抓全了，格式也工整；不足在于某些总结句有点笼统，比如“文件提到性能问题”，却没写具体瓶颈参数。这属于 2B 类模型的通病：抽象概括时容易飘。解决办法是把 prompt 改成“必须引用原文中的具体数字或关键词”，准确率明显改善。
5.2 任务二：让 2B 调用工具生成批处理脚本
第二个任务需要处理一批数据文件。我手上有一个“文件转换工具包”，里面暴露了三个 harness 工具：list_files、read_metadata、run_python。2B 完全不懂数据格式转换的内部实现，但它不需要懂，它只需要判断“下一步调用哪个工具、传什么参数”。
实际执行流程是这样的：
- 第一步，2B 调用
list_files("D:/data/raw")，拿到全部文件名，注意到扩展名是.nc，目标格式是.csv。 - 第二步，调用
read_metadata("D:/data/raw/sample.nc")，读出来变量列表、时间维度长度。 - 第三步，2B 根据工具说明生成一段 Python 脚本，脚本里调用转换库，循环处理所有文件。
- 第四步，调用
run_python执行。
结果第一版脚本确实有 bug：它把输出路径硬编码写死了，导致第二个文件直接覆盖第一个文件。不过这个 bug 也正是由 2B 自己发现的——它执行完后调用工具列表一对比，发现输出文件数对不上，然后自己修正成按源文件名生成输出路径。整个过程不需要人中途介入。
这里有个重要心得：工具链越窄，2B 越稳。我这轮只暴露 3 个工具，它的决策准确率很高。如果我一次性塞给它 20 个工具，它的选择就开始飘了。所以我在 harness 里给每个 skill 都配置了最小工具集合，宁可后期加，不要一开始全给。
5.3 任务三：撞上 setnamedsecurityinfow 权限问题的完整排查
第三个任务是读取一批位于项目目录下的文档，结果运行到一半，控制台突然抛出一个带 Win32 标志的错误：setnamedsecurityinfow failed (win32)。这种报错对很多搞 AI 工具链的人来说很陌生，因为它是 Windows 系统 API 层报出来的，不是模型的问题。
我的排查链路如下：
第一步：定位规律。同样一个 skill，读用户目录下的文件都正常，读D:\workspace里的文件却报错。这基本锁定不是 harness 的 bug，而是系统对某些路径/文件有访问限制。
第二步：用系统自带工具看权限。我在命令行执行icacls "D:\workspace" /T /Q，发现该目录的 ACL 里根本没有我当前用户的写权限，于是尝试给当前用户加上完全控制权限：
icacls "D:\workspace" /grant "用户名:(OI)(CI)F" /T执行完权限确实加上了，但再跑 harness，依然报同样的错。此时我意识到问题可能不是传统 ACL，而是 Windows 的“受控文件夹访问”在拦截。这是 Windows 安全中心里的一项勒索软件防护功能，它会在软件尝试对某些目录做安全描述符修改时直接拦掉，哪怕你已经是管理员。
第三步：验证。打开“Windows 安全中心 -> 病毒和威胁防护 -> 勒索软件防护 -> 受控文件夹访问”，查看受保护文件夹列表，发现D:\workspace确实在里面。解决方案有两种：要么把这个目录加入“允许应用”，要么直接把工作目录整体挪到当前用户主目录下，例如C:\Users\用户名\workspace。我选了后者，最省事，而且以后也不会有这类隐藏坑。
这件事给我的教训是：Win32 权限报错，不要从一开始就归咎于 harness 或插件，先分清“访问控制层”和“应用层”；尤其在 Windows 上跑本地 AI 工具链，把工作目录放在用户主目录里是成本最低的避坑方式。
5.4 代码回退：改坏 Skill 之后怎么恢复
第四个事故是我自己作出来的。当时为了加快综述速度，我修改了“综述 skill”的 prompt 模板，把变量名{{content}}全部改成了{{body}}，但 manifest 里没同步改，结果整个 skill 初始化直接失败。更尴尬的是我没有备份。
后来我找到了 harness 里一个不太起眼的快照功能：它会在每次加载 skill 失败时，把上次成功加载的版本复制到backup目录。顺着这个目录我把旧版 prompt 找回来，问题解决的瞬间我第一反应是：以后必须把 skills 目录纳入 git 管理。
实际建议很简单：无论你用什么 harness，请在第一次配置完成后，立刻对 skills 目录执行一次git init && git add . && git commit -m "initial skills"。之后每次改 skill 前随手 commit 一次。这个习惯会救你很多次。我后来还加了一步：改之前手动复制目录，命名成skill_xxx_backup_日期，双保险。
5.5 边界：哪些任务我不交给 2B
把一个模型用到顺手的前提，是知道它的边界并主动避开。经过这一周实测，这几类任务我坚决不交给 2B：
- 超过 2000 字的连贯长篇论述。它写到后面会开始重复，或者丢掉前文线索。
- 需要多步逻辑推理的问题，比如数学推导。2B 的中间步骤一旦超过三四步，正确率会断崖式下跌。
- 一次性要求读很多文件的“汇总型任务”。它做不到，但 harness 先把文件拆好之后它可以。
- 任何影响生产数据的写操作。我让它生成过脚本，但从不让它直接操作核心数据库，工具白名单也刻意排除了这类。
知道边界不是贬低它，而是把它放在正确的位置上。就像你不会让实习生去签最终合同，但你完全可以让实习生把发票整理得一丝不苟。
6. 这套组合能稳定跑多久：配置清单与日常心得
6.1 连续一周运行的稳定性表现
这台机器我连续跑了一周，每天大约开 4 小时，llama.cpp 和 harness 都在前台运行。整个过程中没有崩溃、没有内存泄漏迹象。内存占用稳定在 7-8GB 上下，UI 操作流畅，风扇偶尔转一下但完全不吵。核显在整个过程中几乎零负载，因为它确实没参与推理。
唯一出现的幺蛾子是 Windows 自动更新，它半夜自动唤醒机器并准备重启，导致第二天早上任务队列积压。我的处理方法是把机器“活动时间”范围拉长，并且关闭了自动重启。如果你也打算长时间跑本地推理服务，这步别忘。
6.2 什么时候用 2B，什么时候切大模型
harness 允许配置多个模型端点，我保留了另一个指向内网大模型的入口。我的分流原则很简单：
| 任务类型 | 默认模型 | 原因 |
|---|---|---|
| 信息抽取、格式化输出 | 2B | 又快又稳，足够 |
| 工具调用、脚本生成 | 2B | 工具链收窄后成功率足够高 |
| 长文归纳、深度代码重构 | 大模型 | 上下文长、抽象推理要求高 |
| 关键决策、生产环境脚本审核 | 人类自己 | 这个谁也别抢 |
原则是：能让 2B 干的尽量不占大模型额度；要让大模型干的，也别为了情怀硬用 2B。你会有一种很清晰的“分级用模型”的感觉，就像团队里有人写文档，有人做复核。
6.3 可直接抄作业的完整配置清单
最后还是把整套配置清单列出来，方便想复现的朋友直接从这一节开始：
- 硬件：任意六核以上支持 AVX2 的 CPU，16GB 双通道内存，核显无所谓，固态硬盘留 30GB 空间。
- 软件：llama.cpp server + 一个开源 agent harness。
- 模型：2B 级别 instruct GGUF，量化档选 Q4_K_M。
- 启动参数：
llama-server -m model.gguf -c 8192 -t 6 --mlock。 - harness 端点：
base_url=http://127.0.0.1:8080/v1，模型名任意。 - Skill 目录：统一放在用户主目录下，用 git 管理。
- 工具暴露原则：每个 skill 最多 3-5 个工具。
- 提示词优化插件：必装，没有它 2B 的可用性降一个档次。
6.4 三句话的经验总结
跑完这三个任务，我自己沉淀下来的经验其实就三条：
第一，别把核显当成加速器。UHD 630 这个级别的核显只负责显示，CPU 的 AVX2 才是真正的推理引擎；与其折腾 GPU 加速，不如把内存双通道和线程数调好。第二，模型越小，任务拆得越细，工具暴露得越少。2B 不是全能冠军，但它合适当“专岗专责”的好员工。第三，harness 的价值不在于让 2B 变成 70B，而是让 2B 把它那 20 亿参数里最有用的部分，稳定输出，一次都不掉链子。
跑完这一圈我是真明白了：2B 不是玩具，它只是需要一套真正合身的 harness，把这二十亿参数里最有用的那部分榨干净。
