在新的 AutoDev MPP （Multiplatform Paradigm） 架构下，我们也基于 MPP Core 构建了 CLI 体系。而与免费送 Token 的 Gemini CLI 等相比， 作为一个开源项目，我们设计 CLI 并不是为了追随潮流。我们的初衷是为了解决上一代 AutoDev 基于 Intellij UI 框架的智能体测试困难问题：

• Sketch 智能体逻辑与 UI 事件绑定紧密（如通过 Action、ToolWindow、Editor 触发）。
• 上下文状态（Project、Editor、Selection）深度依赖 IDE 内核对象。
• 上下文依赖复杂。诸如于 AST、依赖关系等没有剥离
• 测试环境不可移植。很多逻辑通过 IDE runtime 驱动，无法轻易在 CI/CD 环境执行
• ……

同时，基于先前我们在 AI 辅助遗留系统迁移工具的 AI Agent 生成 AI Agent 经验，我们使用它来快速迭代 AutoDev MPP Agent 能力。

代码见：https://github.com/unit-mesh/auto-dev

起步：Vibe Coding Agent 构建 AI Agent

在先前的《Vibe Coding 构建 AI 迁移工具，实现端到端智能迁移》文章中，我们介绍了 如何基于各类 fancy 的主流 AI 编程工具，快速开发一个 AI Agent。其中的一个核心就是提示词：

我正在编写一个自动化的 xx 工具，采用“两阶段 AI 调用模式”。

第一阶段：根据错误信息生成工具调用，以决定需要读取哪些文件。
第二阶段：根据读取的文件内容和错误信息，生成实际的修复代码。
 - 工具包括：read-file、write-file、str-replace 和 list-dir

请参考你所使用的工具（GitHub Copilot/Cursor 或 Windsurf），实现这个 AI Agent。目前只需要代码，不用进行任何修改。

在学习了基本的 AI Agent 和对应的上下文工程之后，你很容易理解这个提示词的用途 —— 运气好的情况下，你可以直接有一个可运行的 AI 辅助问题修复的 AI Agent。基于这个架子，我们就快速有了一个可工作的雏形，再让 AI 完善这个工具即可。对应的，我们在构建 AutoDev CLI 时，也是一样的逻辑：

现在我需要为 @mpp-ui 模块构建出一个 TUI/CLI，即 Terminal UI 和 Command，需要使用 Node.js 作为 Target，
计划引入的库是 https://github.com/vadimdemedes/ink

另外我还希望类似于 jvm 或者 android 版本的交互，我这个 CLI 如果发布出去应该是叫 @autodev/cli 可以通过这个来进行测试。

你应该确保代码能构建和运行，测试也是通过的。按照 KMP（Kotlin Multiplatform） 最佳实践组织，需要真正集成 mpp-core 的 AI Agent。

剩下的就靠 Augment 的想象力。

迭代：CLI 输出即问题的输入，构建可迭代的架构

相信看过上一篇文章《从 Prompt 到上下文工程构建 AI Agent 的大家都 能理解，要让 AI Agent 更好的工作，那么就需要产生足够的 Context 以让 AI 去理解和分析问题。诸如于：当我们使用 autodev . 来启动 AutoDev CLI 时：autodev code --path . --task "xxx"它会输出如下的信息：

INFO: [CodingAgent] Initializing ToolRegistry with configService: true
INFO: [CodingAgent] Enabled builtin tools: [read-file, write-file, edit-file, grep, glob, shell, code-agent, ask-agent, web-fetch]
INFO: [ToolRegistry] 🔧 Registered 8/8 built-in tools
INFO: [SubAgentManager] 🤖 Registered SubAgent: code-agent
INFO: [CodingAgent] Initializing MCP tools from 2 servers...
McpClientManager.initialize() - Initializing 2 servers
Discovering tools from filesystem (stdio transport not fully supported in browser)
Discovering tools from github (stdio transport not fully supported in browser)
...

由于 AutoDev 的新架构是多端统一的，同样的 CodingAgent 代码和 Renderer 机制，就可以确保我们在 CLI 遇到的问题，99%（只能是大概率）都会 在 Desktop、Mobile 等其它端遇到。所以，我们可以基于这个机制，来快速验证各类场景遇到的问题如何修复。交由 AI Agent 去修复：

测试 AI Agent 在如下这类场景的问题，多找几个相似的。然后看看输出的日志和结果，看看 @CodingAgent.kt 是否正确修改，如果有问题请修复：

