AI智能体和agent、agents之间的关系是什么样子的？有没有简单通俗易懂的大白话解释呢？

定义：

Agentic Integration（智能体整合）指的是多个独立的 AI 智能体之间可靠地沟通，以实现各自目标的机制。

问题来得比你想象的快

假设我们将需要整合来自两个不同的自主智能体。当我们已经在不同领域开发了这些智能体后，我们将如何整合它们？

那么，让我们来分析一下挑战。

智能体整合面临的挑战

一个天真的观点是说：“这只是一个 API 调用”，某种程度上这确实如此，但关键的挑战在于，今天还没有一种方法可以正式地定义一个 API，使其能够正确地封装其边界。

非幂等性

首先，智能体或生成式 AI 并不一致。在两次调用之间，它会给出不同的答案。

这是一个大问题。不像当你调用一个 API 来处理数据时，它会回复成功或失败，如果你发送同一个请求两次，它要么给你以前的处理结果（首选行为），要么将其拒绝为重复请求，然后如果你第三次或第四次发送同一张发票，你将得到相同的结果。

如果我有一个智能体，那么第一次可能会失败，第二次可能会成功，第三次失败，而第四次给你第二次尝试的处理结果。那么，你如何在协作中描述真正的失败呢？你如何说明何时应该多次调用某事物并可能对结果求平均值？

上下文自适应

第二个不同的特点是上下文的重要性。

这里指的是单个调用与服务端状态的交互不稳定且不一致。因此，如果你使用完全相同的一组请求调用单个智能体，那么你最终可能会进入一个完全不同的线程，这意味着你的请求可能在当前上下文中完全没有意义。

想象一下你想订购一个披萨，需要提供你的地址。

传统的方法：
服务员会问：“您住在哪个国家？”
回答：“中国。”
服务员又问：“您住在哪个省？”
回答：“广东省。”
服务员再问：“您住在哪个城市？”
回答：“广州市。”
… 接着，服务员会继续问你的街道、门牌号等等，直到你提供完整地址。

这种方法比较机械，一步一步地问，效率可能不高，而且如果你的地址比较复杂，可能需要回答很多问题，并且可能漏掉一些关键信息。

智能体解决方案就像一个更聪明的送餐机器人：

它的目标是“拿到你的正确送餐地址”。

它可以从你提供的任何信息开始。

情况一： 如果你说：“我想订一份披萨，住在天河路 123 号。” 机器人可能会说：“好的，请问您住在哪个城市？” 如果你补全了城市信息，它就完成了地址验证。

情况二： 如果你说：“我在广州。” 机器人可能会问：“好的，请问你的详细地址是什么呢？”

情况三： 你直接说：“我的地址是广东省广州市天河区天河路 123 号天河大厦 10 楼。” 机器人就直接验证了你的地址，不需要再问其他问题了。

然后加入多个不同的智能体，每个智能体都在自己的上下文中工作，我们如何使该上下文保持一致？我们应该使该上下文保持一致吗？上下文的哪些部分需要保持一致？我们如何描述上下文如何改变行为？协作双方的智能体如何调整其行为以动态地实现其目标，同时“尊重”其他智能体正在采取的方法？

越界行为

第三点是，一个智能体可能会在超出他的职责界限。用于地址验证的智能体可能也能成功地响应国际象棋的移动。运输智能体可能也能做到这一点。当被要求乘以一大组数字时，它们可能都能做出回应。

这并不意味着它们是正确的，或者即使它们是“正确的”，它们也不应该这样做。因此，如果一个智能体开始与另一个智能体进行协作，那么即使它完全无效，也不能保证它们不会开始尝试做事。

不同的智能体没有共同的目标

当你控制一个智能体解决某类方案时，你就控制了它们的目的，并且至少定义了你希望它们运行的边界。如果这些智能体位于不同的解决方案域和不同的业务，那么任何目的都必须作为协作的一部分达成一致。

可变的执行成本

