01 / Executive Brief

อ่านสรุปภายใน 30 วินาที

ข่าวนี้ไม่ใช่เรื่อง “เปลี่ยนมาใช้โมเดลที่ถูกกว่าแล้วค่าใช้จ่ายลด 76 เท่า” เท่านั้น แต่เป็นเรื่องของ วิธีจัดการ Context ที่ส่งเข้าโมเดลทุกครั้งที่ Agent เรียกใช้งาน ทีม Asana พบว่า Browser Agent ของ StackAI ส่งประวัติการเปิดเว็บและภาพ Screenshot ซ้ำเป็นจำนวนมาก ขณะที่นโยบายลบภาพเก่าและตัดข้อความทำให้ Prefix ของ Prompt เปลี่ยนแทบทุก Step จน Cache ที่ควรประหยัดค่าใช้จ่ายไม่ค่อยได้ถูกใช้ซ้ำ

ทีมจึงทดลองแคชประวัติที่เพิ่มขึ้น เก็บ Context ให้นานพอ และค่อยลบ Screenshot เป็นชุด แทนการลบทีละรอบ ผลบน Model B ซึ่งเป็นโมเดลที่ใช้อยู่ในระบบเดิมลดต้นทุนโมเดลประมาณ 29 เท่า เมื่อใช้ Workflow ที่ปรับปรุงแล้วกับ GPT-6.1 Sol ตัวเลขเฉลี่ยเหลือราว $0.47 ต่อ Run จึงมีการรายงานการลดต้นทุนเทียบ Development Baseline ที่ประมาณ 76 เท่า พร้อมระยะเวลาทำงานสั้นลงประมาณ 5 เท่า [1–3]

02 / The Problem

ทำไม Browser Agent ยิ่งทำงานนาน ยิ่งจ่ายแพง

Browser Agent ไม่ได้อ่านเว็บแล้วตอบครั้งเดียวเหมือน Chatbot ปกติ งานหนึ่งอาจประกอบด้วยการเปิดหน้าเว็บ ดูภาพหน้าจอ อ่านข้อความ กดลิงก์ กรอกฟอร์ม ย้อนกลับ ตรวจข้อมูล และสรุปคำตอบ ในแต่ละ Step ระบบมักต้องส่ง System Prompt, รายการเครื่องมือ และประวัติสิ่งที่ทำก่อนหน้ากลับเข้าไปเพื่อให้โมเดลตัดสินใจว่าจะทำอะไรต่อ

ถ้าประวัติสะสมยาวขึ้นจาก 20,000 เป็น 50,000 และ 100,000 Tokens การเรียกโมเดลครั้งหลัง ๆ อาจมี Input มากกว่าครั้งแรกหลายเท่า ยิ่งแย่หากโมเดลต้องอ่านข้อมูลเดิมในราคา Input ปกติอยู่เรื่อย ๆ ค่าใช้จ่ายของทั้ง Run จึงไม่ได้เติบโตตามจำนวน Step เพียงอย่างเดียว แต่ขึ้นอยู่กับโครงสร้าง History และความสามารถในการ Reuse Cache ด้วย

ในระบบที่ Asana ตรวจพบ เดิมมีการ Cache ส่วนคำสั่งคงที่ เช่น System Prompt และ Tools แต่ไม่ได้ Cache ส่วน Browsing History ที่เพิ่มขึ้นอย่างมีประสิทธิภาพ ที่สำคัญประวัติถูกแก้ย้อนหลังเกือบทุก Step เมื่อภาพเก่าหรือข้อความเก่าถูกเอาออก การหวังให้ Cache ส่วน History กลับมาใช้ได้โดยไม่ปรับนโยบายเก็บประวัติจึงไม่เพียงพอ [1]

03 / The Mechanism

Prompt Caching คืออะไร และทำไม Cache จึงแตก

Prompt Caching คือกลไกให้ผู้ให้บริการโมเดลนำส่วนต้นของคำขอที่เหมือนเดิมกลับมาใช้ซ้ำ โดยคิดค่าอ่าน Cache ในอัตราที่ต่ำกว่า Input ปกติในเงื่อนไขที่รองรับ สิ่งสำคัญคือ ความเหมือนของ Prefix ไม่ใช่การที่คำขอสองครั้งมีเนื้อหาคล้ายกันประมาณหนึ่ง

