为什么我们建了一个编排器，而不是更多路由规则
静态的 trigger/transform 规则在画布长过几个 Agent 后扩展性很差。这是为什么 MadoHub 现在用一个真正的工具调用循环来路由——以及何时你仍该用规则。
在 MadoHub 大部分时间里，Agent 之间的路由是一个规则引擎。一条连接有一个 trigger（on-idle、on-complete、on-keyword、always）、一个 transform（AI 路由、prompt-wrap、full-output、raw、summary）和 loop-protection 参数。配置一次，它每次都同样地触发。那个模型仍然存在——这是 Agent Routing 和 Flows 文档记录的，也仍是把两个图块连起来做像 peer review 这样的已知模式的最快方式。但它有一个值得具体说的扩展性问题。
问题不是任何单条规则。是数量。
一条带"on idle → prompt-wrap"的连接容易推论：源完成了没？是就转发。麻烦在画布长过几个图块、连接不再独立时开始。
有五个 Agent 和八条连接时，每条规则和每条其他规则互动。A 的输出算不算 B 的 on-keyword trigger 的关键字命中？C 该不该等 D 的冷却，以免同一目标在一秒内被命中两次？这些都没有错误答案——你可以通过加另一种 trigger 类型、transform 或优先级标志解决任何一个。但每个答案都是一条新规则，而规则不组合，它们相乘。一个有 N 个 Agent 的拓扑不需要 N 条规则，它需要接近 N² 的边角处理，因为一条规则对画布其他地方正在发生什么没有模型——它对输出文本做模式匹配并盲目触发。
这是支持一个编排器的真正论据：不是说规则不好，而是一条固定规则在决定做什么之前不能看工作空间其他地方，而一个超过几个 Agent 的工作空间越来越需要恰恰那个。
MadoHub 如何处理
一个工具循环，不是更大的规则
替代方案不是"加一个 AI transform"——MadoHub 早就有那个。而是让路由决策能访问工作空间。默认情况下，一条触发的连接现在打开一个 MadoAgent sub-turn：一个真正的工具调用循环，看一份你画布的快照——每个图块、每条连接的 trigger/transform/轮次状态、近期输出——做一个路由决定，然后停下。
那个决定有意很窄：它可以读文件、查 git 状态、列连接、查路由历史、搜会话、调用记忆，外加恰好一个动作——转发消息，或跳过它。它不能重写画布、变更连接或跑 workflow。指令很简单：内容有实质（一个计划、代码、一份评审）时转发，源输出只是对用户的问题或空话时跳过。一次对实际对话的判断，不是一次模式匹配。
循环保护仍适用，无论路径
用一个模型调用替换一个确定性派发器，不是你第一天就能满信心做的事，所以基于规则系统的护栏原样保留。循环保护限制一条连接在自动停用前能跑多少周期（默认 5），强制触发间最小间隔（默认 3 秒），并可在像 LGTM 这样的停止关键字出现的那一刻结束循环。一个决定每一轮都转发的 sub-turn 仍不能失控——上限和冷却独立于它的决定执行。
shadow 模式，为建立信心
如果你想试新路径而不改行为，shadow 模式让 legacy 路由器实时运行、它的决定是被转发的东西——用户可见行为不变——同时一个 MadoAgent sub-turn 在同一触发上并行跑，纯粹作为比较信号。你能在信任它做实时调用之前，看新路径在真实流量上是否与旧路径一致。legacy 路径在 Settings 里仍可选，留够时间建立信心。
实用指引
- 对已知好形状用 Flows。 三个内置（Peer review、Pipeline、Watcher）仍是固定规则集，因为一个为可重复模式拖下的模板不该每次触发都被一个模型二次猜测。
- 对定制或大型拓扑用编排器。 当没有固定规则集能好好描述你的画布时，一个能在决定前看工作空间其他地方的工具调用循环比又一条规则更通用。
- 对一次性精确控制用手工连线。 在两个图块之间拖一条连接仍是最快路径，当你想对单条链接完全控制、且不需要模板或对话时。
- 保持循环保护开启。 路由循环里的一个 LLM 可能误判输出是否有实质、跳过一条规则会转发的东西，并付出一次模板匹配不会有的延迟和 token 往返。循环保护和交付门保证一个错误决定不会螺旋成无界循环，一次转发不会静默被一个已不在那儿的图块吞掉。