多Agent团队治理：避免中央管控走向两个极端

智能体团队的核心并非等待中央控制器来决策每一个下一步动作，而是持续推进成员能在明确的任务、角色和权限边界内完成的工作。轨道（rail）应该是一层服务：它告知团队哪些任务可以认领、事实存储在哪里、依赖何时释放、以及中断的执行如何恢复。它不能取代智能体的专业判断，也不能取代 PM 或 ADMIN 的业务决策。

多智能体系统会以两种截然相反的方式失败。

没有轨道服务时，任务通过聊天传递，两个智能体开始做同一项工作，报告失去与上游的绑定，流程崩溃后无人能区分重试与停止。每个智能体看起来都是自由的，但团队无法可靠地协调。

有了过于强大的轨道服务，一个分类器判定计划「不完整」并阻止 PM 派发。临时缺失的产物变成终结性失败。固定的重试限制将技术退避静默地转化为业务决策。服务层取代了负有责任的人员，也剥夺了智能体合法的行动空间。

一个健全的工程轨道必须避免两个极端：在授权任务内让智能体自主行动；将事实、派发、审计和技术恢复自动化为服务；将硬性拒绝留给封闭的、可审查的机械条件集合。范围、验收、返工和最终结论仍由负有责任的智能体、PM 或 ADMIN 保留。CodeFlowMu V1.9.7 候选版本是一个有用的边界案例，因为责任边界正是其当前变更的核心。

系列顺序（3/3）。第 1 部分定义了 TMPA–FCoP–CodeFlowMu 边界。第 2 部分测试了任务标识、生命周期、依赖和认领并发。本篇文章通过定义轨道的决策边界以及必须约束其实现的治理契约来收尾这个系列。

轨道服务于自主协作；它既不是状态机也不是 PM

文件状态机回答的是任务当前处于什么位置以及它如何流转。轨道回答的是哪个角色接收工作、哪个会话在运行、能力是否可用、依赖何时释放、以及技术执行如何恢复。

轨道也不是项目管理者或凌驾于智能体之上的管理者。PM 解读需求、选择执行路线、评估证据、决定是否接受或返工。执行中的智能体同样必须在授权的任务和工具边界内做计划、实现并提交证据。这些判断包含业务或专业含义。不能安全地仅从文件存在性、已过分钟数、重试次数或分类器分数中推导出来。

自主不是无约束行为。它是在可见的任务契约、角色能力、当前版本和证据要求下的独立进展。轨道使这些约束和协调事实成为可靠的服务，这样智能体就不必猜测工作是否已被认领、依赖是否已满足、旧的会话是否仍然有效。它不得将这个服务角色膨胀为决定团队目标或结论。

NIST 的 AI RMF 1.0 在整个 AI 生命周期中放置了治理、定义的角色和人类监督。它没有定义工程轨道，但它提供了一个独立的参考点：自动化必须在明确的责任结构内运作。

将自主智能体行动与轨道服务分离

危险的转变是从建议性的到机械性的拒绝。「附件缺失」是一个事实缺口。只有当正式的任務契约或授权决策将其定为前置条件时，它才成为特定操作的前置条件。否则，运行时（Runtime）应该将缺口报告给 PM，而不是关闭工作。

V1.9.7 如何编码这个边界

CodeFlowMu V1.9.7 轨道辅助契约暴露了四种处置方式：

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

neutral：事实可用，但轨道不发布允许/拒绝裁决；

unknown_reconcile：来源缺失或冲突，需要协调；

waiting_dependency：正式 TASK 中存在显式依赖正在等待，因此当前操作等待而非被拒绝；

negative_list_denied：冻结的机械条件拒绝当前操作。

结果中还命名了 decision_owner 为 AGENT、PM 或 ADMIN。治理快照确定：

business_decision: null

这些细节共同创造了一个可测试的边界。轨道可以提供事实和命令界面，而不必在快照中夹带业务裁决。

三种非业务处置方式并非可互换的。unknown_reconcile 意味着来源缺失或冲突，需要协调；waiting_dependency 意味着正式 TASK 依赖正在等待，因此当前操作等待；只有 negative_list_denied 才意味着冻结的机械条件需要拒绝当前操作。经审查的 V1.9.7 契约分离了这些结果。因此，将 unknown_reconcile 称为现有的自动冻结、PM 通知或回滚机制，或将待处理依赖称为拒绝或任务失败，是不准确的。如果高风险下游操作必须在冲突时停止，其依据必须是正式的 TASK 前置条件、冻结的机械规则或明确的 PM/ADMIN 决策；系统不得使用启发式方法来选择冲突分支。

