★ FEATURED ARTICLE 一、从“会聊天”到“能干活”Agent 的本质跃迁如果你只会调用 Chat API那你离 AI-Agent 工程师还有一段距离。这不是危言耸听。普通问答是“你问我答答完结束”。Agent 不一样——它围绕一个目标持续行动边做边判断直到任务完成。你让 Agent“帮我处理这批订单的退款”它不会只回你一段话而是会去查订单状态、调退款接口、发通知邮件、记录日志中途遇到问题还会调整策略。这个跃迁背后三块技术基石撑起了整个体系Function Calling 让 Agent 能“动手”RAG 让 Agent 能“找依据”MCP 让 Agent 的“动手能力”可以标准化接入。下面逐个拆解。二、Function CallingAgent 的手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 有什么区别”——答案在第四节。三、RAGAgent 的“有据可查”3.1 RAG 解决的不是“多读点”而是“有证据”很多人对 RAG 的理解停留在“让模型多读点资料”。这个理解偏了。RAG 真正要解决的是当模型做出一个判断时这个判断能不能落回可验证的证据上。你让 Agent 帮用户处理优惠券核销。Agent 知道“外部接口要加超时、错误码要统一”——这是 Skill 或 Prompt 教它的。但它不知道“你们公司的优惠券接口今天刚把 requestId 字段改成了 idempotencyKey”。这时候就需要 RAG 去检索最新的 API 文档。3.2 RAG 翻车的根因检索了一堆“看似相关”的垃圾一个粗糙的 RAG 系统用户问“订单核销优惠券时幂等键怎么传”它可能返回coupon-api-v1.md老接口字段叫 requestIdcoupon-api-v2.md新接口字段叫 idempotencyKeyrefund-coupon.md退款返券逻辑也提到了 idempotencyKeymarketing-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 生成示例问题来提升检索匹配度。但前提是先把“过滤 重排 引用”这三件事做扎实。四、MCPAgent 工具接入的“标准插座”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 CopilotClientHost 内部维护连接的客户端负责发送和接收 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 系统的人”。
阅读完成 · 觉得有帮助？
)
