我在 Trae 里用 UML-mcp-renderer 画图,发现了 MCP 跟 CLI+Skills 的区别

背景

最近在忙毕业设计,用 Trae 作为开发环境。我接了一个叫 UML-mcp-renderer 的 MCP,用来在对话里生成和修改用例图、类图、架构图、部署图。

一开始用着挺正常的,但后面反复修改的过程中,我发现了一个很明显的问题。

MCP 在长对话里的问题

在一个全新的对话上下文里,没被各种结果污染的时候,用 MCP 是没有任何问题的,也能准确地为我生成 UML 图。

但在我反复修改、和各种环节进行之后,我发现如果我继续保持这个会话,那些 MCP 全量加载的提示词就会被干得稀碎。模型上下文窗口占满的时候,它注意力稀碎,后面根本无法继续为我正确调用 MCP。

我主动让它使用 MCP,它也会当看不到,或者说做不了,然后就自己去写脚本、写 PlantUML 代码来生成图,而不是调用 MCP。

后来我换了一个新对话,就恢复正常了。

改造成 CLI+Skills 之后的对比

同样的这个 MCP,我把它另外改造成了 CLI+Skills 渐进式披露的形式。

然后用同样的情况去用------在长对话之间、反复修改、各种环节混在一起。

结果发现,几乎在什么上下文时期,或者在多长的对话之间,它都能很好的继续为我生图。没有出现之前 MCP 那种"当看不到"或者自己写脚本糊弄的情况。

我的结论

这次经历让我比较清楚地看到了 MCP 和 CLI+Skills 在实际使用中的区别。

不是说 MCP 本身有问题,而是很多 MCP 的实现方式是全量加载,把工具描述、提示词一股脑塞进上下文。在短对话里没问题,但上下文一长、信息一多,这些东西就被淹掉了。模型注意力有限,当上下文中其他内容占了大部分窗口,它就不再能有效关注到 MCP 的调用方式。

而 CLI+Skills 的渐进式披露方式,工具描述在不需要的时候很轻量,需要的时候才展开细节。这样无论上下文多长、多乱,工具调用这一块始终是清晰的,模型能一直正确使用它。

总结

  1. 新对话能恢复正常的 MCP 问题,说明不是 MCP 本身坏了,而是上下文管理的问题。

  2. 同样的功能,用 MCP 全量加载和用 CLI+Skills 渐进式披露,在长对话里的表现差距很大。

  3. 如果 MCP 在长会话里开始不工作,或者自己去写脚本来代替调用,很可能是提示词在上下文里被淹了。

这就是我这次在画毕业设计图的过程中发现的一个实际区别,记录下来供参考。

相关推荐
七夜zippoe23 分钟前
Agent 测试实战:单元测试、集成测试与 Mock LLM 策略
ai·单元测试·集成测试·mock·agent
第404块砖头1 小时前
Spring Boot 4.1 + Spring AI 2.0:我如何用 Java 微服务把 RAG、知识图谱和 MCP 协议串成一个 Agent 平台
知识图谱·知识库·graph·rag·mcp·spring boot 4.1·spring ai 2.0
xrlfreedom2 小时前
MCP 面试高频考点:把知识库 RAG 封装成 Tool 时,提示注入防护与人机协同确认怎么答?
mcp·提示注入防护·人机协同确认
情 九11 小时前
MCP 实战 06:把 HTTP 接口接成工具,让 AI 帮你查数据
人工智能·网络协议·http·mcp
素男12 小时前
两个月不是六十天
人工智能·agent·self-becoming·ai长期记忆·ai自我介绍
lgcgkCQ15 小时前
【AI 转型实战 1】SpringAI 入门:搭建基础大模型对话能力
java·ai·agent·rag·spring ai·mcp·langchain4j
vilya15 小时前
Agent 语音引擎换心记:从「够用」到「稳且好」
人工智能·agent
goehou15 小时前
ReAct 循环跑偏的三种样子,以及怎么在工程上兜住
llm·agent·react·工具调用·工程实践