Ollama 思考模型接入：分清推理输出、最终答案与隐藏显示

先定义应用真正需要的输出 本地聊天工具常把流式文本统一追加到回答区域，但思考模型可能先输出推理内容，再给出最终答案。对用户来说，这两部分承担不同作用；对程序来说，它们也不是同一个字段。接入前先决定最终回答、过程展示和调试记录各保存在哪里。 按接口字段区分内容 Ollama 官方文档说明，聊天接口通过 message.thinking 表示思考内容，通过 message.content 表示最终回答；生成接口则对应 thinking 与 response。若页面始终显示“等待回答”，先检查是否已经收到 thinking，只是还没有收到最终答案。若回答区混入了过程文本，检查两类字段是否被写进了同一个缓冲区。 流式展示需要考虑状态变化 可把界面分成等待、思考中、回答中和已结束几个状态。官方示例在收到第一个 thinking 内容块时开始展示思考部分，收到 content 后切换到回答。应用实现还应考虑用户中断、连接失败、字段为空以及最终答案为空的情况，不把连接结束直接等同于成功答复。 推荐保留两份独立的文本缓冲区，并以接口返回字段驱动界面，而不是通过识别自然语言中的“答案是”来切换状态。前者遵循接口结构，后者容易随着模型措辞变化而失效。 用模拟分块检查复制和保存 不必每次都等待真实模型生成长回答，展示层可以先接收一组自拟片段：第一块只有 message.thinking，第二块仍只有 thinking，第三块出现 message.content，最后一块表示结束。预期是过程区累计前两块，答案区从第三块开始；复制按钮只取答案区，历史记录保留各自字段。 再增加三种情况：直接收到 content 而没有 thinking，只有 thinking 就中断，以及两个字段同时非空。它们分别检查是否错误地要求“必须先思考”、是否把中断标成完整成功、是否因互斥分支漏掉一个字段。按字段分别追加内容，比假定每个数据块只包含一种内容更稳妥。 这些是前端与保存逻辑的测试输入，不代表每个模型一定以这种分块组合输出。接入真实模型后，再保存一条实际响应验证协议。若还允许工具调用，应将“等待工具”作为独立业务分支处理，不能把工具轮次没有最终文本一概归为生成失败。 思考开关不具有完全统一的语义 think 参数要与具体模型匹配。文档列出的 GPT-OSS 使用 low、medium、high 等级，传入 true 或 false 不会按普通布尔开关起作用。不要为所有模型套用同一组设置并宣称已经关闭思考；切换模型后，重新检查参数和返回字段。 隐藏显示与关闭能力要分别验收 命令行提供 --hidethinking，用来隐藏思考显示，同时仍然使用思考模型。是否让模型产生思考内容与是否把它展示出来，是两个层面的设置。若目标是简洁界面，可以隐藏过程；若目标是改变模型运行方式，则需要核对 think 参数及模型支持情况。 用小而明确的样例验证接入 建议先测试一个能够快速完成的问题，记录原始分块的字段类型和先后顺序，再测试主动中断以及最终回答较长的情况。验收重点是显示和保存是否一致：复制答案是否只包含最终内容，重开会话是否恢复正确部分，中断时是否清楚标出尚未完成。 思考内容较长不能证明答案正确。显示逻辑通过后，还应拿已知答案或可靠材料检验最终回答；调低思考等级与隐藏显示的效果也要分开记录，不能把界面少了一段文字当作计算量已经减少。

本篇涉及的工具1

Ollama

官方接口将思考输出与最终答案分开，适合据此实现清晰的流式状态。

适合场景

需要控制本地模型响应展示、复制和历史保存的应用。

需要留意

参数能力随模型不同；隐藏思考显示不代表模型停止思考，也不构成质量保证。

了解项目 访问官网