Agentic Engineering技术解析：从单Agent到多Agent协作的范式演变

技术篇 | 适合技术负责人、架构师、AI工程师阅读

引言

2026年2月，Andrej Karpathy在回顾自己一年前提出的“Vibe Coding”概念时，给出了一个新的定义：“如今，通过LLM智能体进行编程正日益成为专业人士的默认工作流程……其目标是在不牺牲软件质量的前提下，充分利用智能体的优势。许多人试图为这种方法想出一个更好的名称，我个人目前最喜欢的是Agentic Engineering。”

他给出了两个核心理由：Agentic——因为开发者99%的时间不再直接写代码，而是协调智能体并进行监督；Engineering——因为这是一门有深度的学科，有其自身的艺术、科学和专业知识，需要长期学习与精进。

从单Agent到多Agent协作，不仅仅是“多了一个Agent”那么简单，而是一次系统复杂度和工程范式的本质跃迁。本文将为技术负责人和架构师拆解这条演进路径上的核心技术要素——从基础概念到架构模式，再到技术选型与落地挑战。

第一部分：基础概念——从Agent到Agentic Engineering

什么是AI Agent？

AI Agent是一个能够感知环境、自主决策并执行动作的智能实体。它基于大语言模型的理解和推理能力，调用外部工具（API、数据库、代码执行环境）来完成特定任务。

一个Agent的核心能力包括：

• 理解：解析用户意图和上下文

• 推理：规划完成任务的步骤

• 行动：调用工具执行具体操作

• 反馈：根据执行结果调整后续行为

什么是Agentic Engineering？

Agentic Engineering不是某个技术产品，而是一套设计、开发、部署、运营和治理AI Agent的完整工程方法论与基础设施。

它要解决的核心问题包括：

• 多个Agent如何在同一个业务场景中有序协作？

• 如何确保Agent的每一次操作都在合规框架内？

• Agent出错时，系统如何自动降级而不中断业务？

• Agent的决策过程如何做到可追溯、可审计？

从单Agent到多Agent：一次本质跃迁

| 维度

|

单Agent模式

|

多Agent协作模式

任务复杂度

单一任务、边界清晰

|

复合任务、需要拆解与分工

| | 状态管理 |

单会话状态

|

跨Agent、跨会话的共享状态

| | 容错机制 |

单点失败即整体失败

|

部分Agent失败可降级或切换

| | 扩展方式 |

优化单个Agent的提示词和工具

|

增加或调整专业Agent角色

| | 工程复杂度 |

⭐⭐

|

⭐⭐⭐⭐⭐

|

多Agent协作不是“多个Agent各自独立工作”，而是“一群Agent按照既定协议协同完成一个复杂目标”。

第二部分：Agentic程度的光谱——从Router到Autonomous Agent

LangChain创始人Harrison Chase引用Andrew Ng的观点指出：与其争论哪些系统算“真正的AI Agent”，不如承认系统的Agentic程度是一个光谱。一个系统越“Agentic”，就越需要新的工具和基础设施来支撑它——包括编排框架、持久化执行、运行时观测和评估体系。

Agentic程度三层级

| 层级

|

模式

|

自主性

|

技术特征

|

典型场景

L1 Router

LLM决定输入走哪条路径

|

少量自主性

|

单次LLM调用，输出直接决定路由方向

|

简单路由、意图分类

| | L2 State Machine |

多步路由+循环决策，直到任务完成

|

中等自主性

|

多轮LLM调用，状态持久化，条件分支与循环

|

客户服务流程、审批工作流

| | L3 Autonomous Agent |

自主构建工具、记忆经验、持续进化

|

高度自主性

|

自主工具调用、长期记忆、经验复用、自我反思

|

多Agent协同开发、自主软件工程

|

关键洞察：大多数企业应该从L2起步，而非直接追求L3。L3的技术复杂度和失控风险目前仍处于探索阶段。

第三部分：架构演进的四种范式

从单Agent到多Agent协作，技术架构经历了四种典型范式的演进。这些范式的核心区分维度是：Agent数量、协作方式、状态管理的复杂度。

