今天我们把一件很小的事真正接通了。
一个施工 Agent 完成代码，提交 PR；GitHub Actions 自动把 diff 交给一个独立 Reviewer；Reviewer 给出结论和 findings；结果再进入本地施工 Agent 可以读取的位置。如果施工方修了问题，再 push 一次，Review 会重新发生。
它看起来只是一套 AI Code Review。
但跑通以后，我突然觉得，这件事和之前一直想的“一人公司”“Mira Forge”其实是同一个问题。
我们已经给单个 Agent 做出了循环，却还在靠人复制粘贴连接不同 Agent。
这可能才是现在最值得消灭的一层摩擦。
上一篇 《OPC 探索（二）：Mira Forge，一间本地 AI 工程调度室》 讨论的是怎么让多个 AI 工具真正接力。这一次，我更想把它往产品层抽象一步：当 Agent Loop 从单体内部走向多个 Agent 之间，会发生什么？
我还是讨厌那种半成品#
前些天我看过一套“一人公司”式的 AI 产品。
打开客户端，里面是几十个所谓 AI 员工：运营助理、客服、总监、不同平台的专家，各自有头像、职位和卡片，甚至还有一套组织架构。
我的第一反应并不好。
甚至可以说，我很不屑。
因为做技术的人一眼就会问：
这些“员工”之间到底有什么真实差异？
它们有独立的工具、知识、权限和运行状态吗？
任务会在它们之间真的交接吗？
它们能验证自己的工作吗？
一个所谓“专家”到底是在执行一套专业流程，还是只换了一份 prompt 和话术？
如果只是把几十个角色摆进一个漂亮客户端，再配上几个很浅的能力，我仍然认为这是半成品。
今天也没有因为它能卖钱，就突然觉得这种东西完成度很高。
我依然讨厌这种半成品。
这件事没有必要在文章里替自己圆。
但我以前把“半成品”直接等同于“没有商业价值”#
真正需要修正的是另一件事。
我以前太容易从能力真实性出发评价一个产品：
能力够不够深？
实现靠不靠谱？
能不能稳定运行？
所谓专家是不是换皮？这些问题都没错。
错的是，我下意识把它们当成了商业价值的全部。
现实里的客户可能根本不关心 Agent、MCP、Skill、RAG 和工具权限怎么组合。
他只知道：
我不会做小红书。
我没有专门的运营。
我不知道该怎么问 AI。
如果这里有一个“运营专员”，我点进去就能开始干活，会不会比现在方便？对一个已经熟练使用各种 AI 工具的人来说，“几个专家卡片”可能非常浅。
对一个从来不会配置 AI 的小公司来说，它可能已经跨过了最重要的第一道门槛：让人知道自己可以拿 AI 做什么。
所以我现在会把两个判断分开。
产品完成度是一个判断。
商业价值是另一个判断。
一个东西技术上可以是半成品，同时依然抓住真实需求、降低理解门槛、形成销售入口。
承认这一点，不等于我要喜欢它。
只是说明我以前的视野确实窄了一块。
多智能体的价值，不应该是界面里能摆多少个 AI 员工#
这也是我重新思考“多智能体”以后，越来越在意的区别。
第一种多智能体很容易做成：
运营专家
客服专家
产品专家
技术专家
法务专家
……用户看到的是一张组织架构图。
每个角色都能聊天，都有不同 prompt，也许再挂一点知识库和工具。
它当然可以有用。
但如果任务始终是：
用户找 A
↓
A 输出一段文字
↓
用户复制
↓
粘给 B
↓
B 再输出一段文字
↓
用户继续搬运那么真正负责“组织”的人，还是用户。
模型很多。
角色很多。
但系统并没有形成组织行为。
所以现在我更愿意用另一个标准判断多智能体：
多智能体的价值，不在于界面里能摆下多少个 AI 员工，而在于任务能不能在智能体之间流动。
我们已经习惯了微观 Agent Loop#
一个 Agent 内部的循环，现在已经很容易理解：
Goal
↓
Reason
↓
Tool
↓
Observation
↓
Reason
↓
Tool
↓
……
↓
Answer模型不是一次性生成答案。
它执行工具，读取结果，再根据 Observation 决定下一步。
这就是一个微观的 Agent Loop。
但到了多个 Agent 之间，我们经常突然退回最原始的交互方式。
例如写代码：
Coding Agent 写完
↓
我复制结果
↓
丢给 Review Agent
↓
Review Agent 给意见
↓
我复制意见
↓
再丢回 Coding Agent这其实很荒谬。
每一个 Agent 内部都已经可以自动循环几十步，人却还在 Agent 与 Agent 之间充当剪贴板。
也就是说：
我们解决了单体智能的循环，却没有解决智能体之间的循环。
宏观 Agent Loop：一个 Agent 的 Output，成为另一个 Agent 的 Observation#
这次 Code Review 实验让我第一次很具体地看到这种结构。
Builder Agent
↓
Code / PR
↓
Reviewer Agent
↓
Findings
↓
Builder Agent
↓
Fix
↓
Reviewer Agent这里最重要的并不是“用了两个模型”。
甚至不要求两个角色一定使用不同模型。
关键是：
前一个 Agent 的产物，能以稳定合同直接成为下一个 Agent 的输入。
Reviewer 的 findings 也不是停在 GitHub 上给人看完就算，而是能被施工 Agent 拉回本地，判断哪些需要修、哪些应当拒绝、哪些需要人介入。
这时 loop 才真正跨出了一个 Agent 的边界。
我暂时把这种东西叫做 Macro Agent Loop，宏观智能体循环。
微观 loop 解决：
一个 Agent 如何连续完成一件事。
宏观 loop 解决：
多个拥有不同职责、权限和上下文的 Agent，如何围绕同一个目标持续协作。
“减少复制粘贴”是入口，不是终点#
产品上我反而不想一开始讲得特别玄。
用户最先感受到的问题甚至不是“我要一个宏观智能体组织”。
而是：
我为什么一天到晚在复制粘贴？
我现在实际工作里最烦的事情之一就是这种搬运：
- 把需求搬给施工 Agent；
- 把施工结果搬给 Reviewer；
- 把 Review 意见搬回施工 Agent；
- 把测试结果再搬回来；
- 重新解释“这是刚才那一版，不是上一版”。
所以第一层产品价值很朴素：
先让人不要再当消息总线。
但是一旦搬运被消掉，后面自然会出现更大的东西。
系统开始知道：
谁在施工
谁负责 Review
当前是哪一个版本
Review 针对哪一版
哪些 finding 还没解决
什么时候应该返工
什么时候满足放行条件
什么时候必须停下来找人这已经不是一个“自动复制文本”的功能了。
它开始拥有组织状态。
角色应该来自责任，而不是来自卡片数量#
这也改变了我对“AI 员工”这个产品表达的理解。
一个真正有意义的角色，不应该只是：
你现在是一名资深产品经理。角色至少还应该意味着：
你能看到什么
你不能看到什么
你可以调用什么能力
你对什么结果负责
你的上游是谁
你的产物交给谁
失败以后回到哪里
什么情况下必须让人决定所以一个 Reviewer 真正成立，不是因为 UI 上写着“代码评审专家”。
而是因为它：
- 只负责审查，不偷偷施工；
- 针对明确版本给出 Review；
- 把观察、推断和判断尽量分开；
- 输出有稳定格式；
- 结果能回到 Builder；
- 自己无权把“我认为没问题”直接变成整个流程的最终放行。
这时“角色”才不只是人格设定，而成为系统里的责任边界。
判断权和放行权，最好不是同一种权力#
这是这条实验继续往前走以后，一个越来越清楚的产品判断。
第一版我们为了安全，干脆不让 Reviewer 自动 PASS，也不让它自动 merge。
这很适合刚开始跑一条 loop：先证明 Reviewer 能稳定看对版本、产出结构化结论、把结果交还给 Builder。
但如果永远所有“通过”都要人再点一次，那么人仍然在做大量机械确认。
问题不应该变成：
要不要把最终权力都交给 Reviewer？
更合适的问题是：
哪些是需要智能判断的事，哪些只是已经写清楚的规则？
于是角色可以继续拆开：
Builder
↓
Reviewer（判断）
↓
Findings / Verdict
↓
Gatekeeper（规则）
↙ ↘
返工 放行Reviewer 负责理解代码和合同，回答“我看到了什么”“为什么可能有问题”“当前有没有阻塞项”。
Gatekeeper 不需要扮演另一个聪明角色。
它只检查那些已经确定的事实：
Review 是不是针对当前版本
必要检查是否通过
有没有明确要求人工介入
任务是否处在允许放行的状态
目标分支和流程是否符合约定如果这些条件都满足，系统可以自动把任务推进到“评审通过”、在代码托管平台留下正式的通过信号，或者进入 ready-to-merge。
如果条件不满足，就不放行。
这里最重要的不是“又多了一个 Agent”。
恰恰相反：Gatekeeper 最好不是另一个模型。
它更像公司的门禁制度：Reviewer 可以发表专业判断，但门什么时候开，由明确规则决定。
这让我越来越觉得，真正的多智能体系统不只需要“角色”，还需要认真设计权力从哪里来、权力到哪里为止。
外面可以很简单，里面不能是假组织#
用户不应该先学一套 Agent 架构才能用产品。
真正对外的界面完全可以非常简单：
施工
评审
返工
通过甚至最后用户看到的可能只是：
任务正在施工，Reviewer 发现两个问题，已经自动返工一次；当前检查全部满足，已经进入待合并。
或者：
Reviewer 没发现阻塞问题，但这次改动触发了人工确认条件，需要你决定。
这已经足够了。
但简单的界面下面，应该有真的：
state
evidence
permission
handoff
version
review
gate
recovery这可能是我现在最希望守住的区别：
产品可以把复杂性藏起来，但不能用包装假装复杂性已经被解决。
人并不会从 loop 里消失#
增加 Gatekeeper 并不是为了把人彻底拿掉。
它只是继续消灭另一类低价值动作：
明明所有条件都已经满足
↓
人再检查一遍同样的绿灯
↓
再手工改一个状态
↓
再点一次“通过”如果规则足够清楚，这些动作没有必要长期由人承担。
以后人更应该做的是：
定义目标
决定规则和边界
处理 Reviewer 无法确定的灰区
授权高风险动作
处理冲突
决定真正需要承担责任的最终动作自动 merge 也不必因为有了 Gatekeeper 就立刻打开。
至少在这条路线的早期，我更愿意把“评审放行”和“最终合并”看成两个不同层级的动作。规则明确的 Review 可以自动通过；真正改变主干、发布或触发高风险后果的动作，仍然可以保留人为确认。
这和最开始讨论一人公司时的判断又接上了。
“一人公司”并不是一个人做完所有事情。
更理想的状态是：
只有真正需要这个人承担责任的决定，才必须经过这个人。
我现在更愿意从“组织行为”看 Agent 产品#
回头看那套几十个 AI 员工的产品，我的态度其实没有发生戏剧性的反转。
我还是不喜欢。
我还是觉得很多能力停在非常浅的位置。
我还是讨厌把尚未形成可靠能力的东西包装成一个完整组织。
但我不会再因为这个判断，就顺手推导出“它没有商业价值”。
更重要的是，它逼我补上了一个以前看得不够多的维度：
客户购买的不是我们的技术洁癖。
而我们真正可以继续往前做的，也不是嘲笑别人只有几十张 Agent 卡片，再做出另外几十张更漂亮的卡片。
我更想做的是另一件事：
过去我们把多智能体做成了一张组织架构图。下一步，也许应该把它做成真正的组织行为。
Code Review 只是这条路上第一个很小、但已经真实运转起来的样本。
如果 Builder、Reviewer、Gatekeeper、测试、发布、资料采集、需求整理都能逐渐形成稳定 handoff，那么 Agent Loop 就不再只发生在一个聊天窗口里面。
它会开始跨工具、跨角色、跨时间运行。
那时候，“一人公司”才可能不只是几十个 AI 员工的头像。
而是一套真的能工作的系统。
这篇主要讨论产品判断。具体的 GitHub Actions、OpenCode Go、项目级 Review Skill、可信权限边界、版本校验与确定性门禁设计，单独写在 Mira Docs：
《把 AI Code Review 接成一个真正的 Agent Loop》。
