为什么单点 Agent 没人用：三次失败到完整工作流的转折

我们在推广 Agent 的时候，踩过几个坑。写下来，是因为这些坑的顺序本身就是一个故事：不是”从大到小”改进，而是”改错了方向”三次。

坑一：大而全的系统，维护不动

一开始做了一套大而全的系统。功能覆盖了业务的方方面面，听起来很完整。结果两个问题同时出现：

• 维护不动——系统太大，任何一次迭代都要动全身，改一个环节要评估所有关联；
• 改变现有业务流的意愿不强——系统是按我们理解的标准化的，但业务团队不愿意为了一套系统改变他们现有的做法。

大而全的假设是”流程应该长成这样”，但真实业务不是从系统出发的，是从人的日常出发的。系统越完整，离人的日常越远。

坑二：Agent + Skill 单点能力，没人愿意训练

第二次，我们换了个方向：用 Agent 加 Skill 做了一套单点的系统能力——针对某个具体环节做智能处理。想让业务员、商务去训练和使用。

结果：不愿意。

单点能力看起来比大而全轻巧，但它仍然要求人去学、去训、去切换。对业务员来说，这不解决他们完整一天里的任何一段工作——只是一个”额外的东西”。

坑三：单点优化，不温不火

第三次，我们做单点的优化：比如帮他们把询价标准化做了——字段、格式、模板都整理好。

结果：不温不火。功能确实做了，但没有人真正用起来。

回头看，这三个坑有一个共同点：我们一直在给”更好的工具”，而不是”重新设计的流程”。 工具思维问的是”这个环节能不能被优化”，流程思维问的是”人和人之间的一段工作，能不能整体被重新设计”。

转折点：重新设计完整工作流

什么时候开始有使用机会的？

是我们把工作流重新设计之后。 具体说，是把业务员和商务之间的工作流重新梳理，想清楚怎么跟 AI Agent 结合，让整个流程是完整的——从业务员接询价，到商务处理，再到结果回到业务员手上，中间每一步都嵌进 Agent 的能力。

从这个时候开始，大家用的意愿就高了。

更重要的变化在后面：业务团队逐渐开始主动提问题。 觉得哪个环节有问题，会自己提出来要求优化——从被动接受一个工具，变成了参与一条流程的迭代。

单点陷阱：为什么”小”还不够

很多人听到”别做大而全”就以为答案是”做小”。我们的经历说明：小还不够，关键是”小在完整流程上”。

• 单点能力 = 一个环节的智能，但它悬浮在工作流之外，人是可做可不做的；
• 完整工作流 = 一段跨角色协作的重新设计，Agent 是流程的一部分，人不走这条流程就没法完成工作。

判断标准很简单：如果 Agent 从这条流程里拿掉，工作是不是立刻回到原来的做法？ 是的话，它还是个单点工具；不是的话，它已经长在流程里了。

还有一个信号值得注意：当业务员和商务之间的流程被重新设计后，使用是”被迫”的——但恰恰是这个”被迫”，让 Agent 真正进入了工作。 因为完整流程意味着结果必须经过 Agent，不经过就无法继续下一步。单点工具可以不用，完整流程没法绕开。

从”被使用”到”被拥有”

转折后最值得记录的变化，是团队态度的改变：

• 之前：我们推什么，他们看什么，用不用看心情；
• 之后：他们发现流程变顺了，开始主动说哪里还能改。

主动提问题，说明他们已经把这条流程当成自己的了。工具可以不用，但自己参与设计的流程，会想让它更好。

这可能是”采用”最诚实的定义：不是登录数、不是试用次数，而是业务团队开始主动提优化需求。

证据与适用边界

• 这是我们在一个真实业务团队推广 Agent 的第一手经历，属于生产运行中的观察，不是实验室结论。
• 业务场景是业务员与商务之间的询价-处理工作流；不同行业的协作断点不同，但”单点推不动、完整流程才有人用”的判断来自实际反馈。
• 我们仍然相信单点能力有价值——但价值在于成为完整流程里的一个节点，而不是独立存在。
• 大而全系统并非永远错误；它的问题在于没有先经过流程重构就追求规模。

如果你也在推 Agent，可以先读AI 工作流上线前，我先检查四件事了解上线前检查清单，或看匿名询价工作流案例里完整流程怎么设计。关于 Agent 如何从单点走向一段真实工作，见试点设计与评估专题。