ให้นึกถึง Prompt เป็นแถวของบล็อก เริ่มจาก Tools และ System Prompt ตามด้วยประวัติ Tool Calls, ข้อความหน้าเว็บ และ Screenshot หากคำขอใหม่มีส่วนหน้าเหมือนเดิม ระบบอาจอ่าน Prefix ที่ Cache ไว้ได้ แต่เมื่อแก้หรือลบบล็อกที่อยู่ก่อนหน้า จุดที่เปลี่ยนจะตัดการใช้ซ้ำส่วนถัดไป การลบ Screenshot เพียงภาพเดียวก็อาจทำให้ History Cache หลังจุดนั้นใช้ไม่ได้

Cache Read กับ Cache Write ไม่ใช่สิ่งเดียวกัน

การเขียน Cache อาจมีค่าใช้จ่ายสูงกว่า Input ธรรมดา ในรายงานนี้อัตราที่นำมาคำนวณคือเขียน Cache 1.25 เท่าของราคา Input, อ่าน Cache 0.10 เท่าสำหรับ Model A/B/C และ 0.05 เท่าสำหรับ GPT-6.1 Sol ดังนั้นถ้าเขียนไว้แต่ไม่มีการอ่านซ้ำก็อาจแพงขึ้นแทนที่จะถูกลง อัตราเหล่านี้เป็นอัตราของการทดลองช่วงกันยายน 2026 ไม่ใช่ราคาถาวรสำหรับทุก API [1]

การจัดตำแหน่ง Cache Marker จึงเป็นส่วนหนึ่งของ Architecture ไม่ใช่เพียงค่าที่เปิดใน Dashboard รายงานระบุว่า StackAI เพิ่ม Marker ไปยังผลลัพธ์จาก Tool ล่าสุด และต้องรักษาความตรงกันของข้อความก่อน Marker นั้น ผู้ให้บริการรายอื่นอาจมี Automatic Caching, Explicit Caching, TTL และราคาที่แตกต่างกัน จึงต้องตรวจเอกสาร API ของผู้ให้บริการที่ใช้จริงก่อนปรับระบบ

04 / Context Architecture

Asana แก้ด้วย 3 การเปลี่ยนแปลงที่ทำงานร่วมกัน

หนึ่ง — ขยาย Cache ให้ครอบคลุมประวัติที่กำลังเติบโต

เดิม Cache เก็บเพียงคำสั่งที่คงที่ แต่ Page Text และ Screenshot จาก Browser Agent เป็นส่วนใหญ่ของข้อมูลที่ส่งซ้ำ ทีมจึงย้ายขอบเขต Cache ไปยัง History ล่าสุด ไม่ปล่อยให้ประวัติทั้งหมดต้องถูกนับเป็น Input ใหม่ทุกครั้ง

สอง — ลดความถี่การเขียนทับ History

แทนที่จะลบ Screenshot เก่าทีละภาพในทุก Step ระบบยอมให้ภาพสะสม แล้วจึง Prune เป็นชุด เช่นนโยบาย 20:1 หมายถึงเมื่อถึงเงื่อนไขที่กำหนดจะลดภาพค้างเก่าให้เหลือภาพล่าสุดหนึ่งภาพ ช่วงระหว่างการ Prune ประวัติส่วนใหญ่จะถูก Append ต่อท้าย ทำให้ Cache ใช้ซ้ำได้ราว 19 Calls ก่อนช่วงตัดประวัติหนึ่งครั้ง ส่วน 20:10 เก็บภาพไว้มากกว่าเมื่อถึงรอบตัด

สาม — เพิ่มพื้นที่เก็บ History อย่างระมัดระวัง

