Graft คืออะไร: เครื่องมือสร้างแผนผัง Codebase สำหรับ AI

แผนผัง codebase สำหรับ coding agent คืออะไร

แผนผัง codebase สำหรับ coding agent คือดัชนีแบบถาวรของ repository ที่ agent ใช้สำหรับค้นหาข้อมูล แทนที่จะต้องไล่ค้นหา (grep) ใหม่ทั้งหมดตั้งแต่ต้นในทุกเซสชัน Graft เป็นการนำแนวคิดนี้ไปใช้งานจริงรูปแบบหนึ่ง โดยจะทำการวิเคราะห์โค้ดของคุณด้วย tree-sitter จากนั้นเขียนข้อมูลลงในโฟลเดอร์ที่ประกอบด้วยโหนด markdown ที่เชื่อมโยงกันและกราฟการเชื่อมต่อรายสัญลักษณ์ พร้อมทั้งให้บริการเครื่องมือสำหรับการดึงข้อมูลผ่าน MCP (model context protocol ซึ่งเป็นอินเทอร์เฟซมาตรฐานที่ coding agent ใช้เรียกใช้งานเครื่องมือภายนอก)

Graft ไม่ใช่ proxy และไม่ใช่ gateway ไม่มีสิ่งใดคั่นกลางระหว่าง agent ของคุณกับ model API แผนผังนี้เป็นเพียงโฟลเดอร์บนดิสก์ที่ agent อ่านข้อมูล ความแตกต่างนี้เป็นตัวกำหนดว่าคุณกำลังแก้ปัญหาใดอยู่: self-hosted token gateway จะทำหน้าที่วัดปริมาณและกำหนดเส้นทางคำขอที่คุณส่งออกไปอยู่แล้ว ในขณะที่แผนผังจะช่วยลดจำนวนคำขอที่คุณจำเป็นต้องส่งลง

เทคนิคนี้มีมาก่อนเครื่องมือนี้และจะยังคงอยู่ต่อไป ให้เรียนรู้เทคนิคก่อน แล้วจึงค่อยเรียนรู้กลไกการทำงานของมัน

เหตุใด Coding Agent จึงสิ้นเปลือง Context ไปกับการค้นหาโครงสร้างซ้ำๆ

ลองสังเกตการทำงานของ Agent เมื่อเริ่มงานใน Repository ที่มันเคยเห็นมาแล้วกว่า 50 ครั้ง มันจะเริ่มจากการแสดงรายการไดเรกทอรี ใช้ grep ค้นหาสัญลักษณ์ เปิดไฟล์ 3 ไฟล์เพื่อดูว่าไฟล์ไหนนิยามฟังก์ชันนั้นไว้ แล้วเปิดไฟล์ที่ 4 เพื่อดูว่าใครเรียกใช้ฟังก์ชันดังกล่าว สิ่งเหล่านี้ไม่ใช่เนื้องานจริง แต่เป็นขั้นตอนการทำความเข้าใจสภาพแวดล้อม (Orientation) ซึ่งต้องจ่ายค่า Input Token ทุกครั้งที่เริ่มเซสชันใหม่

สาเหตุนั้นเรียบง่าย โมเดลไม่มีหน่วยความจำระหว่างเซสชัน ทุกสิ่งที่ Agent เรียนรู้เกี่ยวกับโครงสร้างโปรเจกต์ของคุณจะอยู่ใน Context Window ซึ่งจะถูกลบทิ้งเมื่อจบเซสชัน ดังนั้นการค้นหาเดิมๆ จึงถูกทำซ้ำตั้งแต่ศูนย์ด้วยต้นทุนเต็มจำนวน ใน Repository ขนาดใหญ่ ขั้นตอนการทำความเข้าใจสภาพแวดล้อมมีต้นทุนสูงกว่าการแก้ไขโค้ดจริงเสียอีก เช่น การเรียกใช้เครื่องมือ 10 ครั้งเพื่อระบุตำแหน่งโค้ด และเรียกใช้เพียง 1 ครั้งเพื่อแก้ไข การทำความเข้าใจสภาพแวดล้อมเป็นเพียงครึ่งหนึ่งของค่าใช้จ่าย ส่วนการแก้ไขคืออีกครึ่งหนึ่ง นี่คือเหตุผลว่าทำไม ทักษะในการควบคุมให้ Agent เปลี่ยนแปลงโค้ดให้น้อยที่สุดเท่าที่จำเป็น จึงควรใช้ควบคู่ไปกับการมีแผนผัง (Map) แทนที่จะต้องเลือกอย่างใดอย่างหนึ่ง

