Agent八股文-agent篇

目录

概念篇

你对AI agent的理解

我凭理解首先回答的就是工具调用，而工具调用就是调用api，之后就想不到非常明显的差别

然后我的回答跟小林这篇文章是十分像，确实仅凭借理解和印象，最长用和最容易看出区别的只有工具调用，其他就想不到了。

大模型的局限性

  • 无上下文记忆，普通api调用为单轮对话，网页版LLM被内部官网维护，自动塞入历史对话，造成 “记忆”假象，本质已经算是agent范畴

  • 无工具调用，大模型无法调用工具-知识冻结

  • 无持续状态：这里算是比较书面的表达，用人话讲：持续状态指的是已有信息的获取，这里容易想成上下文记忆，下面专门说说区别在哪

持续状态与上下文记忆

从上面的表达来讲，二者没有很大区别，我提一个问题就明白了，如果让ai查数据，但是数据十分庞大，如果按照上下文记忆的方式，直接把历史对话作为prompt一部分重新加入，上下文窗口容量直接爆炸，那解决方案就是把数据存入向量数据库，只在系统提示词中写入数据主题内容，模型需要改内容的时候输出调用指令，查询数据库，返回数据，再输入，可以发现这其实是Rag的过程，所以持续状态比较理解的一个例子是查数据库，返回数据生成。

持续状态可以简单的理解成数据的持续状态，专指当对数据有需要的时候才调用，这与上下文记忆有本质的区别，一个按需读取，一个留存在对话框中反复输入。

其实说到这，还可以继续深入，我们可以发现一个问题：无论何种方式都无法绕开输入prompt调用LLM，因为LLM只能单轮对话，所以无论何种方式，最终想让LLM得到数据，都只能通过输入prompt来完成。那么现在有个问题：如果是大篇文章，我们还可以用RAG进行摘要，利用索引找到所需部分，降低prompt内容，但是如果是数据分析呢，要求必须分析所有的数据，但是数据十分庞大一次性输入必然对话框超量，那如何解决 AI的读书和数据分析

Agent 的优势

一、工具调用(Tool Use)

工具大概分为：API调用，联网查询，本地代码，数据库，搜索

工具调用原理：用 json 格式定义工具，内容包含如下

tools = [
    {
        "name":, # 工具名称
        "description":, #工具内容描述
        "parameters":{
            "type":,
            "properties":{
                
            },
            "required":
        }
    }
]

从代码可以看出，对于大模型来讲，他是通过了解json格式的代码理解工具，他会根据 description中的描述来决定是否使用，然后返回 name

那么当大模型返回所需要的工具的时候，谁来实现工具调用呢？**

当模型想调用某个工具的时候，此时会有他的 name，这个名字就如同函数一样，当我们想使用的时候，就直接调用函数名，这里也是同理，只不过调用工具的代码直接封装进 LangChain 里面

二、记忆力机制

从原理出发，这个实现就十分简单了，首先，大模型本身只能单次对话这是铁定的定理，因为他本质是语言推测模型，根据训练数据推测下一个可能得词语，并非我们说的理解语义，只不过训练的成果接近理解的程度，按照这个定理，我们要想他具备记忆力的对话模式，最笨的方法就是每次都将对话内容重新和新问题一起发送，而这就是记忆机制。

从开发的角度，我们具备调用LLM——api的能力，只需要将每次的返回内容用公共变量维护即可，每次调用前，都可以将这个公共变量拼接当前问题然后调用API实现，从而达成了记忆机制。

那么在理解实现记忆机制的基础上，就明白了为什么会有上下文容量限制的原因：每次都是复制之前所有的对话历史，但是单次调用API的内容容量是有限，所以上下文窗口的概念就出现了

这里补充一点，也是后续补上的，上面实现的记忆机制其实短期的记忆机制，专指单轮对话中的所有对话内容称为短期记忆，有短期记忆就有长期记忆，我们举个例子，如果我想让agent记住用户的对话风格以及一些对话爱好，我的实现的路径只能是每次在对话的开头声明我的对话风格和爱好，这是非常麻烦的，我希望每轮对话不需要写这些，他能够长期的记住，如何实现呢？

长期记忆的实现原理，这里的实现方式用向量数据存储，以摘要的方式存储在系统提示词当中，提示词会标明对话开始的时候需要按照摘要去查询对应的对话风格并加载，而这里的查询就是查询向量数据库，其实这个过程也就是RAG。

