Agent+MCP 开发范式

本文主体是高大伟老师在datawhale的宣讲，精练易懂。

辅以一些本人的看法，希望各位大佬一起交流指正。

本人的代码实践

传统智能体架构

Agent = Model + Context + Tools

现在 Tools → MCP 进行规范
MCP 改变了什么
- 工具构建过程
  1. 将工具逻辑封装为函数
  2. 面向智能体构建提示：介绍工具用处，如何使用，注意事项
- MCP 改变了分发逻辑，如地图API、模型服务提供新的发布渠道，且使用和构建新工具的难度降低

Toolkit 在 MCP 中类似于一个工具包

在实际过程中会碰到模型将用户需求复杂化的问题

MCP 中有隐藏的SOP （类似RAG）

将用户的非结构化文本信息转换的过程中需要一个结构化改写

智能体和MCP之间的灰色地带：MCP工具精度、能力范围、是否有隐含条件/规则/SOP

软件开发的SDK也是分离的，不也有类似问题吗？

但是，我们对LLM有更高的期待，期待其自主性，加剧了MCP质量控制的需求

显式操控 client 的生命周期

可以直接通过 client.get_callable_function(func_name=" ") 直接将远端的函数拿到，进行二次开发或约束、逻辑封装

多个 MCP Server 的 prompt 等等非常冗杂，可以通过

多个 Agent 每个负责一个 MCP Server 实现解耦

但是该如何处理多个 Agent 的内部关系？

需要一个优雅的、简洁的

组管理：工具组（多个方向不同的工具） - groupName

⇒ 元工具：需要什么方向工具就去激活然后配备具体的工具

工具不会是一个孤立的组成部分

Q: 目前开发框架是否和需求挂钩

A: 肯定的，开发效率&开发效果
Q: mcp函数优化的目标是优化mcp返回结构？

A: 不一定，system-prompt的角度、或者是组合这样的深度加工
schema: tools_RAG ，目前 chatbot 动态添加 mcp servser ，这可能会导致 content 的超标
Q: 从回答质量和延迟方面考虑，写好 sys_prompt 是不是 Function Calling 比 ReAct 更好？

A: 不一定。ReAct 优点在于可交互性，用户的描述可能不准确，更需要 ReAct 多轮采集