AI Agent商业化困局:当前技术瓶颈与可行的商业模式探索


文章摘要

从OpenAI在2024年初GPT-4 Turbo+ Assistants API 2.0的全面升级,到Anthropic Claude 3 Opus/Sonnet/Haiku三架构模型的推出,再到国内字节跳动豆包、阿里云通义千问等推出的自主可控Agent平台,AI Agent无疑成为了继大模型基座之后最受资本与市场关注的赛道。据Gartner最新发布的《2025年新兴技术成熟度曲线》显示,AI Agent已从2024年的“过高期望的峰值”(Peak of Inflated Expectations)逐渐滑向“泡沫化的低谷期”(Trough of Disillusionment)——资本热度从2023年Q4的单季度120亿美元骤降至2025年Q1的17亿美元,而真正落地到生产环境、实现规模化盈利的案例不足全球已公开Agent项目的0.2%。

为什么会出现如此巨大的反差?是技术还不够成熟?还是我们对Agent的应用场景定位出了问题?又或者是现有商业模式无法匹配Agent的技术特性与成本结构?作为在科技行业深耕16年、经历过Web2.0到云原生再到大模型时代的架构师与博主,今天我想从技术瓶颈的底层逻辑拆解现有商业模式的失效根源分析可行商业模式的三维度探索框架基于场景落地的实战案例剖析未来3-5年的发展趋势预测五个维度,带你系统性地破解AI Agent的商业化困局。

本文的核心目标读者是AI领域的创业者、企业技术负责人、产品经理、以及对Agent赛道有投资/研究需求的专业人士,同时也会用生动的比喻与简化的数学模型照顾到有一定技术基础的普通开发者。全文将严格遵循“金字塔原理”,论点先行、论据支撑,并且会使用Python源代码、Mermaid流程图、数学公式(LaTeX)、对比表格等多种形式,让你不仅知其然,更知其所以然。


核心概念

在正式进入困局分析之前,我们必须先明确几个极易混淆的核心概念——这些概念的模糊不清,既是很多创业者踩坑的原因,也是很多投资人判断失误的根源。

1.1 什么是真正的AI Agent?

首先,我们要区分开市场上常见的“伪Agent”与“真Agent”。很多开发者或企业会把**“基于大模型的对话式工具”(比如集成了知识库检索的RAG聊天机器人)、“固定流程自动化工具”(比如RPA+LLM的混合工具)统称为AI Agent,但这其实是对Agent概念的严重窄化或泛化**。

核心概念定义

真正的AI Agent(自主智能体),是指能够感知环境、基于目标自主决策、调用工具/API完成任务、并根据反馈持续迭代优化的闭环系统。这个定义最早可以追溯到20世纪90年代的多智能体系统(MAS, Multi-Agent System) 研究,但在大模型时代被重新赋予了灵魂——大模型基座提供了通用的“认知能力”与“自然语言接口”,解决了传统Agent“只能处理特定任务、难以理解人类模糊指令”的两大痛点。

核心概念的简化比喻

为了让大家更直观地理解,我们可以把AI Agent比作企业里的“全职员工”

  • 伪Agent(对话式RAG) = 企业里的“前台+图书管理员”:只能回答固定在图书(知识库)里的问题,或者把用户的问题转交给其他人处理,完全没有自主决策能力;
  • 伪Agent(RPA+LLM) = 企业里的“流水线工人”:只能按照预先设定好的流程(脚本)机械地重复操作,一旦流程出现任何微小的变化(比如网页布局改了一行字)就会崩溃;
  • 真Agent = 企业里的“项目经理”:能够理解老板(用户)的模糊目标(比如“帮我筹备一场北京的、面向AI创业者的小型线下沙龙,预算5万以内,时间定在两周后的周六下午”),然后自主地感知环境(查北京两周后的天气、查合适的场地资源、查目标用户群体的活动时间偏好)、拆解任务(拆解为场地预订、嘉宾邀请、报名通道搭建、物料准备、预算控制五个子任务)、调用工具(调用飞书日历工具查老板和潜在嘉宾的空闲时间、调用美团点评工具查性价比高的咖啡厅/会议室、调用微信小程序搭建工具制作报名链接、调用飞书文档工具制作物料清单、调用飞书多维表格工具做预算跟踪)、执行决策(在三个备选场地中选择了中关村创业大街的3W咖啡,因为它距离目标用户群体近、性价比高、有现成的投影设备和麦克风)、反馈优化(如果发现报名人数超过了场地容量,会自动询问老板是否换更大的场地或者限制报名人数;如果预算超支了,会自动删减不必要的物料或者和嘉宾协商降低出场费)。
真Agent的四个核心要素(根据MARL+LLM的混合研究成果总结)

为了更严谨地定义真Agent,我们可以用**“感知-决策-执行-迭代”** 这四个核心要素来构成一个闭环模型(见Mermaid架构图1):

