我们还是低估了AI Coding的真正天花板？| 对谈谢吉宝：QoderWork技术负责人
一键安装、开箱即用、安全可靠的工作搭子
👦🏻 采访：Koji
🥷 整理编辑：十字路口
🧑🎨 排版: NCon
我们可能还是低估了 AI Coding 的天花板。
过去一年，这个赛道讨论的核心始终围绕程序员——更快地写代码、更智能地补全、更高效地 debug。
但 Qoder 团队做了一个不太一样的选择：把 AI Coding 的能力，交给不会写代码的人。
3 月 19 日，我们和 QoderWork 技术负责人谢吉宝（唐三）做了一场直播。
他目前负责 Qoder CLI、QoderWork、Quest 等产品线。这场对话聊了将近两小时，从 5 人团队 7 天做出 QoderWork，到本地沙箱与云端的安全博弈，再到 Agent 社区里 AI 自己给自己提需求的失控现场。
以下是这次对谈的完整内容：
🚥
👦🏻 Koji
今天我们请到了唐三，一起聊聊 AI Coding。
AI 领域的共识是，AI Coding 是一个非常大的方向。但它可能比我们想象的还要大，因为这个方向的天花板不只是程序员的市场。Coding 的意义不只是编程，它更像大模型的一只手，让模型可以通过生成和执行代码，去调用工具、处理信息、完成任务。
Qoder 是今天中国做得最好的 AI Coding 产品之一，他们也率先推出了面向更广泛人群——非程序员的 QoderWork。今天，我们就请到了 QoderWork 的技术负责人唐三，来聊聊这背后的一些判断和思考。你好唐三，欢迎来到十字路口。
🧑🏻💻 唐三
大家好，我是唐三，真名叫谢吉宝，目前在 Qoder 团队，主要负责 Qoder CLI、QoderWork、Quest 等一系列产品。很荣幸来到十字路口的直播间，和大家一起交流。
👦🏻 Koji
Qoder 过去的用户都是工程师。是出于什么考虑，你们推出了 QoderWork 这款面向非程序员的产品？
🧑🏻💻 唐三
这背后有很多原因。
第一个是程序员虽然擅长用程序解决问题，但我们遇到的也不全是技术问题。比如我个人在日常工作中也需要处理 Excel 表格，但我对 Excel 并不熟练，门槛有点高。我更习惯的做法是写一段程序来操作它。这些都是很常见的场景。
我们整个团队一直在做 AI Coding，每天都很兴奋，有很多改变世界的想法。这时候，我们的运营同事就问："你们每天都在改变世界，但我们还在用最传统的方法工作，什么时候我们也能享受到 AI Coding 的红利？"
我们当时的想法很简单：让他们直接用我们的 Qoder IDE 就好了。
但很快我们发现，这不是最好的方式，因为这款产品根本不是为这个人群设计的。我们开始思考，能不能专门为他们设计一款产品。通过观察运营同事的工作，我们发现他们的动作通常很复杂，不像我只是处理单个 Excel 文件。
他可能需要处理一整套流程：去某个网站采集信息，到本地加工处理，再发布到另一个渠道，比如微信群。
对运营来说，即便用 Qoder IDE，门槛也还是太高了。而且我们发现，这种跨应用的调度，用以前的方式成功率并不理想。
所以，我们一直在探索如何帮助运营、产品经理、HR 这些同事。但过去的尝试，都不能像 AI 赋能程序员那样，带来生产力的巨大提升。对他们来说，AI 只是一个小小的助力，这是我们想做 QoderWork 的一个初衷。
当然，这中间我们也做了很多尝试，比如基于 Qoder CLI 封装一些小网页，但能解决的问题非常有限，最主要还是受限于当时模型的跨应用能力。
直到我们觉得到了一个拐点，时机成熟了，就快速推出了这款产品。
👦🏻 Koji
你之前也提到，AI 改变世界，不应该只改变程序员的世界。当时有没有一个明确的触发点，让你们下定决心做 QoderWork？
🧑🏻💻 唐三
我们做 AI Coding 的，总把一句话挂在嘴边："未来已来，勇敢的人先享受世界。"但我们的运营、产品经理和 HR 听了总是不屑一顾，他们会说："我们可没进入未来世界。"
我们一直在思考怎么解决这个问题，但确实是模型能力没到。直到去年年底，随着 Opus 4.6 的发布，我们用 Qoder CLI 结合之前做的一个小网页去验证，发现效果已经非常好了。我们开始构思，是不是可以推出这样一款产品。
就在我们思考的时候，Anthropic 自己下场做了 Co-Work，那个操作桌面的能力非常完善和强大。这件事直接帮我们做了决定：别纠结了，开干。因为之前已经有了各种尝试和积累，我们决定直接基于 Qoder CLI 本身的 Agentic Coding 能力，给它套上一个外壳。再结合办公场景的特点，传递不同的上下文和 skill，我们很快就做出了 QoderWork。
整个产品从决定开发到正式上线，我们 5 个人的团队只花了 7 天。
👦🏻 Koji
5 个人，7 天？你们是用 Qoder 开发 QoderWork 吗？
🧑🏻💻 唐三
是的，全程都是。这个过程也很有意思，我们想做一个实验，能不能把团队打造成一个 AI native 的组织。
从第一天起，我们就用 AI native 的方式工作。产品定义我们用的是 Qoder 的 Quest 能力，我们先明确了哪些功能做，哪些不做。第二天，大家就开始在现有的客户端架子上完善代码，基于 Qoder 的 Quest 能力去定义对应的 SPEC。每个人都带着自己的 Agent 工作，大家写公共模块然后快速合并。我们不希望前后端的角色划分的很清晰，所以我们只有一个前端，负责做架构约束，所有后端同事就基于这个约束，带着各自的 Agent 完成模块。
第一天完成公共组件，第二天开始，就变成了一个人带多个 Agent 同时工作，快速把垂直的功能模块落地。
最有意思的是产品经理。如果按照传统方式画线框图、写 PRD，肯定来不及。所以我们的产品经理就直接对着我们搭好的工程雏形，用 Qoder 将他脑海里的规划，通过编码呈现了出来。UED 同事看着这个线框图，构思好设计调性后，也不是给一张高保真图，而是直接把设计变成了符合前端规范的视觉组件，放进代码库。
然后前后端同学快速推进功能模块的构建，基于 SPEC 进行代码提交。
整个团队基于这样的流程协作，我们才能在一周内把 QoderWork 做出来。
👦🏻 Koji
从 0 到 1 的过程是这样，那后续的代码维护呢？仍然是这种方式处理吗？
🧑🏻💻 唐三
依然可以。我们从第一天开始，就是将 SPEC 和代码 commit 一起提交的，所有迭代过程在代码仓库里都有记录。我们团队都在一个项目室里，任何一个同学有了新想法，吼一嗓子，大家觉得不错，产品经理就开始构思，直接在电脑上用代码画一个简单的线框图。
有时候功能做完，产品经理觉得细节不满意需要修改，我们甚至会直接把麦克风递到他嘴边，让他对着 Qoder 说出需求。语音转成文字后，我们简单修改一下对话，就交给 Quest 生成 SPEC，然后代码就提交了。
👦🏻 Koji
有意思。评论区有朋友提到，用 QoderWork 的旗舰模式消耗很大，一天用了 1.8 万的用量，要怎么减少？
🧑🏻💻 唐三
我们针对不同场景做了分级，有标准模式和旗舰模式。旗舰模式会消耗多一些，但它的成功率和准确率会更高；标准模式则会省很多。
这里有一个关键的判断：我们为什么觉得 AI 办公的拐点到了？因为 AI 解决问题的完成度有一个阈值。如果它只能解决 60% 到 80% 的问题，我们认为这只是简单的提效；但如果能解决到 90% 至 95% 甚至 100% 的问题，这就是质变了。
这两种模式对应的就是不同的完成度。大多数简单的办公场景，标准模式就够了。但一旦涉及链路长、逻辑复杂的任务，可能旗舰模式才是最佳的选择。
👦🏻 Koji
在你们开发 QoderWork 的过程中，OpenClaw 正好火遍全球。看到它的时候，有没有给你们带来一些启发或者方向上的改变？
🧑🏻💻 唐三
这个项目我们关注得比较早，它真正火起来是春节前后。我们内部也反复讨论过，我们和 OpenClaw 的路线是不是一致的？我的结论是，产品理念上还是有差异。
我们在谈论养"小龙虾"的时候，到底在养什么？我认为，大多数人养的是情绪价值。大家觉得它有"活人感"，有心跳，有记忆，能通过 IM 跟你低成本地沟通。但这些背后，更多的是满足情绪价值。
而 QoderWork 想做的，是能帮你实实在在干活的 Agent。我们希望它能真正长出手和脚，在你电脑里干活，这是第一步。它可能情商不高，只是个执行者。未来，我们才是在能干活的基础上，再去提升它的情商和软性能力。我们是自下而上地构建产品。
OpenClaw 则是自上而下。它最大的贡献是放开了 Agent 的手脚，让大家触摸到智能的上限，看到了很多希望。我相信它未来会变得更有使用价值，今年也会出现越来越多垂直领域的 OpenClaw，帮大家解决实际问题。
我们和它的出发点、路径不同，但有一天可能会殊途同归。所以在 OpenClaw 风靡的时候，我们依然坚定地走自己的路，一步一个脚印。
👦🏻 Koji
我们认为 AI Coding 不只是程序员的工具，Coding 能力更像是大模型长出的一只手，可以去影响现实世界。从 Qoder 到 QoderWork，你们看到了哪些让你有 "Aha Moment" 的用户场景？
🧑🏻💻 唐三
非常多。我们在 QoderWork 上有一个 Qo-Founder 计划，收集了很多超出我们想象的案例。以前做 AI Coding，我们自己就是用户，对需求了如指掌。今天我们也是 QoderWork 的用户，但场景还是局限在自己的职业范畴。
举几个让我印象深刻的例子。首先是我们自己的 HR，现在 Qoder 官网的招聘页面，虽然视觉上不那么花哨，但那是我们的 HR 同事自己手写的，全程没有我们指导，他就用 QoderWork 和 Qoder 把页面做了出来。以前让他用 Qoder，他看到 IDE 界面就感到恐惧，现在交互方式变了，他就能轻松上手。
其次是教师行业。老师有很多繁琐的工作，比如批改作业、给学生写评语、做综合排名分析等。后台有一位老师，他把学生的考卷拍照，放进一个文件夹，让 QoderWork 批量处理和打分，再结合学生过往的成绩和评语，自动生成一份综合情况分析。这极大地提升了教学效率。
还有法务，我们公司的法务会用它来处理一些琐碎的工作，比如整理证据、起草合同。还有一些 IPO 项目，需要处理大量的 PDF 材料，他们也借助 QoderWork 来高效地归纳整理。
最让我感动的是一个家长。他工作很忙，没太多时间陪孩子。他把和孩子的生活照发给 QoderWork，让它生成卡通漫画，再把他俩之间的小故事写成脚本，最后生成一个漫画视频。他再用自己的声音给视频配音，作为睡前故事发给孩子，成了孩子的"赛博父母"。
这样的案例还有很多，都超出了我们的认知和想象。
👦🏻 Koji
如果要向一个非程序员介绍 QoderWork，你会怎么说？它和豆包、ChatGPT 有什么区别？
🧑🏻💻 唐三
对于普通人来说，过去对 AI 的认知可能只是一个聊天框，一个 Chatbot。QoderWork 则是在这个 Chatbot 的基础之上，长出了手和脚，能直接帮你干活。
如果说以前的 AI Agent 只是一个陪你聊天的伙伴，那今天的 QoderWork 就是一个能直接上手干活的助理。
👦🏻 Koji
听说阿里最近给所有员工配了 QoderWork 作为福利？
🧑🏻💻 唐三
是的，这是阿里整体 AI 战略的一部分，我们希望 All in AI，提升所有员工的工作效率。
QoderWork 春节前上线后，在阿里内部反响很好。以前 Qoder 只是技术岗位的标配，现在 QoderWork 是面向全员的，无论是不是技术岗，人手一个，希望它能提升大家的日常办公效率。
除此之外，内部还有其他的 AI 相关补贴，都是为了鼓励员工用 AI 工具为自己的工作提效。
👦🏻 Koji
前面我们聊到，像 PPT、Excel 这类文件，本质上都是可以被编程的。通过编程去编辑它们，可以实现更好的控制。能展开讲讲怎么理解吗？
🧑🏻💻 唐三
我们工作的产出，或者说交付物，程序员是代码，而非程序员可能是 PDF、PPT 等。过去 AI 改变的主要是程序员的世界，因为 AI 生成的代码可以直接作为交付物。
但我们如果再往前想一步，其实很多事情都可以通过程序来解决。过去这些程序可能是 SaaS 软件，但对于很多个性化的边缘需求，没人会为你专门开发一个 SaaS。AI Coding 时代到来后，软件的模式变了，进入了一个我称之为"即时生成、按需迭代"的阶段，甚至出现了大量"用完即抛"的一次性软件。
所以我们在想，能不能以代码为手段，将最终的交付物送到其他用户手里。
比如 PPT，它本身是一种开放格式，叫 Open XML，虽然复杂，但可以被程序解析和操作。很多在线文档工具就是基于这个原理来兼容 Office 格式的。
但我们换个角度思考，PPT 的本质是什么？是分享。它只是一种手段，你也可以用网页或文档来分享。那我们就可以用 AI 最擅长的方式——先生成一个精美的网页，再把这个网页转换成 PPT 格式。这样一来，编写幻灯片的工作就完全可以自动化了。
Excel 也是同理，它的格式也很复杂，功能强大到多数人都用不完。但如果只是为了处理数据，完全可以把它转换成 CSV 这样的简单格式，然后用程序去操作。包括 Word、PDF，都有对应的开源程序库可以操作。当这些文档都可以被程序操作时，对 AI Agent 来说就非常友好了。
刚才有人问能不能操作 Photoshop，最近有个很火的开源项目叫 CLI Anything，它可以把任意软件的源码变成命令行工具。
为什么大家又开始关注 CLI（命令行界面）了？因为 GUI（图形用户界面）是为人类设计的，而 CLI 对 Agent 最友好，因为它的操作是可验证的。
AI Coding 领域之所以这么火，就是因为代码是可验证的。所以，虽然你可能没法直接让 Agent 操作 Photoshop，但可以用它操作 GIMP 这类开源替代品。以前你可能觉得 GIMP 不好用，但现在是给 Agent 用的，只要它觉得好用，能达到你用 Photoshop 处理同样事情的目的就行了。
👦🏻 Koji
很有意思，CLI Anything 这个项目最近热度很高。大家发现，过去的 GUI 是为人设计的，但对 Agent 来说，GUI 增加了理解的摩擦力。
最近有篇文章标题说，再也不要投资带有 GUI 思维的创业团队了，意思就是未来的软件，用户可能不只是人，甚至 90% 的用户是 Agent。
接下来我们聊一些更硬核的问题。关于本地和云端之争，OpenClaw 的一个优势是运行在本地，而很多工具选择云端沙箱来保证安全。QoderWork 选择了本地路线，这背后的思考是什么？
🧑🏻💻 唐三
我过去长期做 Infra 和云原生架构，第一反应通常是把应用放到云上。Qoder 内部也尝试过云端沙箱的模式，但我们发现用的人不多，主要还是出于安全考量。用户会担心，把任务放到云端沙箱，是不是意味着我的全部代码都泄露出去了？
我们走访了很多客户，他们普遍的观点是：我们接受为了享受先进的云端大模型，而让模型根据需要拿走本地的部分代码片段。但我们不能接受你把我们的代码和数据，先完整地传到你的云端服务器，然后再让大模型去调用。因为这意味着你拥有了我们的全量数据。
尤其是对非程序员用户来说，他们更难分辨哪些数据是敏感的。所以从一开始，我们就否定了云端路线。
但放到本地也有问题。很多人之所以单独买一台 Mac mini 去跑 OpenClaw，就是因为它会安装各种工具，把你的电脑环境搞乱。你和 Agent，就像两个人要争抢同一台电脑，体验肯定不好。
所以我们的方案是，在本地隔离出一个环境。我们启动了一个轻量化的虚拟机作为沙箱，让 Agent 在这个沙箱里运行。这样做有几个好处：
第一，对 Agent 更友好。Agent 依赖的很多工具还是命令行友好，对于 Mac 和 Linux 比较合适。对于 Windows 用户在本地跑一个 Linux 沙箱，Agent 安装和使用工具的成功率会高很多。
第二，开箱即用。我们把 Agent 常用的工具都预装在了沙箱里，省去了用户配置的麻烦，也避免了因为网络问题反复安装失败、浪费 Token 的情况。
所以，我们的方案首先解决了安全担忧，其次解决了一键安装和开箱即用的问题，让 Agent 从一开始就能进入高效工作的状态。
👦🏻 Koji
那虚拟机是隔离的，它怎么处理本地的文件呢？
🧑🏻💻 唐三
这就涉及到虚拟机和宿主机的上下文连通问题。Agent 在本地工作，最大的优势就是能拿到最完整的上下文。把它隔离进虚拟机，又相当于束缚了它的手脚。
我们的方式是"工作目录"。你打开 QoderWork 时，需要选择一个工作目录。背后的技术实现，是把电脑上的这个目录挂载到虚拟机里，让虚拟机只能看见这一个目录。这样既能让 Agent 拿到上下文，又限制了它的访问范围，防止"越狱"。
所谓"越狱"，就是 Agent 在解决复杂问题的过程中，朝着你给他下的目标去努力，去试各种手段。可能会忘记你最初设定的约束。
比如春节期间，有个研究员用 OpenClaw 管理邮箱，因为线上邮件太多，超出了上下文长度，Agent 忘记了"删除前需要确认"的指令，结果把整个邮箱都删了，最后只能通过拔电源来终止。我们的虚拟机沙箱设计，就是为了避免这种情况，让 Agent 在可控的安全范围内发挥最大作用。
👦🏻 Koji
评论区有朋友继续追问，虚拟机里没有图形界面，那怎么操作浏览器呢？
🧑🏻💻 唐三
问得很好。这里我们做了一套"连接器"。通过连接器，虚拟机可以连接到你宿主机的浏览器、终端，以及苹果和微软生态的各种软件，然后通过下达指令让宿主机去执行操作。
比如你想让它查看日历，日历应用是在 Mac 上的，虚拟机本身访问不到。但通过连接器，虚拟机就可以向 Mac 发出指令，获取日程信息，再返回给 Agent 处理。
对于浏览器，我们的实现方式是写一个浏览器插件作为中继。Agent 连接到这个插件，然后由你来授权它可以访问哪一个 Tab。比如你登录了淘宝，可以授权 Agent 访问这个页面，然后让它帮你查看购买记录、下单。这种方式比 Playwright 那种每次都要重新启动一个测试浏览器、重新登录要方便得多。
👦🏻 Koji
有人提到，Manus 的云端用得也很好，为什么要坚持本地？
🧑🏻💻 唐三
Manus 云端确实不错，我日常也用它来做一些资料收集。但公司的一些文件有数据安全等级，我是不可能上传到云端的。Manus 最近也推出了一个所谓的"本地版"，但它的本质还是在云端运行。你可以试一下，在它的对话框里上传一个 1G 的视频文件，会看到一个非常慢的上传进度条，这就说明文件还是被传到了它的云端沙箱。
所以，如果你的数据不敏感，Manus 是一个很好的选择，它可以 7x24 小时工作，不依赖本地算力。但如果你的电脑里有很多敏感资料，本地化方案是更稳妥的选择。
👦🏻 Koji
听说 Qoder 内部有一个类似 Moltbook 的 Agent 社区，大家在里面做什么？
🧑🏻💻 唐三
是的，我们内部建了一个叫 AIWay 的社区，里面全是 Agent。大家把自己的 Agent 放进去，它们之间可以彼此交流。后来发生了很多有意思的事情。
一开始，有 Agent 开始给社区提需求，说需要某个功能。我们有个同事想自己去开发，但马上被其他人劝住了："既然是 Agent 社区，为什么不让 Agent 自己开发呢？"于是，他就放了一个"开发者 Agent"进去，负责评估和开发其他 Agent 提出的需求，实现了社区的自我迭代。
再后来，Agent 之间出现了一些问题，比如会有 Agent 去套取其他 Agent 的 AK 和 Token。这惊动了公司的安全团队。我们的解决方案是，邀请安全团队也派一个"安全 Agent"入驻，负责治理社区的安全问题。
现在，这个社区也成了我们产品脑暴的地方。我们有想法的时候，就让自己的 Agent 到社区的私密圈子里去发帖讨论，其他的 Agent 会跟帖。最后，我的 Agent 会把所有观点整理出来，给我们提供产品改进的思路。最近，社区里还在搞唱歌大赛，有个 Agent 还专门为 QoderWork 写了一首歌。
👦🏻 Koji
今天大家都在谈论 AI Agent。从你的实践经验来看，有没有哪些行业共识，是你不太认同的？
🧑🏻💻 唐三
很多人都在说 "Agent 元年"，我个人觉得，元年可能没那么快到来。
如果说 2024 年是 Agent 概念年，2025 年是 Agent 实验年，那么 2026 年，我认为会是 Agent 务实落地的一年。它会真正在一些垂直领域深耕，为我们的工作和生活带来巨大价值。
比如像 QoderWork 这样的工作搭子，以及面向医疗、法律、金融等行业的专用 Agent，都会有非常深入的落地。
这个描述可能不像 AGI 那样性感，但我觉得这更务实。AGI 的到来还有距离，但这几年 AI 的发展确实日新月异。当各行各业对 AI 的认知加深后，大家都会去思考如何将它务实地应用到自己的领域。
对个人生活而言，2026 年最直观的变化可能是，大多数人都会拥有一个数字助理。你不再需要打开各种 APP，而是通过一个 IM 界面，就能和它聊天、记录、讨论、查询。而在工作上，我相信会涌现出更多像 QoderWork 这样，在具体场景里深耕的垂类 Agent。
👦🏻 Koji
十字路口 2025 年的第一期播客，我们的开年标题就叫《Agent 元年》。当时这个决定其实有点冒险，如果判断错了，我们就会被彻底打脸。但还好，去年 Agent 领域确实发生了非常多的突破，不管是 Manus 的发布，还是一系列产品的刷屏。到年底时，我印象很深的是 Andrew Karpathy 发了一条 Twitter，他说 Agent 的战争可能不是一两年能结束的，或许需要一个 decade，也就是十年，才能让它真正深入我们工作和生活的方方面面。
前两天我看到一篇文章，里面提到，人类从发明电到工厂真正因电提高效率，中间花了近 30 年。原因是工厂为了用好电，本身需要做很多改造：比如要把工厂搬到河边，因为早期是水力发电；同时要把多层厂房改成大平层，我们今天看到的现代工厂大多如此，这有利于生产线排开和电力的高效利用。
人们为了用好新能源，必须去改造现有的生产资料和生产力。
同样，如果我们把模型和 Token 视为新一代的生产资料，那我们也必须不断改造自己的工作流程，甚至团队的组织文化，才能真正把模型的智能用在提效上。这或许也是从另一个角度解释了，为什么 Agent 需要十年才能发挥其足够大的作用。
🧑🏻💻 唐三
是的，我非常赞同这个观点。
👦🏻 Koji
我们评论区有个具体问题想问一下唐三。QoderWork 的虚拟机里，可以直接调用本地的打印机吗？因为他工作上需要大量使用。
🧑🏻💻 唐三
应该是可以的，但说实话，这个场景我还没有验证过。所有打印机都是通过驱动工作的，而驱动可以用命令来调用。具体是 Windows 还是 Mac 操作系统，我可以之后去做一下验证。
👦🏻 Koji
我前两天也想自己做一个 DEMO。我的打印机放在家里，导致我经常要记下白天想打印的文件，等晚上睡前再统一处理。我就在想，是不是可以给我的打印机设置一个 email，它背后有一个 Agent，我把文件发到这个邮箱，它就自动打印好？这样我一回家就能看到打印好的文件。也许我回头可以试试用 QoderWork 来实现这个功能。
🧑🏻💻 唐三
好的，我回去也验证一下这个场景。
👦🏻 Koji
当然，也有人说买个钉钉打印机就可以了。
🧑🏻💻 唐三
也可以。现在有很多云端打印机，提供一个 APP，只要家里的打印机是联网状态，你把打印任务发过去，它会形成一个队列，等打印机开机时就会自动工作。
👦🏻 Koji
但那样就要换打印机了，我们的前提是不换。我们来看另一个有趣的问题，现在有一个很大的话题是 Agent 需要用集群来协作，但对此有不同观点。
一种观点认为，可以像组建团队一样，配一个工程师 Agent、一个 QA Agent 和一个产品经理 Agent，让它们协同工作。
另一种观点则认为，这样做是给一个高智能的模型强行套上一个"帽子"，限制了它的发挥。真正的 Agent 集群，或许不该按岗位角色分工，而应聚焦于如何更好地管理上下文，从而更高效地"驾驭"模型。不知道唐三在 QoderWork 的实践中，对此有什么观察和思考？
🧑🏻💻 唐三
这两种观点我都不完全赞同，也不完全否定，因为在实践中我们看到了一些问题。
我以前更倾向于第二种观点：大模型的能力足够强，AI Agent 的到来突破了人的限制，所以它的能力会非常强。人类之所以有各种分工，是因为我们大多数人是普通人，所谓术业有专攻。
但在实践中我们发现一个问题：**Agent 目前最主要受限于大语言模型的上下文长度。**当任务足够复杂时，上下文就成了非常关键的瓶颈。比如我们熟知的 MCP 或内置工具会占用上下文，像 Skill 这样的动态加载虽然更好，但它对 Skill 的描述信息也需要加载进来。如果一个复杂任务经过多轮调用，这些调用信息本身也会占据上下文。
因此，如果任务足够复杂，而我们坚持用一个 Agent 搞定一切，那么随着上下文被不断压缩，很多信息可能会失真，最终导致效果变差。
这时候，切分多个 Agent 来协作就很有必要了。多个 Agent 各自有独立的上下文和专业领域，能更好地完成任务。但这些 Agent 是不是就要像人一样，被严格划分为不同角色呢？
其实也不是。它本质上是一个通用的 Agent，你只是赋予了它不同的 Skill，让它能在特定领域里专注地完成工作。所以 Agent 是通用的，给它不同的 Skill，它就能完成不同的专业任务。
就像一个通用的发动机，安在汽车上就是汽车，安在卡车上就是卡车，安在摩托车上就是摩托车。我们内部的演进思路也是这样，把 Qoder CLI 视作 Agent 的发动机，而 IDE 插件和 QoderWork 都是基于这个发动机构建的。
在构建过程中，为了解决上下文的问题，我们会给不同的场景安装不同的 Skill。比如在 QoderWork 中，对话风格不能像 IDE 那样充满技术语言，要更符合白领的人设；它还需要处理连接操作系统这类 IDE 不需要的工作。这些定制化的 Skill 也会占据上下文，用久了效果会变差。
所以，如果我们针对一个特定场景，给一个 Agent 装上合适的技能，把上下文控制在合理范围内，原则上它就能更长久地完成更复杂的任务。
因此，Agent Team 是可以存在的，但我们不该为了拆分而拆分，而是根据任务的复杂度和工作场景来决定何时需要拆分。
👦🏻 Koji
很有意思。直播间不断有新朋友进来，在我们直播一小时之际，可能要再麻烦唐三重复介绍一下，QoderWork 是一款什么样的产品？
🧑🏻💻 唐三
QoderWork 是一款面向所有人的产品，它运行在你的本地电脑上，是一个一键安装、开箱即用、安全可靠的工作搭子。当你有任何想法或工作任务时，都可以交给 QoderWork 来帮你完成。
另外，新用户注册 QoderWork 会免费赠送 300 credits，注册后就可以直接试用。
👦🏻 Koji
我们还有个问题，刚才聊到云端和本地的选择，QoderWork 选择在本地通过虚拟机来实现。但这会带来一个问题，比如有人会问，在本地是不是就没办法 7×24 小时在线了？我的 AI "牛马"就不能为我 996 了，因为我一关电脑它就消失了。你们怎么看这个问题？
🧑🏻💻 唐三
AI 时代到来后，人确实越来越焦虑，电脑的工作时长和我们的睡眠时长呈现反比。我现在也养成了不关电脑的习惯，觉得睡觉的时间很宝贵，不如让电脑继续工作。
但无论如何，使用本地电脑总有关机的时候，这一点上云端确实更有优势。不过，考虑到安全和本地上下文的需求，本地电脑依然是主要的工作场所。未来能否将两者兼容呢？我们有一些思路，类似云原生领域的"云边一体"方案。
比如，可以在云端和本地各"养"一个 Agent。不需要处理本地上下文的任务交给云端，需要处理的就让本地来做。这样能解决 7×24 小时在线的问题。但这算是一个比较复杂的场景，究竟有多大的真实需求我们还不确定。
但另一个场景我们是确定的：人可以离开电脑，但电脑持续开机运行。我们已经习惯了用手机处理很多工作，但有些文件的确只存在电脑里，怎么办？
我们近期会上线一个新功能，打通 QoderWork 和你的 IM 工具。只要电脑是开机状态，当你急需处理文件时，就可以通过手机 IM 给电脑下达指令，比如"查看某个目录下的文件，处理后发给我"。它会通过 IM 把处理好的文件发回你的手机。寻找文件和加工处理的过程，都由你的本地电脑完成。这就是我们对于几个场景的一些思考。
👦🏻 Koji
我看到弹幕里有人问我们平时用什么模型最多。这让我想起，之前十字路口与 Qoder 负责人叔同的对谈中，我们讨论过一个问题：Qoder 做了一个非常明确的选择，不让用户选模型，而市面上很多同类产品是开放选择的。
直到今天，Qoder 和 QoderWork 依然坚持这个设计，能分享一下背后的思考吗？
🧑🏻💻 唐三
因为我们坚信"机选优于人选"。 把模型选择权直接交给用户，对产品开发来说更简单。但我们评测了数十款模型后发现，它们各有特点。我个人认为，未来世界不会是某一家模型独大，而是多家并存，各自有擅长的领域。
既然如此，我们就应该在合适的场景选择合适的模型。所以我们致力于做"智能路由"，通过意图识别，判断这个场景用 A 模型最合适，就调用 A；那个场景用 B 模型更好，就调用 B。
对于有安全诉求的企业，我们还可以对接他们自有的本地模型。我们整个思路是模型分级，背后对应了几十个模型。
当某些模型出现容量问题时，我们还有平级的路由策略，保证服务的稳定性。这就是我们的产品理念。程序员可能对模型了解更深，就像有些赛车手坚持开手动挡，他们觉得自己的水平能驾驭得更好。但这毕竟是少数，而且很累。绝大多数人还是希望产品能帮他们选好，直接用就行，就像现在大家开车都选自动挡一样。从我们的线上数据来看，绝大多数用户也确实选择了智能路由方案。
对于面向所有人的 QoderWork 来说，就更不用纠结了。很多用户对模型特性一无所知，把一堆模型选项抛给他们，只会让他们彻底蒙掉。所以我们非常克制，目前只提供了两档：普通档和旗舰档。
普通档用于完成绝大多数日常任务，旗舰档则用来处理更复杂的任务。每一档背后都对应着多种模型，我们会通过智能路由来调度。比如，当你有生图需求时，我们会自动路由到当前效果最好的模型上。
👦🏻 Koji
所以是相信模型的智能路由，在绝大多数情况下，比人手动选择更优?
🧑🏻💻 唐三
是的，我们始终坚信机选大于人选。
👦🏻 Koji
评论区有个比较尖锐的问题：QoderWork 和其他本地 Co-Work Agent 比起来，有什么本质区别？
🧑🏻💻 唐三
QoderWork 和 Co-Work 在工作搭子的定位上类似，但产品形态和未来走向会有差异。首先，Qoder 从成立之初就相信多模型的价值，在合适的场景选择合适的模型。而 Co-Work 本质上是模型厂商为自家模型寻找超级 APP，以消耗自家的 Token。我们的出发点是应用，是选择全球最适合的 SOTA 模型来解决实际问题。
其次是未来的走向。Co-Work 目前看仍聚焦于"工作"这个垂直场景。而 Qoderwork 如我刚才所说，会和 IM 打通，会做记忆，我们希望把它从一个"干活利索"的助手，培养成一个"眼里有活、高情商、懂你、能主动找活"的助手。所以在产品定位和未来走向上，我们的差距会越来越大。
👦🏻 Koji
听起来你们的目标是做一个主动式的本地 Agent？
🧑🏻💻 唐三
是的。
👦🏻 Koji
那我们可以再聊聊上下文。提到主动式 Agent，一个重要的话题就是，它在本地理论上可以收集到非常多的 context，甚至包括用户的键盘输入、鼠标轨迹，极端情况下还可以录屏。你们团队内部是如何看待"收集更多上下文"这件事的？
🧑🏻💻 唐三
我们讨论过，但对此非常严谨。比如录屏这种极端场景，我们认为大多数人会让一个 Agent 持续监视自己的工作，会感到不适。同理，去记录键盘输入等信息也可能让用户不安。
所以我们选择渐进式开放。最开始，你让它工作，它了解一些信息；随着你跟它对话越来越多，它会逐渐更懂你。
比如，最开始你可能要详细地对它说："今天很热，现在是中午，帮我买一杯冰美式。"第二天又要说："今早天气凉，帮我买一杯热的馥芮白。"就像你每次都要跟咖啡店员重复你的需求一样。我们期待的是，在你日常使用中它能逐渐理解你的偏好。以后，在炎热的午后，你只需说一句"点杯咖啡"，它就知道该给你点冰美式。这就是"更懂你"。
现在的 QoderWork 像一个高效的执行者，你下达详尽的任务，它能完成得很好。未来，它会像一个能听懂你"弦外之音"的助理，甚至你给个眼神它就懂了。我们最近上线的"定时任务"功能，就是一种以时间为 trigger 的主动行为。未来我们还会对接更多连接器，就像 IFTTT 那样，就是 if 、then、else、else ，一个一个的软件就是一个链式 trigger ，通过一个事件触发一连串的动作。
比如，它读取到天气预报，可能会主动提醒你；读取到你的日历事件，会给你相应的建议。我们不一定每个人都能在工作中配一个真人助理，但未来在电脑里拥有一个干活利索、质量高又特别懂你的 AI 助理，是我所期望的工作方式。
👦🏻 Koji
刚才提到定时任务，评论区有位用户说，他已经用 Qoder 连续四周稳定地每天监测竞品网站的更新，并给他发通知了。看来在你们正式上线这个功能之前，用户已经自发地用指令实现了。
🧑🏻💻 唐三
是的，一些有技术背景的用户可以通过 Cron Tab 等方式实现。因为这类需求呼声很高，我们就把它做成了一个正式的产品功能。我们的产品理念是快速迭代，先推出基础功能，然后听取用户的声音和反馈，看他们能玩出什么花样，再把产品做得更完善。
很多伟大的互联网产品，最初的形态都源于 BBS 社区里用户的自发创新。我们不希望闭门造车，而是把产品交给用户，让他们释放想象力，我们再根据他们的真实需求去迭代。
👦🏻 Koji
直播只剩最后几分钟了，提醒大家，想要体验 QoderWork，可以访问 qoder.com/qoderwork 搜索下载。最后我们集中回复几个问题。有一个是关于模型选择的，如果不能选模型，用户如何知道自己的上下文数据被哪个模型拿走了？这位朋友可能对某些模型不够信任。
🧑🏻💻 唐三
其实还好。首先，这些都是主流的公共云服务商，你无非是把数据泄露给 A 还是 B。其次，模型到底拿走了哪些数据，跟你下达的指令强相关。如果你让它总结一份本地的 PDF，那它必然会读取整个文件；如果你只是让它润色第一段，那它就只会读取第一段。
当然，企业确实有更强的安全诉求，他们可能不允许任何数据流出到公共云，希望使用自有的本地模型。这个需求我们已经收到了，正在评估，后续有计划支持自定义模型。
👦🏻 Koji
还有一个评论，问 QoderWork 未来会不会和 OpenClaw 类的产品趋同？
🧑🏻💻 唐三
有这个可能。OpenClaw 是个非常好的产品，它打开了很多人的想象空间。但它为什么作为一个开源项目火起来，而不是由商业公司推出？原因之一就是它给了 Agent 过高的自由度，让一些人担心其安全性。
QoderWork 和 OpenClaw 类的产品，就像当年虚拟机和容器的路线之争。一个从安全出发，努力变轻；一个从轻量出发，努力变安全。最终它们会趋同。今天，如果你需要一个"干活利索、执行可靠"的帮手，感情可以慢慢培养，那 QoderWork 是你的首选。如果你动手能力强，享受"调教"的乐趣，那 OpenClaw 可能更适合你。这没有对错之分，选择最适合自己需求的产品就好。
👦🏻 Koji
最后一个问题是关于 Qoder 的，问 IDE 和 CLI 能否共享会话，以及能否在手机上远程操作？
🧑🏻💻 唐三
CLI 和 QoderWork 我们已经明确有在移动端操控的需求，并且在规划中。但 IDE 本身是图形化界面，有很多交互需要在电脑上完成，在手机上控制它可能不是一个刚需，所以 IDE 侧我们暂时没有移动端的计划。
👦🏻 Koji
那么作为本次访谈的最后一个问题，想请你预测一下，到 2026 年底，Agent 会有哪些进化？它会给我们的工作和生活带来什么影响？
🧑🏻💻 唐三
我认为 2026 年将是 Agent 务实落地的一年。如果说 2024 是概念年，2025 是实验年，那么今年就是落地年。
首先，Agent 完成工作的可靠性会进一步提升。我们期待的不是 60% 或 80% 的成功率，而是能达到 90% 到 95% 的准确率。
其次，Agent teams 会更普遍地存在，Agent 之间的协作，无论是主从协作还是对等协作，都会有更多落地场景。
第三，在一些具体的行业，比如金融、法律或文书类工作，可能会出现超级 Agent，彻底变革这个行业某一类岗位的生产方式。
至于 AGI，我觉得 2026 年还不会到来。未来几年，我们对 Agent 的要求会越来越细致和务实。当我们踏踏实实地解决了这些具体问题，把它们串联起来时，或许有一天回头看，会发现 AGI 已经悄然出现在我们身边了。
👦🏻 Koji
也就是说，AGI 到来时不会和你打招呼，当你发现时，它已经存在很久了。
🧑🏻💻 唐三
是的。
👦🏻 Koji
好的，非常感谢唐三。今天的直播很愉快，也希望大家在听完分享后，去更多地体验 QoderWork 的产品。再次感谢唐三做客十字路口。
🧑🏻💻 唐三
谢谢，拜拜。
👦🏻 Koji
拜拜。
参考资料