คำจำกัดความ
ทราฟฟิกของ AI agent คือชุดคำขอที่แอปพลิเคชันได้รับจากซอฟต์แวร์เอเจนต์ที่ใช้โมเดล AI เพื่อตัดสินใจว่าจะทำอะไรต่อไป เอเจนต์เหล่านี้เรียกดูหน้า, เรียก API, กรอกฟอร์ม และเรียกใช้เครื่องมือบน Model Context Protocol (MCP) servers โดยปกติทำในนามของบุคคลหรือบริษัท ลักษณะที่กำหนดคือโมเดล ไม่ใช่คน เป็นผู้เลือกการกระทำถัดไปภายในงานที่ได้รับมอบหมาย
ทราฟฟิกของ AI agent ทับซ้อนกับรูปแบบอัตโนมัติแบบเดิม เช่น crawlers และสคริปต์ แต่พฤติกรรมแตกต่างกัน เอเจนต์ไล่ตามเป้าหมาย, ปรับตัวตามสิ่งที่พบ และมักโต้ตอบกับส่วนต่างๆ ของแอปพลิเคชันที่ออกแบบมาสำหรับคนเท่านั้น
พบได้ที่ไหน
- เว็บไซต์และแอป SaaS: ผู้ช่วยที่อ่านเอกสาร, เปรียบเทียบหน้าราคา หรือทำเวิร์กโฟลว์หลายขั้นตอนให้เสร็จภายในเซสชันที่ล็อกอินแล้ว ผู้ให้บริการ AI บันทึกทราฟฟิกบางส่วนนี้ไว้: OpenAI's ChatGPT-User และ Claude-User ของ Anthropic จะดึงหน้าเมื่อมีคนถามคำถาม
- API: เอเจนต์ที่เรียก endpoint โดยตรงด้วยข้อมูลประจำตัวของ API โดยมักมีจังหวะและรูปแบบต่างจากการเชื่อมต่อที่ขับเคลื่อนโดยคน
- MCP servers: ไคลเอนต์ AI ที่เรียกใช้เครื่องมือ ซึ่งทุกการเรียกโดยนิยามแล้วเป็นแบบอัตโนมัติ และคำถามคือไคลเอนต์ใดเป็นผู้เรียก และมันอาจทำอะไรได้บ้าง ดู MCP server
วิธีสังเกต
ไม่มีสัญญาณเดียวที่ระบุทราฟฟิกของเอเจนต์ได้อย่างน่าเชื่อถือ ทีมมักรวมหลักฐานที่มีน้ำหนักต่างกัน ตามที่อธิบายไว้ใน วิธีดูว่า ทราฟฟิกของเว็บไซต์มาจาก AI agents หรือไม่:
หลักฐานที่ยืนยันได้
ผู้ดำเนินการเอเจนต์บางรายลงลายเซ็นคำขอด้วย HTTP message signatures (RFC 9421) โดยใช้คีย์ที่เผยแพร่ภายใต้โดเมนที่พวกเขาควบคุม ตามแนวทางของงาน IETF Web Bot Auth ลายเซ็นที่ตรวจสอบผ่านได้เป็นหลักฐานที่หนักแน่นว่าไคลเอนต์ของผู้ดำเนินการรายใดส่งคำขอนั้น
หลักฐานที่ประกาศไว้
ไคลเอนต์สามารถระบุตัวเองได้ เช่น user-agent string, ชื่อไคลเอนต์ MCP หรือ header สิ่งเหล่านี้มีประโยชน์แต่เลียนแบบได้ง่าย ซึ่งเป็นเหตุผลที่ user-agent spoofing เป็นข้อกังวลที่มีอยู่ตลอดเวลา
หลักฐานที่อนุมานได้
จังหวะของคำขอ, รูปแบบการนำทาง, บริบทของเบราว์เซอร์ที่หายไป และรายละเอียดของโปรโตคอลสามารถบ่งชี้ถึงการทำงานอัตโนมัติได้ ข้อสรุปจากการอนุมานอาจผิดได้ ดังนั้นจึงควรระบุว่าเป็นการอนุมานเสมอ
เมื่อไม่มีสิ่งใดสนับสนุนการสรุปได้ คำตอบที่ซื่อสัตย์คือ Unknown
เหตุผลที่สำคัญ
ทราฟฟิกของเอเจนต์ไม่ได้ดีหรือแย่โดยเนื้อแท้ ผู้ช่วยช้อปปิ้งที่เปรียบเทียบแพ็กเกจ, เอเจนต์ภายในที่ซิงก์บันทึก และ scrapers ที่เพิกเฉยต่อเงื่อนไขของคุณอาจดูคล้ายกันในระดับเครือข่าย สิ่งที่เปลี่ยนคือสิ่งที่แอปพลิเคชันของคุณควรทำ:
- เสนอการตอบกลับที่มีโครงสร้างหรือ API ให้กับเอเจนต์ที่คุณยินดีให้บริการ
- ใช้ข้อจำกัดระดับ route ในกรณีที่ปริมาณจากระบบอัตโนมัติอาจกดดันทรัพยากร
- ขอข้อมูลประจำตัวที่เข้มงวดขึ้นก่อนการกระทำที่มีผลกระทบสูง
- รักษาประสบการณ์ของคนให้รวดเร็วและไม่รกรุงรัง
การมองว่าระบบอัตโนมัติทั้งหมดเป็นการละเมิดจะทำให้การเชื่อมต่อที่ถูกต้องใช้งานไม่ได้ การเพิกเฉยต่อมันหมายความว่าการกระทำที่ละเอียดอ่อนอาจทำงานโดยไม่มีบริบทที่ทีมของคุณคาดไว้
ความเข้าใจผิดที่พบบ่อย
"เอเจนต์ระบุตัวเองเสมอ" หลายรายไม่ได้ทำเช่นนั้น และคำประกาศอาจไม่จริง
"เอเจนต์ที่ลงลายเซ็นคือเอเจนต์ที่เชื่อถือได้" ลายเซ็นแสดงว่า key ใดเป็นผู้ลงนามคำขอ ไม่ได้แสดงว่าการกระทำนั้นได้รับอนุญาตหรือปลอดภัย ดู agent authorization
"การบล็อกระบบอัตโนมัติช่วยปกป้องแอป" บ่อยครั้งมันบล็อกการเชื่อมต่อที่ลูกค้าพึ่งพา ในขณะที่ผู้ไม่หวังดีที่มุ่งมั่นก็ปรับตัวได้
Proof of Actor จัดการกับทราฟฟิกของเอเจนต์อย่างไร
Proof of Actor จัดประเภทแต่ละการโต้ตอบเป็น Human, Human + AI, Agent หรือ Unknown (อธิบายอนุกรมวิธานไว้ที่นี่) และระบุว่าผลลัพธ์นั้น verified, declared หรือ inferred ทีมจะสังเกตดูก่อน แล้วจึง route ทราฟฟิกของเอเจนต์ด้วยนโยบายของตนเอง ดู How It Works หรือ สมัครเข้าถึงก่อนใคร
แหล่งอ้างอิง
- Model Context Protocol specification (2026-07-28): ฉบับ MCP ปัจจุบัน ณ เดือนพฤศจิกายน 2026
- RFC 9421: HTTP Message Signatures: มาตรฐานเบื้องหลังคำขอของเอเจนต์ที่ลงลายเซ็น
- IETF Web Bot Auth working group: งานมาตรฐานด้านการยืนยันตัวตนของไคลเอนต์อัตโนมัติ
- OpenAI: Overview of OpenAI Crawlers: ChatGPT-User และ user agents อื่นๆ ของ OpenAI ที่มีเอกสารกำกับ
- Anthropic: crawler and fetcher documentation: Claude-User และบอทอื่นๆ ของ Anthropic