一页讲透现代 AI Agent 的
完整拼图

🗺 先看学习地图：这些概念是怎么一步步长出来的

🤔 出发点：再聪明的大脑，也只是个"文字接龙机"

大语言模型（LLM）的本质是：读入一段文字（上下文），预测下一段文字（输出）。它没有时钟、没有网络、没有文件系统、没有记忆——它连"今天是几号"都不知道。它是一个被关在玻璃房里的天才：博览群书、推理惊人，但看不到外面、也摸不着外面。

下面这个对比实验，直观感受一下"裸模型"和"带工具的模型"的差距（点击问题按钮，两边同时开跑）：

三个问题，三种典型的"玻璃房困境"：拿不到实时信息（时间）、算不准确定性计算（大数乘法会"一本正经地胡说"）、够不着你的环境（本地文件）。而右边的模型并没有变聪明——它只是获得了"申请让别人替它做事"的能力。这就是接下来五章的全部主线。

🧩 五块拼图，各管什么

主线之外还有两站加餐：第 6 章 · Agent 主流架构与 Multi-Agent（单个循环如何组合成系统：Workflow vs Agent、六种架构图鉴、多智能体的甜区与陷阱），以及 第 7 章 · Skill 分层能力手册（把可复用流程做成渐进披露的能力包），再加 第 8 章 · 2026 前沿概念雷达（J-Space、世界模型、A2A、Skills、Vibe Coding……把热词放回正确位置）。

Tool use / Function calling · 现代 Agent 的最小机制单元

⚙️ 机制拆解：一次工具调用的完整往返

以"上海明天天气怎么样？"为例，一次完整往返共 5 步。点击下方步骤逐帧看，注意每一步"谁在动"：

{
  "model": "gpt-5.2",
  "messages": [
    { "role": "user", "content": "上海明天天气怎么样？" }
  ],
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "查询指定城市指定日期的天气预报",
      "parameters": {
        "type": "object",
        "properties": {
          "city": { "type": "string", "description": "城市名，如：上海" },
          "date": { "type": "string", "description": "日期 YYYY-MM-DD" }
        },
        "required": ["city"]
      }
    }
  }]
}

{
  "role": "assistant",
  "content": null,
  "tool_calls": [{
    "id": "call_a1b2c3",
    "type": "function",
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"上海\", \"date\": \"2026-07-09\"}"
    }
  }]
}

# 模型只是"申请"，执行权在你手里
call = response.tool_calls[0]
args = json.loads(call.function.arguments)

if call.function.name == "get_weather":
    result = weather_api.forecast(args["city"], args.get("date"))
    # result = {"temp": "26~31°C", "condition": "多云转小雨", "rain": "62%"}

{
  "role": "tool",
  "tool_call_id": "call_a1b2c3",
  "content": "{\"temp\": \"26~31°C\", \"condition\": \"多云转小雨\", \"rain\": \"62%\"}"
}

{
  "role": "assistant",
  "content": "上海明天多云转小雨，气温 26~31°C，降水概率 62%，出门建议带伞 ☂️"
}

🎯 四个关键认知（面试/实战都会考）

🎮 小游戏：你来当一次模型

用户说："下周三我要去北京出差，帮我看下那天的天气，顺便告诉我现在几点。" 你手里的工具菜单是 get_weather(city, date) 和 get_time(timezone)。作为模型，这一轮你应该输出什么？

{
  "type": "function",
  "function": {
    "name": "get_weather",
    "description": "查询城市天气预报",
    "parameters": { "type": "object", "properties": { "...": "..." } }
  }
}

{
  "name": "get_weather",
  "description": "查询城市天气预报",
  "input_schema": { "type": "object", "properties": { "...": "..." } }
}

📚 本章延伸

Reason + Act · 2022 年的一篇论文，定义了此后所有 Agent 的元模式

2022 年 10 月，普林斯顿大学与 Google Brain 的研究者（姚顺雨等）发表论文 《ReAct: Synergizing Reasoning and Acting in Language Models》（ICLR 2023）。当时既没有 function calling，也没有 Agent 产品——但这篇论文回答了一个根本问题：

