IDE 不够用：构建 Agentic 开发环境 ADE

IDE 组织的是单个人员的代码工作：编辑器、终端、调试器、Git 和扩展。Agentic Development Environment（ADE）还必须组织自主 Agent 的工作——包括它们并行运行、使用不同模型、以及在数天内逐步构建上下文等场景。

这一差异听起来只是语义上的，但当你真正去构建这个产品时就会发现问题所在。在将 AuraPunk 打造成 ADE 的过程中，问题不再是「我们如何在编辑器里塞一个 AI 聊天」，而是变成了：

如何将 Agent 执行转化为可以规划、恢复、审计和审查的工程工作？

本文只涵盖这个问题的本地侧：工作流、状态、内存和工具集成。

IDE：一场会话。ADE：一套工作系统

在传统 IDE 中，大量状态存在于本地会话中：打开的文件、终端、当前分支、编辑器历史记录。关闭终端可能终结操作上下文。换一台机器就创建了另一个会话。

在 ADE 中，工作需要超越会话的生命周期。一张卡片不再只是一个可视化的看板条目，而是成为连接意图、执行和证据的单元：

card / SPEC
  ├── goal and acceptance criteria
  ├── context and decisions
  ├── selected agent and model
  ├── execution, logs, and artifacts
  ├── result and optional review
  └── retrievable memory

这听起来很简单，但它改变了整个界面。用户不需要记住是哪个终端开启了某次调查。他们应该能够检查一张卡片，了解需求是什么、Agent 做了什么、哪里失败了、以及接下来要做什么。

并行不是「跑好几遍」

同时运行多个提示词很容易。真正的问题是在不丢失任务、上下文和结果之间关系的前提下运行多个 Agent。

ADE 需要将工作拆分成足够独立以并行运行、但又足够关联以确保重要决策不消失的单元。在 AuraPunk 中，卡片和 SPEC 在执行开始前就为工作赋予了身份。

收益并非来自给同一个任务分配每个 Agent，而是来自将拆分显式化：

• 一个 Agent 调查代码库；
• 另一个提出或实现一个有边界的变更；
• 再一个编写或验证测试；
• 更强的模型处理模糊决策；
• 更经济的模型处理重复的、规格明确的工作。

ADE 的职责是保持这些执行与同一个项目关联，而不是假装每个 Agent 具有相同的成本、能力或可靠性。

选择 Agent 是工作流的一部分

IDE 通常是集成工具。ADE 需要编排它们。

AuraPunk ADE 设计为与 Codex、Claude Code、OpenCode、Qwen Code、Gemini CLI、Command Code 和 Antigravity CLI 配合工作。目标不是用一个通用的「AI」按钮隐藏它们之间的差异。

每个 Agent 都有自己的画像：推理质量、速度、成本、可用工具、交互风格、以及在代码库中操作的能力。选择应该在卡片层面基于任务来进行。

根据工作类型选择合适的 Agent 和模型——而不是所有事情都用最贵的 Agent。

高风险重构、探索性研究、测试生成和机械性变更并不需要相同的 Agent、模型和监督组合。ADE 应该让这种选择可见，并在后续可追溯。

内存不是更大的上下文窗口

大的上下文窗口有帮助，但它不能解决项目连续性问题。它是临时的、昂贵的，并且无法可靠地区分重要决策和一次性对话。

本地 ADE 需要分层保留内存：

• vector memory：从语义上检索相关内容；
• semantic memory：保存已固化的事实、决策和偏好；
• graph memory：模块、任务、依赖和决策之间的关系；
• SPEC 和卡片：作为人机均可读取的操作内存。

这些形式的内存并不互斥，它们回答的是不同的问题。

关键不在于保存所有内容，而在于在 Agent 开始下一步时检索重要的内容——并且让这些知识靠近项目，而不是散落在短暂的聊天记录中。

Integration Guard：集成不能变成无限制执行

编码 Agent 并非孤立工作。它们需要 CLI、Git、仓库、文件、模型、本地工具，有时还需要 MCP。这使得集成层成为架构的核心部分。

在 AuraPunk 中，我们将这个边界称为 Integration Guard：将集成转化为明确能力而非隐式无限制权限的规则。

原则很直接：

integration discovered
  → capability verified
  → command/action allowed
  → execution recorded on the card
  → result available for review

在实践中，这需要做出传统 IDE 可以推迟但 ADE 不应该推迟的决策：

• 在提供操作前检测工具是否已安装且就绪；
• 用有用的语言解释缺失的需求，而不是暴露一个进程异常；
• 分离工具发现、配置和执行；
• 将操作限制在打开的仓库和任务范围内；
• 记录哪个工具和版本执行了工作；
• 让用户控制修改文件、Git 状态或配置的操作。

Integration Guard 的存在不是为了减少 Agent 的自主性，而是为了让自主性可见且可预测。

人类审查是可选的；可追溯性不是

「Human in the loop」经常变成一个强制队列并摧毁速度优势。替代方案不是移除控制，而是让审查变成可选的和情境化的。

有些卡片可以自动推进：文档更新、隔离组件的测试、机械性变更。另一些值得明确审查：架构变更、契约变更、敏感代码、或影响多个 Agent 的决策。

不可省略的是可追溯性。对于每次执行，ADE 应该能够回答：

• 哪个 Agent 在这张卡片上工作过？
• 使用了哪个模型和集成？
• 有哪些上下文可用？
• 产生了哪些文件、日志和结果？
• 已经尝试过什么？
• 决策记录在哪里？

这段历史让人们能够停下来、稍后返回、继续工作，而不必从零开始对话。

什么让 ADE 不同于 IDE？

IDE 可以添加自动补全而仍然是 IDE。它成为 ADE 的标志是：将 Agent 视为开发过程的参与者，并在原生层面提供：

• 通过卡片和 SPEC 进行规划；
• 每个任务可选择多个 Agent 和模型；
• 有组织的上下文的并行执行；
• 持久的 vector、semantic 和 graph memory；
• 本地集成的护栏；
• 可审计的日志和工作历史；
• 在有价值时进行人类审查，而非作为普遍要求。

构建这些比将模型集成到编辑器中要困难。但这正是真正差异所在：从聊天会话转向一个人机和 Agent 可以共同工作且不丢失项目脉络的环境。

编辑器仍然重要。它只是不再是系统的中心了。