这半年看 AI Agent 讨论，有个很有意思的错位。

网上最热闹的话题，通常还是“哪个模型更强”“榜单又涨了几分”“这一版是不是已经能替代人了”。但真到了公司里，要把 Agent 接进业务、接进团队、接进日常流程，大家卡住的地方往往没那么浪漫。不是模型不聪明，而是它一碰到真实环境就开始露馅：工具不会用、上下文越跑越乱、流程一长就失控、结果看着像对的，真执行起来却不敢放手。

说白了，很多 Agent 进不了生产环境，不是死在模型层，而是死在能力层。

什么叫“能力层”？

我这里说的能力层，不是某个特定框架名词，而是一整套夹在“模型”与“业务落地”之间的东西。比如：

• 工具调用怎么定义，参数是否清楚，边界是否明确
• 检索、记忆、上下文压缩怎么配
• Skill 怎么拆，哪些写成规则，哪些写成可执行动作
• 多 Agent 还是单 Agent，什么时候分工，什么时候收口
• 验证、回滚、人工确认这些保险丝装没装
• 监控、权限、配额、日志这些部署细节有没有补齐

模型像发动机，能力层更像传动、刹车、仪表盘和底盘。发动机马力再大，底盘松，车也不敢上高速。

为什么现在大家会集中卡在这里？

因为模型本身其实已经“够用”了。

Anthropic 在讲 agent engineering 的文章里，反复强调一件事：真正跑得好的团队，往往不是一上来就堆复杂框架，而是先用简单、可组合的模式，把流程一步步搭稳。另一边，最近很多开发者在聊 Claude Code 的 loop、advisor、orchestrator，也都在证明同一个现实: 大家现在研究的重点，已经不是“让模型再聪明 5 分”，而是“怎么让它稳定干活 50 次”。

这两件事听起来差不多，实际上差很远。

模型强，意味着它偶尔能给你一个漂亮答案。
能力层稳，意味着它能在第 1 次、第 20 次、第 200 次都按预期推进任务。

企业要买的是后者。

生产环境最常见的 4 个坑

1. 把 Agent 当成“会自己想办法的超强实习生”

这是最常见的误区。

很多团队对 Agent 的期待是：我给你一句目标，你自己拆、自己找资料、自己调工具、自己验证、自己交付。结果做出来发现，它不是不会干，而是每轮干法都不一样。今天能跑通，明天换个输入就歪了。

原因很简单：自由度太高，但约束和接口设计太弱。

Anthropic 对 workflows 和 agents 的区分其实很有启发。很多业务场景，根本不需要一个全自主 Agent，先把它做成 workflow 反而更稳。哪些步骤固定、哪些节点必须校验、哪些动作必须人工确认，先写死，效率通常比“全自动放飞”高得多。

讲得刻薄一点，很多团队不是缺 Agent，而是缺一个老老实实的流程编排器。

2. Skill 写得像说明书，执行起来却像许愿

很多人第一次做 Skill，会忍不住把所有要求都塞进去：语气、格式、步骤、注意事项、边界条件、异常处理，一口气写满几百行。看上去很严谨，实际上常常不好使。

因为纯文字规则本质上还是概率约束，不是确定性约束。

真正能进生产的 Skill，通常有两个特点：

• 文字部分尽量短，只保留判断、取舍、风格这类“需要模型理解”的东西
• 能程序化验证的部分，尽量交给脚本、测试、规则检查器

也就是说，别让模型既当执行者，又当裁判。它写完以后，最好还有一层外部校验兜底。代码能判断的事情，就不要拜托模型“请你认真一点”。

这也是为什么现在越来越多团队开始重视 skill 体系、validator、评审环、子任务拆分这些东西。不是大家突然爱上流程了，而是被线上事故教育过。

3. 工具层接得多，不等于能力强

还有一种很常见的幻觉：我给 Agent 接了 20 个工具，它就更像生产级系统了。

实际上，工具多只是表象，关键在于工具接口是否清楚、命名是否直白、输入输出是否稳定、失败后是否可恢复。

Anthropic 在一篇文章里专门提到，他们做 coding agent 时，甚至花了更多时间优化工具，而不是优化大 Prompt。这个判断我很认同。因为 Agent 真正落地时，最容易出问题的往往不是“它不会想”，而是“它不会正确调用”。