🎬 亲眼看一遍论文里的真实轨迹

下面是 ReAct 论文 Figure 1 的经典案例（内容译自原文轨迹）。问题故意很绕："除了 Apple Remote，还有什么设备能控制 Apple Remote 最初设计所服务的那个程序？"——纯 CoT 的模型会自信地答错成 "iPod"，看看 ReAct 怎么一步步逼近真相：

📜 那时候没有 function calling，Action 是怎么"调用"的？

全靠提示词约定 + 文本解析。给模型看几个 Thought / Action / Observation 格式的范例（few-shot），模型就会模仿着输出；程序再用正则把 Action: search[...] 抠出来去执行：

PROMPT = """请交替使用 Thought / Action / Observation 解决问题。
可用动作: search[词条], lookup[关键词], finish[答案]

问题: {question}
Thought 1:"""

text = llm(PROMPT)                       # 模型继续"接龙"
m = re.search(r"Action \d+: (\w+)\[(.+?)\]", text)
action, arg = m.group(1), m.group(2)     # 用正则解析出"申请单"
obs = wikipedia_search(arg)              # 程序执行，把结果拼回提示词
PROMPT += text + f"\nObservation: {obs}\nThought:"   # 循环往复

对比一下就能看清进化脉络：ReAct 用脆弱的文本约定实现的事，Function Calling 用训练进模型的结构化输出把它变成了稳定机制。格式变了，"想 → 做 → 看"的骨架一点没变。

📚 本章延伸

把工具往返装进 while 循环，Agent 就诞生了；让循环稳定产出，是一门新工程学

Simon Willison 给过一个被业界广泛引用的极简定义："LLM Agent 就是在循环里运行工具以达成目标的东西"（An LLM agent runs tools in a loop to achieve a goal）。先看这个循环本体——它可能是当代软件业"含金量最高的 15 行代码"：

def agent(task: str) -> str:
    context = [system_prompt, user(task)]     # 上下文从任务开始
    while True:                               # ← Agent 的全部秘密
        reply = llm(context, tools=TOOLS)     # 1. 模型思考
        context.append(reply)
        if not reply.tool_calls:              # 2. 不再开单 = 任务完成
            return reply.text                 #    ← 自然停止条件
        for call in reply.tool_calls:         # 3. 执行每张"申请单"
            result = execute(call)            #    （读文件/跑命令/查库…）
            context.append(tool_result(call.id, result))  # 4. 结果写回
        # 回到循环顶部，模型带着新观察继续想 —— 这就是 ReAct 的现代形态

对照上一章：Thought 就是 llm() 的思考，Action 就是 tool_calls，Observation 就是 tool_result。ReAct 是思想，Function Calling 是机制，这个 while 循环是运行时——三章在这里合流了。

🎬 看循环跑一个真实任务

点击"运行"，看 Agent 如何用 4 轮循环修好一个失败的测试。注意右侧三件事：轮数在涨、上下文在膨胀、直到停止条件触发：

刚才那次运行里藏着三个值得咀嚼的细节：第 2 轮的修改在第 3 轮复测时仍有用例失败（漏了一个边界条件），但失败信息作为 Observation 喂回去后，第 4 轮就修对了——失败不可怕，失败的信息回得去才是关键；停止不是谁喊停，而是模型不再开单；上下文一直在涨，真实任务里它会涨到需要"压缩"的程度。

🏗 Loop Engineering：从"盯着循环"到"设计循环"

循环本体 15 行，但让它稳定地产出正确结果需要一整套工程。2026 年 6 月前后，这套实践被 Google 工程师 Addy Osmani 等人正式命名为 Loop Engineering（循环工程）。它的来历很能说明问题——Claude Code 负责人 Boris Cherny 说："我已经不直接提示模型了，我的工作是写循环（My job is to write loops）"；Peter Steinberger 说得更直白："你不该再一句句提示 Agent，而该去设计提示 Agent 的循环"。

先分清两层"循环"，很多文章混着说：

一层套一层的完整谱系（每层包住前一层，而不是取代）：

🧰 设计一个好循环的六个抓手