unknown_reconcile 还需要整个系列中有一份统一的操作契约。来源冲突、生命周期两个阶段中发现的 TASK 以及不完整的复合标识是不同的触发器，但触发同一种处置——而不是独立的恢复系统。无人值守的实现需要 reconcile_owner、触发原因、规范的任务标识和版本、opened_at、截止日期、升级路线以及允许的终结性结果。它不得在等待时无限轮询模型。经审查的证据尚未证明 SLA、通知、断路器或终结性转换的实现。

摘录来自私有 CodeFlowMu 父级实现，固定在提交 2c901972，而非来自 CodeFlowMu Open。展示这个窄化的接口契约是为了让读者能够检查架构边界——轨道可以返回什么和不可以返回什么。它既不开放完整实现，也不构成公众可以复现的产品证据。

为什么机械性拒绝必须是封闭的和可审查的

当前的 V1.9.7 契约将机械性拒绝限制为一组封闭的、可审查的条件：

禁止当前操作的明确 ADMIN 或权威决策；

授权范围不匹配；

契约定义的规范任务标识字段不一致；

终结性任务状态；

完整性或安全错误。

这些条件共享一个属性：它们可以从确定性事实中审查，而无需让 Runtime 决定计划是否智能或结果是否足够好。第 3 项不能隐藏在「真正冲突」这一模糊短语后面：具体契约必须命名被比较的字段、它们的规范化方式以及不匹配的结果。例如，绑定的 task、root-task、thread 和 revision 字段可以成为该比较的一部分。缺失字段、未定义的比较规则或矛盾的事实应归入 unknown_reconcile，而不是伪装的机械性拒绝。经审查的材料披露了这些命令绑定，但没有完整的复合标识谓词，因此本文不将某个穷尽验证的算法作为结论呈现。

来源冲突通常首先进入 unknown_reconcile；它不会自动插入否定列表。只有当它满足已写入契约的确定性谓词时——例如已定义标识字段的不匹配、范围不匹配或明确禁止当前操作的决策——轨道才能将当前操作转为 negative_list_denied。否则它保留冲突并要求授权参与者来协调它。

显式依赖是一个不同的可审查机械条件：它返回 waiting_dependency，将当前操作保持在队列中直到上游契约满足。它不在冻结的否定列表中，也不是对任务或业务结论的拒绝。

因此，「封闭」必须意味着不仅仅是 一个简短的枚举。每一个机械谓词——包括复合标识、依赖授权和认领争用——必须在一个版本化的策略包内可检查。否则，列表只是名义上封闭，而模糊的谓词或紧急代码补丁可以不断改变谁可以行动。

随着列表的增长，业务偏好往往会伪装成基础设施事实。"计划少于三个步骤"、"未先提交 ISSUE"、"运行超过十分钟"这些可能是有用的警告，但没有哪一条能普遍地意味着任务应该停止。PM 或 ADMIN 可以在任务创建、修订或正式审批期间将条件写入任务；但他们不得在运行时将新的偏好转变为机械性的阻止，从而在服务层中制造一个后门。护栏只检查已冻结在契约或明确决策中的条件。

治理如何不因补丁而被重写地进入护栏

TMPA 约束应通过版本化的治理策略包传递到 CodeFlowMu，而不是分散在 TypeScript 分支或无限制的热重载中。至少，该包需要识别其策略 ID、版本和摘要、支持的 Runtime 范围、角色和作用域断言、身份规范化、依赖变更授权、机械性拒绝断言、迁移要求和回滚条件，以及审批参与者。每种处置都应记录实际使用的策略版本，且该版本在一次任务轮次中保持稳定，除非授权的迁移创建了新的修订版本。

这对于紧急并发修复最为重要。独占预留、锁文件或 compare-and-swap 可以防止两个物理赢家，但也会影响执行授权。工程层面可能fail closed——禁用竞争索赔者或将部署收缩回一个 Runtime——而不改变谁有资格。它不得静默地添加新的赢家选择或拒绝规则，然后在事后解释治理。任何授权变更必须首先进入策略包、获得可问责的审批，并获得命名测试和持久化证据。