总的来说，记忆机制是智能体区别大模型的最明显区别之一，永远都要将智能体作为一个开发项目去看待，而大模型只是一个普通的API调用，那么我要想实现记忆机制，我就会有一个广阔的开发空间，也就是我可以在调用大模型API之外，在自己的代码框里去获取API的有用信息，或者传导特定信息，这样可塑性就很多。

三、多步推理和自我纠错

看小林的描述，看第二遍才发现其实说的就是两种范式，ReAct 和 Plan-Execute-RePlan，

  • 前者的含义是，边思考边执行，从开发角度，如何实现思考，也就是反思功能呢？实际上，我们会对不同环节设计不同的系统提示词，然后流程就是问问题LLM，返回数据，提取数据，将结果和最初问题有一起再次问LLM，只不过第一次是让他解决问题，第二次是让他检查问题，根据检查结果手动在代码框中规定接下来的流程，而实现的方式就是之前所说的“对不同环节设计不同的系统提示词”，这样就实现了反思功能，这个功能其实在LangChain创建agent的时候就会自带ReAct范式，其实也可以说成框架，举个例子，调用API报错该怎么办，这时候反思错误原因在哪，可能是参数不对，可能是名字打错遗漏，然后再重新调用。

  • 而后者就是多步推理的实现，多步推理，其实就是首次思考的时候就计划好步骤，然后按照步骤执行，这就是Plan-Execute-RePlan，从字面意思上就可以理解，先规划，根据规划生成的步骤开始执行，根据执行的结果判断是否符合预期或者需要继续执行等，从而实现多步推理。

Agent 的基本架构有哪几部分组成

我第一次遇到这个问题的时候也会同样回答LLM+工具调用

一般来讲，它包含四部分，LLM，工具调用，记忆机制， 规划模块

我们分开来讲

LLM

虽然不研究大模型内部的组成，但是仍然还是有很多地方值得说一下的。

  1. 系统提示词，在开发的过程中注意到会有一个系统提示词，它规定了ai的身份或者是边界，系统提示词的调优是十分钟要的，【挖坑】如何写好系统提示词

  2. 模型的选择，推理能力强的适合做规划，但是响应时间慢，token消耗量高，对于普通的工作流执行就适合用普通的模型，降低成本

  3. 成功率，有些模型生成的json格式出错，参数出错，导致调用工具的时候反复出错，导致token消耗量高，响应时间长，甚至任务失败

  4. 上下文窗口，对于复杂共走，当然是希望使用上下文窗口大的更好

工具调用

他的调用原理和实现过程在上边已经说过了，这些再写一些细节的东西

  • 工具描述 (description) 的质量影响agent的表现，如果内容模糊，或者内容范围不够细致就会导致不调用或者无脑调用的情况，比如一个工具的描述为“查询数据”，但是他实际维护的是天气数据，当你需要查湿度数据的时候，agent也会无脑调用这个工具，造成不必要的重试。【挖坑】如何写好工具描述

  • MCP 模型上下文协议

    关于他的作用这里重点说一下MCP

记忆机制

包括长期记忆和短期记忆，上面都详细已介绍过了

规划模块

规划这里其实就是指的agent解决复杂任务，需要多过程问题的能力，这就取决于底层大模型的推理能力，决定推理能力的CoT（思维链）决定，【挖坑】思维链如何决定推理能力。

提高大模型推理能力的一个方式就是手动将推理内容一步一步的打印出来这(其实这个操作就是叫CoT，我也是查ai才知道)，存储在上下文窗口中，由于是预测文字，他会对之前对话内容的距离长短分配权重，优先根据最近的信息生成内容，这样的结果会更加可靠一些

范式应用： ReAct 和 Plan-Execute-RePlan

工作流是什么

工作流其实就是AI+传统业务代码

从一个例子出发，加入我希望知道一个智能下单助手，他会先询问用户的下单商品然后再完成下单，其实从后端来看，我做过电商秒杀项目，下单的过程中需要查库存，修改库存，创建订单，等待支付这系列流程，假如我放进agent开发中，其实就是大模型负责获取商品信息，获得完之后自动按照后端的python代码继续实现，这个过程就叫工作流，可以简单的看出，工作流其实就是ai做简单的分类或者语义理解的工作，然后继续按照后端的业务流程继续实现

用比较常见，书面的语言讲，这叫做整个执行流程写在代码中，整体走向完全由开发者的代码决定，最简单的就是LLM 调用，然后根据回答写一堆 if-else 代码进行情况分类