用户输入/外部事件
触发Agent的目标

感知模块
Perception Module

环境状态收集器
Collects context from multiple sources

状态编码器
Encodes raw context into structured/unstructured state vectors

决策模块
Decision Module

目标拆解器
Breaks high-level goal into sub-goals with constraints

工具/API规划器
Selects and sequences appropriate tools/APIs for each sub-goal

执行模块
Execution Module

工具调用执行器
Executes tools/APIs with proper parameters

结果验证器
Validates execution results against constraints

是否满足子目标?

反馈迭代器
Feedback Iteration Module

状态更新器
Updates state vectors with new context

是否所有子目标都完成?

子目标推进器
Moves to the next sub-goal in the sequence

结果生成器
Generates natural language/structured output for the user

任务完成归档器
Archives all context, decisions, and results for future learning

长期记忆更新器
Updates long-term memory with successful/unsuccessful patterns

感知模块(Perception Module)

感知模块是Agent的“眼睛、耳朵和鼻子”,负责从内部资源(比如企业内部的ERP系统、CRM系统、知识库、飞书/钉钉的聊天记录、文档)和外部资源(比如互联网搜索、天气API、股票API、电商平台API、社交媒体API)中收集与当前任务相关的上下文信息,并将这些杂乱无章的原始信息(比如一段聊天记录、一张图片、一段视频、一个CSV文件)编码成大模型能够理解的结构化状态向量半结构化自然语言摘要

感知模块的核心技术包括:多模态理解(MMU, Multi-Modal Understanding)信息检索与抽取(IRE, Information Retrieval and Extraction)上下文窗口扩展(CWE, Context Window Extension)长文本语义分割(LTSD, Long Text Semantic Segmentation)

决策模块(Decision Module)

决策模块是Agent的“大脑”,负责:

  1. 目标拆解:将用户输入的模糊、抽象的高层级目标(比如“帮我筹备一场小型线下沙龙”)拆解成具体、可执行、有时间/预算/质量约束的子目标(比如“在2025年X月X日14:00-17:00之间,预订一个能容纳50人的、位于北京中关村的、预算在2万以内的咖啡厅会议室”);
  2. 工具/API规划:为每个子目标选择合适的工具/API组合(比如为场地预订子目标选择“飞书日历查询工具+美团点评搜索工具+高德地图导航工具+场地预订API”),并确定这些工具/API的调用顺序(比如先查老板和潜在嘉宾的空闲时间,再查符合条件的场地,再和场地确认预订时间和价格);
  3. 风险预判与规避:在执行决策之前,预判可能出现的风险(比如场地临时取消、报名人数超过容量、预算超支),并制定对应的规避方案(比如提前预订两个备选场地、设置报名人数上限、制作预算超支预案)。

决策模块的核心技术包括:大语言模型的思维链(CoT, Chain of Thought)思维树(ToT, Tree of Thought)思维图(GoT, Graph of Thought)多智能体协作(MAC, Multi-Agent Collaboration)强化学习(RL, Reinforcement Learning)马尔可夫决策过程(MDP, Markov Decision Process)

执行模块(Execution Module)

执行模块是Agent的“手和脚”,负责:

  1. 工具调用执行:按照决策模块制定的调用顺序,向工具/API发送符合要求的参数(比如向美团点评搜索工具发送“北京中关村 能容纳50人 咖啡厅会议室 预算2万以内 2025年X月X日14:00-17:00”的参数);
  2. 结果验证:将工具/API返回的结果与决策模块制定的约束条件进行对比(比如检查预订的场地是否位于中关村、容量是否达到50人、价格是否在2万以内、时间是否符合要求);
  3. 异常处理:如果结果验证失败(比如场地临时取消、价格超出预算、参数格式错误),则触发简单的异常处理流程(比如重试工具调用、调整参数、选择备选工具/API),如果简单的异常处理流程无法解决问题,则将问题反馈给决策模块或用户。

执行模块的核心技术包括:函数调用(Function Calling)工具编排(Tool Orchestration)API网关(API Gateway)重试机制与熔断机制(Retry and Circuit Breaker)异步任务处理(Asynchronous Task Processing)

反馈迭代模块(Feedback Iteration Module)

反馈迭代模块是Agent的“记忆和学习能力”,负责:

  1. 短期记忆更新:将本次任务执行过程中产生的所有上下文信息、决策过程、执行结果、异常处理记录存储在短期记忆库(比如Redis、MongoDB的临时集合)中,供后续子任务的决策和执行使用;
  2. 长期记忆更新:在任务完成后,将本次任务执行过程中产生的成功模式(比如“预订中关村创业大街的3W咖啡时,需要提前10天预订,并且可以通过和店长协商降低10%的价格”)和失败模式(比如“使用某天气API查询两周后的天气时,准确率只有60%,应该使用中央气象台的API”)存储在长期记忆库(比如向量数据库、关系型数据库的历史表)中,供未来类似任务的决策和执行使用;
  3. 用户反馈学习:如果用户对本次任务的执行结果不满意,或者给出了明确的修改意见,则将用户的反馈存储在长期记忆库中,并在未来的任务执行过程中调整决策和执行策略。

