การปรับแต่ง Agentic Engine (AEO)

 (addyosmani.com)
12 คะแนน โดย GN⁺ 14 일 전 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • วิธีที่ AI coding agent ใช้บริโภคเอกสารนั้นแตกต่างจากมนุษย์โดยพื้นฐาน ดังนั้น การปรับแต่งโดยยึดมนุษย์เป็นศูนย์กลางเพียงอย่างเดียวจะทำให้ทราฟฟิก AI จำนวนมากขึ้นเรื่อย ๆ หลุดหายไปโดยไม่ถูกเครื่องมือวิเคราะห์จับได้
  • เอเจนต์จะดึงเอกสารด้วย HTTP request เพียงครั้งเดียว นับจำนวนโทเค็น แล้วหากไม่พอดีกับ context window ก็จะทิ้งไปแบบเงียบ ๆ ดังนั้น ตัวชี้วัดวิเคราะห์แบบเดิมอย่างความลึกของการเลื่อนหน้า เวลาที่อยู่บนหน้า หรือการคลิก จะไม่ถูกบันทึกเลย
  • เพื่อตอบโจทย์นี้ จึงมีแนวคิด Agentic Engine Optimization (AEO) ซึ่งเป็นการจัดโครงสร้าง ฟอร์แมต และส่งมอบเอกสารให้เอเจนต์นำไปใช้ได้จริง
  • แกนสำคัญของ AEO คือ การค้นพบได้ง่าย, การพาร์สได้ง่าย, ประสิทธิภาพด้านโทเค็น, การส่งสัญญาณความสามารถ, การควบคุมการเข้าถึง และหากพลาดข้อใดข้อหนึ่ง เอเจนต์อาจข้ามคอนเทนต์นั้นไปหรือสร้างผลลัพธ์ที่ผิดพลาด
  • ทีมที่ลงมือเร็วจะได้เปรียบเพราะ API ของตนมีโอกาสถูกเอเจนต์แนะนำและนำไปผสานใช้งานมากกว่า และการทำเอกสารสำหรับเอเจนต์ก็ลงท้ายด้วยการทำให้เอกสารดีขึ้นสำหรับผู้อ่านที่เป็นมนุษย์ด้วย

AEO คืออะไร

  • Agentic Engine Optimization (AEO) คือแนวปฏิบัติในการจัดโครงสร้าง ฟอร์แมต และส่งมอบคอนเทนต์เชิงเทคนิค เพื่อให้ AI coding agent นำไปใช้ได้จริง
  • หาก SEO คือการปรับแต่งให้เข้ากับ search crawler และพฤติกรรมการคลิกของมนุษย์ AEO ก็มุ่งเป้าไปที่ผู้บริโภคแบบใหม่ คือ AI agent ที่ดึงคอนเทนต์ พาร์ส และให้เหตุผลได้เองโดยอัตโนมัติ
  • ปัจจัยหลักที่ต้องคำนึงถึง
    • Discoverability – เอเจนต์หาเอกสารเจอได้หรือไม่ โดยไม่ต้องพึ่ง JavaScript rendering
    • Parsability – เครื่องอ่านได้หรือไม่ โดยไม่ต้องตีความเลย์เอาต์เชิงภาพ
    • Token efficiency – ใส่เข้าไปใน context window ของเอเจนต์ทั่วไปได้ครบโดยไม่ถูกตัดหรือไม่
    • Capability signaling – API บอกหรือไม่ว่า "ทำอะไรได้" ไม่ใช่แค่ "เรียกใช้อย่างไร"
    • Access control – robots.txt อนุญาตทราฟฟิก AI จริงหรือไม่