แผนผังจะช่วยตัดวงจรนี้โดยย้ายภาระการค้นหาออกจากตัวโมเดลไปไว้ที่ดิสก์แทน โดยใช้ Parser ทำการสำรวจ Repository เพียงครั้งเดียว เพื่อบันทึกว่าสัญลักษณ์ใดถูกนิยามไว้ที่ไหนและเรียกใช้ที่ใด จากนั้นจึงคอยอัปเดตบันทึกนั้นให้เป็นปัจจุบันตามการเปลี่ยนแปลงของโค้ด เมื่อ Agent ต้องการข้อมูล มันจะถามเพียงคำถามเดียวและได้รับคำตอบพร้อมระบุชื่อไฟล์และบรรทัด การสำรวจซ้ำๆ จึงเปลี่ยนเป็นการค้นหาที่มีต้นทุนต่ำ

คุณอาจกำลังใช้งานเวอร์ชันที่ด้อยกว่านี้อยู่แล้ว ไฟล์ AGENTS.md ที่ระบุข้อตกลงในการเขียนโค้ดของคุณ ช่วยป้องกันไม่ให้ Agent ต้องตีความข้อตกลงของคุณใหม่ทุกครั้ง ส่วนแผนผังที่สร้างขึ้นโดยอัตโนมัติจะช่วยป้องกันไม่ให้มันต้องตีความโครงสร้างโปรเจกต์ใหม่ ความแตกต่างอยู่ที่ผู้เขียนไฟล์นั้น คุณเป็นคนเขียนไฟล์คำแนะนำด้วยตนเองจึงทำให้ไฟล์มีขนาดเล็ก ในขณะที่ Parser เป็นผู้สร้างแผนผังจึงสามารถครอบคลุมไฟล์ได้นับหมื่นไฟล์ สำหรับรายละเอียดว่างบประมาณถูกใช้ไปอย่างไรภายในเซสชัน วิธีการที่ Claude Code จัดสรรการใช้ Context Window ได้อธิบายการคำนวณส่วนนี้ไว้แล้ว

สิ่งที่ Graft สร้างขึ้นจริง

ผลลัพธ์มี 2 ส่วน ซึ่งอยู่ภายใต้โฟลเดอร์ graft/ ที่ root ของ repository

ส่วนแรกคือ node graph ที่เขียนด้วย markdown แบบเชื่อมโยงกัน โดยหนึ่งไฟล์ต่อหนึ่ง node แต่ละ node จะประกอบด้วยบทสรุปภาษาที่เข้าใจง่าย, "หัวใจสำคัญ" (crux) ของบรรทัดตรรกะที่ดึงมาจากซอร์สโค้ด, ไฟล์ซอร์สโค้ดต้นฉบับพร้อม content hash, wikilinks ที่ระบุประเภทไปยัง node อื่นๆ (depends_on, part_of, uses, implements) และส่วนบันทึกย่อที่จะคงอยู่แม้มีการสร้างใหม่ เพื่อให้คุณสามารถบันทึกบริบทที่ตัว parser ไม่สามารถอนุมานเองได้

ส่วนที่สองคือ graft/.graph/wiring.json ซึ่งเป็น structural graph รายสัญลักษณ์ที่ tree-sitter สกัดออกมา ได้แก่ คำนิยาม (definitions), การอ้างอิง (references) และเส้นเชื่อมการเรียกใช้ (call edges) ระหว่างสัญลักษณ์เหล่านั้น

การแยกส่วนนี้มีความสำคัญเพราะมีเพียงครึ่งเดียวที่ต้องใช้โมเดล graft build เป็นการทำงานของ tree-sitter ล้วนๆ และไม่เคยเรียกใช้ LLM (large language model) จึงให้ผลลัพธ์ที่แน่นอนและไม่มีค่าใช้จ่าย ส่วน graft build --deep จะเพิ่มบทสรุปที่เป็นข้อความและหัวใจสำคัญรายสัญลักษณ์ ซึ่งส่วนนี้คือการเรียกใช้โมเดลที่มีค่าใช้จ่าย

การรองรับภาษาจะแบ่งเป็นระดับ ซึ่งระดับเหล่านี้จะบอกคุณว่าควรเชื่อถือ call graph มากน้อยเพียงใด ภาษา TypeScript, JavaScript, Python, Go และ Java จะได้รับการแก้ไขการอ้างอิงข้ามไฟล์แบบรับรู้ขอบเขต (scope-aware) ส่วนภาษา Rust, C, C++, C#, Ruby, PHP, Kotlin, Scala, Swift, Elixir, Solidity, OCaml, Zig และ Dart จะได้สัญลักษณ์พร้อมเส้นเชื่อมการเรียกใช้แบบทั่วไป ซึ่งหมายความว่าเส้นเชื่อมอาจเป็นการจับคู่ชื่อแทนที่จะเป็นการอ้างอิงที่แก้ไขแล้ว เส้นเชื่อมระดับคอมไพเลอร์สามารถเลือกเปิดใช้งานได้ด้วย --lsp และ language server เช่น rust-analyzer หรือ gopls

การติดตั้ง Graft และการล็อกเวอร์ชัน

