副标题： 从 7 层能力框架理解 AI Agent 到底能做什么——以及不能做什么
日期： 2026年6月29日

---

一个让人困惑的问题

同一个模型（比如 DeepSeek），在两种场景下表现截然不同：

场景 A：在网页对话框里用

你: "帮我查一下为什么我的程序崩溃了"
DeepSeek: "可能是内存溢出、空指针异常、或者驱动问题..."
         （推理很合理，但它不能碰你的电脑）

场景 B：在 Claude Code（Agent）里用

你: "帮我查一下为什么我的程序崩溃了"
Agent:
  ① 执行 nvidia-smi → 看到驱动版本 535
  ② 查看 Ollama 日志 → "NVIDIA driver too old"
  ③ 查 Ollama 文档 → v0.30.11 要求 ≥ 550
  ④ 给出 3 种升级方案
  ⑤ 执行选中的方案
  ⑥ 验证 segfault 已修复 ✅

模型是同一个，但结果天差地别。多出来的能力不是来自模型，而是来自"Agent 框架"。

这篇文章带你拆解：Agent 到底比裸模型多了什么？每层能力长什么样？以及——它做不到什么。

---

一、Agent 不是"更聪明的模型"

最常见的误解：

“Agent 就是让 AI 自己调用自己，套娃而已。”

不对。Agent 是一个三层的架构：

┌──────────────────────────────────────┐
│             Agent 架构                │
│                                      │
│  ① 模型 (Model) — 大脑               │
│     └ 负责推理、规划、判断            │
│                                      │
│  ② 工具 (Tools) — 手脚               │
│     └ 读文件、写代码、执行命令、       │
│       调 API、搜网络、操作数据库       │
│                                      │
│  ③ 协议 (Protocol) — 神经系统        │
│     └ 模型 → 工具的标准接口           │
│       （MCP: JSON-RPC 2.0）          │
└──────────────────────────────────────┘

没有工具的模型 = 一个被困在笼子里的天才。 它什么都知道，但什么都碰不到。

Agent = 模型 + 工具 + 协议。 缺任何一个都不成立。

---

二、Agent 的 7 层能力金字塔

基于我们三个月里用 Claude Code + 本地 Qwen3-8B + 云端 DeepSeek 的实际项目经验，我总结了一个 Agent 能力金字塔：

                    ┌──────────┐
                    │ ⑦ 连    │  连接外部世界
                   ┌┴──────────┴┐
                   │ ⑥ 规      │  任务规划与拆解
                  ┌┴────────────┴┐
                  │ ⑤ 循        │  试错循环
                 ┌┴──────────────┴┐
                 │ ④ 修          │  修改系统
                ┌┴────────────────┴┐
                │ ③ 诊            │  诊断分析
               ┌┴──────────────────┴┐
               │ ② 试              │  动手验证
              ┌┴────────────────────┴┐
              │ ① 读                │  读取状态
              └──────────────────────┘

下面逐层解释，每层都用一个我们项目里的真实案例来说明。

---

第①层：读 (Read) — 读取系统状态

Agent 能做什么： 读文件、查系统状态、看日志、检查版本号。

普通 LLM 不能做什么： 它不知道你的电脑里装了什么、日志写了什么、配置文件设了什么。

真实案例：

Qwen3 本地部署时 segfault。

Agent 做了:
  cat /var/log/ollama.log     → "NVIDIA driver too old"
  nvidia-smi                  → 驱动版本 535
  ls /proc/driver/nvidia/     → 确认 GPU 信息
  python3 --version           → Python 3.8

人只需要说一句"模型崩溃了"，Agent 自己把 4 份信息读齐了。

关键区别： 裸模型（比如你在网页上问 GPT）只能根据训练数据"猜"你的系统状态。Agent 可以去读——0% 猜测，100% 事实。

---

第②层：试 (Execute) — 动手验证假设

Agent 能做什么： 运行命令、执行代码、调 API、测试网络。

真实案例：

问题：Python 请求 Ollama 超时。

Agent 的诊断过程：
  ① curl localhost:11434          → 通 ✅ （排除 Ollama 问题）
  ② curl GitHub                   → 通 ✅ （排除网络问题）
  ③ python3 -c "requests.post()"  → 超时 ❌ （定位到 Python）
  ④ python3 --version             → 3.8（找到根因）

结论：Python 3.8 的 http.client 实现有已知 timeout 问题
解决：用 pyenv 升级到 3.11