วิธีที่เอเจนต์อ่านเอกสาร

  • รูปแบบของมนุษย์: เข้ามาที่หน้าโฮมของเอกสาร เลื่อนไปยังแต่ละส่วน กวาดดูหัวข้อ รันตัวอย่างโค้ด คลิกลิงก์ภายใน 2–3 หน้า อยู่ต่อเซสชัน 4–8 นาที → เครื่องมือวิเคราะห์บันทึกได้ทั้งหมด
  • รูปแบบของเอเจนต์: จากงานวิจัยที่วิเคราะห์ HTTP traffic ของ coding agent หลัก 9 ตัว เช่น Claude Code, Cursor, Cline, Aider, VS Code, Junie พบว่า การสำรวจหลายหน้าถูกบีบอัดเหลือ HTTP request เพียง 1–2 ครั้ง
    • รับทั้งหน้าด้วยคำขอ GET เพียงครั้งเดียวแล้วจบ ทำให้แนวคิดเรื่อง "user journey" ยุบเหลือเป็นเหตุการณ์เดียวฝั่งเซิร์ฟเวอร์
    • ความลึกการเลื่อนหน้า เวลาบนหน้า การคลิกปุ่ม การทำ tutorial จบ การย้ายลิงก์ หรือการโต้ตอบกับฟอร์ม ซึ่งเป็น event ฝั่งไคลเอนต์ทั้งหมดจะมองไม่เห็นทันที

ลายนิ้วมือของทราฟฟิก AI

  • มี signature เฉพาะที่ใช้ระบุทราฟฟิกจากเอเจนต์ได้ใน server log
    • Aider: Headless Chromium (Playwright), On-demand GET, Mozilla/Safari แบบเต็มใน user-agent
    • Claude Code: Node.js/Axios, On-demand GET, axios/1.8.4
    • Cline: curl, GET + กวาดหา OpenAPI/Swagger, curl/8.4.0
    • Cursor: Node.js/got, HEAD probe → GET, got (sindresorhus/got)
    • Junie: curl, GET หลายหน้าแบบลำดับต่อเนื่อง, curl/8.4.0
    • OpenCode: Headless Chromium (Playwright), On-demand GET
    • VS Code: Electron/Chromium, สไตล์ Chromium ที่มี Electron marker
    • Windsurf: Go/Colly, colly
  • นอกจาก coding agent แล้ว บริการเว็บ AI assistant อย่าง ChatGPT, Claude, Google Gemini, Perplexity ก็สร้าง server-side fetch และมีลายนิ้วมือเฉพาะเช่นกันเมื่อผู้ใช้แชร์ URL

ปัญหาโทเค็น: เอกสารอาจมองไม่เห็นสำหรับเอเจนต์

  • เอเจนต์ส่วนใหญ่มี ขีดจำกัดใช้งานจริงอยู่ราว 100K–200K โทเค็น และการจัดการ context เป็นข้อจำกัดที่ทำงานอยู่ตลอดเวลา
  • ตัวอย่างจากงานวิจัย: Cisco Secure Firewall Management Center REST API Quick Start Guide (Version 10.0) มีขนาด 193,217 โทเค็น หรือประมาณ 718,000 ตัวอักษร ซึ่งเอกสารเพียงหน้าเดียวก็ใช้จนหมดหรือเกิน context window ที่เอเจนต์ส่วนใหญ่มี
  • เมื่อเอกสารยาวเกินไป อาจเกิดกรณีต่อไปนี้
    • ถูกตัดแบบเงียบ ๆ จนข้อมูลสำคัญหายไป
    • ถูกข้ามไปเพราะเอเจนต์เลือกเอกสารที่สั้นกว่า
    • ความพยายามแบ่งเป็น chunk ทำให้เกิดดีเลย์และเพิ่มพื้นผิวความผิดพลาด
    • fallback ไปใช้ความรู้เชิงพารามิเตอร์ — หรือก็คือสร้าง hallucination
  • สรุปคือ จำนวนโทเค็นได้กลายเป็นตัวชี้วัดระดับแรกของเอกสาร และจำเป็นต้องติดตามโทเค็นรายหน้า

