很多人第一次接触 AI Agent，是从 ChatGPT、Claude 这些聊天框开始的。输入一句话，它吐出一段文字——这是大模型（LLM）本身的能力边界：文字进、文字出。

但当你说"帮我查一下明天北京飞上海的航班，挑最便宜的，把行程发到我邮箱"，聊天框就不够了。它需要理解"查航班"这个意图、知道去哪里搜索、比较价格、调用发邮件的工具、最后确认结果。这一整套不只是"生成文字"，而是"把事情办了"的系统，就是 Agent。

一、Agent 的本质定义

Agent = LLM（决策大脑）+ 一系列让它"能干活"的外设。

学术界对 Agent 的定义更严谨：一个智能体必须具备自主性（能独立决策）、反应性（能感知环境并响应）、主动性（能主动采取行动追求目标）、社交能力（能与其他 Agent 或人交互）。LLM 本身只解决了"语言理解与生成"这一环，其他三个属性都需要通过外部系统来实现。

LLM 负责"想"——理解意图、规划步骤、判断下一步。但为了把"想"变成"做"，还需要：

• Memory（记忆）：记得之前说过什么，跨轮对话不丢上下文
• Tools（工具）：能搜索、读文件、跑代码、发请求
• Skills（技能）：把多个工具按固定流程串起来，避免 LLM 自己瞎走流程
• MCP（协议）：标准化的工具接入方式，让工具跨 Agent 复用
• Harness（外壳）：沙箱、钩子、权限约束，保证这个能干活的系统不闯祸

一句话：Agent 不是"更聪明的 ChatGPT"，而是把 LLM 当作决策引擎、外围接了一整套工程能力的完整系统。

从代码的角度看，纯 LLM 调用和 Agent 调用的区别很直观：

纯 LLM 调用：

response = llm.chat("帮我查北京到上海的航班")
print(response)  # LLM 只能"说"出它训练数据里记得的航班信息

Agent 调用：

agent = Agent(llm=llm, tools=[FlightSearch(), EmailSender()])
result = agent.run("帮我查明天北京飞上海的航班，挑最便宜的，发到我邮箱")
# 背后是：意图识别 → 调FlightSearch → 比较价格 → 调EmailSender → 确认结果
print(result)

这就是本质差异：一个只会说，一个真的去做。

二、为什么 LLM 自己不够用

大模型有三个绕不开的先天缺陷，Agent 架构正是为弥补这些存在的：

1. 知识有截止日期

训练数据停在某个时点，不知道你公司的内部文档，也不知道今天刚发生的事。问"2025 年 Q3 的财报"——如果训练数据只到 2024 年，LLM 要么说不知道，要么瞎编。

这个问题靠模型本身解决不了。重新训练成本太高，微调也跟不上信息变化速度。唯一可行的办法是让模型"查了再答"——这就是 RAG。

2. 不会主动行动

这是最隐蔽也最关键的局限。很多人以为"AI 能写代码"就等于"AI 能干活"，但写代码和部署代码之间隔着一整个 DevOps 流程。LLM 输出再漂亮的 Python 脚本，它自己也不会去执行。Tools 就是打通这最后一公里的桥梁——让 LLM 不只是输出文字，还能触发真实操作。

3. 没有记忆

LLM 的参数在训练后固定不变，y = f(x) 中参数不随输入变化。每次对话都是"第一次见面"，除非把历史记录全部塞回输入里。但上下文窗口有限，不可能无限拼接。

这就引出了记忆管理的需求：不是把所有历史都塞进去，而是有选择地记住关键信息，忘记不重要的。

三、谁在弥补这些缺陷

缺陷	补丁方案	作用
知识截止	RAG（检索增强生成）	从外部知识库检索实时信息注入到 LLM 输入中
不会行动	Tools / MCP	让 LLM 能调接口、执行代码、操作文件
没有记忆	Memory 模块	短期记忆（Session 内）+ 长期记忆（跨 Session）

你会注意到这三块是互相独立的：RAG 解决"知识不够"、Tools 解决"能力不够"、Memory 解决"记性不够"。它们可以独立使用，也可以组合——实际上生产环境的 Agent 几乎都是三者同时用。

这一套"LLM + 外设"整合起来，就是 Agent 的完整架构。后面每篇会逐个拆开来讲。

四、Agent 的 Perception-Decision-Action 循环

把 Agent 拆解到最底层，它的运行逻辑可以概括为三个阶段的循环：

1. 感知（Perception）：接收用户输入、感知环境状态、加载记忆和上下文
2. 决策（Decision）：理解意图、规划步骤、选择工具和技能
3. 行动（Action）：执行工具调用、生成输出、记录结果到记忆

用户输入 → 感知（加载上下文/记忆）→ 决策（意图识别/路由）→ 行动（工具调用/生成）→ 观察结果 → 循环/结束

每执行完一次行动，Agent 会观察结果，判断是否要继续——这就是后面会详细讲的 ReAct 循环。

五、2026 年 Agent 开发的特点

2026 年，Agent 开发的重心已经不再是 RAG。Skill、Tool、MCP、Memory 成为新的关键词。像 Claude Code、OpenClaw 等产品，没有 RAG 和向量数据库，照样运行良好。RAG 会在 2B 企业场景回归，但对 2C 个人工具来说，Skill + Tool 已经够用。

这背后有两点原因：

1. LLM 理解力增强——上下文窗口从 4KB 增长到了 200KB+（Gemini 甚至达到 100 万 token），不再需要预筛选工具描述
2. Skill 生态成熟——一个人十多年积累的内容，用 Skill 形式就能被大模型很好理解

六、什么时候不需要 Agent

最后说一个很重要但容易被忽略的点：不是所有场景都需要 Agent 架构。

如果你的任务只是"翻译一段文字"或"写一封邮件草稿"，LLM 直出就够了。引入 Agent 反而增加复杂度和延迟。Agent 的价值在以下场景中才真正体现：

• 任务需要多步推理和工具调用
• 任务需要外部数据（实时信息、私有文档）
• 任务需要跨对话保持上下文
• 任务需要执行实际操作（发消息、改文件、部署代码）

当你的需求超出"聊天"的范畴，想让它"把事情办了"——那才是 Agent 上场的时候。