基于ollama与openclaw的本地大模型自动化工作流SMVCE实践

最近有个很深的感触：本地大模型跑起来真的不难，难的是让它真正“干活”。很多人装完ollama，拉一个模型下来，聊了两句话就放着吃灰了。原因很简单——模型只是工具，而我们要的不是一个聊天窗口，是一条能自动处理事务的流程。

我前阵子把自己的本地AI事务工作流重新整理了一遍，给它起名叫SMVCE。整套流程用ollama做模型底座，用openclaw做流程编排，核心结构是五个环节：State（状态感知）、Model（模型推理）、Verify（结果验证）、Control（决策控制）、Execute（动作执行）。跑通之后，像文本分类、格式清洗、日程整理、巡检报告摘要这类重复事务，我基本都交给它自动完成。

这篇文章把完整流程摊开讲：环境准备、模型对接、五环节落地，以及实测中踩过的坑。无论你是刚接触本地模型，还是已经在用ollama但还没建立起自己的自动化流程，都能找到可以直接抄作业的地方。

1. SMVCE五环节框架拆解：先想清楚模型装完到底干什么

1.1 为什么不是直接装个ollama就完事

先明确一个点：ollama解决的是“模型在哪里跑”的问题。它把下载、运行、暴露API这些事做得非常顺，一条命令就能让本地跑起来一个对话模型。但它的边界也很明显——它只管“生成”，不管“流程”。

什么叫流程？举个例子：我每天会收到若干篇文档，需要先看标题判断归属类别，再提取关键字段，再写入对应的记录文件，最后生成一份日报。这个事务里，真正用到模型的只有“判断类别”和“提取字段”这两步。其余环节——读文件、判断条件、写文件、生成日报——都需要有一套流程引擎来编排。

如果只用ollama，也不是不能写，只是每次都要自己拿Python拼：一个文件读进来、请求一次模型、解析返回、再做业务逻辑。这种胶水代码写一次两次还行，一旦流程多了，维护成本直线上升。而且很少有人意识到：模型输出是不可靠的，必须有一个环节专门“验证并修正”模型的输出，不然整个自动化流程会在某些边缘场景下悄悄出错。

1.2 SMVCE的五个环节分别解决什么问题

SMVCE这个名字来自五个环节的首字母。它在我这里既是框架代号，也是流程设计时的一个检查清单。任何一个自动化需求拿过来，我都会先在纸上把这五列填一遍，再决定用什么样的工具去实现。

这五个环节其实不是什么新概念，它就是把人的日常工作方式搬到了自动化系统里：先看情况，再动脑，检查一遍，拍板，然后执行。很多自动化流程跑不稳，不是模型不够好，而是少了Verify和Control这两个环节。模型偶尔会给出格式不对、内容不合理的结果，如果你跳过校验直接执行，出了问题排查起来非常费劲。

2. 基础设施准备：ollama服务与openclaw编排器的安装

2.1 ollama环境准备与模型选型的务实建议

安装ollama本身没什么可说的，官方脚本装完就能用。重点说模型选型。SMVCE流程里模型承担的是M环节的推理任务，不同任务对模型的要求差别很大。

我实测下来的经验是：纯文本分类、意图判断、字段提取这类任务，7B到8B级别的中文优化模型就够用。这类模型推理速度快，占用显存大概6GB到8GB，普通家用显卡也能跑。需要较长上下文、需要处理中文文档摘要时，建议上14B级别，配合4位量化使用，速度和效果能取一个平衡。如果要做复杂的规划、多步推理，那至少要32B级别，但硬件门槛会高很多，一般就不建议放在SMVCE的常驻流程里。

下载模型时用一个命令就能完成，比如拉取一个8B级别模型：

ollama pull qwen2.5:7b

拉完后先手动跑一次对话，确认模型能正常响应，再进入下一步。这一步别跳，因为后面openclaw对接时会把很多问题归结到模型层，先确认模型本身正常，排查范围会小很多。

另外建议让模型服务常驻运行。ollama默认就是本地服务方式，监听本机端口。如果openclaw也装在同一台机器上，直接使用默认端口就行，不需要额外暴露到局域网。如果你打算让多台机器共用这个模型服务，再考虑修改监听地址，同时一定要加访问控制，否则局域网里任何设备都能直接调用，存在安全风险。

