半年前，我在《AutoDev Next》那篇文章中介绍了 AutoDev 的下一代架构，其中一个核心方向就是：多端支持。 之后，一直在忙项目交付——从 AI 参与遗留系统现代化，到做 AI 辅助的软件工程培训。一直到国庆，才终于有整块时间继续推进 AutoDev 的演进。

这段时间里，我不断做 POC，验证不同技术模型的可行性，尝试新的交互与架构思路。直到最近，新的重构方向基本成型，并成功跑通了关键链路，也顺手 Vibe Coding 了一波。

TL;DR：代码：https://github.com/unit-mesh/auto-dev （似乎是目前国内最好的开源 AI 编程工具）

欢迎来一起加入演进。

基于 KMP + Compose 的 AutoDev 多平台重构实践​

新的 AutoDev 架构如下：

PS：之所以叫重构，是我们在 AutoDev 上已经有大量的经验，尽管架构上是紧耦合的，但是利于 AI 阅读后重写，比如，我们的 DevIns 语言。 在这几个月里，我也尝试使用 Rust/TypeScript/Kotlin 来开发的 CLI，但是发现多数时间在写之前的重复性代码。所以，基于 KMP （Kotlin Multiplatform）是一个更合理的架构。

在新的架构里，MPP-Core 是我们的核心，基于 Kotlin 的 Multiplatform 技术，我们构建出了 JS 和 JVM 版本的两个核心接口和实现，基于 这两个实现。基于多平台的 Core + Compose UI，我们就可以构建出：

• 基于 JS 版本的 @autodev/cli 的 CLI （Command Line Interface）和 TUI （Terminal UI）版本
• 基于 JVM 版本的 AutoDev IDEA，AutoDev Desktop 和 AutoDev Android，以及未来的 AutoDev iOS

而为了在当前 AI Token 还不便宜、Agent grep 还不理想的情况下，我们还是构建了基于 TreeSitter 的 MPP-CodeGraph，通过树和图的方式 来节省上下文，近而节省企业的成本。Codex、Gemini CLI、Claude Code 都是 AI 厂商卖 token 的，自然可以不考虑那么多。

CodeGraph：基于树和代码图的上下文压缩引擎​

尽管 Gemini CLI 和 Claude Code 提供了近似无限上下文的能力，但是对于重构等一系列复杂问题的分析，它们依然非常不靠谱，而且非常贵。 所以，我们还是要引入 CodeGraph 来解决复杂问题下的代码搜索等问题。而 TreeSitter 是目标 “跨平台” 最好的方式之一，毕竟 wasm + binary 可以运行在各种平台上。

AutoDev IDEA：核心能力即 MCP 能力​

在新版本的 IDEA 里，MCP 已经是内置的能力，而我们还是预期 AutoDev 作为 MCP 服务端，来为其它的 Agent 提供服务。

为什么是 AutoDev Desktop 和 AutoDev Android ？​

半年前，我一直在思考如果做一个新 AI IDE 我们是否需要语法高亮，是否需要代码跳转，AutoDev 是不是优势会越来越小。直到，最近的新版本的 Cursor 给出了一个答案，独立 UI 下的 Agents 模式。在简单的任务下，我们并不需要一直坐在电脑前面，比如我在 iPad 上用 VNC Viewer 来看电脑上的进度， 并可以一边看娃。

既然如此，Android 和 iOS 版本就更有意义了，你可以从踏上地铁、公交车的时候，就可以远程 Vibe Coding。然后到了公司，就可以美滋滋地去 吃个早饭（修 AI 的 bug）。

毕竟，Android 上可不写不了代码。

用 Compose 重塑 AutoDev 的界面与交互​

在几个月前，在和 @iptton 尝试使用 Intellij Compose 构建了一个新的 AutoDev IDE UI 之后， 我也尝试了在 2025.2 的版本 IDEA 上 Vibe Coding 了一个新的 UI。显然，与 Swing 相比，有大量语料的 Compose 表现得更加稳定和可靠，不会 像 Swing 报一堆错误。

既然，我们有了更好的 Vibe Coding，那传统的 IDE 交互方式是不是就不需要了，非专业人士只需要一个聊天界面，以及可以实时预览和交互的 UI 就行了？

MPP-Core：AutoDev 的跨平台核心引擎​

如下是我们去年的 AutoDev 架构图，你可以看到在不同平台（JetBrains、VSCode）上的架构差异：

而在今天来看，尽管架构发生了巨大的变化，一切都围绕着 Tool 和 Agent：

我们可以通过 Tool 接口和抽象很好地剥离平台间的差异，进而把各种能力都放在 core 上，进而更好地实现跨平台能力：

近而，我们就可以构建出如上图所示的 AutoDev CLI。

欢迎加入 AutoDev 的多端编程世界​

作为一个刚完成 POC 的版本，我们依然有大量的工作要做。

如果你对 AI 编程、跨平台 Agent、或者像 AutoDev 这样前沿的多端架构感兴趣，无论你是开发者、研究者，还是想玩玩 Vibe Coding 的爱好者，都欢迎加入我们！

我们在 GitHub 上持续更新代码、分享实践经验，也期待你的反馈、PR、甚至新点子——让 AutoDev 的多平台之路走得更稳、更远。

在 AI 编码助手快速发展的今天，每个工具都有自己的集成方式。为了解决这个问题，我们在 AutoDev 中实现了对 ACP (Agent Client Protocol) 的完整支持，让用户可以在同一个 IDE 中自由切换和使用多个 AI 代理。

