กลับไปที่บล็อก

AI สำหรับผู้เริ่มต้นคู่มือ

เอเจนต์ต้องใช้โมเดลในทุกขั้นตอนไหม? ใส่ขั้นตอนตายตัวลงในโค้ด

ทำไมผลลัพธ์เครื่องมือทุกครั้งจึงกระตุ้นการเรียกโมเดลอีกครั้ง ขั้นตอนไหนของเอเจนต์เป็นโค้ดธรรมดาได้ และลูป 3 ขั้นตอนมีค่าใช้จ่ายเท่าไรเมื่อมีและไม่มีการเรียกเพิ่ม

โดย CheapTokens Teamเผยแพร่เมื่อ ใช้เวลาอ่าน 7 นาที

หน้าปก: ลูปเอเจนต์สั้น ๆ ที่บิลด์ผ่านและขั้นตอนถัดไปเป็นกฎ ไม่ใช่การเรียกโมเดล
ในหน้านี้
  1. ทำไมผลลัพธ์เครื่องมือหนึ่งครั้งจึงหมายถึงการเรียกโมเดลอีกครั้ง
  2. ขั้นตอนไหนต้องตัดสินใจ และขั้นตอนไหนตายตัว
  3. ลูป 3 ขั้นตอน มีและไม่มีการเรียกเพิ่ม
  4. ผู้เขียน HarnessMM รายงานอะไร
  5. ตรวจเอเจนต์ของคุณเองในสิบนาที

เอเจนต์ของคุณรันไปสิบนาที แล้วบิลก็แพ้งานเสียอีก บ่อยครั้งเหตุผลมันน่าเบื่อมาก: หลังผลลัพธ์ของเครื่องมือทุกครั้ง harness จะเรียกโมเดลอีกครั้ง แม้ขั้นตอนถัดไปจะชัดเจนอยู่แล้ว

ดังนั้นไม่ เอเจนต์ไม่จำเป็นต้องใช้โมเดลในทุกขั้นตอน มันต้องใช้โมเดลในจุดที่ต้องมีอะไรบางอย่าง ถูกตัดสินใจ ขั้นตอนที่เหมือนเดิมเสมอ เช่นการรันเทสต์หลังบิลด์ที่ผ่านแล้ว สามารถเป็นกฎธรรมดาในโค้ดของคุณได้

มีเหตุผลด้านเงินที่ต้องใส่ใจ การเรียกเพิ่มแต่ละครั้งอ่าน context ทั้งหมดใหม่เป็น input tokens (บทความเรื่องแชทยาว อธิบายว่าทำไม) ดังนั้นการข้ามการเรียกหนึ่งครั้งประหยัดได้มากกว่าคำตอบสั้น ๆ ของมันเอง ถ้าลูปนี้ยังใหม่สำหรับคุณ เริ่มจาก เอเจนต์ AI ทำงานอย่างไร แล้วค่อยกลับมา

ทำไมผลลัพธ์เครื่องมือหนึ่งครั้งจึงหมายถึงการเรียกโมเดลอีกครั้ง#

โมเดลไม่เคยรันอะไรเลย มันเขียนว่า "กรุณารัน make build" harness ของคุณ (โปรแกรมที่ห่อหุ้มโมเดล) รันมัน วางผลลัพธ์ลงในบทสนทนา แล้วเรียกโมเดลอีกครั้งพร้อมทุกอย่างที่ผ่านมา นั่นคือลูปทั้งหมด โมเดลจะรู้ว่าครื่องมือคืนอะไรก็ต่อเมื่อคุณเรียกมัน

ลองนึกถึงเพื่อนร่วมงานใหม่ที่โทรหาผู้จัดการหลังทุกขั้นตอนเพื่อถามว่า "แล้วไงต่อ?" ทั้งที่เช็กลิสต์บอกว่า "หลังคอมไพล์ ให้รันเทสต์" ผู้จัดการตอบเหมือนเดิมทุกครั้ง และทุกการเรียกเสียเวลาหนึ่งนาทีในการอ่านเรื่องทั้งหมดตั้งแต่ต้น

นี่คือหน้าตาใน log ของเอเจนต์ สมมติว่างานคือ "แก้เทสต์ที่พัง":

