多 Agent 团队治理（3/3）：轨道机如何服务自主工作而不越权

一支 Agent 团队的价值，不是等待一个"总控大脑"替每个成员决定下一步，而是在清楚任务、角色和权限边界内，把能够自行完成的工作持续向前推进。轨道机在这里应是服务层：提供谁可领取什么、事实在哪里、依赖何时解除、进程中断后怎样恢复的共同能力；它不应取代 Agent 的专业判断，更不应取代 PM 或 ADMIN 的业务决定。

多 Agent 系统有两种相反的失败。

第一种是没有轨道服务：任务靠聊天转发，两个 Agent 重复开工，报告找不到上游，进程崩溃后没人知道该重试还是停止。每个 Agent 看似自由，实际上无法可靠地协作。

第二种是轨道服务越权：一个分类器觉得计划"不够完整"，系统就禁止 PM 派工；测试附件暂时没出现，Runtime（运行时）便宣布任务失败；重试达到固定次数，技术冷却被写成业务 blocked（阻塞）。表面上治理更严格，实际上服务层正在替有权的人作决定，也剥夺了 Agent 在其职责范围内自主处理工作的空间。

好的轨道机必须同时避开两端：**让 Agent 在授权任务内自主执行；让轨道尽可能自动地提供事实、派工、审计和技术恢复；只对一组封闭、可复核的机械条件作硬拒绝。范围、验收、返工与最终结论仍由 Agent、PM 或 ADMIN 决定。**本文用 CodeFlowMu V1.9.7 候选实现和固定测试解释这条服务边界，并给出一份可直接用于架构审查的分类方法。

系列阅读顺序（3/3） 第一篇解释三层责任与策略版本；第二篇检查 TASK 生命周期与并发认领；本文收口轨道处置。三篇中的来源冲突、身份不足与双阶段路径冲突统一使用 unknown_reconcile，不是互不相干的恢复机制。

轨道机服务于 Agent 自主协作，不是状态机，也不是项目经理

文件状态机回答"任务现在处于什么阶段，怎样迁移到这里"。轨道机回答"哪个角色获得任务、哪个会话运行、工具能否调用、依赖何时释放、进程中断后如何恢复"。两者必须连接，但不能混成一个组件。

轨道机也不是项目经理，更不是替 Agent 写方案或盖章的上级。PM 需要理解需求、选择执行路线、判断证据是否足够、决定返工或接受；执行 Agent 也必须在已授权的任务和工具范围内自行拆解、实施和提交证据。这些判断包含业务或专业语义，不可能从文件是否存在、运行了多少分钟或分类器给了几分机械推出。

因此，所谓"自主"不是不受约束：它是在可见任务合同、角色能力、当前修订和证据要求之内自行推进。轨道机把这些约束和协作事实做成可靠服务，使 Agent 不必靠猜测其他成员是否已经领取、依赖是否满足或旧会话是否已经失效；但轨道不能把这种服务能力扩大为替团队决定目标或结论。

NIST 的 AI RMF 1.0 把治理、角色责任与人工监督放在整个 AI 生命周期中，而不是只放在最后一次审核。它没有定义"轨道机"，但提供了独立的治理背景：自动化机制必须处于清楚的责任结构之内。

先把 Agent 自主动作与轨道服务分成四类

类型	典型问题	Agent 与轨道各自应做什么
事实服务	报告是否存在？任务在哪个目录？当前修订是什么？	轨道记录并展示；Agent 据此继续自己的工作
建议服务	证据可能不足，是否需要补测？	轨道给出理由和建议动作；有权 Agent 或 PM 决定
机械等待	明确依赖尚未满足，是否已经轮到当前任务？	返回 `waiting_dependency`；当前动作等待，不把它写成拒绝或任务失败
机械拒绝	身份冲突、权限越界、任务已终止或执行重复	返回 `negative_list_denied`，拒绝当前动作并留下证据；不替业务关单
业务决定	是否派给 QA？结果能否接受？是否值得继续返工？	交给有权 Agent、PM 或 ADMIN

