GLM-5.1 + Ollama 实现8小时无人值守AI Agent的实战指南

昨晚我把 GLM-5.1 在 Ollama 里跑了起来，同一台旧工作站上同时挂着三个无人值守任务，今早爬起来翻日志，其中一个数据处理任务跑了 7 小时 40 分钟，脚本异常重试了 19 次，最后居然分毫不差地把整批结果交付了。

这个标题放在半年前我是不信的。开源模型再猛，跑个几十分钟的 agent 任务也就到头了，真把它丢在那跑八小时，那基本上等于把压路机开进瓷器店，一个幻觉能毁掉一整轮任务。但这次 GLM-5.1 配合 Ollama 部署，确实把我的阈值拉高了一截。这篇文章我就基于这周的实操，把“一键部署”背后的真实工作量、8 小时自主工作模式的底层逻辑、以及一路踩出来的坑，全部摊开讲。

如果你是刚接触开源模型的小白，这篇可以当半个部署手册用；如果你已经在折腾 agent 和自动化流水线，后面几章的调参和排查经验应该能帮你省下几个通宵。

1. GLM-5.1 到底强在哪，以及“8 小时自主工作”怎么成立

先说结论：真正让我愿意把任务彻底丢给它过夜的三件事，是它的工具调用稳定性、长上下文表现和中文语义理解。模型本身的能力排行我可以不吹，但作为跑活儿的工具，这三个点决定了“自主工作”是营销话术还是真能落地。

1.1 模型定位与核心能力拆解

GLM-5.1 从发布说明来看，延续了开源大模型的通用路线，但它和同量级开源模型拉开距离的地方，主要是把“干活能力”往前顶了一大截。

• 长上下文能力更强：官方参数支持到夸张的长度，本地部署时受硬件限制会缩水，但即便如此，它也能稳定追溯到十几页文档之前的信息，这对多轮任务非常重要。
• 工具调用稳定性：我实测下来的感受是，它不像某些开源模型那样热衷于“自言自语”式地假装调用函数。该调工具的节点会明确输出结构化指令，调用失败后也能理解错误信息，调整参数重试。
• 中文能力和代码能力互补：中文指令理解很细腻，代码生成与修复也稳。我们处理的数据清洗任务里会夹杂大量中文注释和半结构化文本，GLM-5.1 对这类混合输入的解析速度明显快于我用过的同类开源模型。

当然，“国产最强”这个叫法本身见仁见智，每个人手上的基准集不一样，结论自然有偏差。我更愿意把它理解成一个信号：国内开源模型的可用性，已经从“能对话”进化到了“能接手完整任务”的阶段。

1.2 为什么它能“自主”跑 8 小时

所有号称“自主工作”的 AI 流程，拆开来看都是一个循环：任务分解 → 工具调用 → 观察结果 → 决策下一步 → 再执行。GLM-5.1 做得好的是把这个循环里的每一环都压得比较稳。

一个 agent 能连续跑 8 小时，核心不在模型一个点，而在于三个要素：

GLM-5.1 在第一个点上的表现尤其突出。我之前用另一个同级别开源模型跑过同样的自动化任务，前 30 轮对话正常，到了第 40 轮左右开始出现格式漂移，把 JSON 输出漏了一个花括号，我的解析器直接崩掉。GLM-5.1 跑了一整晚，我从日志里翻到的结构化输出基本没有断裂。

第二点同样重要。我不建议真的把十几万字一次性塞给本地模型，但 GLM-5.1 在几万 token 的长对话中保持早期指令的能力，让它能在无人工干预的情况下记住最初的规则、中间的状态和最终的目标。第三点是我这边的工作，文章后面会展开讲。

1.3 哪些场景真的适合“8 小时无人值守”

不是所有任务都适合丢给模型过夜。我根据自己的实践，把适合和不适合的场景都理了一份：

• 适合：

  • 批量数据处理：一堆 CSV、JSON、日志文件，模型逐个读取、清洗、汇总、生成报告。
  • 代码仓库维护：跑测试、看报错、修代码、再跑测试，这个循环非常适合挂机。
  • 定时内容生成：批量生成带固定格式的文档、文案，再自动做质量检查。
  • 竞品或资料调研：给它一组网址和检索工具，让它自动抓取、归纳、对比。

• 不适合：

  • 涉及真实生产数据库的写操作，风险太高。
  • 需要和人实时协商才能推进的任务。
  • 一步错步步错、且没有自动校验手段的流程。
  • 模型能力边界之外的创意型任务，跑得越久越容易产生幻觉。

一句话总结：成功率依赖“可自动验证的中间态”。有了中间态，模型犯错了也能在下一步被扳回来。

2. Ollama 一键部署：在本地把 GLM-5.1 跑起来

