多智能体分工：采集、裁决与执行分离

多个 Agent 开始共用仓库、定时任务和发布权限后，麻烦往往出在开工之前：代码修改被当成研究任务，两个 Agent 同时修一个问题，需要审批的操作直接执行了。Organ 的做法是把任务分配独立出来：代码收集事实，专门的路由 Agent 判断，最后由代码执行硬规则。

作者补充了他们公司五周内的 1,050 次路由请求。数据支持这套设计能暴露问题、约束执行，但还不足以证明它更省钱。对程序员更有用的是：哪些判断可以交给模型，哪些边界必须写进代码。

请求者可以描述问题，但不该决定执行流程

任务路由（task routing）发生在「提出需求」与「开始执行」之间，回答三个问题：任务属于什么类型，由谁负责，现在是否启动。它只是开工前的一次决策；Agent 编排还包括后续运行与交接。

类型选错，会改变后续保障。一次代码修改如果被归为普通任务，就可能绕过测试和审查。

Organ 最初让请求者选择 developer、research、content 等类型，再用部门规则限制工具。作者给出的 90 天生产数据说明，这种方式不可靠：

• 一个描述里写着「不要使用」的废弃通用工具，被调用了 457 次，五个分类工具合计只有 232 次。
• 运营部门 58 次通用任务中，32 次实际修改了代码；营销部门则是 41 次中的 18 次。这些修改没有经过通用任务所缺失的审查和验证。
• 越界请求被要求改写成备注，共发生 973 次，但备注再次被读取的比例只有 10% 到 20%。
• 390 次开发任务用了 390 个不同的查重标签，没有识别出任何重复任务。

部门边界也没有覆盖主要冲突来源。两个主要仓库里，1,576 对执行时间重叠的开发任务，只有 109 对跨部门，占 7%。这些数据统计的是执行重叠，不能直接当成代码冲突率，却说明仅按部门隔离不够。

请求者负责讲清需求，系统负责决定它必须经过什么流程。

模型做判断，代码守住不能商量的边界

作者的方案可以拆成五步。

先由普通代码查询团队职责、进行中的任务、固定日程和当前目标。能查数据库确定的事情，就不让模型猜。

接着由独立路由 Agent 判断任务类型、负责团队、所需权限和启动时机。它可以咨询相关团队负责人，但自己没有启动任务的能力。

然后增加一次独立的策略审查，检查请求是否包含受审批约束的动作。它可以通过请求、移除受限步骤后改写请求，或者拒绝。

之后执行三条代码硬规则：仓库必须属于当前业务，业务不能超过支出上限，同一工作不能已经在执行。模型给出的理由不能绕过这些检查。

最后才启动任务。默认允许，但每次拒绝都要说明怎样才能继续，例如补充仓库名称，或交给指定团队。

这里的关键不在于多问一次模型，而在于把判断权和执行权拆开。独立审查仍然是模型判断，不能等同于确定性的权限控制；真正不能越过的边界，需要执行系统落实。

为什么还要单独审查？他们曾收到「合并这个 PR」「发布两篇已经批准的文章」等请求，路由器照常分派，其中一个任务九分钟后就合并了 PR。关键词过滤也不够，因为合法请求可能写着「rebase，但不要 merge」。

后续五周有 5 次请求因直接要求受限操作而被拒绝，并收到审批路径。不过，这个数量只能证明拦截发生过，不能说明所有越权请求都被识别了。

1,050 次请求说明了效果，也留下了空白

更新窗口是 2026 年 10 月 5 日至 11 月 8 日，全部来自 Organ 自家公司，没有客户数据。

扣除 35 次取消，1,015 次请求中有 875 次形成决策，占 86.2%，另有 140 次失败。形成决策包括允许和拒绝，不能读成任务执行成功。此前窗口是 1,233 次已结束路由运行中有 1,064 次形成决策，占 86.3%；一个统计请求，一个统计运行，只能说大致相当。

64 次拒绝中，40 次涉及仓库未明确或未登记，7 次工作已经在执行，5 次请求受限步骤，5 次属于其他团队，另有 7 次其他原因。拒绝率为 6.1%，其中最常见的问题是缺少执行所需的信息。