Graft ต้องการ Node.js 20 หรือใหม่กว่า และใช้สัญญาอนุญาตแบบ MIT ณ เดือนสิงหาคม 2026 รุ่นปัจจุบันคือ 0.10.1 และรุ่นแรกที่เผยแพร่คือ 0.1.0 ซึ่งลงวันที่ในเดือนกรกฎาคม 2026 โปรดถือว่าซอฟต์แวร์นี้ยังอยู่ในช่วงเริ่มต้น

npm install -g @nanonets/graft@0.10.1
npm ls -g @nanonets/graft

npm ls -g ควรแสดงผลเป็น @nanonets/graft@0.10.1 ให้ล็อกเวอร์ชันนั้นไว้โดยเจตนา การใช้ npm install -g @nanonets/graft เปล่าๆ จะเป็นการดึงแท็ก latest ณ ขณะที่คุณรันคำสั่ง ซึ่งในโปรเจกต์ที่มีการออกรุ่นย่อยหลายครั้งต่อเดือน จะทำให้คุณได้เครื่องมือที่ต่างจากที่เพื่อนร่วมงานติดตั้งในวันจันทร์ การล็อกเวอร์ชันจะช่วยให้ CLI flags และรูปแบบ graph เหมือนกันสำหรับทุกคน คุณจึงสามารถเลือกอัปเกรดได้เมื่อพร้อม

จากนั้นเชื่อมต่อเข้ากับ repository ที่คุณเป็นเจ้าของ:

cd /path/to/your/repo
graft init --dry-run
graft init

graft init จะถามว่าต้องการเชื่อมต่อกับ coding agent ตัวใดของคุณ จากนั้นจึงสร้าง graph ขึ้นมา ให้รัน --dry-run ก่อนและอ่านรายการไฟล์ที่คำสั่งจะเข้าไปแก้ไข เนื่องจากบางไฟล์อยู่นอก repository graft init เป็นคำสั่งแบบ idempotent และจะไม่เขียนทับ config เดิมที่มีอยู่ ดังนั้นการรันซ้ำครั้งที่สองจึงปลอดภัย

ณ เดือนสิงหาคม 2026 การเชื่อมต่อรองรับ Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf และ AdaL โดย Claude Code จะได้รับการบูรณาการที่ลึกที่สุด ได้แก่ รายการ MCP server, statusline ที่แสดงขนาดและความเก่าของ graph, post-edit hooks ที่จะสร้าง graph ใหม่ และไฟล์ skill ภายใต้ .claude/ ส่วนตัวอื่นๆ จะได้รับไฟล์คำสั่งหรือกฎที่แจ้งให้ agent ทราบว่ามีเครื่องมือเหล่านี้อยู่ ดังนั้นคำว่า "รองรับ" จึงหมายถึง Graft จะเขียนการเชื่อมต่อให้ หาก agent ใดเพิกเฉยต่อไฟล์กฎของตนเอง ก็จะเพิกเฉยต่อแผนผังนี้ด้วยเช่นกัน นี่คือสาเหตุทั่วไปที่ agents เพิกเฉยต่อคำสั่งที่คุณเขียนให้ และกฎนี้ก็ใช้ได้กับกรณีนี้เช่นเดียวกับกรณีอื่นๆ

สิ่งที่ถูกเพิ่มลงใน repository ของคุณ และสิ่งที่ควรละเว้นจาก git

หลังจาก graft init ให้คาดหวังผลลัพธ์ดังนี้:

• graft/: กราฟโหนด markdown และ graft/.graph/wiring.json ถูกเพิ่มลงใน .gitignore ให้คุณโดยอัตโนมัติ
• .mcp.json: ลงทะเบียน MCP server แบบ graft เพื่อให้ Claude Code เริ่มการทำงาน
• .claude/settings.json: รวมเข้ากับไฟล์เดิม โดยเพิ่ม statusline และ post-edit hooks
• AGENTS.md, GEMINI.md, .github/copilot-instructions.md, .cursor/rules/graft.mdc, .kiro/steering/graft.md, .windsurf/rules/graft.md และ .adal/skills/graft/SKILL.md: ส่วนที่ถูกคั่นด้วย marker จะถูกต่อท้ายไฟล์ที่ตรงกับ agent ที่คุณเลือก
• ~/.codex/config.toml, ~/.codex/hooks.json และ ~/.codex/hooks/graft/graft-hooks.cjs: เป็นการตั้งค่าระดับเครื่อง จะถูกเขียนขึ้นเมื่อคุณเลือก Codex เท่านั้น graft init --no-global จะข้ามการตั้งค่าเหล่านี้ และ graft init --no-hooks จะข้ามเฉพาะ hook shim

