一、单Agent

一个合格的Agent需要三大核心能力作为其"大脑"中枢:

• Planning(规划):如同一位棋手，能将复杂局面分解为一系列精妙的子步骤
• Tool use(工具使用):宛如工匠，懂得从工具箱中选取最合适的工具并熟练使用
• Memory(记忆):既有短期记忆存储即时信息，又有长期记忆沉淀持久知识

整个应用由模型作为大脑来驱动和决策，任何问题，我们预期模型都能够正确的推理、选择合适的工具、检索到正确的上下文，最终生成符合预期的答案。然而这非常依赖底层模型能力，在当前的实践中模型能力是受限的(不够聪明、上下文窗口等)，单智能体模式面临很多的挑战。为此，业内才设计出其它模式，在工程上做更多事情，来弥补模型能力的不足。以下是单智能体架构下的一些典型问题:

• 如果一个 Agent包含有太多的可用 Tools，模型会在决策工具选择时无所适从，效果变差。
• 多轮执行下来，消息上下文会变得很大，消耗大量的Token且影响模型当前专注度。
• 很多复杂的任务需要很多个步骤，通常在某些环节还需要专业领域技能支持，比如科学计算深入研究、写代码、绘画、任务规划等。
• 单 Agent在复杂任务场景下的可维护性会变差。

1.反思（Reflection）

(1)基础介绍

在行动后（或思考过程中），Agent主动评估自身输出或行为的效果、质量、逻辑性与一致性，发现问题并据此调整后续行动或优化内部状态。这样处理能起到以下关键作用：

• 纠错与改进：检查代码错误、逻辑漏洞、事实性错误（幻觉）、答案的完整性。例如：生成代码后运行测试，发现报错则分析原因并修正。
• 优化输出：对生成的文本进行润色、精炼、调整风格或结构以满足更高要求（如：让摘要更简洁，让故事更生动）。
• 知识验证与推理校准： 检查推理链条是否合理，结论是否有证据支持，减少“一本正经胡说八道”。
• 策略调整：评估当前行动策略是否有效，是否需要改变方法。例如：多次尝试调用某个API失败后，反思是否参数有误或应换用其他工具。

(2)典型技术/方法

• ReAct: 在行动链中显式加入推理步骤。
• Chain of Verification (CoVe): 生成问题来验证自己答案的潜在缺陷。
• Self-Critique 或 Self-Refine 机制：让模型扮演“审查者”角色批判自己的输出。
• 引入外部验证器：使用代码解释器、搜索引擎结果、知识图谱等验证输出。

(3)ReAct

先推理，再行动。

• 思考（Thought）：面对一个问题，我们需要进行深入的思考。这个思考过程是关于如何定义问题、确定解决问题所需的关键信息和推理步骤。

• 行动（Action）：确定了思考的方向后，接下来就是行动的时刻。根据我们的思考，采取相应的措施或执行特定的任务，以期望推动问题向解决的方向发展。

• 观察（Observation）：行动之后，我们必须仔细观察结果。这一步是检验我们的行动是否有效，是否接近了问题的答案。

• 循环迭代

  **ReAct方式的作用就是协调LLM模型和外部的信息获取，与其他功能交互。如果说LLM模型是大脑，那ReAct框架就是这个大脑的手脚和五官。同时具备帮助LLM模型获取信息、输出内容与执行决策的能力。**对于一个指定的任务目标，ReAct框架会自动补齐LLM应该具备的知识和相关信息，然后再让LLM模型做出决策，并执行LLM的决策。

①优点

• ReAct将推理过程显性地记录下来，提升了模型的可信度和人类可解释性。相比直接给出答案，ReAct 通过逐步推理可以降低幻觉率。
• 由于每一步只需考虑当前子问题，响应速度较快，成本也较低。

②缺点

• LLM大模型的通病，即产出内容不稳定，不仅仅是输出内容存在波动，也体现在对复杂问题的分析，解决上存在一定的波动
• 成本，采用ReAct方式，我们是无法控制输入内容的。因为在任务提交给LLM后，LLM对任务的拆解、循环次数是不可控的。因此存在一种可能性，过于复杂的任务导致Token过量消耗。
• 响应时间，比起大部分API接口毫秒级的响应，LLM响应时间是秒级以上。在ReAct模式下，这个时间变得更加不可控。因为无法确定需要拆分多少步骤，需要访问多少次LLM模型。因此在在秒级接口响应的背景下，做成同步接口显然是不合适的，需要采用异步的方式。而异步方式，又会影响用户体验，对应用场景的选择又造成了限制。