同样的规则也适用于依赖项。正在运行的 AI 智能体可以提议变更边缘，但只有 PM、ADMIN 或明确授权的参与者才能变更图。被接受的变更会创建新的任务修订，并在执行继续前重新运行身份、作用域和循环检查。

护栏应该自动化什么

绑定身份和作用域

任务命令应绑定任务、根、线程、轮次和修订版。针对过时修订版、为其他任务挂载的能力或共享一个幂等键的不同业务意图的命令应在生效前被拒绝。

强制执行角色/工具能力

开发、QA、运维和评审角色不应共享一个可变工具面。V1.9.7 检查规范化的工具身份和活动能力。在被检查的 PM 任务变更路径上，请求进入共享的 TaskCommandKernel，因此身份、作用域和重复防止检查在该路径上执行。该证据并未穷尽每个遗留或替代端点。证明不存在绕过也需要端点清单、静态扫描和绕过路径的拒绝测试。

这是工具准入，而非完整的效力分析。路径逃逸、命令参数和操作系统权限仍需要更低层次的策略和沙箱控制。

工具准入不应仅依赖静态角色。工程设计应对生命周期阶段、当前修订版和操作目标应用单独的操作策略：一旦任务处于评审或终态，执行者请求继续写代码时应重新检查是否存在仍然明确有效的返工或执行入口点。被检查的 V1.9.7 证据证明了规范化工具 ID、活动能力、任务作用域和修订版检查；它并不能证明每个工具在活动、评审和完成态都有统一的动态收缩。这是一个需要添加的策略和测试，而非本文声称已完整的特性。

队列化和显式释放依赖

当 QA 任务明确依赖 DEV 子任务时，护栏可以让 QA 一直等待，直到上游契约被满足。挂起来自可审查的 TASK 边缘，而非分类器对文本的解释。

考虑这种对比。如果 QA 仅因为看到旧轮次的 DEV 报告就开始，它可以拿上一个输出作为当前任务的输入。健全的契约会将 QA 任务绑定到特定的上游任务及其当前修订版；在该依赖被满足之前，它返回 waiting_dependency 而非启动 QA。只有当完成证据匹配绑定版本时，护栏才会释放该边缘。这是一个可审查依赖的设计示例，而非声称 V1.9.7 为每种报告-修订版匹配组合都有测试。

为长任务保留技术事实

必须超越会话存活、承受 Runtime 重启、暴露连续日志或支持精确取消的工作可以使用可选的托管命令服务。V1.9.7 还声明短期测试和构建可以使用原生主机命令工具。缺少托管命令工具不得被视为 AI 智能体无法工作或提交 REPORT 的证明。

唤醒和恢复而不宣告业务结果

护栏可以唤醒符合条件的 AI 智能体、恢复可恢复的会话、重试确定性的技术步骤，并在重复失败后添加冷却期或审计。计数和时间窗口对节流和操作员注意力有用。它们不应静默地成为永久性的业务阻碍。

良好的恢复结果应说明观察到什么、什么被机械修复了什么、什么仍然未知，以及谁应该下一步决策。它不代表 PM 宣告项目失败。

超时也必须被视为技术事实，而非业务裁决。V1.9.7 的可选托管命令服务可以保留长任务状态、连续日志、有界等待和精确授权的取消。这支持记录会话或工具调用超过了其预期窗口；但并不能证明每个会话已经有了心跳、自动诊断或 PM 通知。合理的后续策略应在会话或任务证据中记录超时，将重试、接管或终止选择暴露给决策所有者，并避免静默地将技术超时升级为任务失败。

三秒边界测试

假设 QA REPORT 到达时没有任务中指定的原始兼容性日志。

过度延伸的实现会这样做：

Runtime 看到缺失的附件
→ 标记根任务失败
→ 永久阻止 PM 整合

有边界的实现区分两种情况：

如果正式 TASK 在创建、修订或正式审批时已写入"此日志是验收的必要条件"作为冻结的确定性前置条件：
→ 记录证据缺口并拒绝此次验收尝试
→ PM 决定是重新测试、返工还是变更契约

如果日志仅是分类器建议：
→ 暴露缺口和建议
→ PM 根据风险和可用证据做决定

第一个分支是契约设计示例，而非声称 V1.9.7 自动将每个缺失附件转为拒绝。如果当前接口没有预冻结的断言，正确行为仍然是记录证据缺口并交给 PM 决定。

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，报告了 health=ok，并保留了在线网关、当前进程对单写锁的所有权，以及一致的项目根绑定。

