7 层架构:AI Agent 的工程骨架#
AI Agent 的技术选型不应从"选框架"开始,而应从理解系统分层开始。
flowchart TB
subgraph L7["Application Layer"]
A7["Coding Agent / Research Agent
Workflow Agent / Personal Assistant"]
end
subgraph L6["Observability Layer"]
A6["Traces / Logs / Evals
Cost / Latency / Quality"]
end
subgraph L5["Memory Layer"]
A5["Episodic / Semantic / Graph Memory
Long-term User Memory"]
end
subgraph L4["Orchestration Layer"]
A4["Loops / Planners / Subagents
Async Jobs / Cron Triggers"]
end
subgraph L3["Execution Layer"]
A3["Tool Calling / Browser / Shell
Code Runtime / Sandbox"]
end
subgraph L2["Context Layer"]
A2["System Prompt / Session State
Working Memory / Retrieval / Compaction"]
end
subgraph L1["Model Layer"]
A1["Claude / GPT / Gemini / GLM
Local Models via Ollama"]
end
L7 --> L6 --> L5 --> L4 --> L3 --> L2 --> L1
style L1 fill:#3b82f6,color:#fff
style L2 fill:#6366f1,color:#fff
style L3 fill:#8b5cf6,color:#fff
style L4 fill:#a855f7,color:#fff
style L5 fill:#d946ef,color:#fff
style L6 fill:#ec4899,color:#fff
style L7 fill:#f43f5e,color:#fff
每一层解决的问题不同,不能用一个框架覆盖全部:
| 层 | 核心问题 | 典型工具/框架 |
|---|---|---|
| Model | 选哪个模型、成本控制、fallback | OpenAI / Anthropic / 本地 Ollama |
| Context | 上下文管理、压缩、检索 | RAG / Working Memory / Compaction |
| Execution | 工具调用、沙箱隔离 | MCP / Tool Calling / Browser Use |
| Orchestration | 工作流编排、多代理协作 | LangGraph / CrewAI / 自研 |
| Memory | 长期记忆、知识图谱 | Mem0 / Nowledge Mem / Graph Memory |
| Observability | 追踪、评估、成本监控 | Langfuse / LangSmith / Arize |
| Application | 具体业务场景 | Coding Agent / 客服 / 研究 |
框架选型:没有银弹#
主流框架对比#
| 框架 | 定位 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| LangGraph | 复杂状态工作流 | 控制力强、状态清晰、适合生产 | 抽象较重、学习成本高 | 复杂状态工作流 |
| CrewAI | 角色分工 SOP | 上手快、概念直观 | 复杂状态和底层控制弱 | SOP 式多角色流程 |
| AutoGen | 多代理协作 | 研究味浓、协作模式丰富 | 生产稳定性一般 | 实验性协作研究 |
| MS Agent Framework | 企业集成 | 企业能力强、集成完整 | 平台绑定较强 | 微软栈企业集成 |
| Letta (MemGPT) | Memory-first | 长期记忆与状态持久化强 | 心智负担较高 | 长期对话代理 |
| DSPy | Prompt 编译优化 | 优化范式独特 | 不适合通用 runtime | Prompt 工程研究 |
选型决策树#
flowchart TD
START["你的需求是什么?"] --> Q1{"需要复杂
状态管理?"}
Q1 -->|是| LG["LangGraph"]
Q1 -->|否| Q2{"需要多角色
SOP 协作?"}
Q2 -->|是| CA["CrewAI"]
Q2 -->|否| Q3{"微软技术栈?"}
Q3 -->|是| MS["MS Agent Framework"]
Q3 -->|否| Q4{"核心是
长期记忆?"}
Q4 -->|是| LT["Letta / Mem0"]
Q4 -->|否| Q5{"需求独特
控制力要求高?"}
Q5 -->|是| DIY["自研 SDK"]
Q5 -->|否| LG2["LangGraph
(默认推荐)"]
style LG fill:#10b981,color:#fff
style DIY fill:#f59e0b,color:#fff
style LG2 fill:#10b981,color:#fff
多智能体协作:代码检查系统实战#
以"多智能体代码检查系统"为例,展示 Agent 协作的工程实现。
架构设计#
flowchart LR
subgraph Input["输入"]
MR["GitLab MR Diff"]
end
subgraph Planning["规划层"]
PA["规划智能体
(协调分发)"]
end
subgraph Specialists["专项检查"]
SA["安全检查
Agent"]
QA["功能质量
Agent"]
PF["性能优化
Agent"]
MT["可维护性
Agent"]
end
subgraph Output["输出层"]
SUM["汇总智能体
(整合报告)"]
end
MR --> PA
PA --> SA & QA & PF & MT
SA & QA & PF & MT --> SUM
style PA fill:#8b5cf6,color:#fff
style SUM fill:#10b981,color:#fff
各 Agent 职责#
| Agent | 检测范围 | 输出标准 |
|---|---|---|
| 安全检查 | 代码注入、认证授权、敏感数据暴露、输入验证 | confidence > 0.7 且 severity 中/高 |
| 功能质量 | 逻辑错误、边界条件、错误处理、空指针引用 | 标准 Markdown 格式 |
| 性能优化 | 算法复杂度、资源泄漏、重复计算、SQL 优化 | 附带修改建议 |
| 可维护性 | 代码重复、命名规范、函数复杂度、文档完整性 | 避免低价值风格建议 |
评审流程#
第一步:推理分析(理解变更意图和上下文)
↓
第二步:决策与评分(接受/拒绝 + 0-100 分)
↓
第三步:精准反馈(仅高置信度 + 中高严重度的问题)
记忆系统:Agent 的"大脑"#
记忆是 Agent 从"工具"进化为"助手"的关键。
三层记忆架构#
flowchart TB
subgraph WM["Working Memory(工作记忆)"]
direction LR
WM1["当前会话上下文"]
WM2["临时状态"]
WM3["任务进度"]
end
subgraph EM["Episodic Memory(情景记忆)"]
direction LR
EM1["历史对话"]
EM2["操作日志"]
EM3["踩坑记录"]
end
subgraph SM["Semantic Memory(语义记忆)"]
direction LR
SM1["知识图谱"]
SM2["用户偏好"]
SM3["决策模式"]
end
WM -->|"重要信息沉淀"| EM
EM -->|"归纳抽象"| SM
SM -->|"检索召回"| WM
style WM fill:#3b82f6,color:#fff
style EM fill:#8b5cf6,color:#fff
style SM fill:#10b981,color:#fff
记忆技术选型#
| 方案 | 定位 | 特点 |
|---|---|---|
| Mem0 | 生产可用 | 集成快,适合个性化长期记忆 |
| Nowledge Mem | 知识图谱 | 支持 Working Memory、自动整理、跨工具同步 |
| Zep | 对话记忆 | 偏服务化,适合对话场景 |
| Graph Memory | 关系推理 | 正在成为热点,适合复杂关联 |
自我改进闭环#
Agent 执行任务
↓ (失败/被纠正/发现更好方法)
自动记录到 Episodic Memory
↓ (定期归纳)
抽象为 Semantic Memory(最佳实践/避坑指南)
↓ (下次执行)
自动加载相关记忆到 Working Memory
↓
避免重复犯错
企业级 AI 工具链#
2026 年的 AI 工具链已形成完整生态:
分层工具矩阵#
| 层次 | 工具 | 用途 |
|---|---|---|
| Chat | DeepSeek(代码审查优先)、ChatGPT(通用) | 日常对话和分析 |
| Agent 平台 | Manus.im、Coze(零代码/低代码) | 构建业务 Agent |
| IDE | Cursor、GitHub Copilot、Claude Code | 编码辅助 |
| 知识库 | Dify、NotebookLM、Ollama + Open WebUI | 知识检索和管理 |
| MCP | MCP Community、魔搭社区 | 工具协议和集成 |
| 自动化 | N8N + 本地 AI 模型 | 工作流自动化 |
| 浏览器 | Browser Use | 网页操作自动化 |
| 可观测性 | Langfuse(开源)、LangSmith(LangChain 生态) | 追踪和评估 |
MCP:连接一切的协议#
MCP (Model Context Protocol) 正在成为 AI Agent 的"USB 接口":
Agent ←→ MCP Protocol ←→ Tool Server
├── GitLab MCP(代码托管)
├── Nowledge Mem MCP(知识图谱)
├── Browser Use MCP(浏览器)
├── Alist MCP(文件管理)
└── 自定义 MCP Server
MCP 的价值在于标准化了 Agent 与工具的交互协议,避免每个 Agent 框架各自实现一套工具调用。
自研 SDK 的决策逻辑#
在评估完所有框架后,为什么有些团队选择自研?
自研的原因#
- 现有框架要么过于极简,要么过于抽象复杂 – LangGraph 功能强大但学习成本高,CrewAI 简单但不够灵活
- “Harness Engineering"概念的局限 – 只做 prompt + context + experience + skills + sandbox 的编排是不够的
- 业务场景的特殊性 – 企业内部的审批流、合规要求、数据隔离需求无法用通用框架满足
自研的最小可行集#
自研 SDK 最小集 =
Model Router(多模型路由 + fallback)
+ Context Manager(上下文压缩 + 检索)
+ Tool Registry(工具注册 + 沙箱)
+ Memory Store(短期 + 长期记忆)
+ Eval Loop(自动评估 + 成本监控)
实战案例:OpenClaw AI Agent 平台#
以上架构和选型讨论并非纸上谈兵。OpenClaw 是一个在生产环境运行的 AI Agent 平台,它的设计完整体现了 7 层架构的工程实践。
整体架构#
flowchart TB
subgraph Models["Model Layer"]
Claude["Claude Sonnet 4.6"]
GPT["GPT-5.3 Codex"]
GLM["GLM-5"]
DS["DeepSeek"]
end
subgraph Router["Model Router"]
MR["智能路由
(按任务类型分发)"]
end
subgraph Skills["Skills Layer (90+)"]
BG["blog-post-generator"]
CA["coding-agent"]
SR["security-review"]
DT["..."]
end
subgraph MCP["MCP Integration"]
GL["GitLab MCP"]
NM["Nowledge Mem MCP"]
TB["Teambition MCP"]
end
subgraph Cron["Cron Scheduler"]
HB["HEARTBEAT
(系统健康检查)"]
DB["Daily Blog
(每日博客生成)"]
BK["Daily Backup
(配置备份)"]
end
Models --> MR
MR --> Skills
Skills --> MCP
MR --> Cron
style MR fill:#8b5cf6,color:#fff
style Skills fill:#10b981,color:#fff
style MCP fill:#3b82f6,color:#fff
style Cron fill:#f59e0b,color:#fff
Skills 系统:90+ 可组合能力#
OpenClaw 的 Skills 不是固定功能,而是可热插拔的能力模块:
| Skill 类型 | 示例 | 触发方式 |
|---|---|---|
| 编码辅助 | coding-agent, tdd-workflow, security-review | 用户请求或 MCP 事件 |
| 内容生成 | blog-post-generator, daily-blog-generator | Cron 定时或手动触发 |
| 运维自动化 | gitlab-ci-patterns, k8s-manifest-generator | 用户请求 |
| 知识管理 | nowledge-mem, self-improving-agent | 自动或手动 |
Skills 配置管理通过 Nacos 3.2 实现企业级注册与发现,支持版本控制和灰度发布。
Cron 调度:Agent 的"生物钟”#
OpenClaw 的 Cron 调度器让 Agent 具备自主行为能力:
# HEARTBEAT — 系统健康检查
# 23:00-08:00 静默模式:仅状态检查,不重复提醒
# 08:00-23:00 主动模式:发现异常立即通知
# Daily Blog — 每日博客自动生成
# 23:00 触发,自动选题、生成、脱敏、提交
# Daily Backup — 配置自动备份
# 每天 21:39 自动执行,保留 7 天
agentTurn 类型任务必须在 payload 中显式指定 model 字段,否则会被重置为 null 导致任务失败。这个问题首次发现于 2026-03-11,排查了多轮才定位到根因。记忆系统实战#
OpenClaw 的记忆体系是本文"三层记忆架构"的真实实现:
- Working Memory:每次会话自动注入,包含当前焦点领域、未解决问题、近期上下文
- Nowledge Mem:外部知识图谱,通过 MCP 协议集成,支持跨工具同步(Claude Code / Cursor / OpenClaw 共享同一份知识)
- Self-Improving Agent:自动捕获错误和纠正,持续累积到 ERRORS.md / LEARNINGS.md
用户纠正 Agent → 自动记录到 LEARNINGS.md
↓
定期归纳 → 写入 Nowledge Mem 语义记忆
↓
下次会话 → Working Memory 自动加载相关记忆
↓
不再犯同类错误
博客自动化发布#
OpenClaw 已演化出完整的博客自动发布体系:
- blog-post-generator — 根据指定主题生成技术文章
- daily-blog-generator — 每日 23:00 自动选题生成
- 脱敏机制 — 自动过滤内部 IP、密钥等敏感信息
- 去重检查 — 避免重复生成已有主题的文章
- 人工边界 — 不确定的操作先询问用户再执行
这套体系的核心设计原则:Agent 可以自动生成内容,但发布决策权始终在人手中。
实践中的关键教训#
1. 成本比你想象的重要#
多智能体协作意味着 N 倍的 API 调用。一个 4-Agent 的代码审查系统,单次审查的 token 消耗是单 Agent 的 3-5 倍。技术选型时,DeepSeek 的成本优势(0.001 元/千 token vs GPT-4 的 0.03 元/千 token)在规模化后非常显著。
2. 可观测性不是可选项#
Agent 出错时,如果没有 trace 和 eval,你根本不知道是 prompt 的问题、context 的问题还是 tool 的问题。Langfuse/LangSmith 是生产环境的必备。
3. 记忆系统需要"遗忘"#
无限累积的记忆会污染上下文。Working Memory 需要每日清理,Episodic Memory 需要过期机制,Semantic Memory 需要定期校准。
4. 安全边界必须明确#
Agent 能执行 shell 命令、访问文件系统、调用 API – 如果不做沙箱隔离,一个 hallucination 就可能 rm -rf /。Execution Layer 的安全设计比功能设计更重要。
写在最后#
2026 年 AI Agent 的技术成熟度已经从"能不能做"进入了"怎么做好"的阶段。关键不在于选哪个框架或哪个模型,而在于:
- 系统性工程思维 – 7 层架构每层都要有方案
- 成本意识 – 多 Agent 协作的成本控制
- 记忆系统 – 从工具到助手的关键跃迁
- 可观测性 – 生产环境的必备基础设施
- 安全边界 – 给 Agent 的能力加上围栏
技术选型的最终答案不是"用 X 框架",而是理解你的问题属于哪类,然后在每一层选择最合适的工具,把它们组装成一个可靠的系统。
查看 Claude Code + pr-agent 实践