# Octofs: ไฟล์เซิร์ฟเวอร์ที่หยุดไม่ให้ AI ทำลายโค้ดของคุณ

> เราสร้างเซิร์ฟเวอร์ระบบไฟล์ MCP ที่จับภาพหลอน (hallucination) ของ AI ก่อนที่จะทำให้ไฟล์ของคุณเสียหายได้อย่างไร — ด้วยการจับคู่แบบยืดหยุ่น (fuzzy matching), ตัวระบุบรรทัดที่ใช้แฮช, การเขียนแบบอะตอมิก และกลยุทธ์การจับคู่แบบก้าวหน้าที่ใช้งานได้จริง

# Octofs: ไฟล์เซิร์ฟเวอร์ที่หยุดไม่ให้ AI ทำลายโค้ดของคุณ

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

เรื่องนี้เกิดขึ้นบ่อยกว่าที่ใครจะอยากยอมรับ AI agent เป็นเครื่องมือแก้ไขโค้ดที่ทรงพลัง — จนกว่ามันจะหลอนเลขบรรทัด จำการเยื้องผิด หรือใส่บริบทรอบ ๆ ที่ไม่ควรอยู่ในข้อความแทนที่ การแก้ไขสำเร็จในทางเทคนิค แต่ตอนนี้ไฟล์พังแล้ว คุณไม่ทันสังเกตจนกว่า build จะล้มเหลว

**Octofs เป็นเซิร์ฟเวอร์ระบบไฟล์ MCP ที่สร้างมาเพื่อป้องกันสิ่งนี้โดยเฉพาะ** มันให้ตา มือ และตาข่ายป้องกันแก่ AI agent ของคุณ — ความสามารถในการอ่าน แก้ไข สร้าง และค้นหาไฟล์ พร้อมการป้องกันหลายชั้นจากความผิดพลาดที่โมเดล AI ทำเมื่อสัมผัสกับโค้ด

วันนี้เราขอแนะนำ Octofs 0.4.0 — สถานะปัจจุบันของโครงการที่เริ่มต้นจากเซิร์ฟเวอร์ไฟล์ธรรมดา ๆ และวิวัฒนาการมาเป็นสิ่งที่เราคิดว่า AI agent ทุกตัวต้องการ

## ทำไมเราถึงสร้างเซิร์ฟเวอร์ระบบไฟล์ตั้งแต่แรก