กราฟดังกล่าวเป็นแคช เช่นเดียวกับ node_modules ห้าม commit ไฟล์นี้ลงไป มันสามารถสร้างใหม่จากโค้ดได้ในเวลาไม่กี่วินาที และมีการเปลี่ยนแปลงเกือบทุกครั้งที่มีการแก้ไข หากคุณ commit ไฟล์นี้ การแก้ไขเพียงบรรทัดเดียวจะกลายเป็น diff ขนาดหลายร้อยไฟล์ที่ไม่มีใครอยากตรวจสอบ ให้ commit เฉพาะส่วนการเชื่อมต่อระบบ เช่น AGENTS.md และ .mcp.json แทน เมื่อเพื่อนร่วมทีม clone repository ไปแล้ว พวกเขาจะรัน graft build เพื่อสร้างกราฟในเครื่องของตนเอง

ตรวจสอบว่ากฎการละเว้นไฟล์ถูกเพิ่มเรียบร้อยแล้วก่อนการ commit ครั้งแรก:

grep -n graft .gitignore
git status --short

grep ควรแสดงบรรทัดที่มี graft/ และ git status --short ไม่ควรแสดงรายการใดๆ ภายใต้ graft/ หากมีไฟล์ภายใต้ graft/ ปรากฏในผลลัพธ์ แสดงว่ารายการละเว้นไฟล์หายไปหรือถูก override ที่อื่น ให้แก้ไขก่อนทำการ commit เพราะเมื่อ git ติดตามไฟล์ใดไปแล้ว การแก้ไข .gitignore ในภายหลังจะไม่ทำให้ไฟล์นั้นหลุดจากการติดตาม

หากคุณต้องการลงทะเบียน MCP server ด้วยตนเอง หรือต้องการล็อกเวอร์ชันให้ตรงกับที่คุณติดตั้งไว้ รายการตั้งค่ามีดังนี้:

{
  "mcpServers": {
    "graft": {
      "command": "npx",
      "args": ["-y", "@nanonets/graft@0.10.1", "mcp"]
    }
  }
}

เครื่องมือดึงข้อมูลที่เอเจนต์ของคุณใช้แทน grep

Graft เปิดใช้งานเครื่องมือ 6 รายการผ่าน MCP โดย graft_find_code จะส่งคืนโหนดที่จัดลำดับความสำคัญไว้สำหรับคำอธิบายงาน พร้อมระบุไฟล์และบรรทัด graft_file_api จะส่งคืนลายเซ็น (signature) ทั้งหมดในไฟล์โดยไม่มีเนื้อหาโค้ด graft_trace_calls จะไล่ดูผู้เรียก (caller) หรือสิ่งที่ถูกเรียก (callee) ลึกลงไปหลายระดับ graft_find_all จะส่งคืนผลลัพธ์จากการค้นหาด้วย regex โดยจัดกลุ่มตามสัญลักษณ์ (symbol) graft_repo_map ช่วยให้เห็นภาพรวมของ repository ที่ไม่คุ้นเคยเป็นครั้งแรก และ graft_check_freshness จะรายงานว่ากราฟยังคงตรงกับโค้ดปัจจุบันหรือไม่

ทุกเครื่องมือมีคู่ที่เป็น CLI ซึ่งเป็นวิธีที่คุณใช้ตรวจสอบว่าเอเจนต์ได้รับข้อมูลอะไรจริง ๆ:

graft map .
graft ask "where do we validate the refresh token"
graft skeleton src/auth/session.ts
graft callers validateRefreshToken
graft callers validateRefreshToken --direction out
graft grep "refresh_token" --json

graft ask ควรพิมพ์โหนดที่จัดลำดับไว้พร้อมการอ้างอิง file:line แทนที่จะเป็นเนื้อหาไฟล์ นี่คือกลไกทั้งหมด: เอเจนต์จะได้รับตัวชี้ (pointer) และเปิดไฟล์เพียงไฟล์เดียว แทนที่จะต้องอ่านไฟล์สิบไฟล์เพื่อหาไฟล์ที่ถูกต้อง graft viz จะเปิดโปรแกรมดูข้อมูลแบบโต้ตอบบน localhost หากคุณต้องการตรวจสอบกราฟด้วยตนเอง หาก graft ask ไม่ส่งคืนข้อมูลที่เป็นประโยชน์สำหรับคำถามที่คุณสามารถตอบได้ใน 30 วินาที แสดงว่ากราฟนั้นล้าสมัยหรือภาษาที่คุณใช้ยังอยู่ในระดับทั่วไป ซึ่งแผนผังนี้ก็จะไม่ช่วยเอเจนต์ของคุณเช่นกัน

ต้นทุนอย่างหนึ่งที่มองข้ามได้ง่ายคือ นิยามของเครื่องมือทั้ง 6 รายการจะถูกแทรกเข้าไปใน system prompt ของทุกคำขอตลอดทั้งเซสชัน คุณต้องจ่ายต้นทุนนี้ไม่ว่าเอเจนต์จะใช้แผนผังหรือไม่ก็ตาม ใน repository ที่มีขนาดเล็กพอที่จะใส่ใน context ได้ ค่าใช้จ่ายคงที่นี้อาจสูงกว่าการสำรวจที่ประหยัดได้เสียอีก

