我在 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 在长会话里开始不工作,或者自己去写脚本来代替调用,很可能是提示词在上下文里被淹了。

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

相关推荐
JouYY1 小时前
聊一下多 Agent 编排架构的应用实践
架构·llm·agent
米小虾2 小时前
Loop Engineering —— 循环的设计与自主执行
人工智能·agent
米小虾3 小时前
Harness Engineering —— 系统的安全护栏
人工智能·agent
武子康5 小时前
调查研究-200 llama.cpp b9754:一次很小但很关键的 Agent 工具调用修复
人工智能·agent·llama
武子康5 小时前
调查研究-199 MCP Zero-Touch OAuth:为什么它是 MCP 进入企业生产的关键门槛?
人工智能·agent·mcp
用户947850529275 小时前
Skill用得好,下班走得早:一文讲透Skill的结构与设计
agent
leeyi6 小时前
Batch 处理:并发控制与可中断批处理
aigc·agent·ai编程
user4465117917916 小时前
从 XAgent ToolServer 看有状态 Sandbox Tool 的架构设计
mcp
冬奇Lab15 小时前
Workflow 系列(01):基础理论——三种执行模型与 Anthropic 5 种模式
人工智能·agent·工作流引擎
冬奇Lab16 小时前
每日一个开源项目(第143篇):page-agent - 纯 JS 的网页 GUI Agent,无需截图、无需插件、无需后端
前端·人工智能·agent