Coding Agent 到底是怎么工作的，它又为什么会在复杂代码库里失真？

前言：打破黑盒

很多开发者对 AI 编程助手有两个根深蒂固的误解。

第一，把它当"黑盒"------输入需求就期待输出完美代码。

第二，认为模型有百万级上下文窗口，只要把背景信息交代得够多，效果就会更好。

在处理简单、独立的小任务时，这种模式确实高效。但在真实的企业级项目中------几十万行代码、上百个组件、跨模块的业务逻辑、新旧代码共存------这种"黑盒模式"很快就会崩溃。

你会发现 AI 开始胡说八道（幻觉）、无视架构约定，甚至写出"技术上正确但业务上致命"的代码。

之前发布过一篇文章介绍了 Harness Engineering，其中总结了OpenAI、Anthropic 和 Lang Chain 等 Harness 方法论、踩坑指南和实践建议。

但是，其中所有公开的成功案例都涉及绿地项目（没有遗留代码）或从零构建的 Harness。将这些技术应用到有十年历史、没有架构约束、测试不一致、文档残缺的代码库上，是一个更复杂的问题。

第一篇 原理篇

这一篇回答最基础的问题：Coding Agent 到底是怎么工作的，它又为什么会在复杂代码库里失真？

第 1 章 Coding Agent 的工作原理

1.1 LLM 的本质：自回归 + Attention 机制

要理解 Coding Agent 为什么会犯错，首先要理解它的"大脑"是怎么运作的。

大语言模型（LLM）做的事情本质上只有一件：预测下一个 token。它没有独立于输出的"思考"过程------推理即生成，生成即推理。每次只产出一个 token，然后将它加入已有序列，继续预测下一个。这个过程叫做自回归。

那模型在每一步是怎么"看前面的内容"的？这就是 Attention 机制的工作了。

你可以把它想象成一个动态的聚光灯------模型在生成新内容时，会扫视整个上下文窗口中的所有内容，对不同位置分配不同的权重（"注意力"）。

理论上，这个聚光灯可以照到任何位置。

但实践中，它有几个致命的物理限制：

特性	技术含义	对编程的影响
注意力稀疏且有偏	模型不会均匀关注所有内容，倾向于偏好开头和结尾	放在中间的关键代码逻辑可能被忽略
计算复杂度 O(N²)	上下文长度翻倍，计算量和显存都变 4 倍	不能无限制地往上下文里塞文件
注意力权重被稀释	上下文越长，每个 token 分到的"关注份额"越少	几十个文件混在一起，关键信息可能被"淹没"

更重要的是，自回归在编程场景 中会产生幻觉雪球效应。

软件开发是一个"长链路、强约束"的活动------一旦模型在早期猜错了一个函数名（比如因为注意力稀释没找到正确的 API），后续每一步它都会在这个错误基础上继续"自洽地续写"，越来越"相信这个函数存在"，直到编译报错才被打回原形。

理解了自回归 + Attention 的本质，你就能明白两件事：

• 第一：模型的"推理"本质上是一种概率续写，而非逻辑推演；
• 第二：上下文的质量比数量重要得多------塞进 50 个文件并不会让模型更聪明，反而会让关键信息的信号被稀释。

1.2 强化学习（RL）：从"会说话"到"会做事"

预训练只是让模型通过海量 GitHub 源码学会了"代码看起来应该是什么样"。它就像一个看过了所有烹饪书但从没进过厨房的人------知道菜谱长什么样，但并不会做菜。

真正让 Coding Agent 具备"行动能力"的是强化学习（Reinforcement Learning） 。与其告诉模型"怎么做对"，RL 只定义"什么叫做到了"------这与软件开发的哲学完美一致：不管怎么写，测试通过了就行。

现代 Coding Agent 背后的模型通常经历过这样的 RL 训练：

• 在模拟环境中执行编程任务
• 用测试通过率和代码质量评分作为奖励信号
• 学习何时应该读取更多文件、何时直接修改、如何从错误信息中提取线索。

