Qoder:阿里的 agentic platform for real work,九条产品线共用一套知识引擎
qoder
阿里巴巴的智能体编码平台,官方定位 agentic platform for real work:不是一个编辑器,而是一条端到端闭环——理解任务与上下文 → 规划 → 调工具执行 → 验证结果 → 朝交付物迭代,三条底层理念是上下文工程、agent 自主性与目标导向循环;九条产品线共用一套知识引擎(桌面 Qoder 与 Qoder IDE 并存互不替代、Editor 与 Quest 双形态、JetBrains 插件、Qoder CLI、云端 agents 等),会话历史与 memory 分开存但可从 IDE 导入。Repo Wiki 由多 agent 在本地生成、不上传代码库,默认关闭,支持 Auto Update / Auto Export / Citation 回指源码位置。Quest 有四种驱动方式:Agent / Experts / Goal / Spec(可转定时任务)——Spec 走需求澄清(多选题形式,可 Recommend / Continue / Skip)→ 结构化 Spec(需求、设计、任务拆解、验收标准)→ 人工评审 → 执行 → Review/Commit/Push;Goal 只描述结果,每轮结束评估进度、未达成自动进下一轮。两个规模化案例:用 Qoder 造 Qoder(10 人 3 周,50 万行 agent 代码并入 400 万行遗留系统,99% 由 agent 生成,到 v1.4.0 仍在生产运行且零线上事故;方法是认知底座 + Ultra Spec + Experts 交叉评审 + verifier agent 反向过滤幻觉问题,人只做 SLO 定义与不可逆操作的最终决策,人均每天主导 20 多个 Experts 任务);高德车机 AutoSDK 跨 20 多个仓库、超百万行,严格一次通过率 37.3% → 61.5%(问题定性引 KoCo-Bench / arXiv:2601.13240v3:通用编程 Pass@1 可达 90%,领域代码生成只有 8.9%)。边界:客户端与知识引擎不开源;全部规模化数据出自官方案例与厂商自述,自家产品自证存在方法学自利偏差,未独立复算;Experts 单位成本明显高于单 agent(中位数约 75 vs 50 Credits),Credits 周期清零不能囤。置信度 C(厂商宣称)。
- 置信度
- 厂商宣称
- 只有官方模型卡/发布会,无独立复测
- 关键指标
- 10 人 3 周并入 400 万行遗留系统(厂商案例)
- 厂商宣称 · 2026
- 成熟度
- 产品
- 研究 → 演示 → 产品 → 生产
我们的判断我们给它 C 档(厂商宣称)。可复核的硬事实有一批:九条产品线的官方文档逐条可查、Cloud Agents 的四原语与三语言 SDK 是公开仓库(
github.com/QoderAI/cloud-agents)、Credits 的档位与中位数消耗表写在定价页上、Repo Wiki「本地生成、不上传代码库、默认关闭」是可验证的产品行为、/better-harness的审查流程与四个问题写在公开文档里。但我们采信为指标的那条读数——10 人 3 周把 50 万行 agent 代码并入 400 万行遗留系统、99% 由 agent 生成、零线上事故——出自官方案例,而且案例的主体是用 Qoder 造 Qoder 的自家团队,既是厂商自述又是自证,没有第三方审计、没有可复算的口径(什么算「一行」、哪些改动计入、事故定义是什么均未给出),我们更没有独立复现,所以按契约只能落 vendor-claim。高德 AutoSDK 的 37.3%→61.5% 同理:数字来自客户案例,只有它引用的 KoCo-Bench 测量(arXiv:2601.13240v3,通用编程 90% Pass@1 vs 领域代码生成 8.9%)属第三方可查。水位判断:Qoder 的战略位置不在编辑器,而在它是唯一一家把「harness 治理」当成产品主线来做的厂商。三条证据互相咬合:其一,它不把可靠性寄托在更长上下文上——案例里明说即便有 100 万 token 窗口,注意力稀释与上下文衰减依然存在,窗口更大不等于每个 token 得到同等注意,于是改用 Experts 拆分 + 独立上下文 + 共享知识引擎来保一致性,这是对长上下文神话的一次公开证伪;其二,
/better-harness把「审自己的工程环境」做成一条斜杠命令,承认瓶颈已经从模型移到 harness,并且要求修法必须是最小且可持续的(明确反对把偶发失败固化成永久规则);其三,知识引擎被当成可生产、可调优、可刷新、可消费的工程资产而不是一次性索引,高德案例的核心结论「AI Coding 的天花板不在模型本身,而在领域知识」与 KoCo-Bench 的 90% vs 8.9% 落差是同一个判断的两次独立表达。把这三件事连起来看:Qoder 赌的是组织级的认知基础设施,而不是单人生产力工具。对我们自己的启发很直接:Experts 的 Team Lead 不写代码、只把任务拆成 DAG 并规避同文件并发,这是可以照搬的调度约束;「头两天全用来刷新知识层、事后复盘 ROI 最高」是对所有想在存量仓库上跑并行 agent 的团队最有价值的一条经验数据;中位数消耗表(Editor Agent ~12、Quest Agent ~50、Experts ~75 Credits)则给了一个少见的可对齐成本口径。
要如实说清的边界:客户端与知识引擎闭源;全部规模化数字都是厂商自述且含自证;Experts 的单位成本比单 agent 高约 50%,并行度是用额度买的;Credits 周期清零不能囤;QoderWake 的「数字员工」目前更接近长期职责编排,不等于可无人值守交付生产变更。
它是什么:阿里的「agentic platform for real work」,一个产品族而不是一个编辑器
Qoder 是阿里巴巴推出的智能体编码平台,官方定位写得很宽:agentic platform for real work——把 AI 带进软件开发、终端工作流、托管云执行、日常办公与长周期数字岗位。它的设计原点不是「补全 + 对话」,而是一条端到端闭环:理解任务与上下文 → 规划 → 调工具执行 → 验证结果 → 朝交付物迭代。官方把支撑这条闭环的三条底层理念单独列出来:上下文工程(让 agent 从代码、知识、规则、工具、文件与运行环境中获得持久上下文)、agent 自主性(在保留必要审查点的前提下独立决策与多步执行)、目标导向循环(从一个目标出发,经规划、执行、验证、迭代直到交付物就绪)。
产品族目前有九条线,而且不是营销话术式的「全家桶」,每条都有独立文档与独立形态:
- Qoder(桌面端):从 Qoder IDE 的 Quest 模式长出来的独立桌面产品。官方明确说两者并存、互不替代——想自己写代码调代码就用 IDE,想把整件事丢给 agent 就用 Qoder。两边的会话历史与 memory 分开存,首次使用可从 IDE 导入历史与记忆继续上下文。
- Qoder IDE:专用的 agentic 开发工作区,分 Editor(在编码流里给辅助)与 Quest(长周期、多步骤的任务委派)两种形态。
- JetBrains 插件:把补全、Ask、Agent、MCP 与项目规则带进 JetBrains 系 IDE。
- Qoder CLI:终端里的编码 agent,可延伸进脚本与自动化。
- Cloud Agents:托管 agent 的 API 面,四个原语——Agent / Environment / Session / Event:配置 agent 与环境、开 session、流式收结果。提供 TypeScript / Python / Go 三套 SDK(
github.com/QoderAI/cloud-agents),并区分个人空间与企业空间的数据归属、访问与计费。 - QoderWork:委派文档、表格、调研、浏览器与桌面任务,拿回本地可用的交付物。
- QoderWake:创建名为 Waker 的数字员工,承担长期职责、对话、自动化与多阶段流程,支持 Groups + Leader、Autonomous Work、WakerFlow,以及在 IM 里
@Waker直接派活。 - Mobile & Web:远程盯 IDE 与 CLI 的任务、审计划、批授权。
- Enterprise:集中采购、成员与身份、策略、知识、模型、marketplace、审计等治理面。
知识引擎:Repo Wiki + 代码知识图谱 + Memory,是这套东西真正的地基
Qoder 与同类最不一样的一点,是它把「让 agent 读懂一个存量仓库」当成第一性问题来做,而不是靠把上下文窗口拉长。
Repo Wiki 从代码、注释、文档与提交历史自动生成仓库级文档,无需人工干预;代码知识图谱自动建模模块依赖、接口契约与数据流;Memory 与 Knowledge Card 负责把跑过的经验沉淀成可复用资产。官方案例里把这三层合称「认知底座」(cognitive foundation),并给出一个很硬的判断:当几十个 agent 并行写代码时,每一个知识缺口都会被放大——所以他们在三周工期里,头两天全部用来刷新知识层(Repo Wiki 全量刷新 + 知识图谱针对上月新增模块与近期接口变更做深度更新 + 整理历史 Spec),事后复盘认为这两天是整个三周里投入产出比最高的。
工程边界也交代得清楚:Repo Wiki 在本地由多 agent 生成、不上传代码库,默认关闭,支持 Auto Update / Auto Export / Citation(引用回源码位置)。
Quest 的四种驱动方式:Agent / Experts / Goal / Spec(可定时)
Spec 驱动:在 Quest 输入框的「+」里打开 Spec 开关,流程是需求澄清(多选题形式,可 Recommend / Continue / Skip)→ 生成结构化 Spec(需求描述、设计方案、任务拆解、验收标准)→ 人工评审 → 按 Spec 执行 → Review / Commit / Push。Spec 还能直接转成定时任务或转成 Goal。
Goal 驱动:只描述想要的结果,Quest 自己拆解、规划路径、持续迭代,每轮结束都评估当前进度并判定目标是否达成,没达成就自动进下一轮。过程可控:运行中随时暂停、改目标或删任务,暂停保留完整上下文与中间产物;改了目标之后从下一轮起按新目标继续,不重置已有进度。官方给的适用场景是有明确成功判据与验证回路的活:提测试覆盖率、性能调优、跨文件一致性修复、整仓框架升级、批量 API 替换。
Experts 协作是这套体系里最有辨识度的一层。一个 Team Lead expert 不写代码:它读 Spec 的任务列表、识别依赖、把工作拆成 DAG 再派活——有依赖的任务不并行,可能改同一文件的任务不同时跑;后端、前端、测试、审查各 expert 在各自独立的上下文里领活。每个 expert 可以单独指定模型、写不超过 1 万字符的专属 prompt、挂自己的 Skills 与 MCP,并有 Expert Team Canvas 看全局。
为什么非拆不可,官方案例里有一句很诚实的解释:即便 Qoder IDE 支持 100 万 token 上下文窗口,随着上下文增长注意力稀释与上下文衰减依然存在,窗口更大不等于每个 token 得到同等注意。一个 agent 从头做到尾,后半程会忘掉前面的约定。所以他们的做法是让 expert 各自拿独立上下文,一致性由共享的知识引擎与同一份原始决策记录保证,而不是靠一个超长上下文硬扛。
/better-harness:把「harness 本身」当成可被审计的对象
这是我们认为最值得同行抄的一个功能。官方先给了 Agent Harness 的定义:agent 在「理解任务 → 行动 → 检查结果 → 调整」的循环里工作,而可靠的循环除了模型之外还需要清晰的项目上下文、可用工具、操作边界、验证方法,以及把过往经验留下来的机制——这些支撑机制合起来就是 harness,具体可能是仓库说明、rules、skills、hooks、plugins、connectors、脚本、测试命令、发布检查与人工审查步骤。它的目的是让 agent 能回答四个问题:期望什么结果、什么不在范围内;项目该怎么操作与修改;什么证据能证明结果正确;操作或验证失败时该怎么办。
harness 的缺口在单次成功任务里看不出来,只会随时间显形:同一条指令要反复讲、项目约定始终没写下来、验证被跳过、评审意见传不到下一个任务。/better-harness 就是审这些反复出现的模式,流程是摸清现状 → 找断点 → 选最小且可持续的修法 → 验证改进,每条 finding 都给出证据、受影响的工作流环节、建议的持久化修法(rule / skill / hook / script / 人工审批)以及后续如何验证。文档还专门写了两条反面提醒:不要把偶发失败或一次性偏好固化成永久项目规则;报告是决策辅助,动手修之前要对着仓库和团队流程复核。
把「审自己的工程环境」做成一条斜杠命令,意味着 Qoder 认为 agent 的可靠性瓶颈已经从模型转移到 harness——这与我们在其它厂商(Anthropic 的 skills、OpenAI 的 AGENTS.md、Kimi 的工具层护栏)看到的趋势一致,但只有它把审计本身产品化了。
公开案例:两条能查证的规模化数据
- 用 Qoder 造 Qoder:10 人 3 周,50 万行 agent 代码并入 400 万行遗留系统。V1.0 上线时要新增四个大模块(独立 Quest 视图、知识引擎、多工作区并行、Experts 协作),工期锁死三周;仓库前端是 VS Code 扩展,后端是负责 agent 编排、知识引擎与多模型调用的 Go 服务,分两个仓,九个月从 v0.1 长到约 400 万行。方法是三件套:认知底座 + Ultra Spec + Experts 协作。Ultra Spec 与普通 Spec 的区别是先让多个 agent 并行做广度与深度调研、再合并收敛成一份可直接执行的完整计划,写完还要多 agent 交叉评审——架构师看模块边界、安全专家找权限漏洞、性能专家预判瓶颈、接了知识图谱的遗留系统专家查兼容性,再由一个 verifier agent 反向过滤掉幻觉造出来的假问题,人只做最终决策(重点是 SLO 定义与不可逆操作)。执行期三组分头跑,人均每天主导 20 多个 Experts 任务,三周跑了几千个子任务,官方称整体执行效率比单 agent 模式高一个数量级;结果 50 万行全部进主干、99% 由 agent 生成,到 v1.4.0 仍在生产运行且零线上事故。
- 高德车机 AutoSDK:严格一次通过率 37.3% → 61.5%。AutoSDK 跨 20 多个 Git 仓库、超百万行代码。案例先引 KoCo-Bench 的测量把问题定性:通用编程能到 90% Pass@1,领域代码生成只有 8.9%;在 agent 范式下加入领域知识检索能提到 34.2%,最好的一条赛道峰值 62.5%(arXiv:2601.13240v3)。他们把一次通过的失败归成四类——探索漂移、生成偏离、架构违规、约束遗漏——根因收敛到同一处:业务术语含义、模块职责边界、历史决策取舍这些领域知识从未被结构化成 AI 可消费的形态。于是用知识引擎建了一套「生产 → 调优 → 刷新 → 消费」的闭环,让同一类错误不再犯第二次。
另有两条量级较小的公开案例:孩子王用 Qoder 把一周的全栈需求压到一天,并建起跑 400 个业务场景、300 个 agent 的 AI 平台「知数」;一位个人开发者称用 Qoder 两个月交付了过去 20 人 3 个月工作量的 MES 产品。
扩展面与安全面
扩展接口覆盖了当前主流的四种标准:Skills / Plugins / Connectors / Hooks,外加 subagents、AppShot 与 Computer control(桌面与浏览器操作)。安全侧是三档递进的代码安全检查——Static Check / Lightweight Scan / Deep Scan,配修复流程;桌面端任务分 Coding(按工作区分组,带执行模式与分支控制)与 General(按文件夹分组),另有 Automations 定时启动 agent 工作并逐次留痕。
商业面:Credits 的中位数是真给了表的
个人版四档:Free(含 2 周 Pro 试用、300 Credits、有限的补全与 NES、支持 BYOK)、Pro $20/月 2,000 Credits、Pro+ $60/月 6,000、Ultra $200/月 20,000。官方写明付费档的额度价值等同订阅费,Credits 只在当前订阅周期内有效、周期结束清零;额度用尽自动降级到基础模型(有每日上限),失败请求不扣 Credits。更有用的是它给了一张中位数消耗表(200K 上下文口径):Editor Ask ~4、Editor Agent ~12、Quest Agent ~50、Quest Experts ~75、Repo Wiki ~50/仓库(50K 口径下 Editor Ask ~3、Editor Agent ~7)。能公开中位数而不是只说「按量计费」,在这个赛道里算少见。
边界
客户端与知识引擎不开源,Repo Wiki 与知识图谱的生成质量取决于仓库本身的注释、文档与提交历史质量;全部规模化数据(50 万行、99%、一个数量级、37.3%→61.5%)都出自官方案例与厂商自述,其中「用 Qoder 造 Qoder」是自家产品自证,存在方法学上的自利偏差,我们没有独立复算;KoCo-Bench 的读数引自 arXiv:2601.13240v3,属第三方可查但仍是论文口径;Experts 模式的单位成本明显高于单 agent(中位数 ~75 vs ~50 Credits),并行带来的效率提升要以额度换,按人头做容量规划时容易低估;Credits 周期清零意味着不能当预付余额囤;QoderWake 的「数字员工」形态目前更接近长期职责编排,不等于可无人值守交付生产变更。