阿里Qoder挑战全球AI编程，竟然引领“上下文”革命！

采访嘉宾 | 夏振华

编辑 | Tina

策划 | QCon 全球软件开发大会

最近，AI 编程工具的增长速度真是让人惊叹啊。像 Claude Code 和 Cursor 这样的海外代表，凭借其创新的架构和互动方式，迅速吸引了不少目光；而国内的厂商们也不甘示弱，努力打造出既具本土特色又能在国际上竞争的 AI 编程工具。

虽然过去一年中，Agent 的能力有了明显提升，已经能独立处理一些复杂任务了，但“上下文”仍然是一个棘手的问题。开发者在实际开发时，面对庞大的代码量、复杂的模块结构和众多的上下文信息，常常需要花费大量时间去查找、理解和修改代码。而且，由于文档和代码之间常常不同步，知识传递效率低下，以及重复性编码任务占比较高，这些问题都在制约着研发效率。

正如 Andrej Karpathy 所说，LLM 更像是一个“新操作系统”：模型就像 CPU，上下文窗口则好比 RAM，容量有限，取舍很重要。“上下文工程”的任务就是把合适的信息放进这块“工作内存”，为后续的推理打好基础。谁能把正确的信息放进去，谁就更有可能在实际工程中顺利交付。

为了突破这一“上下文”瓶颈，阿里推出了首个 Agentic 编程平台 Qoder。它被视为全球市场的“创新验证平台”，相当于前沿技术的“先锋队”；阿里表示，Qoder 可以一次检索 10 万个代码文件，把电商网站的前后端开发时间从几天缩短到大约十分钟。它结合全球顶尖的大模型能力与 Agent，对大规模代码进行深度语义检索，并持续进行上下文理解，旨在将复杂的多阶段开发任务拆解并由智能体逐步完成，从而以“仓库级理解 + 任务化执行”的方式应对真实工程的复杂性。

那么，这条“重理解”的路线能否在全球范围内立足呢？带着对架构哲学、技术取舍、定位以及定价等关键问题的思考，我们采访了 Qoder 团队的工程师夏振华，围绕这几条主线进行了深入探讨。

采访嘉宾：

夏振华，Qoder 团队的工程师，专注于基于 LLM 的 Agentic Coding 产品的设计与开发。在此之前，他曾在蚂蚁金服和阿里云积累了多年的软件研发工具链架构设计与开发经验。目前，他致力于将 AI Agent 技术应用于软件开发领域，运用 Context Engineering、Multi-Agent 系统、Agentic RAG 等前沿技术提升开发者在日常编程任务和复杂长程任务中的体验与效果。

他将在 10 月 23 日 – 25 日的 QCon 全球软件开发大会上海站发表主题为“为 Coding Agent 构建智能上下文：Qoder 的 Context Engineering 实践”的演讲。

Qoder 的定位与成本

InfoQ：在开发者圈里，大家常常把 AI 编程工具放在一起比较，比如 Cursor、Claude Code 等。外界甚至把 Qoder 称作“阿里版 Claude Code”“阿里版 Cursor”。你们怎么看这种说法？如果已经有 Cursor、Claude Code，开发者或企业为什么还需要 Qoder？Qoder 在这个“工具谱系”中该如何定位？它的独特价值和差异化优势又在哪里？

夏振华：Claude Code 确实是个很不错的产品，它在 CLI 环境中率先探索了 AI 编程的新方式，让命令行这个经典界面焕发了新生。

不过，Qoder 不仅仅局限于 CLI，而是一个完整的 Agentic Coding 平台，既有 IDE 集成版本，也有 CLI 工具，适用于不同的开发场景和偏好。我们的核心优势在于工程级感知和持久记忆，能够全面理解和索引整个代码仓库的结构与历史，而不仅仅是单文件操作，支持跨文件、跨模块的深度语义检索、分析和修改。这种能力确保在复杂、多轮迭代的项目中保持上下文的一致性和长期可靠性，更贴近真实的工程环境。

在模型层面，Qoder 支持模型的自动路由，不同任务可以由最适合的模型无缝切换执行，开发者无需手动选择或理解模型之间的差异，这样就减少了认知负担，提升了工作效率。同时，我们具备任务拆解与规划的能力，可以将复杂的长程任务分解成可执行的子任务，并进行有序调度和跟踪，实现更完整、高质量的任务交付。

