先看证据
把机制串起来
大语言模型本身只负责根据上下文生成文本或代码；要让它持续修改文件、运行测试并迭代修复，还需要一个“代理 harness”，负责工具调用、状态管理和执行环境。代码代理的关键不是单次生成代码，而是能否把生成、执行、观察错误、再次修改组成可靠闭环。文章中的突破，正是模型与这套代理外壳组合后，开始从“经常出错”跨过“日常可用”的门槛。
代理先让模型提出代码或操作，再通过工具读取文件、运行程序和测试，把真实执行结果重新放回上下文。这样模型不必一次性预测完美答案，而可以利用编译错误、测试失败和运行输出进行多轮修正。模型能力提升的关键在于，它开始更稳定地规划步骤、识别失败原因，并遵守代理提供的工具接口。代价是执行时间更长、调用成本更高，也会引入权限、沙箱、上下文膨胀和错误循环等工程风险。相关仓库展示了另一条配套路线：用纯Python实现JavaScript或WebAssembly运行时，便于隔离和移植，但性能明显
['需要反复改代码、跑测试的任务适合使用代码代理', '生产环境接入代理前应限制权限并隔离执行环境', 'micro-javascript明确警告：尚未准备好生产部署', 'pwasm适合无原生依赖场景，不适合性能敏感任务']
提出者回顾的不是发布清单，而是一道门槛
Simon Willison 在 2026 年 9 月于圣何塞举行的 WeAreDevelopers World Congress North America 上发表闭幕演讲，并以一份带注释的演示文稿回顾截至当时的大模型进展。他把这段时间线的起点放在 2025 年 11 月，虽然演讲主题是 2026 年到当时为止的变化。材料明确指出，Claude Opus 4.5 和 GPT-5.1 是那个节点出现的两个重要模型，但它们首先仍属于对前代模型的渐进式改进。
这次回顾值得技术负责人阅读，是因为它没有把模型发布本身当成故事的终点。Willison 关注的是某项能力何时从“经常失败”变成“可靠到可以每天使用”，也就是用户是否需要持续介入整个过程。这个判断把注意力从单一模型的能力展示，转向模型进入真实工具链之后会不会改变工作方式。对工程团队来说，后一个问题通常比发布当天的排行榜位置更接近部署决策。
真正变化的是模型与代理的组合
Claude Code 在 2025 年 2 月已经存在，Codex 也在之后出现。代码代理并不是在 Claude Opus 4.5 和 GPT-5.1 发布时才突然被发明出来，早期工具已经能够围绕代码库执行任务。问题在于，代理要把任务做完，不能只生成一段看起来合理的代码，它还要处理规划、文件修改、命令执行以及后续反馈。只要这些环节中的任意一个环节频繁出错，开发者就很难把完整任务交给它。
材料对转折的描述因此很具体。新模型并没有被宣称为完美，也没有被描述成可以替代开发者，而是与各自的代码代理 harness 配合后，让使用体验从“经常犯错”改善到“足够可靠，可以日常使用”。这里的关键对象不是模型孤立的输出，而是模型、代理编排方式和执行环境组成的系统。模型负责推理与生成，代理负责把这些能力接入文件和工具，工程环境则决定错误能否被发现并处理。
为什么小幅改进会带来非线性结果
代理工作流存在一个隐形门槛。假设一个代理能够完成一部分任务，却总是在测试失败后无法修正，或者改动多个文件时破坏原有逻辑，开发者就必须逐步盯住它的每一次行动。此时，模型即使偶尔给出高质量结果，也很难带来稳定的生产力收益，因为监督本身已经占用了大部分节省下来的时间。一个错误率略有下降的模型，可能仍然没有改变这种工作方式。
但当错误减少到某个范围，工作流的形态就可能改变。开发者不必再对每个中间步骤做即时判断，而可以让代理先推进任务，再通过测试、审查或人工复核检查结果。材料所说的“跨过看不见的线”，并不是一个可以从提供内容中读出的固定分数，也不是对所有仓库都成立的结论。它更像是错误成本与监督成本之间的关系发生了变化，足以让一些团队愿意把代理纳入重复性的日常工作。
鹈鹕与自行车说明了演示的边界
Willison 还提供了一个很有辨识度的模型测试。他多年来让模型“生成一只骑自行车的鹈鹕 SVG”，因为鹈鹕难画，自行车也难画，而且让鹈鹕骑自行车本身就是违反常识的组合。这不是一个足以概括模型能力的正式基准，材料甚至把它称为可能是世界上最愚蠢的 benchmark。它的价值在于把几何结构、细节控制和多个约束放到同一个小任务里，让模型很容易暴露缺陷。
截至 2025 年 11 月，Claude Opus 4.5 生成的自行车车架形状很奇怪，鹈鹕看起来更像鸭子。GPT-5.1 稍微好一些，但车架仍然损坏，鹈鹕的喙也仍然不对。这个结果与代码代理“足够可靠地日常使用”并不矛盾，因为二者测量的对象不同。鹈鹕 SVG 更像能力探针，适合观察模型在困难视觉或几何约束下的失败方式，却不能直接回答代理能否在一个真实代码库里反复完成可检查的修改。
部署判断应从监督成本开始
对技术负责人而言，材料最可执行的启发不是立刻扩大代理权限，而是重新定义评估对象。团队应当把旧模型和新模型放在重复出现、边界清楚并且有检查手段的工程任务中比较，然后记录代理在哪里失败、人工多久需要接管、测试能否捕获问题，以及复核和返工耗费了多少时间。提供的材料没有这些量化数据，因此不能据此断言 Claude Opus 4.5、GPT-5.1、Claude Code 或 Codex 适合所有团队。
更稳妥的部署路径，是先让代理处理能够被现有测试和代码审查约束的任务，再观察监督是否从逐步控制降为结果复核。如果代理只是偶尔完成漂亮的复杂任务，却仍然需要开发者持续修正每一步，那么它还没有跨过团队自己的可用门槛。相反，如果错误能够被验证机制稳定捕获，人工干预明显减少，而且节省的时间超过返工成本，团队才有理由扩大使用范围。模型升级应当触发一次工作流评估，而不应自动等同于更高权限或更广泛的自动化。