原文：https://www.mstx.cn/harness/416.html · 创建：2026-09-02 · 更新：2026-09-04 · 阅读：1141

---

一个看似简单实则关键的决策

在开始搭建Harness之前，你需要做出的第一个技术决策是：用哪个LLM Provider？

这个决策看似简单——不就是选一个API服务商吗？但它实际上影响着Harness的每一个后续设计：工具调用的格式、错误处理策略、成本结构、延迟预算、甚至数据安全架构。

更微妙的是，这个决策不是一次性的。Provider在快速迭代，模型能力在持续变化，价格在动态调整。你今天选择的最优方案，三个月后可能不再是。因此，本节的目标不仅是帮你做出当前的选择，更是帮你建立一套评估Provider的思考框架，让你在未来能够持续做出有依据的判断。

候选方案的概览

截至2026年，Agent开发中主流的LLM Provider可以分为三大类：

类别	代表	特点
商业API（云端）	OpenAI、Anthropic、Google Gemini	能力最强，使用方便，成本可控，但数据需出域
本地部署（开源模型）	Llama、Qwen、DeepSeek等	数据不出域，成本可预测，但需要运维能力
混合方案	敏感数据用本地模型，通用任务用商业API	平衡安全与能力，但架构复杂度最高

每一类方案都有其忠实的拥趸和合理的适用场景。没有"最好"的Provider，只有最适合你约束条件的Provider。

评估Provider的五个维度

选择Provider不是比较"谁的模型更聪明"，而是在五个维度上做出权衡：

维度一：模型能力

这可能是你最关心的维度，但它不是唯一重要的维度。

模型能力包括：

• 推理能力：能否处理多步推理和复杂决策？
• Function Calling质量：能否准确输出结构化的工具调用？参数提取是否可靠？
• 指令遵循：能否严格遵守系统提示词中的行为规则？
• 上下文窗口：能容纳多少对话历史和工具定义？

一个常见的误区：只看模型的"跑分"（如MMLU、GPQA等学术基准），而忽视Function Calling的实际表现。一个学术跑分很高的模型，可能在工具调用场景中表现糟糕。对于Agent来说，Function Calling质量的重要性不亚于推理能力。

建议：在确定候选模型后，用第7章的评估方法，在你的具体场景上做对比测试。学术基准只能作为初筛，场景实测才是最终依据。

维度二：成本结构

LLM的成本不是固定的，它取决于三个变量：

$$\text{成本}=\text{输入token数}\times \text{输入单价}+\text{输出token数}\times \text{输出单价}$$

Agent场景的成本有几个特殊之处：

第一：Agent的token消耗远大于聊天应用。 每次循环都要把完整的对话历史（包括所有工具定义和中间结果）重新发送给LLM。一个5轮循环的Agent任务，token消耗可能是单轮对话的10倍以上。

第二：工具Schema本身也消耗token。 每个工具的JSON Schema（名称、描述、参数定义）都会被塞进系统提示词。工具越多，每次调用的固定开销越大。

第三：输出token比输入token贵。 大多数Provider对输出token的定价远高于输入token。Agent的循环中，LLM每次都要输出决策（可能是工具调用请求），这会累积可观的输出token消耗。

建议：在估算成本时，用真实的循环次数和token消耗数据，而非假设。第9章会讨论如何精确追踪成本。在初始选择阶段，至少要做一次"最坏情况"的成本估算：假设每个任务平均需要10轮循环，每轮消耗5000个输入token和500个输出token，计算每天1000个任务的总成本。

维度三：延迟与吞吐

Agent对延迟的敏感度远高于聊天应用。

聊天应用的延迟是"一次等待"——用户发一条消息，等一次回复。Agent的延迟是"多次等待的累加"——如果每次LLM调用需要2秒，5轮循环就是10秒。这还不包括工具执行的时间。

延迟的关键指标：

• TTFT（Time to First Token） ：从发出请求到收到第一个token的时间。影响用户"Agent开始动了"的感知。
• 总响应时间：完成一次完整LLM调用的时间。
• 吞吐限制：Provider对API调用频率的限制（如RPM，每分钟请求数）。高并发场景下，吞吐限制可能成为瓶颈。

