aps-agent/poc/pi-fallback/GOAL-P3.md

14 KiB
Raw Permalink Blame History

GOAL:Pi Agent 兜底能力 · P3 高风险场景与运维(多 agent 协同 · 第四轮)

本文件是本轮协同的唯一权威协调板。每位 agent 开工前必读;完成后在文末留言板交接。 已提交基线:3543208(P1)+ 967ae37(P2)+ poc 设施两轮。P2 S3 冒烟 16/16、注入攻击 21/21。

本轮目标(P3 出口标准)

按根目录《Pi-Agent兜底能力详细方案》§6 P3:S4(缺算法/策略的沙盒试排)/S6(外部集成故障补录与对账)/S7(现场运维诊断)三个高风险场景 + agent.fallback.execute.highrisk=P3 的白名单治理机制。

具体交付:

  1. P3 白名单机制:agent.fallback.execute.highrisk 从"默认拒绝"升级为"白名单放行"——配置化的场景级白名单(文件化,类似 features.json 语义;文件缺失/损坏 → 默认全拒 fail-closed,与 fallback 开关的默认关语义对齐),每项放行本身登记为 P2 管理动作(改白名单要确认卡);
  2. S4 缺算法沙盒试排:Pi 在沙盒内生成/执行临时分析或试排脚本,产物为草稿版本(P1 语义,不写主干);与既有 flex.schedule / scenario.compare 沙盒语义对齐;收益与风险边界在文档写明;
  3. S6 集成故障补录:MES/WMS 接口故障时,Pi 辅助生成待补录清单/对账文件;补录写操作逐笔过确认卡(P2 既有机制);外部系统恢复后的对账流程(读侧对账 P0 + 差异报告);
  4. S7 运维诊断入口:运维角色专属入口(与 auth 角色体系对齐;非运维角色物理不可见/不可用);Pi 可读日志/配置诊断(只读 P1),改配置类动作走 highrisk 白名单 + 确认卡;全程审计可回放;
  5. 角色门禁:fallback 触发增加角色维度(设计员评估现状 auth/角色能力的复用面;普通用户/运维/管理员对 S4/S6/S7 的可见性矩阵);
  6. 黄金测试:白名单 fail-closed(缺失/损坏/越权场景)、S4 草稿不碰主干断言、S6 补录确认卡链路、S7 角色越权拒绝、P3 动作未入白名单默认拒绝——全部确定性;
  7. 真实冒烟:S6 场景(模拟 MES 断连 → Pi 生成补录清单 → 确认卡 → 补录 → 恢复后对账报告);S7 诊断场景只读部分;
  8. 文档同轮:fallback.md P3 章节、harness.md 权力矩阵、CHANGELOG(FB-03 条目)。

硬约束(GOAL-P2 全部继承,追加)

  • 不 git commit/push;改动最小化;Python 用 .venv\Scripts\python.exe;
  • P3 白名单语义必须 fail-closed:任何配置问题 → 拒绝而非放行(与 features 的 fail-open 相反,与 fallback 默认关同理,要在设计里写清楚语义不混淆);
  • S4 产物只允许草稿语义:验证器要断言沙盒试排不产生主干写事件;
  • S7 运维入口:角色判定复用 server/auth 既有身份体系,不新造权限模型;
  • 黄金测试确定性(fake runner);真实冒烟用临时 APS_HOME;
  • 每轮结束统一等提交授权。

角色分工

角色 任务 输出
Agent-L 设计员 P3 文件级详细设计(白名单 schema/角色矩阵/三场景接线/测试矩阵/爆炸半径) poc/pi-fallback/P3-DESIGN.md
Agent-M 实施员 按设计施工产品代码 + 黄金测试 代码 + P3-IMPL-NOTES.md
Agent-N 验证员 全量回归 + S6/S7 真实冒烟 + 白名单攻击复证 P3-VALIDATION.md

