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 RotChroma 的 Context Rot 研究表明随着输入长度增加模型性能往往不会稳定维持而会出现不同程度的下降并且当“问题”和“相关信息”之间的语义距离较远时这种退化会更加明显。这项研究的实际意义非常深远你在 Agent 工作流中每一次 grep 的执行结果、每一次文件读取的内容如果最终被证明与任务无关都会成为注意力污染物拖累模型在后续步骤的表现。换句话说在真实任务里麻烦往往不在于模型有没有看到信息而在于模型虽然看到了信息却没有稳定地抓住真正重要的那部分。这正是长上下文最容易被误解的地方:很多开发者会把需求文档、架构说明、接口定义、代码片段、历史讨论一次性全部丢给模型直觉上觉得“信息越充分越好”。但现实中这种做法常常会适得其反。原因并不复杂输入越长注意力就越容易被稀释无关信息越多关键线索就越容易被淹没如果问题与答案之间隔得很远模型更容易抓错“看起来相关”的局部信息所以长上下文真正带来的挑战不是“能不能提供更多信息”而是如何避免让更多信息变成更多噪音。2.3 Lost in the Middle注意力的 U 型曲线比 Context Rot 更早被发现的是“Lost in the Middle”现象。2024 年斯坦福大学 Nelson F. Liu 等人在 TACLTransactions 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 SkillsSKILL.md和 AGENTS.md 已开始成为跨工具互通的开放标准。因此本章比较的不是谁有什么能力、谁没有而是每条路线最优先做深的差异化方向。3.2 CursorIDE 原生 Agent 平台率先做深检索与上下文召回Cursor 是目前最成熟的 AI-first IDE 之一。它基于 VS Code 构建具备完整的 Agent 模式——能够规划多步任务、编辑多个文件、运行终端命令并循环迭代直到测试通过或错误解决。2026 年 1 月的 2.4 版本引入了 subagents独立运行在各自上下文窗口中、可并行处理子任务的子代理和 Agent SkillsSKILL.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 分析现有代码库后生成 - 数据库 SchemaReview 表结构、外键关系 - 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 TaskKiro 开始写代码这三个文件requirements.md/design.md/tasks.md都是版本控制的 Markdown 文件存在.kiro/specs/目录下可以 diff、review、追溯。实际效果一位开发者记录写一个数据格式转换功能的 spec 花了 2 小时但节省了 2 周的反复试错。86.5% 的测试覆盖率是另一个副产品——因为每个 Task 里 Kiro 默认包含对应的单测。第二层Steering让 Kiro 记住你的项目约定除了 SpecKiro 还有 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 AgentCursor / Claude Code / Kiro ↓ 生成 新代码 ↓ 持续同步 规范文档闭环工具会迭代模型会升级但结构化的项目知识资产会随团队积累而增值。这才是 AI Friendly 工程化的真正护城河。最后更新2026 年 3 月 | 本文基于公开资料和实测数据工具功能更新频繁请以官方最新文档为准。附录参考资料原理与研究Chroma, “Context Rot: How Increasing Input Tokens Impacts LLM Performance,” July 2025 — https://research.trychroma.com/context-rotCursorCursor Docs: Agent Overview — https://cursor.com/docs/agent/overviewCursor Blog: Best Practices for Coding with Agents — https://cursor.com/blog/agent-best-practicesCursor Changelog 2.4: Subagents, Skills — https://cursor.com/changelog/2-4Cursor Changelog 2.5: Plugins — https://cursor.com/changelog/2-5Cursor Blog: Cloud Agents — https://cursor.com/blog/cloud-agentsCursor Blog: Self-hosted Cloud Agents — https://cursor.com/blog/self-hosted-cloud-agentsClaude CodeClaude Code Docs: Sub-agents — https://code.claude.com/docs/en/sub-agentsClaude Code: Agent Teams — https://code.claude.com/docs/en/agent-teamsClaude Code Docs: Hooks — https://code.claude.com/docs/en/hooksCodex CLICodex CLI Overview — https://developers.openai.com/codex/cliCodex CLI Features — https://developers.openai.com/codex/cli/featuresCodex MCP — https://developers.openai.com/codex/mcpOpenAI: Use Codex with the Agents SDK — https://developers.openai.com/codex/guides/agents-sdkKiroKiro 官网 — https://kiro.devKiro Docs: Steering — https://kiro.dev/docs/steering/Kiro Docs: Agent Skills — https://kiro.dev/docs/skills/Kiro Blog: Custom Subagents, Skills — https://kiro.dev/blog/custom-subagents-skills-and-enterprise-controls/关于 OpenTiny NEXTOpenTiny NEXT 是一套企业智能前端开发解决方案以生成式 UI 和 WebMCP 两大核心技术为基础对现有传统的 TinyVue 组件库、TinyEngine 低代码引擎等产品进行智能化升级构建出面向 Agent 应用的前端 NEXT-SDKs、AI Extension、TinyRobot智能助手、GenUI等新产品实现AI理解用户意图自主完成任务加速企业应用的智能化改造。欢迎加入 OpenTiny 开源社区。添加微信小助手opentiny-official 一起参与交流前端技术OpenTiny 官网https://opentiny.designGenUI SDK 代码仓库https://github.com/opentiny/genui-sdk 欢迎star ⭐如果你也想要共建可以进入代码仓库找到 good first issue标签一起参与开源贡献~如果你有任何问题欢迎在评论区留言交流