③适用场景

ReAct 模式适用于相对中等复杂度的任务，尤其当任务步骤需根据中间结果动态调整时（如某个任务需要根据查询资料来决定给后续）；如果任务流程无法提前确定或需要频繁工具调用，ReAct 能提供较好的灵活性和实时反应能力。

2.工具使用模式（Tool Use）

工具使用让Agent突破大模型固有的限制（如时效性、计算能力、特定领域知识），能调用外部资源和能力。 Agent识别任务需求，判断需要何种外部工具，正确调用工具（提供符合要求的输入），并理解、整合工具的返回结果。

(1)关键作用

• 扩展能力边界： 获取实时信息（搜索引擎API）、执行精确计算（计算器）、操作软件/系统（如发送邮件、操作数据库）、访问专业领域知识（法律/医疗数据库）。

• 克服模型弱点： 解决知识过时、数学计算易错、无法直接操作外部系统等问题。

• 自动化工作流： 串联多个工具完成复杂任务（如：查天气 -> 推荐行程 -> 预订酒店）。

(2)典型技术/方法

• 函数调用 (Function Calling)：大模型核心支持能力，模型识别需要调用哪个预设函数并生成符合要求的参数。
• API 调用：连接各种网络服务（如 Google Search, Wolfram Alpha, Zapier）。
• 代码解释器 (Code Interpreter)： 执行生成的代码（通常是Python）进行数据处理、可视化、复杂计算等。
• 插件 (Plugins)： 为特定平台（如 ChatGPT）扩展的工具集。

3.Plan-and-Execute：先规划后调整

在行动之前，先生成一个较完整的计划，将任务拆解成子任务清单，然后逐一执行。

• 规划阶段（Planning）：分析任务目标，将其拆分为更小的步骤，形成一个有序的执行计划。规划可以通过LLM根据任务要求输出一个步骤列表，也可以结合工具或模板约束来确保计划的结构更完整。
• 执行阶段（Execution）：按照计划顺序逐个执行各个步骤，并处理每步的结果。在执行过程中，智能体可以根据实际执行情况动态调整计划，比如某一步如果结果不如预期，则可以修改后续步骤或重新规划。

(1)优点

• 流程更可控：可以审查或调整生成的计划，对执行结果有一定把控的效果。
• 可以实现可视化的任务执行过程： 有助于提升用户体验。

(2)缺点

• 开销更大：需要先额外一次（或多次）LLM调用来规划，再逐步执行，速度慢，token消耗也更高 。
• 对初始计划的正确性要求很高：如果初始计划不佳，执行阶段可能走弯路甚至失败。虽然可以动态调整，但调整本身又需要额外逻辑和模型交互。

(3)适用场景

• 适合较复杂的多步骤任务，尤其是可以在一定程度上预见步骤的场景 。例如数据分析任务可以先规划“获取数据->清洗->分析->可视化”的步骤。
• 当正确性比速度更重要时，Plan-and-Execute 是值得选择的策略 。

(4)典型技术/方法

• 思维链 (Chain of Thought - CoT)：显式展示推理步骤的基础。

• 任务分解与调度算法： 如基于LLM生成任务列表，可能结合传统规划算法或启发式规则进行排序。

• 旅行规划器模式： 处理具有强时空顺序的任务。

• 基于状态的规划： 根据环境状态变化决定下一步行动。

• 思维树 (Tree of Thoughts - ToT)：模拟多路径探索，评估不同思考路径的前景。像树一样展开，再通过评估机制选出最佳分支。比如解一道数独时，Agent会尝试多个候选解法(分支A、B、C)，逐步排除错误分支，最终选出唯一解。适合复杂规划和解谜任务。

4.Agent常见的优化方法

• 工具标注增强：为每个工具补充足够的结构化元数据，比如功能、输入/输出模式、耗时、幂等性、前置条件等，丰富LLM决策依据。

• 加入自我反思：在规划执行的过程中注入反思环节。比如在计划生成后立即审视并改进；且在任务完成后总结本次的成功或失败经验，存到案例库。

