โครงสร้างพื้นฐานการค้นหาภาพสำหรับ AI Agent: สิ่งที่ตลาดส่งมอบจริง

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

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

ขอบเขตหนึ่งข้อ เผื่อคุณจะหยุดอ่านตั้งแต่ตรงนี้หากนี่ไม่ใช่คำถามของคุณ: บทความนี้พูดถึง เลเยอร์การเข้าถึง — การค้นคืน ความสามารถในการเข้าถึง เงื่อนไข โควตา ไม่ใช่ pipeline การเผยแพร่ หากสิ่งที่คุณต้องการคือวิธีเปลี่ยนร่างบทความให้กลายเป็นหน้าที่มีภาพประกอบ มีเครดิต และมีมาร์กอัป — router prompt, visual brief, การประกอบชิ้นงาน, มาร์กอัป ImageObject — เรื่องนั้นเขียนแยกไว้ต่างหากใน pipeline ที่ทำภาพประกอบให้บทความที่เขียนโดย AI

สิ่งที่เปลี่ยนไปเมื่อผู้เรียกคือเครื่องจักร

มนุษย์ที่ค้นหารูปภาพจะพิมพ์คำสองสามคำ กวาดตาดูกริดของรูป และรู้ทันทีเมื่อเจอรูปที่ดี เอนจินค้นหาสต็อกทุกตัวที่เคยสร้างมาถูกออกแบบโดยยึดตามลูปนี้ แต่เอเจนต์ทำลายสมมติฐานทั้งสามข้อพร้อมกัน:

1. มันเขียนเป็นประโยค ไม่ใช่คีย์เวิร์ด โมเดลที่เพิ่งร่างเนื้อหาเกี่ยวกับเอกสารสินเชื่อบ้านจะไม่พ่นคำว่า mortgage ออกมา แต่จะพ่นข้อความว่า “a woman signing a mortgage document at a kitchen table while a bank adviser explains the terms” นั่นคือผลลัพธ์ตามธรรมชาติของโมเดลภาษา และมันเป็นสิ่งที่ดัชนีแบบจับคู่โทเคนไม่สามารถให้บริการได้เลย
2. มันกวาดตาดูกริดไม่ได้ อะไรก็ตามที่เครื่องมือส่งกลับมา คือ สิ่งที่เอเจนต์รู้ทั้งหมด หากผลลัพธ์เป็นเพียงลิสต์ของ URL ที่ไม่มีคำอธิบาย ขนาด หรือเครดิต เอเจนต์ต้องดึงและดูรูปทีละรูป — หรือที่พบบ่อยกว่านั้นมากคือแค่เดา
3. มันไม่มีมือ มันไม่สามารถอัปโหลดสกรีนช็อตไปยังคิวรีวิว ยอมรับเงื่อนไข หมุนคีย์ใหม่ หรือรอสามวันทำการเพื่อขออนุมัติใช้งานจริง ทุกขั้นตอนที่ต้องใช้มนุษย์ในกระบวนการ onboarding ของ API คือกำแพงที่เอเจนต์จะติดอยู่

ดังนั้น “โครงสร้างพื้นฐานสำหรับค้นหารูปภาพสำหรับเอเจนต์ AI” จึงไม่ใช่แค่วลีทางการตลาด แต่มันคือรายการตรวจสอบ: การค้นคืนด้วยภาษาธรรมชาติ ผลลัพธ์ที่เครื่องอ่านได้และมีข้อมูลมากพอให้นำไปให้เหตุผลต่อ และโมเดลการยืนยันตัวตนกับโควตาที่โปรแกรมทำให้เสร็จได้ด้วยตัวเอง

การทดสอบ: ประโยคปะทะดัชนีคีย์เวิร์ด

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

import json, urllib.request, urllib.parse

BRIEFS = [
  "a woman signing a mortgage document at a kitchen table while a bank"
  " adviser explains the terms, warm morning light",
  "An elderly couple enjoying a peaceful retirement together",
  "a child discovering snow for the first time in a suburban garden",
  "a delivery cyclist waiting at a red light in heavy rain",
]

