Technical reference

การแคชพรอมต์

การแคชพรอมต์ช่วยให้ผู้ให้บริการโมเดลนำคำนำหน้าพรอมต์ที่ไม่เปลี่ยนแปลง (คำสั่งระบบ/นักพัฒนา นิยามเครื่องมือ และบริบทคงที่อื่น ๆ) กลับมาใช้ซ้ำระหว่างรอบได้ แทนที่จะประมวลผลใหม่ทุกคำขอ ซึ่งช่วยลดต้นทุนโทเค็นและเวลาแฝงในเซสชันที่ทำงานยาวนานและมีบริบทซ้ำ

OpenClaw ปรับข้อมูลการใช้งานจากผู้ให้บริการให้อยู่ในรูป cacheRead และ cacheWrite เมื่อใดก็ตามที่ API ต้นทางเปิดเผยตัวนับเหล่านี้ สรุปการใช้งาน (/status และคำสั่งที่คล้ายกัน) จะใช้รายการการใช้งานล่าสุดจากทรานสคริปต์เป็นค่าทดแทน เมื่อสแนปช็อตเซสชันปัจจุบันไม่มีตัวนับแคช โดยค่าปัจจุบันที่ไม่เป็นศูนย์จะมีลำดับความสำคัญเหนือค่าทดแทนเสมอ

เอกสารอ้างอิงของผู้ให้บริการ:

การตั้งค่าหลัก

cacheRetention

ค่า: "none" | "short" | "long" สามารถกำหนดเป็นค่าเริ่มต้นส่วนกลาง แยกตามโมเดล และแยกตามเอเจนต์ได้

yaml
agents:  defaults:    params:      cacheRetention: "long" # none | short | long    models:      "anthropic/claude-opus-4-6":        params:          cacheRetention: "short" # แทนที่ค่าเริ่มต้นส่วนกลางสำหรับโมเดลนี้  list:    - id: "alerts"      params:        cacheRetention: "none" # แทนที่ค่าเริ่มต้นทั้งสองระดับสำหรับเอเจนต์นี้

ลำดับการผสาน (รายการหลังมีลำดับความสำคัญสูงกว่า):

  1. agents.defaults.params - ค่าเริ่มต้นส่วนกลางสำหรับทุกโมเดล
  2. agents.defaults.models["provider/model"].params - ค่าที่แทนที่แยกตามโมเดล
  3. agents.list[].params - ค่าที่แทนที่แยกตามเอเจนต์ โดยจับคู่ด้วยรหัสเอเจนต์

แหล่งที่มา: src/agents/embedded-agent-runner/extra-params.ts (resolveExtraParams)

contextPruning.mode: "cache-ttl"

ตัดบริบทผลลัพธ์เครื่องมือเก่าหลังจากพ้นช่วง TTL ของแคช เพื่อไม่ให้คำขอหลังจากไม่มีการใช้งานระยะหนึ่งแคชประวัติขนาดใหญ่อีกครั้ง

yaml
agents:  defaults:    contextPruning:      mode: "cache-ttl"      ttl: "1h"

ดูพฤติกรรมทั้งหมดที่ การตัดเซสชัน

การรักษาแคชให้อุ่นด้วย Heartbeat

Heartbeat สามารถรักษาช่วงเวลาแคชให้อุ่นและลดการเขียนแคชซ้ำหลังจากช่วงที่ไม่มีการใช้งาน สามารถกำหนดได้ทั้งแบบส่วนกลาง (agents.defaults.heartbeat) หรือแยกตามเอเจนต์ (agents.list[].heartbeat)

yaml
agents:  defaults:    heartbeat:      every: "55m"

พฤติกรรมของผู้ให้บริการ

