ข้ามไปยังเนื้อหาหลัก
ทราฟฟิกจากมนุษย์ vs เอเจนต์

แยกทราฟฟิกจากมนุษย์, ที่มี AI ช่วย และจากเอเจนต์ออกจากกัน

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

ขอสิทธิ์เข้าถึงก่อนใครสำรวจวิธีการทำงาน
Toshendra Sharma

โดย Toshendra Sharmaผู้ก่อตั้งและ CEO, AgentCredia · Updated November 13, 2026

สองหมวดหมู่ไม่เพียงพออีกต่อไป

ตลอดหลายปีที่ผ่านมา ทราฟฟิกถูกแบ่งออกเป็นสองกลุ่ม: มนุษย์และบอต มนุษย์ได้ใช้ผลิตภัณฑ์ บอตถูกบล็อก ถูกจำกัดอัตรา หรือถูกละเลย

การแบ่งแบบนั้นใช้ไม่ได้อีกต่อไป ผู้เยี่ยมชมอัตโนมัติบางส่วนคือเอเจนต์ที่ทำงานแทนลูกค้าจริง: ผู้ช่วยที่เปรียบเทียบแผน, เอเจนต์ที่ดึงข้อมูลผ่าน API ของคุณ, เครื่องมือที่เรียก MCP server ของคุณเพื่อทำงานให้เสร็จ ผู้ให้บริการ AI ในปัจจุบันก็อธิบายการเข้าถึงโดยผู้ใช้เป็นผู้เริ่มต้นลักษณะนี้ไว้ในเอกสารของตนเองเช่นกัน: OpenAI ระบุว่า ChatGPT-User agent ของตนจะเข้าเยี่ยมชมหน้าเมื่อผู้ใช้ถาม ChatGPT (เอกสาร crawler ของ OpenAI), และ Anthropic ระบุ Claude-User สำหรับวัตถุประสงค์เดียวกัน (เอกสาร crawler ของ Anthropic). ในขณะเดียวกัน บางคนทำงานร่วมกับ AI อย่างใกล้ชิด โดยร่างข้อความ กรอกฟอร์ม และนำทางผลิตภัณฑ์โดยมีผู้ช่วยอยู่เคียงข้าง การบีบทั้งหมดนี้ให้เป็นมนุษย์หรือบอตจะนำไปสู่การตัดสินใจที่ผิดพลาดทั้งสองทาง เอเจนต์ที่ชอบธรรมถูกบล็อก และผู้ใช้จริงถูกท้าทายเพียงเพราะพฤติกรรมดูผิดปกติ

หากต้องการ แยกแยะทราฟฟิกจากมนุษย์และเอเจนต์ AI ในแบบที่นำไปสู่การตัดสินใจที่ดี คุณต้องมีหมวดหมู่ที่ละเอียดขึ้น และต้องรู้ด้วยว่าแต่ละผลลัพธ์เชื่อถือได้มากเพียงใด บทความบล็อกเรื่อง วิธีบอกว่าทราฟฟิกเว็บไซต์มาจากเอเจนต์ AI หรือไม่ จะอธิบายสัญญาณที่ทำให้สิ่งนี้เป็นไปได้ และ use case สำหรับ SaaS apps แสดงให้เห็นว่าการแยกความแตกต่างนี้เปลี่ยนการตัดสินใจของผลิตภัณฑ์อย่างไร

สี่คลาส แต่ละคลาสมีความหมายที่แม่นยำ

Proof of Actor จัดประเภทการโต้ตอบออกเป็นสี่คลาส แต่ละคลาสมีคำจำกัดความและขอบเขตที่ชัดเจน เพื่อให้ไม่มีใครในทีมตีความผลลัพธ์เกินกว่าที่หลักฐานรองรับ หากต้องการอ่านเหตุผลเบื้องหลังอนุกรมวิธานนี้ โปรดดู Human, AI-assisted or agent: a taxonomy for app traffic

Human

สัญญาณที่สังเกตได้และรองรับได้บ่งชี้ว่าการโต้ตอบนี้ถูกขับเคลื่อนโดยมนุษย์ คลาสนี้พูดถึงว่าใครเป็นผู้กำกับการโต้ตอบ ไม่ใช่เรื่องตัวตน ผลลัพธ์ Human ไม่ได้ยืนยันว่าใครคนนั้นคือใคร และไม่ได้อ้างว่าไม่มีการใช้ AI ที่ใดเลย

Human + AI