def count(q):
    u = "https://api.openverse.org/v1/images/?" + urllib.parse.urlencode({"q": q})
    r = urllib.request.Request(u, headers={"User-Agent": "benchmark/1.0"})
    return json.load(urllib.request.urlopen(r))["result_count"]

for b in BRIEFS:
    print(count(b), "|", b[:48])
# 0 | a woman signing a mortgage document at a kitchen
# 0 | An elderly couple enjoying a peaceful retirement
# 0 | a child discovering snow for the first time in a
# 0 | a delivery cyclist waiting at a red light in hea

โจทย์สี่ชุด ผลลัพธ์ว่างเปล่าสี่ชุด ทีนี้ลองตัดแต่ละโจทย์ให้เหลือคีย์เวิร์ดสองคำแบบที่มนุษย์จะพิมพ์ — signing document, elderly couple, child snow, cyclist rain — แล้วทุกคำจะคืนผลลัพธ์เป็นหน้าเต็มของรูปภาพ (API รายงานตัวเลข 240 ซึ่งเป็นจุดที่มันจำกัดจำนวนไว้สำหรับผู้เรียกแบบไม่ระบุตัวตน) แคตตาล็อกมีรูปเหล่านั้นอยู่จริง แต่ประโยคต่างหากที่มันแยกวิเคราะห์ไม่ได้

ปัดตารางไปด้านข้างเพื่อดูทุกคอลัมน์ →

คอลัมน์ Pexafy คือประโยคเดิมทั้งสี่ชุดที่ส่งไปยัง search_photos โดยไม่มีการแก้ไข ผ่าน hosted MCP server พร้อมค่าความหน่วงที่เซิร์ฟเวอร์เองรายงานกลับมา นี่คือการเปรียบเทียบ รูปแบบของคำค้นหา ไม่ใช่คุณภาพของแคตตาล็อก — และแคตตาล็อกนั้นไม่ใช่ปัญหาอย่างชัดเจน endpoint สถิติของ Openverse เองรายงานว่ามี รูปภาพ 915 ล้านรูปจาก 52 แหล่ง ในวันที่ทดสอบ และมันยอดเยี่ยมมากในสิ่งที่มันถูกสร้างขึ้นมาเพื่อทำ: การค้นหาด้วยคีย์เวิร์ด สำหรับคน ไม่มีอะไรพังในตัวมันเลย มันแค่ไม่เคยถูกออกแบบมาสำหรับผู้เรียกที่คิดเป็นประโยค เหตุผล ที่การจับคู่แท็กพังเมื่อเจอฉากที่ถูกบรรยาย — และสิ่งที่การค้นคืนเชิงความหมายทำแทน — ถูกอธิบายจากมุมมองของผู้อ่านไว้ใน การค้นหาด้วยประโยคแทนคีย์เวิร์ด สิ่งที่ใหม่ในที่นี้คือการวัดผล และความหมายของมันเมื่อผู้เรียกเป็นโปรแกรมแทนที่จะเป็นคน

“An elderly couple enjoying a peaceful retirement together” · 16 ผลลัพธ์ ใน 135 ms · สามในนั้น

อันดับ 1Pexels Pixabay Unsplash

ตลาด ณ วันที่ 18 สิงหาคม 2026

การค้นคืนคือครึ่งหนึ่ง อีกครึ่งหนึ่งคือ ความสามารถในการเข้าถึง: เอเจนต์เข้าถึงแคตตาล็อกได้หรือไม่ และด้วยเงื่อนไขแบบใด นับตั้งแต่ Model Context Protocol กลายเป็นวิธีที่ผู้ช่วย AI เชื่อมต่อกับระบบภายนอก — ข้อกำหนดฉบับปัจจุบันของมัน ลงวันที่ 28 กรกฎาคม 2026 ได้ย้ายโปรโตคอลไปสู่แกนกลางแบบ request/response ที่ไม่เก็บสถานะ เพื่อให้เซิร์ฟเวอร์อยู่หลัง load balancer ทั่วไปได้1 — วิธีที่ตรงไปตรงมาในการสำรวจตลาดนี้คือการดูสิ่งที่เผยแพร่จริง ไม่ใช่สิ่งที่ประกาศไว้