最危险的错误，是把第二类悄悄升级成第三类。例如，"附件暂时缺失"是一个事实缺口；如果任务合同明确规定附件是启动前置条件，它才可能成为当前动作的机械阻断。否则，Runtime 应把缺口交给 PM 判断，而不是自动关单。

V1.9.7 怎样把边界写进合同

CodeFlowMu V1.9.7 的轨道辅助接口只允许四种处置：

ts 复制代码

type RailAssistanceDisposition =
  | "neutral"
  | "unknown_reconcile"
  | "waiting_dependency"
  | "negative_list_denied";

neutral：事实可用，轨道不作允许或拒绝裁决；
unknown_reconcile：来源缺失或冲突，需要对账；
waiting_dependency：正式 TASK 中的明确依赖尚未满足，当前动作等待而非被拒绝；
negative_list_denied：命中冻结负面清单，当前动作必须拒绝。

返回值还带有 decision_owner，明确下一步判断属于 Agent、PM 还是 ADMIN。治理事实内核则固定写入：

ts 复制代码

business_decision: null

这两个细节共同形成一条可测试的边界：轨道可以生产事实和命令入口，但不能在快照里偷塞一个业务结论。

三种非业务处置不能混为一类。unknown_reconcile 表示来源缺失或冲突，需要对账；waiting_dependency 表示正式 TASK 的明确依赖尚未满足，当前动作等待；只有 negative_list_denied 才是命中冻结机械条件、必须拒绝当前动作。已检查的 V1.9.7 合同把前两种和硬拒绝分开，因此不能把 unknown_reconcile 写成现成的自动冻结、自动通知 PM 或自动回滚机制，也不能把依赖未满足写成一次拒绝或任务失败。若高风险下游动作确实需要在冲突时停住，必须由正式 TASK 前置条件、冻结机械规则，或 PM/ADMIN 的显式决定提供依据；系统不能靠启发式挑选任一冲突分支。

但只定义进入条件还不够。生产级 unknown_reconcile 必须有一个有界处置信封：reconcile_owner、规范任务身份与修订、冲突来源、opened_at、SLA 截止、升级目标、允许的终止结果和最终裁决证据。进入对账后应停止业务推进和模型轮询，只保留确定性监控与一次性通知；到期只能按预先版本化的策略升级给 PM/ADMIN、继续挂起或执行受权回退，不能启发式删边或自行判失败。当前证据没有证明 V1.9.7 已经完整实现这套信封和 SLA。

这些代码来自 CodeFlowMu 私有母版固定提交 2c901972 的短摘录；它们不是 CodeFlowMu Open 代码，也不能供公众直接克隆复现。公开这一小段接口合同，是为了让读者检查"轨道能输出什么、不能输出什么"的架构边界；它既不等于开放完整实现，也不应被当作公众可复跑的产品证据。

为什么机械拒绝必须封闭且可复核

V1.9.7 当前合同把机械拒绝限定为一组封闭、可复核的条件：

已有明确禁止当前动作的 ADMIN 或授权决定；
授权作用域不匹配；
合同已定义字段中的规范任务身份不一致；
任务已经处于不可继续的终态；
同一执行被重复创建；
出现完整性或安全错误。

这些条件的共同点是：它们能够由确定性事实复核，而不要求 Runtime 猜测"这个计划是否聪明""这份报告是否值得接受"。其中第 3 条不能用"真实冲突"这样含混的形容词带过：具体合同必须列出参与比较的字段、规范化方式和不一致时的结果。例如可比较任务、根任务、线程和修订等已绑定字段；字段缺失、比较规则未定义或事实彼此矛盾时，应进入 unknown_reconcile，而不是假装已经满足机械拒绝条件。已检查材料披露了这些命令绑定字段，但没有公开完整的复合身份判定式，因此本文不把它写成已穷尽验证的算法。

来源冲突本身通常首先进入 unknown_reconcile，而不是自动被塞进这张清单。只有当冲突满足一条已写入合同的确定性谓词，例如已定义身份字段不一致、作用域不匹配或已有明确禁止当前动作的决定，轨道才可把当前动作 转为 negative_list_denied。否则它保留冲突并请求有权主体对账。

