Tool: tool_loop — วน loop ด้วย Python ล้วนๆ โมเดลเรียกครั้งเดียว ไม่มีทางหลุด
tool_loop วนทำรายการในแผนทีละข้อ พร้อมส่งต่อผลลัพธ์ของแต่ละรอบให้ขั้นถัดไป จึงช่วยให้งานที่ซ้ำเป็นชุดดำเนินไปครบตามลำดับและตรวจสอบความคืบหน้าได้
Tool นี้คืออะไร
รับรายการ items (keyword, URL, file path, หรือ bash command) แล้ววน Python loop ประมวลผลทีละรายการโดยอัตโนมัติ จากการเรียก tool แค่ครั้งเดียว — มี 4 action: search_and_browse (ค้นแต่ละ keyword แล้วรวม URL มา browse), browse_summarize (fetch+summarize แต่ละ URL), read_file (อ่าน+summarize แต่ละไฟล์), bash_each (รันคำสั่งแต่ละอันผ่าน sandbox)
ปัญหาที่แก้: โมเดลหลุด loop เมื่อต้องทำซ้ำหลายรอบ
คอมเมนต์ต้นไฟล์อธิบายปัญหาตรงๆ: ถ้าปล่อยให้โมเดลเรียก tool ทีละครั้งด้วยตัวเองสำหรับแต่ละรายการ (เช่นเรียก browse_url 20 ครั้งติดกันสำหรับ 20 URL) โมเดลมีความเสี่ยงหลุด loop กลางทาง — อาจลืมว่าทำไปกี่รายการแล้ว, หยุดกลางคันโดยไม่ได้ตั้งใจ, หรือต้อง “continue”/“ต่อ” เองซึ่งไม่เสถียร โดยเฉพาะเมื่อรายการมีจำนวนมาก (สิบ, ยี่สิบ, ห้าสิบรายการ)
ทางแก้คือย้ายการวน loop จากความรับผิดชอบของโมเดลไปเป็นความรับผิดชอบของโค้ด Python ล้วนๆ — โมเดลเรียก tool_loop ครั้งเดียวพร้อมรายการทั้งหมด แล้ว for loop ธรรมดาใน Python จัดการทุก iteration เอง ไม่มีทางหลุดกลางทาง เพราะไม่ใช่การตัดสินใจของโมเดลอีกต่อไปว่าจะทำต่อหรือหยุด
SCALE GATE: ไม่ใช่ทุกงานควรใช้ tool_loop
Docstring มีกฎเลือก tool ชัดเจนก่อนเรียก tool_loop เสมอ — ถ้าเป็น browse_summarize และมี URL ไม่เกิน 8 รายการและไม่ต้องการไฟล์ผลลัพธ์ ให้ใช้ batch_browse แทน (เร็วกว่าเพราะขนานได้) — tool_loop เหมาะกับจำนวนมากกว่านั้นหรือ action อื่น (search_and_browse, read_file, bash_each) ที่ batch_browse ทำไม่ได้เลย
HARD RULE: ห้ามอ้าง path ไฟล์จากความจำ
สำหรับ action read_file มีกฎเข้มงวดฝังไว้ในตัว docstring เอง (เชื่อมโยงกับ workspace_ls ที่พูดถึงไปแล้ว): ต้องมั่นใจว่า path มาจาก tool output จริงในรอบนี้ (จาก workspace_ls() หรือ bash ที่เพิ่งเรียก) ไม่ใช่จำหรือเดามา — ถ้าไม่แน่ใจ ต้องเรียก workspace_ls() ก่อนเสมอ ป้องกันการอ่านไฟล์ผิด path ซ้ำๆ กันหลายรายการพร้อมกัน
ปรับเพดานการเรียกเว็บอัตโนมัติตามจำนวนที่ต้องการ
สำหรับ action ที่เกี่ยวกับเว็บ (browse_summarize, search_and_browse) ระบบปรับเพดานจำนวนครั้งเรียกเว็บต่อ turn ขึ้นชั่วคราวให้พอกับ max_n ที่ขอ (สูงสุด 100 ครั้ง) — เพราะเพดานปกติ 20 ครั้งต่อ turn (ที่ตั้งไว้กัน agent เดี่ยวๆ วนค้นไม่จบ) ไม่พอสำหรับงานที่ตั้งใจจะประมวลผลหลายสิบรายการจริงๆ ผ่าน tool_loop โดยตรง — ถ้า budget ที่เหลือน้อยกว่าที่ขอ ระบบลด max_n ลงให้พอดีกับที่เหลือแทนที่จะ error ทันที
เขียนผลลัพธ์ลงไฟล์ได้ในตัว ไม่ต้องเรียก write_file แยก
ถ้าระบุ output_file มา ผลลัพธ์ทั้งหมด (ชื่อ, แหล่งอ้างอิง, สรุป ของทุกรายการ) จะถูกเขียนเป็น markdown ที่มีโครงสร้างชัดเจนลง workspace โดยอัตโนมัติ — docstring เตือนตรงๆ ว่าถ้าผู้ใช้พูดคำว่า “บันทึก/เก็บ/เขียนไฟล์” ต้องใส่ output_file มาด้วย เพราะผลลัพธ์จะหายไปเมื่อ turn จบถ้าไม่เขียนลงไฟล์ไว้
ผลลัพธ์ที่คืนกลับเป็นแค่ preview — ต้องสรุปเองต่อ
Docstring เตือนไว้ชัดว่าหลัง tool คืนผล (ชื่อเรื่อง 5 อันแรก + จำนวน ok/error) agent ต้องสรุปเนื้อหาจริงให้ผู้ใช้ต่อเอง ห้าม copy-paste ข้อความสถานะดิบอย่าง “✅ เสร็จ X/Y items” มาแสดงตรงๆ — tool_loop ทำหน้าที่แค่ประมวลผลและรวบรวมข้อมูล ส่วนการสังเคราะห์คำตอบที่มีความหมายให้ผู้ใช้ยังคงเป็นหน้าที่ของโมเดล
ทำไมเรื่องนี้ถึงสำคัญ
tool_loop แสดงหลักการที่ตรงกับธีมใหญ่ของทั้งโปรเจกต์ (และของ AGENT LITE ก่อนหน้านี้ด้วย): สิ่งที่ต้องแม่นยำ 100% ควรเป็นโค้ด ไม่ใช่ฝากไว้กับความสม่ำเสมอของโมเดล — การวน loop ผ่านรายการหลายสิบรายการโดยไม่หลุดกลางทางเป็นงานที่ Python for loop ทำได้แม่นยำเสมอ ในขณะที่การให้โมเดลวนเรียก tool ทีละครั้งด้วยตัวเองมีความเสี่ยงสะสมทุกรอบที่เรียก — ย้ายความรับผิดชอบนี้ไปที่โค้ดตัดปัญหานี้ทิ้งไปทั้งหมด
ความคิดเห็น
กำลังโหลดความคิดเห็น...