什么是 ACP？​

ACP (Agent Client Protocol) 是一个开放协议，旨在标准化代码编辑器/IDE 与 AI 编码助手之间的通信。它允许任何支持 ACP 的 AI 代理在任何支持 ACP 的客户端中无缝工作。

想象一下：

• 你可以在 IntelliJ IDEA 中使用 OpenCode
• 在 Zed 中使用 Kimi
• 在 Neovim 中使用 Claude Code
• 所有代理都使用同一套标准协议

为什么需要 ACP？​

问题：碎片化的生态​

目前的 AI 编码助手生态存在严重的碎片化问题：

Cursor → 只能用 GPT 系列
GitHub Copilot → 绑定 VSCode 体验最佳
JetBrains AI → 只在 JetBrains IDEs 中可用
Claude Code → 需要特定客户端

每个工具都需要：

• 为不同 IDE 开发适配代码
• 维护多个版本的集成
• 用户被锁定在特定组合中

解决方案：标准化协议​

ACP 通过标准化接口解决这些问题：

┌─────────────────┐
│   Any IDE       │
│  (ACP Client)   │
└────────┬────────┘
         │ ACP Protocol (JSON-RPC over stdio)
         │
┌────────┴────────┐
│  Any AI Agent   │
│  (ACP Server)   │
└─────────────────┘

AutoDev 的 ACP 实现​

完整的客户端支持​

AutoDev 实现了完整的 ACP Client 功能，支持：

1. 多代理管理

   • 自动检测系统中已安装的 ACP 代理
   • 支持配置自定义代理
   • 一键切换不同代理

2. 协议能力

   • ✅ 文件系统访问（读取/写入项目文件）
   • ✅ 终端集成（执行命令并获取输出）
   • ✅ 多轮对话（上下文感知）
   • ✅ 工具调用（代理可以调用各种开发工具）
   • ✅ 权限管理（细粒度的操作控制）
   • ✅ 流式输出（实时显示响应）

3. 与 AutoDev 生态集成

   • 支持 MCP 服务器集成
   • 可与 DevIns 语言协同
   • 兼容 Bridge 远程代理
   • 集成本地智能体系统

架构设计​

我们的实现采用了清晰的分层架构：

IdeaAcpAgentViewModel          // UI 层：管理用户交互
    ↓
AcpAgentProcessManager         // 进程管理：智能进程复用
    ↓
ACP Protocol (StdioTransport)  // 协议层：JSON-RPC 通信
    ↓
Client/Session                 // 会话层：管理对话上下文
    ↓
JewelRenderer                  // 渲染层：实时显示结果

关键特性：

• 进程复用: 首次连接后进程保持活动，提高响应速度
• 权限对话框: 用户可以审批/拒绝每个操作
• 流式渲染: 实时显示代理的思考过程
• 错误恢复: 完善的错误处理和日志记录

支持的代理​

AutoDev 内置了常见 ACP 代理的预设配置，包括：

• OpenCode: 开源 AI 编码助手（推荐，已测试）
• Codex: OpenAI 官方代理
• Kimi: Moonshot AI 代理
• Gemini: Google AI 代理
• Claude Code: Anthropic 代理
• GitHub Copilot: 通过 ACP 使用

示例：配置 OpenCode​

1. 安装 OpenCode:

curl -fsSL https://opencode.ai/install | bash

2. 在 AutoDev 中:

# ~/.autodev/config.yaml
acpAgents:
  "opencode":
    name: "OpenCode"
    command: "/usr/local/bin/opencode"
    args: "acp"
    env: ""
activeAcpAgent: "opencode"

3. 开始使用:

• 打开 AutoDev 工具窗口
• 切换到 ACP 标签
• 选择 "OpenCode"
• 开始对话！

使用场景​

ACP 代理可以帮助你完成各种开发任务：

1. 代码理解​

用户: "@UserService.kt 这个服务的主要功能是什么？"
代理: [读取文件] 这是一个用户管理服务，主要提供...

2. 代码重构​

用户: "重构 validateUser 方法，提取重复逻辑"
代理: [分析代码] [提供重构方案] [申请写入权限] [修改文件]

3. 测试生成​

用户: "为 IdeaAcpAgentViewModel 生成单元测试"
代理: [分析类结构] [生成测试用例] [创建测试文件]

4. 代码审查​

用户: "检查这段代码的并发安全性"
代理: [分析代码] [识别竞态条件] [提供修复建议]

与 MCP 和 A2A 的关系​

AutoDev 现在支持三种互补的协议：

它们可以协同工作：

用户提问
  ↓ (ACP)
OpenCode 代理
  ↓ (MCP)
访问 GitHub API
  ↓ (A2A)
调用 SQL 优化代理
  ↓
返回综合结果

技术细节​

JSON-RPC over stdio​

ACP 使用 JSON-RPC 2.0 通过标准输入/输出进行通信：

// Client → Agent: initialize
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": 1,
    "capabilities": {
      "fs": {"readTextFile": true, "writeTextFile": true},
      "terminal": true
    }
  }
}

// Agent → Client: response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": 1,
    "agentInfo": {
      "name": "OpenCode",
      "version": "1.1.53"
    }
  }
}

流式更新​

代理可以实时发送更新：