这些数字是不同级别测试套件的总数。它们不能相加，也不能被解读为对所有四种护栏协助处置的同等覆盖。现有数据包不记录 neutral、unknown_reconcile、waiting_dependency 和 negative_list_denied 的直接案例数；因此本文不使用 115、1706 或 936 来声称对这些边界的完整验证。下一个证据包应为每个状态列出命名案例、预期处置和观察结果。

下一组数据包应该是一个可追溯的矩阵，而不是另一个汇总总数：治理声明 → 策略谓词及版本 → CodeFlowMu 入口点 → 命名正面测试和负面测试 → 持久化的结果和提交。它应该独立覆盖未授权的依赖变更、过期的策略或任务修订、具有恰好一个可执行凭证且零失败方副作用的同 TASK 并发声明、四种处置结果中的每一种、对账超时和升级，以及授权恢复。只有这个矩阵才能证明治理语义和工程行为是一致的。

本文不使用 CodeFlowMu 开源代码或开放版测试计数作为产品证据。

这些数字仅支持在记录的 Windows 工作站、候选代码和固定测试集上测试的路径。父源检查、代码回归和重启加载是数据包中的独立证据节点。它们不是渗透测试、独立复现、形式化验证或跨平台可靠性声明。该数据包还保留了早期变更检查中发现的失败，而不是用最终发布检查覆盖它们。

版本状态需要同样的谨慎。版本文件和运行中进程报告 V1.9.7，而发布说明仍称其为候选版本，并将最终 RELEASED 权限保留给 ADMIN。轨道不应代表 ADMIN 发布，文章也不应改写这一边界。

首先，冷冻负面列表是一份工程契约，而不是完整的威胁模型。提示注入、参数逃逸、供应链风险和外部效应仍需要更深层的安全控制。

其次，一个规范的事实内核不能证明每个遗留端点都在使用它。回归测试和静态扫描降低了旧裁决路径返回的风险；它们无法阻止未来引入的并行分类器。

第三，技术恢复不验证业务结果。恢复进程、恢复日志或重新传递 REPORT 不能替代高影响操作的内容审查或 ADMIN 判断。

第四，证据是第一方的。更强的结论需要独立复现、更多崩溃点、多个主机和文件系统环境，以及对长期运行团队的实际观察。

对于每条自动化规则，回答：

什么来源产生这个事实？

当证据缺失时，系统是说"未知"还是猜测？

输出是建议，还是停止操作？

如果停止，原因是基于简短的冷冻机械列表吗？

它是只停止当前操作，还是关闭业务任务？

谁拥有最终决策权，该决策是否绑定到当前修订版？

重试、冷却、超时和恢复是否只改变技术状态，而不是静默决定业务结果？

是否有测试证明分类器评分、已用时间和产物差距不能静默变成业务裁决？

轨道的价值不在于它为 AI 智能体决定一切。它让每个 AI 智能体在正确的边界内更自主地工作，同时为团队提供稳定的事实、受控的动作和可恢复的执行。轨道越可靠，AI 智能体自主性和业务判断的所有权就应该越清晰。

来源和证据边界

关于本系列如何区分公开规范、私有代码摘录、第一方执行记录和独立资料，请参阅 How to Read Engineering Evidence at the Digital Employee Works。下面的来源仍仅支持本文中声明的特定声明。

NIST AI RMF 1.0 支持治理、问责角色和 AI 生命周期中的人类监督的一般背景。它既不定义工程轨道，也不认证 CodeFlowMu。

OWASP AI Agent Security Cheat Sheet 支持在 AI 智能体工具调用周围进行明确授权、最小特权和隔离的一般安全需求。它不能证明这里的每个工具策略都是完整的。

W3C PROV-O 是分离事实、活动和负责主体的独立来源建模参考。它不规定本文的业务决策或恢复策略。

V1.9.7 图表、接口摘录和受控重启观察是第一方候选证据，仅限于此处命名的测试路径。它们不是渗透测试、第三方复现或跨平台结论。访问时间：2026-08-23。

第一部分：治理、文件状态和工程轨道

第二部分：声明、执行、审查和完成任务

第三部分：无未授权管理者的自动化

语言版本：英文原文 · 中文版

研究主页：JoinWell52 Research Center

进一步操作，您可以考虑屏蔽此人或举报滥用