Tool: read_file — อ่านพร้อมกันสูงสุด 4 ไฟล์ พร้อม filter แยกต่อไฟล์

ภาพประกอบ: Tool: read_file — อ่านพร้อมกันสูงสุด 4 ไฟล์ พร้อม filter แยกต่อไฟล์

read_file ใช้อ่านเนื้อหาจาก path ที่รู้แล้ว รองรับ text/code/PDF/Word/Excel/PowerPoint และเอกสารที่ extractor ของ Lite รองรับ โดยออกแบบให้ทำงานบนเครื่อง RAM จำกัดและไม่ยัดเอกสารใหญ่ทั้งก้อนเข้า context

รุ่นปัจจุบันเพิ่ม batch read สูงสุด 4 ไฟล์ใน tool call เดียว

แบบที่ 1: หลายไฟล์ใช้ options เดียวกัน

read_file(paths=[
  "/abs/a.pdf",
  "/abs/b.docx",
  "/abs/c.xlsx",
  "/abs/d.txt"
])

ระบบอ่านแบบ bounded parallelism และรักษาลำดับผลลัพธ์ตาม input

แบบที่ 2: แต่ละไฟล์มี filter/range คนละแบบ

ใช้ requests:

read_file(requests=[
  {"path":"/abs/a.py", "contains":"sync_kb", "context_lines":4},
  {"path":"/abs/b.py", "start_line":"100", "end_line":"180"},
  {"path":"/abs/c.md", "contains":"MCP-RagDoc"}
])

แต่ละ request มี options ของตัวเอง ไม่ต้องแตกเป็นหลาย tool calls

ทำไม batch อยู่ “ใน tool” ไม่ใช่ให้ agent เรียกหลายครั้ง

โมเดล 2B มีต้นทุนในการวางแผน/เรียก tool หลายรอบสูงกว่าการให้โค้ด deterministic จัด parallel I/O ให้เอง

การรวมไฟล์ 2–4 ตัวใน call เดียวลด round trip และยังควบคุมจำนวน worker/output cap ได้จาก code แทนการปล่อย agent สร้าง concurrency เอง

Error isolation

ถ้าไฟล์หนึ่งอ่านไม่ได้ ผลของไฟล์อื่นยังควรถูกคืนตามปกติ แต่ละ entry รายงาน error ของตัวเองแทนการทำให้ batch ทั้งชุดล้ม

contains ค้นทั้งไฟล์ก่อนคืน context

contains เป็น case-insensitive substring filter และคืนบรรทัดที่ match พร้อม context_lines ตามที่กำหนด เหมาะกับ source/document ที่รู้ keyword แล้วและไม่อยากส่ง sample ที่ไม่เกี่ยวเข้าโมเดล

ใน request เดียวไม่ควรผสม contains กับ line range เพราะสองโหมดมีเจตนาต่างกัน

ไฟล์ใหญ่ยังใช้ streaming/sampling

เส้นทาง hot path ไม่ materialize เอกสารใหญ่ทั้งก้อนเพียงเพื่อคืนข้อความไม่กี่พันตัวอักษร

สำหรับ text/document ขนาดใหญ่ ระบบสแกนเพื่อหาความยาว/units/secret-shaped content แล้วอ่านซ้ำเฉพาะส่วนที่ถูกเลือกแบบ deterministic

PDF ยาวจะ sample เป็น page blocks แทนการสุ่มบรรทัด เพื่อรักษา page identity และกระจาย coverage ตั้งแต่ต้นถึงท้าย

Secret scan เกิดก่อนคืน sample

แม้ output สุดท้ายเป็นเพียง sample ระบบยังต้องตรวจ credential/token/private-key shaped content ตาม policy ก่อน ไม่ควรมีกรณีที่ “ส่วนอันตรายอยู่หน้าที่ไม่ได้ sample จึงหลุดการตรวจ”

ใช้ต่อจาก search โดยไม่ค้นซ้ำ

ถ้า rag_search หรือ local_search คืน exact path มาแล้ว ให้เรียก read_file กับ path นั้นโดยตรง ไม่ต้อง search ซ้ำอีกครั้ง

search → verified path → read_file

อ่านต่อ

ความคิดเห็น

กำลังโหลดความคิดเห็น...