三天搭完一个 Agent，是这个时代给产品人的礼物，也是陷阱。我复盘了自己两个失败的 Agent 项目，得出一个和主流叙事相反的判断：八成以上的 Agent 停在 demo 阶段，原因不是技术不够强，而是开发太容易，把"想清楚再动手"的环节一起埋掉了。文末附一张动手前的五问自检清单。

三天，我搭出了两个自己相当满意的 Agent。

一个负责把故事变成连环画，一个负责生成旅游方案。步骤全通，流程能跑，我当时的感觉是：这东西真能用。

不对劲来得也快。漫画最先露馅：前一张图里的主角，到后面几张，脸就变了，画风也跟着漂。旅游方案那边，只要问题稍微偏出我预想的那两三个场景，它就开始出错。我开始打补丁，补完这个场景缺那个功能，前前后后补了十几轮。

比 bug 更扎心的是：别人用一下，就不再用了。

这个经历放在今年，格外应景。WAIC 上，智能体的主叙事已经从”能聊天”变成了”数字员工”，台上的演示一个比一个流畅。但台下，多家机构的调研口径不一，方向却一致：八成以上的 Agent 项目停在 demo 阶段，没能进入真实生产环境。

我那两个 Agent，就是这八成里的。

复盘完这次失败，我的判断是：Agent 跑不起来，不是因为它难做，恰恰是因为它太好做了。技术门槛塌下来的时候，把“想清楚再动手”也一起埋了。

一、是模型还不行吗

Agent 跑不起来，最顺手的解释是把锅甩给技术：模型能力不够，幻觉太多，等下一代模型就好了。

这个解释站不住。

斯坦福 AI Index 追踪过一组数字：OSWorld 基准用真实的电脑任务来考验 Agent，2024 年它发布时，最好的模型成功率只有 12%；到今年，这个数字已经涨到 66%。两年翻五倍，能力曲线在陡峭地往上爬，这是肉眼可见的。

但落地的比例没有跟着爬，八成以上的项目依旧趴在 demo 阶段。

一边狂涨，一边趴着，两条线拉出一个越来越大的剪刀差。如果卡住 Agent 的是技术，这两条线应该一起动。它们没有，说明真正的堵点在别处。

（图注：落地率曲线为示意）

还有一个数字值得玩味。Gartner 戳破过一个泡沫：数以千计自称做 AI Agent 的厂商里，真正具备 Agentic 能力的大约只有 130 家，其余大部分是把聊天机器人和 RPA 重新贴了个标签。贴标签的前提，是大家默认 Agent 这块牌子谁都挂得起。台面上的繁荣有水分，但挤掉水分再看，门槛低到人人都觉得自己能做，这件事是真的。

技术这个嫌疑人，可以先放了。

二、三天搭完的东西，省掉了什么

先交代我自己这个案子的全过程。

起点是两个很具体的念头：我想要一个”给它一个故事，它出连环画”的漫画 Agent，和一个生成旅游方案的 Agent。念头出现到两个都搭完，三天。步骤全通，流程能跑，我记得当时的状态是有点上头的：这在以前，得是一个小团队干几周的活。

问题分两批到来。

第一批是能力问题。漫画 Agent 的风格没法保持一致，前一张图里的主角，后面几张脸就变了，画风也跟着漂。这类问题我认，它是模型层面的，我控制不了。

第二批问题才是真正的教训。旅游方案 Agent 在我预想的那两三个场景里跑得不错，但用户的需求不会乖乖待在我的预想里。稍微偏出去一点，它就出错。我开始打补丁：这个场景缺个功能，补上；那个输入会崩，兜住。前前后后补了十几轮。

补到后来我发现一件事：我在用打补丁的方式，做我本来应该在动手之前做完的事——定义场景边界。

而用户没有义务等我补完。功能单一，场景外不可用，别人用一下，就不再用了。

复盘的时候我问自己：需求验证、场景边界、目标用户，这些东西我一个都没做。我是产品经理，这套流程我熟得不能再熟。我不是不会做，而是搭得太快了，快到这些环节被自然跳过了。

想清楚这一点，才看懂问题的结构。

以前开发一个这样的产品，要真金白银的工程师时间。这个成本很讨厌，但它顺便干了一件好事：逼你在动手之前把需求想清楚，因为试错太贵了。”想清楚再动手”从来不是产品经理的美德，它是被开发成本逼出来的纪律。

现在成本塌了。三天出 demo，试错几乎免费，那道逼你想清楚的闸，也就跟着没了。

