从Cursor系统提示词看Function Calling与MCP工作原理详解

引言

在AI Agent开发中，工具调用（Function Calling）是核心能力之一。本文通过解析Cursor编辑器的系统提示词，深入剖析Function Calling和MCP（Model Context Protocol）的工作原理，并实测不同参数模型的Agent能力差异。

Function Calling的基本流程

工具定义与调用机制

Agent的工具本质上就是一个函数。定义一个Agent需要三要素：模型实例化（名称、temperature等参数）、工具定义（Tools）、系统提示词（System Prompt）。

Function Calling最早由OpenAI在2023年6月引入GPT API，其设计思想是让大语言模型不直接执行代码，而是生成结构化的调用意图描述。这种设计将"决策"（模型负责）和"执行"（程序负责）彻底解耦，使得LLM可以安全地与外部系统交互，而不需要真正拥有执行权限。在实际SDK实现中，工具定义通常以JSON对象数组的形式传入API的tools参数，每个工具包含type（目前固定为"function"）、function.name、function.description和function.parameters四个字段。

工具的工作流程非常清晰：

1. 用户提问（如"100+100等于多少"）
2. 系统提示词规范大模型输出特定格式字符串（如{name: "calculate", arguments: {expression: "100+100"}}）
3. 函数接收该字符串，执行计算，返回结果
4. 大模型接收返回结果，组织自然语言回复用户

关键点在于：系统提示词必须严格规范AI的输出格式，否则函数无法解析，会报"未知工具"错误。

普通工具与MCP工具的核心区别

普通工具采用同步调用方式，使用普通字典存储工具描述，适合本地（local）使用。必须等一个工具执行完毕后，才能进行下一次调用。

MCP工具则有两大区别：

• 完全遵循JSON Schema标准格式定义
• 支持异步消息处理（通过stdin模式），允许多用户同时访问同一工具

MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在为AI模型与外部数据源、工具之间建立统一的通信标准。它借鉴了LSP（Language Server Protocol）的设计理念——正如LSP让任何编辑器都能对接任何语言服务器一样，MCP让任何AI应用都能对接任何工具服务。其中提到的JSON Schema是一种描述JSON数据结构的标准规范（定义在IETF RFC草案中），它能精确描述每个参数的类型、是否必填、取值范围等约束，使得不同系统之间无需额外协商即可理解工具的输入输出格式。

MCP的异步设计是因为它面向所有人公开，多人可能同时调用同一个工具，如果采用同步方式会产生等待问题。MCP支持两种传输模式：stdio（标准输入输出，适合本地进程间通信）和HTTP+SSE（Server-Sent Events，适合远程服务）。异步通信基于JSON-RPC 2.0协议，每条消息带有唯一ID，允许请求和响应乱序到达，从而支持并发调用。

Cursor系统提示词结构解析

提示词的核心组成部分

Cursor的系统提示词包含以下核心部分：

• 身份定义：你是运行在Cursor中的助手
• 工具调用注意事项（Court Tooling）：如"不要告诉用户你在调用什么工具"
• 工具列表与参数定义：如search_and_reading、make_code_change等
• 用户自定义Rules：会被注入到系统提示词中
• Attached Files：用户附加的文件内容

每个工具都详细定义了description、required参数、参数类型等信息，本质上就是告诉大模型"这个工具是什么、需要什么输入"。

系统提示词与工具的对应关系

系统提示词和工具定义是一一对应、缺一不可的关系。提示词中需要包含：

• 工具的使用示例（Few-shot）
• 输出格式的严格要求（"只生成JSON格式，不要解释步骤"）
• 支持的操作说明

这里的Few-shot指的是在提示词中提供少量示例（通常2-5个）来引导模型学会正确的输出模式，这是一种无需微调即可让模型适应特定任务的提示工程技术。对于工具调用场景，Few-shot示例通常展示"用户输入→正确的工具调用JSON"的映射关系，帮助模型理解何时调用哪个工具、参数如何填充。

不同参数模型的Agent能力实测

基础工具调用测试

使用"2的8次方是多少"测试小模型（约1-2B）和4B模型，两者都能正确输出规范的工具调用字符串。4B模型在思考链中会纠结2**8还是2^8的表达差异，但这属于工具端处理的问题。

工具返回结果的信任问题

一个有趣的实验：告诉模型2的8次方等于200（错误答案），模型经过长时间思考后选择了信任自身知识（256），而非工具返回的结果。这说明系统提示词需要进一步强化"必须信任工具返回结果"的指令。

这个现象涉及AI领域中的"grounding"（接地）问题——即模型应该以什么作为事实依据。大语言模型在预训练阶段已经记忆了大量世界知识，当外部工具返回的结果与其内部知识冲突时，模型会陷入"该信谁"的两难境地。在实际Agent系统中，工具返回的实时数据通常应优先于模型的静态知识（因为模型知识有训练截止日期），因此需要在系统提示词中明确写入类似"Always trust tool results over your own knowledge"的指令来解决优先级问题。

复杂场景下的表现差异

将Cursor完整系统提示词输入测试：

• 小模型：无法在大段提示词中准确定位并完成任务
• 4B模型：成功识别attached file内容、遵循自定义rules（西班牙语回复）、按规范格式输出代码修改指令

4B模型输出的代码修改格式完全符合Cursor的要求——上方的自然语言解释给用户看，下方的结构化数据才是真正传给函数的内容。这种"双输出"设计在Agent架构中很常见：面向用户的自然语言部分提供可读性和透明度，面向系统的结构化部分确保程序可以可靠解析。小模型在这类任务中失败的主要原因是上下文窗口利用能力不足——虽然技术上支持长上下文，但在数千token的系统提示词中精确定位相关指令并同时满足多重约束，对模型的注意力机制和指令跟随能力提出了很高要求。

总结

Function Calling的本质是通过系统提示词约束大模型输出特定格式的字符串，再由对应函数解析执行。MCP在此基础上增加了标准化定义和异步处理能力。模型的指令跟随能力直接决定了Agent的可靠性，这也是为什么Agent开发中模型选择至关重要。

核心要点

• Function Calling本质是通过系统提示词约束大模型输出特定格式字符串，由函数解析执行并返回结果
• MCP与普通工具的核心区别在于JSON Schema标准化定义和异步消息处理能力
• 系统提示词与工具定义必须一一对应，缺一不可
• 模型参数量影响复杂场景下的指令跟随能力，4B模型可处理Cursor级别的复杂工具调用
• 工具返回结果与模型自身知识冲突时，需要在提示词中明确优先级