RussellLuo

当我们与 ChatGPT 对话，或让 Agent 完成任务时，背后发挥核心作用的都是 LLM（大语言模型）。文本生成是 LLM 最基础的能力，也是理解其工作原理的起点。

本文以 GPT-2（Small） 为例，先从文本续写的整体过程入手，再解释自回归生成（Autoregressive generation）和单次预测，最后用 llama.cpp 进行验证。

文本续写

就功能而言，可以把 LLM 看作一个文本续写系统：输入 How are，输出 you doing?。从外部看，整个续写过程像是一次完成的。

自回归生成

实际上，you doing? 由多个 Token 依次生成。Token 是模型处理文本的基本单位，通常对应一个文本片段。每轮根据已有的 Token 序列预测下一个 Token，再将它追加到序列中，进入下一轮，直到满足停止条件。

需要注意，" you" 和 " doing" 的前导空格也是 Token 的一部分，因此 Token 并不等同于单词。

一次 Token 预测

以 GPT-2 第一次预测 " you" 为例，一次 Token 预测可以分为分词（Tokenize）、GPT-2 计算、采样（Sampling）和反分词（Detokenize）四个步骤：

分词

分词将 How are 划分为两个 Token，并将它们映射为词表（Vocabulary）中的整数编号，也就是 Token ID：

1
2

"How"  → 2437
" are" → 389

因此，模型接收的 Token ID 序列是 [2437, 389]。这些整数后续还要转换为向量才能参与计算。

GPT-2

GPT-2 接收 Token ID 序列，输出 50257 个 logits（原始预测分数）。每个 logit 对应词表中的一个 Token，表示它作为下一个 Token 的原始评分。

得到 logits 后，GPT-2 的前向计算（Forward Pass）就结束了。接下来由推理框架根据这些评分进行采样，选出下一个 Token ID。

采样

采样根据 logits 选择下一个 Token ID，可以通过 Temperature（温度）、Top-k 和 Top-p 等参数控制选择结果。本例将 Temperature 设为 0，以确定性方式选中 Token ID 345。

即使 logits 相同，不同的采样参数也可能选出不同的 Token。因此，模型计算和 Token 选择是两个不同阶段。

反分词

反分词是分词的逆向转换：Token ID 345 根据同一份词表还原为文本片段 " you"。

说明：
生成的文本片段用于显示，Token ID 则直接追加到已有序列：[2437, 389] + 345 → [2437, 389, 345]。GPT-2 基于新序列继续预测，无须重新分词；不断重复这一过程，就形成了自回归生成。

llama.cpp 实战

下面用 llama.cpp 实际观察分词结果、候选分数与采样结果，以及最终的续写结果。

GPT-2 与 llama.cpp 在这一过程中承担不同职责：

• GPT-2：包含模型结构和训练得到的参数，将 Token ID 序列转换为 logits。
• llama.cpp：加载 GGUF 中的模型与 Tokenizer（分词器）的相关信息，构建并执行计算图（Computation Graph），完成采样和文本输出。

环境准备

下面的实验基于 llama.cpp（版本标签：b10435），需要预先安装 Git、CMake、cURL 和 C/C++ 编译器。

克隆代码并构建 llama-completion 和 llama-server：

1
2
3
4
5
6
7
8

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10435

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release
cmake --build build \
  --target llama-completion llama-server \
  --config Release -j

接着从 QuantFactory/gpt2-GGUF 下载 GPT-2 Q8_0 GGUF 模型：

1
2
3
4
5
6

GPT2_MODEL=models/QuantFactory/gpt2-GGUF/gpt2.Q8_0.gguf
mkdir -p models/QuantFactory/gpt2-GGUF

curl -L --fail \
  -o "$GPT2_MODEL" \
  https://huggingface.co/QuantFactory/gpt2-GGUF/resolve/main/gpt2.Q8_0.gguf

查看分词结果

借助 llama-completion，可以查看输入文本的分词结果，包括 Token 及其对应的 ID：

1
2
3
4
5
6
7

./build/bin/llama-completion \
  -m "$GPT2_MODEL" \
  --prompt 'How are' \
  --predict 0 \
  --verbose-prompt \
  2>&1 |
  grep -E "llama_completion: (prompt:|number of tokens in prompt)| I +[0-9]+ -> '"

输出：

1
2
3
4

0.00.366.307 I llama_completion: prompt: 'How are'
0.00.366.307 I llama_completion: number of tokens in prompt = 2
0.00.366.309 I   2437 -> 'How'
0.00.366.310 I    389 -> ' are'

查看候选分数与采样结果

先在一个终端启动 llama-server：

1
2

./build/bin/llama-server \
  -m "$GPT2_MODEL"

模型加载完成后，另开一个终端，请求生成一个 Token：

1
2
3
4
5
6
7
8
9
10

