Z Research｜我们距离Agent的DeepSeek时刻还有多远（AI Agent 系列二）

（一）AI Agent中的白马非马

我们拆解AI Agent的运作流程，包括感知层、决策层和执行层。接着引入“白马非马”之问，通过AI Agent九宫格分析市场中不同公司所谓的Agent类型，指出需辨别真正有潜力的公司与概念炒作者。同时对比了OpenAI的“纯粹Agent”路线与LangChain的“混合架构”路线，阐述两者在系统设计、开发门槛、可靠性挑战及适用场景上的差异。

（二）从技术栈初探AI Agent进化方向

LLM层面，当前SOTA模型已将工具调用能力内化，我们分析了Agentic能力内化的必然性，下一世代的LLM将自主获取经验成为新燃料。我们还分析了OpenAI的o4-mini和Anthropic的Claude 4在Agentic能力设计思路上的差异，分别代表“隐形智能”和“可编程智能”两种路线，指出未来Agent竞争是“体验普惠”与“深度可靠”的角力，混合架构可能成为下一阶段共性选择。

工程整合对模型能力的贡献开始增加，如Manus揭示的Prompt Engineering在Agent产品发挥的巨大潜力。长程任务与记忆机制方面，持久化执行突破传统模型任务时长限制，外挂记忆模块实现跨任务状态保留。

我们复盘了MCP和A2A对于Agent协议标准化的影响，我们认为，未来的标准统一是生态繁荣的必然，未来我们可以看到Tools层面更多激进大胆的工程尝试。

（三）Multi-Agent已成为必然

指出Single-Agent存在局限性，如Memory上下文窗口与长期记忆问题、Tools复杂任务调用工具达到新数量级、React框架局限性引入Reflextion。

相比之下，Multi-Agent的分布式协作架构在复杂性、鲁棒性及扩展性上有优势，如多方案探索与竞争进化、人类协作适配性。具体阐述了Multi-Agent如何缓解Agent的Memory问题，以及在工具调用层面的优势。

我们还介绍Multi-Agent系统中六种核心架构模式，并分析了当前技术趋势，指出目前Multi-Agent框架处于“春秋战国”式的割据状态，市场中主流AI玩家普遍推出自身框架，但还缺乏竞争收敛的催化剂。

（四）我们与AI Agent中的 DeepSeek时刻的距离

朱啸虎认为所有AI应用都是套壳应用，我们认为Yes and No。

Yes部分是“套壳”现象普遍，技术同质化严重，场景创新不等于技术壁垒，但“苦活累活”可以产生短期差异化，如数据工程和系统集成成本高昂。No的部分认为，从长期看，“苦活累活”有被自动化重构、自优化Agent涌现而淹没的风险，只有更好的工程创新能留下来。

最后，我们以LangChain的Agent报告指出当前用户Agent使用体验的核心卡点结尾。尽管仍有很长距离，但我们相信未来12-24个月内有望看到AI Agent发展的惊喜，整体还在稳步前行。

获取完整报告可私信公众号后台：Z Research

AI Agent 的“白马非马”

开宗明义，概念先行。首先，我们再次回顾一下我们对于AI Agent的定义。

广义上，Agent是一种能够感知环境、进行自主决策并采取行动的智能实体。它突破了传统工具的被动性，具备了一定的自主性和能动性。

在狭义上，Agent以大语言模型（LLM）为核心，融合了规划、记忆和工具调用能力，能够执行各种复杂任务。

那么进一步的拆解AI Agent的运作流程，这是理解其如何完成任务的核心。

（1）感知层，包含的环节有LLM和RAG，以上环节负责收集和处理来自环境的信息，类似于人类的感官系统。

（2）决策层，包含的环节有Memory和Planning，这是Agent的决策中枢。Memory用于集成更好的记忆上下文以便最佳决策，（包括短期记忆和长期记忆，保持多轮对话的连贯性和沉淀用户数据）。Planning用于将任务目标拆解成可以实施的子步骤，这里的决策核心是利用LLM进行推理和决策。

（3）执行层则负责将决策转化为实际的操作，包含的环节有Tools，比如调用工具、执行代码或进行物理交互。

