Context Engineering: ทำไม agent ของคุณโง่ลงที่เทิร์น 40

Anthropic ขีดเส้นแบ่งไว้ในเดือนกันยายน 2025 และสองประโยคนี้ควรวางคู่กัน Prompt engineering คือ “methods for writing and organizing LLM instructions for optimal outcomes” Context engineering คือ “the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference, including all the other information that may land there outside of the prompts”.¹

ความแตกต่างที่ใช้งานจริงคือ เมื่อไร และ โดยใคร prompt ถูกเขียนครั้งเดียวโดยมนุษย์ แล้วตรวจทาน context ถูกประกอบในทุก call โดยโค้ดที่ไม่มีใครกำลังมองอยู่ จากวัสดุที่ไม่มีใครเขียนด้วยมือ: ประวัติ 40 turn, ผลลัพธ์เครื่องมือ 6 ชุด, passage ที่ดึงมา 4 ชิ้น, โปรไฟล์ผู้ใช้, JSON schema 12 ชุด บทที่ 15 วัดว่าคำสั่งที่ดีขึ้นซื้ออะไรได้ บทนี้พูดถึง token อีก 90 เปอร์เซ็นต์ที่มาถึงเอง

เอกสารเดียวกันตั้งชื่อทรัพยากรที่ทุกอย่างใช้: โมเดล “have an ‘attention budget’ that they draw on when parsing large volumes of context. Every new token introduced depletes this budget by some amount” และตั้งชื่ออาการ: “as the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases” — context rot.¹

ประโยคสุดท้ายนั้นเป็นข้ออ้างเกี่ยวกับพฤติกรรม ซึ่งแปลว่าตรวจสอบได้ และตารางด้านบนของหน้านี้ก็คือการตรวจสอบ

40 บรรทัดยิงไปที่ endpoint ในเครื่องจาก บทที่ 22 — เซิร์ฟเวอร์ Python ขนาดเล็กที่ถือ Qwen2.5-0.5B-Instruct บน CPU และพูดรูปแบบ chat-completions เพื่อให้ลูปอยู่ใน TypeScript และ tensor อยู่ฝั่งไกลของพอร์ต

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

ตัวนับ other คือสิ่งที่เปลี่ยนผลลัพธ์น่าผิดหวังให้เป็นผลลัพธ์ที่มีประโยชน์: เมื่อโมเดลผิด มัน หลงทาง หรือมัน มั่นใจ?

คำตอบคือมั่นใจ ในแปดตำแหน่งที่ไม่ใช่ตำแหน่งแรก 136 จาก 205 คำตอบผิดเป็น extension ของ ticket อื่น — ตัวเลขสี่หลักจริง รูปแบบถูกต้อง อ่านจากบรรทัดผิด ที่ตำแหน่ง 1 มีเพียงหนึ่งในห้าครั้งที่พลาดเป็นแบบนั้น; ที่ตำแหน่ง 7 เป็น 21 จาก 26

ความแตกต่างนี้คือสิ่งสำคัญใน production โมเดลที่พูดว่า ฉันหาไม่เจอ คือบั๊กที่คุณสังเกตเห็น; โมเดลที่ส่งเลขของแถวข้างเคียงกลับมา คือบั๊กที่คุณ ship เพราะบนหน้าจอทั้งสองดูเหมือนกัน นี่คือความล้มเหลวที่บทที่ 19 สร้าง citation ที่ตรวจสอบได้ไว้รับมือ แต่ครั้งนี้มันมาจากข้างใน prompt แทนที่จะมาจาก index

ตำแหน่งคือแกนหนึ่ง ความยาวคืออีกแกน และทดสอบง่ายกว่า: วางคำตอบไว้ตรงกลาง แล้วเพิ่มความยาวของรายการ

