把大模型放到自己的机器上跑，数据不出本机，也不依赖网络和额度，这对处理内部资料、离线环境的场景很有吸引力。但真正做起来会发现：模型能跑起来只是第一步，让它稳定地把事情做对，才是大部分工作量。这篇文章整理我搭建本地 Agent 的思路，以及后续"调教"时最有效的几个手段。
本地 Agent 由哪几块组成
不管用哪个框架，本地 Agent 基本都是下面四块拼起来的：
- 模型运行时：负责把模型加载到内存或显存并提供接口，常见选择是 Ollama、llama.cpp 这类工具，它们都能通过本地 HTTP 接口调用。
- 工具层：Agent 能做什么，取决于你给它开放了哪些函数，比如查询数据库、读取文件、执行某个脚本。
- 知识层：把本地文档切片、向量化存起来，提问时先检索相关片段再交给模型，也就是常说的 RAG。
- 编排与记录：决定什么时候调用工具、如何把结果回填给模型，并把每一步都记下来方便复盘。
选模型：先看硬件，再看任务
模型不是越大越好。参数量决定了对内存和显存的需求，也直接影响响应速度。我的做法是先明确任务类型，再倒推需要的规模：
- 分类、抽取、改写这类边界清楚的任务，小模型加上清晰的提示词往往就够用。
- 多步推理、复杂工具调用才需要更大的模型，并且要实际测试它的工具调用是否稳定。
- 使用量化版本可以明显降低资源占用，代价是少量精度损失，建议在自己的任务上对比之后再决定。
调教的顺序：提示词、检索、再考虑微调
遇到"效果不好"时，很多人第一反应是微调模型，但成本最高、见效最慢。我按下面的顺序逐层尝试，前一层解决不了再进入下一层：
- 改系统提示词：明确角色、边界、输出格式，并给出两三个正反例。大部分格式和风格问题在这一步就能解决。
- 补充检索资料：模型缺的是知识而不是能力时，优化文档切片和检索，比训练更有效，也方便随时更新。
- 收紧工具设计：让每个工具职责单一、参数简单、返回结果精炼，模型调用出错的概率会明显下降。
- 最后才考虑微调：只有在固定的格式或领域表达上反复出错，并且已经攒下足够的高质量样本时，再考虑轻量微调。
一定要有自己的评测集
"感觉变好了"是最不可靠的判断。我会先攒二三十个真实问题，每个都写明期望的结果或判断标准，每次修改提示词、换模型或调整检索之后都完整跑一遍，对比通过率。哪怕只是一份表格，也能让调教从凭感觉变成看数据，还能及时发现某次改动让原来正常的问题变差了。
安全边界要先划好
- 默认只读：先只开放查询类工具，需要写入或执行的操作单独加确认环节。
- 限制范围：文件和数据库的访问限定在明确的目录和表里，不给整机权限。
- 全程留痕：记录每次提问、检索到的资料、调用的工具和结果，出问题时能还原当时发生了什么。
- 输出要可核对：回答尽量附上引用的资料出处，让人能快速验证，而不是直接相信。
小结
本地 Agent 的关键不在于跑起了多大的模型，而在于把任务边界、工具、资料和评测这几件事做扎实。先用最小的模型和最简单的工具做出能用的版本，配上评测集，再一层层优化，比一开始就追求大而全更容易做出真正好用的东西。