เกิดอะไรขึ้นกับกราฟเมื่อโค้ดมีการเปลี่ยนแปลง

การรีเฟรชโครงสร้างมีต้นทุนต่ำและทำงานโดยอัตโนมัติ Graft จะอ่านจาก working tree ของคุณแทนที่จะอ่านจาก git ดังนั้นการแก้ไขที่คุณยังไม่ได้ commit และการแก้ไขที่คุณ staged ไว้จะถูกมองเห็นได้เท่าเทียมกัน การคิวรีจะทำการ parse เฉพาะไฟล์ที่มีสถานะ stat เปลี่ยนแปลงเท่านั้น ซึ่งเอกสารโครงการระบุว่ามี overhead ประมาณ 3 ms และการสร้างใหม่เมื่อจบขั้นตอนจะกระทบเฉพาะไฟล์ที่มีการย้ายโค้ดเท่านั้น ให้ตั้งค่า GRAFT_NO_REFRESH=1 หรือส่งแฟล็ก --no-refresh เพื่อตอบคำถามจากกราฟบนดิสก์โดยไม่ต้อง parse ใหม่ ส่งแฟล็ก --no-reuse เพื่อบังคับให้ทำการ cold re-parse ข้อมูลทั้งหมด ซึ่งเป็นสิ่งที่คุณควรทำหลังจากอัปเกรดตัว Graft เอง

ส่วนที่เขียนโดยโมเดลจะมีพฤติกรรมที่แตกต่างออกไป และเป็นส่วนที่อาจเกิดข้อผิดพลาดโดยไม่แจ้งเตือน ข้อมูลสรุป (summaries) และประเด็นสำคัญ (cruxes) จะถูกแคชไว้ แต่ละโหนดจะบันทึก content hash ของซอร์สโค้ดไว้ ดังนั้นเมื่อไฟล์ต้นฉบับมีการเปลี่ยนแปลง โหนดนั้นจะถูกทำเครื่องหมายว่าล้าสมัย (stale) แทนที่จะแสดงผลว่าเป็นข้อมูลปัจจุบัน แฟล็กดังกล่าวจะมีประโยชน์ก็ต่อเมื่อมีกระบวนการทำงานกับมัน ให้รีเฟรชด้วย graft build --deep ซึ่งจะเป็นการใช้โทเค็นของโมเดลอีกครั้ง

ทำให้สถานะความล้าสมัยมองเห็นได้ชัดเจน:

graft check .
echo $?

สถานะ exit status 0 หมายความว่ากราฟตรงกับโค้ด สถานะ exit status 1 หมายความว่าเกิดความคลาดเคลื่อน (drift) ให้รันคำสั่งนี้จาก pre-push hook หรือรันบน branch ใน CI เพื่อป้องกันไม่ให้แผนผังที่มีอายุหกเดือนมาให้คำตอบที่มั่นใจเกินไปกับโค้ดที่ถูกเขียนใหม่ในเดือนมีนาคม

อ่านตัวเลขผลการทดสอบประสิทธิภาพที่เผยแพร่อย่างละเอียด

คำกล่าวอ้างหลักของ Graft คือ "ประหยัดกว่าสูงสุด 4 เท่า และทำงานเร็วขึ้น 3 เท่า โดยมีความถูกต้องดีกว่าหรือเท่าเดิม" ตัวเลขเหล่านี้มาจากผลการทดสอบของโครงการเองที่เผยแพร่ไว้ใน README ต่อไปนี้คือผลการทดสอบทั้งสองชุดที่มีการรายงานไว้อย่างครบถ้วน

[
  {
    "label": "Controlled sweep",
    "run_count": 162,
    "token_saving_pct": 42,
    "tool_call_saving_pct": 46,
    "correctness_pct": 93,
    "baseline_correctness_pct": 93
  },
  {
    "label": "SWE-bench Verified",
    "run_count": 50,
    "token_saving_pct": 23,
    "tool_call_saving_pct": 25,
    "correctness_pct": 66,
    "baseline_correctness_pct": 54
  }
]

การทดสอบแบบควบคุม (controlled sweep) ประกอบด้วยการรัน 162 รอบบน repository สองแห่ง ซึ่งหนึ่งในนั้นคือตัว Graft เอง โดยทดสอบงานละ 3 ครั้ง รายงานระบุว่าใช้ token น้อยลง 42% และใช้ tool call น้อยลง 46% สำหรับการทดสอบบน SWE-bench Verified นั้นใช้จำนวน 50 instances โดยใช้โมเดลเดียวกันทั้งสองฝั่ง ซึ่งรายงานผลการประหยัดที่น้อยกว่า คือประหยัด token ได้ 23% และประหยัด tool call ได้ 25% ส่วนการทดสอบรอบที่สามเป็นการทำซ้ำ pull request ของ PocketBase ที่ถูก merge ไปแล้ว 5 รายการ โดยมีค่าใช้จ่าย 11.02 ดอลลาร์สหรัฐ เทียบกับ 13.91 ดอลลาร์สหรัฐของ baseline

