这届 Agent，全是草台班子：到底什么 Agent 在产生价值？

公众号名称：叶小钗

作者名称：叶小钗

发布时间：2026-06-29 09:00

今年小龙虾火爆得不行，也把很多老板搞得焦虑得不行，所以现阶段 Agent 已经成为了业内普遍认可的技术范式了。

并且今年又连续出了很多新名词，又把很多想要学习的同学搞得很慌，但如果你真的想去学习或者了解 Agent，可以从下面四个问题出发，可能会更接近本质：

当前常用 Agent 到底解决了哪些问题？
其次，我们在做技术选型的时候，什么时候选 Agent，如何满足老板/客户的挤压和真实的情况，因为老板或者客户并不知道 Agent 的技术详情，他就是要 Agent，这时候该怎么办？
然后，请深层次思考，为什么 Agent 这种架构会出现，难道上述 Agent 解决的问题场景，其他技术路径没有办法吗？
最后就是，Agent 这套技术架构是如何解决哪些问题的，然后由于架构原生问题，又带来了哪些困扰？

比如第一个 Agent 解决了哪些问题？就有点难以下口，我们换个问题来反推这个答案：

首先，当前到底什么 Agent 在被真实使用；
其次，这些 Agent 应该如何做分类；
最后，每个品类 Agent 应该有什么样的标签；

什么 Agent 在被真实使用

首先，我们给真实使用下一个定义：

有用户，这里要分三个阶梯，微量用户、少量用户、大量用户；
有活跃度。整体来说，使用频繁，意思是不会因为好奇用一次就跑路，这里也分三个阶梯，用两次就跑、多次使用、频繁并依赖；
有持续付费，这个分为，没有付费，续订率低，续订率高；

如果按照这个排列组合排下来，他应该是这样的(框架能做出来，但是里面的产品却只能蒙，因为我拿不到真实数据)：

从这张全景图我们可以得到几个重要启示或者结论：

一、不存在通用 Agent

当前跑出来的 Agent 不解决通用问题，反而更专注特定场景下的连续性工作

在 AI 之前，我们面临的实际问题是：流程是固定的（写代码/回客服），但输入是千奇百怪的，传统规则引擎搞不定，纯人工又太贵；

最经典的案例就是群昵称格式统一，如果没有人出现是一定搞不定的，比如要求要求的格式是：昵称-岗位-城市，就一定有人写成昵称-城市-岗位 或者 昵称_岗位_城市 等千奇百怪的格式。

而这东西代码、正则表达式是搞不定的，这是大模型之前一直存在并困扰你我最大的难题。

所以对我来说，在利用 AI 的时候，最核心使用的是其泛化能力，这里 AI 乃至 Agent 最核心要解决的问题就出现了：

我会利用 AI/Agent 的泛化能力去解决_确定性流程中的非确定性应对_

所以暂时就不存在什么贾维斯、万能秘书、万能员工这种东西，现在做得好的都是在特定场景里，把一类任务做深，比如：

Coding Agent： 核心是理解代码上下文；
客服 Agent： 核心是理解用户意图；
法律 Agent： 核心是理解案情事实；
医疗 Agent： 核心是采集患者病情，并辅助分诊、诊断与后续管理；
企业流程 Agent： 核心是理解业务状态，并推动跨角色、跨系统流程流转；

这些 Agent 做的都是**【高密度、低创意、高容错】**的脏活累活，最终达成的成果有两点：

一、解决过程效率问题，解决我们在**【查询-推理-输出】**过程上消磨的时间；

比如过去的理想情况是写代码不需要翻文档、写文章不用查资料、客服不需要看话术和历史聊天记录；

二、解决持续性问题，在有些任务上，7x24小时是有可能的，而之前是不可能的，AI的出现就是要把快的部分变得指数级的快；

在结论一的基础下，第二个结论应运而生：

二、受控的自由

生产级 Agent 对稳定性或者说受控性要求极高

当前跑出来的 Agent 都被强约束，没有解决稳定性和安全性的产品，很难上线，其中最典型案例就是小龙虾 OpenClaw：

所以，Agent 是在有明确边界下的受控智能，也就是让模型在可控范围内处理不确定性，所以这里也可以推出第三个结论：

三、Agent 的价值在于智能

Agent 的价值来源于智能，他受追捧的原因是人的惰性，但被诟病的原因是因为智能所带来的 ReAct 技术架构，他存在着不稳定、效率低、成本高的特点

因为_追求更进一步的泛化能力的正确性/稳定性_而引入的 Agent 架构，成功打开了潘多拉的魔盒，并且他已经成为了被广泛认可的架构了

换句话说，Agent 极大的降低了工程维护复杂度、以及架构设计复杂度，比如我们维护分支爆炸的问题、初期架构设计全面性可以不足的问题（比如工作流有些分支想不到）；

但是，他同样带来了新的工程维护复杂度，包括架构黑盒问题、调试难、观测难等问题；

其次，由于架构带来的不稳定性、效率低、成本高，也需要用更多的工程手段去解决：

上面的说法可能不准确，好一点的说法是：

Agent 并没有降低复杂度，而是把显式代码复杂度转移成了隐式数据与 Prompt 复杂度

以前维护 100 个 if-else 很痛苦，但现在维护一套复杂的 ReAct 循环、Tools 描述和 Few-shot 示例同样会很痛苦。

并且这里痛苦的点还是不一样的：代码 BUG 是确定的，Prompt BUG 是随机的。

