第一次听到「Long-Horizon Coding」这个词的时候，我脑子里想的是「哦，就是写很长的代码了」。后来查了下资料才发现，完全不是这么回事。这个词跟红杉资本那篇 《2026: This is AGI》 有很大关系 。他们直接把 Long-Horizon Agents（长程智能体）定义为「功能上的 AGI」——也就是 AI 终于从「聊天框里的回答机器」变成了「能自己把事情搞定的执行者」。
本文关键词：Long-Horizon Coding、长程代码生成、AI 编程智能体、SWE-bench、代码智能体基准测试、自主软件开发
那到底什么是 Long-Horizon Coding？
简单来说，Long-Horizon Coding 不是指代码行数多，而是指 AI 需要在很长时间跨度内、经历很多个步骤、不断试错和调整，最终完成一个复杂的软件工程任务。
举个例子你就明白了：
- 短程（Short-Horizon）：你让 AI 写一个排序函数，它一次性生成代码，完事。类似 HumanEval、MBPP 这种基准测试，考的就是这种「一锤子买卖」的能力 。
- 长程（Long-Horizon）：你扔给 AI 一个 GitHub issue，说「这个项目的用户登录模块有 bug，而且影响了密码重置流程，你修一下」。AI 得自己去看代码库结构、找相关文件、理解业务逻辑、改代码、跑测试、发现不对再回滚、再改……可能要折腾几十个回合，最后才能提交一个靠谱的 PR。这就是 SWE-bench 这类基准测的东西 。
正如红杉那篇文章说的：以前 AI 是 Talkers（说话的人），2026 年开始变成 Doers（干活的人）。Long-Horizon Coding 就是这个转变在编程领域的具体体现。
为什么Long-Horizon这个词现在才被大家关注？
其实概念早就有了，但直到最近几个月才跨过某个「能力阈值」。红杉提到，2022 年的 ChatGPT 解决了「知识/预训练」问题，2024 年的 o1 解决了「推理/思考时间计算」问题，而 2026 年初的 Claude Code 这类工具则解决了「迭代执行」问题 。三个条件凑齐，Long-Horizon Agents 才真正能用了。
从学术圈的角度看，2025-2026 年涌现了一大批专门测长程能力的基准：
| 基准测试 | 测什么 | 特点 |
|---|---|---|
| SWE-bench / SWE-bench Verified | 修 bug | 从真实 GitHub issue 里抽任务，平均改 2-3 个文件 |
| SWE-bench Pro | 复杂工程问题 | 多步骤、专业级任务 |
| TerminalBench | 终端工具使用 | 测命令行操作能力 |
| Commit0 / PaperBench | 长程软件演化 | 不止修 bug，还要持续维护代码库 |
| NL2Repo-Bench | 从零建仓库 | 只给需求文档，AI 自己设计架构、写多模块代码 |
长程编程到底难在哪？
翻了下最近的几篇论文让AI帮我解读，发现 Long-Horizon Coding 的坑比想象中多：
1. 上下文会爆炸
AI agent 在代码库里折腾几十个回合后，上下文窗口里堆满了之前的尝试、错误信息、中间文件……怎么压缩、怎么保留关键信息、怎么丢掉垃圾，都是问题。有篇论文专门研究这个，叫 「Optimizing Context Compression for Long-horizon LLM Agents」 。
2. 错误会累积
有个叫 SlopCodeBench 的基准特别扎心：它测的是 AI 在连续修改代码的过程中，代码质量是怎么逐渐劣化的。结果发现，孤立测试时通过率 80% 的任务，在连续执行场景下掉到 38% 。就像你接手的前任同事留下的代码一样，改来改去最后把代码改成了屎山。
3. 规划能力要够强
NL2Repo-Bench 的实验显示，即使是最强的模型，从零构建一个完整 Python 库的平均测试通过率也不到 40% 。主要死因包括：过早放弃、全局一致性丢失、跨文件依赖搞不定、几百步交互后不知道自己在干嘛。。。
4. 探索大型代码库像大海捞针
有研究者专门测了「在几万文件的仓库里找到该改哪个文件」这个能力。题目很刁钻：用业务语义描述问题，不提文件名、类名、函数名，而且目标文件藏得很深。结果发现 GLM-5 这种专门训练过 agent 轨迹的模型，在这种「战略搜索」上比 Claude Opus 4.5 还强 。这说明长程编程不只是代码写得好，还得会「侦查」。
Long-Horizon Coding 跟常听到的「Vibe Coding」是什么关系？
现在还有个很火的词叫「Vibe Coding」（氛围编程），指那种「随便描述一下需求，AI 自动生成代码，不对就再 vibe 一下」的轻松编程方式。但 Long-Horizon Coding 其实是 Vibe Coding 的「硬核版」——Vibe Coding 可能只需要几分钟、几次交互，而 Long-Horizon Coding 可能要持续数小时、上百次交互，中间还要处理测试失败、依赖冲突、架构调整这些脏活累活 。
有篇论文说：Long-horizon evaluation targets the capabilities that distinguish production-grade agentic engineering from single-turn vibe coding 。翻译过来就是：Vibe Coding 是玩具，Long-Horizon Coding 是生产工具。
当前的现状（2026）：还没到「随便用」的程度
虽然红杉说 2026 年是 Long-Horizon Agents 元年，但实际情况是——能跑通和能靠谱地跑通，是两回事。
SWE-bench leaderboard 上那些 90%+ 的分数看着很唬人，但有文章专门泼冷水：这些分数测的是公开 Python 项目的 bug 修复，不测安全漏洞、不测代码审查能力、不测私有代码库、不测多文件大规模重构 。企业里一个 bug 可能涉及 10-30 个文件的改动，这种复杂度基准测试覆盖不到。
另外，现在的评估成本也高得吓人。有篇论文提到，跑一次 Darwin-Gödel Machine（一种自改进软件 agent）在 SWE-bench Verified 上的测试，要花 22000 美元 。这还没算训练成本——有团队为了训练能处理超长程任务的 KLong agent，搞了个叫 Research-Factory 的自动化流水线，资源消耗大到「小型研究团队可能难以复现」。
一点拙见
我觉得 Long-Horizon Coding 现在有点像 2023 年初的 LLM 应用——大家都知道方向对了，但具体怎么落地还在摸索。几个可能的发展趋势：
- 多 agent 协作：一个 Agent 搞不定长程任务，那就拆成几个——有的负责规划、有的负责写代码、有的负责测试、有的专门「挑刺」。Triple-S、MALMM 这些框架都在往这个方向走 。
- 记忆架构会很重要：长程任务必须记住「我之前试过什么、为什么失败、用户偏好什么」。Harrison Chase（LangChain 创始人）在红杉访谈里特别强调 Memory 是构建垂直领域壁垒的核心 。
- 评估体系会重构：以后看一个 coding agent 厉不厉害，可能不是看 HumanEval 通过率，而是看「能不能连续工作 4 小时不出幺蛾子」。
最后说个题外话——写这篇文章的时候我一直在想，Long-Horizon Coding 本质上测的不是 AI 写代码有多快，而是AI 是不是真的能像一个真人一样「折腾」——犯错、发现、调整、再试，循环往复直到搞定。这种「折腾」的能力，可能才是 AGI 的真正标志。
但话又说回来，自从Kimi2.6发布并体验之后，不知道是不是Kimi存在bug，总感觉有点过了，有的任务其实不需要那么折腾…我已经有些天没有使用Kimi了，主要它动不动就说它“累了”。
（文中数据都来自最近几个月的论文，具体数字可能随时间变化，以最新研究为准。）