โปรดมองข้อมูลทั้งหมดนี้ว่าเป็นผลการทดสอบจากผู้ผลิต มีสองปัจจัยที่จำกัดความน่าเชื่อถือของข้อมูล การทดสอบแบบควบคุมรวมถึง repository ของ Graft เอง ซึ่งเป็น codebase ที่ผู้พัฒนาใช้ปรับแต่งเครื่องมือ ส่วน SWE-bench Verified เป็นชุดข้อมูลสาธารณะที่รวบรวมปัญหาจากโครงการโอเพนซอร์สภาษา Python ที่มีชื่อเสียง ซึ่งชุดข้อมูลสาธารณะมักเป็นสิ่งที่เครื่องมือต่างๆ ถูกปรับแต่งให้ทำงานได้ดีโดยอัตโนมัติ ไม่ว่าผู้พัฒนาจะตั้งใจหรือไม่ก็ตาม ข้อมูลทั้งสองชุดนี้จึงไม่ใช่เครื่องยืนยันประสิทธิภาพสำหรับ private monorepo ของคุณ ซึ่งมีรูปแบบการตั้งชื่อและโค้ดที่ไม่ได้ใช้งาน (dead code) เป็นของตัวเอง

ในส่วนของความถูกต้อง (correctness) ควรพิจารณาให้ถี่ถ้วน ในการทดสอบแบบควบคุม ผลลัพธ์ไม่มีการเปลี่ยนแปลง โดยอยู่ที่ 93% เมื่อใช้เครื่องมือ เทียบกับ 93% เมื่อไม่ใช้ ส่วนการเพิ่มขึ้นเป็น 66% จาก 54% นั้นปรากฏเฉพาะในการทดสอบบน SWE-bench Verified เท่านั้น เครื่องมือที่ช่วยลดค่าใช้จ่ายด้าน token โดยที่คุณภาพงานยังคงเดิมถือเป็นการแลกเปลี่ยนที่คุ้มค่า เพียงแต่อย่านำผลลัพธ์ด้านความถูกต้องจาก SWE-bench ไปรวมกับผลลัพธ์ด้านการประหยัด token จากการทดสอบแบบควบคุมแล้วนำมาอ้างว่าเป็นผลลัพธ์เดียวกัน

วัดค่าส่วนต่างของโทเค็นด้วยตัวเองก่อนจะเชื่อข้อมูลใดๆ

ตัวเลขเดียวที่มีความหมายคือตัวเลขที่มาจาก repository ของคุณเอง วิธีการนี้ใช้เวลาเพียงช่วงบ่าย

เลือกงานที่คุณสามารถทำซ้ำได้อย่างแม่นยำ การตั้งคำถามดีกว่าการแก้ไขโค้ด เพราะการแก้ไขจะทำให้ repository เปลี่ยนไป และการรันครั้งที่สองจะไม่ใช่การทดลองเดิมอีกต่อไป คำถามเช่น "โมดูลใดเป็นตัวบังคับใช้ rate limit บนเส้นทาง login" คือรูปแบบที่เหมาะสม

เปิดใช้งาน telemetry และส่งข้อมูลไปยัง terminal ของคุณ:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=console
claude

Console exporter จะพิมพ์บันทึก metric ออกมาในขณะที่ข้อมูลถูกรวบรวม สิ่งที่คุณต้องการคือ claude_code.token.usage ซึ่งมี attribute type เป็น input, output, cacheRead หรือ cacheCreation ข้อมูลทิศทางจะปรากฏใน input และ cacheRead เนื่องจากเป็นจุดที่เนื้อหาไฟล์ถูกจัดเก็บ ให้นำค่าทั้งสองมารวมกัน

รันงานดังกล่าว 3 ครั้ง โดยแต่ละครั้งต้องอยู่ใน session ใหม่ที่เชื่อมต่อ map ไว้ จากนั้นให้นำรายการ graft ออกจาก .mcp.json แล้วรันซ้ำอีก 3 ครั้ง ให้เปรียบเทียบค่ามัธยฐานแทนการดูผลลัพธ์จากการรันเพียงครั้งเดียว เนื่องจากการรันของ agent มีความผันผวนสูง และการรันที่โชคร้ายเพียงครั้งเดียวอาจให้ผลลัพธ์ที่ตรงกันข้ามกับความเป็นจริง นอกจากนี้ให้บันทึกจำนวนการเรียกใช้เครื่องมือ (tool-call) ไว้ด้วย เพราะการเรียกใช้เครื่องมือคือกลไก และโทเค็นคือผลลัพธ์ ดังนั้นหากโทเค็นลดลงโดยที่จำนวนการเรียกใช้เครื่องมือไม่ลดลง แสดงว่ามีปัจจัยอื่นที่เปลี่ยนแปลงไป

