一、Agent 的本质大模型能理解语言、能推理、能创作——但它只能输出文字。你让它查天气它只能回复我可以帮你查天气。你让它发消息它只能说建议你这样写。它能给你建议但留不下任何行动。这是 Agent 系列要回答的核心问题怎么把一个只会预测下一个词的系统变成一个能帮人做事的系统答案很简单给它装一个代理层。过去人与大模型的交互只有一条路输入文字输出文字。大模型再强也只是一个能说会道的顾问——它分析问题、给出建议但什么都留不在真实世界里。Agent 系统改变了这一点。它成为人与大模型之间的代理LLM 负责推理和决策Agent 负责把决策变成真实操作——调接口、操作外部系统。模型不再只是回答问题而是能真的帮人做事。这个代理层由四个组件构成•Function CallingLLM 与 Agent 之间的交互语言•Skill定义遇到这个场景该怎么做•MCP定义这个能力从哪来、怎么连接外部系统•Memory管理上下文让模型记得之前说过什么、做过什么整个 Agent 系统就是这四者的整合。二、Function CallingLLM 与 Agent 的对话语言2.1 模型没有在调用它在预测当你对 Agent 说上海今天天气怎么样大模型内部生成的不是一段回复而是一段 JSON输入:上海今天天气怎么样模型生成的给代码看的不是给人看的:{function:search_weather,arguments:{city:上海}}模型没有真的调用函数。它只是预测出了这段 JSON——就像它预测今天天气晴气温26°C一样自然。真正执行这个调用的是外面的 Agent 代码# Agent 解析模型输出的 JSONtool_call{function:search_weather,arguments:{city:上海}}# 真正执行搜索resultsearch_weather(city上海)# → 晴26°C# 把结果塞回给模型让它继续想messages.append({role:tool,content:晴26°C})分工很清晰LLM 做决策决定调什么工具、传什么参数Agent 做执行真正调 API、读文件、跑命令。2.2 模型怎么学会输出 JSON靠训练。SFT 阶段喂了大量这样的数据用户: 帮我查一下北京天气 助手:{function:search_weather,arguments:{city:北京}}[工具返回: 晴26°C]助手: 北京今天晴气温26°C。模型见过足够多这样的例子就学会了遇到查天气的请求下一步应该输出 JSON 格式的工具调用——这和它学会Thank you very → much的机制完全一样。Function Calling 不是新能力。它就是预测下一个词只不过这次预测出来的是一段函数调用的 JSON。2.3 最小的 Agent一个循环整个 Agent 的核心是一条 for 循环def run_agent(user_message,max_steps10): messages[{role:system,content:你是一个能使用工具的助手。},{role:user,content:user_message}]forstepinrange(max_steps): responsellm.predict(messages,toolsavailable_tools)ifresponse.typetext:returnresponse.text# 模型输出文字 → 任务完成ifresponse.typetool_call:resultexecute_tool(response.function, response.arguments)messages.append({role:tool,content:result})# 执行后继续循环每一次循环消息历史都在增长——加入了新的工具调用和返回结果。模型看着这些内容继续推理越来越接近最终答案。但消息历史越来越长上下文窗口是有限的。这就是后面 Memory 系统存在的理由。三、Skill 与 MCP能力定义与能力接入Skill 和 MCP 解决的是两个不同层次的问题。3.1 为什么需要 MCP接入外部能力的代价让 Agent 调用一个天气 API看起来很简单。真正去做问题才出来没有 MCP 之前 你的 Agent 要接 GitHub → 写一套 GitHub 集成代码 你的 Agent 要接飞书 → 写一套飞书集成代码 你的 Agent 要接数据库 → 写一套数据库连接代码 换一个 Agent 平台 → 上面三套全得重写一遍每个外部系统有自己的接口规范、认证方式、错误处理。接入一个系统平均要写几百行代码换一个平台全部重来。工具只需要写一次但每次换平台都要重写。MCP 正是为了解决这个问题——它是统一的协议规范只要工具按 MCP 实现一次任何支持 MCP 的 Agent 都能直接用不需要重复对接。注意MCP 是协议规范GitHub Server、天气 Server 是实现了这个协议的具体工具。USB 是接口标准罗技鼠标是按标准造的设备。本文后续说的MCP Server都是指实现了 MCP 协议的具体服务。3.2 MCP 的架构MCP 的三层架构•MCP HostAgent 的运行环境管理所有连接和通信•MCP ClientHost 内部与每个 Server 保持一对一连接•MCP Server提供具体能力的独立服务暴露 Tools / Resources / Prompts其中 **Tools工具**是 Agent 与 LLM 交互的核心。每个 Tool 就是一个可被调用的函数通过 Function Calling 格式暴露给模型{name:search_weather,description:查询城市当前天气,inputSchema:{type:object,properties:{city:{type:string}}}}3.3 为什么需要 Skill能力怎么被正确使用MCP 解决了能力从哪来的问题但还有一个问题没有回答模型怎么知道什么时候该用这个能力比如Agent 接入了飞书 API有发消息、查邮件、建日程三个 Tool。你说帮我把会议纪要发给张总模型面对三个 Tool它怎么知道该用哪个发到哪里格式怎么写这就要靠 Skill。Skill 是一个 prompt 模板 元数据的封装它告诉模型遇到这个场景该怎么做。用一个真正复杂的业务场景来说明——会议纪要 Skill--- name: meeting_notes description: 整理会议纪要并推动后续行动 ---# 会议纪要 Skill## 触发条件用户提供了会议内容、参会人或提到会议纪要、总结一下会议。## 执行流程当模型判断应该使用此 Skill 时按以下步骤工作1. **整理纪要**从用户提供的内容中提取关键讨论点和结论2. **提取行动项**识别会议中明确的待办包括负责人和截止时间3. **发送邮件**调用飞书邮件工具把纪要发给所有参会人 - 邮件标题[会议纪要]{会议主题}-{日期}- 邮件正文包含参会人、讨论要点、行动项清单4. **创建日程**如果待办中有需要后续跟进的调用飞书日历建提醒## 注意事项- 用户没有提供完整会议内容时先反问补充 - 提取不到负责人时默认发给全部参会人确认这个 Skill 做了 MCP 做不到的事•判断何时使用用户提到会议纪要时触发•编排多步流程先整理 → 再提取 → 再发邮件 → 再建日程•指定格式规范邮件标题怎么写、正文包含什么•处理边界情况内容不全怎么办、负责人提取不到怎么办MCP Server 暴露的是三个独立的 Tool发邮件、查邮件、建日程Skill 把它们编排成一个完整的业务能力。Skill 的核心价值在 MCP 提供的原子能力之上封装出模型能理解的业务逻辑。3.4 Skill 与 MCP 的关系SkillMCP本质prompt 模板内容层连接协议传输层回答的问题“遇到这个场景Agent 该怎么做”“这个能力从哪来、怎么被发现”类比餐厅菜单菜品 做法 点单规则厨房接口标准确保所有厨具能插上电由谁定义业务专家 / 开发者MCP 协议规范Skill 定义做什么、怎么做MCP 定义这个能力怎么被连上。两者各司其职没有 MCPSkill 无从落地没有 SkillMCP 的原子能力无法被正确编排成业务场景。3.5 MCP 的生态MCP 由 Anthropic 在 2024 年底推出目前已经得到广泛支持•工具层面GitHub、Notion、Google Drive、Slack、飞书等主流服务都有了 MCP Server 实现•框架层面Claude Code、Cursor、Cline 等 AI 编程工具已原生支持 MCP•社区层面GitHub 上涌现了大量开源 MCP Server覆盖数据库、文件系统、邮件、日历等场景四、MemoryLLM 其实没有记忆4.1 核心前提LLM 本身是无状态的大模型本身没有记忆。它的所有记忆都来自于输入的上下文。你问我们刚才聊了什么Agent 能回答不是因为它记住了上一次对话——而是因为上一次对话的内容被当作输入传给了它。无论是对话历史、系统提示词还是外部检索回来的知识——本质上都是把信息塞进输入里让模型感觉它有记忆。这才是理解 Agent Memory 的关键问题不是Agent 记不记得上次的事而是这次请求的输入里有没有包含上次的信息。4.2 记忆的三个来源理解了无状态的前提之后Agent 的记忆实际来自三个地方对话历史当前会话的所有交互记录。用户说了什么、Agent 回复了什么、调用了哪些工具、返回了什么结果——都在消息历史里。系统提示词Agent 的角色设定、行为规则、边界约束。每次请求都会带上这部分内容是最稳定的记忆。外部检索向量数据库 / RAG跨会话场景下从外部存储检索相关内容拼入上下文。通过向量相似度匹配实现。4.3 记忆的管理策略输入长度有限Agent 必须主动管理记什么摘要压缩消息历史太长时用模型把它压缩成一段摘要替换原始内容。在有限窗口内塞更多轮对话。选择性写入不是所有信息都值得记住。Agent 可以只把真正重要的信息用户偏好、关键决策、结论写入外部存储。分层存储标准化信息用户名、公司名用 KV 数据库精确匹配模糊知识用向量检索。不同信息用不同的存储和召回策略。4.4 召回精度问题向量检索基于语义相似性但相似不等于相关。用户说跟上次一样处理可能召回完全不相关的内容。解决方案元数据过滤按时间、类别筛一遍再检索、重排Rerank 先选 20 条候选再用精准模型选出 3 条、混合检索向量 关键词 元数据一起用。五、完整架构到这里四个组件都讲清楚了。来看它们怎么整合成一个完整系统用户输入:帮我查一下上海天气然后发给张总┌─────────────────────────────────┐ │ Agent 系统 │ ┌─────────────┐ │ ┌──────────┐ ┌──────────────┐ │ │ 用户输入 │───────►│ │ Memory │ │ Skill Registry│ │ └─────────────┘ │ │ 召回相关 │ │ 工具列表 │ │ │ │ 记忆 │ │ │ │ │ └────┬─────┘ └──────┬───────┘ │ │ │ │ │ │ ┌────▼───────────────▼───────┐ │ │ │ LLM大模型 │ │ │ │ 理解输入 参考记忆 │ │ │ │ 做决策Function Calling │ │ │ └────────────┬───────────────┘ │ │ │ │ │ Function Calling 输出 │ │{function:search_weather, │ │arguments:{city:上海}}│ │ │ │ │ ┌─────────────▼────────────┐ │ │ │ MCP Client客户端 │ │ │ │ 按 MCP 协议路由到外部 │ │ │ └─────────────┬────────────┘ │ │ │ MCP 协议 │ └───────────────┼──────────────────┘ │ ┌─────────────────────────────▼────────────────────┐ │ 外部系统MCP Servers │ │ ┌───────────┐ ┌──────────┐ ┌──────────────┐ │ │ │ 天气服务 │ │ 消息系统 │ │ GitHub │ │ │ │ 外部 API│ │外部 API│ │ 外部 API│ │ │ └───────────┘ └──────────┘ └──────────────┘ │ └─────────────────────────────────────────────────┘流程用户输入 → Memory 召回相关记忆 → LLM 推理决定调用search_weatherFunction Calling 输出 JSON→ MCP Client 通过 MCP 协议连接到外部天气服务 API → 执行结果写回 Memory → LLM 继续推理决定调用发消息工具 → 通过 MCP 调用外部消息系统 → 返回结果。5.1 用一个人来比喻把 Agent 系统想象成一个人•LLM大脑。它能思考、能推理、能做决策但光有大脑只是一个悬浮的思维体。•Function Calling神经。大脑的决策通过神经传递给身体——FC 就是大脑向 Agent 身体传递决定的通道。•Skill手的技能。大脑知道要做什么手知道怎么做——Skill 就是手Agent知道的各种操作能力。•MCP手套和工具。手本身能做的事有限戴上手套、拿起工具就能做更多的事——MCP 就是 Agent 连接到外部系统的能力扩展。•Memory记忆。大脑没有记忆所有知识都来自输入——Memory 就是把信息管理好随时准备塞进大脑。组件回答的问题人的比喻LLM“这件事该怎么分析、怎么决策”大脑Function Calling“大脑的决策怎么传递出去”神经Skill“遇到这件事手该怎么做”手的技能MCP“手怎么连接和使用外部工具”手套和工具Memory“之前知道什么、还记得什么”记忆5.2 模块化的价值这四个组件的模块化是 Agent 架构最重要的设计•换模型Skill/MCP/Memory 不变只需要改 LLM 的调用方式•换工具只需要开发新的 MCP ServerAgent 端无需修改•换记忆策略Memory 的接口不变换底层实现换向量库、调召回算法不影响 Agent 其他部分六、工程挑战6.1 上下文窗口爆炸每次工具调用消息历史增长一次。20 轮调用的任务上下文已经相当长——Prefill 越来越慢最终可能超出窗口容量。应对摘要压缩超阈值时压缩历史、滑动窗口只保留最近 N 条、模型分流简单决策用小模型。6.2 记忆召回精度不足向量检索的语义相似不等于任务相关。应对混合检索向量 关键词 元数据、上下文感知召回让模型先理解任务再去检索、记忆质量控制写入前过滤。6.3 Skill 编排混乱多 Skill 协作时模型可能调用顺序不对、重复调用、漏掉关键步骤。应对工作流编排用规则预定义标准流程、子 Agent 分工复杂任务拆给专业子 Agent、安全 Hook执行前加权限校验。6.4 成本控制多轮、多 Skill 调用token 消耗可能是普通对话的 10 倍以上。应对小模型前置过滤意图识别用小模型、结果缓存、步数限制防止失控。七、总结大模型本质上只做一件事预测下一个 token。Agent 系统把它变成了能做事的能力•LLM负责推理和决策通过Function Calling输出决定•Skill定义每个能力怎么做•MCP把能力连接到外部系统•Memory管理上下文让模型能记得之前说过的话Agent LLM Function Calling Skill MCP Memory大模型系列讲的是大脑怎么工作Agent 系列讲的是怎么让大脑指挥四肢。下篇文章会从代码层面实现一个完整的 Agent 系统——从最小循环开始一步步加入 Skill、MCP、Memory。—文章首发于 「小小寰宇」