已知前置问题(设计中必须回答)

  1. 角色体系现状:server/auth 现有角色粒度是否足以表达"运维"?若无,最小扩展方案是什么(不新造权限模型);
  2. S4 与既有沙盒的关系:flex.simulate_due / scenario.compare 已是沙盒试排,Pi 兜底 S4 的增量价值边界在哪(避免重复造轮子——兜底应编排既有沙盒意图,而非自建试排引擎);
  3. S6 对账的"恢复后"语义:外部系统恢复是事件还是人工触发?对账报告的证据链怎么冻结;
  4. 白名单粒度:场景级(S4/S6/S7 整体开关)还是意图级(每个 highrisk 动作单独登记)?给出取舍。

协同留言板

(格式:[角色] 时间 — 结论/交接物/给下一位的话)

[Agent-L 设计员] 2026-09-03 — P3 文件级详细设计完成,交接物:poc/pi-fallback/P3-DESIGN.md(11 节 + 附录,§0 现状事实 15 条全部源码核实、§8 测试矩阵 21 例、§9 双冒烟脚本规格、§10 爆炸半径 rg 实测无 HIGH)。

4 个前置问题的答案(详见设计 §4.1/§5.1/§6.5/§2.3):

  1. 角色体系:server/auth 现有粒度足够——roles 是自由字符串元组(JMS 透传),审批角色有 action/power/全局三层 env 解析(APS_APPROVAL_ROLE_POLICIES 既有机制);「运维」= 角色字符串 ops,最小扩展 = 纯配置零代码,server/auth 一行不改;「非运维物理不可见」落在 propose 闸 1.5(身份不符 → return None,与原话术同形态)。
  2. S4 与既有沙盒:兜底不建试排引擎——S4 = Pi 编排既有沙盒意图(flex.simulate_due/flex.compare/scenario.compare/scenario.sensitivity,全 P0/P1 深拷贝沙盒),增量价值 = 意图自动组合 + 参数探索(临时脚本只作产物不执行,围墙无代码执行面)+ 草稿叙事;验证器用 world_fingerprint 前后相等(auditEvents 等 append-only 键已被指纹排除)+ 零 WORLD_WRITE 审计断言「草稿不碰主干」。
  3. S6 恢复语义:人工触发,不是事件——用户明示后编排器 probe readiness,connected 才进对账协议(不轮询、不后台监听,现状无告警子系统也不造);证据链三层冻结 = 外部响应原文落盘 sha256 → manifest 汇总指纹 → 指纹进 ALGO_RUN 审计 rationale,对账纯读 P0,差异处置回到逐笔卡。
  4. 白名单粒度:意图级为骨架 + 场景级为聚合开关 + 角色级第三维,三层同文件——纯场景级会把 S7 里不同权力动作一勺烩,纯意图级丢失场景归属会让意图被全局放行悄悄扩面。

关键设计决策(M 轮照此施工):① 白名单 fail-closed 到「未知键即全文件判损坏」的强度(与 features.json 的 unknown 忽略相反,两文件两加载器语义隔离,互不 import);② 白名单出卡/执行双端 sha256 比对,审批窗口内白名单变更 → 执行拒绝;③ P3 三场景只开放 frozen 步 + params 内联(吸收 K 轮教训:ASSISTED 真实模型未端到端验证、artifactRef 对真实 Pi 物理不可用);④ S6 逐笔出卡 = 每项 backlog 一张独立 P2 卡(卡间无事务关联,符合补录语义),单轮上限白名单 maxItemsPerRun;⑤ 改白名单 = agent.fallback.policy.update P2 管理动作(Pi 只产 diff 声明,完整文档由编排器再生成),改配置 = agent.fallback.ops.config.apply P3(继承既有 requiredApprovals=2 + SOD + executionGrant 双人链,一行新机制不造);⑥ S7 只读诊断不登记任何新工具——日志/配置脱敏后经 inbox 注入,Pi 仍只有 fs_read。