反馈迭代模块的核心技术包括:向量数据库(Vector DB)检索增强生成(RAG, Retrieval-Augmented Generation)强化学习从人类反馈中学习(RLHF, Reinforcement Learning from Human Feedback)强化学习从AI反馈中学习(RLAIF, Reinforcement Learning from AI Feedback)联邦学习(FL, Federated Learning)


1.2 AI Agent vs. 对话式RAG vs. RPA+LLM:核心属性维度对比

为了帮助大家更清晰地区分这三个极易混淆的概念,我们可以从自主性、通用性、适应性、学习能力、任务复杂度、部署成本、维护成本、安全性这八个核心属性维度进行对比(见对比表格1):

核心属性维度 AI Agent(真Agent) 对话式RAG(伪Agent) RPA+LLM(伪Agent)
自主性 ★★★★★(完全自主,不需要人类干预,除非遇到超出能力范围的问题) ★★☆☆☆(几乎没有自主性,只能回答固定在知识库中的问题,或者把问题转交给人类) ★★★☆☆(有一定的自主性,但只能按照预先设定好的流程操作,一旦流程出现变化就会崩溃)
通用性 ★★★★★(通用的,能够处理各种不同类型的任务,比如文本生成、数据分析、任务调度、多模态处理) ★☆☆☆☆(非常窄的,只能处理与知识库内容相关的问答任务) ★★☆☆☆(比较窄的,只能处理特定领域的、流程相对固定的任务,比如发票审核、订单录入、客户服务工单处理)
适应性 ★★★★★(非常强的,能够适应环境的变化、流程的变化、用户需求的变化) ★☆☆☆☆(几乎没有适应性,知识库内容更新之后才能回答新问题) ★☆☆☆☆(几乎没有适应性,流程变化之后需要重新编写脚本)
学习能力 ★★★★★(非常强的,能够从人类反馈、AI反馈、任务执行记录中持续学习和优化) ★☆☆☆☆(几乎没有学习能力,只能依靠人工更新知识库) ★☆☆☆☆(几乎没有学习能力,只能依靠人工重新编写脚本)
任务复杂度 ★★★★★(能够处理非常复杂的、多步骤的、跨系统的、有约束条件的任务) ★☆☆☆☆(只能处理非常简单的、单步骤的、问答类的任务) ★★★☆☆(能够处理中等复杂度的、多步骤的、单系统的、流程固定的任务)
部署成本 ★★☆☆☆(较高,需要部署大模型基座、感知模块、决策模块、执行模块、反馈迭代模块、向量数据库、API网关等多个组件) ★★★★★(非常低,只需要部署知识库检索系统和大模型API调用接口) ★★★☆☆(中等,需要部署RPA平台和大模型API调用接口)
维护成本 ★★☆☆☆(较高,需要定期更新长期记忆库、优化决策模块的提示词、调整工具/API的调用顺序、修复异常处理流程) ★★★★★(非常低,只需要定期更新知识库内容) ★★☆☆☆(较高,需要定期重新编写RPA脚本、修复流程变化带来的问题)
安全性 ★★☆☆☆(较低,因为Agent可以自主调用工具/API,可能会存在数据泄露、恶意操作、权限滥用等安全风险) ★★★★★(非常高,因为只能回答固定在知识库中的问题,不能调用外部工具/API) ★★★☆☆(中等,因为只能按照预先设定好的流程操作,权限范围相对固定,但仍然可能存在数据泄露的风险)

1.3 AI Agent的分类体系:从不同维度的划分

为了更有针对性地探索AI Agent的商业化路径,我们需要对AI Agent进行科学的分类。目前市场上常见的分类维度包括应用场景、能力范围、部署方式、协作模式、智能程度等,下面我将逐一介绍这些分类维度,并给出对应的分类体系(见Mermaid架构图2):

AI Agent分类体系

按应用场景划分

按能力范围划分

按部署方式划分

按协作模式划分

按智能程度划分

个人助手类Agent

企业内部类Agent

垂直行业类Agent

游戏娱乐类Agent

其他类Agent

研发类Agent

运营类Agent

销售类Agent

客服类Agent

财务类Agent

人力资源类Agent

单能力Agent

多能力Agent

通用能力Agent(AGI Agent)

云端SaaS Agent

本地私有化Agent

混合部署Agent

单Agent

多Agent协作系统(MAS)

分层协作MAS

平等协作MAS

混合协作MAS

反应式Agent

慎思式Agent

混合式Agent

学习式Agent

1.3.1 按应用场景划分