เราไม่ได้เริ่มต้นที่นี่ เราเริ่มจาก [Octomind](https://octomind.run) — runtime สำหรับ AI agent เฉพาะทาง คุณรัน `octomind run developer:general` แล้วได้นักพัฒนาระดับ senior ที่มีเครื่องมือครบครันใน 5 วินาที agent ต้องอ่านโค้ด แก้ไขไฟล์ รันคำสั่ง ค้นหาในโครงการของคุณ มันต้องการการเข้าถึงระบบไฟล์

ระบบนิเวศ MCP มีเซิร์ฟเวอร์ระบบไฟล์อ้างอิงอยู่แล้ว เราจึงลองใช้ มันใช้ได้ — จนกระทั่งใช้ไม่ได้ AI อ้างถึงเลขบรรทัดที่เลื่อนไปหลังการแก้ไขครั้งก่อน มันส่งช่องว่างผิดเล็กน้อยให้กับการแทนที่สตริงและได้รับการจับคู่ที่ไม่ตรงแบบเงียบ ๆ มันทำซ้ำบรรทัดที่ขอบของช่วงการแทนที่ มันพยายามรัน `grep` ผ่าน shell ทั้งที่มีเครื่องมือค้นหาเฉพาะอยู่แล้ว

ความล้มเหลวแต่ละครั้งเล็ก ๆ น้อย ๆ แต่ละครั้งต้องการการแทรกแซงจากมนุษย์ ในระดับ agent — รันการแก้ไขเป็นร้อยครั้งในไฟล์เป็นโหล — ความล้มเหลวเล็ก ๆ น้อย ๆ สะสมเป็นสิ่งที่หยุดมีประโยชน์

ดังนั้นเราจึงเขียนของตัวเอง ไม่ใช่เพราะการเข้าถึงระบบไฟล์น่าสนใจ แต่เพราะ*โหมดความล้มเหลว*ของการแก้ไขไฟล์โดย AI สามารถคาดการณ์ได้ และเซิร์ฟเวอร์ที่ดีสามารถจับส่วนใหญ่ก่อนที่จะกลายเป็นปัญหาของคุณ

## ปัญหาภาพหลอนของ AI ในการแก้ไขไฟล์

นี่คือสิ่งที่พังจริง ๆ:

**เลขบรรทัดผิด** agent อ่านไฟล์ วางแผนแก้ไขห้าจุด ดำเนินการตามลำดับ การแก้ไขแรกเพิ่มสามบรรทัด ตอนนี้การอ้างอิงบรรทัดทั้งหมดที่ตามมาเลื่อนไปสามบรรทัด agent ไม่สังเกตเพราะมันทำงานจากแบบจำลองทางจิตเดิม

**ภาพหลอนการเยื้อง** agent รู้โค้ดที่ต้องการเขียน มันเยื้องผิดเล็กน้อย — สองช่องว่างแทนสี่ หรือ tab เมื่อไฟล์ใช้ช่องว่าง การจับคู่แบบตรงเป๊ะล้มเหลว การแก้ไขเงียบเฉย ไม่ทำอะไร หรือแย่กว่านั้นคือ agent ลองใหม่ด้วยเวอร์ชันที่สับสนกว่าเดิม

**การซ้ำของบริบท** agent ใส่บรรทัดบริบทรอบข้างเพิ่มเติมในข้อความแทนที่ ตอนนี้บรรทัดนั้นปรากฏสองครั้งในไฟล์ ถ้าเป็นเครื่องหมายปีกกาปิด โค้ดอาจยังแปลผ่านได้ ถ้าเป็นบรรทัดที่มีความหมาย คุณก็จะมีบั๊กที่ละเอียดอ่อน

**การจับคู่ที่กำกวม** agent ส่งสตริงสามบรรทัดที่ปรากฏสี่ที่ในไฟล์ ควรแทนที่อันไหน? หากไม่มีการแก้ความกำกวม การแก้ไขก็จะล้มเหลวหรือไปโดนตำแหน่งผิด

นี่ไม่ใช่กรณีพิเศษ มันคือประสบการณ์ทั่วไปของการรัน AI agent ในระดับใหญ่ และทั้งหมดนี้แก้ไขได้ — ไม่ใช่ด้วยการทำให้ AI ฉลาดขึ้น แต่ด้วยการทำให้ไฟล์เซิร์ฟเวอร์ฉลาดขึ้นเกี่ยวกับความผิดพลาดที่มันรู้ว่า AI จะทำ

## Octofs จับความผิดพลาดได้อย่างไร

### การจับคู่แบบก้าวหน้าสามขั้นตอน

เมื่อ AI เรียก `str_replace` ด้วย `old_text` ที่ควรจับคู่กับบางอย่างในไฟล์ Octofs ไม่ได้ลองครั้งเดียวแล้วล้มเหลว มันรันสามขั้นตอน:

**ขั้นที่ 1: การจับคู่แบบตรงเป๊ะ** สตริง `old_text` จับคู่ตรงเป๊ะหนึ่งครั้งในไฟล์ ก็แทนที่เลย เสร็จ นี่คือเส้นทางมีความสุข — มันจัดการการแก้ไขส่วนใหญ่ได้อย่างถูกต้อง

**ขั้นที่ 2: การจับคู่แบบยืดหยุ่นที่ทำให้ช่องว่างเป็นมาตรฐาน** การจับคู่แบบตรงเป๊ะล้มเหลว Octofs จึงทำให้ช่องว่างเป็นมาตรฐานทั้งในข้อความที่ให้มาและเนื้อหาไฟล์ — ยุบลำดับช่องว่าง ตัดบรรทัด — และลองอีกครั้ง หากมีการจับคู่แบบมาตรฐานหนึ่งครั้งพอดี มันจะปรับการเยื้องของข้อความแทนที่อัตโนมัติให้ตรงกับไฟล์จริง นำการแก้ไขไปใช้ และบอก AI ว่าเกิดอะไรขึ้นผ่านคำแนะนำ AI เรียนรู้ การแก้ไขสำเร็จ

**ขั้นที่ 3: การวินิจฉัยที่ละเอียด** ทั้งการจับคู่แบบตรงเป๊ะและแบบยืดหยุ่นไม่ได้ผล แทนที่จะให้ข้อผิดพลาดทั่วไปว่า "ไม่พบการจับคู่" Octofs รันการค้นหาความคล้ายคลึงแบบหน้าต่างเลื่อนทั่วทั้งไฟล์ พบการจับคู่ที่ใกล้เคียงที่สุดสามรายการ และส่งคืนพร้อมเปอร์เซ็นต์ความคล้ายคลึง เลขบรรทัด การวินิจฉัย*ว่าทำไม*จึงต่างกัน (การเยื้องไม่ตรง ช่องว่างเท่านั้น หรือเนื้อหาต่างกัน) และตัวอย่างของข้อความที่เป็นตัวเลือก จากนั้น AI สามารถใช้ `batch_edit` กับช่วงบรรทัดที่แน่นอน — หรือแก้ไข `old_text` ของมันและลองใหม่

นี่คือสิ่งที่เกิดขึ้นทุกครั้งที่การแก้ไขล้มเหลว และเป็นการลดการลองแก้ไขที่ล้มเหลวซ้ำที่ใหญ่ที่สุดที่เราเห็น

### การระบุบรรทัดด้วยแฮช

เลขบรรทัดเป็นตัวระบุที่แย่มากสำหรับการแก้ไขโดย AI พวกมันเลื่อน AI อ่านไฟล์ 500 บรรทัด วางแผนแก้ไขบรรทัด 142-156 แต่การแก้ไขครั้งก่อนได้แทรกสี่บรรทัดที่บรรทัด 80 ตอนนี้เป้าหมายอยู่ที่ 146-160 AI ไม่รู้เรื่องนี้เว้นแต่จะอ่านไฟล์อีกครั้ง — ซึ่งอาจไม่ทำ

Octofs เสนอทางเลือก: **ตัวระบุบรรทัดที่ใช้แฮช** แต่ละบรรทัดจะได้รับแฮชเลขฐานสิบหก 4 อักขระที่ได้จากตำแหน่งและเนื้อหา ต่างจากเลขบรรทัด แฮช*เสถียรข้ามการแก้ไข* — แฮชของบรรทัดไม่เปลี่ยนเพียงเพราะมีการแทรกบรรทัดอื่นไว้ข้างบน AI สามารถอ้างอิงบรรทัดด้วยแฮช และแม้หลังจากการแก้ไขหลายครั้ง การอ้างอิงเหล่านั้นยังคงใช้ได้

อัลกอริทึมแฮชใช้ FNV-1a พับเป็น 16 บิต โดยใช้คีย์ `"<ตำแหน่ง>:<เนื้อหา>"` ตำแหน่งถูกรวมไว้โดยเฉพาะเพื่อจัดการบรรทัดซ้ำ — บรรทัดที่เหมือนกันสองบรรทัดในตำแหน่งต่างกันจะได้รับแฮชต่างกันเสมอ โดยไม่จำเป็นต้องแก้การชนกัน

เปิดใช้งานด้วย `--line-mode hash` และทุกการตอบสนองของเครื่องมือจะส่งคืนแฮชแทนตัวเลข AI ใช้พวกมันสำหรับช่วงของ `batch_edit` ช่วงของ `view` และการวินิจฉัย การเลื่อนของเลขบรรทัดไม่ใช่ปัญหาอีกต่อไป

### การตรวจจับการซ้ำที่ขอบเขตของการแทนที่

นี่คือเรื่องที่ละเอียดอ่อน AI วางแผนแทนที่บรรทัด 100-105 มันรวมบรรทัด 99 (บรรทัดก่อนหน้าช่วง) ไว้ในเนื้อหาแทนที่ — ไม่ใช่เพราะอยากเปลี่ยนมัน แต่เพราะมันกำลัง "ให้บริบท" ตอนนี้บรรทัด 99 ปรากฏสองครั้ง ถ้าเป็นเครื่องหมายปีกกาปิดหรือบรรทัดว่าง อาจไม่เสียหาย ถ้าเป็นโค้ดจริง คุณจะมีบั๊ก

Octofs ตรวจสอบทุกการแทนที่สำหรับการซ้ำที่ขอบเขต มันเปรียบเทียบบรรทัดแรกของการแทนที่กับบรรทัดที่อยู่ก่อนช่วงเป้าหมายทันที และบรรทัดสุดท้ายกับบรรทัดถัดไป หากตรงกัน มันจะปฏิเสธการแก้ไขด้วยข้อความเฉพาะ: _"ตรวจพบบรรทัดซ้ำในการดำเนินการที่ 2: บรรทัดแรกของเนื้อหาตรงกับบรรทัด 99 (อยู่ก่อนช่วงแทนที่ [100-105]) ห้ามใส่บรรทัดที่ไม่เปลี่ยนแปลงโดยรอบ"_

สัญญาณรบกวนเชิงโครงสร้าง — เครื่องหมายปีกกาปิดเดี่ยว บรรทัดว่าง — ได้รับการยกเว้นจากการตรวจสอบนี้ พวกมันปรากฏที่ขอบเขตอย่างถูกต้อง การปิดแบบรวมเช่น `});` ไม่ได้รับการยกเว้น พวกมันมีความหมายเชิงความหมายที่แท้จริง

### การตรวจจับความขัดแย้งสำหรับการดำเนินการแบบกลุ่ม

`batch_edit` ให้ AI ทำการแทรกและแทนที่หลาย ๆ ครั้งบนไฟล์เดียวแบบอะตอมิก แต่จะเป็นอย่างไรหากการแทนที่สองครั้งทับซ้อนกัน? จะเป็นอย่างไรหากการแทรกสองครั้งเล็งไปที่บรรทัด anchor เดียวกัน?

Octofs ตรวจสอบทุกการดำเนินการกับการดำเนินการอื่น ๆ ก่อนที่จะแตะไฟล์ ช่วงแทนที่-vs-แทนที่ที่ทับซ้อนกันจะถูกปฏิเสธ การแทรก-vs-การแทรกที่ anchor เดียวกันจะถูกปฏิเสธ (ลำดับกำกวม) การแทรก-vs-การแทนที่ไม่เคยขัดแย้งกัน — พวกมันทำงานในตำแหน่งที่ต่างกันในเชิงแนวคิด (ช่องว่างหลังบรรทัด vs เนื้อหาของบรรทัด)

หากมีความขัดแย้ง ข้อความข้อผิดพลาดจะรวมดัชนีของการดำเนินการและช่วงบรรทัดที่เกี่ยวข้อง AI สามารถแก้ไขแผนและลองใหม่ ไม่มีการเสียหายบางส่วน

### การเขียนแบบอะตอมิกพร้อมประวัติการยกเลิก

ทุกการแก้ไขผ่าน `atomic_write`: เขียนลงไฟล์ชั่วคราวในไดเรกทอรีเดียวกัน จากนั้นเปลี่ยนชื่อทับเป้าหมาย ไฟล์ไม่เคยอยู่ในสถานะบางส่วน หากกระบวนการล้มกลางการเขียน ต้นฉบับยังคงสมบูรณ์ การเปลี่ยนชื่อเป็นขั้นตอนทำลายเดียว และเป็นแบบอะตอมิกที่ระดับระบบไฟล์

ก่อนทุกการเขียน Octofs จะบันทึกเวอร์ชันก่อนหน้า สูงสุดสิบระดับ undo ต่อไฟล์ หากการแก้ไขผิดพลาด AI สามารถเรียก `undo_edit` แล้วไฟล์จะย้อนกลับ ไม่มี git restore แบบ manual ไม่มี "อุ๊ปส์ ฉันต้องแก้ไขสิ่งที่ AI เพิ่งทำ"

### การตรวจจับการใช้ shell ผิดวิธี

AI มีการเข้าถึง shell นั่นจำเป็น — มันต้องรัน build ทดสอบ linter แต่บางครั้งมันก็พยายามใช้ `cat` เพื่ออ่านไฟล์ หรือ `grep` เพื่อค้นหาข้อความ หรือ `sed` เพื่อแก้ไขบรรทัด เครื่องมือเหล่านี้ทั้งหมดมีเครื่องมือเฉพาะที่ดีกว่าใน Octofs

เมื่อ AI รันคำสั่ง shell ที่ตรงกับรูปแบบการใช้ผิดที่รู้จัก Octofs ตรวจจับและฉีดคำแนะนำในการตอบสนองเครื่องมือถัดไป: _"ควรใช้ `view` เพื่ออ่านไฟล์ (มีเลขบรรทัด รองรับช่วง)"_ AI เห็นคำแนะนำ ปรับพฤติกรรม และใช้เครื่องมือที่ถูกต้องในครั้งต่อไป

### การบังคับใช้ shell แบบไม่โต้ตอบ

คำสั่ง shell รันด้วย `stdin=null` กลุ่มกระบวนการเฉพาะ และตัวแปรสภาพแวดล้อมเช่น `GIT_TERMINAL_PROMPT=0` และ `PAGER=cat` AI ไม่สามารถเปิด prompt โต้ตอบที่ทำให้เซสชันค้างโดยบังเอิญ Git จะไม่ขอข้อมูลรับรอง `sudo` จะไม่ขอรหัสผ่าน `less` จะไม่ถูกเรียกใช้ คำสั่งสำเร็จหรือล้มเหลว — ไม่มีสถานะที่สาม

เมื่อปิด ทุกกลุ่มกระบวนการลูก shell ที่ยังทำงานอยู่จะถูกฆ่าด้วย SIGKILL ไม่มีกระบวนการกำพร้า ไม่มี shell ซอมบี้กินหน่วยความจำ

## สถานะปัจจุบัน: 0.4.0

Octofs 0.4.0 ไม่ใช่ประกาศการเปิดตัว — มันคือสถานะปัจจุบันของโครงการ และเสถียรพอที่จะพึ่งพาได้ นี่คือสิ่งที่เวอร์ชันปัจจุบันมอบให้:

**มุมมองไฟล์แบบหลายช่วง** อ่านส่วนที่ไม่ติดกันของไฟล์ในการเรียกครั้งเดียว — `[[1, 50], [200, 250], [400, 430]]` — แทนที่จะเป็นคำขอแยกสามครั้ง round trip น้อยลง บริบทเสียน้อยลง

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

**การบังคับใช้ shell แบบไม่โต้ตอบ** คำสั่ง shell รับประกันว่าไม่โต้ตอบ ไม่มี prompt ค้าง ไม่มี dialog ข้อมูลรับรอง ไม่มีเอาต์พุตขยะที่เรียกใช้โดย pager

**การจำกัดเกินขอบเขต** ช่วงบรรทัดที่เกินความยาวของไฟล์จะถูกจำกัด ไม่ใช่ปฏิเสธ AI ขอบรรทัด 1-1000 ในไฟล์ 200 บรรทัด? มันได้บรรทัด 1-200 ไม่มีข้อผิดพลาด ไม่ต้องลองใหม่

**ช่วงบรรทัดต่อไฟล์ในมุมมองหลายไฟล์** เมื่อดูหลายไฟล์พร้อมกัน แต่ละไฟล์มีช่วงบรรทัดของตัวเองได้ `paths: ["a.rs", "b.rs", "c.rs"]` กับ `lines: [[1,50], null, [10,30]]` — ไฟล์แรกแสดง 1-50 ไฟล์ที่สองแสดงทั้งหมด ไฟล์ที่สามแสดง 10-30

**การล็อกไฟล์แบบ canonicalized** การล็อกไฟล์ใช้พาธแบบ canonicalized ดังนั้น `./src/main.rs`, `src/main.rs`, และ `/absolute/path/to/src/main.rs` ทั้งหมดจะ resolve ไปยังการล็อกเดียวกัน ไม่มีการเสียหายจากการเขียนพร้อมกันเนื่องจาก aliasing ของพาธ

**การค้นหาด้วย Rust ล้วน ๆ** การค้นหาเนื้อหาไม่ shell out ไปยัง ripgrep อีกต่อไป มันเป็นการนำไปใช้ด้วย Rust ล้วน ๆ ที่เร็วพอ มี dependencies ภายนอกเป็นศูนย์ และทำงานเหมือนกันบนทุกแพลตฟอร์ม

## เครื่องมือต่าง ๆ

Octofs เปิดเผยเครื่องมือ MCP เจ็ดตัว:

| เครื่องมือ        | ทำอะไร                                                                                                               |
| ----------------- | -------------------------------------------------------------------------------------------------------------------- |
| **view**          | อ่านไฟล์ แสดงรายการไดเรกทอรี ค้นหาเนื้อหา รองรับหลายไฟล์ หลายช่วง ID บรรทัดที่ใช้แฮช การค้นหาเนื้อหาพร้อมบรรทัดบริบท |
| **text_editor**   | สร้างไฟล์ แทนที่ข้อความด้วยการจับคู่แบบก้าวหน้า ยกเลิกการแก้ไข                                                       |
| **batch_edit**    | การดำเนินการแทรก/แทนที่แบบอะตอมิกหลายครั้งบนไฟล์เดียว พร้อมการตรวจจับความขัดแย้ง                                     |
| **extract_lines** | คัดลอกช่วงบรรทัดจากไฟล์หนึ่งไปยังอีกไฟล์หนึ่ง                                                                        |
| **shell**         | ดำเนินการคำสั่งพร้อมการรองรับเบื้องหลัง การตรวจจับการใช้ผิดวิธี การบังคับใช้แบบไม่โต้ตอบ                             |
| **workdir**       | จัดการบริบทไดเรกทอรีที่ใช้งาน                                                                                        |

เครื่องมือทั้งหมดรองรับทั้ง STDIO และ Streamable HTTP transport เครื่องมือทั้งหมดรับรู้ gitignore ในระหว่างการสำรวจไดเรกทอรี เครื่องมือทั้งหมดตอบสนองด้วยเอาต์พุตที่มีเลขบรรทัด (หรือระบุด้วยแฮช) เพื่อให้ AI มีการอ้างอิงที่เสถียรสำหรับการดำเนินการต่อ ๆ ไป

## มันเข้ากันได้อย่างไร: Octomind + Octofs

Octofs ทำงานร่วมกับไคลเอนต์ที่เข้ากันได้กับ MCP — Claude Desktop, Cursor, Windsurf, Zed แต่ออกแบบมาสำหรับ [Octomind](https://octomind.run)

agent ของ Octomind อ่านโค้ดเบสของคุณ วางแผนการเปลี่ยนแปลง และดำเนินการแก้ไขผ่าน Octofs Octobrain — เซิร์ฟเวอร์หน่วยความจำของเรา — เก็บสิ่งที่ agent เรียนรู้ระหว่างเซสชัน [Octolib](https://github.com/Muvon/octolib) จัดการการเรียก LLM ทุกครั้ง รวมกันพวกมันคือสแต็คที่สมบูรณ์สำหรับการพัฒนาโดย AI:

- **Octolib** พูดคุยกับโมเดล AI
- **Octobrain** จำข้ามเซสชัน
- **Octofs** แตะไฟล์ของคุณอย่างปลอดภัย
- **Octomind** ประสานทุกสิ่ง

แต่ละชิ้นเป็น open source แต่ละชิ้นทำงานได้ด้วยตัวเอง รวมกันพวกมันแก้ปัญหาในการให้ AI agent เข้าถึงโค้ดเบสได้อย่างเชื่อถือได้และปลอดภัย

## Open source, Rust-native

Octofs อยู่ [บน GitHub](https://github.com/muvon/octofs) ภายใต้ Apache-2.0 มันสร้างด้วย Rust — ไม่ใช่เพราะเราหลงใหลในประสิทธิภาพ แต่เพราะการดำเนินการกับไฟล์ได้ประโยชน์จากความถูกต้องที่ compile-time, async ค่าใช้จ่ายเป็นศูนย์ และไม่มีการหยุดเก็บขยะ binary มีขนาดเล็ก เร็ว และมี runtime dependencies เป็นศูนย์นอกเหนือจาก OS

```bash
# build จากซอร์ส (ต้องการ Rust 1.95+)
git clone https://github.com/muvon/octofs
cd octofs && cargo build --release

# หรือดาวน์โหลด binary ที่สร้างไว้แล้วจาก GitHub Releases
```

เพิ่มในการตั้งค่า Claude Desktop ของคุณ:

```json
{
	"mcpServers": {
		"octofs": {
			"command": "/path/to/octofs",
			"args": ["--line-mode", "hash"]
		}
	}
}
```

ใช้โหมด hash สำหรับ agent ใด ๆ ที่ทำการแก้ไขหลายขั้นตอน การอ้างอิงบรรทัดที่เสถียรกำจัดความล้มเหลวทั้งคลาส

## คำถามที่พบบ่อย

**Octofs คืออะไร?**

Octofs เป็นเซิร์ฟเวอร์ระบบไฟล์ MCP open-source ใน Rust มันให้ AI agent การเข้าถึงที่ปลอดภัยและเชื่อถือได้ในการอ่าน แก้ไข ค้นหา และสร้างไฟล์ — พร้อมการป้องกันในตัวจากโหมดความล้มเหลวที่โมเดล AI แสดงเมื่อแก้ไขโค้ด

**ไคลเอนต์ AI ใดที่ทำงานกับ Octofs?**

ไคลเอนต์ที่เข้ากันได้กับ MCP ใด ๆ: Claude Desktop, Cursor, Windsurf, Zed และ runtime agent Octomind แบบ open-source

**Octofs ป้องกันภาพหลอนของ AI ไม่ให้ทำลายไฟล์ได้อย่างไร?**

ห้าชั้น: (1) การจับคู่แบบก้าวหน้าสามขั้นสำหรับ `str_replace`, (2) ID บรรทัดที่ใช้แฮชที่อยู่รอดผ่านการแก้ไข, (3) การตรวจจับการซ้ำที่ขอบเขตของการแทนที่, (4) การตรวจจับความขัดแย้งสำหรับการดำเนินการแบบกลุ่ม, (5) การเขียนแบบอะตอมิกพร้อม undo สูงสุด 10 ระดับต่อไฟล์

**ID บรรทัดที่ใช้แฮชคืออะไร?**

แต่ละบรรทัดได้รับแฮชเลขฐานสิบหก 4 อักขระที่ได้มาจากเนื้อหาและตำแหน่ง (FNV-1a พับเป็น 16 บิต) ต่างจากเลขบรรทัด แฮชเสถียรข้ามการแก้ไข — แฮชของบรรทัดไม่เลื่อนเมื่อมีการแทรกบรรทัดอื่นไว้ข้างบน เปิดใช้งานด้วย `--line-mode hash`

**Octofs ต่างจากเซิร์ฟเวอร์ระบบไฟล์ MCP อ้างอิงอย่างไร?**

เซิร์ฟเวอร์อ้างอิงทำ file I/O ตรง ๆ Octofs เพิ่มการจับคู่แบบยืดหยุ่นด้วย auto-indentation, ID แฮช, การตรวจจับการซ้ำที่ขอบเขต, การตรวจสอบความขัดแย้งแบบกลุ่ม, การเขียนแบบอะตอมิก, ประวัติ undo, การตรวจจับการใช้ shell ผิดวิธี และการบังคับใช้ shell แบบไม่โต้ตอบ สร้างมาเฉพาะสำหรับโหมดความล้มเหลวที่ AI agent สร้างขึ้นในระดับใหญ่

**Octofs พร้อมสำหรับ production หรือไม่?**

ใช่ 0.4.0 เสถียรและใช้ทุกวันภายใน Octomind Apache-2.0, binary Rust เดี่ยว, runtime dependencies เป็นศูนย์นอกเหนือจาก OS การเขียนแบบอะตอมิกรับประกันว่าไฟล์ไม่เคยจบในสถานะบางส่วน

**รองรับทั้ง STDIO และ HTTP หรือไม่?**

ใช่ STDIO transport สำหรับไคลเอนต์เดสก์ท็อป (Claude, Cursor, ฯลฯ) และ Streamable HTTP สำหรับ agent ระยะไกล

## อะไรต่อไป

เรากำลังพัฒนาการวินิจฉัยที่ฉลาดขึ้น — เมื่อการแก้ไขล้มเหลว Octofs ไม่ควรเพียงแค่บอก AI ว่าอะไรผิดพลาด มันควรแนะนำวิธีแก้ไข เรายังกำลังสำรวจการตรวจสอบการแก้ไขตามรูปแบบ: หาก AI กำลังแก้ไขฟังก์ชัน Rust Octofs สามารถตรวจสอบว่าผลลัพธ์ยังคงแปลผ่านเป็น Rust ที่ถูกต้องก่อนเขียน

ไฟล์เซิร์ฟเวอร์ไม่ใช่ส่วนที่น่าตื่นเต้นของสแต็ค AI agent มันเป็นส่วนที่ต้องทำงานได้อย่างสมบูรณ์แบบทุกครั้ง ไม่อย่างนั้นทุกอย่างก็พังลงมา นั่นคือข้อกำหนดที่ Octofs ถูกสร้างขึ้นมา — และมันเป็น [open source บน GitHub](https://github.com/muvon/octofs) ภายใต้ Apache-2.0 หากคุณต้องการเจาะลึก