1. 为什么 AI Agent 正在成为一个独立学科

如果说 2022 年 11 月 ChatGPT（基于 GPT-3.5）的发布，第一次让「大语言模型」从论文走向大众；那么此后短短几年，整个行业发生了核爆式的演进：从底层的 Transformer 架构，到语言模型本身，再到 Prompt、检索增强、工具调用、多智能体协作、评测监控、部署推理——一层又一层的「上层建筑」被迅速搭建起来。今天，围绕大模型的上下游已经不再是「一个模型 + 一个聊天框」这么简单，而是一个拥有完整分工、完整方法论、完整工具链的庞大体系，业界越来越多地把它统称为 AI Agent（智能体）技术栈。

在 2023 年之前，大家讨论的还是「提示词怎么写」「模型能做哪些题」。从 2023 到 2025，讨论的重心迅速转向：如何让模型完成一件真实的、多步骤的、需要调用外部工具的复杂任务。这正是 Agent 的核心命题。一个 Agent 不再只是「回答问题」，而是要完成「目标设定 → 规划分解 → 调用工具 → 观察结果 → 自我修正 → 最终交付」的完整闭环。

为什么说它值得作为一门独立学科来学？原因有三。

第一，知识体系已经足够庞大且分层清晰。底层是模型训练与推理，中间是能力模块（Prompt、RAG、工具、记忆、规划），上层是框架与应用，周边是评测、监控、安全与部署。每一层都有独立的理论与工程实践，任何一层都足以支撑起专门的研究方向或职业岗位。

第二，工具与标准正在快速固化。LangChain、LlamaIndex、AutoGen、CrewAI 等框架已成为事实标准；OpenAI 的 Function Calling、MCP（Model Context Protocol）、A2A（Agent-to-Agent）协议正在把「Agent 之间如何通信」「Agent 如何调用工具」变成可互操作的行业规范。这意味着它不再是一堆散点，而是一个可以被系统地学习、标准化地教学的领域。

第三，就业与产品形态已经成熟。编程方向的 Cursor、Windsurf、Devin、OpenHands；研究方向的 GPT Researcher、Deep Research；客服、销售、营销、金融、医疗等垂直场景的 Agent 产品大量涌现。会搭建、会优化、会评测 Agent 的人才，已经成为一个明确且稀缺的职业方向。

对普通观众而言，本文想实现的目标是：给你一张完整的「大模型上层建筑地图」。读完本文，你会清楚地知道：现在这个领域里到底有哪些东西、它们分别解决什么问题、彼此之间是什么关系、每个方向该从哪儿入手。全文会从一个最小闭环讲起，逐步向外扩展到整个生态。

2. 先建立一张全局地图

在展开每一层之前，先把整张图印在脑子里。我们可以把大模型上层建筑分成以下几大板块：

• 模型侧：闭源/开源基座模型，以及让模型跑得快、跑得省的推理、训练、微调基础设施。
• 能力侧（Agent 核心模块）：Prompt、工具调用、结构化输出、RAG、记忆、规划、多模态，这些是把「模型」升级为「智能体」的关键零件。
• 框架侧：LangChain、LlamaIndex、AutoGen、CrewAI、Semantic Kernel 等，负责把这些零件组装成可运行的应用。
• 数据与知识侧：Embedding 模型、向量数据库、文档解析、知识图谱，解决「模型的知识从哪儿来、怎么被检索」。
• 协议与标准侧：MCP、A2A 等，解决「工具怎么接、Agent 怎么对话」。
• 评测与安全侧：Agent 评测、RAG 评测、可观测性、护栏与内容安全，解决「怎么知道它做得好不好、做得安不安全」。
• 应用与产品侧：编程、研究、客服、营销、办公等落地场景。

一个典型的 Agent 工作流可以这样描述：用户下达任务 → Agent 用大模型做规划 → 根据记忆与上下文决定下一步 → 通过工具调用去查数据库、搜网页、执行代码 → 把工具返回的结果放进上下文继续推理 → 反复循环直到任务完成 → 通过评测检验结果质量。下面这张流程图概括了整个过程：

后续每一节，我们都在这张图里填充细节。

3. 地基概念：Token、上下文与推理

在讲上层建筑之前，有几个基础名词必须先吃透，否则后面所有框架文档都像天书。

3.1 Token 与分词

大模型不直接认识汉字或英文单词，它处理的基本单位叫 Token。粗略地说，一个英文单词约为 1～1.5 个 Token，一个中文字词约为 1～2 个 Token。比如「人工智能」可能被切分成 2 个 Token。Token 之所以重要，是因为：

• 计费按 Token 算：无论 OpenAI、Claude 还是国内各家，API 价格都以每千 Token 计。
• 上下文窗口按 Token 算：模型一次能「看到」的内容上限由 Token 数决定。
• 速度与成本：输入输出 Token 越多，延迟越高、花费越大。

3.2 上下文窗口

上下文窗口（Context Window） 指模型在一次请求中能处理的最大 Token 总数，包括系统提示词、历史对话、工具返回结果、用户输入和模型输出。早期 GPT-3.5 是 4K～8K，如今主流模型动辄 32K、128K，甚至有百万级 Token 的长上下文模型（如 Gemini、Claude 的部分版本，以及国产 Kimi、MiniMax 等）。