这是目前市场上最常见、也是最有商业化价值的分类维度,我们可以将AI Agent分为个人助手类Agent企业内部类Agent垂直行业类Agent游戏娱乐类Agent其他类Agent五大类:

个人助手类Agent

个人助手类Agent是指为个人用户提供服务的AI Agent,比如帮助个人用户管理日程、预订机票酒店、购物、学习、健身、医疗咨询等。目前市场上比较知名的个人助手类Agent包括:OpenAI的GPT-4o Mini/Plus with Custom GPTs+、Anthropic的Claude 3 Projects、字节跳动的豆包AI助手、阿里云的通义千问AI助手、小米的小爱同学Pro+、华为的小艺智慧助手Pro+等。

个人助手类Agent的核心优势是:用户基数大、市场需求广泛、技术门槛相对较低(可以直接使用第三方的大模型API和工具/API);核心劣势是:用户付费意愿低、竞争激烈、数据安全和隐私保护问题突出、难以实现规模化盈利。

企业内部类Agent

企业内部类Agent是指为企业内部员工提供服务的AI Agent,比如帮助研发人员写代码、调试代码、写文档、做代码审查;帮助运营人员做数据分析、做用户画像、做内容创作、做活动策划;帮助销售人员做客户开发、做客户跟进、做合同起草、做报价单制作;帮助客服人员做客户咨询、做客户投诉处理、做工单分配;帮助财务人员做发票审核、做报销单审批、做财务报表生成、做税务申报;帮助人力资源人员做简历筛选、做面试安排、做员工培训、做绩效评估等。

企业内部类Agent的核心优势是:企业付费意愿高、市场需求明确、数据安全和隐私保护问题可以通过本地私有化部署解决、容易实现规模化盈利;核心劣势是:技术门槛相对较高(需要对接企业内部的多个系统,比如ERP系统、CRM系统、OA系统、知识库系统等)、定制化程度高(不同企业的业务流程和需求差异很大)、部署和维护成本较高。

垂直行业类Agent

垂直行业类Agent是指为特定垂直行业提供服务的AI Agent,比如医疗健康行业的诊断助手、治疗方案制定助手、病历管理助手;金融行业的投资顾问助手、风险控制助手、贷款审批助手;教育行业的个性化学习助手、作业批改助手、试题生成助手;法律行业的合同审查助手、法律检索助手、诉讼策略制定助手;电商行业的选品助手、定价助手、客服助手、物流调度助手;制造业的设备维护助手、生产计划制定助手、质量检测助手等。

垂直行业类Agent的核心优势是:行业壁垒高、竞争相对较少、企业/个人付费意愿高、市场空间大;核心劣势是:技术门槛非常高(需要对特定垂直行业的业务流程、专业知识、法律法规有非常深入的了解)、数据获取难度大(很多垂直行业的数据都是非公开的、或者数据质量很差)、合规性要求高(比如医疗健康行业、金融行业、法律行业都有非常严格的合规性要求)。

游戏娱乐类Agent

游戏娱乐类Agent是指为游戏娱乐领域提供服务的AI Agent,比如游戏中的NPC(非玩家角色)、游戏攻略助手、游戏直播助手、短视频创作助手、音乐创作助手、绘画创作助手等。目前市场上比较知名的游戏娱乐类Agent包括:Unity的AI NPC工具、Epic Games的MetaHuman Animator+AI、字节跳动的豆包AI绘画/音乐/短视频创作工具、OpenAI的Sora(虽然还没有正式开放,但已经引起了广泛的关注)等。

游戏娱乐类Agent的核心优势是:用户基数大、市场需求广泛、技术门槛相对较低、可以快速迭代和试错;核心劣势是:用户付费意愿低(除了少数高端游戏玩家之外)、竞争激烈、内容同质化严重、难以实现长期的用户留存。

其他类Agent

其他类Agent是指不属于以上四大类的AI Agent,比如自动驾驶汽车中的AI Agent、机器人中的AI Agent、智能家居中的AI Agent、智慧城市中的AI Agent等。这些Agent通常需要结合硬件设备使用,技术门槛非常高,但市场空间也非常大。


问题背景

要理解AI Agent当前面临的商业化困局,我们必须先了解AI Agent的发展历史当前的市场环境——只有知其史,才能明其势。

2.1 AI Agent的发展历史:从传统MAS到大模型时代的重新崛起

AI Agent的概念并不是大模型时代才有的,它最早可以追溯到20世纪50年代的图灵测试通用人工智能(AGI, Artificial General Intelligence) 研究,然后经历了以下几个重要的发展阶段(见对比表格2):

