openclaw 接入 ollama

本地起好 ollama、模型也拉下来了，一接到 openclaw 跑 Agent 流程，常见卡点是工具调用不触发、多步任务中途断、响应慢到超时。这篇不讲协议也不讲客户端怎么填，只给工程落地顺序：先怎么确认通、再挑能干活的模型、接着把超时并发降级日志铺上，最后用几条固定用例验证不退化。

本地 ollama 起好了，模型也拉下来了，一接到 openclaw 跑 Agent，常见卡点是工具调用不触发、多步任务中途断、响应慢到超时。这篇不讲协议字段怎么填，只讲工程落地顺序：先确认通、再挑能干活的模型、接着把超时并发降级日志铺上，最后用几条固定用例验证不退化。

顺序别跳。绝大多数接入问题都不是「模型不行」，而是配置没通、能力没匹配、边界没设。按下面四节走一遍，能省掉大半来回试的时间。

第一步：先确认 openclaw 真能拿到 ollama 的响应

动手前先把变量拆开：ollama 服务端能不能回、openclaw 能不能发出去、中间有没有东西拦。两头一起改，出问题就不知道是谁的锅。建议先手动打一个最小请求，确认服务端活着，再去动 openclaw 的配置。

1. 确认服务在跑看 ollama 进程和日志有没有启动报错，端口是不是在监听，这一步不通后面全白搭。
2. 列模型对名字把 ollama 的模型列表拉出来，openclaw 里写的模型名必须逐字一致，多一个空格或大小写不同都会走空。
3. 发一条不带工具的提问用最简单的一句话问它，能正常回话再进工具环节；这样能把配置问题和模型能力问题分开。
4. 接不上就按顺序查服务在不在 → 端口通不通 → 模型存在不存在 → 请求被谁拦了。别跳步，跳步就是在猜。

选模型：不是所有本地模型都适合跑 Agent

Agent 流程吃的是按格式吐出工具调用参数的能力，聊天顺的模型未必能稳定输出结构化内容。判断方法很土但有效：给它一个两步任务，查一个值、再用这个值算一步，能自己走完基本可用，走不完换模型通常比调提示词快。

• 上下文长度决定能塞多少工具描述和中间结果，任务一长最先炸的是这里，别只看参数量。
• 工具调用格式稳定性比单轮回答质量重要，多步任务里一次格式崩了就断链。
• 响应速度影响超时预算，慢模型要配更大的超时余量，或者退到异步。
• 某个模型适不适合哪类任务，到 /models 和 /embeddings 按当时的清单核对，别照抄过期推荐。

什么情况下不必纠结模型选型：只做单轮问答、不派工具、不做多步编排的场景，本地小模型够用，硬上大模型只是浪费显存。反过来，只要流程里有「用上一步结果决定下一步」，就得按 Agent 的标准挑。

超时、并发与降级：Agent 跑飞前的三道闸

本地模型首字慢是常态，超时不能只设一个总数。建议连接、读取、整体分开设，整体超时要能给到覆盖最长一步的余量，否则长任务会在最后一步被砍掉。并发也别一上来拉满，显存和算力决定真实上限，先低并发跑通再往上加，观察有没有请求排队堆积。

重试到上限还是失败，就要有降级路径：换更小的模型重试一次、退化成单步问答、或者把中间结果直接交回人工。别让 Agent 在一个循环里反复调同一个工具。什么情况下不适用：任务本身允许长耗时、且每一步都幂等，可以把步数上限放宽，但重试上限仍要留着。

日志与最小评测：让「这次跑得对不对」可复盘

没有日志就没有复盘。每次运行至少记：用了哪个模型、花了多久、调了哪些工具、每步入参出参、最后停在哪一步。失败样本要能一键重放，本地环境下把输入原样存下来比事后猜有用得多。

• 固定一小批用例，改配置或换模型后重跑一遍，看通过率有没有掉。
• 日志里路径、凭据这类字段该脱敏就脱敏，本地跑也一样。
• 记录每步耗时，才能看出瓶颈是模型慢还是工具慢。
• 失败样本连同当时的配置一起存，否则重放结果对不上。

关于「通过率有没有掉」这种判断，别凭感觉说好像还行。具体到阈值怎么定、基准怎么跑，到 /tools/speed-test 按当时的说明核对，用统一口径比才靠谱。