上下文窗口直接决定了 Agent 能「记住」多少东西。一个多步 Agent 任务里，每一轮的工具调用结果都会被塞回上下文，如果上下文耗尽，模型就会「忘记」更早的信息。因此出现了各种上下文压缩、摘要、分层记忆技术来对抗遗忘。

3.3 温度与采样

temperature 是调用模型时最常见的超参数之一，控制输出的随机性。温度越低，输出越确定、越适合需要稳定格式的任务（如 JSON 抽取、代码生成）；温度越高，输出越多样、越适合创意写作。top_p（核采样）是另一种控制多样性的方式。理解这两者，能帮你在不同场景下正确配置 Agent。

3.4 推理与思考

从 OpenAI 的 o1、o3 到 DeepSeek-R1、国产的推理模型，业界出现了一类「会思考再回答」的模型。它们不再直接吐答案，而是先在内部生成一串「思维链」（Chain-of-Thought），经过自我检查后再给出结论。这类模型在数学、代码、复杂逻辑任务上表现显著提升，但代价是延迟更长、Token 消耗更大。对 Agent 而言，推理模型常被用在规划与决策环节，而快速执行的环节则用普通模型以节省成本。

小结：Token 决定了成本与容量，上下文窗口决定了记忆边界，温度决定了稳定性，推理能力决定了复杂任务上限。这四个词，是读懂一切 Agent 资料的前提。

4. Agent 核心范式：从 ReAct 到多智能体

这一节是整个学科最「理论」也最「实用」的部分，因为几乎所有 Agent 框架，本质上都是下面几种范式的实现或组合。

4.1 ReAct：推理与行动交替

ReAct（Reasoning + Acting） 是 Agent 领域最有影响力的范式，出自 2022 年的一篇论文。核心思想是：让模型交替生成「思考」（Thought）和「行动」（Action），并通过「观察」（Observation）获得工具反馈，循环往复直到得出答案。

一个用 ReAct 风格解决「杭州今天天气如何，适合跑步吗」的流程大致是：

Thought: 我需要查询杭州今天的天气。
Action: 调用 weather_api(city="杭州")
Observation: 多云，19-25 摄氏度，空气质量良
Thought: 温度适宜、空气质量良，适合户外跑步。
Answer: 今天杭州多云，19-25 度，适合跑步。

ReAct 的最大价值在于：它把「模型推理」和「外部世界交互」绑定在一起，让模型能够根据观察结果动态调整下一步，而不是一次性地输出全部计划。LangChain 的 AgentExecutor、以及更现代的 LangGraph，本质上都在实现这个循环。

4.2 Plan-and-Execute：先计划后执行

ReAct 是「走一步看一步」，而 Plan-and-Execute 是「先把全盘计划列出来，再逐步执行」。它通常包含两个角色：

• Planner（规划器）：把复杂任务拆解成一系列子任务列表。
• Executor（执行器）：按列表顺序逐步执行每个子任务。

这种范式的优点是可预测、可审查，适合流程相对固定的任务（如「写一份市场调研报告」可以被拆成：检索行业数据 → 分析竞品 → 生成大纲 → 撰写正文 → 排版）。缺点是不够灵活，如果中途环境变化，计划可能失效。很多框架会结合两者：整体用 Plan-and-Execute，局部用 ReAct 微调。

4.3 Reflexion：自我反思与重试

Reflexion 的核心机制是「让模型评估自己的表现，并把失败经验写入记忆，用于下一轮重试」。它通常不依赖模型的权重更新（不强求微调），而是通过语言化的反馈实现自我改进。典型流程是：

1. Actor（行动者）生成一次尝试。
2. Evaluator（评估者）判断结果是否满足目标。
3. Self-Reflection（自我反思）总结哪里做错了、如何改进。
4. 将反思结果存入记忆，重新尝试。

这一范式在代码调试、单元测试通过率提升等场景效果显著。比如让 Agent 写一段代码，如果测试没通过，就把报错信息连同反思一起反馈给模型，让它重写。很多「自动修复代码」的 Agent 都隐含实现了 Reflexion。

4.4 Tree of Thoughts 与 Graph of Thoughts

思维链是「一条路走到底」，而 Tree of Thoughts（ToT） 是「同时探索多条思路，像下棋一样展开搜索树」。模型在每个节点生成多个候选想法，评估每个候选的潜力，对最有希望的路径继续展开，必要时回溯。Graph of Thoughts（GoT） 进一步把树扩展成图，允许不同分支之间合并、聚合信息。

这类范式在数学推理、创意设计、复杂规划问题中很有价值，但由于每一步都要做多次生成和评估，Token 成本和延迟都很高，目前更多见于研究场景和高价值任务，而非日常高频应用。

4.5 多智能体协作

当任务复杂到单一大模型难以独立完成时，就有了**多智能体（Multi-Agent）**架构：让多个不同角色的 Agent 相互协作、对话、监督。常见角色包括：

• 规划者：负责拆任务、分派工作。
• 执行者：负责具体干活，比如写代码、查资料。
• 审查者：负责质检，挑错、提修改意见。
• 用户代理：模拟用户视角提出问题。

