从代码生成器到软件工程系统：编程智能体的真正变化不在模型里

如果要给这两年的编程智能体写一句介绍，最顺口的说法是：早期 Copilot 帮你补全一个函数，今天的编程智能体自己通读整个仓库、改动几十个文件、跑测试、看报错、修完再跑，最后丢给你一条拉取请求。这个说法没有错，但它只说对了一半。真正有意思的变化不在"模型变得更会写代码"，而在模型之外——我们围着它搭起了一套以前不存在的系统。

这套系统由五件事构成：上下文管理、工具调用、验证回路、记忆与长程编排。模型本身没有变大多少，负责"思考"的仍然是它；但决定一个智能体能不能在真实仓库里连续工作几个小时的，是外面这层系统。行业里流传最广的比喻来自 Andrej Karpathy：大模型是 CPU，上下文窗口是内存，工程师是操作系统。顺着这个比喻往下走，所谓"从生成器到系统"，本质就是从"吐出 token"转向"跨时间地管理上下文、状态、工具与验证"。

这场转变不是某家公司的内部实验，它有清晰的时间线。2021 年，GitHub Copilot 以行内补全的方式登场；2025 年 2 月，GitHub 推出智能体模式，并首次展示代号"Project Padawan"的自主编程智能体；同年 5 月 19 日微软 Build 大会上，Copilot 的编程智能体进入公开预览。用法大致是：你在仓库里开一个问题单交给它，它会在 GitHub Actions 的安全云端环境里自行探索仓库、修改文件，用你的测试与代码检查工具自检，最后推出一条草稿拉取请求，等你去审阅。RedMonk 分析师 Kate Holterhoff 在 GitHub 的通稿里给出了一个精准的概括：这次发布把 Copilot 从"编辑器里的助手"变成了"开发流程中真正的协作者"。这句话就是整篇文章的缩影——工作的基本单位，从"一个函数"变成了"一个任务"。

那么，"系统"在技术上到底意味着什么？那串新名词——仓库上下文、任务分解、智能体记忆、代码库索引、工具调用、终端执行、测试生成、自验证、长程管理、智能体技能、沙箱——看起来像一张清单，其实可以归进五层。

第一层是感知：代码库索引与仓库上下文。这是"文本匹配还是向量检索"之争的落点。传统的检索增强生成（RAG）按语义相似度检索，对散文这类文本足够好用；但代码其实是一张由导入关系、函数调用与类型依赖织成的图——一个调用 processPayment() 的代码块，和定义它的那个代码块，在向量空间里未必邻近。所以真正落地的产品（Claude Code、Cursor、Devin）反而更依赖文本匹配、文件树与依赖关系遍历；实践中胜出的往往是混合检索——向量、图和关键词一起用。再往上，是一份静态的"新人手册"：从 CLAUDE.md、.cursorrules，到 2026 年初行业收敛出的 AGENTS.md——一个由 Linux 基金会托管的开放标准，Codex、Claude Code、Cursor、Copilot 都在读取。

第二层是记忆与状态。上下文窗口是有限、而且会衰减的资源。Chroma 在 2025 年发布的"上下文腐坏"研究中测了 18 个前沿模型，结论很直接：即使没有超出窗口上限，输入越长，输出质量也越差。业界的对策已经变成标准动作：状态落盘、只检索相关片段、压缩内容，或者把工作隔离给子智能体——子智能体只回传一段 1000–2000 token 的紧凑摘要，而不是原始记录。斯坦福与伯克利的 ACE 更进一步，用能自我演化的"剧本"来精炼上下文，而不是每次推倒重来。

第三层是行动。模型上下文协议（MCP）把工具访问变成可复用、带类型的接口；钩子机制则把那些模型只能"大概率遵守"的规则，变成必须执行的硬约束；隔离容器与 git 工作树让一次失误不至于酿成大祸。到了这一层，智能体的角色就变了：它不再"建议"，而是"执行"。

第四层是验证。编辑、运行、读报错、修复、再跑——这个闭环正是"系统"与"生成器"的分水岭。Copilot 的智能体在把改动交给你审阅之前，会先用自己的测试与代码检查工具自检一遍。

第五层是编排。METR 用"时间跨度"基准衡量一个智能体在失败或求助之前能独立工作多久：50% 成功率对应的时长，从 o1 的约 39 分钟（2024 年 12 月）涨到 Claude Opus 4.6 的约 12 小时（2026 年 2 月）——大约每 4.3 个月翻一倍。这就是"系统"和"一次性问答工具"之间最直观的距离。

不过，证据本身也在被重新审视。一方面，以真实工程过程为对象的基准大量出现——SWE-bench、SWE-bench Verified、SWE-bench Pro、Terminal-Bench 2.0、METR Time Horizon、YC-Bench、OTelBench、BinaryAudit——这本身就是趋势被量化的证明：我们不再问"它会不会写一个函数"，而问"它能不能在一个真实仓库里撑过一个小时"。另一方面，这块记分牌本身出了问题。2026 年 2 月 23 日，OpenAI——这个基准最显眼的拥趸之一——宣布在评估前沿模型时弃用 SWE-bench Verified。它的审计发现，抽查的较难题目里，至少 59.4% 的测试用例有缺陷，会把功能正确的提交判错；而且它测过的每个前沿模型，都能仅凭任务 ID 复现"标准答案"。OpenAI 的结论是：六个月里从 74.9% 爬到 80.9% 的"进步"，更多来自训练数据暴露，而不是真实能力。微软一项名为"拯救 SWE-bench"的独立研究也发现，当任务被改写成开发者实际使用的对话口吻时，基准会高估智能体的能力 50% 以上。

诚实的差距，藏在那些没人细看的数据里：顶尖模型在 SWE-bench Verified 上普遍拿到 70–80%+，但在 SWE-bench Pro——2025 年 9 月发布、难度更高也污染更少的长程多文件多语言任务集——上，它们一开始只有约 23%；Codex 此后把它推到了 56.8%。趋势是真的，成熟度却被我们反复引用的那块记分牌放大了。

被改写的还有经济学。当工作单位变成"任务"，计费方式自然跟着变：Cursor 于 2026 年 5 月推出的后台智能体 1.0，按智能体工时计费，而不是按消息条数。Claude Code 完成同一任务通常比 Codex 多花 3–4 倍 token——这种"话多"与更彻底的产出相关，但也更快耗尽额度。一个命中缓存的 token，成本约为未命中的十分之一；所以稳定前缀（系统提示、工具定义）本身就是 10 倍的降本杠杆。"系统"不只行为不同于"生成器"，连成本结构都是另一套。

对正在采用这些工具的团队，有四件事值得优先做。其一，投入 AGENTS.md 与上下文工程——这是成本最低、杠杆最高的那一层。其二，为验证回路而设计；一个跑不了你测试的智能体，只是披着"智能体"外衣的代码生成器。其三，把公开基准当作参考而不是权威，在自己的仓库、用自己真实的对话式请求去度量。其四，记住工作单位已经变了：那是横跨数小时、多个仓库的"任务"，而不是"一个文件"。

智能体已经成为一套软件工程系统；还没跟上的，是我们的评估、计费与习惯。