侧边栏壁纸
博主头像
MobotStone AI

行动起来,活在当下

  • 累计撰写 11 篇文章
  • 累计创建 3 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录
MCP

为什么非要使用Agent?它对业务有什么实际好处?

Administrator
2025-04-29 / 0 评论 / 8 点赞 / 287 阅读 / 0 字

我们团队这一年多一直在开发和优化服务领域的Agent功能,我本人也花了大量时间在这上面。但在实际推广Agent技术时,经常有人问我:为什么非要使用Agent?它对业务有什么实际好处?

提出这个问题的人很多,原因也很简单:在很多业务场景下,Agent本质上就是用大模型分步骤执行任务。同样的功能,其实可以通过传统方式实现,比如:

  • 直接编写代码(硬编码)

  • 使用低代码平台(比如SOP配置工具、流程编排系统等)

具体来说,Agent就是用大模型调用API来完成多步骤操作,但这完全可以用代码实现,或者用低代码平台配置表单、逻辑和API接口,通过参数传递来构建流程。所以问题的本质就是:Agent能做到的事,没有Agent的时候也能做。

而且,用大模型开发Agent还面临不少问题,最主要的有三个:

  1. 速度慢: Agent需要调用大模型,而大模型通常是逐字输出结果。用户可能要等十几秒才能看到完整响应,如果提示词较长,连第一个字的响应都会延迟。再加上Agent需要思考、推理,有时还要分解任务,整个过程就更慢了。

  2. 可能出错: 大模型本身就可能产生错误信息或不按指令执行,这种不可靠性比速度慢更严重,直接影响用户信任。

  3. 交互体验差: Agent主要通过文字对话交互,输出往往是一大段话,阅读起来很费劲,远不如传统网页的表单、卡片式界面友好。

相比而言,传统方式开发的流程有明显优势:

  • 运行速度快

  • 稳定可靠

  • 可以定制专门的用户界面

所以在服务领域,既然传统方法(如SOP系统、流程管理平台)也能处理复杂任务,而且更快、更稳、交互更好,为什么还要用Agent?为什么还要开发Agent平台?尤其是在Agent存在速度慢、可能出错、体验差的情况下。

这个问题我反复思考过,也在不同场合解释过。现在我想通过这篇文章,系统地分析"为什么要做Agent"这个核心问题。

1. 什么是Agent

在讨论“为什么要做Agent”之前,我们需要先明确Agent是什么。很多人可能会简单认为Agent就是“大模型调用API”,但这只是最基础的理解,真正的Agent概念更深入。

在国内,不少厂商把Agent翻译成“智能体”,但严格来说,这个词并不能完全体现Agent的含义。如果查英文词典,“Agent”的核心意思是“代理”。我理解的Agent是指:让大模型替代人类的行为,通过调用某些工具或功能来完成特定任务的能力。因此,国外用“Agent”这个词来指代大模型使用工具帮人干活的流程,其实相当贴切。符合这个定义的,都可以算作Agent。

许多权威机构也对Agent下过定义。比如,OpenAI的研究主管Lilian Weng就提出:

Agent = 大模型(LLM)+ 规划(Planning)+ 记忆(Memory)+ 工具使用(Tool Use)

这个定义从技术实现的角度解释了Agent——真正的Agent不仅仅依靠大模型,还需要具备以下能力:

  • 规划(Planning):能思考下一步怎么做

  • 记忆(Memory):能存储和调用长期或短期记忆

  • 工具使用(Tool Use):能调用外部接口或功能

也就是说,Agent是这些能力的综合体现,而不是单纯的大模型调用API。

另外复旦大学NLP团队给出了一个不同的Agent定义框架,他们把Agent分成三个核心部分:大脑、感知行动[2]。

  • 大脑:这是Agent的控制中心,负责记忆、思考和做决策。

  • 感知:这部分负责获取信息,让Agent能"看懂"或"听懂"外界的信息,处理文字、图像、语音等多种输入。

  • 行动:这部分让Agent能调用工具来完成任务,比如执行某个操作,或者与环境互动。

举个例子:当有人问"今天会下雨吗?"时——

  1. 感知模块先理解这个问题,转换成大模型能处理的形式;

  2. 大脑会根据天气数据和网络上的天气预报进行分析判断;

  3. 行动模块最后做出回应,甚至可以直接递给用户一把雨伞。

通过这样的循环,Agent能不断接收反馈,与环境持续互动,变得越来越智能。