curl -sS http://127.0.0.1:8080/completion \
  -H 'Content-Type: application/json' \
  -d '{
    "prompt": "How are",
    "n_predict": 1,
    "temperature": 0,
    "return_tokens": true,
    "n_probs": 3,
    "response_fields": ["content", "tokens", "completion_probabilities"]
  }'

省略响应中的 bytes 后，关键结果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "content": " you",
  "tokens": [345],
  "completion_probabilities": [
    {
      "id": 345,
      "token": " you",
      "logprob": -1.0721638,
      "top_logprobs": [
        {"id": 345, "token": " you",  "logprob": -1.0721638},
        {"id": 356, "token": " we",   "logprob": -2.1492436},
        {"id": 262, "token": " the",  "logprob": -2.3353780}
      ]
    }
  ]
}

tokens[0] 表示最终选中的 Token ID，即 345；对应的文本片段是 " you"。top_logprobs 列出了本轮预测中排名靠前的候选 Token，其中的 logprob（对数概率）由 logits 转换而来，并非 GPT-2 直接输出的原始 logits。Temperature 为 0 时，llama.cpp 会确定性地选择排名第一的 Token。

查看续写结果

最后运行 llama-completion，从 How are 开始连续生成三个 Token：

1
2
3
4
5
6

./build/bin/llama-completion \
  -m "$GPT2_MODEL" \
  --prompt 'How are' \
  --predict 3 \
  --temp 0 \
  --log-verbosity 1

续写结果：

1

How are you doing?

小结

本文以 How are → you doing? 为例，串起了 LLM 逐个生成 Token 的基本流程：

• How are 被分词为 [2437, 389]，第一次预测选中 Token ID 345（" you"），连续预测后得到 you doing?。
• 一次 Token 预测依次经过分词、GPT-2 计算、采样和反分词；新 Token ID 会追加到已有序列，形成自回归生成。
• GPT-2 负责根据 Token ID 计算 logits，llama.cpp 负责模型执行、Token 选择和文本输出。

AI 正在融入我们的生活

如果说过去的人工智能更多存在于实验室和专业领域，那么今天，AI 已经来到我们身边。从学习辅导、内容创作，到软件开发、办公协作，再到医疗、科研、自动驾驶和机器人，AI 正在进入越来越多真实场景。

AI 应用的三次跃迁

AI 的范围远不止大语言模型，还包括计算机视觉、语音识别、推荐系统、机器学习、机器人控制等多个领域。它的能力可以体现在感知、预测、生成、决策和行动等不同环节。

近年来，以大模型为重要推动力的新一轮 AI 应用浪潮正在展开：AI 先从对话工具进入工作流程，再从协作助手发展为自主执行任务的 Agent，最后与视觉、传感器、机器人和控制系统结合，进一步进入物理世界。

第一跃迁：从 Chatbot 到 Copilot

从 Chatbot 到 Copilot，关键变化是 AI 从独立的对话工具进入具体任务环境，利用任务上下文，在人的操作过程中持续提供协助。人仍主导任务目标、执行步骤和关键操作，AI 负责协作，而不是独立完成任务。

学习：从通用答疑到个性化学习助手

代表产品

• Google Gemini（Study Notebooks）
• Khanmigo

办公：从内容生成到工作助手

代表产品

• Microsoft 365 Copilot
• 飞书（智能会议纪要）

第二跃迁：从 Copilot 到 Agent

从 Copilot 到 Agent，关键变化是 AI 从协助人操作，发展为围绕目标自主拆解任务、调用工具、执行操作，并根据结果调整后续步骤。人从逐步操作任务，转向提出目标和检查结果。

软件开发：从代码建议到自主执行开发任务

代表产品

• OpenAI Codex
• Claude Code

图形界面操作：从操作指导到自主执行

代表产品

• ChatGPT / Codex（Computer Use）

第三跃迁：从数字 AI 到物理 AI

从数字 AI 到物理 AI，关键变化是 AI 不再只处理文字、代码和数据，而是能够通过传感器感知环境、做出决策，并控制车辆或机器人。物理 AI 并非由单一大模型驱动，而是大模型、专用模型、传感器、控制算法与硬件共同作用的系统。

自动驾驶：从辅助决策到自主驾驶

代表产品

• Waymo One
• 百度萝卜快跑

机器人：从固定执行到自主感知与行动

代表产品

• Figure 03
• 优必选 Walker S2

Agent 如何工作

AI Agent 不是“更会聊天的 AI”，而是一个围绕目标持续行动的智能执行系统。以 Codex 这类编程 Agent 为例，它以 LLM 为决策核心，结合上下文、状态、工具和约束，通过 Agent Loop 不断规划、执行、观察和调整，直到任务完成。

Agent = LLM + 上下文与状态 + 工具 + 执行循环 + 约束

在每轮循环中，LLM 根据当前状态决定调用工具、调整计划、请求确认或结束任务；工具返回的日志、错误和测试结果又会成为下一轮决策的依据。这种反馈闭环使 Agent 能够动态处理问题，而不是按照固定流程运行。