เพิ่ม Text History Budget จาก 120,000 เป็น 480,000 characters เพื่อไม่ให้ข้อความเก่าถูกตัดออกทุกครั้งที่บริบทเริ่มแน่น Budget นี้นับข้อความและ Tool Calls แต่ไม่ได้นับ Screenshot, System Prompt และ Tool Definitions ทั้งหมด รายงานระบุว่าในงาน CAT32 ไม่มี Run ใดที่ใช้ Budget 480,000 characters จนต้องตัดข้อความ จึงทำให้ชุดใหญ่แทบไม่มีการ Trim Text เลย [1]

05 / Research Method

ทีมทดลองจริงอย่างไร: 144 Runs และ Follow-up อีก 12 Runs

ทีมใช้ Task ชื่อ CAT32 บนเว็บไซต์สาธิต books.toscrape.com ให้ Browser Agent เปิดข้อมูลหนังสือ 32 เล่ม เก็บรายการละ 6 Fields ได้แก่ ชื่อหนังสือ, URL, UPC, ราคา, สถานะว่าสินค้ามีหรือไม่ และจำนวนคงเหลือ รวม 192 Facts พร้อมตอบยอดรวมราคาและหนังสือที่ถูกหรือแพงที่สุด Reference Answer ทำแยกจากการทดลองและมีราคารวม £1,164.91 [1]

การทดลองแบ่งเป็นสอง Phase: Model A/B ระหว่างวันที่ 14–23 กันยายน 2026 ส่วน Model C/GPT-6.1 Sol วันที่ 30 กันยายน 2026 มีความแตกต่างทั้งการตั้งค่า Reasoning, Tool Choice และอายุ Cache จึงไม่ใช่การทดสอบข้ามโมเดลที่ควบคุมทุกอย่างเท่ากันทั้งหมด อีกทั้งบาง Run ชน Step Limit และมีความล้มเหลวทางเทคนิค รายงานไม่ได้ซ่อนความล้มเหลวเหล่านี้ไว้ [1]

06 / Anatomy of 76×

แกะต้นทุน $36.21 → $1.24 → $0.47 ให้เห็นว่าอะไรช่วยประหยัดจริง

ตัวเลขข่าวที่ดังที่สุดเริ่มจาก Development Baseline ของ Model B มี estimated model cost อย่างน้อย $36.21 ต่อ Run เพราะบาง Run ถูกจำกัดจำนวน Step ก่อนทำงานเสร็จ เมื่อลอง Workflow ที่ปรับปรุงบน Model B เดิม ต้นทุนเฉลี่ยของเงื่อนไขที่ดีที่สุดเหลือ $1.24 หรือประมาณ 29× จากนั้นใช้ Workflow ที่ปรับปรุงแล้วบน GPT-6.1 Sol ได้ $0.47 ต่อ Run ต่ำกว่า Model B ที่ Optimize แล้วประมาณ 2.6× [1,3]

ใน Best Condition ของงานหลัก ต้นทุนโมเดลเฉลี่ยแยกเป็น Model A $0.84, Model B $1.24, Model C $0.66 และ GPT-6.1 Sol $0.47 ต่อ Run ค่าเหล่านี้ไม่ใช่การจัดอันดับโมเดลแบบทั่วไป เพราะพฤติกรรม Agent และการตั้งค่าในแต่ละ Phase แตกต่างกัน รวมถึงเลือก Best Condition หลังเห็นผลทดลองแล้ว

ทำไม Input มากขึ้น แต่ค่ารวมกลับลดลง?

บน Model B รายงานยกตัวอย่าง Call ที่ 30 ซึ่ง Best Condition ส่ง Input มากขึ้นกว่า Baseline แต่ส่วนใหญ่กลับอ่านจาก Cache ในราคาที่ต่ำกว่า แถม Agent ยังกลับไปเปิดหน้าเดิมน้อยลงจนใช้ Calls โดยรวมลดลงด้วย ภาพรวมการประหยัดจึงเกิดจากทั้ง ต้นทุนเฉลี่ยต่อ Call และ จำนวน Calls ต่อ Run ไม่ใช่ Cache Hit เพียงตัวเดียว

