关于AI Agent+MCP 的思考过程和使用经验

背景

公司基于业务,需要一个智能机器人能整理我们的各种能力进行服务。

我们看了下其他部门使用过的解决方案,许多项目提供的机器人更像一种流程编排,基于问题进行分类,基于分类进行各项调用并且自己编写各种展示
这种方式流程固定过于死板,而且开发量大每想要一种能力可能都需要考虑整个流程的变动。

工具的使用初步探索

客户端我们就用的开源的Dify,部署比较清晰,如果你使用docker的镜像,甚至不要半个小时就可以搭建一个dify,然后在通义千问这话大模型申请一点token很快就能上手。基于这个能力后,我们可以在dify配置好一个个工具或者上述一些流程,然后dify配置一个多轮对话机器人或者agent去调用即可。Agent本身是一个能够自主决策并采取行动的软件系统,结合Function Call,它能够观察环境、使用工具,并以目标为导向执行任务。

但是还不够。为什么?因为我们想要做一个智能机器人,能够自主的分析用户意图(LLM,AGENT)并且自主调用大量的各种能力。传统 Function call 模式下,模型必须要求我们了解每个接口的参数、格式、返回结构,对于多轮分析的支持性比较差,难以处理复杂和动态变化的任务。

发现AGENT+MCP

巧了,这时候有个大牛 Anthropic 24年11月底推出一个mcp,mcp可以解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题,MCP 使得 AI 应用能够安全地访问和操作本地及远程数据,只需实现一次 MCP 协议,即可对接多个数据源和工具,从而大大降低开发和维护成本,为 AI 应用提供了连接万物的接口。他比单一的Function Calling这种函数调用更加灵活。MCP 为 AI Agent 提供了一个统一的协议,这样一个理想的“万物互联”生态系统看着很让人着迷。

对比与Function call,Funcation call是 我告诉你每一步怎么做,MCP是 你告诉我你要做什么,我去找服务。

但是当前的 AI Agent 生态关联到MCP存在许多明显问题:

  • 大多数 MCP 服务器都是 Web API 的简单包装器
  • 功能接口可能不完整,具体取决于开发人员的实现
  • 手动创建 MCP 接口非常耗时且容易出错
  • 缺乏标准化的转换流程

我们使用的方案是解析通用Open API 文件成为一个个mcp server的端点

基于 OpenAPI 架构生成完整的 MCP 服务器,使现有的 RESTful API 立即与 AI Agent 调用标准兼容,确保所有 API 端点和功能都已正确映射,无需修改原始 API 实现即可获得 MCP 兼容性,遵循 MCP 规范以确保与各种 AI Agent 框架兼容

解析代理openapi为mcp

结果

目前基于现在的Agent+MCP,我们基本不需要对框架侧或者流程测做大规模变动了,需要的能力只需要更新迭代OPEN API即可,如下是我们的流程,目前其实只靠最下面的Agent即可完成整个流程的推理,他可以自主调用工具,如果工具有依赖,他也会自动进行依赖性调用并获取相关信息,比如我们要查某个团队(说名字)的效能问题,查效能接口需要团队id,他需要先查团队信息接口,自主获取和匹配这个名字的团队的id是什么

注意

目前我们的Agent基本可以达到95%的准确率,这得益于目前仅集成工具还比较少,即使这样偶尔还是会感觉他在胡说八道,agent或者因为对话需求不明确或者因为content过多,他的分析存在瓶颈
对于我们做大规模服务,我的建议如下

  • 在可靠性方面,拆分为多个小 Agent(自己评估规模),各自处理单一职责
  • 记忆和性能,我建议在流程中提炼固定的信息,但一定要精简,尽量减轻agent的负担,让它处理更重要的事情
  • mcp的定义,数据精简和定义清晰是agent能够精准找到工具的诀窍之一
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容