实际系统还会通过最大步数、成本预算、权限控制和人工确认等机制限制循环，确保 Agent 的行动安全、可控。

实战演示：坦克大战

向 Agent 提出目标：

创建一个坦克大战小游戏，试玩并修复发现的问题。

Agent 将自主完成：

规划实现 → 编写代码 → 运行游戏 → Computer Use 试玩 → 发现问题 → 修改代码 → 再次试玩和验证

这个过程展示了 Agent 如何结合代码生成与界面操作，根据实际反馈持续调整，完成从创建到验证的闭环。

大模型如何工作

软件篇

大模型生成回答，本质上是在根据已有内容预测下一个 Token。输入的文字会先被切分成 Token 并转换为向量，再经过多层 Transformer 计算。注意力机制帮助模型判断上下文中哪些信息更重要，最终为下一个 Token 的候选项计算概率。模型选出一个 Token 后，会把它加入上下文并重复这一过程，直到生成完整的回答。

模型的知识并不是以一条条记录的形式存放在内部，而是在海量文本训练中被编码进模型参数。温度和采样策略会影响模型是倾向于选择概率最高的结果，还是保留更多表达上的变化。由于它本质上是一个概率生成系统，回答流畅并不代表内容一定正确；面对冷门事实、过时信息和复杂推理，仍然需要进一步核实。

硬件篇

这些看似复杂的语言能力，落到硬件层面，主要是大规模的矩阵运算和数据搬运。GPU 拥有大量并行计算单元，能够同时执行许多结构相似的运算，因此成为大模型训练和推理的主力；Tensor Core 等专用单元则进一步提高了矩阵运算效率。不过，大模型的运行速度不仅取决于算力，也受到显存容量和带宽的制约。推理过程中，硬件需要不断读取模型参数、保存上下文缓存并传递中间结果，因此 HBM 和片上缓存同样重要。

一次推理通常分为 Prefill 和 Decode 两个阶段。Prefill 会集中处理用户输入，并为后续生成建立 KV Cache，它主要影响第一个 Token 出现前的等待时间；Decode 则利用缓存逐个生成新的 Token，主要影响回答持续输出的速度。上下文越长，KV Cache 占用的显存越多，数据搬运的成本也越高，因此长对话通常更消耗显存，生成速度也可能随之下降。

AI 时代，我们如何成长

AI 带来的问题不只是“它会不会替代人”，更重要的是我们如何使用它：是把思考外包给 AI，还是借助 AI 学习、实验和验证，在提高效率的同时保持自主性和掌握感。

需要警惕

可靠性与安全

大模型可能产生幻觉、过时信息和推理错误，Agent 的工具调用还可能把错误判断变成真实行动。把资料和系统权限交给 AI，也会带来隐私泄露、数据滥用和安全攻击等风险。因此，事实核查、结果验证、权限控制和人工确认仍然不可缺少。

生成更快不等于真正交付

AI 可以快速生成大量内容和代码，但后续的调试、验证和修正仍可能耗费大量时间。只关注生成数量，而不确认结果是否正确、问题是否解决，就容易把“看起来快”误认为“真正交付快”。

便利可能削弱人的掌握感

AI 的即时反馈可能制造一种虚假的心流：人不断提出要求、看到结果快速出现，却没有真正理解问题。随着越来越多分析和判断被交给 AI，人也可能从任务的主导者变成结果的选择者，逐渐削弱独立判断、专业能力和创造力。

如何成长

从替人工作到增强人的能力

当 AI 工具和组织更强调效率与产出时，个人更需要主动保留提出问题、理解原理、检验结果和承担判断的过程，保护自己的自主性和掌握感。

AI 不应只是替人交出答案的黑盒，也可以成为扩展思考和创造能力的工具。它能够解释概念、查找资料、比较方案并快速构建实验；人则负责确定目标、提出问题和判断结果，通过“边做边学、边问边验证”加深理解，挑战更复杂的问题。

面向未来的核心能力

未来的竞争力并不只是“会不会使用 AI”，而是能否把 AI 与自己的专业知识、判断力和创造力结合起来：

专业能力 + AI 协作能力 + 判断与创造能力

专业能力帮助我们理解问题，AI 协作能力提高学习和实践的效率，判断与创造能力则让我们能够识别错误、提出新问题，并对最终结果负责。

不要用 AI 逃避思考，而要用 AI 加深思考；不要让 AI 替你完成工作，而要让 AI 帮你掌握工作。

Skills是当前Agent领域最热门的设计范式之一，风头一时无两。这也让很多人形成了一种直觉：

只要Skill写得足够详细，Agent就能搞定复杂任务。

在简单任务中，这种想法通常没什么问题。但一旦面对长程任务（Long-horizon tasks），效果往往大打折扣，甚至根本无法完成。

