授权与升级路径

第三章把权限边界放在一个 agent 身上。到了团队，权限的问题多出一维：每个 agent 什么能自己决定、什么必须往上报，要有一条明确的升级路径。

没有升级路径，团队走两个极端

升级路径（escalation path）缺失，团队就会滑向两个极端。

一个极端是凡事上报。每个 agent 拿不准就往上推，决策全堵在更高一级或人那里，团队空有很多节点，吞吐却卡在瓶颈上，并行的意义没了。另一个极端是什么都自己扛。每个 agent 都觉得该自己拍板，于是越权操作、不可逆动作各自为政，闯祸只是早晚。

两个极端的根都是同一个：没说清什么该由本岗位处理完，什么该上报。

升级路径定义“什么时候交出去”

一条清楚的升级路径要回答三件事：哪类决定由本岗位处理完，哪类要交给更高段位的 agent 或人，什么情况触发上交。

触发条件通常是这几种：不确定性超过阈值（它自己也没把握）、涉及不可逆的对外动作（错了收不回）、超出本岗位的职责范围（不归它管）。命中其中之一，就不该自己硬扛，而该按路径上报。这等于把第三章“按可逆性分配授权”那条规则，从一个 agent 推广到一整条链——可逆的、确定的、份内的，由本岗位处理完；不可逆的、拿不准的、越界的，向上交。

升级路径让风险有地方去

有了它，团队才能既放得开又收得住。

放得开，是因为大量份内的、可逆的决定不必层层请示，各岗位并行推进。收得住，是因为高风险节点——不可逆动作、高不确定性——有明确去处，会按路径交到能担责的地方。团队的自主性，等于清晰的授权加上明确的升级路径；少了后者，自主就只剩失控或瘫痪两种结局。

升级路径的终点常常是人。人在这张图里不是例外，也是一个岗位。他也有自己的职责、权限和交付件——决策哪类事，批准到哪一级；上报到他面前的，该是结论、依据和风险标记，不是原始流水。不把人当岗位设计，上报就成了倒烂摊子：什么都涌向一个无限兜底的入口，人被淹没，升级路径失效。人和 agent 混在一个团队里还能运转，靠的是同一件事：两边都是岗位，接口约束对两边同样生效。