เวลา coding agent แก้บั๊กหนึ่งงาน มักวนอยู่กับลูปเดิม: สำรวจโครงสร้างโปรเจกต์, apply patch, build, รัน test และรัน lint รวมแล้วห้า tool call และห้า LLM turn ทุก turn ต้องส่ง context ทั้งกองกลับเข้าโมเดลอีกครั้ง token ส่วนใหญ่จึงไม่ได้หมดไปกับโค้ดที่ agent เขียน แต่หมดไปกับการวนไปมาระหว่างแต่ละขั้น

Tura เป็น agent runtime harness แบบ open source ที่เข้ามาลด overhead ตรงนี้ แทนที่จะแจก tool ย่อยเป็นสิบตัวให้โมเดลเรียกทีละอัน Tura เปิด macro tool ชื่อ command_run ให้ agent วางคำสั่งทั้งชุดตามลำดับแล้วส่งมาในคำขอเดียว ห้า turn ที่เคยใช้รอผลทีละขั้นจึงเหลือ turn เดียว

รวมคำสั่งห้าขั้นไว้ใน tool call เดียว

command_run รับฟิลด์ commands แบบ array แต่ละรายการใช้เลข step ระบุลำดับ และใช้ command_type ระบุว่าจะให้ทำอะไร เช่น shell_command หรือ apply_patch รายการที่ใช้เลข step เดียวกันรันพร้อมกันได้ ลูปห้ารอบข้างต้นจึงรวมเป็นก้อนเดียวได้แบบนี้