Log ของเอเจนต์ที่มีการเรียกโมเดลสามครั้ง โดยการเรียกครั้งที่ 2 แค่ทำซ้ำกฎตายตัว
ตัวอย่าง log ของเอเจนต์: การเรียกครั้งที่ 2 คือคำตอบเดิมในทุกการรัน

การเรียกครั้งที่ 2 คือจุดที่น่าสนใจ บิลด์ผ่าน ขั้นตอนถัดไปคือเทสต์เสมอ และโมเดลใช้การอ่าน context เต็มรอบเพื่อพูดว่า "รันเทสต์" การเรียกครั้งที่ 1 และ 3 ต่างออกไป: ครั้งที่ 1 เลือกวิธีเริ่ม ครั้งที่ 3 อ่านผลเทสต์และเขียนรายงาน นั่นคืองานจริง

ขั้นตอนไหนต้องตัดสินใจ และขั้นตอนไหนตายตัว#

สามคำถามคัดแยกขั้นตอนส่วนใหญ่ได้:

  • การกระทำถัดไปถูกกำหนดโดยสัญญาณชัดเจน เช่น exit code, HTTP status หรือ "เจอ / ไม่เจอ" หรือไม่?
  • เป็นการกระทำเดิมทุกครั้งที่สัญญาณนั้นปรากฏหรือไม่?
  • การเดาผิดแก้ไขได้ถูกหรือไม่?

ตอบใช่ทั้งสามข้อ: เขียนเป็นกฎ ไม่อย่างนั้นโมเดลยังคงถือขั้นตอนนั้น

ตัวอย่างที่สอง นอกเหนือจากการเขียนโค้ด สมมติคุณรันสคริปต์ซัพพอร์ต: ลูกค้าเขียนเข้ามา สคริปต์ค้นหาคำสั่งซื้อ แล้วตอบ การค้นหาคำสั่งซื้อด้วยหมายเลขเป็นโค้ด การเติม "คำสั่งซื้อ {id} ของคุณคือ {status}" จากเทมเพลตก็เป็นโค้ดเช่นกัน การอ่าน "มันมาถึงแตก หาทำไงต่อ?" แล้วเลือกระหว่างคืนเงิน เปลี่ยนสินค้า หรือขอโทษ คือการตัดสินใจ ดังนั้นนั่นคือการเรียกโมเดลหนึ่งครั้ง ไม่ใช่สามครั้ง

จับคู่

ใครควรจัดการแต่ละขั้นตอน?

  • บิลด์เสร็จด้วย exit code 0 และขั้นตอนถัดไปคือเทสต์เสมอโค้ด: ขั้นตอนถัดไปตายตัว
  • เทสต์ล้มเหลวพร้อม stack trace; ไฟล์ไหนต้องแก้?โมเดล: การตัดสินใจใหม่
  • เจอคำสั่งซื้อด้วยหมายเลข ตอนนี้ใส่สถานะลงในเทมเพลตตอบกลับโค้ด: เติมเทมเพลต
  • ลูกค้าเขียน "มันมาถึงแตก หาทำไงต่อ?"โมเดล: อ่านข้อความอิสระ

มีตัวป้องกันหนึ่งอย่างที่ทำให้ปลอดภัย: กฎครอบคลุมเฉพาะเส้นทางปกติ บิลด์ล้มเหลวด้วย exit code 1? เทสต์แดง? เครื่องมือคืนอะไรที่กฎไม่คาดคิด? ส่งคืนการควบคุมให้โมเดล เหมือนเดิมทุกประการ คุณกำลังลบการเรียกที่มีคำตอบเดียวที่เป็นไปได้ ไม่ใช่เอาโมเดลออกจากลูป

ลูป 3 ขั้นตอน มีและไม่มีการเรียกเพิ่ม#

มาใส่ตัวเลขให้ log "แก้เทสต์ที่พัง" กัน สมมติฐานทั้งหมดเป็นของเราและเปลี่ยนเป็นของคุณได้ง่าย:

  • system prompt บวกงาน: 3,000 tokens
  • build log: 1,500 tokens; test log: 2,000 tokens
  • คำตอบที่แค่ขอเครื่องมือ: 60 tokens; รายงานสุดท้าย: 300 tokens

