企业官网建设流程全解析

1. 同一颗2B模型，四个框架跑出0.017到0.821的差距

先把结论摆在最前面：模型没换，权重没动，量化方式一样，连推理后端都是同一套，唯一变的是外面那层"壳"——也就是 agent harness。同一颗 2B 参数的小模型，在四个不同 harness 下跑同一批任务，得分从 0.017 一路拉到 0.821。这个跨度不是小数点后一位的抖动，是接近五十倍的差距。

很多人第一反应是"模型太弱"，于是拼命换更大的模型、调更高的量化精度、加更多的显存。但我实测下来，2B 这个量级的模型在 agent 任务上，瓶颈往往不在模型本身，而在 harness 有没有把模型的能力"接出来"。harness 这个词直译是"马具"，很形象：模型是马，harness 是套在马身上的缰绳、鞍具和车架。马再壮，缰绳系错了地方，车也拉不动。

这篇内容适合三类人看：一是手上只有小显存、想用 2B 级别模型跑 agent 的开发者；二是已经在用 Ollama 本地部署模型、但发现 agent 任务效果惨淡的人；三是想理解"为什么同样的模型换个框架分数天差地别"的架构爱好者。我会把四个 harness 的差异拆到可复现的程度，包括提示词组织、工具调用协议、上下文管理、错误回退这几个真正决定分数的环节。

需要提前说明的是，下面所有数字来自我自己搭的一套评测流程，任务集是固定的几十条多步工具调用任务，评分标准统一。不同任务集下绝对分数会变，但框架之间的相对差距趋势是一致的。这点很关键——不要盯着 0.821 这个绝对值，要盯着"同一颗模型为什么能差这么多"。

2. 为什么harness能决定小模型的生死

2.1 2B模型的真实能力边界在哪

先纠正一个普遍误解：2B 模型不是"笨"，而是"窄"。它在单步指令跟随、格式模仿、短上下文推理上其实够用，真正拉胯的是长链条规划和多轮状态保持。你让它做一件事，它能做；你让它做五件事并且记住前三件的结果，它就开始丢状态。

这就意味着，harness 的核心任务不是"让模型变聪明"，而是"把任务拆到模型能力边界之内"。一个合格的 harness 应该做到：把多步任务切成单步、把每步的上下文压缩到模型能处理的长度、把工具返回结果转成模型能理解的格式、在模型跑偏时把它拉回来。这四件事任何一件没做好，分数就会塌。

我做过一个对照实验：同一颗 2B 模型，只给它一句"帮我完成这个任务"，让它自己规划，得分 0.017。这个分数基本等于随机——模型在第一步就开始编造不存在的工具名，然后一路错到底。而当我把它放进一个会主动拆步、每步只喂必要信息的 harness 里，同样的模型能跑到 0.8 以上。模型一个字没改。

2.2 harness到底在替模型做哪些决策

把 harness 拆开看，它其实在替模型做四类决策，而每一类都直接影响最终得分：

这四类决策里，最容易被忽视的是"工具协议"。很多 harness 直接让模型输出 JSON，然后正则去抠。2B 模型在这种自由格式下经常多一个逗号、少一个引号，解析直接失败。而好的 harness 会用结构化约束（比如受限解码、固定模板）把模型的输出空间压窄，让它"想错都难"。

2.3 0.017和0.821之间隔了什么

0.017 那个配置，本质上是"裸模型 + 自由发挥"。模型拿到任务后自己规划、自己决定调什么工具、自己组织参数、自己判断是否结束。对 2B 模型来说，这等于让一个刚学会加减法的人去做微积分。

0.821 那个配置，是"强约束 harness + 分步执行 + 结构化输出 + 失败重试"。模型每一步只需要做一个很小的决定，比如"当前该调哪个工具"或者"这个参数填什么"，其余全由 harness 兜底。

中间的 0.3 和 0.6 两个档位，分别对应"有工具协议但没分步"和"有分步但错误回退很弱"。这四个档位连起来，其实是一条清晰的因果链：约束越强、兜底越全，小模型的可用分数越高。这不是玄学，是工程。