• “案例增强”的规划：基于案例库的“历史最优调用轨迹”，LLM 先检索相似任务的成功案例，用来帮助规划当前任务步骤。

• “检索增强”的工具选择：构建工具池的向量库（描述、调用示例、输入输出、业务标签等），在决策之前借助检索增强来缩小候选工具集。

• 微调Planner模型：记录实际调用‑执行‑结果链，打标签“成功/失败”；用 RL 奖励或对比学习微调专门的Planner模型。

• 思维链或深度思考：利用CoT让 LLM 显式输出逐步推理，强制模型按顺序拆解步骤（或使用深度思考模型），提升决策合理性。

二、工作流

工作流是一种编排模式，需要开发者将一个复杂任务拆解为一系列有序步骤，这些步骤之间的调用关系和条件分支在设计阶段就明确好。一个复杂的问题大模型可能不能很好的解决，那么我们可以把复杂问题拆解成多个小问题，不同小问题交给不同agent或者是工具来执行。当任务可以轻松且清晰地分解成固定的子任务时，这个工作流是最理想的。

1.静态顺序Workflow

• 人做整体规划的决策，LLM是链路的一个节点

• LLM和各类工具通过预定义的代码路径进行编排

• 提供可预测性和一致性

• 适用于明确定义的任务

  

该种方式几乎不让智能体自主决定流程，而是由开发者根据对任务的理解，将任务拆分成固定流程的子任务，并把这些子任务串起来执行。某些子任务可能由LLM完成（例如生成一段文字），但LLM在此不决定下一步做什么 — 下一步已经在程序固化。也就是说，智能体遵循一个事先画好的脚本/流程图来执行，没有决策自由度：

(1)优点

• 静态工作流最大的优点是确定性和可控性。所有步骤由开发者掌控，因而系统行为可预测、易测试，避免了让LLM自己规划可能带来的不确定性。从工程角度看，这种方式更像传统软件开发，调试和监控相对简单。
• 静态流程通常执行速度更快、成本更低，因为不需要额外的决策推理步骤。每个LLM调用都有明确目的，减少了无效对话。

(2)缺点

最大缺点是缺乏灵活性，智能化不足。

• 一旦预设流程无法完全匹配实际任务需求，Agent 就会表现不佳甚至失败。
• 不具有通用智能，只能覆盖开发者想到的那些路径。特别对于未知领域或复杂任务，开发者往往难以提前设计出完善的流程图。
• 如果业务流程发生变化，通常需要进行应用的调整或升级，成本较高，不如让智能体自主学习来得方便。

(3)适用场景

静态工作流适合规则明确、变化少的重复性任务。比如企业中的固定功能、固定报表生成等。特别在企业场景下，如果业务流程高度重复且标准化**，静态工作流能提供稳健的自动化方案 ，不必担心AI“越俎代庖”引入不确定性和风险。

2.静态Workflow+局部智能

在整体上采用固定流程，但在特定步骤上授予智能体一定的自主规划或推理权限。

(1)优点

这种模式最大优点是兼顾可控性与灵活性。

• 与全自主Agent相比，整体行为更可控，因为智能部分被限制在局部范围内，不会干涉整个流程结构。

• 相比纯静态流程，又具备了一定灵活应变能力——至少在那些标记出的复杂环节上，智能体可以随机应变。

• 可以逐步引入智能节点：从全静态开始逐步引入智能环节。

(2)缺点

• 增加系统复杂度，依赖开发者对任务的理解和持续调整。
• 局部智能体的表现仍然可能不稳定。

(3)适用场景

适用于流程较固定但存在关键智能决策点的任务场景。又或者一些长流程的子任务本身是复杂AI问题（如代码生成、数据分析），就特别适合拆出来让智能体发挥。实际项目中可以采用“静态框架 + 智能插件”的思路：框架提供流程壳子，插件（Agent）完成具体智能任务。

3.Routing-路由工作流

路由工作流通过对输入进行分类，将它们分派到专门设计的下游任务或处理路径(通常也叫做意图识别)，以实现关注点分离与更精准的响应。例如，在客服系统中，可以将用户咨询、退款请求、用户投诉等不同类型的用户问题路由到不同的处理流程与工具，或者在成本和速度优化中根据问题复杂度，将简单请求分发给小模型，而复杂或罕见问题则交给更强大的模型处理。