发展阶段 时间范围 核心技术支撑 核心研究成果 核心局限性 市场应用情况
萌芽期 1950s-1970s 符号主义人工智能(Symbolic AI)、逻辑推理(Logical Inference) 图灵测试、麦卡锡的LISP编程语言、专家系统的雏形 只能处理特定领域的、规则明确的任务,难以理解人类的模糊指令,缺乏学习能力 几乎没有市场应用,主要停留在学术研究阶段
成长期 1980s-1990s 专家系统(Expert System)、多智能体系统(MAS, Multi-Agent System)、强化学习(RL, Reinforcement Learning)的早期研究 MYCIN医疗诊断专家系统、DENDRAL化学分析专家系统、BDI(Belief-Desire-Intention)Agent模型 专家系统的知识获取和维护成本非常高,MAS的协作效率非常低,强化学习的训练难度非常大 专家系统在医疗健康、金融、制造业等特定垂直行业有少量的市场应用,但整体规模很小
低谷期 2000s-2010s 机器学习(ML, Machine Learning)、深度学习(DL, Deep Learning)的早期研究、Web2.0、云计算 支持向量机(SVM)、随机森林(RF)、卷积神经网络(CNN)、循环神经网络(RNN) 深度学习的训练需要大量的标注数据和计算资源,缺乏通用的认知能力,难以理解人类的模糊指令 机器学习和深度学习在图像识别、语音识别、自然语言处理等特定领域有少量的市场应用,但Agent的概念几乎被市场遗忘
重新崛起期 2022年底-2024年初 大语言模型(LLM, Large Language Model)、检索增强生成(RAG)、函数调用(Function Calling)、思维链(CoT)、思维树(ToT) OpenAI的GPT-3.5 Turbo+Assistants API 1.0、Anthropic的Claude 2、字节跳动的豆包、阿里云的通义千问 大模型的上下文窗口有限、推理成本高、幻觉问题严重、自主决策能力有限、工具调用能力有限 市场上出现了大量的Agent项目,资本热度非常高,但真正落地到生产环境、实现规模化盈利的案例很少
泡沫化低谷期 2024年中-至今 大语言模型的升级(GPT-4o、Claude 3、Llama 3)、多模态理解(MMU)、思维图(GoT)、多智能体协作(MAC)、强化学习从AI反馈中学习(RLAIF)、向量数据库的升级 OpenAI的GPT-4o Turbo+Assistants API 2.0、Anthropic的Claude 3 Opus/Sonnet/Haiku三架构模型、Meta的Llama 3 400B、Pinecone的Serverless Vector DB 2.0 技术瓶颈仍然存在(比如幻觉问题、自主决策能力有限、工具调用能力有限、多智能体协作效率低)、现有商业模式无法匹配Agent的技术特性与成本结构 资本热度骤降,很多Agent项目倒闭或转型,市场开始回归理性,真正专注于技术突破和场景落地的项目开始受到关注

2.2 当前的市场环境:资本热度骤降,市场回归理性

2.2.1 资本热度骤降:从“过热”到“过冷”

据CB Insights最新发布的《2025年Q1全球AI投资报告》显示,2025年Q1全球AI领域的总投资额为178亿美元,其中AI Agent赛道的投资额仅为17亿美元,占比不足10%——相比之下,2023年Q4全球AI Agent赛道的投资额为120亿美元,占比超过了30%;2024年Q3全球AI Agent赛道的投资额为72亿美元,占比超过了20%。

资本热度骤降的原因主要包括以下几个方面:

  1. 技术瓶颈仍然存在:很多创业者承诺的“完全自主的AI Agent”并没有实现,市场上出现的大部分都是“伪Agent”;
  2. 现有商业模式失效:很多创业者采用的是To C的“免费+增值服务”模式或者To B的“年费订阅”模式,但这些模式无法匹配Agent的技术特性与成本结构;
  3. 落地效果不达预期:很多企业购买了Agent服务之后,发现落地效果很差,不仅没有提高工作效率,反而增加了维护成本;
  4. 竞争激烈:市场上出现了大量的Agent项目,内容同质化严重,很多项目没有核心竞争力;
  5. 合规性要求提高:很多国家和地区出台了严格的AI监管政策,比如欧盟的《人工智能法案》(AI Act)、美国的《人工智能权利法案》(AI Bill of Rights)、中国的《生成式人工智能服务管理暂行办法》等,这些政策增加了Agent项目的合规成本和运营风险。
2.2.2 市场回归理性:从“概念炒作”到“场景落地”

虽然资本热度骤降,但市场并没有完全否定AI Agent的价值——相反,市场开始回归理性,真正专注于技术突破场景落地的项目开始受到关注。据Gartner最新发布的《2025年新兴技术成熟度曲线》显示,AI Agent虽然已经滑向了“泡沫化的低谷期”,但预计将在2-3年内进入“稳步爬升的光明期”(Slope of Enlightenment),并在5-10年内进入“生产力成熟期”(Plateau of Productivity)。