เป้าหมายเชิงปฏิบัติเรื่องโทเค็น

  • หน้า Quick start / getting started: ต่ำกว่า 15,000 โทเค็น
  • หน้า API reference รายหน้า: ต่ำกว่า 25,000 โทเค็น
  • API reference ทั้งชุด: ให้แบ่งเป็น chunk ตาม resource/endpoint ไม่ใช่ตามตัวผลิตภัณฑ์
  • คู่มือเชิงแนวคิด: ต่ำกว่า 20,000 โทเค็น และเชื่อมรายละเอียดเพิ่มเติมด้วยลิงก์แทนการ embed

สแต็ก AEO: สิ่งที่ต้องสร้างจริง

  • AEO ไม่ใช่เทคนิคเดี่ยว แต่เป็น ชุดของสัญญาณและมาตรฐานที่เรียงเป็นชั้นตั้งแต่ฐานจนถึงผิวหน้า

Layer 1: การควบคุมการเข้าถึง (robots.txt)

  • เอเจนต์จำนวนมากจะตรวจ robots.txt ก่อนดึงคอนเทนต์ ดังนั้นหากตั้งค่าผิดก็จะ บล็อกการเข้าถึงเอกสารแบบเงียบ ๆ โดยไม่เกิด error
  • ขั้นตอนปฏิบัติ
    • ตรวจสอบว่ามีการบล็อก user-agent ของ AI agent โดยไม่ตั้งใจหรือไม่
    • พิจารณาอนุญาตรูปแบบ crawler ที่รู้จักกันดีอย่าง Anthropic, OpenAI, Google, Perplexity อย่างชัดเจน
    • หากต้องการควบคุมละเอียดกว่านั้น ให้ใช้ agent-permissions.json (สเปกใหม่สำหรับประกาศขอบเขตการโต้ตอบอัตโนมัติ rate limit และ API endpoint ที่แนะนำ เป็นต้น)

Layer 2: llms.txt เพื่อการค้นพบ

  • เป็น ไฟล์ข้อความล้วนรูปแบบ Markdown ที่โฮสต์ไว้ที่ yourdomain.com/llms.txt และทำหน้าที่เหมือน sitemap สำหรับ AI agent
  • โดยให้ไดเรกทอรีเอกสารที่จัดโครงสร้างไว้พร้อมคำอธิบาย เพื่อให้เอเจนต์เข้าใจคอนเทนต์ที่เกี่ยวข้องได้โดยไม่ต้อง crawl ทั้งเว็บไซต์
  • โครงสร้างตัวอย่าง: Getting Started (Quick Start Guide, Authentication, Core Concepts), API Reference (REST API Overview, Users API 12K โทเค็น, Events API 8K โทเค็น), MCP Integration (MCP Server)
  • คุณลักษณะของ llms.txt ที่ดี
    • อธิบายว่า จะพบอะไรได้บ้าง ไม่ใช่แค่ชื่อหน้า
    • ใส่จำนวนโทเค็นรายหน้าเมื่อมีประโยชน์
    • จัดตาม งาน (task) ไม่ใช่ลำดับชั้นของผลิตภัณฑ์
    • คงขนาดไฟล์เองให้น้อยกว่า 5,000 โทเค็น (เพราะดัชนีก็ห้ามเกินงบ)

Layer 3: การส่งสัญญาณความสามารถผ่าน skill.md

  • หาก llms.txt บอกว่า "อยู่ที่ไหน" skill.md ก็จะบอกว่าผลิตภัณฑ์ "ทำอะไรได้"
  • ทำให้เอเจนต์ไม่ต้องอนุมานความสามารถจากเอกสารเชิงร้อยแก้ว แต่สามารถแมป เจตนา (intention) ไปยัง endpoint/resource ได้แบบประกาศชัดเจน
  • ตัวอย่างโครงสร้างสำหรับบริการยืนยันตัวตน
    • What I can accomplish: การยืนยันตัวตนแบบ OAuth 2.0 (authorization code, client credentials, PKCE), การออกและตรวจสอบ JWT token, การจัดการ session และ refresh token rotation, การเชื่อมต่อ SSO (SAML, OIDC)
    • Required inputs: Client ID/Secret, Redirect URI ที่ลงทะเบียนล่วงหน้า, scope ที่ร้องขอ (read:user, write:data, admin)
    • Constraints: คำขอ token 1000 ครั้งต่อนาทีต่อแอปพลิเคชัน, access token 1 ชั่วโมง และ refresh token 30 วัน, public client ต้องใช้ PKCE
    • Key documentation: OAuth 2.0 Guide, Token Reference, Postman Collection
  • ทำให้เอเจนต์ตัดสินได้ว่า API สามารถตอบเจตนาของผู้ใช้ได้หรือไม่ ก่อนจะใช้ budget ของ context ไปกับการอ่านเอกสารทั้งก้อน

