长期以来,关于编程智能体的问题一直是它们能否真正完成工作。这个问题正在悄然落幕。对于范围明确的任务,只要有代码仓库在手、能够运行测试,优秀的智能体就能提交通过审查的真实改动。而一旦你开始信任这一点,就会遇到一个没人提前警告过你的问题:你想不出足够多的工作来让它们保持忙碌。
执行不再是瓶颈
软件产品永远有做不完的工作。待办事项列表从不会空,可以改进的事情永无止境。所以说一个团队可能会让智能体"没活可干",听起来很奇怪。但"存在无限的工作"和"存在智能体能够接手并完成的工作形式"是两个截然不同的命题,团队正是卡在这两者之间的鸿沟里。
智能体可以在几分钟内执行一个清晰的任务。而写出那个清晰的任务——具备足够上下文、恰当范围、明确完成标准的任务——依然需要一个人花上和从前一样的二十分钟。当执行是慢的那一环时,这没什么问题;编写规格说明只占工作量的百分之五,其余百分之九十五是执行。而当执行成本趋近于零,这个比例就反转了。现在规格说明成了昂贵的那一半,原本能喂饱一个智能体的团队,发现自己喂不饱三个。
瓶颈上移,落到了你身上
这就是任务供给问题:驱动智能体开发的制约因素,不再是智能体做事的能力,而是组织生产形态良好的待办事项的能力。而这个制约因素,恰恰落在你最稀缺的人身上——那些拥有足够上下文、能够判断接下来该做什么以及为什么要做的人。
你会感受到一种奇特的压力。智能体既快又可靠,于是队列清空的速度超过了你补充的速度,而补充恰恰是需要判断力、产品意识和对系统走向的了解的那部分。瓶颈并没有消失,它从键盘转移到了知道键盘该做什么的那个人的脑子里。
智能体必须帮忙供给工作
摆脱供给问题的唯一办法是提高供给,而定义任务的人无法规模化。所以执行工作的智能体必须开始帮忙生成工作——不是凭空捏造一些无意义的活儿,而是把已经在你的系统中流动的信号,转化为具体的、可以直接执行的任务。
TaskGoblin 如今已经在两个你可能没想到属于"任务生成"的地方做到了这一点:
- 审查发现变成工作。 智能体审查的每一个合并请求,都会产生具体、定位明确的发现——这个函数有个正确性缺陷,这条路径没有测试覆盖,这里有安全隐患的气味。每一条发现实际上都是一个预先写好、带有明确完成标准的任务。回复
@taskgoblin fix,这条发现就变成了一次改动。没有人需要坐下来写那张工单;审查已经把它供给出来了。 - 常驻循环变成工作。 Loops 是一个按时钟运行的任务生成器:"每个工作日,找出已合并但对应的 issue 仍处于打开状态的工作,并将其关闭","监控长期处于红色状态的 CI"。这条指令只需写一次,就会持续产出具体的工作——或者在无事可做时正确地不产出任何东西——不需要任何人手动补充队列。
在这两种情况下,智能体都不是在等着别人告诉它该做什么。它在读取系统的状态,并主动提出具体、可以完成的下一步工作。
为什么上下文才是关键所在
智能体主动提出的工作之所以往往价值不高,原因不在于模型不够聪明,而在于智能体不知道你真正在意什么。在对产品意图一无所知的情况下,智能体会欣然给你列出它能看到的二十种重构方案,却唯独漏掉那一个真正能推动业务的改动——因为代码告诉它的是什么是可能的,而不是什么是重要的。
这正是为什么真正有用的任务生成场景,都锚定在真实的意图上。一条审查发现之所以重要,是因为它依附于某人主动选择做出的改动。一个定时循环之所以重要,是因为有人判断保持 issue 与合并同步这件事,值得每天去做。让一个被提出的任务值得去做的上下文,并不单单存在于代码之中;它存在于 issue、讨论和围绕代码做出的种种决策之中——而一个生活在这些系统之中的智能体,就像我们的智能体一样,能够读懂这种意图,而不是靠猜测。
价值现在落在哪里
有必要说清楚,这会把优势留给谁。随着各家模型在"几乎能执行任何任务"这一点上趋同,不成比例的价值将不再流向拥有最聪明智能体的一方,而会流向能够持续为优秀智能体供给有意义工作的一方。制胜之道不是造一个更聪明的模型,而是打通散落在你各个工具中的意图与能够据此行动的智能体之间的闭环,让"接下来该做什么"不再是一个由你亲自承担的瓶颈。
这才是我们真正在解决的问题。让智能体能够写代码,只是前半场。确保它始终知道什么才值得去做——并且能够在不等待你的情况下,把你的上下文转化为下一个具体任务——才是决定前半场价值几何的后半场。
