Tool: write_file — สร้างไฟล์ใหม่แบบ atomic เท่านั้น ไม่ใช่สำหรับแก้ไฟล์เดิม
write_file สร้างหรือเขียนเนื้อหาลงไฟล์ตามตำแหน่งที่กำหนด เหมาะกับงานสร้างเอกสาร โค้ด หรือผลลัพธ์ใหม่หลังจาก agent เตรียมเนื้อหาครบแล้ว
Tool นี้คืออะไร
สร้างไฟล์ใหม่พร้อมเนื้อหาที่กำหนด — เขียนได้เฉพาะในขอบเขต workspace เท่านั้น (ผ่าน _safety.check_path) เขียนแบบ atomic (temp file แล้ว os.replace) เหมือนหลักการเดียวกับ write_file ของ AGENT LITE
จุดต่างสำคัญ: มี tool แยกสำหรับ “แก้ไฟล์เดิม” ต่างหาก
Docstring ของ tool นี้สั้นและตรงประเด็น: “Create a NEW file… For modifying existing files, use edit instead” — นี่คือความต่างสำคัญจาก AGENT LITE ที่ write_file ตัวเดียวทำทั้งสร้างใหม่และเขียนทับ (ผ่าน flag overwrite=true) ส่วน LOCAL AGENT TH แยกความรับผิดชอบออกเป็น 2 tool ชัดเจน: write_file สำหรับไฟล์ใหม่/เขียนทับทั้งไฟล์ และ edit สำหรับแก้บางส่วนของไฟล์เดิมแบบ surgical (แทนที่ข้อความเฉพาะจุด)
การแยกแบบนี้สมเหตุสมผลเมื่อโมเดลมีความสามารถแก้ไขไฟล์แบบละเอียด (find-and-replace) ได้จริง — แทนที่จะให้โมเดลอ่านไฟล์ทั้งไฟล์ แก้บางบรรทัด แล้วเขียนทับทั้งไฟล์ใหม่ (เสี่ยงพิมพ์เนื้อหาส่วนที่ไม่ได้แก้ผิดโดยไม่ตั้งใจ) edit ให้ระบุแค่ข้อความเดิมกับข้อความใหม่ ปลอดภัยกว่าสำหรับการแก้ไฟล์ที่มีอยู่แล้ว
ขอบเขตการเขียนและการเขียนแบบ atomic
ทั้งสองอย่างนี้เหมือนกับหลักการที่เห็นใน AGENT LITE: check_path เช็คว่า resolved path อยู่ใต้ workspace จริงหรือไม่ (ผ่าน realpath ทั้งสองฝั่งกัน symlink หลอกและ ../ traversal) ก่อนเขียนอะไรเลย และเขียนผ่านไฟล์ .tmp แล้ว os.replace ทีเดียว — กันไฟล์เสียหายครึ่งๆ กลางๆ ถ้า process ถูกขัดจังหวะกลางทาง
Hint ที่ต่อท้ายผลลัพธ์ — เตือนให้ตรวจสอบไฟล์ .py
รายละเอียดเล็กที่มีประโยชน์จริง: ถ้าไฟล์ที่เขียนลงท้ายด้วย .py ระบบจะแนบ hint ต่อท้ายผลลัพธ์ว่า “verify with bash: python3 <path>” — เตือนให้โมเดลตรวจสอบว่าโค้ดที่เพิ่งเขียนรันได้จริงไม่มี syntax error แทนที่จะสมมติว่าเขียนถูกแล้วจบเลย เป็นการกระตุ้นพฤติกรรมตรวจสอบตัวเองแบบเบาๆ ผ่านข้อความ ไม่ใช่การบังคับด้วยโค้ด
ทำไมเรื่องนี้ถึงสำคัญ
การแยก write_file กับ edit ออกจากกันสะท้อนหลักการออกแบบที่ต่างจาก AGENT LITE: เมื่อโมเดลมีความสามารถมากพอจะทำการแก้ไขแบบละเอียด (targeted edit) ได้อย่างน่าเชื่อถือ การมี tool เฉพาะทางสำหรับแต่ละ use case (สร้างใหม่ vs แก้บางส่วน) ปลอดภัยกว่าการรวมทุกอย่างไว้ใน tool เดียวที่ทำได้ทุกอย่างแต่เสี่ยงเข้าใจผิดว่าจะทำอะไรได้บ้างในแต่ละครั้ง
ความคิดเห็น
กำลังโหลดความคิดเห็น...