flow {
    // 发送思考过程
    emit(SessionUpdate.AgentThoughtChunk("Analyzing..."))
    
    // 发送工具调用
    emit(SessionUpdate.ToolCall(
        id = "read-1",
        title = "Reading file",
        tool = Tool.ReadTextFile("Main.kt"),
        status = IN_PROGRESS
    ))
    
    // 发送响应
    emit(SessionUpdate.AgentMessageChunk("The file contains..."))
}

权限管理​

用户可以控制代理的每个操作：

suspend fun requestPermission(
    operation: String,
    options: List<PermissionOption>
): PermissionResponse {
    // 显示权限对话框
    val selected = showDialog(options)
    
    return when (selected.kind) {
        ALLOW_ONCE -> execute()
        ALLOW_ALWAYS -> {
            savePermission(operation)
            execute()
        }
        REJECT_ONCE -> cancel()
        REJECT_ALWAYS -> {
            savePermission(operation, denied = true)
            cancel()
        }
    }
}

开发者指南​

想开发自己的 ACP 代理？AutoDev 提供了完整的文档和示例：

最小实现​

class MyAgent : AcpServer {
    override suspend fun initialize(
        clientInfo: ClientInfo
    ): InitializeResponse {
        return InitializeResponse(
            protocolVersion = 1,
            agentInfo = AgentInfo("My Agent", "1.0.0")
        )
    }

    override suspend fun prompt(
        sessionId: SessionId,
        content: List<ContentBlock>
    ): Flow<PromptEvent> = flow {
        val message = content.first() as ContentBlock.Text
        val response = callAI(message.text)
        
        emit(PromptEvent.SessionUpdate(
            SessionUpdate.AgentMessageChunk(
                ContentBlock.Text(response)
            )
        ))
    }
}

查看完整文档: AutoDev ACP Development Guide

性能优化​

我们在实现中注重性能：

1. 进程复用: 首次连接后进程保持活动

   • 首次连接: 3-5 秒
   • 后续使用: < 1 秒

2. 流式渲染: 不等待完整响应即可显示

   flow.collect { update ->
       renderer.renderUpdate(update)  // 实时渲染
   }
   

3. 智能缓存: 缓存文件内容和代理响应

   val cache = LRUCache<String, String>(100)
   

4. 异步处理: 所有 I/O 操作异步执行

   coroutineScope.launch(Dispatchers.IO) {
       // 非阻塞操作
   }
   

测试与验证​

我们提供了完整的测试工具：

# 快速验证脚本
./docs/test-scripts/verify-opencode.sh

# 输出：
✅ OpenCode binary: /usr/local/bin/opencode
   Version: 1.1.53
✅ Config file: OpenCode configured
✅ Source code: OpenCode preset defined
✅ Testing ACP protocol: Working

✅ All checks passed!

完整测试套件包括：

• 单元测试（Kotlin/JUnit）
• 集成测试（完整协议流程）
• 性能测试（响应时间、内存使用）
• 兼容性测试（多个代理）

未来计划​

我们计划进一步扩展 ACP 支持：

1. 更多代理预设: 持续添加热门 AI 代理
2. 代理市场: 让用户分享和发现自定义代理
3. 代理组合: 支持多个代理协同工作
4. 远程代理: 通过 Bridge 支持云端代理
5. 代理评分: 收集用户反馈，推荐优质代理

开始使用​

用户​

1. 安装任何 ACP 代理（如 OpenCode）
2. 在 AutoDev 中选择代理
3. 开始编码！

文档: AutoDev ACP User Guide

开发者​

1. 实现 ACP 协议
2. 发布你的代理
3. 在 AutoDev 中使用

文档: AutoDev ACP Development Guide

总结​

ACP 协议为 AI 编码助手生态带来了急需的标准化。通过在 AutoDev 中实现完整的 ACP 支持，我们：

• ✅ 让用户可以自由选择 AI 代理
• ✅ 降低了代理开发的集成成本
• ✅ 促进了开放的工具生态
• ✅ 提供了与 MCP/A2A 的互操作性

我们相信，标准化的协议是 AI 辅助编程未来发展的关键。AutoDev 将持续投入，推动 ACP 生态的繁荣。

资源链接​

• ACP 协议规范
• AutoDev ACP 文档
• OpenCode 官网
• GitHub 仓库
• 测试报告

欢迎在 GitHub 上提交 Issues 和 PR，一起完善 AutoDev 的 ACP 支持！

当下大多数 AI 编程助手，无论是 Copilot、Cursor，还是各种类 AutoGPT 项目，本质上都存在一个问题：AI 编码助手只是更强的补全器， 而不是具备行为能力的开发者副手。它们擅长补全代码，但缺乏结构化任务理解、缺乏上下文感知，更无法根据开发者的意图自我组织多步行为。 更重要的是：它们是“别人造好的助手，而不是你能定义的工具

AutoDev 的本地智能体系统，从根本上改变了这个逻辑。

AutoDev 的新范式：Prompt 即 Agent，配置即能力链​

AutoDev 推出的本地智能体系统以两个核心理念为基础：

1. 智能体的结构可声明、能力可组合、行为可扩展
2. 一句 Prompt + 一段配置，生成一个完全私有、本地可运行的 Agent 编码助手

其核心架构允许开发者：

• 自定义 agent 的能力链（例如先读文件、再检索相关函数、然后写测试并提交）
• 注入自己的提示词风格、子任务规划逻辑，甚至嵌入插件模块
• 在本地选择任意大模型（如 Deepseek、Qwen、GLM）完成推理