2.2 openclaw的角色与环境准备

openclaw在SMVCE里承担的是“编排器”的角色。简单说，它负责把State、Verify、Control、Execute这四个环节落地成可配置的流程，然后把M环节交给ollama的模型来做。

安装openclaw之前先确认几件事：机器上要有支持的运行时环境，配置文件在安装目录下，第一次启动会自动生成默认配置。安装完成后，先跑一遍自带的功能演示，确认编排器能正常工作，再开始对接模型。

如果你对这种编排器不熟，可以把它理解成一个“带规则引擎的任务分发器”：你定义了一些步骤，每个步骤可以调用模型、可以读写文件、可以执行指令，步骤之间通过条件跳转连接。openclaw负责把这些步骤按顺序跑起来，同时处理重试、超时、日志这些杂事。这样业务代码只需要专注在具体动作上，不需要重复实现一套流程框架。

3. openclaw与ollama的对接配置：把本地模型变成编排器的“大脑”

3.1 定义模型提供方

openclaw对接ollama的方式很直接——它支持把模型提供方配置成一个自建的服务端点。ollama本身暴露了兼容格式的API，因此在openclaw的配置里，只需要把服务地址指向本地ollama的地址，并填上你要用的模型名称。

配置示例：

model_provider: type: ollama base_url: http://127.0.0.1:11434 model: qwen2.5:7b temperature: 0.2 max_tokens: 4096

几个参数说明一下：base_url指向ollama监听地址，默认就是11434；model必须和你在ollama里拉取的模型名称完全一致，这个名字写错了，对接时最常见的现象就是报“模型不存在”；temperature在自动化流程里建议调低，我用0.1到0.3之间，因为流程任务要的是稳定输出，不需要创造性，调低了生成结果更可复现。max_tokens按任务内容长度调整，纯分类任务给1024足够，长文本摘要任务给到4096起步。

3.2 连通性验证

配置改完后，不要急着搭完整流程，先做一次最小化验证：让openclaw跑一个最简单的模型调用步骤，输入一句固定文本，看返回是否正常。

我习惯用这样的测试方式：构造一个步骤，输入“用一句话说明SMVCE中的Model环节起什么作用”，然后看编排器日志里模型返回的内容。这一步能同时验证三件事：网络通不通、模型名对不对、提示词能不能被正确送到模型。

如果返回超时，先去确认ollama那一侧的日志，看请求到底有没有进来；如果返回了空内容，大概率是模型名称不匹配；如果返回了内容但夹杂着很多额外信息，可能是提示词模板里带了不该有的系统字段，需要精简。

3.3 容易忽略的配置细节

对接过程中有两个容易忽略的细节，单独拿出来说。

第一个是上下文长度的设置。ollama默认的上下文长度可能不足以支撑长文档处理。如果你的流程里要喂给模型一大段文本，建议在模型配置里显式指定上下文窗口大小，同时注意显存占用会随上下文变长而明显增加。我实测同一张显卡上，上下文从4K提到8K，推理速度会有显著下降。

第二个是超时设置。模型调用不是瞬时完成的，尤其是长上下文或者生成内容较长时，一个请求跑几十秒很正常。而编排器默认的超时时间往往很短，这会导致“模型明明在算，却被判成超时失败”。我把这类超时统一调到120秒以上。

4. SMVCE核心流程落地：从状态采集到动作执行

这一章把五个环节分别讲透，并给一个完整示例：自动处理一条文本记录，判断类别、提取字段，然后归档。整个流程跑一遍，你就能理解SMVCE每一步的实际作用。

4.1 S环节：状态采集，先搞清楚当前发生了什么

State环节的目标是拿到“输入的事实”。以文本自动处理为例，状态采集就是读取待处理文件，提取基础元信息（文件名、大小、修改时间），把正文完整读出来。

这里有一个实操提醒：状态采集阶段不要夹带任何“判断逻辑”。你只需要把事实原样记录下来，至于这段文本属于哪个类别、内容是不是合规，那是后面Model和Verify环节的事。把阶段职责分清楚，流程出问题时定位会非常快。

采集到的状态可以组织成结构化数据，传给下一步：

