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

关注

原创 2026-07-13 14:25:11 613 阅读 AI 写同款· GEO 优化 ›

大模型长上下文失忆难题：Context Ledger架构如何提升Coding Agent代码理解能力在AI编程助手（Coding Agent）的开发实践中，Transformer架构的自注意力机制面临长上下文处理的固有挑战。当序列长度扩展至百万token级别时，注意力权重稀释效应和位置编码衰减会导致模型出现信息遗忘现象，即无法有效利用远距离的代码定义和系统指令。这一技术瓶颈限制了AI助手在复杂软件开发中的实际应用价值。为解决此问题，业界提出了Context Ledger（上下文账本）架构，通过解耦存储与推理、建立结构化索引和实现按需检索，将线性的上下文记忆转化为可精准查询的项目知识库。该方案能有效应对代码阅读详情

前言：打破黑盒

很多开发者对 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 月 | 本文基于公开资料和实测数据，工具功能更新频繁，请以官方最新文档为准。

附录：参考资料

原理与研究

Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” July 2025 — https://research.trychroma.com/context-rot

Cursor

Cursor Docs: Agent Overview — https://cursor.com/docs/agent/overview
Cursor Blog: Best Practices for Coding with Agents — https://cursor.com/blog/agent-best-practices
Cursor Changelog 2.4: Subagents, Skills — https://cursor.com/changelog/2-4
Cursor Changelog 2.5: Plugins — https://cursor.com/changelog/2-5
Cursor Blog: Cloud Agents — https://cursor.com/blog/cloud-agents
Cursor Blog: Self-hosted Cloud Agents — https://cursor.com/blog/self-hosted-cloud-agents

关于 OpenTiny NEXT

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

欢迎加入 OpenTiny 开源社区。添加微信小助手：opentiny-official 一起参与交流前端技术～
OpenTiny 官网：https://opentiny.design
GenUI SDK 代码仓库：https://github.com/opentiny/genui-sdk （欢迎star ⭐）
如果你也想要共建，可以进入代码仓库，找到 good first issue标签，一起参与开源贡献~如果你有任何问题，欢迎在评论区留言交流！