你还可以定义它在 IDE 的交互方式、在命令行的交互方式，甚至在 @ 的交互方式：

• actionLocation：IDE 中的交互位置，诸如 ContextMenu、CommitMenu、@mention 等
• interaction：输出方式，诸如 AppendCursor、RightPanel 等。

✅ 示例配置：一分钟声明你的 Agent​

如下，我们将创建一个用户选中需求后，可以用鼠标右键点击生成 Protobuf IDL 的智能体：

---
name: "Design Profobuf IDL"
actionLocation: ContextMenu
variables:
  "spec": /any/ { thread(".devin/shell/fetch-teamai-spec.sh") | jsonpath("$.[1].content") }
onStreamingEnd: { parseCode | saveFile | openFile }
---

请根据用户的输入和规范，生成相应的 Proto 文件。

规范如下：

$spec

用户的需求是：$selection

只需这一段 YAML，AutoDev 就能生成一个理解团队协议规范的智能体：

• 自动调用 fetch-teamai-spec.s 脚本获取需求规范
• 注入上下文信息并结合用户选中需求
• 自动生成符合要求的 .proto 文件并打开编辑

这种原子化能力封装 + 跨工具联动方式，大大拓展了 agent 的实用边界。

✅ 示例配置二：编排的数据库设计智能体​

---
name: "设计数据库"
variables:
  "story": /any/ { thread(".devin/shell/github-issue.curl.sh") | jsonpath("$.body") }
afterStreaming: {
  case condition {
    default { execute("gen-sql.devin", $story, $output) }
  }
}
---

你是一位专业的数据库管理员。根据用户的需求，你应该在列表中为用户选择最佳的表。

— 用户使用数据库：$databaseInfo
- 用户表：$tables

例如：

- 问题（要求）：按用户类型计算平均行程长度。用户表：trips, users, Subscriber_type *
- 你应该回答：[trips, Subscriber_type]

----

以下是用户需求：

$story

请为用户选择最佳的表，只需以列表形式返回表名，无需解释。

只需这一段配置，AutoDev 会自动生成：

• 一个能够理解数据库结构并执行 SQL 生成的智能体
• 完全根据用户输入的数据库表和需求动态生成查询
• 将查询结果传入到下一个智能体（gen-sql.devin）进行处理

✅ 示例配置三：在聊天中生成代码​

只需要在配置中添加 agentic 为 true 的值，并将 $selection 改为 $input 变量，AutoDev 就会自动将用户的输入传递给智能体：

---
name: "Design Profobuf IDL"
actionLocation: ContextMenu
variables:
  "spec": /any/ { thread(".devin/shell/fetch-teamai-spec.sh") | jsonpath("$.[1].content") }
onStreamingEnd: { parseCode | saveFile | openFile }
agentic: true
---

请根据用户的输入和规范，生成相应的 Proto 文件。

规范如下：

$spec

用户的需求是：$input

总结：智能体的未来，是“开发者驱动”的自由工坊​

AutoDev 本地智能体系统给开发者带来了真正的控制权。

• 你定义行为，而不是接受行为
• 你组合模块，而不是等待功能更新
• 你掌控模型，而不是被平台绑定

每个开发者都应该拥有属于自己的 AI 编程助手，而不是为一个 “通用 Copilot” 妥协。

这，就是 AutoDev 想做的事。

📌 项目地址： https://github.com/unit-mesh/autodev 📚 文档 & 快速上手： https://ide.unitmesh.cc/docs

PS：在我们等待了几个月之后，国内终于有模型（DS V3-0324）能支持 AutoDev 的能力，也因此是时候发布 AutoDev 2.0 了！

2023 年 4 月，我们开始了 AutoDev 的第一个功能：AutoCRUD，经过两年的快速迭代，我们干掉了这个功能。因为新的 AutoDev 2.0 来了，智能体 驱动的 AI 编程改变了我们过去的架构。在 AutoDev 2.0 中，你可以：

• 编码智能体 Sketch 进行自动化编程
• 自动化编程的规划器 AutoDev Planner
• 系统迁移 Bridge 辅助旧系统重构
• 观察者 Observer，动态观察 IDE 中的代码变化
• 模型协议 MCP 接入工具生态
• 在不同场景使用多种开源模型（编程、推理、Apply、补全等）
• ……

更棒的是 AutoDev 2.0 是开源的，你可以自由使用、修改、分享，让我们一起来探索这个无限可能的世界！与此同时，我们是最好的 JetBrains IDE 平台上的第二代 AI 编程工具，你可以尽情利用 JetBrains 的插件生态，让 AutoDev 2.0 更加强大！

编码智能体 Sketch​

我们开发 AutoDev 2.0 的动机来源于：DeepSeek V3 模型的推出。我们在 Shire 智能体语言上构建了 Sketch View，并率先将其应用到多文件编程支持。 随后，我们将其应用到 AutoDev 2.0 中，通过丰富的 IDEA 插件生态，来构建更好的 IDE 编程体验。

交互式决策视图：Sketch View​

Sketch View 提供了是一种新的交互式视图，它可以帮助你更好地理解架构、进行决策。Sketch View 的特点有：