市场回归理性的表现主要包括以下几个方面:

  1. 投资者更加关注技术壁垒:投资者不再仅仅关注项目的概念和团队背景,而是更加关注项目的技术壁垒,比如是否拥有自主可控的大模型基座、是否拥有核心的感知/决策/执行/反馈迭代技术、是否拥有丰富的垂直行业数据和专业知识;
  2. 企业更加关注落地效果和ROI:企业不再仅仅关注Agent的功能是否强大,而是更加关注Agent的落地效果和ROI(投资回报率),比如是否能够提高工作效率、是否能够降低运营成本、是否能够增加收入;
  3. 创业者更加专注于垂直细分场景:创业者不再试图打造“通用的AI Agent”,而是更加专注于垂直细分场景,比如医疗健康行业的病历管理助手、金融行业的发票审核助手、教育行业的作业批改助手等;
  4. 技术提供商更加关注工具链和生态建设:技术提供商不再仅仅提供大模型API,而是更加关注Agent的工具链和生态建设,比如提供向量数据库、工具编排平台、多智能体协作平台、长期记忆库管理工具等。

问题描述

在了解了AI Agent的核心概念、发展历史和当前的市场环境之后,我们可以正式进入困局分析阶段。AI Agent当前面临的商业化困局主要包括技术瓶颈困局商业模式困局两个方面,下面我将逐一详细描述这两个方面的问题。


3.1 技术瓶颈困局:从“感知-决策-执行-迭代”闭环模型的四大模块拆解

虽然大模型基座的出现解决了传统Agent“只能处理特定任务、难以理解人类模糊指令”的两大痛点,但“感知-决策-执行-迭代”闭环模型的四大核心模块仍然存在很多技术瓶颈,这些技术瓶颈是导致AI Agent无法真正落地到生产环境、实现规模化盈利的根本原因

3.1.1 感知模块的技术瓶颈

感知模块是Agent的“眼睛、耳朵和鼻子”,它的核心作用是从内部资源和外部资源中收集与当前任务相关的上下文信息,并将这些杂乱无章的原始信息编码成大模型能够理解的结构化状态向量或半结构化自然语言摘要。感知模块当前面临的技术瓶颈主要包括以下几个方面:

瓶颈1:多模态理解能力有限

虽然目前市场上出现了很多多模态大模型(比如OpenAI的GPT-4o、Anthropic的Claude 3 Opus/Sonnet/Haiku、Google的Gemini 1.5 Pro/Ultra、字节跳动的豆包4.0、阿里云的通义千问2.5等),但这些多模态大模型的理解能力仍然有限

  • 对于简单的多模态内容(比如一张带有文字的图片、一段带有语音的视频),这些多模态大模型的理解能力还可以;
  • 对于复杂的多模态内容(比如一张带有复杂图表的工程图纸、一段带有专业术语的医疗视频、一段带有多种语言和方言的音频),这些多模态大模型的理解能力就会大幅下降,甚至会出现严重的幻觉问题
  • 对于实时的多模态内容(比如自动驾驶汽车中的摄像头和雷达采集的实时数据、机器人中的传感器采集的实时数据),这些多模态大模型的推理速度太慢,无法满足实时性的要求。

为了更直观地理解多模态理解能力有限的问题,我们可以看一个简单的例子:假设我们让Agent帮我们分析一张带有复杂财务报表的图片,图片中的财务报表包含了资产负债表、利润表、现金流量表三张表格,并且这些表格的格式非常复杂(比如有合并单元格、有多层标题、有小数点后四位的数字)。对于这样一张图片,目前市场上的多模态大模型往往会出现以下问题:

  1. 识别错误:识别出来的数字和文字有很多错误(比如把“1,234,567.89”识别成“12,345,678.90”,把“净利润”识别成“毛利润”);
  2. 理解错误:无法理解财务报表中的专业术语和逻辑关系(比如无法理解“资产=负债+所有者权益”这个会计恒等式,无法理解三张财务报表之间的勾稽关系);
  3. 幻觉问题:会编造一些图片中不存在的数字和文字(比如编造一个“营业收入增长率”的数字,而这个数字在图片中根本不存在)。
瓶颈2:长文本语义分割与信息检索能力有限

虽然目前市场上的大模型的上下文窗口已经越来越大(比如OpenAI的GPT-4o Turbo的上下文窗口可以达到128K tokens,Anthropic的Claude 3 Opus的上下文窗口可以达到200K tokens,Google的Gemini 1.5 Pro的上下文窗口可以达到1M tokens,Meta的Llama 3 400B的上下文窗口可以达到128K tokens),但对于超长文本(比如一本几百万字的书、一份几千页的法律合同、一份几万行的代码库)来说,1M tokens的上下文窗口仍然是不够的——而且,即使大模型的上下文窗口可以容纳超长文本,大模型的推理成本也会非常高,推理速度也会非常慢,注意力分散问题也会非常严重(大模型往往会忽略超长文本中的重要信息,只关注开头和结尾的信息)。

