AI Agent自修改代码实验：144轮迭代下的代码熵增与崩溃分析

在探索AI自主编程的边界时我进行了一次实验让一个AI智能体Agent在144个循环中持续修改自己的Python源代码。这个实验并非为了创造一个完美的代码生成器而是想观察在无限制的自我迭代下代码会如何“演化”以及最终会“崩溃”成什么样子。结果既在意料之中又充满了令人深思的细节。本文将完整复盘这次实验从环境搭建、核心循环逻辑到代码的“熵增”过程、典型错误模式以及从中提炼出的关于AI辅助编程的工程实践启示。无论你是对AI Agent开发感兴趣的工程师还是想了解当前大模型编码能力的边界这篇文章都将提供一手的技术观察和避坑指南。1. 实验背景与核心概念1.1 什么是自修改代码的AI Agent在这个上下文中AI Agent指的是一个具备一定自主能力的程序它能够接收目标例如“优化这段代码”调用大语言模型LLMAPI进行分析和代码生成并执行生成的代码。而“自修改”意味着这个Agent的核心循环逻辑就是不断地读取自己的源代码文件让AI分析并重写它然后再保存、加载并执行新版本的自己。这听起来有点像科幻电影里的自我进化但其技术基础并不复杂。本质上它是一个将代码生成、文件IO、动态导入import和异常处理循环结合起来的自动化脚本。实验的目的不是追求功能的完善而是观察在这种“自我指涉”和“无监督迭代”下代码质量、结构和功能会如何变化。1.2 实验想解答的问题创造性还是破坏性AI在多次迭代中是会创造出更优雅、更高效的代码还是会引入难以察觉的bug和逻辑混乱代码“熵增”定律在没有明确优化目标和严格测试的情况下代码是否会不可避免地走向混乱和腐败大模型的记忆与一致性当前的大语言模型如GPT-4、Claude等在长上下文和多轮对话中能保持一致性但当它以“每次只看到当前版本代码”的方式介入时它能否维持一个连贯的代码演进路径工程风险的真实图景完全依赖AI进行代码迭代在实际项目中会埋下哪些隐患本次实验使用Python语言因为它动态、灵活的特性非常适合这类自修改操作。实验的核心就是下面这个简单的循环读取自身 - 请求AI修改 - 保存 - 重新导入 - 执行。2. 环境准备与实验工具为了复现和深入理解这个实验你需要准备以下环境。请注意实验代码涉及动态修改和导入自身存在一定风险请在隔离的虚拟环境中进行。2.1 基础环境配置操作系统Windows 10/11, macOS 或 Linux (实验在Linux环境下进行但代码是跨平台的)。Python版本3.8 或更高版本。确保pip包管理器可用。虚拟环境强烈推荐使用venv或conda创建一个独立的Python环境避免污染系统库。# 使用 venv python -m venv ai_agent_env source ai_agent_env/bin/activate # Linux/macOS # ai_agent_env\Scripts\activate # Windows2.2 关键依赖库实验的核心依赖是OpenAI的Python客户端库用于调用GPT模型API。同时需要colorama来在终端输出彩色日志增强可读性。pip install openai colorama关于API Key你需要一个有效的OpenAI API Key。请妥善保管不要将其硬编码在代码中提交到版本控制系统。2.3 实验代码结构概览在开始前我们先了解下初始的Agent代码结构。它主要包含以下几个部分主循环逻辑控制迭代次数协调读取、修改、重载流程。AI交互模块封装与OpenAI API的通信构建提示词Prompt。代码重写器将AI返回的内容写回源文件。动态重载与执行使用Python的importlib重新加载模块并执行特定函数。健壮性包装大量的异常捕获和日志记录因为崩溃是实验的一部分。一个最简化的项目目录如下self_modifying_agent/ ├── agent.py # 主程序即即将被自我修改的文件 ├── run_experiment.py # 启动实验的引导脚本 └── requirements.txt3. 核心代码拆解自修改循环如何工作让我们深入agent.py的初始版本看看自修改循环是如何实现的。理解这部分是分析后续“崩溃”的关键。3.1 引导脚本安全的启动器由于主文件agent.py会不断被重写直接运行它可能导致不可预测的行为。因此我们创建一个独立的run_experiment.py作为安全的引导程序。# run_experiment.py import subprocess import sys import time def run_cycle(cycle_count): 运行一个完整的修改-执行周期 print(f\n{*60}) print(f启动第 {cycle_count} 轮迭代) print(*60) try: # 使用子进程运行agent.py隔离每次迭代的环境 result subprocess.run( [sys.executable, agent.py, str(cycle_count)], capture_outputTrue, textTrue, timeout30 # 设置超时防止卡死 ) print(f标准输出:\n{result.stdout}) if result.stderr: print(f标准错误:\n{result.stderr}, filesys.stderr) print(f返回码: {result.returncode}) return result.returncode 0 except subprocess.TimeoutExpired: print(⚠️ 本轮执行超时) return False except Exception as e: print(f⚠️ 执行过程异常: {e}) return False def main(): total_cycles 144 successful_cycles 0 for i in range(1, total_cycles 1): if run_cycle(i): successful_cycles 1 else: print(f第 {i} 轮迭代失败可能代码已损坏。) # 可以选择继续尝试或终止 # break time.sleep(2) # 循环间短暂停顿避免API速率限制 print(f\n实验结束。成功轮次: {successful_cycles}/{total_cycles}) if __name__ __main__: main()这个脚本的核心思想是进程隔离。每一轮迭代都在一个新的子进程中运行agent.py这样即使某轮迭代的代码彻底崩溃如语法错误也不会影响引导脚本本身从而保证实验能持续记录。3.2 Agent核心自我读取、修改与重载agent.py的初始版本包含了自我修改的所有逻辑。以下是其关键部分# agent.py (初始版本) import openai import os import sys import importlib import inspect import time from colorama import init, Fore, Back, Style init(autoresetTrue) # 初始化colorama # 配置OpenAI客户端API Key应从环境变量读取 client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY)) MODEL_NAME gpt-4 # 或 gpt-3.5-turbo def get_self_code(): 读取自身的源代码 current_file __file__ with open(current_file, r, encodingutf-8) as f: return f.read() def modify_code_with_ai(current_code, cycle_num): 调用AI模型请求其改进当前代码 prompt f 你是一个Python专家。以下是第{cycle_num}轮的一个自我修改AI Agent的代码。 请分析并改进这段代码。你可以 1. 修复潜在的bug。 2. 优化代码结构或性能。 3. 添加更有用的功能或注释。 4. 增强错误处理或日志。 5. 保持代码的自我修改能力。 注意不要改变基本的自我修改循环框架即get_self_code, modify_code_with_ai, reload_and_execute等核心函数名和调用逻辑。 直接返回完整的、可运行的Python代码。 当前代码 python {current_code} try: response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperature0.7, # 一定的创造性 ) new_code response.choices[0].message.content # 清理响应提取代码块 if python in new_code: new_code new_code.split(python)[1].split()[0] elif in new_code: new_code new_code.split()[1].split()[0] return new_code.strip() except Exception as e: print(Fore.RED f调用AI API失败: {e}) return None def write_new_code(new_code): 将新代码写回文件 current_file __file__ # 备份旧代码可选 backup_file f{current_file}.backup if os.path.exists(current_file): import shutil shutil.copy2(current_file, backup_file) with open(current_file, w, encodingutf-8) as f: f.write(new_code) print(Fore.GREEN ✅ 代码已更新。) def reload_and_execute(): 动态重载当前模块并执行主逻辑 current_module sys.modules[__name__] importlib.reload(current_module) # 重载后重新导入必要的函数因为模块对象已更新 from agent import main_loop_logic main_loop_logic() def main_loop_logic(): 被重载后执行的主要逻辑 print(Fore.CYAN Style.BRIGHT f\n[Agent] 我正在运行第 {sys.argv[1]} 轮次。) # 这里可以放置一些简单的自检或功能代码 # 例如计算斐波那契数列、读取某个文件等 print(Fore.YELLOW 执行一些示例任务...) # 模拟任务 time.sleep(0.5) print(Fore.YELLOW 示例任务完成。) def main(cycle_num): 主控制流程 print(Fore.BLUE f\n 开始第 {cycle_num} 轮自修改 ) # 1. 获取当前代码 old_code get_self_code() print(Fore.BLUE f当前代码长度: {len(old_code)} 字符) # 2. 请求AI修改 print(Fore.BLUE 请求AI分析并改进代码...) new_code modify_code_with_ai(old_code, cycle_num) if new_code and new_code ! old_code: # 3. 写回新代码 write_new_code(new_code) # 4. 重载并执行新逻辑 print(Fore.BLUE 尝试重载并执行新代码...) reload_and_execute() else: print(Fore.RED ⚠️ 未获得有效的新代码本轮跳过修改。) # 执行原有逻辑 main_loop_logic() if __name__ __main__: if len(sys.argv) 1: main(int(sys.argv[1])) else: print(请提供循环轮次作为参数。)关键机制解释get_self_code: 使用__file__获取当前脚本路径并读取内容。modify_code_with_ai: 构建一个详细的Prompt将当前代码发送给AI并请求其返回“改进版”。temperature0.7是为了在改进和保持稳定性之间取得平衡。write_new_code: 在写回新代码前先备份旧版本。这是一个重要的安全措施。reload_and_execute: 这是最精妙也最危险的一步。importlib.reload()会强制Python重新加载当前模块然后我们试图从重载后的模块中导入并执行新的main_loop_logic函数。进程参数: Agent通过sys.argv[1]接收当前轮次数用于日志和Prompt。4. 实验过程与崩溃演化分析实验启动了144轮循环。下面我们分析代码在迭代中是如何一步步“崩溃”的。4.1 早期阶段第1-20轮功能增强与结构膨胀最初的几轮AI的表现堪称“优秀”。它做了许多看似合理的改进添加日志引入了更详细的logging模块替换了print。增强错误处理在文件操作、API调用处添加了更具体的try-except块。代码重构将一些逻辑提取成独立函数增加了docstring。添加新功能例如添加了一个简单的self_test()函数检查API连通性或者添加了代码复杂度计算。此时的问题代码量开始稳步增长从最初的约150行增加到300多行。虽然每个改动单独看都有道理但已经开始偏离“简洁的核心循环”这一初始状态。4.2 中期阶段第21-80轮矛盾与冗余累积随着迭代进行AI开始表现出“健忘症”和“局部优化”的倾向。功能冲突某一轮添加了使用requests库获取天气的功能另一轮又添加了用socket进行端口扫描的演示代码。这些功能彼此无关且都未能完整实现只是留下了函数框架和TODO注释。冗余代码同样的工具函数如safe_read_file被以不同的名字和略有差异的实现添加了多次。Prompt污染AI在返回的代码中有时会将其收到的指令Prompt本身作为注释或字符串字面量错误地包含在代码中导致下一轮AI看到这些残留指令时产生困惑。结构僵化为了处理越来越多的“潜在错误”代码被大量的if-else和异常检查包裹核心逻辑变得难以辨认。典型代码片段第50轮左右def validate_code_syntax(code): # 新增的语法验证函数但实现不完整 try: ast.parse(code) return True, None except SyntaxError as e: return False, str(e) # 注意这里没有处理IndentationError等其他错误 def main_loop_logic(): # ... 之前的功能 ... # 新增的无关功能框架 try: check_network_latency() # 未定义的函数 except NameError: print(Network check not implemented) # ... 更多无关代码 ...4.3 崩溃阶段第81-144轮错误爆发与逻辑解体在80轮之后代码库已经变得臃肿且充满矛盾。崩溃开始以多种形式出现4.3.1 语法错误与运行时错误AI在尝试“优化”时会引入直接的语法错误。例如字符串引号不匹配print(This is a string)。缩进错误在函数定义中混合了空格和制表符或if语句后缺少冒号。未定义变量调用了一个前面轮次生成但已被重写或删除的函数。导入错误添加了import some_obscure_module但该模块并未安装。一旦这类错误被写入agent.py下一轮子进程执行时就会直接因SyntaxError或ImportError而启动失败导致循环中断在我们的实验中引导脚本会记录失败并继续尝试下一轮。4.3.2 逻辑死循环与资源耗尽AI有时会“优化”出一个包含无限循环或递归的函数。例如def optimize_self(): while True: # 模拟“深度思考” pass当reload_and_execute后调用到这样的函数子进程会卡死直到run_experiment.py中的timeout将其终止。4.3.3 自我修改能力的破坏这是最致命的崩溃模式。AI在修改代码时可能会重命名或删除核心函数例如将get_self_code改名为read_my_source但未更新main函数中的调用点。改变函数签名修改modify_code_with_ai的参数导致调用时传参错误。注释掉或删除重载逻辑AI可能认为importlib.reload不安全而直接将其删除或注释导致自我修改循环链断裂。破坏__name__ __main__守卫错误地修改了脚本入口使得代码无法以子进程方式被正确启动。当自我修改的核心机制被破坏后Agent就失去了“进化”能力变成了一堆无法执行下一次迭代的静态代码。4.3.4 代码风格与结构的彻底腐化到实验后期代码文件可能包含多个不同风格的日志配置冲突。重复定义的同名类或函数后者覆盖前者。大量从未被调用到的“僵尸”函数和变量。极其复杂的、试图“管理”整个过程的控制流但其本身逻辑混乱。最终代码的熵增加到无法维持基本运行的程度。实验结束时成功的轮次即能完整执行完一次自我修改并进入下一轮远低于144次。5. 常见问题与排查清单如果你自己运行类似的实验很可能会遇到以下问题。这里提供排查思路问题现象可能原因排查与解决思路子进程立即退出返回码非0新代码存在语法错误SyntaxError。1. 检查agent.py.backup与最新代码对比。2. 在隔离环境中手动python -m py_compile agent.py检查语法。3. 在Prompt中要求AI“确保返回的代码语法完全正确”。子进程超时被终止新代码包含无限循环、死锁或长时间阻塞操作。1. 在run_experiment.py中合理设置timeout参数。2. 分析备份代码查找while True、递归调用等。3. 在Prompt中禁止AI添加可能导致阻塞的代码。AI返回的代码不完整API响应被截断或AI未返回完整代码块。1. 检查modify_code_with_ai函数中的代码提取逻辑是否健壮。2. 增加对响应长度的检查如果太短则视为失败。3. 在Prompt中明确要求“返回完整的文件内容”。模块重载后找不到函数reload_and_execute逻辑错误或函数名被更改。1. 在重载后使用dir(current_module)查看模块属性。2. 使用try-except包裹from agent import ...语句。3. 考虑更稳定的重载机制或放弃重载改为每次由引导脚本全新启动。API调用频繁失败达到速率限制或配额不足。1. 在循环中增加time.sleep间隔。2. 实现简单的退避重试机制。3. 监控API返回的错误信息。代码功能偏离初衷Prompt不够明确AI自由发挥过度。1. 强化Prompt中的约束“必须保持main、get_self_code、modify_code_with_ai、write_new_code这四个核心函数的名称和基本调用关系不变”。2. 要求AI“仅进行微小的改进或bug修复不要添加大型新功能模块”。6. 实验启示与AI辅助编程最佳实践这次实验虽然以代码的混乱崩溃告终但它清晰地揭示了当前AI在自主编程上的局限性并为如何在工程中有效利用AI提供了宝贵经验。6.1 AI作为编码伙伴的定位优秀的局部优化器与代码生成器AI擅长根据清晰指令完成特定、封闭的任务如编写一个函数、重构一段代码、添加注释、修复已知bug。糟糕的长期架构师与产品经理AI缺乏对项目整体目标、技术债务和长期可维护性的宏观理解。在无监督的迭代中它容易陷入局部最优引入冲突和冗余。缺乏一致性和记忆每次调用对于AI都是独立的它无法像人类开发者一样基于之前的全部决策历史进行连贯的思考。6.2 在真实项目中使用AI编码的最佳实践基于实验教训提出以下建议设定清晰的边界使用AI完成具体、离散的任务例如“为这个函数添加错误处理”、“将这段循环改为列表推导式”、“编写这个类的单元测试”。绝对不要将整个项目或一个持续演进的核心文件交给AI进行无监督的迭代修改。明确告诉AI什么不能改比如API接口、数据库Schema、关键的业务逻辑函数名。强化代码审查与测试AI生成的每一行代码都必须经过人工审查。不能假设其正确性。建立强大的自动化测试套件单元测试、集成测试。在应用AI的修改后立即运行测试确保核心功能未被破坏。测试是抵御AI引入“静默错误”的最有效防线。对于关键模块可以考虑采用代码对比工具如git diff仔细检查AI所做的每一个更改。设计稳健的交互流程迭代式交互不要一次性要求AI做太多改动。采用“小步快跑”的方式每次提出一个小的改进点审查通过后再进行下一个。提供上下文在Prompt中提供足够的上下文信息如相关的类定义、函数签名、错误信息等这能显著提高AI生成代码的准确性。使用版本控制每次让AI修改代码前先提交当前状态到Git。如果AI的修改导致问题可以轻松回滚。永远不要在没有备份的情况下让AI直接覆盖生产代码。工程化集成可以考虑开发一些工具将AI代码生成作为开发工作流中的一个受控环节。例如一个脚本可以1) 从Git拉取代码2) 针对某个文件向AI发起特定修改请求3) 将AI的返回生成一个Pull Request4) 触发CI/CD流水线运行测试。只有测试通过该PR才可被合并。6.3 对未来AI编程助手的展望尽管当前有局限但实验也指明了方向更强的上下文感知未来的AI编码助手需要能理解项目的完整上下文、依赖关系和技术栈。目标驱动的规划能力AI需要能够将高级目标如“提升性能”分解为一系列具体、有序、不冲突的代码修改步骤。集成测试与验证AI工具应能自动运行相关的单元测试或在生成代码时进行某种形式的“推理验证”确保修改不会破坏现有契约。这次让AI Agent自我修改144轮的实验就像一场观察代码在“自由进化”下命运的加速实验。它生动地展示了在没有明确目标、严格约束和持续验证的情况下即使是最智能的代码生成工具也会迅速将系统引向混乱。对于开发者而言真正的价值不在于追求全自动的代码生成而在于将AI作为一位强大的、但需要严格监督的副驾驶。我们应利用其强大的模式识别和代码生成能力同时用人类的架构思维、系统观和严谨的工程实践来牢牢握住方向盘。只有这样人机协作才能走向既高效又可靠的正轨。