Layer 4: ฟอร์แมตคอนเทนต์เพื่อให้เอเจนต์พาร์สได้

  • อย่าให้แค่ HTML แต่ต้องให้ Markdown ด้วย — อนุญาตให้เข้าถึง Markdown ต้นฉบับได้ด้วยการเติม .md ใน URL หรือใช้ query parameter ซึ่งช่วยลด token overhead อย่างมากเพราะไม่มี tag, navigation, footer ที่เป็น noise
  • จัดโครงสร้างเพื่อให้สแกนได้ ไม่ใช่แค่อ่านได้
    • ลำดับหัวข้อสม่ำเสมอ (H1 → H2 → H3 และไม่ข้ามขั้น)
    • แต่ละส่วนเริ่มด้วย ผลลัพธ์ (outcome) ไม่ใช่พื้นหลังประกอบ
    • วางตัวอย่างโค้ดไว้ทันทีหลังคำอธิบาย
    • สำหรับ parameter reference ให้ใช้ ตาราง ซึ่งบีบอัดได้ดีกว่ารายการเชิงร้อยแก้ว
  • ตัด noise ด้าน navigation อย่าง sidebar, breadcrumb, footer link ออก
  • ภายใน 500 โทเค็นแรกของแต่ละหน้า ควรตอบให้ได้ว่า "นี่คืออะไร ทำอะไรได้ และต้องมีอะไรจึงจะเริ่มต้นได้"

Layer 5: การเปิดเผยจำนวนโทเค็น

  • แสดง จำนวนโทเค็น ทั้งในดัชนี llms.txt และในหน้าคอนเทนต์เอง (metadata หรือ page header)
  • ตัวอย่างการตัดสินใจที่เอเจนต์ใช้ข้อมูลนี้
    • "หน้านี้มี 8K โทเค็น — ใส่ทั้งหน้าลงใน context ได้"
    • "หน้านี้มี 150K โทเค็น — ต้องดึงมาเฉพาะส่วนที่เกี่ยวข้อง"
    • "เกิน context window — ใช้สรุปจาก llms.txt"
  • การติดตั้งทำได้ฝั่งเซิร์ฟเวอร์โดยนับจำนวนอักขระแล้วหารประมาณ 4 จากนั้นเปิดเผยผ่าน meta tag หรือ HTTP response header

Layer 6: "Copy for AI"

  • เมื่อดีเวลอปเปอร์พยายามใส่เอกสารเป็น context ให้ AI assistant ใน IDE การคัดลอกจาก HTML ที่เรนเดอร์แล้วมักพาเอา navigation และ footer noise ติดไปด้วย
  • ปุ่ม "Copy for AI" ที่คัดลอก Markdown สะอาดลง clipboard ช่วยยกระดับคุณภาพของ context ที่เอเจนต์ได้รับอย่างมีนัยสำคัญ
  • Anthropic และ Cloudflare มีเวอร์ชันลักษณะนี้ออกมาแล้ว ให้สัญญาณสูงในต้นทุนต่ำ