หนึ่ง record และ 97 token: 90 % สาม record และ 159 token: 55 % แปด record และ 315 token: 15 % และจากนั้นแบนราบต่ำไปจนถึง 140 record และ 4,477 token การพังทั้งหมดเกิดขึ้นระหว่างบรรทัดแรกกับบรรทัดที่แปดของรายการ

คอลัมน์สุดท้ายคือทุกอย่างที่ไม่ใช่ extension ที่ถูกต้องและไม่ใช่ของ record อื่น ซึ่งเมื่อมี record เดียวบนหน้า ก็เป็นที่เดียวที่คำตอบผิดจะตกลงไปได้ สองครั้งที่พลาดในกรณี หนึ่ง record ควรรายงานแทนที่จะปัดทิ้ง เพราะทั้งสองไม่ใช่การปฏิเสธ: ครั้งหนึ่งตอบ 5806 ให้ทะเบียนที่มีบรรทัดเดียวบอกว่า 5805 ที่ 97 token กับผู้สมัครเพียงตัวเดียว โมเดลนี้ยังคัดลอกตัวเลขผิด 2 ครั้งจาก 20 และนั่นคือพื้นฐานที่ทุกอย่างอื่นถูกวัดเทียบ

มีข้อสรุปสองอย่าง context ที่ใหญ่ขึ้นซื้อสิทธิ์ในการส่งมากขึ้น ไม่ได้ซื้อความแน่นอนว่าจะถูกอ่าน: โมเดลนี้มี window 32,768 token และช่วงที่ใช้งานได้จริงในงานนี้คือไม่กี่ร้อย token และไม่มี threshold ไม่มีหน้าผา ไม่มีสถานะ “context full” — การเสื่อมเริ่มตั้งแต่ record ที่สามและสมบูรณ์ที่ record ที่แปด ที่หนึ่งเปอร์เซ็นต์ของ window ไม่ว่าขีดจำกัด context คืออะไร มันไม่ใช่สิ่งที่ควบคุมเรื่องนี้

มักมีการเสนอ 2 กลไก กลไกแรกคือเลขคณิตจากบทที่ 9 ซึ่ง Anthropic กล่าวด้วยถ้อยคำเดียวกับคอร์สนี้: โมเดล “are based on the transformer architecture, which enables every token to attend to every other token across the entire context. This results in n² pairwise relationships for n tokens”.¹ Attention บน sequence ที่ยาวขึ้นไม่ใช่การทำ operation เดิมกับวัสดุมากขึ้น; มันคือ budget คงที่หนึ่งก้อนของมวลความน่าจะเป็นที่ถูกกระจายไปยังคู่แข่งมากขึ้น กลไกที่สองคือการฝึก: โมเดลเห็น sequence สั้นมากกว่ายาวมาก ดังนั้น pattern เชิงตำแหน่งระยะไกลจึงเป็นส่วนของ network ที่ฝึกน้อยที่สุด นั่นเป็นเหตุผลเชิงโต้แย้ง ไม่ใช่การวัด และบทนี้ตัดสินมันไม่ได้

สิ่งที่ ตัดสินแล้ว คือรูปทรง และเป็นเช่นนั้นมาตั้งแต่ 2023 Liu และคณะทดสอบการตอบคำถามหลายเอกสารและ key-value retrieval ข้ามตระกูลและขนาดของโมเดล และพบว่า “performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models”.² บทที่ 15 เอากฎตำแหน่งจาก paper นั้น; บทที่ 19 เอาเหตุผลที่ chunk ที่ดึงมา 20 ชิ้นทำคะแนนแย่กว่า 4 ชิ้นจาก paper นั้น รูปแบบใช้งานจริงของข้อเท็จจริงนี้คือประโยคเดียวที่คุณควรลงมือทำ: เรื่องนี้ใช้เวลาห้านาทีในการวัดบนโมเดลของคุณเองด้วยข้อมูลของคุณเอง และ curve ที่ตีพิมพ์ใด ๆ ก็แทนของคุณไม่ได้