标题说“一键部署”，实际上真正动起手来还是有几个前置条件要确认。Ollama 确实把模型下载、内存管理、API 暴露这些底层工作都封装掉了，但硬件能不能扛住，模型文件从哪来，这些还是得自己来。

2.1 环境准备与硬件需求

我这次用来跑 GLM-5.1 的机器是一台中等配置的工作站：32 GB 内存、一张 12 GB 显存的显卡、Linux 系统。部署过程很顺利，8 小时挂机也没有崩。如果你是 Apple Silicon 的 Mac，或者 16 GB 内存的轻薄本，适合跑小尺寸量化版本，效率也很高。

注意这里说的“尺寸”是指权重参数量级。同尺寸模型在不同精度下占用的资源完全不同，量化版本通常用 4-bit 或 8-bit 存储权重，效果损失可控，资源占用大幅下降。对于要跑十几个小时的任务，我更看重稳定性，所以选了量化适中的版本，而不是强行堆最大模型。

2.2 拉取模型并启动服务

Ollama 的安装很简单，命令行一条指令的事，服务起来之后通过 REST API 交互。GLM-5.1 拉取我用的是这样的命令：

bash复制ollama pull glm-5.1:14b-q4_K_M

模型标识符里那段后缀代表量化精度和版本。不同的硬件、不同的发布渠道，可用的 tag 会略有差别，我建议先执行 ollama list 和平台上的模型页面确认好 tag 再动手，省得拉错文件。

第一次运行时先试一下基础对话：

bash复制ollama run glm-5.1:14b-q4_K_M

如果命令行能正常回话，说明底层全部就绪。Ollama 会在首次加载时把权重读进内存，之后所有调用都走本地 HTTP API，不再需要命令行交互。

2.3 Modelfile 定制：长任务跑挂机前的关键调整

“一键部署”的另一半是体验优化。默认参数能跑，但跑长任务不能直接用默认参数，这句话希望你先记住。我用 Modelfile 把模型重新打包了一份自定义版本：

bash复制FROM glm-5.1:14b-q4_K_M
PARAMETER temperature 0.3
PARAMETER top_p 0.9
PARAMETER num_ctx 32768
PARAMETER keep_alive 30m

• temperature 设置为 0.3：自主任务里不需要创造性，参数越低，输出越稳定，幻觉越少。跑代码和数据清洗这类任务，我甚至会把温度压到 0.1。
• num_ctx 设为 32768：这是上下文长度。默认值往往很小，如果任务长，模型会“忘记”几轮之前的内容。
• keep_alive 设为 30m：让模型权重在内存里保持 30 分钟，避免频繁执行任务时反复加载，减少延迟。

构建并运行自定义版本：

bash复制ollama create glm5-1-longtask -f Modelfile
ollama run glm5-1-longtask

这一步付出的时间成本很低，但对长任务的稳定性影响极大。上下文长度不够导致的“失忆”，是很多网上所谓“跑到一半开始胡言乱语”案例的真相。

2.4 把 OLLAMA 变成后台服务

跑 8 小时任务，不适合开着终端窗口守着。Ollama 本身可以作为系统服务运行，这样就算关闭 SSH 会话，任务也能继续。

我用的是 Linux 下比较朴素的做法：编辑 service 文件，加入环境变量和启动参数：

ini复制[Service]
Environment="OLLAMA_HOST=0.0.0.0"
Environment="OLLAMA_KEEP_ALIVE=30m"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
ExecStart=/usr/local/bin/ollama serve
Restart=always

几个环境变量的作用：

• OLLAMA_HOST=0.0.0.0：允许局域网内其他机器访问模型服务，方便把不同任务的调用方指向同一个模型实例。
• OLLAMA_KEEP_ALIVE=30m：和前面 Modelfile 里的 keep_alive 对应，控制模型在空闲时驻留内存的时间。
• OLLAMA_MAX_LOADED_MODELS=1：只保留一个模型在内存里，避免多模型同时加载把内存挤爆。长任务期间不会频繁切换模型，这个参数能省出大量内存。

启用服务：

bash复制systemctl enable ollama
systemctl start ollama

到这里，本地推理服务就能稳定在后台跑了。“一键部署”其实是五六个步骤，但一次性配置好，后面每次跑任务都真的只需一条命令。

3. 跑一个真正的“8 小时自主 AI 工作”任务

服务部署好只算完成 20%，真正的重头戏是搭任务循环。模型再强，没有一套可靠的执行外壳，也没法做到八小时无人值守。我把自己常用的 agent 循环骨架，以及一整晚跑批任务的完整过程，原原本本写到下面的章节。

3.1 Agent 循环的最小骨架

我习惯把“自主工作”拆成一个带检查点的 while 循环。核心逻辑用伪代码描述是这个样子：

python复制task_queue = load_initial_tasks()
checkpoint = load_last_checkpoint()

