dc-docs/output/feishu-docs/CXbTw5QJKics8ekslrGcB6DmnEf.md

CXbTw5QJKics8ekslrGcB6DmnEf

Source: https://fcnlycv6dd0w.feishu.cn/wiki/CXbTw5QJKics8ekslrGcB6DmnEf

今日内容

①多Agent研究协作系统调研梳理（Codex+Claude Code） ②从代码协作经验迁移到论文研究项目 ③相关研究文献支撑整理

一、多Agent研究协作系统调研梳理

🔎 主要推进：

（一）整理背景：从 AI 辅助到研究过程管理

在前期使用 AI Agent 推进论文研究、变量构建、数据分析和文档整理的过程中，逐渐发现一个问题：

🔎 单个Agent虽然能够持续产出内容，但在复杂任务中****容易陷入自我强化陷阱、方向漂移和口径混乱。 尤其是在论文研究这类长期复杂项目中， AI 的问题不一定是“写不出来” 而是它容易把前面已经生成的内容当成默认正确的基础，然后继续补充、扩展和润色。 AI 很多时候不是主动质疑自己刚才的判断，而是更倾向于：

• 证明自己前面生成的内容是合理的；
• 为已有框架继续寻找解释；
• 沿着既定方向补充论据；
• 把原本需要重新判断的问题，写成看似完整的论证；
• 在自我审查时维护自己前面的表达，而不是推翻它。 这就会导致一个问题： AI 自己审核自己的时候，很容易变成“自我辩护”，而不是真正的“外部审查”。

（二）研究的风险

**在论文研究中，这种问题尤其危险。**因为论文不是只要写得顺就可以，还要满足：

• 研究问题成立；
• 理论逻辑清楚；
• 变量口径一致；
• 数据证据充分；
• 方法解释克制；
• 结论不能超过证据边界。

🗯️ 如果只靠一个 Agent 从头推进到尾，可能会出现一种表面上很流畅、实际却不够严谨的情况：文本越来越完整，但研究逻辑不一定越来越可靠。 本次整理的重点不是简单学习“两个 AI 怎么一起写代码”，而是思考： 能否把代码项目中的多Agent协作模式，迁移成一个面向论文研究的 AI 协作与质量控制系统。

（三）系统核心价值：解决单 Agent 的自证陷阱

🗯️ 这套系统最大的价值，是解决单Agent在复杂研究任务中的自证陷阱。 所谓自证陷阱，就是同一个 Agent 在生成内容之后，再让它自己审查时，它往往不会真正站到外部评审角度重新判断，而是会继续延续自己的：

• 初始假设；
• 写作风格；
• 判断标准；
• 证据选择偏好；
• 论证路径；
• 已经投入的修改方向。 于是，它的自我审查可能会从：“这个方向是否真的成立？”变成：“我刚才这样写为什么是合理的？” 前者是审查，后者是辩护。

🔎 这套系统的核心设计是：把生成者和审查者分开。 在系统中： - **Codex：**负责生成、修改、整理和执行； - **Claude Code：**负责审查、质疑、判断和校准； - **人：**负责方向控制、关键取舍和最终决策。 Codex 负责把研究内容推进出来，Claude Code 负责判断这个推进是否成立，最终由人决定是否采纳。

（三）多Agent协作的四条规则

从代码项目中的协作方式迁移过来的四条核心规则。 代码项目里最常见的错误，是让 Claude Code 和 Codex 同时修改同一批文件，导致互相覆盖、代码混乱、AI 越改越偏。 迁移到论文研究中，对应的问题就是： 多个 AI 同时修改同一套理论框架、变量口径或正文表述，最后导致研究内容前后不一致。 规则一**：同一时间只让一个Agent拥有修改权** 错误做法是：

• Codex 正在改机制框架
• Claude Code 同时也在重写同一部分机制框架 这样会导致：
• 机制定义前后不一致；
• 变量口径被改乱；
• 旧概念重新混入；
• 论文越改越散；
• 很难判断到底哪个版本是最终版本。 正确做法是：
• Codex：负责执行、整理、修改
• Claude Code：只读审查、提出问题 或者在某些任务中反过来也可以，但核心原则不变： 同一时间只能有一个 Agent 负责修改内容，另一个 Agent 只负责分析或审查**。** 规则二**：所有协作信息必须文件化** 多Agent协作不能依赖对话记忆，而要让工具直接读取文件或Git获取上下文。
• 因为 Codex 和 Claude Code 之间没有共享记忆。
• 即使是同一个Agent，在多轮对话之后，也可能忘记前面已经确定的任务目标、修改边界、审查意见和关键决策。 因此，所有协作信息都应该通过文件和 Git 进行沉淀，让 Agent 以项目文件为准，而不是以临时对话为准。 **代码项目中，通常会把协作信息写文件目录，**比如：
• brief.md：任务目标
• plan.md：设计方案
• review.md：审查意见
• backlog.md：待办问题
• decision_log.md 关键决策

🔎 这样做的核心作用是： - 让 Codex 和 Claude Code 读取同一套上下文 - 避免信息断层； - 保证任务目标、修改范围和审查意见一致 - 方便通过 Git 查看每一轮修改和决策变化 - 防止多轮推进后概念、变量和口径被改乱 迁移到论文研究项目中，也可以建立类似的研究记忆文件：

• brief.md：研究任务
• plan.md ：修改方案
• review.md：审查意见/ 审查标准
• decision_log.md：关键研究决策
• progress.md：阶段进展记忆

