# 7 วิธีง่ายๆ ในการลดต้นทุน AI Agent โดยไม่ลดคุณภาพ > ลดต้นทุนของ AI agent โดยรักษาเสถียรภาพของเซสชันงานเมื่อรองรับ ทำให้คำนำหน้าพรอมต์เป็นมิตรกับแคช เลือกโมเดลที่มีส่วนลดสำหรับอินพุตที่ถูกแคช บีบอัดบริบทเก่า ตัดแต่งเอาต์พุตของเครื่องมือ หยุดการเรียกซ้ำ และใช้โมเดลราคาถูกสำหรับขั้นตอนง่ายๆ วัดผลประหยัดจากงานที่เสร็จสมบูรณ์ ไม่ใช่จากคำขอแต่ละรายการ # 7 วิธีง่ายๆ ในการลดต้นทุน AI Agent โดยไม่ลดทอนคุณภาพ AI Agent อาจมีค่าใช้จ่ายสูงด้วยเหตุผลง่ายๆ ข้อเดียว: งานของผู้ใช้หนึ่งงานอาจทำให้เกิดการเรียกใช้โมเดลหลายครั้ง Agent จะส่งคำสั่ง ประวัติการสนทนา คำจำกัดความของเครื่องมือ และข้อมูลที่ดึงมา ซ้ำแล้วซ้ำเล่า นอกจากนี้ยังอาจเรียกใช้เครื่องมือที่ล้มเหลวซ้ำ หรือใช้โมเดลราคาแพงสำหรับงานที่โมเดลขนาดเล็กกว่าก็จัดการได้ คุณไม่จำเป็นต้องมีระบบกำหนดเส้นทางที่ซับซ้อนเพื่อปรับปรุงสิ่งนี้ เริ่มต้นด้วยการเปลี่ยนแปลงเชิงปฏิบัติสองสามอย่าง: ทำให้แต่ละงานอยู่ในเซสชันที่เสถียรเมื่อผู้ให้บริการของคุณรองรับ ทำให้ prompt ง่ายต่อการแคช ตัดทอนบริบทเก่า ตัดแต่งผลลัพธ์ของเครื่องมือ และหยุดลูปที่ไม่จำเป็น เป้าหมายไม่ใช่เพื่อลดคำขอทุกครั้ง แต่เพื่อใช้จ่ายน้อยลงในขณะที่ Agent ยังคงทำงานได้อย่างถูกต้อง > **คำตอบสั้นๆ:** รักษาเซสชันหรือคีย์การกำหนดเส้นทางให้คงที่ระหว่างงานหนึ่งงาน ใช้คำนำหน้า prompt ที่เหมือนกันซ้ำ เลือกโมเดลและผู้ให้บริการที่รองรับ cached input แบบลดราคา สรุปข้อความเก่า ส่งคืนเฉพาะข้อมูลเครื่องมือที่จำเป็น จำกัดการเรียกซ้ำ และใช้โมเดลที่ถูกกว่าสำหรับขั้นตอนง่ายๆ วัดค่าใช้จ่ายทั้งหมดของงานที่เสร็จสมบูรณ์ก่อนและหลังการเปลี่ยนแปลงแต่ละครั้ง ## 1. เก็บ session ID เดียวกันระหว่างงานหนึ่งงาน Agent หลายตัวต้องเรียกหลายครั้งเพื่อทำงานหนึ่งชิ้นให้เสร็จ Agent เขียนโค้ดอาจตรวจสอบไฟล์ เสนอการเปลี่ยนแปลง เรียกใช้เครื่องมือ อ่านผลลัพธ์ แล้วจึงสร้างคำตอบสุดท้าย หากแพลตฟอร์มรองรับการกำหนดเส้นทางแบบ sticky การส่ง session หรือ routing key ที่สอดคล้องกันสามารถช่วยให้คำขอที่เกี่ยวข้องไปถึงผู้ให้บริการรายเดียวกันหรือตำแหน่งแคชที่เข้ากันได้ สร้างตัวระบุเพียงครั้งเดียวเมื่อเริ่มงาน และนำกลับมาใช้ใหม่จนกว่างานนั้นจะสิ้นสุด: ```python session_id = create_session_id() while task_is_running: response = call_model( messages=messages, session_id=session_id, ) ``` อย่าใช้ session ID ทั่วโลกเดียวสำหรับทุกๆ ลูกค้าและทุกๆ งาน ให้สร้างค่าใหม่สำหรับแต่ละงานอิสระ และอย่าใส่ข้อมูลผู้ใช้ส่วนตัวลงในตัวระบุ ฟิลด์ที่แน่นอนขึ้นอยู่กับผู้ให้บริการ อาจมีชื่อว่า `session_id`, `user`, `prompt_cache_key` หรือชื่ออื่นๆ API บางตัวไม่เปิดเผยการกำหนดเส้นทางแบบ sticky เลย ตรวจสอบเอกสาร API ก่อนเพิ่มฟิลด์ที่กำหนดเอง ฟิลด์ที่ไม่รองรับอาจถูกเพิกเฉยหรือถูกปฏิเสธ เซสชันที่เสถียรมีประโยชน์ แต่ยังไม่เพียงพอในตัวมันเอง โดยปกติแล้วระบบแคชจะเปรียบเทียบคำนำหน้า prompt ดังนั้นส่วนที่ซ้ำกันของคำขอของคุณต้องคงที่ด้วย ## 2. วางเนื้อหา prompt ที่ใช้ซ้ำได้ไว้ด้านหน้า Prompt caching ทำงานได้ดีที่สุดเมื่อคำขอต่อเนื่องเริ่มต้นด้วยเนื้อหาเดียวกัน วางส่วนที่ใหญ่และใช้ซ้ำได้ไว้ที่จุดเริ่มต้น: 1. คำแนะนำระบบ 2. คำจำกัดความของเครื่องมือ 3. รูปแบบเอาต์พุตและกฎความปลอดภัย 4. บริบทของโปรเจกต์หรือผลิตภัณฑ์ที่คงที่ 5. ประวัติการสนทนา 6. ข้อความผู้ใช้ล่าสุดและข้อมูลที่เปลี่ยนแปลงอื่นๆ หลีกเลี่ยงการแทรก timestamp, ID สุ่ม, ตัวนับคำขอ หรือตัวอย่างที่เปลี่ยนแปลงบ่อยๆ ไว้ใกล้ด้านบน การเปลี่ยนแปลงเล็กน้อยในช่วงต้นของ prompt สามารถป้องกันไม่ให้คำนำหน้าส่วนหลังตรงกับคำขอก่อนหน้า ตัวอย่างเช่น คำนำหน้านี้เปลี่ยนแปลงทุกครั้งที่เรียก: ```text เวลาที่ขอ: 2026-08-21T10:32:18Z คุณคือตัวแทนฝ่ายสนับสนุน... [คำจำกัดความของเครื่องมือ] ``` ย้ายค่าที่เป็นไดนามิกไปไว้ด้านหลัง: ```text คุณคือตัวแทนฝ่ายสนับสนุน... [คำจำกัดความของเครื่องมือ] [กฎการตอบสนองที่คงที่] เวลาที่ขอปัจจุบัน: 2026-08-21T10:32:18Z [ข้อความผู้ใช้ล่าสุด] ``` OpenAI แนะนำให้วางเนื้อหาคงที่ไว้ก่อนและเนื้อหาที่แปรผันไว้ทีหลัง เนื่องจากการ hit แคชต้องใช้คำนำหน้าที่ตรงกันทุกประการ เอกสารของ Google Gemini ให้คำแนะนำที่คล้ายกันสำหรับการแคชโดยนัย: วางเนื้อหาทั่วไปขนาดใหญ่ไว้ที่จุดเริ่มต้นและส่งคำนำหน้าที่คล้ายกันในช่วงเวลาที่ใกล้กัน ดูคำแนะนำอย่างเป็นทางการของ [OpenAI prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) และ [Gemini context caching](https://ai.google.dev/gemini-api/docs/caching) ## 3. เลือกโมเดลที่รองรับ cached input แบบลดราคา ไม่ใช่ทุกโมเดลจะจัดการกับ cached input ในลักษณะเดียวกัน ก่อนเลือกโมเดลสำหรับ Agent ที่ทำงานยาวนาน ให้ตรวจสอบ: - โมเดลรองรับการแคช prompt โดยอัตโนมัติหรือโดยชัดแจ้งหรือไม่? - cached input ถูกเรียกเก็บในอัตราที่ต่ำกว่าหรือไม่? - มีความยาว prompt ขั้นต่ำก่อนเริ่มการแคชหรือไม่? - แคชมีอายุการใช้งานนานแค่ไหน? - API ส่งคืนจำนวน cached token ในข้อมูลการใช้งานหรือไม่? ราคา input token ที่ต่ำอาจดูน่าสนใจ แต่โมเดลที่มีส่วนลดการแคชที่ดีอาจถูกกว่าสำหรับ Agent ที่ส่ง system prompt ยาวหรือชุดคำจำกัดความของเครื่องมือขนาดใหญ่ซ้ำๆ [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reduce-ai-agent-cost-without-losing-quality) ให้การเข้าถึงโมเดลต่างๆ ผ่าน API แบบรวม เอกสารการเรียกเก็บเงินระบุว่าโมเดลที่มี prompt caching จะคิดค่าใช้จ่าย cached input tokens ที่ซ้ำในอัตรา cache ที่ต่ำกว่า ใช้ [รายการโมเดล Atlas Cloud](https://www.atlascloud.ai/pricing/models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=reduce-ai-agent-cost-without-losing-quality&sort=new) เพื่อเปรียบเทียบราคาโมเดลปัจจุบัน จากนั้นทดสอบโมเดลที่รองรับการแคชกับ prompt ที่ซ้ำของคุณเอง อย่าเลือกผู้ให้บริการจากคำกล่าวทางการตลาดเพียงอย่างเดียว ให้รันงานจริงที่เหมือนกันหลายๆ ครั้ง และตรวจสอบการใช้งานและค่าใช้จ่ายจริงที่ส่งคืน พฤติกรรมของแคชอาจขึ้นอยู่กับโมเดล ความยาว prompt ช่วงเวลาของคำขอ และการใช้งานของผู้ให้บริการ ## 4. บีบอัดประวัติการสนทนาเก่า Agent ไม่จำเป็นต้องเก็บข้อความเก่าทุกข้อความแบบเต็มตลอดไป การสนทนาที่ยาวมักประกอบด้วยการทักทาย คำอธิบายซ้ำ แผนที่ล้าสมัย และผลลัพธ์ของเครื่องมือขนาดใหญ่ที่ไม่มีผลต่อขั้นตอนถัดไปอีกต่อไป นโยบายบริบทอย่างง่ายคือ: ```text เก็บข้อความล่าสุด 4 ถึง 8 ข้อความแบบเต็ม สรุปข้อความเก่าเป็น การตัดสินใจ ข้อเท็จจริง ข้อจำกัด และงานที่ยังค้าง ลบผลลัพธ์ของเครื่องมือที่ซ้ำหรือล้าสมัย ``` สรุปที่มีประโยชน์อาจมีลักษณะดังนี้: ```text เป้าหมาย: แก้ไขความล้มเหลวในการชำระเงินสำหรับผู้ใช้ในแคนาดา ข้อเท็จจริงที่ยืนยันแล้ว: API ส่งคืน HTTP 422 เมื่อไม่มี postal_code การตัดสินใจ: ตรวจสอบความถูกต้องของ postal_code ก่อนส่งการชำระเงิน ไฟล์ที่เปลี่ยนแปลง: checkout.ts และ validation.ts งานที่ค้าง: เพิ่ม regression test ``` วิธีนี้ปลอดภัยกว่าการขอสรุปที่สั้นมากซึ่งละชื่อไฟล์ รหัสข้อผิดพลาด หรือข้อกำหนดของผู้ใช้ เก็บรายละเอียดที่มีผลต่อความถูกต้อง สิทธิ์ หรือการเรียกใช้เครื่องมือครั้งถัดไป ลบข้อความที่บันทึกเฉพาะว่า Agent มาถึงจุดนั้นได้อย่างไร สำหรับงานที่ยาวมาก ให้สร้างสรุปใหม่หลังจากถึงเหตุการณ์สำคัญ แทนที่จะสรุปทุกครั้ง การเรียกสรุปก็มีค่าใช้จ่ายเช่นกัน ดังนั้นจึงควรทดแทน input ในอนาคตให้เพียงพอเพื่อให้คุ้มค่า ## 5. ส่งคืนข้อความจากเครื่องมือให้น้อยลง ผลลัพธ์ของเครื่องมือมักเป็นจุดที่ประหยัด token ได้ง่ายที่สุด เครื่องมือค้นหาอาจส่งคืน 50 ผลลัพธ์เมื่อ Agent ต้องการแค่ห้า การเรียกฐานข้อมูลอาจส่งคืน 30 คอลัมน์เมื่อขั้นตอนถัดไปใช้แค่สาม คำสั่งอาจส่งบรรทัด log นับพันเมื่อข้อผิดพลาดปรากฏใน 100 บรรทัดสุดท้ายเท่านั้น ลดผลลัพธ์ของเครื่องมือก่อนที่จะเข้าสู่บริบทของโมเดล: - เลือกเฉพาะคอลัมน์ฐานข้อมูลที่จำเป็น - เพิ่มตัวกรองและขีดจำกัดในการค้นหา - แยกข้อความหลักของบทความแทนที่จะส่งคืน navigation และ HTML - ส่งคืนหน้าต่างข้อผิดพลาดเล็กๆ แทนไฟล์ log ที่สมบูรณ์ - แทนที่ข้อมูลไบนารีหรือสื่อขนาดใหญ่ด้วย metadata และการอ้างอิงที่ปลอดภัย - เก็บเฉพาะคีย์ JSON ที่จำเป็นสำหรับการตัดสินใจครั้งถัดไป ตัวอย่างเช่น อย่าส่งระเบียนลูกค้าทั้งหมดหาก Agent ต้องการเพียงสถานะบัญชีและชื่อแผน: ```json { "account_status": "active", "plan": "pro" } ``` การกรองควรเกิดขึ้นในเครื่องมือหรือโค้ดแอปพลิเคชันเมื่อเป็นไปได้ การขอให้โมเดลอ่านการตอบสนองขนาดใหญ่แล้วย่อให้สั้นลงยังคงต้องจ่ายสำหรับการตอบสนองขนาดใหญ่นั้น ## 6. หยุดการเรียกซ้ำและลูป Agent ที่ไม่สิ้นสุด Agent อาจสิ้นเปลืองเงินโดยการเรียกใช้เครื่องมือเดียวกันด้วยอาร์กิวเมนต์เดียวกัน การลองซ้ำคำขอที่ไม่ถูกต้อง หรือดำเนินการต่อหลังจากที่มีคำตอบที่ใช้งานได้แล้ว เพิ่มขีดจำกัดพื้นฐานสองสามข้อ: - กำหนดจำนวนขั้นตอนของโมเดลและเครื่องมือสูงสุดต่องาน - ตรวจจับการเรียกใช้เครื่องมือที่เหมือนกันและบล็อกการทำซ้ำครั้งที่สอง - หลังจากความล้มเหลวคล้ายกันสองครั้ง ให้หยุดและเปลี่ยนแนวทางหรือขอความช่วยเหลือ - สิ้นสุดการทำงานเมื่อเอาต์พุตที่ต้องการผ่านการตรวจสอบ - ต้องการการยืนยันก่อนดำเนินการที่มีค่าใช้จ่ายสูงหรือมีความเสี่ยงสูง การลองซ้ำควรเลือกทำ การหมดเวลาหรือข้อผิดพลาดของเซิร์ฟเวอร์ชั่วคราวอาจสมควรลองซ้ำ การขาดพารามิเตอร์ที่จำเป็นมักจะสมควรได้รับคำขอที่แก้ไขแล้ว ไม่ใช่คำขอเดิมซ้ำอีก หากความน่าเชื่อถือเป็นปัญหาที่เกิดซ้ำ ให้ใช้การ fallback แทนที่จะเป็นลูปลองซ้ำไม่จำกัด คำแนะนำเกี่ยวกับ [การ failover และ routing ของโมเดลสำหรับ coding agents](https://ask.atlascloud.ai/add-model-failover-routing-coding-agents) อธิบายวิธีทำให้งานหลายขั้นตอนดำเนินต่อไปได้เมื่อโมเดลหรือผู้ให้บริการล้มเหลว ## 7. ใช้โมเดลที่ถูกกว่าสำหรับขั้นตอนง่ายๆ ไม่ใช่ทุกขั้นตอนที่ต้องใช้โมเดลที่แข็งแกร่งที่สุดของคุณ โมเดลที่มีต้นทุนต่ำกว่ามักจะเพียงพอสำหรับงานที่แคบและตรวจสอบง่าย เช่น: - จำแนกคำขอเป็นชุดหมวดหมู่เล็กๆ - แยกฟิลด์เป็น schema JSON ที่ตายตัว - จัดรูปแบบข้อความใหม่ - สร้างสรุปสั้นๆ - ลบระเบียนที่ซ้ำกัน - ตรวจสอบว่ามีฟิลด์ที่จำเป็นหรือไม่ เก็บโมเดลที่แข็งแกร่งกว่าไว้สำหรับการวางแผนที่ไม่ชัดเจน การใช้เหตุผลที่ซับซ้อน การเปลี่ยนแปลงโค้ดที่สำคัญ หรือการตรวจสอบครั้งสุดท้าย คุณไม่จำเป็นต้องมีเราเตอร์อัตโนมัติขั้นสูงเพื่อเริ่มต้น ย้ายขั้นตอนง่ายๆ หนึ่งขั้นตอนไปยังโมเดลที่มีต้นทุนต่ำกว่า เปรียบเทียบผลลัพธ์ และเก็บการเปลี่ยนแปลงไว้เฉพาะเมื่อยังคงผ่านการตรวจสอบเดียวกัน ด้วยอินเทอร์เฟซแบบรวม การสลับโมเดลอาจเป็นการเปลี่ยนแปลงการกำหนดค่าแทนที่จะเป็นการรวมระบบใหม่ บทความเกี่ยวกับการใช้ [หนึ่ง API gateway สำหรับ coding agents ทั้งหมด](https://ask.atlascloud.ai/one-api-gateway-every-coding-agent) แสดงให้เห็นว่าทำไมสิ่งนี้จึงมีประโยชน์เมื่อเครื่องมือหรือ Agent หลายตัวต้องการเข้าถึงแค็ตตาล็อกโมเดลเดียวกัน ## วิธีตรวจสอบว่าการเปลี่ยนแปลงได้ผลหรือไม่ เลือกงานจริง 10 ถึง 20 งานที่ Agent ของคุณทำอยู่แล้ว รันก่อนและหลังการเปลี่ยนแปลงแต่ละครั้ง และบันทึก: | เมตริก | สิ่งที่ต้องดู | | --- | --- | | จำนวน input tokens ทั้งหมด | บริบทที่สั้นลงและการกรองเครื่องมือช่วยลดหรือไม่? | | จำนวน cached input tokens | prompt ที่ซ้ำกัน hit แคชจริงหรือไม่? | | จำนวน output tokens | Agent สร้างคำอธิบายที่ไม่จำเป็นหรือไม่? | | จำนวนการเรียกโมเดล | ขีดจำกัดลูปช่วยลดการเรียกซ้ำหรือไม่? | | จำนวนการเรียกเครื่องมือ | การเรียกที่เหมือนกันหรือไม่จำเป็นหายไปหรือไม่? | | จำนวนงานที่เสร็จสมบูรณ์ | Agent ยังทำงานเสร็จถูกต้องหรือไม่? | | ต้นทุนรวมของงาน | งานทั้งหมดถูกลงหรือไม่? | วัดทั้งงาน ไม่ใช่คำขอ API เพียงครั้งเดียว คำขอที่ถูกกว่าไม่ใช่การประหยัดหาก Agent ต้องลองซ้ำหลายครั้ง หรือมีคนต้องซ่อมแซมเอาต์พุต หากคุณต้องการพื้นฐานที่กว้างขึ้น ให้ใช้คำแนะนำในการ [ประมาณความสามารถในการอนุมาน AI เวลาแฝง และต้นทุน](https://ask.atlascloud.ai/estimate-ai-inference-capacity-latency-cost) ## เริ่มต้นด้วยการเปลี่ยนแปลงที่ง่ายที่สุดสามอย่าง หากคุณต้องการจุดเริ่มต้นที่มีความเสี่ยงต่ำ ให้ทำสามสิ่งนี้ก่อน: 1. ทำให้คำแนะนำระบบและคำจำกัดความของเครื่องมือคงที่และอยู่ที่จุดเริ่มต้นของ prompt 2. สรุปประวัติการสนทนาเก่าและตัดแต่งผลลัพธ์ของเครื่องมือขนาดใหญ่ 3. ตั้งค่าขีดจำกัดสำหรับการเรียกซ้ำและจำนวนขั้นตอนสูงสุด จากนั้นทดสอบโมเดลที่รองรับการแคชและโมเดลที่ถูกกว่าสำหรับขั้นตอนง่ายๆ หนึ่งขั้นตอน แค็ตตาล็อกโมเดลแบบรวมของ Atlas Cloud ทำให้การเปรียบเทียบเหล่านั้นง่ายขึ้น แต่ตัวเลือกที่ดีที่สุดยังคงขึ้นอยู่กับ prompt และงานจริงของคุณ การปรับต้นทุนที่ดีที่สุดมักไม่ใช่การเปลี่ยนแปลงครั้งใหญ่เพียงครั้งเดียว แต่เป็นการลบงานที่ซ้ำซ้อนจำนวนเล็กน้อยออกจากทุกขั้นตอนในขณะที่ยังคงผลลัพธ์ที่ถูกต้อง ## คำถามที่พบบ่อย ### การใช้ session ID เดียวกันจะลดต้นทุน AI Agent เสมอหรือไม่? ไม่ มันจะช่วยได้ก็ต่อเมื่อผู้ให้บริการใช้ฟิลด์นั้นสำหรับการกำหนดเส้นทาง สถานะ หรือความสัมพันธ์ของแคช ปรึกษาเอกสารของผู้ให้บริการและยืนยันการใช้งานแคชในการตอบสนองหรือข้อมูลการเรียกเก็บเงิน คำนำหน้า prompt ที่คงที่ยังคงมีความสำคัญ ### ควรเลือกโมเดลที่มี input token ถูกที่สุดเสมอหรือไม่? ไม่ เปรียบเทียบราคา cached-input ราคา output อัตราความสำเร็จ และจำนวนครั้งที่ลองซ้ำ โมเดลที่แพงกว่าเล็กน้อยอาจมีต้นทุนต่ำกว่าต่องานที่เสร็จสมบูรณ์หากทำงานได้อย่างน่าเชื่อถือ ### Agent ควรเก็บประวัติการสนทนาไว้เท่าใด? เก็บข้อความล่าสุดที่จำเป็นสำหรับขั้นตอนปัจจุบัน และสรุปเนื้อหาเก่าเป็นข้อเท็จจริง การตัดสินใจ ข้อจำกัด และงานที่ค้างอยู่ ความยาวที่เหมาะสมขึ้นอยู่กับงาน แต่ประวัติที่สมบูรณ์ไม่จำกัดนั้นไม่ค่อยจำเป็น ### การบีบอัดบริบทสามารถลดคุณภาพของคำตอบได้หรือไม่? ได้ หากมันลบข้อกำหนดหรือหลักฐานที่สำคัญ รักษาชื่อ ตัวระบุ การตัดสินใจ ข้อผิดพลาด สิทธิ์ และงานที่ยังไม่เสร็จ ทดสอบบริบทที่บีบอัดกับตัวอย่างจริงก่อนใช้ในวงกว้าง ### จะรู้ได้อย่างไรว่า prompt caching ทำงานอยู่? ตรวจสอบการตอบสนองของ API และข้อมูลการเรียกเก็บเงินสำหรับการใช้งาน cached-token หรือค่าใช้จ่าย cached-input ที่ต่ำกว่า ชื่อฟิลด์แตกต่างกันไปตามผู้ให้บริการ รันคำขอซ้ำๆ ด้วยคำนำหน้ายาวที่เหมือนกัน และเปรียบเทียบกับคำขอที่มีคำนำหน้าส่วนต้นเปลี่ยนแปลง ## FAQ ### การใช้ session ID เดียวกันช่วยลดต้นทุนของ AI agent เสมอไปหรือไม่ ไม่ จะช่วยได้ก็ต่อเมื่อผู้ให้บริการใช้ฟิลด์นั้นสำหรับการกำหนดเส้นทาง สถานะ หรือความสัมพันธ์ของแคช ตรวจสอบเอกสารของผู้ให้บริการและยืนยันการใช้งานแคชในข้อมูลการตอบกลับหรือการเรียกเก็บเงิน ### ฉันควรเลือกโมเดลที่มีอินพุตโทเคนถูกที่สุดเสมอหรือไม่ ไม่. เปรียบเทียบราคา input ที่แคช ราคา output อัตราความสำเร็จ และการลองใหม่ โมเดลที่มีความสามารถมากกว่าสามารถมีต้นทุนต่องานที่เสร็จสมบูรณ์น้อยกว่า หากหลีกเลี่ยงความล้มเหลวและการทำงานซ้ำ ### เอเยนต์ควรเก็บประวัติการสนทนาไว้เท่าไหร่? เก็บข้อความล่าสุดที่จำเป็นสำหรับขั้นตอนปัจจุบัน และสรุปเนื้อหาเก่าเป็นข้อเท็จจริง การตัดสินใจ ข้อจำกัด และงานที่เปิดค้าง ประวัติเต็มแบบไม่จำกัดนั้นไม่ค่อยจำเป็น ### การบีบอัดบริบทสามารถลดคุณภาพของคำตอบได้หรือไม่? ใช่ ถ้ามันลบข้อกำหนดหรือหลักฐานที่สำคัญ รักษาตัวระบุ การตัดสินใจ ข้อผิดพลาด สิทธิ์ และงานที่ยังไม่ได้รับการแก้ไข จากนั้นทดสอบบริบทที่ถูกบีบอัดกับตัวอย่างจริง ### ฉันจะรู้ได้อย่างไรว่าการแคชพรอมต์ทำงานอยู่ ตรวจสอบการตอบกลับของ API และข้อมูลการเรียกเก็บเงินสำหรับการใช้งานโทเค็นที่ถูกแคชหรือค่าใช้จ่ายอินพุตที่ถูกแคชที่ต่ำกว่า ทำการร้องขอซ้ำๆ ด้วยคำนำหน้ายาวที่เหมือนกันและเปรียบเทียบผลลัพธ์กับคำนำหน้าที่เปลี่ยนไป