实操启示：对齐 RL 的奖励信号

理解了 RL，你就懂了该怎么给 Agent 下指令：

• ❌ 糟糕的指令："帮我修一下登录的 bug。"
• ✅ 优秀的指令："修复登录会话未保存的问题，运行 npm test 应全部通过。"

对人类来说差别不大，但对 Agent 来说，后者提供了明确的成功标准，完美对齐了它在 RL 训练中习得的"奖励信号"模式。

目标越清晰、越可验证，Agent 表现越好。

1.3 Agent Loop：核心运行循环

语言模型可以回答问题，而 Agent 可以做事情。两者最大的区别，在于后者不是一次性给出答案，而是进入一个循环：

调用模型 → 决定下一步动作 → 执行工具 → 把结果写回上下文 → 再次调用模型

这就是 Agent Loop。

以一个实际场景来说明------用户请求"修复用户登录后会话没有正确保存的 bug"：

轮次	Agent 行为
第 1 轮	模型收到请求，调用 list_directory 查看项目根目录
第 2 轮	识别出 src/auth/ 目录，调用 read_file 查看 login.js
第 3 轮	发现调用了 sessionManager.save()，继续读 session/manager.js
第 4 轮	发现 save() 中异步操作未 await，调用 edit_file 修复
第 5 轮	调用 shell 工具运行测试验证
第 6 轮	测试通过，生成最终响应总结修复内容

注意一个关键细节：每一轮工具调用的结果都会被写回上下文窗口。

这意味着上下文在不断膨胀------读取的文件内容、命令输出、错误日志，全都累积在有限的窗口里。这就是为什么长任务容易失败：上下文被工具输出"污染"了。

第 2 章 上下文越长，效果不一定越好

理解了 LLM、强化学习和 Agent Loop 之后，下一个问题就很自然：既然 Coding Agent 已经具备了理解、行动、验证和修正的能力，它的边界到底在哪里？

很多人的第一反应是："边界来自上下文窗口不够大。"这句话只说对了一半。上下文窗口当然重要，但真正的问题不只是"能不能装下"，而是：

装进去之后，模型还能不能稳定、准确地利用这些信息。

因此，Coding Agent 的上下文问题，其实要分成两层来看：

• 第一层是容量限制：模型和工具到底能容纳多少输入。
• 第二层是利用限制：即使上下文已经放进去了，模型是否还能真正抓住其中最重要的部分。

真正决定效果的，往往是第二层。

2.1 物理上限与"有效窗口"

每个模型都有上下文窗口上限。这个上限不是一个随意标注的产品数字，而是由底层计算代价决定的。传统 Attention 机制的计算和存储成本，通常会随着输入长度快速上升。上下文越长，推理速度越慢，显存和算力压力也越大。

这意味着，所谓"支持更长上下文"，本质上只是说： 模型在物理上可以接收更多输入。

但这并不能自动推出另一个结论：模型已经具备了在这个长度下稳定理解这些输入的能力。

这也是为什么，开发者不能把长上下文窗口理解成一个万能解法。它解决的只是"输入容量"问题，而不是"理解质量"问题。

2.2 Context Rot

Chroma 的 Context Rot 研究表明，随着输入长度增加，模型性能往往不会稳定维持，而会出现不同程度的下降；并且当"问题"和"相关信息"之间的语义距离较远时，这种退化会更加明显。

这项研究的实际意义非常深远：你在 Agent 工作流中每一次 grep 的执行结果、每一次文件读取的内容，如果最终被证明与任务无关，都会成为"注意力污染物"，拖累模型在后续步骤的表现。

换句话说，在真实任务里，麻烦往往不在于模型有没有看到信息，而在于：模型虽然看到了信息，却没有稳定地抓住真正重要的那部分。

这正是长上下文最容易被误解的地方:

很多开发者会把需求文档、架构说明、接口定义、代码片段、历史讨论一次性全部丢给模型，直觉上觉得"信息越充分越好"。但现实中，这种做法常常会适得其反。原因并不复杂：

