- AGENTS.md ทำหน้าที่เสริม README และเป็น ไฟล์เฉพาะที่เก็บบริบทและคำแนะนำ ที่เอเจนต์เขียนโค้ด AI ต้องใช้เมื่อลงมือทำงานในโปรเจกต์
- ขณะนี้มีการใช้งานใน โปรเจกต์โอเพนซอร์สมากกว่า 20,000 โปรเจกต์ เพื่อจัดระเบียบข้อมูลอย่างการ build/test/code style ที่ไม่จำเป็นสำหรับมนุษย์ แต่สำคัญสำหรับเอเจนต์
- ให้คำแนะนำสำหรับเอเจนต์ไว้ใน ตำแหน่งที่ชัดเจนและคาดเดาได้ ช่วยให้ README กระชับ ขณะเดียวกันก็เพิ่มประสิทธิภาพการทำงานร่วมกัน
- AGENTS.md ไฟล์เดียวรองรับเอเจนต์และเครื่องมือได้หลากหลาย และในโมโนรีโปขนาดใหญ่ก็สามารถใช้ AGENTS.md แยกตามแต่ละซับโปรเจกต์ ได้
- เป็น มาตรฐานแบบเปิด ที่เกิดจากความร่วมมือของหลายอีโคซิสเต็ม เช่น OpenAI Codex, Cursor, Google Jules
Why AGENTS.md?
- README.md เป็นเอกสารสำหรับมนุษย์ ใช้สำหรับ quick start, คำอธิบายโปรเจกต์ และแนวทางการมีส่วนร่วม
- AGENTS.md เป็นเอกสารเสริมสำหรับเอเจนต์ ที่เก็บบริบทเชิงรายละเอียดอย่างกฎ build/test/code เพื่อไม่ให้ README ซับซ้อนเกินไป
- เหตุผลที่แยกเป็นไฟล์ต่างหาก
- ให้ ตำแหน่งคำแนะนำที่คาดเดาได้ สำหรับสิ่งที่เอเจนต์ต้องอ้างอิง
- ทำให้ README ยังคงกระชับโดยยึดมนุษย์ผู้ร่วมพัฒนาเป็นศูนย์กลาง
- ให้ คำแนะนำเฉพาะสำหรับเอเจนต์ที่มีความละเอียดสูง และช่วยเสริมเอกสารเดิม
- เลือกใช้ชื่อที่เป็น มาตรฐานแบบเปิดที่ใครก็ใช้ได้ ไม่ใช่ฟอร์แมตแบบปิดของผู้ให้บริการใดผู้ให้บริการหนึ่ง
- AGENTS.md เดียว สามารถใช้งานร่วมกับเอเจนต์เขียนโค้ด AI และเครื่องมือหลายตัวได้
How to use AGENTS.md?
- 1. สร้างไฟล์ AGENTS.md
- วางไว้ที่รูตของรีโพซิทอรี (เอเจนต์หลายตัวรองรับการสร้างให้อัตโนมัติ)
- 2. เขียนหัวข้อสำคัญ
- ภาพรวมของโปรเจกต์
- คำสั่ง build และ test
- แนวทาง code style
- วิธีการทดสอบ
- ข้อพิจารณาด้านความปลอดภัย
- 3. ใส่คำแนะนำเพิ่มเติม
- สิ่งที่ต้องการสื่อสารกับสมาชิกทีม เช่น กฎ commit/PR, ข้อควรระวังด้านความปลอดภัย, ชุดข้อมูลขนาดใหญ่, ขั้นตอนการ deploy
- 4. รองรับโมโนรีโป
- สามารถวาง AGENTS.md แยกตามแต่ละแพ็กเกจได้
- เอเจนต์จะอ่าน ไฟล์ที่อยู่ใกล้ที่สุด และปฏิบัติตามคำแนะนำที่เหมาะกับซับโปรเจกต์นั้น
- ตัวอย่าง: รีโพซิทอรีของ OpenAI มี AGENTS.md อยู่ 88 ไฟล์
FAQ
- รายการที่จำเป็น: ไม่มี สามารถใช้รูปแบบ Markdown ทั่วไปได้อย่างอิสระ
- เมื่อเกิดความขัดแย้ง: AGENTS.md ที่ใกล้ที่สุดมีลำดับความสำคัญก่อน และพรอมป์ต์ที่ผู้ใช้ระบุไว้อย่างชัดเจนจะถูกใช้เป็นลำดับสุดท้าย
- มีการรันอัตโนมัติหรือไม่: เอเจนต์สามารถรันคำสั่งทดสอบที่ระบุไว้ในไฟล์เพื่อพยายามแก้ไขข้อผิดพลาดได้
- อัปเดตได้หรือไม่: เปลี่ยนแปลงได้ตลอดเวลา และควรดูแลในฐานะ เอกสารที่มีชีวิต
- การย้ายจากเอกสารเดิม: เปลี่ยนชื่อไฟล์แล้วคงความเข้ากันได้ด้วย symbolic link
mv AGENT.md AGENTS.md && ln -s AGENTS.md AGENT.md
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สำหรับโปรเจ็กต์เล็ก ๆ แค่ไฟล์ .md ไฟล์เดียวก็เพียงพอ แต่จากประสบการณ์แล้วสำหรับโปรเจ็กต์ที่ซับซ้อน โครงสร้างโฟลเดอร์แบบลำดับชั้นพร้อม
index.mdมีประสิทธิภาพกว่ามากโครงสร้างที่มี
index.mdและไฟล์ลูกอย่างauth.md,performance.mdดูแลรักษาง่าย และช่วยให้ LLM หรือเอเจนต์ดึงเฉพาะบริบทที่เกี่ยวข้องได้โดยไม่สิ้นเปลืองโทเคนโดยไม่จำเป็นไฟล์
.docsจึงเหมาะทั้งกับมนุษย์และ LLM และในindex.mdก็ยังใส่คำแนะนำสั้น ๆ สำหรับแต่ละไฟล์รวมถึงแนวทางการจัดระเบียบได้ด้วยอย่างไรก็ดี ชื่ออย่าง
.agentsดูสื่อความหมายน้อยกว่า.codebotsหรือ.contextคิดว่าไฟล์และไดเรกทอรีสำคัญ ๆ ไม่จำเป็นต้องซ่อน
โดยเฉพาะเอกสาร ถ้าซ่อนไว้กลับยิ่งทำให้ไม่โปร่งใส ไม่แน่ใจว่าเป็นเพราะธรรมเนียมหรือไม่ แต่รูปแบบนี้ไม่ใช่แพตเทิร์นที่ดี
เลยลองคิดว่าชื่ออย่าง
robot_docsจะเป็นอย่างไรจริง ๆ แล้วข้อมูลพวกนี้ก็ทับซ้อนกับสิ่งที่ผู้ร่วมพัฒนาสนใจอยู่แล้ว เลยคิดว่าโดยหลักควรอยู่ใน
CONTRIBUTING.mdโครงสร้างนี้ให้ความรู้สึกเหมือนเอกสารแนวทางการออกแบบซอฟต์แวร์/สไตล์การเขียนโค้ดสำหรับทั้งมนุษย์และหุ่นยนต์
ฉันใส่ไฟล์
.mdแบบนี้ไว้ในโฟลเดอร์docs/และให้ Claude Code เขียนโดยตรงAGENTS.mdและCLAUDE.mdควรมีไว้เพื่อหุ่นยนต์เท่านั้น และไม่ว่าจะใช้ไฟล์ใหญ่ไฟล์เดียวแบ่งส่วนด้วยหัวข้อ h2 หรือจะแยกเป็นหลายไฟล์ ต่างก็มีข้อดีข้อเสียของตัวเองยังมีฟอร์แมตเอกสารสถาปัตยกรรมอย่าง Arc42 ที่รองรับทั้งสองแบบ
แทนที่จะอ้างอิงส่วนใดส่วนหนึ่งใน Markdown ขนาดใหญ่ การแยกเป็นไฟล์ต่างหากแล้ว @mention จะง่ายกว่าและลดความผิดพลาดได้
เวลาต้องโฟกัสเฉพาะบางส่วน การแยกเป็นไฟล์เล็ก ๆ ก็เหมาะกับโค้ดเอเจนต์มากกว่าเช่นกัน
ไฟล์เล็ก ๆ ยังสะดวกกว่าตอนรีวิว diff/PR ด้วย
คุณสามารถมีไฟล์
AGENTS.mdหลายไฟล์ภายในโค้ดเบสเดียวกันได้ถ้า tooling ถูกทำให้สามารถอ่านทั้ง
AGENTS.mdในไดเรกทอรีปัจจุบันและในรูทไดเรกทอรีได้ ข้อมูลก็จะอยู่ใกล้กับโค้ด ซึ่งสามารถใช้ควบคู่กับแนวทางที่ต้องการได้ฉันก็ใช้โครงสร้างคล้ายกัน และได้ผลค่อนข้างดีจากการเพิ่มคำแนะนำสั้น ๆ รายไฟล์ลงใน
index.mdตอนนี้ก็กำลังลองวิธีใส่ไฟล์กฎพฤติกรรมที่ต้องการรายไดเรกทอรี เช่น
rules.mdตัวอย่างเช่น ในไดเรกทอรีที่รวมบริการหลายแบบอย่าง
realtime-service.tsและqueue-service.tsก็จะวางrules.mdไว้ข้าง ๆจากนั้นระบุไฟล์กฎนี้ในพรอมป์ต์เพื่อสร้างสิ่งใหม่ ๆ ได้ง่ายขึ้น แต่ชื่อยังน่าจะต้องคิดต่ออีกหน่อย
ตอนนี้เป็นช่วงเปลี่ยนผ่านที่มนุษย์ต้องเขียนคำแนะนำพิเศษเพิ่มขึ้นจากที่มนุษย์เองต้องใช้ เพื่อให้เอเจนต์เข้าใจโค้ดเบส
ฉันคิดว่าอีกไม่นานสิ่งนี้จะไม่จำเป็น
ถ้าเอกสารโปรเจ็กต์ของเราถูกเขียนไว้อย่างครบถ้วนตั้งแต่แรก เนื้อหาใน
AGENTS.mdก็น่าจะถูกรวมอยู่ในนั้นได้ทั้งหมดเราควรเขียนเอกสารสำหรับมนุษย์เสมอ และจุดแข็งของ LLM ก็คือการอ่านสิ่งที่มนุษย์เขียนได้
ฉันคิดว่านี่คือมุมมองที่ควรใช้ในการออกแบบ
มันมีประโยชน์ไม่ใช่แค่เพื่อทำความเข้าใจโค้ดเบส แต่ยังใช้ระบุกฎด้านสไตล์เฉพาะได้ด้วย เช่น จะเขียนเทสต์ด้วยไลบรารี
assertตัวไหน ห้ามใส่คอมเมนต์ ต้องใช้ structured logging ฯลฯจริง ๆ แล้วอาจมีประโยชน์กับโปรเจ็กต์ใหม่ที่แทบยังไม่มีโค้ดมากกว่าเสียอีก
คาดว่าในอนาคตจะมีการนำกฎที่เครื่องอ่านได้มาใช้ในสังคมมากขึ้น
ตัวอย่างเช่น รถยนต์ไร้คนขับกับกฎหมายจราจร ซึ่งแม้แต่มนุษย์เองยังตีความป้ายที่ต้องอาศัยบริบทได้ยาก เช่น “ห้ามเลี้ยวขวาไฟแดง ในวันเปิดภาคเรียน 7–9 น.” เครื่องก็ยิ่งลำบากกว่า
สุดท้ายหน่วยงานรัฐคงต้องลดการพึ่งพาบริบท หรือเปลี่ยนเป็นสัญญาณที่เครื่องอ่านได้ เช่น QR code
ถ้าไม่มีการเปลี่ยนแปลงแบบนี้ เครื่องก็จะละเมิดกฎกันบ่อยขึ้น
คิดว่าในพื้นที่อย่าง business logic ต่อไปก็ยังจำเป็นต้องมีคำแนะนำเฉพาะสำหรับเอเจนต์
เครื่องไม่มีทางรู้ได้เองว่าเรากำลังสร้างอะไร เจตนาคืออะไร หรือเป้าหมายสุดท้ายของโปรเจ็กต์คืออะไร ถ้าไม่มีคนอธิบายอย่างเป็นรูปธรรม
แม้แต่เรื่องสถาปัตยกรรมก็เช่นกัน แต่ละคนมีเกณฑ์ต่างกัน ต้องมีภาพโครงสร้างอยู่ในหัวถึงจะเข้าใจเวลามองการเปลี่ยนแปลงจริง ๆ และตรงนี้แหละคือคอขวดตัวจริง
โดยรวมเห็นด้วย แต่บางครั้งก็รู้สึกอยากบังคับให้ข้อมูลบางอย่างถูกใส่เข้าคอนเท็กซ์ทุกครั้ง เช่น สิ่งที่อยากให้มีอยู่ในคอนเท็กซ์เสมอ ก็คงอยากแยกไว้เป็นไฟล์ต่างหาก
ถ้าไม่บันทึกกฎและสมมติฐานที่เราคิดกันโดยปริยายไว้เป็นเอกสาร LLM ก็จะไม่มีทางรู้
แม้บางส่วนอาจอนุมานจากโค้ดได้ แต่ไม่มีทางครบ 100% ดังนั้นการเขียนข้อกำหนดไว้อย่างชัดเจนจึงสำคัญ
AGENTS.mdสุดท้ายแล้วก็ทำหน้าที่คล้ายREADME.mdแต่ดึงกระแสจนทำให้คนยอมเติมเนื้อหาจริง ๆ ซึ่งน่าสนใจมากคนมักขี้เกียจเขียนเอกสารให้คนอื่นอ่าน แต่พอเป็นเพื่อหุ่นยนต์กลับตั้งใจเขียนกันเต็มที่ ชวนให้รู้สึกแปลกดี
ปรากฏการณ์นี้คล้ายกับการออกแบบตามหลักสรีรศาสตร์เพื่อคนกลุ่มเล็ก แต่สุดท้ายกลับทำให้ด้ามจับเหมาะกับทุกคนมากขึ้น
ผมกลับมองว่าเป็นเพราะคนไม่อ่านเอกสารต่างหาก จึงไม่มีแรงจูงใจให้ใครเขียน
แต่
CLAUDE.mdสำหรับเอเจนต์ ถ้าเขียนครั้งเดียวแล้วจะมีเอเจนต์ 1000 ตัวมาอ่านต่อทันที มันก็เลยน่าเขียนขึ้นมาหรือจริง ๆ แค่ใส่สิ่งจำเป็นขั้นต่ำใน
README.mdก็พอแล้วไม่ใช่หรือในความเป็นจริง ต่อให้เป็นเอเจนต์เองก็อาจไม่อ่านเอกสารนี้ หรือถ้าต้องสั่งเพิ่มอีกไม่กี่รอบก็อาจลืมทั้งหมดอยู่ดี
สถานการณ์ตอนนี้คือผู้คนกำลังพยายามดึงนักพัฒนาที่เป็นมนุษย์ออกจากกระบวนการพัฒนาให้มากที่สุด รวมถึงตัวเองด้วย จึงทำให้เอเจนต์จำเป็นต้องมีคำแนะนำที่เหมาะสมติดตัวไว้
เพราะความต้องการที่จะลดบทบาทมนุษย์ออกจากการพัฒนาซอฟต์แวร์ทั้งหมดกำลังเพิ่มขึ้น
มีการพูดติดตลกว่าเดี๋ยวนี้บรรยากาศโดยรวมคือ vibe coding
และเหมือนเคยมีความเห็นมาก่อนด้วยว่า การเขียนเอกสารสำหรับบอตสุดท้ายก็ไม่ได้ต่างจากการเขียนเอกสารที่ดีอยู่แล้ว
สุดท้ายมันให้ความรู้สึกเหมือนบอกแค่ว่า “สร้างไฟล์
AGENTS.mdแล้วใส่เวทมนตร์ลงไป” จากนั้นค่อยลิงก์ไปยังเว็บไซต์จริงอีกทีในกรณีของฉัน ฉันกำลังพัฒนาโค้ดดิ้งเอเจนต์ที่ดูแลรีโพซิทอรีมากกว่า 5,000 แห่ง
สถานะของเอเจนต์ถูกเก็บไว้ในไดเรกทอรีซ่อน
.agentซึ่งมีทั้งโฟลเดอร์การตั้งค่าตามบทบาทของแต่ละเอเจนต์และคำสั่งที่ชัดเจนแยกตามบทบาทในโฟลเดอร์โปรเจ็กต์จะมีโฟลเดอร์
agentsและแยกหลายไฟล์ตามบทบาทในรูปแบบ<Role> <instruction>เอเจนต์จะอ่านเฉพาะไฟล์ที่กำหนดบทบาทของตัวเอง และเก็บสถานะไว้ในโฟลเดอร์
dot<coding agent name>การเริ่มต้นทำผ่าน
/initและแทนที่จะสร้างดัชนีโค้ดทั้งรีโพแบบตรง ๆ จะสร้าง high-level summary ที่สรุปทั้งสถาปัตยกรรมและตรรกะของระบบสรุปนี้จะแสดงเป็น “ghost comments” ที่เปิดปิดได้ในเอดิเตอร์ และเป็นเมทาดาทาที่ไม่ถูก commit ลงในโค้ดจริง
มีระบบแม็ปปิงที่ละเอียดซึ่งเชื่อมแต่ละสรุปเข้ากับบรรทัดโค้ดได้อย่างแม่นยำ
ตอนแรกฉันลองใช้ RAG กับโค้ดโดยตรงแต่ไม่ได้ผลตามที่ต้องการ จึงเปลี่ยนมาใช้โครงสร้างปัจจุบัน
ตอนนี้ใช้โมเดลค้นหาแบบไฮบริดที่ผสานการค้นหาเชิงไวยากรณ์อย่างรวดเร็วบน AST เข้ากับการสำรวจเชิงความหมายจากสรุป (RAG)
เช่น ถ้าถามว่า “ระบบยืนยันตัวตนของแอปนี้ทำงานอย่างไร?” การค้นหาเชิงไวยากรณ์จะเจอฟังก์ชันที่มีคำอย่าง
loginเท่านั้น แต่การค้นหาเชิงความหมายจะใช้สรุปเพื่อทำความเข้าใจ flow การยืนยันตัวตนทั้งหมดในเชิงเรื่องเล่า และเชื่อมโยงข้อมูลที่กระจายอยู่ตามไฟล์ต่าง ๆ ได้ ราวกับเวทมนตร์เพิ่มเติมจากนั้น ยังสร้างลำดับชั้นของสรุปได้ด้วย ทั้งแบบ B-tree หรือ tree ทั่วไป
กล่าวคือ มี summary สำหรับแต่ละเมธอด/คลาส/โมดูล และให้แต่ละชั้นชี้ไปยังชั้นที่ลึกลงไป
RAG จึงสามารถไล่สำรวจลึกเท่าที่จำเป็นตาม semantic query ได้ โดยแต่ละขั้นจะสรุปชั้นล่างลงมาเพื่อลดปริมาณข้อมูล แต่ยังคงความหมายที่จำเป็นไว้
วิธีนี้มีประสิทธิภาพเป็นพิเศษเมื่อโค้ดมีการทำ abstraction ที่ดี
ตัวอย่างเช่น ฟังก์ชันอย่าง
add(n1, n2)ที่ความหมายชัดเจนจากชื่อเพียงอย่างเดียว อาจไม่จำเป็นต้องรู้ implementation จริง แต่ฟังก์ชันในโลกจริงมักมีหลายบทบาท เช่น logging หรือ cache จึงอาจต้องใส่โค้ดจริงเข้าไปในคอนเท็กซ์ตามสถานการณ์อยากฟังคำอธิบายเพิ่มอีกหน่อย
รู้สึกเหมือนมนุษย์กำลังถูกค่อย ๆ บังคับให้เขียนเอกสารโปรเจ็กต์ให้ดีขึ้น
พูดเล่นแต่ก็จริง เพราะนี่คือประเด็นที่ฉันใช้ไปคุยกับทีม
ถึง LLM อาจไม่ได้เพิ่มผลิตภาพอย่างมหาศาลจริง ๆ แต่ผลลัพธ์อย่างหนึ่งคือมันทำให้เราจัดทำเอกสารได้ดีขึ้นมาก
"Mission. Fucking. Accomplished." xkcd 810
ฉันยังไม่แน่ใจว่าจำเป็นต้องแยก
README.mdกับAGENTS.mdออกจากกันจริงหรือไม่ตามบทสรุปนี้ เหตุผลที่ควรแยกคือ
ส่วนเหตุผลที่ไม่ควรแยกคือ
README.mdตอนนี้ให้ความรู้สึกเหมือนเป็นหน้า marketing/landing page ไปแล้ว ส่วนAGENTS.mdและCLAUDE.mdคือที่สำหรับไปเอาเนื้อหาจริงอย่างโค้ด สถาปัตยกรรม และวิธีใช้งานตอนอ่านตัวอย่าง ฉันก็คิดแบบเดียวกัน และจริง ๆ ก็รู้สึกว่าแค่มี
README.mdที่ดีสักไฟล์เดียวซึ่งรวมทุกอย่างไว้ก็น่าจะพอแล้วREADMEมีไว้สำหรับมนุษย์ ส่วนAGENTS.mdและไฟล์ทำนองเดียวกันมีไว้สำหรับ LLMวิธีใช้งาน/ติดตั้งอยู่ใน readme ส่วนวิธีคอมไพล์/ทดสอบ การตัดสินใจด้านสถาปัตยกรรม มาตรฐานการเขียนโค้ด และโครงสร้างรีโพ จะถูกรวบรวมไว้ในเอกสารสำหรับเอเจนต์
ต้องคิดถึงข้อจำกัดด้านความจุของ context ใน LLM ด้วย
README.mdมักมีเนื้อหาเยอะเกินกว่าจะใส่ทั้งหมดลงใน context ได้ใน
AGENT.mdจึงใส่เฉพาะคำสั่งสำคัญอย่างการทดสอบและคำสั่ง build ที่ LLM จำเป็นต้องรู้แบบกระชับแม้อาจมีบางส่วนซ้ำกับ README แต่ก็อยากหลีกเลี่ยงการส่งเนื้อหาที่ไม่จำเป็นซ้ำ ๆ เข้า context
คำสัญญาของ AI ไม่ใช่ว่าเราไม่จำเป็นต้องยึดติดกับฟอร์แมตที่แม่นยำ แค่เขียนในแบบที่ต้องการแล้วเครื่องจะปรับตัวเองให้ได้หรอกหรือ?
ในทางปฏิบัติ สิ่งที่ถูกทำให้เป็นมาตรฐานมีแค่ชื่อไฟล์ ส่วนเนื้อหาไม่ได้บังคับรูปแบบใด ๆ และให้แต่ละคนเขียนในแบบที่ต้องการได้ ซึ่งก็ดูเป็นทางเลือกที่ถูกต้อง
AGENTS.mdเป็น Markdown มาตรฐาน ดังนั้นจะใช้หัวข้อแบบไหนก็ได้ และเอเจนต์จะเป็นฝ่าย parse ข้อความเองถึงอย่างนั้น โครงสร้างและรูปแบบในระดับหนึ่งก็ยังมีความสำคัญ
แม้จะไม่ถึงขั้นต้องเป๊ะเหมือนไวยากรณ์ของโค้ดก็ตาม
สุดท้ายแล้วก็กลับมาที่เรื่องเดิม คือเนื้อหาต้องเขียนให้ชัดเจน
ยิ่งเอกสารยาว การใช้แนวทางเชิงโครงสร้างก็ยิ่งเอื้อต่อการดูแลรักษาในมุมของมนุษย์
เอเจนต์แต่ละตัวที่ใช้ ไม่ว่าจะ Claude Code, Gemini หรือ Aider ต่างก็ใช้ชื่อไฟล์ไม่เหมือนกัน
ถ้ามีการทำมาตรฐานก็คงดี แต่ตอนนี้เลยยอมรับภาระใช้ ruler เพื่อสร้างหลายฟอร์แมตให้อัตโนมัติ
โดยเฉพาะอย่างยิ่ง วิธีที่เอเจนต์แต่ละตัวใช้ไฟล์ตั้งค่า MCP ก็ยังต่างกันมาก จึงคิดว่าการทำมาตรฐานคงไม่เกิดขึ้นในเร็ววัน
ruler
ถ้ามองแบบประชดนิด ๆ ก็อาจเป็นเพราะมันช่วยสร้าง vendor lock-in
การทำมาตรฐานอาจนำไปสู่การกลายเป็น commodity ซึ่งผู้ให้บริการน่าจะไม่ค่อยอยากให้เกิด
Jules ใช้
AGENTS.mdจึงแสดงให้เห็นว่า Google กำลังเข้าร่วมมาตรฐานนี้ถ้า Gemini Code Assist ยังเดินหน้าต่อ ก็คาดว่าน่าจะรองรับ
AGENTS.mdด้วยในเอกสารของ Aider เหมือนจะไม่ได้ระบุชื่อไฟล์เฉพาะไว้ ถ้ามีลิงก์ก็น่าจะช่วยแชร์หน่อย
ดูเหมือนว่า Anthropic จะเป็นรายเดียวที่ยังไม่รองรับชื่อไฟล์มาตรฐานอย่างเป็นทางการ
น่าเสียดายนิดหน่อยที่เครื่องมืออย่าง ruler กลายเป็นสิ่งจำเป็นจริง ๆ
เป็นเว็บไซต์ที่ให้ความรู้สึกแปลก ๆ
สงสัยว่า OpenAI ทำขึ้นมาเพื่อดึงทราฟฟิกและวางตำแหน่งทางการตลาดหรือเปล่า
ในทางปฏิบัติ มันไม่ได้กำหนดฟอร์แมตอะไรเลย แค่กำหนดชื่อไฟล์เท่านั้น
ที่ Anthropic/Claude ไม่อยู่ในรายการก็สะดุดตาเหมือนกัน แม้จะใช้วิธี symbolic link ให้
CLAUDE.mdชี้ไปที่AGENTS.mdก็ยังพอได้จริง ๆ แล้วเป็นของ sourcegraph และมีมาตั้งแต่เดือนพฤษภาคม
ก่อนหน้านี้ใช้
agent.mdและตอนนี้เปลี่ยนเป็นagents.mdพร้อม 301 redirect แล้วดูได้จากลิงก์เก่า
และมีประกาศอย่างเป็นทางการด้วย
ดูเหมือนล่าสุดจะไปจับมือเป็นพาร์ตเนอร์กับ OpenAI
ที่น่าสนใจคือ ตอนแรกเป็น
agent.mdแต่ตอนนี้เปลี่ยนเป็นagents.mdเหตุผลที่ Claude ไม่อยู่ในรายชื่อก็เพราะมีแค่ Claude เท่านั้นที่ยังไม่รองรับกติกาชื่อไฟล์มาตรฐานนี้