所以，Qoder 在 AI 编程工具生态中，不仅仅是一个代码生成或补全的助手，而是一个智能研发伙伴，适用于从简单编码到复杂系统构建的全链路场景。Qoder 在 8 月 21 日全球首发后，已经吸引了数十万开发者，验证了市场需求的成功！

InfoQ：Claude Code 和 Cursor 都曾面临推理成本和价格的争议。从用户体验的角度来看，Qoder 的 Credits 消耗规则似乎并不完全透明。有开发者认为，根据信息面板的数据和实际体验，Credits 的计费方式并不是简单按调用次数来算，而更像是基于 token 消耗后的归一化处理。能否具体介绍一下 Qoder 的 Credits 定价逻辑？在不同场景下（如大文件检索、复杂任务、多代理并行），Credits 的消耗方式有什么不同？

夏振华：Qoder 的 Credits 计费并不是单纯按提问次数或模型调用次数来算，而是基于实际的 token 消耗进行统一换算和结算。这样的方式能更准确地反映任务的真实计算量，同时避免用户在复杂任务或长上下文情况下受到不公平的计费。我们始终为订阅用户提供全球顶尖的编程模型，确保他们获得行业内最强的上下文工程能力和推理效果。

另外，我们也在持续通过技术升级来提升服务，比如提升工程检索的准确性、优化智能体工具的并行化，以及上下文智能压缩等，确保在效果稳定的前提下，持续优化单任务的 token 消耗，希望让开发者感受到我们的 Credits 越来越耐用。

在 Qoder 刚发布的公测期，确实收到了用户关于 Credits 消耗快的反馈，我们非常重视这些体验，并通过技术优化，当前最新版 Qoder 的整体耐用度相比公测期提升了 15%。

关于不同场景下的 Credits 消耗，复杂的场景需要处理的上下文越大，迭代步骤越多，token 消耗自然更多，Credits 的使用量也随之增加。这里面有一些使用技巧，我们会在 Qoder 社区开设专栏，提供相关的参考指南。

InfoQ：最近有用户在 Claude Code 上用 200 美元的包月订阅消耗出了价值 5 万美元的 token，逼得官方不得不连夜限速。这也让大家开始关注：Qoder 在包月订阅的情况下，对于每月的 token 使用有没有限流或速率控制机制？你们如何平衡用户希望长时间运行代理与平台控制资源成本之间的矛盾？

夏振华：Qoder 的每个订阅版本都设定了固定额度的 Credits，系统会根据任务的实际 token 消耗进行折算和扣减，额度用尽后将自动降级至基础模型，用户仍然可以继续使用，以满足需要持续运行的需求，同时有效避免单个用户极端占用资源的情况。

在平衡用户长时间运行代理与平台资源成本方面，Qoder 一方面通过技术优化不断降低模型的推理成本；另一方面也鼓励开发者在提交任务时明确表达需求，减少无效调用和重复推理，从而实现资源的高效利用和稳定可控的用户体验。

InfoQ：Qoder 上线以来，用户增长的情况如何？主要的增长动力来自个人开发者，还是更多来自团队和企业用户？你们认为，接下来用户增长的关键因素是什么？

夏振华：Qoder 自上线以来，用户增长的速度非常快。虽然具体数据不便透露，但从活跃度和使用广度来看，早期阶段的增长主要来自对新技术新产品充满好奇的个人开发者，而且海外用户占比较高，他们乐于在日常编码、学习和探索中尝试 Qoder，并形成了良好的口碑。我们最近对部分订阅用户的调研发现，通过同事或朋友推荐使用 Qoder 的比例超过了 40%，这让我们感到惊喜，口碑传播的力量真的不可小觑。随着用户规模的持续扩大，以及工具在复杂工程场景中的能力得到验证，团队和企业客户的比例也在不断提升，近期 Qoder Team 版也将上线。

接下来的用户增长，核心还是在于不断提升产品的竞争力，构建更强大、差异化的能力，并切实解决开发者在实际场景中遇到的问题。

面向全球的技术筹码：

技术路线与差异化

