软件的瓶颈从来不是智能，而是上下文。

一个供应商案例被频繁引用：乐天给了一个 AI 编程智能体一项大型开源项目中的具体任务，并报告它在长时间会话后得到可用结果。此事确有其事，但它不是受控生产率研究，也不能证明有关编程智能体的一般理论。更窄的结论才有用：明确界定的任务、相关仓库上下文、可执行检查和人工审查，可以支持智能体在陌生系统上持续完成有用工作。

这是工程视角，不是供应商宣传。文中事实与来源已于 2026 年 9 月 2 日核查。能力与生产率会因模型、工具、仓库、任务、审查者和评估方法而异。

乐天到底发生了什么？

在 2025 年 5 月 Claude Opus 4 发布时，Anthropic 表示乐天测试了一次约七小时的开源重构。在 Anthropic 的乐天客户案例中，一位工程师要求 Claude Code 在 vLLM 里实现特定的激活向量提取方法。案例报告其相对参考实现达到 99.9% 数值准确率。这是供应商发布的客户证据，不是独立基准。

两点诚实的更正，因为我们宁可说得准确，也不愿说得夸张：

• 它并未被证明为完全无人值守。案例称工程师偶尔提供指导。应把“自主”视为发布者对会话的描述，而不是零人工干预的证据。
• 99.9% 是一个很窄的指标。它指的是某个方法的输出相对参考实现的数值准确率，并不是说该智能体在所有事情上都有 99.9% 的正确率。这个数字有用、具体，也很容易被当成标题来误读。

同一案例把 vLLM 称为 1250 万行代码库，却没有公布计数方法、版本、包含的仓库，或如何处理生成和供应商代码。不要把该数字当作实测仓库规模。能够支持的说法只是：任务涉及一个大型多语言开源系统和一个具体参考实现。

为什么真正的瓶颈是上下文，而不是智能？

该案例支持一个实用假设，而非普遍定律：即使模型能生成看似合理的代码，仓库上下文和反馈仍可能成为瓶颈。工程师还带来默会领域知识、架构历史、产品判断和责任，这些不是多加载文件就能获得的。

有用的问题不是上下文或智能是否为唯一瓶颈，而是智能体是否获得了与任务相关的代码、约束、工具、测试和反馈，以及审查者能否发现检查未覆盖的失败模式。

长时间智能体运行的上下文有哪些限制？

人类不擅长长时间持有大量上下文，并不是因为我们笨。我们会累。我们会忘记四十个文件之前读过的东西。一休息就丢了思路。在漫长一段工作的后半程，会犯下第一个小时绝不会犯的小错误。在脑中持有一个庞大系统的心智模型很耗神，而疲惫正是 bug 的来源。

编程智能体不会经历人类疲劳，但这不代表它能在七小时内稳定推理，也不代表它能完美利用大上下文窗口。模型可能丢失相关信息、过度关注较新的观察、累积早期错误或耗尽上下文预算。长上下文研究表明，性能可能强烈取决于相关信息出现的位置。因此，长时间智能体运行需要上下文筛选、摘要、检查点、测试和恢复路径。

但有个真实的陷阱：智能体只能在它实际拿到的上下文上做出良好推理。把它对准错误的文件，或不给它关键约束，它就会毫不疲惫、却又自信满满地把错的东西造出来。喂给它正确的上下文，如今才是真正的技能。关于这项纪律的成本面，我们在如何在 2026 年降低 LLM Token 成本里写过：管理上下文，而不仅仅是花掉 token，才是这盘棋的大头。

如果你需要一套把持久记忆、共享状态、有界推理和意图路由分开的具体架构，请看我们的Meterless 上下文层事实核查评测。

如果缺失的是跨文件关系，我们的Graphify 采购评测对比代码库知识图谱、仓库搜索与 RAG，并给出可衡量的两周试点方案。

如果并行智能体的下一个瓶颈变成代码库准备与变更集成，请用我们的Git worktree 与 Jujutsu 决策指南，在调优后的 Git 基线和可测量的 Jujutsu 试点之间选择。

关于在会话之间把这份上下文写下来的工具层，可以看我们的Graft 评测，它讨论仓库地图究竟该进 Git，还是应该留作可重建的本地缓存。

这会让工程师消失吗？

这个案例不能回答就业问题。它展示一个技术工作流，而不是劳动力市场结果或普遍生产率提升。编程智能体可以把工作转向任务设计、上下文准备、工具监督和审查，但效果会因团队和任务而异。

最后这项能力被低估了。智能体会产出自信、格式工整、看似合理却暗藏错误的代码，而一位初级审查者会因为它“看起来对”而放行。要抓住这一点，恰恰需要多年手写代码才培养出的判断力。经验并没有变得一文不值，它只是从“我敲出解法”变成了“我在错误的解法上线前就认出它”。如果你想看看这种审查具体长什么样，我们的vibe 代码生产就绪清单，就是我们用来对照智能体产出的那份清单。

当智能体写代码时，好的工程是什么样子？

委派可以成为集中的工程工作：界定任务、组装证据、定义验收标准并审查结果。它不会消除实现知识，因为审查者仍需理解系统和改动后果。

这种模式下的好工程包括有限任务、相关上下文、最小权限工具、可复现检查、可审查 diff 和合格的人类决策。测试会降低风险，但不能证明覆盖范围之外的正确性。

"智能体不会经历人类疲劳，但它仍有有限上下文和失败模式。工程优势来自筛选证据、定义检查和审查结果，而不是假定它能完美掌握整个代码库。"

你该如何围绕编程智能体重构工作流？

如果你想在自己的工作上复现乐天的结果，按顺序，真正重要的几步是：

1. 把任务收窄界定。“按照这份参考实现这个特定方法”比“改进推理层”更容易测试。精确会减少歧义，但不保证无人值守成功。
2. 给它正确的上下文，而不是全部上下文。把智能体对准真正重要的文件、接口和约束。上下文不是越多越好，而是越对越好。如今大部分技能就藏在这里。
3. 用测试与护栏来把关。使用相关测试、参考、静态检查和安全控制。通过检查只能作为覆盖范围内的证据，不能证明改动完全正确。
4. 像资深者一样审查，而不是盖橡皮图章。逐行读 diff，找出那些细微、看似合理的错误，那些能编译通过、也能糊弄一眼的错误。这是你投入的最高杠杆的一小时。
5. 把所有权和知识留在内部。一个交付出团队没人看得懂的代码的智能体，是一项依赖，不是一场胜利。要确保有一个人对交付的东西负责，并能讲清楚它。

这些都不稀奇。它就是好工程一直需要的那份纪律，只是重新分配了权重：用更少的时间产出代码，用多得多的时间去界定和验证它。

视觉工作也需要同样的处理。我们的Claude Code 设计系统指南说明如何把已批准示例、品牌证据和实现规则变成持久的仓库上下文，而不是在每个提示词里重复。

Semaprax 是对这一上下文问题的研究回应，并不能证明新语言已经解决问题。Semaprax 基准冻结一个小型结构化上下文契约并公开限制，目前尚不测量模型 Token、任务质量或仓库规模成本。