为了解决超长文本的问题,目前市场上常见的解决方案是检索增强生成(RAG)——也就是先把超长文本分割成很多小的“ chunks(块)”,然后把这些chunks存储在向量数据库中,当用户输入一个问题的时候,先从向量数据库中检索出与问题相关的几个chunks,然后把这些chunks和用户的问题一起输入到大模型中,让大模型生成答案。

虽然RAG是目前解决超长文本问题的最常用的解决方案,但它仍然存在很多技术瓶颈:

  1. 长文本语义分割能力有限:如何把超长文本分割成合适的chunks是一个非常困难的问题——如果chunks太大,大模型的推理成本会很高,推理速度会很慢,注意力分散问题会很严重;如果chunks太小,chunks之间的语义关系就会被切断,大模型就无法理解整个超长文本的逻辑关系。目前市场上常见的语义分割方法包括固定长度分割固定句子/段落数量分割基于语义相似度分割基于文档结构分割等,但这些方法都存在一定的局限性;
  2. 信息检索能力有限:如何从向量数据库中检索出与问题相关的、高质量的chunks也是一个非常困难的问题——目前市场上常见的信息检索方法包括向量相似度检索关键词检索混合检索等,但这些方法都存在一定的局限性:
    • 向量相似度检索:只能检索出与问题在语义上相似的chunks,但无法检索出与问题在逻辑上相关但在语义上不相似的chunks(比如问题是“公司的净利润是多少?”,而相关的chunks是“公司的营业收入是多少?”和“公司的成本是多少?”);
    • 关键词检索:只能检索出包含问题关键词的chunks,但无法检索出与问题在语义上相关但不包含问题关键词的chunks(比如问题是“公司的盈利能力如何?”,而相关的chunks是“公司的净利润增长率是多少?”);
    • 混合检索:虽然结合了向量相似度检索和关键词检索的优点,但仍然无法完全解决信息检索能力有限的问题;
  3. 检索结果排序能力有限:如何把检索出来的多个chunks按照与问题的相关性从高到低排序也是一个非常困难的问题——目前市场上常见的检索结果排序方法包括向量相似度排序关键词匹配度排序基于大模型的排序等,但这些方法都存在一定的局限性,尤其是基于大模型的排序,虽然排序结果的质量很高,但推理成本也非常高,推理速度也非常慢。
瓶颈3:内部系统对接难度大

对于企业内部类Agent和垂直行业类Agent来说,内部系统对接是一个非常重要的环节——Agent需要对接企业内部的多个系统,比如ERP系统、CRM系统、OA系统、知识库系统、财务系统、人力资源系统等,才能收集到与当前任务相关的上下文信息。但内部系统对接的难度非常大,主要原因包括以下几个方面:

  1. 内部系统的接口标准不统一:很多企业内部的系统都是在不同的时间、由不同的供应商、使用不同的技术栈开发的,接口标准非常不统一(比如有的系统使用RESTful API,有的系统使用SOAP API,有的系统使用GraphQL API,有的系统甚至没有公开的API,只能通过数据库直接访问);
  2. 内部系统的文档不完善:很多企业内部的系统的文档非常不完善,甚至没有文档,Agent的开发者很难了解这些系统的接口参数、返回结果、错误处理方式等;
  3. 内部系统的权限管理复杂:很多企业内部的系统的权限管理非常复杂,Agent需要获得多个系统的不同权限才能收集到与当前任务相关的上下文信息,但权限的申请和审批流程非常繁琐,而且存在数据安全和隐私保护的风险;
  4. 内部系统的稳定性和可靠性差:很多企业内部的系统的稳定性和可靠性非常差,经常会出现接口超时、接口返回错误、系统崩溃等问题,这会严重影响Agent的感知能力和执行效果。

3.1.2 决策模块的技术瓶颈

决策模块是Agent的“大脑”,它的核心作用是将用户输入的模糊、抽象的高层级目标拆解成具体、可执行、有时间/预算/质量约束的子目标,为每个子目标选择合适的工具/API组合并确定调用顺序,预判可能出现的风险并制定对应的规避方案。决策模块当前面临的技术瓶颈主要包括以下几个方面:

瓶颈1:大模型的幻觉问题严重

大模型的幻觉问题(Hallucination)是指大模型会编造一些与事实不符的、或者不存在的信息。虽然目前市场上的大模型的幻觉问题已经比之前的模型(比如GPT-3)有所改善,但仍然非常严重——据OpenAI的官方数据显示,GPT-4o的幻觉率约为10%-15%,Claude 3 Opus的幻觉率约为8%-12%,Google的Gemini 1.5 Ultra的幻觉率约为7%-11%

大模型的幻觉问题对于Agent来说是致命的——因为Agent是基于大模型的决策来执行任务的,如果大模型的决策是错误的(比如编造了一个不存在的工具/API、编造了一个错误的工具/API参数、编造了一个错误的子目标),那么Agent的执行结果也必然是错误的,甚至会给用户带来严重的损失(比如Agent帮用户预订了一个不存在的机票酒店、Agent帮用户做了一个错误的投资决策、Agent帮用户签了一份错误的合同)。