多智能体的关键争议在于：协调开销与不稳定。多个模型来回对话会大幅增加 Token 消耗与延迟，而且可能出现「跑偏」或无限循环。因此当下工程界的趋势是：能用单智能体 + 好工具解决的，就不轻易上多智能体；只有任务天然需要角色分离（如「生产 + 质检」）时才引入。

范式小结：ReAct 是「边想边做」，Plan-and-Execute 是「先想后做」，Reflexion 是「做不好就想、想了再做」，ToT/GoT 是「多路探索」，多智能体是「分工协作」。理解了这五种范式，你就理解了市面上八成 Agent 框架的设计动机。

5. 基础能力模块：把模型变成智能体

范式是「骨架」，这一节讲的是「零件」。一个 Agent 要落地，离不开下面六大能力模块。

5.1 Prompt Engineering：最小成本的最大杠杆

提示词工程 是调用大模型最基础、性价比最高的技能。核心技巧包括：

• 角色设定：你是一位资深 Python 架构师，擅长代码审查。
• 清晰指令：把任务拆成明确步骤，避免歧义。
• 少样本（Few-shot）：给模型几个输入输出的范例，让它模仿格式与风格。
• 思维链（CoT）：要求模型「一步一步思考」，显著提升推理题正确率。
• 结构化输出约束：明确要求返回 JSON，并给出字段说明。
• 防止幻觉：要求模型「如果不知道就明确说不知道，不要编造」。

在 Agent 场景下，Prompt 不再是「一句话」，而是由多个部分组成：

1. System Prompt：定义角色、边界、工具使用规则。
2. 任务描述：当前目标与子任务。
3. 工具说明：可用工具的名称、参数、用途。
4. 输出格式：规定最终结果的结构。
5. Few-shot 示例：示范正确行为。

现代框架把这些 Prompt 做了封装，但底层逻辑完全一致。能写好 Prompt 的人，调 Agent 的效率和产出质量会高出数倍。

5.2 Function Calling / Tool Use：让模型「动手」

如果说 Prompt 让模型「会说话」，那么 函数调用（Function Calling） 就让模型「会做事」。其机制是：

1. 开发者声明一系列可用函数（名称、参数 schema、描述）。
2. 模型根据用户意图，决定是否调用某个函数，并生成符合 schema 的参数。
3. 由宿主程序（框架）真正执行该函数（查天气、搜网页、调 API、执行 SQL）。
4. 将执行结果返回给模型，模型继续推理。

例如，模型收到「帮我把北京飞上海的机票按价格排序」，会输出一个调用 search_flights(origin="北京", destination="上海", sort_by="price") 的指令，宿主程序执行后把航班列表还给模型，由模型整理成自然语言回答。

Function Calling 是 Agent 的「行动力」来源。它本身是模型能力（需要模型能理解工具说明并生成合法参数），而工具的执行则由框架与开发者负责。常用的工具封装协议之一就是后文要讲的 MCP。

5.3 结构化输出：让结果可被程序消费

在 Agent 流水线里，模型输出往往不是给人类看的，而是给下一个模块用的。结构化输出要求模型返回 JSON、XML 等机器可读格式，并且严格遵守 schema。具体手段包括：

• 在 Prompt 中要求 JSON 格式并给出示例。
• 使用支持 JSON Mode / Structured Output 的 API（如 OpenAI 的 response_format）。
• 使用框架的 OutputParser / Pydantic 校验，把自然语言或 JSON 解析成类型安全的对象。
• 解析失败时自动重试或修复。

结构化输出是 Agent 可靠性的基石。一个「自由发挥」的模型可以被人类容忍，但一个下游模块如果拿到格式错误的数据就会直接崩掉。

5.4 RAG：检索增强生成

大模型的知识截止于训练数据，而且容易产生幻觉。RAG（Retrieval-Augmented Generation，检索增强生成） 的思路是：先根据用户问题去外部知识库检索相关内容，再把检索到的内容拼进上下文，让模型「带着参考资料作答」。

RAG 的典型流水线：

RAG 的关键环节包括：文档解析与切分、Embedding 模型选择、向量库选型、检索策略（相似度、混合检索、重排序 Rerank）、上下文拼接策略。它是企业知识库问答、客服、合同审查等场景的核心技术。

5.5 Memory：让 Agent 记得住

一个没有记忆的 Agent，每一轮都像失忆症患者。记忆系统通常分为几类：

• 短期记忆：就是当前上下文窗口内的对话历史和工具结果。
• 长期记忆：把历史信息持久化到向量库、数据库或文件，供后续检索。
• 情景记忆：记住「某次任务中发生了什么」，用于复盘。
• 语义记忆：记住「事实性知识」，比如用户偏好、项目背景。
• 过程记忆：记住「怎么完成某类任务」的经验（类似 Reflexion 的反思存储）。

实现长期记忆的常见方式：把重要对话摘要后写入向量库，后续根据相似度或关键词检索；或者维护一个结构化的「用户画像」文档，持续更新。记忆系统决定了 Agent 能否在长期、多轮、跨会话的协作中保持一致性。

5.6 多模态：超越纯文本

早期的上层建筑几乎都围绕文本。如今，模型已经能处理图像、音频、视频，甚至直接操作屏幕。多模态对 Agent 的意义在于：

