ขออภัยที่ส่วนสุดท้ายของซีรีส์ 19 ระบบนี้มาช้า แต่ช้าก็ยังดีกว่าไม่มา
รูปแบบสากลทั้งหกแบบใน 19 ระบบที่ผมกำลังศึกษาอยู่นี้คือแกนหลักของซีรีส์นี้ ได้แก่ การลงทุนด้านคุณภาพในตอนเขียน, การติดตามที่มาที่ไปพร้อมกับข้อเท็จจริง, การค้นหาแบบผสมผสานแบบ RRF, การจัดเก็บแบบหลายชั้นพร้อมการเลื่อนชั้นตามความร้อน, งบประมาณบริบทที่ชัดเจน, และเครื่องมือที่ไม่ใช่การฉีดที่อินเทอร์เฟซเอเจนต์ แต่ละรูปแบบสมควรมีบทความของตัวเอง เพราะระบบตั้งแต่สามระบบขึ้นไปค้นพบแนวทางเดียวกันนี้อย่างอิสระ
รูปแบบสากลจบลงแค่นี้ จากนั้นรูปแบบที่กำลังเกิดขึ้นก็เริ่มต้นขึ้น
บทความนี้เกี่ยวกับแปดรูปแบบที่อยู่ต่ำกว่าเกณฑ์ ปรากฏอยู่ในระบบเดียวหรือสองระบบ โดยการนำไปปฏิบัตินั้นชัดเจนว่ากำลังแก้ไขปัญหาจริง จนยากที่จะเชื่อว่ารูปแบบเหล่านี้จะยังคงหายากต่อไป เจ็ดรูปแบบปรากฏในระบบเดียวเท่านั้น ส่วนอีกรูปแบบหนึ่งปรากฏในสองระบบ และห่างจากการถูกนำไปใช้อีกเพียงครั้งเดียวก็จะก้าวขึ้นมาเป็นสากล รูปแบบแรกได้รับการลงรายละเอียดมากที่สุดเพราะมันสำคัญที่สุด
การมาเร็วหมายความว่าบางรูปแบบอาจไม่กลายเป็นสากล แต่การมาเร็วยังดีกว่ามาช้า: คุณสร้างระบบในปี 2026 ที่ปล่อยออกมาโดยไม่มีระบบอนุญาตในชั้นจัดเก็บข้อมูล เพราะการสังเคราะห์เรียกว่ามันเป็นความแปลกประหลาดเฉพาะกรณี แล้วคุณก็เจอการสาธิตการฉีด prompt บน Hacker News ในปี 2027
เอนจินจัดเก็บข้อมูลคือผู้มีอำนาจเพียงผู้เดียวที่ยึดถือ
บทความก่อนหน้านี้แย้งว่าเอเจนต์ควรเป็นผู้ถือเครื่องมือ ให้เครื่องมือ SQL แก่มัน แล้วคำถามก็เกิดขึ้นทันที: อะไรจะหยุดมันไม่ให้สอบถามตารางที่ไม่ควร?
แนวทางแบบง่ายๆ นั้นเป็นที่รู้จักกันดีและผิดทั้งหมด
คำสั่งระดับ prompt: "คุณไม่ได้รับอนุญาตให้อ่านตาราง conversations" ใช้ได้กับโมเดลที่ให้ความร่วมมือ แต่ใช้ไม่ได้กับโมเดลใดๆ ที่อ่านคำสั่งผิด ตัดสินว่าข้อห้ามไม่适用 กับงานปัจจุบันของมัน หรือกำลังทำงานภายใต้การเจลเบรก
ตัวกรองระดับแอปพลิเคชัน: เครื่องมือ \sql_query\ ห่อหุ้ม SQL ของโมเดล แยกวิเคราะห์เพื่อหาการอ้างอิงตารางที่ต้องห้าม ปฏิเสธคำค้นหาก่อนส่งต่อไปยังฐานข้อมูล ใช้ได้กับโมเดลที่ไร้เดียงสา แต่ใช้ไม่ได้กับโมเดลใดๆ ที่อ้างชื่อตาราง ใช้ \ATTACH\ ใช้ประโยชน์จากความไม่ตรงกันในการแยกวิเคราะห์ระหว่างตัวห่อหุ้มและฐานข้อมูล หรือเส้นทางผ่านวิวที่กำหนดไว้ที่อื่น
การเข้าถึงผ่าน ORM เท่านั้น: เอเจนต์ไม่เคยแตะต้อง SQL ดิบ แต่มันเรียกเมธอดที่กำหนดประเภท ใช้ได้จนกว่าระบบจะพัฒนาเครื่องมือดีบัก เครื่องมือวิเคราะห์ เครื่องมือโยกย้าย หรือฟีเจอร์ "ให้เอเจนต์ join สองตาราง" ซึ่งถึงจุดนั้นกฎจะพัง และความเสียหายจะไม่มีใครสังเกตเห็น
พูดง่ายๆ: ไม่มีสิ่งเหล่านี้เป็นการบังคับใช้เลย มันเป็นแค่คำใบ้ ระบบที่ต้องการการแยกซับเอเจนต์อย่างแท้จริงต้องให้เอนจินจัดเก็บข้อมูลปฏิเสธการอ่านด้วยตัวเอง ไม่ใช่ชั้นที่อยู่เหนือมัน นี่คือระเบียบวินัยที่ความปลอดภัยตามความสามารถกำหนดกับทรัพยากรระบบปฏิบัติการ: เคอร์เนลเป็นคนปฏิเสธ ไม่ใช่แอปพลิเคชัน นอกจากนี้ยังเป็นระเบียบวินัยที่ความปลอดภัยระดับแถวของ PostgreSQL กำหนดกับ SaaS แบบหลายผู้เช่า: นโยบายอยู่ในฐานข้อมูล ไม่ใช่ ORM เพราะ "วิศวกรที่สร้างไมโครเซอร์วิสใหม่ลืมใช้ตัวกรองผู้เช่า" เป็นคลาสบั๊กที่มีเพียงนโยบายของเอนจินจัดเก็บข้อมูลเท่านั้นที่จะตัดออกได้
second-brain คือตัวอย่างการทำงานแรกของคลังข้อมูลนี้ ฐานข้อมูลแบบมีขอบเขตของมันมีสามชั้น แต่ละชั้นจำเป็น แต่ไม่มีชั้นใดเพียงพอด้วยตัวเอง
การเชื่อมต่อ SQLite ในหน่วยความจำใหม่ต่อหนึ่งเอเจนต์แบบมีขอบเขต ตัวสร้างเปิด \:memory:\ และแนบฐานข้อมูลจริงในโหมดอ่านอย่างเดียว การเชื่อมต่อของเอเจนต์ไม่มี schema หลักจริง ไม่มีอะไรให้อ่านยกเว้นสิ่งที่ชั้นถัดไปวางไว้ที่นั่น
TEMP VIEWs ใน schema หลักที่เปลี่ยนเส้นทางไปยังตารางที่อนุญาตในแหล่งข้อมูล นิยามวิวมาจากโปรไฟล์ของเอเจนต์และสามารถเข้ารหัสการแก้ไขระดับคอลัมน์หรือตัวกรองระดับแถว ตัวตรวจสอบชื่อวิวป้องกันการฉีดชื่อตารางที่เป็นอันตรายผ่านโปรไฟล์
ฮุคอนุญาต C-API ของ SQLite ที่ปฏิเสธการอ่าน schema แหล่งข้อมูลใดๆ ที่ไม่ผ่านวิว ฮุคนี้จะทำงานสำหรับทุกการอ่านที่ SQLite กำลังจะดำเนินการ ก่อนที่ออปติไมเซอร์จะแก้ไขชื่อตารางด้วยซ้ำ การอ่านภายในเนื้อหาวิวได้รับอนุญาต วิวคือตัวกรองขอบเขต การอ่านระดับบนสุดจะถูกตรวจสอบกับชุดชื่อวิวที่ขอบเขตสร้างขึ้น การอ่านใดๆ ต่อ schema แหล่งข้อมูลโดยตรงจะถูกปฏิเสธโดยไม่มีข้อยกเว้น
LLM สามารถเขียน SQL อะไรก็ได้ที่ต้องการ มันสามารถอ้างชื่อตาราง ใช้ \UNION\ ใช้ \ATTACH\ ใช้ไวยากรณ์ทั้งหมดของ SQLite แต่มันไม่สามารถอ่านแถวจากตารางที่ไม่ได้อยู่ในรายการอนุญาตได้สำเร็จ เพราะตัวอนุญาตสกัดกั้นการอ่านที่ชั้น C ก่อนที่ชื่อตารางจะถูกแก้ไข ตัวกรองระดับแอปพลิเคชันสามารถเลี่ยงได้ แต่การอนุญาตของเอนจินจัดเก็บข้อมูลไม่สามารถเลี่ยงได้
ประมาณ 50 บรรทัดของ Python ใน stdlib ไม่มีการพึ่งพาเพิ่ม ไม่มีกระบวนการเพิ่ม ไม่มีการโยกย้าย schema ค่าใช้จ่ายต่อการค้นหาคือ callback C หนึ่งครั้งต่อการอ่าน ซึ่งมองไม่เห็นเมื่อเทียบกับต้นทุนของตัวค้นหาเอง รูปแบบนี้ประกอบเข้ากับทุกสิ่งทุกอย่างได้อย่างสะอาด: ทะเบียนเครื่องมือของเอเจนต์ยังคงสามารถจำกัดฟีเจอร์ได้ นิยามวิวยังคงสามารถเข้ารหัสการแก้ไขระดับคอลัมน์ได้ และประวัติการสนทนายังคงถูกแก้ไขในตอนเขียนได้ ไม่มีชั้นใดอ่อนแอลงเนื่องจากการบังคับใช้ในชั้นเก็บข้อมูล พวกมันถูกเสริมกำลังโดยสิ่งนี้
กรอบความคิดนี้สำคัญ รูปแบบความปลอดภัยอื่นๆ ทุกรูปแบบใน 19 ระบบเป็นเพียงคำใบ้ เอนจินจัดเก็บข้อมูลคือผู้มีอำนาจ
อีกสามรูปแบบที่ควรกล่าวถึง
การป้องกัน race condition ในการล้างข้อมูลแบบอะซิงก์ (llm-wiki)
การบำรุงรักษาหน่วยความจำในเบื้องหลังนั้นมีความ race กับ actions ของผู้ใช้ในเบื้องหน้าอย่างพื้นฐาน การ sweep ที่เริ่มต้นกับโปรเจกต์ A และเสร็จสิ้นกับโปรเจกต์ B ได้ทำให้ทั้งสองเสียหาย มันย้ายการตัดสินใจของ A ไปยังที่เก็บทบทวนของ B หรือทำเครื่องหมายรายการของ B ว่าถูกแก้ไขด้วยข้อมูลของ A นี่คือคลาสบั๊กที่ง่ายต่อการแนะนำ ยากต่อการตรวจจับ และเป็นไปไม่ได้ที่จะกู้คืนอย่างสะอาดเพราะสถานะที่เสียหายนั้นดูเหมือนถูกต้อง
llm-wiki วนรอบการทบทวนเบื้องหลังแบบสองขั้นตอน และที่ทุกจุดผลลัพธ์ จะตรวจสอบสัญญาณป้องกัน race สองตัวอีกครั้ง: สัญญาณยกเลิกที่ถูกเรียกโดยตัวจัดการสลับโปรเจกต์ และการเปรียบเทียบเส้นทางกับโปรเจกต์ปัจจุบันใน store UI หากการตรวจสอบใดล้มเหลว sweep จะกลับมากลางคันโดยไม่ใช้การตัดสินใจ การจับมือสลับโปรเจกต์ที่ด้านคิวทำให้ภาพสมบูรณ์: มัน flush สถานะของโปรเจกต์ที่active ไปยังดิสก์ก่อนล้างหน่วยความจำ คืนค่ารายการที่กำลังประมวลผลกลับไปเป็นสถานะรอดำเนินการ ยกเลิกทั้งการเรียก LLM ที่กำลังดำเนินการและการตัดสินใจ sweep ที่กำลังดำเนินการ จากนั้นจึงเขียนไปยังเส้นทางของโปรเจกต์ที่หยุดไว้ชั่วคราว
รูปแบบหลักคือข้อสรุป: กำหนดได้ในที่ที่ทำได้ ใช้ LLM ในที่ที่จำเป็น และยกเลิกได้ทุกที่ โครงสร้างสองขั้นตอนทำให้ LLM อยู่นอกกรณีที่การตรวจสอบการมีอยู่แบบง่ายๆ จัดการได้ การป้องกัน race ทำให้ทั้งสองขั้นตอนยกเลิกได้ การรวมกันนี้เป็นแม่แบบสำหรับการวนรอบบำรุงรักษาหน่วยความจำเบื้องหลังในทุกระบบ
ตัวสร้างไร้การดำเนินการแบบลดระดับอัตโนมัติ (graymatter)
การออกแบบ API ไลบรารีมีความตึงเครียดที่เกิดขึ้นซ้ำๆ "Hello World" ที่ง่ายที่สุดต้องการให้ไลบรารีทำงานได้ทันที หนึ่งบรรทัดเพื่อสร้าง หนึ่งบรรทัดเพื่อเรียก ท่าทางการผลิตที่ป้องกันได้มากที่สุดต้องการให้มันล้มเหลวดังๆ ที่การสร้างพร้อมกับข้อผิดพลาดที่มีโครงสร้างซึ่งผู้เรียกไม่สามารถละเลยได้
graymatter เลือกที่จะล้มเหลวอย่างเงียบๆ แต่ด้วยระเบียบวินัยที่เปลี่ยนการแลกเปลี่ยนให้เกิดผล ตัวสร้างไม่เคยส่งกลับข้อผิดพลาด หาก init ล้มเหลว bbolt ถูกล็อก ไดเรกทอรีข้อมูลไม่สามารถเขียนได้ vector store ไม่สามารถเปิดได้ มันจะบันทึกไปยัง stderr และส่งกลับ Memory ที่ลดระดับซึ่งเมธอดทั้งหมดเป็น no-op ผู้เรียกในฝั่งผลิตจะตรวจสอบผ่าน \Healthy()\ ก่อนที่จะเชื่อถือ handle ไลบรารีสามารถ \go get\ ได้ สามารถ import ได้ในสามบรรทัด และทำงานได้ใน demo \Healthy()\ คือภาษีของระเบียบวินัยในฝั่งผลิต
รูปแบบนี้ทำให้ไลบรารีปลอดภัยที่จะฝังใน harness เอเจนต์ที่มีพิธีการเริ่มต้นระบบของตัวเอง harness เอเจนต์ที่เรียก \[graymatter.New](https://graymatter.new/)(...)\ ระหว่างบูต ไม่สนใจเส้นทางข้อผิดพลาดเพราะไม่มีเส้นทางข้อผิดพลาด และดำเนินการต่อไป จะได้ชั้นหน่วยความจำที่ทำงานได้ในเส้นทางปกติ และการสำรองแบบไม่มีหน่วยความจำเมื่อไดเรกทอรีข้อมูลเป็นแบบอ่านอย่างเดียว ไม่ว่ากรณีใด harness ก็บูตได้ นี่คือการประกอบเชิงป้องกันแบบเฉพาะที่ตัวสร้างที่ล้มเหลวดังๆ ไม่สามารถเสนอได้โดยไม่ต้องจัดการข้อผิดพลาดอย่างชัดเจนในทุกตำแหน่งที่ฝัง
การตรวจจับซ้ำซ้อนในโหมดเงา (mem9)
ทุกระบบที่จัดส่งการปราบปรามซ้ำซ้อนต้องเลือกเกณฑ์ความคล้ายคลึงโคไซน์ เหนือ 0.95 แน่นอนว่าซ้ำซ้อน ต่ำกว่า 0.7 แน่นอนว่าไม่ใช่ พื้นที่ระหว่างนั้นเป็นที่ถกเถียง และการตัดที่ถูกต้องขึ้นอยู่กับโมเดล embedding โดเมน การกระจายของคำค้นหา และต้นทุนของผลบวกลวงเทียบกับผลลบลวงในระบบเฉพาะนี้
สิ่งล่อใจนั้นท่วมท้นที่จะเลือกหนึ่งโดยอาศัยสัญชาตญาณแล้วจัดส่ง mem9 ไม่ทำเช่นนั้น มันรันคำค้นหาการตรวจจับซ้ำซ้อนสำหรับทุกข้อเท็จจริง บันทึกคะแนนโคไซน์ใน Prometheus histogram และไม่ดำเนินการใดๆ เกณฑ์ถูกเลื่อนออกไปจนกว่าข้อมูลการผลิตจะพิสูจน์ได้ "จัดส่งการสังเกต ไม่ใช่การประมาณ"
ตรรกะเดียวกันนี้ใช้กับการตัดสินใจที่ใช้เกณฑ์ทุกครั้งในทุกระบบหน่วยความจำ เกณฑ์การจัดอันดับใหม่ เกณฑ์ความเชื่อมั่นในการดึงข้อมูล เกณฑ์ความร้อนสำหรับการเลื่อนชั้น เกณฑ์ความคล้ายคลึงสำหรับการรวมข้อมูลเชิงลึก ระบบส่วนใหญ่ใน 19 ระบบจัดส่งค่าเหล่านี้โดยการเดา mem9 จัดส่งโดยเลื่อนค่าออกไป ระเบียบวินัยนี้หายากและผลลัพธ์ดีกว่า
อีกสี่รูปแบบ สั้นกว่า
การแยกฐานข้อมูลทางกายภาพต่อผู้เช่า (mem9)
แทนที่จะใช้ตัวกรอง \WHERE tenant_id = ?\ บนที่เก็บที่ใช้ร่วมกัน mem9 จัดเตรียมคลัสเตอร์ TiDB แยกต่างหากต่อผู้เช่าผ่าน TiDB Zero การแยกเป็นฝั่งเอนจินจัดเก็บข้อมูล แอปพลิเคชันไม่สามารถค้นหาข้ามผู้เช่าโดยไม่ได้ตั้งใจเพราะไม่มีที่เก็บที่ใช้ร่วมกันให้ค้นหา มันเป็นเวอร์ชันที่หยาบกว่าของสถานะปลายทางเดียวกันกับการอนุญาตชั้นจัดเก็บข้อมูล: การแยกถูกบังคับใช้ที่เอนจิน ไม่ใช่แอปพลิเคชัน ต้นทุนโครงสร้างพื้นฐานที่ในอดีตทำให้สิ่งนี้ไม่สามารถปฏิบัติได้หายไปแล้ว TiDB Zero จัดเตรียมโดยอัตโนมัติ Neon ทำเช่นเดียวกันกับ PostgreSQL Cloudflare D1 ทำเช่นเดียวกันกับ SQLite
การตกแต่งต้นทางพร้อมงบประมาณบริบทที่ชัดเจน (mem9)
หน่วยความจำที่ถูกดึงมาคือสตริง "ผู้ใช้ชอบ Postgres" ถูกต้อง กระชับ แต่เป็นไปไม่ได้ที่จะอ้างอิงโดยไม่มีบริบท mem9 แนบรอบการสนทนาต้นทางเป็นการตกแต่ง ให้คะแนนเทียบกับคำค้นหา และจำกัดด้วยงบประมาณสามเท่า: คะแนนขั้นต่ำ ขีดจำกัดต่อหน่วยความจำ ขีดจำกัดรวม เอเจนต์ที่อ่าน "ผู้ใช้ชอบ Postgres" จะได้รับรอบที่ผู้ใช้พูดว่า "เราลอง MongoDB แต่ joins ฆ่าเราเลยเปลี่ยนมาใช้ Postgres เมื่อไตรมาสที่แล้ว" ไม่ต้องเรียกเครื่องมือครั้งที่สอง การอ้างอิงอยู่ในผลลัพธ์ ข้อกำหนดเบื้องต้นนั้นเป็นสากลอยู่แล้ว: การติดตามที่มาบวกการค้นหาแบบผสมผสาน ระบบส่วนใหญ่ใน 19 ระบบสามารถนำสิ่งนี้ไปใช้ได้ภายในสองวัน
purpose.md เป็นไฟล์ที่สี่ (llm-wiki)
รูปแบบ Karpathy LLM Wiki มีสามไฟล์มาตรฐาน: แหล่งข้อมูลดิบ, ชุดทำงานของ wiki และ schema.md สำหรับกฎโครงสร้าง llm-wiki เพิ่มไฟล์ที่สี่: purpose.md ที่ผู้ใช้กรอก แทรกเข้าไปในการเรียก LLM ทุกครั้งที่ระบบทำ ทุก prompt การนำเข้า ทุก prompt การสร้าง ทุกการแชทที่ดึงข้อมูลจะอ่านมัน ผลลัพธ์คือลำดับความสำคัญของทิศทางที่คงที่ซึ่งปรับสภาพพฤติกรรมปลายน้ำทุกอย่าง LLM จะอ่าน system prompt อยู่แล้ว การเพิ่มความตั้งใจของผู้ใช้ไม่มีค่าใช้จ่ายและยกระดับทุกสิ่ง การไม่มีในระบบอื่นๆ ส่วนใหญ่นั้นอธิบายได้ยากกว่าการมีอยู่ใน llm-wiki
AGENTS.md เป็นสัญญาเอเจนต์ที่มีอำนาจ (Tolaria, OpenContext)
ที่เก็บส่วนใหญ่ที่มี \AGENTS.md\ หรือ \CLAUDE.md\ ปฏิบัติต่อมันเป็นไฟล์คำใบ้ Tolaria และ OpenContext ปฏิบัติต่อมันเป็นสัญญา โดยสนับสนุนทุกข้อผูกมัดด้วยการตรวจสอบเชิงกลไกที่ทำให้ build ล้มเหลวหากเอเจนต์ละเมิด "อย่าข้าม pre-commit hooks" ไม่ใช่คำขอที่สุภาพ มันเป็นกฎที่ CI บังคับใช้ "ความครอบคลุมการทดสอบต้องอยู่เหนือเกณฑ์" ไม่ใช่แนวทางปฏิบัติ มันเป็นเกณฑ์ที่ test runner จะ abort คำใบ้สามารถถูกละเลยได้ สัญญาที่ backed by a check ไม่สามารถละเลยได้ สองระบบทำสิ่งนี้แล้ว อีกหนึ่งระบบมันจะก้าวขึ้นมา
รูปแบบไหนจะกลายเป็นสากลต่อไป
การอนุญาตชั้นจัดเก็บข้อมูลจะกลายเป็นสากลเป็นอันดับแรก นี่คือการทำนายที่มั่นใจที่สุดในการวิเคราะห์แหล่งข้อมูลนี้ ทุกระบบหน่วยความจำที่ให้ซับเอเจนต์เข้าถึง SQL ได้ ห่างจากการฉีด prompt หนึ่งครั้งจากการละเมิดความลับโดยไม่มีการบังคับใช้ชั้นจัดเก็บข้อมูล โครงสร้างพื้นฐานมีอยู่แล้ว SQLite มี \set_authorizer\ ตั้งแต่ช่วงต้นทศวรรษ 2000 PostgreSQL RLS เป็นกระแสหลัก LanceDB และ ClickHouse มีฮุคนโยบายของตัวเอง อุปสรรคไม่ใช่ทางเทคนิค มันคือการรับรู้ second-brain ได้ให้ตัวอย่างการทำงานแล้ว API ที่จัดการรุ่นต่อไปจะลอกเลียนระเบียบวินัยนี้เพราะทางเลือกอื่นไม่สามารถป้องกันได้
การตกแต่งต้นทางจะกลายเป็นสากลเป็นอันดับสอง ข้อกำหนดเบื้องต้นเป็นสากลอยู่แล้วแล้ว การนำไปปฏิบัติคือสองคำค้นหาบวกงบประมาณ การได้รับข้อมูลฝั่งเอเจนต์นั้นมากพอที่ใครก็ตามที่จัดส่งมันก่อนใน API ที่จัดการจะดีกว่าอย่างเห็นได้ชัดในการอ้างอิงคำตอบในบทสนทนาต้นทางมากกว่าผู้ที่จัดส่งเป็นอันดับสอง แรงกดดันให้ลอกเลียนแบบสูง graymatter มีแหล่งข้อมูลต่อข้อเท็จจริง supermemory มีสายเลือด Hindsight มีการติดตามที่มาของการสนทนาที่สมบูรณ์ ใดๆ ในนี้ห่างจากรูปแบบนี้เพียง PR เดียว
ตัวสร้างไร้การดำเนินการแบบลดระดับอัตโนมัติจะกลายเป็นสากลเป็นอันดับสาม และในภาษาที่แตกต่างกัน สภาพทางวัฒนธรรมของ Go ทำให้รูปแบบนี้ปลอดภัย ผู้รับช่วงต่อรายต่อไปไม่น่าจะเป็น Python เนื่องจากวัฒนธรรมชอบ exceptions มากเกินไป แต่อาจเป็น Rust มันเป็นตัวเลือกการออกแบบ API ไลบรารี ไม่ใช่ตัวเลือกหน่วยความจำ และมันจะแพร่กระจายไปทุกที่ที่ "ความสวยงามของ demo บวกระเบียบวินัยในการผลิต" เป็นการแลกเปลี่ยนที่ถูกต้อง
การปรับใช้โหมดเงาคือตัวเก็งที่มืด ง่ายทางเทคนิค ยากทางวัฒนธรรม หากรุ่นที่สองวัดปริมาณเกณฑ์ก่อนกำหนดการ รูปแบบจะก้าวขึ้นมาทันที และรุ่นที่สามและสี่จะตามมาภายในรอบการเปิดตัวเดียว เพราะหลักสรีรศาสตร์ทางวิศวกรรมไม่อาจโต้แย้งได้เมื่อสาธิตแล้ว
สี่รูปแบบที่เหลือแต่ละรูปแบบขึ้นอยู่กับรูปร่างการปรับใช้เฉพาะที่กลายเป็นเรื่องธรรมดามากขึ้น การป้องกัน race จะกลายเป็นสากลเมื่อระบบมากขึ้นมีความขนานหลายการสนทนา การแยกทางกายภาพต่อผู้เช่าจะกลายเป็นสากลเมื่อลูกค้าองค์กรที่มีข้อกำหนดเริ่มขอ AGENTS.md ในฐานะสัญญาจะกลายเป็นสากลเมื่อกรอบ "เอเจนต์คือเพื่อนร่วมงาน" กลายเป็นคำอุปมาหลักของ harness ไม่มีรูปแบบใดเป็นไปไม่ได้ ไม่มีรูปแบบใดแน่นอน
บทสรุป
เส้นด้ายที่เชื่อมโยงทั้งแปดรูปแบบคือตำแหน่งเดียวกัน: ชั้นแอปพลิเคชันไม่ใช่ขอบเขตการแยกที่เชื่อถือได้ การอนุญาตชั้นจัดเก็บข้อมูลคือการแสดงออกต่อเอเจนต์ ฐานข้อมูลทางกายภาพต่อผู้เช่าคือการแสดงออกต่อผู้เช่า AGENTS.md ในฐานะสัญญาคือการแสดงออกต่อพฤติกรรมเอเจนต์ การวนซ้ำครั้งต่อไปของคลังข้อมูลนี้ ในการทำนายนี้ จะมีรูปแบบสากลใหม่ภายใต้ชื่อนั้น
บทความก่อนหน้านี้ให้เหตุผลว่าเอเจนต์ควรถือเครื่องมือและตัดสินใจว่าจะดึงข้อมูลอะไร บทความนี้เกี่ยวกับสิ่งที่ยึดถือเมื่อเอเจนต์เปลี่ยนเครื่องมือเหล่านั้นไปยังที่ที่คุณไม่ได้คาดหวัง รูปแบบสากลทั้งหกคือฉันทามติ แปดรูปแบบนี้คือตัวชี้วัดชั้นนำว่าฉันทามติจะเคลื่อนไปทางไหนต่อไป การอนุญาตชั้นจัดเก็บข้อมูลคือผู้นำของผู้นำ และต้นทุนของการพลาดมันคือต้นทุนแบบที่ปรากฏบน Hacker News
