为什么一定要做Agent智能体？

另外的一个定义是复旦大学NLP团队给出来的，他们认为Agent的概念框架包括三个组件：大脑、感知、行动^[2]。大脑模块作为控制器，承担记忆、思考和决策等基本任务。感知模块从外部环境感知并处理多模态信息，而行动模块则使用工具执行任务并影响周围环境。比如：当人类询问是否会下雨时，感知模块将指令转换为大模型可以理解的表示，然后，大脑会根据当前天气和互联网天气报告开始推理，最后，行动模块作出回应并将雨伞递给人类。通过重复上述过程，Agent可以不断获得反馈并与环境互动。

其实这些各种版本的定义实际上是对我们刚才所说的Agent代理「人」做某些事情的一个更细致的拆解而已，大家仔细想想，人要做某件事情，也是需要根据自己的记忆（学过的知识、当前事情的上下文），需要先规划这个事情怎么做，可能需要做一些思考、问题拆解，这中间也可能会使用各种各样的工具，最终通过某些动作、操作去把把某件事情完成。

因此，国内将Agent翻译为智能体，也是在表达，一个能规划、有记忆、能使用工具的东西，它又不是一个人，也不是一个动物，又不能直接将其描述为一个机器人（因为不一定是机器人形态，但有大脑），所以就给他起了个名字，叫“智能体”。

在文章的开头，我列出来了很多人反馈的Agent的几大挑战或者说缺点，但任何新兴事务或者技术在发明初期都会存在这样或者那样的问题或者缺点，如果只看缺点，不看优点，可能很难看清事务发展的方向。

那么，Agent的优势在哪里呢？Agent可以“代理/模拟”「人」来完成相关事情，它有一个非常聪明的大脑，甚至在很多领域比人都聪明，所以，从这个角度来看，Agent的出现，其实是“解放了人的生产力”，所以，从这个角度来说，Agent其实是一个极大提升效率的生产力。具体地，体现在下面几个方面，我将逐一展开分析。

首先，使用Agent智能体的第一个优势是降低了应用开发的成本和门槛。在工作和生活中，我们很多时候存在很多的需求，这些需求如果想要满足，要么就是寻找已经造好的轮子（比如现成的平台或APP），要么就是自己动手DIY一个定制化的轮子，那么就涉及到一个应用开发的问题。

过去，想要实现一个功能，我必须是一个专业的开发人员，必须能够编写专业的代码。但现在，如果你使用Agent而不是传统的硬编码方式，那么首先的好处就是你不需要编写代码，这降低了门槛。也就是说，如果我不是专业的研发人员，我是一个产品经理，或者是一个运营人员，我也可以通过自然语言描述prompt的方式实现一个Agent，来满足我的个性化需求的开发。这是需求开发的巨大的效率提升，也是应用开发的门槛的大幅降低。这是Agent与传统开发范式相比，最大的区别。

 美图秀秀（电脑版）中支持的许多功能是基于AI增强的

早年如果你想修图，你必须学习Photoshop，这也是为什么修图也叫P图的原因，因为其首字母就是P开头，要想修图就必须要会用这款软件。你需要学习Photoshop复杂的抠图功能和调色、调光能力。现在有了美图秀秀，你只需要打开APP，它就提供了一系列低成本的工具和AI能力，甚至能够快速让你的图片一键变美。无论是变瘦、磨皮变美，都可以分分钟做到，你要做的只是需要选择一下，点击一下，就可以完成。所以现在修图，真的不需要再去找专业的修图师，完全可以通过这些APP自己完成图片的美化和创作，同样的让P图技术不再是门槛，人人都是修图师。

而在大模型时代，Agent的目标是解放需求开发的生产力。假如你想要做一个APP、一个网站，或者一个小程序来满足个人需求，你以后应该也几乎不需要专业的软件开发团队来完成了，通过Agent，即使你是一个不懂前端、后端、算法，也不懂产品设计的人，也能轻松地用大模型做出一款GenAPP（生成式APP），让代码开发、参数配置的技术不再是门槛。

 通义智能体平台上有着许多Agent，他们其实都是GenApp