file_name: incoming/test_report_0421.txt file_size: 15432 content: "...正文内容..."

这些原始字段到Model环节会发挥作用。我见过有人在这个阶段就把标题截断、正文做了去重清洗，结果给模型的信息不完整，导致分类和提取的准确性肉眼可见地下降。S环节要克制，只做采集，不做加工。

4.2 M环节：模型推理，把状态变成可用的决策依据

Model环节是整套流程里唯一调用大模型的部分。核心工作是把State环节拿到的状态改写成一段结构清晰的提示词，让模型输出你想要的判断结果。

提示词的设计有几个要点。第一，要让模型明确自己的任务边界，不要给它发散空间，我会明确写出“你是一个文档分类器，只输出指定格式的内容”。第二，给出输入材料。第三，明确输出格式要求，最好直接规定成JSON结构。

示例提示词：

你是一个文档分类器。根据输入内容判断文档类别，只从[会议记录, 日报, 巡检报告, 其他]中选择一个，并提取正文中出现的关键项目名与日期。输出JSON格式： {"category": "...", "project": "...", "date": "..."} 输入内容： {state.content}

注意M环节的输出先不要直接拿来用。模型可能会给出字段缺失、类别不在选项里、甚至是JSON包裹在额外文字里的结果，这些是正常的，交给下一环节处理。

4.3 V环节：结果验证，自动化流程的“守门员”

Verify环节是把模型输出做一次程序化校验。这一步是SMVCE里最容易被省略、但恰恰最关键的环节。

具体校验内容因任务而异，常见三类：格式校验，看输出能否被正确解析，字段是否齐全，类型是否符合预期；枚举校验，看类别字段是否落在预设的候选集合内；逻辑校验，看字段之间是否自洽，比如日期字段是否合法，项目名是否为空。

下面是格式校验逻辑的示意代码：

def verify(result): if result["category"] not in ["会议记录", "日报", "巡检报告", "其他"]: return fail(reason="category字段超出预设范围") if not result.get("project"): return fail(reason="project字段缺失") if not is_valid_date(result.get("date")): return fail(reason="date字段格式错误") return pass()

在写流程的时候，我习惯让Verify返回的不只是一个“通过/不通过”，而是一个结构化结果，包括校验项列表、失败原因、以及建议分支。这样后续Control环节可以针对不同失败原因做不同处理，而不是一刀切地失败。

实测中，模型输出的JSON偶尔会有多余文字包裹，比如在外面带了代码块标记。我处理的办法是在Verify环节先做一次“提取有效JSON”的清洗，再进入正式校验。这个细节很不起眼，但能省掉大量人工介入。

4.4 C环节：控制策略，决定下一步走哪条路

Control环节根据Verify的结果决定流程走向。

最朴素的策略是“全部通过则执行，否则人工介入”。但实际跑下来你会发现，失败类型不同，处理方式也应该不同。我常用的是分级策略：

• 格式校验失败：尝试让模型重新生成一次，给一个“上次输出不符合要求”的提示，通常第二次都能返回规范结果。重试两次仍失败，再转人工。
• 枚举校验失败：说明模型选出的类别根本不在预设集合里，这种情况下重试意义不大，直接标记为异常，把上下文转给人工。
• 逻辑校验失败：如果只是日期字段格式问题，可以考虑走一次修正逻辑，而不是整体重跑。

Control环节本质上是把“遇到什么情况怎么办”的决策规则写清楚。用代码表示就是分支判断，但更重要的是把每种失败情况都想在前头。设计完整的控制策略，是流程稳定性的关键。

4.5 E环节：动作执行，把决定变成实际结果

Execute环节负责把决策落地。一个流程的最后一步往往比较简单，可能是写文件、发通知、调用某个外部命令。

以文档自动处理为例：如果分类是“日报”，就把处理后的数据和原文一起归档到对应目录，并追加一条记录；如果分类是“巡检报告”，则额外执行一次报告摘要生成；如果转人工，则把原始内容和失败原因写入待处理列表，并发送通知。

动作执行有几个注意点。第一，执行动作要可重入，也就是说同一个文件被处理两遍，不应该产生重复的副作用。实现上最简单的方式是处理前先记录一个“已处理清单”，执行完把文件标识写入清单，下次扫描时先查清单、跳过已处理的。第二，执行结果要留痕，每一步执行成功或失败都应有日志记录，整个流程才有可追溯性。第三，所有外部动作都建议加上超时保护，避免某个执行动作卡住整个流程。

