AI 时代的技术分歧：为什么有了原生 Function Calling，Cline 还要把工具写进提示词里？

AI 时代的技术分歧：为什么有了原生 Function Calling，Cline 还要把工具写进提示词里？

在探索 AI Agent（智能体）的开发世界时，如果你仔细研究过各大模型厂商提供的 API，你一定会遇到一个极其重要的概念：Function Calling（函数调用）。

很多技术大牛在科普时都会强调一句话：“Function Calling 是大模型在原生层面（API 级别）支持的能力。”

这句话确实点出了 Function Calling 颠覆 AI 开发格局的本质。但在实际操作中，很多敏锐的同学在翻看像Cline (原 Claude Dev)这样顶级的 AI 编程助手时，却发现了一个令人困惑的现象：Cline 并没有使用大模型原生 API 里的tools参数，而是写了一大堆<tool_name>的 XML 标签，硬塞在系统提示词（System Prompt）里去教 AI 怎么用工具！

为什么 Cline 要“反其道而行之”？要解开这个谜团，我们必须先了解大模型调用工具的演进史，再揭开“JSON 派”与“XML 派”的路线之争。

阶段一：强行模拟（Prompt Engineering 的痛苦时代）

在 2023 年中旬（OpenAI 正式发布 Function Calling 之前），大模型只懂聊天，它的输入和输出纯粹是自然语言。 那时，如果你想让它去查天气，你必须在系统提示词里写一段类似于“紧箍咒”的规则去“逼”它：

“你是一个助手。当你需要查天气时，你必须严格按照以下格式输出：Action: get_weather, Args: {"city": "Beijing"}。千万不要输出废话！千万不要加标点符号！”

这种方式极其痛苦：

• 易发幻觉：大模型可能会调皮地回复：“好的，这就去查！Action: get_weather...”。
• 解析噩梦：开发者必须写复杂的正则表达式（Regex）去这段乱七八糟的文本里“抠”出参数。只要大模型多说一句废话，程序直接崩溃。

阶段二：原生支持（JSON 派的绝对统治）

后来，OpenAI 等厂商在训练模型底层架构时，直接内置了这种能力，并通过 API 接口开放。这就是“原生层面（API 级别）支持”。

你不再需要在提示词里长篇大论。你只需在 API 层面传入一个独立的tools参数（包含一段规范的 JSON 结构）：

# API 级别：把工具说明书作为独立参数传给模型response=client.chat.completions.create(model="gpt-4",messages=[{"role":"user","content":"今天北京天气？"}],tools=[{"type":"function","function":{"name":"get_weather","parameters":{...}}}])

原生支持的“魔法”在于底层拦截：厂商在底层协议拦截了输出，模型一旦决定调用工具，它绝对不会返回聊天废话，而是直接返回一个完美的、必定能被代码解析的 JSON 对象。这就叫基础设施层赋予的“特权”。

路线之争：Cline 为什么偏要重回“提示词”？

既然原生的 JSON API 这么香，完美解决了格式解析的问题，为什么顶尖的 AI 工具 Cline 还要用一堆<use_mcp_tool>的 XML 标签写在提示词里去“模拟”函数调用呢？

这不是倒退，而是为了追求极致的体验和控制力。这里面隐藏着三个深层原因：

原因一：Claude 模型的“家族天赋”

Cline 最核心适配的是 Anthropic 家的 Claude 模型。Anthropic 在训练 Claude 时，给它灌输了极强的 XML 解析和生成能力。对于 Claude 来说，看懂和生成<tags>比处理复杂的嵌套 JSON 更加得心应手。Cline 这是在投其所好。

原因二：完美的“打字机”流式体验（Streaming）

使用原生的 JSON Function Calling 时，很多模型在输出 JSON 时会产生“卡顿”，因为它必须在后台把 JSON 结构拼装完整，确保没有语法错误，才能发给程序解析。 但如果是输出 XML 文本，大模型可以像人类说话一样，一个字符一个字符地吐出来（<->t->h->i->n->k->>）。这让 Cline 的前端界面能做到真正的“丝滑打字”效果，你能实时看到 AI 思考的过程，而不必对着屏幕干等。

原因三：强行绑定“思考”与“行动”

在 Cline 的系统提示词中，有一条铁律强制大模型：在调用工具之前，必须先在<thinking>标签里输出推理过程。 这把大模型的“思考（Reason）”和“行动（Act）”无缝且强制地绑定在了一次连续的文本输出流中。而原生的 JSON API 很难做到这种“先大段文本发散思考，紧跟严谨机器指令”的连贯性。

总结：殊途同归的底层逻辑

了解了这段历史，你便拥有了超越普通开发者的视角：

• 主流行业标准：是 OpenAI 定义的JSON Native Function Calling（原生 API 级），它安全、稳定、适合大多数常规开发。
• 极客定制路线：是 Cline 采用的基于XML 的 Prompt Tool Calling（文本流级）。它为了极致的流式体验和对 Claude 模型的深度压榨，用极其精妙的 Prompt 工程将底层逻辑搬到了台面上。

无论哪种路线，它们的核心目的都是一样的：让大模型输出一段可被机器解析的格式化指令，从而让宿主程序（Host）代替它去执行外部任务。洞悉了这种差异，你便能根据自己使用的模型和产品需求，灵活选择最适合的工具调用方案。