为了更直观地理解，上图呈现了单次AI Agent运作的全流程示意图。这个示意图展示了从感知到行动的完整路径，以及各个组件之间的交互关系。通过这个技术栈，Agent能够实现从简单的任务到复杂工作的自动化处理，展现出巨大的应用潜力。

笔者深知，我们对于Agent的定义从来不是市场的唯一解。但在纷繁复杂的市场噪声之下，我们试图最大化的凝聚共识。

有了上面对Agent定义的正本清源，我们就可以进一步展开Agent的“白马非马”之问：当市场大量公司都声称自己在做Agent时，他们到底在做些什么？

现在我们来探讨AI Agent九宫格，这有助于我们更好地理解Agent的多样性和应用场景。

从形式上看，AI Agent可以分为三种类型：形式纯粹、形式中立和形式自由。形式纯粹的Agent主要依赖LLM完全自主进行规划和执行，这种方式强调模型的自主性和智能涌现。形式中立的Agent则是由人类定义workflow，然后由机器来执行，这种方式在一定程度上结合了人类的逻辑和机器的效率。形式自由的Agent则更进一步，将人工与人工智能相结合，甚至认为人工也是人工智能的一部分，这种观点拓展了我们对Agent的理解。

从内容上来说，AI Agent也呈现出不同的特点。能力泛化的AI通用Agent，类似于跨国IT人力众包平台，能够处理各种通用任务，成本相对较低。垂类场景的AI代理则专注于特定领域，如代码开发领域的Copilot，为企业数字化转型提供辅助。内容自由的AI代理自定义平台则更加强调减少人工干预，如Cursor变体等工具，允许用户根据自身需求定制Agent的功能。

在将市场相对熟知的AI公司代入到我们的Agent光谱之中后，我们最大的Takeaway是：在鱼龙混杂，噪声巨大的今天，我们需要分清哪些是真正具备想象空间的公司？哪些是以Agent概念炒作的公司？

在市场分歧中，我们对于Agent定义的争议也不是孤例。从海外的LangChain VS OpenAI来看，更可以深刻体现AI Agent的形态之争。

（一）核心争议点：Agent的本质定义

1、OpenAI的“纯粹Agent”路线

（1）定义：Agent是“能代表用户独立完成任务”的系统，由LLM动态驱动决策，自主规划工具调用和工作流，无需预设代码路径。

（2）典型场景：如OpenAI的Deep Research项目，模型自主规划研究步骤并调用工具，无需人工编排复杂流程。

（3）核心理念：随着模型能力提升（如GPT-4→GPT-5），系统应减少人工规则，增加模型自主权

2、LangChain的“混合架构”路线

（1）批判焦点：批判焦点：OpenAI的定义过于“二元对立”，忽视现实系统的复杂性。LangChain创始人Harrison Chase指出：生产级系统本质是Workflow（工作流）与Agent的混合体（"Agentic系统"）。

（2）定义扩展：

Workflow：预定义代码路径，确定性高，适合简单任务（如文档问答）

Agent：由LLM动态决策，灵活性高，适合复杂场景（如多工具协作）

（3）核心理念：框架应支持从结构化工作流到模型自主的渐进过渡，而非非此即彼。

（二）技术路线对比：模型中心主义vs 工程控制主义

OpenAI路线：若模型能力持续突破，将推动高度自主Agent普及

LangChain路线：为当前模型局限性提供工程解决方案，尤其适合企业级高可靠需求场景

从技术栈初探AI Agent进化方向

OpenAI的o3、o4-mini与Anthropic的Claude 4（Opus 4/Sonnet 4）代表了当前AI Agentic能力内化的前沿，目前SOTA模型已将工具调用能力内化，并衍生出新的进化方向：

1、Agentic能力内化成为LLM进化的必由之路

传统预训练遭遇数据瓶颈（Ilya Sutskever称互联网数据如“化石燃料”），而自主获取经验（Online Learning） 成为新燃料；Claude 4连续7小时任务、o3自动学习YouTube字幕等案例，验证了环境交互式学习的必要性。

2、工程整合对模型能力的贡献量开始ramp up

o3与Claude 4均未突破底层架构（依赖RL微调与混合训练），但通过工具链工程化（如Codex CLI、沙箱环境）实现体验跃迁。

