做开发这几年，我用 AI 干过最多的一件事不是写代码，而是做选择。技术选型、框架取舍、排期优先级、开源方案对比…… 每次让大模型帮我拿主意，它都先给我写上一大段——开头铺垫、中间论证、结尾总结，看着很专业，但真正有用的就最后那两行。后来我把 Ollama 本地部署好，试着把决策模型接进来，让 AI 直接输出结论，效果完全是两个量级。这篇文章就聊聊我为什么说“AI 做选择，不必先写一段话”，把从环境搭建到接口封装的完整链路都摊开来，给你一套能直接抄作业的方案。

如果你也在折腾 Ollama 本地部署、想让 AI Agent 具备“快速拍板”的能力，或者只是受够了每次问 AI 都收到长篇大论，那这篇文章应该能帮你省下不少时间。我会从决策模型的输入输出设计讲起，再落到具体的部署、接口实现和常见坑，最后用几个真实场景跑给你看。

1. 决策模型接入前的顶层设计：先想清楚“AI 帮谁做决定”

1.1 为什么“做选择”和“写文案”是两码事

很多人第一次用大模型做决策，都会掉进同一个误区：把“让 AI 做选择”等同于“让 AI 写一篇分析报告”。这俩底层逻辑完全不一样。

写文案的任务，诉求是信息密度高、逻辑完整、表达流畅。大模型天生擅长这个，因为它的训练目标就是预测下一个 token，而“像人一样写文章”就是它的看家本领。但做决策不一样，决策的本质是“从一个离散的备选集合里挑出一个最优项”，它更像查表、打分、排序，而不是生成一段长文本。

我举个例子你就明白了。假设你是个项目经理，问同事“服务器选 A 厂商还是 B 厂商”，他给你写了 3000 字对比报告，从品牌历史讲到售后条款，最后才在末尾提了一句“选 A”。你会觉得他敬业吗？大概率只会觉得他浪费时间。你真正需要的是一句话：“选 A，因为供货周期短 20%，价格还低 5%。”

AI 也是这样。你让大模型“先写一段话再给结论”，它会把大量 token 消耗在铺垫、过渡和复述上。对于单次问答这可能无所谓，但如果你的决策模型要被 AI Agent 高频调用、要嵌入自动化流程，每多一段废话，都是在烧 token、耗时间、增加解析难度。更有甚者，模型写着写着还可能“忘”了你最初问什么，结论和前面的分析自相矛盾。

所以我在设计决策模型时，第一原则就是：把输出空间压缩到最小。只允许它输出结论、置信度和极简短的理由，不允许它自由发挥。后面你会看到，这套思路配合 Ollama 的结构化输出，能把一次决策的响应时间压到 1 秒上下，token 消耗也小得惊人。

1.2 决策输入的最小闭环：格式合规比内容流畅更重要

既然要做决策模型，第一步不是写代码，而是设计输入输出。我的做法参考了经典的“加权评分决策法”，把它简化成一个机器友好的 JSON 结构。

输入侧，我固定三个字段：

• options：备选方案列表，比如 ["Ollama", "LM Studio", "vLLM"]
• dimensions：评分维度，比如性能、生态、部署难度、资源占用
• weights：每个维度的权重，比如性能 0.3、生态 0.3、部署难度 0.2、资源占用 0.2

输出侧，我只接受一个严格的结构：

{
  "selected": "Ollama",
  "confidence": 0.85,
  "reasons": [
    "部署最简单",
    "社区生态最活跃"
  ]
}

selected 是最终拍板的结果，confidence 是模型的置信度，reasons 是最多给三条理由，每条不超过 10 个字。

你可能觉得这个设计太“死板”了，AI 不是应该很灵活吗？但恰恰相反，决策场景最怕的就是“灵活”。你不约束格式，模型就可能给你返回“综合考虑各种因素，我认为 A 和 B 各有优劣，但我个人倾向于……”这种没法被程序直接消费的答案。你让 Agent 去解析这段话，轻则写一堆正则，重则直接解析失败。