ผู้ให้บริการเสียเงินรายใหญ่มาถึงในเดือนนี้

Getty Images เปิดตัว MCP server เมื่อวันที่ 12 สิงหาคม 2026 หกวันก่อนบทความนี้ โดยเปิดให้ค้นหาและดาวน์โหลดเนื้อหาครีเอทีฟ เนื้อหาข่าว และเนื้อหาคลังภาพ ผ่านเวิร์กโฟลว์ AI2 โดยมุ่งเป้าไปที่ทีมองค์กรและผู้สร้างแพลตฟอร์ม และหน้าการเข้าถึงของตนเองก็ระบุราคาเริ่มต้นชัดเจน: คุณต้องมีสัญญา Getty Images ที่ใช้งานอยู่ เช่น Premium Access รวมถึงต้องยอมรับเงื่อนไขของ Web Service ไม่มีระดับฟรี Shutterstock ก็เข้าถึงเนื้อหาได้ผ่าน MCP server เช่นกัน — เครื่องมือ 24 อย่างครอบคลุมการค้นหา คอลเลกชัน และการอนุญาตสิทธิ์ — โดยการดาวน์โหลดถูกล็อกไว้หลังบัญชีที่มีการสมัครสมาชิกใช้งานอยู่3

ทั้งสองการตัดสินใจนี้สมเหตุสมผลและมุ่งเป้าไปที่ผู้ซื้อเฉพาะกลุ่ม Getty มีรายได้ 981.3 ล้านดอลลาร์ ในปี 20254 ในตลาดภาพถ่ายสต็อกที่มีขนาดประมาณ 5.4 พันล้านดอลลาร์ สำหรับปี 20265 คอนเนกเตอร์ที่ต้องมีสัญญาปกป้องรายได้นั้นแทนที่จะเปิดกว้างมัน หากคุณเป็นธนาคารหรือสถานีโทรทัศน์ นี่คือสิ่งที่คุณต้องการพอดี แต่หากคุณเป็นนักพัฒนาที่ต่อเชื่อมโปรเจกต์เล็ก ๆ — หรือเอเจนต์ที่ต้องไม่หยุดเพื่อขอให้มนุษย์เซ็นเอกสารอะไรสักอย่าง — นี่คือประตูที่ปิดตายอยู่

ไลบรารีฟรียังไม่เปิดตัวอะไรเลย

Unsplash, Pexels และ Pixabay คือสามแคตตาล็อกที่นักพัฒนาส่วนใหญ่หันไปใช้ และไม่มีเจ้าไหนเผยแพร่ MCP server อย่างเป็นทางการเลย สิ่งที่มีอยู่แทนคือชั้นวางของ wrapper จากคอมมูนิตี้ เราไล่สำรวจ MCP registry อย่างเป็นทางการ ทั้งหมด — 22,607 เซิร์ฟเวอร์ 75,487 เวอร์ชันที่เผยแพร่ — และเก็บทุกรายการที่ชื่อหรือคำอธิบายเกี่ยวข้องกับการค้นหารูปภาพหรือรูปสต็อก รูปแบบที่พบเหมือนกันหมด:

ปัดตารางไปด้านข้างเพื่อดูทุกคอลัมน์ →

import json, urllib.request, urllib.parse

def crawl(term):                      # registry แบ่งหน้าด้วย `nextCursor`
    out, cursor = {}, None
    while True:
        p = {"limit": "100", "search": term} | ({"cursor": cursor} if cursor else {})
        d = json.load(urllib.request.urlopen(
            "https://registry.modelcontextprotocol.io/v0/servers?" + urllib.parse.urlencode(p)))
        for e in d["servers"]: out[e["server"]["name"]] = e["server"]
        cursor = (d.get("metadata") or {}).get("nextCursor")
        if not cursor or not d["servers"]: return out

servers = {}
for t in ["photo", "image", "stock", "picture", "unsplash",
          "pexels", "pixabay", "getty", "shutterstock", "openverse"]:
    servers |= crawl(t)