• 输入越长，注意力就越容易被稀释
• 无关信息越多，关键线索就越容易被淹没
• 如果问题与答案之间隔得很远，模型更容易抓错"看起来相关"的局部信息

所以，长上下文真正带来的挑战不是"能不能提供更多信息"，而是： 如何避免让更多信息变成更多噪音。

2.3 Lost in the Middle：注意力的 U 型曲线

比 Context Rot 更早被发现的是 "Lost in the Middle" 现象。2024 年，斯坦福大学 Nelson F. Liu 等人在 TACL（Transactions of the Association for Computational Linguistics）上发表的研究揭示了一个关键发现：LLM 对上下文中不同位置信息的注意力遵循 U 型曲线------开头和结尾获得的注意力最高，而中间部分最容易被忽略。

在包含 20 个文档的多文档问答测试中，当正确答案所在的文档被放在第 5--15 的位置（即中间段），模型的准确率比放在第 1 或第 20 位时下降了超过 30%。

这对 Coding Agent 的影响是直接的：当 Agent 搜索一个函数名并读取了 8 个文件，排在第 4 个文件中的关键代码正好落在模型的注意力"盲区"。

核心结论： 上下文管理不是"把东西塞进去就行"，而是一门需要精心设计的工程学科。更少但更精准的上下文，胜过更多但更嘈杂的上下文。

这就是为什么 Coding Agent 需要精心设计上下文管理策略------正如 Anthropic 在其 Context Engineering 博客中所说的："上下文是一种有限资源，具有递减的边际回报。"

2.4 当前 Coding Agent 的三类根本局限

第一，偏差累积不可逆。

一旦前面某一步理解走偏，后面的推理和生成通常会在这个偏差上继续展开。在代码任务里，这种偏差经常表现为"局部自洽"------单行代码合理、函数调用形式也对、命名风格甚至保持一致------但如果早期对函数职责或接口语义理解错了，后面每一步都在错误前提上继续"认真地写对代码"。

很多 AI 代码的问题，不是完全不会，而是局部正确、整体错误。

第二，多重约束处理能力有限。

真实开发中的约束------语法、语义、目录结构、旧逻辑兼容、测试通过、性能不退化、安全边界、团队规范------通常同时成立。

但对 Agent 来说，这些约束往往不是被完整、稳定地同时建模的。一旦任务链条拉长，就容易顾此失彼：修了 bug 却破坏了兼容性，满足了功能却忽略了项目规范。

第三，天然偏向串行探索。

资深开发者面对复杂问题会先保留多个假设再逐步排除，但大多数 Agent 仍更偏向串行探索------先查一个方向、试一步、再根据结果往下走。

这容易"过早深入某条路径"，在错误方向上花太多成本。

到这里，我们已经知道 Agent 为什么会失真。接下来的问题就是：如果失真不可避免，工具层究竟在怎样补偿它？

第二篇 工具篇

这一篇不做编程Agent"谁更强"比较，而是回答：不同工具到底在用什么机制，补偿 Agent 对复杂代码库理解不稳定的问题？

第 3 章 四种 AI 编程路线：它们到底是怎么理解代码库的

3.1 不要只比较模型，要比较"上下文系统"

如果只从模型参数看主流 Coding Agent，很多差异其实解释不了。

在真实项目里，决定效果的往往不是"模型会不会写代码"，而是它如何进入代码库、如何拿到约束、如何形成行动闭环，以及这些能力能否沉淀为长期可复用的项目资产。

因此，理解工具差异，不能只看它用了哪个模型，而要看它背后的上下文系统。这里至少有五个关键维度。

第一，上下文如何进入模型 。

它是主要依赖语义检索、文件搜索、目录扫描这类"从仓库中找相关内容"的方式，还是更多依赖 spec、rules、steering、skills 这类"显式供给知识"的方式。

第二，约束如何被持久化 。

项目规范、开发流程、页面模式和交付要求，是只存在于一次会话里的临时提示，还是已经沉淀为仓库中的规则文件、结构化文档和长期知识入口。