3、工具链深度内化

（1）端到端工具调用：均将工具使用能力（搜索、代码执行、图像操作）融入模型推理链：

o3通过CoT（思维链）自动生成代码调用工具（如裁剪图片、爬取网页），无需预设API；

Claude 4通过RLVR（可验证奖励强化学习） 优化工具调用逻辑，确保代码执行结果可验证（如SWE-bench代码修复准确率80.2%）。

（2）多模态工具融合：Claude 4原生整合文本/图像/音频输入，支持沙箱代码运行与图表生成；o3支持图像融入CoT进行旋转、定位分析。

4、长程任务与记忆机制

（1）持久化执行：突破传统模型任务时长限制：Claude 4可连续运行7小时（如税务申报、开源项目重构）；o3支持异步处理，允许用户关闭设备后任务继续执行。

（2）外挂记忆模块：Claude 4的Prompt Cache缓存1小时内的上下文；o3通过文件与Memory读取实现跨任务状态保留。 

在Agentic能力内化的模型上，OpenAI 的 o4-mini 和 Anthropic 的 Claude 4（常被简称为 Claude 4.0）在 Agentic 能力的设计思路上存在显著差异，体现了两种不同的技术路线——前者走的是黑盒内嵌式整合，后者则采用混合推理式可控路径：

（1）OpenAI 路线：通用化与体验优先，通过降低使用门槛推动Agent 普及，但面临长任务可靠性瓶颈，需依赖 GPT-5 实现突破。

（2）Anthropic 路线：垂直化与可控性，锁定企业市场，以编程、合规场景为护城河，但需应对低价模型（如DeepSeek）的价格压力。

两种路线，两种未来

（1）o4-mini 代表“隐形智能”：Agent 能力如水电般即开即用，适合大众用户，但需解决黑盒不可控问题

（2）Claude 4 代表“可编程智能”：将Agent 转化为企业基础设施，以可控性换取复杂场景落地，但需平衡成本与灵活性

未来Agent 的竞争，本质是 “体验普惠” 与 “深度可靠” 两条路线的角力，而混合架构（如动态切换推理模式）可能成为下一阶段的共性选择。

尽管YC对于Browser Use的热情有助推其Portfolio的嫌疑，数据选点有Cherry-picking的可能，但不可否认的是，GUI/Browser Use无论在投资界还是产业界，都在迅速的凝聚共识。

Browser Use的价值主要体现在以下方面：

1、结构化网页解析替代传统视觉识别

传统AI Agent（如OpenAI Operator）依赖截图分析网页元素，延迟高、成本昂贵（约$200/月）且错误率高。

 Browser Use通过DOM树解析将按钮、表单等元素转化为AI可读的“类文本”格式，任务成功率提升至89.1%（高于Operator的87%），成本降低90%。

这一改变带来的核心价值是：Browser Use可以解决动态网页（如LinkedIn频繁改版）的适配难题，成为AI理解网页的“通用翻译器”。

2、自我修正与异步并发能力

内置错误回滚机制：当操作失败时自动尝试替代方案（如点击备用按钮）

多标签页并发管理：支持数十任务并行（如批量比价+自动结账）

这一改变带来的核心价值是：突破单任务串行瓶颈，为长周期任务（如持续跟踪商品价格）提供技术基础。

3、重构AI Agent开发范式

低代码集成：3行代码对接外部系统（如数据库/API），支持GPT-4、Claude 3.5、Llama等主流模型。有助于开源生态爆发，GitHub相关项目星标表现不错，容易被明星项目集成，吸引更多开发者共建。

这一改变带来的核心价值是：降低Agent开发门槛，推动技术民主化。

那么，我们从各个主体来看，Browser Use的价值体现在：

对开发者：提供首个“开箱即用”的网页操作框架，将Agent开发周期快速压缩

对用户：提高Agent任务处理的准确性，从而提高用户体验

对生态：推动AI Agent从“封闭实验室”走向“开放互联网”

Manus的出现在产品维度确实带给人足够惊喜，在产品之外呢？

尽管现在断言AI Agent产品赢家为时尚早，但我们从Manus的产品思路可以看到很多的方向性：

1、低成本工程整合的价值  

