长程任务、Matt skills、信息瓶颈
现实当中我们有多少任务是可以甩手，不需要任何外界信息的摄入就长时间执行的？我是看到孔博士的微信推文里面提到，他去做了个小调研，发现超过1小时的真实任务好像不那么多。
现实工作中，经常做着做着发现，需要补充信息，需要跟别人沟通获取信息，然后把新信息消化掉，再加工。
要无人值守，让agent做一个很长的任务，意味着操作者需要一开始就把信息提供完整，这非常难。
而且，几个小时过去，如果人有责任心、勤于思考，可能自己对于这个问题也会有一些新想法，他也需要把这些新想法补充到agent的进程里面去。
有一些任务符合条件，比如证明数学猜想，或者把编程项目从一个语言迁移到另一个语言，这些问题很难，需要执行很久，而且信息可以在一开始就给齐。
模型厂商为了突破长程任务，提高了模型主动校验闭环、处理长上下文的能力。有了这些能力，agent可以做几十个小时的任务。由于上述人类交付信息的方式，我认为已经不太实用。另外，太长的任务，就算agent交付了，由于工作量太大，人类去审阅结果的质量也很难，不如拆成更小的issues分别去解决。这里就牵涉到另外一个问题——基于issue的agent管理机制。
在这些突破之后，模型执行任务已经不缺能力，而是缺信息。这也就是Matt skills这个套组有用的地方，它解决的是信息问题。信息永远要提供，因为模型不可能知道我的需求。模型不是我肚子里的蛔虫，它不知道我的话是什么意思。不同的人讲同样的词，意思都可能不一样。模型无法得知给它下需求的人到底是什么意思，它得从多个角度来询问我，然后我们才能够对齐，尽量把误解降到最小。
这就是Matt skills的思想。
有一种幻想，说一个企业可以把知识库沉淀下来，然后就能做Deep Research了。
我不知道有多少人尝试过Deep Research。以我的标准而言，Deep Research出来的结果准确率仍然不够高。
很多时候是“搜商”有问题，模型不知道自己不知道什么。它会按自己的想法去搜索和构建，往往掌握的信息已经过时了，但它还不知道，还按已经掌握的旧假设去搜，结果搜到旧信息，于是一切都是对的、自洽的。最后出一份刻舟求剑的报告，其准确性，在我的场景，能有50%就不错了。
“不知道自己不知道什么”这个信息覆盖问题很难解决，这也是所有agent的长程任务必须要面对的一个困难。在执行长程任务之前，agent怎么确定它的信息是完备的？
不要说一个企业的知识库了，就算我作为一个个体给agent下任务时，可能做着做着就发现它跑偏，跟我的预期不一样。因为agent没有和我对齐。我以为一件事是不言自明的，但它其实不知道，它也不知道自己不知道，也不会来问我，所以就做不好。
这也说明了为什么所谓的“loop engineering”行不通。这个词一度很火，受到Peter Steinberger和Boris Cherny的追捧。整个loop过程都没有外界信息的摄入，只是让agent自己不断地重复，缺的信息一直缺下去，结果自然不会优化。
Matt skills的精髓就在于，会要求agent向我盘问各种细节，也就是著名的grill-me。甚至，Matt skills套组里还有一个新技能叫做to questionnaire，功能是把当前问题列表整理成问卷，以发给同事或者其他人。不仅让使用者可以补足信息，也让使用者可以邀请团队成员一起补足信息。
那么，模型不知道自己不知道什么，它都不知道，又怎么能问出来呢？Matt的做法是：让模型先写方案，然后把模型写的方案里面的每个抉择点拿出来问。一问，自然就知道缺什么信息了，用户和模型对一下就可以。根据补充的信息，改一下决策，得出来的决策结果自然质量更高。
当然，有的人会觉得很烦，觉得问题问得太多。因为每一个抉择点都拿出来问，自然是过于饱和。但经过了几轮产品层面优化，现在Matt skills一轮会一齐问三四个问题，而且大部分选默认就可以，我们只需少量干预，体验有所改善。这个被问的过程，正好也是我们审阅agent计划的过程。这样还挺好，等于我还顺便看了一眼agent的决策，比完全摸黑要更有控制力，还回顾、梳理了自己的需求。
我喜欢Matt skills远远超过Superpowers。Superpowers希望把人类的一些很好的工程规范介绍给agent。但首先我觉得没有一个好的工程规范可以解决所有问题，工程需要灵活性。而模型自身的通用智能能力提升，在学习了大量工程手段、掌握了深刻的工程思想之后，它自己就知道拿到什么样的需求，该用什么样的工程规范去做。它具有灵活性，比任何规则都还要灵活智能。
但是Matt skills不一样，它解决的是信息问题。模型永远缺信息，所以这是需要我来提供的。虽然Matt skills里也有工程方面的内容，但主要还是围绕信息展开。
而且Matt skills体现的是对模型性格的设定，即希望模型来询问用户。但在很多任务上，是不需要模型这么做的。比如面对简单问题的时候，我问一句话，模型直接交付结果就行了，不用总是问。有时候用户可能希望它问，有时候用户可能不希望它问。
调用模型API的时候，经常出现这种情况：问模型是谁，模型却答不出来自己的名字。模型厂商当然可以通过训练让模型正确地答出自己的身份。但各公司现在都不这么做。
有一种传言说，这样做会降低模型的通用智力，但是我没有找到论文和研究来佐证这一点。我想从产品层面也有这样做的理由：如果模型强化了它的身份信息，意味着我作为下游开发者，调用模型API向我的客户提供服务时，客户问它是谁，它还会很倾向于说“我是某某厂商的模型”，而更不愿意说我指定的产品名字，这样肯定不行。所以，类似这种身份、性格信息是不适合训到模型里的，而是适合写在指令里，在系统指令里面告诉模型：“你是谁谁谁”。这样才更契合模型API本身作为一个产品在市场上的需求。
同样，针对每一个决策做盘问，作为一种性格，肯定也不适合内化到模型中。比如模型API也可以做陪伴应用、客服应用，这些场景盘问性格都不合适。所以“盘问”就更适合作为外挂指令。有朋友反馈，GPT 6 Astra很喜欢盘问，它干活的时候觉得有问题，就会停下来问人，而这在很多场合是有问题的。这个特征一旦作为模型性格底色，在很多应用场景就会不适配。因此，我相信，喜欢盘问将不会是未来模型的原生性格，Matt skills作为外挂需要长期存在，这是它跟Superpowers的不同之处。
那么，在利用Matt skills把信息全部对齐以后，我们是不是就可以做十几个小时的任务了呢？因为，我们已经在执行行动开始之前，把信息都给齐了。
我觉得仍然有困难。如果要执行的是对agent而言都要做十几个小时的任务，那就意味着这个任务方案也会非常长，人很难在有限的注意力和工作记忆里，把这么长的方案审阅、决策、答复清楚。做方案给信息本身，就把任务约束在了一定规模之内。人处理信息的规模将会约束任务的规模。当然，前文提到的数学证明、代码迁移这种信息几乎全部在项目本身的情况除外。
本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