มีการประกาศว่าใช้ AI ช่วย หรือสังเกตได้ผ่าน integration ที่รองรับซึ่งมองเห็นสิ่งนั้นได้จริง ตัวอย่างเช่น ผู้ใช้ระบุว่าคอนเทนต์ถูกร่างด้วย AI ผ่านการควบคุมการเปิดเผยของคุณเอง หรือแอปพลิเคชันของคุณรายงานว่า assistant ในตัวทำการกระทำบางอย่างให้ผู้ใช้ที่ลงชื่อเข้าใช้แล้ว อ่านเพิ่มเติมได้ในรายการอภิธานศัพท์ AI-assisted interaction

Agent

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

Unknown

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

ทุกคลาสมาพร้อมฐานของข้อสรุป

การแยกทราฟฟิกจากมนุษย์และเอเจนต์เป็นเพียงครึ่งหนึ่งของงาน อีกครึ่งหนึ่งคือการรู้ว่าข้อสรุปแต่ละแบบมีน้ำหนักมากเพียงใด นั่นคือเหตุผลที่ผลลัพธ์ของ Proof of Actor ทุกครั้งมาพร้อมฐานของข้อสรุป:

  • Verified: ข้อความยืนยันที่ตรวจสอบได้และผ่านการยืนยันแล้ว เช่น ลายเซ็นคำขอที่ตรวจสอบกับกุญแจที่เผยแพร่ไว้
  • Declared: ไคลเอนต์หรือแอปพลิเคชันของคุณเป็นผู้ระบุไว้ เช่น เอเจนต์ประกาศตัวเอง หรือผู้ใช้เปิดเผยการช่วยเหลือจาก AI
  • Inferred: ข้อสรุปที่ได้จากสัญญาณด้านพฤติกรรมหรือบริบท โดยจะถูกระบุว่าเป็นการอนุมานเสมอ
  • Unknown: หลักฐานไม่เพียงพอสำหรับการตัดสิน

การรวมกันของคลาสและฐานของข้อสรุปคือสิ่งที่ทำให้คุณสร้างกฎที่แม่นยำได้ เอเจนต์ที่ได้รับการยืนยันและเอเจนต์ที่ถูกอนุมานต่างก็เป็นเอเจนต์เหมือนกัน แต่คุณอาจต้องการให้รายแรกเข้าถึง structured API และให้รายหลังอยู่ภายใต้ rate limit มาตรฐานได้ การส่งที่มีการประกาศว่าใช้ AI ช่วยและเซสชันของมนุษย์อาจดำเนินต่อไปตามปกติได้ทั้งคู่ โดยมีป้ายกำกับที่ช่วยทีมสนับสนุนของคุณ คุณสามารถดูอนุกรมวิธานทั้งหมดได้ที่ Detection & Limitations

การจัดประเภทเกิดขึ้นอย่างไร

Proof of Actor ใช้เส้นทางที่เริ่มจากหลักฐานก่อนเหมือนกันสำหรับการโต้ตอบทุกครั้ง คำอธิบายฉบับเต็มอยู่ใน How It Works

สัญญาณที่ integration ของคุณมองเห็นได้

  • Request signatures จากไคลเอนต์อัตโนมัติที่เผยแพร่กุญแจของตน โดยใช้ HTTP Message Signatures ตามที่กำหนดไว้ใน RFC 9421. IETF Web Bot Auth working group มีอาณัติให้กำหนดมาตรฐานวิธีที่ไคลเอนต์อัตโนมัติยืนยันตัวตนด้วยวิธีนี้
  • Declarations จากไคลเอนต์ที่ระบุตัวเอง เช่น user agents ที่มีเอกสารกำกับของ AI crawlers และ fetchers รวมถึงจากแอปพลิเคชันของคุณเองเมื่อทราบว่ามีการใช้ AI assistance
  • Request context ที่ integration ฝั่งเซิร์ฟเวอร์เข้าถึงได้ เช่น headers และรายละเอียดของโปรโตคอล
  • Interaction signals จาก browser integration ที่ได้รับอนุมัติบนหน้าที่มันทำงานอยู่

จากสัญญาณไปสู่ผลลัพธ์

