AI Agent 选型：先选工具，再选模型

这件事是从一次意外的发现开始的。

我在 Cursor CLI 里输入“帮我查一下 Upwork 上这个月发了哪些GEO（生成式引擎优化）相关的订单”，它回了一句“抱歉，我查不了，被拦截了”。同一台电脑上，切到Codex，同样的任务——搜索、筛选、整理订单——一气呵成。

Cursor 使用 auto 模式，Codex使用当前模型，底层模型能力是差不多的，行为差异却这么大。这是两个 AIAgent（AI 智能体）工具链设计不同的结果：Codex把网页搜索作为原生工具内置了，Cursor CLI在这个任务里没有可用的网页搜索工具。

换句话说，在这个具体任务里，模型能力不是瓶颈；有没有可用的网页搜索工具，才是瓶颈。

我们一直选错了顺序

很长一段时间里，我默认的选型顺序是：先比大语言模型（Large LanguageModel，LLM），比如GPT、Claude、Gemini，再选支持这个模型的工具。这个顺序很自然，因为模型是技术的“硬实力”，是大家在媒体上反复比较的指标。

但这个场景反复出现之后，我开始意识到问题出在哪里：模型能力已经趋同，工具链的差异才决定一件事能不能做成。

Codex的优势在于把搜索、文件、截图、长任务等能力放进同一个工作台，适合需要联网信息和跨工具执行的多面手场景。

Cursor 的优势在编辑器内——行内补全、可视化 diff、原生 IDE体验更顺；如果任务依赖网页信息采集，就要看当前环境是否配好了对应工具和权限。

Claude Code 走的是可扩展路线——hooks、skills、subagents、MCP和长上下文，适合需要深度自主性的工程任务。

三者在 2026年中已经趋同到都能覆盖多文件编辑、并行智能体、模型上下文协议（ModelContextProtocol，MCP）和云端执行等方向。差距不再只是“能不能做”，而是“配了什么工具、默认怎么用”。

于是选型顺序自然反转了：先确定任务，再看哪个 AI Agent配了对应的工具链，最后才看这个 Agent 下能用什么模型。

一个更实用的框架

AI Agent 能力 = 模型（大脑）+ 工具（手脚）+ 交互范式（怎么用你）

对使用者来说，三个因素里最不可互换的是“工具”。模型可以换（现在部分Agent 支持切换底层LLM），交互范式可以适应，但工具链是硬绑定的——没有网页搜索工具的 AIAgent，给它接上更强模型也搜不了 Upwork。

所以你不需要纠结“哪个模型最强”。你需要的是：

搜索类、信息获取类任务 优先选已经配好网页搜索和资料整理工具的 Agent。

大型重构、复杂工程分析 优先选长上下文、subagent和扩展机制更成熟的 Agent。

日常编码、快速原型 优先选 IDE体验、行内补全和代码 diff 最顺手的 Agent。

而且它们不是互斥的。我现在的做法是组合使用：同一个项目，日常编辑在Cursor，需要搜资料时切 Codex，遇到大重构就上楼跑 Claude Code。

给不懂技术的朋友解释这件事，我常用的类比是：先看车架，再看发动机。

车架决定这辆车能装什么——是跑车底盘还是越野底盘，能挂什么附件。发动机决定它能跑多快。但再强的发动机，装在一台没配越野胎的轿车上，也上不了山。

AI Agent也一样：模型是发动机，工具链是车架。先想清楚你要跑什么路（任务），再选对应的车架（Agent工具链），最后在它的引擎选项里挑一个够用的发动机（模型）。

AI Agent选型的第一性原则不是“发动机马力大不大”，而是“车架配了什么”。先想清楚你要跑什么路，再给车架上发动机。