ถามทีมหนึ่งว่าอะไรเติม context ของ agent ของพวกเขา แล้วคุณจะได้ค่าประมาณ เพราะไม่มี API ใดคืนคำตอบนี้: response ให้ prompt_tokens กับคุณ เป็นตัวเลขเดียวสำหรับทั้งหมด

คุณกู้ breakdown ได้ด้วยการนับ 4 ครั้งและลบ 3 ครั้ง — prompt ที่ render ทั้งหมด, ตัวเดียวกันแต่ไม่มีนิยามเครื่องมือ, system message อย่างเดียวทั้งมีและไม่มีนิยามเหล่านั้น, และทุกอย่างเมื่อเอาผลลัพธ์เครื่องมือออก:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt ใช้ chat template ของโมเดลเองก่อน tokenizing ซึ่งสำคัญกว่าที่ฟังดู: ข้อความของคุณไม่ใช่สิ่งที่ถูกนับ role marker, preamble ของ tool calling และการ render schema ล้วนเป็น token ที่คุณจ่ายเงินและไม่เคยพิมพ์ บทที่ 7 สร้าง tokenizer และบทที่ 16 นับด้วย js-tiktoken; ที่นี่การนับมาจากโมเดลเดียวกันที่จะอ่าน prompt ซึ่งเป็นการนับเดียวที่ถูกต้องเป๊ะ

ตอนนี้รัน agent จริงผ่านมัน: การสืบสวน incident 40 turn, เครื่องมือ 12 รายการ, สภาพแวดล้อม operations ปลอมที่คืน log dump และ series ของ metric ที่สมจริง

อ่านแถวแรกเทียบกับแถวสุดท้าย

ที่ turn 1 prompt มี 2,547 token และ 71 % ของมันคือนิยามเครื่องมือ system prompt คือ 3 % สิ่งที่ผู้ใช้พิมพ์คือ 6 % agent ยังไม่ได้ทำอะไรเลย แต่กำลังแบก JSON schema 1,817 token แล้ว

เมื่อถึง turn 40 prompt มี 10,632 token และสัดส่วนกลับด้าน: นิยาม 17 %, บทสนทนา 29 %, ผลลัพธ์เครื่องมือ 53 % output ของเครื่องมือแซงนิยามที่ turn 5; บทสนทนายังไม่แซงนิยามจนถึง turn 25 ดังนั้นตลอด 60 เปอร์เซ็นต์แรกของ session แค็ตตาล็อกเครื่องมือใหญ่กว่าทุกอย่างที่เคยพูดกัน

แล้วดูยอดรวม ตลอด 57 model call การรันนี้ถูกคิดเงิน 370,291 input token สำหรับ context สุดท้าย 10,632 — prompt สุดท้ายถูกจ่ายซ้ำประมาณ 35 เท่า ซึ่งคือ quadratic ของบทที่ 16 พร้อมตัวคูณของ agent ทับอยู่ด้านบน ใน 370,291 นั้น 103,569 หรือ 28 % ของทุกอย่างที่ถูกคิดเงิน คือนิยามเครื่องมือทั้ง 12 รายการ ที่ถูกส่งซ้ำแบบ byte-identical ในทุก call

แค็ตตาล็อกเครื่องมือคือต้นทุนคงที่ที่ใหญ่ที่สุดใน agent และมองไม่เห็น เพราะคุณไม่เคยเห็นมัน: คุณส่ง array ของ object แล้ว provider render มันเข้า prompt ให้คุณ เมื่อนับบนเครื่องมือ 12 รายการเดิม:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

ต่อตัว เครื่องมือมีต้นทุนเพิ่มตั้งแต่ 80 token สำหรับ get_current_time ซึ่งรับ string หนึ่งค่า ไปจนถึง 263 สำหรับ search_tickets ซึ่งรับ parameter 4 ตัวพร้อม enum และประโยคคำแนะนำตัวละหนึ่งประโยค นั่นคืออัตราแลกเปลี่ยนเบื้องหลังคำแนะนำหลักของบทที่ 18 ว่า description คือ API: description ที่ดีมีต้นทุนประมาณ 100 token ในทุก request ไปตลอดชีวิตของ agent มีผลตามมา 3 อย่าง