Anthropic (API โดยตรงและ Vertex AI)

  • รองรับ cacheRetention สำหรับผู้ให้บริการ anthropic และ anthropic-vertex รวมถึงโมเดล Claude บน amazon-bedrock และปลายทางแบบกำหนดเองที่เข้ากันได้กับ anthropic-messages เมื่อกำหนด cacheRetention อย่างชัดเจน
  • เมื่อไม่ได้กำหนด OpenClaw จะตั้งค่าเริ่มต้น cacheRetention: "short" สำหรับ Anthropic โดยตรง (เฉพาะผู้ให้บริการ anthropic และ anthropic-vertex เท่านั้น ส่วนเส้นทางอื่นในตระกูล Anthropic ต้องกำหนดค่าอย่างชัดเจน)
  • การตอบกลับแบบ Anthropic Messages ดั้งเดิมเปิดเผย cache_read_input_tokens และ cache_creation_input_tokens ซึ่งแมปไปยัง cacheRead และ cacheWrite
  • cacheRetention: "short" แมปไปยังแคชชั่วคราวเริ่มต้นระยะเวลา 5 นาที ส่วน cacheRetention: "long" จะขอ TTL 1 ชั่วโมง (cache_control: { type: "ephemeral", ttl: "1h" }) เมื่อกำหนดอย่างชัดเจน การคงแคชระยะยาวที่มาจากค่าโดยนัย/ตัวแปรสภาพแวดล้อม (OPENCLAW_CACHE_RETENTION=long โดยไม่มี cacheRetention ที่กำหนดอย่างชัดเจน) จะอัปเกรดเป็น TTL 1 ชั่วโมงเฉพาะบนโฮสต์ api.anthropic.com หรือ Vertex AI (aiplatform.googleapis.com / *-aiplatform.googleapis.com) เท่านั้น โฮสต์อื่นยังคงใช้แคช 5 นาที

แหล่งที่มา: src/agents/anthropic-payload-policy.ts (resolveAnthropicEphemeralCacheControl, isLongTtlEligibleEndpoint)

OpenAI (API โดยตรง)

  • การแคชพรอมต์ทำงานโดยอัตโนมัติในโมเดลรุ่นใหม่ที่รองรับ OpenClaw จะไม่แทรกเครื่องหมายแคชระดับบล็อก
  • OpenClaw ส่ง prompt_cache_key เพื่อให้การกำหนดเส้นทางแคชคงที่ระหว่างรอบ โฮสต์ api.openai.com โดยตรงจะได้รับค่านี้โดยอัตโนมัติ พร็อกซีที่เข้ากันได้กับ OpenAI (oMLX, llama.cpp และปลายทางแบบกำหนดเอง) ต้องกำหนด compat.supportsPromptCacheKey: true ในการตั้งค่าโมเดลเพื่อเข้าร่วม โดยระบบจะไม่ตรวจพบค่านี้โดยอัตโนมัติสำหรับพร็อกซี
  • ระบบจะเพิ่ม prompt_cache_retention: "24h" เฉพาะเมื่อเลือก cacheRetention: "long" และปลายทางที่แก้ไขแล้วรองรับทั้งคีย์แคชและการคงแคชระยะยาว (compat.supportsLongCacheRetention ซึ่งเป็น true โดยค่าเริ่มต้น แต่โปรไฟล์ความเข้ากันได้ของ Together AI และ Cloudflare จะปิดใช้งาน) cacheRetention: "none" จะระงับทั้งสองฟิลด์
  • การเข้าใช้แคชสำเร็จจะแสดงผ่าน usage.prompt_tokens_details.cached_tokens (Chat Completions) หรือ input_tokens_details.cached_tokens (Responses API) ซึ่งแมปไปยัง cacheRead
  • เพย์โหลดของ Responses API อาจเปิดเผย input_tokens_details.cache_write_tokens ด้วย ซึ่งแมปไปยัง cacheWrite และคิดราคาตามอัตราการเขียนแคชของโมเดล ส่วนเพย์โหลด Responses ที่ไม่มีฟิลด์นี้จะคง cacheWrite ไว้ที่ 0 API Chat Completions ของ OpenAI ไม่ได้จัดทำเอกสารหรือส่งตัวนับ cache_write_tokens แต่ OpenClaw ยังคงอ่าน prompt_tokens_details.cache_write_tokens จาก API ดังกล่าวสำหรับพร็อกซีที่เข้ากันได้กับ OpenRouter และพร็อกซีรูปแบบ DeepSeek ที่รายงานจำนวนการเขียนแยกต่างหาก
  • ในการใช้งานจริง OpenAI มีพฤติกรรมคล้ายแคชคำนำหน้าเริ่มต้น มากกว่าการนำประวัติทั้งหมดที่เลื่อนไปข้างหน้าของ Anthropic มาใช้ซ้ำ โปรดดู ความคาดหวังจากการใช้งานจริงของ OpenAI ด้านล่าง