范式一：单Agent模式（Single Agent）

核心特征：

• 一个Agent独立完成从任务理解到执行的全流程

• 通过ReAct（推理+行动）循环持续迭代

• 调用多个工具，但所有决策由同一个Agent做出

技术实现：

python

<span style="color: rgb(160, 161, 167);font-style: italic;"><span leaf=""># LangGraph单Agent模式伪代码</span></span><span leaf="">graph&nbsp;</span><span style="color: rgb(64, 120, 242);"><span leaf="">=</span></span><span leaf="">&nbsp;StateGraph</span><span style="color: rgb(56, 58, 66);"><span leaf="">(</span></span><span leaf="">AgentState</span><span style="color: rgb(56, 58, 66);"><span leaf="">)</span></span><span leaf="">graph</span><span style="color: rgb(56, 58, 66);"><span leaf="">.</span></span><span leaf="">add_node</span><span style="color: rgb(56, 58, 66);"><span leaf="">(</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"agent"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">,</span></span><span leaf="">&nbsp;agent_node</span><span style="color: rgb(56, 58, 66);"><span leaf="">)</span></span><span style="color: rgb(160, 161, 167);font-style: italic;"><span leaf=""># 推理节点</span></span><span leaf="">graph</span><span style="color: rgb(56, 58, 66);"><span leaf="">.</span></span><span leaf="">add_node</span><span style="color: rgb(56, 58, 66);"><span leaf="">(</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"tools"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">,</span></span><span leaf="">&nbsp;ToolNode</span><span style="color: rgb(56, 58, 66);"><span leaf="">(</span></span><span leaf="">tools</span><span style="color: rgb(56, 58, 66);"><span leaf="">)</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">)</span></span><span style="color: rgb(160, 161, 167);font-style: italic;"><span leaf=""># 工具执行节点</span></span><span leaf="">graph</span><span style="color: rgb(56, 58, 66);"><span leaf="">.</span></span><span leaf="">add_conditional_edges</span><span style="color: rgb(56, 58, 66);"><span leaf="">(</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"agent"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">,</span></span><span leaf="">&nbsp;should_continue</span><span style="color: rgb(56, 58, 66);"><span leaf="">,</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">{</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"continue"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">:</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"tools"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">,</span></span><span style="color: rgb(80, 161, 79);"><span leaf="">"end"</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">:</span></span><span leaf="">&nbsp;END</span><span style="color: rgb(56, 58, 66);"><span leaf="">}</span></span><span style="color: rgb(56, 58, 66);"><span leaf="">)</span></span>

适用场景：边界清晰、工具调用链明确的单一任务（如文档摘要、数据查询、代码生成）。

优缺点：

• ✅ 实现简单，调试方便

• ❌ 无法处理需要多角色协作的复杂任务

• ❌ 单点决策容易产生上下文遗忘和推理偏差

范式二：监督者-工作者模式（Supervisor-Worker）

核心特征：

• 一个“监督者Agent”负责拆解任务并分配给多个“工作者Agent”

• 工作者各自完成子任务，结果汇总给监督者

• 监督者负责质量把控和最终整合

协作流程：

text

<span leaf="">用户请求 → 监督者Agent拆解任务 &nbsp; &nbsp;├── 工作者Agent A（数据收集）→ 返回结果 &nbsp; &nbsp;├── 工作者Agent B（数据分析）→ 返回结果 &nbsp; &nbsp;└── 工作者Agent C（报告生成）→ 返回结果监督者Agent整合 → 最终输出</span>

适用场景：可并行拆解的复合任务（如市场调研报告生成、多维度数据分析）。

技术框架：LangGraph的create_react_agent、CrewAI的Process、AutoGen的GroupChat。

优缺点：

• ✅ 任务并行处理，效率高

• ✅ 每个Agent聚焦单一职责

• ❌ 监督者Agent的拆解质量决定了整体成败

• ❌ 工作者之间缺乏横向沟通

