1. 项目概述当语言模型学会“自我编程”最近在折腾大语言模型LLM应用时我一直在思考一个核心问题我们给模型一个任务它生成一段代码或指令然后我们手动执行。这个“生成-执行”的循环里人始终是那个关键的“执行器”和“调试器”。有没有可能让模型自己完成这个闭环这就是“Self-Programmed Execution”SPE自我编程执行试图回答的问题。简单来说SPE旨在让语言模型智能体Language-Model Agents不仅能生成解决问题的程序还能自主地、迭代地执行和调试这些程序直到任务完成。这个概念听起来有点抽象但它的潜力巨大。想象一下你告诉一个数据分析助手“帮我分析上个月的销售数据找出异常点并生成报告。”传统的智能体可能会生成一段Python代码然后卡住等你来运行。而具备SPE能力的智能体会自己生成代码在安全的沙箱里执行检查输出是否符合预期如果发现错误比如缺少某个库它会自动修改代码比如加上import pandas然后再次尝试最终把整理好的报告交给你。整个过程你只需要下达初始指令。为什么SPE如此重要因为它是实现真正“自主智能体”的关键一步。目前的AI应用大多停留在“建议”层面而SPE推动其走向“执行”层面。这对于自动化工作流、复杂问题求解、甚至是AI驱动的科学研究都至关重要。它模糊了“编程”与“使用程序”的边界让语言模型从一个被动的文本生成器转变为一个能主动操作环境、解决问题的“行动者”。2. SPE的核心原理与架构设计2.1 从“生成代码”到“执行循环”的范式转变传统的语言模型应用流程通常是线性的用户指令 - 模型思考/规划 - 生成代码/动作 - 人工执行与验证。SPE的核心在于将这个流程变成一个由模型自身驱动的闭环用户指令 - 模型生成可执行程序 - 在安全环境中自动执行 - 观察执行结果 - 基于结果进行反思与调试 - 迭代生成新程序。这个循环的驱动力是一个关键的反馈机制。模型不仅需要理解任务还需要理解执行环境的状态比如文件系统里有什么、当前工作目录、已安装的包、上一次执行的结果成功、失败、报错信息、输出内容并据此做出下一步的决策。这要求模型具备更强的推理能力、对编程语言语义的深度理解以及对执行上下文的持续跟踪能力。2.2 SPE系统的关键组件拆解一个典型的SPE系统架构通常包含以下几个核心组件任务解析与规划模块接收用户自然语言指令将其分解为一系列可执行的子目标或步骤。这个模块需要理解任务的最终目的而不仅仅是表面指令。例如“整理文档”可能意味着“读取所有.txt文件 - 提取标题 - 按日期排序 - 生成摘要文件”。代码生成器这是语言模型的核心能力所在。根据当前任务步骤和上下文包括历史执行记录生成符合目标环境如Python解释器、Shell、特定API语法的可执行代码。这里的挑战在于生成的代码必须是具体、完整且考虑到当前环境状态的。安全执行沙箱这是SPE得以实现的基石。所有由模型生成的代码都必须在一个严格受限的沙箱环境中运行以防止其对真实系统造成破坏如删除文件、安装恶意软件、无限循环。沙箱需要提供对文件系统、网络、系统调用等资源的受控访问。Docker容器是一个常见的选择。执行结果观察器捕获代码执行的所有输出包括标准输出stdout、标准错误stderr、返回值以及执行过程中对环境状态的改变如创建了哪些新文件。这些信息需要被结构化地记录下来作为反馈给模型的重要输入。反思与调试模块这是SPE的“智能”所在。模型需要分析执行结果。如果执行成功且输出符合预期则进入下一步。如果失败或输出异常模型需要像程序员一样进行调试分析错误信息NameError,FileNotFoundError等推断错误原因并规划如何修复代码。这个过程可能涉及查阅“记忆”中的知识如何导入模块、正确的函数用法或向用户请求澄清。状态管理与记忆系统需要维护一个贯穿整个任务执行周期的状态。这包括原始任务描述、已完成的步骤、当前步骤的目标、执行环境的最新快照、以及历史尝试的记录尝试了哪些代码结果如何。这个状态是模型进行每一步决策的上下文依据。2.3 为什么Lisp语言与SPE理念高度契合在相关讨论和实践中Lisp尤其是其方言如Scheme, Clojure经常被提及作为SPE的理想实验语言。这并非偶然其背后有深刻的逻辑同像性Lisp代码本身就是用Lisp的数据结构列表来表示的。这意味着程序可以轻松地生成、修改和操作其他程序或自身。这种“代码即数据”的特性使得在Lisp中实现“自我修改”或“自我生成”的程序在语法层面变得异常简单和自然。模型生成一段Lisp代码本质上就是生成一个列表系统可以很容易地解析、评估它。强大的元编程能力Lisp设计之初就考虑了元编程。宏Macro系统允许开发者创建新的语法形式这为模型生成复杂但结构良好的代码提供了高级抽象工具。模型可以学习使用或组合现有的宏来构建程序而不是从头生成每一行原始语法。简洁一致的语法Lisp的语法极其简单前缀表达式大量使用括号减少了模型在语法细节上犯错的概率。相比于Python或JavaScript中复杂的语法规则缩进、分号、各种括号的混合使用Lisp的语法噪音更小让模型能更专注于程序逻辑本身。实时交互与增量开发传统的Lisp开发环境如SLIME, CIDER强调“读取-求值-打印”循环。这与SPE的“生成-执行-观察”循环在哲学上高度一致。SPE系统可以看作是一个自动化的、由模型驱动的REPL。注意虽然Lisp在理论上非常优雅但在实际构建面向大众的SPE应用时Python仍然是更务实的选择因为它有极其丰富的库生态和更广泛的开发者基础。不过理解Lisp的特性有助于我们设计出更通用、更强大的SPE架构其思想可以借鉴到其他语言的实现中。3. 实现SPE智能体的核心技术与实操要点3.1 环境搭建构建安全的执行沙箱安全是SPE的第一要务。绝不能允许模型生成的代码在宿主机上肆意运行。方案选择Docker容器沙箱我推荐使用Docker作为执行沙箱。它为每个任务或每次执行创建一个全新的、隔离的容器实例。# Dockerfile示例一个基础的Python执行环境 FROM python:3.11-slim WORKDIR /workspace # 限制不必要的系统权限 RUN apt-get update apt-get install -y --no-install-recommends \ gcc python3-dev \ rm -rf /var/lib/apt/lists/* # 以非root用户运行 RUN useradd -m -u 1000 agent chown -R agent:agent /workspace USER agent CMD [python3]关键配置与安全策略资源限制在运行容器时必须通过--memory,--cpus等参数限制CPU和内存使用防止代码陷入死循环耗尽资源。网络隔离默认使用--network none禁用容器网络访问除非任务明确需要如下载包。如需网络可使用白名单机制或仅允许访问特定内部API。文件系统隔离将宿主机的一个临时目录以只读或特定读写权限挂载到容器的/workspace作为任务的工作空间。确保容器无法访问宿主机的其他目录。超时控制为每次代码执行设置严格的超时如30秒超时即强制终止容器。只读根目录使用--read-only标志运行容器防止对系统文件的修改。所有必要的写入都定向到挂载的/workspace卷。实操命令示例# 启动一个执行沙箱运行代码然后清理 docker run --rm \ --memory512m \ --cpus1.0 \ --network none \ --read-only \ --tmpfs /tmp:rw,size64M \ -v /tmp/task_123:/workspace:rw \ -w /workspace \ my-python-sandbox \ timeout 30 python3 -c $generated_code这个命令创建了一个内存限制512MB、无网络、根目录只读的容器在/workspace目录下执行生成的Python代码并设置30秒超时。3.2 与语言模型的交互设计高效的提示工程让模型扮演好“程序员”和“调试员”的角色提示词的设计至关重要。提示词需要提供充足的上下文和明确的指令格式。一个基础的SPE循环提示词结构可能如下你是一个自主编程智能体。你的目标是通过编写和执行代码来完成用户任务。 你拥有一个安全的Python沙箱环境。环境初始时/workspace目录下可能有用户提供的文件。 ## 当前任务 {用户原始指令} ## 当前状态与上下文 - 工作目录/workspace - 目录内容{当前工作空间的文件列表} - 上一步执行结果{上一步代码的执行结果摘要包括输出、错误或文件变更} - 剩余目标{根据任务分解的剩余步骤} ## 你的行动 请根据以上信息决定下一步操作。你必须从以下选项中选择一种并严格按照对应格式输出 1. **生成代码**如果你认为下一步是编写并执行代码。 json {action: run_code, code: 你的Python代码字符串必须是完整可执行的代码块} 2. **任务完成**如果你认为所有目标均已达成可以提交最终结果。 json {action: finish, summary: 任务完成总结, output_files: [/workspace/report.txt, ...]} 3. **请求澄清**如果任务描述模糊或遇到无法解决的问题。 json {action: ask_user, question: 你的具体问题} 请只输出JSON不要有其他任何内容。提示词设计的核心技巧结构化输出强制模型以严格的JSON格式回应便于程序解析。这比让模型自由发挥文本稳定得多。提供丰富上下文将环境状态、历史结果作为输入的一部分让模型的决策基于事实而非臆想。明确行动空间将模型的可选行动生成代码、结束、提问定义清楚限制其行为范围提高可控性。迭代细化在模型多次尝试失败后可以在提示词中加入“反思”部分要求它先分析之前失败的原因再生成新代码。3.3 状态管理与执行循环的逻辑实现SPE系统的中枢是一个状态机它驱动着“生成-执行-观察-决策”的循环。下面用伪代码展示核心循环逻辑class SPEAgent: def __init__(self, llm_client, sandbox): self.llm llm_client self.sandbox sandbox self.state { task: , workspace_files: [], history: [], # 记录每一步的代码、结果 current_goal: } def execute_task(self, user_task): self.state[task] user_task self.state[workspace_files] self.sandbox.list_files(/workspace) self.state[current_goal] user_task # 初始目标就是整个任务 max_steps 20 for step in range(max_steps): # 1. 构建提示词调用LLM获取决策 prompt self._build_prompt() llm_response self.llm.generate(prompt) action self._parse_response(llm_response) # 解析出JSON动作 # 2. 根据动作类型处理 if action[type] run_code: code action[code] # 3. 在沙箱中执行代码 execution_result self.sandbox.run_python_code(code) # 4. 更新状态记录历史更新文件列表 self.state[history].append({ step: step, code: code, result: execution_result }) if execution_result[success]: self.state[workspace_files] self.sandbox.list_files(/workspace) # 可能还需要根据代码逻辑和结果更新current_goal # 循环继续模型将在下一步收到本次执行结果 elif action[type] finish: return self._compile_final_output(action) elif action[type] ask_user: # 中断循环将问题抛给用户获取答案后更新state并继续 user_answer get_user_feedback(action[question]) self.state[user_clarification] user_answer continue raise Exception(达到最大步数限制任务未完成) def _build_prompt(self): # 基于当前state构建详细的提示词 # 包含任务、文件列表、上一步结果、历史尝试等 ...循环控制的关键点步数限制必须设置最大迭代次数如20步防止任务陷入无限循环。结果解析需要仔细解析沙箱的执行结果区分成功输出、运行时错误、编译错误、超时等不同情况并将这些信息清晰地反馈给模型。目标更新对于复杂任务模型在完成一个子目标后应该能自动将current_goal更新为下一个子目标。这可以通过在提示词中让模型自己总结“剩余目标”或者在代码中预设任务分解逻辑来实现。4. 高级策略与性能优化实战4.1 让智能体学会“使用工具”函数调用集成纯粹的代码生成执行虽然强大但有些操作通过调用预定义好的函数工具会更安全、更高效。例如操作数据库、发送邮件、调用特定API。我们可以将SPE与LLM的“函数调用”Function Calling能力结合。实现方式在提示词中除了“生成代码”这个动作增加一个“调用工具”的动作。同时为模型提供一个工具清单。## 可用工具 你可以调用以下预定义工具这比编写原始代码更安全便捷 - query_database(sql_query: str) - List[Dict]: 执行SQL查询返回结果列表。 - send_email(to: str, subject: str, body: str) - bool: 发送邮件。 - get_webpage(url: str) - str: 安全地获取网页内容。 ## 你的行动新增选项 ... 4. **调用工具**如果你认为使用现有工具能更高效地完成子目标。 json {action: call_tool, tool_name: query_database, arguments: {sql_query: SELECT * FROM sales WHERE date 2023-10-01}} 系统收到call_tool动作后不是执行代码而是调用对应的本地函数并将函数返回的结果作为“执行结果”放入上下文供模型下一步决策使用。这大大扩展了智能体的能力边界同时保持了安全性。4.2 长期记忆与技能库避免重复造轮子一个高效的SPE智能体应该能从历史经验中学习。我们可以为它建立两个“记忆”系统短期会话记忆即当前任务的状态管理state记录本次任务中的所有尝试。长期技能记忆一个向量数据库存储历史上成功解决过的问题及其对应的代码片段、提示词和上下文。当新任务到来时系统可以先在技能记忆库中进行语义搜索寻找类似的任务和解决方案。如果找到高度匹配的可以直接复用或微调其中的代码策略从而显著减少LLM的调用次数、提升解决速度并提高成功率。例如智能体之前成功解决过“读取CSV文件并计算列的平均值”。当新任务是“读取JSON文件并计算某个字段的总和”时系统可以从记忆库中检索到相关的“文件读取”和“数据聚合”模式引导模型更快地生成正确代码。4.3 分层任务分解与规划对于非常复杂的任务期望模型一次性生成完整解决方案是不现实的。我们需要引入一个“规划器”模块。这个模块可以由另一个LLM驱动专门负责将模糊的用户指令分解成一个清晰的、有序的子任务列表DAG有向无环图。用户指令“分析销售数据找出表现最差的三个产品类别并给销售团队写一份改进建议邮件。” 规划器输出 1. 子任务A定位并加载销售数据文件CSV/Excel。 2. 子任务B清洗数据处理缺失值。 3. 子任务C按产品类别分组计算总销售额和环比增长率。 4. 子任务D排序并找出增长率最低的三个类别。 5. 子任务E根据分析结果起草邮件正文。 6. 子任务F使用邮件工具发送邮件。然后SPE核心循环将依次处理每个子任务。每个子任务都可以视为一个独立的SPE循环。规划器还可以在遇到失败时进行动态重规划调整子任务顺序或策略。5. 常见问题、故障排查与避坑指南在实际构建和运行SPE系统时你会遇到各种各样的问题。以下是我从多次实践中总结出的核心挑战和解决方案。5.1 模型生成的代码不安全或不稳定这是最常见也最危险的问题。问题表现代码尝试执行os.system(rm -rf /)、import未知的第三方库、陷入无限循环。排查与解决强化沙箱如前所述使用Docker并配置最严格的权限无root、无网络、只读根目录、资源限制。这是第一道也是最重要的防线。代码静态分析在执行前对生成的代码进行简单的语法和安全扫描。可以使用Python的ast模块解析抽象语法树禁止某些危险的节点类型如Import,Call到某些危险函数eval,exec,os.system。但要注意静态分析很难覆盖所有情况。白名单机制对于需要网络或特定库的任务采用白名单。例如只允许import一个预先在容器中安装好的库列表如pandas,numpy,requests。可以在提示词中明确告知模型“你的环境已预装以下库...请只使用这些库。”超时与监控执行时必须带超时并监控资源使用。一旦超时或内存超限立即终止进程。5.2 模型陷入无效循环或逻辑错误模型可能会在一个错误上反复尝试相似的错误方案。问题表现连续多次生成语法错误类似的代码或者反复尝试读取一个不存在的文件路径。排查与解决丰富错误反馈不要只把stderr原始文本给模型。将错误信息结构化、清晰化。例如将FileNotFoundError: [Errno 2] No such file or directory: data.csv转化为更易理解的反馈“代码尝试打开文件data.csv但失败因为该文件不存在于工作目录中。当前目录下的文件有report.txt,config.json。”引入反思步骤在连续失败2-3次后修改提示词强制模型进入“调试模式”。例如“上述尝试均未成功。请先详细分析最近三次失败的根本原因列出所有可能的问题然后制定一个新的、不同的解决方案。”限制尝试次数对每个子任务设置最大尝试次数如5次。超过次数后系统自动 fallback 到请求用户帮助避免无限消耗资源。提供更多上下文有时模型犯错是因为不了解环境全貌。确保在每次提示中都包含完整、最新的工作空间文件列表。5.3 任务分解与规划不合理规划器可能产生不可行或顺序错误的子任务。问题表现规划器要求“先分析数据”但“加载数据”的任务却失败了子任务之间存在未声明的依赖关系。排查与解决人工设定任务模板对于常见任务类型数据分析、文件处理、信息汇总可以预先定义好任务模板和步骤减少规划器的负担。验证与回溯每完成一个子任务检查其输出是否满足下一个子任务的预期输入。如果不满足触发回溯机制重新评估规划或执行上一个任务。让规划器更具体提示规划器时要求其输出每个子任务的输入预期和输出描述。例如“子任务1输入-/workspace/raw_data.xlsx输出-一个名为cleaned_data.csv的清洗后文件”。这样便于系统自动化验证。5.4 性能与成本问题频繁调用大模型和启动Docker容器开销很大。问题表现处理一个简单任务耗时过长API调用费用高昂。排查与解决缓存机制对相同的提示词或类似的代码生成请求进行缓存。如果模型生成了一段用于读取CSV的代码并且成功了可以将其缓存。下次遇到“读取文件”的类似意图时可以直接复用或微调无需重新生成。使用轻量级模型不是所有步骤都需要最强的模型。任务分解、简单的代码生成或错误分析可以尝试使用较小的、更快的模型如7B/13B参数的开源模型。只有在复杂推理和调试时才调用GPT-4等大型模型。容器复用对于连续的多步代码执行如果环境变化不大如只是安装了某个包可以考虑复用同一个Docker容器而不是每一步都启动新的。但这需要仔细管理容器状态避免污染。异步执行如果任务中的多个子任务相对独立可以尝试并行执行但要注意资源竞争和状态管理。构建一个稳定可靠的SPE系统是一个在“模型能力”、“系统安全”和“执行效率”之间不断权衡和迭代的过程。从一个小而精的用例开始比如“自动化处理特定格式的日志文件”逐步增加复杂性和自主性是避免早期陷入泥潭的最佳实践。这个领域正在快速发展每一次实践中的踩坑和填坑都是向着更智能、更自主的AI未来迈进了一步。