Tool: read_file — อ่านไฟล์เดี่ยวหรือขนานสูงสุด 4 ไฟล์ พร้อม filter แยกต่อไฟล์

read_file อ่านไฟล์ text/code และเอกสาร PDF/Word/Excel จาก path ที่ Agent ระบุ พร้อม line/page range, text/regex filter และ document mode ตามชนิดงาน รุ่นปัจจุบันอ่าน หลายไฟล์พร้อมกันใน tool call เดียวได้สูงสุด 4 ไฟล์ เพื่อลดจำนวนรอบ ReAct และยังคงผลลัพธ์เรียงตามลำดับ input เดิม
Parallel read: สองรูปแบบ
ถ้าหลายไฟล์ใช้เงื่อนไขเดียวกัน ส่ง path เป็น list 2–4 ไฟล์ได้โดยตรง:
read_file(path=["a.py", "b.py", "c.py"])
runtime ใช้ worker pool อ่านพร้อมกัน แต่ประกอบผลกลับตามลำดับ a → b → c และถ้าไฟล์ใดไฟล์หนึ่งอ่านล้มเหลว error จะอยู่เฉพาะ block ของไฟล์นั้น ไม่ทำให้ batch ทั้งชุดหาย
ถ้าแต่ละไฟล์ต้องอ่านคนละช่วงหรือใช้ filter คนละแบบ ให้ใช้ requests:
read_file(requests=[
{"path": "app.py", "contains": "timeout"},
{"path": "config.py", "line_start": 280, "line_end": 320},
{"path": "report.pdf", "contains": "revenue", "doc_mode": "section"}
])
แต่ละ request มี path และ filter/range ของตัวเองได้อิสระ การส่ง requests จะไม่อนุญาตให้ผสมกับ top-level path หรือ filter กลาง เพื่อกัน configuration ที่กำกวม
ผลรวมของ batch ถูก cap แบบแบ่งงบอย่างเป็นธรรม (V2_READ_FILE_BATCH_MAX_CHARS, default 20,000 chars) เพื่อไม่ให้ไฟล์ใหญ่ไฟล์เดียวกินพื้นที่ทั้งหมด ส่วนจำนวนไฟล์สูงสุดควบคุมด้วย V2_READ_FILE_BATCH_MAX_FILES ซึ่ง default คือ 4
Tool นี้ยังอ่านเอกสารเดี่ยวได้ละเอียดเหมือนเดิม
สำหรับไฟล์เดียว behavior เดิมยังอยู่ครบ: อ่าน text/code, PDF/Word/Excel, page range, line range, search filters และ query-aware sampling โดยไม่บังคับให้ใช้ batch
ไฟล์โค้ดใหญ่: คืน “structure map” ไม่ใช่ sample เนื้อหา
จุดต่างสำคัญที่สุด: ถ้าไฟล์เป็นโค้ด (.py, .js, .go ฯลฯ) และยาวเกินขีดจำกัด ระบบไม่สุ่มตัวอย่างบรรทัดเหมือนเอกสารทั่วไป แต่สกัดโครงสร้างของไฟล์ ออกมาแทน — สแกนหาบรรทัดที่ประกาศ def, class, function, const ฯลฯ แล้วคืนเป็นรายการ signature พร้อมเลขบรรทัด:
[bash.py — 697 lines, structure map only]
imports:
from __future__ import annotations
import os
symbols:
def bash(command, timeout=30) :648
def _build_sandbox_profile(workspace, extra_write_paths=()) :12
Use grep or bash to read specific sections by line number.
เหตุผลชัดเจน: สำหรับไฟล์โค้ด การเห็นภาพรวมของฟังก์ชัน/คลาสทั้งหมดพร้อมเลขบรรทัดมีประโยชน์กว่าการเห็นเนื้อหาสุ่มบางส่วน — โมเดลรู้ทันทีว่ามีอะไรอยู่ตรงไหน แล้วใช้ grep หรือ bash (sed -n) อ่านเฉพาะส่วนที่ต้องการต่อ แทนที่จะได้ code fragment สุ่มๆ ที่อาจตัดกลางฟังก์ชันจนอ่านไม่รู้เรื่อง
เอกสาร (PDF/Word/Excel): sample แบบปักหมุดโครงสร้าง + คำที่ query ถาม
สำหรับเอกสารที่ไม่ใช่โค้ด ใช้ _sample_coverage ที่ซับซ้อนกว่าการสุ่มบรรทัดธรรมดา — มีการปักหมุด (pin) เนื้อหาที่ต้องรอดจากการสุ่มเสมอ 2 ประเภท:
- โครงสร้างเอกสาร — หัวข้อ markdown (
#) และแถวหัวตาราง (บรรทัดที่อยู่เหนือ separator แบบ| --- |) เพื่อไม่ให้ตัวอย่างที่สุ่มมาเป็นข้อมูลที่ไม่มี label กำกับ - คำที่ query ถามถึง — ถ้าโมเดลส่ง
user_queryมาด้วย (เช่น “ค่าธรรมเนียมเท่าไร”) ระบบดึงคำสำคัญจาก query แล้วปักหมุดบรรทัดที่มีคำเหล่านั้นให้รอดจากการสุ่มเสมอ (จำกัดงบไว้ที่ 40% ของพื้นที่ทั้งหมด กันไม่ให้หน้าที่มีคำนั้นเยอะแย่งพื้นที่จนไม่เหลือให้ coverage ทั่วไป)
ตัวอย่างที่ยกไว้ในคอมเมนต์ตรงๆ: ค่าธรรมเนียมเปอร์เซ็นต์ที่อยู่ที่ตัวอักษรตัวที่ 25,000 ของหน้าเว็บแอปยาว 1.2 ล้านตัวอักษร รอดจากการถูกสุ่มทิ้งได้ เพราะมันตรงกับคำใน query แม้จะอยู่ลึกกลางเอกสารที่การสุ่มแบบสม่ำเสมอทั่วไปมีโอกาสข้ามไปสูงมาก
Sampling รับประกันว่าเนื้อหาไม่ถูกหยุดกลางคัน
อัลกอริทึมคำนวณสัดส่วนการเก็บ (ratio) ให้พอดีกับงบตัวอักษรที่มี รวมค่าใช้จ่ายของ marker [... skipped N lines ...] เข้าไปในการคำนวณด้วย เพื่อไม่ให้การสุ่มหยุดก่อนถึงท้ายเอกสาร — และบังคับเก็บบรรทัดแรกและบรรทัดสุดท้ายเสมอ (หัวและท้ายเอกสารมีข้อมูลสำคัญบ่อยครั้ง) พร้อม cap ความยาวต่อบรรทัดไว้ที่ 2,000 ตัวอักษร กันบรรทัดเดียวที่ยาวผิดปกติ (เช่น minified code) กินงบทั้งหมด
ไฟล์ใหญ่เกิน 50MB ปฏิเสธตรงๆ
ค่า default ปัจจุบันของ READ_FILE_MAX_BYTES คือ 50MB สำหรับไฟล์ทั่วไป ถ้าใหญ่กว่านั้นระบบปฏิเสธพร้อมแนะนำให้เจาะส่วนที่ต้องการด้วย bash/search ก่อน แทนการโหลดไฟล์ทั้งหมดเข้าหน่วยความจำ ข้อยกเว้นคือ PDF ที่ใช้ page_start/page_end ซึ่งอ่านเฉพาะหน้าที่ระบุและจึงข้าม file-size gate นี้ได้
ไม่ระบุ path มา — แนะนำไฟล์ในเวิร์กสเปซให้แทนการเดา
ถ้าโมเดลลืมส่ง path มา ระบบไม่ error เฉยๆ แต่สแกนหาไฟล์เอกสาร (PDF/Word/Excel) ที่มีอยู่ใน workspace แล้วแสดงรายชื่อให้ พร้อมข้อความชัดเจนว่า “Ask the user which file they mean — do not guess” — ป้องกันโมเดลเดา path มั่วเมื่อไม่แน่ใจ
ทำไมเรื่องนี้ถึงสำคัญ
read_file ของ TH ตอนนี้มีสองชั้นที่ช่วยลดต้นทุนของ agent loop: อ่านหลายไฟล์พร้อมกันได้เมื่อทำงานกว้าง และยัง อ่านอย่างเจาะจงเมื่อทำงานลึก ด้วย structure map, range และ query-aware filters แทนการเรียก tool ซ้ำทีละไฟล์โดยไม่จำเป็น
ความคิดเห็น
กำลังโหลดความคิดเห็น...