如今,运行编程智能体的默认场所就是你的编辑器内部。Cursor、Claude Code,还有你 IDE 里自带的助手——它们坐在你身边,你看着它们工作,你逐步批准它们的操作。这感觉很自然,因为它模仿了结对编程:一个飞快的初级开发者趴在你肩头,而你依然手握方向盘。
这种模式非常适合需要持续监督的智能体。问题在于,智能体每个月都需要更少的监督,而它们越自主,把它们绑在一台只有你醒着时才醒着的笔记本电脑上,就显得越奇怪。
本地模式的天花板
本地智能体继承了你所有的限制。它只在你的机器开机时运行,你合上电脑它就停止。它要跟你的编辑器、浏览器和构建流程争抢同样的 CPU 和内存。它一次只能做一件事,因为你一次也只能盯一件事。它做的一切,也只发生在只有你能看到的地方。
这些都不是工具本身的缺陷——这就是"本地"的逻辑。智能体活在你所在的地方,于是被一切限制你的东西所限制:你的工作时间、你的硬件、你的注意力、你那唯一的一双眼睛。当智能体还需要人类盯着每一步时,这些限制是免费的。可一旦它不再需要,这些限制就是纯粹的成本。
异步、远程的替代方案
另一种模式,正是我们构建 TaskGoblin 所围绕的核心:智能体根本不住在你的编辑器里。它生活在专属的基础设施上,通过你团队已经在用的工具来触达你——一个 Linear 事项、一个 GitLab 或 GitHub 的合并请求、一个 Slack 话题。你把任务交给它,就像交给身处另一个时区的远程同事一样,然后它就在云端沙箱里把活干了,而你可以去忙别的事情。
这种转变听起来只是计算跑在哪里的问题。但它实际上关乎智能体被允许成为什么样子。把它从笔记本电脑上挪开,"本地"的种种限制便一个个消失:
- 它可以并行运行。 十个事项可以同时进行,因为不需要任何人去逐一盯着。
- 它全天候在线。 远程智能体不会因为你合上笔记本电脑而停止工作;傍晚 6 点分配的任务,第二天早上就能完成。一天中可用的"智能体工时"不再等同于你的工作时间。
- 它运行在为它量身打造的基础设施上, 而不是在开发者的笔记本电脑上跟你的编辑器抢资源。
- 它在团队看得见的地方工作。 它的产出是一个合并请求和一串评论记录,而不是一个私密会话——监督变成了整个团队在共享空间里共同完成的事。
- 它原生集成于平台。 触发它的是已经在你的工具中流动的事件——一次指派、一次提及、一个新的拉取请求——而不是你去打开一个应用。
- 它天生就是隔离的。 每次运行都是一个全新的沙箱环境,使用范围受限、由中介签发、智能体本身从不持有的凭证——这种安全姿态,是运行在你自己机器上的进程所无法企及的。
这些优势单独看都算不上惊天动地。但加在一起,它们累积出一道难以辩驳的差距:十个智能体全天候工作,对阵一个你收工它也收工的智能体。
"但我需要紧密的反馈循环"
反对远程模式最有力的理由,就是那种紧密的循环:快速的来回、盯着智能体、中途纠正、凭感觉引导。这是真实存在的,对于真正探索性的工作——试验一个想法、调试一个你自己都还没搞懂的问题——本地依然是正确的工具。
但关于这种循环,有两件事是事实。它在整体工作中所占的比例,比感觉上要小得多;大量真正的工程工作,其实是那些定义清晰、并不需要人在旁边盯着的任务。而且它每次都会随着智能体变强而进一步缩小,因为你之所以要盯着,是因为你还不信任智能体能在无人看管的情况下把事情做完——而这种信任正是在不断上升的。紧密的循环不会消失,但它会越来越少地代表你一天中的工作内容。
"但安全问题呢"
最严重的反对意见不是关于工作流程,而是关于信任:把你的代码和凭证放在别人的基础设施上。这个问题理应得到一个认真的回答,而不是敷衍带过——这也正是我们构建工作的重要组成部分。每次运行都按沙箱隔离;密钥在静态时加密存储,从不出现在智能体的运行环境中;每个组织的数据都与其他组织严格隔离。远程不等于草率——如果做得到位,一个专门打造、由中介签发凭证的沙箱,要比一个在开发者笔记本电脑上自由运行、环境变量里存着真实令牌的智能体更经得起推敲。
未来会走向何方
我们并不是说本地模式会消失。探索性的工作,以及一些受合规约束的环境,在很长一段时间里都会为编辑器中的智能体保留一席之地。我们的主张更为克制,但我们认为也更难反驳:随着智能体越来越有能力在无人盯着的情况下完成真正的工作,重心会从笔记本电脑转移到共享的、全天候在线的基础设施上——这不是因为开发者更喜欢这样,而是因为一个让十个智能体全天候运转的团队,产出会轻松超过一个只让一个智能体工作到合上电脑为止的团队。
这正是 TaskGoblin 押注的方向。不是给你机器上的智能体开一扇更好的窗,而是一个从一开始就从未在你机器上运行过的智能体——它就等在你团队已经在用的工具里,在你喝完这杯咖啡之前,就已经准备就绪。