第三，行动如何形成闭环 。

Agent 是主要停留在"给出建议"层，还是能够真正读文件、改文件、运行命令、拿到反馈，并在反馈基础上继续修正。

第四，外部能力如何接入 。

工具是否支持 MCP、hooks、subagents、commands、plugins、skills 这类扩展机制，以便把额外能力接入到当前任务链路中。

第五，团队如何治理 。

这些能力究竟只是某个开发者的个人技巧，还是能够沉淀为项目级、团队级的共享能力，成为稳定的工程资产。

只有把主流工具放在这五个维度上看，我们才能真正理解：它们的差异并不只是"谁更聪明"，而是谁在用什么方式补偿 Coding Agent 对复杂代码库理解不稳定的问题。

需要说明的是，今天的 Cursor、Claude Code、Codex CLI、Kiro 都已具备完整的 Agent Loop 能力------读文件、改文件、运行命令、迭代修正。

它们也都支持 MCP、subagents、skills 等扩展机制。在知识格式上，Agent Skills（SKILL.md）和 AGENTS.md 已开始成为跨工具互通的开放标准。

因此，本章比较的不是"谁有什么能力、谁没有"，而是每条路线最优先做深的差异化方向。

3.2 Cursor：IDE 原生 Agent 平台，率先做深检索与上下文召回

Cursor 是目前最成熟的 AI-first IDE 之一。它基于 VS Code 构建，具备完整的 Agent 模式------能够规划多步任务、编辑多个文件、运行终端命令，并循环迭代直到测试通过或错误解决。

2026 年 1 月的 2.4 版本引入了 subagents（独立运行在各自上下文窗口中、可并行处理子任务的子代理）和 Agent Skills（SKILL.md 格式的动态能力包）。

2 月的 2.5 版本更进一步推出了 plugins 机制，将 skills、subagents、MCP servers、hooks、rules 打包为可安装的单元，并建立了 Cursor Marketplace（参见 Cursor Changelog 2.4、2.5）。

此外，Cursor 还推出了 Cloud Agents（在云端隔离虚拟机中自主运行、可从 web、Slack、GitHub 等入口触发）和 Automations（基于事件或定时触发的自动化 Agent 工作流）（参见 Cursor Blog: Cloud Agents, Automations, Self-hosted Cloud Agents, 2026）。

但在所有这些能力之中，Cursor 最先做深、也最有差异化的方向，是在 IDE 环境内把代码库级检索与上下文召回做好。

在真实项目里，很多错误并不是因为模型不会生成，而是因为它最开始就找错了地方。

它可能读了看起来相似但职责不同的模块，抓住了局部命名相近却语义并不一致的实现，或者忽略了真正决定行为的规则文件与历史约束。这样一来，后续推理再完整，也很可能是在错误前提上继续展开。

Cursor 在这方面投入了大量工程：

• 它通过语义搜索深度索引整个代码库，当你首次打开一个项目时，Cursor 会在后台扫描并索引整个代码库，一旦代码库索引完成，就能实现语义搜索。并在每次 Agent 会话开始前就建立了对仓库结构的理解。
• 它的 rules 系统支持项目级（.cursor/rules/）、用户级、团队级和 Agent 级（AGENTS.md）四层规则，确保项目约束在每次交互中都被稳定传递。
• skills 的动态加载机制，则避免了把所有知识一次性塞进上下文。

向量语义索引

Cursor 在你打开项目时，就在后台悄悄建了一张"代码地图"。

扫描所有文件
   ↓
 按函数 / 类 / 逻辑块语义切分（不是按行数硬切）
   ↓
 每个代码块 → 生成语义向量（embedding）
   "verifyCredentials()" 的向量在数学上接近 "用户鉴权" 的向量
   ↓
 向量存入数据库（Turbopuffer）
   ↓
 你提问 → 问题也被向量化 → 搜索最近邻 → 召回相关代码块
   ↓
 代码块 + 你的问题 → 一起喂给 LLM

