@xy19009188 #4 我的账号就是 plus ，我邀请你了，你估计得接受下，看下领得到不

@xy19009188 有想应该会收到一个邮件用来确认

@xy19009188 邀请了，好像是有些条
https://help.openai.com/articles/20001271

@koloonps #1 不会呀，我用 codex 做的，用户都一万多了

pi 的会话压缩得自己写，dsh 可以抄下作业

@zoues 是的，不是手绘的

提出好问题的能力，其实并不容易掌握

mimo

再沉淀下，以后写自传了我买一本，立字为据

@litchinn https://i.imgur.com/fNwRlAd.png 认真的去看了下源码，梳理了下，分享给朋友们

抖音的视频、音频是分别返回的

@wsseo 我理解这个 web 是用 sdk 做了个 demo ，实际应该是去用 sdk

是的，连带账号也一起送了好像，我用完 antigravity ，chrome 访问也重定向去 hk 了，美国 ISP 倒是可以

@xyooyx
列个公式其实就很清晰了

总命中率 = (System Cache Hit + History Cache Hit) / Total

= [ C × hit_rate_system + ΣΔ(k) × hit_rate_history ] / [ C + ΣΔ(k) + d ]

代入场景数据：
系统提示（含工具）：1500–3000 tokens
历史对话（ 10 轮）：4000–8000 tokens
当前输入：20–100 tokens
则：
命中率 = (3000 + 8000) / (3000 + 8000 + 50) ≈ 99.5%

所以得出推论：
- Agent 只要跑起来，轮次必然长，高缓存命中是“必然结果”
- 这不是某个特定任务的福利，而是 Agent 场景的“通用属性”

那问题就变成了：
既然所有 Agent 都必须面对“长文本 + 高重复”这个通用问题，
那一个模型如果能做到：
- 长上下文不崩（ 128K 甚至 1M 依然能 recall ）
- Cache 策略高效（不重复计算）
- 长文本推理速度不线性下降

我们就认为这个模型在 Agent 这个赛道里“做得好”。因为它在解决的是这个场景下的“通用瓶颈”

@lm1368 呃....