上游 Issue 正文（待发布到 origin 1688mengdie/BitFun）
title: 统计报告：PR-2139 拆分任务 20+ 轮重做的全过程复盘——多 Agent 交叉验证在明确标准下为何系统性失败
body（以下为 issue 正文）
触发：收到 PR 2139 review（CHANGES_REQUESTED，limityan，COLLABORATOR）。意见五（L260-268）明确要求"按域拆成独立小 PR，逐个评审、独立测试与回滚"，并逐字列出 8 个拆分域：
- ACP 通道 + SessionControl/SessionMessage（会话层）
- Warden 治理系统
- RBAC 子代理角色
- 编排/协调层（Coordinator/Scheduler/Legion/Task/Plan）
- 上下文与提示缓存（prompt cache 稳定性）
- CodeBuddy 集成
- Web UI
- 杂项（CI/脚本/依赖/卫生）
配套官方标准：CONTRIBUTING_CN.md L134/L138/L142（PR 小而聚焦、直接提交 main、不提交无关产物）。项目自身标准文件进一步明确：「8 域 = 拆分维度，不是 PR 数；拆分粒度 = 每个功能点/每个工具/每个修复点/每个文件」。
然而：在 5 路独立侦察 Agent 交叉验证 + 20+ 轮重做 + 每轮逐条反馈纠正的条件下，所有 Agent 始终无法给出符合该标准的拆分结果。本文记录全过程，供社区参考。
一、时间线（基于工作产物归档 35 份文件）
| 阶段 |
主要结论（均被否定） |
否定原因 |
| 前任 |
3 PR 方案（Rust 变更闭包合并） |
违反"按域拆、小而聚焦" |
| 第 1-2 轮（5 路） |
52 PR / 57 PR / 150+ PR / 35 PR / 10 PR |
契约前置 PR / 携带他人文件 / 机械单文件拆 |
| 第 3-4 轮 |
契约抽取前置（C0/P0/K1-K10）反复出现 |
前置 = 顺序依赖 = 违反"互不统属" |
| 第 5-7 轮 |
35 PR / 31 PR / 23 PR / 21 PR / 17 PR / 13 PR / 8 PR / 5 PR |
核心闭包吞并多域 / 跨域合并 / 两可裁决 |
数字演变：3 → 52 → 57 → 150+ → 35 → 10 → 60 → 42 → 33 → 35 → 31 → 5 → 23 → 21 → 17 → 13 → 8 → 30 → 5——10+ 个不同答案，无一收敛。
二、根因分析（机制层面，非个体能力）
2.1 负反馈只否定结果，不否定方法
每轮反馈都是"数不对""不该前置""不该合并"，Agent 保留推导方法的 90%，只修补被点名的层（换一种前置形态、闭包扩大一号）。负反馈不携带方法级信息，Agent 无法从"结果被否"反推"假设根因"。
2.2 惯性思维：技术分析取代需求理解
5 路 Agent 全部陷入"文件依赖分析 / 符号闭包推导"的技术动作，把任务重构为"如何让每个 PR 可独立编译的图论问题"。无一路先回答"8 个域，每域几个 PR"——8 域清单人人能复述，但"域 = 审查方可独立评审的产品功能边界"这个语义全部丢失，被"编译/文件边界"取代。
2.3 交叉验证放大同构错误
5 路独立设计意图防盲区，结果高度同构：全部提"抽契约"、全部陷入"同文件整体归属"闭包推导、失败模式完全相同。交叉验证只能发现不一致，无法发现一致的错误——5 个 Agent 共享同一训练分布与方法论时，交叉验证只是把同一个错误复制 5 份。
2.4 缺少需求语义锚点
任务是开放解空间（怎么拆都能编译），收敛需要权威锚点。锚点只能来自对审查方意图的理解（"按域分组、域内细拆"），而 Agent 自己发明的锚点全是技术性的（编译可行性）。没有语义锚点的生成模型，必然漂移到它最熟悉的技术坐标系。
三、结论
- 带负反馈的上下文，做多少遍都会失败——负反馈必须携带方法级指导（"文件不是最小单位，语义功能才是"），只否定结果无效。
- 多 Agent 交叉验证不能替代锚点——只能过滤偶然错误，不能纠正共享方法论导致的系统性偏差。
- 任务派发必须先给语义锚点（域 = 产品功能边界，可跨域共享文件但不可合并域），这是执行成败的第一变量。
- 光靠 Agent 无法完成需要产品语义理解的任务——需要携带需求语义的人类关键指导。
四、附
- 详细论文：《负反馈上下文下，多 Agent 交叉验证为何徒劳》（归档：
E:\finance-trading\lvpa\software\bitfun-pr-docs-archive\论文-负反馈上下文下的多Agent交叉验证为何徒劳-20260809.md）
- 过程产物：35 份工作文档（侦察报告/违规存档/标准迭代 v3/v4），均在工作区外归档目录
本 issue 由下游维护者在拆分任务复盘后提交，用于记录 Agent 协作工程中"标准明确但系统性失败"的实证案例。
上游 Issue 正文（待发布到 origin 1688mengdie/BitFun）
title: 统计报告：PR-2139 拆分任务 20+ 轮重做的全过程复盘——多 Agent 交叉验证在明确标准下为何系统性失败
body（以下为 issue 正文）
触发：收到 PR 2139 review（CHANGES_REQUESTED，limityan，COLLABORATOR）。意见五（L260-268）明确要求"按域拆成独立小 PR，逐个评审、独立测试与回滚"，并逐字列出 8 个拆分域：
配套官方标准：CONTRIBUTING_CN.md L134/L138/L142（PR 小而聚焦、直接提交 main、不提交无关产物）。项目自身标准文件进一步明确：「8 域 = 拆分维度，不是 PR 数；拆分粒度 = 每个功能点/每个工具/每个修复点/每个文件」。
然而：在 5 路独立侦察 Agent 交叉验证 + 20+ 轮重做 + 每轮逐条反馈纠正的条件下，所有 Agent 始终无法给出符合该标准的拆分结果。本文记录全过程，供社区参考。
一、时间线（基于工作产物归档 35 份文件）
数字演变：3 → 52 → 57 → 150+ → 35 → 10 → 60 → 42 → 33 → 35 → 31 → 5 → 23 → 21 → 17 → 13 → 8 → 30 → 5——10+ 个不同答案，无一收敛。
二、根因分析（机制层面，非个体能力）
2.1 负反馈只否定结果，不否定方法
每轮反馈都是"数不对""不该前置""不该合并"，Agent 保留推导方法的 90%，只修补被点名的层（换一种前置形态、闭包扩大一号）。负反馈不携带方法级信息，Agent 无法从"结果被否"反推"假设根因"。
2.2 惯性思维：技术分析取代需求理解
5 路 Agent 全部陷入"文件依赖分析 / 符号闭包推导"的技术动作，把任务重构为"如何让每个 PR 可独立编译的图论问题"。无一路先回答"8 个域，每域几个 PR"——8 域清单人人能复述，但"域 = 审查方可独立评审的产品功能边界"这个语义全部丢失，被"编译/文件边界"取代。
2.3 交叉验证放大同构错误
5 路独立设计意图防盲区，结果高度同构：全部提"抽契约"、全部陷入"同文件整体归属"闭包推导、失败模式完全相同。交叉验证只能发现不一致，无法发现一致的错误——5 个 Agent 共享同一训练分布与方法论时，交叉验证只是把同一个错误复制 5 份。
2.4 缺少需求语义锚点
任务是开放解空间（怎么拆都能编译），收敛需要权威锚点。锚点只能来自对审查方意图的理解（"按域分组、域内细拆"），而 Agent 自己发明的锚点全是技术性的（编译可行性）。没有语义锚点的生成模型，必然漂移到它最熟悉的技术坐标系。
三、结论
四、附
E:\finance-trading\lvpa\software\bitfun-pr-docs-archive\论文-负反馈上下文下的多Agent交叉验证为何徒劳-20260809.md）