到这里，SMVCE五环节已经走完。看起来简单，但每环节之间传递的是结构化数据，不是随意拼接的字符串，整条流程才具备复用和扩展的基础。

5. 实测记录与踩坑复盘：跑通SMVCE后，这些细节让我改了三版配置

5.1 模型输出的“格式漂移”问题

跑了一段时间后，我发现同一个提示词在不同批次调用里，输出格式会有细微差异。比如第一次返回的JSON字段顺序和第二次完全不同，有时还喜欢在JSON外面包一个代码块。这类问题靠改提示词往往解决不彻底，最稳妥的是在Verify环节做“宽容解析”，加一层JSON提取逻辑，无论模型输出外面包了什么，都能把核心JSON抽出来。

另一个值得注意的点是，模型在temperature调高时，格式漂移会更明显。我把所有流程任务的temperature都固定到0.2以内，格式稳定性提升非常明显。如果你在跑真实业务，保持低temperature是保证可复现性的基础。

5.2 上下文长度对推理速度和结果的交互影响

我的一个流程需要把一份较长的文档整体喂给模型做摘要，一开始上下文窗口开得比较小，模型经常截断重要信息。调大上下文后，显存占用上去了，推理时间明显变长，一度影响整条流程的节奏。

后来我做了两个调整：一是把长文档先做分段预处理，按段落切分后只把关键段落送入模型；二是针对不同任务配置不同的上下文长度，不是所有步骤都开大窗口。这个优化让整个流程的耗时下降了接近一半。

我的做法是：先按标题和小标题切段，每段单独过一遍模型，提炼出要点，再把这些要点重新拼成一份缩略版文档，最后送给模型做整体摘要。这样既保留了关键信息，又避免了一次性塞入超长文本带来的速度和显存压力。

5.3 编排器的超时与重试逻辑

前面提到把模型调用的超时调到120秒，但光调超时还不够。如果模型服务真的卡住了，超时之后流程会反复重试，反而把资源占满。

我改成了这样的策略：第一次超时后，等待几秒重试一次；如果再次超时，把当前任务标记为“待人工处理”，不再自动重试。同时给模型服务加了一个简单的健康检查，在每次启动流程前先确认服务在线。这些策略看起来都是小事，但稳定性的提升就来自这些细节。

重试策略在写成配置时也要注意：重试次数不要给太多，我一般给两次，超过就直接转人工。有些任务重试一次就能恢复正常，有些任务重试再多次也没用，反而会反复消耗算力。

5.4 提示词模板的版本化管理

随着流程变多，提示词也开始膨胀。我最初把提示词直接写在配置里，后来发现改起来很痛苦，每次微调都不知道会影响哪些流程。

做法是把所有提示词模板以独立文件管理，并加上版本号。每次调整模板时，同时记录一次测试用例的输出变化，看看新的模板是否引入问题。这样积累下来，整个提示词集合变成了一个可维护的资产，而不是一团需要翻配置的混乱内容。

我现在的模板目录结构大概是这样的：

prompts/ ├── classify_doc_v3.txt ├── extract_entity_v2.txt └── summary_v5.txt

每次改动后，我会把旧版本和新版本在同样的输入上各跑一次，对比输出差异。这个习惯让我之前好几次“微调”引发的回归问题，在发出去之前就拦下了。

最后说几点个人体会。SMVCE这套流程从我第一次搭到现在的稳定版本，中间改了三轮配置，最大的收获不是工具用得多熟，而是把“模型输出不可靠”这个前提真正落实到了流程设计里。很多人搭本地AI流程失败，不是因为模型不行，而是把模型输出当成了可信任的结果，跳过了验证与控制，导致流程跑几天就开始出错。

如果你也想搭一套类似的流程，我的建议是从最小的场景开始，选一个重复频率高、判断规则清晰的事务，比如“自动归档文档”或者“自动生成周报”，先把五环节走通，再去扩展更复杂的任务。工具本身都不复杂，真正需要花心思的是每个环节的边界和责任划分。把这五步想清楚了，后面的路就会顺很多。