InfoQ：Qoder 在设计上最核心的理念是什么？它是如何做到既降低新手的上手难度，又能满足百万行级项目的复杂需求的？

夏振华：我们的设计思路是让 AI 更深入地理解真实软件的开发过程，参与到创造中去，从而帮助构建出更优秀的产品。所谓真实软件，意味着我们的目标不是停留在演示级的小功能，而是面向长期维护、迭代和交付的真正工程，无论是几百行的原型代码还是几十万行的企业代码库，Qoder 都能融入整体架构，理解全局上下文并稳定输出。

Qoder 的底层能力是高度内化的。它在后台拥有工程级感知、持久记忆、任务拆解等复杂机制，能够在面对百万行的代码仓库时，自动“唤醒”这些能力，帮助开发者跨文件、跨模块地分析、检索、规划和交付复杂任务。

但对于新手来说，他们不需要理解这些复杂的过程。Qoder 会通过自然语言交互、即时反馈和简洁的用户界面，把这些高级能力隐藏在流畅的使用体验背后，让任何人都能轻松上手，快速获得有价值的结果。

InfoQ：市面上的 AI 编程工具越来越多，但不少开发者觉得它们在功能和体验上差异不大，包括上下文管理等关键能力，大家的方案看起来很相似，容易出现“同质化”。在你看来，如今团队在选择 AI 编程工具时，是否已经有了清晰的判断标准？

聊聊AI编程工具的选择与Qoder的创新

夏振华：现在市面上的AI编程工具确实看起来差不多，像代码补全、Agent模式等功能都很相似，给人一种“同质化”的感觉。不过，实际应用过程中，这些工具在实现方式、可扩展性以及与不同开发环境的契合度上，往往会有很大的差别。这些都是团队在挑选工具时需要着重考虑的因素。最终，企业会在效果、性价比和安全合规等几个方面进行综合评估。Qoder在这些关键领域投入了不少精力，旨在为企业和开发者提供一个真正可靠的智能研发伙伴。

除了基本的Agent模式，Qoder还推出了两个特色功能：Repo Wiki和Quest模式，这两个功能在开发者社区里得到了不少好评。Repo Wiki会自动生成项目知识库，在大型项目中找到功能实现特别方便。这一功能解决了技术文档更新不及时的问题，帮助新团队成员快速熟悉项目。

而Quest模式则更进一步，算是Qoder的一个亮点。Quest的意思是探索，它标志着Qoder朝着自主编程迈出的重要一步。这个模式主要针对复杂和耗时的开发任务，写好详细的规范后，它会自动规划、撰写并提供报告，多个任务可以同时进行，我只需要审核它的计划就行。Quest上线后仅两个月，Cursor也迅速跟进，推出了Plan模式，从某种程度上看，大家都意识到这是一个正确的发展方向。

InfoQ：在AI编程工具中，大家常谈到“外壳”，也就是在代理或模型外增加的一些功能，比如提示词优化。那你们是如何判断哪些功能应该直接内置在CLI中，作为Qoder的“默认体验”，而哪些又应该交给使用者或外部工具来实现呢？

夏振华：我们的选择原则很简单：不纠结于“外壳”争论，核心是让开发者在实际项目中高效、稳妥地完成任务。默认内置的功能是那些跨项目通用且与正确性密切相关的能力，比如对代码项目的深入理解（包括项目结构、依赖关系、构建和测试），持续的任务记忆和知识积累，以及精细的上下文组织和“最小必要上下文”分发，以确保代理始终在正确的约束下工作。

至于企业外部系统和知识库的集成（如私有规范、流程、审批和资产库等）、个性化功能和自定义策略，则交给用户或外部工具来实现。

Qoder CLI也在前几天全面上线。它在全球顶尖编程模型的基础上，进行了大量的工程设计，大幅提升了Agent的能力。Qoder CLI内置了轻量级的Agent框架，可以高效运行在普通笔记本电脑和云端沙箱实例上，满足不同场景的开发需求。测试显示，Qoder CLI在空闲状态下的内存消耗比类似工具低70%，常见命令的响应时间也不到200毫秒。