# 137 เซิร์ฟเวอร์ที่ไม่ซ้ำกัน · remote กับ local ดูได้จาก `server["remotes"]`
# คีย์บุคคลที่สามที่จำเป็นอยู่ใน packages[].environmentVariables

wrapper แต่ละตัวล้วนเป็นไคลเอนต์บาง ๆ ของ keyword API สามตัวเดียวกัน ซึ่งหมายความว่าเบนช์มาร์กด้านบนใช้ได้กับทุกตัว: transport เปลี่ยนไป แต่การค้นคืนไม่ได้เปลี่ยน wrapper ไม่สามารถทำให้ดัชนีแท็กเข้าใจประโยคได้

เงื่อนไขที่หยุดเครื่องจักรไม่ใช่โควตา

โควตาและเงื่อนไขของไลบรารีฟรีถูกเปรียบเทียบกันในหน่วยเดียวกันไว้ใน บทเปรียบเทียบ API รูปภาพสต็อกฟรี — คิวขออนุมัติ การเรียก download ที่บังคับ ข้อบังคับเรื่องแคช 24 ชั่วโมง กฎการให้เครดิต บทความนั้นอ่านเงื่อนไขเหล่านี้ในมุมของนักพัฒนาที่กำลังเลือกผู้ให้บริการ ลองอ่านมันอีกครั้งในมุมของ โปรแกรม ที่ต้องปฏิบัติตามเงื่อนไขเหล่านั้น แล้วจะเห็นบรรทัดหนึ่งที่โดดเด่นออกมาซึ่งไม่เกี่ยวกับปริมาณเลย:

การอ่านแบบเดียวกันนี้ใช้ได้กับขั้นตอน onboarding เช่นกัน ระดับทดลองที่จะกลายเป็นระดับใช้งานจริงได้ก็ต่อเมื่อมนุษย์รีวิวสกรีนช็อตของแอปคุณก่อน ไม่ใช่ rate limit ที่เอเจนต์จะถอยกลับมาได้ แต่มันคือขั้นตอนที่มันทำไม่ได้เลย Pixabay ระบุเจตนาไว้อย่างชัดเจน — API นี้มีไว้สำหรับการใช้งานของมนุษย์ที่ถูกต้องตามกฎหมาย และการดาวน์โหลดอัตโนมัติจำนวนมากเป็นสิ่งต้องห้าม ทั้งหมดนี้ไม่ได้ไร้เหตุผลแต่อย่างใด — ช่างภาพเปิดให้ใช้งานฟรี และมีคนต้องจ่ายค่าแบนด์วิดท์ มันแค่บรรยายถึง API ที่ถูกสมมติไว้ว่าผู้เรียกจะต้องมีหน้าจอและมือคู่หนึ่ง

ข้อกำหนดสี่ข้อ และใครที่ทำได้ครบ

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

1. การค้นคืนเชิงความหมาย — ประโยคเต็มคืนหน้าผลลัพธ์ที่จัดอันดับแล้ว ไม่ใช่ชุดผลลัพธ์ว่างเปล่า
2. สัญญาอนุญาตฟรี จากหลายแหล่ง — ไม่มีอะไรต้องขอสิทธิ์ต่อรูป และไม่มีไลบรารีเดียวมากำหนดสไตล์ของทุกหน้าที่คุณเผยแพร่
3. เซิร์ฟเวอร์แบบ hosted พร้อมระบบล็อกอินของตัวเอง — remote, OAuth, ไม่มีโปรเซสในเครื่องต้องติดตั้ง และไม่มี API key ของบุคคลที่สามต้องแปะลงในไฟล์ config
4. ระดับฟรีที่เครื่องจักรทำให้เสร็จได้ด้วยตัวเอง — ไม่ต้องรีวิวสกรีนช็อต ไม่ต้องมีสัญญา มีโควตารายเดือนและ rate limit ต่อนาทีที่ worker สามารถกะจังหวะของตัวเองได้

ปัดตารางไปด้านข้างเพื่อดูทุกคอลัมน์ →