GenAI 中一个非常有趣的事情，并且在智能体 AI 下只会不断增加，那就是你不知道执行成本会是多少。我们不可能确切地知道为了完成某个任务，智能体何时终止，但在今天的大多数的传统技术解决方案中，我们至少可以对类似处理发票的计算成本以及该过程通常需要多长时间有一个大致的了解。

如果我们在一个智能体解决方案中拥有完全的控制权，我们甚至可以将成本和时间作为考虑因素和终止因素，比如，如果智能体的API请求没有在“XX人民币”内解决某个任务，则报告失败。这只是意味着我们限制了失败，并且在考虑协作时，使用成本作为考虑因素。但是，如果我们有单独的智能体进行协作，我们如何确定总成本？我们如何估计这甚至是否值得继续尝试？谁来定义成本是否太贵了，以及我们如何看待沉没成本？

定义智能体整合需要什么？

因此，考虑到这些挑战，我们探讨一下对于自主 AI 协作，我们需要能够解决的几件事：

我们将使用什么语言进行沟通？

需要做出的第一个决定是：用于智能体相互交流的机制和语言。

这两个智能体会像人类一样使用英语或其他语言“交谈”吗？还是它们会使用统一 API 的格式，并且将其他智能体“仅仅”视为任何其他应用程序吗？

实际上不管是第一种还是第二种交流方式，这两种选择都不是很理想的。

• 自然语言：在多个智能体的交互过程中，无法预测一个智能体会想另外一个智能体输出什么样的自然语言。
  
  
• API通信：没有解决智能体协作的挑战。
  
  
• 通信协议：一个交互应该具有
  
  
• 前提条件——允许你交互之前必须是什么
  
  
• 后置条件——函数/智能体/服务保证在成功完成时将是什么
• 不变量——函数/智能体/服务承诺它不会改变什么

现在，其中一些可能在智能体级别本身，一些在单个交互级别，一些可能需要在智能体之间进行协商。

给定的智能体允许做什么？不做什么？什么时候可以要求它做什么？

智能体整合需要通信协议，适用于智能体和协作

开发人员可以处理 API 并通过阅读 API、阅读文档、四处询问然后编写代码来找出正确的方法。智能体需要做同样的事情，并且我们需要使其更加正式，因为智能体不应该被信任。

我们需要考虑智能体本身的通信协议，还需要考虑两个智能体之间每次交互的通信协议，如果多个智能体一起工作，那么我们需要考虑管理整体协作的通信协议。

我会定期更新干货和学习笔记。喜欢的话，记得点个关注 ，不错过后续精彩内容！

智能体就是agent的中文翻译，它们是一回事，指能自主感知环境、决策并行动的智能实体 。
学过英语的都看的出来，agents是agent的复数形式，代表多个智能体。比如一个智能客服是一个agent，多个智能客服一起工作就构成了agents。

智能体是一种能够实现感知环境、进行自主决策并执行任务的系统。与大模型不同，智能体具备一定程度的自治性，能够根据输入的信息进行推理、学习，并持续优化自身的行为。

按照行业主流观点，一个典型的AI智能体通常具备以下四个核心特性：

• 感知：通过自然语言处理（NLP）、计算机视觉（CV）等技术获取环境信息
  决策：结合业务逻辑、大模型或知识库进行推理与规划
  
• 执行：与外部系统交互，如调用API、触发自动化流程或生成文本内容
• 自主学习：通过用户反馈、强化学习等方式优化自身能力。该能力以知识增强系统或模型微调的形式提供，门槛较高

在企业数字化转型背景下，智能体的价值不仅在于提升效率，还在于构建更加智能的业务流程，使企业能够更灵活地应对变化。

三个模块的职责如下：

• 感知模块：负责接收需要智能体处理的任务。任务通常有三种来源，人类通过语音、视频或键盘直接输入的信息、来自其他软件或智能体的调用参数以及通过物联网、RPA等技术手段读取的数据
• 决策模块：根据感知到的信息，判断其意图，并完成对应的分析与决策。这里通常需要用到大模型，联合使用多模态、多厂商的大模型已成常态
• 执行模块：将决策转换为软件动作，直接或间接展现给人类，完成任务，形成闭环