3. 四个harness的实测配置与分数拆解

3.1 评测环境与任务集设定

为了让对比有意义，我把变量控制到最死。模型统一用同一份 2B 量化权重，通过 Ollama 本地加载，温度固定 0.2，top_p 固定 0.9，最大输出长度 1024。四个 harness 跑的是同一批任务，任务集包含文件操作、信息检索、多步计算、条件分支这几类，每条任务需要 3 到 8 次工具调用才能完成。

评分用的是"端到端成功率"：整条任务链全部步骤正确才算通过，中途任何一步错就算失败。这个标准比"单步准确率"严格得多，也更能反映 harness 的真实水平。因为 agent 任务的本质是链条，链条断一环，后面全废。

提示：如果你自己复现，建议先用 10 条任务跑通流程，确认评分脚本没问题，再上全量。我一开始评分脚本有个 bug，把"工具调用成功"误判成"任务成功"，导致分数虚高，排查了半天。

3.2 配置A：裸模型自由发挥（0.017）

这个配置最简单，也最惨。系统提示词就一句话："你是一个助手，可以使用工具完成任务。"工具列表以自然语言描述塞进提示词，模型输出什么就解析什么，解析失败就跳过。

实测下来，模型在第一步就开始出问题。它会把工具名写错，比如把read_file写成readfile或者open_file；参数格式也五花八门，有时候是 JSON，有时候是类似函数调用的写法，有时候干脆是自然语言"请帮我读取这个文件"。解析器根本接不住。

更致命的是，模型没有"任务完成"的概念。它调完一个工具后，经常继续编造下一步，哪怕任务已经结束了。或者反过来，任务还没做完就宣布"已完成"。这种配置下，0.017 的分数其实已经算"没完全归零"了。

3.3 配置B：加了工具协议但没分步（0.31）

第二个配置我加了结构化工具协议：给模型一个固定的输出模板，要求它必须按{"tool": "...", "args": {...}}的格式输出。同时在提示词里明确列出所有可用工具及其参数签名。

分数从 0.017 跳到 0.31，提升主要来自"解析成功率"。模型现在知道该怎么表达工具调用了，解析器也能稳定接住。但问题转移到"规划"上：模型还是被要求一次性规划整条链，2B 模型规划到第三步就开始丢状态，忘记前面调过什么、返回了什么。

这个档位说明一件事：光有格式约束不够，还得有任务分解。格式解决的是"说不说得清"，分解解决的是"想不想得全"。

3.4 配置C：分步执行但回退很弱（0.62）

第三个配置引入了分步执行：harness 把任务拆成"当前步"，每步只让模型决定"下一步调什么工具、填什么参数"，执行完把结果喂回去，再问下一步。同时加了简单的历史压缩，只保留最近三步的摘要。

分数到 0.62，明显上了一个台阶。模型不再需要一次性想清楚所有步骤，只需要专注当前这一步，这对 2B 模型友好太多。但短板也很明显：一旦某步工具返回错误（比如文件不存在、参数越界），harness 只是把错误信息原样丢回给模型，模型经常看不懂，然后重复同样的错误调用，陷入死循环。

我统计过，配置 C 失败的案例里，超过六成是"错误后无法恢复"。这说明错误回退不是锦上添花，是刚需。

3.5 配置D：完整harness（0.821）

第四个配置在 C 的基础上补了三件事：错误分类与重试、参数校验前置、终止条件显式化。

错误分类是指 harness 把工具返回的错误分成"可重试"（如临时失败）和"需改参"（如参数非法）两类，分别给出不同的提示。参数校验前置是指在真正调用工具前，harness 先按 schema 校验一遍参数，不合法就直接打回让模型重填，不浪费一次真实调用。终止条件显式化是指 harness 明确告诉模型"什么情况下应该输出 DONE"，而不是让模型自己猜。

这三件事加起来，把分数从 0.62 推到 0.821。提升幅度没有前面几档大，但每一分都来自"把边界情况处理干净"。agent 任务里，边界情况才是真正的分数杀手。