while not task_queue.empty():
    current_task = task_queue.pop()
    result = execute_with_model(current_task)
    if validate(result):
        save_artifact(result)
        checkpoint.mark(current_task.id, status="done")
    else:
        error_info = parse_error(result)
        if current_task.retry_count < MAX_RETRY:
            task_queue.push(retry_with(error_info))
        else:
            checkpoint.mark(current_task.id, status="failed", note=error_info)
    checkpoint.save()

这看起来简单，但它其实就是长时间自主工作的秘密：每经过一个任务，系统的状态都被持久化到磁盘，模型宕机了、网络断了、显卡过热了，重启之后还能从断点继续跑。

实际代码里，我会用 SQLite 来存储任务队列和状态。这样不用引入重量级数据库，查状态、断点续跑都非常方便。任务执行时的模型调用，直接走 Ollama 的 HTTP API：

bash复制curl http://localhost:11434/api/chat -d '{
  "model": "glm5-1-longtask",
  "messages": [...],
  "stream": false
}'

注意把 stream 设为 false，这样等待响应时不会被流式输出卡住，重试时也更好控制超时。

3.2 给模型一套克制而够用的工具集

很多人的 agent 跑挂，不是因为模型烂，而是给了太多的工具和权限。工具越多，决策分支越复杂，越容易失控。我的原则是：第一步任务只需要三个工具，绝不多加。

• 读文件工具：接收文件路径，返回文本内容。
• 写文件工具：接收路径和内容，写入并返回结果。
• 执行命令行工具：接收命令字符串，捕获标准输出和退出码。

听起来很简陋，但恰恰是这套组合能覆盖大量真实场景。数据清洗、日志分析、代码修复，本质上都是“读入内容 → 思考 → 产出文件或命令”。多出来的数据库查询工具、网络请求工具，都应该在任务真正需要时才逐步加进去。

给模型的工具说明要写得直白。不要写“该工具用于高效地读取指定路径下的文件内容”，而是写“输入文件路径，返回文件完整文本，文件过大时只返回前 2000 字符”。模型是状态机和概率模型，它会严格按照描述去理解工具的边界，描述含糊，调用就含糊。

3.3 任务拆解、进度保存与断点续跑

我这一晚跑的任务，是让 agent 处理一个包含几百份历史业务报表的目录。报表格式混乱：有 CSV、PDF 转出的文本、还有带合并单元格的表格碎片。任务目标是把所有报表统一成同一种 JSON 结构，并生成汇总统计。

我把任务按“单位报表”拆成了几百个小任务，每个小任务都是“读一份文件 → 解析 → 输出 JSON → 自检”。这就是任务可以并行和续跑的基础。

每处理完一份文件，agent 会先把临时 JSON 写入输出目录，再更新 SQLite 里的任务状态。如果中途某个任务连续失败超过三次，会把对应文件路径记入失败清单，继续下一份，而不是把整夜时间耗在一只坏蛋上。

断点续跑的逻辑在下一批实验里最重要。第二天我重启了机器，重新拉起同一个脚本时，直接指定从上次的 checkpoint 继续扫描，SQLite 里标记为 done 的任务全部跳过，只处理未完成和失败的条目。整个系统像什么都没发生过一样继续跑。

3.4 全程实录：从傍晚挂机到次日清晨

我把整个流程按时间轴还原一下，方便你对照参考自己跑的时候哪个环节会出问题。

18:30，启动任务。我把模型加载，确认 glm5-1-longtask 驻留内存。然后启动 agent 主脚本，日志输出正常。每个任务的平均耗时预估在 30 秒到 3 分钟之间。

21:00 左右，我注意到任务处理速度下降。查了下日志，发现是某几份报表文件特别大，模型每次读取都要吃掉大量上下文 token，而且重复解析同一份文件的失败重试占了不少时间。我在工具里加了一个前置截断逻辑：超过一定长度的文件先切片再解析，速度立刻回到了正常水准。

23:40，日志里出现了一次奇怪的工具调用：模型试图用“写文件工具”去覆盖输入目录里的原文件。这个动作在验证层被拦截了，因为我在文件写入工具的描述和底层实现里做了双重限制，只允许写入输出目录。这是我强烈建议你抄作业的一点：输出路径白名单，一定在模型控制之外写死。

次日 06:30，任务队列清空。失败清单里有两个文件，分别是格式损坏的 PDF 和一份密码保护的表格。其余全部成功，汇总报告正常生成。整个任务跑了大约 11 小时，中间模型没有崩溃，没有出现大幅度发散，就一个 agent 稳定地熬了个通宵。

4. 会遇到的坑和排查思路

跑了三周 GLM-5.1 + Ollama，我把遇到最多的几类问题整理成了速查表。这些问题不全是模型的问题，很多是架构层面和资源层面的，但你迟早都会撞上。

4.1 内存和显存相关的坑