比如一个文件工具到底接收相对路径还是绝对路径，一个搜索工具返回的是原文、摘要还是结构化字段，一个发布工具失败后能不能重试，都会直接影响系统稳定性。

如果你的工作流里还要接生图、生视频、改图这类多模态能力，这个问题会更明显。与其每次单独对接不同模型、不同接口、不同异步返回方式，不如在工具层接一个统一入口。像 iMini 这种聚合式平台，更适合放在能力层里当作标准化工具使用，Agent 只需要学会一种调用方式，后面切模型和扩能力都轻很多。

4. 真正烧钱的地方，已经不是模型，而是部署工程

这个变化最近非常明显。

前几天有篇关于 FDE 的分析很扎眼：AI 公司过去 12 个月里，在前置部署工程上已经砸了接近 97.5 亿美元。背后的逻辑也很直白：GPT、Claude、Gemini 这些模型本身已经足够强，真正难的是把它们安装进企业流程、数据结构、权限体系和组织习惯里。

这就解释了为什么很多 Demo 看起来惊艳，到了生产却迟迟推不动。

因为从 Demo 到生产，中间隔着一整套脏活累活：

• 权限谁批
• 日志谁看
• 失败怎么回滚
• 输出谁验收
• 成本怎么控
• 不同团队怎么复用
• 出了问题算模型错，还是算流程错

这些问题没有一个靠换大模型就能解决。

那应该怎么配，才更像“能上线的 Agent”？

如果让我给一个偏工程化的建议，我会按下面这个顺序来。

第一，先做小闭环，再谈大自治

不要一开始就追求“全自动多 Agent 系统”。先挑一个边界明确、反馈明确、结果可验证的小任务，把闭环跑顺。

比如：

• 收集信息 -> 归纳 -> 生成初稿 -> 人工确认
• 读取需求 -> 修改代码 -> 跑测试 -> 返回 diff
• 检索资料 -> 提取字段 -> 填表 -> 记录日志

先把一个小环打通，比画一张复杂架构图有用得多。

第二，能 workflow 的地方，别硬上 autonomous agent

很多任务其实有稳定流程，就没必要让模型每次“现场发挥”。

固定步骤用 workflow，开放问题再交给 agent；高风险动作加人工确认；关键节点做程序化校验。这样系统会笨一点，但可控很多。生产环境里，可控通常比聪明更值钱。

第三，把“判断”与“验证”拆开

模型负责判断，系统负责验证，这是我觉得最重要的一条。

模型可以负责：

• 任务拆解
• 方案选择
• 信息归纳
• 文本生成

系统最好负责：

• 格式检查
• 权限检查
• 单元测试
• 文件路径校验
• 成本阈值控制
• 是否允许真正执行外部动作

这一步做得越彻底，Agent 越敢上生产。

第四，认真写工具文档，而不是只顾着接工具

一个能用的工具，不只是“API 接好了”，而是模型看完就知道什么时候该用、怎么用、哪里不能用。

参数名尽量直白，输入尽量少歧义，边界情况尽量提前讲明白，最好还有示例。你可以把它理解成：不是在给模型喂接口，而是在给一个新同事写最关键的 docstring。

第五，给系统留出“求助人类”的台阶

很多人做 Agent 时，会把人工介入理解成“不够自动化”。我正好相反，我觉得能在关键节点把问题优雅地抛回给人，反而是成熟系统的标志。

HITL 不是妥协，是风控。

金额高、影响大、不可逆的动作，本来就该有人点头。模型能把 80% 的重复劳动吃掉，已经很值了，剩下那 20% 的判断权，不必逞强。

未来比的不是谁模型更大，而是谁系统更顺

我现在越来越觉得，AI Agent 的竞争会越来越像工业化竞争，而不是单点智力竞赛。

模型当然还会继续进步，但对大多数团队来说，决定成败的变量已经换了：

• 你的上下文管理稳不稳
• 你的 Skill 体系清不清楚
• 你的工具接口好不好用
• 你的验证链够不够硬
• 你的部署工程能不能把能力真正嵌进业务

同样一个模型，放在不同能力层配置里，最后跑出来完全可能是两个物种。

所以如果你最近也在做 Agent，我的建议很简单：先别急着问“要不要换更强模型”，先问一句更要命的。

你的 Agent，到底是在裸奔，还是已经有底盘了？