建议：在评估Provider时，实际测量你的场景下的端到端延迟——包括网络往返、LLM生成时间、工具执行时间。不要只看Provider公布的平均延迟数据，关注P95延迟（95%的请求在多少时间内完成），因为长尾延迟对用户体验的伤害最大。

维度四：数据安全与合规

这可能是决定性的维度，尤其是对于企业用户。

核心问题：你的数据能不能发到外部API？

• 如果Agent处理的是公开信息，数据出域可能不是问题
• 如果Agent处理的是用户隐私、商业机密、医疗记录、金融数据，数据出域可能是不可接受的
• 某些行业有明确的合规要求（如GDPR、HIPAA），限制了数据的使用方式

三种方案的数据安全对比：

方案	数据出域	合规风险	适用场景
商业API	是	取决于Provider的数据政策	非敏感数据、通用场景
本地部署	否	最低	敏感数据、强合规要求
混合方案	部分	取决于路由策略	敏感与非敏感数据混合

建议：在技术选型之前，先搞清楚你的合规约束。如果你的场景不允许数据出域，商业API的选择空间就非常有限，本地部署可能成为唯一方案。合规约束不是技术选型的"附加条件"，而是前置条件。

维度五：稳定性与生态

稳定性：Provider的API可用性如何？是否频繁变更？是否有完善的降级机制？

生态：Provider的工具链是否成熟？是否有良好的SDK支持？社区是否有丰富的调试和监控工具？

一个实际的问题：Provider是否会静默更新模型？OpenAI和Anthropic都会在用户无感知的情况下微调模型版本。这意味着你的Agent行为可能在没有改动任何代码的情况下发生变化。这是商业API的固有特性，你需要通过Harness的评估体系来检测和应对 这种漂移（第8章会详细讨论）。

三个主要选择的深入分析

OpenAI

优势：

• Function Calling生态最成熟：OpenAI是最早推出Function Calling的Provider，其工具调用格式已成为事实标准。大量框架（包括LangChain、Agents SDK）和工具（包括Langfuse、LangSmith）都以OpenAI的API为第一支持对象。
• 模型选择丰富：从轻量快速的gpt-4o-mini到能力最强的旗舰模型，覆盖了不同的成本-能力平衡点。
• 文档和社区：OpenAI的文档质量在行业中是标杆，社区资源丰富，问题容易找到解决方案。

劣势：

• 数据出域：所有数据都发送到OpenAI的服务器。对于数据敏感的场景，这是硬伤。
• 静默更新：模型版本会在无通知的情况下调整，Agent行为可能突然变化。
• 价格波动：OpenAI的价格调整相对频繁，长期成本预测困难。

适合谁：大多数通用场景的默认选择。尤其是当你需要快速搭建原型、充分利用Function Calling生态时。

Anthropic

优势：

• 推理能力强：Claude系列在复杂推理和长文本理解方面表现出色。尤其在需要精细的指令遵循和长篇文档分析的场景中。
• Function Calling能力也在成熟：Claude的工具调用虽然起步晚于OpenAI，但质量已基本对齐，且在并行工具调用 方面有独特设计。
• 长上下文窗口：Claude的上下文窗口在同价位中通常更大，适合需要大量工具定义或长对话历史的场景。

劣势：

• 生态兼容性：虽然Claude的工具调用格式与OpenAI接近，但部分框架和工具对Claude的支持仍不如OpenAI完善。
• 成本：在同等能力级别上，Claude的价格通常略高于OpenAI。

适合谁：需要强推理能力的复杂Agent、大量文档处理的场景、以及偏好Anthropic在AI安全方面立场的团队。

本地部署（开源模型）

优势：

• 数据完全不出域：这是本地部署最核心的价值。对于强合规要求的场景，这可能是唯一选择。
• 成本可预测：没有按token计费的不确定性，成本主要是硬件和运维。
• 完全可控：可以微调模型、修改推理参数、甚至定制模型架构。