Manus未突破底层模型（依赖Claude/Qwen），但通过融合Computer Use、自主规划等现有技术，以工程创新实现体验跃迁。这充分展示了工程层面的价值——应用层竞争力可能源于技术整合而非原创模型。

工程整合与架构创新可能比底层模型更具短期竞争力，开源社区3天复现Manus（如OpenManus项目），说明其技术可复制性，但工程落地能力才是护城河。

2、交付取代建议，从Copilot走向Agent

Manus以“交付取代建议”重新定义Agent价值，以用户体验为中心，追求任务闭环而非技术炫技，Manus成功地展示了Copilot和Agent在产品形态的区别：即Copilot强调AI辅助决策和建议，Agent强调AI自动执行和交付。

3、减少人工编排，释放模型智能涌现

回顾我们在AI Agent的“白马非马”讨论中的九宫格。Manus是目前Agent产品中更接近AI Agent狭义定义的产品。

传统Workflow设计（如Coze、Dify）需人工拆解任务，而Manus的自主规划能力（自动分解目标→生成Todo→执行）降低了人工干预成本，体现“弱框架、强智能”理念。其产品部分验证了：过度依赖Prompt/规则约束会抑制模型潜力，适度放手可能获得更优解。

4、过程可视化，降低用户信任门槛

Manus的“过程可视化”（展示任务拆解与执行步骤）降低用户认知门槛，增强信任感。 

进入到Tools环节，我们可以看到近期各家AI巨头动作频频，其中绕不开的主要工程层面的Buzzword是MCP。

MCP（模型上下文协议）：由Anthropic提出，基于动态发现与双向通信的开放架构，类似于一个通用接口，允许AI模型更灵活地连接和使用各种工具，而无需为每个工具单独编写代码，支持“一次集成，全局调用”的生态模式。

1、MCP VS 传统API

（1）传统API：需为每个服务编写定制化代码（如认证、数据格式转换），维护成本高且灵活性受限，适合需严格控制的场景（如金融交易接口）。其集成的本质是工具拼接。

（2）MCP的突破性：MCP的三层架构（Host-Client-Server）打破了传统API的“烟囱式”集成模式，完成协议层与执行层的解耦重构，不同AI Agent无需重复对接设备协议即可协同MCP实现了工具内化—AI Agent通过协议直接理解工具语义，如同人类学会使用锤子后无需每次思考如何握持。

2、MCP生态快速繁荣

（1）MCP Server数量暴增：在2025年3月以后，每月翻倍，覆盖覆盖搜索工具、API连接器、数据库交互等基础模块。

（2）GitHub生态活跃度飙升：MCP开源仓库星标数已突破48k，连续位居AI类项目榜首，且代码贡献者数量预计突破10万人。

（3）科技巨头普遍融入MCP生态：

海外方面，OpenAI、Google、MS、AWS全面支持MCP，推动其成为AI领域的USB-C接口。

国内方面，字节火山发布大模型生态广场MCP Servers，阿里云上线全生命周期MCP服务，腾讯云升级大模型知识引擎，百度打造MCP Store开发者社区。

可以肯定，MCP在各个工具集成协议中已取得毫无疑问的身位优势。但正如通信协议的不断迭代，未来的New Version MCP或其他工具集成协议仍存在巨大变量，我们需要Keep and see。

如果说MCP的推出旨在解决AI Agent工具调用的问题，那么Google A2A协议则侧重解决Agent 之间的通信问题。

A2A（Agent-to-Agent Protocol）：由Google于2025年4月推出的开源协议，旨在为AI智能体（Agents）提供标准化的通信方式，允许不同框架（如LangChain、CrewAI）或不同供应商开发的智能体无缝协作，打破智能体间的隔离状态。A2A通过统一的通信格式和交互规则，让智能体像网络服务一样自由“对话”。

Agent的重要创新在于其名片机制：借助JSON 格式的智能体卡片（Agent Card），A2A可以精准刻画智能体的身份属性、技能特长、接口细节与安全标准，有效化解传统 AI 系统因技术隔阂造成的“Agent 能力烟囱”瓶颈，促进 Agent 自动交互，降低人工介入成本，消除 AI 孤岛现象。