ทายตัวเลข

ถ้าการรันเทสต์ย้ายเข้าโค้ด ลูปจะเรียกโมเดลกี่ครั้ง?

แสดงคำตอบ

คำตอบ: 2

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

โมเดลในทุกขั้นตอน การเรียกครั้งที่ 1 อ่าน 3,000 tokens การเรียกครั้งที่ 2 อ่าน 3,000 + 60 + 1,500 = 4,560 การเรียกครั้งที่ 3 อ่าน 4,560 + 60 + 2,000 = 6,620 input รวม: 3,000 + 4,560 + 6,620 = 14,180 tokens; output: 60 + 60 + 300 = 420

รันเทสต์ในโค้ด การเรียกครั้งที่ 1 อ่าน 3,000 tokens harness รันบิลด์ แล้วรันเทสต์ตามกฎ และการเรียกครั้งที่ 2 อ่าน 3,000 + 60 + 1,500 + 2,000 = 6,560 input รวม: 3,000 + 6,560 = 9,560 tokens; output: 60 + 300 = 360

ผลต่างคือ 14,180 − 9,560 = 4,620 input tokens ประมาณหนึ่งในสามของ input บวกคำตอบเล็ก ๆ หนึ่งอัน บน DeepSeek-V4-Flash งานแบบนี้หนึ่งครั้งมีค่าใช้จ่าย $0.00025 วิธีแรก และ $0.00018 วิธีที่สอง งานหนึ่งชิ้นเป็นแค่ความคลาดเคลื่อนจากการปัดเศษ สมมติเอเจนต์ของคุณทำ 500 งานต่อวัน (14,180 × 500 = 7,090,000 input tokens, 420 × 500 = 210,000 output tokens เทียบกับ 4,780,000 และ 180,000):

500 งานต่อวัน โมเดลเดิม
  • โมเดลในทุกขั้นตอน$0.127
  • รันเทสต์ในโค้ด$0.0897

ช่องว่างเพิ่มขึ้นตาม context: ยิ่ง log ยาวที่โมเดลลากตามมาเท่าไร การข้ามการอ่านซ้ำก็ยิ่งคุ้มค่ามากขึ้นเท่านั้น นี่คือลูปเดียวกันวางเทียบกัน:

การเรียกโมเดลสามครั้งเทียบกับสองครั้งเมื่อการรันเทสต์เป็นกฎในโค้ด
งานเดียวกัน: การเรียกโมเดลตรงกลางหายไป

ในโค้ด กฎคือไม่กี่บรรทัด นี่คือ pseudo-code ชื่อ helper เป็นของคุณ:

python
result = run_tool(call)              # the model asked for: make build
messages.append(tool_message(result))

if call.name == "build" and result.exit_code == 0:
    tests = run_tool("make test")    # fixed rule, no model call
    messages.append(tool_message(tests))
# anything else (build failed, odd output) goes back to the model

reply = call_model(messages)         # the model reads everything once

ผู้เขียน HarnessMM รายงานอะไร#

แนวคิดนี้ไม่ใช่แค่ของเรา HarnessMM เป็น preprint บน arXiv (arXiv:2610.32813 ส่งเมื่อ 23 ตุลาคม 2026 ตรวจสอบเมื่อ 2 พฤศจิกายน 2026) โดย Yuhua Jiang, Chang Xu, Feifei Gao และ Li Zhao ข้อสังเกตของพวกเขา: harness ของเอเจนต์มักเรียกโมเดลอีกครั้งหลังผลตอบกลับจากเครื่องมือ แม้การเรียกก่อนหน้าจะกำหนดการกระทำถัดไปไว้แล้วก็ตาม วิธีแก้ของพวกเขา คือ guarded decision reuse จะเล่นการตัดสินใจนั้นซ้ำและถอยกลับไปใช้โมเดลเดิมเมื่อมีการตัดสินใจเชิงความหมายใหม่ปรากฏ หลักฐานไม่สนับสนุน หรือ selector ไม่เลือก if ข้างต้นคือเวอร์ชันที่เขียนด้วยมือของแนวคิดเดียวกัน ตัวป้องกันของพวกเขาตัดสินใจอย่างไรอยู่ในบทความ