🔎 项目中的协作信息不应该只停留在聊天记录里，而要沉淀成可读取、可追踪、可复盘的文件。 所有 Agent 都只以文件为准，避免因为对话记忆不一致导致研究方向、变量口径和修改边界发生偏移。 规则三**：每次只让 AI 扮演一种角色** 多Agent 协作中，每次任务都要让 AI 扮演一个清晰的角色 不能把分析、设计、修改、审查、优化全部混在一起。 错误提示词是：

• 帮我分析、设计、实现、测试、优化一下这个项目。
• 这种任务范围太大，AI 很容易混乱。它可能一边分析，一边改写，一边补充论证，一边自我证明，最后导致产出失控。 正确做法是： 每次只给 AI 一个明确角色、一个清晰目标、一个有限边界。 例如，让 Claude Code 做审查时，可以明确要求： 让 Codex 执行修改时，可以明确要求： 你现在只做执行修改。请根据 review.md 中的 P0 和 P1 问题，修改当前机制框架。 要求：

1. 不处理 P2
2. 不新增没有数据支撑的变量
3. 不改动本轮任务之外的内容
4. 如果发现额外问题，记录到 backlog.md，不要直接处理

🔎 这条规则的核心是： Claude Code 负责判断，Codex 负责执行；不要让一个 Agent 同时分析、生成、审查和裁决。 职责越单一，边界越清楚，AI 的输出越稳定，也更方便后续复查和回滚。 规则四**：每次修改后必须有统一检查标准**

• 不要让Agent临时猜测或自行决定检查命令**。不要让 AI 自己说“看起来完成了”。**
• 通过固定检查脚本，Agen的工作从自由发挥变成闭环迭代
• **改动→检查→反馈→修复，**持续循环，质量可控。

🔎 因为如果没有统一检查标准，AI 很容易根据自己的理解临时判断任务是否完成，甚至只要文本看起来完整、代码看起来能运行，就默认已经达标。 但在复杂项目中，真正重要的不是“看起来完成”，而是： 是否通过了预先定义的检查标准。 每次 Codex 修改完论文内容后，Claude Code 都应该根据这套清单进行审查，重点检查：

• 研究问题是否聚焦
• 机制名称是否统一
• 机制边界是否清楚等等 这条规则的核心是： 不要让 AI 自己决定“是否完成”，而是让它接受固定标准的检查。 这样可以把 AI 的工作从自由发挥，转变成可控的研究质量循环。

（四）相关研究依据

Self-Refine：支持“生成 → 反馈 → 修改”

**论文：**Self-Refine: Iterative Refinement with Self-Feedback 核心思想是： LLM 第一次生成的结果不一定最好，可以通过反馈和 refinement loop（优化循环） 进一步提升 启发支撑：

• Codex 先生成/修改，不要求一次完美；
• Claude Code 给反馈；
• Codex 再 refinement；
• 循环提升质量。

Reflexion：支持“反馈 + 记忆”改善后续表现

论文：Reflexion: Language Agents with Verbal Reinforcement Learning 核心思想是： Agent 可以把反馈、失败原因、反思内容写入记忆，并在后续任务中利用这些记忆改善表现。 启发支撑：

• 每轮 Codex 执行和 Claude Code 审查后，都应该更新 progress.md。
• progress.md 不是流水账，而是下一轮 agent 的工作记忆。 因此每次循环都要沉淀：
• 本轮做了什么。
• Claude Code 认为哪里不达标。
• Codex 下一轮要修什么。
• 哪些问题已经解决。
• 哪些判断被保留或推翻。

Multi-Agent Debate：支持多个模型实例互相挑战

**论文：**Improving Factuality and Reasoning in Language Models through Multiagent Debate 核心思想是： 多个模型实例提出各自回答，并经过多轮 debate（辩论），有助于提升推理和事实性。 启发支撑：

• 不要让一个 agent 从头到尾自说自话。
• 让 Codex 和 Claude Code 扮演不同角色，可以引入外部质疑。 最稳的是：
• Codex 输出明确稿件/文件
• Claude Code 输出审查意见
• Codex 逐条修改
• Claude Code 再验收 也就是结构化 debate（辩论），而不是自由聊天。

LLM-as-a-Judge 的 self-preference bias：支持“生成者和评审者分离”

**论文：**Self-Preference Bias in LLM-as-a-Judge 核心警示是： LLM 作为审核时，可能偏好与自身风格相近、更熟悉、或自身生成的内容。 启发支撑：不要让同一个 agent 既写、又最终裁决自己写得好不好。 因此更合理的是：

• Codex 写/改
• Claude Code 审
• Codex 再改
• 人 最终决定 这能减少“自证陷阱”：不是让生成者解释自己为什么对，而是让另一个 agent 专门寻找它哪里不够对。

🔎 这套系统并不是直接证明“Claude 一定比 Codex 适合审查”，也不是证明“Codex 一定比 Claude 更适合执行”。 更准确地说，角色分工来自实际项目体感、工具能力和实践。 但相关研究可以支持这套系统背后的底层原则： - 生成—反馈—修改的循环是有效的； - Agent 可以利用反馈和记忆改善后续表现； - 多 Agent 互相挑战有助于提升推理和事实性； - 同一个模型自评自身输出可能存在偏好，因此生成者和审查者分离是合理的。 这套系统的定位不是“AI 工具工作流”，而是：一个面向研究的 AI 协作与质量控制系统。