上面介绍的各种定义,其实都是在进一步细化我们之前说的"Agent代理人类完成事情"这个概念。我们仔细想想,人类做事的过程也是这样:

  1. 依赖记忆:调用已知知识,考虑当前情况的背景信息

  2. 进行规划:先思考怎么做,可能要分步骤解决问题

  3. 使用工具:过程中会借助各种外部资源

  4. 执行动作:最终通过具体操作完成任务

所以,Agent实际上是在用类似人类的方式解决问题。国内之所以把Agent翻译成"智能体",是因为需要找一个合适的词来描述这种能规划、有记忆、会使用工具的实体:

  • 它不是真人

  • 不是动物

  • 也不一定是有实体的机器人(虽然具备类似"大脑"的功能)

"智能体"这个名称比较准确地抓住了这类系统的核心特点。

2、Agent的优势

在文章开头,我列举了很多人提出的Agent目前存在的问题和不足。但是我们要知道,任何新技术在发展初期都会经历这样的阶段。如果我们只关注它的缺点,就会忽略这项技术真正的价值和发展前景。

我们可以参考历史上蒸汽火车的例子。当火车刚被发明出来时,很多人指出了它的缺,然而历史证明,火车最终还是取代了马车。如果当时仅仅因为这些初期问题就放弃发展火车,那就太短视了。因为火车相比马车具有显著优势:

火车早期缺点

火车最终优势

马车固有缺陷

依赖固定轨道

运行速度提升5-10倍

最高时速仅15-20km

煤炭消耗大

运输效率提高20倍

载重能力有限

初期事故率高

行驶平稳性大幅改善

剧烈颠簸不适

建设成本高

单位运输成本下降90%

饲养维护成本高昂

这个例子告诉我们,对待新兴的Agent技术也应该保持同样的眼光。我们要看到它具备的潜力和优势,而不是因为暂时的不足就否定它的价值。

那么,Agent到底有什么好处呢?简单来说,Agent能帮人干活——它能「代替人」完成各种任务,而且它很聪明,在很多事情上甚至比人类做得更好。本质上,Agent的出现就是为了帮人从重复劳动中解放出来,让我们的工作效率更高。具体来看,Agent的优势主要体现在以下几个方面(后面会详细分析):

3、开发变得更简单

使用Agent的第一个关键好处是:让制作应用程序变得更方便、更省钱。日常生活中我们经常遇到各种需求,要解决这些需求通常只有两个选择:要么直接用别人做好的工具(比如现成的软件),要么自己从头开发一个定制化的工具——这就涉及到编程开发的问题。

以前要实现一个功能,你必须是个专业程序员,必须会写代码。但现在,用Agent代替传统编程方式,最大的改变就是你不需要懂代码了。即使你不是程序员,只是个普通的产品经理或者运营人员,只要能用日常语言描述清楚需求(通过写prompt),就能自己创建一个Agent来解决问题。这不仅大大提高了开发效率,更重要的是让普通人也能自己做工具了。

可能这样说还是有点抽象,举个现实中的例子:就像剪映这样的视频剪辑软件,让不会专业剪辑的人也能轻松做视频。

过去制作视频需要专业技能,特别是剪辑环节成本很高。剪辑不只是简单拼接片段,还需要调整转场效果、添加各种特效元素,甚至精确到每一帧来编辑字幕。但现在的剪映这类工具带来了明显改变——它们提供大量现成模板和AI功能,让普通人也能轻松制作视频。

与早期软件相比,剪映的优势在于:

  1. 直接可用的素材:内置丰富转场、特效模板

  2. AI自动化功能:包括智能剪辑、素材生成,最实用的是AI自动加字幕

(以前人工加字幕需要一整天,现在AI几分钟就能完成,只需简单校对即可)

这种改变极大地降低了视频制作难度,让更多没有专业背景的人也能产出优质内容。短视频平台(如抖音、B站、小红书)能快速崛起的关键原因之一,正是这类工具让制作视频不再困难——当技术不再是障碍,创意就成了核心,真正实现了"人人都能当剪辑师"。

另一个类似的例子是美图秀秀。以前想要修图,必须学习专业的Photoshop软件(这也是"P图"这个说法的由来)。你需要掌握复杂的抠图、调色、调光等专业技能。但有了美图秀秀后,普通人也能轻松实现照片美化——打开APP就能使用各种简单工具和AI功能,一键瘦脸、磨皮、美颜,只需轻轻点击就能完成。