AI的读书和数据分析

我们可以发现一个问题：无论何种方式都无法绕开输入prompt调用LLM，因为LLM只能单轮对话，所以无论何种方式，最终想让LLM得到数据，都只能通过输入prompt来完成。那么现在有个问题：如果是大篇文章，我们还可以用RAG进行摘要，利用索引找到所需部分，降低prompt内容，但是如果是数据分析呢，要求必须分析所有的数据，但是数据十分庞大一次性输入必然对话框超量，那如何解决**

想到这里，我就突然明白应用的含义，这是我第一次发现agent在不同领域的使用区别，

  • 阅读查资料，基础的RAG更合适

  • 数据分析，必须全部数据，或者说数据越多越好，RAG就不能利用摘要来分块了。

其他解决方案

Map-Reduce（分治法）：让大模型做“流水线工人”

其实就是子agent的方式，通过将数据分块分给其他agent分析，然后主agent汇总二次分析就可以得到比较接近的结果，

工具调用（Tool Use）：让大模型做“指挥官”而不是“搬运工”

可以利用python，excel等工具直接分析，然后得到分析报告进行汇总，这样省去了模型识别数据的消耗，降低成本

简单的讲

  • RAG chunk文档分割和embedding向量化，基于摘要选重点，这对于文章比较实用，但是对于数据分析来讲，必须需要分析所有数据就不行了

  • 任务编排 Map-Reduce 其实有点像子agent的方式，每个agent分析一部分数据，然后主agent汇总再次分析，这就等价于全部分析

  • 工具调用：调用python等工具进行分析，读取文件直接分析数值，这样就类似于excel表格功能，同样agent得到的也是汇总过的数据，总的来说，对于需要分析的内容超过对话长度，但是有不得不全面读取的内容，基本上都是讲任务分散，而大模型输入的内容都是汇总过的内容，依次来解决

设计范式篇

了解哪些其他的 Agent 设计范式？Agent 和 Workflow的区别是什么？

ReAct 和 Plan-Execute-RePlan，一个是边想边做，一个是先计划所有步骤，然后按步骤执行，一个让agent实现反思功能，一个实现复杂任务分支解决，实际应用一般是二者混合用，具体的讲，Plan-Execute-RePlan 保证任务解决的整体框架，ReAct我保证单步骤任务的完整性。

第二个问题：工作流中包含agent，agent是其中一个节点，用于前期的分类或者基础决策，根据智能体的决策结果执行后续对应代码，简单的区别就是agent然后加一堆ifelse

ReAct 范式

一般都是他是边想边做，局部最优，容易忘记之前内容，可是我有一个疑问，无论是什么范式，第一步问LLM的时候，LLM的回答逻辑一定是先给出一个解决方案，里面记录了接下来的每一个步骤，

那么问题来了，为什么在已有解决方案的情况下，会出现局部最优，忘记内容的情况

首先，ReAct 的实现原理为

  • Thought 调用LLM给出当前步骤的方案

  • Action 进行工具调用

  • Observation 基于搜索解决判断是否满足返回答案，否则继续循环

可以看到，这一个非常简单的agent调用过程，对于上面的问题，书面说法是，中间遗忘，注意力分散，信噪比增加。

解释一下上面的问题：

  • 首先，在这种范式下使用的隐式规划，虽然在prompt中会存在解决方案，但是大模型并不一定会注意到，对于当前的prompt大模型对内容的选取会有权重，并不能全部覆盖，所以会导致部分遗忘，具体的讲，模型一般会优先以首位内容作为思考文本，所以就会造成中间内容遗忘，

  • 再加上执行步骤过程中会有对此失败的操作，就会导致prompt中存在大量失败内容，造成信噪比****增加，模型无法准确识别有用信息，所以造成有用信息遗忘

  • 随着步骤的增加，上下文窗口不够，就会对之前的内容部分删除，导致忘记最初任务，然后模型会根据当前做的步骤推断最初任务，最后就有可能导致任务方向错误

Plan-Execute-RePlan 范式

其实就是字面意思，有一个规划器，先讲模型的规划方案存入全局变量，然后执行器只负责按照规划步骤中的某一步骤要求去做，无需考虑方向的问题，重新规划器的作用是用来判断当前数据是否可以返回答案，以及步骤和执行效果不符，考虑重新规划方案。