风险最高点:§10.1/10.2 双 MED——fallback_lane 计划锁闸口改造(validate_plan/check_step_request 硬拒改白名单裁决)与 execute_confirmed 两个写文件新分支(热路径);均已给降级方案(frozen 直执 + checkpoint 前置保证最坏退化为一次显式失败且已回滚的确认;原子写 tmp+replace 无中间态),且 H-8 专项守护「白名单缺失时 P2 存量路径零影响」。

给 Agent-M 的话:照 §1 变更清单 12 项施工,§2.1 裁决表与 §8 测试矩阵是硬契约;三处易踩坑已在设计写明——新出卡路径必须照做指纹对齐(refresh_confirmation_world_fingerprint)与 contextPolicies setdefault(§0.14①②);S6 多卡循环 stage 时每张卡都要独立走这套;脱敏函数失败归并不阻断(export_snapshot:791 先例)。施工前先复跑 P2 三目标文件 41 例确认基线绿。未 git commit,等统一授权。

[Agent-M 实施员] 2026-09-04 — P3 产品代码 + 黄金测试施工完成,交接物:poc/pi-fallback/P3-IMPL-NOTES.md(改动清单 11 文件、自验数字、9 条偏差如实登记、遗留清单)。

自验数字:新建 test_fallback_highrisk.py 21 例(H-1..H-21,§8 矩阵全覆写)21 passed;四文件联合(highrisk+execute+lane+feature_flags)65 passed(P2 存量 44 例零回归);爆炸半径 19 文件 195 passed;ruff 与 HEAD 基线多重集比对 59=59 零新增(施工中的 9 条新增违规已全部修净复核)。文档三处同步(harness.md 矩阵+2 行+变更记录 / fallback.md P3 章节 / CHANGELOG FB-03 条目)。

两条设计外增量(已在 IMPL-NOTES/CHANGELOG 登记,请 N 重点复证):⑦ harness refresh_confirmation_world_fingerprint 原实现推进指纹不重算信封哈希——S6 第二张及以后确认卡必现「完整性校验失败」,已修(P2 单卡未暴露是因为无身份绑定时指纹为空 refresh 空转);⑧ S6 兄弟卡世界指纹重锚——首笔落账后同 run 其余待批卡冻结指纹推进+信封重算,否则漂移检测误杀,§6.3「逐笔互不影响」语义的落地必需。

遗留(诚实标注):① S6/S7 两个冒烟脚本本轮未写,§9.1/§9.2 验收点 + smoke_s3_execute.py 手法可直接照做,CHANGELOG 数字已留「待 Agent-N 补实测」;② 分批全量黄金未复跑(只到爆炸半径切片 195 例);③ MockMesClient 无 fetch_work_order/readiness,stub 下对账按 MISSING 如实呈现,真实 MES 链路待冒烟。

给 Agent-N 的话:除设计 §8 矩阵外,建议专项复证偏差⑦⑧的攻击面——伪造/篡改同 run 待批卡后重锚是否仍 fail-closed、非同 run 的世界改动在第二笔审批时是否仍被漂移检测拦下(H-8/H-20 已覆盖基础形态)。未 git commit,等统一授权。

[Agent-N 验证员] 2026-09-04 — 终验完成,交接物:poc/pi-fallback/P3-VALIDATION.md(全量回归/专项复证/双冒烟逐步证据/出口标准 8 项逐条/未验证清单)+ tests/golden/test_fallback_p3_attack.py(7 例攻击专项)+ smoke/smoke_s6_reconcile.py / smoke/smoke_s7_ops.py(五/四阶段可复跑)+ regression_driver.py 与两份回归结果 JSONL。判定:P3 条件 NO-GO。

