一个让OPC开发者真正“看得见“AI在干什么的多Agent VS Code插件
## 前言：Claude要你身份证，而你的工作流怎么办？
2026年4月16日，Anthropic毫无征兆地上线了强实名身份验证（KYC）——必须真人、手持政府签发的实体证件、配合实时自拍。不配合？直接封号。更狠的是，官方公告里明确写着："账户即便完成验证，照样可能被禁用。"
这意味着什么？如果你是Claude Code的重度用户，你的整个工作流——对话历史、上下文积累、自动化配置——随时可能化为乌有。你花了大量订阅费和时间搭建的AI编程体系，平台一个弹窗就能全部清零。
这不是假设，是今天正在发生的事。
而就在Claude用户集体焦虑的同时，另一个问题也被放大了：**你看得见AI在干什么吗？**
你发了一条指令，AI开始"思考"。30秒后，它改了5个文件。你不知道它读了哪些上下文、为什么这么改、改的对不对。等发现错了，已经花了几千个Token。
**黑箱问题 + 供应商锁定风险 = OPC开发者的双重困境。**
**Mutsumi 是我见到的第一个同时解决这两个问题的VS Code插件。**
---
## 一、Mutsumi 是什么？
**Mutsumi** 是一个开源的 VS Code 多 Agent 协作插件，由开发者 MalachiteN 独立完成。名字来自《草莓100%》的若叶睦——设计理念是"像睦美一样有多重人格"，每个 Agent 有明确的角色分工。
GitHub：https://github.com/MalachiteN/Mutsumi
License：Apache 2.0
技术栈：TypeScript + VS Code Extension API + OpenAI Compatible API
**核心卖点**：上下文完全控制 + 可观测性 + 可审计性
---
## 二、五角色系统：不是"一个AI干所有事"，而是"一群AI各司其职"
Mutsumi 内置五个角色，每个角色有明确的职责边界：
| 角色 | 职责 | 可派生子角色 |
|------|------|-------------|
| **chat** | 纯聊天入口，不进入工程执行树 | — |
| **orchestrator** | 全局任务收敛与调度中心，访谈用户，生成终态文档，分派执行 | planner / implementer / reviewer |
| **planner** | 里程碑与依赖规划，识别中间状态和并行/串行关系 | reviewer |
| **implementer** | 具体工程实现者，写代码、验证实现、集成子结果 | implementer / reviewer |
| **reviewer** | 纯审计角色，只读审查输出，采用 pass/conditional pass/fail 三态结论 | — |
**关键设计**：每个预设角色都有决策和任务推进能力，避免层级树汇报结构中的信息压缩损失。
### 实际体验
我试用了一个典型场景：**重构一个 TypeScript 模块**。
1. 我在 chat 里描述需求："把这个 utils.ts 拆分成三个模块"
2. orchestrator 自动启动，先访谈我确认细节（哪些函数、依赖关系、命名规范）
3. planner 生成任务分解：3个子任务，2个可并行
4. 两个 implementer 并行执行，各自负责一个模块
5. reviewer 审查每个 implementer 的输出
6. orchestrator 汇总结果，生成终态文档
整个过程我都能在侧边栏看到每个 Agent 的状态和输出。**不是黑箱，是白箱。**
---
## 三、动态上下文管理：六阶段架构
这是 Mutsumi 最硬核的技术亮点。
### 六阶段流水线
```
1. 环境与宏初始化 → 加载持久化上下文状态和宏定义
2. System Prompt 构建 → 整合 Rules 和运行时环境
3. 用户输入解析 → TemplateEngine 递归处理文件引用
4. 增量快照与版本控制 → 智能变更检测，节省 Token
5. 持久化与元数据更新 → 保存 ghost blocks 到 Cell Metadata
6. 最终消息装配 → 一致性前缀，最大化 LLM KV Cache 利用率
```
### @[path] 递归引用
这是我最喜欢的功能。你可以用 `@` 语法引用文件：
```
请根据 @[src/utils.ts] 和 @[docs/api.md] 重构这个模块
```
Mutsumi 的 TemplateEngine 会：
1. 发现 `@[src/utils.ts]` → 读取文件，运行预处理器
2. 发现内部引用 `@[src/types.ts]` → 递归解析
3. 返回展开后的完整内容
4. 发现 `@[ls{"uri": "path/to/codebase"}]` → 预执行工具
**文件哈希追踪**：如果引用的文件没变，注入一条让 Agent 回溯历史记录的指令（省 Token）；如果变了，注入最新版本并 bump version。
### 预处理器与宏支持
```
@{define DEBUG, true}
<!-- @ifdef DEBUG -->
调试模式下的额外检查逻辑
<!-- @endif -->
```
Rules 文件和被引文件都支持预处理指令，可以按条件控制哪些内容对 Agent 可见。
---
## 四、可观测性：发送前就能看到上下文
这是 Mutsumi 和其他 AI 编程工具最大的区别。
**其他工具**：你发指令 → AI 开始处理 → 等待 → 看结果 → 发现上下文错了 → 浪费了 Token
**Mutsumi**：你发指令 → 看到上下文装配结果 → 确认无误 → AI 开始处理 → 看结果
在发送会话历史到 LLM 之前，你可以预先查看：
- 完整的上下文装配结果（哪些文件被引用、Rules 如何生效）
- RAG 搜索结果（搜到了什么、相关性如何）
**这个功能对于 OPC 开发者尤其重要。** 一个人开发，没有同事帮你检查"AI是不是读了正确的文件"。Mutsumi 让你自己就能做这个检查。
---
## 五、内置工具生态
Mutsumi 提供了丰富的内置工具：
**文件操作**：`read_file`、`edit_file`、`create_file`、`ls`、`get_file_size`
**代码搜索**：`search_file_contains_keyword`、`search_file_name_includes`、`project_outline`、`query_codebase`
**执行控制**：`shell`、`get_env_var`、`system_info`
**文件编辑**：`edit_file_search_replace`、`create_or_replace`
**Agent 编排**：`dispatch_subagents`、`get_available_models`、`task_finish`
**RAG 向量搜索**：基于 sqlite-vec 的代码库语义搜索
**语法树解析**：基于 web-tree-sitter 的代码结构分析
---
## 六、与主流工具对比
| 特性 | Mutsumi | Claude Code | Cursor | Cline |
|------|---------|-------------|--------|-------|
| 多 Agent 协作 | ✅ 五角色系统 | ❌ 单 Agent | ❌ 单 Agent | ❌ 单 Agent |
| 上下文可观测 | ✅ 发送前预览 | ❌ | ❌ | ⚠️ 部分 |
| 可审计性 | ✅ reviewer 角色 | ❌ | ❌ | ❌ |
| 动态上下文管理 | ✅ 六阶段架构 | ⚠️ 基础 | ⚠️ 基础 | ⚠️ 基础 |
| @[path] 递归引用 | ✅ | ❌ | ❌ | ❌ |
| 预处理器/宏 | ✅ | ❌ | ❌ | ❌ |
| 文件哈希追踪 | ✅ | ❌ | ❌ | ❌ |
| 多工作区支持 | ✅ 原生 | ❌ | ⚠️ | ⚠️ |
| Skills 兼容 | ✅ | ✅ | ❌ | ❌ |
| 模型支持 | OpenAI Compatible | Anthropic | 多模型 | 多模型 |
| 开源 | ✅ Apache 2.0 | ❌ | ❌ | ✅ MIT |
**Mutsumi 的差异化很明确**：它不是要取代 Claude Code 或 Cursor，而是解决它们不解决的问题——**上下文控制和可观测性**。
更重要的是，**Mutsumi 不锁定任何供应商**。它使用 OpenAI Compatible API，今天用 Kimi K2.5，明天换 GPT，后天换本地模型——你的工作流不受任何平台政策变化的影响。Claude 要你身份证？换一个 API 地址，继续用。
---
## 七、快速上手
### 安装
```bash
# 从源码构建
npm install
vsce package
# 本地安装到 VS Code
code --install-extension mutsumi-[version].vsix
```
### 配置
在 VS Code 设置中配置：
- `mutsumi.apiKey`：API 密钥
- `mutsumi.baseUrl`：API 地址
- `mutsumi.models`：模型配置（可选覆盖）
**注意**：Mutsumi 默认围绕 Kimi K2.5 优化，推荐使用 zenmux 聚合平台或 Kimi 开放平台。但也兼容任何 OpenAI Compatible API。
### 创建第一个 Agent
1. `Ctrl+Shift+P` → `Mutsumi: New Agent`
2. 在 `.mtm` notebook 文件中开始对话
3. 使用 `@[文件路径]` 引用代码文件
---
## 八、适合谁用？
**强烈推荐**：
- Claude Code 用户（今天Anthropic上线KYC，你的工作流需要Plan B）
- OPC 开发者（一个人需要完全掌控 AI 的行为）
- 对 AI 编程工具的"黑箱"感到不安的开发者
- 需要代码审计能力的团队
- 使用多工作区/远程文件系统的开发者
**可能不适合**：
- 只需要简单代码补全的用户（Copilot 更轻量）
- 不关心上下文管理的用户（Cursor 更省心）
- 非 VS Code 用户（目前只支持 VS Code）
---
## 九、总结
Mutsumi 不是一个"又一个 AI 编程工具"。它同时解决两个问题：**AI 编程的可观测性**和**供应商锁定风险**。
今天Anthropic上线KYC，给所有Claude用户敲了一记警钟：你的AI工作流，不应该绑定在任何一个平台的政策上。
Mutsumi 的设计哲学是：**模型是可替换的，上下文控制是不可妥协的。** 你用 Kimi K2.5 还是 GPT 还是本地模型，Mutsumi 不关心。它关心的是：你能不能看见 AI 在干什么、能不能审计它的决策、能不能在出问题之前拦截。
在 OPC 时代，一个人就是一家公司。你没有同事帮你 review 代码，没有 QA 帮你测试，没有项目经理帮你检查 AI 是不是读对了文件。你需要一个工具，让你**看得见 AI 在干什么**，并且**不把鸡蛋放在一个篮子里**。
Mutsumi 就是这个工具。
**项目地址**：https://github.com/MalachiteN/Mutsumi
**License**：Apache 2.0（可商用）
---
*小蠹OPC | CSDN*
*GitHub：github.com/dechang64*