那么问题就来了——当处理长程任务时，Skills应该如何设计？

长程任务为什么困难

在Agent系统中，长程任务是指那些需要持续几十分钟、数小时甚至几天时间才能完成的任务，例如：

• 自动化软件开发流程
• 深度技术调研
• 长链路业务流程执行

这类任务通常具有三个特点：

1. 步骤数量多
2. 执行时间长
3. 上下文持续增长

从LLM的角度来看，本质问题在于：

任务执行过程中产生的token会不断累积，进而导致上下文膨胀，甚至会超出LLM的上下文限制。

有了Skills为什么还需要上下文工程

针对上述问题，Anthropic在Effective context engineering for AI agents中进行了深入探讨，并从上下文工程（Context engineering）的角度出发，提出了3种解决方案：

• 压缩（Compaction）：在上下文接近上限时，通过高保真摘要压缩历史对话并重启上下文窗口，以维持长程任务的连贯性。
• Subagents（Sub-agent architectures）：将复杂任务拆分给多个拥有独立上下文的专用Subagent处理，并由主Agent进行高层规划与结果整合，从而突破上下文限制并提升复杂任务的处理能力。
• 结构化笔记（Structured note-taking）：让Agent定期将重要信息记录到上下文之外的持久存储中，并在需要时拉回，以保持跨复杂任务的关键上下文和依赖。

细心的读者可能已经注意到，上述文章发表于Skills推出之前，那么Skills是否已经解决了长程任务的问题呢？答案是否定的。

关于Skills，我们在谈谈Agent Skills的底层原理中探讨过：它的三层加载技术（亦即Progressive Disclosure），本质上是一种Context Offloading策略。但有一点需要补充的是，Progressive Disclosure的设计是为了“让通用Agent具备处理各种特定任务的能力，但无需一次性加载所有特定任务的知识”，而不是为了更好地处理某个长程任务。

因此，即使有了Skills，我们仍然需要结合上下文工程的方法来应对长程任务。对于上述3种方法，压缩需要Agent系统本身支持（Claude Code等工具已经支持）。本文主要从使用者的角度出发，探讨如何利用Subagents和结构化笔记来优化Skills的设计。

一个简化案例：开发流程Agent

假设我们希望构建一个Agent，用于自动化软件开发流程。

实际的开发流程通常会涉及众多环节，这里为了简化讨论，我们只考虑以下三个步骤：

• Issue → Code：根据Issue生成代码
• Code → Tests：为代码生成测试
• Code → Review：进行代码审查

针对这个流程，我们可以写一个“大Skill”：

1
2
3
4
5
6
7
8
9
10

---
name: dev-workflow
description: Complete development workflow for handling issues.
---

You help developers with three workflow tasks:

1. Issue to Code: Generate code from issue description.
2. Code to Tests: Generate tests for the generated code.
3. Code to Review: Perform code review on the generated code.

如果在Claude Code中使用这个Skill，执行过程中的Context大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

[System] You are Claude Code.
[User] Complete issue.md
[Tool Call] Read(.claude/skills/dev-workflow/SKILL.md)
[Tool Output] <the skill instructions>
[Tool Call] Read(issue.md)
[Tool Output] <issue description>]
[Assistant] <generated code>
[Tool Call] Write(code.py)
[Tool Output] <success>
[Assistant] <generated tests>
[Tool Call] Write(tests.py)
[Tool Output] <success>
[Tool Call] Bash(python tests.py)
[Tool Output] <test results>
[Assistant] <generated review report>
[Tool Call] Write(review.md)
[Tool Output] <success>
[Assistant] <final output>

可以看到，3个任务共享同一个LLM上下文，随着任务的推进，上下文会不断膨胀。在真实场景中，如果Issue的需求比较复杂，上下文膨胀问题会更加严重，甚至可能导致任务失败。

技巧一：使用1个主Agent和3个Subagent

利用Subagents的思路，一种策略是创建3个独立的Subagent，分别负责开发、测试和审查（参考Create custom subagents）。

开发Subagent（位于.claude/agents/code-developer.md）：

1
2
3
4
5
6

---
name: code-developer
description: Generate code from issue description.
---

You are a code developer. Your task is to generate code based on the provided issue description.

测试Subagent（位于.claude/agents/code-tester.md）：

1
2
3
4
5
6

---
name: code-tester
description: Generate tests for the provided code.
---

You are a code tester. Your task is to generate tests for the provided code.

审查Subagent（位于.claude/agents/code-reviewer.md）：

1
2
3
4
5
6

---
name: code-reviewer
description: Perform code review on the provided code.
---

You are a code reviewer. Your task is to perform code review on the provided code.

有了这3个Subagent之后，我们再创建一个Skill（位于.claude/skills/effective-dev-workflow/SKILL.md），指导主Agent调用这3个Subagent：

1
2
3
4
5
6
7
8
9
10
11
12