Qoder CLI还内置了Quest模式（自主编程）和CodeReview功能，让AI能够自主完成任务开发，无需开发者深度参与。并且，用户可以在命令行终端进行代码审查，快速识别项目中的关键修改，并给出审查建议，代码审查耗时减少了50%，代码质量提升了一倍。

InfoQ：Claude Code的产品负责人曾强调，他们特意保持产品的简单和通用，避免在模型外堆砌过多复杂的结构，因为模型能力进步很快，而复杂的结构反而可能成为束缚。那在Qoder的设计中，你们是如何判断哪些功能可以依赖模型本身的能力来完成，哪些又需要用工程手段来补充呢？

夏振华：我们的判断原则是尽量保持Agent架构的简单，避免复杂的工作流，把推理、反思和迭代交给模型，最大化利用模型升级带来的好处。

其他涉及工具调用的输出质量、上下文组织与切分、记忆与状态管理、容错与可观察性，以及外部数据与环境集成的可靠性等，都是通过工程手段来补充的。

关于检索与上下文工程

InfoQ：长链式的代理任务通常会消耗大量token。Qoder在设计时是如何看待和优化这个问题的？你们会考虑哪些具体手段呢？

夏振华：对于长链式代理任务，Qoder会在计划和执行阶段生成结构化方案，明确步骤和依赖，减少无序调用并防止偏离主线；依托强大的工程检索能力，只召回相关代码片段，显著降低上下文占用；在工具调用上实现并行化，缩短链路以减少消耗；结合精细的上下文组合，只引入必要信息，并通过裁剪和压缩策略移除冗余数据，生成摘要，避免窗口被占满，同时保证任务质量并提升性价比。

InfoQ：今年大家都在说“代理之年”，但在实际应用中，复杂任务往往会涉及几十甚至上百次工具调用，造成上下文爆炸：一方面窗口很快就被填满，另一方面还会出现“上下文腐烂”导致的性能下降。Qoder在设计中是如何解决这种“工具调用密集造成的上下文爆炸”问题的？在确保任务完成度的同时，如何平衡窗口上限、性能退化与成本控制？

夏振华：在有限的上下文长度下，我们通过Context Edit能力和长期记忆机制，保留任务主线需要的关键信息，同时清理无关或过期内容，避免窗口被无效历史填满；结合工程级压缩与模型端摘要，以更紧凑的形式保留必要信息，降低token占用的同时确保可用性。此外，在实际工程应用时，还需结合不同模型的prompt cache，决定压缩策略和触发时机，避免无谓的上下文调整带来的额外成本。

InfoQ：你们提到过“通过技术升级与手动压缩上下文的结合，Credits耐用度将提升50%”。总结和压缩并不是一件简单的事，需要谨慎以避免信息丢失。Qoder在上下文压缩时，是如何保证意图不被淡化、关键指令不丢失的呢？

夏振华：在进行上下文压缩时，Qoder会通过精细化总结和关键代码保留，确保压缩后仍能维持任务主线和用户意图。我们会结构化提炼任务目标、技术概念、文件摘要、问题修复记录及待办事项，并结合近期代码改动，使模型在精简上下文时保持连续性和高性能，避免走偏或丢失核心信息。需要注意的是，压缩本质上属于有损处理，可能会导致效果下降，这一点要有心理准备。

InfoQ：在代码检索方面，有的团队选择“重型RAG管道”，如Windsurf的分块、向量检索和重排；也有的像Claude Code一样走“代理式检索”，完全不建索引，Cline甚至直言“不能用2023年的方法解决今天的问题”。Qoder在实践中更倾向于哪条路线？你们怎么看待“什么时候该上索引，什么时候简单探查就够”的取舍标准？

夏振华：在Qoder的实践中，我们更倾向于构建完整的工程检索引擎，而不是完全依赖代理式的grep检索。这样可以在源代码规模较大、文件分布复杂时，通过分块、向量检索和结果重排来有效提升检索的准确性和召回率，从而减少多轮模型调用，提高整体效率并优化运行成本。

关于“什么时候该上索引，什么时候简单grep就够”，我们的取舍标准主要基于以下几点：

