智能机器应用进化之路——从语言理解到自主决策
前文已详尽探讨了AI大模型的诸多知识与概念,但如何准确领会它们并将其融合,以便更轻松地把握它们在实用中的角色呢?此前我们进行了横向的阐述与剖析,接下来将对AI大模型应用的纵向演进做一综合审视。
人类的终极追求是什么?就是让机器“为我所用”,使自身彻底解放。尽管这个愿景尚很渺远,但总要迈步向前,方有实现的可能。那么首要一步是什么?自然是让机器能领悟人类的语言。于是,程序员应运而生,他们借助多样的编程语言,完成人类自然语言到机器可辨识的“言语”——二进制流的转换任务。但这种途径,不可否认,代价极其高昂,它妨碍了人对机器的驾驭,有时甚至被机器反过来束缚。 因而,AI大模型应用的首步,便是攻克自然语言的理解(吸纳)和反馈(输出成果)。这种与AI大模型的交互本领,是成就一切AI大模型应用的基础。当然,伴随需求的持续演进,这个自然语言也在不断拓宽,它不仅涵盖人们通常认知的语言,也囊括人类产生的各类文件、图像和音视频等素材。 而随着进一步推进,人们察觉,可将工业生产中的作业流(workflow)引入大模型,在输入输出与AI大模型间增设一个作业流机制,以便能迅速提升效率,减少各种突发状况的处置。
但很快,人们就意识到,作业流有其局限。正如现实世界中的作业流一样,它通常只适用于一些固定场景或动态性要求极低的情形。但人类对大模型的应用千差万别,该如何应对? 恰如编程语言中所言,添加一个中间层。这样智能体就登场了。智能体相当于在人类与大模型间安插了一个代理,可间接理解为它是一个自动化的程序员,对人类所需的输入和输出进行决断、整合。通过对提示语或结果加以处理,将正确的信息馈入大模型,将大模型产出的结果“转译”为人类的自然语言并回馈结果。更关键的是,它能通过函数调用(Function Call)和ReAct实现与AI大模型自动进行多轮处置,并达成人类最渴求的结果。
到了智能体阶段,大体上人类与大模型的交互压力已大幅减轻。但这又引出另一个问题,智能体在函数调用和调用各类工具时,发现种类繁多。这么说吧,有点像晚清时期为了组建新军,采购了万国品牌的枪械。这就导致了一个灾难性的难题,即便是同一类型的调用,接口也可能不统一,都需要开发者对其进行二次包装。而且AI大模型的不同,又会产生同样的调用也要再次包装一回。这样就形成了一个N乘N的映射,大量工作纯属浪费。 这时,定有聪慧的人会想到,能否把接口封装成统一标准,好,太妙了。这就是MCP出现的缘由。要形成标准,就必须有标准的协议,这就是MCP,从而形成了规范化的接口调用流程。它有些类似电脑中的可插拔USB接口,不管你是什么品牌、容量多大、速度快慢都能自动进行识别并转换成标准协议。 借助MCP,实现了智能体驱动这些工具为大模型所用的一个标准化应用接口实现。MCP的出现,极大卸下了开发人员的重担,将N乘N解耦成了一对一,提高了效率。
但这随即又浮现一个问题,MCP的出现又带来了开发门槛提升,需要学习各种MCP的内容;还有,众多现实世界中的需求和工具频繁变动,MCP无法灵活地应对。特别是在专业级的大型企业和工业应用中,繁复的技术往往让开发者头疼。另外还有一个重要的问题,MCP如此关键,是不是智能体没多大功效了?或者它只是一个MCP的简易封装调用? 现在梳理一个问题,假设要制造一条香肠流水线,怎么做?可以先搞一个切肉的装置,再搞一个粉碎的装置,再找一个搅拌的装置,再找一个塑形打包的装置,这不一条最基础的流水线就成了。而这些装置完全可以由一到多个厂家来制作,最后组装调试即可(当然实际可能没这么简单)。 智能体类似于流水线,它可以把专业性的问题和经验通过一定策略进行调用,并通过MCP实现对所需工具接口的调用,然后在人类和AI间中转处理。而这些专业复杂的问题就可以让专业人士编写成技能供开发者直接调用即可。MCP只是智能体为了实现处理的工具所需的一环。 也就是说,智能体作为主导,进行更进一步的抽象,不再依赖开发者对具体场景的专业技能,而把这个专业的技术应用抽象为专业人士的文档或低代码(非常简单)调用。这样,不同的场景就会有不同的技能,最终实现智能体的强大功能。另外技能的出现,也解决了另一个问题,就是一次进一次出的问题。而形成了一个循序渐进的过程,即前面讲的“渐进式披露”。通过从整体(目录)到具体(技术说明)执行的可控流程即动态的加载所需要的相关说明。 这样,智能体即可通过技能获取整体的目录,又可以根据需要通过目录获取具体的说明书,然后利用MCP调用工具辅助实现所需。使得智能体真正的成为一个“智能体”。 当然,在此基础上的一定还会不断演进和进步。毕竟作为一个火爆的应用,变化之快,很可能让人难以想象。
通过上面的剖析,有过编程经验的会不会察觉,它和编程语言演进过程中的单体程序到库到框架、各种数据接口和访问标准、状态机和自动机等有着相似的发展历程。也就是说,不管技术如何前行,技术处理人类问题的思维始终保持着同一个脉络,这就明了为什么总是反复强调编程思想至关重要的缘由了吧。