佬友们好，想问一个问题
我刚开始学用agent，主要用codex，发现codex上下文窗口还是比较短的，通常没讨论几句就到上限了，然后自行优化上下文，据说这样会对上下文理解会有一定影响，而且聊的一久上下文变多了之后额度就会消耗非常快，所以我就想有什么办法能更好的管理一下上下文，我也试过让她自己写skill和自我迭代（可以这样叫吗），分五次对话总结一次，但是我发现skill的话很难触发，不知道是我的提示词有问题还是别的
上下文一般275k就够了啊，多大的项目啊。oai的远程压缩属于天顶星科技了，损失非常小，不至于说失忆吧，我一个会话都十几个g了都不见得失忆
也不是失忆，只是想学习一下上下文管理，上下文太长吃额度太高了_(:з)∠)_
平时换窗口的时候写交接文档也蛮顺的，没出过什么问题
很久没用 codex 了，现在都有压缩 tool 了吗
是指skill吗，那个是我让codex自己写的总结skill
嗯，如果不是的话那就是窗口到上限了自动有优化上下文压缩
应该是这个意思吧
我理解错了，我以为是你写 skill 叫 gpt 主动调用一下压缩
可以学习一下多agent系统？ 主agent不干脏活就不被一些不必要的信息污染了，剩下的执行agent之类的可以使用luna这种便宜模型
是的是有这个想法，只是我可能对skill了解不多，用skill除非我主动说不然甚至相关情景下他自己都不会调的
是codex的max吗，据说会有多agent协作，我还没试过_(:з)∠)_
如果你是要在更短的上下文时触发压缩，那可以直接配置toml model_auto_compact_token_limit = xxxx
具体你要的上下文大小
ultra会有muti-agent，但是这个貌似非常消耗toekn，我也没用过。最近我在使用dsh尝试搭建一套多agent的系统，不知道能不能成 
那这个的话你算是问到很核心的东西了，长上下文本质上在业界都属于很难解决的问题。
正如上面有佬友说的用便宜模型去干活返回摘要是一个思路，只让主模型去解决真的难题，什么搜索，读文件你都让他开luna之类的模型去返回摘要；
codex这类的codingagent本质就是每次请求带上之前的上下文一起去请求去推理，命中的缓存越多越便宜，尽量一个方向问下去，主要是为了减少无关上下文和 compaction 后的信息损失，不要问太过跳跃的问题，这样他能复用之前的缓存会便宜很多。
当然你刚开始用agent的话我这样说你可能不太理解，你可以理解成你问的问题，对话的东西都是你那个领域比较相关的，这样缓存命中多了额度就不会说消耗的很快
原来是这样，感谢佬友们的回复
确实，我在做项目的时候因为总是没有头绪导致想到哪做到哪，有可能这里会导致污染上下文
我通常是在做某个板块的时候先和他聊用什么方式好，可行性如何然后在继续，但是睡一觉起来忘了又得问一嘴做到哪了，或者突然有点子了就又添加任务
好的感谢佬友回复
不客气。
如果是你这种使用场景的话，就是我建议你可以系统性去看看怎么管理上下文的，或者说你刚开始学的话，你可以给自己在项目里面搞几个文件，比如说一个taskmd，记录你的小点子跟他说先记录下来不要实现，继续做当前做的事；
一个currentmd，每次做完或者你想停下来的时候记录一下，下次开新会话直接让他读就好；
一个decisionmd，记录你的设计理念，免得你现在选了a方案，过两天就想为什么不用b方案，不用gpt重新给你去推导。
我之前一开始也是这么干的，当然你后续学的更深了，学会一些skill、memory、上下文压缩之后，你就会有自己的思路去管理上下文了。
上下文的本质是什么该给模型看，什么不该出现的问题，也就是不是想办法让模型记住得更多，而是想办法让模型在正确的时候看到正确的信息。搞清楚这个你就会明白为什么额度烧的快了
本来是有很多方法重组上下文来维持高效注意力的，但当下计费模式极度依赖KV缓存，折腾上下文的收益在成本面前毫无竞争力。