代码库规模与结构：当代码库体量大、文件结构层次深，并且跨模块引用频繁时，建立索引能显著减少检索时间并提高相关性；而在小型项目或结构相对集中的场景，简单的grep就足够了。
成本控制：建立索引会有初始计算和存储开销，但在长时间使用中能显著降低模型调用次数和API消耗；而简单的grep虽然零索引成本，但在重复场景中总调用费用更高。

总体来看，我们会在大型、复杂和高频的检索场景下优先选择索引，而在小型或一次性探索任务中使用grep，这样既能保证性能又能合理控制成本。

InfoQ：我们注意到很多厂商都在引入缓存机制，比如OpenAI的Responses API会自动缓存对话历史，Anthropic以前需要显式header来启用，现在也自动化了，Gemini也支持隐式缓存。缓存确实能明显降低延迟和成本，但它并不能解决长上下文带来的“上下文腐烂”和性能下降问题。在Qoder的上下文工程实践中，你们是如何理解缓存的价值和局限的？会不会把缓存和压缩、检索等手段结合起来，以优化整体体验？

夏振华：在Qoder的上下文工程实践中，我们视缓存为降低成本、提升性能的核心能力之一。它的价值主要体现在高命中率带来的延迟降低和推理费用优化，尤其在Agent场景中频繁请求重复的情况下，能够显著减少模型计算开销。

不过，长时间保留大量原始prompt虽然便于复用，但也可能导致上下文长度增加，出现“上下文腐烂”，影响输出质量，因此需要谨慎权衡。

为此，我们会将缓存与压缩、检索增强等策略结合使用：当判断平台缓存机制可能失效，或者上下文接近模型上限时，会主动优化上下文结构，提取关键信息并替换冗余内容，从而在保证命中率的同时减轻性能衰减，确保整体体验的稳定和优质。

关于多Agent与单Agent的讨论

InfoQ：在业内对于多代理的看法并不一致。Cognition认为不要做子代理，因为子代理之间沟通不畅；而Anthropic则强调多代理的优势。Qoder在设计时是如何看待这种分歧的？如果是多个代理，如何处理它们之间数据、记忆和上下文的割裂问题？在选择最优解、减少合并冲突、降低开发者的认知负担等方面，你们是否探索过新的机制？

夏振华：模型能力的提升，很多观点都会发生变化，比如提到的Devin关于多Agent的看法，其实也在变化。Qoder在这方面的探索已经持续了一年多，从去年开始我们就尝试通过多Agent的串联配合来完成研发任务，解决模型能力不足的问题。随着模型能力的演进，我们主要的架构是基于单Agent通过工具调用自主迭代循环来完成任务。

Qoder：让编程更智能的未来

现在，我们也在积极探索多代理的协同工作，以及主子代理的组合方式，目的是解决上下文隔离和共享等一系列难题。总的来说，这一切还在摸索中，后续的进展我们会持续更新。我们的核心思路是让子代理只获取最必要的信息，并通过结构化的关键摘要来反馈，这样主代理就能集中处理和决策，减轻上下文割裂和主代理的负担。

InfoQ：最近社区里有不少人反映，Claude Code 很难实现真正的“全自动长跑”，总是需要人工确认。Qoder 有没有计划支持这种不间断的运行模式？如果有，你们会如何在用户体验和安全性之间做出权衡呢？

夏振华：Qoder 的 Quest Mode 就是为了长时间运行的研发任务而设计的，采用了规范驱动的开发方式，能够将用户需求自动转化为详细的设计规范，并在这个基础上自主完成开发、测试、重构和问题修复，实现全自动化的研发过程。

借助我们的云端远程运行能力，Quest Mode 可以在安全的云沙箱环境中持续执行任务，不需要依赖本地环境，用户在执行过程中可以随时中断或调整任务，这样既能确保长时间稳定运行，又能降低安全风险。

InfoQ：很多团队在尝试把代理迁移到云端时，都会遇到一个挑战：如何复制开发者本地的环境？直接克隆开发环境常常过于复杂、个性化，难以真正实施。因此大家开始转向容器和沙箱，以便在更标准化的环境中运行代理。Qoder 在云端代理的设计上是否遇到过类似的问题？有没有什么值得分享的“黑科技”？

