一个服务卡住了。开发者不是缺一段更像人的解释，而是需要看到线程、变量和错误发生的那一刻。另一个岗位要接手的，却是“哪些用户受影响、修了什么、下次如何检查”。两种工作需要不同的检查表面。
Oh My Pi 把 IDE 级工具带进终端 Agent；Buda 把对话、文件、执行与预览组织在云端工作区。比较两者，核心问题不是能否编程，而是团队现在缺少深入调试的操作现场，还是缺少跨岗位可接手的任务成果。
从一个断点开始看 Oh My Pi
Oh My Pi，通常简称 OMP，是基于 Pi 扩展的开源编程 Agent。它的 README 将产品描述为“把 IDE 接进来的 coding agent”，并明确列出 LSP 和 debugger。
这些工具解决的是具体工程问题。LSP 可以提供符号、诊断与重命名等代码语义；调试器可以在进程中设置断点、检查栈帧与变量。官方示例涵盖 C 的 lldb、Go 的 dlv 和 Python 的 debugpy。工程师不必只凭 Agent 的解释猜测程序内部发生了什么。
OMP 还支持隔离 worktree 的子 Agent、advisor 模型、代码审查、记忆、MCP，以及浏览器和桌面控制。因此，不能把比较文写成“终端只能改代码，Buda 才能用浏览器”。它已经有丰富的执行和观察入口。
Buda 的 Agent Workspace 提供 Terminal、浏览器、文件、应用预览和 Git 等视图。这里没有证据证明它提供与 OMP 相同的原生 DAP 调试工具，本篇不作此承诺。它的价值在于把任务产物和执行表面放在同一个持久云端环境中。
三种审查对象，不要混成一种
OMP 的能力让三种不同的“审”同时出现。
**第一种是运行时检查。**断点和栈帧回答程序此刻为何失败。它提供工程证据，不直接解释业务影响。
**第二种是 Agent 行为检查。**advisor 可以使用另一模型观察主 Agent 的执行并给出提醒；/review 则以代码审查为目标。模型之间相互检查有价值，但最终仍需确认问题是否被复现、测试是否覆盖以及修改是否合适。
**第三种是交付接受。**产品或支持团队要知道哪些流程变化、哪些客户需要处理、哪些内容可对外说明。这份材料应以文件和证据存在，不应只能在某一时刻的会话里找到。
如果团队的问题主要是第一种，IDE 级工具直接相关。如果第二、第三种之间的交接总是丢材料，就要设计成果包与检查入口，而不仅是再给 Agent 加一个工具。
/collab 是真协作，但共享的是会话
OMP 官方 README 描述了 /collab：可以把实时会话放到 relay，提供链接或二维码；同事可以从另一个终端加入，也可以在浏览器中进入。它区分可读写协作和 /collab view 只读观看，并说明客户端加密的传输设计。
所以，“OMP 没有团队协作”是错误判断。它适合让同事加入同一个调试现场，一起观察或引导 Agent。
选型时要继续问：会话结束以后，哪个版本的结果是交接材料？只读观看者能否拿到最终测试和说明？新同事能否找到任务要求和未解决事项？这些问题并非否定实时协作，而是说明实时参与与异步接手是两种需求。
Buda 的文件和任务执行视图可以作为检查位置。团队依然要指定哪些文件是最终产物、谁负责验收，不能把“放进同一个工作区”说成自动具有正式审批、无限共享权限或审计合规保证。
一个故障，交给两类人
下面是构造的试点场景，未进行 OMP 与 Buda 的对照测试。
假设支付服务偶发超时。工程任务首先需要复现：找到请求条件、观察调用栈，验证是否存在锁等待，再用回归测试证明修复。对于这样依赖运行时状态的问题，OMP 的调试器、LSP 和 worktree 工具值得纳入评估。
工程阶段的产物可以包括：复现说明、修改 diff、测试命令、脱敏日志，以及尚未覆盖的环境。不要把完整客户请求或生产密钥复制到演示材料里。
第二阶段由支持负责人接手。此时需要的不是全部栈帧，而是影响范围、可安全使用的解释、客户处理步骤，以及不能确定的事项。要求生成 incident-summary.md 和 support-checklist.md，每个结论链接到工程证据。涉及退款、客户通知或生产操作的步骤只给建议，不让 Agent 自动执行。
Buda 可以承接文件、日志整理、说明草稿与可视化检查，但不应声称已经通过本场景证明排障能力或业务收益。选择两种产品的依据，是它们各自适合支持的检查方式。
试点要测“下一位同事找到结果”的时间
不只记录 Agent 写代码多久。一个更完整的试点包括四项：
| 检查 | 可观察的证据 |
|---|---|
| 故障是否真正复现 | 复现输入、错误位置、预期与实际结果 |
| 修复能否回归 | 修改版本、测试命令、通过与未覆盖项 |
| 同事能否异步接手 | 不参加实时会话的人能否定位最终文件和依据 |
| 敏感操作能否被限制 | 测试凭据、允许的工具范围、人工确认点 |
同一个工程师做第一轮并不够。让没有参加 /collab 的同事接收资料，标记他找不到的内容。若必须让原操作者口头补充，记录补充时间和原因。这样才能区分工具深度与交接质量。
费用也要分开。开源许可不等于模型和运行环境免费；Buda 订阅也不等于任务消耗固定。使用 当前定价页核对套餐，并单独记录模型消耗、调试维护与人工检查，不给未经测量的省钱结论。
先保留有效的调试现场，再补交接缺口
如果团队经常处理断点、调用栈、符号重命名和复杂仓库改动，OMP 的工程工具有明确价值，不应为了一套统一工作区就忽略它们。
如果痛点是多个岗位拿不到文件、无法回看任务过程，或需要持续组织代码之外的任务，Buda 的工作区值得独立试点。无需把“选择工作区”理解为放弃编程，也不要把云端环境当作性能或安全保证。
两类工作可以分开安排，但本文没有验证 OMP 会话、记忆或 worktree 与 Buda 之间的自动同步。若要交接，先约定导出什么文件、按哪个版本接受，再考虑集成。
FAQ
Oh My Pi 能用浏览器或桌面吗？
能。官方 README 描述真实浏览器和桌面控制工具。实际启用方式、宿主环境与权限需要按其配置核实，不能推断所有安装默认都具备同样访问范围。
advisor 模型是否等于人工审核？
不等于。advisor 是另一模型给执行者反馈；业务负责人仍须检查真实证据并承担接受决定。模型提醒不能替代授权。
/collab 是否支持只读观看？
官方文档列出 /collab view。实时观看与最终交付文件的版本、保留和访问约定仍应分别确认。
Buda 是否替代 OMP 的 debugger？
本篇没有证据支持等同替代。Buda 提供 Terminal 和其他检查表面，但不把这些视图写成已验证的原生 DAP 功能。
OMP 的 benchmark 数字能否说明它更适合团队？
README 的性能数字属于厂商披露。本篇不将其作为独立评测，也不从编辑通过率推断跨岗位交接表现；应采用团队自己的任务测试。
把修复变成能交出的文件
选择一个真实故障，分别列出“工程复现需要的证据”和“支持接手需要的资料”。让第二位同事不参加现场、只凭交付包继续工作。要检查 Buda 的产物组织方式，可查看 Agent Workspace。
资料核验：2026 年 10 月 8 日。OMP 官方 README用于能力事实；故障、文件名和试点为构造示例，不是实际客户事件或执行结果。