เวลาทำงานของ Baseline บน Model B อยู่ที่ประมาณอย่างน้อย 22.5 นาที ขณะที่ Best Condition บน Sol ใกล้ 4 นาที จึงรายงานว่าทำงานเร็วขึ้นราว 5 เท่า แต่ข้อมูลนี้ไม่พิสูจน์ว่าการอ่าน Cache เพียงอย่างเดียวทำให้ Inference เร็วขึ้น 5 เท่า เพราะจำนวนการเปิดหน้าและการเรียก Tools ก็เปลี่ยนไปด้วย

07 / Cost Meets Reliability

Context Budget ไม่ได้ส่งผลแค่ราคา แต่เปลี่ยนโอกาสได้คำตอบ

ผลอีกส่วนที่ควรได้รับความสนใจมากกว่าพาดหัว คือการเพิ่ม History Budget เปลี่ยนพฤติกรรม Agent อย่างชัดเจน ที่ Budget 120,000 characters, GPT-6.1 Sol ส่งคำตอบได้เพียง 3 จาก 18 Runs ขณะที่ Model C ส่งคำตอบไม่ได้เลย 0 จาก 18 แต่เมื่อเป็น 480,000 characters ทั้งสองโมเดลส่งคำตอบได้ 18 จาก 18 Runs และตอบยอดรวมราคาถูกต้องทั้งหมด [1]

เหตุผลเชิงกลไกคือการตัด Text History อย่างถี่ทำให้ความรู้ที่เคยอ่านหายจาก Context ถึงแม้ Agent จะเคยเปิดครบ 192 Facts ไปแล้วก็ตาม หากข้อมูลที่ต้องใช้ตอบอยู่ในข้อความที่ถูกตัดออก Agent อาจกลับไปอ่านซ้ำหรือไปต่อไม่ไหว ในรายงาน 480k ทำให้ไม่มีการ Trim Text จึงช่วยให้ Agent เก็บหลักฐานไว้ถึงตอนตอบได้มากขึ้น

08 / Counterintuitive Result

ถ้าอย่างนั้นยังจำเป็นต้อง Prune History หรือไม่?

ผลทดลองเพิ่มเติมน่าสนใจมาก ทีมทดสอบ No-pruning โดยปล่อย Screenshot ทั้งหมดค้างไว้ในประวัติ และไม่ได้แก้ History เก่าเลย พบว่าในงาน CAT32 นี้ Cost per Call ต่ำกว่า Best Condition แบบ Batch Pruning ประมาณ 1.2× บน Model B และ Sol และต่ำกว่าบน Model C ราว 5% ผลดังกล่าวเกิดในชุด Follow-up 12 Runs ที่จัดทำหลังชุดหลัก [1,2]

ทำไมจึงเป็นไปได้? การ Prune แม้ทำเป็น Batch ก็ยังเป็นการเขียนทับส่วนเก่าของ Prompt หนึ่งครั้ง ซึ่งอาจต้องจ่าย Cache Write ใหม่จำนวนมาก หากงานจบก่อน Context เต็ม การไม่ Prune เลยอาจประหยัดกว่า ทั้งนี้การเก็บภาพทั้งหมดมีต้นทุนหน่วยความจำและข้อจำกัด Context ของโมเดล ซึ่งต่างกันไปตามงาน

บทเรียนจึงไม่ใช่ “ต้องตั้งค่า 20:1 ทุกที่” แต่ควรทดลองหลาย Policy ตามอายุงาน จำนวนภาพ ขนาด Context ความถี่ของ Tool Call และราคา Cache Read/Write ในงานที่ยาวกว่าหรือโมเดล Context แคบกว่า Batch Pruning หรือ Compaction อาจสำคัญกว่า

09 / AI Engineering Workflow

เบื้องหลังอีกชั้น: ให้ AI Coding Agent วิจัยระบบ Agent

Frank Hidalgo ซึ่งเป็น CTO ของ StackAI ในเครือ Asana มอบหมายให้ GPT-6 Astra ที่ทำงานใน Codex อ่าน Codebase, ตรวจเส้นทาง Request, เพิ่มการวัด Usage, สร้าง Harness สำหรับรันเงื่อนไขทดลองหลายแบบ และวิเคราะห์ Trace ที่ได้ เมื่อเครื่องมือเดิมไม่เหมาะกับ Controlled Experiment Agent ก็ช่วย Refactor โครงสร้างให้ทดลองหลาย Workflow ควบคู่กันโดยใช้ค่าตั้งค่าคนละชุด