{
  "name": "command_run",
  "arguments": {
    "commands": [
      { "step": 1, "command_type": "shell_command", "command_line": "rg --files crates/runtime/src crates/tools/src" },
      { "step": 2, "command_type": "apply_patch", "command_line": "*** Begin Patch … *** End Patch" },
      { "step": 3, "command_type": "shell_command", "command_line": "cargo build -p runtime" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo test -p runtime --lib" },
      { "step": 4, "command_type": "shell_command", "command_line": "cargo clippy -p runtime --all-targets" }
    ]
  }
}

agent ส่งก้อนนี้ครั้งเดียว จากนั้น harness จะรันคำสั่งตามลำดับ แล้วรวบรวมผลส่งกลับให้โมเดลอ่านทีเดียว สิ่งที่ลดลงคือ overhead ของบทสนทนา ส่วนคำสั่งที่ลงมือรันจริงยังอยู่ครบทุกบรรทัดเหมือนเดิม

จัด context ตามสถานะงาน ไม่รอให้ session โตแล้วค่อยตัด

agent framework แบบเดิมจัดการ context อีกทางหนึ่ง โดยปล่อยให้ session เดียวทำงานต่อเนื่องไปจนกว่าผู้ใช้จะเปิด session ใหม่ ระหว่างนั้นระบบจะโหลดไฟล์ skill แบบ Markdown ก้อนใหญ่เข้ามาเก็บไว้ใน context จนกว่าจะ reset หรือถึงรอบ compaction เมื่อ compact แล้วจะเหลือเพียงบทสรุปย่อ ส่วนรายละเอียดว่าเคยรันอะไรและพังตรงไหนก็เลือนหายไปด้วย

Tura มอง context เป็นส่วนหนึ่งของ state machine แล้วผูก runtime prompt ที่โหลดตอนรันเข้ากับ task_status ที่ประกาศไว้ชัดเจน คู่มือและคำสั่ง CLI เฉพาะงานจะเข้ามาผ่าน task tree แบบ recursive ส่วน context ที่หมดหน้าที่แล้วก็ถอดออก สลับ หรือ compact จาก CLI ได้ตรงๆ จุดต่างสำคัญคือ checkpoint ยังเก็บทั้งตำแหน่งโค้ด ทั้ง patch และ test ตลอดจนสถานะงานไว้ครบ ไม่ได้เหลือแค่ข้อความสรุปคร่าวๆ

เพราะ compact เป็นคำสั่ง CLI ผ่าน task_status.compact_context จึงวัดผลออกมาเป็นตัวเลขได้ ในชุด session ที่เผยแพร่ หลัง compact แล้ว Tura ใช้เวลาเฉลี่ย 2.6 รอบกว่าจะกลับไปรันงานต่อ ไม่ใช่เพียงเปิดอ่านไฟล์ ส่วน Codex ใช้ราว 5.4 รอบ

แต่ต้องอ่านสองตัวเลขนี้พร้อมวิธีวัด ฝั่ง Tura นับจาก event compact_context ซึ่งมีบันทึกไว้ชัดเจนในข้อมูลแต่ละรอบ ขณะที่ Codex ไม่มี event แบบเดียวกันให้ดู ตัวเลข 5.4 จึงเป็นค่าประมาณจากจุดที่ input token ลดฮวบ โดยตัดช่วงที่น่าจะเป็นการอ่านไฟล์สื่อออกไป เท่ากับว่าสองฝั่งใช้วิธีวัดคนละแบบ

ผลวัดจาก 180 session กับ 20 งานใน DeepSWE

ชุดทดสอบมี 20 งานจาก DeepSWE v1.1 แต่ละคอนฟิกรันงานละสามครั้ง รวมทั้งหมด 180 session ทุกคอนฟิกใช้โมเดล GPT-5.6 SOL ตัวเดียวกัน โดยมี Codex CLI เป็น baseline สำหรับเทียบผล

สองคอนฟิกนี้เน้นคนละเรื่อง Direct เน้นประหยัดและทำอัตราสำเร็จได้พอๆ กับ Codex CLI โดยใช้ token ไม่ถึงหนึ่งในสี่ของ baseline ส่วน Balanced ใช้ token มากกว่า Direct เพื่อดันอัตราสำเร็จขึ้นเป็น 80.0% สูงกว่า Codex CLI อยู่ 16.7 จุด และยังใช้ token น้อยกว่า baseline

อีกคำถามที่ตามมาคือ Balanced ชนะเพราะตั้ง reasoning effort สูงกว่าหรือเปล่า ผล baseline ที่ DeepSWE วัดเองบนงาน 20 ข้อชุดเดียวกันพบว่า GPT-5.6 SOL ระดับ High กับ Medium ต่างกัน 8% น้อยกว่าช่องว่าง 16.7 จุดระหว่าง Balanced กับ Codex CLI ถ้าดูละเอียดกว่าเปอร์เซ็นต์จากผล verifier ที่ตัดสินแค่ผ่านหรือไม่ผ่าน จะพบว่า Balanced ผ่านมากกว่า Codex CLI 10 ครั้งจากทั้งหมด 60 ครั้ง

ตัวเลขชุดนี้ยังใช้ตอบอะไรไม่ได้บ้าง

ข้อจำกัดที่ชัดที่สุดคือ Tura-AI ระบุไว้เองว่ายังไม่มี ablation test ที่พิสูจน์ว่า command_run เพียงตัวเดียวทำให้ turn และ token ลดลง ตัวเลขที่รายงานเป็นผลจาก harness ทั้งระบบ ซึ่งวัดทุกองค์ประกอบพร้อมกัน ยังไม่ได้แยกทดสอบทีละองค์ประกอบ

ขอบเขตอีกชั้นอยู่ที่สภาพแวดล้อมของการวัด ผลที่เผยแพร่มาจาก GPT-5.6 SOL เพียงชุดเดียว งาน 20 ข้อ และ 180 session เท่านั้น ยังไม่มีผลจาก provider อื่นอย่าง Anthropic หรือ Google รวมถึง endpoint แบบ OpenAI-compatible และโมเดลที่รันในเครื่อง ส่วน latency ของ UI การ parse session และผลข้าม OS ก็ยังค้างอยู่ในเอกสาร roadmap กับหน้ารวมช่องว่างของหลักฐาน

ดังนั้น ถ้าจะใช้ตัวเลขเหล่านี้ตัดสินใจ ต้องถือว่าตัวเลขนี้ใช้ได้เฉพาะกับคอนฟิกที่วัดมาแล้วเท่านั้น รายงานฉบับเต็มอยู่ที่ หน้า benchmark ของโปรเจกต์

ลองเอง หรือยืมแค่หลักการไปใช้

ถ้าอยากลองของจริง ติดตั้งจาก npm บน Mac หรือ Linux ได้ด้วยสองคำสั่งนี้

npm install tura-ai
tura

ถ้าใช้ Windows ให้เปลี่ยนเป็น npm install -g tura-ai แล้วสั่ง tura เหมือนกัน ก่อนเริ่มมีสองเรื่องที่ต้องรู้ เรื่องแรก Tura ไม่ได้ให้ credential ของ provider มาด้วย เมื่อเปิดครั้งแรกจึงต้องตั้ง provider และเลือกโมเดลก่อน ถึงจะส่ง prompt ได้ เรื่องที่สอง license เป็น AGPL-3.0-or-later ซึ่งมีผลหากคิดจะเอาไปต่อยอดเป็นบริการของตัวเอง

ถ้ายังไม่คิดย้าย agent ก็หยิบสองหลักการนี้ไปใช้กับของเดิมได้ทันที ข้อแรก รวบคำสั่งที่รู้ลำดับแน่นอนให้จบในคำขอเดียว แทนที่จะปล่อยให้ agent ถามกลับทีละขั้น ข้อสอง ตัด context ที่หมดหน้าที่ทันทีเมื่องานย่อยจบ แทนที่จะรอให้ session โตแล้วค่อย compact ทั้งกอง ตัวเลขของ Tura ชี้ว่าวิธีที่ harness คุยกับโมเดลทำให้การใช้ token ต่างกันได้หลายสิบเปอร์เซ็นต์ โดยไม่ต้องเปลี่ยนโมเดล

ที่มา: โปรเจกต์ Tura: Build agent that uses 80% less token and delivers better results บน GitHub