人在这个过程中只需要说一句话"帮我看看为什么 Python 请求超时了"。Agent 自动执行了 4 个测试步骤，每个步骤都在验证一个假设。

这就是"动手"的力量。 裸模型只能推理，Agent 能实验。

---

第③层：诊 (Diagnose) — 多步诊断链

这是最具实用价值的一层。它把 ① 读 + ② 试 组合为诊断闭环：

③ 诊 = ① 读 + ② 试 + 因果关系推理

真实案例：Segfault 完整诊断链

步骤1: 读 (Read)
  Agent 看到: ollama serve 启动后 segfault
  读日志: "NVIDIA driver too old"

步骤2: 查 (Research)
  Agent 查 Ollama 文档: v0.30.11 要求 CUDA 12 → 驱动 ≥ 550

步骤3: 试 (Execute)
  nvidia-smi: 当前驱动 535 → 确实低于 550

步骤4: 关联 (Diagnose)
  因果链: segfault → Ollama 无法调用 GPU → CUDA 12 需要新驱动
          → 驱动 535 < 550 → 升级到 570

步骤5: 方案 (Plan)
  给出 3 种方案（A: apt 升级 / B: 手动安装 / C: 降级 Ollama）
  推荐 A，但提示如果 A 不行走 B

裸模型会怎么做？ 你问它"为什么 segfault"，它能说出"可能跟驱动有关"——但它不知道你当前是 535 还是 570。这就是诊的能力差距。

---

第④层：修 (Modify) — 修改系统

Agent 能做什么： 改配置文件、安装软件包、修改代码、升级版本。

真实案例清单（全都来自本项目）：

操作	命令	风险等级
升级 NVIDIA 驱动	apt install nvidia-driver-570	⚠️ 需要 sudo
安装 pyenv + Python 3.11	git clone pyenv && pyenv install 3.11	✅ 安全
修改 Flask 配置	sed -i 's/127.0.0.1/0.0.0.0/' app.py	✅ 安全
修改 Modelfile 参数	num_predict -1	✅ 安全
安装 Python 依赖	pip install requests flask	✅ 安全
启动/停止服务	pkill ollama && ollama serve &	✅ 可控

关键区别： 裸模型只能"告诉你怎么修"（你自己动手）。Agent 能直接修（你只需要确认授权）。

---

第⑤层：循 (Iterate) — 试错循环

软件开发的常态：第一次通常不对。

Agent 的迭代能力表现在：

① 执行命令 → ② 观察结果 → ③ 判断对错 → ④ 修正 → 回到①

具体例子：
  apt install nvidia-driver-570 → 需要先卸载 535
  apt purge nvidia-driver-535 → 卸载成功
  apt install nvidia-driver-570 → 安装成功
  reboot → 重启
  nvidia-smi → 确认 570 ✅
  ollama serve → segfault 消失 ✅

一次循环不够就再来一次。人只需要在关键决策点（“卸载旧驱动？”“重启？”）确认一下。

这是 Agent 区别于普通脚本的地方：脚本按固定流程走，Agent 根据结果自适应调整流程。

---

第⑥层：规 (Plan) — 任务规划与拆解

这是我们上一篇博客的核心主题——但上一篇是从"人"的角度写，这一层是从"Agent 自动做"的角度。

Agent 怎么自动拆解？

用户: "写一个 Flash Attention 的 PyTorch 实现"

Agent 判断: 这个问题太复杂，包含概念+框架+算法+验证
           一次性丢给模型 → 大概率出错（我们在实验中已验证）

Agent 自动拆解:
  第①问: 核心概念解释（限定200字）
  第②问: 分块循环框架（不要softmax）
  第③问: online softmax 合并（独立demo）
  第④问: 整合+对比验证
  验证: 检查第④问输出是否用了 rescaling → 没通过则标注警告

注意这个过程有几个关键点：

• Agent（而不是人） 做了任务拆解的决策
• Agent 为每个子问题设计了精确的 prompt（限定范围、格式、长度）
• Agent 验证了中间结果（第④问的代码没有用 rescaling→标记警告）
• Agent 把 4 个结果组装成最终输出

这就是"规"层的能力。 不是把问题转发出去，而是先想"这个问题该怎么吃"。

---

第⑦层：连 (Connect) — 连接外部世界

最高一层，也是最隐蔽的一层。

Agent 能连接什么：

         ┌──── MCP 工具 ──── 自定义功能
         │
