EN
AI模型

怎样选择开放模型并自建AI Agent：从本地验证到安全上线

开放模型不是越大越好。本文从任务、工具调用、上下文、硬件和许可证出发，讲清如何用Ollama验证、用vLLM服务化，并搭建带权限、评测和人工确认的自托管AI Agent。

Jacky Wang 6 分钟阅读 19 阅读

自建 AI Agent 最容易走错的一步，是先选“最强模型”，再硬找使用场景。真正可落地的顺序应该反过来：先定义任务、工具权限和验收标准，再选择刚好能稳定完成任务的开放权重模型。模型只是推理层，Agent 的可靠性更多取决于工具设计、状态管理、权限边界和失败处理。

本文给出一条从个人电脑验证到 GPU 服务器上线的实用路径。你不需要一开始就搭建复杂的多智能体平台；一个模型服务、一个受控工具循环和一组可复现评测，已经足够做出可用的第一版。

先澄清：开放权重不一定等于开源

很多人把可以下载权重的模型统称为“开源模型”，但许可证可能限制商用、再分发或特定用途。选型前至少要核对模型卡、许可证、上下文长度、工具调用格式和推理框架支持情况。不要只看榜单名称，也不要假设同一系列的不同尺寸拥有完全相同的授权条件。

如果你需要了解主流系列的参数、性能与部署差异，可以先看站内的主流开放权重模型横评。这篇文章不再重复跑分，而是把重点放在如何为 Agent 做工程选型。

选模型时，先回答五个问题

1. Agent 到底要完成什么任务？

把需求写成可验证动作，而不是“做一个万能助手”。例如：从指定目录读取文档并生成带引用的摘要；查询只读数据库并返回表格；根据工单内容调用三个固定 API。任务越明确，越容易用较小模型稳定完成。

2. 是否真的需要工具调用？

聊天质量好，不代表函数调用可靠。Agent 模型必须能稳定输出工具名称和符合 JSON Schema 的参数，还要能理解工具结果并决定是否继续。上线前应单独测试：选错工具、漏填参数、重复调用、工具报错后的恢复，以及是否会在没有授权时尝试调用工具。

3. 上下文是“标称长度”还是“可用长度”？

长上下文会增加显存占用和延迟，而且模型在上下文后段的检索质量未必保持不变。与其把全部资料塞进提示词，不如使用检索、摘要和分层记忆，只把完成当前步骤所需的信息交给模型。

4. 延迟、吞吐和质量哪个最重要？

本地个人助手看重首 token 延迟；后台批处理更看重吞吐；代码修改或财务分析则更在意一次成功率。不要用一个平均跑分替代业务指标。至少记录任务成功率、P95 延迟、输出 token、工具调用次数和人工返工时间。

5. 你的硬件预算是多少？

粗略估算权重显存可以使用“参数量 × 量化位数 ÷ 8”，但这只是起点。实际运行还需要 KV Cache、运行时缓冲和并发空间。上下文越长、并发越高，额外显存越多。首次部署应预留余量，而不是把显存使用率顶到极限。

一个实用的模型分层方法

任务类型 优先选择 需要重点验证
分类、抽取、固定格式改写 小型指令模型 结构化输出、中文准确率、吞吐
知识库问答、客服草稿 中型通用模型 引用一致性、拒答、长上下文
代码代理、多工具工作流 工具调用和代码能力较强的模型 JSON 参数、跨文件理解、测试修复循环
复杂规划、高风险决策 更强模型或混合路由 升级人工、审计、不可逆操作确认

更经济的方案通常不是让最大模型处理所有请求，而是做路由：小模型完成分类与简单执行，遇到低置信度、连续失败或高风险任务时，再升级到更强模型或人工。

开发阶段：用 Ollama 快速验证

Ollama 适合在个人电脑或单机环境快速下载、切换和调用模型。它提供本地 API，也支持工具调用。安装后可以先运行一个与你硬件匹配、明确支持工具调用的模型：