จากนั้นให้หักลบค่าใช้จ่ายที่ benchmark ไม่ได้แสดงให้เห็น graft build --deep ใช้โทเค็นของโมเดลในการ refresh ข้อมูลทั้งหมดทุกครั้ง โดย schema ของเครื่องมือทั้ง 6 รายการจะถูกส่งไปพร้อมกับทุกคำขอ หาก agent ของคุณรันบนเซิร์ฟเวอร์ที่คุณเช่า การกำหนดเพดานค่าใช้จ่ายสูงสุดสำหรับ agent จะช่วยเปลี่ยนจากเหตุการณ์ไม่คาดคิดให้กลายเป็นงบประมาณที่ควบคุมได้ และ สิ่งที่ telemetry ของ coding agent รายงานจริง จะครอบคลุมถึงข้อมูลที่ถูกส่งออกจากเครื่องเมื่อคุณเปิดใช้งาน exporter แล้ว

แผนผัง codebase จะหยุดเป็นประโยชน์เมื่อใด

• Repository มีขนาดเล็กพอที่จะอยู่ในบริบทได้: บริการขนาดเล็กเพียงหนึ่งรายการไม่จำเป็นต้องใช้แผนผัง และคุณยังต้องเสียค่าใช้จ่ายในการเรียกใช้ tool schema ถึงหกรายการในทุกคำขอ หาก agent ของคุณสามารถค้นหาไฟล์ที่ต้องการได้ภายในหนึ่งหรือสองการเรียกใช้เครื่องมือ ให้ข้ามการใช้แผนผังไปได้เลย
• ภาษาของคุณอยู่ในกลุ่ม broad tier: การเชื่อมโยงการเรียกใช้แบบทั่วไป (generic call edges) หมายความว่า graft callers อาจพลาดการระบุผู้เรียก (caller) หรือสร้างข้อมูลที่ผิดพลาดจากการที่ชื่อซ้ำกัน ให้ยืนยันด้วย graft grep ก่อนที่คุณจะเชื่อถือขอบเขตผลกระทบ (blast radius) ที่ได้รับ
• กราฟข้อมูลล้าสมัยโดยไม่มีใครสังเกตเห็น: graft check จะส่งค่า exit code 1 เมื่อเกิดความคลาดเคลื่อน (drift) ซึ่งจะมีประโยชน์ก็ต่อเมื่อมีการเรียกใช้งานจริงเท่านั้น ควรตั้งค่าเป็น hook หรือขั้นตอนใน CI แทนที่จะอาศัยความเคยชิน
• Monorepo จำเป็นต้องมีการกำหนดขอบเขต: Monorepo ที่เป็น git เดียวจะถูกแบ่งโดยอัตโนมัติผ่านไฟล์ workspace, go.mod, pyproject.toml หรือ Cargo.toml และ graft ask "..." --in services/billing/ จะช่วยจำกัดขอบเขตการสืบค้นให้เหลือเพียงโปรเจกต์ย่อยเดียว สัญชาตญาณเดียวกันกับที่นำไปสู่ ไฟล์ AGENTS.md แบบซ้อนกันในแต่ละแพ็กเกจ สามารถนำมาประยุกต์ใช้กับแผนผังได้เช่นกัน
• Agent เพิกเฉยต่อการเชื่อมโยง: ให้สังเกตการเรียกใช้เครื่องมือในเซสชันจริงก่อนที่คุณจะสรุปว่ามีการใช้แผนผังอยู่ หาก agent ยังคงเรียกใช้ grep แสดงว่ามันไม่ได้อ่านไฟล์กฎ (rules file) ที่คุณกำหนดไว้

FAQ

ฉันควร commit โฟลเดอร์ graft/ ลงใน git หรือไม่?

ไม่ควร graft build จะเพิ่ม graft/ ลงใน .gitignore ของคุณโดยอัตโนมัติ เนื่องจากกราฟเป็นแคชที่สร้างใหม่ได้เหมือนกับ node_modules มันมีการเปลี่ยนแปลงเกือบทุกครั้งที่มีการแก้ไข หากคุณ commit ลงไปจะทำให้ diff ที่สำคัญถูกกลบด้วยไฟล์ที่สร้างขึ้นใหม่จำนวนมาก ให้คุณ commit เฉพาะส่วนการเชื่อมต่อที่แจ้งให้ agent ทราบว่ามีแผนผังนี้อยู่ ซึ่งรวมถึง AGENTS.md และ .mcp.json แล้วปล่อยให้เพื่อนร่วมทีมแต่ละคนรัน graft build ในเครื่องของตนเอง ตรวจสอบให้แน่ใจด้วย grep -n graft .gitignore และ git status --short ก่อนการ commit ครั้งแรก เพราะเมื่อ git ติดตามไฟล์ใดแล้ว การแก้ไข .gitignore ในภายหลังจะไม่ทำให้ไฟล์นั้นหลุดจากการติดตาม