格式合规比内容流畅重要得多，这一点我在踩过几次坑之后深有体会。最开始我图省事，直接让模型“用一句话回答”，结果 10 次里有 3 次它会在答案后面附加解释，还有 1 次给出两个选项。自从把输出约束成 JSON Schema，并规定 selected 必须严格等于某个备选项的原文，准确率就稳定多了。

2. 环境底座：Ollama 本地部署的几个容易翻车的细节

2.1 离线安装与国内镜像源：下载慢的终极解法

Ollama 本身安装包不大，真正的痛点在于拉模型。默认从官方源下载模型，速度确实让人抓狂，尤其是几个 G 的大模型，进度条半天不动。我刚开始折腾的时候，恨不得把路由器重启三遍。

试下来最稳的方案有两种，你根据情况选。

第一种：直接用国内镜像站下载模型文件，再手动导入 Ollama。思路是访问镜像站找到对应模型的 GGUF 格式文件，下载到本地后用 Modelfile 注册。命令很简单：

# 先用文本编辑器写一个 Modelfile，内容大概长这样
FROM /data/models/qwen2.5-14b-instruct-q4_k_m.gguf

# 然后执行导入
ollama create qwen2.5-14b -f Modelfile

注意 FROM 后面的路径要写成本地磁盘的真实路径，不能是网络地址。这个方案的好处是：下载工具可以随意选择——迅雷、IDM、命令行 wget 都行，只要能下完就行。我实测下来，同样的模型文件走镜像站下载，速度能比官方源快好几倍，而且断点续传的体验也好很多。

第二种：如果只是偶尔拉一两个中小模型，可以用环境变量指定模型下载源，让 Ollama 去镜像站拉取。这种方式更省事，但需要镜像站支持 OCI 协议的 API 转发。我不展开具体地址了，你自己搜一下“Ollama 国内镜像”就能找到不少备选，选那种历史悠久、文档全的即可。

这里有一个已经踩过的坑：不管你用哪种方式，下载完成后千万别忘了检查模型文件的完整性。我遇到过两次模型跑起来疯狂报错，最后发现是文件下载到一半损坏了。用官方 sha256 校验一下最稳妥，镜像站一般会在页面底部贴出哈希值。

2.2 模型存储路径：安装到其他盘的正确姿势

Ollama 默认把模型存在 C 盘，这对 Windows 用户来说就是灾难。我机器上的模型加起来快 60 G，要是全堆在系统盘，C 盘早就红灯了。所以第一件事就是改存储路径。

Windows 上的操作很简单：新建一个环境变量 OLLAMA_MODELS ，值设置成你想存放的目录，比如 D:\ollama\models ，然后重启 Ollama 服务。注意不是重启应用，而是去任务管理器把 Ollama 的后台进程全部结束，再重新启动，否则环境变量不生效。

Linux 上稍微复杂一点。如果你是用 systemd 管理 Ollama 服务的，直接改 service 文件：

sudo systemctl edit ollama.service

写入：

[Service]
Environment="OLLAMA_MODELS=/data/ollama/models"

然后重启服务：

sudo systemctl daemon-reload
sudo systemctl restart ollama

这里有个细节：如果你已经下载过模型，光改环境变量是不够的，必须把旧的 models 目录整体搬到新位置。直接剪切复制就行，搬完再重启服务。至于为什么需要这么做，因为 Ollama 是依靠 OLLAMA_MODELS 这个路径去找模型的，路径变了但文件没搬过去，就会出现 model not found 的报错。我先改了路径忘了搬文件，白排查了半天才发现问题，这个低级错误希望你别再犯。

2.3 Linux 下载模型过程中的段错误排查

ollama serve 崩溃、直接给你来一个 Segmentation fault ，这个问题在 Linux 上不算罕见。我遇到过几次，把排查思路整理一下，省得你对着黑窗口发呆。

常见原因有三个：第一，模型文件损坏或下载不完整；第二，磁盘空间不足，解码到一半写不了临时文件；第三，系统 glibc 版本过低。我分别在两台老服务器上遇到过前两种情况。

排查顺序建议这样走：

先看日志。用 journalctl -u ollama -n 100 查看服务日志，如果看到明确的内存地址错误，基本可以判断是运行时崩溃，优先怀疑模型文件。这时重新拉取镜像，或者用 sha256 校验本地文件。

