一篇讲清 Prompt、Agent、Function Calling、MCP 的关系
很多 AI 应用讲到最后都会落到几个词：Prompt、Agent、Function Calling、MCP。它们经常被放在一起说，但在工程链路里承担的职责完全不同。
如果把这些概念混在一起，很容易出现两个误判：一是以为 Prompt 写得好，系统就能自动执行任务；二是以为接了 MCP，应用就天然具备智能体能力。实际项目里，这两种判断都会让方案走偏。
先把输入、推理、调度和执行分开
Prompt 是输入层。用户给出的需求、系统预设的角色和约束，都属于这一层。它决定模型拿到什么上下文、应该以什么边界生成结果。
Model 是认知层。它负责理解需求、生成计划、判断下一步可能要做什么。但模型本身不是业务系统，也不会凭空拥有访问文件、数据库、接口和网页的权限。
Agent 是编排层。它把模型的判断放进一个可执行流程里，决定什么时候调用工具、什么时候把工具结果交回模型、什么时候停止任务。真正做产品时，Agent 这一层通常还要处理状态、上下文、重试、日志和人工确认点。
Tool 是能力层。读文件、搜索、访问数据库、调用 HTTP API、上传图片、创建草稿，这些都是具体工具。没有工具，AI 应用只能停留在文本生成；有了工具，系统才开始进入真实业务流程。
Function Calling 解决的是调用接口的稳定性
早期做工具调用，经常会把规则写进 Prompt：如果你要调用某个工具，请输出一段固定格式的 JSON。这个方式能做 Demo，但稳定性不够。
问题不在于模型不会理解，而在于自然语言生成本身容易出现格式偏差。字段名多一个字符、参数类型不对、漏掉必填项，都可能让后端调用失败。
Function Calling 的作用，是把工具名、参数 schema、调用结果这些内容结构化。模型需要调用工具时，不是随手生成一段“看起来像 JSON”的文本，而是在明确的函数描述里选择函数和参数。
所以它的核心价值不是“让模型变聪明”，而是让模型到工具之间的通道更可控。对工程实现来说，这意味着更少的解析歧义、更明确的参数校验、更容易记录调用日志。
MCP 解决的是工具和资源接入方式
MCP 可以理解成外部能力接入 Agent 的协议层。它关心的是：一个文件系统、数据库、浏览器、搜索服务、企业内部系统，如何以统一方式把能力暴露给 Agent。
这和 Function Calling 的关注点不一样。Function Calling 更偏“模型怎么规范地发起工具调用”；MCP 更偏“外部工具、资源、提示模板如何被统一描述和接入”。
在一个真实项目里，MCP 不会替你设计业务流程，也不会自动判断权限边界。它只是降低了接入不同工具服务的适配成本。业务能不能跑起来，仍然取决于 Agent 编排、工具实现、权限控制、日志记录和失败处理。
一个可落地的智能体链路大概长这样
可以把链路拆成七段：
- User Prompt：用户提出任务，例如“把这篇文章发到三个平台”。
- System Prompt：系统定义角色、平台规则、禁忌、输出格式和安全边界。
- Model：理解任务，判断需要生成文章、处理图片、调用发布接口。
- Agent：安排步骤，先读文件，再生成平台版本，再检查登录，再发布。
- Tool：执行读写文件、图片处理、HTTP 请求、浏览器登录、接口调用。
- Function Calling：让工具调用参数和返回结果结构化。
- MCP：把外部服务以统一协议接入，例如浏览器、发布服务、文件资源。
这里每一层都可以出问题。Prompt 不清楚，模型会误解任务；工具能力不足，Agent 想做也做不了；没有日志和重试，流程失败后很难定位；权限边界不清，接入企业系统时会带来安全风险。
判断一个 AI 应用，别只看聊天效果
从产品和工程角度看，真正值得关注的是任务能不能闭环。
一个系统如果只会回答“Prompt 是什么”，那它是问答工具。它如果能根据任务选择工具、调用接口、读取结果、修正下一步，并把过程记录下来，才开始接近可用的 Agent。
MCP 也一样。支持 MCP 只是说明它有更标准的外部能力接入方式，不等于它已经具备稳定业务执行能力。最终还要看工具是否可靠、权限是否清楚、异常是否可恢复、输出是否可验收。
写在最后
Prompt、Agent、Function Calling、MCP 的关系，最好不要用“谁更高级”来理解，而要用“谁负责哪一层”来理解。
Prompt 负责表达需求，模型负责理解和生成，Agent 负责编排任务，Tool 负责执行动作，Function Calling 负责规范调用，MCP 负责统一接入外部能力。把这几层拆清楚，AI 应用的落地难点也会清楚很多。
