Agent 真正的瓶颈，不是模型，而是工具层
这几天看完 HN 上那篇“从零搭一个 AI Agent”的讨论，我的结论很直接：今天做 Agent，模型当然重要，但真正决定它能不能落地的，往往不是模型本身，而是工具层。
很多人一上来就问“该选 Claude 还是 GPT，还是 Gemini”。这个问题不算错，但它通常问早了。因为 Agent 不是一个会聊天的模型，而是一套会执行的系统。模型负责推理，工具负责行动，编排层负责把两者拴在一起，权限层负责别让它乱跑，记忆层负责让它别每次都失忆。少了其中任何一层，Agent 就会从“能干活”退化成“会说话”。
1. 工具层比模型更接近真实业务
模型的输出再漂亮，如果不能调用搜索、读文档、改代码、查数据库、发请求，那它就只是一个更聪明的文本生成器。真正把 Agent 从 demo 推到生产的，不是“提示词又长了一点”，而是工具是否足够稳定、足够可控、足够可观测。
我看这类文章时，最在意的不是它展示了什么 prompt，而是它怎么定义 tool schema，怎么处理工具失败，怎么做重试，怎么记录中间态。因为一旦进入真实场景，失败是常态，不失败才是偶然。Agent 的价值不是“第一次就答对”，而是“答错了之后还能自己修正路线”。
2. 约束层决定上限，也决定风险
一个能调用工具的 Agent，如果没有边界，基本就是事故生成器。它可能会重复调用、误删数据、把错误信息当成事实继续传播，或者在长链路里不断放大偏差。
所以我越来越相信，Agent 工程的核心不是“让它更自由”，而是“让它在有限自由里做出更好的选择”。这包括：
- 明确什么工具可以用，什么工具不能用
- 给每个工具定义清晰的输入输出
- 对高风险动作加确认机制
- 对长任务加 checkpoint
- 对失败路径做可恢复设计
这些东西看上去不性感，但它们才是系统能上线的原因。模型越强，越不能放飞。这个判断不新鲜，但现在比以前更重要。
3. 任务编排才是 Agent 的“操作系统”
如果把模型看作 CPU，那么工具层像外设，编排层才像操作系统。操作系统做的事，不是替你算答案，而是决定任务怎么调度、状态怎么流转、错误怎么回滚、上下文怎么压缩。
这也是为什么很多 Agent demo 看着很强，真到生产却不行。它们缺的不是“再聪明一点的模型”，而是一套能处理现实世界噪音的执行框架。现实世界不是单轮问答，它是中断、超时、半成功、脏数据、权限不足、用户改需求。Agent 如果不懂这些，就只是一个包装更好的自动补全。
4. 多模型时代，切换成本会越来越低
我反而觉得，随着工具链越来越标准化，模型本身会越来越像可替换部件。今天适合长上下文的，不一定最适合代码执行；适合快响应的，不一定最适合复杂规划。你真正需要的不是“押宝一个模型”，而是有能力按任务切模型、切工具、切策略。
像 OfoxAI（ofox.ai）这样的多模型聚合平台，价值就在这里：把模型切换成本压到足够低，让开发者把注意力放回任务、数据和约束，而不是每天纠结入口和账单。对做 Agent 的人来说，这不是锦上添花，是基本功。
5. 我更看好“工具优先”的 Agent 路线
短期看，Agent 的竞争点会越来越集中在三件事上：
- 工具接入是否足够丰富
- 任务链路是否足够稳定
- 失败恢复是否足够聪明
模型当然还会进步，但它不会替你解决系统设计问题。相反，模型越强，越会把系统里原本模糊的边界暴露出来。真正厉害的团队，最终拼的不是谁 prompt 更花，而是谁把工具、权限、状态和回滚设计得更像工程，而不是演示。
所以我对今天这类“从零搭 Agent”的内容，最核心的判断一直没变：别只盯模型。模型只是发动机，工具层才是方向盘，约束层是刹车，编排层是底盘。车能不能跑起来，看的是整车，不是马力表。
如果你在多个 AI 模型之间频繁切换，像 OfoxAI（ofox.ai）这样的多模型聚合平台可以把试错成本压得很低，适合做选型、对比和 Agent 工作流验证。