再看磁盘。用 df -h 检查空间，Ollama 加载大模型时需要在临时目录做解包操作，空间不够直接段错误。需要注意的是，除了模型目录， /tmp 也可能会被用到，两个地方都要看。

最后看依赖。如果你的系统是 Ubuntu 20.04 以下，glibc 版本大概率不满足新版本 Ollama 的要求。这种属于环境问题，要么升级系统，要么下载旧版本的 Ollama 安装包。

还有一个容易被忽略的点：ulimit 限制。如果进程能打开的文件数太少，模型加载时也会异常退出，把 ulimit 调大就行。命令是 ulimit -n 65535 。

3. 接入决策模型：从“先写一段话”到“直接出结论”

3.1 用结构化输出接住决策结果

Ollama 很好的一点是原生支持结构化输出，也就是让模型按你给定的 JSON Schema 返回结果。这一点对决策模型来说太关键了，相当于从根上杜绝了“自由发挥”的空间。

调用方式是在 /api/chat 接口的请求体里加一个 format 字段，传一个 JSON Schema 进去。我下面给的是一个可以直接改用的例子：

curl http://localhost:11434/api/chat -d '{
  "model": "qwen2.5:14b",
  "stream": false,
  "messages": [
    {
      "role": "system",
      "content": "你是一个决策助手。只做一件事：从给定选项中选出一个最合适的，并给出置信度和至多两条简短理由。禁止输出选项以外的内容。"
    },
    {
      "role": "user",
      "content": "备选方案：Ollama、LM Studio、vLLM。评估维度：性能0.3、生态0.3、部署难度0.2、资源占用0.2。请做出选择。"
    }
  ],
  "format": {
    "type": "object",
    "properties": {
      "selected": { "type": "string" },
      "confidence": { "type": "number" },
      "reasons": { "type": "array", "items": { "type": "string" } }
    },
    "required": ["selected", "confidence", "reasons"]
  }
}'

这么做的好处是，响应体直接就是合法 JSON，你用 json.loads() 就能解析，什么都不用额外处理。

但这里有个容易踩的坑： format 只保证输出是合法的 JSON，不保证 JSON 内容一定符合你的业务约束。比如模型可能返回一个不在备选列表里的值，或者 reasons 数组里写满了废话。所以提示词里一定要说清楚“selected 必须来自备选列表”，解析时还要再做一层校验。我自己写了个校验函数，发现 selected 不在列表里时，强制重试一次，准确率几乎到了 100%。

3.2 FastAPI 调用 Ollama 实现决策接口

单机用 curl 测试没问题，但想把它交给 Agent 或者前端用，就得封装一个正经的 API 服务。我用 FastAPI 写了一个很轻量的决策接口，核心代码就这么多：

import requests
from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI()

class DecisionRequest(BaseModel):
    options: list[str]
    dimensions: list[str]
    weights: dict[str, float]

class DecisionResponse(BaseModel):
    selected: str
    confidence: float
    reasons: list[str]

def call_ollama(prompt: str, schema: dict) -> dict:
    resp = requests.post(
        "http://localhost:11434/api/chat",
        json={
            "model": "qwen2.5:14b",
            "stream": False,
            "messages": [{"role": "system", "content": "你只负责决策，不解释，不铺垫。"},
                         {"role": "user", "content": prompt}],
            "format": schema,
            "options": {"temperature": 0}
        },
        timeout=60,
    )
    resp.raise_for_status()
    return resp.json()["message"]["content"]

@app.post("/decide", response_model=DecisionResponse)
def decide(req: DecisionRequest):
    schema = {
        "type": "object",
        "properties": {
            "selected": {"type": "string"},
            "confidence": {"type": "number"},
            "reasons": {"type": "array", "items": {"type": "string"}}
        },
        "required": ["selected", "confidence", "reasons"]
    }

    weight_lines = "、".join([f"{d}:{w}" for d, w in req.weights.items()])
    prompt = f"备选方案：{', '.join(req.options)}。评估维度：{weight_lines}。请做出选择。"
    content = call_ollama(prompt, schema)

    import json
    result = json.loads(content)

    if result["selected"] not in req.options:
        # 简单重试一次
        content = call_ollama(prompt + "注意：selected 必须严格等于备选方案中的一项。", schema)
        result = json.loads(content)

    return DecisionResponse(**result)