其实我们可以看到，现在有包括我们在内的很多头部厂商或独角兽已经在加大投入做Agent平台了，这些人的目标也是致力于让更多普通人通过简单的自然语言描述和极为简单的配置，最低成本地实现一个能够解决更复杂问题、执行更复杂任务的Agent。所以这个事情已经不是在未来了，而是已经是进行时了，相信不在远的将来，我们会迎来GenAPP的大爆发时代，人人都是开发者。

使用Agent的第二个优势是简化流程复杂度。大模型的引入，可以像“胶水”一样连接各个模块，比如能够自动处理参数转换、能够自动完成一些校验逻辑，这就极大的减少了流程配置的工作量。这种自动化的能力使得开发过程更加高效。

 传统的流程编排过程过于复杂

比如，在流程中通常会调许多API，如果是传统的流程编排，前一步的API返回结果传进来，与后一步API输入参数之间的映射，你必须得严丝合缝，包括变量类型和内容，你必须要有完备的转换过程，才能保证不会出现任何bug或错误。

但有了Agent之后，你不需要做那么完备，你可以让大模型在中间像“胶水”一样去连接各个模块。大模型就像「人」一样，看到问题、API接口、参数时，它会自然而然地做转换。它可以把用户的问题输入内容自然地转换到相应的API入参上。所以大模型或Agent的出现，它可以做这个粘合剂，把那些不完备的地方，通过模型本身的强大理解能力给弥补完备。就是这样的一个能力，会大大降低一个流程或一个GenApp的构建复杂度。上一步是构建降低了构建的门槛，不但不用写代码和配置，只需要写字就可以，一些不必要的中间过程逻辑也可以不写，只需要关注在最主要、最核心的流程上即可。

对于流程复杂性这一点，在算法模型层面尤为明显。例如，如果我想用传统的方式开发一个APP或功能，需要开发许多小模型来完成某些功能。比如，在一些流程的开头，可能会需要一个“路由”模块，在以往的情况下，这需要训练一个单独的路由模型，从而来判断问题或者意图需要路由到哪个分支。其他类似的，在流程中间涉及到需要算法模型参与识别的地方，我仍然需要去调用或者SFT一些小模型来处理这些单独的任务。每个单独的小模型的训练，都需要收集相应的数据集，构建相应的Label标签，然后训练，最终部署，并且这些小模型最终也就只能做这么一件事情。

但是，基于大模型的Agent实际上就极大的避免了这种流程的复杂性并降低了成本，你完全可以通过prompt来让大模型完成一个简单的操作。大模型甚至自己可以给自己写prompt、自己分解一个复杂问题，分解完之后它自己判断是否需要路由、是否需要中间调用某些识别能力、是否需要做某些判断，它自己完全就可以做好这些事情。也就是说，大模型以及Agent的出现，它不需要你去做一个这样非常“完备”的流程。

第三点个优势，是关于交互层面的，也就是说是LUI（自然语言交互界面）还是GUI（图形交互界面）的问题。诶？等等，不对啊，在前面不是说，大模型是基于自然语言进行交互的，因此纯文本交互不友好，这应该是Agent的一个缺点吧！怎么放在优势里面讲了呢？其实，与其说是一个缺点，不如说这是一个“误区”。其实，Agent智能体并不局限于自然语言交互，它是可以处理多种形式的输入和输出，包括图形界面和动作执行。这意味着Agent可以适应不同的应用场景，提供更灵活的解决方案。

前面讲过，什么是Agent？让大模型“代理/模拟”「人」的行为，使用某些“工具/功能”来完成某些“任务”的能力就可以定义为Agent。那么，你会发现，这里面其实并没有提到交互的问题，并没有来说必须是自然语言交互还是什么其他形式的交互，所以，自然语言的交互界面，只是人和大模型、接口和大模型之间的交互方式，并不意味着Agent也要以自然语言的形式与大模型进行交互。