• 交互式设计。多种化的 Patch/Diff 处理， 并针对生成代码进行 Lint 检查等
• 开发者体验。前端应用在启动 dev 服务时， 自动打开 WebView 查看编译正确
• 质量与安全。生成依赖文件时，可提供依赖的安全检查

并且，你还可以用它来查看代码的结构，以及更好地编写代码。

隔离环境的工具调用：DevIns​

我们在 AutoDev 1.0 中设计了 DevIns DSL 来构建隔离环境的指令抽象，基于 DevIns 指令，AutoDev 可以：

• 安全操作。对指令进行更安全的检查，诸如 Shell、SQL，而不是依赖于 LLM 的不靠谱分析。
• 模型无关。即可以在不同的模型上使用 CoT 来进行工具调用，而不依赖于 function tool。
• 关键上下文。即基于 IDE 的 PSI 接口丰富了语法分析计算与架构视图，提供系统的关键上下文。

同时，DevIns 能和 MCP 生态非常好的结合在一起，以便于更好地调用工具。

可见的任务规划：AutoDev Planner​

Planner 是 Sketch 的核心功能，它提供了一种新的任务规划体验。你可以通过 AutoDev Planner 来：

• 可见的任务规划。通过 Pin 及 Planner ToolWindow 的可以看到当前的任务进度
• 动态的任务规划。AI 会根据上下文动态调整任务规划（取决于模型，有时候并不会实时更新）
• 手动执行未完成的任务。用户可以手动执行未完成的任务，以便更好地调整任务规划

结合诸如于 DeepSeek R1 这一类推理模型，AutoDev Planner 可以更好地规划任务，以适应用户需求。

被动式错误观测：Observer​

Observer 是在 Sketch 中新增的一个功能，它可以帮助你更好地观察代码的变化。Observer 可以观察：

• 测试失败。当测试失败时，Observer 可以自动带上上下文（相关代码）发给模型
• 构建失败。当构建失败时，诸如 Gradle、Maven 的构建日志会被自动发送给模型
• 添加依赖失败。当添加依赖失败时，Observer 会自动将问题反馈给模型
• ……

通过被动式的错误观测，AutoDev 可以更好地理解代码的变化，以提升开发效率。

旧系统改造智能体：AutoDev Bridge（试验性）​

Bridge 是我们针对遗留系统迁移的一个新功能，它主要包括：

• 迁移路径。基于"探索-感知-响应"框架，通过大型语言模型智能生成系统迁移路径
• 架构视图。利用 AI 进行工具调用对现有系统进行深度扫描，生成符合C4模型标准的架构蓝图
• 业务逻辑分析。结合抽象语法树(AST)解析和运行时调用链追踪技术，实现业务逻辑的精准还原
• 执行迁移。生成包括单元测试、集成测试和端到端测试在内的多层次验证方案，确保迁移后系统功能完整性

作为一个试验性功能，AutoDev Bridge 并没有完全成熟，但是我们相信它会在未来的迁移中发挥重要作用。

DevOps 生态集成：双向 MCP​

MCP（模型上下文协议）是一个非常好的开放协议，它可以帮助 AI 智能体更好地理解上下文。在 AutoDev 2.0 中，我们将 MCP 与 JetBrains 插件生态 进行了双向集成，以便于更好地调用工具。

• MCP 即工具。通过 DevIns 指令对 MCP 进行封装，来调用第三方工具
• AutoDev 即服务。将 AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用

如此一来，将 AutoDev 与整个工具生态进行了无缝集成，丰富系统的上下文能力，降低幻觉的产生。

其它​

我们重新写了 UI 配图页面，详细参考新文档进行配置：https://ide.unitmesh.cc/quick-start

AutoDev 1.x 功能​

AutoDev 1.x 的功能依然保留，删除了一些用得比较少的功能，如 AutoCRUD。

工具问题依旧，效率真能提升吗？​

哪怕效率提升再多，效能提升依然有限。你们在写代码上的时间到底有多少？？？？？？？？？？？？

安装 AutoDev 2.0​

你可以通过 GitHub 来下载最新版本的 AutoDev 插件：https://github.com/unit-mesh/auto-dev 。

也可以 Settings → Plugins → Marketplace → Manage Plugin Repositories → Add，添加 https://plugin.unitmesh.cc/updatePlugins.xml 然后搜索 AutoDev 进行安装。

我们还在努力重新上架到 JetBrains 插件市场，但是你还可以通过下载源码来手动安装。

最近，我们在 AutoDev 上构建了新的功能：AutoDev Planner，它是一个基于 DeepSeek R1 推理模型构建的编码任务规划功能。当然了，除了 DeepSeek R1 之外，你也可以使用其它模型。

在 AutoDev Planner 中，AI 将会根据你的输入和收集的上下文，生成一个用于后续编码的任务计划。随后，这个编码计划可以用其它指令遵循更好的模型，比如 DeepSeek V3，来生成代码、编辑代码等。

引子 1：AI 编码任务的进度显性化​

在进行 AI 编码 Agent 的设计时，一个非常有意思的点是，用户对于编码任务的感知是怎样的，即用户应该能显性看到进度，还是隐性感知进度。

Copilot Workspace：早期的 AI 显性任务​

去年，我尝试使用 GitHub Copilot Workspace 来帮助我进行前端的开发工作。我尝试了几十个小的需求点，哪怕只是简单的 i18n 翻译，它的表现并没有 我想象中的那么好，大抵是受限于 GPT 4 的能力限制。而 Copilot Workspace 的思路确实非常不错：