• 输入侧：Agent 可以「看」截图、扫描件、图表、设计稿，而不只是读文字。
• 输出侧：可以生成图、语音、视频、前端页面。
• 交互侧：结合计算机视觉与屏幕理解，Agent 可以像人一样操作 GUI（图形界面），即 Computer Use。

多模态让 Agent 的应用边界从「文字办公」扩展到设计、质检、医疗影像、视频剪辑等更广阔的领域。

6. 模型侧生态：基座、推理与训练

了解了 Agent 的零件之后，我们往下沉一层，看看支撑这些能力的模型基础设施。

6.1 闭源与开源模型格局

闭源商业模型的代表有 OpenAI（GPT 系列）、Anthropic（Claude 系列）、Google（Gemini 系列），以及国内的通义千问、文心一言、豆包、Kimi、MiniMax、智谱 GLM 等。闭源模型通常能力更强、服务更稳定、配套工具更完善，适合对质量要求高、能接受 API 费用和合规约束的场景。

开源模型的代表有 Llama（Meta）、Qwen（阿里）、DeepSeek、Mistral、Gemma（Google）、GLM（智谱）、InternLM（上海 AI 实验室）等。开源模型的最大价值是可私有化部署、可控、可微调，适合对数据安全敏感或有成本优化需求的企业。很多企业会走「开源模型 + 自建推理 + 领域微调」的路线。

对 Agent 开发者来说，选择模型的标准包括：推理能力、Function Calling 支持度、上下文长度、输出稳定性、价格与延迟、数据合规。没有「最好」的模型，只有最匹配场景的模型。

6.2 推理与服务框架

即使拿到了模型权重，要让它在生产环境中「跑得快、跑得省」，还依赖推理引擎。常见的有：

• vLLM：高性能 LLM 推理引擎，以 PagedAttention 技术著称，吞吐量极高，支持 OpenAI 兼容 API，是目前自建推理的事实标准之一。
• Ollama：面向本地开发者的极简单机推理工具，一条命令 ollama run llama3 就能跑模型，适合个人实验和边缘设备。
• SGLang：新兴的高性能推理框架，以 RadixAttention 加速结构化输出与复杂调度。
• TensorRT-LLM：NVIDIA 官方推理方案，深度优化 GPU 性能。
• llama.cpp / Ollama 后端：面向 CPU 与消费级 GPU 的量化推理，让模型能在笔记本上运行。
• LM Studio / LocalAI：提供图形化或类 OpenAI 接口的本地推理入口。

这些工具解决的是同一个问题：把模型推理的吞吐、延迟、显存占用优化到极致。对于 Agent 应用，推理引擎的延迟往往直接影响用户体验，因此选型非常重要。

6.3 微调与训练：让模型更懂你的领域

通用模型很强，但在垂直领域（法律、医疗、金融代码、公司内部规范）往往不够「懂行」。微调（Fine-tuning） 就是用小规模领域数据，让模型学会特定任务。关键技术包括：

• LoRA（低秩适配）：只训练很小一部分新增参数，大幅降低显存需求，是当前最主流的微调方式。
• QLoRA：在 LoRA 基础上叠加 4-bit 量化，让 70B 级模型也能在消费级 GPU 上微调。
• PEFT：Hugging Face 的参数高效微调库，统一封装 LoRA、Prefix Tuning 等技术。
• DeepSpeed / FSDP：分布式训练框架，用于多卡甚至多机训练大模型。
• TRL：Hugging Face 的 Transformer Reinforcement Learning 库，支持 SFT、DPO、PPO 等对齐训练。
• Axolotl / Unsloth：封装良好的微调工具，大幅降低上手门槛，尤其 Unsloth 以极快的 LoRA 训练速度闻名。
• RLHF / DPO：基于人类反馈或偏好对的对齐技术，让模型输出更符合人类期望。

对大多数 Agent 应用来说，优先靠 Prompt + RAG + 工具调用，只有这些手段都无法满足时才考虑微调。微调的真正常见场景是：输出格式强约束、特定领域术语、风格迁移、以及希望用小模型替代大模型以降低成本。

7. 数据与知识侧：模型的知识从哪儿来

RAG 和 Agent 的很多能力，依赖一套完整的数据基础设施。

7.1 Embedding：把文字变成向量

检索的前提是「算相似度」，而算相似度的前提是把文字变成向量。Embedding 模型（如 OpenAI text-embedding-3、BGE、M3E、Jina Embeddings、Cohere Embed 等）负责把一段文本映射成高维向量，语义相近的文本在向量空间里距离更近。

选型时要关注：向量维度、最大输入长度、中英文效果、是否支持多语言、推理成本、是否有开放权重可本地部署。国产 BGE 系列在中英文检索上表现优异，常被用于企业私有化场景。

7.2 向量数据库：相似度检索的引擎

向量数据库专门用来存储和检索向量，支持「给我最相似的 Top-K 条」这种查询。常见的有：

• FAISS：Meta 开源的向量检索库，性能极强，但不是完整数据库（更像引擎）。
• Milvus：国产开源分布式向量数据库，功能全面，适合大规模生产。
• Qdrant：Rust 编写的高性能向量库，部署简单，支持过滤与混合检索。
• Chroma：轻量级向量库，API 简单，适合原型和本地开发。
• Weaviate：支持向量 + 关键词混合检索与图能力的向量库。
• Pinecone：托管向量库服务，开箱即用，适合不想自运维的团队。
• pgvector：PostgreSQL 的向量扩展，让传统关系库直接支持向量检索。