最典型的症状是：刚开始跑得好好的，几个小时后突然整机卡死，或者模型响应时间越来越长，最终某个任务一直超时。这通常是内存被慢慢吃光了。

我之前排查过一起这样的情况。原以为是模型漏内存，后来发现是 Ollama 默认 keep_alive 时间太长，而且我同时加载了两个模型，权重全部驻留在内存里。再加上 agent 脚本本身缓存了一堆历史消息，每轮对话都把全部历史发给模型，很快就把内存耗尽了。

解决方案很简单：按照前面 2.3 的做法，把 OLLAMA_MAX_LOADED_MODELS 设为 1，OLLAMA_KEEP_ALIVE 设成 30 分钟。脚本端只保留最近十轮核心上下文，更早的内容落盘存储，需要时再搬回来。

注意：显存溢出不像内存溢出那样有明显的系统级报错，往往是模型推理直接报错退出。如果某个超长任务反复在同一位置失败，优先考虑是不是上下文长度超出显存承载能力。可以把 num_ctx 降低一点，或者换更小的量化版本。

4.2 长上下文下的漂移与“失忆”

模型在长时间任务里会表现出两种让人抓狂的行为：

第一种是早期指令漂移。比如我在最前面要求“所有日期字段统一用 YYYY-MM-DD 格式”，两个小时后，某一步的输出里突然冒出“2024年03月01日”这种原始格式，而验证逻辑没逮住，就把脏数据写进了结果。

这是长上下文任务的通病。应对思路是在每个任务节点把关键规则重复注入一次，而不是只靠模型开头的那一段“系统提示词”。我后来把关键规则做成一个固定片段，在每轮调用的 messages 列表里重新放入，基本杜绝了这种漂移。

第二种是上下文截断。模型或者框架在上下文过长时自动丢掉早期内容，导致 agent 忘掉任务目标。排查方法比较粗暴：打开日志，检查每次请求的 messages 长度。如果发现有自动截断逻辑在工作，要么提升 num_ctx，要么主动压缩历史。

4.3 客户端请求超时与任务假死

Ollama 的 API 在处理长文本生成时，响应时间会明显拉长。如果 agent 脚本用默认的请求超时时间，很容易在任务还没跑完时就被判定为超时，从而触发错误的重试。而重试往往会把同一个请求再发一次，累积起来更慢。

我习惯把客户端的超时时间放到 10 分钟以上，并且在请求层做独立的超时监控。如果模型真的超过两分钟没有任何响应，那多半是系统层面的问题，可以检查磁盘是否被写满、显存是否被占满、Ollama 日志是否有崩溃记录。

4.4 模型输出格式不稳定的终极兜底

即便 GLM-5.1 的格式稳定性已经很优秀，我依然会做两个兜底动作：

• 每个 tool call 的响应都做 JSON Schema 校验，不合格就把错误信息回传给模型，让它重新生成。
• 最终写入磁盘之前，再让一个轻量级脚本做字段级校验，不依赖模型自我检查。

这两层兜底不复杂，但能把长时间任务的成功率从“还行”拉到“可以接受”。任何一个模型都不值得你无条件信任，但你给它搭好护栏，它能超额完成任务。

5. 我的实操心得与建议

先说我最直接的一个感受：跑完这次 8 小时任务，我最大的收获不是“模型能跑这么久”，而是“模型配合合理的架构，真的可以做到无人值守”。

有几个经验，写在最后，都是这周反复踩坑后沉淀下来的：

第一，别把模型的能力当上限，要把验证能力当上限。一个任务能跑多久、多复杂，取决于每个步骤有多容易被自动校验。写文件后检查文件大小、执行命令后检查退出码、解析结果后做 Schema 校验，这些都是让模型“敢跑”的基础。

第二，日志要极端详细。每个任务开始时间、结束时间、模型返回内容、工具调用参数、重试次数，全部记录。否则模型半夜跑崩了你都不知道崩在哪一步。我用的最简单方案是 JSON Lines 日志文件，一行一个事件，出错时按任务 ID 检索就行。

第三，Ollama 这个部署方式对中小团队和独立开发者是真的友好。不用维护一套复杂的推理服务，一条命令启动，API 和命令行两套交互方式都有，省出来的时间可以全部花在任务逻辑本身上。如果你手头只有一台普通笔记本，先从最小尺寸跑起来，不要被参数吓到。

接下来我打算做两件事：一是把 GLM-5.1 接到本地的 RAG 知识库上，让它在长任务中能随时检索专有文档；二是把任务失败重试的决策权也交给模型，让它自己判断该换路还是该止损。开源模型这个赛道的更新速度大家有目共睹，我写这篇文章的时候可能新的版本又放出来了，但部署方法和任务架构这套东西不会过时。你拿它套到任何一个新模型上，都能少走很多弯路。