然后就是，Agent 架构和 Workflow 并不是冲突的，他们应该融合，也确实是融合了：Workflow 负责确定性主干，Agent 负责不确定性局部。

四、技术选型要看分类

首先，Agent 的成功，非常依赖于场景，如果打开的话是该场景所具备的上下文。

现在很多公司都采购或者部署了数字员工平台类 Agent，比如 WorkBuddy、钉钉悟空、甚至古早的 Coze、DIfy。

但采购并不等于使用，要用好首先受限于员工的能力，其次受限于组织是否进行了 AI 原生的改造，这里属于组织课题，之前有探讨这里不做展开。

但是左右的技术/AI 负责人都可能会面临相同的难题：老板要 Agent，是因为媒体把 Agent 包装成了“无所不能的孙悟空”。

我们这些实际去落地的就不能这么玩，如果一个技术路径选错了，就会很难办。

比如，我最近收到一个企业咨询，他们做 AI 客服居然选的 OpenClaw 去做，最后结果是不稳定、慢、还有点小贵，他问我怎么办？他架构都是错的，这还能怎么办…

这里的策略首先是不能拒绝，其次也不能答应，需要做的是真实的翻译翻译：大多数老板要的根本不是Agent，他要的是：降本提效、少出错、看起来先进可以吹牛。

所以你的任务是把需求重新翻译成工程问题：

第一类，提效已知任务，很可能 API 加 RAG 就够了；
第二类，替代人工操作流，前提是先把 SOP 梳理清楚，至于最后选 Agent 还是其他路径，可以再说；
第三类，高价值专业决策，这种场景最适合Agent，但如前所述，只能给 AI 受控的自由；

至此，我们最初前三个问题大概就已经被解答过了（图可以横向滑动）：

<<< 左右滑动见更多 >>>

在这个基础下，我们再次回归思考一个问题：为什么Agent会出现？

为什么 Agent 会出现？

首先，模型当前虽然很强大，但他是天生缺陷的，他本身只包含了训练后的内置数据，这里就产生了第一个矛盾点：

当前社会信息爆炸太严重，一个星期就可以发生很多事，模型首先不可能跟得上这个节奏；其次他也不会去跟这些节奏，因为互联网上多数数据是垃圾，模型不可能去吃这些垃圾，垃圾吃多了会影响智商的；
除了市面上的信息，各个企业还有很多自己私有的数据，这些数据全部需要跟模型交互，否则在公司场景下模型的意义就不大了；

所以，Agent出现的第一个原因是，他至少需要与外部世界进行信息交流，尤其是一些垂直领域，如果数据不足，模型很容易胡言乱语的。

然后就是第二个原因，也是我们前面说的问题了：我们的产品难以应付用户无限的意图，这里比较抽象，我们再举个例子：

工作流打开就是if else，或者各种规则引擎，他能干什么，他能很好的解决：已知输入、已知分支。比如：

用户问退款，订单已发货，走 A 流程；
用户问退款，订单未发货，走 B 流程；
用户问发票，走 C 流程。

这套东西很稳，也很便宜。但问题是，真实用户不是这么说话的。用户可能会说：

我昨天买的那个东西还没收到，我不想要了
你们能不能处理下？

这句话里有退款、有物流、有订单，还有可能涉及赔偿。传统规则引擎去做，就要提前把所有表达、状态、组合情况都穷举出来。于是问题来了：

业务分支是有限的，但用户表达是无限的

这就是规则引擎的边界，也是传统编程的能力边界，他做最核心逻辑还行，如果都想提前写好，维护成本很高的。

我这边真实案例就是，之前一个兄弟，他们是做客服的，最后那个Workflow流程自己都维护不动了：

当环境复杂度上升，Workflow 的成本曲线会很难看：

在这个场景下 Agent 的泛化能力就出来了：先做意图识别，再做步骤规划，生成这次要的 Workflow，这里因为要保证 Workflow 的正确性所以会有很多模型的自我质疑，最终生成他认为对的工作流：

至于这个工作流是不是真的对，就不好说了，虽然已经加了很多循环验证了：

这里再加一句：

Agent 解决的不是怎么回答的问题，而是给出了一套将问题编译为可执行计划的框架，甚至于你把 Agent 这套架构本身理解为一套 Workflow 也是可以的

他是一套用于生成工作流的工作流，这个也是一套现阶段验证出来，很不错的范式

最后再总结一下：相较于 Workflow，Agent 架构是一种工程架构层面的优化：

他把一部分原本由工程师在开发期显式写死的控制流（if/else、编排），迁移到运行时由模型来决定（路由、工作流程）

他是用更多的成本（多轮推理 + 多次工具调用 + 更高延迟/Token），换开发与维护成本的下降（分支更少、扩展更快、长尾更适配）

结语

所以，Agent 没那么玄乎，他又不是孙悟空…

它本质上干的事就一件：把程序员写死在代码里的 if-else，挪到了运行时让模型现挂。用 AI 的泛化能力去解决确定流程里的不确定部分。

当然，代价也是明显的：代码 Bug 是确定的，Prompt Bug 是随机的。

以前维护 100 个分支头疼，现在维护一套 ReAct 循环加几十个工具描述，去构造那套可观测性日志系统，一样掉头发，只是疼法不同。

所以，其中优劣大家自己下去感受吧，毕竟 Agent 跟 Workflow 又不是互斥的。

内容效果不满意？点此反馈