前言：大模型时代Agent的定义虽各有千秋，但在总体上Agent具有以下共性：基于大语言模型（LLM）构建的智能系统，能够主动感知环境、推理规划、执行复杂行动，并通过持续学习实现自我进化。与传统的AI系统不同，LLM agents不仅仅是被动响应用户输入，而是具备自主决策和执行能力的“自主代理”。

我们可以抓取一个最精简、也是最核心的公式：Agent = LLM + Tools

1. Authropic

Authropic把涉及到智能体的内容统一称为：agentic systems，在细节处对workflow和agent做了重要的架构区分，因此两者属于两类不同的系统：

• Workflow：通过预定义的代码路径来编排大模型和工具。
• Agent：大模型自己决定流程和使用的工具，自主控制如何完成任务。

1.1 Workflow

a）提示链（Prompt chaining）

提示链将任务拆解为一系列的子任务：

• 每个LLM call处理前一个LLM call的输出；
• 可以在中间节点任何步骤添加检查点（图中的网关），以确保处理过程仍在正确的轨道上。

b）路由（Routing）

通过路由对输入进行分类，并将其转发到专门的后续的任务（specialized followup task）。

• 将任务的关注点进行拆解，从而针对每一个具体任务设计和调整提示词。
• 否则，（all-in-one）提示词不仅很长，而且针对任何一种任务的提示词优化都可能导致其他任务的性能下降。

c）并行化（Parallelization）

多个任务同时进行，然后对输出进行聚合处理。考虑两个场景：

1. 分段（Sectioning）：类似MapReduce，将任务分解为独立的子任务并行运行，最后对输出进行聚合。
2. 投票（Voting）：相同的任务并行执行多次，以获得多样化的输出。

d）编排者-工作者（Orchestrator-workers）

在这种Workflow中，一个中心式LLM动态地分解任务，将其委托给worker LLM，并汇总他们的结果。

e）评估者-优化者（Evaluator-optimizer）

在这种Workflow中，一个LLM call生成响应内容，而另一个提供评估和反馈，形成一个闭环。

1.2 Agent

Agent一般从下面的场景收到任务并开始执行：

1.明确收到的人类指令；

2.与人类交流到一定的程度时，理解了自己接下来应该做什么。

一旦任务明确，Agent就会独立规划和执行，中间也可能会问人类一些问题，以获取更多信息或帮助它自己做出正确判断。

• 在Agent 执行过程中，对它来说最重要的是每一步执行之后，都能从环境中获得“真实信息（例如工具调用或执行代码），以帮助它评估任务的进展。
• Agent 可以在检查点或遇到障碍时暂停，然后向人类获取帮助。
• 任务通常在完成时终止，但也可以包括停止条件（例如最大迭代次数），以避免Agent行为不可控。

在实现Agent时，建议遵循三个核心原则：

1.Agent 设计的简洁性。

2.Agent 工作过程的透明性，例如能明确显示Agent的规划和步骤。

3.通过完善的文档和测试,精心设计Agent与计算机之间的接口(agent-computer interfaces,ACl)。

[!note]

不管是Workflow 还是Agent，都是一种模式，而不是规范，开发者可以组合和改造这些模式来实现自己的AI系统。成功的关键，是能衡量系统的性能，然后不断对实现进行改进和迭代。

大模型领域的成功并不是构建最复杂的系统，而是构建符合你需求的系统。从简单的提示词开始，不断评估和优化，只有在简单的解决方案真的解决不了问题时，才应该考虑引入multi-step agentic systems。或者换句话说，只有在性能有明显改善时，才应该考虑增加复杂性。

2. OpenAI

OpenAI把框架设计为编排（Orchestration），共分为两类：

1.单智能体系统：由一个配备了适当工具和指令的模型在循环中执行工作流。

2.多智能体系统：在多个相互协调的Agent之间执行工作流。

2.1 单智能体系统

单个Agent可以通过逐步添加工具来处理许多任务，这样可以控制复杂性，简化评估和维护。

每个编排方法都需要“运行”的概念，通常实现为一个循环，让智能体一直运行，直到满足退出条件。常见的退出条件包括工具调用、特定的结构化输出、错误或达到最大轮数。

