马化腾点赞的AI Agent：繁荣还是泡沫？深度剖析通用Agent的技术困境与资本博弈
近期，一篇题为《几乎都在挂羊头卖狗肉，AI Agent的泡沫现在到底有多大？》的文章，以中肯但略带悲观的角度探讨了AI Agent的现状，引发了广泛讨论。该文章具有较高的参考价值，它系统梳理了多位行业一线实践者对通用Agent的认知与看法。
正如原文所指出的，作者以Manus的新产品Wide Research及其公司跑路、撤资事件作为切入点，深入剖析了国内外Agent领域泡沫化乱象的具体表现、背后的驱动因素以及未来的生存法则。在与多位偏向实践导向的技术专家交流后，我发现他们对AI发展的认知呈现出高度的一致性。以下是我对这些关键观点进行的进一步解读与拆解。
类Manus产品崛起的背后原因
在深入分析之前，我们必须清醒地认识到：今年Agent概念的爆火，首要原因在于大模型的基础能力取得了显著提升，其次才是在此基础上工具调用（tool-use）方面取得的关键性突破。
大模型主要负责解决任务规划与调度问题，因此，类Manus的AI产品能够爆发的核心驱动力正是模型能力的跨越式增强。 工具链则致力于解决多模态交互问题，包括近期备受关注的MCP（Model Context Protocol）和Computer Use，本质上都是AI多模态能力的延伸，旨在攻克AI在听觉、视觉、触觉等领域的各种“能力短板”。
而通常所说的记忆与反馈迭代机制，则完全属于数据工程的范畴。这类技术过去常被称为RAG（检索增强生成），近期或许又多了一个称谓——上下文工程。优秀的数据工程能够有效减轻模型的幻觉问题。记忆体系过去难以实现，如今变得可行的根本原因在于模型上下文长度得到了极大扩展，从当前趋势看，突破百万上下文长度指日可待。
综上所述，Agent得以发展的根本源泉在于模型底层能力的增强。 在此基础之上，才催生了工具链的繁荣景象：“从编程接口到浏览器使用（browser-use），再到计算机操作（computer-use），随着MCP这类通用接口普及率的提高，Agent的工具调用能力不断增强，使其能够更高效地从外部获取信息并与各类系统进行交互。”
下图可以更清晰地展示，今年Agent的爆发实质上是工具链能力与AI模型能力叠加的结果：
不过，需要指出的是，通用Agent依赖于browser-use或computer-use，在某种程度上是一种无奈之举，因为许多网站并未提供标准的API接口。
XX-use未必是最优解决方案
理想情况下，我们应优先让Agent调用那些受控、可测试、可审计的标准化函数（例如通过MCP），而将Computer Use仅作为兜底的备用能力。
例如，我们团队此前进行过一个简单的实践验证：《Coze+Claude实现Manus》。在这个尝试中，我们并未使用Computer Use，一方面因为应用场景足够聚焦和单一，另一方面也是希望验证基于AI编程（利用Claude模型生成代码）这种方式的可行性。
大家可以设想，当AI编程能力变得更加强大、模型的理解能力进一步提升时，整个Agent的架构或许就能形成闭环。这很可能解释了为何许多科技巨头都在密切关注这一领域：谁掌握了AI编程能力，谁就掌控了智能体能力扩展的“总开关”。这不再是简单地开发一个应用程序，而是在构建一个能够自主生长和演化应用的底层平台。
这契合了OpenAI、Google等行业巨头“让模型吞噬一切”的终极路线图。然而，这条道路上的安全性问题与实现难度极高，仍有漫长的征程需要跋涉。
与此同时，业界也涌现出许多消极的评判声音。
行业内的消极声音
尽管这可能不够公平，但Manus已然成为通用Agent的典型代表，也成为了主要的批评对象。
从业者王显指出：“Manus前阵子刚推出的新功能Wide Research，我认为其竞争力非常弱，对提升产品核心竞争力几乎没有助益。” 他的后续观点更为尖锐：“Manus从创立至今，从产品设计的思路来看，是完全失败的。” 在他看来，早期采用广泛而浅层的策略获取用户尚可理解，但长期而言，这种模式无法抵御大型模型厂商的业务下沉以及垂直领域专业厂商的渗透侵蚀。
行业的观点比较一致地聚焦于 “能否真正解决实际问题” ：
- 当用户面临真正复杂、棘手的现实问题时，这类通用Agent往往仍然无能为力；
- 当一个Agent宣称自己能够处理所有事务时，它在任何一个特定领域通常都无法做到极致；
- ……
上述观点或许有些过于激烈，因为通用Agent无疑代表着一个重要的技术发展方向，只是当前的表现尚未达到预期。
其中有一句评论尤为关键：“Manus仍然未能解决场景壁垒的构建问题。” 它缺乏专业的领域数据、专属的工具链、行业认可的认证、与具体业务的深度绑定集成，也没有切入高价值的业务场景，简而言之，任何人都可以模仿实现。因此，它更偏向于工程能力的横向扩展，而非在构建深厚的场景护城河。
任何人都能实现，意味着其构建成本相对不高。但 “成本不高”是相对的，即便是垂直领域的Agent也会遭遇以下共性挑战：
- 精准的意图识别：用户的需求常常是模糊且充满歧义的。智能体必须理解用户的“言外之意”，这是提升用户体验的关键门槛，需要极其精细的提示工程（Prompt Engineering） 和大量高质量的对话数据进行调优。
- 强大的工具生态：智能体的能力边界由其能够调用的工具决定。一个“类Manus”产品能否真正解决问题，取决于它能否高效使用各类服务（如预订票务、查询邮件、控制智能家居、分析数据等）。自建工具链成本高昂，因此，与第三方服务的集成能力变得至关重要。
- 深厚的领域知识：在垂直领域，通用知识远远不够。必须将行业的SOP（标准作业程序）、私有数据库、专家经验等注入到智能体中。这部分工作是繁琐且需要深耕的“脏活累活”，没有捷径可走，但正是构建竞争壁垒的核心所在。
这也正是红杉资本等机构高度推崇OpenEvidence的原因：AI应用的竞争重点，已经从纯粹的技术能力比拼，转向了产品定义、用户体验打磨、生态整合以及垂直行业知识深度的竞争。早期的市场红利，属于那些在垂直领域做得无比深入、构建了坚实壁垒的团队。
既然如此，通用Agent尚不成熟，为何仍能吸引众多追捧者？
资本追捧与市场期待
王显甚至认为，这场通用Agent泡沫的兴起，是创业公司与资本市场共同推动的产物：
“Manus根本不是在认真打磨产品，而是在执行一套资本运作的路线，通过持续推高市场声量以获得更高额的融资。至于创始人在获得融资后，是真正深入场景做产品，还是卷款跑路，只有创始人自己清楚。从产品角度看非常失败，但从营销角度看却可以说非常成功。”
另一位从业者张森森表示：“国内很多Agent产品功能堆砌繁多，但基本都属于快速拼凑，痛点把握不够聚焦。” “例如，大量集成了文案撰写、PPT制作、资料查询、图片生成等功能的产品层出不穷，其中不乏大厂参与。它们都具有通用Agent的特点：功能广泛但都不精通。写代码准确率不高，数据分析缺乏可解释性，设计产出质量参差不齐。初次使用或许能带来新鲜感，但若想长期依赖则难以实现。它们很少能产出明确与工作流、KPI绑定的、可交付的确定结果。”
……正如各位业内人士所言，通用Agent确实尚不成熟，那么大家追捧的原因何在？这里提供一个真实案例：前两个月，我的一位担任某公司高管的好友，他们公司开发了一款类Manus产品。正当他私下向我吐槽产品毫无壁垒、一个月就匆忙上线、幻觉问题严重时，他们的老板却果断决定All In投入！原因无他，仅仅因为 马化腾为他们的产品点了赞！ 你觉得产品怎么样并不重要，资本市场的看法才至关重要。并且，正因为这类产品构建成本相对较低，创业公司就更乐意投身其中。
另一方面，我所在的一个AI训练营中，有位学员刚刚成功融资一亿元，他们从事的是垂直领域的Agent创业。即便在那个看似细分的领域，许多Manus遇到的问题，他们几乎全都遭遇了：
- “产品的宣传能力与实际交付能力之间存在显著落差，并非能力完全无用，而是存在明显的期望差距；”
- “成功演示的往往是任务中那20%的标准化、流程化部分，而真正构成工作核心的，是那80%的、充满各种‘长尾异常’和复杂多变的现实状况。”
从这些角度来看，原始文章的分析确实非常客观和深入。
总而言之，我从中得出的结论是：作为既得利益者，通用Agent的推崇者们绝不会主动承认自身的不足；而资本的参与者对于它们暂时是否真的‘可行’并不十分关注，反正他们自认为是最了解AI趋势的一批人，相比其他赛道，他们在这个领域取得成功的概率似乎更高。
接下来，我们将开始探讨Agent存在缺陷的根本性原因。
Agent缺陷的深层根源
对于这部分论述，我特别认同郭炜的观点：“很多Agent公司并没有真正沉下心来，深入到具体的用户场景中去进行深耕。”
不过，对于其原因，我有更深的感触：当前国内的创业生存环境异常严峻，以我自身的创业经历为例：
- 耗时3个月才拿下电信业务经营许可证，使得APP终于得以正式上线；
- 历时6个月，算法备案至今尚未完成，导致核心的AI功能模块一直无法开放；
- ……；
不得不说，国内针对创新型AI业务的创业环境确实存在诸多挑战，这在客观上加剧了创业者们对 “快速获得投资”的渴望。这导致了一个现象：即使我们明知通用Agent目前存在诸多问题，但为了迎合资本市场的偏好，也不得不投入资源做一个类似的产品。很坦诚地说：我们计划在11月发布的产品中也会包含一个Agent模块，并且我们并不指望它解决所有问题，但在那20%我们精心设计并要求的核心场景中，我们会竭力确保它表现优异！
这并非完全由技术逻辑驱动，而是资本关注什么，我们有时不得不做什么。如果没有基本的资金流入作为支撑，创业项目可能很快就会面临生存危机。
因此，与其单纯从技术层面探寻Agent缺陷的根源，不如从环境层面审视问题：由于各种现实压力，国内创业者普遍显得过于急躁，很难真正沉下心来，投入必要的时间和资源去深耕数据工程等基础建设！
我此前在公司担任AI项目负责人时，每周需要进行三次进度汇报；我的那位CEO好友，尽管已是一家公司的掌舵者，每周仍需应对多位投资人的频繁“关切”。这些都是巨大的现实压力。
如果你要问我Agent缺陷的根本原因在哪里，我认为答案是 “需要在每一个垂直领域做深做透，当各个领域的专家级Agent成熟后，通用Agent或许只需承担一个初步的意图识别和分发角色即可。” 从技术实现层面来看，这并不算特别困难，主要的难点在于对行业专业知识（Know-How）的系统性梳理和知识结构的长期沉淀。然而，对于大多数公司而言（甚至许多资金流健康的公司也充满焦虑），哪里有那么充足的耐心和资金去进行这场持久战呢？
我个人负责的一个管理数字分身的Agent项目，断断续续折腾了一年多，期间因为生存压力问题几次被迫中断……
综上所述，Agent的根本缺陷在于工程化实施的难度、资本市场的短期逐利性以及创业者缺乏长期投入的决心。
通用Agent面临的五大鸿沟
原文犀利地指出了通用Agent“挂羊头卖狗肉”的现状，我们结合自身观察，将其根本缺陷归结于工程、资本与决心三大症结。但这三大症结的背后，与异常艰难的创业实操环境息息相关……
原文篇幅较长，我们不一一点评，但其中有几个核心要点非常重要：
一、 因上下文缺失（缺乏特定知识语境）导致的MCP协议效能耗损
不存在一个能够“包打天下”的万能Agent。更可行的路径是通过Agent-to-Agent（A2A）协作协议，让多个精通各自领域的垂直Agent相互配合，共同完成复杂的综合性任务。
二、 无法根除的“模型幻觉”难题
通用Agent在用户侧遇冷的另一个关键原因，是它普遍缺乏模型决策过程的透明性与可观测性。在严肃的生产环境中，对AI应用输出的准确率要求极高，95%的准确率往往是不可接受的，必须达到99%甚至更高。
正是基于这个原因，可预测、可控制的AI Workflow（工作流）才在企业级场景中广泛流行。未来，“Workflow（工作流）+ Agent”的混合模式可能会成为一种主流选择，即用确定性的流程框架，去约束和引导不确定性较高的AI自主决策。
三、 被过度炒作的多智能体（Multi-Agent）概念
在现阶段，设计良好的单智能体已经能够解决相当多的问题。多智能体协作这类概念，大家保持关注即可，切勿盲目增加系统复杂度，为了“多智能体”而“多智能体”……
其他诸如上下文长度与模型能力平衡等问题，大家有所了解即可，此处不再赘述。
结语：垂直Agent的可行路径
这里引出一个关键问题：既然通用Agent目前尚不靠谱，那么是否存在相对靠谱的垂直领域Agent呢？
作为一名曾经的AI医疗领域从业者，我认为被头部风险投资机构押注并在医生群体中快速获得认可的OpenEvidence，似乎是一个值得关注的正面案例。
原因很简单：它成功地将“智能体”拆解为“明确的行业问题→结构化的数据语义→确定性的结果交付”这一基本链路，用高度工程化的思维来构建产品。下面我们用更通俗的语言来拆解一下，看看它究竟做对了哪些事情：
一、 精准锁定单一用户群体
OpenEvidence只服务于持有执业资质的医生，坚决不做“万能助手”。这一步看似主动放弃了广阔的大众市场，实则精准地过滤掉了约80%的歧义性输入和难以处理的长尾需求，从而换来了高密度、可清晰定义和验证的专业问题场景。而且，服务这类专业用户所积累的数据反馈，价值会越来越高。
二、 强调信息来源与全链路可追溯性
OpenEvidence在信息的可追溯性和高质量溯源方面做得非常出色！它的每一个回答都必须附带引用，且来源严格限定于《新英格兰医学杂志》(NEJM)、《美国医学会杂志》(JAMA)等经过同行严格评审的权威医学文献。这种设计将大模型产生“幻觉”的可能性压缩到了医生专业判断可接受的范围之内。
三、 产品化“证据链”，而非打造聊天机器人
OpenEvidence的另一个核心在于其基于高质量数据生成的可溯源的思维链（Chain-of-Thought）。这一特性的核心价值不是“聊天聊出来”的答案，而是结构化呈现“证据+临床决策要点”的工作流产品，它明确服务于床旁快速辅助决策这一具体场景。高质量的数据输入与模拟专家医生的推理方式，极大地降低了模型产生幻觉的可能性。
四、 以工程化的确定性换取智能的可靠边界
从权威内容合作、证据处理管线，到模型推理与工作流的全程可观测、可干预，团队持续将“软性的智能”嵌入到“硬性的、确定的流程”之中。正如其团队一再强调的，其产品的核心竞争力在于构建了一套“临床证据→结构化处理→可追溯呈现”的工程化秩序。
总结来说就是：他们在坚实的数据工程基础上，构建了一套完整的、能够自我强化的飞轮系统，这使得他们的产品得以持续改进，越做越好。 这种看似笨拙、需要慢慢积累数据和持续打磨的方式，实际上已经与大多数追求快速功能的通用Agent拉开了显著的差距。
核心总结
综上，与其说OpenEvidence是一个垂直领域的Agent “一个会聊天的医生” ，不如说它是一个高度专业化的 “临床证据决策支持工作流” 产品。它用高度确定性的工程化工作流，有效兜底了大模型内在的不确定性，这与我们在前文强调的“Workflow + Agent”混合路线完全契合。
当然，OpenEvidence的成功路径只是其中一种可行的模式。未来，或许其他领域的Agent能够探索出更优、更具创新性的实践方法。