---
name: effective-dev-workflow
description: Complete development workflow for handling issues.
---

You are a project manager. Your task is to manage the development workflow for handling issues.

Here are the steps you need to follow:

1. Issue to Code: Use the `code-developer` agent to generate code from the issue description.
2. Code to Tests: Use the `code-tester` agent to generate tests for the generated code.
3. Code to Review: Use the `code-reviewer` agent to perform code review on the generated code.

同样地，我们可以在Claude Code中使用这个Skill，但执行过程中会产生4个独立的Context。

主Agent的Context：

1
2
3
4
5
6
7
8
9
10
11
12
13

[System] You are Claude Code.
[User] Complete issue.md
[Tool Call] Read(.claude/skills/effective-dev-workflow/SKILL.md)
[Tool Output] <the skill instructions>
[Tool Call] Read(issue.md)
[Tool Output] <issue description>
[Tool Call] Task(code-developer, "Generate code and save it as code.py")
[Tool Output] <final output from code-developer>
[Tool Call] Task(code-tester, "Generate tests for the code in code.py and save them as tests.py")
[Tool Output] <final output from code-tester>
[Tool Call] Task(code-reviewer, "Perform code review on the code in code.py and save the report as review.md")
[Tool Output] <final output from code-reviewer>
[Assistant] <final conclusion>

开发Subagent的Context：

1
2
3
4
5
6

[System] You are Claude Code.\nYou are a code developer...
[User] Generate code and save it as code.py
[Assistant] <generated code>
[Tool Call] Write(code.py)
[Tool Output] <success>
[Assistant] <final output>

测试Subagent的Context：

1
2
3
4
5
6
7
8
9
10

[System] You are Claude Code.\nYou are a code tester...
[User] Generate tests for the code in code.py and save them as tests.py
[Tool Call] Read(code.py)
[Tool Output] <code content>
[Assistant] <generated tests>
[Tool Call] Write(tests.py)
[Tool Output] <success>
[Tool Call] Bash(python tests.py)
[Tool Output] <test results>
[Assistant] <final output>

审查Subagent的Context：

1
2
3
4
5
6
7
8

[System] You are Claude Code.\nYou are a code reviewer...
[User] Perform code review on the code in code.py and save the report as review.md
[Tool Call] Read(code.py)
[Tool Output] <code content>
[Assistant] <generated review report>
[Tool Call] Write(review.md)
[Tool Output] <success>
[Assistant] <final output>

由上可见：

• 主Agent只关注高层次的任务调度，每个Subagent只返回关键结果，大大减少了主Agent的上下文负担。
• 同时，每个Subagent也都有自己独立的上下文，不会相互干扰，从而有效避免了上下文膨胀的问题。

技巧二：使用3个独立的Skill

利用结构化笔记的思路，我们也可以创建3个独立的Skill，分别负责开发、测试和审查。

开发Skill（位于.claude/skills/code-developer/SKILL.md）：

1
2
3
4
5
6
7
8
9
10

---
name: code-developer
description: Generate code from issue description.
---

You are a code developer. Your task is to generate code based on the provided issue description.

There is a {project_root}/NOTES.md file that records the progress of the task:
- Please review this file before starting the task.
- After completing the task, record the key progress in this file.

测试Skill（位于.claude/skills/code-tester/SKILL.md）：

1
2
3
4
5
6
7
8
9
10

---
name: code-tester
description: Generate tests for the provided code.
---

You are a code tester. Your task is to generate tests for the provided code.

There is a {project_root}/NOTES.md file that records the progress of the task:
- Please review this file before starting the task.
- After completing the task, record the key progress in this file.

审查Skill（位于.claude/skills/code-reviewer/SKILL.md）：

1
2
3
4
5
6
7
8
9
10

---
name: code-reviewer
description: Perform code review on the provided code.
---

You are a code reviewer. Your task is to perform code review on the provided code.

There is a {project_root}/NOTES.md file that records the progress of the task:
- Please review this file before starting the task.
- After completing the task, record the key progress in this file.

然后，我们在3个不同的会话里分别调用这3个Skill，从而会产生3个独立的Context。

开发Skill的Context：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[System] You are Claude Code.
[User] Complete issue.md
[Tool Call] Read(.claude/skills/code-developer/SKILL.md)
[Tool Output] <the skill instructions>
[Tool Call] Read(issue.md)
[Tool Output] <issue description>
[Tool Call] Read(NOTES.md)
[Tool Output] <notes content>
[Assistant] <generated code>
[Tool Call] Write(code.py)
[Tool Output] <success>
[Tool Call] Write(NOTES.md, "# Task Progress\n## Completed Tasks\n### 2026-03-08: Generated code and created code.py")
[Tool Output] <success>
[Assistant] <final output>

此时，NOTES.md的内容如下：

1 2 3

# Task Progress ## Completed Tasks ### 2026-03-08: Generated code and created code.py