4.并行Workflow

• 分割：将任务分解成可以并行运行的独立子任务。

• • 实施防护措施，其中一个模型实例处理用户查询，而另一个筛选它们以防止不当内容或请求。这通常比让同一个LLM调用同时处理防护措施和核心响应表现得更好。
  • 自动化评估，用于评估LLM性能，每个LLM调用评估模型在给定提示上的不同方面的性能。

• 投票：多次运行相同的任务以获得多样化的输出。

• • 审查代码中的漏洞，多个不同的提示审查并标记代码，如果它们发现问题。
  • 评估给定内容是否不适当，多个提示评估不同的方面或需要不同的投票阈值来平衡误报和漏报。

三、多智能体(也可以放到工作流之中)

随着任务复杂度增加，单一智能体需要理解的语境和工具使用面临上下文窗口限制，导致性能下降。

多智能体协作通过动态任务分解、专业化分工和协同工作克服这一挑战。在处理复杂任务时，系统会将任务分解为多个子任务。每个子任务由专门的智能体处理，这些智能体在特定领域具有专长。

智能体之间通过持续的信息交换和任务协调来实现整体目标，这种协作方法可能产生智能涌现，即系统整体表现超越单个智能体能力之和。

在当前的现实中，在开发一个单智能体系统时会遇到的问题：

• 智能体可用的工具过多，在决定下一步调用哪个工具时效果不佳
• 上下文过多对于单个智能体来说过于复杂，难以跟踪
• 系统中需要多个专业领域(如规划器、研究员、数学专家等)
• …

为了解决上述的问题，可以考虑将应用拆分为多个更小的独立智能体，并将它们组合成一个多智能体系统，期望达到的效果

• 模块化：独立的智能体使开发、测试和维护变得更容易；
• 专业化：可以创建专注于特定领域的专家智能体，这有助于提高整个系统的性能。
• 控制：可以明确控制智能体之间的通信方式(而不是依赖于函数调用)。

1.多智能体使用方式

(1)架构

①Network(协作模式)

每个Agent都可与其他Agent通信。任何Agent都可以决定接下来调用哪个其他Agent。

较为常见的使用方式为"评估器**-优化器"模式**

LLM一个调用会产生响应，而另一个调用则会循环提供评估和反馈。当我们有明确的评估标准，并且迭代改进提供可衡量的价值时，此工作流程特别有效。良好契合的两个标志是，首先，LLM当人类表达他们的反馈时，反应可以得到明显改善；其次，LLM可以提供这样的反馈。这类似于人类作家在撰写一篇精美的文档时可能经历的迭代写作过程。

②Supervisor(指挥官模式)-常用

每个Agent与一个监督者Agent通信。监督者Agent决定接下来应该调用哪个Agent。

分层规划包含至少两个层级：

• 高层Agent（规划者/经理）：面向最终目标，制定子任务或子目标清单，分配给低层Agent。高层Agent关注全局进展，可能不直接与环境交互，而是通过检查下级完成情况来决定接下来做什么。
• 低层Agent（执行者/员工）：接受高层指派的具体子任务，在其自己能力范围内完成。低层Agent可能本身用ReAct或其他模式来解决子任务，然后将结果汇报给高层。

这种架构下，高层和低层可以都是LLM实例，扮演不同角色进行**多轮协作：**高层发号施令，低层报告结果，循环往复直到任务完成。

充分利用了职责分离的思想，每个Agent专注于其擅长的层面，提高效率和效果。高层Agent擅长宏观计划，确保不偏离大方向；低层Agent专注微观执行，可以投入更多细节推理（团队协作胜过一人包办）。

多子任务并行处理，提高速度（比如高层把任务分给两个低层Agent同时做不同部分）。某个子任务失败可以局部重新规划与执行，提高健壮性。

(2)协调者/控制器（Orchestrator/Controller）

这是整个系统的大脑，负责任务调度和Agent协同。它的主要职责包括：

• 任务分解：接收用户初始请求，并将其分解为一系列子任务。
• *工作流管理*：决定任务执行的顺序和逻辑（顺序、并行、条件分支）。
• *Agent调度*：根据子任务的要求，选择最合适的Agent来执行。
• *状态管理*：跟踪每个子任务的完成状态和整个项目的进度。