这不是我一个人的问题。即便在 Agent 时代之前，CB Insights 就统计过，42% 的创业公司失败于同一个原因：构建了没人想要的东西。Anthropic 的创始人手册里，给这个陷阱起了个准确的名字，叫”把构建误当验证”：有一个想法，立刻搭出原型，然后把原型的存在当作需求成立的证据。手册还专门提醒，智能体编程把”有想法”到”有产品”的距离压缩得越短，这个失败率只会越高。

原型能跑，证明的只是它能跑。它证明不了有人需要它。

有人会说：快速试错本身就是验证，补丁循环不就是迭代学习吗？区别在这里：迭代有效的前提，是大方向被验证过，而且用户愿意给你第二次机会。我的补丁两条都不占——方向没验证过，用户也只给了一次机会。它不是迭代，是替被跳过的产品定义还债。

我的 demo 就是这样：它是我热情的证据，不是需求的证据。

三、demo 和生产之间，隔着什么

技术门槛塌了之后，真正拦住 Agent 的是剩下的两道门槛：业务门槛，和工程门槛。我的 Agent 死在第一道，葬在第二道。

业务门槛：你替谁解决什么问题

我的两个 Agent，起点都是我自己的需求：我想看故事变成连环画，我想要旅游方案。这没什么错，几乎所有个人 Agent 都这么开始。

但每个人的工作和生活越来越不一样。我的两三个场景，是我的生活切出来的横截面，换一个人，横截面就完全对不上。我拿自己当了全体用户的样本，而这个样本量是一。

业务门槛问的不是“我需要什么”，而是“除了我，还有谁需要”。这一问在传统产品流程里叫需求验证，是立项前的必答题。到了三天出 demo 的节奏里，它连被问出来的机会都没有。

demo 阶段这道题可以不答，因为唯一的用户就是你自己。想进生产，它是第一道闸。

工程门槛：场景外的世界怎么兜住

第二道门槛更隐蔽，因为 demo 阶段它完全不露面。

demo 演示的是一条铺好的路：输入是干净的，场景是挑过的，路径是我调试过的。我的旅游方案 Agent 在这条路上跑得很漂亮。但真实用户不走铺好的路，他们的输入千奇百怪，需求从四面八方来。每一个我没预想到的输入，都是一次对边界的撞击。

有团队分享过类似的落差：内部演示时任务完成率能到 90%，真实用户用了一周，跌到 40% 以下。我的十几轮补丁，补的就是这 50 个百分点。

工程门槛问的是：场景边界画在哪，边界外的输入怎么办，是优雅拒绝还是硬着头皮胡答，出错了用户怎么兜底。这些问题在传统开发里叫异常处理和边界设计，不新鲜。新鲜的是，Agent 的 demo 好到让人忘了问。

两道门槛，没有一道是技术门槛。它们都是产品和工程的基本功，以前被开发成本逼着做，现在得靠自觉。

四、跑起来的那些，靠的是什么

回头看那些真跑进生产的 Agent，有一个共性值得琢磨。

我的推测是：企业场景会是跑起来的主力。不是因为企业的 Agent 技术更强，而是面向企业交付，你没法跳过产品流程——需求得先被客户确认，场景边界写进合同，验收标准逼你把”什么情况下不能用”提前想清楚。交付压力把那道塌掉的闸，重新立了起来。

这个推测反过来看更有意思：个人搭 Agent，恰恰是全世界约束最少的开发场景。没有客户逼问，没有验收标准，连投资人都没有。所有的闸，都得自己给自己立。

怎么立？我把我这次欠下的作业，整理成了一张清单。下次动手搭任何 Agent 之前，先答五个问题：

1. 除了我，还有谁有这个需求？说得出具体的人，才算数。
2. 他们多久遇到一次？低频的痒，撑不起一个工具。
3. 不解决有多难受？忍一忍就过去的问题，用户也会忍一忍就不用你。
4. 他们现在怎么应对？现有办法够用，你就是在跟”凑合”抢用户，而”凑合”是免费的。
5. 我的场景边界画在哪，边界外怎么办？答不出这题，你的补丁循环已经在路上了。

五个问题，一个都不涉及技术，花不了一个下午。而我那两个三天搭完的 Agent，用十几轮补丁和归零的留存，替我交了这个下午的学费。

那个漫画 Agent 我还留着。偶尔点开跑一次，看主角的脸又变了一副模样，就当是提醒自己：搭得快，从来不是问题；以为快就够了，才是。