选型维度包括：数据规模、是否需要过滤、混合检索、部署成本、运维复杂度。小项目用 Chroma/FAISS 即可，生产级用 Milvus/Qdrant/pgvector。

7.3 文档解析与切分

知识库里往往塞满了 PDF、Word、PPT、网页、扫描件。文档解析就是把这些异构文件变成干净文本。常用工具有：

• Unstructured：专门处理各种文档格式的开源库，能抽取标题、表格、图片说明。
• Docling（IBM 开源）：面向文档理解与转换，支持复杂 PDF 布局。
• LlamaIndex / LangChain 的 Loader：两大框架都内置了海量数据加载器。
• PDF 专用工具：如 PyMuPDF、pdfplumber、Marker、MinerU 等，用于处理复杂版面与公式。

切分（Chunking） 是另一个关键环节：把长文档切成适合检索的小块。切分策略有固定长度切分、按语义切分（句、段、标题）、递归字符切分、结合 Embedding 的语义切分等。切分太粗会导致检索噪声大，太细又会丢失上下文，需要根据文档类型与查询场景调节。

7.4 重排序与混合检索

纯向量检索有时会漏掉精确关键词匹配。因此生产系统常采用：

• 混合检索（Hybrid Search）：同时做向量检索 + 关键词检索（如 BM25），再合并结果。
• 重排序（Rerank）：用专门的 Rerank 模型（如 BGE-Reranker、Cohere Rerank）对初检结果重新打分排序，显著提升相关性。

这套「召回 + 重排」的组合拳，是高质量 RAG 系统的标配。

7.5 知识图谱

向量检索擅长「模糊语义匹配」，但难以表达实体之间的复杂关系（如「张三任职于 A 公司，A 公司投资了 B 公司」）。知识图谱用节点和边显式地表达实体与关系，常与 RAG 结合成 GraphRAG：先做实体抽取、构建图，再在图上做多跳推理检索。GraphRAG 适合关系复杂、需要多跳推理的问答场景，但构建成本高，适合数据相对稳定、价值密度高的领域。

8. Agent 开发框架：造房子的脚手架

这是整个生态中最热闹、迭代最快的部分。下面的框架各有定位，理解它们的差异，比记住每个 API 更重要。

8.1 LangChain 与 LangGraph

LangChain 是 Agent 领域知名度最高的框架，核心贡献是把 Prompt、模型、检索器、工具、记忆等组件抽象成统一接口，让开发者像搭积木一样组合。但早期的 LCEL（LangChain Expression Language）在处理复杂状态流转时略显吃力。

LangGraph 是 LangChain 团队推出的低层图编排框架，用「有向图」显式定义 Agent 的状态与流转，支持循环、分支、人工介入、检查点与回放。它非常适合构建可控的、生产级的复杂 Agent，也逐渐成为 LangChain 生态的重心。简单场景可以用 LangChain 快速串起来，复杂多步、需要精细控制的场景则应考虑 LangGraph。

8.2 LlamaIndex

LlamaIndex 的出发点是「数据侧」，即如何把企业数据（文档、数据库、API）高效地接入大模型。它在 RAG、索引、查询、检索策略 上做得非常深入，提供丰富的加载器、分块器、索引结构和查询引擎。如果你做的是「知识库 + 检索问答 + 多数据源聚合」，LlamaIndex 是首选之一。如今它也提供了 Agent 与工作流能力，与 LangChain 的边界越来越模糊，但数据侧仍是其强项。

8.3 AutoGen

AutoGen 是微软推出的多智能体框架，核心是「多 Agent 对话」。它让多个 Agent 通过自然语言对话协作完成编码、数据分析等任务，早期版本以其近乎「AutoGPT 感」的自动协作而闻名。新版 AutoGen 更强调事件驱动与可观测性。适合希望「让多个角色自动开会解决问题」的场景。

8.4 CrewAI

CrewAI 是一个 Python 多智能体框架，以角色（Role）、目标（Goal）、背景（Backstory）来定义每个 Agent，用 Task 定义工作流，再用 Crew 把它们组织成一个团队。它的理念是「组建一支虚拟团队」，上手非常直观，适合快速搭建多角色协作应用。中文社区对 CrewAI 的教程很多，生态活跃。

8.5 Semantic Kernel

Semantic Kernel 是微软推出的企业级 AI 编排框架，深度集成 .NET 生态，也支持 Python/Java。它的核心概念是「技能（Skill/Plugin）+ 计划器（Planner）+ 记忆」。对于已有大量 .NET 技术栈的企业，Semantic Kernel 是与现有系统结合最自然的选择。

8.6 Haystack

Haystack 是 deepset 推出的开源框架，以检索式问答和 RAG 见长，提供 Pipeline 式的声明式编排，组件化程度高，适合构建生产级检索系统。新版 Haystack 也加入了 Agent 能力。

8.7 MetaGPT、CAMEL、AgentScope、Swarm 等