这套机制叫 RAG（检索增强生成） 。即使 verifyCredentials() 函数名里一个 "auth" 都没有，只要语义接近"验证用户身份"，就能被召回。

关键细节：切分时按语法结构而非行数------完整的函数是一块，完整的类是一块，语义内聚，召回质量高于随机截断。

限制：Embedding 存于 Cursor 服务器（原始代码留本地）；超大仓库（100K+ 文件）初始建索引 CPU/RAM 占用较高。

差异化重点：率先把"从大型仓库中准确召回相关内容"这件事做深，并把这种能力原生嵌入了 IDE 工作流。

3.3 Claude Code：把探索过程做成可编排、可治理的 Agent 系统

如果说 Cursor 更强调在 IDE 内把检索和交互体验做深，那么 Claude Code 所代表的路线，则更强调另一件事：代码理解并不是一次性完成的，而是在探索、执行、反馈和修正的循环中逐步形成的------而且这个循环本身需要可编排、可分工、可治理。

这条路线补偿的，其实不是单纯的"找不到"，而是另一类在真实开发中更常见的问题：很多任务即使找到了相关文件，也仍然不能立刻得出结论。

因为真正的理解往往要靠：

• 继续追踪调用链
• 运行命令看反馈
• 比较不同实现路径
• 在失败中修正判断
• 把探索结果不断回写到任务上下文中

实时 Grep 探索

Claude Code 工程师在 Hacker News 公开说明：不使用 RAG，没有预建索引。它的策略是给 AI 一套文件系统工具，让它自己翻代码：

你问："鉴权逻辑在哪？"
   ↓
 Claude 调用工具探索：
   grep -r "auth" . → 返回 87 个匹配
   grep -r "guard" . → 返回 23 个匹配
   glob "**/*.interceptor.ts" → 找到拦截器文件
   read "auth.interceptor.ts" → 读取内容，继续追踪
   ↓
 最终定位到鉴权逻辑 

这个过程十几轮工具调用，每轮消耗 token，所以相同任务 token 消耗是 Codex 的 3--4 倍 。

弥补手段有两个：一是 1M token 的超大上下文窗口，可以把整个模块的代码直接装进去，绕开语义弱点；二是在项目根目录维护 CLAUDE.md，手动写明"鉴权逻辑在 src/core/interceptors/，入口是 AuthInterceptor"------给 Claude 一张手绘地图，跳过探索过程。

差异化重点：当代码库复杂到无法被一次性读懂时，帮助 Agent 组织探索过程本身------包括分工、通信、治理和结果整合。

3.4 Codex：执行与验证快速闭环

Codex 这条路线与前两者又有所不同。它的差异化方向，在于它把代码理解、文件修改、命令执行和结果验证压缩进了一个低摩擦、快速可验证的闭环。

这条路线隐含的判断是：并不是所有问题都需要先建立大范围上下文理解。对于大量真实开发任务来说，更关键的是尽快进入一个低摩擦的、本地可验证的循环------读仓库 → 改文件 → 跑命令 → 看结果 → 继续修正。

这种工作方式特别适合那些目标相对明确、反馈速度快、验证路径清晰的任务。例如修 lint、补测试、改脚本、做批量替换、修一个边界清晰的问题。这些任务不一定缺少理解，很多时候真正缺的是一个足够顺滑的本地执行与验证回路。

从这个角度看，Codex 优先做深的不是"上下文如何召回"或"探索如何编排"，而是另一类非常实际的缺口：任务能否快速进入一个可验证、可收敛的终端工作循环。

Codex 真正擅长的场景：批量生成单元测试（给它一批文件，让它统一补测试）、跑并行的独立任务（同时提交 5 个不相关的小改动）、不想被打断时的后台任务（提交完继续开会，回来看 PR）。开发者的普遍描述是"值得信任的长时间任务执行器，但不是能陪你边聊边改的协作者"。

这条路线的重要性在于，它提醒我们：Coding Agent 的有效性，不只取决于"它看到了多少上下文"，还取决于"它能否在最短路径内拿到真实反馈"。而一旦真实反馈能够快速进入循环，很多原本模糊的判断就会在执行中被压实。

