Agent 工程体系全景 / Agent Engineering System Overview
📅 创建时间：2026-07-28 🏷️ 标签：#Agent #Overview #SystemArchitecture #LearningPath 📚 前置知识：[[/04-ai/01-llm-engineering/00-llm-overview]]
📋 本章目标
- 理解 Agent 在 LLM 应用体系中的定位——它不是新技术，是一种系统架构模式
- 建立 Agent 工程的完整心智地图：从 API 调用到多 Agent 编排
- 理解每个子领域解决什么问题、数据如何在各组件之间流动
- 能够按照清晰的学习路径从零开始构建 Agent 系统
第0部分：Agent 到底是什么——从你已经知道的东西出发
0.1 你已经在用 LLM API 了，Agent 只是多了一步
如果你已经调用过 LLM API（ChatGPT API / Claude API），那 Agent 并没有引入任何你完全陌生的东西。
普通 LLM 调用（你已经会了）：
POST /v1/chat/completions
{messages: [{role: "user", content: "1+1等于几？"}]}
→ 返回 {content: "等于2"}
Agent = 普通 LLM 调用 + 工具调用 + 循环
POST /v1/chat/completions
{messages: [...], tools: [{name: "get_weather", ...}]}
→ 返回 {tool_calls: [{name: "get_weather", args: {...}}]}
→ 你的程序执行 get_weather()
→ POST /v1/chat/completions （把工具结果传回去）
{messages: [..., {role: "tool", content: "{temp: 25}"}]}
→ 返回 {content: "北京今天25°C"}Agent 不是一个新的 API 或新的模型。它是你在 LLM API 外面写的一个 while 循环。 这个循环负责：检测 LLM 是否想调工具 → 执行工具 → 把结果传回 → 循环直到 LLM 给出最终回答。
0.2 整个 Agent 工程体系就是在解决这个循环中的各种问题
┌─────────────────────────────────────────────────────────────┐
│ Agent 循环中的每一步对应一个子领域 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户问题 │
│ ↓ │
│ ┌──────────────────┐ ← Memory：把什么放进 messages？ │
│ │ 构造 messages │ 对话历史？长时记忆？RAG 检索结果？ │
│ └────────┬─────────┘ │
│ ↓ │
│ ┌──────────────────┐ ← Tools：注册哪些工具？怎么描述？ │
│ │ POST API │ MCP：标准化的工具接入协议 │
│ │ (messages+tools) │ │
│ └────────┬─────────┘ │
│ ↓ │
│ ┌──────────────────┐ ← Structured Output：强制 JSON Schema │
│ │ 解析 LLM 响应 │ 让输出可预测、可解析 │
│ └────────┬─────────┘ │
│ ↓ │
│ tool_calls? │
│ ↓ ↓ │
│ 是 否 → 最终回答 │
│ ↓ │
│ ┌──────────────────┐ ← Workflow：ReAct / Plan-Execute │
│ │ 执行工具 │ 单步还是循环？要不要先做计划？ │
│ │ 返回结果给 LLM │ │
│ └────────┬─────────┘ │
│ ↓ │
│ 回到"构造 messages"（循环） │
│ │
│ 横向关注点： │
│ ┌──────────────────┐ ← 评估：怎么知道 Agent 做得好不好？ │
│ │ 可观测性 & 评估 │ 日志、trace、eval benchmarks │
│ └──────────────────┘ │
│ ┌──────────────────┐ ← 安全：沙箱、权限、注入防护 │
│ │ 安全边界 │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘0.3 本模块文章导航
按学习顺序排列。每一篇的核心问题：
| 序号 | 文章 | 核心回答的问题 |
|---|---|---|
| 01 | Function Calling | LLM 怎么"调用函数"？tool 怎么注册？循环是什么？ |
| 02 | 框架演进 | 为什么需要 LangChain/LangGraph？它们封装了什么？ |
| 03 | RAG 基础 | 文本怎么变成向量？Embedding 模型是什么？ |
| 04 | 记忆管理 | Agent 的"记忆"到底存在哪里？短时 vs 长时 |
| 05 | Agent 工作流 | ReAct 每一步在做什么？Plan-Execute 是什么？ |
| 06 | 多 Agent | 多个 Agent 怎么"通信"？编排程序做什么？ |
| 07 | RAG 进阶 | 混合检索、重排序、Query 改写 |
| 08 | 真实应用 | Code Agent / 客服 / 数据分析 的架构模式 |
| 09 | 结构化输出 | 怎么让 LLM 输出可靠的 JSON？ |
| 10-13 | Agent 架构与执行 | 工具、架构模式、模式切换与工作流编排 |
| 14 | Context Engineering | 进入模型的上下文怎样选择、压缩和组织？ |
| 14a | Agent 缓存工程 | KV Cache、Prompt Cache 与缓存命中到底是什么？ |
| 15 | Harness / Loop / Skills | 怎样在模型外验证、约束并持续执行？ |
| 16-17 | 协议与评估 | MCP 如何连接工具？Agent 怎样系统评估？ |
| 18-23 | 生产级治理 | 沙箱、权限、密钥、注入防护、可观测性与路由 |
| 24-27 | 设计案例 | OpenClaw、Claude Code、LobeChat 与 Coding Agents 对比 |
| 28 | 领域 Agent 的确定性工具执行 | 高副作用领域怎样把 LLM 意图编译为可确认、可验证的单次执行？ |
0.4 学习路径
┌─────────────────────────────────────────────────────────────┐
│ 推荐学习路径 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 第一步：先跑通（理解数据流） │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 00 → 01 (FC) → 亲手写一个 while 循环调 API │ │
│ │ 理解：每次 POST 的 messages 里到底有什么 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 第二步：加能力 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 03 (RAG) → 04 (Memory) → 05 (Workflow) → 06 (Multi)│ │
│ │ 理解：Embedding 是另一个 API，记忆是外部数据库 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 第三步：工程化 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 02 (Frameworks) → 09 (Structured) → 10 (Tools) │ │
│ │ → 11 (Architecture) → 13 (Orchestration) │ │
│ │ 理解：框架、输出、工具和工作流怎样组成系统 │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 第四步：生产级 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 14 (Context) → 14a (Caching) → 15 (Harness) │ │
│ │ → 16 (MCP) → 17 (Eval) → 安全治理 → 案例分析 │ │
│ │ 理解：上下文、成本、验证、安全与可观测性 │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘第1部分：Agent 不是什么——澄清常见误解
1.1 Agent ≠ 智能
Agent 不会"理解"你的意图。它的每一个决策——调用哪个工具、传什么参数、何时停止——都是基于统计模式匹配（预测下一个 token）。让它看起来"智能"的是：
- 好的工具设计（给它正确的、有限的选择）
- 好的 prompt 设计（给它清晰的上下文和约束）
- 好的循环控制（设置最大迭代次数、超时、错误处理）
1.2 Agent ≠ 独立进程
如前所述，Agent 不是一个独立运行的服务。它是你的程序在 LLM API 外面包的一层控制流。CrewAI 的 "Agent"、LangGraph 的 "Node"——这些只是代码中的抽象，最终都编译为 POST /v1/chat/completions。
1.3 Agent ≠ 替代传统软件
Agent 适合的任务：需要推理、需要灵活应对不确定输入、需要编排多个工具完成任务。 Agent 不适合的任务：确定性计算、需要 100% 可靠性的操作、实时系统。
第2部分：核心概念速查
┌─────────────────────────────────────────────────────────────┐
│ Agent 工程的核心概念与数据流 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Token LLM 处理的最小单位（~0.75 个英文单词） │
│ Context 每次 API 调用时 messages 数组的总 token 数 │
│ Tool 一段 JSON Schema 描述的函数，LLM 可以"请求"调用│
│ Tool Call LLM 输出的结构化 JSON，表示"我想调这个函数" │
│ Agent Loop while finish_reason != "stop": 执行+返回 │
│ Embedding 文本→向量的 API，用于语义搜索 │
│ Vector DB 存向量+文本的数据库，支持 ANN 搜索 │
│ RAG 检索增强生成：先搜相关知识，再让 LLM 回答 │
│ Memory 在 LLM 外部维护的信息，每次请求前拼入 prompt │
│ Workflow 对 Agent Loop 的结构化约束（ReAct/Plan等） │
│ Multi-Agent 编排程序依次或并行调用多个 LLM API │
│ MCP Agent 与工具之间的标准通信协议 │
│ Structured 强制 LLM 输出符合 JSON Schema 的文本 │
│ │
└─────────────────────────────────────────────────────────────┘核心总结
Agent 的本质：一个 while 循环，反复 POST messages 到 LLM API，直到
finish_reason == "stop"。工具调用、记忆、工作流都是在这个循环上叠加的机制。一切最终都是 HTTP 请求：Function Calling、Embedding、RAG 检索——底层都是 HTTP POST。理解每个环节的请求体和响应体格式，是消除"魔法感"的关键。
"Agent A" 不是一个进程：多 Agent 系统中，"Agent"只是一个 system prompt + 一组 tools + 一次 LLM API 调用。Agent 之间不互相通信——编排程序在它们之间传递字符串。
框架封装了模式，不是创造了新能力：LangChain/LangGraph/CrewAI 没有发明新的 LLM 能力——它们只是把 Agent Loop、状态管理、多 Agent 编排等模式封装成了 API。不学框架只用 SDK 也能实现所有功能。
相关笔记
- [[01-function-calling]] — Function Calling 完整数据流
- [[05-agent-workflow]] — Agent 工作流范式
- [[06-multi-agent]] — 多 Agent 系统
- [[/04-ai/01-llm-engineering/00-llm-overview]] — LLM 原理基础
下一步学习
- [ ] 阅读 01 - Function Calling — 理解 Agent 的最基本单元
- [ ] 用原生 SDK（不用任何框架）写一个带工具调用的 while 循环
- [ ] 亲手打印每次 API 调用的 request body 和 response，确保理解数据流
学习状态：🟡 开始学习