Tool: read_file — อ่านได้เกือบทุกอย่าง ข้อความ โค้ด PDF Word Excel รูปภาพ เสียง วิดีโอ
read_file เป็น tool อ่านไฟล์ตัวเดียวที่ครอบคลุมเกือบทุกประเภทไฟล์ในเครื่อง — ต่างจาก ENDEAVOR AGENT LITE ที่แยก read_file กับ read_image เป็นคนละ tool ตัวนี้รวมภาพเข้าไปในเครื่องมือเดียว
ขอบเขตการอ่าน: ทุกที่ ยกเว้น path คุ้มครอง
อ่านได้ไม่จำกัดเฉพาะ workspace เหมือน write_file/edit — เพราะการอ่านมีความเสี่ยงต่างจากการเขียน resolve_read_path() อนุญาตให้อ่านได้ทุก path ยกเว้นรายการ protected path ตายตัว (SSH/AWS/GPG key, Keychain, ที่เก็บ credential ของ browser/แอป) และตรวจ ../ path traversal ด้วย realpath เดียวกับที่ path แบบ absolute โดนตรวจ — ป้องกันการอ้อมผ่าน relative path ที่ resolve ไปยัง path ต้องห้ามในที่สุด
ไฟล์ประเภทต่างๆ ที่รองรับ
- ข้อความ/โค้ด:
line_start/line_end(1-indexed แบบเดียวกับrg -n) อ่านช่วงที่รู้ตำแหน่งแล้วโดยตรง แทนอ่านทั้งไฟล์ — ไฟล์โค้ดที่ใหญ่เกิน limit จะคืน structure map (รายชื่อ symbol + เลขบรรทัด) แทน ยกเว้นระบุ line range มาแล้ว - PDF/Word/Excel: แปลงเป็น markdown อัตโนมัติ เอกสารใหญ่ถูก sample ทั้งไฟล์ (outline + ย่อหน้า/แถวกระจายทั่วไฟล์ พร้อม marker
[... skipped N ...]) — เป็นการ sample แบบ local ล้วนๆ ไม่ใช่การเรียก LLM สรุป และเป็นพฤติกรรมปกติของไฟล์ใหญ่ ไม่ใช่บั๊ก - รูปภาพ (PNG/JPG/GIF/BMP/WebP/HEIC/TIFF): แปลงเป็น PNG แนบกลับให้ดูโดยตรง — จำกัดไม่เกิน 50MB และ 40,000,000 พิกเซล ย่อขนาดให้ด้านยาวสุดไม่เกิน 2048px ก่อนแนบเสมอ
- เสียง/วิดีโอ (m4a/mp3/wav/mp4/mov ฯลฯ): ถอดเสียงในเครื่องล้วนๆ ผ่าน Apple Speech (ภาษาไทย) — บันทึก transcript เต็มเป็นไฟล์
.mdในเวิร์กสเปซ แล้วคืนข้อความ (หรือตัวอย่างที่ sample แบบ local ถ้ายาวมาก ไม่เคยสรุปด้วย LLM) การใช้งานครั้งแรกในเครื่องต้องเปิด Siri ใน System Settings และกดยินยอมครั้งเดียว
PDF page range: อ่านหน้าที่ต้องการตรงๆ แทนการ sample
page_start/page_end (1-indexed, PDF เท่านั้น) อ่านหน้าตามที่ระบุจริง แทนการ sample/ตัดทอน — ใช้ได้ทั้ง PDF ที่ extract ข้อความได้ตรงๆ และ PDF ที่สแกนมาต้อง OCR แต่ละคำขอหยุดที่ขอบหน้าที่สะอาด เมื่อครบ 30 หน้า หรือชน output budget อย่างใดอย่างหนึ่งก่อน แล้วบอก page_start ที่ควรใช้ต่อในบรรทัด [note: ...] ท้ายผลลัพธ์ — ใช้แทนกันไม่ได้กับ line_start/line_end, search filter, หรือ doc_mode ในคำขอเดียวกัน
Search filter: กรองก่อนส่งกลับ ไม่ใช่อ่านทั้งไฟล์แล้วมาเลือกเอง
ใช้ได้กับข้อความ/โค้ด และเอกสารหลัง markdown conversion — ระบุได้ทีละแบบ: contains (substring, case-insensitive), contains_any/contains_all (รายการคำ), regex + regex_flags (i/m/s), whole_word คืนเฉพาะส่วนที่ match พร้อม context_lines โดยรอบ (default 3 บรรทัด) — สำหรับเอกสารยังมี doc_mode เลือกกรานูลาริตี้ได้: heading (เฉพาะหัวข้อ markdown), section (ทั้ง section ที่ match), row/cell (ตาราง markdown เป็นแถวหรือเป็นช่อง)
ข้อจำกัดขนาดไฟล์
ไฟล์ใหญ่เกิน READ_FILE_MAX_BYTES (default 50MB) ถูกปฏิเสธ — ให้ใช้ bash (rg -n/find/rg --files) หาตำแหน่งที่ต้องการก่อนแทน ไฟล์เสียง/วิดีโอมี limit แยกที่ใหญ่กว่า (READ_FILE_AUDIO_VIDEO_MAX_BYTES default 500MB) ข้อยกเว้นเดียวคือ PDF ที่อ่านด้วย page_start/page_end — ยกเว้น limit เพราะแตะแค่หน้าที่ขอจริงเท่านั้น ไม่โหลดทั้งไฟล์
รายละเอียดที่มาจาก backward-compat จริง
ซอร์สโค้ดมีคอมเมนต์อธิบายว่าทำไม server.py ยังเช็คนามสกุลไฟล์รูปภาพก่อนเรียก _read_file_impl โดยตรง แทนที่จะให้ tool read_image แยกทำหน้าที่นี้ทั้งหมด:
Existing ChatGPT app snapshots may not yet include the newer read_image tool. Keep image reading available through this long-lived tool schema so those clients receive the image instead of an unusable redirect.
คือ ChatGPT client บางเวอร์ชันที่ scan tool schema ไปแล้วก่อนหน้านี้อาจยังไม่รู้จัก tool ใหม่ — read_file จึงยังรับไฟล์รูปภาพได้โดยตรงเพื่อไม่ให้ client เก่าเจอทางตัน
ทำไมเรื่องนี้ถึงสำคัญ
read_file ต้องรองรับความหลากหลายของไฟล์ที่ ChatGPT อาจต้องอ่านมากกว่า tool อื่นในระบบ — ตั้งแต่โค้ดไม่กี่บรรทัดไปจนถึงวิดีโอความยาวหนึ่งชั่วโมง การ sample แบบ local-only (ไม่มี LLM เรียกซ้ำสอง), page range ที่แม่นยำ, และ limit ที่แยกตามประเภทไฟล์ ล้วนออกแบบมาให้ผลลัพธ์ ตรวจสอบได้และคาดเดาได้ แทนที่จะหวังให้โมเดลเดาว่าไฟล์นี้ “น่าจะ” มีอะไรอยู่
ความคิดเห็น
กำลังโหลดความคิดเห็น...