夏振华：确实，云端复制本地环境是一个不小的挑战。在 Qoder 的 Quest 模式中，我们通过用户自定义的 Dockerfile 作为基础环境来解决这个问题，系统会先验证并构建环境，然后在每次任务执行前检出相应的版本并运行用户提供的安装和初始化脚本，以确保可重复和可隔离。

评测方法与“榜单偏差”纠偏

InfoQ：Qoder 如何收集和利用用户反馈？在阿里内部和企业客户中分别采用什么机制？你们是如何进行评测的？更关注端到端、触发型，还是能力型评测？

夏振华：关于用户反馈的收集，Qoder 遵循用户授权和主动提供的原则，同时符合相关隐私条款和安全规范。无论是在阿里内部还是企业客户，都可以通过 IDE 内置的反馈入口、官方邮件或论坛提交建议和问题。对于阿里内部团队，我们还建立了更实时的沟通机制，比如钉钉协作群，让研发、测试和业务团队能够提前体验新版本，并在真实环境中快速反馈问题，推动迭代优化。

在评测方面，我们覆盖了主要的研发场景，包括前端、后端、客户端开发等，以及主流编程语言的多种任务类型，从 bug 修复到需求实现，再到代码重构和结构优化等。我们既关注整体效果，评估任务从触发到交付的完整链条质量，也重视核心能力的精准评测，比如代码生成的质量和检索的准确性。在此基础上，我们还会进一步分析过程中的成本和执行效率，确保整体表现既有效率又稳定。

InfoQ：市面上很多编程工具都声称自己在开放基准测试中表现最佳，但这些基准往往无法覆盖企业真实的复杂场景，比如超大规模单体仓库、成千上万个微服务、大规模迁移和依赖升级。Qoder 在评估和优化时，如何避免仅仅在排行榜上好看，而是能够真正解决企业开发中的实际问题？

夏振华：开放基准测试通常无法涵盖企业真实的复杂研发场景，因此我们建立了自有的评测集，覆盖的维度比开放基准测试更丰富，包括前端、后端、客户端等不同研发场景，主流编程语言，以及多种类型的任务——从 bug 修复到需求实现，再到代码重构、架构优化和跨服务依赖调整等。与许多工具仅在有限样本中“跑分”不同，Qoder 的评测环境更贴近企业的真实研发项目。

InfoQ：在探索模型边界时，有人提到要“推模型一把”，看看它是否能被逼出新的能力。结合你们的经验，当模型未达到预期时，如何快速判断原因是提示词设计不当、模型选型问题，还是模型本身的能力瓶颈？

夏振华：我们通常会先用一组简单、可控的基准任务来建立下限；如果通过改写提示词或微调工具就能显著提升效果，那一般是提示词设计不当或在该模型下的适配性问题。

如果在相同的提示词和评测数据下更换不同模型，若表现差异明显则是模型选型问题；如果所有模型都以类似方式失败且加入少量示例或思维链也没有明显改善，那多半是模型能力瓶颈。

还有一个方法是查看厂商是否提供基于模型的开源产品或官方最佳实践，如果参考并调整后仍无法达标，那更可能是模型能力瓶颈。

实践方法与路线图

InfoQ：最后能分享一些 Qoder 的使用技巧吗？

夏振华：首先，任务描述一定要尽量一次性讲清楚，技术栈、功能细节、规范要求都要尽量完善，否则来回补充和追问不仅浪费时间，还会增加成本，影响整体效果。

另外，可以在项目中放置一个规则文件，明确代码风格、文件结构和规范要求，这样 Qoder 生成的内容会更符合项目标准。

除此之外，Qoder 具备智能记忆功能，遇到关键业务规则或曾踩过的坑，我会主动让它记录下来，比如 API 的认证方式，这样下次就不需要反复强调了。

会话管理也很重要，完成与当前任务无关的编码工作时，最好开一个新的独立会话。如果某个会话窗口的历史上下文过长且不相关，可以主动触发压缩，只保留核心信息，这样后续响应会更快、更准确。

版本控制同样关键，每完成一个功能模块我都会及时提交（commit），这样在出现问题时能迅速回退。

InfoQ：从未来发展来看，Qoder 最想成为怎样的产品？如果拿 Cursor、Claude Code、Lovable 来对比，你们最希望在技术层面超越的“关键一点”是什么？