• MetaGPT：以「软件公司」为隐喻，让多个 Agent 扮演产品经理、架构师、工程师、测试，按照标准化交付物（如 PRD、设计文档、代码）协作完成软件开发，强调 SOP（标准作业流程）在 Agent 协作中的作用。
• CAMEL：较早提出角色扮演多智能体的论文/框架，设计「AI 用户 + AI 助手」互相提问与执行。
• AgentScope：阿里巴巴开源的多智能体框架，强调分布式、可扩展和大规模 Agent 编排。
• Swarm（现演化为 OpenAI Agents SDK）：OpenAI 发布的轻量级多 Agent 编排示例，提出「交接（Handoff）」等极简抽象，后来发展成官方 Agents SDK，强调简洁与生产可用。

8.8 低代码/可视化平台

对于不想写代码的团队，有一批「拖拽式」Agent 平台：

• Dify：开源 LLM 应用开发平台，支持可视化编排工作流、RAG、Agent、企业知识库，支持私有部署，生态活跃。
• Coze（扣子）：字节跳动推出的 Agent 搭建平台，可视化程度高，内置丰富插件，可直接发布到豆包、微信等渠道。
• n8n / Flowise / Langflow：可视化工作流平台，n8n 偏通用自动化，Flowise/Langflow 偏 LLM 应用编排。
• Zapier / Make：通用自动化工具，也逐步接入 AI 节点。

这类平台大幅度降低了 Agent 的构建门槛，适合业务人员、创业团队和需要快速验证的场景；但深度定制、复杂逻辑与高并发场景，通常仍需回到代码框架。

8.9 框架选型建议

一个实用原则：先用低代码平台验证需求，再用代码框架做深度定制。追求生态与教程丰富选 LangChain/LangGraph；偏企业知识检索选 LlamaIndex；偏多智能体快速搭建选 CrewAI/AutoGen；.NET 企业选 Semantic Kernel；已有检索系统选 Haystack。与其纠结「哪个框架最好」，不如先明确「我的核心任务是哪种」。

9. 协议与标准：让工具与 Agent 互相对话

当生态里有成百上千个工具和 Agent 时，标准协议的价值就凸显出来。

9.1 MCP：模型上下文协议

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底开源的一个开放协议，目标是统一「大模型如何调用外部工具与数据源」。它的架构是：

• Host：承载大模型的应用，如 Claude Desktop、IDE、自建 Agent。
• MCP Server：暴露具体能力的服务，如文件系统、数据库、浏览器、GitHub 的访问。
• Client/Server 通信：基于 JSON-RPC，支持本地（stdio）与远程（HTTP/SSE）两种方式。

MCP 的价值在于「一次编写、处处可用」：一个 GitHub MCP Server 可以被任何支持 MCP 的 Host 使用，而不需要每个应用都单独写集成代码。此后 OpenAI 也宣布支持 MCP，加上阿里、腾讯等厂商跟进，MCP 已迅速成为工具接入的事实标准。

9.2 A2A：Agent 到 Agent 协议

如果说 MCP 解决「Agent 怎么用工具」，那么 A2A（Agent-to-Agent） 解决「Agent 之间怎么协作」。A2A 是 Google 联合多家公司推出的开放协议，目标是让不同厂商、不同框架构建的 Agent 能够互相发现、互相调用、互相交接任务。它强调「agent card」能力发现、任务生命周期管理、长任务的流式交互等。A2A 若被广泛采纳，未来可能形成类似「Agent 的万维网」。

9.3 其他相关标准

• OpenAPI / JSON Schema：工具的参数描述普遍沿用这些既有标准。
• Function Calling 协议：各家 API 都提供了类似的函数调用协议，虽然细节不同，但思想一致。
• OpenTelemetry：在可观测性领域被广泛用于 Agent 的链路追踪与指标采集。

理解这些协议的意义在于：未来的 Agent 开发，很可能不再是「自己写死工具调用」，而是「注册标准化的 MCP Server + 通过 A2A 与其他 Agent 协作」。提前熟悉标准，等于踩在了趋势前面。

10. 工具调用、浏览器与代码执行

Agent 的「手脚」具体有哪些？这是从概念走向落地的关键一环。

10.1 浏览器自动化

很多任务需要 Agent 真实地浏览网页、点击、填表、抓取数据。相关工具包括：

• Playwright / Puppeteer / Selenium：经典的浏览器自动化库，Agent 通过它们操作网页。
• Browser-use：专为 LLM 设计的浏览器智能体库，让模型以「看网页 → 决定点击 → 执行」的方式完成任务。
• Skyvern：基于视觉和 LLM 的浏览器代理，强调理解网页而非依赖固定的选择器，适合复杂表单和网站自动化。

浏览器 Agent 的难点在于网页结构复杂、易变、反爬和登录墙，目前更适合「信息搜集、表单填报、流程测试」等相对结构化的任务。

10.2 代码解释器与沙箱执行

让 Agent 写代码还不够，很多任务需要它执行代码并观察结果：数据分析、图表生成、文件转换、甚至纠错后再运行。实现方式有：

• 沙箱环境：如 Docker、Firecracker、gVisor 等，把代码执行隔离起来。
• 代码解释器：如 OpenAI Code Interpreter、E2B（云沙箱）、Jupyter 内核，提供「写代码 → 运行 → 返回结果」的闭环。
• 本地执行：直接调用 Python/Shell，但必须做好安全隔离，避免恶意代码破坏系统。