差异化重点：通过执行与验证闭环，降低任务收敛成本。

3.5 Kiro：不是先找代码，而是先把任务和长期知识结构化

Kiro 是 AWS 旗下的 AI IDE，基于 VS Code 构建，同样具备完整的 Agent Loop 能力。但它的差异化重点不在于执行层，而在于任务起点和长期知识层 。

Kiro 是这几款工具里设计哲学最独特的一个。它解决的问题不是"怎么找到代码"，而是"怎么让 AI 在写代码之前就真正搞清楚你要做什么"。

很多失真并不是从"改代码"那一刻才开始，而是从任务定义不清、长期知识没有显式接上时就已经发生了。

核心理念：先规格，再动手

Kiro 的出发点是针对"vibe coding"（凭感觉提示）的反思：一通 prompt 下来代码能跑，但 AI 做了哪些假设？边界条件考虑了吗？架构决策记录在哪？Kiro 的回答是------强制走一套结构化流程，在写任何代码之前把意图固化为文档。

Kiro 通过三层机制实现这一点：

第一层：Specs（规格驱动开发）

用户描述需求后，Kiro 将其转化为 requirements.md、design.md和 tasks.md，在编码之前先把"到底要完成什么"结构化。

用一个真实例子说明

你输入："给电商系统加一个商品评价功能"

第一步：Requirements（需求）
   Kiro 自动展开为用户故事 + 验收标准：
   - 用户可以对已购买商品留评（1-5星 + 文字）
   - 评价需在购买后 90 天内提交
   - 店铺可以公开回复评价
   - 评价显示排序：最新优先，可切换"最有用"
   → 生成 requirements.md（可修改）

第二步：Design（技术设计）
   Kiro 分析现有代码库后生成：
   - 数据库 Schema（Review 表结构、外键关系）
   - API 端点列表（POST /reviews, GET /products/:id/reviews...）
   - TypeScript 接口定义
   - 数据流图（Mermaid 格式）
   → 生成 design.md（可修改）
 
第三步：Tasks（实现任务）
   Kiro 按依赖顺序排列任务：
   ☐ Task 1: 创建 Review 数据库模型
   ☐ Task 2: 实现 POST /reviews API（含单测）
   ☐ Task 3: 实现 GET /reviews API（分页、排序）
   ☐ Task 4: 前端评价表单组件
   ☐ Task 5: 前端评价列表展示
   → 生成 tasks.md，每个任务关联至对应需求

第四步：执行
 点击某个 Task 的"Start Task"，Kiro 开始写代码 

这三个文件（requirements.md / design.md / tasks.md）都是版本控制的 Markdown 文件 ，存在 .kiro/specs/ 目录下，可以 diff、review、追溯。

实际效果：一位开发者记录，写一个数据格式转换功能的 spec 花了 2 小时，但节省了 2 周的反复试错。86.5% 的测试覆盖率是另一个副产品------因为每个 Task 里 Kiro 默认包含对应的单测。

第二层：Steering：让 Kiro 记住你的项目约定

除了 Spec，Kiro 还有 Steering 文件机制------相当于 Kiro 的长期记忆。运行一次 Kiro: Setup Steering for Project 自动生成：

.kiro/steering/
   product.md ← 产品定位、功能、目标用户
   structure.md ← 目录结构和组织逻辑
   tech.md ← 技术栈和开发工具 

你也可以手动添加，比如创建 architecture.md 写入"所有 API 必须走 BFF 层，禁止前端直连数据库"，此后 Kiro 的每次回答都会遵守这条约束。

项目规范、编码约定、技术栈偏好、部署流程等长期知识存放在 .kiro/steering/ 目录中，支持 always、auto、fileMatch和 manua四种包含模式，确保 Agent 在不同场景下拿到恰当的知识而非全量信息。Kiro 同时兼容 AGENTS.md 开放标准，放在工作区根目录即可被自动读取。

适合和不适合的场景