显式依赖是另一类可复核的机械条件：它返回 waiting_dependency，使当前动作停在等待队列，待上游满足合同后再释放；它不属于冻结负面清单，也不构成对任务或业务结论的拒绝。

所谓"封闭清单"，必须精确到某一版本策略包内的确定性谓词集合 ，而不只是六个自然语言标签。身份比较若没有公开参与字段、规范化算法和缺失字段处置，就不能声称该谓词已经可独立审计；此时应返回 unknown_reconcile。同样，未来加入独占认领后，"另一份有效保留已经存在"能否拒绝当前认领，也必须先成为策略包中的版本化谓词，不能由工程补丁临时发明。

治理策略如何进入轨道，而不被工程补丁改写

治理规则需要以版本化 Policy Bundle（策略包）进入 CodeFlowMu，而不是一部分写在 TMPA 文档、一部分散落在 TypeScript 判断中。最低字段应包括：策略 ID 与版本、内容摘要、适用 Runtime 范围、角色与作用域规则、身份规范化方式、依赖变更权限、机械拒绝谓词、迁移要求、批准者和回滚条件。每次处置结果都要记录实际消费的策略版本。

策略更新也不应在一个运行中的任务轮次里静默热替换。新包通过校验和 ADMIN 授权后，在声明的任务或 Runtime 边界生效；旧轮次继续绑定旧版本，或通过明确迁移重新准入。这样才能回答"当时为什么拒绝这次动作"。

并发修复尤其要遵守这一点。O_CREAT | O_EXCL、不可覆盖保留或比较---交换只提供物理互斥；谁可以竞争、失败是否属于 negative_list_denied、何时允许重试、保留何时失效，仍是治理规则。紧急补丁可以先关闭多领取者入口或降级为单 Runtime，但不能一边新增锁，一边未经策略升级就改变任务执行权的分配方式。

依赖图同样属于治理承载物。执行 Agent 可以提出改边请求，不能直接修改已存在 TASK 的依赖；PM、ADMIN 或策略明确委派的主体批准后，系统生成新修订并重跑身份、作用域、DAG 和旧修订拒绝检查。当前材料尚未证明所有写入入口已经统一服从这条规则。

清单越长，越容易把业务偏好伪装成基础设施事实。比如"计划少于三个步骤""没有先写 ISSUE""运行超过十分钟"都可能是有用提醒，却不能普遍推出任务应当停止。PM 或 ADMIN 可以在任务创建、修订或正式审批时写入合同或作出决定；但不能在运行时临时把一条偏好"映射"为机械阻断，让服务层绕过既定规则。轨道只复核已经冻结在合同或明确决定中的条件。

轨道机真正应该自动做什么

1. 绑定身份和作用域

每次任务命令都需要绑定当前任务、根任务、线程、执行轮次和修订。旧修订上的命令、错误任务上的能力或不同业务意图复用同一防重复流水号，应当在执行前被拒绝。

2. 检查角色工具能力

开发、测试、运维和审查角色不应看到同一套可变更工具。V1.9.7 的角色门禁按规范工具 ID 和活动能力精确检查；在已检查的 PM 任务修改路径中，请求通过统一 TaskCommandKernel（任务命令内核）进入，因此身份、作用域和防重复检查在这条路径上执行。这个证据不等于已经穷尽所有旧接口或替代入口；要证明不存在绕过，还需要端点清单、静态扫描和针对绕过路径的拒绝测试。

但这只是工具准入，不是完整副作用分析。工具参数能否逃出项目根、底层进程拥有什么操作系统权限，仍需要各自门禁和沙箱。

工具准入还不应只看静态角色。工程上应把任务生命周期、当前修订和动作目标作为另一层操作策略：例如一个任务已经进入 review 或终态时，执行者继续写代码的请求应重新核对是否仍有显式、有效的返工或执行入口。当前已检查的 V1.9.7 证据证明角色工具 ID、活动能力、任务作用域和修订检查，但没有证明所有工具已经按 active、review、done 阶段实现统一的动态收缩；这是一项应补充的策略和测试，不是本文声称已经完成的功能。