A2A（Agent-to-Agent）与MCP（Model Context Protocol）是如何协同的？

A2A与MCP的协同是构建复杂AI系统的核心架构，两者通过分工与互补，推动从“个体能力”到“群体智能”

A2A的通信标准（如HTTP/JSON-RPC）与MCP的工具调用规范（如OpenAPI）兼容，形成“任务流-工具链”闭环。例如，智能体通过A2A接收任务后，内部调用MCP接口完成操作，再将结果通过A2A传递。

但是，如果我们把目光放得更长，我们可以很轻易地发现：MCP和A2A之间的上下游关系只是局部的，二者的能力边界并不是泾渭分明，长期看隐含着激烈的标准之争。

短期共存：MCP和A2A互补性需求明确，复杂系统需同时整合两类协议（如企业CRM中，客服Agent用A2A协调工单，用MCP查数据库）。

长期竞争：MCP和A2A存在巨大的生态位重叠风险，复杂工具（如金融建模API）既可包装为MCP服务器，也可升级为A2A智能体，导致协议边界模糊。开发者可能面临“二选一”困境：若A2A的AgentSkill能覆盖工具调用功能，可能削弱MCP的部分价值。

核心的争论是什么？

MCP和A2A未来生态之争的本质是：你是否相信Agent的原子能力是被封装在Tool中，还是被封装在子Agent之中。

MCP可以更好的链接Agent与工具，如果Agent的原子能力以工具形式存在，那么MCP从长期看是更具竞争力的。

A2A可以更好的链接Agent之间，如果Agent的原子能力以更小型的Agent形式存在，那么A2A从长期看是更具竞争力。

Multi-Agent已成为必然

在从Agent的运作流程中拆解中看到了各个环节的一些进展，但是，我们需要看到的是，Single-Agent存在巨大局限性，短时提高的程度是有限的。

1、Single-Agent的局限性

（1）Memory上下文窗口与长期记忆：单个Agent在长期记忆的存储和使用方面面临巨大压力。实现长期记忆的典型解决方案是将其存储在外部向量数据库中，但访问和利用这些记忆需要高效的机制。

（2）Tools复杂任务调用工具达到新的数量级：Agent时代涉及大量不同类型的动作工具，从简单的API调用到复杂的物理操作，对Agent的理解和操作能力提出了更高要求。

（3）React框架局限性引入Reflextion：React框架的局限性导致了“误差积累”问题。在多步骤的复杂任务中，由于推理过程高度依赖模型自主决策，任何一步的推理错误都可能通过后续步骤放大，最终导致任务失败。

2、为什么不是更好的Single-Agent？而是Multi-Agent?

Single-Agent的突破相比于Multi-Agent带来的即时提升需要更多时间。

克服AI Agent的局限选择Multi-Agent而非优化Single-Agent，本质在于分布式协作架构在复杂性、鲁棒性及扩展性上的根本优势。

（1）多方案探索与竞争进化

Multi-Agent支持并行探索多条解决路径（如辩论、对抗机制），通过竞争筛选最优方案。Single-Agent仅能线性尝试，效率低下且易陷入局部最优。

Single-Agent一旦崩溃整个系统就瘫痪，而Multi-Agent中某个智能体失效时，其他可以接管任务。

（2）人类协作适配性

Multi-Agent的分布式角色设计（如MetaGPT模拟开发团队）更贴近现实分工场景，便于人类参与监督与流程管理

1、Single-Agent在Memory方向的卡点

（1）短时记忆：上下文窗口硬性限制

Single-Agent 依赖模型的上下文窗口存储短期记忆（如对话历史），但主流模型存在严格上限： Claude 3.7（204K tokens），也无法避免长任务中的早期信息截断，长对话或复杂任务中，容易导致关键历史信息被丢弃，导致决策失误（如忘记用户初始需求）。

（2）长期记忆：能力存在巨大短板

Single-Agent会话结束后，上下文窗口内容清零，难以跨会话保留用户偏好、任务进度等核心信息，依赖外部数据存储方案，但上下文窗口有限导致长时记忆调度仍然有吞吐量的问题：临时性记忆导致每次交互需重复说明需求（如客服场景需反复确认用户信息）。

2、Multi-Agent如何缓解Agent的Memory问题？