适合：复杂功能开发、有多人协作的团队（spec 文档是副产品，新成员可以直接读）、需要可追溯性的受监管行业、AWS 云原生项目（原生集成 Lambda / S3 / DynamoDB 上下文）。

不太适合：快速小改动（spec 流程有前期开销）、"帮我在这个函数里加一行日志"这类即时任务------直接用 chat 模式，不需要走 spec 流程。

第三层：skills（技能包）

与 Cursor 和 Claude Code 采用相同的 SKILL.md 格式，skills 是可按需激活的领域知识和工作流包。

这条路线修补的是两类很根本的缺口:

• 第一类：任务边界缺口。
  很多 AI 失真并不是因为不会写，而是因为一开始就没有把"到底要完成什么""哪些约束不能动""什么算完成"定义清楚。一旦任务边界模糊，后续每一步都会越来越漂。Kiro 的 specs 机制把需求、设计和任务拆解变成了编码之前的显式输入。
• 第二类：长期知识缺口。
  真实项目里有大量关键知识，并不直接写在当前文件里，而是分散在长期规范、设计决策、历史模式和团队约定之中。如果这些知识在任务开始前就没有被明确接入，Agent 很容易在局部看似合理、整体却偏离项目方式。Kiro 的 steering 和 skills 机制把这些长期知识变成了可持久化、可按场景路由的显式输入。

因此，Kiro 的关键并不是"让搜索更强"，而是让需求、规则、模式和长期知识在任务开始前就先被显式化和结构化。

这条路线尤其重要。因为它已经开始逼近一个更深层的问题：当工具越来越重视 spec、steering、skills 这类长期知识入口时，真正需要被建设的，就不再只是一次会话中的上下文，而是项目层、团队层的知识供给结构。

差异化重点：让需求、规则和长期知识在编码开始前就被显式结构化，避免失真从任务起点就开始。

3.6 小结：工具在趋同，知识供给才是分水岭

把四条路线放回同一个框架里看，就会发现：它们并不是在做同一件事，只是实现方式不同；更准确地说，它们分别在把不同类型的上下文缺口做深、做透。

路线	差异化重点
Cursor	索引化 + 显式引用：依托 IDE 建立持久化索引，上下文主要通过主动检索（如 @ 符号、代码引用）显式注入，由云端并行 Agent 处理大范围代码片段，上下文范围清晰可控，但灵活性依赖用户主动选择。
Claude Code	动态探索 + 代理共享：支持代理在任务执行中自主检索和发现相关上下文，多代理之间可共享与合并上下文，强调"边探索边判断"，上下文范围随探索路径动态扩展，治理机制防止上下文爆炸。
Codex	短会话 + 流水线传递：上下文以命令执行为中心，多 Agent 按流水线串联，每个环节的输出结构化为下一环节的输入，上下文生命周期短、传递明确，适合快速验证和可复现的流程，但缺乏长期记忆。
Kiro	显式结构化 + 持久化知识库：将需求、设计决策、领域知识预先结构化，作为长期上下文持久化存储，任务执行时主动引用这些结构化信息，上下文高度显式化且可追溯，适合需要保持知识一致性的复杂项目。

而随着能力趋同和知识格式互通，工具选择问题最终会收束到一个更根本的问题：项目本身的知识供给是否到位。

Cursor 的向量索引再强，也需要正确的 .cursorrules 约束才能不乱用组件。

Claude Code 的推理再深，也需要 CLAUDE.md 告诉它"禁止使用 any 类型"。

Kiro 的 Spec 再完整，也需要 Steering 文件记录项目历史决策。

这意味着真正的差异化竞争力，在于建立一套可持续维护的 AI 知识工程体系：

代码库
  ↓ 逆向提取
规范文档（CLAUDE.md / .cursorrules / Steering 文件）
  ↓ 注入
AI Agent（Cursor / Claude Code / Kiro）
  ↓ 生成
新代码
  ↓ 持续同步
规范文档（闭环）