เครื่องมือที่คุณไม่ได้ใช้ก็ยังคิดเงิน agent เรียกใช้ 7 จาก 12 รายการ อีก 5 รายการมีต้นทุน 697 token ในแต่ละ request จาก 57 request — รวม 39,729 มากกว่าหนึ่งในสิบของทุกอย่างที่การรันถูกคิดเงิน สำหรับความสามารถที่ไม่เคยแตะ หนึ่งในห้ารายการมีรายละเอียดคมที่สุดใน trace: โมเดลพยายามเรียก read_log สามครั้ง ซึ่งไม่มีอยู่จริง เครื่องมือที่มันต้องการคือ search_logs นิยามแพงเป็นอันดับสองในแค็ตตาล็อกที่ 237 token มันจ่ายให้นิยามนั้น 57 ครั้ง ไม่เคยใช้ และไม่เคยหาชื่อเจอ

การตัด prose คือ optimisation ที่ถูกที่สุดที่มี และมันเป็นการแลกเปลี่ยน การตัด description เหลือหนึ่งประโยคและทิ้งเอกสาร parameter ประหยัดได้ 526 token ต่อ call หรือ 29 เปอร์เซ็นต์ โดยไม่แตะ logic สักบรรทัด — และทำให้โมเดลเรียกเครื่องมือแย่ลง ซึ่งเป็นสิ่งที่บทที่ 18 วัดไว้ ประเด็นคือทั้งสองด้านของการแลกเปลี่ยนนี้อยู่ในหน่วยเดียวกันแล้ว

เมื่อถึง scale หนึ่ง การส่งนิยามทั้งหมดก็ไม่สมเหตุสมผลอีกต่อไป Anthropic ใส่ตัวเลขให้เรื่องนี้ในเดือนพฤศจิกายน 2025: ชุด server ที่เชื่อมต่อจำนวนมากหมายถึงการประมวลผลนิยาม “hundreds of thousands of tokens” ก่อนที่ request จะถูกอ่าน และการแทนที่สิ่งนั้นด้วยการรันโค้ด — ให้ agent ค้นพบและโหลดเฉพาะนิยามที่ต้องการ — “reduces the token usage from 150,000 tokens to 2,000 tokens, a time and cost saving of 98.7%”.³ แนวคิดเดียวกับส่วนที่เหลือของบทนี้ แต่นำไปใช้กับ schema แทนประวัติ: เก็บ index ไว้ แล้ว resolve entry เมื่อจำเป็น

มีสิ่งสองอย่างถูกปลูกไว้ใน transcript 40 turn นั้น ที่ turn 2 ก่อนงานจริงใด ๆ ผู้ใช้ระบุกฎประจำว่า: ticket ใดก็ตามที่คุณเปิดต้อง filed ใต้ employee number ของฉัน 4417 ที่ turn 19 ระหว่าง incident มีข้อเท็จจริงหนึ่งข้อ: shard ที่ได้รับผลกระทบคือ pay-shard-7 ยืนยันโดยทีม payments ที่ turn 40 ผู้ใช้ขอให้ agent เปิด incident ticket ซึ่งต้องใช้ทั้งสองอย่าง แต่ละ probe ถูกถามด้วยถ้อยคำต่างกัน 6 แบบและให้คะแนนเต็ม 6 — greedy decoding เป็น deterministic ดังนั้น call เดียวให้ yes หรือ no ที่ทำซ้ำไม่ได้ และ 6 call ให้ rate