安全是代码执行的第一要务：永远不要在未隔离的环境中运行不可信的代码。

10.3 Computer Use：像人一样操作电脑

Computer Use 是更激进的形态：让 Agent 直接看屏幕截图，然后输出鼠标点击和键盘输入，像人类一样操作任意图形界面。代表产品有 Anthropic 的 Claude Computer Use、OpenAI 的 Operator，以及开源的 Open Interpreter、OSWorld 等。这种方式的通用性最强，但准确率、速度和安全风险仍然突出，目前多用于演示和研究场景。

11. 评测、监控与安全：让 Agent 可被信任

能跑起来只是第一步，怎么能知道它做得好不好、安不安全、出了错能不能定位，是生产化的核心。

11.1 Agent 评测

跟传统软件不同，Agent 的输出是自然语言，评价标准更主观、更复杂。常用做法包括：

• 基准数据集：如 GAIA（通用助手基准）、SWE-bench（软件工程任务）、WebArena（网页操作）、ToolBench（工具使用）等，用来横向比较 Agent 能力。
• LLM-as-a-Judge：用另一个大模型根据「事实性、完整性、流畅性、遵循指令」等维度打分。
• 端到端任务成功率：定义一个可自动判断成功与否的任务集（比如「能否正确预订航班」「能否通过测试用例」），统计完成率。
• 轨迹评测：评估中间规划与工具调用是否合理，而不仅是最终答案。

11.2 RAG 评测

RAG 系统需要单独评测「检索质量」和「生成质量」。常用指标与工具有：

• 召回率 / 精确率 / MRR / nDCG：评估检索模块。
• Faithfulness（忠实度）：生成内容是否与检索到的上下文一致，防止幻觉。
• Answer Relevance（答案相关性）：答案是否切题。
• Context Relevance（上下文相关性）：检索内容是否有用。
• RAGAS：专门的 RAG 评测框架，基于 LLM 计算上述指标。
• DeepEval / Promptfoo：通用 LLM 评测与测试框架，可做单元测试式的回归验证。

11.3 可观测性

Agent 是多步、非确定的过程，出问题时需要能「回放现场」。可观测性工具包括：

• LangSmith（LangChain 官方）：记录每个步骤的输入输出、延迟、成本、Token 用量，支持调试与评测。
• Langfuse：开源的 LLM 可观测平台，支持追踪、成本统计、数据集与评测，可自托管。
• Phoenix（Arize）：开源的可观测与评测平台，强调 Embedding 与 RAG 的可视化分析。
• OpenTelemetry 集成：把 LLM 调用作为分布式链路的一部分统一监控。

11.4 安全与护栏

Agent 的安全风险比普通聊天更高：它可能泄露数据、执行危险操作、被提示注入攻击、产生有害内容。防护手段包括：

• 提示注入防护：识别并过滤隐藏在工具返回值或用户输入里的恶意指令。
• 内容安全护栏：如 NeMo Guardrails（NVIDIA）、Guardrails AI、Llama Guard，对输入输出做策略校验。
• 权限最小化：工具只授予完成任务所需的最小权限，敏感操作必须人工确认（Human-in-the-Loop）。
• 沙箱与审计：所有外部交互记录日志，可审计、可回滚。
• 输出验证：对结构化输出做 schema 校验，对危险操作做二次确认。

安全护栏不是「可选项」，很多企业 Agent 项目最终卡在安全合规上。这个方向本身也是一个专门的学科分支。

12. 应用场景与产品：Agent 在现实世界长什么样

理论讲完了，最后看看 Agent 已经「长成」的形态。理解产品，能反过来指导你该学什么。

12.1 编程 Agent

这是 Agent 落地最成功的领域。代表产品：

• Cursor / Windsurf：AI 编程 IDE，能在编辑器中读懂整个工程，提供代码补全、多文件编辑、debug 建议，本质是一个「代码 Agent」。
• GitHub Copilot：代码补全与 Chat 助手，逐步加入 Copilot Workspace 等多文件 Agent 能力。
• Devin / OpenHands：全自主编程 Agent，能独立完成 issue 修复、搭建项目、跑测试，目标是「AI 软件工程师」。
• SWE-agent / Aider / Cline：开源编程 Agent，结合源代码检索与终端操作，能自动修改代码。

编程 Agent 的核心能力是：读懂仓库结构、精准修改代码、执行测试反馈、遵守工程规范。学习方向包括：代码检索（AST/符号索引）、编辑器集成、测试驱动修复。

12.2 深度研究与办公 Agent

• OpenAI Deep Research / Google Gemini Deep Research：输入一个研究问题，自动搜索大量网页、阅读、综合，生成带引用的研究报告。
• GPT Researcher：开源深度研究 Agent，模拟「研究员 - 编辑」协作，并行抓取与综合信息。
• NotebookLM：把上传的资料变成可交互问答的「个人研究助手」，支持生成播客等新形态。
• Manus / 办公自动化 Agent：多步骤执行网页任务、报表生成、数据整理，目标是「把你交代的事直接做完」。

12.3 客服、销售与营销 Agent