ระบบจะตรวจสอบสัญญาณ ติดป้ายกำกับตามฐานของข้อสรุป และรวมเข้าด้วยกัน หลักฐานที่ยืนยันได้อย่างแข็งแรงจะให้ผลลัพธ์ที่มั่นใจ หลักฐานที่อ่อนหรือขัดแย้งกันจะให้ข้อสรุปแบบมีเงื่อนไขหรือ Unknown การหมดเวลา หรือสัญญาณที่หายไป จะไม่ถูกเปลี่ยนเป็นผลลัพธ์ Human ผลลัพธ์ที่ได้คือคลาส ฐานของข้อสรุป และสรุปหลักฐานที่ทุกคนในทีมของคุณอ่านได้

เมื่อแยกทราฟฟิกแล้ว คุณทำอะไรต่อได้บ้าง

Proof of Actor จัดวางไว้รอบความสามารถสามอย่าง ได้แก่ Detect, Understand และ Route

Detect actor ที่อยู่เบื้องหลังแต่ละการโต้ตอบ

รวบรวมสัญญาณที่มีในแต่ละบริบท และแยกข้อความยืนยันที่ตรวจสอบได้ออกจากข้อสรุปเชิงอนุมาน คง Unknown ไว้ให้มองเห็นได้

Understand ว่า actor แต่ละแบบใช้ผลิตภัณฑ์ของคุณอย่างไร

ดูสัดส่วนของกิจกรรมจากมนุษย์, ที่มี AI ช่วย, จากเอเจนต์ และจาก unknown แยกตาม route และตามเวลา เปิดผลลัพธ์ใดก็ได้เพื่อดูว่าอะไรเป็นสิ่งที่ทราบแล้วและอะไรยังไม่ทราบ ระบุ route ที่เอเจนต์มารวมตัวกัน และ workflow ที่มีการใช้ AI assistance บ่อย

Route actor แต่ละแบบไปยังประสบการณ์ที่เหมาะสม

ใช้นโยบายของคุณเองเมื่อหลักฐานรองรับแล้ว บนเว็บไซต์สาธารณะ use case ของ websites แสดงให้เห็นว่าการตัดสินใจเหล่านี้เชื่อมกับ route จริงอย่างไร:

  • ให้เอเจนต์ที่ได้รับการยืนยันได้ใช้ structured response หรือ API แทนหน้าเว็บในรูปแบบมนุษย์
  • คงประสบการณ์มาตรฐานไว้สำหรับเซสชันที่ขับเคลื่อนโดยมนุษย์
  • ติดป้ายกำกับการส่งที่มีการใช้ AI ช่วย เพื่อให้ทีมที่เหมาะสมเป็นผู้ดูแล
  • ขอข้อมูลรับรองที่เข้มงวดขึ้นสำหรับการกระทำที่อ่อนไหว เมื่อเงื่อนไขของคุณต้องการ
  • เลือก fallback ที่ชัดเจนสำหรับ Unknown ในแต่ละ route เช่น อนุญาตหน้าเว็บสาธารณะและคงการตรวจสอบเดิมไว้สำหรับการเปลี่ยนแปลงบัญชี

คู่มือเรื่อง การนำ actor-aware policies ไปใช้อย่างปลอดภัย อธิบายวิธีย้ายจากการสังเกตไปสู่การบังคับใช้ทีละ route

เหตุใดสิ่งนี้จึงสำคัญต่อผู้ใช้ของคุณ

การทำสิ่งนี้ให้ถูกต้องเป็นเรื่องที่ดีสำหรับทุกคนที่ใช้แอปพลิเคชันของคุณ

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

การลงชื่อเข้าใช้ไม่ใช่ตัว actor

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

การปฏิบัติต่อทั้งสามแบบเหมือนกันจะสร้างปัญหาทั้งสองด้าน หากสมมติว่าคำขอทุกครั้งบนบัญชีเป็นของเจ้าของ เอเจนต์อาจเข้าถึง workflow ที่ออกแบบมาสำหรับมนุษย์ได้ หากสมมติว่าคำขอที่ผิดปกติทุกครั้งเป็นการโจมตี เครื่องมือของเจ้าของเองก็จะถูกบล็อก การแยก actor ออกจากบัญชีทำให้แอปพลิเคชันของคุณคงการยืนยันตัวตนและการอนุญาตไว้ตามเดิม และเพิ่มบริบทที่ขาดหายว่าใครเป็นผู้กระทำอยู่ตอนนี้ บริบทนั้นคือสิ่งที่ทำให้คุณสามารถเสนอการเข้าถึงแบบมีโครงสร้างให้เอเจนต์ โดยไม่เปิด workflow สำหรับมนุษย์เพียงอย่างเดียวให้พวกมัน

เริ่มในโหมดสังเกตการณ์