📚 本章延伸

Model Context Protocol · 让"能力"以标准方式插进任何 Agent

🤯 它解决什么痛：M × N 的集成爆炸

没有标准时：3 个 AI 应用要接 4 个系统（GitHub、数据库、Slack、文件系统），就得写 3 × 4 = 12 套各不相同的胶水代码。有了统一协议：应用实现一次客户端、系统实现一次服务端，3 + 4 = 7 份标准实现，互相即插即用。点开关直观感受一下：

2024 年 11 月 25 日 Anthropic 开源了 MCP；不到一年，OpenAI、Google、Microsoft 相继采纳；2025 年 12 月它被捐给 Linux Foundation 旗下新成立的 Agentic AI Foundation，正式成为中立的行业标准——生态里已有超过 1 万个公开 MCP Server。"AI 应用的 USB-C"从比喻变成了现实。

🏛 三个角色：Host / Client / Server

点击图中任何一个部件，看它的职责说明：

🧱 Server 提供的三种原语：谁做主是精髓

MCP 不只是"工具的搬运工"。Server 能暴露三类东西，官方设计的精髓在于每类东西由谁做主：

反向也有原语：Server 可以向 Client 请求 LLM 补全（Sampling）、向用户追问输入（Elicitation）。了解即可——注意 2026-07-28 新版规范已将 Sampling、Roots、Logging 标记为废弃（deprecated）。

📡 底层长什么样：一次完整的连接与调用

MCP 底层是 JSON-RPC 2.0 消息，跑在两种标准传输上：stdio（本地子进程，走标准输入输出）或 Streamable HTTP（远程服务）。点击播放，看 Cursor 连接一个天气 Server 的完整过程：

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
  "protocolVersion":"2025-11-25",
  "clientInfo":{"name":"cursor","version":"2.x"},
  "capabilities":{}}}

{"jsonrpc":"2.0","id":1,"result":{
  "protocolVersion":"2025-11-25",
  "serverInfo":{"name":"weather-mcp","version":"1.0.0"},
  "capabilities":{"tools":{}}}}

{"jsonrpc":"2.0","id":2,"method":"tools/list"}

{"jsonrpc":"2.0","id":2,"result":{"tools":[{
  "name":"get_weather",
  "description":"查询指定城市当前天气",
  "inputSchema":{"type":"object",
    "properties":{"city":{"type":"string"}},
    "required":["city"]}}]}}

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"get_weather",
  "arguments":{"city":"上海"}}}

{"jsonrpc":"2.0","id":3,"result":{
  "content":[{"type":"text","text":"上海：多云 29°C，湿度 78%"}],
  "isError":false}}

📅 时间线：从一家之言到行业标准

📚 本章延伸

写几个带好注释的函数，SDK 帮你把它们变成协议上的标准插件

👨‍💻 完整代码：一个天气 Server 的四种打开方式

from mcp.server.fastmcp import FastMCP

# 创建 Server，名字会在宿主的工具列表里展示
mcp = FastMCP("weather")

@mcp.tool()
def get_weather(city: str) -> str:
    """查询指定城市的当前天气。city 为中文城市名，如：上海"""
    # 演示用模拟数据；真实场景换成 HTTP 调用气象 API
    data = {"北京": "晴 32°C", "上海": "多云 29°C", "深圳": "雷阵雨 27°C"}
    return data.get(city, f"未收录城市：{city}")

@mcp.tool()
def get_air_quality(city: str) -> str:
    """查询指定城市的空气质量指数（AQI）"""
    data = {"北京": "AQI 87 良", "上海": "AQI 42 优", "深圳": "AQI 35 优"}
    return data.get(city, f"未收录城市：{city}")

if __name__ == "__main__":
    mcp.run()   # 默认 stdio 传输：宿主把它当子进程拉起来

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather", version: "1.0.0" });

// 用 zod 声明参数 Schema，SDK 自动转为 JSON Schema
server.registerTool("get_weather",
  {
    title: "天气查询",
    description: "查询指定城市的当前天气",
    inputSchema: { city: z.string().describe("中文城市名，如：上海") }
  },
  async ({ city }) => {
    const data: Record<string, string> =
      { "北京": "晴 32°C", "上海": "多云 29°C", "深圳": "雷阵雨 27°C" };
    return { content: [{ type: "text", text: data[city] ?? `未收录：${city}` }] };
  }
);

