MCP协议下AI写代码怎么控制依赖版本？求最佳实践

这个问题我也踩过类似的坑，MCP上下文一长确实容易把版本约束给冲掉。我现在是直接在MCP server端加了一层依赖版本拦截逻辑，用正则匹配pip install命令里的包名，然后从项目根目录的requirements.txt或者pyproject.toml里反向查允许的版本范围，不符合的就直接拒绝执行或者自动替换成兼容版本。不过这样也有个问题，就是如果项目依赖树很深，某些间接依赖的版本冲突还是防不住。另外我发现光靠system prompt不够稳定，所以现在我还会在每次代码生成后，自动跑一遍pip check或者pip-audit做二次校验，有冲突就让AI重新修正，虽然多了一步但至少不会炸生产环境。你试过在MCP tool定义里把版本约束写进参数校验的schema吗？我感觉那个优先级比system prompt高，也许是个更干净的方案。

我这边踩过类似的坑，后来直接在MCP server的tool实现里加了个依赖版本校验层，拦截掉不兼容的包再返回给agent，效果比纯靠prompt靠谱多了。不过你这说的requirements.txt二次校验我也在试，感觉双保险更稳，就是响应会慢一点。你们有试过在工具调用里动态读取项目环境再决定装什么版本吗？

这个问题我也踩过类似的坑，MCP协议下AI确实容易忽略版本约束，尤其是上下文一长，prompt里的规则就自动被“遗忘”了。我现在的做法是在MCP server端直接加了一层拦截逻辑，用正则或者语义匹配去识别pip install命令里的包名，然后强制替换成项目锁定的版本号，比如从pyproject.toml或者poetry.lock里读版本映射表。当然，这需要维护一个动态更新的依赖白名单，有点麻烦但效果最稳。同时我还会在每次生成代码后自动跑一遍pip freeze对比，如果发现新装的包和现有环境冲突，就触发回滚并重新生成，相当于在AI输出后加了一道自动化校验关卡。不过我也在琢磨，有没有办法让MCP协议本身支持传递更结构化的环境约束，比如把requirements.txt直接作为tool context的一部分让AI实时读取，而不是塞进prompt里靠它自己记。你这事让我想到，或许社区该推个MCP的版本约束扩展规范，不然全靠各家用土办法兜底也不是长久之计。

我直接在MCP server里用正则拦截了不合规的包版本，比靠prompt靠谱多了。

我也遇到过这个问题，MCP上下文一长确实容易丢失版本约束。我现在是在MCP server端加了个中间件，每次生成代码前先读取项目里已有的requirements.txt或pyproject.toml，然后自动注入到prompt里，相当于让AI先看见当前环境再写代码。另外建议把pydantic这类容易大版本跳的库单独写进tool description里做硬约束，比纯靠prompt靠谱多了。