从技术实现的角度上看，智能体引擎、感知模块和执行模块本质上是一个应用软件，该软件通过特定的接口与大模型对接，最终形成一个完整的智能体。

吴恩达提出了四种AI Agent设计要素，包括：

检查（Reflection）：通过让大模型自我检查以提高代码质量。
工具使用（Tool use）：大模型使用各种工具来执行操作、收集信息。
规划（Planning）：智能体进行复杂的规划算法，如失败规避。
多智能体协作（Multiagent collaboration）：不同智能体协作完成任务，如开发游戏。

1. 检查（Reflection）

就是让AI来检查AI的输出，举个例子：

Step 1：你是一名专业的Python研发人员，你现在正在写一个脚本，该脚本可以自动识别world文件、pdf文件里的第一行文本，并把该文本用作文件的文件名。

Step 2: 你把写好的脚本给到了你的上司，一位资深的Python研发专家。他审查了你的代码，对性能、安全性和结构的全面评估，给出了修改建议。

Step 3: 你根据上司的建议，修改了代码并输出。

这种输出代码的质量，比你定义一个角**输出效果要好很多。而且它还能规避很多你意想不到的问题。

2. 工具使用（Tool use）

我一开始是以为让大模型去调用某些插件，后面我发现很多AI做不到。所以，我现在的理解是我们要善于使用各种生产力工具。比如，编码可以使用copilot。在GPT plus里就是各种插件。比如做数据分析的插件，做网络搜索的插件等。或者是说可以让AI运用已经很成熟的一些理论公式啥的。这样输出效果也会很好。比如让智能体运用SWOT分析法分析某个行业。

3. 规划（Planning）

规划就是把一个复杂的事情分拆成多个步骤去执行。吴恩达老师举的例子：

Request:Please generate an image where a girl is reading a book,and her pose is the same as the boy in the image example.jpg,then please describe the new image with your voice.

大概意思是识别图片中男孩的姿势，然后生成一张女孩在读书的图。女孩的姿势和男孩一样。最后用语音描述这幅新生成的图片。这个在一个智能体工具里是做不到的。但是在comfyui里是可以做到的。写到这里，我好像又理解让AI使用工具的意思了，应该是在comfyui这类集成工具里让AI善于调用其它工具。

举个例子：请你扮演一个电商公司的两个不同角色——运营总监张三和产品总监李四。

Step 1：张三提出一个创意——举办一场拉新比赛，总奖金1万元。奖励规则为：拉新人数第一名奖励5000元，第二至第三名平分3000元，第四至第十名平分2000元。

Step 2：李四对方案进行评估并提出反馈，例如指出该方案可能引发刷单风险、目标人群不明确等问题，并提出优化建议。

随后，双方进行多轮反馈与优化，至少完成5次来回沟通，逐步完善方案内容，最终输出一个在预算范围内、可执行性强、能最大化注册量的完整营销方案。

你会发现，经过多轮协作与迭代，最终的方案远优于最初的设想。而且，我们还可以引入更多角色（如市场总监、风控专家等）参与讨论，进一步提升方案的全面性与可行性。

其思想就是：与其让一个智能体长时间思考一个问题，不如通过多个智能体之间的协作，模拟不同视角的讨论与优化。虽然当前的AI反馈往往是即时的，但我们也可以设想未来，AI能在更长时间（如一天或几天）内持续优化方案，只要最终结果更优，这种“延迟反馈”也是值得接受的。

AI Agent的核心在于构建一个“感知-决策-执行”的完整闭环，而非仅限于对话交互。一个合格的Agent需具备理解任务目标、规划执行路径、调用外部资源和反馈调整的能力，形成一个“有限状态机 + 大语言模型”的协同系统。

以下是AI智能体架构设计的12条核心原则：

原则一：自然语言转结构化工具调用
让LLM输出结构化JSON，直接驱动后端API，实现自然语言控制程序执行。

