10 月 1 日，JetBrains 在自己的 AI 博客上开了 Air 的 EAP。
Air 不是一个新的 AI 编程工具。官方在博客里说它是 "a conduit for agents and subscriptions you already use"，也就是你正在用的那些 agent 的通道。安装包里一个 agent 都不带，Codex、Copilot、Junie、Cursor 谁都能接进来。
同一篇博客里还有另一句话，更值得停一下：
"As agents do more of the work, verifying and owning the result becomes the hard part, and that is what the IDE is for."
agent 干得多了，验证并为之负责就成了难的那部分，IDE 存在的意义在这儿。说这话的是个卖 IDE 的，但他把话说到了点子上：活分出去容易，收回来难。
并行会话把产量推上去，也把账摊开了
Air 的功能列表不长，方向都是一个：让多个 agent 会话同时跑。会话可以并行，跨项目有统一视图，每个会话花了多少钱也能看到。要动主干代码，先在临时 worktree 里隔离跑，验完再 cherry-pick 回去。
这套设计背后的假设很直白。JetBrains 在博客里写："Agentic development is becoming the norm, and an IDE that keeps agents at arm's length will struggle to stay relevant." 意思是同时开三四个会话正在从个别人的玩法变成常态，把 agent 挡在门外只会被甩开。
产量确实上去了。麻烦在上去了之后，坐在屏幕前的那个人面对的是什么。
四个并行会话交回四份改动，每份单看都挺合理：它们来自不同会话，动过不同文件，提了不同的 commit。你真正要判断的不是某一段代码写得好不好，而是这四份东西合在一起，系统还对不对。前一个判断有编译器帮你，后一个没有。
JetBrains 那句话里用了两个词，verifying 和 owning。验证是技术动作，负责是人的动作，后者没有工具能替你完成。
难的位置往上游移了一格
Air 的定位里还有一句 "ships with no agents installed"。一个不预装 agent 的容器。读起来像克制，不绑供应商，把选择权留给用户。但它同时说明，承载 agent 的这一层开始中立化之后，工具之间的差别就只剩下谁来干活、干完的活长什么样。
JetBrains 说要接管验证这件事。可是验证得有对象。如果产物是一串聊天记录，那验证就只能靠人脑重新过一遍逻辑，再靠记忆去对之前是不是这么说的。这跟从前开几个窗口看代码没有本质区别，只是窗口变多了，窗口里的东西还会被自动压缩。
验收的前提，是产物留在工程里
飞算 JavaAI 的智能会话里有一条按环节推进的指令链：需求分析、前后端设计、前端开发、后端开发，再加一条把四步串起来的全栈。
这条链有个不太显眼、但跟验收直接相关的特点：每走一步都往项目里落东西。需求分析产出需求文档和业务设计文档，前后端设计产出技术栈决策、数据库设计、接口设计。这些文件写进项目工作区的 docs 目录，跟源码在同一个仓库里，能提交、能 review、能回溯。
这跟「agent 帮你写代码」是两码事。它决定的是你要验收一份改动时，手上有没有一张对阵图。接口改了什么，docs 里的接口设计文档对得上；表结构动了哪几处，数据库设计文档在那儿。某个字段当初为什么这么定，不用猜，它是因为被写下来才落地的，出处就在工程里。
会话窗口里那段记录回答的是「当时我们聊了什么」，docs 里那几份文档回答的是「这个系统现在是什么样」。验收要的是后者，它得能被打开、被比对、被下一个人读到。而前者会随对话被压缩、被新会话覆盖，过几天连打开它的人都不确定还在不在。
并行会话真正改的是什么
回到开头四个会话的场景，Air 改的其实不是「写」，是并行度。以前一个人一天改一个模块，现在四个会话同时推，一天能碰四个。可验收没法并行，你的判断力只有一份，得一个一个过。产量翻倍，判断力还是原来那么多，这个缺口就是 JetBrains 说的那个 hard part 落下的地方。
大部分 agent 交付的成果停在会话里。你在对话框里来回几轮，代码写出来了，文件改了，然后这段过程就留在对话里。第二天想查一句「当时这个字段为什么这么定」，往上翻几十屏，翻到的大多是压缩过的摘要。
传统开发里接口设计是人写的，写的时候脑子里装着业务，所以文档没更新，人也能自己兜住。agent 进来之后，中间那层「人记得的上下文」没了，它只按读到的写。这时候上游产物有没有落下来、落在哪，就从「文档习惯好不好」变成了「验证做不做得成」。
验证能不能做，取决于被验证的东西是不是留在了能被验证的地方。会话记录不行，工程里的产物才行。
并行会话把瓶颈推到了判断上：四份改动合起来对不对，改动背后的决定站不站得住。判断要有依据，依据得是这个工程自己长出来的东西，而不是某个对话窗口里已经被压缩过的一段记忆。
边界
Air 现在还是 EAP，2006.3 版本或者插件商店都能装，免费档给的是 Junie Lite。它在多会话并行、成本可视、worktree 隔离上的设计是完整的，但 EAP 意味着接口和形态都还会变，现在不适合直接压到生产流程上。
还有一句得说清楚：Air 解决的是把 agent 管起来，不解决怎么知道它做对了。这两件事常被混着谈。前者是容器，后者是验收标准，容器做完了，标准还得有人定。
另外，产物落进 docs 也不等于验收自动变轻松。文档一样会过期，一样会跟代码对不上。它的价值在「有据可查」四个字上，至少在要核对的时候，存在一个能往回查的版本，而不是连当时怎么定的都无从确认。
你们团队现在同时开着几个 agent 会话？这些会话产出的东西，是落在工程里有据可查，还是散在各自的聊天框里？