（1）分层记忆：工作记忆（当前任务）、短期记忆（近期交互）、长期记忆（用户偏好）分属不同Agent管理。

（2）记忆共享：通过公共知识库（如向量数据库）实现跨Agent信息检索，避免重复存储。

（3）Memory负载的分散化：Single-Agent的上下文窗口是有限的，但通过Agent之间Prompt传递上下文的形式，可以在不同Agent分散上下文窗口负载，提高持续作业的能力。

在工具调用层面，我们可以看到，Single-Agent有几个问题:太多的工具可能会使选择复杂化,上下文变得过于复杂,任务可能需要专业化。

因此我们可以选择Multi-Agent系统,其中多个Agent可以分管不同的工具调用相互交互及其环境（例如Coding/Message/Search）

每个Agent可能都有不同类型的工具，但在数十个量级的Multi-Agent管理架构中,其核心有两个组件：

（1）Initialization—系统中的Single-Agent如何创建?

（2）Agent Orchestratio—Agent任务编排&监督实施

1、React框架的局限性

（1）迭代深度受限

ReAct 框架需要多次调用工具并循环推理，但实际场景中往往设置迭代次数上限（如 N=5），当任务复杂度超过阈值时，Agent 无法通过足够次数的工具调用完成完整排查。例如在金融场景排查放款失败问题时，若涉及多系统联调，有限的迭代次数可能导致关键步骤缺失。

（2）误差传播风险

由于推理过程高度依赖模型自主决策，任何一步的推理错误都会通过后续步骤放大，最终导致整体任务失败。尽管可引入校验机制，但额外校验步骤会进一步增加迭代次数和响应延迟。

（3）实时性难以保障

ReAct 的动态决策特性导致响应时间不可控：复杂任务可能需要数十次工具调用，累积延迟可达小时级；缺乏对工具执行耗时的预判机制，无法像预定义工作流（Workflow）那样精准控制超时阈值

2、Multi-Agent在何种程度上可以解决？

（1）工具解耦：每个 Agent 仅携带特定工具集，减少单次处理负载

（2）并行处理：多个 Agent 可协同处理关联任务，缩短整体链路耗时

（3）错误隔离：单个 Agent 故障不会导致全链路崩溃，可通过替补 Agent 重启子任务

（4）更好的纠错查错机制：通过Reflexion来帮助Agent从先前失败中学习的技术，在过程中提升Agent准确性。

执行者（Actor）— 根据状态观察选择并执行行动

评估者（Evaluator） — 对执行者产生的输出进行评分

自我反思（Self-reflection） — 反思执行者采取的行动和评估者生成的评分

以下是Multi-Agent系统中六种核心架构模式的解析，结合技术定义与典型应用场景说明：

1、Single-Agent（单智能体）

定义：整个系统仅包含一个智能体，直接连接LLM并管理所有工具（如API、数据库）。  

特点：结构简单，适合基础任务（如问答机器人）。

局限性：工具过多时决策混乱，长上下文任务易信息丢失。

案例：客服机器人独立处理用户查询，但无法跨领域协作。

2、Network（网络架构）

定义：所有智能体可自由通信，任意智能体均可决定下一步调用的对象，形成多对多连接。

特点：灵活性高，适合开放式协作（如开放社区讨论）。

局限性：智能体数量增加后协调难度剧增，易出现通信拥塞。

案例：社交软件中用户可任意@其他用户发起协作。

3、Supervisor（监督者架构）

定义：中央监督者智能体接收任务，分解后分配给特定子智能体执行，并整合结果。

特点：控制力强，避免任务冲突（如团队分工明确）。

局限性：监督者单点故障可能影响全局。

案例：旅行规划中，监督者分配航班预订给Agent A、酒店预订给Agent B。

4、Supervisor (as tools)（工具化监督者）

定义：监督者将子智能体视为“工具”，通过LLM的函数调用（Function Calling）动态选择工具并传参。  

特点：兼容现有工具调用框架，开发成本低。

局限性；需预定义工具接口，灵活性受限。

案例：监督者调用“数学计算工具”解方程，调用“搜索工具”查资料。

5、Hierarchical（分层架构）