Agent ───┼──── 其他 LLM ──── Qwen3、本地模型
         │
         ├──── 外部 API ──── GitHub、搜索引擎
         │
         ├──── 文件系统 ──── 读/写/修改文件
         │
         └──── 执行环境 ──── Shell、代码解释器

真实案例：MCP 协议让 Claude Code 调用本地 Qwen3

# MCP Server (qwen3_mcp.py) - 不到 100 行
if method == "tools/list":
    return {"tools": [{"name": "ask_qwen3", ...}]}

if method == "tools/call" and name == "ask_qwen3":
    # 转发到本地 Ollama
    resp = requests.post("http://localhost:11434/api/chat", json={...})
    return resp.json()

这个 MCP 服务器只有 100 行代码，但它做的事情意义重大：它让一个云端 Agent (Claude) 能调用本地模型 (Qwen3)，而且通过标准化协议，任何支持 MCP 的客户端都能复用。

MCP 协议就是 Agent 的"USB-C 接口"——
任何设备只要插上就能通信，不用为每种外设定制线缆。

---

三、这 7 层不是玄学，是从项目里长出来的

上面 7 层的每一层，都对应着我们在 Qwen3 本地部署项目中经历的实打实的问题：

能力层	真实问题	如果没有 Agent
① 读	日志显示 segfault、Python 3.8	你要手动 cat、手动 nvidia-smi
② 试	curl 通但 Python 不通	你要自己一步步试
③ 诊	驱动 535 < 550 → segfault	你要自己关联因果关系
④ 修	改 Modelfile、装 Python 3.11	你要自己敲命令
⑤ 循	apt install 失败 → purge → 重装	你要自己记步骤
⑥ 规	Flash Attention 拆 4 步	你要自己想拆分方案
⑦ 连	Claude Code 调本地 Qwen3	你要自己写中转代码

没有 Agent，这些事都能做——但每一件都是你自己动手。有了 Agent，你只需要说一句"帮我搞定"，它在后台完成了上面 7 层的工作。

---

四、Agent 的边界：它做不到什么

诚实地说清楚。

1. Agent 不能超越模型的推理能力

如果底层的模型（比如 8B 量化模型）本身理解不了某些概念，Agent 拆得再细也没用。Agent 放大了模型的能力，但不能创造能力。

2. Agent 的工具受限于接口

只能读文件？那就不能改。只能执行命令？那就不能调 GUI。Agent 的能力上限 = 可用工具的总和。

3. 复杂规划需要好的底层模型

任务拆解（第⑥层）本身需要模型有较强的规划能力。B 级模型的拆解方案可能不如 A 级模型拆得好——但它拆了总比不拆强。

4. 迭代会消耗更多时间和 token

一次性提问:  1 次 LLM 调用 → 可能出错 ❌
Agent 拆解: 5 次 LLM 调用 → 大概率正确 ✅
              ↑ 成本换质量，需要在具体场景里权衡

---

五、理解这 7 层，有什么用？

对开发者来说，这 7 层框架最大的价值是：你知道该让 Agent 帮你做什么事。

如果你想让 Agent…	主要用到的层	成功率
排查一个系统错误	①②③	⭐⭐⭐⭐⭐
修一个 bug	①②③④⑤	⭐⭐⭐⭐
写一个复杂功能	⑥⑦	⭐⭐⭐
做知识问答	无（直接问模型即可）	⭐⭐⭐
多步自动化流程	①②③④⑤⑥⑦	⭐⭐⭐⭐

经验法则： Agent 最适合"需要动手的、多步骤的、需要验证的"任务。最不适合"一次性知识问答"——那个直接问模型就够了。

---

六、总结

回到开头的问题：为什么同一个模型，在 Agent 里和网页对话框里表现截然不同？

网页对话框里的模型 = 只有大脑
  → 能想、能说，但不能做

Agent 里的模型 = 大脑 + 手脚 + 神经
  → 能想、能说、还能读、试、诊、修、循、规、连

Agent 不是更聪明的模型——Agent 是长了手脚的模型。

这 7 层能力——读、试、诊、修、循、规、连——每一层都是 Agent 比裸模型多出来的实用价值。理解它们，你就知道了什么时候该用 Agent，什么时候直接问模型就够了。

---

附：本文所有案例均来自我们完成的 Qwen3-8B 本地部署项目。系列前两篇见：

1. [从零到一：用 AI Agent 辅助在 6GB 显卡上本地部署大模型实战] — 部署全流程
2. [只有 B 级模型，怎么干出 A 级的活？] — 任务拆解方法论