1 简介

当前大型语言模型（LLM）的上下文窗口容量（约100万token）已无法满足企业级代码库的处理需求，这暴露出AI编程工具在复杂场景下的架构瓶颈。

为解决这一问题，行业正推动“上下文堆栈”架构的演进，该架构整合了仓库概览系统、语义搜索技术及企业级集成方案，将上下文资源视为类似CPU时间的稀缺资源进行精细化分配。

这一技术趋势不仅影响着代码辅助工具的进化路径，更对AI代理在长文本理解、多模态任务处理等前沿领域的扩展能力提出关键挑战。

随着每个模型的发布，智能正在迅速提升。就在上周，OpenAI 宣布在 2025 年 ICPC 编程竞赛中取得了满分，击败了所有人类选手。他们使用公开的 GPT-5 模型的一个版本（可能是一个非常高计算能力的版本，但仍然如此）实现了这一目标。

2 场景上下文促使程序开发员更重要

然而，编码代理还远远无法取代软件开发人员。这是为什么呢？

限制因素不再是原始智能，而是情境。现有的编码智能体根本无法掌握它们需要解决的问题的足够情境。这严重限制了它们在没有人类指导的情况下有效工作的持续时间。

• 情报和背景

现有的编码代理的自主性有多强？让我们把自主性想象成一个光谱，看看我们在这个光谱上走了多远。

级别 1 - 几行代码

这就是自动完成功能所做的事情，而且效果非常好。

级别 2 - 一次提交

Cursor 和 Claude Code 非常适合此大小范围内的任务。

级别 3 - 一个 PR

Devin 和其他异步代理就是为处理这种规模的任务而构建的。但它们工作可靠吗？只能处理相对简单的任务。

级别 4 - 主要功能或重构

在现有代码库上自主执行此操作超出了当前代理的能力范围。

级别 5 - 完整代码库。Lovable

和 Replit 等氛围编码产品目前就是这么做的，但之所以能成功，是因为它们可以从零开始。问题在于，它们通常在开发出可用于生产环境的应用程序之前就遇到了瓶颈。

、目前我们在生产代码库上能够可靠实现的只有 Level 2 级别。即便如此，也需要大量的人工指导和审核。如何在不牺牲质量的情况下，进一步提升自主性？

3 提高自主性

当智能体在某项任务中失败时，原因通常有两个：要么是智能失败，要么是场景失败。要么是模型没有获得所需的信息，要么是它没有足够的智力来正确处理这些信息。

还有其他因素也会影响性能，例如味觉。但如果我们只讨论智能体在某项任务中是成功还是失败，那么只考虑智能和情境就足够了。

另外需要注意的是，我将一般的世界知识也纳入智能的一部分，这既是为了简单起见，也因为我认为很难将两者完全区分开来。

编程竞赛是智力的竞赛。解决问题所需的全部背景信息都包含在问题陈述中。无需了解现有的代码库，无需考虑业务需求，也无需遵循任何未写明的开发流程。

我们本周看到的超人 ICPC 表现，以及上个月的 IOI 金牌级表现，强烈表明前沿模型的原始智能和通用编程知识足以实现大多数软件工程工作的自动化。

这些性能是使用比开发人员日常使用的模型（例如 Claude 4 和 GPT-5）强大得多的模型实现的。因此，我们不能断言智能不足永远不会导致当前编码代理失败。它们有时仍然会做一些相当愚蠢的事情。但随着模型的改进，代理编码中越来越多的失败是情境失败，而不是智能失败。

• 编码人工智能需要什么上下文？

上下文不仅仅是代码，还包括规范、开发实践、对话等等。当人类开发人员编写代码时，他们会从隐性知识库中汲取知识，而这些知识远远超出了代码库本身可见的范围。目前的编码代理最多只能利用其中 20% 的上下文进行操作。

代理需要什么样的环境才能可靠地自主运行，并交付与人类开发人员一样好甚至更好的代码？这与人类开发人员的需求是一样的。

以下是一些基本内容：

它需要能够访问所有代码文件
大多数编码代理已经可以做到这一点。

它需要能够访问文档，
如果设置正确，大多数编码代理都可以做到这一点。

它需要能够运行代码并查看输出
大多数编码代理已经可以很好地做到这一点。

然后还有更微妙的语境形式：

它需要对代码库的组织方式以及不同代码的存放位置有深入的理解。
这对于高效执行和确保不遗漏任何细节至关重要。大多数基于工具的代理，例如 Cursor 和 Claude Code，都没有这方面的功能。有些代理提供了类似的功能。

它需要理解代码库中所有现有的架构模式和约定。每个代码库都有自己的“方言”。也许你总是以特定的方式使用依赖注入。

也许存在一条关于业务逻辑和表示逻辑位置的不成文规则。也许你有一个处理异步操作的特定模式，这种模式在过去三年中自然发展。

当前的代理在这方面遇到困难，因为许多模式都是代码库中涌现的属性，没有记录在任何地方。它们分布在成千上万的提交、拉取请求和代码审查中。

它需要理解为什么事情会这样进行。

为什么身份验证系统会这样工作？因为两年前发生了一起安全事件，导致系统彻底重新设计。为什么我们不使用看起来完美的库 X？因为它在 2022 年造成了生产问题。

这种部落知识存在于 Slack 线程、会议记录、事件事后分析和开发人员的头脑中。

它需要了解开发和部署实践测试期望、风格和评论指南等。

每个团队都有关于代码交付的不成文规则。也许你会因为一些微妙的依赖关系而先部署到 staging-east。也许某些测试看起来很奇怪，因为它们正在绕过已知的竞争条件。CI/CD 流水线有一些手动审批步骤，这些步骤看似多余，但却能防止过去发生过真正的灾难。

当前的代理可以读取你的测试配置和部署脚本，但他们无法理解这些配置背后的“原因”。他们可能会删除一些实际上可以防止生产问题出现的“冗余”检查，或者遵循众所周知已经过时的官方文档。

它需要理解产品和业务需求。

代码并非凭空而来。那条看似随意的验证规则？它的存在是因为欧盟市场的监管要求。那条奇怪的数据转换？它正在为你最大的企业客户处理一个极端情况。

我不知道现在有任何编码代理可以插入这种数据。

请注意，所有基本形式的上下文都使用“访问”一词，而更精细形式的上下文则使用“理解”一词。这一点很重要。大多数上下文信息并非记录在代理可以阅读的单个文档中。即使记录下来，也往往分散在许多不同的文件和应用程序中。

其中一些信息可能相互冲突且已过时。向代理提供此类上下文信息并非仅仅为其提供一个连接到您的 Google Drive 和 Linear 帐户的 MCP 连接器那么简单。代理需要处理和整合这些信息。

4 小结

这对于编码代理意味着更多上下文

首先，我们需要让它们访问更多上下文。这些新上下文中的大部分内容需要复杂的预处理才能使用，所以这不是一个简单的问题。

其次，并非所有内容都已记录下来。这意味着经验丰富的人类开发人员仍需要在未来很长一段时间内填补这些空白。

第三，智能体需要学会识别自身缺失的上下文信息，以便能够寻求人工指导。目前，它们似乎只是被训练得能够凭借现有信息继续前进。