定义：多层监督结构，高层监督者管理中层协调组，中层再管理底层执行智能体。

特点：支持复杂任务递归分解（如企业多部门协作）。

案例：智能家居中，安防管理Agent协调门窗传感器Agent和摄像头Agent。

6、Custom（自定义架构）

定义：智能体仅与特定子集通信，部分流程为确定性规则（非LLM决策）。  

特点：平衡灵活性与效率，避免全连接开销。

局限性：需定制通信协议，开发复杂度高。

案例：供应链系统中，采购Agent仅与库存Agent、订单Agent通信。

那么，目前的技术趋势是怎么样的？

当前企业级应用以Supervisor和Hierarchical为主（如AWS的MAC框架），因其在任务成功率和系统稳定性上的优势。而Custom架构在特定领域（如工业自动化）因高效性备受关注。

Multi-Agent框架处于“春秋战国”式的割据状态，与MCP和A2A的凝聚共识的快速度不同，目前市场中主流的AI玩家普遍推出自身的Multi-Agent框架，短时间内还缺乏竞争收敛的Catalyst：

1、框架需承载全栈复杂性：Multi-Agent框架（如LangGraph、AutoGen）需解决任务编排、状态管理、容错恢复等系统级问题，牵一发而动全身

2、协议仅定义交互规范：MCP与A2A协议聚焦通信接口标准化，不涉及内部实现

3、框架需试错验证场景适配性，协议可抽象通用需求

我们与AI Agent中的 DeepSeek时刻的距离

朱啸虎说：“所有的AI应用都是套壳应用，说有壁垒是忽悠人的，所有的能力都来自于AI之外的苦活累活。”

我们对于这句话的评价是Yes and No。

Yes的部分：

1、“套壳”现象普遍存在，技术同质化严重

（1）开源模型降低门槛：当前多数AI Agent基于LLaMA、GPT等开源模型二次开发，核心能力依赖底层模型而非自身创新。如客服Agent常直接调用API封装对话流程，缺乏算法原创性。

（2）场景创新≠技术壁垒：如朱啸虎所言，许多企业仅通过“优化工作流”实现商业化（如用AI简化客服工单），其价值源于业务整合而非AI技术本身。

2、“苦活累活”可以产生短期差异化

（1）数据工程决定短期能力：AI Agent的精准决策依赖高质量数据清洗、标注及领域知识注入。例如医疗诊断Agent需医生参与数据校验，金融风控Agent需行业规则编码。

（2）系统集成成本高昂：将AI嵌入企业现有系统（如ERP、CRM）需大量定制开发，这类“脏活”成为落地瓶颈。

No的部分：

1、 苦活累活从长期看依然有被淹没的风险

从长期看，“苦活累活”正被自动化重构，自优化Agent涌现可从交互中自主优化策略，减少人工干预。

2、“苦活累活”里面只有更好的工程创新配留下来

从Cursor、Windsurf、Lovable的经验来看，下一代的AI 工具的本质是为了降低使用门槛而非提高使用门槛。如果需要投入极高人力做实施，只能说明AI工具链还不够成熟。

那么对应的，下一步应该应该做什么呢？

√投入打造更好更易用的工具链，磨刀不误砍柴工

×投入更多人力去做实施

毕竟AI时代已经也必将进一步稀释人力的规模效应。

最后，让我们现在回到最初的问题：我们距离Agent的DS时刻还有多远？

我们会说，路漫漫其修远，但是在这个进程中，我们有望在未来12-24个月之内就看到足够多的惊喜。

在此，我们以LangChain的Agent报告作为结束：

从用户反馈来看，许多人对构建和测试智能体的最佳实践感到不确定。知识储备是一个重要障碍，许多团队缺乏与智能体相关的技术知识，包括如何针对特定用例实施智能体。此外，构建和部署智能体需要大量时间，尤其是在确保其可靠运行时，可能涉及调试、评估和微调等繁琐过程。

对于不同规模的企业来说，采用Agent的核心卡点也有所不同。小型企业更关注性能、质量和延迟，而中大型企业则更关心成本、安全性和可靠性。这些因素都影响了Agent技术的普及速度。

总的来说，我们正稳步迈向那个时刻。

获取完整报告可私信公众号后台：Z Research