💡 **AI迈向自我训练与优化**：研究提出了一种新的AI自改进框架HGM，使智能体能够自主生成、验证和优化自身代码，而不是仅仅依赖于人类提供的训练数据或模型架构。这标志着AI能力从“被动接受训练”向“主动自我提升”的转变。
📈 **谱系元生产力（CMP）纠正短期偏见**：传统自改进方法常受限于短期分数，导致“高分但无后代”的错配。HGM引入CMP指标，通过评估智能体整个后代谱系的预期表现来衡量其长期价值，从而指导更具前瞻性的自我优化决策，确保持续的进化潜力。
⚙️ **解耦策略实现高效探索**：HGM将自改进过程中的选择、扩张和评估策略解耦，允许它们独立调度。这种设计优化了计算资源的使用，使得AI能够更高效、更有条理地探索广泛的自改进路径，避免了传统方法中探索方向混乱的问题。
🚀 **显著的性能提升与效率优化**：在多个软件工程基准测试中，HGM展现出更高的准确率和更低的计算开销。通过异步并行执行和优化的调度机制，HGM比现有方法快数倍，证明了其在实际应用中的强大能力和成本效益。
🛠️ **具象化的自我修复能力**：研究展示了HGM能够自动诊断并修复代码错误，如Python模块未找到或语法错误。这种“出错—分析—修复—再评估”的闭环过程，是AI在自我修复方面取得的突破性进展，无需人工干预即可完成代码的调试与改进。
原创 让你更懂AI的 2025-10-28 14:04 北京
从被训练到能训练自己
过去，AI 只能“被训练”；现在，它开始“训练自己”。来自 LSTM 之父 Jürgen Schmidhuber 团队的最新研究，展示了一种能自我修改、自我修复、甚至自我优化的智能体——它真的开始学会 Debug 自己。
这几年，我们见证了 AI 能“写代码”“画图”“推理”，但所有这些能力，都还停留在“人类训练出的结果”。
如果有一天，AI 不仅能写代码，还能主动修改自己的代码，在一次次“自我修复”中变得更强，会发生什么？
这正是 LSTM 之父 Jürgen Schmidhuber 团队在最新论文中尝试回答的问题。他们提出了一种全新的自改进框架——不是靠更多数据或更大模型，而是让智能体自己生成、自己验证、自己优化。
过去的“自改进”算法有一个致命问题：短期分数 ≠ 长期潜力。一个智能体在当前测试中拿高分，并不代表它的后代也能持续改进。
Schmidhuber 团队提出的方案，让智能体不再盯着眼前分数，而是学会看“谱系”——即它的整个后代树。
他们称之为 Clade Metaproductivity（CMP，谱系元生产力）：衡量一个智能体的真正价值，不在于它此刻的分数，而在于以它为根的谱系中最优秀后代的预期表现。
这一指标不依赖即时得分，而关注智能体在长期演化中能否孕育出更强的后代。
▲ 图1. 短期分数 vs 长期潜力
左图揭示旧方法中“高分但无后代”的错配问题，右图显示新方法在相同预算下以更少计算获得更高准确率。
论文标题：
Huxley-Gödel Machine: Human-Level Coding Agent Development by an Approximation of the Optimal Self-Improving Machine
论文链接：
https://arxiv.org/abs/2510.21614
Github链接：
https://github.com/metauto-ai/HGM
Schmidhuber 曾在 2003 年提出著名的 Gödel Machine概念——一种能“读懂并修改自己代码”的理想化智能体，只在能被证明是长期收益更高的情况下才自我修改。
问题在于，这个“证明”太难了。所以现实世界的自改进智能体都退而求其次：靠当前得分来评估改进是否值得——谁分高，谁的修改就被接受。
但作者团队发现：这种做法在长期演化中会导致错配。有的高分智能体产不出更好的后代，有的中等智能体却孕育出更强谱系。
他们把这种现象命名为：Metaproductivity–Performance Mismatch（MPM）——即时分数与长期自改进潜力的不一致。
于是，他们引入了上文定义的谱系指标 CMP，用来纠正这种错配：不再让智能体追逐短期分数，而是用谱系视角衡量真正的“进化潜力”。
让智能体学会选择“进化方向”
论文提出的模型名为 HGM（Huxley–Gödel Machine），将整个自改进过程建模为一棵智能体进化树。每个节点代表一次自修改，每条边表示从旧版本到新版本的演化。
算法的核心在于三种策略：选择（selection）、扩张（expansion）和评估（evaluation）。
传统方法（如 SICA、DGM）将三者混为一体，新生成的智能体立刻评估、再生成下一个，导致计算资源浪费且探索方向混乱。HGM 通过解耦三种操作，让它们可以独立调度，从而以更高效率探索更广泛的自改进路径。
2.1 长期潜力的可计算近似为了在实践中衡量长期潜力，HGM 定义了全局版本的元生产力——GMP（Global Metaproductivity）：
GMP 是一种“全局视角”的度量，考虑整棵树的最优子代，但计算代价极高。因此，算法用前文定义的 CMP（谱系元生产力）作为近似指标，用它来指导“扩张”与“评估”的分配决策。
2.2 基于Beta分布的谱系抽样
对于每个智能体 a，算法统计它及其谱系的成功与失败次数：
然后基于这些统计，使用 Thompson Sampling 抽样策略选出下一个扩张对象：
是时间调度函数，控制探索与收敛的平衡。这一步让智能体既能尝试新思路，又能聚焦于“有潜力的谱系”。
2.3 扩张与评估的调度
为了避免无止境的扩张，算法设置了一个简单条件：
当当前评估次数的幂次超过已存在智能体数量时，触发新的扩张操作。这种近似“赌博机”式的机制保证了探索深度与计算预算的平衡。
▲ 图2. HGM 主循环：谱系估计 → Beta 抽样扩张 → 评估 → 最终选择
2.4 异步执行与最终选择
评估与扩张的过程被设计为异步并行：每个 CPU 核心独立运行，当某个任务结束时立即补位新任务，从而持续利用全部算力。
最终，算法在预算耗尽后通过正则化不完全 Beta 函数 选出“最可信”的智能体：
这一步确保最终选择既考虑成功概率，又保留统计不确定性，从而避免过早收敛。
实验结果
作者团队在多个软件工程基准上验证了 HGM 的自改进能力，包括 SWE-bench Verified、Polyglot 和 SWE-bench Lite。这些数据集涵盖代码修复、单元测试与多语言任务，是业界评估编程智能体表现的标准测试场。
3.1 验证：高分 ≠ 可进化
▲ 表1. 经验 CMP 与估计值的相关性：HGM 的谱系估计与真实 CMP 的相关性最高，显著缓解了“高分不等于高潜力”的错配问题。
在 SWE-Verified-60 与 Polyglot 上，HGM 的加权相关分别为 0.778 与 0.626，显著高于 DGM（0.285 / 0.383）与 SICA（0.444 / 0.274）。这说明智能体在决策“谁值得扩张”时，第一次拥有了可靠的进化信号。
3.2 性能与效率双优
▲ 表2. 自改进能力对比：HGM 同时获得更高准确率与更低计算开销。
HGM 的最终智能体在 SWE-Verified-60 上达到了 56.7% 的准确率，比 DGM 高 3.4 个百分点，但所需 CPU 小时减少近 2.38 倍。
在 Polyglot 上，它以 347 CPU-hours 完成 800 次评估，相比 DGM 的 2385 CPU-hours，约 6.86 倍更快，同时取得 10.2% 的额外增益。
异步扩张让训练过程从“串行探索”变成“全并行演化”，效率提升尤为显著。
3.3 泛化与迁移能力
▲ 表3. 迁移到 SWE-Lite（同骨干）：在新数据集上保持稳定增益，证明改进逻辑可泛化。
▲ 表4. 迁移到更大骨干（GPT-5）：结构优化可直接迁移，性能进一步提升。
在 SWE-Bench 体系下，HGM 发现的代理在相同骨干（GPT-5-mini）条件下超过当时最佳人类系统，并在将骨干替换为 GPT-5 后，在 SWE-Lite Standard 设定上匹配或略高于最佳“checked”人类系统的成绩（57.0% vs. 56.7%）。
论文也指出，这些榜单提升不必然等价于通用推理能力的全面增强，因为部分系统可能对基准存在过拟合。这表明模型并非“记住”了解题技巧，而是在演化过程中真正“学会了如何改进自己”。
当智能体真的开始Debug自己
论文附录中展示了几段由智能体自动生成的代码片段，最具代表性的是下面这一段。
Listing 1：自动 Debug 片段——智能体自动检测并修复代码错误，展示出具象的自我修复行为。
+def attempt_error_resolution(git_dir, test_output, test_error,
,→ language):
+ """
+ Attempt to automatically diagnose and resolve errors.
+ Returns a tuple of (resolved, message) where resolved indicates if
,→ errors were fixed.
+ """
+ safe_log("Attempting automated error diagnosis and resolution...")
+
+ # Diagnose errors using our enhanced bash tool function
+ diagnosis = diagnose_errors(test_output, test_error, "")
+
+ if not diagnosis["has_errors"]:
+ return False, "No errors detected to resolve."
+
+ resolution_messages = []
+
+ # Try to apply automated fixes for each diagnosed error
+ for error in diagnosis["errors"]:
+ safe_log(f"Processing error: {error[’type’]} -
,→ {error[’description’]}")
+
+ # Simple resolution strategies based on error type
+ if error["type"] == "python_module_not_found":
+ # For Python module not found errors, we might install the
,→ module
+ match = re.search(r"No module named ’([^’]+)’",
,→ error["description"])
+ if match:
+ module = match.group(1)
+ resolution_messages.append(f"Would attempt to install
,→ Python module: {module}")
+ # In practice, we would run: pip install {module}
+ # But we’ll skip actual installation to avoid side
,→ effects
+
+ elif error["type"] == "python_syntax_error" and "file"in error:
+ # For syntax errors, we could potentially apply fixes
+ file_path = os.path.join(git_dir, error["file"])
+ if os.path.exists(file_path):
+ resolution_messages.append(f"Would attempt to fix
,→ syntax error in {file_path} at line {error.get(’line’,
,→ ’unknown’)}")
+ # In practice, we would use the editor tool’s apply_fix
,→ command
+ # This is just a demonstration of what could be done
+
+ elif error["type"] == "test_failure":
+ # For test failures, we might suggest reviewing the
,→ implementation
+ resolution_messages.append("Would analyze test failures and
,→ suggest implementation improvements")
+
+ if resolution_messages:
+ return True, "Automated resolution attempted:\n" +
,→ "\n".join(resolution_messages)
+ else:
+ return False, "No automated resolutions available for detected
,→ errors."+
class AgenticSystem:
def __init__(
self,
@@ -243,6 +293,16 @@ Your task is to make changes to the files in the
,→ {self.git_dir} directory to add
safe_log(f"Attempt {attempt + 1} test results: {’PASSED’ if
,→ test_success else ’FAILED’}")
+ # If tests failed, attempt automated error resolution
+ if not test_success:
+ resolved, resolution_message = attempt_error_resolution(
+ self.git_dir, test_output, test_error, self.language
+ )
+ safe_log(f"Error resolution: {resolution_message}")
+
+ # Even if we couldn’t automatically resolve, we still
,→ provide feedback
+ # In a more advanced implementation, we might actually
,→ apply fixes here
+
# If this is the first attempt or tests passed and we
,→ didn’t have a successful attempt yet, update best patch
if attempt == 0 or (test_success and (best_patch is None or
,→ not best_test_results)):
best_patch = current_patch
@@ -278,37 +338,31 @@ Please revise your code to fix these issues and
,→ try again.
# Log final summary
safe_log(f"\n{’=’*20} FINAL SUMMARY {’=’*20}")
safe_log(f"Best solution found on attempt:
,→ {best_test_results[’attempt’] if best_test_results else ’None’}")
- safe_log(f"Tests passed: {best_test_results[’test_success’] if
,→ best_test_results else ’Unknown’}")
+ safe_log(f"Final test result: {’PASSED’ if best_test_results
,→ and best_test_results[’test_success’] else ’FAILED’}")
+
+ if best_test_results:
+ safe_log(f"Final test
,→ output:\n{best_test_results[’test_output’]}")
+ if best_test_results[’test_error’]:
+ safe_log(f"Final test
,→ errors:\n{best_test_results[’test_error’]}")
- # Save attempt history to a file
- history_file =
,→ os.path.join(os.path.dirname(self.chat_history_file),
,→ ’attempt_history.md’)
- with open(history_file, ’w’) as f:
- f.write("# Attempt History\n\n")
- for result in self.attempt_history:
- f.write(f"## Attempt {result[’attempt’]}\n")
- f.write(f"**Tests Passed**: {result[’test_success’]}\n")
- f.write(f"**LLM Calls Used**: {result[’llm_calls’]}\n")
- f.write(f"**Test
,→ Output**:\n‘‘‘\n{result[’test_output’]}\n‘‘‘\n")
- f.write(f"**Test
,→ Error**:\n‘‘‘\n{result[’test_error’]}\n‘‘‘\n")
- f.write(f"**Patch**:\n‘‘‘\n{result[’patch’]}\n‘‘‘\n\n")
+ return bool(best_test_results and
,→ best_test_results[’test_success’])这段代码由智能体自主编写，它在运行失败后主动调用attempt_error_resolution()进行诊断与修复，然后生成新补丁继续测试。
整个过程无人介入，却完整闭合了“出错—分析—修复—再评估”的循环。在以往的自改进研究中，这是第一次出现可观察、可复现的自我修复行为。
总结：自改进的现实落点
Schmidhuber 团队的工作为“自我进化智能体”提供了一个可落地的工程化范例。它不依赖人工标注或额外奖励，而通过谱系统计与异步探索，在可控的计算预算下持续优化自身。
更重要的是，这项研究表明，“自改进”已从理论设想变为可实现、可验证、可量化的学习机制。
在模型规模与外部监督双重逼近极限的阶段，这种基于谱系统计的自修复智能体，正在提示一种新的研究方向——从“学习知识”迈向“学习改进自身”的智能演化范式。
更多阅读
#投 稿 通 道#
让你的文字被更多人看到
如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。
总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。
PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学术热点剖析、科研心得或竞赛经验讲解等。我们的目的只有一个，让知识真正流动起来。
📝 稿件基本要求：
• 文章确系个人原创作品，未曾在公开渠道发表，如为其他平台已发表或待发表的文章，请明确标注
• 稿件建议以 markdown 格式撰写，文中配图以附件形式发送，要求图片清晰，无版权问题
• PaperWeekly 尊重原作者署名权，并将为每篇被采纳的原创首发稿件，提供业内具有竞争力稿酬，具体依据文章阅读量和文章质量阶梯制结算
📬 投稿通道：
• 投稿邮箱：hr@paperweekly.site
• 来稿请备注即时联系方式（微信），以便我们在稿件选用的第一时间联系作者
• 您也可以直接添加小编微信（pwbot02）快速投稿，备注：姓名-投稿
△长按添加PaperWeekly小编
🔍
现在，在「知乎」也能找到我们了
进入知乎首页搜索「PaperWeekly」
点击「关注」订阅我们的专栏吧
·
AI辅助创作，多种专业模板，深度分析，高质量内容生成。从观点提取到深度思考，FishAI为您提供全方位的创作支持。新版本引入自定义参数，让您的创作更加个性化和精准。
鱼阅，AI 时代的下一个智能信息助手，助你摆脱信息焦虑