AGENTS.md: มาตรฐานพื้นฐานที่กำลังก่อตัว

  • เช่นเดียวกับที่ README.md เป็นจุดเริ่มต้นของมนุษย์ในรีโพซิทอรี AGENTS.md กำลังก้าวขึ้นมาเป็นจุดเริ่มต้นของ AI agent
  • coding agent จะมองหา AGENTS.md ใน root directory เมื่อเปิดโปรเจ็กต์ และใช้เป็นชุดคำสั่งอ้างอิงสำหรับงานทั้งหมดถัดจากนั้น
  • สิ่งที่ AGENTS.md ที่ดีควรมี
    • โครงสร้างโปรเจ็กต์และตำแหน่งไฟล์สำคัญ
    • ลิงก์ตรงไปยังเอกสารของ API/บริการที่เกี่ยวข้อง
    • sandbox สำหรับพัฒนาและสภาพแวดล้อมทดสอบที่มีให้ใช้
    • rate limit และข้อจำกัดที่เอเจนต์ควรรู้
    • แพตเทิร์นและ convention ที่นิยมใช้ใน codebase
    • ลิงก์ MCP server หากมี
  • Cisco DevNet ได้นำสิ่งนี้ไปใช้เป็นไฟล์มาตรฐานใน GitHub template สำหรับโปรเจ็กต์โอเพนซอร์ส โดย AGENTS.md ของแต่ละโปรเจ็กต์จะถูกกรอกข้อมูลล่วงหน้า เช่น เอกสาร OpenAPI, DevNet sandbox และลิงก์สภาพแวดล้อมทดสอบ เมื่อสร้างโปรเจ็กต์ใหม่

การติดตาม AI referral traffic

  • สิ่งที่ทำได้ทันทีคือ เริ่มติดตาม AI referral traffic ในเครื่องมือวิเคราะห์
  • แหล่ง referral ที่ควรจับตา: labs.perplexity.ai/referral, chatgpt.com/(none), chatgpt.com/organic, link.edgepilot.com/referral, platform.openai.com/referral, perplexity/(not set), claude.ai/referral, copilot.microsoft.com/referral, gemini.google.com/referral
  • ทราฟฟิกเอเจนต์โดยตรงที่มาถึงโดยไม่มี referrer สามารถจับได้จาก HTTP fingerprint ที่กล่าวไปก่อนหน้า (axios/1.8.4, curl/8.4.0, got (sindresorhus/got), colly)
  • การสร้างเซกเมนต์ทราฟฟิก AI อย่างเหมาะสมจะให้ ตัวชี้วัดนำ (leading indicator) สำหรับตัดสินว่าความพยายามด้าน AEO ได้ผลแค่ไหน

นัยที่กว้างกว่าสำหรับประสบการณ์นักพัฒนา

  • จนถึงตอนนี้ developer portal ถูกออกแบบโดยยึดรูปแบบการรับรู้ของมนุษย์เป็นหลัก เช่น progressive disclosure, ลำดับชั้นเชิงภาพ, ตัวอย่างแบบโต้ตอบได้, และ tutorial แบบมีไกด์
  • สมมติฐานที่พังลงในโลกที่มีเอเจนต์เป็นศูนย์กลาง
    • ลำดับชั้นเชิงภาพไม่มีความหมาย — เอเจนต์อ่านตัวข้อความ ไม่ได้อ่านเลย์เอาต์
    • progressive disclosure กลายเป็นอุปสรรค — เอเจนต์อยากได้ทุกอย่างพร้อมกัน
    • ตัวอย่างแบบโต้ตอบได้สูญเสียคุณค่า — หากไม่มีเวอร์ชัน static/API ที่เทียบเท่า ก็แทบใช้การไม่ได้
    • user journey พังทลาย — tutorial หลายหน้ากลายเป็นการโหลด context เพียงครั้งเดียว
  • ไม่ได้หมายความว่าการออกแบบเพื่อมนุษย์จะหายไป แต่มนุษย์เองก็กำลัง อ่านเอกสารมากขึ้นภายใน context ของ AI assistant
  • เอกสารที่ดีที่สุดในอนาคตต้อง สแกนได้และมีโครงสร้างดีสำหรับมนุษย์ ขณะเดียวกันก็ machine-readable และมีประสิทธิภาพด้านโทเค็นสำหรับเอเจนต์

