AI 编程 Agent 通过测试也可能做出架构错误决策

在与多位开发者讨论 AI 编程 Agent 后，我一直思考一个问题：

通过测试用例，是否足以证明 AI Agent 做出了正确的工程决策？

这不仅仅是理论层面的担忧。

现代编程 Agent 越来越多地在代码库级别工作，而非生成孤立的代码片段。例如，OpenAI 的 Codex 文档描述了使用代码库特定的 AGENTS.md 指令来告诉 Agent 如何浏览代码库、运行测试、遵循项目实践。Anthropic 同样描述了 Claude Code 搜索代码库、追踪依赖关系、编辑多个文件、处理 CI 失败等工作方式。(OpenAI)

这改变了"正确性"的含义。

一个简单的场景

项目最初的结构是：

Architecture v1

API
 ↓
Service
 ↓
Database

AI Agent 学习了这个结构，并正确地实现了一个新功能。

随后架构发生了变化：

Architecture v2

API
 ↓
Event Bus
 ↓
Services
 ↓
Database

同样的任务被再次请求。

如果 Agent 继续遵循旧的架构，它的代码可能仍然：

满足可见的功能需求，

但对当前系统而言却是错误的。

这就是我关注的区别所在：

代码正确性 ≠ 上下文正确性

传统的编程基准测试通常提供：

Repository
+
Issue
↓
Agent
↓
Patch
↓
Tests / Evaluation

例如，SWE-bench 围绕真实的 GitHub Issue 和代码库设计，OpenAI 创建了 SWE-bench Verified 并进行人工验证，因为基准测试本身的质量会影响我们对模型能力的判断。(OpenAI)

但还有另一个值得测试的维度：

当上下文发生变化时，会发生什么？

近年来的研究已经在朝这个方向推进。

SWE-ContextBench 评估编程 Agent 能否在相关任务中复用相关经验，而 SWE-Explore 则专门关注代码库探索和上下文检索，而非将整个编程任务视为单一的通过/失败结果。(arXiv)

所以我认为思路不应该是：

"替换现有的编程基准测试。"

而是为它们增加受控的上下文切换评估。

保持模型和任务不变。

只改变相关上下文。

Test A — 原始上下文

Architecture:
REST → Service → Database

Constraint:
All database access must go through Repository classes.

Controller
   ↓
Service
   ↓
Repository
   ↓
Database

Test B — 架构已变更

Architecture:
REST → Event Bus → Service → Database

现在期望的实现应该发生变化。

如果 Agent 仍然产生：

Controller
   ↓
Service
   ↓
Repository

那么我们就得到了一次可测量的上下文适应失败。

我们不应该仅仅因为 Agent 改变了答案就奖励它。

假设我们改变了一些无关的东西：

README formatting

架构没有变化。

Agent 应该在理想情况下做出相同的工程决策。

所以一个有用的基准测试应该同时测试：

Relevant Context Change
        ↓
Decision SHOULD change

Irrelevant Context Change
        ↓
Decision SHOULD remain stable

这给了我们两个互补的属性：

Agent 能否对相关变化做出适当的响应？

Agent 能否在上下文无关的情况下避免不必要的更改？

我们可以对其进行定量测量。

Context Adaptation Rate
=
Correct decisions after relevant context changes
/
Total relevant context changes

Context Stability
=
Unchanged decisions under irrelevant changes
/
Total irrelevant context changes

然后将这些与现有指标结合：

Agent Evaluation
│
├── Functional Correctness
├── Test Pass Rate
├── Constraint Adherence
├── Context Adaptation
├── Context Stability
└── Repository Understanding

我并不是在说这是一个成熟的基准测试方法。

这是一个值得通过实验验证的方向。

行业已经在朝着操作整个代码库的 Agent 发展。

Anthropic 最近对大约 400,000 个 Claude Code 会话的分析描述了 Agent 被用于越来越端到端的软件任务，而工程师在规划和指导工作方面保留着重要角色。(Anthropic)

随着 Agent 获得更多自主权，评估问题也在发生变化。

对于代码补全系统：

"这段代码正确吗？"

对于修改长期运行的生产系统的 Agent：

"考虑到系统的当前状态、约束、架构和历史，这是正确的决策吗？"

变得更为重要。

也许下一代的编程 Agent 基准测试不应该只衡量：

Agent 能完成任务吗？

还应该衡量：

Agent 能否识别任务周围的现实已经发生了变化？

这能给我们一个更真实的 Agent 可靠性图景。

Task → Code → Tests

Task
 +
Current Context
 +
Constraints
 +
Repository State
 +
Previous Decisions
        ↓
      Agent
        ↓
     Decision
        ↓
Context-aware Evaluation

而且重要的是，这可以通过实验来测试，而非将其视为一个模糊的概念。

在上下文切换基准测试中，你会首先包含什么：架构变更、安全约束、依赖变更、业务需求，还是代码库历史？

OpenAI — SWE-bench Verified 和评估方法论 (OpenAI)

OpenAI — Codex 和代码库特定的 AGENTS.md 上下文 (OpenAI)

Anthropic — Claude Code 和代码库级别的编程工作流 (Anthropic)

Anthropic — Claude Code 使用的实证分析 (Anthropic)

SWE-ContextBench — 编程 Agent 中的上下文/经验复用 (arXiv)

SWE-Explore — 代码库探索和上下文检索评估 (arXiv)