ทุก Run มีการเก็บ Request, Provider Usage, Browser Actions และเหตุการณ์ Eviction ไว้ใน Command เพื่อให้ตรวจย้อนหลังได้ ทีมนำข้อค้นพบมาสร้าง Tickets และ Pull Requests ผ่านการ Review ก่อนส่งเข้า StackAI จริง มีทั้งการจับ Configuration Mismatch และ Evidence Capture Failure ระหว่างทาง ไม่ใช่ปล่อยให้ AI ทดสอบแล้วเชื่อผลโดยอัตโนมัติ

Hidalgo ประเมินว่าถ้าลงมือค้นหาและทดลองแบบนี้ด้วยตัวเองอาจใช้เวลาหนึ่งถึงสองเดือน แต่งานในรอบนี้ใช้ประมาณหนึ่งสัปดาห์ จุดนี้แสดงความสำคัญของระบบเก็บหลักฐาน: หาก Trace และ Receipt ไม่ครบ Agent ที่มาวิเคราะห์ภายหลังก็ไม่สามารถย้อนพิสูจน์ได้ว่า Cost ลดจริงจากสาเหตุใด

สำหรับการพัฒนาเว็บไซต์ที่ใช้ AI ช่วยสร้างบทความ แนวคิด Human → Research Agent → Evidence → Reviewer → Draft/PR สามารถนำมาใช้ได้เช่นกัน ดูเพิ่มเติมในบทความ Hybrid Mind เรื่อง อนาคตการสร้างบทความด้วย AI Agent โดยต้องคงขั้นตอนตรวจข้อเท็จจริงและอนุมัติจากมนุษย์

10 / Engineering Checklist

นักพัฒนา Agent ควรนำบทเรียนนี้ไปใช้อย่างไร

ก่อนจะลองเปลี่ยนเป็นโมเดลที่ถูกกว่า ให้เปิด Trace ของ Workflow ที่ใช้เงินสูงที่สุด แล้วถามว่า Model Call แต่ละครั้งส่งอะไรบ้าง ส่วน Tools/System เหมือนเดิมหรือไม่ History เก่าถูกแก้ตอนไหน มีภาพเก่าถูกลบก่อน Call ทุกครั้งหรือเปล่า และ Provider Receipt บอกว่ามี Cache Read จริงเท่าไร การตอบคำถามเหล่านี้สำคัญกว่าการดู Context Window สูงสุดบนหน้าขาย API

ขั้นตอนตรวจ Agent ก่อนเสียเงินเปลี่ยนโมเดล

1. เก็บ Baseline: บันทึก Cost/Run, จำนวน Calls, Latency และ Success Rate โดยใช้ Task เดิม
2. ตรวจ Prompt Prefix: ระบุ System, Tools, Browser History และส่วนที่เปลี่ยนระหว่าง Calls
3. อ่าน Provider Usage: แยก Uncached Input, Cache Read, Cache Write และ Output; อย่าสรุปจาก Tokens รวม
4. เปลี่ยนทีละ Policy: ทดลอง Cache Growing History, Append-only, Batch Pruning หรือ No Pruning โดยคงโมเดลและ Task เดิม
5. วัดความน่าเชื่อถือ: ตรวจ Seen, Kept, Answered, Correct และกรณี Agent ต้องย้อนอ่านหน้าเดิม
6. ตั้งเพดานและเกณฑ์รับงาน: คุม Steps, Tokens, Cost และ Timeout ก่อนนำ Workflow ที่ชนะไปทดสอบข้ามโมเดล

แนวทางที่สมเหตุสมผลคือสร้าง Baseline ก่อน จากนั้นเปลี่ยนทีละตัวแปร เช่น เปิด Cache History โดยไม่เปลี่ยน Pruning, เพิ่ม Budget โดยไม่เปลี่ยนโมเดล และทดลอง Batch Pruning หลาย Threshold หากผลดีขึ้นค่อยทำการทดลองข้ามโมเดลอีกครั้ง เพราะการเปลี่ยนหลายตัวพร้อมกันทำให้ระบุสาเหตุได้ยาก

