Agent工程架构
2606 字约 9 分钟
domain/aiai/agents
2026-07-24
Agent 工程架构是从"能跑的 demo"到"可运维的生产系统"的桥梁。核心问题不是"LLM 够不够强"，而是如何组织感知、推理、执行、记忆四大模块，让系统可扩展、可调试、可恢复。
一句话解释
Agent 工程架构 = 分层设计（感知/推理/执行/记忆） + 编排模式（Router/Orchestrator/Worker/Pipeline） + 框架选型 + 可观测性，决定了系统的可扩展性和可维护性。
分层架构
四层模型
关键洞察：各层之间通过显式状态对象传递数据，而非隐式依赖。这是 LangGraph 等框架的核心设计哲学——状态是数据的"总线"，每层的输入输出都经状态中转。
与传统软件架构的区别
| 维度 | 传统微服务 | Agent 架构 |
|---|---|---|
| 控制流 | 确定性路由（代码 if-else） | 非确定性路由（LLM 推理决定） |
| 状态管理 | 分布式事务/Saga | 检查点 + 断点续跑 |
| 错误处理 | 重试 + 熔断 + 降级 | 重试 + 重规划 + 人工介入 |
| 可观测性 | APM（调用链/指标） | LLM 调用链 + token 消耗 + 决策追踪 |
| 测试方式 | 单元测试 + 集成测试 | 端到端评估 + 基准测试 |
| 部署形态 | 容器 + 编排器 | 容器 + LLM API + 工具服务 |
架构设计模式
1. Router（路由器）模式
- 适用场景：多技能 Agent 系统，请求类型多样
- 优势：每个子 Agent 专注一个领域，Prompt 精简
- 劣势：Router 判断错误会路由到错误 Agent
- 实现：OpenAI Agents SDK 的 Handoff 机制
2. Orchestrator-Worker（编排器-工人）模式
- 适用场景：复杂任务需要分解和并行执行
- 优势：Orchestrator 全局视角，Worker 专注执行
- 劣势：Orchestrator 是单点，其规划质量决定整体效果
- 实现：LangGraph 的 Supervisor 模式、CrewAI 的 Crew + Manager
3. Pipeline（流水线）模式
- 适用场景：流程明确、步骤固定的任务
- 优势：简单直接，每步可独立测试
- 劣势：灵活性差，无法动态调整流程
- 实现：Google ADK 的 SequentialAgent
4. Autonomous Loop（自主循环）模式
- 适用场景：开放式、探索性任务（研究、代码开发）
- 优势：最接近"自主智能"的形态
- 劣势：循环可能不终止，成本不可预测
- 实现：ReAct 模式、AutoGPT、BabyAGI
模式选型决策
| 任务特征 | 推荐模式 | 理由 |
|---|---|---|
| 请求类型多样，需路由 | Router | 专业化分工 |
| 复杂任务，可分解 | Orchestrator-Worker | 并行执行 + 全局协调 |
| 流程固定，步骤清晰 | Pipeline | 简单可靠 |
| 开放探索，无固定流程 | Autonomous Loop | 灵活适应 |
| 需要高可靠性 + 人工审批 | Orchestrator-Worker + HITL | 可控 + 可审计 |
单体 Agent vs 多 Agent 架构
选型核心问题
"N 个 Agent = N 倍 LLM 调用，什么时候值得？"
| 维度 | 单 Agent | 多 Agent |
|---|---|---|
| 成本 | 低（一次 LLM 调用循环） | 高（N 倍调用 + 通信开销） |
| 复杂度 | 低（一个控制循环） | 高（协调 + 通信 + 状态同步） |
| 专注度 | 低（一个 Prompt 承载所有能力） | 高（每个 Agent 专注一个领域） |
| 可调试性 | 中（单一调用链） | 低（多 Agent 交互复杂） |
| 适用任务 | 单一领域、中等复杂度 | 跨领域、高复杂度、可并行 |
| 典型场景 | 客服 Bot、数据分析助手 | 软件开发团队、研究协作 |
经验法则：
- 能用单 Agent 解决的，不要用多 Agent
- 当 Prompt 超过 2000 token 或工具超过 10 个时，考虑拆分
- 子任务之间高度独立时，多 Agent 的并行优势才能体现
详见 多Agent协作。
主流框架对比
2026 年框架格局
2025-2026 年，Agent 框架完成了第一轮洗牌。主流选择已从"百花齐放"收敛到几个核心选项：
| 框架 | 核心抽象 | 设计哲学 | 最佳场景 |
|---|---|---|---|
| LangGraph | 有向图（状态机） | 精细状态控制 | 复杂业务流程、高合规场景 |
| OpenAI Agents SDK | Agent + Handoff | 极简主义 | 快速原型、OpenAI 生态 |
| Google ADK | 模块化 Agent 组合 | 企业级全栈 | Google Cloud 用户、企业集成 |
| CrewAI | 角色化协作 | 多 Agent 协作 | 任务分配型多 Agent 场景 |
| AutoGen | 对话式协作 | 快速原型 | 多 Agent 对话验证 |
各框架架构哲学差异
LangGraph — 给工程师的"状态机"：
- 核心是显式定义的有向图，节点是 LLM/工具调用，边是状态转移
- 支持循环图（Agent 的"思考→执行→再思考"循环天然适配）
- 持久化状态（Checkpointing）支持断点续跑和时间旅行调试
- 配合 LangSmith 提供目前最完整的 Agent 可观测性链路
- 代价：图定义有一定心智负担，强绑定 LangChain 生态
OpenAI Agents SDK — 极简主义：
- 几十行代码跑起一个有工具调用能力的 Agent
- Handoff 机制优雅处理多 Agent 任务路由（LLM 自动判断移交）
- 与 OpenAI 生态（Assistants API、Code Interpreter）无缝集成
- MCP 原生支持，工具生态统一化
- 代价：状态控制能力基础，可观测性相对薄弱
Google ADK — 企业级全栈：
- 预置 Agent 类型：SequentialAgent、ParallelAgent、LoopAgent
- 原生集成 BigQuery、Vertex AI RAG、GitHub、Jira 等企业系统
- 多 Agent 架构是一等公民设计（非后期补丁）
- 代价：Google Cloud 绑定较深，学习曲线中等偏高
框架选型决策树
2026 趋势：MCP 正在成为工具接入的统一标准，三个主流框架均已跟进。框架差异化将更多体现在状态管理、调试体验和部署能力上，而非工具接入。详见 Tool Use工具调用设计。
可观测性与调试
为什么 Agent 需要不同的可观测性
传统 APM 关注：调用链（trace）、指标（metrics）、日志（logs）。
Agent 系统还需要：
- LLM 调用链：每一步的 Prompt、Completion、Token 消耗、延迟
- 决策追踪：Agent 为什么选择 A 而不是 B？推理过程可追溯
- 工具调用审计：调用了什么工具、传入什么参数、返回什么结果
- 成本追踪：每次任务消耗多少 Token、花费多少
- 状态快照：任意时刻 Agent 的完整状态（用于调试和回放）
可观测性工具
| 工具 | 定位 | 核心能力 |
|---|---|---|
| LangSmith | LangGraph 配套 | 最完整的 Agent 调试链路，每步输入输出/Token/延迟/错误 |
| Langfuse | 开源可观测 | LLM 调用追踪、Prompt 版本管理、成本分析 |
| Phoenix | Arize 出品 | 开源 LLM 可观测，支持 trace + evaluation |
| Weights & Biases | ML 平台 | 实验追踪 + 模型评估 + 部署监控 |
核心原则：可观测性从第一天开始就要搭好，而不是出了问题再补。生产环境的 Agent 没有可观测性基本等于盲飞。
生产级 Agent 的架构清单
| 维度 | 关键问题 | 关联笔记 |
|---|---|---|
| 状态管理 | 如何持久化、如何恢复、如何回放？ | Agent状态管理 |
| 任务调度 | 如何分解、如何并发、如何重试？ | Agent任务队列 |
| 安全控制 | 权限分级、沙箱、人工审批？ | Agent权限与安全 |
| 效果评估 | 如何衡量 Agent 质量？ | Agent评估 |
| 多 Agent 协作 | 何时拆分、如何通信、如何协调？ | 多Agent协作 |
| 规划执行 | 如何分解任务、如何重规划？ | Planner与Executor |
| 失败处理 | 常见失败模式与应对？ | Agent失败模式 |
| 工作流设计 | 顺序/条件/循环/并行？ | Agent工作流 |
常见误区
- 过度设计：简单任务不需要多 Agent 和复杂图结构，LLM 直接调用即可
- 忽视可观测性：Agent 行为非确定性，没有调试链路出问题就是黑箱
- 框架锁定：选框架时不想清楚迁移成本，三年后想换框架代价巨大
- 状态管理缺失：没有显式状态管理，任务中断后无法恢复
- 工具数量失控：一个 Agent 挂载太多工具，Prompt 膨胀导致 LLM 选择困难
可继续补充的方向
- Agent 架构的性能优化（延迟/成本/吞吐量）
- Serverless Agent 部署模式
- Agent 的版本管理和 A/B 测试
- Agent 架构的容错模式（Circuit Breaker / Bulkhead / Timeout）
关联笔记
- AI 与 Agent — Agent 概念入口与五要素框架
- Agent工作流 — 工作流设计模式（顺序/条件/循环/并行）
- Agent状态管理 — 状态持久化与检查点机制
- 多Agent协作 — 多 Agent 系统的协作模式
- Agent评估 — Agent 效果评估框架
- Agent权限与安全 — 安全与权限控制
- Agent面试知识体系 — Agent 工程面试知识