เราสร้าง Pexafy ขึ้นมาเอง ดังนั้นให้อ่านแถวสุดท้ายนั้นด้วยความสงสัยตามควร — แล้วลองตรวจสอบดู: การสำรวจ registry สามารถทำซ้ำได้ด้วยสคริปต์เดียว เงื่อนไขการเข้าถึงของ Getty และ Shutterstock อยู่บนหน้าของตัวเอง และข้อจำกัดของ API รูปภาพทั้งสามตัวอยู่ในเอกสารของตัวเอง ทุกอันมีลิงก์แนบไว้ด้านล่าง คำกล่าวอ้างนี้แคบและพิสูจน์เท็จได้: ณ วันที่ 18 สิงหาคม 2026 เราไม่พบบริการที่สองที่ทำได้ครบทั้งสี่ข้อ หากคุณรู้จักบริการนั้น เราจะเพิ่มมันเข้าไปในตารางนี้ — จุดประสงค์ของการเขียนข้อกำหนดออกมาชัด ๆ ก็คือใครก็ตามสามารถนำมันไปทดสอบกับสินค้าใดก็ได้ รวมถึงของเราเองด้วย

สิ่งที่เซิร์ฟเวอร์รูปภาพที่ดีทำผ่าน MCP

คอนเนกเตอร์ไม่ใช่แค่ REST endpoint ที่ทาสีใหม่ การใช้งานเลเยอร์นี้สองแบบถูกเขียนไว้ที่อื่นแล้วและจะไม่กล่าวซ้ำที่นี่ — การทำภาพประกอบให้ร่างบทความ ในบทความ pipeline และการรักษาความสอดคล้องทางภาพของซีรีส์ยาว ๆ ในบทความเรื่องปริมาณ สิ่งที่เป็นของโครงสร้างพื้นฐานคือสิ่งที่ทั้งสองอย่างพึ่งพา และไม่มีใครเพิ่มเข้าไปทีหลังได้: การตัดสินใจสามอย่างฝั่งเซิร์ฟเวอร์ ทำครั้งเดียว สำหรับเอเจนต์ทุกตัวที่เชื่อมต่อเข้ามา

1. ส่งกลับเป็นออบเจกต์ที่เอเจนต์ให้เหตุผลต่อได้ อะไรก็ตามที่เครื่องมือส่งกลับมาคือทั้งหมดที่โมเดลรู้ — มันกวาดตาดูกริดไม่ได้ ความแตกต่างระหว่างสองรูปแบบด้านล่างนี้คือความแตกต่างระหว่างผู้ช่วยที่ให้เหตุผลเกี่ยวกับรูปภาพได้ กับผู้ช่วยที่แค่ส่งต่อลิงก์:

# Wrapper คีย์เวิร์ดทั่วไป: เอเจนต์ต้องดึงมาดู หรือเดาเอา
[{ "url": "https://…/photo-8795398.jpeg" }, { "url": "https://…/366611.jpg" }]

# ผลลัพธ์หนึ่งรายการ ตามที่ส่งกลับจริง — ตัดให้สั้นลงตรงนี้ ไม่ได้เพิ่มอะไรเข้าไป
{
  "rank": 1,                       // handle ที่มนุษย์ใช้เรียก: "more like #1"
  "photo_id": "019e14d9-e821-…",   // สิ่งที่ get_similar_photos ใช้
  "width": 6424, "height": 4283, "orientation": "landscape",
  "color_hex": "#918872", "blur_hash": "LPI#Px?aDikCGwW?M{kD-VR*s.fl",
  "source": "Pexels", "license_type": "free",
  "alt_description": "Older couple sits together on wooden bench in a park",
  "attribution": { "plain": "Photo by Anastasia Shuraeva on Pexels", "html": "…" },
  "urls": { "thumb": "…", "small": "…", "regular": "…", "large": "…" }
}

ด้วยรูปแบบที่สอง เอเจนต์สามารถพูดได้ว่า “#3 เป็นแนวตั้ง มันจะทำให้ hero slot ของคุณเสียเลย” ตัดช่างภาพที่ซ้ำออกไป ส่งเนื้อหาเครดิต และส่งคู่ width/height ให้เทมเพลตของคุณเพื่อป้องกัน layout shift — โดยไม่ต้องดึงรูปแม้แต่รูปเดียว ในขณะที่รูปแบบแรก การตัดสินใจทุกอย่างเหล่านั้นเป็นเพียงการเดาหรือต้อง round trip เพิ่ม