这种变化让专业修图师不再是必需品,普通人也能成为修图师。类似的,在大模型时代,Agent的目标是降低开发门槛。未来如果你想做个APP、网站或小程序,可能不再需要专业开发团队。即使不懂前端、后端、算法这些技术,通过Agent也能用自然语言直接生成应用(GenAPP),让代码和参数配置不再是障碍

实际上,目前已经有不少头部科技公司和独角兽企业(包括我们)正在全力开发Agent平台。这些平台的目标很明确:让普通人通过简单的文字描述和基本设置,就能低成本地开发出能处理复杂问题的智能助手(Agent)。

这件事不是未来的设想——它正在发生。可以预见,我们很快会进入"GenAPP"的爆发期。到那时,人人都能成为开发者,技术门槛将不再是障碍。

4、简化流程复杂度

使用Agent的第二个优势是降低流程复杂度。接入大模型后,系统能够自动完成参数转换、执行校验逻辑等步骤,直接把不同模块串联起来。这种自动化处理大幅减少了手动配置的工作量,让开发变得更高效。

在传统流程开发中,调用多个API时需要严格对齐前后流程的数据格式。前一个API的输出必须完全匹配后一个API的输入,包括变量类型和内容转换,必须手动配置所有转换逻辑才能避免出错。而使用Agent后,大模型可以自动处理这些转换,无需完全手动配置。它能像人一样理解问题、API接口和参数,自动完成格式转换,从而大大简化流程搭建的复杂度。

这种简化在算法模型开发上更加明显。以前开发一个功能需要训练多个小模型——比如流程开头的"路由"模块需要单独训练模型来判断用户意图该走哪个分支,中间的识别任务也需要单独训练专用模型。每个小模型都需要收集数据、标注、训练和部署,最终只能完成单一功能。

但基于大模型的Agent可以大幅降低这种复杂度。通过自然语言指令(prompt)就能让大模型完成操作,包括自动分解问题、判断是否需要路由或调用其他功能。大模型甚至能自己优化指令,完全不需要人工搭建复杂的完整流程。

5. 交互方式多样化

第三个优势体现在交互方式上——不论是自然语言交互(LUI)还是图形界面交互(GUI),Agent都能灵活适配。有人可能会疑惑:“前面不是说大模型主要基于自然语言交互吗?纯文本交互不方便,这不是Agent的一个缺点吗?” 其实,这种看法是一个误区。Agent并不局限于自然语言交互,它可以处理多种输入和输出形式,包括图形界面指令和具体操作执行,因此它能适应不同场景,提供更灵活的解决方案。

前面提过 Agent 的定义:让大模型“代理”人类行为,通过特定工具或功能完成任务的能力。这里并没有限定交互方式——自然语言只是人与大模型、系统与大模型沟通的一种方式,并不意味着Agent本身也必须依赖自然语言来交互

举几个实例帮助理解:比如国外AI公司Anthropic曾发布过一款控制电脑操作的Agent[3],效果非常出色(演示视频)。这类Agent直接接收并执行操作指令,而不依赖文本对话,证明了交互方式的多样化可能。

Anthropic的这款Agent能直接操作电脑完成任务。比如你只需要说"帮我打开浏览器并搜索某个关键词",它就会自动执行:首先识别屏幕上哪些是浏览器图标并点击打开,然后找到地址栏,输入你说的网址或关键词进行搜索。整个过程完全只用自然语言输入需求,而Agent会将这些指令转换成一连串的实际操作动作。

另一个典型的例子是微软开发的热门Agent应用[4]——供应链分析Agent。它能自动追踪供应商表现,及时发现供应链延迟问题并做出响应。这个功能让采购团队不再需要花费大量时间手动监控,帮助企业降低供应链中断造成的额外成本,提高供应链管理效率。

在这类Agent中,用户交互可能完全不需要输入自然语言,而是通过预设选项、表单或按钮进行操作。用户完成交互后,系统会自动将这些选择转换成自然语言指令发送给大模型处理。比方说,当你需要分析某周的销售数据时,可能只需要在前端界面选择相应的时间范围,剩下的分析、计算和报告生成工作会由大模型自动完成。最终呈现给你的也不是一段文字,而是自动生成的图表、数据表格、趋势曲线等可视化结果。

所以,认为"Agent必须通过对话形式交互"其实是个误解。Agent并不局限于自然语言交互方式,这在Agent的基本定义中也没有强制要求。它的核心在于智能完成任务,至于交互形式,完全可以根据实际需求灵活选择。