性能也要分清起点。从路由器接手到记录结果，中位数为 28.5 秒，P90 为 49.6 秒；按周统计的请求到结果耗时，中位数则从 78 秒降到 37 秒，中间曾升到 97 秒。

原文用下面的数据描述每周耗时，它能帮助区分整体改善和短期尖峰：

{"type":"line","title":"Median time from routing request to recorded outcome, by week","caption":"Weeks start Monday, UTC. Requests with a recorded outcome only. 90th percentile by week: 333 s, 304 s, 511 s, 227 s, 64 s.","source":"Organ production routing records, Organ's own company only, 5 October to 8 November 2026 (aggregate)","data":{"labels":["Oct 5","Oct 12","Oct 19","Oct 26","Nov 2"],"datasets":[{"label":"Median seconds","data":[78,73,97,45,37]}]},"options":{"unit":"s"}}

要看 caption：这里只统计有记录结果的请求，不能据此推断所有请求的等待体验。

路由器复用请求者已经运行的机器，因为设计时启动新机器平均需要 775 秒，P90 达 1,586 秒。代价是请求者机器出故障，路由也会中断。

费用则没有本期结论。成本记录无法关联到具体请求，所以作者没有报告数字；此前每次已启动运行至少花费 $0.77，且有 122 次缺失成本记录，这只是下限。

失败必须可解释，完成必须有外部证据

上线首夜，他们把 run ID 同时用作查重标签，导致同仓库后续请求撞上数据库唯一性约束：45 次失败、2 次成功路由，另有 17 次请求卡在等待。修复方式是每个请求独立建运行记录，查重另用请求日志。

更严重的问题是失败没有原因。此前七周的 169 次失败中，83 次来自请求者机器故障，另外 86 次原因缺失。抽查其中 8 次后，他们发现路由轮次会撞上 360 秒限制，日志却只记了开始。

后来系统明确记录 FAILED、原因和重新请求的提示，不再退回请求者自选类型，也不静默重试。只有流连接丢失、worker 重启或路由超时，允许一次新的尝试。

更新窗口里的 140 次失败全部记录了原因：101 次机器或运行时故障，19 次任务已无法继续，10 次没有任何 Agent 同时具备所需工具，3 次未及时记录决策，其他 7 次。每周失败数从 54 次降到 11 次，失败率从 20.2% 降到 7.7%，最后一周机器故障归零。

这些记录能区分基础设施、权限配置和决策问题，但原文没有对照实验，不能把下降全部归功于某一项改动。

作者还给了一个示意流程：周三的技术 SEO 检查发现 sitemap 中某页面发生重定向，提出修复需求，路由器分配代码任务，最终开 PR 等待审查。这个例子不是实测运行记录。它最有价值的要求是：下次检查确认线上页面已修复，才能关闭问题，不能只看任务显示完成。

我的判断

我认同把审查、查重和权限边界从请求者手里拿走。类型标签一旦能决定是否测试、是否审批，就不能完全相信请求者自行填写。

但模型路由器并非默认答案。只有两个职责清楚的 Agent，直接写「代码交给开发 Agent」通常更简单。作者自己也承认，新旧窗口形成决策的比例几乎没变，本期成本又缺失，因此「更省钱、更可靠」都没有充分证据。

他们团队已经有共享仓库、日程、目标和审批体系，普通团队未必具备这些前提。尤其是查重：原文解释了旧键为什么失效，却没有交代新系统怎样判断两个自然语言请求属于同一工作。这仍然是落地时需要解决的问题。

更适合先复制的是硬规则、失败原因和结果验证，再考虑增加模型路由。

能拿来做什么

• 给现有 AI 编程流程增加执行入口检查，先核对仓库、预算和进行中的工作；职责简单时，继续用静态规则分派即可。
• 让前端或 Node 修复请求描述现象、影响范围和证据，由系统判断是否需要代码审查，并在仓库不明确时返回补充条件。
• 为路由记录失败原因和状态变化，分别统计决策耗时、失败率、拒绝率及查重命中，保留每项指标的分母。
• 把巡检任务的关闭条件写成可验证结果，例如线上 URL 恢复预期行为，而不是 Agent 已结束运行。