• Brainstorm。对用户的 Task 进行头脑风暴（Brainstorm）
• Task。将 Task 转换为一个可编辑的 Plan
• Execute。执行 Plan，生成代码 Pull Request
• PR。将变更以 Pull Request 的形式提交

你可以显性看到 AI 思考、编辑、执行的过程，当然它没有动态的去调整他的计划，而是一次性生成（基于 2024 年的认知）。

Cursor：AI 隐性任务下的自动化重试​

回到，最近一年多特别火热的 AI 编码工具 Cursor，它构建了非常好的 AI Editor 体验，用户抛出一个问题。它会：

• 自动收集 IDE 中的上下文
• 对代码进行编辑
• 在代码出现 Lint 问题时，自动修复；在代码出现错误时，自动重试
• ……

你可以通过文字大概理解 AI 到底干了点什么，但是很快大量地重试，让你感知不到过程的存在。

JetBrains Junie：动态的 AI 任务规划​

JetBrains Junie 算是最新 AI 编码工具，它构建了一个动态的 AI 任务规划体验。用户抛出一个问题。它会：

• 结合分析问题，理解用户意图，生成一个任务计划
• 按步骤执行每个任务，并根据需求再获取上下文
• 在任务执行过程中，动态调整计划，以适应用户需求

在过程中，你可以看到它的计划在不断调整和迭代，直到最终完成用户的 issue 或者不能完成。

引子 2：推理模型规划任务的想象空间​

众所周知，2024 年底的推理模型或者说“可深度思考模型”，带来了更多的想象空间与可能性。我们在 AutoDev Sketch（类 Cursor Composer 自动编码 Agent） 中做了一系列的实验， 发现与其它的国内模型相比，DeepSeek R1 在相同上下文的情况下，比普通模型更容易生成更好的工具调用（ 基于DevIns 指令）。 与 DeepSeek V3 相比，DeepSeek R1 调用了更多的工具。

理想情况下，我们应该用 R1 进行首轮工具对话和第二轮的任务规划，但是 R1 的速度确实太慢了，从时间上来算相当于多调用了一轮 API。但是，依旧可以 看到 R1 的优势，相信大家也有相似的感受和体验。

当然我们没有做大规模的实验，毕竟构建非常好的测试数据集是特别花费时间的。

AutoDev Planner：Agent 编程的任务规划​

基于上述的思考，我们构建了新的拟人功能：AutoDev Planner 以强化 Sketch 的任务规划能力。AutoDev Planner 的核心功能是：

• 可见的任务规划。通过 Pin 及 Planner ToolWindow 的可以看到当前的任务进度
• 动态的任务规划。AI 会根据上下文动态调整任务规划（取决于模型，有时候并不会实时更新）
• 手动执行未完成的任务。用户可以手动执行未完成的任务，以便更好地调整任务规划
• 规划 Review。用户可以手动调用模型来 Review 任务规划（为什么不是自动的，因为 token 对普通用户来说是非常昂贵的）

总体思路还是非常简单的，就只是调用模型生成计划，然后展示这个交互。

关键点 1：基于推理模型的任务规划​

由于推理模型与普通的模型在理解 prompt 和遵循指令的能力是有差异的，我们原先用于 V3 的 prompt 并不适用于 R1。因此，我们需要重新设计 prompt 以适应 R1 的能力。

简单来说，就是当完成了初步的上下文收集之后， 而且用户配置了推理模型之后，我们会调用 R1 来生成一个任务计划。这个任务计划会包含：任务、步骤及 其相关的进度情况，随后我们会将这个计划展示给用户。

关键点 2：任务规划的可交互性​

与其它的 AI 编码工具不同，我们认为任务规划是一个非常重要的交互，因此我们提供了一些交互功能：

• 任务的状态显示：
  • 完成的任务将会被标记为完成
  • 未完成的任务可以手动执行
• Pin。用户可以将任务 Pin 到 IDE 的某个位置，以便更好地关注
• 文件交互。考虑到模型的能力，当文件出现在任务中，可以点击文件名打开文件
• 编辑。当用户觉得任务规划不合适时，可以暂停并及时调整任务。
• review。用户可以手动调用模型来 Review 任务规划

通过可视化任务来构建更好的 AI 编码体验，这是 AutoDev Planner 的初衷。

总结​

AutoDev Planner 是一个基于推理模型的任务规划功能，它可以帮助用户更好地理解 AI 编码任务的进度，以及更好地调整任务规划。当然，它还有很多不足之处， 欢迎在 GitHub 上提出 issue 和 PR。

欢迎下载最新版本体验：https://github.com/unit-mesh/auto-dev/releases

在 Agentic Coding 这一话题下，工具使用（Tool Use/Function calling）是一个非常有意思的话题。完成一个软件开发任务，需要使用到大量的工具， 除去在 IDE 及其插件生态本身提供的功能外，还会使用到大量的外部工具，如 Git、Docker、Kubernetes、Jenkins 等等。如何让 AI 知道更多工具的存在以及如何使用这些工具，是一个非常有意思的话题。

所以，我花了一天的时间在 AutoDev 中实现了相关的功能，即 AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用；AutoDev 作为一个 MCP 客户端，可以调用任何 MCP 服务。

引子 1：从渐进性 AI Agent 方案，到 AutoDev 即 MCP 服务​

