--- title: AI 编程的下一场架构迁移：从代码检索，到上下文操作 source_url: https://mp.weixin.qq.com/s/HLqHRQ33xkBQSW778mIzsQ publish_date: 2026-05-16 tags: [wechat, article, claude, openai, agent, harness, rag, coding, llm] review_value: 7 review_confidence: 7 review_recommendation: neutral ingested: 2026-05-16 sha256: 40ea957b2e0a0455fdac78abbf391213bc6e3684f69a8a132fcfb263d66f64a9 --- # AI 编程的下一场架构迁移：从代码检索，到上下文操作 架构师（JiaGouX） 我们都是架构师！ 架构未来，你来不来？ * * * 这段时间，我们在《架构师》里断断续续梳理了几条线，今天想试着把它们串一串。 Karpathy 在最新访谈里提醒大家 [ ，Vibe Coding 之后，更值得认真看的其实是 Agentic Engineering ]() ； [ Boris Cherny 那一场让“开发工具从 IDE 变成 Agent 控制台” ]() 这件事变得很具体； [ Cursor 的复盘把 Harness 拉回到线上系统的日常运营里 ]() ——评估、观测、回滚、模型适配，一个都少不了； [ Martin Fowler 则把问题压回到软件工程最朴素的一层 ]() ：非确定性进了研发链路，确定性的验证体系反而更重要。 这些话题表面上看挺分散，但底下其实有一条线： ** AI 编程的重心，正在从“模型能不能写代码”，慢慢挪到“Agent 能不能在真实工程里自己找上下文、动手执行、验证结果，并把过程收住”。 ** 今天想顺着这条线，补一个最近被反复讨论、又特别容易被误读的小切口：代码检索。 [ Boris 在 Latent Space ]() 访谈里提到，Claude Code 早期试过用 Voyage 给代码库做索引，后来转向 agentic search——也就是让模型自己用 glob、grep 和常规代码搜索去找上下文。这个点最近被国内不少同行反复讨论，最常见的提法是一句话：RAG 不适合代码，Grep 回来了。 这句话有传播力，但我自己读访谈的时候，感觉它还没说到根上。 真正值得架构师多想一层的，不是 grep 赢了，也不是 RAG 输了。 ** 更大的变化是：AI 编程工具的上下文控制权，正在从系统预处理迁移到 Agent 的运行循环里。 ** 过去是系统提前切块、索引、召回，再把上下文一股脑交给模型。现在越来越多的 coding agent 会根据任务目标，自己决定搜什么、读什么、改什么、跑什么测试、保留什么结论，以及什么时候把低价值的上下文丢掉。 这件事表面看是检索路线之争，再往里走一层，其实还是 [ Harness ]() 。 上下文控制权从系统预处理迁移到 Agent 运行循环 * * * ## 太长不看 * • Claude Code 没有证明“RAG 已死”，它更像证明了一件事：代码任务里，搜索正在变成 Agent 推理过程中的动作。 * • 代码库和普通文档不一样。函数名、路径、错误栈、配置项、测试名，本身就是工程师留下的高精度锚点。 * • Agentic Search 的价值不在“更原始”。它实时、可解释、贴近当前文件系统，同时少掉索引同步和敏感代码外传的问题。 * • Cursor 的官方数据也提醒我们：语义搜索仍然有价值，尤其在大型代码库和自然语言查询里。 * • 真正的分水岭不在 RAG 和 Grep，而在上下文能不能被搜索、读取、压缩、隔离、缓存、验证和审计。 * • 企业落地 AI Coding，最后要补的不是单个检索模块，而是一套 Harness：搜索、读取、执行、记忆、压缩、隔离、权限和评估。 * • Agentic Engineering、Agent 控制台、上下文工作集、Harness 新后端，说到底都在回答同一个问题：Agent 怎么进入真实工程系统。 * * * ## 先别急着宣布 RAG 已死 说实话，我个人不太喜欢“RAG 已死”这种说法。 它容易把讨论拽进站队： 一边说向量库没用，一边说 grep 只是开倒车。两边都有道理，也都容易说过头。 Boris 在访谈里给出的原话边界，其实比传播版要克制。他讲的是 Claude Code 早期试过 RAG、给代码库做索引，用的是 Voyage 这类现成方案；后来发现 agentic search 在内部体感和评测里都更好。原因除了效果本身，还包括索引同步、安全、隐私和责任问题。代价他也老老实实说了：latency 更高，token 更贵。 所以这就不是一个可以拿出来无脑外推的结论。 代码库有几个特殊点： * • 它经常处在高频变化里，索引很容易落后于真实工作区。 * • 很多问题先表现为精确符号，而不是模糊语义。 * • 搜索过程需要和阅读、修改、测试连续发生。 * • 代码通常敏感，索引放在哪里、谁能访问、怎么失效，都不是小问题。 所以 Claude Code 的选择，放在代码场景里很合理。 但企业知识库、客服知识库、合同库、产品文档、海量 PDF，又是另一回事。Wes Roth 转述过一组反向实验：让 Claude Code 直接读几百份企业 PDF，速度、成本和事实准确性都撑不住。这个结果并不意外。 更成熟的说法应该是： ** RAG 没死，该放下的是“所有上下文都必须先向量化”的路径依赖。 ** 代码场景里，Agentic Search 很多时候更自然；大规模知识检索里，RAG、BM25、语义索引、重排和权限过滤仍然有自己的位置。 架构设计最怕的不是选错技术，而是把某个场景里的胜利，误当成所有场景的规律。 所以这次不太想把话题停在检索工具上。 如果只谈 RAG 和 Grep，很容易变成工具比较；如果放进 Agentic Engineering 里看，它问的其实是另一件事： Agent 到底应该怎样获得上下文，怎样证明自己找对了上下文，又怎样在找错时及时收回来。 * * * ## 搜索从模块变成动作 传统 RAG 更像一个 pipeline 。 用户提问之后，系统先检索，再把 top-k 结果拼进 prompt，最后让模型生成回答。这里的搜索是模型调用前的一个模块。模型拿到的是别人已经选好的上下文。 Agentic Search 的味道不一样。 它更像一个工程师进入陌生代码库时的动作： 先看目录。 再搜入口。 看到一个函数名，顺手搜调用方。 读到一段配置，再去找测试。 跑一次命令，拿到报错，再换关键词继续搜。 这个过程不是一次检索，而是一串带反馈的探索。 Claude Code 官方文档也把它的工作方式拆成三段：gather context、take action、verify results。它会搜索文件理解代码，编辑文件采取行动，运行测试验证结果，然后把结果再带回下一轮。 也就是说，coding agent 的基本单元已经不是： ` Prompt -> Code ` 而更像： ` Intent -> Search -> Read -> Plan -> Edit -> Run -> Observe -> Repair -> Verify ` 放在这个循环里看，Search 只是第一步。 真正重要的是，Agent 有能力把搜索结果接着变成阅读、修改、执行和验证。它不会在“搜到几段相似文本”后停下，而是在真实工作区里一边探索，一边修正自己的假设。 这也是为什么我更愿意把这次变化叫 “上下文操作权的迁移”。 过去上下文是系统提前准备好的材料。现在上下文变成 Agent 可以操作的对象：可以找、可以读、可以缩小范围、可以转存、可以压缩、可以交给 subagent 隔离处理。 这也能解释为什么 Boris 的访谈不该只读成“终端工具变强了”。开发工具从 IDE 走向 Agent 控制台以后，人控制的不再只是光标和文件，而是目标、边界、预算、权限和验证。搜索只是 Agent 接管工作流后的第一个动作。 * * * ## 代码库自带很多高精度锚点 为什么这条路在代码场景里特别顺？ 因为代码不是普通自然语言文档。 函数名、类名、接口名、路径、错误栈、环境变量、配置项、测试名、commit message，这些东西本来就是工程师留给未来维护者的索引。 如果线上报错里出现 ` refreshAccessToken ` ，最先做的通常不是问“哪里语义上和刷新 token 相似”，而是直接搜这个符号。 如果测试失败在 ` PaymentRetryPolicyTest ` ，第一步也不是向量检索，而是找到这个测试、被测对象、最近改动、相关配置。 这不代表语义搜索没用。 Cursor 官方博客给了一个很好的平衡： 它们的 agent 同时使用 grep 这类正则搜索和 semantic search。 语义搜索可以回答“where do we handle authentication?”这类自然语言问题。Cursor 的评估显示，引入 semantic search 让 agent 回答准确率平均提升 12.5%，大型代码库上收益更明显。 这说明成熟方案通常不是二选一。 更像是不同上下文通道各自负责不同问题： --- 场景 | 更合适的入口 ---|--- 明确函数名、报错、路径、配置项 | grep / glob / 直接读取 自然语言询问“哪里处理某类逻辑” | semantic search 大型 monorepo 的跨域理解 | 语义索引 + 符号/调用关系 高频修改中的当前工作区 | 实时文件系统读取 企业知识库和历史文档 | RAG / BM25 / 重排 / 权限过滤 长程工程任务 | search、memory、compaction、subagent、cache 组合 代码任务里的上下文通道选择 所以，“Grep 回归”这个说法可以当入口，但不该当结论。 更稳的结论是： ** 代码任务里，词法锚点、语义线索和运行反馈要一起进入 Agent 的工作循环。 ** * * * ## 上下文才是第一资源 这条线继续往下走，很快就会碰到一个更老的问题：上下文窗口。 Shopify CEO Tobi Lütke 去年说过一句被反复引用的话——他更愿意叫它 context engineering，而不是 prompt engineering，因为真正的核心技能，是怎么给 LLM 提供足够的、合适的上下文，让任务变得可解。这话放到 coding agent 上更合适。 很多团队做 AI Coding 落地时，第一反应是换更强模型、接更多工具、塞更多文档。看上去模型拥有的信息更多，但实际跑起来，经常是窗口被弄脏了。 Claude Code 官方文档说得很直接：上下文窗口会装入对话历史、文件内容、命令输出、项目指令、记忆和系统指令。随着任务推进，窗口会填满；Claude Code 会清理旧工具输出、必要时做摘要，但早期详细指令可能丢失，所以持久规则应该放到 ` CLAUDE.md ` ，而不是只靠聊天历史。 这和我们之前在《 [ Agent Harness 上下文管理：聊天记录还是工作集？ ]() 》里给出的判断是同一件事： ** 上下文窗口不是聊天记录，也不是资料仓库，它更像是 Agent 当前推理的工作集。 ** 工作集最怕什么？ 不是信息少一点。 是低密度信息太多。 比如： * • 搜索结果太泛，模型被无关文件拖走； * • 工具输出太长，真正关键的报错被淹没； * • 调试失败路径一直留在窗口里，后续推理被旧假设牵着走； * • 项目规则写得太散，压缩后丢掉了最关键的约束； * • 多个任务混在一个会话里，Agent 开始串线。 所以 AI Coding 的上下文管理，不能只问“窗口有多大”。 还要问： * • 什么稳定内容应该放在前缀里，便于缓存？ * • 什么动态内容应该按需读取，而不是提前塞满？ * • 什么工具输出只需要 preview？ * • 什么探索过程应该放到 subagent 里？ * • 什么任务状态应该写进文件、计划或 session，而不是留在窗口里？ 这也是 Prompt Caching 值得重看的地方。 它表面上是省钱，实际在倒逼团队把上下文结构整理干净：工具定义、系统规则、项目约定这类稳定内容放在前面；用户意图、工具输出、失败观察这类动态内容往后长；长任务中间再通过压缩、转存和摘要保持工作集干净。 缓存命中率不是一个孤立的计费指标。它经常反映出上下文结构是不是稳定。 这也是为什么我现在越来越少把 prompt 当成唯一入口。Prompt 当然重要，但真正决定长任务能不能跑下去的，经常是窗口外那层结构：哪些信息长期稳定，哪些信息按需读取，哪些状态写入文件，哪些探索过程隔离出去。 * * * ## Subagent 的核心是隔离污染 Subagent 也经常被误读。 很多文章把它写成“多智能体协作很酷”。这个方向当然有想象力，但在 Claude Code 的官方文档里，subagent 首先解决的是一个很具体的问题：当支线任务会产生大量搜索结果、日志或文件内容，淹没主会话时，把它放进独立上下文里做，最后只返回摘要。 这句话很工程。 一个大型排查任务可能要读几十个文件、跑多轮测试、翻很多日志、试几个错误假设。这个过程对最终结论有价值，但过程本身不一定应该进入主上下文。 如果全塞进去，主 Agent 很快会被低密度信息拖慢。 更合理的做法是： * • 主 Agent 保留目标、约束、计划和关键决策； * • Explore subagent 去做大范围搜索和阅读； * • Debug subagent 去吃日志和复现路径； * • Review subagent 用较干净的视角检查最终 diff； * • 主 Agent 只接收高密度结论、证据路径和下一步建议。 这里的重点不在“多了几个角色”。 重点是上下文边界被切开了。 好的 Agent 架构，会让不同密度、不同风险、不同生命周期的信息，在不同上下文里被消化，而不是一股脑进入主会话。 这和我们在《 [ Sub-Agent VS Agent Team：多智能体架构先看上下文边界 ]() 》《 [ Subagents 详解：Claude Code 如何避免上下文污染 ]() 》里聊到的结论也是一致的： 先看上下文边界和读写边界，再谈角色分工。 * * * ## 企业真正要补的是 Harness 把前面几块合在一起，就能看到企业落地 AI Coding 真正缺什么。 问题不只是缺一个检索模块。 也不只是缺一个更长上下文窗口。 更不是把 IDE 里接一个聊天框。 企业真正要补的是 Harness。 这也是我们之前两篇——《 [ Agent 架构关键变化：Harness 正在成为新后端 ]() 》和《 [ Cursor 复盘 Harness：模型决定能力上限，Harness 决定生产下限 ]() 》——能放在同一条线上看的地方。Agent 一旦进入业务系统，状态、权限、trace、恢复这些后端问题都会冒出来；Harness 也不是一次性设计完就摆在那里不动，它需要持续评估、观测、修正、回滚，还要跟着模型一起往前走。 我这里说的 Harness，是模型之外那套让 Agent 能在工程系统里工作的运行底座。它决定 Agent 能看什么、能做什么、能记住什么、能忘掉什么、能否验证自己、能否被人接管、能否留下可审计轨迹。 可以粗略拆成几层： --- Harness 模块 | 主要职责 ---|--- Search Harness | 搜索文件、符号、日志、提交历史、外部文档 Read Harness | 控制读取粒度、分页、preview，避免上下文爆炸 Execution Harness | 运行测试、lint、typecheck、脚本和本地服务 Memory Harness | 保存项目约定、架构决策、反复出现的纠错经验 Compaction Harness | 长任务中压缩历史，保留关键状态和下一步 Isolation Harness | 用 subagent、sandbox、worktree 隔离任务和风险 Policy Harness | 管权限、审批、凭证、危险命令和审计 Evaluation Harness | 用测试、线上信号、代码保留率和失败分类评估质量 Agent Harness 承重层 Anthropic 文档把 Claude Code 称为 Claude 外面的 agentic harness，提供工具、上下文管理和执行环境，让语言模型变成 coding agent。这个定义很重要。 模型负责推理，Harness 负责让推理接上真实工程。 Cursor 的 Harness 复盘也在讲同一件事。它们不只看模型分数，还看离线评测、线上 A/B、Keep Rate、用户后续反应、工具错误率、cache hit rate。对 Cursor 来说，一个 Agent 版本更准确的发布单元，是“模型 + Harness”。 OpenAI Codex 和 GitHub Copilot cloud agent 则把这条线往工程流程里推。Codex 的云端任务跑在独立 sandbox 里，可以读写文件、运行测试、给出 PR；GitHub Copilot cloud agent 在 GitHub Actions 驱动的环境里研究仓库、创建计划、修改代码、运行测试和 linter，并把结果放进 PR 流程。 这说明 AI Coding 的战场正在从“编辑器里补全几行代码”，转向 branch、worktree、sandbox、test、PR、review、CI 这些工程主流程。 所以未来 AI 编程工具的护城河，大概率不会只是聊天框。 ** 真正难的是 Harness：谁能把 Agent 的搜索、执行、验证、权限、上下文和协作流程组织成稳定系统。 ** * * * ## 从 Vibe Coding 到 Agentic Engineering 说到这里，还是要回到 [ Agentic Engineering ]() 。 Simon Willison 最近用 Agentic Engineering 这个词，来指代专业工程师使用 Claude Code、OpenAI Codex 这类 coding agents 来构建软件。这类工具的关键特征，不只是生成代码，还能执行代码、跑测试、根据反馈独立迭代。 这和 Vibe Coding 的边界不太一样。 Vibe Coding 更适合原型、个人工具、低风险探索。它让想法更快变成可运行的东西，这件事本身就很有价值。 Agentic Engineering 关心的则是另一件事：这个结果能不能被审查、被测试、被回滚、被维护，能不能在团队里继续被拥有。这也是我们在《 [ Agent 时代，架构师应该学什么 ]() 》里反复回到的问题。 放到本文这条线里看，两者的差别可以这么理解： Vibe Coding 关心“能不能做出来”。 Agentic Engineering 关心“做出来以后，系统和团队还能不能接得住”。 Claude Code 的 Agentic Search、Cursor 的 semantic search、Codex 的 cloud sandbox、GitHub 的 PR 工作流，看起来是不同产品的不同功能。往下一层看，它们其实都在把 Agent 推进真实工程系统。 一旦 Agent 进入工程系统，问题就不再只是模型会不会写代码。 还要回答： * • 它怎么获得上下文？ * • 它怎么验证假设？ * • 它怎么隔离探索过程？ * • 它怎么压缩长期任务？ * • 它怎么调用确定性工具？ * • 它怎么留下审计和证据？ * • 它怎么在出错时停下来、回滚或交给人？ 这些问题都不是“RAG 和 Grep 谁赢了”能回答的。 它们属于架构问题。 Martin Fowler 给我的提醒也在这里。AI 进入研发链路以后，最大的变化不是我们终于可以少写几行代码，而是一个非确定性的执行者进入了原本依赖确定性反馈的工程系统。搜索、编辑、运行测试这些动作都可以交给 Agent，但目标、边界、验证和责任链不能跟着一起丢。 * * * ## 写在最后 写到这里，我自己越来越倾向于把这次争论看成一个信号，而不是一场胜负。 表面上大家在争 RAG、Grep、Agentic Search 谁更先进。 往深一层看，是 AI 编程工具正在从“模型拿到上下文后生成答案”，慢慢变成“Agent 在工程现场里持续操作上下文”。 这也是我这段时间一直绕回去的那条线： [ 上下文不是聊天记录 ]() ， [ Subagent 不是多智能体炫技 ]() ， [ Prompt Cache 不只是省钱小技巧 ]() ， [ Codex 也不是云端版自动补全 ]() 。 它们其实都在指向同一个变化： ** AI 编程的核心能力，正在从代码生成，迁移到对上下文、工具、执行环境和验证闭环的组织能力上。 ** RAG 还会继续存在，语义索引也会继续存在，Grep、glob、ripgrep 这些老工具更会继续存在。 真正会变的，是它们不再孤立地作为“检索模块”坐在那里，而会被放进 Agent 的工程循环里，被 Harness 调度、约束、观察和评估。 对架构师来说，接下来更值得花力气练的能力，可能不是追一个又一个新名词。 而是把这个问题想清楚： 当 Agent 可以自己搜索、阅读、执行、验证、修改系统时，我们到底要给它怎样的上下文边界、工具边界、权限边界和验证边界？ 这个问题答得越清楚，AI Coding 就越像工程，而不是魔法。 * * * ## 参考来源 * • Latent Space: Claude Code: Anthropic's Agent in Your Terminal https://www.latent.space/p/claude-code * • Anthropic Claude Code Docs: How Claude Code works https://code.claude.com/docs/en/how-claude-code-works * • Anthropic Claude Code Docs: Explore the context window https://code.claude.com/docs/en/context-window * • Anthropic Claude Code Docs: Subagents https://code.claude.com/docs/en/sub-agents * • Anthropic Docs: Prompt caching https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching * • Cursor: Improving agent with semantic search https://cursor.com/blog/semsearch * • Cursor: Continually improving our agent harness https://cursor.com/blog/continually-improving-agent-harness * • OpenAI: Introducing Codex https://openai.com/index/introducing-codex/ * • OpenAI Codex https://openai.com/codex/ * • GitHub Docs: Copilot cloud agent https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent * • GitHub Blog: Agent HQ https://github.blog/news-insights/company-news/pick-your-agent-use-claude-and-codex-on-agent-hq/ * • Simon Willison: Writing about Agentic Engineering Patterns https://simonwillison.net/2026/Feb/23/agentic-engineering-patterns/ * • GrepRAG: An Empirical Study and Optimization of Grep-Like Retrieval for Code Completion https://arxiv.org/abs/2601.23254 如喜欢本文，请点击右上角，把文章分享到朋友圈 如有想了解学习的技术点，请留言给若飞安排分享 ** 因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享 ** ** ·END· ** **相关阅读：** [刚刚，Claude Code“代码泄露”背后：如何重新看 Agent Harness]() [大家都在讲 Harness，但它到底该怎么理解]() [模型越来越强，为什么大家却开始重写 Harness]() [如何让单个 Agent 做长任务不失真：Anthropic 给出了一套更工程化的答案]() [Claude Code高手的 8 个 Claude Code 实战习惯]() [别从 README 开始：一个架构师会怎样翻 Codex 仓库]() [Spec 不是代码的替代品，它是 AI Coding 的上下文管理层]() [如何让 Agents 自己设计、升级 Agents]() [OpenAI怎么把开源项目维护做成工作流：Skills、AGENTS.md 和 CI 的一套组合拳]() [Claude Skills 入门：把“会用 AI”变成“可复制的工程能力”]() [一套可复制的 Claude Code 配置方案：CLAUDE.md、Rules、Commands、Hooks]() [Claude Code 最佳实践：把上下文变成生产力（团队可落地版）]() [把 AI 当成新同事：Agent Coding 的上下文与验证体系]() [一周写百万行的背后：Cursor长时间运行 Agent 的工程方法论]() [2026年生活重启指南]() [我真不敢相信，AI 先加速的是工程师。]() [扒一扒 Claude Cowork 系统提示词：Anthropic 如何打造数字同事]() [Cowork 安全架构深度解析：从 Claude Code 到 Cowork，Anthropic 如何把“可控”做成产品]() [Anthropic官方万字长文：AI Agent评估的系统化方法论]() [银弹还是枷锁？Claude Agent SDK 的架构真相]() [Claude Code创始人亲授13条使用技巧]() [Claude Code 内部工具开源 code-simplifier：终结 AI 屎山代码的终极方案]() > 版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢! ** 架构师 ** 我们都是架构师！ **** 关注 ** 架构师(JiaGouX)，添加“星标” ** ** 获取每天 AI 技术干货，一起成为牛逼架构师 ** ** AI/Agent群请 ** ** 加若飞： ** ** 1321113940 ** ** 进群 ** 投稿、合作、版权等邮箱： ** admin@137x.com **