测试Skill的Context：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

[System] You are Claude Code.
[User] Generate tests for code.py
[Tool Call] Read(.claude/skills/code-tester/SKILL.md)
[Tool Output] <the skill instructions>
[Tool Call] Read(code.py)
[Tool Output] <code content>
[Tool Call] Read(NOTES.md)
[Tool Output] <notes content>
[Assistant] <generated tests>
[Tool Call] Write(tests.py)
[Tool Output] <success>
[Tool Call] Bash(python tests.py)
[Tool Output] <test results>
[Tool Call] Edit(NOTES.md, "\n### 2026-03-08: Generated tests and created tests.py")
[Tool Output] <success>
[Assistant] <final output>

此时，NOTES.md的内容如下：

1 2 3 4

# Task Progress ## Completed Tasks ### 2026-03-08: Generated code and created code.py ### 2026-03-08: Generated tests and created tests.py

审查Skill的Context：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[System] You are Claude Code.
[User] Perform code review on code.py
[Tool Call] Read(.claude/skills/code-reviewer/SKILL.md)
[Tool Output] <the skill instructions>
[Tool Call] Read(code.py)
[Tool Output] <code content>
[Tool Call] Read(NOTES.md)
[Tool Output] <notes content>
[Assistant] <generated review report>
[Tool Call] Write(review.md)
[Tool Output] <success>
[Tool Call] Edit(NOTES.md, "\n### 2026-03-08: Performed code review and created review.md")
[Tool Output] <success>
[Assistant] <final output>

此时，NOTES.md的内容如下：

1 2 3 4 5

# Task Progress ## Completed Tasks ### 2026-03-08: Generated code and created code.py ### 2026-03-08: Generated tests and created tests.py ### 2026-03-08: Performed code review and created review.md

由上可见：

• 因为每个Skill都在不同的会话中被调用，所以它们之间不会共享上下文，从而避免了上下文膨胀的问题。
• 每个Skill都通过NOTES.md文件来读取和记录关键进度，从而实现了跨Skill（跨会话）的信息传递，保证了整体任务的连贯性。

值得说明的是，这个技巧的本质是基于独立会话的多Agent协作。这里不同的Skill，实际上只是给每个Agent添加了不同的知识，使其能够执行特定的任务。

关于多Agent协作完成复杂任务的更多内容，Anthropic在另一篇文章Effective harnesses for long-running agents作了详细介绍，感兴趣的读者可以进一步阅读。

结语

Skills是一种强大的能力封装方式，但面对长程任务时，它并不是解决一切问题的银弹——LLM的上下文限制始终是绕不过去的瓶颈。

更实用的思路是将Skills与上下文工程结合起来：

• 通过Subagents拆分上下文，让不同角色各自处理独立子任务；
• 通过结构化笔记在上下文之外保存关键状态，实现跨会话的信息传递。

Skills负责告诉Agent“怎么做”，上下文工程决定Agent“能走多远”。两者结合，才是应对长程任务的完整答案。

大家好！今天给大家介绍cMCP v0.4.0的重要更新。

cMCP是什么？

cMCP是一个MCP服务器的命令行工具，可以理解为“MCP版的curl” —— 通过命令行就能快速调用和测试MCP服务器的功能。

基本用法：

1
2
3
4
5

# STDIO transport
cmcp 'python server.py' tools/list

# HTTP transport
cmcp http://localhost:8000/mcp tools/call name=add arguments:='{"a": 1, "b": 2}'

v0.4.0新特性：mcp.json配置支持

为什么引入mcp.json配置文件？

1. 简化命令输入：以前每次调用都要输入完整的命令或URL以及各种配置参数，比较繁琐。
2. 拥抱生态标准：MCP生态逐渐形成了MCP JSON配置标准，主流工具如Cursor、Claude Code都在使用。

有了配置文件，就可以统一管理所有MCP服务器了！

创建配置文件 .cmcp/mcp.json（或 ~/.cmcp/mcp.json）：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "mcpServers": {
    "local-server": {
      "command": "python",
      "args": ["server.py"],
      "env": {"API_KEY": "your-key"}
    },
    "remote-server": {
      "url": "http://localhost:3000/mcp",
      "headers": {"Authorization": "Bearer token"}
    }
  }
}

使用起来超级简单：

1
2
3
4
5

# 列出工具
cmcp :local-server tools/list

# 调用工具
cmcp :remote-server tools/call name=add arguments:='{"a": 1, "b": 2}'

只需要用 :server-name 就能引用预定义的服务器（及配置参数），大大提升效率！

兼容性

mcp.json配置格式与Cursor、Claude Code完全兼容，可以直接复用现有配置：

1
2
3
4
5

# 使用 Cursor 的配置
cmcp --config .cursor/mcp.json :my-server tools/list

# 使用 Claude Code 的配置
cmcp --config .mcp.json :my-server tools/list