2. กำหนดหมายเลขให้ผลลัพธ์ เพื่อให้คนชี้ได้ ผลลัพธ์กลับมาแบบจัดอันดับเป็น #1, #2, #3… ซึ่งเป็นวิธีที่ใครก็ตามอ้างถึงรูปในบทสนทนา — “more like #3” — โดยไม่ต้องคัดลอกตัวระบุด้วยมือ ในไคลเอนต์ที่รองรับ MCP Apps ภาพขนาดย่อจะแสดงผลแบบอินไลน์ และการเปิดดูรูปหนึ่งจะแสดงเมทาดาทาที่มีอยู่แล้วในผลลัพธ์เครื่องมือ โดยไม่มีการเรียกเพิ่ม

3. คงสถานะอ่านอย่างเดียว และระบุให้ชัดเจน เครื่องมือสามตัว ไม่มี write scope ไม่มีการเปลี่ยนแปลงบัญชี หนึ่งในนั้นไม่มีสิ่งเทียบเท่าในระบบคีย์เวิร์ดเลย: search_photos_by_image รับรูปอ้างอิง — hero image เดิมของลูกค้า สกรีนช็อตที่วางไว้ในแชท — พร้อมประโยคเสริมทางเลือกเพื่อปรับแต่งมัน (“like this, but at night”) ไม่มีฟิลด์ใน API แบบจับคู่แท็กที่รับคำขอแบบนี้ได้เลยแม้แต่การพิมพ์ และเอเจนต์ที่เปลี่ยนแปลงอะไรไม่ได้เลยคือเอเจนต์ที่ผลลัพธ์แย่ที่สุดคือชุดผลลัพธ์ว่างเปล่า ไม่ใช่ตั๋วซัพพอร์ต

สองพื้นผิว และคุณต้องการอันไหน

มีทางเข้าอยู่สองแบบเท่านั้น และการเลือกนั้นขึ้นอยู่กับว่าใครอยู่ในลูป ไม่ใช่เรื่องความสามารถ — เครื่องมือและแคตตาล็อกเหมือนกันทั้งสองแบบ

คอนเนกเตอร์ เมื่อมีคนอยู่ในลูป URL เดียวคือ https://mcp.pexafy.com/mcp เพิ่มครั้งเดียวในการตั้งค่าคอนเนกเตอร์ของผู้ช่วย การล็อกอินเกิดขึ้นในหน้าต่างเบราว์เซอร์และไคลเอนต์ได้รับข้อมูลรับรองของตัวเอง จึงไม่มีคีย์ต้องแปะลงในไฟล์ config และไม่มีคีย์ต้องหมุนทีหลัง ไคลเอนต์ที่ไม่รองรับ OAuth จะส่ง Pexafy API key เป็น bearer token ไปยัง endpoint เดียวกัน — ซึ่งทำให้คอนเนกเตอร์ใช้งานได้จาก cron job บน build server ที่ไม่มีใครอยู่คลิก “Allow” ขั้นตอนการต่อสายทีละขั้นสำหรับ Claude, ChatGPT และไฟล์ config สำหรับ fleet อยู่ใน บทความ pipeline ซึ่งไม่ได้เปลี่ยนแปลง

HTTP API เมื่อไม่มีใครอยู่ในลูป งานแบบ batch ที่เติมพูลสำหรับ 800 topic cluster ไม่ควรแสร้งทำเป็นไคลเอนต์แชท: บัญชีเดียวกัน คีย์เดียวกัน HTTP ธรรมดา 100 ผลลัพธ์ต่อการเรียก กฎการกะจังหวะที่ไปด้วยกัน — header ของ rate limit เหตุผลว่าทำไม 429 ต่อนาทีถึงคุ้มที่จะลองใหม่ แต่ 429 ที่มาจากโควตารายเดือนนั้นไม่คุ้ม ต้นทุนของ worker ที่ปริมาณสูง — เรื่องเหล่านี้อยู่ใน บทความเรื่องการทำภาพประกอบที่ระดับสเกลใหญ่ ซึ่ง worker ตัวนั้นถูกเขียนออกมาแบบเต็มรูปแบบ

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