เช็กลิสต์ตรวจสอบ AEO

Discovery

  • มี llms.txt ที่ root พร้อมดัชนีเอกสารแบบมีโครงสร้าง
  • robots.txt ไม่ได้บล็อก user-agent ของ AI agent ที่รู้จักโดยไม่ตั้งใจ
  • ใช้ agent-permissions.json กำหนดกฎการเข้าถึงของไคลเอนต์อัตโนมัติ
  • มี AGENTS.md ในรีโพซิทอรีโค้ดที่เชื่อมโยงเอกสารที่เกี่ยวข้อง

Content structure

  • ให้บริการหน้าเอกสารเป็น Markdown ที่สะอาด ไม่ใช่ HTML ที่เรนเดอร์แล้ว
  • แต่ละหน้ามีข้อความบอกผลลัพธ์ชัดเจนอยู่ใน 200 คำแรก
  • หัวข้อมีความสม่ำเสมอและถูกต้องตามลำดับชั้น
  • วางตัวอย่างโค้ดไว้ถัดจากคำอธิบายเชิงร้อยแก้วทันที
  • parameter reference ใช้ตาราง ไม่ใช้ร้อยแก้วซ้อนหลายชั้น

Token economics

  • ติดตามจำนวนโทเค็นของหน้าเอกสารแต่ละหน้า
  • ไม่มีหน้าเดี่ยวใดเกิน 30,000 โทเค็นหากไม่มีแผนการแบ่ง chunk
  • แสดงจำนวนโทเค็นของหน้าหลักใน llms.txt
  • ให้จำนวนโทเค็นผ่าน metadata ของหน้า (meta tag หรือ HTTP header)

Capability signaling

  • มีไฟล์ skill.md อธิบาย ความสามารถ ของแต่ละบริการ/API ไม่ใช่วิธีเรียกใช้งาน
  • แต่ละ skill มี capabilities, required inputs, constraints, และ key doc links
  • หากเหมาะสม ให้มี MCP server สำหรับเชื่อมต่อกับเอเจนต์โดยตรง

Analytics

  • ทำเซกเมนต์แหล่ง AI referral ใน web analytics
  • เฝ้าดู server log สำหรับ HTTP fingerprint ของ AI agent ที่รู้จัก
  • ตั้ง baseline ของสัดส่วนทราฟฟิก AI เทียบกับมนุษย์

UX bridge

  • มีปุ่ม "Copy for AI" บนหน้าเอกสาร
  • เข้าถึง Markdown ต้นฉบับได้ผ่านกติกา URL (เช่น เติม .md)

Tooling

  • ได้เปิดเผยเครื่องมือตรวจสอบขนาดเล็กชื่อ agentic-seo สำหรับสแกน llms.txt, การบล็อกเอเจนต์ใน robots.txt, จำนวนโทเค็น, ความพร้อมใช้ของ Markdown ฯลฯ — เป็นแนวคิดแบบ Lighthouse สำหรับความพร้อมของเอเจนต์

ควรเริ่มจากตรงไหน

  • ลำดับที่แนะนำ
    1. ตรวจ robots.txt — ใช้เวลา 10 นาที ป้องกันการล็อกเอเจนต์เงียบ ๆ
    2. เพิ่ม llms.txt — ใช้เวลาไม่กี่ชั่วโมง เพิ่ม discoverability ได้ทันที
    3. วัดและแสดงจำนวนโทเค็น — โปรเจ็กต์ทำในสุดสัปดาห์ แต่ให้ leverage สูง
    4. เขียน skill.md สำหรับ 3 API แรก — เริ่มจากเป้าหมายที่เอเจนต์เข้าถึงมากที่สุด
    5. เพิ่มปุ่ม "Copy for AI" — ต้นทุนต่ำ สัญญาณสูง
    6. ตั้งค่าติดตามทราฟฟิก AI — เพื่อให้มีข้อมูลรองรับงานที่เหลือ

สรุปส่งท้าย

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

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น