快速开始

安装：

1

pip install cmcp

项目地址：https://github.com/RussellLuo/cmcp

欢迎大家体验 cMCP v0.4.0 的新功能！如果有任何问题或建议，欢迎在GitHub仓库中提出。

从ChatGPT的横空出世，到OpenClaw的一夜爆火，AI技术的发展可谓日新月异。如果说LLM是最强大脑，那么赋予它手和脚，使其从对话框中走出来的，正是Function Calling。

Function Calling（函数调用）有时也称为Tool Use（工具使用）。按照OpenAI的官方定义，Function Calling为LLM提供了一种强大且灵活的方式，使其能够与外部系统交互并获取训练数据之外的信息。

要理解Function Calling的真正价值，我们需要先来了解其背后的应用场景。

应用场景

现实生活中，我们常常需要与各种系统和服务进行交互，以获取所需的信息或完成特定的任务。例如，查询天气、预订机票、支付账单、控制智能家居设备等。

以天气查询为例：

What is the weather like in Chengdu?

为了处理这个任务，AI系统通常需要执行以下操作：

1. 理解用户的自然语言输入，并将其转化为结构化的指令或意图（这里的意图是“查询天气”，参数是“成都”）。
2. 根据指令调用相应的API或服务，得到结果（这里的结果可能包括温度、湿度等）。
3. 将结果加以整理和格式化，再以自然语言的形式返回给用户（例如，“今天成都的气温是22度，湿度为60%”）。

由此可见，这类AI系统的本质在于：

自然语言 → 结构化语义 → 触发系统动作

其中，从自然语言到结构化语义的转换，是整个流程的核心。

NLU

在LLM出现之前，这类任务通常由传统的自然语言理解（Natural Language Understanding, NLU）来完成。作为NLP的一个子集，NLU技术主要包括意图识别（Intent Recognition）和槽位填充（Slot Filling）两个子任务。

上述天气查询的例子，经过NLU处理后，得到的结构化输出大致是这样的：

然而，NLU技术存在一些明显的局限性：

• 所有意图必须预定义（分类）
• 所有槽位必须事先建模（序列标注）
• 泛化能力差，新场景需要重新训练模型
• 多步推理能力几乎为0

Prompt Engineering

LLM兴起以后，其强大的生成式语义推理、结构约束和泛化能力，完美地解决了NLU的诸多痛点。然而，早期的LLM并不具备Function Calling的能力（如DeepSeek-R1）。于是，人们主要通过Prompt Engineering（提示词工程）的方式，引导LLM生成符合预期的结构化数据。

例如，针对天气查询的例子，可以设计如下Prompt：

You are an assistant that can perform actions based on user requests. Your responses should be in JSON format with the following structure:

1 2 3 4 5 6 7

{ "name": "action_name", "arguments": { "key1": "value1", "key2": "value2" } }

Query: What is the weather like in Chengdu?

发给LLM后，就能得到如下JSON格式的文本输出：

1
2
3
4
5
6

{
  "name": "get_weather",
  "arguments": {
    "location": "Chengdu"
  }
}

Structured Output

上述方式虽然有效，但是稳定性不高。随着模型能力的演进，很多LLM开始原生地支持JSON mode，后来又进一步支持了Structured Output（结构化输出），生成结构化数据的能力得到了显著提升。

使用Structured Output，可以非常稳定地生成结构化数据。有些SDK（如OpenAI Python SDK），甚至还提供了与数据验证库（如Pydantic）的无缝集成，进一步增强了类型检查和数据验证的功能。例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

from openai import OpenAI
from pydantic import BaseModel, Field

client = OpenAI()

class Arguments(BaseModel):
    location: str

class Query(BaseModel):
    name: str = Field(..., description="Action to perform")
    arguments: Arguments = Field(..., description="Arguments for the action")

response = client.responses.parse(
    model="gpt-4o-2024-08-06",
    input=[
        {
            "role": "system",
            "content": "Extract the query information.",
        },
        {
            "role": "user",
            "content": "What is the weather like in Chengdu?",
        },
    ],
    text_format=Query,
)

print(response.output_parsed)

# Output:
# name='getWeather' arguments=Arguments(location='Chengdu')

Structured Output vs Function Calling

事实上，在OpenAI的生态中，Function Calling（于2023年6月推出）先于Structured Output（于2024年8月推出）出现。

早期的Function Calling有时会“幻觉”出不符合格式的JSON，而Structured Output则可以确保输出严格遵循Schema。因此，Structured Output也可以看作是Function Calling能力的底层升级（Strict mode）。

从形式上来看，虽然Structured Output和Function Calling都会让LLM生成结构化的数据（通常是JSON），但它们解决的问题维度并不相同：

Function Calling

由上述分析可见，Function Calling的核心在于由LLM灵活决定是否调用工具、调用哪个工具。仍然以天气查询为例，如果我们将思维模式从“结构化输出”转变为“工具调用”，整体的处理逻辑就会截然不同。