3. 排队并释放明确依赖

QA 任务明确依赖某个 DEV 子任务时，轨道可以把 QA 留在等待队列，直到上游提交符合合同的结果。这里的暂停来自 TASK 中可复核的依赖，不来自分类器对自然语言的猜测。

一个对照例子：如果 QA 只看到某份旧轮次的 DEV 报告就开始测试，可能把上一版输出当成本轮输入；正确的合同应把 QA 任务指向具体上游任务及其当前修订，未满足时返回 waiting_dependency 而不启动 QA。待上游的完成证据与所绑定的版本相符后，轨道才释放这条边。这个例子说明需要怎样设计可复核依赖；本文没有把它写成 V1.9.7 已经覆盖所有报告---修订匹配组合的测试结论。

4. 保存长作业的技术事实

需要跨会话、跨 Runtime 重启运行的长作业，可以交给托管命令服务保存状态、日志和取消边界。V1.9.7 候选实现同时明确：短测试与普通构建可以使用 Host（宿主环境）原生命令工具；缺少托管命令不能被解释为 Agent 无法工作，更不能阻止 REPORT。

5. 自动唤醒与确定性恢复

轨道可以重新唤醒等待中的 Agent、恢复可确认的 Session、重试确定性技术步骤，并为多次失败增加冷却和审计。次数和时间适合限速与提示，却不应自动变成永久业务阻断。

自动恢复的输出应是："当前观察到什么、已经机械修复什么、仍缺什么事实、建议谁决定下一步"，而不是"系统替 PM 判定项目失败"。

超时也应被当作技术事实，而不是业务裁决。V1.9.7 的可选托管命令服务可保存长作业状态、连续日志、有限等待与精确授权取消；这支持记录"哪次会话或工具调用超过了预期窗口"，却不证明所有会话都已有心跳、自动诊断或 PM 推送。一个合格的后续策略应把超时记录进会话/作业证据，暴露给决定者重试、接管或终止选项，并避免静默把技术超时升级为 Task Failure（任务业务失败）。

一个三秒看懂的边界例子

假设 QA 报告已经到达，但缺少任务要求的兼容性测试原始日志。

错误做法：

text 复制代码

Runtime 发现附件缺失
→ 自动把根任务标记 failed
→ 永久停止 PM 汇总

正确做法要分情况：

text 复制代码

如果 TASK 在创建、修订或正式审批时已经把"没有该日志不得验收"写成冻结的确定性前置条件
→ 轨道记录证据缺口，并拒绝当前验收动作
→ PM 决定补测、返工或调整合同

如果该日志只是分类器建议
→ 轨道只展示缺口和建议
→ PM 根据风险与现有证据决定是否继续

这里的第一种分支是合同设计示意，不是本文声称 V1.9.7 已把任意附件缺失自动升级为拒绝。若现行接口没有这种预先冻结的谓词，正确行为仍是记录证据缺口并交给 PM。

V1.9.7 实际验证了什么

V1.9.7 的第一方候选证据包 V1.9.7-RAIL-ASSISTANCE-RC-20260822-001（候选代码 9e4c6e6a）记录了以下结果。证据包分别记录母版检查、候选代码回归和受控重启加载，不能把它们压缩成一个"所有结果都来自同一提交"的断言：

固定关键场景连续 10 轮通过，每轮 Runtime 115/115；
Runtime 全量回归 1706/1706；
Shell 全量回归 936/936；
Runtime 类型检查、Shell 生产构建、REPORT 身份和版本一致性检查通过；
受控重启后，进程加载 V1.9.7，健康状态为 ok，网关在线、单写者锁仍归当前进程、项目根绑定保持一致。

这些计数属于不同层级的测试集合，既不能相加，也不能被读作"轨道辅助四种处置都被同等覆盖"。现有证据包没有登记 neutral、unknown_reconcile、waiting_dependency、negative_list_denied 各自直接覆盖了多少用例；因此本文不以 115、1706 或 936 证明这四态边界已经完整验证。下一版证据包应单列四态的命名用例、预期处置和实际结果。