工具会迭代，模型会升级，但结构化的项目知识资产会随团队积累而增值。这才是 AI Friendly 工程化的真正护城河。

最后更新：2026 年 3 月 | 本文基于公开资料和实测数据，工具功能更新频繁，请以官方最新文档为准。

附录：主流基准

业界有两个主流基准，测的是完全不同的事情：

SWE-bench Verified：给 AI 一个真实的开源仓库和一份 Bug 描述，让它自己定位问题、修改代码、跑测试，全程不能提示。这考验的是"能不能独立解决复杂工程问题"。

Terminal-Bench 2.0：一批终端任务，考验 AI 执行命令、处理输出、完成操作的速度和准确率。更接近"日常批量任务"的场景。

2026 年 3 月数据：

基准	第一	得分	第二
SWE-bench Verified	Claude Code	80.8%	Codex CLI ~80%
Terminal-Bench 2.0	Codex CLI	77.3%	---
推理速度	Codex CLI	240+ token/s	约为 Claude Opus 的 2.5 倍

怎么理解这个差距？

SWE-bench 80.8% 意味着：给 Claude Code 100 个真实 Bug，它能独立修好约 80 个，剩下 20 个需要人介入。这在两年前是不可想象的。

Codex 速度快但推理浅------开发者在 Reddit 的普遍反馈是"直接任务很准，复杂架构决策容易犯低级错误"。

对日常工作的含义 ：

如果你的任务是"写一个标准 CRUD 接口"，两款工具都能完成，Codex 快很多；如果是"找出这个竞争条件的根因并修复"，Claude Code 的推理深度有明显优势。

附录：参考资料

原理与研究

• Chroma, "Context Rot: How Increasing Input Tokens Impacts LLM Performance," July 2025 --- research.trychroma.com/context-rot

Cursor

• Cursor Docs: Agent Overview --- cursor.com/docs/agent/...
• Cursor Blog: Best Practices for Coding with Agents --- cursor.com/blog/agent-...
• Cursor Changelog 2.4: Subagents, Skills --- cursor.com/changelog/2...
• Cursor Changelog 2.5: Plugins --- cursor.com/changelog/2...
• Cursor Blog: Cloud Agents --- cursor.com/blog/cloud-...
• Cursor Blog: Self-hosted Cloud Agents --- cursor.com/blog/self-h...

Claude Code

• Claude Code Docs: Sub-agents --- code.claude.com/docs/en/sub...
• Claude Code: Agent Teams --- code.claude.com/docs/en/age...
• Claude Code Docs: Hooks --- code.claude.com/docs/en/hoo...

Codex CLI

• Codex CLI Overview --- developers.openai.com/codex/cli
• Codex CLI Features --- developers.openai.com/codex/cli/f...
• Codex MCP --- developers.openai.com/codex/mcp
• OpenAI: Use Codex with the Agents SDK --- developers.openai.com/codex/guide...

Kiro

• Kiro 官网 --- kiro.dev
• Kiro Docs: Steering --- kiro.dev/docs/steeri...
• Kiro Docs: Agent Skills --- kiro.dev/docs/skills...
• Kiro Blog: Custom Subagents, Skills --- kiro.dev/blog/custom...

关于 OpenTiny NEXT

OpenTiny NEXT 是一套企业智能前端开发解决方案，以生成式 UI 和 WebMCP 两大核心技术为基础，对现有传统的 TinyVue 组件库、TinyEngine 低代码引擎等产品进行智能化升级，构建出面向 Agent 应用的前端 NEXT-SDKs、AI Extension、TinyRobot智能助手、GenUI等新产品，实现AI理解用户意图自主完成任务，加速企业应用的智能化改造。

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～

OpenTiny 官网：opentiny.design

GenUI SDK 代码仓库：github.com/opentiny/ge... （欢迎star ⭐）

TinyRobot 代码仓库：github.com/opentiny/ti... （欢迎star ⭐）

NEXT SDK 代码仓库：github.com/opentiny/we... （欢迎star ⭐）

如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~如果你有任何问题，欢迎在评论区留言交流！