采访嘉宾 |夏振华

编辑 | Tina

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

AI 编程工具正爆发式增长。以 Claude Code、Cursor 为代表的海外路线，凭借架构与交互创新快速出圈；Cline、Replit、AmpCode 等也在加速试验新形态。与此同时，国内厂商积极入局，试图打造兼具本地特色与全球竞争力的 AI Coding 工具。

尽管过去一年 Agent 能力明显进步，开始从“辅助”走向能独立处理长链条任务，但“上下文”依然是摆在实用化面前的一块硬骨头。在实际开发中，面对庞大的代码规模、复杂的模块结构和分散的上下文，开发者常常需要投入大量时间进行检索、理解和修改。与此同时，文档与代码长期不同步、知识传递低效以及重复性编码任务占比高，成为限制研发效率的核心痛点。

正如 Andrej Karpathy 所言，LLM 更像一种“新操作系统”：模型好比 CPU，上下文窗口如同 RAM，容量有限、取舍关键。“上下文工程”的任务，就是把正确的信息装进这块“工作内存”，为下一步推理服务。谁能把对的东西放进窗口，谁就更可能在真实工程里稳定交付。

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

这条“重理解”的路线能否在全球对标中站稳？带着对架构哲学、技术取舍与定位 / 价格等关键问题的关注，我们采访了 Qoder 团队工程师夏振华，并围绕这三条主线展开深度解析。

采访嘉宾：

夏振华，Qoder 团队工程师，负责基于 LLM 的 Agentic Coding 产品的设计与研发工作。之前在蚂蚁金服、阿里云有多年软件研发工具链的架构设计和研发经历。目前专注于 AI Agent 技术在软件开发领域的创新应用，致力于通过 Context Engineering、Multi-Agent 系统、Agentic RAG 等前沿技术提升提升整体 Coding Agent 在开发者日常编程任务以及长程复杂任务上的体验和效果。

他将在 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 编程工具生态中，不只是代码生成或补全助手，而是面向工程全周期的智能研发伙伴，适用于从 vibe Coding 到日常编码，再到复杂系统构建的全链路场景。Qoder 在 8 月 21 日全球首发后，目前已经收获了全球数十万开发者，验证了 PMF 的成功！

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

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

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

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

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

InfoQ：Qoder 上线以来，用户增长的情况如何？主要的增长动力来自个人开发者，还是更多来自团队和企业用户？在你们看来，下一个阶段的用户增长会依赖于哪些关键因素？

下一个阶段的用户增长，核心还是在于持续提升产品力，构建更强的、差异化、引领市场方向的核心能力，并切实解决开发者在真实场景中的实际问题。

面向全球的技术筹码：

技术路线与差异化

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

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

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

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

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

夏振华：目前市场上的 AI 编程工具在功能层面确实有一定的相似性，比如代码补全、Agent 模式开发任务等，因此表面看容易出现“同质化”的印象。然而，在实际落地中，这些能力的实现方式、可扩展性、与工程环境的融合深度，以及对不同规模和复杂度项目的适配效果，往往存在明显差异，这也正是团队在选择工具时需要重点考量的地方。最后，企业会在效果、性价比、安全合规这几大维度综合权衡。Qoder 正是在这些关键维度上深度投入，为企业和开发者提供切实可依赖的智能研发伙伴。

Qoder 除了基础的 Agent 模式之外，我们也发布了两个特色功能，Repo wiki、Quest 模式，这两个功能也在开发者社区收到了非常多正向的反馈。Repo Wiki 会自动生成项目知识库，在大型仓库里找功能实现尤其实用。这个功能解决了技术文档滞后的老大难问题，让新团队成员能够快速上手项目。

Quest 模式就更进一步，是 Qoder 强大之处。Quest 意味着探索，是 Qoder 迈向自主编程的关键一步。主要针对复杂或耗时的开发任务，写出详细 Spec 后它会自己规划、撰写并给出报告，多个任务可以异步并行执行，我只需要审阅它的 plan 即可。Quest 上线后 2 个月，近期 Cursor 也快速跟进、发布了 Plan 模式，从某种意义上，大家也看到了这是正确的方向。