其实听起来和ReAct解决问题的方式是一样的，但是这个是显示规划，用全局变量维护规划内容，每次执行的时候，对单独从全局变量中选取该步骤的执行内容，执行器Execute只是单纯的执行所需的工具，不会考虑下一步骤的执行，这样的好处就是解耦，之前的范式模型需要记住解决方案有需要记住每一步的返回内容，有需要思考当前步骤的方案，不免造成注意力分散，不分内容遗忘，实际上某些内容对于当前步骤是没有用，但是又不能丢弃，原因是可能后续或者最终总结的时候有用，而显示规划就不会造成遗忘的情况，就像是特工一样，每个特工之前不知道对方的任务，只负责完成自己的任务，这样实现的效果会更好，只负责执行，不负责思考正确与否，而这个思考的工作交给Replan解决。

这里我自己有一个思考就是为什么react已经具备了反思功能，也就是修正功能，为什么还需要Replan，因为一般工程中都是Plan-Execute-RePlan 范式负责整体框架，而内部Execute执行调用agent的时候，agent已经内置了React，所以他已经具备自我纠错的能力，比如调用失败怎么办，用户重新插画怎么办等等

并且其实在实际开发中，我的Replan并没有手写纠错逻辑代码，但是仍然效果很好，所以就问了AI，我就不再手写了，直接贴截图了

简单的说，其实react的纠错能力就满足开发需求了，属于轻量级纠错，对于复杂系统或者追求复杂问题高精度解决的话，就需要利用replan的重量级纠错，他负责全局规划的重新修正，二者的级别量级还是能感受出来的。

Anthropic 在他们的工程博客里总结了一个非常实用的原则：能用 Workflow 解决的问题，就不要用 Agent。

CoT 推理链

因为之前了解到，LLM有注意力分散机制，对于头尾数据更加关注，容易遗忘部分中间内容，而模型本身是依靠预测下一个字解决任务，看起来其实是一个隐形推断，其实模型并没有思考，只不过是按照以前的训练数据隐形预测，这样就会导致无推理逻辑，最终答案错误

CoT，为了让ai一步一步显化推理，具体的方式就是在提示词中表示必须一步一步将推理过程打印出来，这样的好处就是，每一步推理都存储在prompt，并且是最新的，那么LLM的关注度是最高的，这样就避免了跳步的现象，错误大大降低。

具体实现方式

  • 直接在prompt添加需要将推理过程输出

  • 给出一个高质量推理模型，让LLM模仿

复杂任务拆分如何做，效果如何提升

我本来以为这个方式会跟高大上，实际上就是静态拆分和动态拆分

  • 静态拆分：就是静态工作流，对于一个任务直接用代码逻辑写死运行过程，调用时就类似后端api调用

  • 动态拆分：Plan-Execute-Replan，让ai提前写好解决方案，然后全局存储，按步骤运行

拆分之后如何提升效率？

需要将任务画有向无环图DAG，然后将可以并行处理的任务步骤进行并行处理，大大降低响应延迟。

工程实践篇

agent的记忆机制有哪些，实际开发过程中如何设计记忆模块

因为之前写过，所以我会直接回答短期和长期，并且再说说实现原理

其实记忆机制有四个部分：

  • 感知记忆：其实就是当前对话框里正在填写的内容

  • 短期记忆：指的是上下文窗口

  • 长期记忆：存储在数据库中的总结性内容

长期记忆的触发方式是用过手写代码逻辑实现，一般在对话结束的时候，手动将对话的所有内容交给LLM总结提炼出重点部分，然后将其存入和数据库中，文本类就存在向量数据库，关系型明显的就存在数据库，更细节的，划分为情节记忆（记住以前发生的事情），语义记忆（之前的某些结论），程序记忆（完成一件事的推理过程，无需下次记忆），其实这些记忆都是靠代码逻辑去定义，一般都是先调用LLM，通过提示词控制记忆类型，所以不需要刻意去详细了解 各种记忆类型

  • 实体记忆：比长期记忆多一步，将总结性内容变成结构化部分，他比较老旧，现在的使用方式都是直接长期记忆，以前由于模型不具备记忆机制，没有一轮对话的概念，每一次单次对话就是一次结束，所以就会每次结束后都进行一次LLM总结，十分消耗，现在版本一般都用长期记忆去代替，

如何在开发过程中设计记忆模块

存什么

