SOTA Sync
← 返回 FEED
AGENT2026-05-13

Agentic Research Best Practices：用 Coding Agent 驱动科研项目

Joseph Viviano 分享了他 15 个月来用 coding agent 驱动科研项目的经验总结。核心前提：研究代码库和工程代码库需求不同。

研究代码库的独特需求

必须满足：

  • 高可移植性和可复现性——精确反映论文产出的运行过程
  • 易理解——让他人快速上手和 hack
  • 正确性——测试、文档、注释、代码和论文本身必须精确匹配
  • 你自己完全理解其工作方式

不需要：

  • 生产级质量
  • 面向长期维护或扩展的复杂抽象
  • 处理 API 变更、遗留代码路径等用户支持复杂度

核心工作流

paper.tex / design_doc.md（静态意图）
    ↓
roadmap.md（线性目标）
    ↓
task_plan.md（细粒度任务，<20% context window）
    ↓
实现 + 外部验证
    ↓
notes.md（发现记录）
    ↓
定期汇总回高层文档

paper.tex / design_doc.md 捕获要解决的问题、使用的方法、项目架构。agent 会从这里抽取大量假设，所以这份文档要仔细审查。

roadmap.md / task_plan.md 将设计文档线性化为具体任务列表。粒度与项目复杂度成正比——小项目可以跳过这层。目的是给每个 agent 一个 well-scoped 的任务，轻松放入 <20% 的 context window。

notes.md 建设过程中的发现：算法怪癖、库限制、集群陷阱、其他代码库的实现研究。这些笔记应定期 compact，只保留尚未编码进代码库的信息。

关键原则

Git 是 Savegame 每个 TODO 单独 commit，清晰 commit message。Agent 使用 git 比任何研究者都专业。让 agent 驱动 git，而不是你自己做。

Plan Agent ≠ Implement Agent 除非任务简单，否则用独立 agent 做计划和实现。这样 implementation agent 只消费相关 planning context 的子集。

独立 Test Agent 测试由未参与实现的独立 agent 编写，减少 test-cheating 可能性。

Worktrees 并行 多个 agent 在单个项目的并行代码副本中工作，用 worktrees 实现。这是研究者几乎不碰的高级 git 工具，但 agent 可以处理复杂度。

Context 管理是核心技能

  • Agent 在 100-300k token 范围表现最好，大 context limit 大多是营销谎言
  • AGENT.md 只放通用规则，保持简短
  • 一个坏 prompt = 一百行坏代码 = 污染代码库 = 未来 session 难以识别

AGENT.md 通用规则示例

  • 不要假设：如果指令不清晰，问澄清问题直到消除所有歧义
  • 这是研究代码库，修改代码时不要保留静默 fallback，要 fail loudly
  • 代码应该对读者显式，简单模式够用就不用复杂工程模式
  • 工作时不要删除旧注释，除非底层逻辑变了且注释错误
  • 优先可复现性和清晰度，而非聪明设计和效率
  • 设计解决方案时对齐 design_doc.md 和 paper.tex 中的高层计划
  • TODO.md 中每个 item 单独 commit

成本控制策略

  1. 不同产品计费方式不同，比较相似任务的 token 消耗
  2. 管理好 context 就能限制 token 使用
  3. 用重推理模型（Opus）做计划，用便宜模型（Sonnet）执行 TODO
  4. 最小化 planning docs 内容，定期 compact 防止 context bloat
  5. 定期重构简化代码，防止 context 爆炸（现在花钱省以后的钱）
  6. 频繁重启 chat，但不要太频繁。最佳性能：<40% context 使用率

并行工作流

多个 agent 处理多个并行问题，每个可以有自己的 subagent：

  • 代码库安全漏洞扫描 → 不同 subagent 处理不同模块
  • 并行 stream 通过代码库状态和定期更新的 notes.md / plans.md 同步 context

验证策略

AI 在能验证自己做对了时表现最好。理想情况：有可执行测试确保代码正确。

  • 独立 test agent + code agent 分离
  • Linting、typing、docstrings、assertions 帮助验证代码匹配意图
  • 敏感操作（数据库迁移、大文件系统操作）让 agent 输出脚本，你手动验证后执行

论文与代码对齐

研究过程中发现和偏差必然发生。让 agent 做 thorough analysis：

"请分析方法部分和结果部分，与开发的代码库对比。用 subagent 并行工作。确保所有方法细节都在论文中捕获，所有结果都来自论文描述的方法，注意数学实现中的细微偏差。不要直接编辑论文，我们先逐个诊断偏差再决定修复。"

新标准的建立

社区应该提高对「可接受研究代码」的标准：

  1. 项目从 project plan 开始，最终成为论文本身。design_doc.md 与代码库应有深度连接
  2. Typing、Comments、Docstrings、Variable Names 不仅帮助 coding agent，也帮助下游用户理解论文如何在代码中反映
  3. Testing 是 coding agent 的有用约束，也让你对结果有信心
  4. Thorough Demonstrations 现在可以单次 sitting 完成，帮助读者交互式理解

Warm Start

永远不要从零开始。如果不用 fork，可以提供参考代码库指导方法细节或架构。也可以从 "stubs" 开始——函数/类签名提供高层架构结构，代码细节留空。

练习建议

想练习 agent 驾驭能力？建一个 3D 游戏引擎。比研究代码库复杂 10 倍，需要精确描述行为（不容易编码为测试）、playtest 验证结果。这能锻炼写精确 spec、管理 context、设计验证策略的能力。

Joseph 正在现代化一个经典游戏，这是他以前做梦都不敢在职业生涯之外追求的项目——agent 让这成为可能。

相关