前言
手头一个多模块项目要批量改造。之前用单 Agent 改这种活，翻车翻到怕：改完接口，别的模块引用没同步，缩进也给你弄乱。最气的是有一次它直接把我本地手动改过的代码覆盖了，只能靠 git 找回。
听人提到 oh-my-pi（omp），说它跟普通对话式工具不是一路，装起来倒是简单，一行 curl 就完事。我把手头这个改造任务整个丢了进去。
半个月下来，AI 幻觉少了很多，准确率明显上来了。
一、第一次交任务：所有活都从主 Agent 一个口进
我用对话式工具的习惯是先点名：你改这个文件，你去查那个接口。第一次用 omp 也这么干，想直接点名某个子 Agent 干活，试了两下发现根本没有这个入口。omp 的架构里，主 Agent 是根智能体、唯一入口：你只跟它说话，它负责拆解需求、派出子智能体、收拢结果。所有子智能体都由主 Agent 派生，任务统一由它收口，用户不需要直接面对任何一个子智能体。
那会儿我还觉得多了一层，用顺了才明白单入口的好处：需求怎么拆、派谁去、结果怎么合并，全在主 Agent 一层决策，责任清晰，不会出现多个智能体各干各的、最后没人负责的局面。
半个月下来，我关心的就四件事：AI 幻觉大幅减少，准确率提高了很多；可以配置多种模型，复杂编码和轻量调研自动分流；任务执行很丝滑，改动列表、耗时、成本一眼看全；执行结果结构展示，内置工具很强大，全局搜索靠内置 ripgrep 秒出结果。
这四个承诺背后都有机制撑着：幻觉减少靠多层 Agent 校验叠加真实调试数据，准确率靠 LSP 语法校验兜底。当时我以为它只是换了套说法，后面才一层层看明白这些机制的过程。
二、第一次并行改造：看清 8 个角色的分工
交任务之前，我以为它会像单 Agent 那样一口气把文件全改了。结果它没有一股脑自己改，而是按角色派活。我盯着过程看，把 8 个内置子智能体的分工看清楚了：
scout：代码侦察兵
任务一开始，先出去的永远是 scout。它遍历项目目录、梳理文件结构、统计依赖、定位目标代码范围，一圈跑下来告诉我改动边界在哪。它不写代码，只给后续任务划定边界，避免改错范围。
researcher：调研研究员
涉及一个没接触过的第三方 API 时，researcher 先联网查文档、查 API 用法、查开源方案、查漏洞信息、查技术规范，把事实拿回来。调研结论以结构化结果回传，不带猜测。
planner：方案规划师
事实齐了，planner 把需求拆解成分步改造方案、文件修改清单、风险点。方案落到具体文件级别，不是一句"优化代码"。
worker：执行工人
方案确认后 worker 才动手，真正落地写代码、改文件、写单元测试、执行 Shell 脚本。所有修改都在独立工作区里完成，不直接污染主仓库。
reviewer：代码评审官
worker 交活后，reviewer 自检代码规范、逻辑漏洞、性能问题、LSP 语法报错，最后输出明确的评审等级。
context-builder：上下文构建器
任务时间长、对话轮次多的时候，context-builder 在长会话里压缩、清洗项目上下文，减少 Token 浪费。它的价值很直接：避免长会话 AI 失忆，改到后面忘了前面。
oracle：双校验复核官
reviewer 过完还不算完，oracle 用第二独立视角二次审核改动，相当于双人交叉审查。多一层独立复核，AI 幻觉就往下降一截。
delegate：通用委托 Agent
偶尔有零散、非常规的自定义任务，就交给 delegate，不占 scout、reviewer 这些专职角色的坑。
八个角色各司其职，这张分工表就是 omp 的部门架构：一个任务进来，主 Agent 按角色派活，责任到人。
三、跑起来之后：担心的几件事被逐个推翻
1. 工作区完全隔离，杜绝冲突
8 个子 Agent 并行干活，我第一反应是它们会互相踩：同时改一个文件怎么办？盯了一轮发现担心是多余的。每个子 Agent 都会创建独立隔离工作树，底层实现按平台不同：
- macOS：APFS 克隆快照
- Linux：Btrfs/ZFS 重链接、OverlayFS
- Windows：ProjFS 镜像
各个子 Agent 修改完全互不干扰，最后由主 Agent 统一合并。多 AI 同时改同一个文件导致覆盖丢失的问题，从机制上就避免了。合并阶段该有的协调一样不少。
2. Schema 结构化输出，不用解析废话
我还担心过它改完怎么验收，结果子 Agent 干完活不返回大段自然语言描述，强制输出 JSON 结构化校验数据，主程序直接机器读取。我第一次看到真实输出长这样：
json
{
"modified_files": ["src/parser.ts", "src/utils/io.ts"],
"exported_interfaces": ["parseConfig", "loadProject"],
"elapsed_ms": 4823,
"cost": 0.042,
"summary": "完成配置解析模块改造，导出 2 个接口，无破坏性变更"
}修改文件列表、导出接口、耗时、调用成本、修改摘要，全在这里。自动化汇总直接吃 JSON，不用人工去啃自然语言长文。
3. 智能体之间可以直接通信
并行任务之间还有依赖，我那次是 A 组件导出完成后，B 路由模块才能适配。我原以为这种前后脚只能靠串行排队，结果子 Agent 支持类 IRC 的点对点私信通讯：A 导出完成后，通过 IRC 通知 B 路由模块适配，B 收到消息再开工。复杂流水线的协同就是这样串起来的。
4. 两种编排工作流
主 Agent 会根据依赖关系选编排方式：
- 串行流水线：规划 → 执行 → 评审 → 复核，适合强依赖步骤，一步做完下一步才动。
- 并行扇出（Fan-out）：多个 Worker 同时开工，适合多文件、多模块的批量改造，比如前端组件批量新增、接口批量补全。
5. 可扩展集群 Swarm 模式
后来试了 Swarm：通过 @oh-my-pi/swarm-extension 插件，用 YAML 编排任意复杂 DAG 多智能体工作流，可以后台常驻、无人值守运行。适合自动化批量工程处理，也能嵌进 CI 流程。
四、半个月下来的价值：几个实打实的落点
1. 大型项目重构能力质变
手头那个多模块项目，Monorepo 结构、多文件大范围改造，跑下来没有乱套：分工明确、可追溯、可回滚。每个改动都有归属，出问题能定位到具体子 Agent 和提交。
2. AI 幻觉大幅降低
幻觉是当初最担心的一环，也是前后差别最大的一环。降低幻觉靠的是三重兜底：多层 Agent 校验（reviewer 加 oracle 两轮独立审查）、真实调试数据（DAP 挂载真调试器拿运行报错）、代码语法校验（LSP 兜底）。每层我都实际看到过。
3. 成本可控
半个月的账单也看得明白：模型自动路由，调研、搜索这类轻量任务自动走廉价模型，只有核心编码才用高端模型。路由规则明确，不是一句"智能省钱"。
4. 结果工程化
所有改动自动生成规范 Git 原子提交记录，一键回滚，Code Review 友好。评审的时候看的就是一个个原子提交，而不是一大坨 diff。
五、用熟了之后：几个改主意的体验
1. 哈希锚定编辑，不写崩文件
之前单 Agent 最大的翻车点是缩进错乱、空格乱改、上下文错位、批量替换把文件写崩。omp 用哈希锚定定位编辑点，之后这些毛病我再没遇到过。印象最深的一次：我手动改了一个文件忘了告诉它，它直接停下来等确认，拒绝覆盖我手动改过的内容。这个设计的目的就是保护有效代码，宁可停下也不误伤。
2. LSP+AST 语法级修改
重命名函数或变量时，全项目所有引用自动同步更新，导入路径、跨文件依赖批量修复。这不是文本瞎替换，是语义级修改，TS、Go、Python、Java 这些主流语言的语义理解都很准。
3. 真能调试 Bug，不再靠猜
绝大多数 AI 只能静态看代码猜问题，omp 可以直接调用 DAP 协议挂载真实调试器：自动打断点、单步执行、查看运行时变量和调用栈、捕获崩溃堆栈。之前排查一个疑似死锁的问题，我先把日志翻了两遍，没看出名堂；它挂上调试器，断点一打，拿到真实运行报错数据，变量卡在哪一眼就清楚了。后端、嵌入式、Rust/Go 底层 bug 的排查体验尤其明显。
4. 子 Agent 并行 + 双层评审
多模块改造时，一条指令派出侦察、规划、编码、评审、复核子智能体并行隔离工作，各自独立工作区互不冲突；主 Agent 统一合并后，还有双层代码评审，标记 P0 到 P3 级风险。
5. 性能丝滑，全平台可用
Rust 内核二进制单文件，内置 ripgrep、持久 Shell 会话、内置浏览器抓取，不反复 fork 外部命令，大项目全局搜索秒出结果。Windows、macOS（M 系列）、Linux x64/ARM64（树莓派）全平台原生支持，Windows 不用依赖 WSL。安装极简，一行 curl 或 powershell 脚本就部署完。
6. 模型极度自由
一次性配置 40+ 大模型服务商：OpenAI、Claude、Gemini、Ollama 本地模型、第三方中转，来者不拒。自动任务路由：复杂编码用强代码模型，调研搜索自动切低成本轻量模型，还支持自动故障降级。本地 Ollama 离线跑完全没问题，隐私敏感项目很友好。
7. 深度融入现有开发流
之前 Cursor 的配置没白搭：直接读取 .cursor/rules、.clinerules 等主流 AI 规则文件，配置可以直接迁移。内置 32 个工具：Git 批量操作、网页结构化抓取、PDF 解析、GitHub PR/Issue 交互、沙箱运行 Python 脚本。终端斜杠命令体系（/plan 规划、/review 评审、/branch 会话分支），熟练后手速极快。
六、劝退点和门槛
以下门槛都是真实存在，用之前先掂量。
1. 学习曲线陡峭，新手劝退
功能太庞大：LSP 配置、DAP 调试器对接、子 Agent 编排、模型路由规则、工作区隔离、插件扩展，整套体系吃透要 1-2 天。对比 claude-cli、普通 Pi、Cursor 对话框开箱即用，omp 属于工程级重工具，纯小白上手压力大，命令也多，不记斜杠命令发挥不出全部能力。
2. 纯 GUI、轻度编码用户完全没必要用
全程依赖 VS Code 图形界面、只写简单脚本、做零散小功能的人，用它属于过度复杂。它本质是终端原生工具，核心使用场景就是重度 Terminal 工作流。
3. 配置初期略繁琐
首次使用要配置各大模型 API Key；部分语言要本地装好对应 LSP 服务；调试功能要适配 lldb/dlv/debugpy 调试器。一次性配置完成后后续基本无痛，但初次搭建确实耗时。
4. 资源开销高于轻量 CLI Agent
开启多子 Agent 并行、长会话上下文、持续调试会话时，内存占用会更高；老旧低配机器多任务并行会轻微卡顿。
5. 小众语言支持一般
前端主流、后端 Go/Java/Python/Rust 支持完美；小众冷门编程语言的 LSP 适配较弱，语法级修改能力会打折扣。
总结
现在我的用法固定了：小改动还是随手写，多文件改造、重构这种活才丢给 omp，丢之前先把本地手动改过的文件跟它说清楚。花两天把配置和规则吃透，值得吗？我现在的答案：看你手头是不是经常有大范围改动。
你如果也在折腾 omp 或者类似的编码 Agent，模型路由、LSP 适配这些怎么配的，评论区聊聊。