6、多Agent协同完成任务

如今最热门的Agent发展趋势之一就是多Agent系统(Multi-Agent)。现在的Agent不再是单一功能的工具,而是能够进行多种形式的组合、协作和竞争[2]。

举个例子,在处理服务业工单时,客户经常会在同个工单中提出多个问题。这时候可以同时调用多个专业Agent协作处理,就像团队接力一样逐步解决问题。对于特别复杂的问题,还能让不同领域的Agent像专家会诊一样共同讨论,甚至互相交流意见,最终找到解决方案。

Agent之间也可以产生竞争关系。比如当多个子任务Agent各自提出不同方案时,可以由一个决策型Agent或人工最终选择最优方案。

更有趣的是,现在很多人正在设想未来会出现由多个Agent组成的社会系统。就像下面这张图展示的场景:在厨房里,一个Agent负责接收点单,另一个负责安排烹饪流程;音乐会上,三个Agent协作演奏;户外有两个Agent正在讨论制作灯笼的材料、预算和工具选择。人类可以随时参与这些社会活动的各个环节,整个系统就像一个小型世界在自主运转。

7、解决Agent面临的实际问题

之前我们讨论过Agent发展面临的几个关键挑战,其中交互问题已经详细解释过了。现在我们来重点说说另外两个主要问题:运行速度慢和幻觉问题。需要说明的是,只要是基于当前神经网络架构的大模型,这两个问题就必然存在,但好消息是行业已经找到了很多解决方案。

关于运行速度的提升,主要有以下几种方式:

  • 硬件层面:很多公司正在通过升级GPU性能,或者开发专用AI加速芯片来提速

  • 算法优化:像FlashAttention、vLLM这类框架,通过优化Transformer中的KV Cache来提升推理效率

  • 模型精简:采用模型裁剪技术去掉冗余参数,或者使用模型蒸馏让小模型学习大模型的能力

  • 量化压缩:通过降低模型数值精度来减少计算量

  • 工程优化:比如对大文本进行预处理分块,或者优化prompt结构来提升响应速度

至于大模型的"幻觉"问题(即事实性错误),现在新一代模型在这方面已经有了很大改善。当前出现的问题更多是因为指令不明确导致的误解,而非纯粹的胡言乱语。针对这个问题,主要解决方案包括:

  • 规范prompt书写,比如OpenAI的Meta-Prompting项目

  • 采用DeepSeek R1等具备"慢思考"能力的模型增强推理

  • 使用GraphRAG等技术,让检索系统能够做知识图谱推理

  • 开发专门的"系统2"推理模型来提高理解能力

我们团队也在开发创新方案来优化Agent性能,比如:

  • "Agent预编译"技术:提前确定哪些任务需要大模型参与,哪些可以预先生成

  • 模块化执行:在运行中只调用必要的生成模块

虽然挑战依然存在,但通过持续的技术突破,Agent的效果和可靠性正在稳步提升。综合来看,发展Agent技术的利远大于弊,这确实是一个值得长期投入的重要方向。

8、总结

通过前面的分析和案例对比,我们可以清楚地看到,开发Agent带来的优势远远超过不开发。虽然现有技术还存在一些问题,但这些只是暂时的挑战,我们不能因此否定Agent的价值,而是应该坚持这个方向,持续优化Agent平台的能力,逐步解决出现的问题。

在哲学中,有一个基本原理叫“否定之否定”,意思是事物发展的总体趋势是“曲折前进”的,甚至可能是螺旋式提升。在新旧技术交替的阶段,往往会出现新旧方法混合使用的情况。就像姜文导演的电影《让子弹飞》(经典!)里的一幕:几匹马拉着火车在铁轨上跑——这种“马拉火车”的场景,在清末民初确实短暂出现过。人们既不愿意完全放弃马车,又想尝试新技术的火车,于是就有了这种看起来很别扭的过渡方案。当时的顾虑可能包括担心火车跑得太快、煤炭供应不足,或者担心马匹“失业”等等。最终,这些犹豫和妥协催生出了“马拉火车”这种奇怪的组合。

我们需要认识到,任何新事物都需要时间去适应和接受,大多数创新和改变都是逐步推进的,很难一步到位。但我们的目标应该是尽量缩短"马拉火车"这样的过渡期,真正着眼于提升生产力和工作效率,推动新技术快速投入使用,避免长期陷在与旧技术的反复磨合和历史包袱之中。

8
博主关闭了所有页面的评论