• 客服 Agent：基于企业知识库的 RAG 问答 + 工单系统集成，能自动回复、查询订单、转接人工。Dify、Coze 上的大量应用都属于此类。
• 销售 Agent（SDR）：自动触达潜在客户、跟进邮件、记录 CRM，结合语音播报进行电话外呼。
• 营销内容 Agent：根据品牌调性批量生成文案、图片、短视频脚本，配合多渠道分发。
• 电商运营 Agent：自动生成商品描述、客服话术、投放素材。

12.4 行业垂直场景

• 金融：研报生成、财报分析、合规审查、投研问答。
• 医疗：病历摘要、辅助诊断知识检索、患者随访（需严格合规）。
• 法律：合同审查、类案检索、法律文书生成。
• 教育：智能助教、个性化出题、作文批改。
• 制造/能源：设备故障诊断、知识库问答、工单自动化。

12.5 产品形态背后的共同能力

抛开行业差异，所有成功的 Agent 产品基本都具备：清晰的输入输出边界、可靠的领域知识底座、可控的工具集、完善的安全与评估机制。学习 Agent，最有效的方式就是拆解一两个成熟产品，还原其技术栈，然后自己动手复刻一个「最小可用版」。

13. 学科化的学习路径建议

如果你想把「AI Agent」当成一门学科来系统学习，这里给出一条循序渐进的路径。

第一阶段：打地基（2～4 周）

• 理解 Transformer 的基本结构：注意力机制、Encoder-Decoder。
• 掌握 Token、上下文窗口、温度、推理等基础概念。
• 亲手调用一个 LLM API（如 OpenAI、Qwen、DeepSeek），跑通对话、流式输出。
• 熟练写 Prompt：角色、步骤、Few-shot、结构化输出。

第二阶段：掌握 Agent 核心（4～6 周）

• 手写一个最简单的 ReAct Agent：不用框架，就用 API 循环实现「思考 → 调用函数 → 观察 → 继续」。
• 学习 Function Calling 与 JSON Schema。
• 学习 RAG：从文档解析、切分、Embedding、向量库、检索、重排到生成，完整跑一条链路。
• 学习记忆：短期上下文管理与长期记忆存储（摘要 + 向量库）。

第三阶段：用好框架（4～8 周）

• 用 LangChain 或 LlamaIndex 重构前面的 Agent 与 RAG。
• 学习 LangGraph 的状态图思想，构建带循环、分支、人工确认的工作流。
• 尝试 CrewAI/AutoGen 搭建一个多智能体协作 Demo，理解其优劣。
• 用 Dify/Coze 搭建一个可视化应用，感受低代码平台的边界。

第四阶段：工程化与生产（6～12 周）

• 学习 vLLM/Ollama 部署开源模型，理解量化与推理优化。
• 接入 MCP Server，体会工具标准化。
• 使用 LangSmith/Langfuse 做链路追踪，定位问题。
• 使用 RAGAS/DeepEval 建立评测集与回归测试。
• 学习护栏与安全：提示注入防护、权限控制、审计日志。
• 亲手交付一个端到端、可演示、可评测的生产级 Agent 项目。

第五阶段：深入专长（按兴趣选择）

• 模型方向：LoRA/QLoRA 微调、RLHF/DPO 对齐、推理加速。
• 数据方向：文档理解、向量检索、GraphRAG、知识图谱。
• 协议方向：MCP、A2A 的深入实现。
• 多模态方向：视觉理解、Computer Use、语音交互。
• 行业方向：选择一个垂直领域深挖，把 Agent 落到业务里。

核心学习方法论：与其看一百篇教程，不如亲手把一个「能跑通闭环」的 Agent 从零到一做完。遇到问题再看文档、论文和源码。Agent 领域变化极快，最重要的能力不是记住某个框架的 API，而是掌握底层原理、拥有快速上手新工具的方法论。

14. 总结：上层建筑的底层逻辑

从 ChatGPT 到如今繁花似锦的 Agent 生态，表面上工具层出不穷，但其底层逻辑始终没变，可以浓缩成三句话：

1. 大模型负责「思考」，Agent 负责「行动」。思考能力来自模型与推理范式，行动能力来自工具调用与外部交互。
2. 一切架构都在解决四个问题：知识、记忆、工具、控制。RAG 解决知识，Memory 解决记忆，Function Calling/MCP 解决工具，规划与工作流解决控制。
3. 从「能跑」到「可信」之间，隔着评测、监控与安全。它们不是附加品，而是生产系统的必需品。

对于每一位想进入这个领域的读者，本文的意义不是让你记住所有名词，而是帮你建立一张可以持续生长的地图。以后每出现一个新框架、新协议、新模型，你都能迅速判断它在地图上的位置：它是新的基座模型，还是更好的推理引擎？是新的 Agent 范式，还是更顺手的编排框架？是数据侧的新工具，还是评测侧的新方法？

一旦有了这张地图，你就不会再被层出不穷的概念牵着走。你会清楚地知道：大模型时代的「上层建筑」，本质上是一套把「语言理解」转化为「真实行动」的工程学。而学习它最好的方式，就是现在动手，让一个真正的 Agent 为你完成一件真实的小事。

本文到此结束。祝你在这张地图上，找到属于自己的坐标和方向。