การใช้งาน Graft มีค่าใช้จ่ายหรือไม่?

ในส่วนของโครงสร้างไม่มีค่าใช้จ่าย graft build, graft ask, graft check และเครื่องมือดึงข้อมูล MCP ทั้ง 6 รายการ เป็นการทำงานแบบ tree-sitter ซึ่งไม่เคยเรียกใช้งานโมเดล ส่วน graft build --deep คือส่วนที่มีค่าใช้จ่าย โดยจะเขียนสรุปเป็นภาษาอังกฤษทั่วไปและประเด็นสำคัญของแต่ละสัญลักษณ์ผ่าน LLM ซึ่งกำหนดค่าด้วย GRAFT_PROVIDER, GRAFT_API_KEY และ GRAFT_MODEL รวมถึง GRAFT_BASE_URL สำหรับ endpoint ใดๆ ที่รองรับ OpenAI คุณสามารถรัน Graft เฉพาะส่วนโครงสร้างโดยไม่ต้องเสียค่า token ให้กับตัวกราฟเลยก็ได้

แผนผัง codebase จะช่วยประหยัดค่าใช้จ่ายใน repository ของฉันได้มากน้อยเพียงใด?

ไม่มีใครสามารถบอกคุณได้หากไม่ได้ทำการวัดผล โปรเจกต์นี้รายงานว่าประหยัด token ได้ 42% ในการทดสอบ 162 รอบของโปรเจกต์เอง และ 23% บน SWE-bench Verified โดยเทียบกับ baseline ที่ไม่มีแผนผัง ทั้งสองเป็นการทดสอบจากผู้ให้บริการ ซึ่งส่วนหนึ่งรันบน repository ของ Graft เอง และไม่มีการทดสอบใดที่อ้างอิงถึงโค้ดส่วนตัวของคุณ ให้คุณรันคำถามที่ทำซ้ำได้หนึ่งข้อจำนวน 3 ครั้งโดยใช้แผนผัง และอีก 3 ครั้งโดยไม่ใช้ โดยตั้งค่า CLAUDE_CODE_ENABLE_TELEMETRY=1 และ OTEL_METRICS_EXPORTER=console จากนั้นเปรียบเทียบค่ามัธยฐานของ claude_code.token.usage สำหรับประเภท input และ cacheRead

จะเกิดอะไรขึ้นกับกราฟเมื่อฉันทำ refactor?

โครงสร้างจะทำการ parse ตัวเองใหม่ Graft จะตรวจสอบ working tree และ parse เฉพาะไฟล์ที่มีการเปลี่ยนแปลง ดังนั้นการเปลี่ยนชื่อไฟล์จะถูกตรวจพบในการ query ครั้งถัดไปโดยใช้เวลาประมวลผลเพิ่มเพียงประมาณ 3 ms และมันสามารถมองเห็นงานที่ยังไม่ได้ commit ได้เนื่องจากมันอ่านไฟล์โดยตรงแทนที่จะอ่านจากประวัติของ git ส่วนสรุปที่เขียนโดยโมเดลจะเป็นส่วนที่ล้าสมัย โดยแต่ละ node จะเก็บ content hash ของแหล่งที่มาไว้ และเมื่อแหล่งที่มามีการเปลี่ยนแปลง node นั้นจะถูกทำเครื่องหมายว่าล้าสมัยแทนที่จะเขียนทับทันที ให้รัน graft check . เพื่อดูความคลาดเคลื่อน จากนั้นรัน graft build --deep เพื่ออัปเดตส่วนที่เป็นข้อความให้เป็นปัจจุบัน

ปัจจุบันมี coding agent ใดบ้างที่สามารถใช้ Graft ได้?

ณ เดือนสิงหาคม 2026 graft init รองรับการเชื่อมต่อกับ Claude Code, Cursor, Codex, GitHub Copilot, Google Gemini, Kiro, Windsurf และ AdaL โดย Claude Code จะได้รับฟีเจอร์มากที่สุด ได้แก่ รายการ MCP server ใน .mcp.json, statusline, post-edit hooks และไฟล์ทักษะภายใต้ .claude/ ส่วน Codex จะได้รับส่วน AGENTS.md และรายการระดับเครื่องภายใต้ ~/.codex/ ซึ่ง graft init --no-global จะข้ามไป ส่วน agent อื่นๆ จะได้รับไฟล์กฎหรือไฟล์ควบคุม (steering file) สำหรับ MCP client อื่นๆ สามารถใช้งาน server ได้โดยตรงผ่านการลงทะเบียนคำสั่ง npx -y @nanonets/graft@0.10.1 mcp