AI News HubLIVE
站内改写4 分钟阅读

自我改进的工程:AI 系统的线束设计

本文探讨了递归自我改进(RSI)的概念,重点介绍了现代AI系统中“线束”(harness)工程的作用。线束是基础模型周围的系统,负责编排执行、管理上下文、调用工具和持久化状态。文章分析了三种设计模式:工作流自动化、文件系统作为持久内存、子代理和后台作业,并以编程代理线束为例展示了具体实现。进一步讨论了上下文工程(ACE 和 MCE)以及元线束(Meta-Harness)的优化策略,预测了RSI的近期路径:线束工程将朝着元方法论演进,使线束系统本身成为优化目标。

递归自我改进(RSI)的概念源自I. J. Good在1965年定义的“超智能机器”,即一种能在所有智力活动中超越人类并设计出更优机器以自我改进的系统。Yudkowsky在2008年将“递归自我改进”具体化为一个反馈循环:AI利用其当前智能来改进产生智能的认知机制。在现代AI中,这种反馈循环可能直接体现为模型重写自身权重,或更广泛地,模型改进训练管道和部署系统,从而催生性能更优的后续模型,在经济上重要的任务中表现出色。前沿实验室(如Anthropic和OpenAI)的研究开发速度已呈急剧加速之势。

显式提及“部署系统”的原因在于,原始模型与现实世界之间的接口层与模型的原始智能(即预训练后的评估)同样重要。成功的编程代理产品(如Claude Code和Codex)展示了线束(harness)作为AI部署关键组件的价值。线束是围绕基础模型构建的系统,负责编排执行,决定模型如何思考、规划、调用工具、行动、感知和管理上下文、存储工件以及评估结果。本文将聚焦于线束工程的研究及其对RSI的贡献,涵盖自动研究、自我改进代理和进化程序搜索等领域的工作。

线束设计模式

与早期代理框架(“代理=LLM+记忆+工具+规划+行动”)相比,线束工程额外包含工作流设计(如循环工程)、评估、权限控制和持久状态管理。它不再仅仅是提示模板,而是更接近运行时和软件系统设计:模型如何观察、行动、记忆、自我检查并改进。设计应刻意保持简单和通用,以促进泛化,并借鉴现有软件工程实践以受益于预训练知识。线束与操作系统有强烈类比:应封装复杂逻辑,同时保持接口简单。同时,配置、工具接口等协议可能逐步实现行业标准化。

模式1:工作流自动化

定义一个模型可操作、测试和迭代的工作流是自动化的关键设计。Karpathy的autoresearch仓库是一个简洁示例。常见工作流遵循目标导向的循环:规划、执行、观察/测试、改进,直至达成目标。过程中可能主动向用户请求澄清任务规范或执行偏好。简化的Codex代理循环:代理调用工具,工具响应影响模型的下一次生成。工作流图强调模型分析自身轨迹和失败案例,在“代理运行时”中迭代,而非静态提示模板。

模式2:文件系统作为持久内存

长周期代理系统中反复出现的模式是对丰富状态和工件的简单控制。线束不应将整个工作流和所有日志放入上下文,而应将持久状态保存在文件中。在长周期代理部署中,实验日志、代码差异、论文摘要、错误追踪和过去轨迹等工件常常远超模型训练的上下文窗口。学习通过文件系统(常用bash命令)读写和编辑是LLM的基础技能,因此以文件形式管理持久内存自然受益于核心模型能力的提升。

模式3:子代理和后台作业

线束可以生成多个子代理并行执行并监控后台作业。当主代理需要搜索多个假设、并行运行实验或委派孤立子任务而不污染主上下文时,此模式尤其实用。父代理需要一个轻量级进程管理器:启动作业、检查日志、取消失败任务、将结果合并回主线程。关键设计是使并行性显式且可审查。子代理输出若仅存在于瞬态聊天上下文中,则很快过时且不可见;若存储为文件、日志和状态记录,则模型可在中断后恢复并对其执行历史进行推理。

案例:编程代理线束

主流编程代理的核心接口已在Claude Code、Codex、OpenCode和Cursor风格代理中趋于稳定。它们通常使用如下循环:

  • 工具组定义:文件系统(发现、读取、修改)、Shell执行、IO(lsp、git)、外部上下文(MCP、技能)、Web搜索、工件(读取文档、生成HTML)、后台进程(Cron)、代理委派等。

线束层 vs. 核心智能?

很难预测RSI未来在多大程度上依赖线束工程,但近期路径不太可能始于模型直接重写权重。我预测的实用近期路径是:线束工程将朝着元方法论演进——即改进获取更好答案的机制,而非仅仅是改进答案本身。线束系统本身成为优化目标,减少启发式规则,增加通用机制。成熟线束使自动研究成为模型自我改进的循环,更智能的模型则防止线束过度工程化,保持系统可持续性。最终,许多线束改进可能内化到核心模型行为中,但与外部上下文和工具的接口应保留。提示工程已展现了这种模式的柔和版本:手动提示技巧随着指令调整和模型推理改进而变得不那么核心,但指定目标、约束、上下文和评估的需求并未消失。

线束优化

线束系统中被优化的对象大致演进为:指令提示 → 结构化上下文 → 工作流 → 线束代码 → 优化器代码。随着模型变得更智能、更强大,我们转向更复杂的目标和更通用的方法。

上下文工程

简单地将所有工具响应和模型生成追加到上下文会随代理任务时间增长而迅速失控。上下文管理是为LLM构建更结构化和简洁上下文并管理持久状态的一层。长上下文研究会持续进步,但当前长上下文智能与上下文工程常常交织。

代理上下文工程(ACE; Zhang et al. 2025)将上下文视为不断演化的剧本,而非不断加长的提示。它包含三个组件:生成器(产生任务轨迹,引用要点)、反射器(从成功和失败轨迹中提炼洞察)和策展人(以增量、条目化条目更新结构化上下文)。为防止迭代重写中的上下文崩溃和简洁性偏差,ACE的关键设计是策展人不会重写完整提示文本,而是输出结构化、条目化的要点集合(标识符,描述),这些要点通过确定性逻辑合并到结构化上下文日志中,并定期精炼和去重。

元上下文工程(MCE; Ye et al. 2026)将机制(如何管理上下文)与工件内容(上下文中的内容)分离,在元优化层面运行技能进化,在基础层面运行上下文优化。MCE不强制执行ACE那样的启发式规则,而是使用自由形式的技能存储任务关键知识,并迭代演进技能和技能条件上下文。技能数据库追踪历史技能、上下文函数和评估指标。元级代理执行代理交叉,创建新技能;基础级上下文工程师执行技能并学习上下文函数。实现中,上下文函数实例化为专用目录中的文件集合,包括静态(skill.md)和动态(上下文和数据回滚)组件。

元线束(Meta-Harness; Lee et al. 2026)将优化又提升一层:被优化的对象是决定和优化哪些信息应存储、检索和呈现给模型的代码。其元循环优化算法中,提议者负责创建新线束配置,评估者并行评分,进化者通过交叉和变异生成改进版本。该方法将线束设计视为一个可搜索的空间,使系统能够自动发现更高效的交互模式。

总之,线束工程在RSI中扮演核心角色,提供从手动提示向自主、自我改进系统演进的桥梁。随着模型能力增强,线束本身变得越来越智能和自适应,最终可能内化为模型行为的一部分,但与外部世界的接口将持续存在。