可验证闭环的边界

闭环在哪些任务上最容易成立？

• 容易成立: Coding、工具调用和业务状态变更;
• 原因: 测试、环境状态或确定性规则能够快速给出反馈;
• 含义: 可验证闭环的适用范围由“评价信号是否可自动获得”划定;

开放任务为什么让闭环失效？

• 典型任务: 开放式科研、战略规划和复杂产品设计;
• 特征一: 评价信号来得慢;
• 特征二: 正确答案不唯一;
• 特征三: 研究品味、长期价值、可维护性等真正重要的目标还很难用分数评判;
• 失效形态: Harness 可以把流程执行得非常完整，却只是稳定地产出“像成果的东西”，没有推动真实目标;

自主科研暴露了哪三类问题？

问题	表现
实现漂移	原方案一旦变难，Agent 逐渐退回训练数据中更熟悉、但已经偏离研究假设的普通实现
认识论上的过度乐观	信号仍可能只是噪声，系统却开始解释结果、添加补丁并宣布发现；失败和阴性结果更容易被忽略
隐性判断力不足	Agent 可以运行实验，却未必知道什么基线真正重要、哪个异常值得追踪、何时应该放弃假设

• 压力测试观察: 四次从研究想法走向论文的端到端尝试中，三次在实现或评估阶段失败，只有一次完成整条流水线;
• 判断: 这类任务不能靠换一个模型彻底解决，而要改变证据和监督结构;

应改变什么结构来补救？

• 结论与证据分离: 对引用、数字、方法和结论分别记录证据来源，最终文稿只是证据图的一种呈现;
• 案例: ScientistOne 的 Chain-of-Evidence 设计把每类声明都链接到可审计来源；它提高的是可追溯性，并不自动保证研究问题有价值;
• 保留负面结果: 失败实验、被拒提案和停止原因写入日志，否则进化模块只看到幸存方案，会反复探索已经证伪的路径;
• 维护搜索多样性: 不应只保留当前得分最高的一条链，备选方案池还需保留若干暂时低分但类型不同的分支，避免所有方案收敛成同一个易得分模板;
• 让人类在更高层介入: 人的作用不应只是在危险工具调用前点“批准”，还包括定义问题、审查评价标准、解释反常结果和决定何时停止;