Amazon Bedrock

  • การอ้างอิงโมเดล Anthropic Claude (amazon-bedrock/*anthropic.claude* รวมถึงคำนำหน้าโปรไฟล์การอนุมานของระบบ AWS us./eu./global.anthropic.claude*) รองรับการส่งผ่าน cacheRetention ที่กำหนดอย่างชัดเจน
  • โมเดล Bedrock ที่ไม่ใช่ Anthropic (ตัวอย่างเช่น amazon.nova-*) จะไม่มีการคงแคชในขณะรัน ไม่ว่าจะกำหนดค่า cacheRetention ใดไว้ก็ตาม
  • ARN ของโปรไฟล์การอนุมานแอปพลิเคชัน Bedrock แบบทึบ (รหัสโปรไฟล์ที่ไม่มี claude) จะไม่มีการคงแคชเช่นกัน เว้นแต่จะกำหนด cacheRetention อย่างชัดเจน เนื่องจากไม่สามารถอนุมานตระกูลโมเดลจาก ARN เพียงอย่างเดียวได้

OpenRouter

สำหรับการอ้างอิงโมเดล openrouter/anthropic/* OpenClaw จะแทรกเครื่องหมาย cache_control ของ Anthropic ในบล็อกพรอมต์ระบบ/นักพัฒนา แต่เฉพาะเมื่อคำขอยังคงมุ่งไปยังเส้นทาง OpenRouter ที่ยืนยันแล้ว (openrouter บนปลายทางเริ่มต้น หรือผู้ให้บริการ/URL ฐานใด ๆ ที่แก้ไขไปยัง openrouter.ai) การเปลี่ยนให้โมเดลชี้ไปยัง URL พร็อกซีที่เข้ากันได้กับ OpenAI แบบกำหนดเองจะหยุดการแทรกนี้

อนุญาตให้ใช้ contextPruning.mode: "cache-ttl" สำหรับการอ้างอิงโมเดล openrouter/anthropic/*, openrouter/deepseek/*, openrouter/moonshot/*, openrouter/moonshotai/* และ openrouter/zai/* เนื่องจากเส้นทางเหล่านี้จัดการการแคชพรอมต์ฝั่งผู้ให้บริการโดยไม่ต้องใช้เครื่องหมายที่ OpenClaw แทรก

แหล่งที่มา: extensions/openrouter/index.ts (OPENROUTER_CACHE_TTL_MODEL_PREFIXES)

การสร้างแคช DeepSeek บน OpenRouter เป็นแบบพยายามให้ดีที่สุดและอาจใช้เวลาสองสามวินาที คำขอที่ตามมาทันทีอาจยังแสดง cached_tokens: 0 ให้ตรวจสอบด้วยคำขอที่ใช้คำนำหน้าเดิมซ้ำหลังจากรอสักครู่ โดยใช้ usage.prompt_tokens_details.cached_tokens เป็นสัญญาณว่าพบแคช

Google Gemini (API โดยตรง)

  • การรับส่งข้อมูล Gemini โดยตรง (api: "google-generative-ai") รายงานการเข้าใช้แคชสำเร็จผ่าน cachedContentTokenCount จากต้นทาง ซึ่งแมปไปยัง cacheRead
  • ตระกูลโมเดลที่เข้าเกณฑ์: gemini-2.5* และ gemini-3* (ไม่รวมตัวแปร Live/พรีวิวที่อยู่นอกการจับคู่คำนำหน้านี้ ตัวอย่างเช่น gemini-live-2.5-flash-preview)
  • เมื่อกำหนด cacheRetention ในโมเดลที่เข้าเกณฑ์ OpenClaw จะสร้าง ใช้ซ้ำ และรีเฟรชทรัพยากร cachedContents สำหรับพรอมต์ระบบโดยอัตโนมัติ โดยไม่ต้องใช้แฮนเดิลเนื้อหาที่แคชด้วยตนเอง TTL คือ 300s สำหรับ cacheRetention: "short" และ 3600s สำหรับ "long"
  • คุณยังคงสามารถส่งแฮนเดิลเนื้อหาที่แคชของ Gemini ที่มีอยู่แล้วผ่าน params.cachedContent (หรือ params.cached_content แบบเดิม) ได้ แฮนเดิลที่ระบุอย่างชัดเจนจะข้ามเส้นทางการจัดการแคชอัตโนมัติทั้งหมด
  • กลไกนี้แยกจากการแคชคำนำหน้าพรอมต์ของ Anthropic/OpenAI โดย OpenClaw จะจัดการทรัพยากร cachedContents ดั้งเดิมของผู้ให้บริการสำหรับ Gemini แทนการแทรกเครื่องหมายแคชแบบอินไลน์

แหล่งที่มา: src/agents/embedded-agent-runner/google-prompt-cache.ts

ผู้ให้บริการผ่านชุดทดสอบ CLI (Claude Code, Gemini CLI)

แบ็กเอนด์ CLI ที่ส่งเหตุการณ์การใช้งาน JSONL (jsonlDialect: "claude-stream-json" หรือ "gemini-stream-json") จะผ่านตัวแยกวิเคราะห์การใช้งานร่วมกัน ซึ่งรู้จักชื่อฟิลด์หลายรูปแบบ รวมถึงตัวนับ cached แบบธรรมดาที่แมปไปยัง cacheRead เมื่อเพย์โหลด JSON ของ CLI ไม่มีฟิลด์โทเค็นอินพุตโดยตรง OpenClaw จะคำนวณเป็น input_tokens - cached กลไกนี้เป็นเพียงการปรับข้อมูลการใช้งานให้เป็นรูปแบบมาตรฐานเท่านั้น โดยไม่ได้สร้างเครื่องหมายแคชพรอมต์รูปแบบ Anthropic/OpenAI สำหรับโมเดลที่ขับเคลื่อนด้วย CLI เหล่านี้

แหล่งที่มา: src/agents/cli-output.ts (toCliUsage)

ผู้ให้บริการอื่น

หากผู้ให้บริการไม่รองรับโหมดแคชใด ๆ ข้างต้น cacheRetention จะไม่มีผล

ขอบเขตแคชของพรอมต์ระบบ

OpenClaw แบ่งพรอมต์ระบบเป็น คำนำหน้าคงที่ และ คำต่อท้ายที่เปลี่ยนแปลงได้ ณ ขอบเขตคำนำหน้าแคชภายใน เนื้อหาเหนือขอบเขต (นิยามเครื่องมือ เมทาดาทาของ Skills และไฟล์พื้นที่ทำงาน) จะถูกจัดลำดับให้เหมือนกันทุกไบต์ระหว่างรอบ เนื้อหาใต้ขอบเขต (ตัวอย่างเช่น HEARTBEAT.md การประทับเวลาขณะรัน และเมทาดาทาอื่นที่เปลี่ยนในแต่ละรอบ) สามารถเปลี่ยนแปลงได้โดยไม่ทำให้คำนำหน้าที่แคชไว้ใช้ไม่ได้

ตัวเลือกการออกแบบที่สำคัญ:

  • ไฟล์บริบทโปรเจกต์ในพื้นที่ทำงานที่คงที่จะถูกจัดลำดับไว้ก่อน HEARTBEAT.md เพื่อไม่ให้การเปลี่ยนแปลงของ Heartbeat ทำลายคำนำหน้าคงที่
  • ขอบเขตนี้ใช้ครอบคลุมการจัดรูปแบบการรับส่งข้อมูลของตระกูล Anthropic, ตระกูล OpenAI, Google และ CLI เพื่อให้ผู้ให้บริการที่รองรับทั้งหมดได้ประโยชน์จากความคงที่ของคำนำหน้าแบบเดียวกัน
  • คำขอ Codex Responses และ Anthropic Vertex จะถูกกำหนดเส้นทางผ่านการจัดรูปแบบแคชที่รับรู้ขอบเขต เพื่อให้การใช้แคชซ้ำสอดคล้องกับสิ่งที่ผู้ให้บริการได้รับจริง
  • ลายนิ้วมือของพรอมต์ระบบจะถูกปรับให้เป็นมาตรฐาน (ช่องว่าง รูปแบบการขึ้นบรรทัดใหม่ บริบทที่เพิ่มโดยฮุก และลำดับความสามารถขณะรัน) เพื่อให้พรอมต์ที่ไม่มีการเปลี่ยนแปลงทางความหมายใช้แคชร่วมกันระหว่างรอบได้

หากพบว่า cacheWrite เพิ่มสูงอย่างไม่คาดคิดหลังจากเปลี่ยนการกำหนดค่าหรือพื้นที่ทำงาน ให้ตรวจสอบว่าการเปลี่ยนแปลงนั้นอยู่เหนือหรือใต้ขอบเขตแคช การย้ายเนื้อหาที่เปลี่ยนแปลงได้ไปไว้ใต้ขอบเขต (หรือทำให้เนื้อหานั้นคงที่) มักแก้ปัญหาได้

กลไกป้องกันความคงที่ของแคชใน OpenClaw

  • แค็ตตาล็อกเครื่องมือ MCP ที่รวมมาให้จะถูกเรียงลำดับแบบกำหนดแน่นอน (ตามชื่อเซิร์ฟเวอร์ แล้วตามชื่อเครื่องมือ) ก่อนลงทะเบียนเครื่องมือ เพื่อไม่ให้การเปลี่ยนลำดับของ listTools() ทำให้บล็อกเครื่องมือเปลี่ยนแปลงและทำลายคำนำหน้าแคชพรอมต์
  • เซสชันเดิมที่มีบล็อกรูปภาพบันทึกคงอยู่จะเก็บ 3 รอบที่เสร็จสมบูรณ์ล่าสุด ไว้ครบถ้วน (นับรอบที่เสร็จสมบูรณ์ทั้งหมด ไม่ใช่เฉพาะรอบที่มีรูปภาพ) บล็อกรูปภาพเก่าที่ประมวลผลแล้วจะถูกแทนที่ด้วยเครื่องหมายข้อความ เพื่อไม่ให้คำขอติดตามผลที่มีรูปภาพจำนวนมากส่งเพย์โหลดเก่าขนาดใหญ่ซ้ำอย่างต่อเนื่อง

รูปแบบการปรับแต่ง

ทราฟฟิกแบบผสม (ค่าเริ่มต้นที่แนะนำ)

คงค่าพื้นฐานระยะยาวไว้ในเอเจนต์หลัก และปิดการแคชสำหรับเอเจนต์แจ้งเตือนที่ทำงานเป็นช่วงสั้น ๆ:

yaml
agents:  defaults:    model:      primary: "anthropic/claude-opus-4-6"    models:      "anthropic/claude-opus-4-6":        params:          cacheRetention: "long"  list:    - id: "research"      default: true      heartbeat:        every: "55m"    - id: "alerts"      params:        cacheRetention: "none"

ค่าพื้นฐานที่ให้ความสำคัญกับต้นทุน

  • กำหนดค่าพื้นฐาน cacheRetention: "short"
  • เปิดใช้ contextPruning.mode: "cache-ttl"
  • ตั้งช่วง Heartbeat ให้ต่ำกว่า TTL เฉพาะสำหรับเอเจนต์ที่ได้ประโยชน์จากแคชที่อุ่นอยู่

การทดสอบการถดถอยแบบใช้งานจริง

OpenClaw ใช้เกตทดสอบการถดถอยของแคชแบบใช้งานจริงชุดเดียว ซึ่งครอบคลุมคำนำหน้าซ้ำ รอบเครื่องมือ รอบรูปภาพ ทรานสคริปต์เครื่องมือรูปแบบ MCP และกรณีควบคุมที่ไม่ใช้แคชของ Anthropic

  • src/agents/live-cache-regression.live.test.ts
  • src/agents/live-cache-regression-runner.ts
  • src/agents/live-cache-regression-baseline.ts

เรียกใช้ด้วย:

sh
OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache

ไฟล์ค่าพื้นฐานจัดเก็บตัวเลขจากการใช้งานจริงที่สังเกตได้ล่าสุด พร้อมเกณฑ์ขั้นต่ำการถดถอยเฉพาะผู้ให้บริการที่การทดสอบใช้ตรวจสอบ การเรียกใช้แต่ละครั้งใช้รหัสเซสชันและเนมสเปซพรอมต์ใหม่ เพื่อไม่ให้สถานะแคชก่อนหน้าปนเปื้อนตัวอย่างปัจจุบัน Anthropic และ OpenAI ใช้การบังคับใช้ที่ต่างกัน: หาก Anthropic ต่ำกว่าเกณฑ์ขั้นต่ำจะถือเป็นการถดถอยอย่างชัดเจน (การทดสอบล้มเหลว) ส่วน OpenAI หากต่ำกว่าเกณฑ์ขั้นต่ำจะเป็นเพียงการเฝ้าระวัง (บันทึกเป็นคำเตือน แต่ไม่ทำให้การเรียกใช้ล้มเหลว) ทั้งสองไม่ได้ใช้เกณฑ์เดียวกันข้ามผู้ให้บริการ

ความคาดหวังจากการใช้งานจริงของ Anthropic

  • คาดว่าจะมีการเขียนข้อมูลช่วงวอร์มอัปอย่างชัดเจนผ่าน cacheWrite
  • คาดว่าจะนำประวัติเกือบทั้งหมดกลับมาใช้ซ้ำในการโต้ตอบรอบถัด ๆ ไป เนื่องจากการควบคุมแคชของ Anthropic เลื่อนจุดแบ่งแคชไปตามบทสนทนา
  • ค่าขั้นต่ำอ้างอิงสำหรับเลนแบบคงที่ เครื่องมือ รูปภาพ และรูปแบบ MCP เป็นเกณฑ์ตรวจจับการถดถอยแบบบังคับ

สิ่งที่คาดหวังจากการใช้งาน OpenAI แบบสด

  • คาดว่าจะมีเฉพาะ cacheRead โดย cacheWrite จะคงเป็น 0 บน Chat Completions
  • ให้ถือว่าการนำแคชกลับมาใช้ซ้ำในการโต้ตอบรอบถัด ๆ ไปจะคงที่อยู่ที่ระดับหนึ่งซึ่งขึ้นอยู่กับผู้ให้บริการ ไม่ใช่การนำประวัติทั้งหมดที่เลื่อนไปตามบทสนทนากลับมาใช้ซ้ำแบบ Anthropic
  • ค่าขั้นต่ำใช้สำหรับเฝ้าดูเท่านั้น (หากไม่ถึงค่าจะบันทึกเป็นคำเตือน ไม่ใช่ทำให้การทดสอบล้มเหลว) โดยอ้างอิงจากพฤติกรรมการใช้งานจริงที่สังเกตพบบน gpt-5.4-mini:
สถานการณ์ ค่าขั้นต่ำของ cacheRead ค่าขั้นต่ำของอัตราการพบแคช
คำนำหน้าคงที่ 4,608 0.90
ทรานสคริปต์เครื่องมือ 4,096 0.85
ทรานสคริปต์รูปภาพ 3,840 0.82
ทรานสคริปต์รูปแบบ MCP 4,096 0.85

ตัวเลขอ้างอิงล่าสุดที่สังเกตพบ (จาก live-cache-regression-baseline.ts) คือ: คำนำหน้าคงที่ cacheRead=4864 อัตราการพบแคช 0.966; ทรานสคริปต์เครื่องมือ cacheRead=4608 อัตราการพบแคช 0.896; ทรานสคริปต์รูปภาพ cacheRead=4864 อัตราการพบแคช 0.954; ทรานสคริปต์รูปแบบ MCP cacheRead=4608 อัตราการพบแคช 0.891

เหตุผลที่การตรวจสอบยืนยันแตกต่างกัน: Anthropic เปิดเผยจุดแบ่งแคชอย่างชัดเจนและรองรับการนำประวัติการสนทนาที่เลื่อนไปข้างหน้ากลับมาใช้ซ้ำ ขณะที่คำนำหน้าที่นำกลับมาใช้ซ้ำได้จริงของ OpenAI ในทราฟฟิกสดอาจหยุดคงที่ก่อนถึงพรอมต์ทั้งหมด การเปรียบเทียบผู้ให้บริการทั้งสองด้วยเกณฑ์เปอร์เซ็นต์เดียวกันข้ามผู้ให้บริการจะทำให้ตรวจพบการถดถอยที่ไม่เป็นจริง

การกำหนดค่า diagnostics.cacheTrace

yaml
diagnostics:  cacheTrace:    enabled: true    filePath: "~/.openclaw/logs/cache-trace.jsonl" # ไม่บังคับ    includeMessages: false # ค่าเริ่มต้น true    includePrompt: false # ค่าเริ่มต้น true    includeSystem: false # ค่าเริ่มต้น true

ค่าเริ่มต้น:

คีย์ ค่าเริ่มต้น
filePath $OPENCLAW_STATE_DIR/logs/cache-trace.jsonl
includeMessages true
includePrompt true
includeSystem true

ตัวสลับผ่านตัวแปรสภาพแวดล้อม (สำหรับการแก้จุดบกพร่องครั้งเดียว)

ตัวแปร ผลลัพธ์
OPENCLAW_CACHE_TRACE=1 เปิดใช้งานการติดตามแคช
OPENCLAW_CACHE_TRACE_FILE=path เขียนทับพาธเอาต์พุต
OPENCLAW_CACHE_TRACE_MESSAGES=0|1 สลับการบันทึกเพย์โหลดข้อความทั้งหมด
OPENCLAW_CACHE_TRACE_PROMPT=0|1 สลับการบันทึกข้อความพรอมต์
OPENCLAW_CACHE_TRACE_SYSTEM=0|1 สลับการบันทึกพรอมต์ระบบ

สิ่งที่ควรตรวจสอบ

  • เหตุการณ์การติดตามแคชอยู่ในรูปแบบ JSONL พร้อมสแนปช็อตเป็นลำดับขั้น เช่น session:loaded, prompt:before, stream:context และ session:after
  • ผลกระทบของโทเค็นแคชในแต่ละรอบดูได้จากส่วนแสดงการใช้งานตามปกติ โดย cacheRead และ cacheWrite จะแสดงใน /usage tokens, /status, สรุปการใช้งานของเซสชัน และเลย์เอาต์ messages.usageTemplate แบบกำหนดเอง
  • สำหรับ Anthropic เมื่อเปิดใช้งานการแคช คาดว่าจะพบทั้ง cacheRead และ cacheWrite
  • สำหรับ OpenAI เมื่อพบแคช คาดว่าจะพบ cacheRead; ส่วน cacheWrite จะมีค่าเฉพาะในเพย์โหลด Responses API ที่มีข้อมูลนี้เท่านั้น (ดู OpenAI ด้านบน)
  • OpenAI ยังส่งคืนส่วนหัวสำหรับการติดตามและการจำกัดอัตรา เช่น x-request-id, openai-processing-ms และ x-ratelimit-*; ใช้ส่วนหัวเหล่านี้เพื่อติดตามคำขอ แต่การคำนวณการพบแคชควรอ้างอิงจากเพย์โหลดการใช้งาน ไม่ใช่จากส่วนหัว

การแก้ไขปัญหาอย่างรวดเร็ว

  • cacheWrite สูงในรอบส่วนใหญ่: ตรวจสอบอินพุตพรอมต์ระบบที่เปลี่ยนแปลงบ่อย และตรวจสอบว่าโมเดล/ผู้ให้บริการรองรับการตั้งค่าแคชของคุณ
  • cacheWrite สูงบน Anthropic: มักหมายความว่าจุดแบ่งแคชอยู่บนเนื้อหาที่เปลี่ยนแปลงในทุกคำขอ
  • cacheRead ของ OpenAI ต่ำ: ตรวจสอบว่าคำนำหน้าคงที่อยู่ส่วนหน้า คำนำหน้าที่ทำซ้ำมีอย่างน้อย 1024 โทเค็น และมีการใช้ prompt_cache_key เดิมซ้ำสำหรับรอบที่ควรใช้แคชร่วมกัน
  • cacheRetention ไม่มีผล: ตรวจสอบว่าคีย์โมเดลตรงกับ agents.defaults.models["provider/model"]
  • คำขอ Bedrock Nova ที่มีการตั้งค่าแคช: เป็นพฤติกรรมที่คาดไว้ เนื่องจากคำขอเหล่านี้จะถูกแปลงเป็นการไม่เก็บรักษาแคชขณะรันไทม์

เอกสารที่เกี่ยวข้อง:

เนื้อหาที่เกี่ยวข้อง

Was this useful?
On this page

On this page