ในกรณี AI Newsroom เช่น Hybrid Mind กระบวนการค้นข่าวหลายเว็บและอ่านข้อความอาจเป็นงานที่นำแนวคิดนี้ไปทดลองได้ แต่ควรวัด Fact Retention, การอ้างอิงแหล่งข่าว และความถูกต้องของการสรุปควบคู่กัน ไม่ควรบีบ Context จนข้อเท็จจริงหรือหลักฐานอ้างอิงหายไป และไม่ควรนำผลวิจัย Asana ไปอ้างเป็นผลประหยัดจริงของระบบเราโดยยังไม่ Benchmark

ประเด็นเรื่อง Prompt Caching ต่างจาก KV Cache ที่ใช้เพิ่มความเร็วการประมวลผลภายใน Inference ซึ่งอธิบายเพิ่มเติมในบทความ Hybrid Mind LLM Inference Engineering และต่างจากความจำเชิงความหมายระยะยาวที่วิเคราะห์ในบทความ ResonanceDB / AI Memory

11 / Cost Model

แบบจำลองต้นทุน: ทำไม Cache Hit 89% ไม่ได้แปลว่าค่าใช้จ่ายทั้ง Run ลด 89%

หากแยก Token ของแต่ละ Call เป็น U = Uncached Input, W = Cache Write, R = Cache Read และ O = Output สูตรที่รายงานใช้คือ Estimated Model Cost = (U × ราคา Input + W × ราคา Write + R × ราคา Read + O × ราคา Output) ÷ 1,000,000 แล้วรวมทุก Call ในหนึ่ง Run [1]

ตัวอย่างสมมติแบบง่าย: หาก Input มี Cache Read 89% และทุก Cached Token อ่านในราคา 5% ของ Uncached Input ขณะที่ส่วนที่เหลือจ่ายราคา Input ปกติ และไม่คิด Cache Write จะได้ต้นทุน ส่วน Input ประมาณ 11% + (89% × 5%) = 15.45% ของการจ่าย Input ทั้งหมดแบบไม่ Cache หรือลดส่วน Input ประมาณ 84.55% เท่านั้น

แต่ต้นทุน ทั้ง Run ต้องรวมการเขียน Cache, Output Tokens, จำนวน Calls, Step ที่ล้มเหลว และโครงสร้าง Pricing ส่วนอื่นด้วย อีกทั้งสูตรนี้ไม่ได้คำนวณ Sandbox, Browser Execution หรือ Infrastructure ตามรายงาน Asana จึงห้ามนำ 84.55% ไปแทนข้อเท็จจริงการลดค่าใช้จ่ายทั้งหมด

12 / Interpretation

ข้อจำกัด: งานศึกษานี้บอกอะไร และยังบอกอะไรไม่ได้

รายงาน Asana เป็นกรณีศึกษาทางวิศวกรรมที่มี Raw Run Ledger, Provider Usage และคำอธิบายวิธีทดสอบจำนวนมาก จึงมีประโยชน์สูงในการเรียนรู้กลไก แต่ยังไม่ใช่การทดสอบ Benchmark อิสระที่ครอบคลุม Agent ทุกแบบ งานทั้งหมดใช้ Browser Agent Design เดียว และ Task เดียวคืออ่านข้อมูลหนังสือ 32 รายการ โมเดลสี่รุ่นมาจากสองผู้ให้บริการ และแต่ละ Condition มีเพียง 3 Runs เป็นหลัก [1]

นอกจากนี้ Baseline บางรอบติด Step Limit ก่อนทำงานเสร็จ จึงทำให้ตัวเลขต้นทุน Baseline เป็นเพียงขอบล่าง ไม่ใช่ค่าเฉลี่ยของงานที่สำเร็จทั้งหมด Phase 1 และ Phase 2 ใช้การตั้งค่าต่างกัน และการเลือก Best Condition ตามต้นทุนเฉลี่ยหลังเห็นผลอาจเกิด Selection Bias ตัวเลข 76× จึงควรอ่านเป็นผลที่รายงานสำหรับ Workflow/การตั้งค่านี้ ไม่ใช่ตัวคูณที่นำไปตั้งเป้าสำหรับทุกโครงการ