node dist/jsMain/typescript/index.js code --task "add Spring ai to project and also a service example, I use deepseek,
 here it's the documentation https://docs.spring.io/spring-ai/reference/api/chat/deepseek-chat.html -p .

通过添加更多的 println 和 console.info，AI 就能构建，执行，修改、再构建，执行，修改，直到他达到目标或者放弃：

我正在构建一个 AI Coding Agent ，请执行如下的命令，然后看

1. 是否在目标产生结合对应的代码修改？
2. 输出的过程是否合理？有没有输出多余的内容？
3. 对于用户的体验是不是好？比如能不能通过 codehighlight 或者展示 diff 的方式来展示修改？

命令是：

cd mpp-ui && npm run build:ts && node dist/index.js code --path /Users/phodal/IdeaProjects/untitled --task "Create a hello world"

不愧是 Cursor：

这个设计让 AutoDev Coding Agent 能够像 Cursor 一样优雅地处理长日志输出！🚀

演进：生成自动化的 Agent 测试框架

在我们自己找到一些场景，再借由 AI 生成一些场景之后，答案就变得更加清晰，问题也就得非常简单了：让 AI 生成 CLI 的测试框架：

我现在测试 ai agent 的 robustness，当前已经写了一些测试代码（可以通过 git 查看未提交的变更），我想基于这部分构建一个专用的测试框架，
你看看怎么提炼好，并进行提炼。我关注的是：

- 生成的提示词
- 调用的工具有哪些
- 结果产生的变更有哪些

围绕这个去设计，以更好地扩展能力。再看看有哪些场景

在 Augment 烧完了一堆 credits 之后，他完成了任务。

➜  autocrud-mpp git:(master) tree /Volumes/source/ai/autocrud/mpp-ui/src/test/framework
├── analyzers
│     ├── CodeChangeAnalyzer.ts
│     ├── PromptAnalyzer.ts
│     └── ToolCallAnalyzer.ts
├── cli.ts
├── core
│     ├── TestCase.ts
│     ├── TestEngine.ts
│     └── TestResult.ts
├── index.ts
├── reporters
│     └── ConsoleReporter.ts
├── scenarios
│     └── ScenarioBuilder.ts
├── validate-framework.ts
└── validate-structure.cjs

我们接下来就可以用 AI 生成测试 AI Agent 的用例：

• Add Redis cache to Spring Boot project with example service（预期至少调用一次 read, 二次 write）
• 为 BlogPost 实体添加视频支持功能，包括 URL、标题、描述字段（预期至少调用三次 read,四次 write，BlogPost.java 会被修改）
• 实现完整的 JWT 认证系统，包括用户管理、登录、注册功能（预期 build.gradle.kts 会被修改，User.java 会被创建，JwtUtil 会被创建）
• ……

集成：CI/CD 集成与质量门控

现在，我们就让 AI Agent 继续去干活：

我的 Repository secrets 已经配置好了 DEEPSEEK_TOKEN 现在需要怎么添加到  @.github/workflows/integration-tests.yml 中，
以便于测试在读取 key 的时候能读到，
➜ untitled git:(github) ✗ cat ~/.autodev/config.yaml
active: my-deepseek
configs:
  - name: my-deepseek
    provider: deepseek
    apiKey: sk-xxx
    model: deepseek-chat 

这个是我本地的示例。另外这个 workflow 是可以挂的，但是阈值至少是 80% ？然后要有很好的报告展示

AI Agent 可以在执行 CLI 后，查看变更，然后修改不合适的地方，再次循环。

现在你的 GitHub Actions workflow 已经完全配置好了，整个 CI/CD 流程现在具备了生产级别的质量保证能力！🚀

总结：在不确定的 AI 世界中，构建确定的验证体系

AutoDev CLI 的出现，标志着 AI 编程进入新的阶段—— 从“AI 生成代码”到“AI 验证代码”，再到“AI 生成测试 AI 的系统”。这套架构实现了三个关键能力：

• 可验证的生成：AI 产物不再是黑箱，而是具备上下文、日志与行为可追踪性。
• 可演化的框架：测试框架由 AI 自生成、自维护，持续进化。
• 可移植的环境：统一的 CLI/MPP 结构打通多端验证链路。

在一个 AI 充满不确定性的时代，AutoDev CLI 让我们重新掌握了工程的确定性—— AI 自我生成、自我测试、自我演进。