AI Agent是以大语言模型(LLM)为核心，能自主感知环境、推理决策、调用外部工具并循环执行直至完成目标的系统。其核心组成模块包括规划、推理中枢(LLM)、工具集和记忆。Agent通过ReAct（交替思考、行动、观察）或Plan-and-Execute（先规划再执行）等范式实现智能，并借助Tool Call与MCP协议连接外部世界。Human-in-the-Loop（人工确认）机制确保高风险操作的可靠性，而Agent Skills则通过渐进式披露机制，将领域知识与流程规范按需加载。沙箱、Session管理、上下文管理、知识库与记忆等外围组件则保障Agent的稳定运行。未来，Agent将贯穿软件工程与数据分析全流程，但同时也需警惕失控、偏见、就业冲击等风险，重新定义“可控”与边界成为关键命题。
- 从一个案例开始
当你对一个智能体说：“帮我把上个月的销售数据拉出来，对比市场同类产品，做成分析报告，上传并抄送团队”。
十分钟后，智能体已连上数据库、写好并跑通取数分析SQL、联网搜索最新竞品信息、画好图表、生成了一份图文并茂的报告，然后停下，弹出一句：“报告已起草好，收件人是这几位，确认发送吗？如有需要修改的地方请指出。”
❞
这是当下一个普通智能体 (AI Agent) 的基本功能。几年前我们用AI对话聊天，现在我们用AI实际干活。接下来，作者将揭秘AI Agent的核心原理与基础组件。
- 智能体到底是什么
一句话定义：AI Agent 是一个以大语言模型(LLM)为"大脑"，能够自主感知环境、推理决策、调用外部工具，并循环执行直到完成目标的系统。
它和传统聊天机器人的本质区别是行动能力。聊天机器人止步于"输出一段文字"；Agent 会实际搜索、调用 API、编写代码、读写文件、操作浏览器，甚至委派给另一个Agent。 如果把 LLM 比作一个绝顶聪明却被"锁在房间里、只能说话"的大脑，那么Agent框架做的事，就是给这个大脑装上眼睛（感知），手脚（工具），记事本（记忆）和纪律（规划与红线），让它能真正走出房间，并影响世界。
1.1 核心组成模块
一个完整的 Agent 系统，通常由以下几个模块组成：
规划（Planner）：把大目标拆成可执行的小步骤，代表范式是 ReAct 与 Plan-and-Execute。
推理中枢 (LLM)：真正的"大脑"，负责理解任务、生成思考与行动指令、判断是否收尾。
工具集（Tool Set）：通过 Function Calling | MCP 协议触达外部世界，是 Agent 的"手脚"。
记忆（Memory）：短期是对话上下文，长期是向量数据库与持久化存储。
「注意」：LLM 本身不执行任何动作，它只负责"决策"。它输出的是"我要调用 function_x，参数是param1, param2"这样的结构化指令，真正去调 API、执行代码的是外层的"Agent 运行时"。
❞
- 核心原理
Agent的"智能"不是玄学，而是几种可拆解、可工程化的范式在协同工作。现在从最基础的推理循环开始，逐步到工具调用，人机交互，与智能体技能等原理。
2.1 ReAct
ReAct源自论文《ReAct: Synergizing Reasoning and Acting in Language Models》，是当今几乎所有 Agent 的推理骨架。它的核心思想优雅简洁：让模型交替地"想一步，做一步，看一眼结果"，也就是三段式循环：
- Thought（思考）：模型推理当前状态，决定下一步做什么。
- Action（行动）：模型决定调用哪个工具、传什么参数。
- Observation（观察）：工具返回结果，作为新的上下文返回给模型。
接着是Observation → 新的 Thought → 新的 Action → ...不断循环，直到任务完成。
关于何时停止：**LLM 不会主动说"我该停止"，那循环何时结束？**目前有以下几种规则：
- Final Answer 标记：模型认为信息已足够时，会输出
Final Answer前缀，运行时检测到即停止。由大模型训练获得的能力。 - 最大迭代次数（Max Iterations）：开发者预设上限（N = 10 步、20 步），到顶就强制收尾。这是防止无限循环的最后防线。
- 错误熔断：连续多次工具调用失败（如 3 次），判定无法继续，输出当前最优结果。
ReAct的优点是灵活，自适应强，能在执行中随时纠偏；缺点是每一步都要调用一次LLM，Token消耗较大，且步子多了容易"跑偏"。这就引出了它的互补范式。
2.2 Plan-and-Execute
如果说ReAct是"走一步看一步"，那Plan-and-Execute就是"先起草规划再开动"。它把执行拆成两个阶段：
规划阶段（Plan）：一个较强的 LLM（Planner）一次性生成完整的步骤清单。
执行阶段（Execute）：一个执行器（Executor）逐条执行，甚至可以用更轻量、更便宜的模型；一旦某步失败，就触发重规划（Re-Plan）。
重规划是与 ReAct 最关键的区别。ReAct 遇到失败是"换个工具/参数再试试"(局部重试)，而 Plan-and-Execute 是把"已完成步骤 + 失败信息 + 剩余计划"整体回传给规划器，让它重新审视整个计划(全局修订)。
为了不让它无限重规划，工程上会设两道闸：总步数上限(如 10 步)和重规划次数上限(如 3 次)，任一超限即标记任务失败。
对比如下：
| 维度 | ReAct | Plan-and-Execute |
|---|---|---|
| 规划时机 | 每步都规划 | 一次性规划，失败时重规划 |
| 调用频率 | 每步都调用(高) | 规划时调用，执行可用轻量模型(低) |
| 失败处理 | 单步重试 | 整体重规划 |
| 适用场景 | 步骤少、需灵活应变 | 步骤多、流程明确、可预拆解 |
| 优点 | 灵活、自适应 | 全局视野、成本可控 |
| 缺点 | 易跑偏、成本高 | 计划僵化、重规划开销大 |
这两种范式往往在框架中被结合使用。例如简单1~2轮对话能完成的任务，则直接使用ReAct模式；超长/复杂任务，先使用Plan-and-Execute，每步执行时，采用ReAct配合。
2.3 Tool Call
工具调用的本质是：LLM 输出结构化指令，运行时负责执行。以经典的 Function Calling 为例，一次完整调用如下所示：
更专业地说，它是LLM 与外部系统之间的结构化动作接口：
- 开发者向模型声明可用函数：
name、description、parameters / JSON Schema。 - 模型判断是否需要调用工具。
- 如果需要，模型输出类似
{ tool_name, arguments }的结构化调用意图。 - Agent / 应用层解析这个调用意图，校验参数，执行真实 API、数据库查询、搜索、计算等。
- 工具结果再回传给模型，模型基于结果继续推理或生成最终回答。
MCP 的作用
MCP，Model Context Protocol，本质上是：**Agent连接外部工具、数据源、上下文资源和工作流的一套开放协议标准。
核心能力：
| 能力 | 作用 |
|---|---|
| Tools | 暴露可被模型调用的工具，例如搜索、数据库查询、计算任务 |
| Resources | 暴露上下文资源，例如文档、数据schema、项目代码 |
| Prompts | 暴露可复用的提示模板或工作流入口 |
MCP的规范明确说明，MCP server暴露工具，客户端通过tools/list发现工具，通过tools/call调用工具；每个工具有唯一名称、描述和输入 schema。此外，MCP 还支持 Resources，用统一 URI 暴露文件、数据库 schema、应用上下文等信息。Prompts 则用于提供结构化提示模板，支持用户或客户端选择调用。
对比
| 维度 | Function Calling | MCP |
|---|---|---|
| 所在层级 | 模型调用接口层 | 工具/上下文接入协议层 |
| 解决问题 | 模型如何表达“我要调用哪个函数、用什么参数” | 外部工具、数据、资源如何标准化暴露给 AI 应用 |
| 关注对象 | function name + arguments | tools / resources / prompts / transport / auth / JSON-RPC |
| 执行者 | 应用层或 Agent runtime | MCP client 调用 MCP server |
2.4 Human-in-the-Loop
AI自主性越强，越需要一个"人工确认"的交互。当 Agent 即将执行高风险操作时(例如向他人付款、删除数据、修复关键配置)，系统先暂停住，等人确认。这就是Human-in-the-Loop（HITL）。
HITL技术实现依赖两个关键能力：中断 interrupt与状态快照 checkpoint。
完整链路是：Agent 检测到高风险 Action → 触发 interrupt，把完整状态快照落盘到状态存储库 → 流程挂起，向人工展示审批界面 → 给出三种裁决之一：批准（Approve）、修改后批准（Edit）、拒绝（Reject）→ Agent 从快照恢复状态，继续后续循环。
在大家常用的 Agent (例如
Cursor,CodeX) 均采用Plan-and-Execute搭配HITL。先进行需求理解与规划起草，当遇到不确定的步骤，或需要执行对系统有影响的操作时，触发人工确认，只有等人工完成确认后，Agent才会继续执行。❞
2.5 Agent Skills
仅推理和工具往往还不够，真实工作需要输入领域知识和流程规范。而用户不可能将操作规范，报表口径，审批流程每次都写进提示词，那会瞬间撑爆上下文。Agent Skills就是为此而生。
一个 Skill 本质上是一个**「文件夹」：一个必需的SKILL.md(定义name和description) + 可选的scripts/(脚本代码),references/(参考资料),assets/(静态资源)。Skill的精髓在于渐进式披露（Progressive Disclosure）**，分三级按需加载：
- 一级（永远常驻）：只把每个 Skill 的
name + description预载进系统提示，让 Agent"知道有哪些技能、何时该用"，却几乎不占 token。 - 二级（命中才载入）：当 Agent 判定某 Skill 相关时，才读取完整的
SKILL.md正文指令。 - 三级（深挖才读取）：需要更多细节时，再去读
scripts/,references/,assets/里的链接文件。
这套机制把"通用 Agent"变成"领域专家"，同时把上下文占用压到最低。今年，Agent Skills 已发展为发布在agentskills.io的开放标准，跨平台可移植；Claude 全家桶（Claude.ai、Claude Code、Agent SDK）与 DeepAgents 都已支持。作者后续也将发布一篇关于Agent Skill的选择与实战文章。
**「Skill VS MCP」**引用Anthropic：
MCP 给 AI Agent 提供连接到外部服务和数据源的能力。Skill 则提供程序知识–关于如何完成特定任务或工作流程的说明。可以同时使用两者：MCP 连接为 AI Agent 提供工具访问权限，而 Skill 教会 AI Agent 如何有效地使用这些工具。
❞
- 外围组件
真正把 Agent 送上生产线的，往往不是那些酷炫的推理范式，而是一圈"不起眼但缺一不可"的支撑组件。让我们先看一下完整的AI Agent架构图。
3.1 沙箱
Agent 可以编写和执行任何代码、命令，但不能任由它在生产服务器上直接执行。沙箱（Sandbox）就是一个被严格隔离的执行环境，无法影响宿主机。
一个典型沙箱的生命周期是：创建（指定运行时）→写入代码→执行（受限运行）→取回结果（stdout / 文件）→销毁（释放资源）。隔离维度包括：文件系统临时且销毁不可恢复、网络仅限白名单、CPU / 内存 / 运行时间都有硬性配额；一旦越界，立即强制终止。
3.2 Session 管理
Agent 任务往往横跨多轮、长时间运行，甚至需要在中断后异步恢复。Session 管理负责维护每个会话的状态，让 Agent 重启、故障恢复都能"接着上次继续"。
一个 Session 里到底存什么？
| 状态类型 | 典型内容 | 特点 |
|---|---|---|
| 工作态 | 当前任务、最近若干轮消息、工具中间结果、协调锁 | 几乎每轮都读写、可重算、丢了能恢复 |
| 持久态 | 完整对话转录、工具执行结果、审批记录、审计日志 | 是"真相源"，崩溃后必须存活 |
| 检查点 | 节点边界的完整状态快照 | 用于中断恢复、失败重跑、HITL 续跑 |
业界主流：热冷分层（Redis + PostgreSQL）
目前生产环境的事实标准是混合架构：用Redis承担热路径毫秒读写、带 TTL 的会话工作态、分布式锁；用RDBMS做冷路径与真相源落盘完整转录、工具结果、checkpoint、审计。一个后台 worker 定期把已完成的会话从 Redis 持久化到 Postgres，让 Redis 保持精简（几百 MB 工作态）而 Postgres 承载 GB 级历史。跨会话的语义召回则常用向量检索搭配Milvus等VectorDB。
3.3 上下文管理
LLM 的上下文窗口是有限且昂贵的资源。长任务跑着跑着，上下文就会被中间步骤、搜索结果、工具输出塞满。上下文工程（Context Engineering）也是近年来 Agent 的核心竞争力之一。
Compaction（压缩）：
Compaction 的思路是：当对话逼近窗口上限时，把历史**「高保真地摘要」，再用"摘要 + 最近内容"重启一个新的上下文窗口。关键在于「摘要什么、丢弃什么」：以 Claude Code 为例，它会让模型保留「架构决策、未解决的 bug、关键实现细节」**，丢弃冗余的工具输出和重复消息，然后带着"压缩后的上下文 + 最近访问的 5 个文件"继续跑，用户几乎无感。
分层压缩流水线（由轻到重）
以 Claude Code 的分层策略为例：
| 层级 | 触发时机 | 做法 | 成本 |
|---|---|---|---|
| Micro-compaction | 随时 | 清理陈旧的工具结果，且 cache-aware（不破坏已缓存前缀） | 零模型调用 |
| Auto-compaction | 约 80–85% 窗口占用 | fork 一个子 agent 对历史做摘要，并打上边界标记以保留可审计时间线 | 一次模型调用 |
手动/compact | 用户主动 | 大任务开跑前先压一遍，给后续腾出空间 | 一次模型调用 |
| Session-memory compact | 实验特性 | 用预先抽取的笔记直接替代摘要，跳过模型调用 | 极低 |
| Emergency | prompt_too_long报错 | 兜底：中途捕获错误、压缩后自动重试 | 视情况 |
一个实用经验是提前触发（如 200K 窗口在 ~150K 就压），给模型留足输出预算，才能写出高质量摘要。(Claude Code 上下文压缩)
服务端 Compaction
除了客户端自己做，Anthropic还把压缩下沉到API：在请求里声明compact_20260112策略、按input_tokens设阈值（默认 150K），命中后 API 自动生成一个compactionblock；后续请求带上它，API 会**「自动丢弃该 block 之前的全部内容」**，从摘要处续跑，无需客户端写压缩代码。(Anthropic Compaction 文档)
3.4 知识库与记忆
Agent 的记忆粗看分两层：「短期记忆」是当前对话上下文，随会话消失；「长期记忆」则依赖向量数据库与持久化存储，让 Agent 能跨会话回忆、并通过 RAG（检索增强生成）把外部知识库接入推理。但要真正落地，得回答四个问题：「怎么判定该记什么、怎么筛选取回、存在哪里、后续怎么加载」。
记忆分层：从 RAM 到冷存
业界常按"寿命 + 用途"把记忆细分为四类，Letta/MemGPT 更直接把它类比成操作系统的虚拟内存：
| 记忆类型 | 内容 | Letta 类比 |
|---|---|---|
| 工作/短期 | 当前上下文窗口内的对话与中间态 | Core Memory（RAM，在窗口内，随读随写） |
| 情景（Episodic） | 历史会话记录，可检索 | Recall Memory（磁盘缓存） |
| 语义（Semantic） | 沉淀下来的事实、偏好、知识 | Archival Memory（冷存，靠工具查询） |
| 程序性（Procedural） | 流程与规范 | 对应 Skills，非"记忆" |
如何判定该记什么（写路径）
主流做法是**「写入时用 LLM 门控做事实抽取」：Mem0 的 distill-at-write 会在每轮结束后用一次 LLM 调用把原始对话提炼成结构化"事实"，采用「append-only（只增不改）」避免覆盖丢失，并做「去重、冲突消解、时间推理」（比如"4月要去新西兰"到期后改写为"已于 2026年4月去过新西兰"），同时按user / session / agent / app四个维度「分域」防止串味。(Mem0 架构) ChatGPT 走的是另一条路：后台「Dreaming」进程在空闲时读取多段历史，「合成」**出一份用户记忆状态，单独存放、在推理时注入系统提示。(ChatGPT Dreaming)
如何筛选 / 召回（读路径）
召回质量取决于"多信号融合"而非单纯向量相似度。生产系统通常并行跑**「向量语义检索 + BM25 关键词 + 实体/图谱匹配」，分融合后再 Rerank，并叠加「分域过滤」（只取该用户/该会话）与「时间排序」**（取正确的那个时间版本）。
- 缓存与向量库怎么选
| 用途 | 选型 | 说明 |
|---|---|---|
| 热态 / 工作记忆 | Redis/Valkey | 亚毫秒读写、TTL、分布式锁 |
| 语义 / 向量召回 | Qdrant/Milvus | 超大规模、需二值量化等优化选 Qdrant 等专用库 |
| 关系型元数据 | PostgreSQL/MySQL | ACID、跨会话/时间范围的复杂过滤 |
| 关系型 / 图记忆 | Neo4j | 需要多跳推理、实体关系与双时态审计时 |
假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。
接下来告诉你一条最快的邪修路线，
3个月即可成为模型大师，薪资直接起飞。
阶段1:大模型基础
阶段2:RAG应用开发工程
阶段3:大模型Agent应用架构
阶段4:大模型微调与私有化部署
配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇
)
 agent和组件)