从零手写AI Agent框架：Function Call与MCP全链路实战解析

为什么要从零手写智能体框架

如今搭建一个简易的AI Agent并不难，LangGraph、Swarm等框架让入门变得轻松。但正如这位B站UP主（皮坦爸爸/童老师）所言，本次课程的核心目的是「驱魅」——让智能体对开发者不再神秘。

整个课程不使用任何现成框架，完全从零手写代码，深度拆解「模型-工具-记忆」的底层逻辑。这样做的最大价值在于，能够彻底看清 Function Call、多轮对话、MCP 工具调用等关键环节的每一个细节，避免框架带来的黑盒。

作者的一个观察颇具行业洞察：很多公司在 Demo 阶段会使用 LangGraph、Swarm 等框架，但项目一旦深入、业务出现大量特殊性需求时，往往倾向于「自研」。原因在于自研代码足够灵活——「你想要什么就是什么，你想不要什么就不要什么」，框架的诸多限制反而难以满足复杂业务的定制需求。

提示词工程的四大痛点

课程开篇先厘清了一个认知误区。有人认为「大模型的核心就是提示词」，作者将持此观点的人戏称为「掌管提示词的神」。这句话对也不对——除了直接训练模型，我们确实主要通过提示词来影响大模型；但提示词并非随便拼凑就能生效，它背后有一套方法论，衍生出零样本学习、少样本学习、**思维链（CoT）**等技术。

思维链（Chain-of-Thought，CoT）背景：CoT由Google Brain团队Wei et al.在2022年的论文中正式提出。其核心发现是：当提示词中包含「逐步推理」的示例时，大模型在复杂推理任务上的表现会显著提升。后续研究进一步发展出「零样本CoT」（只需加入"Let's think step by step"即可触发）、「思维树（ToT）」等变体。CoT之所以有效，学界普遍认为是因为中间步骤为模型提供了额外的「计算空间」，使其能够分解复杂问题——这与智能体的多步骤工具调用设计理念高度吻合。

若以提示词为中心构建系统，会暴露四个明显问题：

脆弱性与不可复现性：稍微改动几个对人类无差别的词，模型结果可能大相径庭。做 Demo 时「看天吃饭」问题不大，但真正落地时这种不确定性难以接受。
扩展性差：随着工具数量增多，纯提示词方案的扩展性急剧下降。
用户负担重：把提示词工程的复杂性转嫁给用户，体验极差。
无状态性：大模型本质上没有记忆能力，多轮对话难以处理。

正因如此，业界从单纯的「提示词」升级到了**「Context（上下文）工程」**，引入短时记忆、RAG、工具标准化输出等模块来系统性解决这些问题。

「上下文工程（Context Engineering）」是2024年后业界逐渐形成的新概念，由Andrej Karpathy等人推广。它与「提示词工程」的本质区别在于：提示词工程关注单次输入的措辞优化，而上下文工程关注如何系统性地管理模型在整个任务过程中所能看到的全部信息——包括历史对话、检索到的文档（RAG）、工具描述、执行结果等。这一转变背后是对LLM局限性的深刻认识：模型能力的上限往往不由参数决定，而由输入给它的上下文质量决定。

Function Call：让大模型学会调用工具

大模型本质上是「字符串进、字符串出」的系统。用它做问答没问题，但要调用工具就需要一套机制——将**工具的 Schema（描述）**以字符串形式喂给模型。

**Function Call（函数调用）**是大型语言模型与外部工具交互的核心机制。从技术实现角度看，模型在训练阶段被专门注入了「工具调用」的数据格式，使其能够识别结构化的工具描述并输出符合规范的调用指令。OpenAI在2023年的GPT-3.5/4版本中率先将其标准化，随后成为行业惯例。值得注意的是，Function Call并非真正意义上的「调用」——模型本身无法执行代码，它只是输出一段结构化的JSON字符串，真正的执行由宿主程序完成，再将结果反馈给模型继续推理。

工具 Schema 本质是工具的结构化描述，包含：工具的功能说明、每个参数的名称、类型（字符串/数字/布尔）、含义解释，以及 required 标记参数是否必填。大模型通过分析这些描述来决定调用哪个工具、传入什么参数。

我们再定义一下

有意思的是，这个格式必须遵循一定规范，因为它对应模型训练时约定好的格式——只有推理时的工具格式与训练数据保持一致，模型才能正确解析。

用大模型生成 Schema，降低注释规范要求

这里作者做了一个巧妙的工程优化。传统做法（如某些框架）要求开发者严格按照 Google 或 NumPy 风格的标准注释格式书写，一旦注释不规范就解析失败。

作者的方案则是：把函数注释（function.__doc__）连同目标 Schema 结构一起拼进提示词，交给大模型来完成「自然语言注释 → 结构化 JSON」的转换。这样开发者写注释可以相当随意，只要描述清楚即可。

由于大模型输出存在随机性，作者设计了最多循环三次的重试机制——根据经验，三次基本能转换成功，若三次都失败则直接抛错。

MCP协议：把远程服务镜像成本地工具