为了更直观地理解大模型的幻觉问题对于Agent的影响,我们可以看一个简单的例子:假设我们让Agent帮我们预订一张“2025年X月X日从北京首都国际机场到上海浦东国际机场的国航CA1234次航班的经济舱机票”,然后Agent调用了大模型来规划工具/API的调用顺序和参数。如果大模型出现了幻觉问题,编造了一个“不存在的国航机票预订API”,或者编造了一个“错误的航班号CA1235”,或者编造了一个“错误的日期2025年X月Y日”,那么Agent的执行结果也必然是错误的——要么无法预订机票,要么预订了一张错误的机票。

瓶颈2:大模型的自主决策能力有限

虽然目前市场上的大模型(比如GPT-4o、Claude 3 Opus、Gemini 1.5 Ultra)已经具备了一定的思维链(CoT)思维树(ToT)思维图(GoT) 能力,但它们的自主决策能力仍然有限——主要表现在以下几个方面:

  1. 无法处理非常复杂的、多步骤的、跨系统的、有多个约束条件的任务:对于非常复杂的任务(比如“帮我筹备一场北京的、面向AI创业者的小型线下沙龙,预算5万以内,时间定在两周后的周六下午,邀请10位AI领域的知名专家作为嘉宾,吸引100位AI创业者报名参加”),目前市场上的大模型往往无法将其拆解成合适的子目标,或者无法为每个子目标选择合适的工具/API组合,或者无法处理子目标之间的依赖关系和冲突;
  2. 无法处理模糊的、不确定的、动态变化的环境:对于模糊的、不确定的、动态变化的环境(比如“帮我做一个股票投资决策,当前的股票市场非常不稳定,有很多不确定的因素”),目前市场上的大模型往往无法做出合适的决策,或者无法根据环境的变化及时调整决策;
  3. 无法处理道德、伦理、法律等方面的问题:对于道德、伦理、法律等方面的问题(比如“帮我写一份虚假的简历”、“帮我逃税”、“帮我侵犯别人的隐私”),虽然目前市场上的大模型都有一定的内容过滤机制,但仍然有很多大模型会做出违反道德、伦理、法律的决策,或者无法识别出这些问题。
瓶颈3:多智能体协作效率低

虽然多智能体协作系统(MAS, Multi-Agent System) 是解决单Agent自主决策能力有限的一个有效方法(比如我们可以把一个非常复杂的任务拆解成很多小的子任务,然后让不同的Agent来负责不同的子任务,比如一个Agent负责场地预订,一个Agent负责嘉宾邀请,一个Agent负责报名通道搭建,一个Agent负责物料准备,一个Agent负责预算控制,然后这些Agent之间相互协作,共同完成整个任务),但目前市场上的多智能体协作系统的协作效率仍然非常低——主要原因包括以下几个方面:

  1. Agent之间的通信协议不统一:目前市场上的多智能体协作系统没有统一的通信协议,不同的Agent之间很难进行有效的通信和协作;
  2. Agent之间的任务分配机制不合理:如何把不同的子任务分配给不同的Agent是一个非常困难的问题——如果任务分配不合理,就会出现有的Agent任务太多、有的Agent任务太少的情况,从而影响整个系统的协作效率;
  3. Agent之间的冲突解决机制不完善:当不同的Agent之间出现冲突的时候(比如负责场地预订的Agent预订的场地容量只有50人,而负责嘉宾邀请的Agent邀请了10位嘉宾,负责报名通道搭建的Agent已经吸引了80位AI创业者报名参加),如何解决这些冲突是一个非常困难的问题——目前市场上的多智能体协作系统的冲突解决机制非常不完善,往往需要人类的干预;
  4. Agent之间的信任机制不健全:如何让不同的Agent之间相互信任也是一个非常困难的问题——如果Agent之间的信任机制不健全,就会出现有的Agent不愿意共享信息、有的Agent不愿意执行任务的情况,从而影响整个系统的协作效率。

3.1.3 执行模块的技术瓶颈

执行模块是Agent的“手和脚”,它的核心作用是按照决策模块制定的调用顺序,向工具/API发送符合要求的参数,将工具/API返回的结果与决策模块制定的约束条件进行对比,处理执行过程中出现的异常。执行模块当前面临的技术瓶颈主要包括以下几个方面:

瓶颈1:工具/API的生态不完善

虽然目前市场上已经出现了很多Agent工具平台(比如OpenAI的Plugin Store、Zapier的AI Actions、Microsoft的Power Automate AI Builder、字节跳动的豆包插件中心、阿里云的通义千问插件中心等),这些工具平台提供了很多常用的工具/API(比如天气API、股票API、电商平台API、社交媒体API、飞书/钉钉/企业微信的API等),但**工具/API的

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