ส่วนเรื่องความเร็ว การรันพร้อมกันบนเครื่องและทรัพยากร Provider อาจกระทบเวลา และการลดจำนวน Calls ช่วยลดระยะเวลาได้โดยไม่จำเป็นต้องเกิดจาก Cache อย่างเดียว ดังนั้นบทความนี้แยกข้อค้นพบที่ทีมวัดจริงออกจากคำอธิบายเชิงกลไกและข้อเสนอประยุกต์ใช้ของ Hybrid Mind เสมอ

สุดท้าย การเพิ่ม History Budget ไม่ใช่การอนุญาตให้ Agent ใช้ Token ไม่จำกัด รายงานเองระบุว่าหาก Agent วนลูปและ Context โตมาก ค่าใช้จ่ายอาจพุ่งทันทีเมื่อ Cache แตก ต้องใช้เพดาน Step, Tokens, Cost และ Timeout ควบคู่กับการจัดการ Context

FAQ / Sources

คำถามที่พบบ่อยและแหล่งข้อมูล

Asana ลดต้นทุน AI Agent 76 เท่าจริงหรือ?

รายงานการทดลองระบุการลด estimated model cost เทียบ Development Baseline ประมาณ 76 เท่าใน Task ที่กำหนด ยังไม่ใช่หลักฐานว่าค่าใช้จ่ายรวมของ Asana ใน Production ลดลงเท่ากัน

ต้องใช้ GPT-6.1 Sol จึงจะประหยัดได้หรือไม่?

ไม่จำเป็น เพราะ Model B เดิมก็ลดค่าใช้จ่ายประมาณ 29 เท่าเมื่อแก้ Workflow ขณะที่ผลข้ามโมเดลขึ้นอยู่กับราคา API และการตั้งค่าเฉพาะช่วงเวลาทดลอง

Append-only History คืออะไร?

คือการเพิ่มข้อมูลใหม่ท้ายประวัติแทนการแก้หรือลบข้อความก่อนหน้าในทุก Step เพื่อรักษา Prefix เดิมให้ Cache นำไปใช้ซ้ำได้ ขณะที่ยังต้องมีนโยบายจำกัดความยาวเมื่อ Task ใหญ่เกิน Context

Batch Pruning 20:1 ดีกว่า No Pruning เสมอหรือไม่?

ไม่ งาน Follow-up ของ Asana พบว่า No Pruning อาจมี Cost per Call ต่ำกว่าใน Task เดียวกัน แต่ในงานยาวหรือ Context Window เล็กอาจต้อง Prune เพื่อไม่ให้ Run ล้มเหลว

89% Cache Read หมายถึง AI เร็วขึ้น 89% หรือไม่?

ไม่ใช่ 89% คือสัดส่วน Input Tokens ที่อ่านจาก Cache ในเงื่อนไข Best ของ Sol เท่านั้น ความเร็วรวมขึ้นอยู่กับจำนวน Calls, Browser Actions, Tool Latency, Output และปัจจัยอื่นด้วย

เอาแนวคิดนี้ไปใช้กับ Hybrid Mind AI Newsroom ได้อย่างไร?

เริ่มด้วยการวัด Prompt, Token Usage, Trace และความครบของหลักฐานในการค้นข่าว จากนั้นออกแบบ A/B Benchmark ของ History Policy ในระบบทดลอง โดยยังไม่แตะ Production และต้องคงเกณฑ์ Fact Check กับ Source Citation ให้ครบ

เรียบเรียงและวิเคราะห์เชิงวิศวกรรมโดย Hybrid Mind · ตรวจแหล่งข้อมูล ณ 11 ตุลาคม 2026 · ตัวเลข Benchmark เป็นของ Asana/StackAI ไม่ใช่การทดสอบต้นทุน API ของ Hybrid Mind