电视剧《扑通扑通的青春》剧情简介
2026-07-05 3382148
2026-07-05 0
最近，JetBrains 正式发布了 Air 的公开预览版（Public Preview）：让多个 AI Agent 并行写代码的全新工具。
一个 Agentic Development Environment，不是给 IDE 加个 AI 聊天框，而是围绕 AI Agent 重新构建的开发环境。
对比传统的IDE 你就会很清晰：
| 传统 IDE | Air |
|---|---|
| 人类写代码，AI 辅助 | AI 写代码，人类审查 |
| AI 是「副驾驶」 | AI 是「团队成员」 |
| 一次一个 Agent | 同时多个 Agent 并行 |
| Agent 直接改主分支 | Agent 在沙箱中工作 |
在深入Air的特性之前，我们需要先理解：为什么需要一个专门的 Agent 运行环境？
对于GitHub Copilot、Cursor 再到各种 Agent 工具，你一定遇到过这些问题：
痛点一：Agent 碎片化
你可能同时在用 Cursor 写业务代码、用 Claude 做架构设计、用 ChatGPT 查问题。每个 Agent 都是独立的「信息孤岛」，它们之间无法共享项目上下文。你需要反复复制粘贴代码片段、手动描述项目结构。
痛点二：只能串行，不能并行
当你有一个需求需要同时改网络层、UI 层和测试层时——即使 AI 30 秒就能写完一个文件——你也只能一个接一个地排队等。这就像有一支 10 人团队，但只允许一个人干活。
痛点三：上下文窗口的「断崖」
大模型有 token 限制。当项目复杂到一定程度，Agent 对项目的理解就不可避免地「降级」。传统方案要么全量塞进去（超了），要么只塞当前文件（不够）。
痛点四：代码安全失控
现有工具中，Agent 的修改直接落在你的工作目录里。一旦改错了，你需要手动 git stash 或者 Ctrl+Z 多次回退。如果同时跑两个 Agent，产出的代码可能互相冲突覆盖。
痛点五：审查成本高
Agent 生成了 200 行代码，你需要逐行阅读来判断质量。但你无法快速看到「它到底改了什么」，没有 Diff 视图、没有冲突提示、没有一键回退。
IntelliJ IDEA 加了 AI Assistant，VS Code 有 Copilot 插件——但本质上，这些方案都是在已有 IDE 架构上「叠加」AI 能力。
问题在于：传统 IDE 的架构是为人类单线程操作设计的——一个编辑器、一个终端、一条主分支。当你想让多个 Agent 同时工作时，这套架构就成了瓶颈：
不在旧架构上打补丁，而是从零设计一个「Agent-first」的开发环境：多Agent并行，每个 Agent 拥有独立的任务卡片和执行状态
你可以同时启动 Junie（JetBrains 自研 Agent）、Claude Code、OpenAI Codex 等多个 Agent，让它们各自处理不同的子任务。
实际场景：
需求：为 App 新增「收藏」功能Air 拆解为 3 个子任务：
Task A → Junie：写 Room 数据库 DAO + Repository
Task B → Claude：写 Compose UI + ViewModel
Task C → Codex：写单元测试 + 集成测试三个 Agent 同时开工，互不干扰。
传统方式下你需要等 A 完成才能开始 B（因为它们在同一个文件系统里操作），但在 Air 中，总耗时从「A+B+C」降为「max(A, B, C)」。
每个 Agent 工作在独立的 Git Worktree 中：相当于每个 Agent 有自己的分支和文件副本。
再配合 Docker 容器，Agent 可以自由执行命令（跑测试、启动服务、编译代码），不会影响你的主工作区。
这意味着：
gradle build 不会阻塞你的本地构建Air 继承了 IntelliJ 平台 26 年积累的代码索引能力：AST 解析、类型推导、依赖图、调用链分析。
这些信息以结构化的方式注入给 Agent，让它「真正理解」你的项目——而不是简单地把文本塞进上下文窗口。
对比现在的Agent方案：
| 方案 | 上下文策略 | 效果 |
|---|---|---|
| Copilot Chat | 当前文件 + 手动 @file | 简单场景够用，复杂项目不够 |
| Cursor | 全局 embedding 索引 | 能找到相关文件，但缺乏语义 |
| Air | AST + 类型 + 依赖图 + 编译信息 | Agent 理解项目结构如同 IDE 本身 |
Air 支持 BYOK（Bring Your Own Key）。同一个任务执行到一半，如果你觉得当前 Agent 产出不满意，可以热切换到另一个模型继续，同时会话上下文不丢失。
这在实践中非常有用：
所有 Agent 的产出都以 Diff 形式呈现在审查面板中。
你可以：
开发者始终保有代码主权——AI 不会直接修改你的主分支。
| 维度 | Cursor | Windsurf | 多终端方案 | Air |
|---|---|---|---|---|
| 定位 | AI-native 编辑器 | AI 编辑器 | 手动组合 | Agent 运行环境 |
| Agent 数量 | 1 | 1 | N（手动） | N（统一管理） |
| 隔离方式 | 无 | 无 | 手动 stash/branch | Git Worktree + Docker |
| 上下文来源 | Embedding 索引 | 文件索引 | 手动复制 | AST + 编译信息 |
| 审查方式 | Inline Diff | Apply | 手动比对 | 统一审查面板 |
| Agent 切换 | 切换模型需重新对话 | 固定模型 | N/A | 热切换，上下文保持 |
| 平台支持 | 全平台 | 全平台 | 全平台 | 仅 macOS（当前） |
| 价格 | $20-40/月 | $15-50/月 | 各 Agent 费用之和 | Public Preview 免费 |
核心差异：
两者不一定互斥。你完全可以用 Cursor 做日常编辑，用 Air 做大型重构、多模块并行开发。
下面来看下该如何实际使用Air
Air 的项目打开方式与 IntelliJ 类似——选择项目根目录即可。Air 会自动：
在 Air 的 Task 面板中：
1. 点击 "New Task"
2. 描述你的需求（自然语言）
3. Air 自动拆解为子任务（你可手动调整）
4. 为每个子任务分配 Agent
5. 点击 "Run All" → 并行启动
任务完成后，进入 Review 面板：
整个流程对 Git 操作者来说非常直觉：每个 Agent 的产出就像一个 Pull Request。
Air 仍处于 Public Preview 阶段，使用前需要了解以下限制：
目前仅支持 macOS（Apple Silicon）。Windows 和 Linux 支持还在开发中。对于以 Windows 为主力开发机的团队，暂时无法使用。
Air 基于 Fleet 技术栈构建。Fleet 在公测期间以「性能不稳定」「功能缺失」著称，最终被砍。虽然 Air 团队声称已大幅重构底层，但 Fleet 的技术债是否完全清理干净，仍需时间验证。
目前 Air 对 Android 项目的支持集中在 Kotlin/Java 代码层面。以下场景的 Agent 效果仍待验证：
对于有合规要求的企业，目前不适合在生产流程中引入 Air。
JetBrains 做 Agent 运行环境有两个独一无二的优势：
Air 的逻辑是：如果 AI Agent 是未来的「劳动力」，那么 JetBrains 要做的不是被 Agent 替代，而是成为 Agent 的「工作平台」。
短期来看（6-12 个月）
长期来看（1-3 年）
Air 押注的方向是对的：AI Agent 需要一个比「聊天框」更好的运行环境。
但当前版本离「好用」还有距离。建议先关注、体验、储备认知，不必急于在生产项目中 all-in。
