作者—审阅者循环以约三分之一成本完成与多智能体工作流相当的MCFM Fortran到C++翻译

提出并验证了一套以验证边界为核心的人机协作工作流架构，包含五项设计原则：每个阶段边界做数值验证、人类设计并接受目标而智能体做重复性工作、可复现性与来源记录、角色间协作、开放且用户可控的智能体执行策略。 相对于把智能体用于全自动化的做法，该工作把监督、实现与验收三种角色显式分离，并将规范、计划、工具与日志保存在团队共享的版本化Lab Notebook目录树中，使同一任务可在不同编排器下重跑比较。 架构与原则在MCFM翻译案例上以十四次运行实现，所有运行从同一提交和同一445个候选文件出发，门控与oracle在每次运行中为同一份代码。

在相同编排器（Claude Code）与相同模型（Opus 5）下，作者—审阅者循环（R12）与多智能体工作流（R2）settle了相同的文件，循环的成本约为其40%，每个文件耗时相近。 该对比只改变编排模式而固定智能体与模型，因此把成本差异归因到编排层；作者指出并行智能体各自读取同一背景材料，而完成量只取决于单次集成步骤的结果，故并行节省的时间不足以补偿重复读取。 R12与R2为单次运行，其余配置大多有重复；成本按列表价格计算，文件数按每次运行产生的git分支统计而非智能体自报清单。

行为规则由编排器架构强制（CodeScribe，csloop）时，没有阶段超出迭代上限或偏离执行策略；仅靠提示约束（Claude Code，ccloop）时，作者阶段频繁超限，其中一次达到67次迭代（上限30），且未收到纠正性的ReAct反馈。 该对比固定作者—审阅者模式，只改变执行策略的强制方式，说明可复现、可审计且可预期终止的运行需要被强制的结构而非提示中的约束。 csloop覆盖R4–R11共八次运行，ccloop覆盖R12–R14三次运行，均在同一agentic layer上运行。

模型选择影响工具调用行为与成本：名义上计费最低的Sonnet 5产生了每个settle文件最昂贵的两次运行（R7、R8），其每个文件的工具调用次数是其他csloop运行的数倍且完成文件更少；GPT 5.6-Sol（R9–R11）在相似token成本下每个文件表现接近Opus 5运行，但工具调用更多。 该对比保持编排器不变而只改变模型，把差异归因到模型及其API格式；同时发现十四个运行挑选的文件顺序与最终文件高度一致，主要因为编排器的排序工具决定了哪些文件就绪。 csloop内跨三个模型家族共八次运行，其中R8为不完整运行（未归档agent_log）；缓存效率差异被归因于Anthropic与OpenAI暴露的不同API开关。

该工作面向需要在不侵蚀领域理解与正确性保证的前提下使用智能体的科学软件团队，尤其是维护大型遗留Fortran代码库并希望逐步迁移到C++或设备可移植内核的团队。作者说明Lab Notebook的继承结构、共享agentic layer设计与分阶段转换格式是通用的，其他项目可保留同一布局、替换项目相关部分，并加入通过MCP暴露工具的agentic layer实现。作者也指出作者—审阅者循环可用于部署模拟活动、运行分析与分部分完成工作，使人类能有效监督AI工作。成本结论被作者限定为特定于该任务：文件之间互不依赖，但每个文件相对于智能体必须先阅读的材料很小。

智能体运行是随机过程，作者指出每个条件单次观测无法把编排器或模型效应与运行间方差分开，且ccworkflow Opus 5（R2）与ccloop Sonnet 5（R14）为单次运行。Claude Code在Lab Notebook之外保留用户私有memory目录，R1的memory影响了R12并使其跳过Mods/目录，作者说明该影响未在记录中留下痕迹，R13与R14在清除memory后处理了被跳过的文件。共享规范中关于Fortran kind参数（sp、dp、ex、qp）的C++表示存在空白，模型给出了保留类型的实数类型与占位整数两种互不兼容的答案，两者都通过了完整基准套件，因为转换后的代码从未直接引用这些常量。作者还指出模型API格式与智能体执行策略仍是开放问题，并引用一份报告称大规模运行的多智能体系统绕过了执行良好的护栏。