其实这些内容算是使用后的经验，需要存什么就存什么，一般是存入高价值记忆，然后抛弃低价值噪音，控制方式一般也是通过提示词来控制

  • 高价值记忆

    • 用户偏好和习惯

    • 任务关键的结论和决策

    • 技术方案

    • 外部导入的知识文档

  • 低价值噪音

    • 中间的推理过程CoT

    • 工具原始数据，原始的api响应数据，详细调试日志

    • 闲聊内容

怎么存

语义检索——向量数据库

结构化数据，如用户偏好，状态字段——关系型数据库，Key-Value 键值对

文档知识库——向量数据库

什么时候取出来

包括主动检索和被动检索

  • 主动检索是在对话开始时，在系统提示词中明确要求读取某些历史记忆，这样用户就不需要交代一些通用性的历史背景

  • 被动检索，将知识检索封装成一个工具Tool，让ai自主判断是否使用工具

上下文不够的时候你是如何处理的？

滑动窗口

只保留最近的N轮对话，更早的历史信息直接丢弃，优点是简单操作，坏处就是丢失重要信息的风险高，决绝于对话先后

摘要压缩

将历史内容给LLM进行文本压缩，除去一些噪音，降低token占用

压缩颗粒度选取

  • 全文压缩

  • 最近的10条对话记录保持原文，之前的进行压缩摘要

  • 保留最近10条，然后按照层级压缩，比如最近的11-20条采用适当压缩，之后的采用更精炼的压缩方式

将重要内容存储到长期记忆

将不常用，但是以后会用到的重要数据存储在数据库中，通过摘要按需查询。具体实现方式是让LLM对每个对话记录进行一个重要性打分，将重要内容存储到长期记忆

结构化抽取

将文本信息抽取成结构化信息抽取，比如我有一个书包，那么可以写成 bag:1 的字段，这样要比语言表达更加简练，消耗Token更小，这就有种做高中数学题，将大题给出的文本条件转化成公式条件一样，是一个意思不变，但是更加简练的方式，还是很牛逼的

优点：

信息损失最小，只要字段定理合理，重要的信息群补必备精确保留，没有摘要带来的模糊化，代价就是开发成本高，需要定义什么是重要字段，需要对业务有理解，不同类型的任务需要的字段也不一样，通用性低

然后我就有了这样的一个思考？

为什么不能直接给LLM让他提取所有字段，转化成结构语言，因为最后都需要加入好prompt，又不是存入数据库存储，所以字段的名字完全是可以随意的，那么为什么不直接让ai去识别转化，而是需要预定重要字段？

预定义重要字段的原因，最重要的是其实为了服务下游逻辑代码的参数需要，因为普通业务代码都带有参数，实现代码功能的前提需要精准的参数输入，你让AI进行机构化提取，每次提取的key可能是相同语义，但是不同字段表现，比如 名字 name 名称，这样导致将语言结构化之后，下传参数出现问题，或者找不到对应参数的问题，如果想要解决，还需要格外调用LLM按照下游代码所需的参数去匹配结构化数据，还不如直接按照LLM需要的参数预定好结构化数据字段，name就name，名字就名字。

【挖坑】记忆框架的了解

Mem0，Letta，Core Memory，Zep

知识图谱

数据库只能做语义检索功能，但是不具备推导能力，本质是一条一条的存和取，如果想要查询某两个实体的关系，例如A的公司主要从事什么业务，就需要先查询A的公司，在查询公司的业务 ，这种需要关系推导的，有强关联的数据可以通过知识图谱实现，实现逻辑就是从对话中提取到实体和关系，然后存入图谱中，这样做的好处就是可以实现跳步，在查询的过程中就和图搜索一样最终直接返回答案，而不需要先把所需数据中找出来，然后再给LLM推理，降低Token消耗

随着时间增长，长期记忆中存储许多重复或者冲突的碎片化信息，如何处理，或者说如何维护长期记忆高效运行

  1. 去重，将语义相近的内容合并成一个完成的版本重新存储

  2. 去除矛盾，根据时间戳判断相互矛盾的结论的存储时间，保留最近结论

  3. 抽象提炼，通过好几个相同的现象总结成结论，比如去爬取不同网站的内容，结果都因为动态渲染的问题无法成功，就可以总结成简单的请求会出现问题，需要采取自动化工具获取。

Agent的反思机制如何实现

提到反思就需要考虑两个方面：评估和改进

这就对应着两个LLM的调用，一个是评估者，一个是改进者，两个基本都是通过提示词进行身份赋予。

评估prompt

