如果你用 Claude Code 或 Codex 在真实项目里改过 Bug，多半撞过这堵墙：前 3 轮惊艳，第 10 轮崩盘——Agent 把第 2 轮已经修好的 Bug 又改了回去，会话塞满报错和垃圾日志，你不得不手动切断新建会话，再手动用自然语言把过去一小时拼凑给新 Agent。

Loom 想解决的就是这个「局部失忆」。它是 Valkor 联合浙江大学智能计算与软件研究中心、UCL 软件工程团队开源的 Delivery Harness（交付马甲），给编程智能体加一层独立结构化的工程状态层。

代码仓库：github.com/valkor-ai/loom

Loom 是什么

更直白的类比：Loom 是给单机游戏引入「自动存档点」的交付马甲，把一次复杂的软件交付拆解成结构化、可随时恢复的状态链。

它解决的核心问题不是「怎么让模型写更多代码」，而是「长任务如何在真实工程流程中持续推进、可验证、可恢复地走完」。

当 Agent 运行测试失败时，Loom 不会把失败当成一段终端文本丢进聊天上下文，而是捕捉并结构化为一个独立于聊天记录存在的待办状态。

Bug 不会被淹没

失败变成下一步行动的「强约束」，Agent 不可能在后续对话里打个哈哈就把这个 Bug 漏掉。

多 Agent 零成本接管

你前 5 轮可以用 Claude 4.6 Sonnet 改逻辑，第 6 轮换成 GPT-5.5 跑测试。新 Agent 接入 Loom 后，只要读取结构化的「交付状态链」，就能瞬间知道：

• 自己是谁、在哪、刚才改了什么
• 下一步该修哪个 Bug
• 哪几个文件的 Diff 已经定型不能再乱动

不需要重新阅读冗长的聊天历史，直接原地「接管比赛」。

为什么靠卷 Context Window 治不好长任务

把长任务失败归咎于 Context Window 不够长，在真实工程逻辑上是个伪命题。

信息量大不等于可靠性高。把几万行编译日志、多轮 Diff、测试输出一股脑塞进上下文，只会让会话充满杂音，模型容易迷失，或把局部看起来能跑的代码误判为完成。

工程的本质是结构化与确定性。Loom 的思路不是让模型看更多、记更多，而是帮模型过滤噪音，只提炼最核心的工程线索：

• 计划进行到哪一步了？
• 哪些单测真的 Pass 了？
• 哪几个文件的 Diff 已经定型不能再乱动了？

当这些关键点成为可被编程读取的结构化数据时，衡量 AI Coding 效能的标准，也就从「模型能生成多少行代码」变成「长任务持续推进的完备率」。

核心功能

• 自动存档点：把交付过程拆成结构化、可恢复的状态链，类似单机游戏的 save point。
• 独立工程状态层：与聊天上下文解耦，关键工程线索以可编程读取的结构化数据存在。
• 多智能体 / 多模型接管：新 Agent 读取状态链即可原地接管，零成本切换模型。
• 失败即约束：测试失败被捕捉为待办状态，成为下一步的强约束，不会被聊天噪音淹没。

实际体验

优势

• 解决长任务失控：不再因为上下文拉长导致 Agent 迷失方向，第 10 轮不会改回第 2 轮已修的 Bug。
• 解锁多模型协作：可以根据任务阶段切换最合适的模型，逻辑用一家、测试用另一家，互不干扰。
• 与「卷 Context Window」路线互补：Loom 不冲突、不替代，是叠加在现有 Coding Agent 工作流之外的一层基础设施。

代价

• 需要把 Loom 接入你现有的 Claude Code / Codex 工作流，存在一定的初始配置成本。
• 作为相对新生的开源项目，生态和文档成熟度需要自行评估。

应用场景

• 长任务交付：在一次会话里跑 10 轮以上的复杂 Bug 修复、API 补全、功能开发。
• 多模型工作流：想根据任务阶段动态切换 Claude、GPT 等不同模型，又不想丢失中间状态。
• 生产环境前置验证：Demo 跑通和真实软件之间还差一整套可信度验证，Loom 提供状态基础设施。
• Agent 评测 / 微调数据收集：Loom 在执行过程中捕获 Agent 的动态反馈轨迹，为未来动态 Benchmark 和微调提供真实工程语料。

定位与互补

Loom 与 agentic loops 通用模式（循环、反馈、工具调用）互补而非重叠：loops 关注单次任务内的执行闭环，Loom 关注跨任务、跨会话、跨模型的工程状态持久化。

大模型在静态语料库学到了「完美的最终代码长什么样」，却很难学到「一个复杂的 Bug 到底如何被一步步定位、失败、妥协并最终修复的」——而这些过程轨迹，才是软件工程中最核心的工程判断力。

开源地址：github.com/valkor-ai/loom