范式三：交接模式（Handoff）

核心特征：

• 多个Agent按顺序接力完成一个长流程任务

• 每个Agent完成自己的部分后，将上下文状态“交接”给下一个Agent

• 交接点包含：完成的工作成果、未解决的问题、下一步需要关注的要点

协作流程：

text

<span leaf="">用户请求 → Agent A（需求理解）→ 交接 → Agent B（方案设计）→ 交接 → Agent C（代码实现）→ 最终输出</span>

适用场景：有明确阶段性产出的长流程（如软件开发的“需求→设计→编码→测试”）。

技术实现要点：

• 状态对象需要在Agent之间传递和积累

• 交接协议需要标准化（包含完成状态、产出物、待办事项）

• 每个Agent只关注自己的专业领域，不越界

优缺点：

• ✅ 流程清晰，责任分明

• ✅ 每个Agent可以深度优化自己的环节

• ❌ 流程是线性的，某个环节失败会影响整体

• ❌ Agent之间缺乏迭代反馈（下游无法向上游提出修改）

范式四：协作网络模式（Collaborative Network）

核心特征：

• 多个Agent形成网状协作关系，可以相互通信、辩论、迭代

• 无单一“监督者”——决策通过协商或投票达成

• 适用于没有标准答案的开放性复杂问题

子模式：

| 子模式

|

说明

|

典型场景

辩论（Debate）

多个Agent各自提出方案，相互质询辩论，最终达成共识

|

复杂决策、方案评估

| | 批评-修正（Critic-Refine） |

生成器Agent产出草稿，批评者Agent提出修改意见，迭代优化

|

代码审查、内容质量保证

| | 投票（Voting） |

多个Agent分别给出判断，通过多数表决确定最终结论

|

不确定性高的判断任务

|

适用场景：高复杂度、高不确定性的开放任务（如产品方案设计、技术选型决策、合规风险评估）。

技术框架：AutoGen（原生支持辩论模式）、CrewAI（支持层级和网络流程）。

优缺点：

• ✅ 适合复杂开放问题，容错性强

• ✅ Agent之间可以相互纠错，减少幻觉

• ❌ 技术复杂度最高，Token消耗巨大

• ❌ 可能陷入循环辩论，需要“仲裁者”机制

第四部分：核心技术挑战与应对策略

以下是企业从单Agent演进到多Agent协作时，最常遇到的五个技术挑战及应对方案。

挑战一：上下文窗口限制

问题：多Agent协作中，共享上下文迅速膨胀，单个Agent的上下文窗口容易被撑爆。

应对策略：

• 结构化记忆：使用CLAUDE.md/AGENTS.md编码项目架构和约束，采用渐进式披露——主文件保持在300行以内，细节通过按需加载

• 分层上下文：全局上下文（项目规范）+ 局部上下文（当前任务），Agent按需获取

• 向量检索：长期记忆通过向量数据库存储，Agent按语义检索相关信息，而非全部加载

挑战二：多Agent协作的死锁与冲突

问题：多个Agent互相等待、意见冲突、覆盖彼此的工作。

应对策略：

• 引入“仲裁者”机制：在关键决策点由人类或专门的“仲裁者Agent”介入，打破僵局

• 明确依赖关系：任务分解时标注依赖图，独立任务并行、依赖任务串行

• 单一职责原则：每个Agent只聚焦一个专业领域，不越界操作

• 设置超时和熔断：单个Agent若超过指定时间未完成，自动跳过或转人工

挑战三：幻觉控制

问题：LLM概率性输出导致幻觉——在多Agent协作中，幻觉会通过Agent之间的交互被放大。

应对策略：

• RAG优先：Agent的每个回答先检索知识库，再基于检索结果生成

• 置信度打分：Agent输出附带置信度评分，低于阈值自动转人工

• 双重验证：关键输出由两个不同的Agent分别生成并比对，不一致时触发人工介入

• 结构化输出约束：使用Pydantic Schema强制Agent返回类型安全的对象，而非自由文本

