简介(未完成)
比尔·盖茨：AI Agent将彻底改变人类生活方式尽管软件在过去几十年里取得了显著的进步，但是，从很多方面来看，它依然有些 “笨拙”。在计算机上完成任务时，你需要告诉设备使用哪个应用程序。例如，你可以用微软 Word 和谷歌文档撰写商业提案，但它们无法帮你发送邮件、分享自拍、分析数据、策划派对或购买电影票。即便是最优秀的网站，也只能片面地了解你的工作、个人生活、兴趣及人际关系，在利用这些信息来为你服务方面能力有限。但在未来五年内，这一切将彻底改变。你不再需要针对不同的任务使用不同的应用。你只需用日常语言告诉你的设备你想要做什么，软件将能够根据你愿意分享的信息量做出个性化的回应，因为它将深入理解你的生活。在不远的将来，任何联网的人都将能夠拥有一个由 AI 驱动的个人助理，其能力将远超现今的技术水平。这种能够理解自然语言并根据对用户的了解来完成多种任务的软件，被称为 “Agent”。PS：各个app 不再直面用户，而是通过接入Agent，由Agent来完成和用户之间的交互，Agent 将成为下一个平台。具象化一下，就是钢铁侠中的Javis。
Agent不只是一个工具
- 一开始大家玩 Prompt 工程（把大模型当做工具来调用，工具模式），接着是Prompt Chain或Flow，再到Agent，多Agent，很清晰的一个脉络架构。
- 我们回到 Agent 这个概念上，实际上，人类是这个星球上最强大的 Agent。Agent是一个能感知并自主地采取行动的实体，这里的自主性极其关键，Agent要能够实现设定的目标，其中包括具备学习和获取知识的能力以提高自身性能。Agent 的复杂程度各不相同，一个简单的恒温器可以是一个 Agent，一个大型的国家或者一个生物群体也可能是个 Agent。感知环境、自主决策、具备行动能力，设定明确的目标和任务，适应环境及学习能力，都是 Agent 的关键特点。
- 我们认为Agent技术是未来实现社会全面自动化的关键技术。在大模型出现之前，自动化更多的是一些偏结构化固定模式环境中通过实现固定算法流程来完成自动化任务，而大模型智能体的通用性带来了灵活性，使其可能应对人类在脑力劳动中面临的各种复杂长尾任务，进一步实现体力和脑力任务的全面自动化。PS：LLM本质是文字接龙，看你让大模型接什么，如果使用大模型接出来的东西。有点一生二、二生三、三生万物的意思，就好像无论汽油机、还是电动机，基本的动力输出形式是转圈圈，但是经过一些机械传导，可以转为各种机械运动形式：水平、垂直（打夯机）、椭圆运动等等，简单机械运动组合起来可以进行复杂机械运动比如纺织机，进而推动了大部分手工劳动的自动化。
- 在通用人工智能（AGI）的漫长旅途中，大模型虽显强大，仍存在着显著的技术天花板。许多人开始探索如何挖掘大模型在大任务执行能力上的可能性，其中一个基本策略就是能够分解和组合。例如，经典的 MapReduce 模式可以将一个大型文本进行摘要，因为它的上下文有限，一种解决办法是扩大 context 的范围。另一个解决方案是，在有限的 context 中，我们先将文本拆分成小片段，对每个片段进行摘要，然后再将其组合，从而得出结果。大家也发现大模型直接给出答案似乎并不靠谱，那么是否可以让它像人类一样，一步一步思考呢？毕竟，人类在解决问题时，也是逐渐构建解决方案，而并非立即给出答案。因此，开始出现了一系列的尝试解法，比如思维链、多思维链、思维树和思维图等。上述的讨论主要是任务分解和组合，他们尽管强大，却不能与外界进行互动，这就不得不讲到反馈机制了。反馈是整个控制论的基石，也是动物体从诞生之初就具备的基本能力。最经典的方法实际就是 ReACT，ReACT让大模型先进行思考，思考完再进行行动，然后根据行动的结果再进行观察，再进行思考，这样一步一步循环下去。这种行为模式基本上就是人类这样的智能体主要模式。
- 众人熟知的认知飞轮，感知、认知、决策、行动，今天的人工智能代理更像是基于这个认知飞轮构建的。但是从本质上，人类智能远比这复杂。
- 智能究竟是什么？人类对世界进行建模，把世界以实体、关系、属性描绘出来。然而，这也是我们认知的极限，我们只能理解一个对象化的世界，非对象化的世界我们无法理解。比如，当我们探索量子的时候，我们还常常用对事物进行对象化的方式去理解，但是发现我们的理解力有时候是有限的，因为量子世界的真相超出了人类认知能力的范围，我们智能使用低维空间的投影去推断它，就像我们无法在三维世界去想象十一维世界的样子。
- 其实在大模型Agent技术出现之前，人们就已经意识到，试图集成各种深度学习模型以实现人工普遍智能（AGI）并不够，还需要更高层次的认知模型。Agent都必须对世界有准确的理解才能做出正确的决策。当模型不能正确运行时，决策就会出错；只有当世界模型构建的正确，才能选择正确的模型，进而做出正确的决策。
- 今天计算机领域的工程实践中，人们更多采用的是面向过程架构，无论是接口、函数、UI界面，还是组件，又或者是一个应用程序，都是以接口的形式存在的。而这个接口实质上是一种被调用的子流程，借此过程的完成，我们希望执行结果符合我们的预期，但程序并不为结果负责。它解决的是过程和流程问题，系统内没有目标的概念。当然，也存在一些以目标导向为核心理念的的软件工程，例如声明式编程，它只需要你描述你想要什么，而无需关心执行的过程，像HTML和SQL便是其经典例子。在这样的架构下，程序能够自行寻找达成目标的方法。然而问题在于，这种面向目标的架构只能应用于垂直领域，而无法普遍应用到所有领域，只有在特定的领域内才能发挥作用，这就限制了它的应用范围。总的来说，尽管面向目标架构在计算机领域有一席之地，但由于其只能在特定领域发挥作用，而无法解决所有领域的问题，因此它的应用还是有所限制，更多出现在特定的DSL（领域特定语言）中，这种架构的确也发挥了巨大的作用。在软件工程的范式迁移中，我们发现面向过程架构与面向目标架构之间的重要区别点：随着人类的生产方式的变化，软件工程可能正逐步演化为智能体工程(Agent Engineering)；以前我们主导的生产方式是人类处于中心位，AI做辅助。而未来可能会变成以 AI 为中心，人类变为辅助。由此，整个产品形态和平台的构成可能会发生这样的转变。
智能体是一个利用LLM来决定应用程序控制流程的系统，智能体的基本概念是在没有人工定义工作流（Workflow）的情况下，利用外部工具或功能，选择要执行的一系列操作，在没有人类控制的情况下独立运行（自主性，无需持续的人工干预或输入）。对于 toB 产品，智能体能够解决功能点繁多、使用链路冗长、使用方法复杂难上手等问题。从技术角度来看，智能体通过大模型理解用户意图并生成结构化描述，进而执行相关操作。因此，智能体在实际应用中扮演着至关重要的角色，成为了连接大模型和现有应用的桥梁。
Agent和过去程序代码不一样的地方就是它或多或少是有一些智能的，和过去一个函数或者应用写好之后就处于不可改动的情况不同。也就是意味着，利用Agent或者Multi-Agent实现的应用程序是有可能实现进化的。传统的应用程序不过是为Agent提供了一个基本的”环境”，Agent可以通过与人(“用户”)的交互以及环境的互动过程中，通过数据和反馈来感知外部，并且不断生成代码和使用工具来优化应用。例如，过去人们购买的应用软件都需要等待厂家的升级来进行版本的改动和调整，但是基于Agent的应用程序就有可能通过自然语言来构筑新的功能，而无需等待版本的更新。也就是说，应用应该是”成长”出来。如果将来LLM能够收集数据来更新自己，那么人类就真的变成了超级智能的引导程序。
LLM带来的自主性给软件开发带来了什么好处呢
- 传统软件编程的世界。一个软件系统，一般来说底层是由很多模块 (module) 组装而成的。然后程序会把这些模块编排起来 (orchestrate) ，按照某种顺序来执行。也就是说，粗略来看，一个软件系统由两部分元素组成：模块 (Module)；编排 (Orchestration)（PS：程序=数据结构+算法；程序=控制+逻辑）。先说一下编排。有开发经验的工程师都会知道，很多业务系统都存在一个「编排层」，这一层负责把众多模块「串」起来。工程师的很大一部分工作量，实际上都是在根据业务需求修改编排层的实现。正是这个编排层确定了程序的执行路径，并为系统引入了某种动态特性。如果执行路径上的每一步 (step) 都是提前能确定好的，那么就属于静态编排；如果引入了分支逻辑 (if/else/switch) 和循环逻辑 (while或递归调用) ，那么程序就能够根据输入数据在运行时动态地确定执行路径，那么就属于动态编排。可见，传统的软件编程方式天然就已经可以提供某种动态特性。那么，AI Agent带来了哪些新的能力，是传统的软件编程所不具备的呢？表面上看，LLM输入一段文本，输出一段文本，封装后似乎跟传统的软件模块没有什么差别。但由于LLM的reasoning能力，它的输出一旦被解释成与执行决策有关的信息，就为AI Agent系统带来了某种「自主性」。这种自主性超越了传统软件编程所能够提供的动态特性，是一种巨大的差异。我们分两个方面细分来讨论：
- 一个是关于模块间编排的自主性。可能称为planning的自主性更形象一些。
- 第二个是关于模块内的自主性。
- 先说planning的自主性。传统软件开发，不管是静态编排，还是动态编排，都需要工程师在编写代码的那一刻（也就是程序执行前）确定所有可能的执行路径。而这张图表明，在AI Agent时代，我们预期LLM的reasoning能力能够在众多的模块间动态地规划出一条执行路径。我们只需要提供一系列候选的可执行模块，而不再需要人工去编排路径。也就是说，工程师在编码的那一刻不需要考虑清楚可能的执行路径，执行路径可以在程序执行过程中根据执行动态现场确定。这种自主性程度显然超越了我们前面提到的动态编排了。实际上，编排的英文单词是orchestration，而这种高度自主的编排，称为planning可能更合适一些。
- 再审视一下模块内的情况。如果把LLM调用封装成一个模块，而LLM的输出仅仅是作为一段待处理的数据交给后续模块来处理（比如生成了一段总结，或者一段文学描写），那么这样的模块和传统的软件模块并没有本质区别（区别仅在于准确率方面）。但是，如前所述，LLM的输出一旦被解释成与执行决策有关的信息，情况就不同了。至少有两种典型的编程模式，LLM的输出会影响到后续的执行决策：
- 一种是动态任务拆分。在传统软件开发中，把一个复杂的任务拆分成多个简单的子任务来完成，也是一种很常见的策略。但是，以前工程师需要在编码时就明确任务如何拆分，比如拆分成几个子任务，每个子任务是什么，然后把每个子任务写代码实现出来。而LLM带来了「动态」的任务拆分，它可以基于输入数据现场拆分任务，并把拆分出来的子任务交给后续的LLM来继续执行。你在编码的那一刻无法预测任务拆分的细节，既不知道拆分后的子任务数量，也不知道每个子任务具体是什么。
- 另一种是AI现场编码。当没有现成的软件模块可供调用的时候，LLM根据程序输入数据，现场编写脚本代码（比如数据分析脚本、自动化测试脚本），并在沙箱中运行。LLM这种解决问题的方式，具备高度的定制化和自主性。
- LLM带来的自主性给软件开发带来了什么好处呢？这就涉及到软件的开发成本问题。在传统的软件开发模式中，所有预设的逻辑都必须由人类工程师编码完成。大型的软件开发，最后就变成了一个堆人力的事情。在AI Agent时代，新的技术为我们描绘了一个更美好的未来：以前的预设逻辑（需要人力编程的逻辑），都已经内化到了模型中，现在我们只需要把它们诱发出来，去动态执行。具备高度自主性的AI Agent，它们或者基于现有的软件模块，组装出更复杂的软件系统（基于planning的自主性）；或者基于用户需求现场生成高度定制化的代码。
- 从面向step到面向goal。程序语言所描述的，本质上是个DAG (Directed Acyclic Graph) 或DG (Directed Graph) 。当有循环逻辑的时候，就是DG；没有循环的时候，就是DAG。把程序看成一个DAG或DG来进行编排，不管是可视化编排，还是通过代码进行编排，在LLM出现之前其实早就存在了。同时，现在大多数Agent/Workflow框架（比如LangGraph、Dify、LlamaIndex等），也都是在基于DG/DAG解决编排问题。所有这些方案的底层架构，是基于或至少「类似于」Pregel的 (谷歌总结出来的一种分布式图计算架构)，如果不考虑分布式计算的部分，Pregel在编排逻辑上跟手写代码的if/else、while本质上是一回事，因为工程师需要手工编码程序执行的每一个step。Pregel通过在每一个superstep末尾发送动态消息，让它具备了动态编排的特性。当然，所有可能的执行逻辑和可能的执行路径，是提前预设好的（在程序执行前确定好的）。以上所有这些基于DG/DAG的编排方案，可以统称为Graph Orchestration（基于图的编排）。我们现在的问题是，AI Agent的自主性（包括上一节提及的planning的自主性和模块内的自主性）对于软件开发有什么新的要求呢？或者换句话说，为了把AI Agent的自主性更好地发挥出来，我们是采用传统的Graph Orchestration就够了？还是说需要一个全新的编程范式？各种不同的Agentic System，它们所呈现出来的不同程度的自主性，本质在于系统编排的执行路径是在何时决策的。总共分成三种编排时机：
- 静态编排：执行路径的每一步都是提前确定好的。
- 程序动态编排：具体执行时的路径只能根据输入数据动态确定，但所有可能的执行路径都是提前确定好的。
- 自主编排（或者叫自主planning）：没法提前设想所有的可能情况，执行路径也需要根据执行动态现场确定。PS：执行工具可能也需要根据执行现场确定。模块和编排都是临时确定。 这种新的特性，呼吁一种编程范式的转变：从面向step到面向goal。这就好比，当你交给某个人一件任务，如果这个人能力比较弱，你就需要把具体每一步怎么干都明确告诉他；但如果这个人精明强干，那么你只需要把任务目标告诉他，具体怎么干你就完全不用管了。我们可以认为LLM具有某种程度的「智能」，所以跟它交流更自然的方式是告诉它目标 (goal) ，然后让它来编排具体的执行路径从而把任务完成。传统的面向step的任务，只要把每一步执行完，就算目标达成了。但是，面向goal的任务，即使我们能够把任务拆解成多步，这时候把每一步都执行完也仍然不能够说明目标达成了（PS：因为实现没有把所有执行路径预计全）。成功执行完每一步，只能保证会输出某个结果，但并不能保证输出的效果一定是符合目标的。因此，面向goal的编程通常需要我们提供一个评估模块。同时，面向goal的编程模式也可能带来一些潜在的好处。比如针对同一个目标，系统可能会发现多条执行路径，从而提供更多选择性；或者执行过程中出现错误的时候，系统也许可以动态找到其他执行路径，从而把错误绕过去。