在更庞大的 AI Agent 话题之下，比如自动化的 Computer Use 场景下，IDE 也只是一个可调用的 Agent 工具。从当前的 AI Agent 进度来看，现在的 Agent Tool 使用是一种渐进式的 AI Agent 方案 —— 毕竟写过 E2E 测试的同学都知道：操作 UI 的效率是非常之低的；以至于我们在编写 AutoDev 时，并没有写多少 UI 自动化测试。

我们现在考虑的 AI Coding 是以 IDE 为中心的，但是还存在一个场景是以 Agent Tool 为中心的。即：

• Agent 通过操纵 Browser 去获取需求信息；
• Agent 打开 IDE 去编写代码；
• Agent 打开 DevOps 工具去发布代码；
• ……

既然借助 Agent Tool 来调用工具是 2025 年的一个趋势，那么我们为什么不将 AutoDev 作为一个 MCP 服务呢？即 AutoDev 作为一个 MCP 服务，让任何 Agent Tool 都可以调用 AutoDev 的服务。哪怕是 Cursor、Cline、GitHub Copilot 等等，都可以调用 AutoDev 的服务，以获取 IDE 中的高质量上下文。

引子 2：从 MCP 即 Agent Tool 生态，到 MCP 服务即 AutoDev 指令​

在过去，我们在 AutoDev 中优先考虑的是借助 IDE 的生态，以及自身的插件体系，以实现 AI 更好的支持端到端的开发流程。但是，随着我们在 AutoDev 集成了更丰富的插件能力之后，我们依然需要大量的 Agent Tool。

Agent Tool 决定 AI IDE 的基线能力​

不可否认，在我们研究了大量的 AI Coding 工具之后，我们会发现，大量的 AI Editor 基于 VSCode 时在 tool 上提供的能力非常之相似，以至于我们 可以用一张图来描述它们的能力。但是，在 IDE 上的 AI Coding 插件则提供了更加丰富的能力，如 AST、Debug、FQN 查找等等。

典型的基于 VSCode 的 AI Coding 工具，提供了十个左右的工具，而基于 JetBrains 的 AI Coding 插件（如 AutoDev、JetBrains Junie）则提供了 20 个左右的工具，而这些只是基础的 IDE 上的能力。

而随着 AI Coding 进一步向需求、部署、运维等方向发展，相关的工具生态势必会更加丰富。

MCP 开源生态已经形成​

MCP（Model Context Protocol）是由 Anthropic 公司（Claude 模型） 推出的一个协议，它通过提供一种标准化的接口，LLM 应用可以访问外部信息、工具和资源。尽管我们在 AutoDev 提供了强大的自定义能力，诸如于 Custom Agent 等能力，但是：

• 有些工具是我们无法预知的，如某些公司内部的工具；
• MCP 等工具的生态是非常丰富的，并且正在成为一个标准。（尽管国内可能有一些不同）

但是，自打 Cursor、Cline 等编程工具引入了 MCP 之后，大量的 MCP 服务已经在国外形成了一个生态，特别是已经有了非常多的开源实现。

AutoDev x MCP：双向赋能​

基于上述的思考，我们基于 MCP 相关的插件（MCP Plugin）和生态（io.modelcontextprotocol），构建了 AutoDev x MCP 的双向赋能方案。即：

• AutoDev 作为一个 MCP 服务，可以被任何 Agent Tool 调用；
• AutoDev 作为一个 MCP 客户端，可以调用任何 MCP 服务。

通过这两种方式来沉淀我们在 MCP 方面的能力。

AutoDev 作为 MCP 服务端​

我们基于 JetBrains 的 MCP 方案，提供构建了 AutoDev 作为一个 MCP 服务的能力（注：需要在配置中开启 MCP 能力）。你只需要通过 JSON 来配置即可 ，如下是 Cline 插件中的配置示例：

{
  "mcpServers": {
    "AutoDev": {
      "command": "npx",
      "args": [
        "-y",
        "@jetbrains/mcp-proxy"
      ],
      "disabled": false,
      "autoApprove": []
    }
  }
}

在当前的版本里，我们只基于官方提供的能力，加了一些数据库相关的能力，其它能力需要等有合适的国产 MCP 服务后再进行扩展。

AutoDev 作为 MCP 客户端​

相似的，你需要在 AutoDev 的 Custom Agent 页面配置相关的 MCP 服务，如下是 MCP 官方提供的示例

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Volumes/source/ai/auto-dev"
      ]
    }
  }
}

随后，这个 MCP 服务提供的工具，就可以在 AutoDev 中被调用了。如下是转换为 DevIns 后的示例：

/list_directory

{
 "path": "/Volumes/source/ai/autocrud/docs/mcp"
}

现在，借助于强大的 AutoDev DevIns Command，你可以在 AutoDev 中调用任何 MCP 服务，当然 Agent 也是可以的。

其它​

人生苦短，我有 AI。

• 详细文档见：https://ide.unitmesh.cc/mcp
• 欢迎下载和使用最新版本 AutoDev（v2.0.0-rc.2）进行体验。下载地址：https://github.com/unit-mesh/auto-dev/releases/tag/v2.0.0-rc.2

在 2023 年，基于当时的模型能力有限，我们在 AutoDev 设计了一系列的遗留系统功能的特性。而在 2025 年，经过自动编程智能体 AutoDev Sketch 的一系列 迭代，我们开始思考如何将 AI 智能体应用到遗留系统中，便产生了 AutoDev Bridge 这个想法。