จากนั้น replay transcript ภายใต้ context policy 7 แบบ Replay แทนที่จะ re-run อย่างจงใจ: message, tool call และผลลัพธ์เครื่องมือเป็น byte-identical ในทั้ง 7 แบบ ดังนั้นตัวแปรเดียวคือ แต่ละ policy เลือกเก็บอะไรไว้ บทที่ 16 แสดงว่าทำไม sliding window เป็นการเคลื่อนไหวทาง เศรษฐศาสตร์ ที่แย่ เพราะมันทำลาย prefix ที่ cache ได้ นี่คือสิ่งที่มันทำกับพฤติกรรม:

แถว compaction รวมต้นทุนของการ compact: 18,581 input token สำหรับ summary 7 ชุด และอีก 3,392 สำหรับ note-taker แถว control อยู่ตรงนั้นเพื่อให้ศูนย์ถูกอ่านเป็นศูนย์ — เมื่อมี message สองข้อความนั้นอย่างเดียวใน prompt 1,981 token โมเดลนี้ตอบ probe ทั้งสองได้สมบูรณ์ ดังนั้นไม่มีแถวไหนที่งานยากเกินไป

Full history จำได้ และเป็นสิ่งที่แพงที่สุดในตาราง: 370,291 input token สำหรับ session ที่เนื้อหาถาวรมีสองประโยค

สิ่งนี้ตอบคำถามที่ตอนเปิดทิ้งไว้ ทำไม transcript 10,632 token ถึงถือข้อเท็จจริงที่ทะเบียน 853 token ทำหล่น? เพราะความยาวเป็นตัวแปรที่ผิด ทะเบียนมี extension สี่หลัก 25 ตัวในประโยคเหมือนกัน 25 ประโยค — decoy ที่เกือบสมบูรณ์ 24 ตัวสำหรับตัวเดียวที่คุณต้องการ transcript มี employee number หนึ่งค่าและ shard name หนึ่งชื่อเท่านั้น Context rot คือ interference ก่อนที่จะเป็น volume นั่นคือเหตุผลที่ 136 จาก 205 คำตอบผิดด้านบนเป็นค่าของเพื่อนบ้าน คำถามที่มีประโยชน์เกี่ยวกับ window ไม่ใช่ว่ามันยาวแค่ไหน แต่คือมีสิ่งกี่อย่างในนั้นที่ดูเหมือนคำตอบ

Sliding window ถูกกว่า 57 % และทำ incident หายไปแล้ว employee number รอดมาเพียงเพราะ agent พูดซ้ำมันเข้าไปใน turn ล่าสุด shard ซึ่งถูกระบุครั้งเดียวที่ turn 19 ไม่อยู่ใน 12 message ล่าสุด — และโมเดลไม่บอกเช่นนั้น เมื่อถูกถาม 6 ครั้ง มันตอบว่า “the affected payment shard is shard 4417” โดยคว้า employee number ซึ่งเป็น identifier อื่นเพียงตัวเดียวที่เหลือใน window และอีกสองครั้งตอบ “pool” ซึ่งยกมาจาก string pool_exhausted ใน log line

Compaction ถูกและทำข้อเท็จจริงเดียวกันหาย summary 7 ชุด เขียนโดยโมเดลภายใต้คำสั่งชัดเจนให้ เก็บ identifier, ตัวเลข, standing instruction และคำถามเปิดไว้ และ pay-shard-7 ไม่อยู่ใน summary ที่สำคัญเลย; การเดา 6 ครั้งคือ shard 1, pay_shard_1 และ pool Compaction ไม่ล้มเหลวเสียงดัง มันสร้าง session ที่ลื่นไหล น่าเชื่อ สั้นลงมาก และทำบรรทัดหนึ่งหล่นเงียบ ๆ

สามแถวได้ 0/6 บนข้อเท็จจริง turn 19 — sliding window, compaction และ compaction with notes รวมคำตอบผิด 18 ครั้ง และ ไม่มีสักครั้งที่เป็น “ฉันไม่รู้”

