类似 VS Code 的工具难以识别项目的 Python 环境，从而阻碍了代码执行和依赖分析等关键功能。这一挑战的根源在于编辑器缺乏一种通用方法来检测项目所采用的工作流工具，或定位其虚拟环境的位置。当项目首次打开时，VS Code 无法可靠地判断用户是否偏好使用 Hatch、Poetry、uv 还是自定义方案。现有方法通常依赖于根据 pyproject.toml 进行猜测，这需要维护一个精确的支持工具列表。此外，将环境存储在全局位置或允许共享环境的工作流工具会进一步增加识别难度，尤其是在用户管理众多环境的情况下。对于存储在本地 .venv 目录中的环境，存在一种简单解决方案，可提供基础功能。然而，对于位于项目之外或存在多个环境的情况，则需要一个专用文件（如提议的 .python-envs）来列出其路径。为解决工具偏好问题，建议在 pyproject.toml 中引入 [workflow] 表，以定义工具如何以服务器模式启动，从而基于工作流服务器协议（Workflow Server Protocol）通过 JSON-RPC 进行通信。该协议允许工具向编辑器报告可用环境并管理其创建。另一种替代方案是建立 CLI 工具的命名约定，使其返回所需的环境详情。作者的动机源于希望简化所有 Python 用户的设置流程，无论其经验水平如何，通过最小化手动环境管理来实现。本努力旨在提供非 VS Code 专用的解决方案，以便其他编辑器也能采用。此类标准化的通信协议将使工作流工具超越单纯的中间件角色，实现更广泛的编辑器支持，并减少定制扩展的开发工作。