Agent执行任务时，假设每一步都是0.9的成功率，10步以后，整体成功率就只有0.35了——漏洞百出的流水线，指望通过大量生产来找出侥幸的合格品。
最讽刺的，他们说："没关系，只要用户的任务跑得足够多，那些被采纳的结果就能告诉我们系统擅长什么，把这些成功案例当showcase就好。"
但，这真的不是拿用户当小白鼠吗？
Agent的尽头是Workflow
仔细分析那些最终被验证成功的Agent路径，更像是大力出奇迹、列出那些本来就存在的Workflow：穷举所有可能路径，找出真正有效的——这本应该是产品设计初期就该做的工作。但崇拜Agent的人偏偏要鄙视Workflow的"局限性"，宁愿消耗海量算力和用户耐心去测试"最佳路径"。
这让我想起了经久不衰的关于产品经理的讨论：
-
古典互联网产品经理：靠洞察和强主观判断构建产品 -
AB测试型产品经理：靠大规模测试下的数据支持
问题来了，AB测试型产品经理诞生于C端大流量产品疯狂增长的移动互联网中后期。抖音调整一个小按钮，前端用户几乎感知不到成本，可以瞬间产生反馈数据。微信视频号调调算法，前端用户最多多划俩视频，用户感知很低。
但啥时候珍贵的B端用户甚至 Prosumer也成了大规模AB测试的"燃料"？
消耗信任比消耗算力更可怕
无论是Agent还是Workflow，高留存一定建立在高可用上。
在当前Agent可用性还远未达标的情况下，就大肆宣传其"通用万能"，结果只能是：
-
用户对技术普遍失望 -
产品和概念快速祛魅 -
获客成本暴涨
无需纠结到底是谁在"拿着锤子找钉子"或者"拿着钉子找锤子"——这一次，被当成实验对象的"钉子"不是没有感知的物品，而是真实的人。人会错误和失败挫伤——当消耗掉了人们对某种产品的热情和好奇，口碑的反噬一定会反映到获客成本上。
你很难想象微信是通过AB测试试出来的。伟大的产品往往来自对用户需求的深刻理解和前瞻洞察。与其把用户当成廉价QA，不如在产品设计阶段多下功夫、而非醉心于高端的技术架构。
毕竟，失去的用户信任，比消耗的算力要昂贵得多。