原则二：提示词即代码，拒绝黑盒提示
将提示词作为可版本管理的业务逻辑，支持灰度发布和调试。

原则三：上下文即状态机
LLM本身无状态，开发者需显式构建上下文，包括任务说明、执行结果、对话历史和系统参数。

原则四：工具 = 可执行结构化输出
每个工具本质是JSON命令，模型只需输出结构化内容。

原则五：统一执行与业务状态
将执行状态与业务状态统一记录在上下文中，无需独立状态机模块。

原则六：生命周期控制 = 程序级API
支持启动、暂停、恢复、终止Agent运行，建议使用RESTful接口管理。

原则七：工具调用实现人机协同
当需要人工介入时，LLM应主动发出请求，如：

json深色版本 { “action”: “request_human_input”, “message”: “请补充项目描述” }

原则八：自定义控制流，增强弹性
手动实现Switch、Loop等结构，配合缓存、校验、限流，提升系统稳定性。

原则九：错误信息显式写入上下文
失败调用也应记录到上下文中，帮助LLM识别问题并调整路径。

原则十：多小Agent > 一大管家
避免构建万能大Agent，任务拆分为多个小模块协作更高效，建议控制在3-10步。

原则十一：多渠道触发，原路返回
支持从Slack、邮件、Webhook等渠道唤醒，响应保持渠道一致。

原则十二：无状态归并器设计
所有状态应存储于上下文或外部数据库，不依赖本地缓存，提升扩展性和可观测性。

ReAct Agent是用于提示大语言模型的框架，不同于前端的React框架，它是众多主流Agent开发架构变种的基础。该框架于2022年10月在论文《ReAct: Synergizing Reasoning and Acting in Language Models》中首次引入，并在2023年3月修订。其核心作用是协同大语言模型的推理和行动能力，使模型更强大、通用且可解释，让智能体在产生想法和执行特定任务的行动之间动态交替。相关参考网站ReAct官网介绍了ReAct相关数据以及不同提示形式的效果，论文中的代码部分包含经典的Prompts和案例，可供课外扩展学习。

Reason部分：基于思想链（CoT）这一提示工程技术。CoT的作用是将输入分解为多个逻辑思维步骤，辅助大模型进行推理和解决复杂问题，具体包括：

分解问题：面对复杂任务时，把任务拆解为更小的步骤，每个步骤专注解决问题的不同方面。

顺序思维：思维链中的每一步都依赖上一步的结果，从而构建出一条完整的逻辑推理链。例如，计算商店商品先降价20%再加价10%后的最终价格，先计算降价后的价格（100×(1 - 0.2) = 80），再依据此结果计算加价后的价格（80×(1 + 0.1) = 88）。

Act部分及循环机制：ReAct采用“思考 - 行动 - 观察 - 回答”的循环模式。用户提出问题后，智能体先思考，确定解决问题的思路和所需执行的任务；接着通过行动去执行思考阶段确定的任务，这个过程类似于Function Calling中调用外部工具的过程；然后进入观察阶段，根据行动的结果判断是否完成任务或确定下一步行动；如果观察结果表明任务未完成，则继续循环，直到观察阶段确认已妥善处理用户问题，最后输出回答。

明确任务与执行过程：ReAct提示模板主要包含三个关键部分，用于清晰定义代理的任务和执行流程。

思考与行动设定：第一部分设定代理的思考和行动模式，如在“思考、行动、观察、回答”的循环中运行，在循环末尾输出答案。使用“思考”描述对问题的想法，“行动”选择可用工具执行任务。

工具定义：第二部分定义代理在行动时可使用的工具，如“calculate”函数用于计算（需用Python并确保使用浮点数语法）、“wikipedia”用于调用维基百科API搜索关键词并返回摘要信息。这些工具的定义类似于Function Calling中对外部工具的定义，但在代理框架下需根据需求适当调整应用方式。

提示示例：第三部分通过类似CoT的方式构造提示示例，展示如何思考、行动和得出最终答案。例如，在询问“法国的首都是什么”时，思考环节确定在维基百科查找法国相关信息，行动环节调用“wikipedia”工具并以“法国”为关键词进行搜索，最终输出“法国的首都是巴黎”的回答。

