在小参数本地模型上构建 Agent 系统

约束先行

先看数据在哪里。在企业内网中——设备配置、拓扑、路由状态、审计日志、客户环境——最有价值的数据往往也最敏感。在很多这样的环境里，你根本不能把这些数据送到托管模型。原因不是成本，而是安全与合规：数据不允许离开这栋楼。

所以模型必须跑在本地。而第二个约束随之而来。

在本地跑一个前沿级大模型很贵——不是贵在每 token，而是贵在硬件。以可用延迟运行一个 100B+ 的模型，需要相当规模的 GPU 投入，多数团队没法为每台工作站、每个站点都这样配置。从这里往下走，实际落点就是 ~30B 量级的模型。这是当前本地部署的最佳折中点：它能塞进人们真正拥有的硬件，且延迟足以支撑一个交互式 Agent。

问题在于，30B 模型不是前沿模型，而且它会不停地提醒你这一点。

30B 模型会错在哪

当你真的想在它上面构建 Agent 时，三个短板会立刻显现：

幻觉。 让它做多步骤的活儿，它会很乐意编出一个看起来合理的答案，而不是真去做——捏造一段总结、猜一个值、反复念叨”我这就去做 X”却从不真正做 X。
知识稀薄且陈旧。 它不了解你的环境、你的规范、任务领域的具体细节；它的通用知识既比前沿模型少，也比它旧。
可用上下文很短。 标称的上下文窗口不是可用的那个。实际中你面对的更接近小端 8K token、中端 32K。一旦用工具 schema 和原始数据把它填满，模型就不再推理了。

这些都不是靠换模型能解决的——那扇门已经关上了。你要在它周围的 harness 里解决。下面把每个短板对应到具体手段。

治幻觉：少给绳子，少给可编造的空间

小模型最容易幻觉的时刻，是被要求去生产本该由它计算的东西，或被要求去规划本该由它遵循的东西。

把活儿推进代码，而不是模型里。 当任务跨 N 个条目时，别让模型去编排 N 次工具调用——写一个在 Python 里迭代的工具，只调用一次。一个确定性计算的变更计划生成器可以做到 0 次数据库调用，而朴素的 Agent 循环要做 60–80 次。从不需要持有 80 个中间结果的模型，也就没机会去编造它们。
告诉它做什么（WHAT），而不是怎么做（HOW）。 给小模型一份逐步清单，它会机械执行、陷入循环，最后幻觉出一个”完成”。给它一个目标加约束，它会推理。在一次五轮实验里，每一版”先做第 1 步，再做第 2 步……”的 prompt 都失败了；“这是目标和约束”的那版成功了。
用确定性方式给输出打分。 一个便宜的 Python 判定——“Agent 到底产出了成果物，还是只是嘴上说说？“——能在结果到达用户之前就抓住”捏造总结”这类失败，且几乎零成本，而不是让一个 LLM 去给另一个 LLM 打分。

补知识：去检索它，而不是指望它

模型不了解你的世界，那就在调用时把相关的那一片喂给它。

让每个答案都落在真实数据上。 Agent 从真正的事实来源读取——数据库、在线设备——而不是从模型”记得”的东西读取。它的职责是对检索到的事实做推理，而不是去回忆它们。
把知识作为 memory 注入，而不是改 prompt。 把领域知识和来之不易的约束沉淀成小而可检索的指南（guide），并把相关的那些注入到每一次模型调用中（按作用域过滤、按配额封顶）。这也是系统自我改进的方式：一次学到的教训变成一条指南，从此引导每一次后续运行——远比改 prompt 更持久。

省上下文：把预算花在刀刃上

把上下文当作硬预算，为每个 token 记账。

一切按 tier 定尺寸。 假设可用上下文为 ~8K / 32K / ≥200K，据此缩放——召回多少条 memory、附带多少行数据。小模型永远不会被塞一堵它无法推理的墙。
让编排器只做瘦路由。 顶层 Agent 把意图路由给某一个专家子代理，并原样返回该子代理的输出——不做二次综合。能力都在专家子代理里，路由器的上下文因此保持极小。
对工具狠下节制。 每个工具定义在每次调用时都要花 ~150–300 token——16 个工具就是约 3,200 token 的永久开销，而且长工具列表还会抬高工具选择的出错率。把工具数量硬性封顶（每个 Agent 只留几个），保持工具 docstring 简短，并优先用普通脚本而非重量级工具定义。

归纳成一个模式

以上没有一条是”模型技巧”。它们都是 harness 工程：把活儿推进确定性代码、让答案落在检索到的数据上、通过注入的 memory 来引导行为、把紧张的上下文预算刻意花在刀刃上。做到这些，一个你能在自有硬件上运行的模型——就在你自己的网络里、什么都不出这栋楼——就能干出那些”显然需要前沿模型”的活儿。

我们把它落地在哪

以上正是 OLAV 背后的设计哲学——一个面向网络运维的开源 Agent 平台，从头就是为在本地小模型上运行而构建的。上面每一条原则都是它里面的承重规则：按 tier 的上下文预算、瘦路由编排器、工具数量封顶、WHAT-not-HOW 提示、fat tool、以及基于 memory 的行为引导，全部由架构强制约束，而不是靠”自觉”。

如果你正想在自己掌控的硬件上构建一个真正能用的 Agent，OLAV 是一份”各部件如何拼装”的可运行参考。它基于 BSL-1.1 开源——欢迎访问 github.com/james-olavai/olav。