สิ่งที่สิ่งนี้แก้ไม่ได้

รายการที่ตรงไปตรงมา เพราะแต่ละข้อเคยทำให้ใครสักคนต้อง rollback มาแล้ว

• สัญญาอนุญาตยังคงควบคุมภาพอยู่ เงื่อนไขการใช้งาน API ของ Pexafy ไม่ได้บังคับให้ต้องให้เครดิต และผลลัพธ์ทุกอันมาพร้อมสตริงเครดิตที่พร้อมแสดงผล — แต่สัญญาอนุญาตที่แนบมาจากไลบรารีต้นทางใช้บังคับกับการใช้งานรูปนั้นของคุณ ให้แสดงเครดิตโดยอัตโนมัติ มันถูกกว่าการมาตรวจสอบทีหลังมาก
• แคตตาล็อกสัญญาอนุญาตฟรีไม่ใช่คลังภาพข่าว ไม่มีข่าว ไม่มีกีฬา ไม่มีแบรนด์หรือบุคคลสาธารณะที่จำได้ตามคำขอ หากหน้าเว็บของคุณต้องการรูปของเหตุการณ์หรือบุคคลที่เฉพาะเจาะจง นั่นคือสิ่งที่ผู้ให้บริการมีลิขสิทธิ์มีไว้ และคอนเนกเตอร์ของพวกเขาก็มีอยู่แล้วในตอนนี้
• มันคือการค้นคืน และมีแค่การค้นคืนเท่านั้น ไดอะแกรม แผนภูมิ และสกรีนช็อตถูกเรนเดอร์จากโค้ด ไม่ใช่ค้นหา การลดความซ้ำซ้อนข้ามหน้าเว็บของคุณเป็นคอลัมน์ในฐานข้อมูลของคุณ ไม่ใช่พารามิเตอร์บน endpoint และไม่มีรูปภาพใดทำให้หน้าเนื้อหาบางติดอันดับได้ — นโยบายสแปมของ Google ปฏิบัติต่อ การใช้เนื้อหาสเกลใหญ่ในทางที่ผิด เหมือนกันไม่ว่าหน้าเว็บนั้นจะมีภาพประกอบหรือไม่6 ทั้งสามข้อนี้เป็นปัญหาของ pipeline ที่มีคำตอบแบบ pipeline ซึ่งอธิบายไว้ใน บทความ pipeline และ บทความเรื่องปริมาณ

เริ่มจากตรงไหนดี

1. ลองรันเบนช์มาร์กซ้ำดู ยี่สิบบรรทัด ไม่ต้องใช้คีย์ ไม่ว่าคุณจะใช้ image API ตัวไหนอยู่ตอนนี้ ลองส่งโจทย์จริงสามข้อจากเอเจนต์ของคุณเองไปตรง ๆ แล้วนับดูว่ามีชุดผลลัพธ์ว่างเปล่ากี่ชุด
2. ต่อคอนเนกเตอร์หนึ่งตัวเข้ากับผู้ช่วยที่คุณใช้อยู่แล้ว และลองขอรูปที่คุณต้องการจริง ๆ ในสัปดาห์นี้ ด้วยประโยคเดียว นั่นคือการประเมินผลทั้งหมดที่ต้องทำ
3. ย้ายโจทย์เข้าไปในเอเจนต์ — หนึ่งฉากต่อหนึ่งช่อง เขียนขึ้นจากร่างเนื้อหา ไม่ใช่จากหัวเรื่อง
4. เพิ่มคอลัมน์ photo_id ก่อนที่คุณจะเผยแพร่อะไรในปริมาณมาก
5. ใช้ระดับฟรีไปก่อน — 5,000 การค้นหาต่อเดือน ที่ 20 ต่อนาที จนกว่าช่วงเวลา build จะบังคับให้คุณต้องอัปเกรด ไม่ใช่บิลค่าใช้จ่าย

อ้างอิงและเชิงอรรถ