跳转至

AI 编程的下一场架构迁移：从代码检索，到上下文操作

Ch04.216 AI 编程的下一场架构迁移：从代码检索，到上下文操作

📊 Level ⭐⭐ | 10.6KB | entities/ai-编程的下一场架构迁移从代码检索到上下文操作.md

AI 编程的下一场架构迁移：从代码检索，到上下文操作

架构师（JiaGouX） 我们都是架构师！

这段时间，我们在《架构师》里断断续续梳理了几条线，今天想试着把它们串一串。Karpathy 在最新访谈里提醒大家，Vibe Coding 之后，更值得认真看的其实是 Agentic Engineering；Boris Cherny 那一场让"开发工具从 IDE 变成 Agent 控制台"这件事变得很具体；Cursor 的复盘把 Harness 拉回到线上系统的日常运营里——评估、观测、回滚、模型适配，一个都少不了；Martin Fowler 则把问题压回到软件工程最朴素的一层：非确定性进了研发链路，确定性的验证体系反而更重要。

这些话题表面上看挺分散，但底下其实有一条线：

** AI 编程的重心，正在从"模型能不能写代码"，慢慢挪到"Agent 能不能在真实工程里自己找上下文、动手执行、验证结果，并把过程收住"。**

相关实体

→ 原文存档

深度分析

上下文控制权从系统预处理迁移到 Agent 运行循环

文章最核心的洞察，不在 RAG 与 Grep 的技术之争，而在于上下文控制权的转移。过去，AI 编程工具的上下文管理是系统层面的预处理工作：索引、切块、召回，把结果一股脑交给模型。Claude Code 的实践表明，coding agent 正在把搜索、读取、编辑、测试、验证这一整套循环，拉到 Agent 的运行时决策里。

Boris Cherny 在 Latent Space 访谈中提到，Claude Code 早期尝试用 Voyage 做代码索引，后来转向 agentic search——让模型自己用 glob、grep 和常规代码搜索去找上下文。这个转变的本质不是"Grep 赢了"，而是Agent 获得了上下文的运行时操控权：它决定搜什么、读什么、改什么、跑什么测试、保留什么结论、何时丢弃低价值上下文。

代码库天然提供高精度锚点

代码库与普通文档的本质区别在于：函数名、类名、接口名、路径、错误栈、环境变量、配置项、测试名、commit message——这些本来就是工程师留给未来维护者的索引。当线上报错出现 refreshAccessToken，工程师第一时间不是问"哪里语义上和刷新 token 相似"，而是直接搜这个符号。

这解释了为什么 Agentic Search 在代码场景特别顺。但 Cursor 的数据也提醒我们，语义搜索并非无用——在大型代码库和自然语言查询（"where do we handle authentication?"）场景下，semantic search 让 agent 准确率平均提升 12.5%。成熟的方案通常是组合：词法锚点负责精确符号定位，语义线索负责跨域理解，RAG/BM25 负责知识检索。

上下文即工作集：窗口不是聊天记录

Shopify CEO Tobi Lütke 主张用"context engineering"替代"prompt engineering"——核心问题不再是模型能力，而是如何给 LLM 提供足够且合适的上下文让任务可解。这个观点在 coding agent 场景下更加尖锐。

Claude Code 的上下文窗口会装入对话历史、文件内容、命令输出、项目指令、记忆和系统指令。随着任务推进，窗口会被填满，Claude Code 会清理旧工具输出、必要时做摘要。关键结论是：上下文窗口不是聊天记录，也不是资料仓库，它更像是 Agent 当前推理的工作集。

工作集最大的敌人不是信息少，而是低密度信息太多：搜索结果太泛导致模型被无关文件拖走、工具输出太长淹没关键报错、调试失败路径一直留在窗口里拉着旧假设走、多任务混在一个会话里 Agent 开始串线。

Subagent 的核心价值是隔离上下文污染

Subagent 经常被误读为"多智能体协作的酷炫演示"，但在 Claude Code 的官方文档里，它的首要目的是解决支线任务淹没主会话的问题。当一个大型排查任务要读几十个文件、跑多轮测试、翻很多日志、试几个错误假设，这个过程本身不该进入主上下文——否则主 Agent 很快会被低密度信息拖慢。