为什么大模型能做得更好？​

过去，我们公司 Thoughtworks 在这方面有非常多的积累，包括从迁移策略的设计、安全防护网的搭建等等，但是不论哪种迁移模型（绞杀者、修缮者等）最后 都是需要人工介入的。而在 2025 年，已经有越来越多的 AI 智能体能够做到自动化迁移，因此我们进一步完善了我们的开源方案。

在遗留系统迁移上，为什么大模型能做得更好呢？

• 设计合理的路径规划。通常来说，优先基于成本考虑，而大模型作为一个知识库，能非常好的给你成本评估。
• 生成架构蓝图。结合目录结构、依赖信息、API，AI 能针对于当前系统描绘出初步的架构蓝图。
• 提炼代码中的业务知识。结合 AST 等，分析现有代码的业务逻辑，再基于其重写。
• 跨语言翻译。与生成代码不同的是，LLM 能非常好的将其翻译成目标语言，只需要几十秒到几分钟的时间。
• 迁移防护网的增强。即生成自动化测试来验证迁移的正确性，实现实现精准回归测试。（注：在前端依然有所不足）
• ……

所以，我们只需要思考两件事：

• 如何让 AI 能借助工具更好地理解遗留系统？
• 如何借助降低迁移的风险？

AutoDev Bridge 如何加速老旧系统迁移？​

基于对遗留系统迁移的理解，我们设计了 AutoDev Bridge 的初步方案。它主要包括：

• LLM 生成的迁移方案。（基于“探索-感知-响应”方案）
• 基于 C4 的当前架构现状分析。（基于 AI 工具调用）
• 结合 AST 与调用链的业务逻辑分析。（AI 理解代码）
• 生成迁移测试用例。
• AI 辅助的代码翻译。
• ……

借助与 IDE 的紧密集成，AutoDev Bridge 能获得非常准确的 IDE 上下文，以进一步降低 AI 幻觉的产生。

探索-感知-响应：LLM 生成的迁移方案​

在过去，我们将遗留系统迁移定义为 Cynefin 中的复杂问题，即你无法预测结果，只能通过实践来发现。于是乎，我们参考了 Cynefin 的思想，设计了现有的 AutoDev Bridge 的思维框架，即你要先探索、再感知、再响应。由于，我们预期的是模型在行动前是需要有一个蓝图（C4 模型），所以我们将这个过程分为三个阶段：

• 探索：通过初步调用工具，获取系统的基本信息，如目录结构、依赖关系等。
• 感知：基于探索的结果，生成初步的架构蓝图、迁移方案。
• 响应：进行迁移方案的验证、生成迁移测试用例、生成迁移代码。

落地到国内的模型能力下，就会由由 V3 来进行探索，R1 进行方案设计，由 V3 进行响应。

面向架构视图的工具设计​

为了更好让 AI 理解当前系统的架构，我们面向架构视图设计了一系列的工具。

注：显然 DeepSeek 不能很好理解 C4 模型，还需要进一步的优化。

业务知识提取与理解​

在业务逻辑分析中，我们主要是基于 API 的 AST 与调用链的业务逻辑分析。即先通过 webApiView 获取所有的 API，再通过 knowledge 获取 API 的调用链。 如：

/knowledge:GET#/api/blog/*

在有了从 Controller 到 Repository 的调用链后，AI 就可以非常好地理解当前 API 的业务逻辑。

当然，这只是一个简单的示例，实际上，AI 还需要结合搜索等工具，进一步获得更多的上下文。

总结​

随着，我们研究的进一步深入，我们会逐步完善这个方案，以实现更好的自动化迁移。

欢迎在 GitHub 上持续关注我们：https://github.com/unit-mesh/auto-dev

A little over two weeks ago, after the release of DeepSeek V3, we introduced multi-file editing capabilities for Shire.

Following extensive testing, we discovered that DeepSeek V3 performs exceptionally well in programming scenarios, especially in multi-file editing contexts.

This inspired us to add a new feature—AutoDev Composer—to AutoDev, which had long lacked major updates. In developing this feature, we drew inspiration from a number of mature tools:

• The impressive Sketch rendering mechanism on Shire
• Complex system prompts from tools like Cursor and WindSurf
• The bug-ridden StreamDiff mode from Continue
• …and more

Now, there’s no need to switch to a VSCode-like IDE to craft prompts and then return to IntelliJ IDEA for debugging. With AutoDev Composer, you can handle everything directly within IntelliJ IDEA.

As an amateur project, we’ve put in a lot of effort to make this happen! 😊

Introduction paragraph text here.

在上一个版本中，我们构建了 AutoDev 的自定义 Agent 功能，即用户可以通过自定义能力来构建自己的智能体，以实现对于软件开发任务的智能辅助。 而在这个版本中，我们开始构建一个新的 AI Agent 语言：DevIns，即 Development Instruction。即 DevIns 可以让用户更快速描述软件开发任务， 同时，还可以自动化处理来自 AI Agent 返回的内容。

Introduction paragraph text here.

在开源 AI IDE 插件 AutoDev 的 #51 issue 中，我们设计了 AutoDev 的 AI Agent 能力，半年后我们终于交付了这个功能。

在 AutoDev 1.7.0 中，你将可以接入内部的 AI Agent，并将其无缝与现有的 AI 辅助能力结合在一起。

Introduction paragraph text here.