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

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

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

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

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

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

เราไม่ได้เริ่มต้นที่นี่ เราเริ่มจาก Octomind — 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

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

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

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

Open source, Rust-native

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

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

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

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

{
	"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 ภายใต้ Apache-2.0 หากคุณต้องการเจาะลึก