2.2 何时考虑多智能体系统

建议：优先发挥单智能体系统的能力。

以下是常见需要拆分Agent的两个参考标准：

1.逻辑复杂：当提示词中包含大量的条件判断（如多个if-then-else分支），或模板逻辑变得难以维护时，建议按照逻辑片段将任务拆分给不同的Agent分别处理。

2.工具过载：问题不在于工具数量本身，而在于它们之间的相似度和重叠度。有些系统能成功管理15个以上定义清晰的工具，而另一些则在不到10个模糊重叠的工具中就出现混乱。

2.3 多智能体系统

多智能体系统可以根据不同的业务流程和场景需求，设计出各种架构。

但从实际客户经验来看，我们总结出两种通用、可落地的设计模式：

1.管理者模式（Agent作为工具本身），由一个中心Agent担任“管理者”角色，通过工具调用的方式调度多个专职Agent，每个Agent负责一个具体任务或领域。

在现在的发展中为了解决 Agent 之间的信息互通问题，一些新的协议开始进入起草阶段，其中比较受关注的有：

• ANP（Agent Network Protocol）：中国开发者率先提出并推动的一个协议。
• A2A（Agent-to-Agent）Protocol：Google 也在探索类似的概念和协议。

这些协议的核心目标，大致可以归纳为两点：

• **第一，让 Agent 之间明确彼此的能力，便于协作。**就像外包网站的个人主页，清晰写明自己的专长，其他人可以按需查找，找到合适了的人就一起做项目。
• 第二，让 Agent 之间可以高效地传递信息。就像团队协作之前，大家约定好沟通方式（比如人会约定好用飞书还是用钉钉）以及消息格式（类似布置任务需要包含哪些信息）。

至于未来哪个协议会成为主流，现在下结论还为时尚早。

2.去中心化模式（Agent之间相互交接）多个Agent平行运行，彼此间根据各自专长进行任务接力和分工协作。

多Agent系统可以被抽象为一张图谱，图中的节点代表Agent：在管理者模式中，连线表示工具调用；在去中心化模式中，连线表示任务的转交和流转。

3. Google

Agent中有三个核心组件，如图所示：

3.1 Model(模型)

这里指的是用作 Agent 中用来做核心决策的语言模型（LM）。

• 可以是一个或多个任何大小的模型，能够遵循基于指令的推理和逻辑框架，如 ReAct、Chain-of-Thought、Tree-of-Thoughts。
• 可以是通用的、多模态的，或根据特定 Agent 架构的需求微调得到的模型。
• 可以通过“能展示 Agent 能力的例子或数据集”来进一步微调模型，例如 Agent 在什么上下文中使用什么工具，或者执行什么推理步骤。

3.2 Tool(工具)

基础模型在文本和图像生成方面非常强大，但无法与外部世界联动极大限制了它们的能力。 工具的出现解决了这一问题。有了工具，Agent 便能够与外部数据和服务互动，大大扩展了它们的行动范围。

工具可以有多种形式，常见是 Web API 方式，即 GET、POST、PATCH 和 DELETE 方法。 例如，结合用户信息和获取天气数据的 tool，Agent 可以为用户提供旅行建议。

有了工具，Agent 可以访问和处理现实世界的信息，这使它们能够支撑更专业的系统，如检索增强生成（RAG），显著扩展了 Agent 的能力。

3.3 Orchestration(编排层)

编排层描述了一个循环过程：Agent 如何接收信息，如何进行内部推理，如何使用推理来结果来指导其下一步行动或决策。

• 一般来说，这个循环会持续进行，直到 Agent 达到其目标或触发停止条件。
• 编排层的复杂性跟 Agent 及其执行的任务直接相关，可能差异很大。 例如，一些编排就是简单的计算和决策规则，而其他的可能包含链式逻辑、额外的机器学习算法或其他概率推理技术。

4. 建议框架一

AI下半场，聊一聊 Agent 本质与变革 | 大白话技术科普系列@Jomy

