（本文作者为 飞向TAI空，钛媒体经授权发布）
2026年9月22日，杭州，云栖大会技术主论坛。阿里巴巴ATH事业群副总裁、Qoder产品线总裁丁宇（花名叔同）站上讲台，带来题为“不止编程，无限创造”的演讲。他宣布，Qoder全新升级为“面向所有人的Agentic Coding平台”。
这一天，距离Qoder在西溪园区一间小项目室里成立，刚好478天。
478天里，Qoder从一款AI IDE，发展为覆盖桌面、IDE、CLI、云端、移动端和数字员工的产品家族。据Qoder方面披露，其全球用户已超过800万。产品面对的人群也在变化：从专业开发者，到不以编程为职业的普通用户，再到希望将Agent纳入业务流程的企业。
变化同样发生在团队内部。这支最初人数不多的创新团队，已经成为阿里内部AI Native实践最深入的团队之一。
演讲结束后，钛媒体联合创始人刘湘明与丁宇再次坐到一起。一年前，两人在云栖大会上谈论的，主要还是AI如何帮助人写代码。一年后，近一个小时的对话已经越过编程本身，延伸到软件工程、组织协作，以及人在AI时代究竟应该保留什么能力。
因此，这场对话不只是关于一款编程产品如何扩张边界。它也提供了一个观察窗口：当AI开始改变软件生产，一支亲自使用这些能力的团队，会如何重新组织自己。
起点：一个当天拍板的决定
西溪园区的一次交流
故事要从2025年年初说起。那天，丁宇在西溪园区向阿里高层做了一次汇报，话题是AI Coding。丁宇后来回忆，高层对Coding这件事非常看重，当天就决定孵化这个业务。
接下来的节奏很快。Qoder团队快速成立，被看作阿里参与全球AI Coding竞争的号角，也拉开了阿里全面投入Agent应用赛道的序幕。
此后，团队整建制搬到西溪C区，闭关了整整半年。
一个做基础设施的人，为什么来做AI Coding
丁宇在2010年加入阿里。此后的十几年里，他长期与云计算的底层技术打交道，带领团队攻坚全面容器化、统一调度、混合部署等技术，推动阿里业务上云。
这些工作很少直接出现在普通用户眼前。用户看到的是应用和服务，背后则是计算资源如何分配、不同业务如何协同运行，以及庞大的系统如何保持稳定。
从云基础设施到AI Coding，工作对象发生了变化，工程问题却没有消失。过去要解决的是让大量应用在云上可靠运行；如今，除了运行，还要进一步参与这些应用的生产过程。
因此，基础设施出身的创始人，也在Qoder身上留下了印记，不只是“重技术”，而是重视技术之间的衔接：模型如何与Harness配合，上下文如何被理解和传递，生成速度如何与测试、安全和交付能力匹配。丁宇在后来的采访中反复强调这些问题。
闭关半年，一切从零开始
闭关的那半年，团队要做的远不止写一个产品。
丁宇列过一张清单：端侧产品、独立官网、用户体系、商业化链路、产品营销、全球部署架构……“都是从无到有。”一家创业公司在头两年要搭的东西，这支团队要在两个月搭完。
攻坚数月，首款产品Qoder在2025年8月上线。它率先支持Repo Wiki、Quest模式等功能，为开发者提供了一种新的开发范式。上线后仅仅5天，用户规模就冲上了10万。考虑到它面对的是一向挑剔的专业开发者，这个速度并不多见。
此后，团队几乎每个月都有一次重量级发布：JetBrains插件、Qoder CLI、企业版和Teams版、桌面智能体QoderWork（后合并至千问办公）、数字员工QoderWake、云端Cloud Agents、移动端相继推出。半年时间，一套面向AI Coding场景的全产品矩阵就搭了起来。丁宇说，这在AI时代以前是很难想象的速度。
一年，三次扩大边界
去年还在聊怎么写代码
在今年云栖大会的直播间，刘湘明和丁宇又坐在了一起。
一年前的云栖大会，两人也是这样对谈。刘湘明记得，那时Qoder刚刚冒头，“咱们聊的很多都还是怎么写代码”。一年后，他听完丁宇的演讲，第一反应是“这个进步太快了”：不只是写代码，已经到了软件工程、到了完成任务，甚至开始考虑生态。
热度也肉眼可见。刘湘明说，他们在三亚办的一场AI编程分论坛，一个小会场前后加了三次椅子。
丁宇把这一年多的变化分成三个阶段。第一阶段是辅助编程，AI帮人补全代码。第二阶段进入代码工程，AI能理解整个代码库，完成知识问答、多文件编写，但仍以代码为中心。到了2026年，模型能力大幅提升，Computer Use、Browser Use等工具能力快速进步，Agent能处理的任务越来越长，AI Coding开始覆盖软件全生命周期。
“Coding Agent本身就是一个通用Agent。”丁宇说。很多人已经在用它做和编程无关的事，AI Coding因此可以服务每一个人。回看Qoder的发展路径，它并不是简单地把一个AI编程工具做得更大，而是在短时间内完成了三次能力边界的外扩：先服务专业开发者，再走向普通岗位，最终进入组织的生产流程。
第一阶段：先把专业开发者做深、做透
2025年下半年，Qoder IDE、JetBrains插件、CLI和企业版相继推出。这个阶段，Qoder的目标十分明确：围绕专业开发者构建一套完整的AI Coding产品矩阵。
它解决的不再只是代码问题，而是逐步深入真实的软件工程场景——理解项目上下文、跨文件修改代码、执行长周期开发任务，并适配不同开发者的工作习惯。从IDE、插件到命令行，再到面向企业的管理能力，Qoder正在覆盖开发者从个人编程到团队协作的完整链路。
这也是Qoder后续扩展边界的技术基础。无论产品形态如何变化，其底层始终围绕同一套核心能力展开：以模型、Context和 Harness的联合优化，让Agent不仅能够生成代码，也能够理解环境、调用工具并完成任务。
第二阶段：在“全民养龙虾”的热潮中，选择另一条路
2026年1月，OpenClaw爆火，“全民养龙虾”成为当时最受关注的Agent现象之一。大量产品试图把Agent放进个人电脑，让它在本地自主执行任务。
Qoder也看到了这股趋势，但没有直接复制一只“住在电脑里的龙虾”，而是选择从“人与Agent如何协作”出发，开发面向所有岗位的桌面Agent工具QoderWork。它不再只面向程序员，而是试图服务产品、设计、运营、市场等更广泛的职业人群。
这款产品延续了Qoder团队一贯的AI Native开发方式。团队对外给出的说法是“五个人、七天完成上线”。后来，面对外界对这一速度的追问，丁宇在一次内部会议上给出了更出人意料的答案：
“我们其实没用七天，只用五天就完成上线。之所以对外说五人七天，是怕卷到大家。”
这句话指向的不只是开发效率的变化。它指向了AI Native团队与传统软件团队的根本差别：当代码生成、测试、评审和任务执行逐渐交给Agent，制约产品迭代的主要因素，开始从“有多少人写代码”转向“团队能否定义清楚目标、组织好上下文，并管理多个Agent协同工作”。
2026年5月，Qoder 1.0发布，通用任务处理、能力扩展和全流程执行能力进一步增强。Qoder仍以专业Coding Agent为能力底座，也试图通过更低门槛的交互，把这种能力开放给更广泛的人群。同月推出的Qoder Cloud Agents，则把任务执行从本地延伸到了云端。长时间、高资源消耗的任务可以交给云端Agent持续运行，开发完成的应用也能进一步部署上线。
第三阶段：从服务个人，到走进组织
当Agent能够帮助一个人完成任务，接下来的问题自然变成：它能否成为组织生产体系的一部分？
此后，Qoder团队用18天开发并上线数字员工产品QoderWake。与普通AI助手不同，QoderWake被定义为一种“生产可用、安全可控、持续进化”的数字员工。它可以被赋予岗位角色、接入企业流程、学习组织知识，并在权限和安全规则的约束下持续工作。
这意味着Qoder面对的对象发生了变化。过去，它关注的是一个开发者怎样更高效地完成任务；现在，它需要回答一个更复杂的问题：一个组织如何招聘、训练、管理和考核数字员工，又如何让人与Agent形成新的分工关系。
市场反馈也随之出现。截至目前，Qoder全系产品已服务全球超过800万用户，企业客户达数十万家，覆盖中国东方航空、中国移动、中国交建、广东交通集团、同济大学等企业和机构，成为国内用户规模最大的Agent应用之一。根据IDC市场调研报告，Qoder在中国AI Coding市场份额位居第一。
从IDE、插件和CLI，到桌面Agent、Cloud Agents，再到数字员工，Qoder的产品边界一直在向外扩张。但贯穿三次跃迁的主线没有改变：以Coding Agent为底层能力，把代码从开发者的专业工具，转化为所有岗位都可以调用的生产力基础设施，最终嵌入组织的真实业务流程。这也解释了丁宇为何反复强调，AI Coding的终点并不是“让AI写出更多代码”。真正的变化在于，当Agent开始理解上下文、调用工具并进入协作流程，软件生产的基本单位将不再只是程序员，而可能变成“人和一组Agent”共同组成的新型团队。
水面之下：Qoder把最多的精力花在Harness上
对谈中，刘湘明问了一个很直接的问题：过去一年，你们的精力主要花在提升代码可用性上，还是花在周边这些工作上？
丁宇的回答是：“都不少。但要说排优先级和投入，我们还是在基建上花的精力最多。”他解释，Qoder的产品理念和别人不太一样，做的是“产品、Context、Harness加模型的端到端联合优化”。
这个回答，很像一个做了十几年云基础设施的人会给出的答案：用户看见的是产品能不能完成任务，背后决定结果的，却不只是模型本身。上下文是否充分、工具是否合适、执行过程是否受控，都会影响模型能力最终能兑现多少。所谓“周边工作”，并不只是代码能力之外的附加项，而是让这些能力真正可用的一部分。
丁宇接着说出了他的“暴论”：“如果你只做一个Harness，跟任何一个模型都不沾边，几乎是做不好的。”
这句话强调的不是工具和模型必须出自同一家公司，而是两者不能彼此割裂。Harness负责组织上下文、调用工具、约束执行，但这些机制如何设计，离不开对模型能力和行为特点的理解。
一套看起来通用的框架，并不天然意味着它能让所有模型都发挥出最佳表现。在Qoder内部，这种联合优化首先体现在与千问的深度协同上。
从评测、数据、分析、优化到灰度验证，Qoder的Harness都与千问深度结合；千问进行强化学习（RL）训练时使用的脚手架，也是Qoder的Harness。它不只存在于模型交付之后的产品层，也参与到模型的训练与改进过程中。
这也触及递归自我改进（RSI）所关注的一个关键问题：模型如何借助实际执行环境获得反馈，并将反馈用于后续改进。Harness离不开模型，模型的进化同样需要合适的工具和环境。对Qoder而言，两者不是先后交接的关系，而是需要持续磨合的一个系统。
不过，基建并不只体现在训练和评测中。落到工程现场，它往往是一条条具体、甚至琐碎的约束。
例如，如何让AI遵守代码仓库的架构规则？一种方式是把要求写进提示词，期待模型记住并照做；另一种方式，则是把要求变成可以执行的检查，让不符合规范的操作无法继续。
Qoder选择的是后者：把原本依赖“事后质检”的一部分工作前移，将架构规则和检查步骤固化为代码仓库中的检查关卡，通过lint、类型检查和自定义脚本识别违规操作，并在触发约束时拦截报错。
区别在于，规则不再只是AI应当理解的一段文字，而是执行过程中必须通过的一道关。可靠性也就不再完全依赖模型的“自觉”，而有了工程机制的支撑。
同一套底座之上，Qoder再按使用人群和工作方式提供不同入口。今年8月发布的全新Qoder已经不像一个传统IDE，但仍然保留了按IDE方式使用的可能。它试图改变的不是所有用户的工作习惯，而是让不同用户都能以适合自己的方式进入同一套能力体系。
上层可以越来越简洁，下层却需要足够深厚。用户不必理解模型适配、上下文管理和执行约束的全部细节，但产品必须把这些工作做好。统一的Harness，正是支撑不同产品形态的共同底座。
这套底座也经历过一次高强度的工程检验。Qoder CLI最初使用Go语言开发，后来团队判断，原有技术方案已难以适应产品快速迭代的需要，决定整体迁移到TypeScript。按照对谈中的介绍，七个人、30天，产出二十多万行代码，在用户无感的情况下完成了这次语言层面的迁移。
底层与千问深度协同，并不意味着产品层只向千问开放。
Qoder同时为多个头部模型进行单独适配。原因很实际：不同模型的训练数据、能力边界和行为偏好并不一致。工具选择、执行路径、提示词设计、上下文压缩，乃至是否支持原生多模态，都可能需要不同的处理方式。接入一个模型，只是让它能够被调用；适配一个模型，才是让它在具体任务中更好地发挥作用。
丁宇举例，有的模型当时还不支持原生多模态，团队就需要补上相应能力；有的生图模型受到用户欢迎，就把它引入产品。模型之间的差异，不应该全部变成用户需要自行研究和处理的问题。
“想用A家的模型，就得用A家的Harness；想用B家的模型，就得用B家的Harness。一个用户桌面上要装十几个桌面应用？”
这句反问背后，是Qoder对产品边界的判断：用户可以有模型偏好，但不应该因为切换模型，就反复更换工作环境、学习另一套使用方式。“Qoder is all you Need”所表达的，是希望在一个产品里承接不同场景和模型选择，把适配的复杂性留给产品，而不是留给用户。
与千问深度联合优化，和向多个模型开放，因此并不矛盾。前者追求协同的深度，后者服务于用户选择的广度。开放也不是不做适配，恰恰意味着要为不同模型做更多细致的适配。
也正因如此，当刘湘明听说Qoder开源了Harness时，有些意外：“我觉得这其实应该是一个很大的护城河。”
丁宇的解释是，这与千问模型开源的思路一脉相承。既然模型已经开放，与之深度协同的执行框架也应该让社区用得上。第三方Harness未必会专门为千问投入同等程度的优化；如果缺少这部分配套，开发者体验到的效果，就可能与模型在充分适配后的表现存在距离。
按照他的说法，开放Harness，是希望社区开发者能够直接受益于联合优化带来的成本、效率和效果改善，减少实际使用中的失败案例。“很多开发者在评测Qwen模型的时候，也一定要选择我们的Harness，这样才能给一个真实的反馈。”
人不再做Agent的“搬运工”
丁宇在对谈里描述了一个很多人都经历过的场景：把一个大任务一句话甩给Agent，它执行了7个小时，做完才发现过程不对、路走偏了。中国AI Coding的渗透率已经远超50%，手写代码和手工调试不再是主流。生产力的瓶颈，已经从写代码本身，转移到了人和Agent怎么协作上。于是，Qoder的产品思路也从“人机交互”变成了“人机协同”。
把讨论搬进任务现场
丁宇拆解过传统的工作流程：定一个需求，先拉视频会议、现场会议讨论；然后立项，定一系列需求，找人跟进，打勾看进度。“这些东西，过去跟AI都没有什么关系。”
更麻烦的是上下文。讨论完了，有人手写一份文档，再委派一个人去和AI交互，把活干了。每转一次手，上下文就可能丢一截，或者变得碎片化，有统计说，人与人沟通时，信息的接收率大概只有25%。
Qoder的做法是，把人和Agent拉进同一个讨论组。Project把大目标拆成可讨论、可委派、可验收的事项；Discussion让多个人和智能体在一个群组里，从讨论的第一句话，到委派干活，再到结果验收，所有信息都共享，由模型识别哪些是关键信息、哪些不需要。“人也不用去做一些不愿意干的活，就是整理汇总。”
解决“跑偏”的另一层办法是约束。Agent Team可以针对一类目标组建一支编队，有角色、有分工，每个Agent都有自己的约束条件，彼此牵制。丁宇说，这支编队干活时“会非常遵循你的意志”，“就像你带了一个真人团队一样”。目前，Agent Team专家团已经能让一个开发者同时拥有8个Agent并行干活。
入口的扩展服务于同一个目的。围绕一个人工作的Agent越来越多，人需要随时调度和管理它们，又不能被绑在电脑前。“所以我就用手机、眼镜，或者我的耳机，各个设备去跟它连接、管理。”丁宇的说法更直白：“就是让每个人可以养更多的Agent。”
看不见的效率：软件工程与安全
AI Coding让代码产能过剩，随之而来的是整个行业都面临的难题：代码写得越快，“屎山”也堆得越快。如果大家只沉浸在生产代码的快乐里面，产生了大量代码，而测试、Code Review、集成回归的自动化程度和数量不成比例，它最后一定会拖垮你。
我们的经验是：“如果你多产生了五倍的代码，就要多产生十倍的测试，把大回归的自动化提升十倍，才能把缺陷率压下来。”软件架构、质量、安全生产、稳定性和高可用，这些人类沉淀下来的最佳实践依然适用。区别在于，执行者换成了Agent，“不是说模型就可以放飞自我”。丁宇说：“在Harness之上还可以再做Harness。”
Qoder走的是“循环工程”（Loop Engineering）的路子。补测试用例、Code Review、集成回归、线上答疑、修Bug，都由循环工程里的智能体唱主角。
团队的考核方式也跟着变了：看的是智能体在循环里独立完成了百分之多少的工作。Qoder从30%左右做起，现在很多领域能做到60%。Code Review已经到了70%，也就是说，七成代码经过智能体审查就可以直接合并。为了把这个比例往上推，团队不断加能力、加校验规则，还会换一个模型来交叉验证。
据了解，Qoder团队的月代码产量，比2026年初提升了五倍。
让发现漏洞的，也去修漏洞
当AI把代码生产速度推高，安全就不能继续留在开发流程的末端。否则，前端节省下来的时间，很可能变成后端排查漏洞、修复问题和反复验证的成本。
Qoder Security要解决的，正是从“发现问题”到“解决问题”之间的这段距离。据丁宇介绍，Qoder Security基于阿里巴巴安全团队自研的安全大模型，针对代码安全场景进行强化，用一个专门检查安全的模型，交叉检查另一个模型生成的代码。生成模型关注如何实现功能，安全模型则从另一种视角审视产物：功能实现的同时，是否引入了安全问题。
这背后的思路，不是要求一个模型同时把所有事情做好，而是让不同能力的模型相互补充，把安全检查嵌入代码生产过程。
更重要的变化发生在检查时机上。过去，安全问题如果到了工程完成后才被发现，往往需要重新定位代码、理解业务逻辑，再修改和验证。问题发现得越晚，牵涉的环节就可能越多。为什么不在生成第一行代码的时候，就检查出安全问题？
因此，Qoder Security将“安全左移”和“默认安全”作为产品设计理念：安全不应是一项等开发结束后才想起来的附加工作，而应成为开发流程的一部分。为此，产品设置了四个检查切面，由管理员统一下发配置，在相应环节触发扫描。发现问题后，系统给出修复建议，开发者确认后即可执行修复。
丁宇用一句话概括这种变化：“以前代码是你生产的、我发现的，你来修复。现在是它生产的、它发现的，它来修复。”
当然，自动修复不等于安全责任也可以一并交给AI。开发者仍需判断修改是否符合业务要求，企业仍需明确安全规则和验收标准。“默认安全”也不是对代码绝无漏洞的承诺，而是尽可能让检查与修复更早发生、更容易执行。
据发布会披露，Qoder Security累计完成安全扫描180万次，发现并修复漏洞5.8万个。刘湘明把这称作“看不见的效率”——它不像生成一个页面、上线一项功能那样直观，却体现在少一次跨团队沟通、少一轮事后返工，以及更早消除一个可能进入生产环境的问题。
用Qoder造Qoder：一支团队的AI Native创新
Qoder团队是阿里内部最早的AI Native团队之一。丁宇的逻辑很简单：“我们自己在创造Agent，在改变别人的生产力和生产关系，就要先改变自己。”
丁宇形容这一年的状态，“就像脚踩风火轮，每天双十一，持续驻扎在作战室打仗”。很多同学加入团队后，就再没离开过项目室。速度就是这样被跑出来的。QoderWork从研发到发布的闪电速度，是团队的“标志性事件”，它让团队真正进入了AI Native的组织形态和研发范式。QoderWake、移动端、语音功能，都在18天内完成。从通义灵码到Qoder CN版的整套升级迁移，用了30天。
“我们创造了奇迹，奇迹成就了业务。”丁宇说。
工种消融，中间产物消亡
在Qoder团队里，产品经理、设计师、前端、后端、架构师、测试，不再按工种排队交接，而是围绕一个需求坐进同一个“项目作战室”。随时共享上下文，需要时随时开会，不需要时谁也不打扰。“用Agent所有事情都已经同步完了，会也不用开。”大家也不再各自向自己的老板汇报，而是都为同一个需求和产品负责。
工种的边界随之模糊。后端不一定写代码，产品经理可能也不写需求文档。讨论需求时产品经理仍然主导，但可能只是用语音把讨论录成素材，直接交给模型去做。
设计师也开始开发功能。丁宇回忆过去的流程：设计师出一张视觉稿，交给前端拆图、切图，大家为像素对不齐纠结半天；前端做完页面，再交给后端对接数据库和架构。“在AI能力非常强的今天，这些角色之间的区别已经被弥合掉了。”
被取消的还有中间产物。设计稿、PRD、测试文档，统统被Spec取代。丁宇说，过去的文档有生命周期，写完需求文档，大家去做新需求，文档就废弃了；Spec则直接丢给模型，模型照着就把东西生产出来，“设计即代码”。人要掌控的，是整体的定义、结构、约束和非功能性需求，所以团队里依然保留架构师。
他算过一笔账：开发者过去只有三分之一的时间在写代码，另外三分之二花在沟通、对齐、开会、培训和各种事务上。AI Native组织要做的，就是把那三分之二优化掉。结果是，团队效率至少提升了十倍，发版从“一周一次就算非常高效的互联网团队”，变成了一天1到2次。“这就是AI时代的速度。”
不限Token，一人一台Mac mini
刘湘明问：很多人说AI提高了个人效率，组织效率反而降低了，你们是怎么形成正向循环的？
丁宇的第一条经验是：先放开Token，让大家充分释放生产力。
第二条，是给每个人配一台Mac mini，作为“第二台电脑”，专门跑数字员工。“有个人在你的工位上一直帮你干活，或者在你的会议室里一直帮你干活。”人拿着自己的电脑去做别的事，注意力被释放出来。
他的逻辑是：人很难一天8小时、10个小时高强度产出，但Agent可以，“它不会累，不需要休息，不需要下班”。人要做的，是变成管理者，管好它们。
第三条，是把最优秀的人当底线。团队会挑出最优秀员工沉淀下来的技能和Agent，“蒸馏”后复制给其他人。“大家PK一下，谁的闭环率高，谁的循环工程做得好，大家就都用他的，再在上面二次发挥。不是把你自己作为底线，而是把最优秀的人作为底线，大家再去提升天花板。”
从团队实践到产品：QoderWake与Cloud Agents
那台“第二台电脑”，变成了一款产品
团队给每个人配的那台Mac mini，在云栖大会上变成了一款产品：QoderWake数字员工。
QoderWake不是一个AI工具，而是企业的“新的headcount”。招人、培养人，对企业来说一直是件难事；而一个数字员工，一天之内就能完成安装部署、技能启用和各种配置，然后上岗干活。“像一个员工”，是这个产品的关键。它可以部署在自己的电脑上，但自己的电脑会关机。所以更好的选择是部署在云电脑，或者Mac mini这样的独立设备上，7×24小时持续工作。
接下来就像带一个新人。一个研发团队的leader，可以给自己配上设计师、产品经理、研发等不同角色的数字员工，把它们加进IM和各种流程，给它们素材，让它们看别人怎么工作，自己整理归纳、学习。它们可以拉群讨论，可以整理会议纪要，可以是你的数字分身，也可以是你的下属或同事。
“其实就跟咱们带一个新的实习生、新的同学一样。”但是这个比培养一个人快得多，模型的智商是很高的。你把相应的技能、流程数据和上下文给它，它就会做得很好。
有的企业不仅给数字员工配了工位和电脑，还给了它一个工号，让它在群里参与讨论，真的像一个员工一样做事。由此也提出一个组织度量标准：看一个组织是不是AI Native，就看数字员工的比例。数字员工比例高、能实现5到10倍提效的，就是优秀的AI Native组织。
据发布会披露，QoderWake已服务超过2000家企业，部署数字员工10万个，岗位覆盖产品、市场调研、设计、文档、研发、测试、数据、客服等，生产力提效10倍。
本地跑也挺香，为什么还要上云
人可以随时切换工作场景，正在执行的任务却未必适合跟着中断。Agent越能承担复杂工作，执行时间和资源需求就越可能超出一台个人电脑的承载范围。
这让丁宇重新审视了团队已经拥有的能力。“今天云的能力这么强”，CPU、GPU、云端电脑、云沙箱、开放API等配套设施已经具备，Coding Agent也能承担越来越复杂的任务。那么，能不能把两者组合起来，让适合在云端执行的工作，不再被绑定在用户的电脑上？
这是Cloud Agents要解决的第一层问题：把开发任务委派到云端，减少长任务对本地设备的占用。但更深一层的需求，发生在开发完成之后。
一个在线应用写好了，Qoder已经能够帮助用户一键部署到云上。如果开发出来的本身就是一个智能体应用，事情就不只是上传代码、启动服务那么简单了。它需要持续调用模型、使用工具、执行任务，还要管理运行环境、Harness、访问凭据和并发请求。随着使用者增多，生命周期管理、稳定性和安全也都要纳入考虑。
换句话说，让Agent替自己完成一次任务，与让一个Agent上线、持续为其他人提供服务，是两种不同的工程要求。前者解决“能不能做”，后者还要解决“如何持续运行、如何管理”。
“这些东西其实都是ready的，只要你把它产品化。”丁宇说。
这里的产品化，不是简单地把一组云服务入口放进开发工具，而是把原本需要开发者分别理解、配置和衔接的环节，组织成一条连贯的工作流程：在Qoder中开发应用，将任务交给云端执行，再把开发出的智能体部署上线，并纳入后续维护和生命周期管理。
这也是阿里云的基础设施积累与Qoder的Coding Agent能力发生交汇的地方。前者提供运行所需的计算资源和环境，后者连接开发、部署与维护。对于用户而言，目标不是多学一套云产品，而是减少从“做出来”到“用起来”之间的障碍。
目前，Cloud Agents已覆盖数十个行业场景，服务超过千家企业。这意味着，它所面对的需求，已经不只是个人电脑上的效率提升，还包括智能体如何进入真实业务、承接持续服务的问题。
因此，本地与云端并不是一道非此即彼的选择题。本地运行有它的便利，云端则承接那些需要更长执行时间、更多资源和持续在线能力的工作。当Agent从个人工具走向面向他人的服务，“在哪里运行”就不再只是部署偏好，而成为产品能否进入生产环境的一部分。
不做“中国版谁”，寻找自己的下一步
在云栖大会之前举行的Qoder一周年内部大会上，阿里巴巴集团CEO吴泳铭、CTO吴泽明等核心管理层一同出席。吴泳铭说，自己也是Qoder的忠实用户，使用中遇到问题，会直接转给团队。他对这款AI Native产品的期待很具体：应该做到一天一个版本。
更大的期待，则指向产品的边界：Qoder要从“程序员工具”走向“所有人的操作系统”。工程师仍然是最重要的硬核用户，但它未来要帮助的，是所有用电脑工作的人。
这里的“操作系统”，更适合被理解为一种工作入口的愿景：用户不必先判断该打开哪个软件、调用什么工具，而是先表达目标，再与Agent一起完成任务。它要求Qoder不只会写代码，还要能理解不同岗位的上下文，把工具、信息和执行过程组织起来。
这也构成了Qoder必须处理的一组关系：既不能丢掉专业开发者所要求的能力深度，又要让不懂代码的人用得起来。用户范围扩大，不意味着专业能力可以降低；恰恰相反，只有底层能力足够扎实，产品才有可能把复杂性留给自己，把简单留给用户。
沿着这条路线，Qoder不可避免地被拿来与OpenAI的Codex比较。随着Codex从编程向更广泛的任务场景延伸，两者的产品边界出现更多交集，“中国版Codex”的说法也随之增多。
丁宇并不愿意用这个标签定义Qoder。
“每一个产品有它的哲学和设计理念，我们不想成为中国的谁谁谁。”他承认，两者在扩展能力、专业开发者与泛用户的覆盖上，有相近的选择。但在他看来，区别不仅在功能清单里，也在于如何进入用户所在的行业和工作流程。
Qoder更看重生态的结合、开放与集成。“我们为什么跟中国移动、联想合作，他们要的未必是Coding这个动作，而是Coding的能力。”
这句话划出了一条重要的边界：并不是所有合作伙伴都需要再做一款编程工具，但它们可能需要让自己的产品具备理解任务、调用工具、生成代码并完成执行的能力。Qoder想提供的，不只是一个供人直接使用的应用，也是一种能够被其他产品和行业场景调用的能力。
不愿成为谁的翻版，并不意味着回避竞争。在内部，丁宇给团队定下的要求是，面对全球最强的几家对手，要“追得上、对得齐、有创新”。
谈及未来，丁宇给出了他的一些思考：
首先，没有人能确定产品的终局。丁宇说，模型能力不断变化，Harness随之调整，产品交互和任务组织方式也在演进。今天有效的产品形态，未必会成为明天的标准。对团队而言，难点不只是快速增加功能，还在于判断哪些设计值得积累，哪些需要随着能力变化重新来过。
其次，开源既是机会，也是持续的竞争压力。有动手能力的工程师可以选择开源工具，自行组合模型和运行环境。对于Qoder，单纯提供一个调用模型的界面，很难成为长期优势。它需要在模型、Harness、Runtime、基础设施和产品之间做联合优化，让用户在任务完成度、成本、时延和使用体验上，感受到一体化产品的价值。
这也不是一道简单的“开放还是封闭”的选择题。丁宇在对话中同样谈到了开放Harness的计划：让更多开发者受益于模型与Harness的联合优化。真正需要建立的优势，并不是把每一层能力都封闭起来，而是持续把这些能力组合得更好。
最后，是每个使用者都要面对的成本问题。丁宇观察到，一个人每月的Token开销，可能从去年的百元，增长到今年的数百元、数千元，部分高强度使用团队还会更高。他把这种真金白银的投入，视为AI开始进入真实生产的信号。
但愿意付费与持续获得回报，仍然是两件事。对企业而言，最终要计算的不是消耗了多少Token，而是完成了多少有效任务、减少了多少人工和返工，以及这些收益能否覆盖模型调用、部署和管理的成本。Agent越深入业务，这笔账就越需要算清楚。
对话接近尾声，刘湘明问：一年后，如果两人再坐在这里，会聊些什么？
丁宇没有给某种产品形态下定论，只给出了一个判断：“那些跟着最好的模型，构建了最好的Harness，做了最好的上下文，并基于这个做出最好产品的团队，会胜出。”
刘湘明接了一句：“其实你描述的，就是Qoder团队。”
478天前，Qoder还是西溪园区一间小项目室里、由少数人做出来的产品。如今，它已被放到阿里Agent战略的重要位置。从服务程序员，到尝试帮助所有用电脑工作的人，团队面对的问题也变了：不再只是证明AI能把代码写出来，而是证明它能够在越来越多的工作中，持续交付值得信赖的结果。
这比一天发布一个版本，更难。（本文首发于钛媒体APP）
更多精彩内容，关注钛媒体微信号（ID：taimeiti），或者下载钛媒体App