Tool: edit — แก้ไฟล์เดิมแบบตรงจุด ต้องได้รับอนุญาตจากคุณก่อนครั้งแรกของแต่ละโฟลเดอร์
edit คือ tool สำหรับแก้ไฟล์ที่มีอยู่แล้วแบบเจาะจงจุด ไม่ใช่เขียนทับทั้งไฟล์ (นั่นคือหน้าที่ของ write_file กับ overwrite=true) — และเป็น tool เดียวในระบบที่ permission gate ถูกออกแบบไว้ละเอียดที่สุด เพราะความเสี่ยงตรงและชัดเจนที่สุด: แก้เนื้อหาไฟล์ของผู้ใช้โดยที่ผู้ใช้อาจไม่รู้
Permission gate: nonce ครั้งเดียวต่อโฟลเดอร์ ต่อ session
ครั้งแรกที่ edit แตะโฟลเดอร์ระดับบนสุดใต้ workspace (เช่น workspace/my-project/) ใน session นั้น จะได้ผลลัพธ์ [permission_required] กลับมาพร้อม nonce แบบสุ่มครั้งเดียว (secrets.token_hex(4)) — ข้อความบังคับให้โมเดลถามผู้ใช้ตรงๆ ในบทสนทนา ไม่ใช่สันนิษฐานเอง จากคอมเมนต์ trust-model ในซอร์สโค้ดจริงของ tools/_edit_grants.py:
the gate is a two-call protocol: the first qualifying call against a not-yet-granted folder always fails and returns a fresh, single-use nonce, with an explicit instruction that the model must ask the user directly and only pass the nonce back once they’ve said yes THIS turn — never speculatively.
หลังผู้ใช้ตอบตกลง โมเดลเรียก edit(...) อีกครั้งพร้อม grant_phrase เท่ากับ nonce นั้นเป๊ะๆ — จากนั้นทั้งโฟลเดอร์ (ทุกไฟล์ในนั้น) จะแก้ไขได้ตลอดที่เหลือของ session โดยไม่ต้องขอซ้ำ โฟลเดอร์อื่นต้องขอแยกเป็นของตัวเอง
หน่วยของการอนุญาต ไม่ใช่ทั้ง workspace และไม่ใช่ไฟล์เดียว แต่เป็นchild โดยตรงของ workspace ที่ path นั้นตกอยู่ใต้ (สอดคล้องกับวิธีที่คนพูดถึง “โฟลเดอร์ X บน Desktop”) — ถ้า path อยู่นอก workspace ทั้งหมด หน่วยจะเป็นโฟลเดอร์ที่ไฟล์นั้นอยู่โดยตรง เพราะไม่มี anchor ระดับบนให้ไต่ขึ้นไป
nonce ไม่หมุนทุกครั้งที่ผิด — ถ้าพยายามซ้ำด้วยรหัสผิดหรือเรียกไฟล์พี่น้องในโฟลเดอร์เดียวกันก่อนได้รับอนุญาตจริง nonce เดิมยังใช้ได้ ไม่งั้น nonce ที่เพิ่งแจกไปในคำตอบก่อนหน้าจะใช้ไม่ได้ก่อนที่ผู้ใช้จะทันตอบกลับด้วยซ้ำ มีแค่การอนุญาตสำเร็จจริงเท่านั้นที่ทำให้ nonce หมดอายุ
ซื่อสัตย์กับข้อจำกัดของตัวเอง
คอมเมนต์เดียวกันยังระบุตรงๆ ว่านี่ไม่ใช่การรับประกันทางการเข้ารหัส:
This does not cryptographically prove a human approved it; it forces one extra explicit round-trip per folder and leaves an audit trail … That is the strongest guarantee achievable without a second UI surface — know this ceiling before relying on it for anything higher-stakes.
เพราะไม่มี dialog ระดับ OS และไม่มีไฟล์ให้ผู้ใช้กดยืนยันเอง ช่องทางเดียวกลับไปหาเจ้าของเครื่องจริงคือแชทเดียวกับที่ ChatGPT กำลังคุยอยู่ — gate นี้จึงเป็นfriction ที่บังคับ round-trip เพิ่มหนึ่งครั้งพร้อมทิ้ง audit trail ไว้ใน logs/agent_activity.jsonl ไม่ใช่กำแพงกันโมเดลที่ถูก jailbreak โดยเจตนา
3 โหมดแก้ไฟล์
- STRING (ค่าเริ่มต้น):
old_string→new_string—old_stringต้องเป็น substring ที่ไม่ซ้ำในไฟล์ (หรือตั้งreplace_all=true) ถ้า match มากกว่าหนึ่งจุด ใช้near_lineช่วยระบุตำแหน่งที่ต้องการ - LINE: ระบุ
line_start(1-indexed) — ถ้ามีline_end >= line_startจะแทนที่ช่วงนั้นทั้งหมด (ใส่new_stringว่างเพื่อลบช่วงนั้นทิ้ง); ถ้าไม่ใส่line_endจะแทรกnew_stringเป็นบรรทัดใหม่ต่อจากline_start - BATCH: ส่ง
edits=[{...}, ...]หลายรายการ ใช้ field ชุดเดียวกับสองโหมดข้างต้น (เลือกold_stringหรือline_startอย่างใดอย่างหนึ่งต่อรายการ) ใช้กับไฟล์เดียวเท่านั้น และเป็นatomic — hunk ไหน fail ทั้ง batch ถูกยกเลิก ไม่มีอะไรถูกเขียนเลย บรรทัดของ hunk ถัดไปคำนวณจากไฟล์หลังการแก้ของ hunk ก่อนหน้าในชุดเดียวกันแล้ว ถ้า batch ผสม line-based หลายรายการ ให้เรียงจากline_startมากไปน้อย (ล่างขึ้นบน) ไม่งั้นเลขบรรทัดของรายการที่เหลือจะเลื่อนหนีไม่ตรงจุด
นอก workspace: working copy เดียวกับ write_file
ไฟล์นอกเวิร์กสเปซไม่ถูกแก้ในตำแหน่งเดิมเลย — การแก้ครั้งแรกสร้าง working copy name.edited.ext จากต้นฉบับ แล้วการแก้ครั้งถัดไปทำงานกับ copy นั้นต่อ ผลลัพธ์รายงาน path ของ copy กลับมาเสมอ
เช็ค syntax ให้ทันทีสำหรับไฟล์ .py
หลังเขียนไฟล์ .py สำเร็จ ระบบเช็ค syntax ให้อัตโนมัติแล้วต่อท้ายผลลัพธ์ด้วย ✓ หรือ ⚠ — ถ้าพบ syntax error จะรายงานแต่ไม่ revertการแก้ที่เพิ่งทำ ไม่ต้องเสียรอบเรียก bash แยกต่างหากแค่เพื่อตรวจว่าไฟล์ python ยัง parse ผ่านอยู่ไหม
ช่องว่างที่ตั้งใจยอมรับไว้
edit และ write_file(overwrite=true) เท่านั้นที่อยู่ใต้ gate นี้ — bash/python_exec ไม่ได้ถูกครอบคลุม แม้จะเขียนไฟล์ผ่าน shell redirection ได้ก็ตาม ผู้พัฒนายอมรับ trade-off นี้ไว้ตั้งใจ (2026-08-26): เลือก friction แคบที่สุดเฉพาะสอง tool ที่เสี่ยงทับไฟล์เดิมของผู้ใช้โดยตรงมากที่สุด แทนบล็อกทุกช่องทางที่เขียนไฟล์ได้ ถือเป็นความรู้ที่ต้องรู้ก่อนใช้งาน ไม่ใช่ช่องโหว่ที่ไม่มีใครรู้ตัว
ทำไมเรื่องนี้ถึงสำคัญ
edit เป็นตัวอย่างที่ชัดที่สุดของหลักการ “ยอมรับเพดานของตัวเอง” ในระบบนี้ — แทนที่จะอ้างว่า gate นี้ปลอดภัยสมบูรณ์ ซอร์สโค้ดบอกตรงๆ ว่ามันคือ friction ที่ดีที่สุดเท่าที่ทำได้โดยไม่มี UI แยก และบอกไว้ชัดว่าอย่าเอาไปพึ่งพาสำหรับอะไรที่ความเสี่ยงสูงกว่านี้
ความคิดเห็น
กำลังโหลดความคิดเห็น...