多 Agent 结果合并：Provenance、冲突仲裁与原子提交

让三个 Agent 分别研究安全、成本和性能，最后再让一个“总编”写结论，看似已经完成合并。真正的风险是总编只拿到三段文本：它不知道哪条结论来自哪个输入版本、哪些证据被两个候选重复引用，也不知道“应立即升级”和“应保持旧版”其实针对不同环境。多数票同样不可靠，三个同源副本不等于三份独立证据。

RAG 引用溯源 连接回答 claim 与文档 chunk，Agent 记忆压缩血缘 处理长期摘要的可逆整合。本篇关注一次多 Agent run 内，多个可执行候选怎样进入同一 canonical result，并保证仲裁决定本身可审计。

result-envelope.v1 不接受裸文本

每个候选必须包含 candidateId、runId、生产节点与 attempt、输入 artifact digest、sourceEpoch、authorizationEpoch、输出 schema、实现/模型/Prompt/策略版本、结构化 claim、evidence、假设、范围和置信依据。正文可以作为 artifact，但不能成为唯一接口。

{
  "schemaVersion": "result-envelope.v1",
  "candidateId": "cand_security_7",
  "producer": {"node": "security", "attempt": "a3", "fence": 12},
  "inputs": [{"artifactId": "repo_9", "digest": "sha256:..."}],
  "claims": [{"claimId": "c17", "predicate": "deployable", "value": false,
    "scope": {"env": "prod"}, "evidence": ["ev_31"]}]
}

摘要哈希使用固定字符编码、字段排序和数字表达；RFC 8785 的 JSON Canonicalization Scheme 可作为 JSON 签名输入的基础。哈希之前要拒绝重复键、非有限数和未知 schema，不能各语言随意 stringify。W3C PROV 的 Entity、Activity、Agent 关系适合描述 artifact、转换和执行者，但业务仍需冻结自己的有限字段和版本。

CandidateSet 保存预期 producer、各 producer 终态、OPEN/SEALED、set version 与 seal generation。登记事务只接受 OPEN 集合中的有效 attempt 和预期 producer，并递增 set version；迟到结果只进隔离区。全部必需 producer 终态且可选项按版本化 deadline 策略关闭后，以 CAS 将 OPEN -> SEALED，冻结有序 candidate root、provenance root、source/auth epoch 与 seal generation。之后候选只能进入下一代，不能修改已封口集合。多 Agent 任务 Claim 提供 attempt fence；共享记忆仍走 多 Agent 共享记忆并发控制。

先分类冲突，再选择规则

规范化服务按 claim 的 subject、predicate、scope 与有效区间分组，生成 SUPPORTS、COMPLEMENTS、CONTRADICTS、SUPERSEDES 或 INCOMPARABLE 边。范围不同的结论通常是互补，不应强迫二选一；同一证据派生的候选要标记共同祖先，避免重复计票；缺失必要证据的是不完整，不是“少数意见”。语义分类器可以提出边，但高风险 predicate 的最终类型需规则或人工确认。

仲裁策略按 claim 类型版本化。可测数值要求单位和观测窗一致后采用预定义聚合；规范事实优先有效、可访问的一手来源；代码修改必须通过独立测试门；风险判断保留反对意见与适用条件。安全或合规冲突默认 UNRESOLVED，不能用模型置信分平均。与 RAG 证据冲突处理 不同，这里的候选还可能包含补丁、计划和工具产物，因此仲裁要检查副作用前置条件和产物兼容性。

ArbitrationDecision.v1 保存候选集合摘要、冲突图摘要、规则版本、选用/拒绝 claim、理由码、人工 actor、审批与到期时间。模型生成的自然语言说明只是附属展示，决定必须可由有限枚举和引用复核。

Canonical result 用 CAS 发布

合并器只读取 SEALED 集合。发布事务锁定 run 与有效性时钟，重查 DAG revision、seal generation、candidate/provenance root、当前 source/auth epoch 和 result version，并逐项确认 evidence 仍可访问；全部匹配才写 canonicalResultVersion+1、仲裁记录与 outbox。封口后不存在同代迟到候选；撤权与修订先推进相应 epoch，因此与提交竞争时只有一方成功。下游只消费 canonical commit。

来源撤销、输入修订或检测到错误时，先推进 epoch，使旧结果不可继续传播；再沿 provenance 找到受影响 claim，创建更高版本 REVOKED，并从当前有效输入封口新集合前向重算。用户界面展示未解决冲突和范围。Agent 人工审批门 可用于不可逆结论，但审批摘要必须绑定 sealed root、epoch 与 policy digest。

并发与恶意测试

测试让登记候选与 OPEN -> SEALED 竞争，断言候选要么进入 root，要么被拒绝；两个合并器只能一个提交。再让撤权推进 epoch 与发布竞争，并覆盖重复 evidence、单位/环境冲突、伪造 producer、篡改 artifact、旧 attempt 和仲裁超时。属性测试验证候选顺序不改结果，重复候选不增权重，canonical claim 均可追到当前可访问输入。

指标包括有血缘 claim 覆盖率、未解决冲突率、共同祖先去重率、仲裁 CAS 冲突、候选到发布延迟、人工复核量、撤销传播时长和无法复算结果数。关键门槛是高风险 claim 证据覆盖 100%、无来源 canonical claim 为零、相同候选集合重放摘要一致。

上线先 shadow 构建 provenance 和冲突图，再让新格式只服务新 run。异常时冻结晋级；上一版只有在 provenance、source/auth epoch 和策略仍有效时，才能作为新 canonical version 的输入被重新发布，否则发布 REVOKED/UNAVAILABLE，并从当前有效输入前向重建。回滚不能删除 provenance 或把未决冲突改成成功；恢复前重放 sealed root 与规则，确认摘要一致，再逐步重开仲裁。