本文来自微信公众号： 叶小钗 ，作者：叶小钗，原文标题：《这届 Agent，全是草台班子：到底什么 Agent 在产生价值？》
今年小龙虾火爆得不行，也把很多老板搞得焦虑得不行，所以现阶段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是在有明确边界下的受控智能，也就是让模型在可控范围内处理不确定性，所以这里也可以推出第三个结论：
三、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又不是互斥的。