之前我和我的 agent 实测发现，Jev 的上下文是两道墙：state（材料）加最长那道题不超过约 32K，整个请求不超过约 64K。为什么是两道，官方没解释，从 OpenAI 出来的 CEO 说架构先捂着，果然很 Open。

一位也在研究 Jev 的朋友分享的研究报告里提到一种解释。我们顺着找到原作者 Archer Hume，又用一万六千多次请求核了一遍。

我们的结论是：Jev 把每道题和同一份 state 配成一对，各对之间互不相通；这些对成批一起算；state 在一次请求里只处理一次、各对共用，类似前缀缓存。所以第一道墙是每一对的上限，大概率就是模型本身的窗口；第二道墙是一份 state 加全部题的总额。

1️⃣ 每道题只看得到 state 和该题目自身。我们把一条信息写进同一请求里的其他题目中，再拿一道题去问，720 次一次都感知不到该信息；写进 state 就没问题。第一道墙也只管这一对。我们换了 21 种题型、长短和搭配，无论别的题有多少、排在哪，state 加这道题都卡在 32,743 token（按计费单位）。

2️⃣ 各对应该是一起算的。每多一道短题，服务端耗时只多零点几毫秒，一道道排队算做不到。官方文档也说题是并行判断的。

3️⃣ state 在一次请求里只处理一次。计费上 state 只收一次，和官方说的「state 读一次」对得上，所以第二道墙里 state 只占一份，整个请求计费不超过 65,792。Archer 公开的实测数据里，22.8K 的 state 配 5000 道题，服务端 1.8 秒返回；要是每道题各处理一遍 state，就是 22.8K × 5000，约 1.14 亿 token，处理时间和计费都不支持这种方式。

既然 state 共用的好处只在一次请求里，同一份 state 的题就尽量一次列全。拆开问，state 和每次请求的固定开销都要重新收费，原样重发也不更快；同一段 state 的 12 道题拆成 12 次挨个发，比一次问完耗时约 12 倍、贵约 8 倍。

这套结构最早由 Archer 9 月 17 日在《Jev's Architecture Unmasked》里有证据地提出，那时官方文档还没写上下文长度。原文在他的博客 网页链接 我们补的是精确到 1 token 的边界和更大样本的复现。

Jev人工智能