给大家看几个非自然语言交互的Agent的例子，大家就能看明白了。比如，国外大模型厂商Anthropic发布过一款控制电脑使用的Agent^[3]，其效果比较惊艳，大家可以点此查看演示视频(https://www.youtube.com/watch?v=ODaHJzOyVCQ)：

 Anthropic研发的可以自主控制电脑的Agent

Anthropic的这个Agent，他可以帮我打开电脑上的某个浏览器，甚至都不需要指定浏览器的名称，只说帮我打开浏览器，帮我输入某个网址或打开某个网页搜索什么关键词，点击某个步骤就可以。可以完全用自然语言描述这个需求，描述完毕后，大模型在实际运行的时候，它会直接上去操作。它通过截图，然后给大模型通过多模态识别去获得屏幕上的内容，然后自己判断屏幕上哪个图标是浏览器，自己完成点击操作，然后自己去找哪个地方是地址栏，自动把你说的网站转换成网址填进去，然后帮你搜索东西。整个过程，只有输入是自然语言，但输出其实就是一个系列的操作动作的执行。

再比如，微软发布了十款非常受欢迎的Agent^[4]，其中有一个是供应链分析Agent，它会通过自主跟踪供应商的表现，检测供应链延迟并做出响应，帮助企业优化供应链，让采购团队摆脱耗时的手动监控，减少供应链中断带来的额外成本。

 微软供应链分析Agent可以自主分析供应链延迟检测

在这个Agent里，输入都不是自然语言了，它们可能是一些预设的要求、选项或表单，让用户去交互。交互完毕后，它背后会整理成一个自然语言给到大模型，让大模型完成一些任务。比如，帮我分析这一周的销售情况，你可能就在前端的表单里选个时间，但背后的执行、分析、报告生成过程，是大模型自主思考去完成的。并且，最终生成出来的报告也并非是以自然语言形式，它是直接渲染成了一个图表、表格等在内的各种展示形式的集合体，甚至还有一些曲线预测这样的内容。

综上所述，挑战Agent是以对话形态为主的交互，其实是一个伪命题。Agent并不是一定是以纯自然语言形式去进行交互的，并且这在Agent的定义里面本身也是没有的。

最后，有一个现在非常火热的Agent热点，就是多Agent（Multi-Agent），Agent的存在形式并不是仅仅是单一的功能了，而是可以进行各种各样的组装、协同、竞争^[2]。

 多Agent的协同模式，如合作方式、竞争方式等

比如多个Agent之间进行组装完成一些复杂的场景，比如在服务领域的某些工单里面，经常会出现客户在同一个工单中连续问多个问题，这个时候，就完全可以调用多个处理不同问题的Agent参与决策进行合作，就像人一样进行接力，把问题解决。有些时候，也可能会面临一些疑难杂症的问题，也可以有多个领域相关的Agent来进行专家会诊，甚至Agent之间都可以相互交流，最终讨论、解决同一个问题。

Agent之间也可以进行竞争，多个子任务Agent给出了多版不同方案，由一个决策Agent或者人来最终决定要使用哪款子任务Agent给出的方案等等。

甚至还有不少人在设想未来会出现由多个Agent组成的社会，甚至人类也可以参与其中。下面这张图就展示了这个多Agent社会中的一些特定场景。在厨房中，一个Agent负责点菜，另一个Agent负责规划和解决烹饪任务。在音乐会中，三个Agent正在合作参与乐队演出。户外有两个Agent正在讨论灯笼制作，计划所需的材料和财务，并选用工具。人可以参与这个社会活动的任何阶段，这个社会就仿佛一个小的世界一般。

 一种假想的多Agent社会

现在让我们继续把注意力转回到开篇我们讲的几点Agent的挑战，其中第三点关于交互的在前文中已经讲过了，现在说一下另外两个挑战。当然，只要是现在神经网络架构下的大模型，就仍然存在之前提到的速度慢以及幻觉问题。但是，其实这些问题一直在不断由各种方案优化中。

首先，在速度方面，我们已经可以看到许多公司通过芯片级别的提升，比如通过提升GPU的性能，或者在GPU上实现更多其他的芯片层面加速。也有许多像FlashAttention、vLLM这样的大模型部署框架，通过对Transformer中KV Cache的优化来提升推理速度等等。还有一些方法是通过减少模型的参数量，舍弃一些无用的参数，只保留重要的参数信息，尽量保持效果不变，这就是模型参数裁剪。还有使用更小参数的模型去针对大参数量的模型做模型蒸馏，其他的还有各种量化技术等等。

通过这些从硬件到软件层面的优化，是可以不断的提高模型的运行效率的。当然，除了模型层面的优化之外，还有许多在工程层面的优化，比如对于大文本、大文档的读取，可以使用预处理的方式将其切块，对于一些冗长的Prompt，可以做一些Prompt层面的信息压缩，从而提高大模型的响应速度等等。

    AI芯片、优化KV Cache等各种大模型推理加速优化方案

至于幻觉问题，现在大部分的模型随着不断的迭代、更新，在Prompt写的比较明确的情况，基本上很少出现太离谱的事实性错误幻觉，更多是指令写的不明确，存在歧义，大模型没按照预期的情况去输出，导致被大家定义为了幻觉。这种情况，我们也会去引导Prompt的规范化书写，甚至还有一些类似于OpenAI的Meta-Prompting项目^[5]，用Meta-Prompt指导大家优化Prompt的方案，也能进一步提升大模型对指令跟随的能力，产出更符合期望的Agent。

同时，在模型推理层面，像DeepSeek R1或OpenAI o1/o3系列模型，基于慢思考的System2，通过引入hidden-thought等方法进行reasoning推理，从而提升了大模型的理解能力，进一步减少幻觉的比例。其他的还有类似GraphRAG等方案，在RAG中引入知识图谱推理，也能进一步减少大模型的幻觉比例，提升大模型的准确性和理解能力。

这里我提前预告一下，在提升大模型的运行速度和降低幻觉这方面，我们也在探索一些新的方法，从而来优化Agent的速度和稳定性。比如说我们在研究一种Agent预编译能力，即会去让大模型自动拆解哪些部分不需要大模型的参与，哪些部分就可以在Agent构建阶段进行提前预编译，这样在真正线上执行Agent时，大部分的场景下是不需要大模型参与实时生成的，只需要大模型参与必要的部分生成，从而缩短大模型的推理时长，并提高稳定性。

综上所述，我们可以看到，尽管大模型存在着一些挑战，但是通过不断的技术创新和优化，我们正在努力提升Agent的性能和稳定性，降低幻觉的比例，使其更加高效和可靠。相比这些缺点（更何况未来会逐步解决），Agent的优点显然是更值得我们继续投入下去的动力，总而言之，一句话来说就是：做Agent相比不做Agent利大于弊，是一个值得我们长期重点投入下去的能力和形态。

经过上述的分析和例子，我们可以看到做Agent相比不做Agent的优势是显而易见的。尽管现在的技术手段上存在一些问题和挑战，但这些短暂的问题不应该直接否定Agent发展前景，而是应该更加坚定的正确的方向上不断推进，继续优化Agent平台和能力，尽量减少问题的出现。

哲学里面有个基本规律叫“否定之否定”，历史的发展总体进程一定是“曲折向前”的，甚至是螺旋式发展，在新旧事物交替的期间，甚至很容易出现新旧事物杂糅的情况。 

但我也能理解，任何事物的出现需要一定的时间去让大家接受，甚至很多创新、变革都是渐进式发生的，很难一蹴而就。但我们要做的，就是努力缩短像“马拉火车”这样的过渡阶段出现的时间，尽可能更加从本质上去提升生产力和效率，让新技术快速落地，避免陷入和老技术纠缠不清的泥潭和历史债务之中。

/END/

来源：阿里云开发者公众号