在人工智能从短时问答走向长时任务执行的潮流中,如何让大型语言模型(LLM)在数小时甚至数十小时内持续、稳定地完成复杂工程任务,成为研究与工程实践的核心议题。Claude Sonnet 4.5能够在接近30小时的持续会话中迭代出类似Slack的聊天应用,其背后并非偶然的"超强记忆",而是一组工程化的提示设计与系统约束共同作用的结果。本文围绕可复现的模式与实践,剖析这种长时自治能力的关键要素,并讨论其局限、风险与应用场景。 要使单次会话跨越成千上万行代码而不崩溃,首要的是将"大代码块"转化为可持续的工件(artifact)。当模型生成超出某个长度阈值的代码段时,系统要求把它作为独立工件保存,而不是简单嵌入在对话里。这种设计把代码库变成附加式、可追加的结构,每次迭代只需要在工件上做增量修改或追加新的工件,从而避免上下文长度溢出和回复截断导致的丢失。
把文件化输出与严格的导入/依赖规则结合起来,模型可以像人类工程师一样逐步搭建模块:前端组件、后端路由、数据库模式以至构建脚本,皆以独立工件形式存在并由生成策略统一管理。 与工件策略配合的是明确的"更新与重写"工作流。工程化的提示将小改动(update)与结构性更改(rewrite)严格区分,并限定小改动的规模与频次,例如单次diff不超过若干行、位置限制与次数上限。通过这种约束,模型在长周期迭代中不会反复大幅重构已确立的模块,而是倾向于安全的增量演进。这种策略降低了合并冲突和隐性回归的概率,使得数万行代码可以在多轮交互中渐进积累。 长时运行的交互式UI尤其容易因为运行时持久化策略不当而变得脆弱。
为此,系统会强制运行时约束:禁止将关键业务状态写入浏览器的localStorage或sessionStorage,要求优先采用内存状态管理或可控的短期存储;在某些沙箱环境下禁用HTML表单或iframe中的特定功能,防止外部环境的不可预测性破坏自动化测试与迭代。通过对运行时边界的明确限定,生成的界面在连续测试与自动化工具的包围下能保持稳定,避免在长时间的自我迭代中因环境差异而失效。 模型选择何种依赖与打包方式同样决定了长时自治的可行性。现实工程中,工具链漂移(toolchain drift)会让自动生成的代码"活不长"。相应地,提示会限定可用的工件类型、导入规则与依赖来源,优先推荐成熟、文档完备且运行环境友好的技术栈(例如单文件HTML、通过CDN引入的前端库、轻量后端框架与REST API模式)。这种"可预测的依赖面"让模型不用为构建、打包、运行环境做过多假设,从而将注意力放在业务逻辑本身。
完成工程任务往往不仅仅是写代码那么简单,还需要进行大量的信息检索与设计决策。为此,提示语言通常会引入一种研究节奏:定义一个Research模式,限定每次研究允许的工具调用次数与研究-构建的循环步骤。这种模式把"查资料""设计协议""验证假设"与"写代码"分离开来,鼓励模型先进行短轮次的探究,再回到构建阶段。研究节奏降低了盲写代码的概率,也使模型能够在长时间会话中保持对外部信息的有序访问。 工具使用的治理同样关键。与让模型"猜测"相关事实不同,提示要求模型在未确定时使用工具进行验证。
通过对工具调用行为的治理,系统可以有效减少因凭空假设导致的错误路径,从而在长周期迭代中节约大量回滚成本。工具治理还包括调用频率限制、调用内容格式约束与结果集的可信度评估,以便在多轮工具交互后,将高质量证据纳入后续决策。 另一个重要模式是将"思考"和"执行"明确分离。提示鼓励模型在执行前进行充分的规划与澄清(deliberation),并在用户或上层控制器确认后进入执行阶段(action)。这一分离避免了半成品式的代码肆意生成,也保护了已生成工件免遭冲动式重写。对长时任务而言,规划-执行的模式能保持整体目标一致性,并为每轮变更建立可审计的动机链路。
持续进展的核心在于有反馈的计划循环。借鉴Voyager和Generative Agents等体系结构,提示把记忆(state)与工具使用结合,形成"提议代码 - 执行 - 学习"的闭环。每一轮执行不仅产生文件与测试结果,还会以结构化方式被回写为下一轮计划的输入。通过反思性机制,模型能够修正设计错误、积累经验并形成越来越稳健的实现策略,从而让一个最初的高层蓝图在几十个小时内成长为完整的系统。 保持会话一致性的另一个工程细节是强制在每次调用中附带完整的会话状态与相关上下文。尤其是对聊天应用类项目,消息历史、存在性(presence)信息、UI状态和测试日志需要在每次生成时同步给模型。
尽管这会带来上下文长度的压力,但结合工件化策略与差分更新规则,系统能在保证状态完整的前提下避免重复传输大量静态代码,从而兼顾连贯性与效率。 长时运行不可能没有错误,良好的错误仪式(error rituals)与上下文清理机制是必需的。提示会要求模型在遭遇编译、集成或运行时错误时执行一套约定动作:精炼错误上下文、提炼核心失败原因、尝试有限次的自动修复并记录失败案例以供人工回顾。这样的流程能把偶发的集成失败转化为经验样本,帮助模型在随后的步骤中避开相同陷阱。 在技术选型方面,提示通常建议使用"熟悉且文档完备"的堆栈。大模型的知识边界意味着它们更擅长于主流框架与模式。
因此,采用React、Flask、REST等被广泛使用并有充足范例的技术,可显著提高生成代码的正确率与可维护性。可预测的架构还能使自动化测试与静态分析工具更容易落地,进一步提高长时自治的可靠性。 更具实验性的做法是允许"模型内调用模型"的自我协作。工件可以被设计为运行时通过fetch等方式调用LLM API,从而生成辅助开发工具(如代码补全器、迁移脚本或测试生成器)。这种"Claude-in-Claude"模式在工程上等同于让模型写一个小巧的开发助手,从而在长时构建过程中提供即时反馈与自动化辅佐。但必须注意安全与成本,在开放调用外部API时需严格控制权限与调用频次。
为了便于自动化验证与回归测试,提示还会在必要场景下强制输出机器可解析的格式,例如JSON-only的接口或结构化日志样式。结构化输出让下游脚本能在无人监控的长时间运行中对模块进行自动化验证,快速识别功能回归或集成问题,从而支持连续多小时的无人化迭代。 把上述模式汇合在一起,能够构建出支持长时自治的工程系统:工件化输出为大代码库提供持久层;严格的更新策略避免无序重写;运行时与依赖约束保证环境稳定;研究节奏与工具治理降低决策风险;思考与执行分离维护质量;计划 - 执行 - 学习循环实现累积进化;结构化状态与错误仪式确保可审计性与鲁棒性。这些工程化手段为LLM在长时任务中的可持续工作提供了必要的边界与流程。 然而,这并不意味着没有局限或风险。首先,长时间的自动化构建会产生大量低级或重复性错误,尤其是在未充分设计测试覆盖的情况下。
自动修复机制可能掩盖深层设计缺陷,导致技术债务的隐匿累积。其次,模型依赖预先定义的提示与约束,若这些提示设计不当,反而可能把模型限制在低效或错误的路径上。再次,允许模型在运行时调用外部API或在工件中嵌入可执行脚本会带来安全风险,必须严格配置最小权限与审计机制。 从成本角度看,长时运行意味着大量推理调用与工具调用,可能带来显著的计算与API费用。实践中需权衡自动化深度与成本投入,例如在关键路径使用人工复核或将高频调用替换为缓存机制,以降低总体支出。 对于希望在自家项目中借鉴这些模式的工程团队,实用建议包括:首先,把生成物结构化并持久化为独立工件,结合版本控制与差分更新策略;其次,为模型定义明确定义的工作模式(研究、计划、执行、验证),并在提示中把每种模式的输入输出格式标准化;第三,限制可用依赖与运行时API,优先使用成熟、稳定的库与CDN资源;第四,在自动化测试与回归检测上投入足够资源,确保每次变更都有可自动执行的验证路径;最后,把安全防护和成本控制放在设计早期,避免"自动化无限制扩张"带来的权限与费用灾难。
展望未来,随着模型能力与推理效率的提升,长时自治的应用场景会从原型构建逐步扩展到更复杂的系统集成、运维自动化与跨团队协作。更先进的长期记忆机制、分层自治体(agent-of-agents)架构与更细粒度的工具治理将提升系统的鲁棒性与可控性。但无论技术如何进步,工程化的流程、清晰的边界与人为审查仍将是保障质量与安全的基石。 总结而言,Claude Sonnet 4.5能够持续数十小时构建大规模应用,不是靠单一"超强记忆"或"黑箱能力",而是依赖一组相互配合的提示工程与系统约束:通过工件化保存大代码、以更新/重写区分变更策略、限定运行时与依赖面、执行研究节奏与工具治理、分离思考与执行并建立反馈学习循环。把这些模式融入工程实践,能显著提高大型语言模型在长周期任务中的产出质量与稳定性,同时也提醒我们重视测试、成本与安全等现实问题。对于希望利用LLM进行长时开发的团队而言,关键在于把"自治"的幻想转化为可审计、可控制的工程流程,从而把模型的创造力与工程可靠性有效结合。
。