顾名思义这种设计模式是先有计划再来执行。如果说 ReAct更适合 完成“厨房拿胡椒粉”的任务，那么 Plan & solve 更适合完成“西红柿炒鸡蛋”的任务：你需要计划，并且过程中计划可能会变化（比如你打开冰箱发现没有西红柿时，你将购买西红柿作为新的步骤加入计划)。

提示词模板方面，论文标题中说得很直白，《Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning by Large Language Models》，简言之就是 Zero shot 的提升，下图是作者代码中给出的一些 PS-Plan and Solve 提示词。

架构上它的组成是这样的：

• 规划器：负责让 LLM 生成一个多步计划来完成一个大任务。代码中有 Planner 和和 Replanner，Planner 负责第一次生成计划；Replanner 是指在完成单个任务后，根据目前任务的完成情况进行 Replan，所以 Replanner 提示词中除了 Zeroshot，还会包含：目标，原有计划，和已完成步骤的情况。
• 执行器：接受用户查询和规划中的步骤，并调用一个或多个工具来完成该任务。

REWOO(Reason without Observation)这种方法是相对 ReAct中的Observation 来说的，ReAct 提示词结构是 Thought→ Action→ Observation, 而 REWOO 把 Observation 去掉了。但实际上，REWOO 只是将 Observation 隐式地嵌入到下一步的执行单元中了，即由下一步骤的执行器自动去 observe 上一步执行器的输出。

举个例子，常见的审批流都是环环相扣的，比如我们的目标是完成 c，我们的步骤是：

• 我们需要从部门 A 中拿到 a 文件，
• 然后拿着 a 文件去部门 B 办理 b 文件，
• 然后拿着 b 文件去部门 C 办理 c 文件- 任务完成。

这其中第 2，3 步骤中 B，C 部门对 a，b 文件的审查本身就是一类Observation。又比如下面提示词模板中给出 one shot 内容中定义出每一步的 plan 都会依赖上一步的输入。

架构上它由三个组件组成：

• Planner：负责生成一个相互依赖的“链式计划”，定义每一步所依赖的上一步的输出。
• Worker：循环遍历每个任务，并将任务输出分配给相应的变量。当调用后续调用时，它还会用变量的结果替换变量。
• Solver：求解器将所有这些输出整合为最终答案。

Storm 相应论文标题是《 Assisting in Writing Wikipedia-like Articles From Scratch with Large Language Models》，很直白：可以从零生成一篇像维基百科的文章。主要思路是先让 agent 利用外部工具搜索生成大纲，然后再生成大纲里的每部分内容。

提示词模板方面主要围绕如何生成大纲，如何丰富大纲内容来展开。

架构上，就是先有 topic， 然后生成大纲，根据大纲丰富内容。这里会有一个大纲生成器，一个内容生成器。

Compiler-编译一词在计算机科学的意义就是如何进行任务编排使得计算更有效率，原论文题目是《An LLM Compiler for Parallel Function Calling》，很直白，就是通过并行Function calling来提高效率，比如用户提问张译和吴京差几岁，planner 搜索张译年龄和搜索吴京年龄同时进行，最后合并即可。

