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

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

本人的代码实践

https://github.com/ceilf6/word-MCP-agent/commit/45c7df3908be412da5e362d6da011ab530a56a58

• 传统智能体架构
  Agent = Model + Context + Tools

  现在 Tools → MCP 进行规范

• MCP 改变了什么

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

实践

AgentScope 1.0 with MCP

1. 连接高德 MCP Server
2. 创建 ReAct - 思考+行动的循环
3. 对话

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

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

1. 幻觉
   优化 prompt”不要做任何假设”
2. 参数结构化

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

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

（改进 word-MCP-agent ：64964fc86909c14a0646463196c165a58ca9736e；25bf287b509617af38e76d70a4570d19c8f49da9）

• 问题：坐标误差

MCP质量控制

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

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

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

AgentScope

显式操控 client 的生命周期

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

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

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

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

需要一个优雅的、简洁的

解决方案

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

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

展望

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

• 模型训练
• 自我学习、演化
• 长期记忆

QA

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

   A: 肯定的，开发效率&开发效果

2. Q: mcp函数优化的目标是优化mcp返回结构？

   A: 不一定，system-prompt的角度、或者是组合这样的深度加工

3. schema: tools_RAG ，目前 chatbot 动态添加 mcp servser ，这可能会导致 content 的超标

4. Q: 从回答质量和延迟方面考虑，写好 sys_prompt 是不是 Function Calling 比 ReAct 更好？

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