InfoQ：在 AI 编程工具里，大家经常会讨论所谓的“外壳”（harness），也就是在代理或模型外层加的一些功能，比如提示词优化，那么你们是如何判断哪些能力应该直接内置在 CLI 里，作为 Qoder 的“默认体验”，而哪些能力应该交给使用者或外部工具自己去实现？

夏振华：我们的取舍原则很简单：不纠结“套壳”之争，关键是让开发者在真实工程里高效、稳妥地把任务做完。默认内置的，是跨项目通用且与正确性强相关的能力：代码工程的深度理解（项目结构、依赖、构建与测试）、持续的任务级记忆与知识沉淀，以及精细化的上下文组织与“最小必要上下文”分发，确保代理始终在正确的约束与单一事实源下工作。

而企业外部系统与知识库的集成（私有规范、流程、审批、资产库等）、个性化能力与自定义策略则交给使用者或外部工具来实现。

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

Qoder CLI 还内置了 Quest 模式（自主编程）与 CodeReview 能力，无需开发者深度介入，就可以轻松实现 Spec 驱动的任务委派，让 AI 自主完成任务开发。同时在命令行终端即可进行代码审查，帮助用户快速扫描项目中的关键改动点，并给出审查意见，代码审查耗时减少 50%，代码质量提升一倍。

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

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

其他比如涉及工具调用的输出质量、上下文组织与切分、记忆与状态管理、容错与可观测性、以及外部数据与环境集成的可靠性与边界，则用工程手段补齐。

检索与上下文工程

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

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

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 通过工具调用自主迭代循环的方式来完成任务。

当前，我们也在做包括多 Agent 的串联、主子 Agent 形式的探索，并解决这里面存在的上下文隔离、共享等问题。整体目前仍在探索阶段，进展后续也会持续同步出来。核心思路是子 Agent 仅获取最小必要输入、以结构化关键摘要信息的方式回传，由主 Agent 聚合与决策，降低上下文割裂与主 Agent 负担。

InfoQ：社区里也常有人吐槽，Claude Code 很难做到真正的“全自动长跑”，代理跑一会儿就要人工确认。Qoder 会不会考虑支持这种 24 小时不间断的运行模式？如果支持，你们会如何在体验、安全性之间做取舍？

夏振华：Qoder 的 Quest Mode 就是为长时间运行的研发任务而设计，采用 Spec 驱动的开发范式，让 Agent 能够将用户的需求自动转化为详尽的设计规范，并在此基础上自主完成开发、测试、重构和 Bug 修复等工作，实现端到端的自动化研发。

依托 Remote 云端运行能力，Quest Mode 可以在安全的云端沙箱环境中持续执行任务，无需依赖本地环境，用户可在执行过程中随时中断或调整任务，从而在保证长时间稳定运行的同时降低安全风险。

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

夏振华：是的，云端复制本地环境确实是一个难题。Qoder 的 Quest 模式里我们是这样来解决这个问题：远程任务以用户自定义的 Dockerfile 作为基础环境，系统先验证 / 构建，再在每次任务执行前 checkout 对应 commit 并运行用户提供的安装 / 初始化脚本，保证可重复、可隔离。

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

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

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

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

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

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

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

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

在相同的 prompt 与评测数据下横向替换不同模型，若表现差异显著则是模型选型问题；若各模型都以类似方式失败且加入 few-shot/ 思维链也无明显改进，多半是模型能力瓶颈。

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

实践方法与路线图

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

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

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

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

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

版本控制也非常重要，每完成一个功能模块我都会及时提交（commit），方便在出现问题时迅速回退。

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

夏振华：我们希望成为面向真实工程的 Agentic Coding Platform，不只是“会写代码”，而且能够实现从需求到可合并 PR 的端到端执行者，深度理解仓库、做出系统级设计决策，并产出高质量、易维护的变更代码——Think deeper, Build better。

声明：本文为 InfoQ 整理，不代表平台观点，未经许可禁止转载。