你是不是也在做Agent，却总觉得“功能多但不精”？这篇文章讲透通用Agent的五大缺陷，从幻觉难题到场景壁垒，再到资本驱动的泡沫逻辑，帮你看清“挂羊头卖狗肉”的现状，也提供一套垂直Agent的构建思路，适合收藏反复拆读。
最近看了一篇关于Agent比较中肯但略显悲观的文章：《几乎都在挂羊头卖狗肉，AI Agent的泡沫现在到底有多大？》
这篇文章价值较高，整理了多位行业一线实践者对通用 Agent的认知。
正如原文所述，他们以Manus的新产品Wide Research和公司跑路、撤资事件为引，深入探讨了国内外Agent泡沫乱象的现实、背后原因以及未来生存规则。
在与多位偏实践导向的技术专家交流后，我发现他们对AI的认知相当一致。以下是我对其中一些关键观点的进一步解读和拆解。
在深入探讨之前，我们需要清醒认识到：今年Agent的大火，首先应该是模型能力取得了大幅增强，其次才是在这基础之上的tool-use上取得了关键突破。
大模型解决规划与调度问题，Manus类AI产品能爆发的核心原因就是模型能力大幅增强；
工具链解决多模态问题，包括最近很火的MCP、Computer Use其实都算是AI多模态能力的延伸，要的就是解决AI各种“不行”的问题，这里包括了听觉、视觉、触觉等；
所谓的记忆和反馈迭代全部是数据工程的事情，之前一直叫RAG，可能最近还多了个称呼上下文工程。数据工程做得好，也可以有效降低模型幻觉。
记忆体系之前不可行，现在可行的核心原因是模型上下文大大扩展，从现在来看破百万是早晚的事。
综上，Agent能行的原因来源于模型能力增强。
在此之下才工具链的繁华：“从编程到browser-use，再到computer-use，以及随着MCP通用接口普及率的提升，Agent的tool use能力得到增强，能够更高效地从外部获取信息，以及与外部系统进行交互。”
下图会更清晰展示，今年Agent的爆发是由于工具链叠加AI：
只不过，值得一提的是通用Agent使用browser-use、computer-use还是有一些无奈之举，因为很多网站并不提供API。
理想情况是让 Agent 调用受控、可测、可审计的函数（MCP），Computer Use 作为兜底能力。
比如我们之前做的简单实现：《Coze+Claude实现Manus》。
这里就没有使用Computer Use，一来是场景足够单一，二来是就是想验证下AI Code 这种方式（Claude）。
大家可以想象下，当AI编程再强大一点、理解能力更强一点，整个Agent架构可能就闭环了，这可能也是为什么很多巨头都在关注这块的原因：
掌控了AI编程能力，就掌控了智能体能力扩展的“开关”。这不再是做一个应用，而是在打造一个能够生长应用的平台。
这符合OpenAI、Google等巨头“模型吃掉一切”的终极路线图，只不过这里面的安全性问题和实现难度较高，还有很长的路要走…
然后就是很多消极的声音了：
虽然有些不公平，但Manus成了通用Agent的代表，也是主要输出对象…
王显：Manus前阵子刚推出的新功能Wide Research，我觉得非常不具备竞争力，对提高产品竞争力没有什么用。
他进一步的观点就更激烈了：Manus自始至今，从产品角度而言，思路是完全失败的。
在他看来，早期采用浅而宽的策略获客可以理解，但长期无法抵御模型厂商的下沉和垂直厂商的渗透。
大家的观点是比较一致的全部集中在能否解决问题：用户遇到真正复杂的问题时，这个通用Agent还是帮不上忙；当一个Agent宣称能做所有事情时，它往往在任何一个领域都做不到最好；…
上述的观点有些过于激烈，因为通用Agent肯定是一个大的发展方向，只不过暂时表现还不佳罢了。
其中有一句话是尤其关键的：Manus仍然没有解决场景壁垒的问题。
它没有专业数据、没有专属工具链、没有行业认证、没有与业务深度绑定的集成，也没有与高价值业务场景的绑定，也就是任何人都能做。所以，它更偏向工程能力的延伸，而不是在构建场景护城河。
任何人能做就代表实现成本不高，但成本并不高是相对的，就算是垂直领域Agent也会遭遇以下问题：
这也是为什么红杉这么推崇OpenEvidence的原因：
AI应用的竞争已经从技术能力的竞争，转向了产品定义、用户体验打磨、生态整合与垂直行业知识深度的竞争，早期的红利属于在垂直领域做得无比深入的团队。
所以，通用Agent尚不成熟，为什么大家各自追捧？
王显更是认为这场通用Agent泡沫的兴起是创业公司和资本共谋的产物：
“ Manus 根本不是在做产品，而是在走资本路线，通过不断推高市场知名度以获得更高融资。至于创始人是拿到融资后真正深入场景做产品还是卷钱跑路，只有创始人自己才知道。产品非常失败，但营销可以说非常成功。”
张森森表示，“国内很多 Agent 产品功能繁多，但基本都是快速堆叠，痛点不聚焦。”
“比如有大量集成了写文案、做 PPT、查资料、生成图片等功能的产品，不乏大厂参与其中。它们都有通用 Agent 的特点，功能多但不精。写代码准确率不高，数据分析缺少可解释性，设计产出质量参差不齐。初次使用可能觉得新鲜，但要长期依赖则难以实现。很少有明确与工作流、KPI 绑定的可交付结果。”
……
正如各位大佬所言，通用Agent尚不成熟，为什么大家各自追捧呢？
我这里给个真实案例：
前两个月，我一好基友是某公司的高管，他们开发了一个类Manus产品，正在他私下跟我吐槽毫无壁垒、一个月就搞定、幻觉很多的时候，他们老板却表示直接All In！
原因无他，马化腾给他们产品点赞了！你觉得怎么样不重要，资本觉得怎么样很重要，并且正因为成本低，创业公司就更高兴了…
另一方面，我这边AI训练营有个学员刚融资一个亿，他们做的是垂直领域的Agent创业，而就是在那个小的领域，很多Manus遇到的问题，他们几乎全遇到了：“他们的宣传能力与实际能力并不匹配，并非能力完全无用，而是存在明显落差；”“成功演示的往往是任务中那 20% 的标准化部分，而真正构成工作核心的，是那 80% 的、充满‘长尾异常’的复杂现实。”
从这些角度来说，原文章真的很良心…
总而言之，这里我看到的结论是：通用Agent作为既得利益者，他们是绝不会说自己不行的，资本参与者对于他们暂时行不行不大关注，反正他们是最为了解AI的一批人，相较而言，他们比其他人容易成功
接下来开始探讨Agent缺陷的根本原因
这部分的论述我特别认同郭炜的观点：（很多Agent公司）没有真正深入到用户场景中去做。
只不过原因这里我有更多的感受：当前国内创业生存环境极差，以我这边创业为例：3个月拿下了电信审批资质，APP终于可以上线；6个月了算法备案还没下来，所以AI模块一直没上…
不得不说国内创业环境真的很差，这变相加剧了我们对投资的渴望，这会导致我们明知通用Agent不行，但也会投其所好的做一个，很不好意思来说：
我们11月产品里面也会有个Agent，并且我们并不其他他解决太多问题，但在20%我们要求的场景，我们会要求他很好！
这里也不是技术有什么，我们做什么，而是资本关注什么，我们不得不做什么，如果没有基本的资金，那么我们马上就会死…
所以，与其从技术层面找Agent缺陷的根本原因，不如从环境层面看问题：国内创业者因各种原因都太急躁了，根本没办法沉下心来做数据工程！
我之前在公司做AI项目负责人的时候，一周要汇报三次；我的基友已经是CEO了，但每周都要面对几个投资人的“关切”，而这些都是压力…
如果你要问我Agent缺陷的根本原因在哪，我会说需要在每个垂直领域打透，专家Agent出来后，通用Agent带一个意图识别就好。
而这一切从技术实现上来说并不难，主要难在行业KnowHow的梳理和知识结构的沉淀，而一般公司（很多资金流健康的公司也慌）哪有那个耐心资金去耗啊！
我一个管理数字分身的Agent，折腾了一年多，中间因为生存问题断断续续几次了…
综上，Agent的根本缺陷在工程在资本在决心。
原文犀利地指出了通用Agent“挂羊头卖狗肉”的现状，我们结合自身情况 将其根本缺陷归结于工程、资本与决心。但这三大症结的背后，由于实际艰难环境息息相关…
原文太长，我们就不一一拆解了，但有几个点是很重要的：
一、MCP因上下文缺失（知识语境缺少）导致的耗损
不存在一个“万能Agent”硬扛所有，而是通过A2A协议，让多个精通各自领域的垂直Agent协作完成复杂任务。
二、无法根除的“幻觉”难题
通用Agent在用户侧遇冷还有一个原因是他缺少模型的可观测性，在严肃的生产环境中，对应用的准确率要求极高，95%都是不可接受的数字，必须达到99%。
也正是这个原因 AI Workflow 才在企业场景中大行其是，后续“Workflow（工作流）+ Agent”的混合模式会是一种选择，用确定的流程框架，约束不确定的AI决策。
三、过度炒作的多智能体
现阶段单智能体已经可以很多问题，多智能体这种东西，大家听听就好了，不要盲目增加复杂度…
其他如什么上下文长度和模型能力，大家了解下就好…
这里有一个问题：既然通用 Agent 现在不靠谱，那么有没有靠谱的垂直Agent？
作为过去AI医疗从业者来说，被头部 VC 押注并在医生群体里快速破圈的OpenEvidence似乎很受看好。
原因也很简单：他把“智能体”拆解为“行业问题→数据语义→确定性交付”这条最基本的链路，用工程化思维来构建产品。这里用说人话的方式来做下拆解，看看他到底哪里作对了：
一、锁定单一人群
OpenEvidence只服务持有执业资质的医生，不做“万能助手”。
这一步看似放弃了广阔市场，实则精准砍掉了80%的歧义输入和长尾需求，换来高密度的可验证问题场景。
而且这类数据是越来越有用的反馈。
二、强来源与全链路可溯源
OpenEvidence在可溯源，高质量溯源这块做得非常好！
他每个回答都必须带有引用，且来源严格限定于《新英格兰医学杂志》(NEJM)、《美国医学会杂志》(JAMA)等经过同行评审的权威医学证据。
这种设计将模型的“幻觉”压缩到了医生可接受的专业范围内。
三、产品化“证据链”，而非聊天机器人
OpenEvidence的另一个核心在于他基于高质量数据生成的可溯源CoT。
这一特性的核心不是“聊出来”的答案，而是结构化呈现“证据+临床要点”的工作流产品，服务于床旁快速决策这一明确场景。
高质量的数据 + 像专家医生一样的思考方式，大幅度降低了幻觉的可能。四、以工程确定性换取智能边界
从内容合作、证据管线到模型与工作流的全程可观测，持续把“软性智能”嵌进“硬性流程”。
正如团队一再强调的，其核心是 “临床证据→结构化→可追溯”的工程秩序。
总结一句话就是：他们在数据工程基础上建立了完善的飞轮系统，这让他们产品越做越好了。
这种慢慢积累数据持续打磨的方式看上去很笨，实际上却已经跟一般Agent拉开了差距。
综上，与其说OpenEvidence 是一个垂直Agent “会聊天的医生”，不如说他是一个“证据工作流”产品。
它用高度确定性的工作流，兜住了大模型的不确定性，这与我们在前文强调的 “Workflow + Agent”路线完全一致。
当然，这只是一种做法，也许后面其他Agent有更好的做法呢？
本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。