挑战四：成本控制

问题：多Agent模式下，每步都调用LLM，Token消耗呈指数增长。

应对策略：

• 模型路由：简单任务用小模型（如Llama-3.1-8B），复杂任务用大模型

• 提示词压缩：减少不必要的上下文加载，仅传递当前任务所需信息

• 缓存机制：重复查询结果直接缓存，避免重复调用LLM

• 分流策略：高频、固定、规则清晰的任务交给规则引擎处理，不经过LLM

挑战五：可观测性缺失

问题：多Agent协作链路长，出错后难以定位是哪个Agent的哪个决策出了问题。

应对策略：

• 全链路追踪：每个Agent节点的输入、输出、耗时、模型版本全部记录

• 节点化日志：每个决策点独立记录，便于事后复盘

• 成本归因：按Agent/任务/用户维度拆分Token消耗，定位成本黑洞

第五部分：技术选型推荐

基于当前主流技术生态，以下是不同需求场景下的选型建议：

| 需求场景

|

推荐框架

|

理由

轻量级POC

LangChain + OpenAI API

|

生态成熟，上手最快

| | 企业级稳定工作流 |

LangGraph

|

原生支持状态管理和持久化，适合L2及以上模式

| | 多Agent复杂协作 |

AutoGen（微软）/ CrewAI

|

原生支持Supervisor-Worker、Handoff、Debate等模式

| | 强合规需审计追踪 |

自研编排引擎 + 标准化日志中间件

|

商业工具难以满足定制化审计需求

| | AWS生态 |

AWS Strands Agents SDK

|

与AWS服务深度集成

|

选型关键原则

1. 从L2起步，不盲目追求L3：L3（全自主Agent）的技术复杂度和失控风险仍处于探索阶段，大多数企业应从“人机协同”开始

2. 先看可观测性，再看模型能力：决定项目成败的往往是“出错了能否快速定位”，而非“支持GPT-4还是Claude”

3. 小场景切入，数据驱动扩展：先用2-3周做一个低风险POC，拿到真实数据（效率、人工介入率、成本）后再决定是否扩大

结语

Agentic Engineering不是“Vibe Coding的升级版”，而是一种截然不同的工程范式。它要求工程师完成三重角色转变：

| 维度

|

传统开发

|

Agentic Engineering

角色

代码编写者

|

Agent协调者 + 监督者

| | 工作方式 |

逐行编写代码

|

定义目标 → 拆解任务 → 审核Agent输出

| | 调试方式 |

修复代码语法错误

|

调试工作流本身——调整工具、搜索策略或提示词约束

|

从单Agent到多Agent协作的演进，本质上是从“让AI帮你做一件事”到“让一群AI帮你完成一个业务系统”的跃迁。前者是工具，后者是生产力。

正如Google Research所定义的：“Agentic Engineering是将LLM视为执行复杂多步工作流的半自主系统，而非简单自动补全引擎的严谨学科。”

框架会变，API会变，但Agentic Engineering的设计原则会持久。当你的团队准备好从“与一个Agent对话”升级到“编排一群Agent协作”时，本文的范式演变与选型指南，就是你出发的起点。

上一篇战略文章回顾：《Agentic Engineering：企业AI规模落地的实践路径》——从战略与管理视角的系统论述，适合企业决策者阅读。

📌 术语速查表

| 术语

|

简要解释

ReAct

推理（Reasoning）与行动（Acting）的交替循环，Agent边思考边执行

| | RAG |

检索增强生成，在LLM生成前先从知识库检索相关信息，减少幻觉

| | Supervisor-Worker |

监督者-工作者模式，一个Agent拆解任务分配给多个专业Agent

| | Handoff |

交接模式，Agent完成后将上下文状态传递给下一个Agent

| | Human-in-the-Loop |

人在环中，关键节点需要人工确认才能继续

| | Function Calling |

LLM调用外部函数/API的能力，让Agent能操作外部系统

| | LangGraph |

LangChain生态的工作流编排框架，支持状态管理和复杂图结构

|