编码智能体项目进展:
一个观察。
长时程解题器,其实相当好写。
你在结构上下功夫。你把系统想透。你从第一天起就深思熟虑地搭架构。而只要你干得好,大概率你能让智能体一直转,转到你需要它们停下为止。
事实上,只要你擅长上下文隔离,还能在进程之间管起某种面向任务的记忆,你甚至能让长时程解题在 27B 到 35B 一级的模型上跑通——就在一年前,这还属于边缘到不可想象的操作。
至少……在你试着把那套流程泛化到其他模型上之前,是这样。
我觉得人们漏掉的正是这一块。
模型是混沌的。而工具——至少按行业今天做工具的做派——仍然需要被一步步推理着用。对这摊做法我有一箩筐响亮的抱怨,但我先攥在手里一分钟,先假设我们聊的都是云优先的、或在某种有意义的意义上可云互换的工具。
泛化在哪一步变成了基准
因为正是工具推理——有时是它的缺席——制造了瓶颈。
想象这个场面:你造出了你职业生涯里最干净的一场智能体运行时,你为它在逻辑上的完美而兴奋。它在发光。但三个模型能跑通这条工作流,第四个跑不通。
你为第四个模型修好它,结果不知怎的,你又把同一段东西为前两个搞坏了。现在你举着手电压着灯,揣着记录板,蹲在哥布林洞里,琢磨你需要的到底是更严的不变量、更简单的流程、更清楚的角色边界——还是一把西塔琴和一场仪式之火。
答案是:全都要。
所以泛化才成了基准。
哪怕在没那么讲究的系统里,你也会偶尔见到这种警告:「你用这个模型时会发生什么,我们不知道。后果自负!」
这也是编码智能体之所以是个如此迷人的问题空间的原因之一。
当然,别的原因还多得是。
没把编码智能体折腾明白之前,你没法真正用智能体经营一摊生意。但我觉得最有意思的部分是:写代码这件事,不同于其他智能体工作类目……你对任务到底是什么,只有一个模糊的概念。
你不知道东西的数量。你不总能在动手之前预知一个改动的后果。你对任何一个项目的复杂度,只有个大概——前提是用户没一路失控,拐进一长串「要是能……就好了」。
而只要由你喋喋不休,他们就一定会。
规模化的一致自纠
所以,当你在造能连轴写上几小时、几天、几星期不停手的智能体时,整个游戏就变成:在把自纠循环保持连贯的前提下,把确定性最大化。
然后你把它泛化。
然后你拿当下最流行的十二个模型去测。
然后你用完成的项目、稳定的交接、连贯的恢复行为,以及最好是最少数量的突发 AI 耍脾气,来度量成功。
要是你能不被一场吞时间的复杂度熔毁拖住而走到那一步,朋友,你开始挣钱了。
这比听起来难得多。
我想,这就是大多数系统至今没去真干的实际原因。
它比什么都狠地拽低你的速度。
眼下承认这件事是危险的:存在一些开发语境,连全自动化系统都能把你的速度拖到爬行。
但那是真正的活儿。
你在泥里趟。你陪着你那些慢吞吞的评测,盯紧了,因为这是精工活。你观察,你记录,你收紧循环。你简化流程。哪里聪明会伤人,你就哪里少点聪明;哪里模糊一直在渗,你就哪里多点明写。
等干完,你就能用上这件工具了——它应该能把你的速度还给你。
目前的构建
我差不多就停在今天的这里。
编码智能体项目到了最后一圈。我刚加了内部遥测,让审计和调试变容易。步骤更少。能见度更好。整体上审计和监控都更容易。
下一步是一个编排兼容的 MCP 服务器,为 Paperclip 优化。等 Pillowfort 上线,它也该能配合 Pillowfort。同一个总原则。
我们熬过了好年景,也熬过了融化季。
而我对接下来的事感觉相当有把握:很快,就能把这玩意交到我那组 beta 测试者手里。
这会很好玩。