Agent 的能力上限往往不是框架决定的，而是底层模型决定的
模型能力是 Agent 的天花板
前面 19 篇讨论了各种 Agent 设计模式、工具、框架。但有一个事实绕不开：Agent 的表现上限主要由底层模型决定。
同样的 Agent 框架、同样的 prompt、同样的工具集，换一个能力更强的模型，效果往往有明显提升；换一个能力更弱的模型，再精巧的框架也救不回来。这一篇梳理影响 Agent 表现的几个关键模型能力维度。
维度一：指令遵循（Instruction Following）
Agent 的工作很多时候是按 prompt 指示做事。指令遵循能力直接决定 Agent 行为的可控性。
什么是指令遵循
- 严格按照输出格式（JSON、特定字段顺序、特定标记）
- 不偏离 prompt 设定的任务边界
- 多步指令时不漏步骤
- 否定指令的遵守（"不要做 X"）
对 Agent 的影响
指令遵循差的模型，常见症状：
- 要求输出 JSON，模型在 JSON 外加上额外说明
- 要求只用提供的工具，模型自己编造工具名
- 多 Agent 系统里，扮演特定角色的 Agent 偶尔"出戏"
- 设定了禁止操作，模型在某些条件下仍然执行
主流模型的大致表现
（注：这是基于公开评测和实际使用的概括，具体数字随版本变化）
| 模型 | 指令遵循 |
|---|---|
| Claude Sonnet 4 / Opus | 较强，对复杂格式遵守稳定 |
| GPT-4 / GPT-4o | 较强 |
| GPT-3.5 | 一般，复杂指令容易漏 |
| Gemini Pro | 中等 |
| 开源模型（Llama 3、Qwen 等） | 视具体型号和版本差异较大 |
实践经验：如果 Agent 表现不稳定，第一个怀疑对象就是指令遵循能力。
维度二：工具使用（Tool Use）
Agent 需要根据情况选择并调用工具，这个能力的稳定性影响很大。
工具使用涉及的子能力
- 在多个工具里选对一个
- 正确填写工具的参数
- 处理工具返回的结果
- 知道什么时候不该调用工具（避免不必要的成本）
- 工具失败时合理处理
实际差异
| 能力 | 强模型表现 | 弱模型表现 |
|---|---|---|
| 工具选择 | 看任务自然选对 | 倾向用熟悉的工具，错选 |
| 参数填写 | 类型正确，必填项不漏 | 类型错、字段名拼错 |
| 结果处理 | 看懂错误信息后调整 | 不看结果，重复同样调用 |
| 工具数量 | 几十个工具仍能用对 | 超过 10 个就开始混乱 |
提升工具使用稳定性的方法
不只是换模型，prompt 设计也有影响：
- 工具描述要具体："搜索学术论文" 比 "搜索" 好用
- 参数示例：给每个工具几个调用示例
- 失败处理指引：明确告诉 Agent 失败时该怎么办
- 工具分组：把工具按场景分组，让 Agent 先选场景再选工具
弱模型 + 好 prompt 通常优于强模型 + 草率 prompt。但有上限。
维度三：长上下文（Long Context）
Agent 任务往往涉及大量历史信息：之前的工具调用结果、错误信息、代码片段。模型的长上下文处理能力影响 Agent 在长任务上的表现。
长上下文不只是窗口大小
声称支持 1M token 的模型，不等于在 1M token 里都能保持稳定的理解能力。常见现象：
- 位置敏感：放在中间位置的信息被忽略（lost in the middle）
- 召回准确率下降：上下文越长，准确召回特定细节的能力越差
- 推理能力下降：长上下文下做复杂推理的稳定性低于短上下文
不同模型的实际表现
| 模型 | 窗口 | 长上下文实际表现 |
|---|---|---|
| Claude Sonnet 4 / Opus | 200K | 长上下文性能下降较小 |
| GPT-4o | 128K | 中段位置召回有下降 |
| Gemini 1.5 Pro / 2.0 | 1M-2M | 窗口大，但全长一致性是另一回事 |
| 开源模型 | 视具体型号 | 名义窗口和实际可用差距大 |
对 Agent 设计的指导
- 长任务里主动总结，不要堆所有历史
- 关键信息（任务目标、约束）放在 prompt 开头或结尾
- 中间历史定期压缩
- 不依赖模型从长上下文里精确召回某个具体事实，重要的事实应该显式放在最新的 message 里
维度四：推理能力（Reasoning）
复杂任务需要多步推理。模型的推理能力决定了 Agent 能处理的任务复杂度上限。
推理体现在哪些地方
- 任务规划：把复杂任务拆解成子任务
- 失败诊断：从错误信息里推断真正原因
- 反事实思考：假设某条路走不通，预判替代方案
- 跨步骤的因果关联：步骤 5 失败可能是因为步骤 2 的某个决策
思考型模型的引入
2024 年开始，OpenAI o1、o3，DeepSeek R1，Claude 4 等模型引入了显式的思考机制——在输出最终答案前，模型先输出一段（不直接展示给用户的）推理过程。
这类模型在复杂推理任务上有明显优势：
| 模型类型 | HumanEval | SWE-bench Verified |
|---|---|---|
| 常规模型（GPT-4o） | ~90% | ~30% |
| 思考型模型（o3） | ~95% | ~70% |
但代价是延迟和费用——思考过程本身要消耗 token，且这部分 token 通常按更高单价计费。
何时用思考型模型
适合用：
- 复杂的算法实现
- 多步推理才能解决的 bug
- 需要规划的开发任务
不适合用：
- 简单的代码补全
- 信息检索任务
- 对响应延迟敏感的交互场景
实际中混用是常见做法：路由层根据任务难度分发，简单任务给常规模型，复杂任务给思考型模型。
维度五：代码相关的专项能力
代码 Agent 特有的几个维度：
多语言支持
主流模型对 Python 支持都不错。其他语言差异大：
- Rust、Go：主流模型较好，但偶有过时 API
- TypeScript / JavaScript：较好，前端框架版本敏感
- Java / C#：可用，但企业级框架的最佳实践掌握有限
- 冷门语言（OCaml、Erlang 等）：质量明显下降
库 / 框架的版本敏感性
模型训练数据有 cutoff，新版本 API 可能模型不知道。常见症状：
- 使用了已废弃的 API
- 用旧版本的语法或参数
- 不知道某些新引入的库
应对：
- prompt 里显式说明用的版本
- 提供 import 示例
- 失败时给文档链接让 Agent 重读
项目惯例的适配
模型默认按"常见做法"写代码，可能和项目现有风格不一致：
- 命名风格（snake_case vs camelCase）
- 错误处理方式（异常 vs 返回值）
- 日志库选择
应对：
- prompt 里说明项目惯例
- 提供项目里的代码片段作为示例
- 用 lint 工具校验生成的代码
模型选择的几个实际考虑
1. 不是越贵越好
复杂推理任务：用强模型（Claude Opus、GPT-4、o3） 简单任务：用便宜模型（Claude Haiku、GPT-4o-mini） 混用：路由层分发
2. 评测要在自己的场景做
公开 benchmark 反映的是平均能力。你的具体场景可能正好踩在某个模型的弱项上。建议从自己的真实任务里采样 20-30 个，每个候选模型都跑一遍。
3. 关注稳定性，不只是平均分
90% 通过率 + 偶尔静默错误 vs 80% 通过率 + 失败时显式承认，后者在生产里通常更可控。
4. 模型版本会变
主流模型在持续迭代，今天的最佳选择半年后可能不是。设计 Agent 系统时把"切换模型"的代价控制低一些，不要把某个特定模型的特性深度耦合进系统。
框架 vs 模型的权衡
回到开头的问题：Agent 的表现里，框架和模型谁更重要？
经验性的判断：
- 模型差距 1 个档次（比如 GPT-3.5 vs GPT-4）：模型差距主导，无论框架怎么设计
- 模型差距小（比如 Claude Sonnet 4 vs GPT-4o）：框架设计能拉开 10-20% 的差距
- 同一模型下：好的 prompt 和工具设计可以让弱模型接近强模型的水平
实际选型的合理顺序：
- 先选合适的模型（功能足够、成本可接受）
- 再设计合适的 Agent 框架（控制流、工具集）
- 最后调 prompt 和工具描述（细节优化）
倒过来做（先选框架再考虑模型）是常见的弯路。
系列暂告段落
20 篇下来，从代码作为推理工具（PoT、CoC）到代码作为动作空间（CodeAct、Voyager），到工程化的系统设计（SWE-agent、OpenHands），再到评测、安全、上下文管理、模型选择，把代码 Agent 这个方向较重要的内容覆盖了一遍。
后续如果有新的有意思的论文或工程实践，会作为单篇补充。这个系列暂时告一段落，欢迎反馈和讨论。
版权声明: 如无特别声明，本文版权归 sshipanoo 所有，转载请注明本文链接。
（采用 CC BY-NC-SA 4.0 许可协议进行授权）
本文标题:20. 模型自身能力对 Agent 表现的影响
本文链接:https://www.sshipanoo.com/blog/ai/code-agent-harness/20-模型能力对Agent的影响/
本文最后一次更新为 天前，文章中的某些内容可能已过时！
你愿意为你喜欢的事情付出多少！