如图所示，使用Function Calling来处理天气查询，整体的流程大致如下：

1. 向模型发送用户请求，并明确声明其可调用的工具列表（如get_weather(location)）。
2. 模型根据请求，决定需要调用的工具名称（如get_weather）及相应的参数（如{"location": "chengdu"}）。
3. 应用程序解析工具调用请求后，执行对应的代码，并获取结果（如{"temperature": 14}）。
4. 应用程序携带工具调用的结果，再次向模型发起请求。
5. 模型据此生成最终的回复（如It's currently 14°C in Chengdu.），或者再次调用其他工具。

对应于上述流程，下面给出一个可运行的Python示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

import json
from openai import OpenAI

client = OpenAI()

# 1. Define a list of callable tools for the model
# (Note that `parameters` are defined in JSON Schema)
tools = [
    {
        "type": "function",
        "name": "get_weather",
        "description": "Retrieves current weather for the given location.",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "description": "City e.g. Beijng, Chegndu"
                }
            },
            "required": ["location"],
            "additionalProperties": False
        },
        "strict": True
    },
]

def get_weather(location: str) -> str:
    # Here you would normally make an API call to a weather service
    return '{"temperature": 14}'

# Create a running input list we will add to over time
input_list = [
    {"role": "user", "content": "What is the weather like in Chengdu?"},
]

# 2. Prompt the model with tools defined
response = client.responses.create(
    model="gpt-5",
    tools=tools,
    input=input_list,
)

# Save function call outputs for subsequent requests
input_list += response.output

for item in response.output:
    if item.type == "function_call":
        if item.name == "get_weather":
            # 3. Execute the function logic for `get_weather`
            location = json.loads(item.arguments)["location"]
            output = get_weather(location)
            
            # 4. Provide function call results to the model
            input_list.append({
                "type": "function_call_output",
                "call_id": item.call_id,
                "output": output,
            })

response = client.responses.create(
    model="gpt-5",
    instructions="You are a helpful assistant.",
    tools=tools,
    input=input_list,
)

# 5. The model should be able to give a response!
print(response.output_text)

# Output:
# The current temperature in Chengdu is about 14°C.

框架封装

至此，我们已了解了Function Calling的基本原理与使用方式。但在实际应用中，若每个工具都需要手动编写JSON Schema，其开发复杂度势必大幅增加。因此，众多开发框架对此进行了封装，以提供更高层次的抽象。

例如，使用LangChain提供的@tool装饰器，便能轻松地将Python函数注册为LLM可调用的工具：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("gpt-5")

@tool
def get_weather(location: str) -> str:
    """Retrieves current weather for the given location."""
    return f"It's sunny in {location}."

# 1. Bind (potentially multiple) tools to the model
model_with_tools = model.bind_tools([get_weather])

# 2. Model generates tool calls
messages = [{"role": "user", "content": "What's the weather like in Chengdu?"}]
ai_msg = model_with_tools.invoke(messages)
messages.append(ai_msg)

for tool_call in ai_msg.tool_calls:
    # 3. Execute the tool with the generated arguments
    tool_result = get_weather.invoke(tool_call)
    # 4. Pass results back to model
    messages.append(tool_result)

# 5. Model generates the final response
final_response = model_with_tools.invoke(messages)
print(final_response.text)

# Output:
# It's sunny in Chengdu right now.

如今，Agent已成为主流，上述工具执行循环（Tool Execution Loop）也演进为ReAct Agent的核心范式。为此，很多框架进一步对整个Agent模式进行了抽象，从而将Function Calling的复杂性封装在高层API之下，大幅降低了开发门槛。

例如，借助LangChain提供的create_agent函数，只需寥寥数行代码，就能构建出一个完整的天气查询Agent：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

from langchain.agents import create_agent
from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("gpt-5")

@tool
def get_weather(location: str) -> str:
    """Retrieves current weather for the given location."""
    return f"It's sunny in {location}."

agent = create_agent(model, tools=[get_weather])
result = agent.invoke(
    {"messages": [{"role": "user", "content": "What's the weather like in Chengdu?"}]}
)
print(result["messages"][-1].content)

# Output:
# It’s sunny in Chengdu right now.

结语

本文从实际应用出发，梳理了从传统NLU到Prompt Engineering，再到Structured Output和Function Calling的技术演进脉络，并对比了后两者的功能定位差异。同时，介绍了如何使用框架来简化Function Calling的开发流程。

在Claude Code、OpenClaw等智能体日益普及的当下，Function Calling作为LLM的核心能力，已成为驱动这些Agent的重要技术基石。随着这项技术的广泛应用，工具生态的开放性与标准化也愈发关键。在此趋势下，MCP（模型上下文协议）已逐渐成为行业的事实标准，我们将在后续的文章中继续探讨这一话题。