在上一篇文章中，我分享了“真实上下文窗口”大小和“广告上下文窗口大小”
Claude 3.7 宣传的上下文窗口是 200k，但我注意到输出剪辑的质量在 147k-152k 标记。无论使用哪个代理，当发生裁剪时，工具调用到工具调用调用都开始失败
简而言之，我们正处于另一个“640kb 对任何人来说都足够了”的时代，人们需要开始思考当前一代的上下文窗口与 20 世纪 80 年代计算机上的 RAM 有何相似之处，直到DOS=HIGH,UMB成为一种东西……
LLM 上下文窗口就像 IBM 8086 XT 中的 RAM 一样，是宝贵的资源，但工程师和开发工具公司并不这样对待它们。
当前一代编码代理通过工具调用到在单个上下文窗口（即 RAM）内运行的工具调用的紧密评估循环来工作。然而，这种设计的问题在于，当法学硕士提供了糟糕的结果时，编码助理/代理的死亡螺旋和主上下文窗口上的暴力，在试图找出下一步时消耗了宝贵的资源。
当前一代的软件开发代理是这样工作的。这不太好（tm）
但是，我一直在想：如果代理可以生成新代理并克隆上下文窗口怎么办？如果这样的事情是可能的，它将使代理能够产生子代理。主代理将暂停，等待子代理耗尽其自己的上下文窗口（即 SWAP），然后为主代理提供具体的后续步骤。
我怀疑下一代特工在幕后会是这样的
目前这只是理论上的，我还没有研究过。尽管如此，我仍然梦想着未来软件开发代理不会浪费宝贵的上下文（RAM）并在主线程上进入死亡螺旋。
PS 社交
- 领英： https ://https://ift.tt/oWzP1uU
- 推特： https ://x.com/GeoffreyHuntley/status/1911237235644809466
- 蓝天： https://bsky.app/profile/ghuntley.com/post/3lmnv43hmk32d
pps。额外阅读
“即使在非编码代理系统中，您也会经常看到这种[崩溃]，其中单个代理在某个时刻开始崩溃。” – 施里武·香卡