几个细节我特意说一下。

第一， options 里的 temperature 设成 0。做决策不是写诗，不需要“创造性”，温度越低输出越稳定。我实测过 temperature 0 和 0.7 的结果差异，后者偶尔会给出让我意外的答案，但对决策模型来说，“意外”往往意味着跑偏。

第二，把模型名写成一个环境变量或者配置文件，不要硬编码。我一开始图方便硬编码了模型名，后来换模型跑对比实验，改代码改了三次，烦透了。现在都从环境变量读。

第三，超时给足一点。本地推理虽然没有网络延迟问题，但大一点的模型加载到内存也要时间，首次调用尤其慢。如果超时设得太短，动不动就报错，特别影响体验。

3.3 通过 Nginx 加一层 API Key 保护

本地服务默认只在 localhost:11434 监听，自己用没问题，但如果你想在局域网里让多台机器访问，或者把服务暴露到公网配合 CherryStudio 这类客户端用，那就必须做访问控制，不然等于把模型裸奔给所有人。

我用的方案是在 Nginx 层做反向代理，并在代理层校验 API Key。配置大概长这样：

server {
    listen 8080;
    server_name your-server-name;

    location / {
        if ($http_x_api_key != "your_secret_key_here") {
            return 401;
        }
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

客户端调用时，在请求头里带上 X-API-Key 就行。

用 Nginx 而不是在 FastAPI 里校验，好处是：API Key 的校验逻辑跟业务代码完全解耦，以后想换 Key、想加 IP 白名单，直接改 Nginx 配置，不用重新部署应用。CherryStudio 这类支持自定义 API 地址的工具，把 base URL 填成 http://你的服务器:8080 ，再填上 API Key，就能直接用了。

这个方案也有个明显的局限：Nginx 的 if 指令做复杂逻辑比较吃力，如果你需要更精细的权限控制（比如不同 Key 对应不同模型），建议在 FastAPI 层加一个依赖项做统一认证，Nginx 只负责反代。我目前就是这样组合的：Nginx 挡掉大部分流量，应用层再做一次校验，双保险心里踏实。

4. 典型决策场景实验与结果对比

4.1 场景一：技术选型决策

我用决策模型跑过最典型的一次实验，是本地推理引擎选型。备选方案就三个：Ollama、LM Studio、vLLM。

评估维度我设成：性能、生态、部署难度、资源占用，权重分别给了 0.3、0.3、0.2、0.2。输入给模型之后，它返回的结果是：

{
  "selected": "Ollama",
  "confidence": 0.78,
  "reasons": ["部署最简单", "社区生态活跃"]
}

说实话这个结论跟我自己的判断高度一致。Ollama 虽然在高吞吐场景下打不过 vLLM，但胜在上手快、开箱即用、社区资料多，对小团队来说综合体验最好。

但这个实验也暴露了一个问题：模型给出的 confidence 往往偏高，有时候甚至接近 1.0。这不是模型“太自信”，而是它习惯给一个看起来合理的数值。所以我后来在提示词里强调“置信度必须小于 1，表示你有多确定”，并且明确告诉它：如果几个选项差异不大，置信度应该在 0.5 到 0.6 附近。这一下就靠谱多了，至少 confidence 能作为决策参考了。

4.2 场景二：日常任务优先级排序

决策模型不只能用于技术选型，日常任务排序也非常有用。我把一天要干的五件事丢进接口，让它输出一条优先级序列，格式约定成只返回排好序的数组。

实测体验很惊喜。以前用通用对话模型问“你觉得我该先做什么”，它会用大段文字分析每件事为什么重要、为什么紧急，最后给个“建议你先做……”，你还要自己在心里把它和剩下的任务再排一遍。现在直接返回 ["给客户写报价", "修复登录bug", "整理周报", "回邮件", "刷技术文章"] ，我照着执行就行，省掉了解读步骤。

这里有个小技巧：优先级排序场景，我会在用户提示词里加一句“不要分析，直接按优先级从高到低输出”。加上这句之后，模型几乎不会再输出多余的前缀。

4.3 去掉思考过程的实测对比

标题里说了“不必先写一段话”，这里我分享一个对比实验。

我用的测试模型是 Gemma3 系列（Ollama 上可以直接拉取），这个模型默认会有思考过程，响应里会附带一个 thinking 字段。第一次调用决策接口时我没管它，结果一次请求下来，thinking 内容比正式回复还长好几倍，耗时明显增加。

后来我把提示词调整成：“这是一个决策任务，禁止输出任何思考过程，直接给出结论。”同时，解析接口响应时把 message.thinking 字段直接丢弃，只取 content 。

对比数据很直观：同一道决策题，开启思考过程时响应约 4.8 秒，关闭之后降到 0.9 秒左右。token 消耗也从一千多降到了两三百。对单次调用来说，前后差四秒你可能无所谓，但如果你的 AI Agent 一天要调用几百次决策接口，这点差距会被无限放大。

需要说明的是，关闭思考过程在 Ollama 里有不同的实现方式，不同模型对提示词的敏感度也不一样。我用的笨办法是“提示词明确禁止 + 解析时丢弃”，通用性最好，任何模型都能用。如果你想在某个特定模型上彻底禁用它的思考层，建议查一下模型的官方文档，看它有没有对应的启动参数，比如关闭 think 标记的开关。

5. 常见问题与排查技巧实录

5.1 决策场景高频故障排查速查表

我在搭这套系统的过程中，前前后后遇到不少问题，挑几个最高频的整理成表格，你遇到类似情况可以直接对照着查。

现象	可能原因	解决办法
返回的 JSON 解析失败	模型版本过旧，不支持 format 参数	升级 Ollama 到最新版，或换用支持 JSON Schema 的模型
selected 不在备选列表中	提示词约束力不够	在提示词里加“必须严格等于原文”，解析时校验并重试
响应特别慢	模型没有关闭思考过程	用提示词禁止思考，并丢弃 thinking 字段
模型名字拉取失败	本地镜像源或模型文件损坏	用 sha256 校验文件，重新导入模型
局域网访问 401	API Key 没传或传错位置	确认请求头是 X-API-Key ，值要与 Nginx 配置一致
每次结果都不一样	temperature 没设 0	在调用参数里显式设置 temperature: 0

5.2 决策模型的“确定性”调优经验

这一节聊点调试心得。

先说说 temperature 的调法。我前面反复强调温度设 0，但你可能不知道原因：温度控制的是 token 采样的随机性。温度越高，模型越“敢说”概率低的词，输出越多样；温度设为 0，模型每次都会选择概率最高的 token，输出最确定。决策模型要的是稳定复现，不是创意发散，所以温度必须是最低档。

其次是上下文长度的控制。决策模型的输入不要带太多无关上下文，我第一次试验的时候把一整个技术方案文档塞进提示词，结果模型被大量信息“带偏”，选了一个文档里提到的备选项。后来我把输入精简成“选项、维度、权重”三件套，准确率立刻回升。决策场景不需要模型读论文，它只需要足够的数据来做“加减法”。

最后是多模型交叉验证。如果你纠结于某个关键决策，同一个决策请求分别发给两个不同模型（比如 qwen2.5 和 gemma3），然后比较结论。如果两个模型给出的答案一致，那这个结论大概率是靠谱的；如果不一致，说明选项本身的差异并不大，或者你的权重设置有问题。这个方法不能百分百保证正确，但至少能帮你排除掉单模型的系统性偏好。

---

最后分享一个我在实际使用中发现的细节：Ollama 的 /api/chat 接口本身支持多轮对话，但在决策这种场景里，多轮对话反而是负担。每次决策请求都从零开始，不带历史消息，能大幅降低因果偏差。我甚至建议你把决策服务封装成独立微服务，跟闲聊功能彻底分开，这样既方便维护，也更容易做性能调优。折腾完这套本地决策系统之后，最大的变化是：我现在问 AI 问题，基本只看结论，不看长篇解析了。