前面我們開始處理 conversation 越來越長之後的 context problem。

一個 conversation 裡可能累積：

User Message
Assistant Message
Tool Call
Tool Result
User Message
Assistant Message
Tool Call
Tool Result
...

而真正跟下一個問題有關的，通常只是其中一小部分。

所以現在的方向是：

Full Conversation History
        ↓
Context Filter
        ↓
Relevant Turns
        ↓
      Agent

但只把 filter 寫出來還不夠，我想知道的是：

少送一些 history 之後，Agent 會不會變差？又到底省了多少 context？

為此用一個 Evaluation page 來觀察與比較。

Checkpointer vs Jev

目前 eval 會讓同一段 conversation 跑兩次。

第一組是原本的：

Checkpointer
→ send full conversation history

也就是：

Turn 1
Turn 2
Turn 3
Turn 4
...
Turn 15

第二組是：

Jev
→ select relevant earlier turns
→ send only those turns

例如：

Current Request
        ↓
       Jev
        ↓
Turn 4 + Turn 15

其他 history 並沒有被刪掉。

完整紀錄還是保存在 file system 裡，之後也可以搬到 database。

差別只是：

這一次 model 不需要看到全部。

Evals Page on Context Management

這個 page 的目的只有一個：

比較 full history 和 filtered history 對 Agent behavior 的影響。

上面先顯示整個 conversation 的 summary。

每個指標代表：

Correct
→ 最後答案有沒有回答對

Grounded
→ 答案裡的數字或 claim，有沒有來自 Agent 實際看過的 result

Steps
→ Agent 一共跑了多少 execution steps

Queries
→ 一共呼叫了多少次 database query

Skill Reads
→ 一共讀了多少次 SKILL.md

Tokens / Turn
→ 一個 turn 裡所有 model calls 加起來用了多少 tokens

First Call / Turn
→ 這個 turn 第一次 model call 時用了多少 tokens

這裡我特別加了一個：

First Call / Turn

目的是想知道：

這個 turn 一開始，到底帶了多少 conversation context 進 model？

因為一輪對話可能變成：

query
→ error
→ retry
→ query again
→ answer

多一次 tool call，total tokens 就可能差很多。

First Call 則比較直接反映一開始送進 model 的 context 大小。

Context 越長，差異越明顯

短 conversation 沒有太多東西可以 filter，所以 full history 和 filtered history 的差異通常不大。

因為 system prompt、tool definitions 本身就已經佔掉一部分固定 context。

例如：

Fixed Prompt      ████████
History           ██

這時候就算 history 少一半，整體差距也不會很明顯。

真正開始有差的是 long conversation：

Turn 1
Turn 2
Turn 3
...
Turn 24

如果每次都把全部 history 重新送進 model，context 就會一直往上長。

Filtered version 則只把這次 request 需要的 turns 帶進來。

這邊用一個 24-turn conversation 做測試，可以看到越到後面，filtered version 的 first-call context 差距越明顯。

每個 Turn 到底用了哪些 History？

Summary 可以看到整體統計，但我更想知道：

某一個問題，Jev 到底選了哪些 earlier turns？

所以 eval page 也會把每個 turn 實際送進 model 的 history 列出來。

例如第 16 輪：

Was March busier than February overall?

這個問題真正需要的 context 可能只有：

Turn 4
→ February result

Turn 15
→ March result

所以 filtered version 可以只送：

Sent: (4)(15)

而不是：

Turn 1
Turn 2
Turn 3
...
Turn 15

這樣可以直接看到：

Context Filter 到底認為哪些 previous turns 跟這次 query 有關？

這裡還有一個設定：

recent_turns = 2

也就是最近兩個 turns 不經過 filter，直接保留。

一開始我試過設成 0，但 Agent 反而比較容易需要重新理解 context，甚至多做一些 query 或 retry。

目前 2 在這組測試裡比較穩定。

這不是一個 universal value，不同 use case 還是需要另外調整，但先用它作為起點。

Details

每個 turn 打開來可以看到：

這些欄位主要是讓我可以從不同角度看一個 turn 發生了什麼：

Expected
→ 這一題預期應該得到的答案

Sent Turns
→ Context Filter 最後送進 model 的 previous turns

Steps
→ Agent 這一輪總共跑了多少 execution steps

Queries
→ 這一輪實際呼叫了多少次 database query

First Call Tokens
→ 第一次 model call 帶進去的 tokens
→ 主要用來觀察一開始送了多少 conversation context

Total Tokens
→ 整個 turn 從開始到結束，所有 model calls 加起來用了多少 tokens

Missing Values
→ 預期答案裡應該出現，但 final answer 沒有提到的值

Ungrounded Values
→ final answer 裡出現了，但沒有在 Agent 實際看過的 result 裡找到依據的值

Final Answer
→ Agent 最後真正回給 user 的答案

這幾個指標大概可以分成三類：

Correctness
→ Expected
→ Missing Values
→ Ungrounded Values

Execution
→ Steps
→ Queries

Context / Cost
→ Sent Turns
→ First Call Tokens
→ Total Tokens

所以打開一個 turn 時，不只是看：

✓ Correct
✗ Wrong

還可以一起看：

送了哪些 history？
Agent 做了多少工作？
context 到底有多大？
最後漏了什麼？
有沒有講出沒看過的數字？

這樣比較容易判斷問題到底出在：

Context Filter
Agent Reasoning
SQL Query
Grounding
還是單純 Token / Execution Cost

也可以展開 Agent 的 execution steps，看它實際跑了哪些 SQL。

這裡我覺得很重要。

因為只看最後答對還是答錯，資訊其實太少。

一個 answer 錯，可能是：

Context 選錯
SQL 寫錯
沒有重新 query
用了舊 result
Scorer 判錯

所以這個 evaluation page 不只是看 score。

它也讓我們知道：

這個 run 為什麼對？為什麼錯？

Case Study

其中有一個 turn 是：

Was March busier than February overall?

Full history 的版本沒有重新 query。

它直接拿前面出現過的 daily counts 自己加總，最後得到：

476 vs 388

但那其實算的是：

video-days

不是：

distinct videos

Filtered version 反而重新 query database，得到：

February → 107
March    → 93

這個 case 蠻有意思因為原本直覺上會覺得：

More Context
→ More Information
→ Better Answer

但實際上不一定。

舊 context 裡如果剛好有一個看起來可以 reuse、但語意不完全一樣的 result，Agent 反而可能直接沿用它。

所以：

Context 不是越多越好。

Context Optimization 不只是省 Token

原本做這件事，我最先想到的是 token cost。

但實際跑完之後，我覺得另一個更重要的問題是：

Too little context
→ Agent 缺資訊

Too much context
→ Agent 可能被舊資訊影響

所以 Context Management 不只是：

怎麼把 prompt 變短？

而是：

怎麼讓 Agent 在這一次 task 裡，只看到真正有用的資訊？

Jev 在這裡扮演的角色也很單純：

Current Query
      ↓
Previous Turns
      ↓
Noul
      ↓
Relevant / Not Relevant

它不負責 reasoning，也不負責回答問題。

只是幫我們先縮小 context。

目前這組測試看起來，這個方向不只可以降低 context，也有機會避免 Agent 被不相關的舊結果帶偏。

當然這還只是目前的測試結果。

換到不同 domain、不同 conversation pattern，filtering strategy 和保留多少 recent turns，都還需要重新驗證。