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
ความคิดเห็น
กำลังโหลดความคิดเห็น...