一、从“会聊天”到“能干活”：Agent 的本质跃迁
如果你只会调用 Chat API，那你离 AI-Agent 工程师还有一段距离。这不是危言耸听。

普通问答是“你问我答，答完结束”。Agent 不一样——它围绕一个目标持续行动，边做边判断，直到任务完成。你让 Agent“帮我处理这批订单的退款”，它不会只回你一段话，而是会去查订单状态、调退款接口、发通知邮件、记录日志，中途遇到问题还会调整策略。

这个跃迁背后，三块技术基石撑起了整个体系：Function Calling 让 Agent 能“动手”，RAG 让 Agent 能“找依据”，MCP 让 Agent 的“动手能力”可以标准化接入。下面逐个拆解。

二、Function Calling：Agent 的手
Function Calling 是整个 Agent 体系的命根子。没有它，模型只能“说”；有了它，模型才能“做”。

2.1 它在做什么
核心逻辑很简单：模型决定调什么函数、传什么参数，但不执行。执行是应用代码的事。

一个典型的流程：

你在请求里带上工具定义（函数名、描述、参数 schema）

模型判断是否需要调工具。需要的话，返回一个结构化的 function_call，包含 call_id、函数名和 JSON 参数

你的代码收到这个调用，执行真正的业务逻辑，把结果包装成 function_call_output 追加到消息里

把整个消息列表再次发给模型，模型基于工具返回的真实数据生成最终回答

2.2 工程上真正要关心的三件事
第一，schema 设计是接口设计的延伸。 函数描述写得含糊，模型就乱调。参数命名不清晰，模型就传错值。把每个函数当成给一个“不太聪明但很听话的实习生”写的 API 文档来对待。

第二，strict 模式建议默认开启。 OpenAI 的 API 支持 strict: true，确保模型输出严格符合你定义的 JSON Schema，而不是“尽力而为”。少一个字段、多一个逗号，下游代码就崩了。

第三，并行调用是一把双刃剑。 GPT-5 之后模型可以在单轮里并行调用多个函数。查天气 + 发邮件 + 查数据库，一次搞定，延迟大幅降低。但如果工具之间存在依赖关系（比如必须先查订单才能退款），并行就是灾难。parallel_tool_calls: false 是你需要记住的保险开关。

面试高频问题：“Function Calling 和 MCP 有什么区别？”——答案在第四节。

三、RAG：Agent 的“有据可查”
3.1 RAG 解决的不是“多读点”，而是“有证据”
很多人对 RAG 的理解停留在“让模型多读点资料”。这个理解偏了。

RAG 真正要解决的是：当模型做出一个判断时，这个判断能不能落回可验证的证据上。

你让 Agent 帮用户处理优惠券核销。Agent 知道“外部接口要加超时、错误码要统一”——这是 Skill 或 Prompt 教它的。但它不知道“你们公司的优惠券接口今天刚把 requestId 字段改成了 idempotencyKey”。这时候就需要 RAG 去检索最新的 API 文档。

3.2 RAG 翻车的根因：检索了一堆“看似相关”的垃圾
一个粗糙的 RAG 系统，用户问“订单核销优惠券时幂等键怎么传”，它可能返回：

coupon-api-v1.md（老接口，字段叫 requestId）

coupon-api-v2.md（新接口，字段叫 idempotencyKey）

refund-coupon.md（退款返券逻辑，也提到了 idempotencyKey）

marketing-campaign.md（营销发券，根本不是核销场景）

模型看到这堆材料，很可能拼出一个“看起来合理但业务错误”的答案。这不是模型不行，是检索层把过期文档、错模块文档、低相关文档一起塞进了上下文。

3.3 工程解法：三段式 RAG
把 RAG 做成三段流水线，而不是“向量搜索 + 拼接”：

第一段：Query Rewrite。 用户的原始 query 往往模糊、短、带口语。用一个小模型或规则做查询改写，补上领域术语和隐含条件。

第二段：Rerank + Filter。 先粗召回（比如 top-20），然后用 cross-encoder 做重排，同时用元数据过滤掉过期版本、错误模块的文档。这一步是 RAG 质量的分水岭。

