预检与冻结

为什么需要预检

预检解决一个具体问题：规划阶段的结论不能直接当作授权。

规划由模型驱动，它检索并评估可用的流程与能力。但模型看到的是它有权看到的候选，而实际执行需要的是当前用户与当前工作范围在创建沙箱那一刻仍然有效的授权。两者可能不同——权限可能被撤销、版本可能被撤回、连接器地址可能变化。

因此预检不做「信任规划结果」，而是用同一身份重新检查一遍，并把检查结果固化下来。这既是安全边界，也是可复现性的来源。

预检的七个步骤

一、解析输入。 解析身份、工作范围、需求来源、仓库、基线分支与当前可用能力。

二、确定流程。 按用户选择冻结现有版本，或执行检索、评估、适配与生成。

三、确定性编译。 使用共享编译器规范化流程。编译器至少检查：

• 每个必需输入有且只有一个合法来源；
• 不存在循环依赖、重复节点标识或非法返工目标；
• 产物类型与格式契约兼容；
• 输入使用限定引用，不产生隐式依赖边。

四、风险评估。 评估并持久化风险分类、置信度与是否需要审批。这些数据用于解释、审计、后续策略分析与重现，本身不构成流程方案的人工阻塞条件；需要审批的节点仍必须在该节点执行前完成审批。

五、重新授权与校验。 以当前用户与工作范围对每个精确引用重新授权，校验仓库与分支、兼容性、预算与风险。预检不重新解析浮动标签、不按范围替换候选、不添加任何内置能力。

六、冻结。 冻结初始执行流程快照、执行规格与精确能力锁。快照标记它来自现有版本还是由 Agent 生成。

七、计算摘要。 对整个规格计算规范化内容摘要。这是执行期不可变性的证明。

沙箱内的重验

预检完成后规格才传递给运行器。运行器在启动后按相同编译器与相同摘要重新校验冻结计划，不重新解释自然语言，也不解析浮动引用。

两处使用同一套逻辑是有意的：如果只有预检校验，那么在规格传递过程中出现的问题不会被发现；如果只有运行期校验，那么失败会发生在资源已经创建之后。

失败关闭

预检失败时：

• 不创建运行环境；
• 不创建 Pod、服务或任务密钥；
• 任务保留结构化检查结果与修复入口；
• 不静默回退到更宽权限。

最常见的失败原因已在前面的章节列出。预检界面上会展示流程检索、生成、风险与冻结的进度，因此失败点通常可以直接定位。

执行清单

预检为每个任务生成一份无密钥、摘要固定的执行清单。这是任务唯一的执行配置，必须完整包含仓库地址与基线分支、全部需求来源定位信息、流程策略，以及每个节点的最终提示词、技能、扩展、子 Agent、主 Agent 模型与运行时配置。

执行规格只携带清单的内容引用和摘要。沙箱只读挂载后由运行器重验。

唯一配置不等于内联所有外部正文。 运行器按全部来源定位信息把需求物化到任务本地后供各节点使用；技能、钩子与运行时文件按配置物化；沙箱预注入凭据环境变量。这些载荷都不能形成第二份平行执行配置，也不要求运行器补算领域配置。

全部需求来源固定为每个任务各物化一次。运行器保留来源身份并生成统一需求索引，重试、返工和全部节点复用同一份本地结果。这是平台不变量，不在配置中暴露刷新策略。需要刷新外部需求时创建新任务或显式的新执行修订，而不是让普通节点在运行中读取浮动正文。

界面上的投影

控制面聚合任务快照时，从同一份冻结清单投影每个节点的非密钥 Agent 证据：主 Agent 模型与运行时、节点提示词、子 Agent 名称与继承关系，以及精确的技能与扩展版本。

网关地址、凭据引用、扩展认证与平台系统提示词不进入快照。界面对于系统提示词显示明确的私有执行层说明，不从会话文本、目录或测试夹具反推。