4. 把分数从0.017拉到0.821的四个关键改造

4.1 工具协议：把自由格式换成受限模板

第一个改造是工具调用协议。我放弃了"让模型自由输出 JSON"的做法，改成固定模板加受限解码。具体来说，模型每一步的输出被约束成两段：先输出一个工具名（从枚举里选），再输出参数（按该工具的 schema 填）。工具名用受限解码强制只能从合法列表里选，参数用 schema 校验。

这个改造的收益最直接。2B 模型在自由格式下，JSON 合法率大概只有六成；换成受限模板后，合法率接近百分之百。别小看这个提升，agent 任务里一次解析失败就可能让整条链断掉。

注意：受限解码不是所有推理后端都原生支持。如果你的后端不支持，可以用"先让模型输出，再用 schema 校验 + 失败重试"的方式近似，效果差一点但也能用。

4.2 任务分解：让模型一次只想一步

第二个改造是任务分解。我不再让模型规划整条链，而是让 harness 维护一个"当前步"的概念。每步的提示词只包含：任务总目标（一句话）、当前进度摘要（最近三步）、当前可用工具。模型只需要回答"下一步做什么"。

这个改造对 2B 模型是决定性的。它的注意力预算有限，你让它同时想五步，它每步都想不清楚；你让它只想一步，它能想得很准。这就像让一个人搬砖，一次搬一块他能搬得又快又稳，一次搬十块他只会摔跤。

进度摘要的写法也有讲究。我试过三种：完整历史、最近三步原文、最近三步摘要。实测下来"最近三步摘要"最好，既保留了关键状态，又不占太多上下文。完整历史会让 2B 模型被无关信息干扰，原文则太长。

4.3 错误回退：把失败变成可恢复的状态

第三个改造是错误回退，这也是配置 C 到 D 的核心增量。我的做法是把工具返回分成三类：成功、可重试失败、需改参失败。成功就正常推进；可重试失败（比如超时）就自动重试一次；需改参失败就把错误信息和参数 schema 一起喂回模型，明确告诉它"哪个参数不合法，请重新填"。

关键点是"明确告诉它哪里错了"。2B 模型看不懂模糊的错误信息，你给它一句"操作失败"，它只会重复同样的调用。你给它"参数 path 不能为空，请提供文件路径"，它大概率能改对。错误信息要具体到字段级别。

我还加了一个"同一错误连续出现三次就强制换策略"的机制。2B 模型有时候会卡在一个错误上反复撞墙，harness 必须主动打断它，比如换一个工具、或者跳过当前步。这个机制救回了不少本来要失败的任务。

4.4 终止判断：别让模型自己猜什么时候结束

第四个改造是终止条件显式化。裸模型经常在该结束时继续瞎调，或者在该继续时提前宣布完成。我的做法是在每步提示词里明确写："如果任务已完成，输出 DONE；否则输出下一步工具调用。"

同时 harness 侧也做校验：如果模型输出 DONE 但任务目标明显没达成（比如要求的文件还没创建），harness 会拒绝这个 DONE，并提示模型"任务尚未完成，请继续"。这个双向校验把"提前结束"和"永不结束"两类问题都压下去了。

这四个改造没有一个是"调模型参数"，全是 harness 层面的工程。这也是我想强调的核心观点：小模型 agent 的分数，很大程度上是 harness 工程质量的函数，而不是模型参数量的函数。

5. 本地部署与复现时最容易踩的坑

5.1 Ollama加载2B模型的显存与速度权衡

用 Ollama 本地跑 2B 模型，显存占用和推理速度是两个要平衡的点。2B 模型量化到 4bit 大概占 1.5G 到 2G 显存，看起来很小，但 agent 任务的特点是"调用次数多"，每一步都要推理一次，一条任务链可能推理十几次。这时候速度就成了瓶颈。

我的经验是：如果显存够，尽量把模型全部放进显存，不要用 CPU 卸载。CPU 卸载会让单次推理从几百毫秒涨到几秒，一条任务链下来就是几十秒的差距。另外，Ollama 的并发设置要注意，agent 任务通常是串行的，不需要开高并发，开高了反而抢显存。