本地工具解决了，但很多工具实际部署在远程 MCP 服务上，无法直接本地调用。作者的解法是「远程服务镜像」——把远程 MCP 服务直接镜像成本地工具函数。

这样你的外面的工具和本地的工具

**MCP（Model Context Protocol，模型上下文协议）**由Anthropic于2024年11月发布，旨在解决AI模型与外部数据源、工具之间的碎片化集成问题。在MCP出现之前，每个AI应用都需要为每种外部服务单独开发适配层，形成「N×M」的集成复杂度。MCP通过定义标准化的服务器-客户端通信协议，将其简化为「N+M」模式——服务提供商只需实现一次MCP服务端，AI应用只需实现一次MCP客户端即可互联互通。目前已有数百个主流服务（GitHub、Slack、各类数据库等）提供官方MCP支持，正在成为AI工具生态的事实标准。

在 Demo 中，MCP 服务提供了两个工具：一个查询天气（直连阿里云^广告官网获取真实数据），一个兑换汇率（为演示方便随机生成）。通过 get_tools 拿到远程工具的名称与描述，拼装成本地函数体，调用时再转发到远程 MCP。这些镜像出来的函数甚至不需要落盘，直接加载进内存即可使用。

这个直接从阿里云的官网上查询天气

MCP 标准化协议的核心价值在此凸显：如果没有 MCP，张三、李四各自搭建的服务接口都不一样，你需要为每套服务单独适配镜像逻辑，成本巨大。有了 MCP 这套标准化协议后，只需实现一套镜像逻辑，任何符合标准的服务都能转成本地工具函数，架构瞬间清晰。

最终在主函数中，本地工具（百度搜索、获取时间、加法运算）与 MCP 工具被统一对待，「把 MCP 函数工具当本地工具来用」，让整个架构保持整洁一致。

双模型分发架构与思考循环

整个智能体的运行流程可以拆成两大步骤：用户输入 → 思考判断是否需要调用工具 → 调用工具后再思考 → 直到不需要工具则进行最终回答。由于一次请求可能涉及多次工具调用（如同时查询北京和上海天气），这里设计了一个循环机制。这种「思考-行动循环」在学术界有一个经典的形式化描述——ReAct（Reasoning + Acting），由Yao et al.于2022年提出，是目前智能体设计最有影响力的范式之一。

我这一轮我调了工具了

分发模型 vs 闲聊模型

作者引入了双模型架构：

Dispatch（分发）模型：用能力更强的模型判断是否需要调用工具及工具参数。这一步对模型推理能力要求较高。
Chat（闲聊）模型：若判断只是普通闲聊，则交给较弱的模型处理，有效节省调用成本。

系统维护一个状态机管理流程转换：初始为 chat 状态，判断需要工具时切换到 tool 状态执行工具调用；工具执行完后，将结果通过大模型「过一遍」进行总结性描述，再返回给用户。状态机（State Machine）是计算机科学中描述系统状态转移的经典模型，在本架构中的核心价值在于：当智能体行为异常时，开发者可以通过查看状态转移日志精确定位问题发生在哪个节点，而非面对一个不透明的黑盒——这正是「去黑盒化」工程思想的体现。

临时消息不入上下文

一个关键的工程细节：思考阶段会把工具 Schema 和引导性提示词（如「根据上一步结果执行下一步操作」）临时注入，但这些引导信息不会进入长期上下文。

原因在于——大模型上下文过长会影响效果，因此应尽量让有效信息进入模型。工具 Schema 只在调度阶段放入，正式对话时并不携带，既缩短了输入长度，又能让模型获取更多有效信息。

短期记忆：让AI Agent记住对话上下文

记忆能力通过一个 MemoryManager 实现，它把多轮对话信息全部存储起来，构成所谓的短期记忆。

Demo 中的验证很直观：直接问原生大模型「我是谁」，它不知道；告诉它「我是皮坦爸爸」后再问，它就能记住并回答。若要做得更复杂，还可以将记忆持久化到 Redis 或数据库中，甚至引入**RAG（检索增强生成）**实现长期记忆管理。

RAG由Meta AI在2020年提出，在智能体记忆体系中承担「长期记忆」的角色：将历史对话、用户偏好、领域知识向量化存储于向量数据库（如Pinecone、Chroma、Milvus），在每次对话时检索最相关的片段注入上下文。相比于将全部对话塞入上下文窗口的「短期记忆」方案，RAG能够处理远超上下文长度限制的历史信息，但代价是引入了检索准确性的不确定性。两种记忆机制在生产级智能体中通常协同使用，共同构成完整的记忆体系。

核心结论：智能体本质是工程化封装

通读整个从零手写的过程，作者给出了一个值得深思的结论：智能体其实跟 AI 算法本身关系并不大，它更多是工程化的封装工作。

这也解释了为什么理解底层原理如此重要——当你把 Function Call、MCP 镜像、状态机循环、上下文管理、记忆存储这些「工程积木」都拆解清楚后，就能根据业务的特殊需求自由组合，而不必受制于任何框架的限制。这正是本次课程「驱魅」的最终目的。