在开始搭建Harness之前，你需要做出的第一个技术决策是：用哪个LLM Provider？
这个决策看似简单——不就是选一个API服务商吗？但它实际上影响着Harness的每一个后续设计：工具调用的格式、错误处理策略、成本结构、延迟预算、甚至数据安全架构。
更微妙的是，这个决策不是一次性的。Provider在快速迭代，模型能力在持续变化，价格在动态调整。你今天选择的最优方案，三个月后可能不再是。因此，本节的目标不仅是帮你做出当前的选择，更是帮你建立一套评估Provider的思考框架，让你在未来能够持续做出有依据的判断。
截至2026年，Agent开发中主流的LLM Provider可以分为三大类：
| 类别 | 代表 | 特点 |
|---|---|---|
| 商业API（云端） | OpenAI、Anthropic、Google Gemini | 能力最强，使用方便，成本可控，但数据需出域 |
| 本地部署（开源模型） | Llama、Qwen、DeepSeek等 | 数据不出域，成本可预测，但需要运维能力 |
| 混合方案 | 敏感数据用本地模型，通用任务用商业API | 平衡安全与能力，但架构复杂度最高 |
每一类方案都有其忠实的拥趸和合理的适用场景。没有"最好"的Provider，只有最适合你约束条件的Provider。
选择Provider不是比较"谁的模型更聪明"，而是在五个维度上做出权衡：
这可能是你最关心的维度，但它不是唯一重要的维度。
模型能力包括：
一个常见的误区：只看模型的"跑分"（如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秒。这还不包括工具执行的时间。
延迟的关键指标：
建议：在评估Provider时，实际测量你的场景下的端到端延迟——包括网络往返、LLM生成时间、工具执行时间。不要只看Provider公布的平均延迟数据，关注P95延迟（95%的请求在多少时间内完成），因为长尾延迟对用户体验的伤害最大。
这可能是决定性的维度，尤其是对于企业用户。
核心问题：你的数据能不能发到外部API？
三种方案的数据安全对比：
| 方案 | 数据出域 | 合规风险 | 适用场景 |
|---|---|---|---|
| 商业API | 是 | 取决于Provider的数据政策 | 非敏感数据、通用场景 |
| 本地部署 | 否 | 最低 | 敏感数据、强合规要求 |
| 混合方案 | 部分 | 取决于路由策略 | 敏感与非敏感数据混合 |
建议：在技术选型之前，先搞清楚你的合规约束。如果你的场景不允许数据出域，商业API的选择空间就非常有限，本地部署可能成为唯一方案。合规约束不是技术选型的"附加条件"，而是前置条件。
稳定性：Provider的API可用性如何？是否频繁变更？是否有完善的降级机制？
生态：Provider的工具链是否成熟？是否有良好的SDK支持？社区是否有丰富的调试和监控工具？
一个实际的问题：Provider是否会静默更新模型？OpenAI和Anthropic都会在用户无感知的情况下微调模型版本。这意味着你的Agent行为可能在没有改动任何代码的情况下发生变化。这是商业API的固有特性，你需要通过Harness的评估体系来检测和应对这种漂移（第8章会详细讨论）。
优势：
gpt-4o-mini到能力最强的旗舰模型，覆盖了不同的成本-能力平衡点。劣势：
适合谁：大多数通用场景的默认选择。尤其是当你需要快速搭建原型、充分利用Function Calling生态时。
优势：
劣势：
适合谁：需要强推理能力的复杂Agent、大量文档处理的场景、以及偏好Anthropic在AI安全方面立场的团队。
优势：
劣势：
适合谁：数据合规是第一优先级的企业；有专门ML运维团队的团队；需要深度定制模型能力的场景。
一个务实的建议：如果你选择本地部署，优先选择对Function Calling支持最好的开源模型，而非推理跑分最高的。在Agent场景中，工具调用的可靠性比通用智能更重要。
在实践中，越来越多的团队采用混合方案：
混合方案的架构：
用户请求 → Harness
│
▼
┌─────────────────┐
│ 模型路由器 │
│ │
│ 判断： │
│ 含敏感数据？ │
└────┬────────┬───┘
│ │
敏感 │ │ 非敏感
▼ ▼
┌──────────┐ ┌──────────┐
│ 本地模型 │ │ 商业API │
└──────────┘ └──────────┘
混合方案的代价是架构复杂度：你需要维护两套模型的接口适配、两套评估基线、两套成本追踪。但它可能是在约束条件下最优的工程折衷。
综合以上分析，这里给出一个简化的决策流程：
第一步：确认合规约束
│
├── 数据不允许出域？ → 本地部署或混合方案
│
└── 数据可以出域？ → 进入第二步
│
第二步：评估能力需求
│
├── 复杂推理、精细指令遵循？ → 优先考虑Anthropic Claude
│
├── 工具生态、快速迭代、成本敏感？ → 优先考虑OpenAI
│
└── 需要对比实测？ → 两个都测，用评估集说话
│
第三步：估算成本与延迟
│
├── 预算有限？ → 选择性价比高的模型（如gpt-4o-mini）
│
└── 延迟敏感？ → 实测P95延迟，选择满足预算的最快模型
基于以上分析，本书做出以下选择：
主选Provider：OpenAI API（兼容接口）
理由：
代码层的应对策略：
本书的示例代码使用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的第一个组件。
评论专区
评论加载中...登录后即可发表评论