ผู้เขียนรายงานผลลัพธ์เหล่านี้บน HumanEval:

  • Codex harness: 66.72k → 47.02k tokens ต่องาน (−29.54%) ความสำเร็จคงเดิมที่ 90.82%
  • DeepSeek Harness: 96.28k → 11.62k tokens ต่องาน (−87.93%) ความสำเร็จ 71.43% → 85.71%

อ่านอย่างระวัง มันเป็น benchmark เดียว harness ของผู้เขียนเอง preprint ที่ยังไม่ผ่าน peer review และหน้า arXiv ไม่ได้ระบุโค้ด คุณอาจเห็น "88%" ในบทความที่เล่าต่อ: นั่นคือตัวเลขของ DeepSeek Harness เท่านั้น ส่วน Codex อยู่ที่ประมาณ 30% มองทั้งสองเป็นทิศทาง ไม่ใช่คำสัญญาสำหรับเอเจนต์ของคุณ log ของคุณเองบอกได้มากกว่า

ตรวจเอเจนต์ของคุณเองในสิบนาที#

เปิด log ของทุกการเรียกโมเดล พร้อมตัวเลข usage จากแต่ละ response (การติดตามค่าใช้จ่าย token ของเอเจนต์ใน Python แสดงวิธีหนึ่ง) จากนั้นอ่านยี่สิบรันล่าสุดและทำเครื่องหมายแต่ละการเรียก: ตัดสินใจ หรือ ตายตัว การเรียกหนึ่งครั้งเป็นตัวเลือกเมื่อการกระทำถัดไปไม่เคยเปลี่ยนตลอดรันเหล่านั้น log ของคุณแสดงอะไร?

เลือกกรณีของคุณ

log ของคุณแสดงอะไร?

การเรียกคู่เดิมในทุกการรัน

มีกฎตายตัวซ่อนอยู่ตรงนั้น เขียนมันเป็น if บนสัญญาณชัดเจน เช่น exit code และเก็บโมเดลไว้เป็น fallback เมื่อสัญญาณเป็นอะไรที่ไม่คาดคิด

การเรียกที่แค่จัดรูปแบบใหม่หรือคัดลอกผลลัพธ์เครื่องมือ

ย้ายมันเข้าเทมเพลตในโค้ด ถ้าข้อความต้องการโมเดลจริง ๆ มันเป็นงานเล็กสำหรับโมเดลราคาถูก ไม่ใช่โมเดลใหญ่สุดของคุณ

การเรียกที่ขั้นตอนถัดไปเปลี่ยนตามเนื้อหา

เก็บโมเดลไว้ตรงนี้ นี่คือสิ่งที่มันมีไว้ และโมเดลที่ถูกกว่ามักจัดการขั้นตอน classify-and-pick ธรรมดาได้ ดู model routing: โมเดลราคาถูกก่อน

ทุกการเรียกอ่าน log ขนาดใหญ่อีกครั้ง

ตัดสิ่งที่ส่งกลับเข้าบทสนทนา: เก็บผลลัพธ์เครื่องมือออกจาก context งานเดียวกันถูกลงโดยไม่ต้องลบการเรียกใด ๆ

ถ้าคุณอยากลองบนโมเดลที่มี context ยาว CheapTokens ให้บริการ DeepSeek-V4-Flash (deepseek-ai/DeepSeek-V4-Flash-0731) สำหรับลูปเอเจนต์: ราคาเดียวทุกชั่วโมง context 380K และ output สูงสุด 32,768 tokens ต่อคำตอบ สำหรับขั้นตอนที่ยังต้องตัดสินใจมี GLM-5.3-Flash (zai-org/GLM-5.3-Flash) พร้อม context 390K ทั้งคู่ทำงานผ่าน API ที่เข้ากันได้กับ OpenAI และ Anthropic ที่ https://api.cheaptokens.dev/v1 ด้วยยอดเงินเดียวสำหรับทุกโมเดล การตั้งค่าอยู่ใน docs ราคาอยู่ที่ หน้าค่าบริการ และหน้าโมเดลคือ DeepSeek ราคาถูก