下一版不能只把总数拆成四个数字，还应建立"治理主张---策略谓词---代码入口---测试用例---持久证据"的对应表，至少覆盖：身份字段缺失进入对账、双阶段冲突共用对账入口、对账超时不产生 Token 空转、未授权依赖修改被拒绝、获准改边生成新修订、并发认领至多一个赢家、失败领取者零外部副作用，以及策略版本切换不改变旧轮次语义。在这张矩阵形成前，回归全绿只能证明受测代码路径稳定，不能证明治理合同已经完整。

本文没有使用 CodeFlowMu Open 源码或 Open 测试数量作为能力证据。

这些数字只支持记录中的固定 Windows 工作站、候选代码和测试集合上的受测行为；母版检查、代码回归与重启加载分别对应证据包中的不同节点。它们不是渗透测试、第三方复现、形式化证明或跨平台可靠性结论。证据包还保留了早期变更检查发现的旧断言失败，没有用最终发布检查全绿覆盖历史失败。

版本状态同样需要说准确：当前版本文件和实机进程显示 V1.9.7，但发版说明仍标注"候选版本"，只有 ADMIN 能作最终 RELEASED 决定。轨道机不应替 ADMIN 发布，文章也不应替 ADMIN 改写版本事实。

仍然存在的风险

第一，冻结负面清单是工程合同，不是完整威胁模型。提示词注入、工具参数逃逸、供应链风险和外部副作用仍需要更底层的权限与安全控制。

第二，事实内核存在并不自动保证每个旧接口都只消费它。V1.9.7 的回归和静态扫描降低了旧裁决路径复活的风险，但不能证明未来代码不会重新引入平行分类器。

第三，技术恢复可能成功，业务结果仍可能无效。恢复了进程、重新拿到日志、重新投递报告，都不能代替 PM 核对内容，更不能代替 ADMIN 对高风险动作作决定。

第四，当前验证是第一方证据。更强的结论需要独立复现、更多故障点、不同 Host 与文件系统环境，以及对真实长期团队的观察。

用这张表审查自己的轨道

对每条自动化规则，逐项填写：

它读取的事实来自哪里？
事实缺失时输出"不知道"，还是自行猜测？
它给的是建议，还是会停止动作？
如果会停止，理由是否属于一条短而冻结的机械负面清单？
它停止的是当前动作，还是越权关闭整个业务任务？
最终决定者是谁，决定是否被记录并绑定当前修订？
重试、冷却、超时和恢复是否只改变技术状态，而不擅自决定业务结论？
有没有测试证明分类器、超时和附件缺口不会偷偷升级成业务裁决？

轨道机的价值不在于"什么都替 Agent 决定"，而在于让每个 Agent 能在正确边界内更自主地工作，同时让团队拥有稳定的事实、节奏和恢复能力。轨道越可靠，Agent 的自主空间与业务决定的归属反而都应该越清楚。

资料与证据边界

本系列如何区分公开规范、私有代码摘录、第一方运行记录与独立资料，见《如何阅读数字员工工场的工程证据》。以下来源仍只支持本篇明确写出的主张。

NIST AI RMF 1.0：支持治理、责任角色与人工监督贯穿 AI 生命周期的通用背景；不定义本文的轨道机，也不认证 CodeFlowMu。
OWASP AI Agent Security Cheat Sheet：支持对 Agent 工具调用需要最小权限、明确授权与隔离防线的通用安全要求；不证明本文所有工具策略已经完备。
W3C PROV-O：为事实、活动和责任主体分离提供独立的来源建模参照；不规定本文的业务裁决或恢复策略。
V1.9.7 的数字、接口摘录和受控重启观察均为第一方候选证据，只支持文中指明的受测路径。它们不是渗透测试、第三方复现或跨平台结论。访问日期：2026-08-23。

系列导航

语言版本：中文原文 · English version

研究主页：JoinWell52 Research Center

你在自己的 Agent 系统中，是把"执行成功""证据充分"和"有权验收"分开保存，还是仍压在一个完成字段里？