提示词里对 Planner 的要求是这样的，重点是希望生成一个 DAG(Direct Acyclic Graph, 有向无环图。

架构上有一个 Planner(规划器)，有一个 Jointer(合并器)。

Basic Reflection 可以类比于学生(Generator)写作业，老师(Reflector)来批改建议，学生根据批改建议来修改，如此反复。

提示词就是复刻师生之间的交互。

架构上有一个 Generator，一个 Reflector。

Reflexion 是 Basic reflection 的升级版，相应论文标题是《Reflexion: Language Agents with Verbal Reinforcement Learning》，本质上是强化学习的思路。和 Basic reflection 相比，引入了外部数据来评估回答是否准确，并强制生成响应中多余和缺失的方面，这使得反思的内容更具建设性。

提示词方面：会让大模型针对问题在回答前进行反思和批判性思考，反思包括有没有漏掉(missing)或者重复(Superfluous)，然后回答问题，回答之后再有针对性的修改(Revise)

架构上，有一个 Responder：自带批判式思考的陈述 Critique；有一个 Revisor：以 Responder 中的批判式思考作为上下文参考对初始回答做修改。

LATS 相应论文标题是《Language Agent Tree Search Unifies Reasoning Acting and Planning in Language Models》，很直白：是 Tree search + ReAct+Plan&solve 的融合体。在原作的图中，我们也看到 LATS 中通过树搜索的方式进行 Reward(强化学习的思路)，同时还会融入 Reflection，从而拿到**结果。所以：

LATS = Tree search + ReAct+Plan&solve + Reflection + 强化学习

提示词模板方面和之前的 reflection，plan&solve，ReAct 差别不大，只是上下文中多了对树搜索结果的评估和返回结果。

架构上，就是多轮的 Basic Reflection， 多个 Generator 和 Reflector。

Self-discover 的核心是让大模型在更小粒度上 task 本身进行反思，比如前文中的 Plan&Slove 是反思 task 是不是需要补充，而 Self-discover 是对 task 本身进行反思。

提示词方面，Self-discover 列出一系列的反思方式让 agent 来选择：

结构上，Self-Discover 如下图所示：

• Selector: 从众多的反省方式中选择合适的反省方式；
• Adaptor: 使用选择的反省方式进行反省；
• Implementor: 反省后进行重新 Reasoning;

Agent 中没有最好的设计模式，只有最适合的设计模式 ，最终还是要从用户需求出发来选择。

ReAct Agent框架的基础理论

Agent的九种设计模式(图解+代码)_agent模式-CSDN博客

AI智能体和agent、agents之间的关系，其实就像是一个团队里的不同角色和它们之间的协作关系。要搞清楚它们之间的区别和联系，咱们得先从最基本的定义说起。

智能体，英文叫Agent，这个词在计算机科学和人工智能领域里是个广义的概念。简单来说，就是一个能够自主感知环境并采取行动的实体。这个实体可以是软件程序，也可以是物理机器人，甚至是人类。想象一下，如果你把一个智能音箱或者自动驾驶汽车看作是一个智能体，它们能根据周围的情况做出反应，比如识别语音指令或者避开障碍物。

而AI智能体，则是特指那些基于大模型的自主智能体。这些智能体不仅能感知环境，还能进行复杂的决策和执行动作。举个例子，当你告诉一个AI智能体帮忙下单一份外卖时，它会直接调用相关的APP，选择外卖，再调用支付程序完成支付，整个过程无需人类干预。这种能力使得AI智能体能够在复杂多变的环境中独立操作，处理未知情况。

agents又是什么呢？其实，agents就是多个agent的组合。在实际应用中，为了完成更复杂的任务，往往需要多个agent协同工作。比如在一个智能工厂里，不同的机器人可能负责不同的工序，它们之间通过通信和协调来共同完成任务。这种情况下，每一个单独的机器人就是一个agent，而这些agent的总和就构成了一个更大的系统或者说是agents。

一下，AI智能体是智能体的一个子集，专门指的是那些具备高度自主性和智能化的实体。而agents则是指由多个agent组成的群体或系统。这三者之间的关系就像是个体与团队的关系：单个AI智能体可以独立完成任务，但当面临更复杂的挑战时，就需要多个AI智能体（即agents）一起合作了。

为了让这个概念更加通俗易懂，我们可以打个比方：如果说智能体是一支足球队中的任何一个队员，那么AI智能体就是那个技术高超、能够独自带球突破对方防线的球员；而agents则是整支球队，每个队员都有自己的位置和任务，通过默契配合来实现最终的胜利。

希望这个解释能帮助大家更好地理解AI智能体和agent、agents之间的区别与联系。随着技术的不断进步，未来这些智能体将在更多领域发挥重要作用，让我们的生活变得更加便捷和高效。