การติดตั้งใช้งานทุกครั้งเริ่มต้นในโหมดสังเกตการณ์ Proof of Actor บันทึกผลลัพธ์ในขณะที่แอปพลิเคชันของคุณตอบสนองเหมือนเดิมทุกประการ ทีมของคุณสร้าง baseline ของกิจกรรมจากมนุษย์, ที่มี AI ช่วย, จากเอเจนต์ และจาก unknown เปรียบเทียบกับผลลัพธ์ที่คุณรู้แล้ว และทบทวน false positive ใดๆ ก่อนจะเปลี่ยนกฎแม้เพียงข้อเดียว เมื่อพร้อมใช้นโยบายแล้ว คุณจึงเปิดใช้งานสำหรับ workflow เดียวก่อน แล้วค่อยขยายต่อจากนั้น

เข้าร่วม Founding Developer Program

Proof of Actor อยู่ใน private beta กับกลุ่มทีมแอปพลิเคชันขนาดเล็ก ผู้พัฒนารุ่นบุกเบิกที่ได้รับเลือกสามารถรับสิทธิ์ใช้งานฟรีได้นานสูงสุด 12 เดือน ภายใต้ขอบเขตการใช้งานที่ตกลงกันไว้ เพื่อแลกกับข้อเสนอแนะจากการใช้งานจริง คุณจะได้รับการสนับสนุนการเชื่อมต่อโดยตรงจากวิศวกรของเรา การเข้าถึงความสามารถก่อนใคร และอิทธิพลต่อการกำหนดลำดับความสำคัญ

หากคุณต้องการแยกแยะทราฟฟิกจากมนุษย์และเอเจนต์ AI ในแอปพลิเคชันของคุณ ให้ สมัครขอ early access และบอกเราว่าคุณต้องการทำความเข้าใจการโต้ตอบใดมากที่สุด

สำรวจ Proof of Actor อ่าน how it works หรือดูอย่างชัดเจนว่า หลักฐานสามารถยืนยันอะไรได้บ้าง

แหล่งที่มา

สำหรับนักพัฒนา

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent หรือ Unknown
basis
ระดับความแข็งแรงของหลักฐาน: Verified, Declared, Inferred หรือ Unknown
evidence
สัญญาณที่อยู่เบื้องหลังผลลัพธ์ เพื่อให้ทีมของคุณเห็นเหตุผล

เริ่มในโหมด observation: บันทึกผลลัพธ์ไว้ข้าง log ของคุณ และไม่เปลี่ยนแปลงอะไรจนกว่าคุณจะเลือกนโยบาย อ่านคู่มือการเชื่อมต่อ Node.js

คำถามที่พบบ่อย

คุณแยกแยะทราฟฟิกจากมนุษย์และเอเจนต์ AI ได้อย่างไร?

Proof of Actor รวมสัญญาณที่ integration ของคุณสังเกตได้ เช่น ลายเซ็นคำขอ, การประกาศจากไคลเอนต์, บริบทของคำขอ และสัญญาณการโต้ตอบจากเบราว์เซอร์ แล้วส่งกลับเป็นคลาสพร้อมฐานของข้อสรุปที่ระบุไว้อย่างชัดเจน

ทำไมจึงต้องมีคลาส Human + AI?

บางคนทำงานกับผู้ช่วย AI อยู่เคียงข้าง หากจัดให้เป็นมนุษย์ล้วนหรืออัตโนมัติล้วนทั้งหมด จะทำให้สูญเสียบริบทสำคัญ Human + AI ครอบคลุมการช่วยเหลือที่มีการประกาศไว้ หรือที่สังเกตได้ผ่าน integration ที่รองรับ

ผลลัพธ์ Agent เหมือนกับบอตที่ไม่ดีหรือไม่?

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

ถ้าทราฟฟิกไม่สามารถจัดประเภทได้จะเป็นอย่างไร?

ระบบจะรายงานเป็น Unknown ซึ่งเป็นผลลัพธ์ระดับแรก Unknown จะไม่ถูกเปลี่ยนเป็น Human และจะไม่ถูกถือว่าเป็นอันตรายโดยค่าเริ่มต้น

ฉันจำเป็นต้องบล็อกอะไรหรือไม่?

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

รู้ว่าใครกำลังใช้แอปของคุณ

private beta สำหรับกลุ่มเล็กๆ ของ founding developers

ขอสิทธิ์เข้าถึงก่อนใครดูราคา

อยากคุยก่อนหรือไม่ พูดคุยกับผู้ก่อตั้ง