AI Agent 落地：从演示到干活的最后一百米

最近跟几个在做 AI Agent 的朋友聊了一圈，发现一个挺有意思的现象。

大家都在做 Agent。有人用 LangGraph 搭多 Agent 流程，有人自己写编排框架，有人在 MCP 协议上做工具集成。论技术方案，一个比一个花哨。

但聊到”这东西真的在生产环境跑起来了吗”，大部分人沉默了。

不是不能用。是今天跑得好好的，明天换了个输入，就崩了。

这让我想起之前看到的一句话：AI Agent 的演示能力远超它的落地能力。你给任何人演示一个 Agent 自动写代码、自动排日程、自动填表单，大家都觉得太酷了。但真把它丢到生产环境，让它连续跑一周不出事——那是另一个故事。

第一个坑：错误会滚雪球#

LLM 单次调用的准确率，头部模型大概能做到八九成。听着还行。

但 Agent 不是单次调用。它要先把任务拆成步骤，每步调工具，看完结果再决定下一步。三步下来，就算每步都九成准，整体成功率已经掉到七成出头了。五步？六成都悬。

我不是在搞数学题。问题是实际场景里，错误不互相对冲，它们互相放大。第一步解析错了，后面跟着全是白忙活，更糟的是——基于错误数据推出来的结论，看起来还挺合理。

Claude Code 的文档里提到过这个。简单任务没问题，多步推理就崩。他们的解法是上重试、上沙箱、加手动确认。说白了是用工程手段兜底，不是让模型本身变靠谱。

我理解这么做是对的，但也说明一件事：目前的 Agent 能干活，前提是你得在周围焊一圈护栏。

Agent 真的有用，前提是它能操作真实工具。查库、调接口、改配置、发消息，这些才是价值。

但每接一个工具，你就得给 Agent 写一份说明书。

MCP 解决了协议层面的标准化——输入输出格式统一了。但有个更头疼的问题没解决：Agent 怎么知道什么场景该用什么工具？

钉钉的 CLI 有三十几个命令，飞书的只多不少。你把所有命令都注册成 MCP tool，Agent 的上下文窗口被吃掉一大半。你不全注册，它又可能挠头半天找不到对的工具。

而且工具之间有依赖。得先查用户信息才能发消息，先鉴权才能调 API。这些流程知识，现在全靠 Agent 自己在上下文中推理。推理就会出错，尤其在工具数量超过五六个的时候。

有个朋友的做法很实在——他写了一份很厚的 Skill 文档，把常用场景的步骤、参数、异常处理全写进去，管它叫”Agent 的入职培训手册”。效果确实好了不少。代价是文档维护成本很高，工具一升级就得跟着改。

但我觉得这个方向是对的。让 Agent 自己靠推理来摸索工具用法，就像让新来的实习生自己看 API 文档干活——能用，但别指望效率。不如把那些”老员工才知道的经验”直接写成手册。

这个说起来有点虚，但实际很要命。

传统软件是确定的。输 A 得 B，一百次一样。你可以建监控、设告警、写自动化测试。

Agent 不是。同一个输入，这次输出 B，下次输出 C。不是 bug，是 LLM 天生有随机性。temperature 设成 0 也救不了——prompt 措辞不一样、上下文长度不一样、甚至 token 位置变了，结果都可能不同。

你让运维团队去给一个不确定的系统开”自动执行”？没人敢点那个按钮。

所以现在大多落地的 Agent 都带人工确认环节。Agent 干完活，生成执行计划，等人点确认。但这样一来，Agent 的生产力又被人的带宽卡住了——本想让机器 24 小时跑，结果还是要等人上班。

我不是在唱衰。恰恰相反，我挺看好这个方向的。但”能演示”到”能干活”之间的距离，比很多人愿意承认的要长。

有件事让我比较乐观。

DeepSeek V4 的缓存定价让单次调用成本降得很低。这意味着 Agent 可以设计更多的”试错——重试”循环，而不必心疼钱。错误多了虽然吃点 token，但总比流程卡死好。

另外，Skill 文档那个方向我确实看好。把流程知识从模型推理里剥离出来，写进结构化文档，让 Agent 照着做。维护成本是高，但比起让 Agent 自己瞎猜，这是务实的选择。

那些真正在生产环境跑起来的 Agent，没有一个是真的完全无人值守的。它们的共同点很朴素：Agent 做 80% 的重复劳动，剩下的交给人来判断。听起来不够酷，但能一直跑。

最后说一句。

Agent 的 demo 让人相信未来已来。但让它真正落地，你得承认未来还没完全来，然后在这个前提下干活。

承认它会犯错，所以留后路。承认它会迷路，所以把路书写清楚。至于靠不靠得住——留一道人闸，让有判断的人兜底。

这些都不性感。但这是把东西真正做起来的唯一路子。

参考：