第三段：Grounded Answer。 最终生成时，强制要求引用来源。每个关键判断后面带上 [source: coupon-api-v2.md]。如果模型找不到可引用的证据，它应该说“我不确定”，而不是编一个。

RAG 的目标不是让模型显得懂很多。RAG 的目标是让模型每个关键判断都能落回证据。

3.4 进阶方向
基础 RAG 跑通之后，如果还要提升，可以考虑：分层索引（摘要层 + 细节层）、混合索引（向量 + 图 + SQL）、为每个 chunk 生成示例问题来提升检索匹配度。但前提是先把“过滤 + 重排 + 引用”这三件事做扎实。

四、MCP：Agent 工具接入的“标准插座”
4.1 先分清 Function Calling 和 MCP
这是面试最容易被追问的点。

Function Calling 是一次 API 调用里的工具声明。 你在每次请求里带上 tools 数组，应用自己维护工具列表、认证方式、错误处理、服务连接。它是“一次性”的。

MCP 是一个协议。 它定义了 AI 应用（Host）如何通过标准消息与外部能力服务（Server）通信。工具提供方实现一个 MCP Server，任何支持 MCP 的 Host 都能接入，不需要为每个 Host 单独写适配代码。

打个比方：Function Calling 是你每次打电话时口头告诉对方“我能做这几件事”；MCP 是你把名片放进了通讯录，谁需要谁查。

4.2 MCP 的三层架构
Host：用户实际使用的 Agent 应用（比如 Cursor、VS Code Copilot）

Client：Host 内部维护连接的客户端，负责发送和接收 MCP 消息

Server：暴露 tools、resources、prompts 的外部能力服务

标准的消息类型包括 ListToolsRequest、CallToolRequest、ReadResourceRequest、GetPromptRequest 等。Server 可以是一个包装 REST API 的适配层，也可以直接连接数据库或本地文件系统。

4.3 为什么 MCP 重要
在没有 MCP 之前，每接一个外部系统（Git、数据库、Jira、内部 API），你就要写一遍工具声明 + 认证 + 错误处理 + 连接管理。MCP 把这件事标准化了。

微软的 MCP C# SDK 已经可以通过 NuGet 直接使用，由 Microsoft、Anthropic 和 MCP 开源组织共同维护。越来越多的产品（GitHub Copilot、Docker 等）开始提供预置的 MCP 集成。

但 MCP 不是万能药。 它解决的是“接入标准化”，不解决“工具设计得好不好”。一个描述含糊的 MCP Server，和一个描述含糊的 Function Calling 工具，一样会让模型乱调。

五、从学习到落地：一条务实的路径
如果你正在从“会调 API”走向“能设计 Agent 系统”，建议按这个顺序验证自己：

第一阶段：能稳定地调用 LLM、拿到可解析的结构化输出。这一步不过关，Agent 每一步决策都会散架。

第二阶段：吃透 Function Calling。能设计出模型“看得懂”的工具 schema，能处理 function_call_output 的回传循环，能判断什么时候该用 parallel_tool_calls: false。

第三阶段：搭一个基础 RAG。文档分块、embedding、向量检索，先把链路跑通。然后重点做过滤和重排——这才是 RAG 从“能跑”到“能用”的关键。

第四阶段：理解 MCP 的角色。不需要立刻自己写 MCP Server，但要能讲清 Host / Client / Server 的职责划分，能判断什么时候该用 MCP 而不是裸 Function Calling。

最后一个反直觉的建议：学会判断什么时候不该用 Agent。“过度 Agent 化”是新手最常踩的坑。一个简单的模板填充任务，用 Prompt + Function Calling 就够了，硬套 Agent 只会引入不必要的延迟和失败点。能讲清“什么时候不用 Agent”，比会写十个 Agent Demo 更值钱。

总结：Function Calling 给 Agent 手，RAG 给 Agent 证据，MCP 给 Agent 标准化的工具接入通道。三块基石拼在一起，你才真正从“会调 API 的人”变成了“能设计 Agent 系统的人”。