劣势：

• 能力差距：开源模型在Function Calling质量和推理能力上，与顶级商业API仍有差距。这个差距在快速缩小，但在复杂Agent场景中仍然显著。
• 运维负担：需要自己管理GPU资源、推理服务、模型更新。这不是"装个软件"那么简单。
• 生态不成熟：围绕开源模型的Agent工具链（可观测、评估、调试）仍在发展中。

适合谁：数据合规是第一优先级的企业；有专门ML运维团队的团队；需要深度定制模型能力的场景。

一个务实的建议：如果你选择本地部署，优先选择对Function Calling支持最好的开源模型，而非推理跑分最高的。在Agent场景中，工具调用的可靠性比通用智能更重要。

混合方案：一条务实的路径

在实践中，越来越多的团队采用混合方案：

• 敏感数据：走本地模型，确保数据不出域
• 通用任务：走商业API，享受最强的能力和最成熟的生态
• 路由逻辑：在Harness中实现一个模型路由器，根据任务类型和敏感级别决定使用哪个Provider

混合方案的架构：

用户请求 → Harness
        │
        ▼
┌─────────────────┐
│ 模型路由器       │
│                 │
│ 判断：          │
│ 含敏感数据？     │
└────┬────────┬───┘
     │        │
敏感 │        │ 非敏感
     ▼        ▼
┌──────────┐ ┌──────────┐
│ 本地模型  │ │ 商业API  │
└──────────┘ └──────────┘

混合方案的代价 是架构复杂度：你需要维护两套模型的接口适配、两套评估基线、两套成本追踪。但它可能是在约束条件下最优的工程折衷。

一个决策框架

综合以上分析，这里给出一个简化的决策流程：

第一步：确认合规约束
│
├── 数据不允许出域？ → 本地部署或混合方案
│
└── 数据可以出域？ → 进入第二步
│
第二步：评估能力需求
│
├── 复杂推理、精细指令遵循？ → 优先考虑Anthropic Claude
│
├── 工具生态、快速迭代、成本敏感？ → 优先考虑OpenAI
│
└── 需要对比实测？ → 两个都测，用评估集说话
│
第三步：估算成本与延迟
│
├── 预算有限？ → 选择性价比高的模型（如gpt-4o-mini）
│
└── 延迟敏感？ → 实测P95延迟，选择满足预算的最快模型

本书的技术选型

基于以上分析，本书做出以下选择：

主选Provider：OpenAI API（兼容接口）

理由：

• 1、Function Calling格式是事实标准，代码示例的普适性最强
• 2、生态最成熟，可观测和评估工具的集成最顺畅
• 3、兼容接口 意味着你可以用相同的代码调用其他Provider（如DeepSeek、Kimi等提供OpenAI兼容接口的服务）

代码层的应对策略：

本书的示例代码使用OpenAI SDK，但所有代码都遵循一个原则：通过配置而非硬编码来指定Provider。这意味着你可以将base_url和api_key替换为任何兼容的Provider，而不需要修改核心逻辑。

from openai import OpenAI

# 通过配置选择Provider，而非硬编码
client = OpenAI(
    base_url=os.getenv("LLM_BASE_URL", "https://api.openai.com/v1"),
    api_key=os.getenv("LLM_API_KEY"),
)

这段代码可以无缝切换Provider。当你在后续章节中读到"调用LLM"时，记住：具体调用的是哪个Provider，是你的配置决策，而非代码结构的一部分。

本节小结

选择LLM Provider是Harness设计的第一块基石。这个决策应该在五个维度上做出：模型能力、成本结构、延迟与吞吐、数据安全与合规、稳定性与生态。

没有普适的最优选择。在你的约束条件下做出最合理的权衡，并保持切换的灵活性——这才是正确的策略。本书的示例代码使用OpenAI兼容接口，但所有设计原则和架构模式，对于任何Provider都同样适用。

在下一节中，我们将开始实际搭建：安装依赖、初始化项目结构、跑通最小Harness的第一个组件。