PyCharm为AI代理引入实时Jupyter内核，运行成本降低12%
如果你曾把 notebook 工作交给 AI 智能体，你应该知道结果通常是什么：它往往会弄坏你的 .ipynb，在运行一结束就丢掉你训练好的模型，或者在长时间任务中发呆空转、白白烧掉预算。
为了解决这个问题，我们推出了一款全新的 Jupyter skill。它直接内置于 PyCharm，让 AI 智能体在实时 Jupyter 内核中工作，而不是把任务交给子进程、导致进度丢失。这一项改动意味着状态可以在单元格之间持久保留，.ipynb 不会损坏，长任务会一直等待执行完成，而不是反复检查、浪费宝贵的 token。
PYCHARM 的 JUPYTER SKILL
一个实时内核让 Opus 比 shell 模式更省钱。比 shell 便宜 12%
Claude Opus 5，12 个机器学习任务
内核 59.09 美元
Shell 67.06 美元
12 个机器学习任务
98% 缓存读取
状态在单元格之间持久保留
对 Opus 来说，内核模式比 shell 模式更便宜
我们测试了 Jupyter skill 的效率，比较了智能体在解决十二个不同机器学习问题时的表现。我们比较了三种模式：完全使用 bash、完全通过 Jupyter skill 使用内核，以及两种混合使用。
虽然智能体在每种模式下都能解决全部十二个任务，但每种模式的成本有所不同。对于 Claude Opus 5，通过内核工作花费 59.09 美元，而通过 shell 需要 67.06 美元——大约便宜 12%。
这里有一个反直觉的地方：内核模式使用了更多 token，但成本却更低。这是因为它能保持提示缓存的热度。它 98% 的输入来自缓存读取，而 shell 模式只有 82%——而缓存读取的成本仅为新建缓存的 1/12。
我们为什么这样做
Notebook 是编码智能体最容易出问题的地方。大多数 AI 工具会把 .ipynb 当作纯文本文件：它们直接手工修改 JSON（然后把它弄坏），再通过运行子进程来执行代码。智能体一旦启动子进程，内核状态——训练好的模型、加载的数据框、所有 import——都在子进程里，进程一退出就消失。智能体无法检查它、保存检查点，也无法复用。输出会一直缓冲到运行结束，所以进度完全不可见，长时间的训练任务只能被动等待——直到连接超时都看不到任何东西。
我们问了一个非常自然的问题：如果智能体通过 IDE 操作实时 Jupyter 内核会怎样？
于是我们构建了新的 Jupyter skill，把 PyCharm 自己的 notebook 智能能力——包括 notebook 模型和实时内核控制——暴露给智能体。它通过一个 MCP 包装器 execute_tool 实现，覆盖了核心 notebook 操作，包括创建、编辑和读取 notebook；运行单元格；等待长时间运行；探测正在运行的内核；以及控制其生命周期。这个 skill 会告诉智能体何时以及如何使用这些操作。
工作方式
智能体：
- 直接在内核中运行。 智能体将真正的 Python 代码写入单元格并运行，因此变量、模型和数据可以在单元格之间持久保留——就像人类在 notebook 中操作一样。
- 等待而不是轮询。 不会按固定计时器轮询并在每次空转调用时重新计费，
wait_cell_execution会一直阻塞，直到单元格完成（或达到安全上限），然后把控制权交回。这有助于减少空闲往返。 - 只读取新增内容。 当长时间运行持续输出时，智能体读取的是增量——也就是自上次检查以来新产生的那些行——而不是每次都重新发送整个不断增长的单元格输出。
这项 PyCharm 功能需要 JetBrains AI 订阅才能使用。
方法论
我们使用了 MLGym 机器学习基准测试中的十二个任务——包括分类、回归和强化学习问题，每个任务都要求智能体加载数据、训练模型、评估并保存结果。我们用 Claude Opus 5 和 OpenAI 的 GPT-5.6 模型（Sol 和 Terra）通过 Codex 运行这些任务。我们比较了三种模式：只使用内核、内核加 shell 混合使用、以及只使用 shell。由于这些基准任务会把测试标签暴露给智能体，我们将成本——而不是准确率——作为可靠的评估信号。
出于透明性，需要说明一个注意事项：审计发现，十二个任务中有一个（Titanic）存在污染——智能体能偷看测试集，而且每个智能体都利用这一点选择了最优模型作为最终答案展示。Titanic 对于 LLM 来说是一个众所周知且简单的任务，而且这个问题在三种模式下都一致出现，所以不会扭曲对比结果。即使剔除 Titanic，结论依然成立——对 Opus 来说，内核模式仍比 shell 模式便宜 10%（56.34 美元对比 62.65 美元）。
结果
成本优势取决于模型和任务。对于 Claude Opus，在长时间、有状态的任务上最明显；而在短任务以及 Codex 模型上，shell 模式更便宜——因为 Codex 模型本身就已经高效利用缓存，所以在这些场景下，这个 skill 的价值体现在工作流上，而不是成本上。
仍然存在的不足
有两件事值得注意：
- 告诉智能体保存产物。 在一次运行中，智能体训练出了一个很好的模型，但在结束前从未保存提交文件。你可以很容易避免这一点：在上下文文件（例如
CLAUDE.md）或 skill 中明确添加指令，让智能体在达到目标指标后立即保存任何模型。 - 有些任务仍然超出智能体的能力。 在困难任务上，智能体的方法不足以达到标准。这是真正的机器学习难题，不是工具差距——某些复杂问题仍然需要人类参与。
这个 skill 消除了机械性浪费，但不会把一个薄弱的方法变成强大的方法。
想试试吗？
打开 PyCharm 2026.2.1 中的 AI 聊天窗口，让智能体在 notebook 中工作——创建 notebook、加载数据集，或者启动一次训练运行。智能体会直接操作内核，而不是在 shell 中运行命令。
你还可以直接在 IDE 中浏览和管理 skills，通过外部注册表（比如公共 GitHub 仓库）扩展内置库，或者让 PyCharm 导入你已经为 Claude Code 或 Codex 配置好的 skills。