ต่อมาคือแถวที่ควรน่าอาย การเก็บ message ทั้ง 40 ข้อความของผู้ใช้แบบ verbatim พร้อม 4 turn ล่าสุดแบบเต็ม และไม่มีอะไรอีก มีต้นทุน 168,550 token — น้อยกว่า full history 54 % — และตอบ probe ทั้งสองได้ดีเท่า full history หรือดีกว่า ไม่มี summariser ไม่มี note-taker ไม่มีโมเดลตัวที่สอง: แค่ filter บน role === "user" คำพูดของผู้ใช้คือ token มูลค่าสูงที่ถูกที่สุดใน window ของ agent และ design ส่วนใหญ่ทิ้งมันไปพร้อมกับทุกอย่างอื่น

สองแถวสุดท้ายคือตารางเปิดบทอีกครั้ง ภายใน agent block ที่ pin ไว้ชุดเดียวกัน ย้ายจาก system message ไปไว้ท้าย prompt: 5/6 กลายเป็น 6/6 ด้วย 6 trials นั่นไม่ใช่ความแตกต่างที่มีนัยสำคัญและไม่ได้ถูกเสนอว่าเป็น — มันถูกเสนอเป็นเครื่องเตือนใจว่า ที่ไหน คือ parameter ที่คุณกำลังตั้งค่า ไม่ว่าคุณจะรู้หรือไม่

กลยุทธ์ 4 ข้อด้านล่างเป็นของ Anthropic ตามลำดับของ Anthropic แม้มีเพียง 3 ข้อท้ายที่เป็นรายการ long-horizon ของเขา¹ ทั้งสี่คือ variation ของคำสั่งเดียว: อย่าแบกสิ่งที่ fetch ได้ และอย่าแบกแบบ raw หากแบกแบบ compressed ได้

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

sub-agent ไม่อยู่ในตารางด้านบน เพราะมันไม่ได้รัน 40 turn: มันรันครั้งเดียว ใน window ที่ใครบางคน scope ไว้ให้ เมื่อให้ system prompt, turn 17 ถึง 19 และไม่มีอะไรอีก — 2,737 token — มันตอบ shard probe ได้ 6/6 ดีกว่า policy ทุกตัวในตาราง และตอบ employee probe ได้ 0/6 เพราะเลขนั้นไม่อยู่ใน 3 turn ที่มันได้รับ

นั่นคือ sub-agent ในตัวเลขสองตัว: window ที่สะอาดไม่ใช่ intelligence มันคือ scope และการ scope ถูกทำล่วงหน้าโดยโค้ดที่ต้องรู้อยู่แล้วว่า turn ไหนสำคัญ มีอีกสิ่งหนึ่งในคำตอบเหล่านั้นที่ควรเก็บไว้ นี่เป็น policy เดียวที่ตอบ “None available” แทนที่จะประดิษฐ์อะไรขึ้นมา โมเดลที่มี context เล็กและ coherent รู้ว่าตัวเองขาดอะไร; โมเดลที่มี context ใหญ่และ noisy ไม่รู้

แทบทุกบทสนทนาสับสนเรื่อง memory ของ agent คือกลไกสามแบบที่สวมคำเดียวกัน พวกมันมีอายุ เจ้าของ และ failure mode ต่างกัน และ system ที่เก็บทั้งหมดไว้ในที่เดียวกันมีปัญหาที่มันยังไม่สังเกตเห็น

กรอบวิชาการคือ CoALA ซึ่งจัด language agent รอบ “modular memory components” และแยก working memory ออกจาก episodic, semantic และ procedural store⁴ MemGPT ใช้แนวคิดเดียวกันแบบตรงตัว โดยยืม virtual memory จาก operating system: tier เร็วใน window, tier ช้านอกมัน และโมเดลเองย้ายข้อมูลระหว่างกันด้วย function calls⁵ ทั้งสองบังคับคำถามที่ product ต้องตอบอยู่ดี — ไม่ใช่ ฉันเก็บได้มากแค่ไหน แต่คือ สิ่งนี้อยู่ใน store ไหน และหมดอายุเมื่อไร