核心数字:全量 golden 191 文件 1501 passed / 18 failed / 10 errors(stash 基线 9 文件逐例一致,全为既有失败:native sidecar 环境依赖 11 例 + folder_schedule 系列 6 例 + MES/HTTP fixture 8+2+4+2——与 P3 零相关);文档门禁 25 passed;ruff M 的 8 文件 59=59 零新增复算一致;四文件联合 65 passed、含攻击专项五文件 72 passed。

偏差⑦⑧专项 7/7 全过:第二张卡信封完整+乱序双批、旧卡伪造/参数篡改/重放三态全拒、跨 run 卡不被重锚(漂移检测拦)、非兄弟改动借重锚混检被拦、伪造兄弟(篡改 runId 落盘)蹭重锚被 paramsHash 层物理拒。附带发现:审批仓 transaction 每次从盘刷新,纯内存篡改会被自动中和(信任方向正确)。

S6 冒烟 19/24——抓到一个真实链路才摸得到的产品缺陷(FB-03-BUG-1,判 NO-GO 的唯一原因):段 C 补录写在真实断连下 100% 失败回滚——mes.apply_report 本地落账前无条件 client.post_report() 同步推 MES,断连注入(设计 §0.8 官方手法)下 MesHttpError 上抛 → execute_plan 整体回滚。golden 层 MockMesClient post_report 永远成功 + probe 走 monkeypatch seam,结构性摸不到。真实失败文案实测:「兜底执行失败(MesHttpError: [MES_HTTP_TIMEOUT] POST /work-orders/EXT-1001/reports (HTTP 504)),已自动回滚……你的数据未留下任何变更」。治理面在失败前全部正常(显式失败+回滚+失败现场建档+审计齐全)。其余全绿:断连注入 CONNECT_FAILED、真实 Pi 产 S6 两步计划(woId/进度与 CSV 一致)、逐笔双卡、恢复后假 MES(冒烟内嵌 HTTP 服务)对账 MATCH 1/DRIFT 1、manifest sha256 应验、ALGO_RUN 含 manifestSha256、对账纯读指纹相等、删白名单对照组零卡零变更、probe 仍 failed 如实回复「尚未恢复」(H-17 真实复证)。

S7 冒烟 12/12 全过:ops 身份四文件注入 + 预埋双形态敏感串脱敏实测(***REDACTED***、零泄漏)+ P1 草稿 + 世界零变更 + calls.jsonl 围墙内读取;非 ops(desktop planner)对照物理不可见实测(零 run、原话术);验收点 D(双人链)由 H-20 确定性全覆盖已登记。

给修复轮的话:FB-03-BUG-1 是设计层语义决策(补录 = 本地落账 + 待同步标记恢复后闭环,还是同步推送容忍失败),非一行笔误,我按约束未动产品代码;修复后 smoke_s6_reconcile.py 五阶段全自动可复跑(outage 阶段 D3–D6/G1 转绿即解除 NO-GO)。环境层坑两个已在脚本内修复并登记:本机系统代理劫持 httpx 本地请求(NO_PROXY 修正)、Windows MAX_PATH 致 rmtree 失败(robocopy purge 兜底)。未 git commit,等统一授权。

[Agent-O 修复收口] 2026-09-04 — FB-03-BUG-1 已修复并复证,交接 docs/CHANGELOG.md 顶部条目 + tests/golden/test_fallback_offline_booking.py(6 passed)+ smoke_s6_reconcile.py 复跑结果。 语义:S6 补录步 params 显式声明 offlineBooking: true,出卡闸与执行端双端实时探测断连事实, 双成立才走 apply_report(offline_booking=True) 本地落账并打 syncStatus=PENDING_SYNC; 在线路径默认参数不变;PENDING_SYNC 自动补推仍为后续轮次。确定性联合 78 passed、文档门禁 25 passed、ruff 零新增;真实 S6 冒烟复跑 24/24,段 C D3–D6/G1 全绿。P3 判定转 GO; Agent-N 的 NO-GO 留言保留为修复前时序记录。P3/P4 代码均未提交,等统一授权。