await server.connect(new StdioServerTransport());

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["run", "python", "/绝对路径/server.py"]
    }
  }
}

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["run", "python", "/绝对路径/server.py"]
    }
  }
}

🔬 上手感受：迷你 Inspector

官方提供了可视化调试器 MCP Inspector（npx @modelcontextprotocol/inspector），连上你的 Server 就能手动点工具、看原始消息。下面是一个网页版迷你复刻——连接上面那个天气 Server，亲手发一次 tools/call：

试试选"拉萨"——Server 返回"未收录城市"。注意这不是协议错误（isError 为 false），而是一条对模型友好的业务信息：真实 Agent 拿到它会换个方式继续，而不是崩溃。这正是"错误信息要可行动"的设计。

📐 把工具写好的六条军规

📚 本章延伸

单个循环是原子，架构决定原子怎么组合成分子——直到组合成一支"智能体军团"

⚖️ 先立地基：Workflow 还是 Agent？

Anthropic 在《Building Effective Agents》里给出了业界沿用至今的经典辨析——两者都是"agentic system"，但由谁决定下一步完全不同：

🎛 六种主流架构图鉴

前五种是 Workflow（路径代码定），最后一种是 Agent（路径模型定）。点左侧切换，每种都配了数据流向图和"什么时候用"：

🕸 Multi-Agent：什么时候一个大脑不够用？

把编排者-工作者里的"工作者"换成完整的 Agent（各带自己的循环、工具和上下文窗口），就得到了多智能体系统。它的价值不玄学，就三条：

但 2025 年业界发生过一场著名的"路线之争"，两篇文章至今都值得读：

🤝 MCP × A2A × Agent Card：互补，不是替代

外层 Agent
  └─ MCP knowledge_chat
       └─ 内层知识库 Agent
            └─ 内部检索、HSCode、合规等工具

推荐演进（不是替换）：
外层 Agent
  ├─ MCP：短请求、确定性工具、知识问答
  └─ A2A：长任务、异步协作、独立 Agent 委托

知识库 Agent
  └─ MCP：内部检索和业务工具

📚 本章延伸

不是超长提示词，而是节省上下文的分层执行系统

把 Skill 理解成：

• description 是路由规则——告诉 Agent“做什么、什么时候触发”；
• SKILL.md 正文 是操作手册——命中后才加载的流程与判断；
• references / scripts / assets 是第三级资源——某个分支才需要时再读、再跑、再复制。

📦 最小形态 vs 推荐结构

my-skill/
└── SKILL.md

my-skill/
├── SKILL.md
├── agents/openai.yaml
├── scripts/
├── references/
└── assets/

🚦 三级加载：如何省上下文

🧭 内容该放哪里？动手分类

先判断，再看解释。这是写好 Skill 最关键的肌肉记忆：

🗂 五种常见形态

🏭 Skill 仓库是一条生产线

单个 Skill 是能力模块；Skill 仓库是可组合的工作系统。典型工程生产线：

📚 本章延伸

推特时间线上最火的热词，逐个放回技术栈的正确位置

下面 12 张卡片覆盖了近期（截至 2026-07-08）讨论度最高的概念。点分类筛选，点卡片展开细节——每张卡都标注了它与本页主线的关系，方便你"挂"到已有的知识树上：

📚 本章延伸

把五块拼图合成一张图，再用一套综合题验证你真的懂了

🗺 一张图看懂全部关系

当你在 Cursor 里说"帮我查下上海天气然后写进 README"，发生的完整链路：

🔑 五个概念的一句话定位（背下来就能给别人讲）

🎓 通关综合测验

五道综合题，考察的是概念之间的关系而非孤立定义——这才是真懂的标志：

🛤 接下来动手：真实 Demo 实践路线图

知识只有过手才算数。按顺序做，每完成一项点一下（进度会保存）：

📖 延伸书架