提示：如果你的机器显存紧张，可以考虑把上下文长度调小。agent 任务每步的上下文其实不长，把 num_ctx 从默认的 2048 调到 1024 甚至 512，能省不少显存，对分数影响很小。

5.2 提示词里的隐藏陷阱：工具描述太长反而拖后腿

我踩过一个大坑：一开始我把每个工具的说明写得很详细，包括用途、参数、示例、注意事项，结果分数反而下降。排查后发现，2B 模型的上下文预算有限，工具描述太长会挤占任务本身的信息，而且模型容易被冗长的描述带偏。

后来我把工具描述压缩到"名称 + 一句话用途 + 参数列表"，分数回升。这说明对小模型来说，提示词不是越详细越好，而是要"刚好够用"。详细的说明适合大模型，小模型需要的是精简和聚焦。

5.3 评测脚本本身的坑：别把工具成功当任务成功

前面提过，我最初的评分脚本把"工具调用成功"当成"任务成功"，导致分数虚高。这个坑很隐蔽，因为工具调用成功率高的时候，你会以为 harness 做得很好，实际上任务根本没完成。

正确的评分应该是端到端的：检查任务的最终状态是否符合预期，比如文件是否真的被创建、内容是否正确。中间的工具调用成功只是必要条件，不是充分条件。建议评分脚本里加一层"最终状态校验"，别偷懒。

5.4 温度与采样：小模型更需要确定性

2B 模型在 agent 任务上，温度一定要调低。我实测温度 0.2 比 0.7 的分数高出一大截，因为 agent 任务需要的是稳定复现，不是创意发挥。温度高了，模型会在工具名、参数格式上随机抖动，解析失败率飙升。

top_p 也建议调低，0.9 左右比较稳。另外，如果你的后端支持，可以固定随机种子，这样同一批任务跑两次结果一致，方便排查问题。agent 调试最怕的就是"这次错下次对"，固定种子能省很多事。

6. 这套harness思路还能怎么扩展

6.1 从2B到更大模型的迁移注意事项

这套 harness 思路不是 2B 专属的。我拿同样的 harness 跑过更大的模型，分数同样有提升，只是提升幅度没那么夸张——因为大模型本身规划能力就强，harness 的边际收益递减。但错误回退和参数校验这两块，对大模型同样有价值，能减少偶发失败。

迁移时要注意的是：大模型对提示词的"容错"更强，你可以适当放宽约束，给它更多自由度。但对小模型，约束越紧越好。所以 harness 最好做成"约束强度可配置"，根据模型能力动态调整。

6.2 多工具场景下的协议设计

工具数量一多，协议设计就更关键。我的经验是：工具超过十个之后，不要让模型从全量列表里选，而是先做一层"工具分组"，让模型先选组、再选具体工具。这样每一步的决策空间都变小，2B 模型更容易选对。

另外，工具命名要有一致性。别一会儿read_file一会儿get_content，模型会混。统一用"动词_名词"的格式，模型学起来更快。

6.3 把harness做成可插拔的中间层

最后分享一个架构上的想法：把 harness 做成一个独立的中间层，模型和任务之间通过标准接口通信。这样你可以随时换模型、换工具、换任务集，而不用改 harness 核心逻辑。我现在的做法是 harness 只依赖"模型调用接口"和"工具注册接口"两个抽象，具体实现随便换。

这个设计的好处是，你可以快速做 A/B 测试：同一批任务，换不同模型跑，或者换不同 harness 配置跑，对比分数。agent 开发本质上是个实验驱动的活，架构上支持快速实验，比什么都重要。

我在实际使用中发现，很多人把精力花在"找更强的模型"上，却忽略了 harness 这层。但实测数据摆在这：同一颗 2B 模型，harness 做得好坏能带来近五十倍的分数差距。与其追更大的模型，不如先把手上这颗模型的 harness 打磨到位。这个投入产出比，高得离谱。