การทดสอบเชิงปฏิบัติคือคำถามหนึ่งข้อสำหรับแต่ละข้อเท็จจริง: พรุ่งนี้อะไรควรยังเป็นจริงอยู่? ผลลัพธ์เครื่องมือจาก turn 12: ไม่มีอะไร Summary ของ session: จนกว่า session จะจบ ว่า employee number ของผู้ใช้คือ 4417: จนกว่าเขาจะเปลี่ยนงาน คำตอบสามแบบ store สามแบบ

ตอนนี้คุณวัดได้แล้วว่าอะไรอยู่ใน window ตัดสินใจได้ว่าอะไรควรอยู่ในนั้น และแยกความต่างระหว่าง agent ที่ลืมบางอย่าง กับ agent ที่แบกมันอยู่แต่ไม่ได้มอง

กลยุทธ์สุดท้ายในสี่ข้อคือข้อที่ไม่พอดีกับที่นี่ sub-agent ไม่ใช่ context policy มันคือ agent ตัวที่สอง และทันทีที่มีสองตัว คุณต้องตัดสินว่าอะไรส่งผ่านระหว่างกัน และตัวไหนเป็นหัวหน้า บทที่ 25 คือสิ่งนั้น: orchestration pattern 5 แบบและชื่อของแต่ละแบบมาจากไหนจริง ๆ, topology 2 แบบที่มักถูกปนกัน — การถาม sub-agent แล้วได้คำตอบกลับมา เทียบกับการส่ง conversation ให้มันและไม่ได้กลับมา — และผลการวัดที่พบว่าในงานที่มันคิดราคา วิธีที่เรียบง่ายกว่าชนะ ตามด้วยการทดสอบว่าเมื่อไรที่มันหยุดชนะ

มันยังรับมรดกทุกอย่างที่บทนี้เพิ่งวัดมาอย่างพอดี sub-agent คืน summary summary คือ compaction ที่คุณไม่ได้เขียน ผลิตโดยโมเดลที่คุณมองไม่เห็น window และ parent ไม่มีวิธีแยก summary ที่ดีออกจาก summary ผิดแต่มั่นใจ — ความต่างเดียวกับที่แยก 84 % ออกจาก 19 % ด้านบนของหน้านี้ และที่เปลี่ยนข้อเท็จจริงที่หาย 18 ข้อให้เป็นสิ่งประดิษฐ์ 18 อย่าง ดังนั้น: เมื่อ sub-agent ผิด parent ได้ดูอะไรกันแน่?

ตัวเลขทุกตัวที่นี่ถูกผลิตบนเครื่องนี้และไม่มีตัวใดเป็นค่าประมาณ โมเดลคือ Qwen2.5-0.5B-Instruct ใน float32 บน CPU ด้วย greedy decoding เสิร์ฟผ่าน loopback โดย endpoint Python ขนาดเล็กที่พูดรูปแบบ chat-completions และเปิด token-count route — seam ของ บทที่ 14 อีกครั้ง tensor อยู่ฝั่ง Python และลูปอยู่ฝั่ง TypeScript — ดังนั้นทุก count คือ tokenizer ของโมเดลนั้นเองที่ apply กับ chat template ของมันเอง ตารางตำแหน่งคือ 288 call, 9 ตำแหน่งคูณ 32 trial โดยใช้ ticket ต่างกันในแต่ละ trial; ตารางความยาวคือ 140 call; agent run คือ 57 model call ตลอด 43 นาทีของ wall clock; ตาราง policy คือ transcript เดียวนั้น replay ภายใต้ 7 policy ช่วงเป็น Wilson จากบทที่ 4 ไม่มี paid API ถูกเรียก ซึ่งเป็นเหตุผลที่ไม่มีราคาสักรายการในบทนี้: token count ถูกต้องเป๊ะ และ rate ที่คุณจะเอาไปคูณคือของบทที่ 16