(3)通信机制：

• 消息传递（如基于聊天）
• 黑板模型：所有Agent都可以读写一个共享的存储区域（如数据库、内存数据结构）。Agent将结果写入共享区，其他Agent从中读取所需信息。这种方式更适用于数据流密集的应用。
• 发布/订阅等：Agent之间通过发送和接收结构化的消息（如JSON格式）进行交互

(4)协作协议

• 辩论机制
• 投票机制
• 竞标机制
• 领导协调机制

2.适用场景

当任务规模庞大或专业模块众多时，分层/多Agent是很自然的选择。例如一项软件工程任务，从需求分析、设计、编码、测试到文档，每一步都可由不同Agent完成，由总负责人Agent协调。再如学术研究Agent，一个负责制定研究计划，几个分别去查文献、做实验、分析数据，最后综合。

四、低代码与高代码

1.从低代码到高代码

在 AI 原生应用的早期探索中，低代码工具发挥了重要作用。Dify、Coze、阿里云百炼、Cloud Flow、n8n 等产品，通过可视化编排和模板化配置，使非专业开发者也能快速拼装出应用雏形。这类工具极大降低了试错成本，为企业内部的概念验证(PoC)和小规模试点提供了便利。

低代码平台在运行时也离不开底层引擎的支撑，大多数低代码平台的底层引擎和管控部署在一起，这限制了 Agent 的性能和可扩展性。但更重要的原因在于低代码平台是对于高代码的一层封装，其抽象层次很难满足所有场景，无法在性能、可扩展性和复杂业务逻辑方面满足大规模生产的要求。这也是为什么在进入大规模生产应用阶段后，很多低代码方案都需要迁移到高代码框架中实现。

高代码则代表了当下 AI原生应用生产落地的主流形态。ADK、LangGraph、AutoGen、AgentScope、Spring Al Alibaba等框架，为开发者提供了面向 Agent 的编程接口。相比低代码，高代码具备更高的性能可控性、更强的灵活性以及更好的可预测性，能够支撑复杂场景下的业务逻辑实现与系统集成。

2.高代码的演进

在 AI 原生应用的三种构建模式中，高代码模式最贴近工程师对系统的可控需求。此类开发方式不限于使用现成 Agent 框架，更注重灵活的编排、精准的上下文控制、可靠的执行机制，以及对复杂任务的支撑能力。

框架使得上手变得容易。然而，它们经常创建额外的抽象层，这可能会掩盖底层的提示和响应，使得调试变得更加困难。

高代码模式本身经历了从 ChatClient→Workflow→Agentic 的演进过程。

• ChatClient 阶段:最初的实现仅是一次单一的 LLM 调用，简单但缺乏复杂任务执行能力;
• Workflow 阶段:通过将传统工作流转化为 LLM 节点编排，实现了自主性与确定性的初步平衡，但由于编排复杂，维护成本较高;
• Agentic 阶段:逐渐成为主流形态。它通过提供面向 Agent的 API，并内置多种通用的协作模式(Pattern)，使开发者能够在 Agentic自主性 和 Predictability(可预测性)之间取得平衡，从而兼顾开发效率与执行准确性。

最后

选择AI大模型就是选择未来！最近两年，大家都可以看到AI的发展有多快，时代在瞬息万变，我们又为何不给自己多一个选择，多一个出路，多一个可能呢？

与其在传统行业里停滞不前，不如尝试一下新兴行业，而AI大模型恰恰是这两年的大风口，人才需求急为紧迫！

由于文章篇幅有限，在这里我就不一一向大家展示了，学习AI大模型是一项系统工程，需要时间和持续的努力。但随着技术的发展和在线资源的丰富，零基础的小白也有很好的机会逐步学习和掌握。

【2025最新】AI大模型全套学习籽料（可无偿送）：LLM面试题+AI大模型学习路线+大模型PDF书籍+640套AI大模型报告等等，从入门到进阶再到精通，超全面存下吧！

获取方式：有需要的小伙伴，可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
包括：AI大模型学习路线、LLM面试宝典、0基础教学视频、大模型PDF书籍/笔记、大模型实战案例合集、AI产品经理合集等等

AI大模型学习之路，道阻且长，但只要你坚持下去，就一定会有收获。