多 AI 协同工作流 v2.5→v2.9 演化：执行方证据可信度分级（智能体操盘 PBC 仓库实战）
让 AI 智能体无人值守完成"修 GitHub 网络 → 拉私有仓库 → 内容审计 → 构建"全链路。执行方给出的 3 个中间结论在核对原始证据后全部被推翻——连通性探测全 200（假阳性）、pull 报成功但未合并、凭据存入但 token 失效。沉淀为执行方证据必须分层交付的校准规则。
- 多AI协同
- 验收
- 证据可信度
- v2.5→v2.9
- 智能体
背景
本轮把 PBC 仓库的 GitHub 连通性修复、私有仓库拉取、内容完整性审计和静态站构建整体交给一个 AI 智能体无人值守执行。执行过程中，执行方有 3 个”看起来成立”的中间结论，在回看原始证据时全部被推翻。
三个被推翻的中间结论
| 执行方中间结论 | 原始证据核验 | 真相 |
|---|---|---|
| 四个 GitHub IP 全部返回 200，全部可用 | curl 的 %{remote_ip} 是 127.0.0.1，不是目标 IP | 执行环境 shell 预置了 http_proxy，--resolve 被忽略，测的是代理不是各 IP |
| git pull 已经把远端拉下来了 | 本地 HEAD 仍是 0ff85ff，origin/main 已到 5a6b0a7 但未合并 | fetch 成功但本地分支无 upstream，pull 的 merge 阶段被跳过 |
| PAT 已存入凭据管理器，认证应当通过 | 直接打 GitHub API 返回 401 Bad credentials | 凭据确实存进去了，但 token 本身已失效，存入≠有效 |
沉淀的 3 条校准
- 证据必须分层交付——网络层（remote_ip）、进程层（exit code）、文件层（实际路径+字节数）。执行方报结论时缺任何一层，验收方有权拒收
- “动作成功”≠“结果达成”——fetch 成功、凭据写入成功都属于动作层，必须另验结果层（文件是否真的变了、认证是否真的通过）
- 外部系统的结论用外部系统的原始接口复核——token 是否有效直接打 API 看状态码，不在 git 命令层反复盲试
与既有规则的关系
- 是 v2 “只信凭证”的细化：凭证从”有/无”升级为”分层”
- 再次印证核心原则——执行方的话只是线索，原始证据才是事实。本轮三个反例全部是执行方自查时发现，说明”自查原始输出”这道工序不能省
验证
- 三条均在本轮实操中实际发生并定位到根因，非推演
- 修正后链路跑通：网络修复 → 私有仓库拉取（47 文件 fast-forward）→ 审计 → 构建，全程 exit 0