合理的架构是：主 Agent 保留目标、约束、计划和关键决策；Explore subagent 做大范围搜索和阅读；Debug subagent 吃日志和复现路径；Review subagent 用干净视角检查最终 diff；主 Agent 只接收高密度结论、证据路径和下一步建议。重点是上下文边界被切开，不同密度、不同风险、不同生命周期的信息在不同上下文里被消化。

企业落地的真正缺口是 Harness

把搜索、执行、验证、隔离、压缩、权限这些能力串起来看，企业落地 AI Coding 真正缺的不是更强的模型、更长的上下文窗口，或者 IDE 里加一个聊天框。企业真正要补的是 Harness——模型之外那套让 Agent 能在工程系统里工作的运行底座。

Harness 可以粗略分为八层：Search Harness（搜索文件、符号、日志、提交历史）、Read Harness（控制读取粒度、分页、preview）、Execution Harness（运行测试、lint、typecheck、脚本）、Memory Harness（保存项目约定、架构决策、纠错经验）、Compaction Harness（长任务中压缩历史）、Isolation Harness（subagent、sandbox、worktree 隔离）、Policy Harness（权限、审批、凭证、审计）、Evaluation Harness（测试、线上信号、代码保留率、失败分类）。

Anthropic 把 Claude Code 称为 Claude 外面的 agentic harness——模型负责推理，Harness 负责让推理接上真实工程。Cursor 的复盘也指向同一件事：Agent 版本更准确的发布单元是"模型 + Harness"组合，而不只是模型能力的提升。

实践启示

1. 重新理解代码检索的战略地位

RAG 和 Grep 的争论是表层现象。更值得架构师关注的命题是：代码检索正在从"模型调用的预处理模块"变成"Agent 推理过程中的运行时动作"。这意味着搜索结果不再是静态的上下文填充，而是 Agent 与代码库实时交互的起点。在设计 AI Coding 基础设施时，应该把搜索能力当成 Agent 工作流的一等公民来设计，而不是当作 RAG pipeline 的一个环节。

2. 构建上下文分层策略

不是所有上下文都该塞进窗口。架构上应该建立清晰的分层：

  • 前缀层（Prefix）：工具定义、系统规则、项目约定等稳定内容，适合缓存
  • 动态层（Dynamic）：用户意图、工具输出、失败观察等，按需读取
  • 持久层（Persistent）：任务状态、计划、session 状态写入文件而非留在窗口
  • 隔离层（Isolated）：subagent 负责大范围探索，结论才传回主会话

这种分层直接决定 Prompt Caching 的效果——缓存命中率反映的是上下文结构的稳定性。

3. 企业 AI Coding 应该从 Harness 评估切入

在引入 AI Coding 能力时，企业不应该只评估模型的代码生成能力，而应该评估完整的 Harness 体系：

  • Agent 能看什么、做什么、记住什么、忘掉什么
  • 能否验证自己、被人接管、留下可审计轨迹
  • 搜索、执行、验证、权限的闭环是否完整

Cursor 的做法是同时看离线评测、线上 A/B、Keep Rate、用户后续反应、工具错误率、cache hit rate。一个版本的发布单元应该是"模型 + Harness"，而不是模型 alone。

4. 区分 Vibe Coding 和 Agentic Engineering 的边界

Vibe Coding 适合原型、个人工具、低风险探索，让想法快速变成可运行的东西。Agentic Engineering 关心的是结果能不能被审查、被测试、被回滚、被维护、能不能在团队里继续被拥有。团队在引入 AI Coding 时应该明确当前处于哪个阶段，并相应地设置不同的验收标准和质量门槛。

5. 架构师的核心问题是"边界设计"而非"工具选型"

当 Agent 可以自己搜索、阅读、执行、验证、修改系统时，架构师真正要回答的问题是：

  • 给 Agent 怎样的上下文边界（什么信息稳定存放，什么按需读取）
  • 怎样的工具边界（能调用什么，不能调用什么）
  • 怎样的权限边界（能看到什么代码，能修改什么文件）
  • 怎样的验证边界（谁来确认结果正确，出错时如何回滚或交接）

这些问题答得越清楚，AI Coding 就越像工程，而不是魔法。