ollama run <model-name>

接着用本地 API 做三组最小测试：普通问答、结构化 JSON、一次工具调用。此时不要急着加记忆、向量库和十几个工具。先证明模型能在 50 至 100 条真实样本中稳定选择正确工具。

生产阶段：用 vLLM 提供兼容 API

当你需要 GPU 服务、并发和统一客户端时，可以使用 vLLM。官方文档显示，它能够提供 OpenAI 兼容的 Chat Completions、Responses 和 Embeddings 等接口。基本启动方式如下：

vllm serve <model-id> \
  --host 127.0.0.1 \
  --port 8000 \
  --api-key <local-api-key>

不要在不了解模型模板的情况下直接复制工具调用参数。vLLM 的自动工具选择需要匹配模型的 tool-call parser 和 chat template；不同模型的配置可能不同。服务也不应未经认证直接暴露到公网，建议放在反向代理、私网或零信任访问层之后。

Agent 的最小架构：循环，而不是魔法

最小 Agent 只需要六步：

  1. 接收用户目标，并加载允许使用的工具清单。
  2. 模型决定直接回答还是生成工具调用。
  3. 程序用 JSON Schema 校验参数。
  4. 权限层检查用户、资源、动作和风险等级。
  5. 执行工具，把结果作为结构化消息交回模型。
  6. 达到完成条件、步骤上限或风险阈值后停止。
for step in range(MAX_STEPS):
    response = model(messages, tools=allowed_tools)
    if not response.tool_calls:
        return response.text

    for call in response.tool_calls:
        args = validate(call.name, call.arguments)
        authorize(user, call.name, args)
        result = execute_with_timeout(call.name, args)
        messages.append(tool_result(call.id, result))

raise RuntimeError("agent exceeded step limit")

这段循环真正重要的不是模型调用，而是 validate、authorize、超时和 MAX_STEPS。工具描述应窄而明确，例如“读取指定项目中的文件”，而不是“执行任意 shell 命令”。写操作、转账、发布内容和删除数据应进入人工确认队列。

什么时候需要 LangGraph？

只有当流程出现分支、重试、暂停恢复、人工审批或长时间状态时，才值得引入图式编排。LangGraph 的工具节点和条件路由适合把 Agent 表达成可观察的状态机。简单的单工具助手用几十行循环往往更容易调试；框架不会自动修复模型选错工具或权限设计过宽的问题。

上线前必须完成的评测

  • 任务集：使用真实但脱敏的成功、失败和边界案例。
  • 工具集：测试正确调用、错误参数、超时、空结果和重复执行。
  • 安全集：测试提示注入、越权读取、危险写入和敏感信息回显。
  • 恢复能力：工具失败后能否停止、重试或升级人工。
  • 可观测性：记录模型版本、提示版本、工具参数、延迟和最终结果，但避免记录密码与敏感正文。

一个工具单次成功率即使看起来很高，经过多步串联后，整条任务的成功率也会下降。因此应限制循环步数，尽量让工具具备幂等性，并为有副作用的动作增加确认与审计。

最终建议：先做窄，再做强

自建开放模型 Agent 的优势是数据路径、成本结构和权限边界都掌握在自己手里；代价是你也要承担模型更新、推理服务、评测、安全与监控。最稳妥的路线是从一个可验收的窄任务开始，用 Ollama 验证模型与工具调用，再用 vLLM 服务化，并在扩大权限前补齐评测、审计和人工升级机制。

不要把“能调用工具”误认为“可以自主运行”。真正可用的 Agent，应当知道自己能做什么、不能做什么、什么时候必须停下来。

主要来源

说明：具体模型、许可证、工具调用模板和推理框架支持会持续变化。部署前应以对应模型卡和当前版本官方文档为准，并在自己的真实任务集上重新评测。

发表评论