任务：{task}
当前输出：{current_output}
请评估以上输出：
1. 有没有事实错误或者逻辑问题
2. 有咩有遗漏重要内容
3. 内容是否表达清晰

如果输入足够号，回复 [PASS]
否则指出具体问题并给出改进建议

改进Prompt

原始任务:{task}
当前输出：{current_output}
评估意见：{reflection}
请根据评估意见改进输出

反思逻辑，

  1. LLM根据问题生成方案

  2. LLM评估结果

  3. 符合要求返回答案

  4. 否则LLM给出改进方案

  5. 然后循环，LLM 再根据内容执行方案

在实际的工程中还需要考虑什么时候采用反思，因为每次都是用反思，并且还存在循环情况，开销和响应延迟都会大大增加，在反思颗粒度上分两种

  • 步骤级反思：每完成一次步骤就进行一次反思，好处就是只要一步出现问题，可以立即纠正，对于强依赖上次数据的任务十分有效，缺点就是需要额外调用多次LLM

  • 任务级反思：每次执行完一个完整的任务才会进行整体评估，好处就是可以宏观看到某些步骤出现的问题——（前后结论矛盾），坏处就是如果图中某一步关键出现问题，导致解决问题的思路走向走偏，后面的生成全部作废，消耗更多资源。

多Agent协作篇

什么是 Multi-Agent？

多agent在物理限制层面主要是解决上下文容量不足和多身份混乱的问题

上下文容量不足

对于一些复杂的任务，规划方案，各个步骤执行，中间的推理链，api返回的原始数据，错误重试成本都在一个agent中，上下文必然不够

多身份混乱

agent在不同阶段被赋予不同的身份提示词，但是以前阶段被赋予的身份提示词仍然还存在于上下文容量中，多个身份在一起，他就会综合考虑，侧重点分散，分析的结果就不会特备专业

在逻辑层面的必要性

对于线形任务，一个步骤的运行需要上一个步骤的强依赖，这种是适合单Agent，但是对于DAG并行任务，这里重点指的是DAG，图中某点的运行需要之前的某几个点的数据，而不是之前全部数据，那么这里就有一个问题就是单个agent的执行顺序问题，一般这种就用多Agent去实现

多Agent的三种协作方式

  • 顺序流水线，A做完给B

  • 并行，一个调度这把多个独立的子任务同时分发给不同的Worker Agent

  • 辩论评审模式，多个agent对同一个问题给出解决方案，由一个裁判Agent选出最优解

两种设计模式

  • 中心化：一个中央调度者，负责分配工作，好处就是中央调度可以记录日志，追溯问题出错的来源，根据中心调度的方式不同，又分为三种

    • 静态路由，任务拆分和分配规则预先定义好

    • 动态规划，中心调度者本身就是一个LLM，由大模型自动分配任务

    • 自适应编排，中心调度者不仅是一个LLM，还会根据worker agent的执行结果调整后续计划，比如返回信息不够，二次运行等。

  • 去中心化：只了解缺点，任务分配没有协调（重复工作），执行顺序没有保证，失败没有感知，没有人来确认任务整体完成，

如何实现单agent和多agent的决策选型

渐进式演进

先让单agent跑起来，如果发现某个环节成了瓶颈，就把某个环节专门给一个agent去完成，一上来就直接多agent分配工作容易造成大材小用的情况。

Agent之间是如何进行协作，以及他们的动态切换机制是什么

如何协作其实就是在问agent之间如何通信

  1. 解耦，通过消息队列异步发送消息，上游处理完数据将消息发送到消息队列，下游从队列中接收消息

  2. 共享白板，设计一块公共变量，所有agent都可以看到里面的详细信息，类似于并发编程中的 sync 关键字，容易出现的问题就是脏数据，覆盖数据，

解决方案——维护状态

  • 区分状态和局部状态，全局状态存放用户信息，原始请求等，局部状态存放每个agent自己的中间结果

  • 明确写入规则，只追加不覆盖

  • 错误日志也要写入，方便中心调度识别并修改策略

选型：如果想前一步生成结果，后一步直接调用，就可以使用共享白板，但是如果想多个agent在不同的代码块中方便维护，就是用消息队列实现解耦。

动态切换

这里其实指的中心调度的调度方式，之前写过了，一个是静态路由，一个是动态规划，还有一个是自适应编排。

posted @ 2026-08-23 15:32  zxsoul  阅读(25)  评论(0)    收藏  举报