目前，大厂对Agent框架的分类方法各有不同，有的强调技术栈（如基于LLM的、基于规则的），有的强调功能定位（如对话型、任务型、工具调用型），还有的从交互模式来区分（如单体Agent与多Agent协作）。

这些分类方法各有价值，但往往存在边界模糊：定义不一的问题。相比之下，通过系统可控性与自动化程度为标准来划分，更直观也更便于理解。

基于这一思路，可以将Agent框架分为三类：手动Agent框架（白盒系统）、半自动Agent框架（灰盒系统）、全自动Agent框架（黑盒系统）。这种分类方式不仅能体现系统的“黑箱程度”，也能帮助我们更清晰地理解不同 Agent 在实际应用中的定位与适用场景。

4.1 手动Agent框架【白盒系统】

开发者预先设定好任务执行的每一步计划，明确规定哪个步骤使用哪个工具，LLM主要负责在预设节点上填充内容或做简单决策。

可以称之为工作流（Workflow），它是一个白盒系统。

Dify和Coze就是典型的代表，能够提供可视化流程编排工具。此时Tools的执行步骤，在很多时候是被人强制执行的，以此换取更多的确定性。

手动 Agent 框架 = LLM + Tools + Workflow

4.2 半自动Agent框架【灰盒系统】

将 AI 预设为不同身份的垂直 Agent（系统提示词+特定工具），每个垂直 Agent 完成不同的子任务，最后通过框架将每个子任务的执行过程和结果组合起来，完成最终目标。

我称之为 Multi-Agent System（多 Agent 系统），它是一个灰盒系统。

Manus 和扣子空间的规划模式就是典型的多 Agent 框架。规划和记忆管理都属于编排的一部分。

半自动 Agent 框架 = LLM + Tools + Prompt + Orchestration（编排）

4.3 全自动Agent框架【黑盒系统】

只给模型设定一个最终目标，模型接收到目标就开始自我循环，直到完成目标或遇到无法解决的障碍。

全自动 Agent 框架是最简洁的，调用工具的那几行代码，就是其全部的核心了，复杂过程全部交由模型去解决。

我称之为 Single-Agent System（单 Agent 系统），也就是所谓的通用 Agent，它是一个黑盒系统。

模型自主完成工具调用这个操作，就是全自动 Agent 框架了，如果模型没有 Tool Use 功能，也可以通过代码来实现。

全自动 Agent 框架 = LLM + Tools

**需要强调的是，这 3 种框架并不是对立关系，而是常常组合使用。**比如，Multi-Agent 系统可以与 Workflow 相结合，Single-Agent 系统也是 Workflow 和 Multi-Agent 系统的重要组成部分。

5. 建议框架二

LLM Powered Autonomous Agents

在 LLM 驱动的自主智能体系统中，LLM 作为智能体的核心，辅以几个关键组件：

• Planning 规划

  1. 子目标和分解：智能体将大型任务分解为更小、更易于管理的子目标，从而能够高效处理复杂任务。
  2. 反思与改进：智能体可以对过去的行动进行自我批评和自我反思，从错误中学习并改进它们以用于未来的步骤，从而提高最终结果的质量。

• Memory 记忆

  1. 短期记忆：我会将所有情境学习（参见提示工程）视为利用模型的短期记忆来学习。
  2. 长期记忆：这为智能体提供了在长时间内保持和回忆（无限）信息的能力，通常通过利用外部向量存储和快速检索来实现。

• Tool use 工具使用

  1. 代理学会调用外部 API 以获取模型权重中缺失的额外信息（这些信息通常在预训练后难以更改），包括当前信息、代码执行能力、访问专有信息源等。

总结

这里给一个明确的结论： 受限于当前 LLM 的可控性以及能力，指望一个全能的模型 + 简洁的单 Agent 系统包打天下，在短期内是不现实的。Multi-Agent 系统将是未来相当长一段时间内构建复杂、可靠 Agent 应用的主流范式。

在垂直 Agent 优化实践中，有几条关键经验，也在此分享给大家：

• 明确的指引。在实践中体现为精准的系统提示词。
• 垂直的工具。在实践中体现为只接入任务强相关的 MCP Server。
• 完整的上下文。在实践中体现为完善的任务描述和任务记忆。