การขับเคลื่อนเบราว์เซอร์ด้วย LLM ผ่านโมเดลการใช้งานคอมพิวเตอร์นั้นมีค่าใช้จ่ายสูงกว่าการเรียกใช้ผู้ให้บริการรายเดียวกันผ่าน API แบบมีโครงสร้างถึงประมาณ 45 เท่า ใช่แล้ว
คู่มือนี้จะอธิบายตัวเลข 45 เท่าดังกล่าว อธิบายว่าเมื่อใดที่การใช้งานคอมพิวเตอร์ยังคงมีประโยชน์ และแสดงวิธีทำให้ทั้งสองเส้นทางรวดเร็วและประหยัดเมื่อคุณสร้างด้วย Apidog. กรอบการทำงานต่อไปนี้ใช้ได้กับ OpenAI Operator, การใช้งานคอมพิวเตอร์ของ Anthropic, การใช้งานเบราว์เซอร์, Skyvern และเครื่องมือใหม่ ๆ ในอนาคตที่มาพร้อมกับลูปการจับภาพหน้าจอ
หากคุณเขียน API สำหรับเอเจนต์ AI คุณควรอ่านคู่มือประกอบของเราเกี่ยวกับ วิธีการเขียนไฟล์ agents.md ด้วย; ข้อกำหนดในนั้นจะทำให้เส้นทาง API แบบมีโครงสร้างเป็นค่าเริ่มต้นที่ชัดเจนสำหรับผู้เรียกใช้ของคุณ
สรุปสั้นๆ (TL;DR)
- การใช้งานคอมพิวเตอร์หมายถึง LLM ดูภาพหน้าจอและส่งการคลิก, การกดแป้นพิมพ์ และการเลื่อน; API แบบมีโครงสร้างหมายถึง LLM ส่งการเรียกใช้เครื่องมือ JSON ที่แบ็กเอนด์ของคุณดำเนินการ
- สำหรับงานเดียวกัน การใช้งานคอมพิวเตอร์ใช้โทเค็นมากกว่า 30 ถึง 50 เท่า เนื่องจากทุกขั้นตอนมีการส่งภาพหน้าจอใหม่ รวมถึงการลองใหม่
- เลือกใช้การใช้งานคอมพิวเตอร์เฉพาะในกรณีที่ไม่มี API, API ถูกจำกัดอัตราการใช้งาน หรือเวิร์กโฟลว์อยู่เบื้องหลังการรับรองความถูกต้องที่ต้านทานการเขียนสคริปต์
- เลือกใช้ API แบบมีโครงสร้างสำหรับสิ่งอื่น ๆ ทั้งหมด: การชำระเงิน, การค้นหา, การอัปเดต CRM, เครื่องมือภายใน, อะไรก็ตามที่คุณสามารถจัดทำเอกสารด้วย OpenAPI
- ไฮบริดคือคำตอบที่เป็นจริง: API แบบมีโครงสร้างจัดการ 90 เปอร์เซ็นต์ที่มีปลายทาง, การใช้งานคอมพิวเตอร์ครอบคลุมส่วนที่เหลือ
- ดาวน์โหลด Apidog เพื่อออกแบบสคีมาเครื่องมือ JSON, จำลองปลายทางในขณะที่คุณทำซ้ำ, และเล่นซ้ำทั้งกระบวนการโดยไม่ต้องใช้เครดิตเอเจนต์
ทำไมช่องว่างของค่าใช้จ่ายจึงใหญ่ขนาดนี้
ตัวเลข 45 เท่าไม่ใช่เกณฑ์มาตรฐานที่ชาญฉลาด; มันเกิดจากวิธีที่แต่ละเส้นทางใช้โทเค็น
การเรียกใช้ API แบบมีโครงสร้างจะส่งพรอมต์เดียวพร้อมคำขอของผู้ใช้และสคีมาเครื่องมือ จากนั้นจะได้รับออบเจกต์ JSON ที่รันไทม์ดำเนินการ การเดินทางไปกลับ: โทเค็นขาเข้าไม่กี่ร้อย, โทเค็นขาออกห้าสิบ, การเชื่อมต่อเครือข่ายหนึ่งครั้ง
ลูปการใช้งานคอมพิวเตอร์จะส่งพรอมต์เดียวกันพร้อมกับภาพหน้าจอ, ได้รับพิกัดการคลิก, ดำเนินการ, จับภาพหน้าจออีกครั้ง และทำซ้ำ งาน “จองเที่ยวบิน” ทั่วไปจะดำเนินการ 12 ถึง 30 รอบ แต่ละภาพหน้าจอมีค่าใช้จ่ายประมาณ 1,500 โทเค็นที่ความละเอียดปกติ ลองคูณดู
เอกสาร การใช้งานคอมพิวเตอร์ ของ Anthropic ระบุราคาโทเค็นของภาพหน้าจออย่างเปิดเผย; ค่าใช้จ่ายจริงนั้นสูงกว่านั้นอีก เนื่องจากโมเดลจะลองใหม่เมื่อคลิกผิด, เลื่อนผ่านองค์ประกอบที่ถูกต้อง, และใช้รอบในการปิดแบนเนอร์คุกกี้. กระทู้ HN ที่อ้างถึง การใช้งานคอมพิวเตอร์แพงกว่า API แบบมีโครงสร้าง 45 เท่า ได้ระบุบทลงโทษโดยทั่วไปไว้ที่ 30 ถึง 50 เท่า ซึ่งตรงกับสิ่งที่เราเห็นเมื่อเราเล่นซ้ำงานเดียวกันผ่านทั้งสองเส้นทางใน Apidog.
เมื่อเส้นทาง API แบบมีโครงสร้างชนะ
กำหนดค่าเริ่มต้นเป็น API แบบมีโครงสร้างเมื่อเป็นไปตามเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้
ผู้ขายเผยแพร่ข้อมูลจำเพาะของ OpenAPI, สคีมา GraphQL หรือแม้แต่หน้า REST เพียงหน้าเดียว หากมีรูปแบบ JSON อยู่ LLM สามารถเติมข้อมูลได้ ความแม่นยำของการเรียกใช้เครื่องมือบน GPT-5.5, Claude 4.5 และ DeepSeek V4 สูงกว่า 95 เปอร์เซ็นต์สำหรับปลายทางที่มีการจัดทำเอกสาร; รูปแบบความล้มเหลวนั้นหายาก ตรวจจับได้ง่าย และลองใหม่ได้ง่าย
งานพอดีกับปลายทางหนึ่งหรือสองปลายทาง “สร้างลูกค้า Stripe,” “อัปเดตขั้นตอนข้อตกลง HubSpot,” “โพสต์ข้อความ Slack,” “เรียกใช้ CI ซ้ำ” ล้วนเป็นการเรียกใช้ครั้งเดียว การกำหนดเส้นทางผ่านเบราว์เซอร์เทียบเท่ากับการส่งโปสการ์ดจากอีกฟากของห้องในทางวิศวกรรม
เวิร์กโฟลว์ทำงานโดยอัตโนมัติ Cron jobs, webhooks และ queue workers ไม่สามารถดูแลลูปการจับภาพหน้าจอที่ตัดสินใจเลื่อนไปในทิศทางที่ผิดได้ การเรียกใช้แบบมีโครงสร้างนั้นเป็นแบบกำหนดได้ในระดับเครือข่าย
ความหน่วงแฝงมีความสำคัญ การเรียกใช้แบบมีโครงสร้างจะคืนค่าใน 200 ถึง 800 มิลลิวินาที ลูปการใช้งานคอมพิวเตอร์ที่มี 15 รอบใช้เวลา 30 ถึง 90 วินาที ซึ่งนานขึ้นเมื่อมีการลองใหม่
คุณต้องทดสอบก่อนที่จะนำไปใช้งาน การจำลองปลายทาง JSON ใช้เวลาไม่กี่วินาทีใน Apidog การจำลองลูปจับภาพหน้าจอของเบราว์เซอร์เป็นโครงการวิจัย
เมื่อการใช้งานคอมพิวเตอร์ยังคงมีประโยชน์
ยังมีบางกรณีที่ยังคงให้ความสำคัญกับลูปการจับภาพหน้าจอ
พอร์ทัลผู้ขายแบบเก่า พอร์ทัลการจัดซื้อ, การขนส่ง และสวัสดิการบางแห่งมีมาก่อน REST พอร์ทัลเหล่านี้ทำงานอยู่เบื้องหลังเซสชัน ASP.NET โดยไม่มีอินเทอร์เฟซสำหรับเครื่องจักร การใช้งานคอมพิวเตอร์เข้ามาแทนที่สคริปต์ Selenium ที่เปราะบางซึ่งเสียทุกไตรมาส; การแลกเปลี่ยนค่าใช้จ่าย 45 เท่ากับการบำรุงรักษาเป็นศูนย์บางครั้งก็เป็นการตัดสินใจที่ถูกต้อง
เครื่องมือภายในที่คุณไม่สามารถแก้ไขได้ CRM ที่ลูกค้าของคุณจ่ายเงินไปในปี 2014, ERP แบบเก่า, แดชบอร์ด SharePoint หากคุณไม่สามารถจัดส่งการบูรณาการได้และทีมไม่ต้องการจ่ายเงินสำหรับ iPaaS, ลูปการจับภาพหน้าจอก็เป็นทางเลือกที่แท้จริง
งานปฏิบัติการครั้งเดียว ผู้ก่อตั้งที่ขอให้เอเจนต์ “วิจัยคู่แข่ง 50 รายนี้และใส่ข้อมูลสำคัญลงใน Notion” ไม่ใช่เวิร์กโฟลว์ที่ต้องการสัญญาแบบมีโครงสร้าง การใช้งานคอมพิวเตอร์จะจัดการมันเพียงครั้งเดียวแล้วหายไป
การทำวิศวกรรมย้อนกลับที่ได้รับการคุ้มครองโดยข้อกำหนดและเงื่อนไข ข้ามข้อนี้ไป คำขอ “ขูดเว็บไซต์นี้ด้วยการใช้งานคอมพิวเตอร์” ส่วนใหญ่อยู่ในด้านที่ผิดของข้อกำหนดของผู้ขาย; ค่าใช้จ่ายเป็นเรื่องเล็กน้อยที่สุดในปัญหาของคุณ
กรอบการตัดสินใจง่ายๆ
เรียกใช้คำขอผ่านการตรวจสอบสี่ข้อนี้ก่อนที่จะใช้การใช้งานคอมพิวเตอร์
| ตรวจสอบ | ถ้าใช่ | ถ้าไม่ |
|---|---|---|
| มี API ที่มีเอกสารอยู่หรือไม่? | ใช้ API | ดำเนินการต่อ |
| คุณสามารถส่งอะแดปเตอร์ฝั่งเซิร์ฟเวอร์แบบบางที่ห่อหุ้มปลายทางส่วนตัวได้หรือไม่? | สร้างอะแดปเตอร์, เปิดเผยเป็น JSON | ดำเนินการต่อ |
| เป็นงานที่ทำครั้งเดียวหรือมีปริมาณน้อย (น้อยกว่า 100 ครั้ง/วัน) หรือไม่? | การใช้งานคอมพิวเตอร์เป็นที่ยอมรับได้ | ดำเนินการต่อ |
| คุณโอเคกับการจ่ายค่าโทเค็น 30-50 เท่าในการรันแต่ละครั้งหรือไม่? | ใช้งานคอมพิวเตอร์ | หยุด เจรจาขอเข้าถึง API |
สามในสี่ของเวิร์กโฟลว์ที่เราเห็นในโค้ดเบสของลูกค้าล้มเหลวในการตรวจสอบข้อหนึ่งหรือสอง; การใช้งานคอมพิวเตอร์จะอยู่รอดก็ต่อเมื่อทั้งสองข้อล้มเหลว
API แบบมีโครงสร้างมีลักษณะอย่างไรในเอเจนต์
นี่คืองาน “ดึงการชำระเงินที่ล้มเหลวเมื่อวานนี้” ที่แสดงออกมาทั้งสองวิธี เวอร์ชันที่มีโครงสร้างคือสิ่งที่คุณต้องการให้เอเจนต์ทุกตัวใช้เป็นค่าเริ่มต้น
from openai import OpenAI
client = OpenAI()
tools = [{
"type": "function",
"function": {
"name": "list_failed_payments",
"description": "List failed payments in a date range",
"parameters": {
"type": "object",
"properties": {
"start": {"type": "string", "format": "date"},
"end": {"type": "string", "format": "date"},
},
"required": ["start", "end"],
},
},
}]
resp = client.chat.completions.create(
model="gpt-5.5",
messages=[{"role": "user", "content": "Show yesterday's failed payments."}],
tools=tools,
tool_choice="auto",
)
call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)
payments = stripe.PaymentIntent.list(
created={"gte": args["start"], "lte": args["end"]},
limit=100,
)
พรอมต์สองรายการเข้า, การตอบกลับแบบมีโครงสร้างหนึ่งรายการออก, การเรียก HTTP หนึ่งครั้งไปยัง Stripe เอเจนต์ไม่เคยเห็นแดชบอร์ด
การใช้งานคอมพิวเตอร์ที่เทียบเท่ากันจะเปิดเบราว์เซอร์, เข้าสู่ระบบ Stripe, จับภาพหน้าจอแดชบอร์ด, คลิกตัวเลือกวันที่, จับภาพหน้าจออีกครั้ง, ลากช่วง, จับภาพหน้าจอ, เลื่อนไปที่ “ล้มเหลว,” จับภาพหน้าจอ, และสุดท้ายดึงตัวเลขจากพิกเซล แต่ละภาพหน้าจอมีโทเค็นอินพุตประมาณ 1,500 โทเค็น สิบสองรอบเป็นเรื่องปกติ ค่าใช้จ่ายคือ 45 เท่าและอัตราความสำเร็จต่ำกว่า
การออกแบบเส้นทางแบบมีโครงสร้างด้วย Apidog
เหตุผลที่ทีมหันไปใช้การใช้งานคอมพิวเตอร์นั้นไม่ค่อยเกี่ยวกับค่าใช้จ่าย; มักจะเป็นเพราะไม่มีใครออกแบบพื้นผิวเครื่องมือที่สะอาดสำหรับเอเจนต์ Apidog ให้พื้นที่คุณในการทำงานนั้นอย่างถูกต้อง
ขั้นตอนที่หนึ่ง: จำลองการทำงานที่เอเจนต์ต้องการเป็นปลายทางในโครงการ Apidog การมี POSTs ไม่กี่รายการที่ครอบคลุม “รายการใบแจ้งหนี้,” “อัปเดตข้อตกลง,” “ส่งข้อความ” ก็เพียงพอที่จะแทนที่ 80 เปอร์เซ็นต์ของการสาธิตของผู้ปฏิบัติงาน Apidog สร้างเอกสาร OpenAPI 3.1 โดยตรงจากมุมมองการออกแบบ
ขั้นตอนที่สอง: ป้อนเอกสาร OpenAPI นั้นเข้าสู่กรอบการทำงานเอเจนต์ของคุณ อาร์เรย์ tools ของ OpenAI, สคีมาการใช้งานเครื่องมือของ Anthropic และตัวโหลด OpenAPI ของ LangChain ล้วนใช้ OpenAPI 3.1 โดยตรง ตอนนี้เอเจนต์มีการเรียกใช้ฟังก์ชันแบบมีประเภทที่สะท้อนการออกแบบของคุณ
ขั้นตอนที่สาม: เปิดเซิร์ฟเวอร์จำลองของ Apidog การจำลองจะคืนค่า JSON ที่สมจริงสำหรับทุกปลายทาง ดังนั้นคุณสามารถเรียกใช้เอเจนต์ตั้งแต่ต้นจนจบโดยไม่ต้องเข้าสู่การผลิตหรือจ่ายค่าโทเค็นในการทำงานจริง เราครอบคลุมรูปแบบเดียวกันใน คู่มือการพัฒนาแบบสัญญามาก่อนของ Apidog
ขั้นตอนที่สี่: เล่นซ้ำการรับส่งข้อมูล Apidog บันทึกทุกคำขอและการตอบกลับในขณะที่เอเจนต์ทำงาน ดังนั้นคุณสามารถเปรียบเทียบการทำงานที่ผ่านกับการทำงานที่ล้มเหลวและดูว่าการเรียกใช้เครื่องมือใดเปลี่ยนไป นี่คือวิธีที่คุณลดปัญหา “เอเจนต์ทำงานเมื่อวานนี้และเสียในวันนี้”
ขั้นตอนที่ห้า: ส่งมอบ โครงการเดียวกันนี้ยังทำหน้าที่เป็นเอกสารสาธารณะของคุณ, ชุดทดสอบ QA ของคุณ และแดชบอร์ดการตรวจสอบของคุณ
ไฮบริด: เมื่อคุณต้องการทั้งสองเส้นทาง
ในการใช้งานจริง เอเจนต์ส่วนใหญ่จะลงเอยด้วยการเป็นไฮบริด ค่าเริ่มต้นที่เหมาะสมจะมีลักษณะดังนี้
- 90 เปอร์เซ็นต์ของการดำเนินการผ่านพื้นผิวเครื่องมือแบบมีโครงสร้างที่คุณออกแบบ
- 10 เปอร์เซ็นต์จะกลับไปใช้ลูปการใช้งานคอมพิวเตอร์สำหรับพอร์ทัลแบบเก่าที่เหลืออยู่
- พรอมต์เราเตอร์จะตัดสินใจว่าจะใช้เส้นทางใดตามชื่อการดำเนินการ
เราเตอร์เป็นข้อความระบบเล็กๆ: “ถ้า tool_name อยู่ใน known_tools, ให้เรียกใช้เครื่องมือ มิฉะนั้น ให้ส่งต่อไปยังเอเจนต์เบราว์เซอร์” Claude 4.5 ของ Anthropic และ GPT-5.5 ของ OpenAI ล้วนจัดการการกำหนดเส้นทางนี้ได้อย่างน่าเชื่อถือ; คุณสามารถร่างรูปแบบเดียวกันใน DeepSeek V4 ดู วิธีใช้ DeepSeek V4 API สำหรับรูปแบบคำขอ
ติดตามทั้งสองเส้นทางแยกกันในระบบตรวจสอบของคุณ การเรียกใช้แบบมีโครงสร้างควรคิดเป็น 99 เปอร์เซ็นต์ของปริมาณและ 30 เปอร์เซ็นต์ของค่าใช้จ่าย; การใช้งานคอมพิวเตอร์สำรองควรคิดเป็น 1 เปอร์เซ็นต์ของปริมาณและ 70 เปอร์เซ็นต์ของค่าใช้จ่าย หากอัตราส่วนกลับกัน แสดงว่ามีคนเพิ่มการดำเนินการผิดวิธี และคุณจำเป็นต้องออกแบบปลายทางสำหรับมัน
ข้อผิดพลาดทั่วไปที่ควรหลีกเลี่ยง
นี่คือรูปแบบที่ปรากฏในตั๋วสนับสนุน
ข้ามสคีมา ทีมงานส่งมอบเอเจนต์ด้วยพรอมต์ระบบที่เป็นข้อความล้วนๆ และสงสัยว่าทำไมการเรียกใช้แบบมีโครงสร้างจึงล้มเหลว ควรส่ง JSON Schema เสมอ ทั้ง Claude และ GPT ปรับปรุงความแม่นยำของเครื่องมือได้ถึงเลขสองหลักเมื่อสคีมาเข้มงวด
ให้เอเจนต์ออกแบบสคีมาในขณะรันไทม์ สคีมาคือพื้นผิวผลิตภัณฑ์ เขียนมันใน Apidog, กำหนดเวอร์ชัน และปฏิบัติต่อการเปลี่ยนแปลงในลักษณะเดียวกับการเปลี่ยนแปลง API สาธารณะ สคีมาที่ปรับเปลี่ยนตัวเองได้คือสาเหตุที่ทำให้เกิดการหยุดชะงักของการผลิต
การบันทึกโทเค็น ไม่ใช่ค่าใช้จ่าย โทเค็นการใช้งานคอมพิวเตอร์ซ่อนอยู่ในอินพุตรูปภาพ ซึ่งเครื่องมือตรวจสอบส่วนใหญ่มีราคาแตกต่างกัน อ่านคอนโซลการเรียกเก็บเงินของผู้ให้บริการของคุณ ไม่ใช่แดชบอร์ดการติดตามของคุณ
สับสนระหว่างการใช้งานคอมพิวเตอร์กับ RPA การทำงานอัตโนมัติด้วยหุ่นยนต์ (RPA) ดำเนินการคลิกตามสคริปต์กับองค์ประกอบ DOM ที่รู้จัก การใช้งานคอมพิวเตอร์จะตัดสินใจใหม่ว่าจะคลิกอะไรในทุกๆ ภาพหน้าจอ แบบแรกทำซ้ำได้และราคาถูก; แบบที่สองมีความยืดหยุ่นและมีราคาแพง อย่าเลือกใช้การใช้งานคอมพิวเตอร์เมื่อ RPA เป็นเครื่องมือที่เหมาะสม
ลืมเรื่องค่าใช้จ่ายของความหน่วงแฝง บิลโทเค็น 45 เท่าเป็นภาษีอย่างหนึ่ง สิ่งที่ใหญ่กว่าคือลูปการจับภาพหน้าจอ 60 วินาทีจะทำให้เอเจนต์หลุดออกจากขั้นตอนของผู้ใช้ หากผู้ใช้กำลังรออยู่ คุณมักจะต้องการ API เสมอ
ทางเลือกที่ควรพิจารณา
หากผู้ขายไม่มี API แต่มี UI ที่เป็นที่รู้จักดี มีสามทางเลือกระหว่างการใช้งานคอมพิวเตอร์เต็มรูปแบบและการบูรณาการเต็มรูปแบบ
สคริปต์เบราว์เซอร์แบบไม่มีหัว (Playwright, Puppeteer) ไม่มีค่าใช้จ่ายต่อการรันหลังจากพัฒนาเสร็จแล้ว พวกมันจะเสียเมื่อ UI เปลี่ยนแปลง; ควรตั้งงบประมาณสำหรับเรื่องนั้น
ตัวเชื่อมต่อ Zapier หรือ Make ที่ผู้ขายเผยแพร่ แพลตฟอร์ม iPaaS ได้จ่ายค่าธรรมเนียมการรวมระบบให้คุณแล้ว จ่ายค่าที่นั่ง, จัดส่งได้เร็วขึ้น
API ส่วนตัวที่ทำวิศวกรรมย้อนกลับ ตรวจสอบแท็บเครือข่ายใน DevTools แดชบอร์ดของผู้ขายหลายแห่งสื่อสารกับปลายทาง JSON ภายในที่คุณสามารถเรียกใช้ได้โดยตรงด้วยคุกกี้การรับรองความถูกต้องเดียวกัน จัดทำเอกสารใน Apidog และถือว่ามันมีความเสถียรปานกลาง เราใช้เคล็ดลับนี้ใน การทดสอบ API โดยไม่ต้องใช้ Postman
การใช้งานคอมพิวเตอร์เป็นทางเลือกสุดท้าย ไม่ใช่ค่าเริ่มต้น
กรณีการใช้งานจริง
ทีมงานปฏิบัติตามกฎระเบียบของ Fintech ได้แทนที่รายงาน Stripe ที่ใช้คอมพิวเตอร์ 6 ขั้นตอนด้วยการเรียกใช้แบบมีโครงสร้างสามครั้ง ค่าใช้จ่ายโทเค็นลดลง 92 เปอร์เซ็นต์ และการรันจาก 41 วินาทีเหลือ 2 วินาที
เอเจนต์สนับสนุน SaaS แบบ B2B ใช้การใช้งานคอมพิวเตอร์สำหรับเวิร์กโฟลว์เดียวเท่านั้น: พอร์ทัลจัดซื้อของผู้ขายที่ไม่มี API ส่วนที่เหลือทั้งหมดถูกกำหนดเส้นทางผ่านการเรียกใช้เครื่องมือ OpenAPI ที่ออกแบบใน Apidog ค่าใช้จ่ายโทเค็นทั้งหมดของเอเจนต์ลดลงจาก 4,200 ดอลลาร์เหลือ 310 ดอลลาร์ต่อเดือน
ผู้ก่อตั้งคนเดียวใช้การใช้งานคอมพิวเตอร์สัปดาห์ละครั้งเพื่อรีเฟรชแดชบอร์ด Notion จาก ERP แบบเก่า ค่าใช้จ่าย 45 เท่าในการรันสัปดาห์ละครั้งมีเพียงไม่กี่เซ็นต์; ทางเลือกอื่นคือโครงการรวมระบบที่ใช้เวลาหลายสัปดาห์ นั่นคือรูปแบบที่เหมาะสมสำหรับการใช้งานคอมพิวเตอร์
บทสรุป
ตัวเลข 45 เท่าเป็นเรื่องจริง ทำซ้ำได้ และควรปรับเปลี่ยนวิธีที่ทีมของคุณเลือกใช้เครื่องมือ กำหนดค่าเริ่มต้นเป็น API แบบมีโครงสร้างที่ออกแบบใน Apidog; ใช้การใช้งานคอมพิวเตอร์เฉพาะในกรณีที่ไม่มี API และเวิร์กโฟลว์ทำงานไม่บ่อยพอจนค่าใช้จ่ายโทเค็นเป็นเพียงค่าผิดพลาดในการปัดเศษ
ห้าประเด็นสำคัญที่ควรนำไปใช้:
- การใช้งานคอมพิวเตอร์ใช้โทเค็นมากกว่าการเรียกใช้ API แบบมีโครงสร้างที่เทียบเท่ากันถึง 30 ถึง 50 เท่า
- ปลายทางที่มีเอกสารประกอบพร้อมกับ JSON Schema เหนือกว่าลูปการจับภาพหน้าจอในด้านค่าใช้จ่าย, ความหน่วงแฝง และความน่าเชื่อถือ
- สแต็กแบบไฮบริดเป็นเรื่องปกติ: ออกแบบ 90 เปอร์เซ็นต์ใน Apidog, และกลับไปใช้การใช้งานคอมพิวเตอร์สำหรับ 10 เปอร์เซ็นต์ที่เหลือ
- จำลองพื้นผิวเครื่องมือแบบมีโครงสร้างก่อนที่คุณจะเชื่อมต่อกับโมเดลจริง ช่วยประหยัดเครดิตเอเจนต์และย่นระยะเวลาการทำงาน
- ติดตามทั้งสองเส้นทางแยกกันในระบบตรวจสอบ เพื่อให้คุณสังเกตเห็นเมื่ออัตราส่วนเปลี่ยนแปลงไป
ขั้นตอนต่อไป: เปิด Apidog, สร้างโปรเจกต์สำหรับพื้นผิวเครื่องมือของเอเจนต์ของคุณ และเปิดเซิร์ฟเวอร์จำลอง ภายในหนึ่งชั่วโมง คุณจะทราบว่าเวิร์กโฟลว์ที่คุณตั้งใจจะส่งมอบโดยใช้การใช้งานคอมพิวเตอร์สามารถยุบรวมเป็นการเรียกใช้แบบมีโครงสร้างสองครั้งแทนได้หรือไม่
คำถามที่พบบ่อย
การใช้งานคอมพิวเตอร์มีราคาถูกกว่า API แบบมีโครงสร้างหรือไม่?
ไม่ ไม่ใช่ในแต่ละครั้งที่รัน โทเค็นภาพหน้าจอมีค่าใช้จ่ายมากกว่า การใช้งานคอมพิวเตอร์อาจมีราคาถูกกว่าโดยรวมเมื่อค่าใช้จ่ายในการรวมระบบจะเกินค่าใช้จ่ายในการรันหลายปี ซึ่งเกิดขึ้นได้เฉพาะกับเวิร์กโฟลว์ที่มีปริมาณน้อยมากเมื่อเทียบกับ API ที่ไม่มีอยู่
ฉันจะจำลองพื้นผิวเครื่องมือ JSON สำหรับเอเจนต์ได้อย่างไร?
ออกแบบปลายทางใน Apidog, เปิดเซิร์ฟเวอร์จำลองในตัว, และชี้เอเจนต์ของคุณไปยัง URL จำลอง ทุกคำขอจะส่งคืน JSON ที่สมจริงโดยไม่มีค่าใช้จ่ายโทเค็น เราครอบคลุมเวิร์กโฟลว์ตั้งแต่ต้นจนจบใน เครื่องมือทดสอบ API สำหรับวิศวกร QA
ฉันสามารถใช้ OpenAPI สำหรับการเรียกใช้เครื่องมือในโมเดลใดก็ได้หรือไม่?
ได้ พารามิเตอร์ tools ของ OpenAI, บล็อก tool_use ของ Anthropic และปลายทางการเรียกใช้เครื่องมือของ DeepSeek V4 ล้วนใช้สคีมา OpenAPI 3.1 Apidog ส่งออกสคีมาได้อย่างสะอาดตา ดู วิธีใช้ DeepSeek V4 API สำหรับรูปแบบคำขอของ DeepSeek
GPT-5.5 ยังคงรองรับการใช้งานคอมพิวเตอร์อยู่หรือไม่?
OpenAI จัดส่งการใช้งานคอมพิวเตอร์ผ่านผลิตภัณฑ์ Operator และผ่าน Responses API โปรไฟล์ค่าใช้จ่ายใกล้เคียงกับการจับภาพหน้าจอต่อภาพหน้าจอของ Anthropic คำแนะนำในบทความนี้ใช้ได้โดยไม่คำนึงถึงผู้ให้บริการ
แล้ว Skyvern, การใช้งานเบราว์เซอร์ และเอเจนต์โอเพนซอร์สอื่นๆ ล่ะ?
หลักการคำนวณเดียวกัน พวกมันลดราคาต่อการเรียกใช้โดยการกำหนดเส้นทางผ่านโมเดลโอเพนซอร์สที่ถูกกว่า แต่จำนวนรอบและขนาดภาพหน้าจอคล้ายกัน API แบบมีโครงสร้างยังคงเหนือกว่ามากในกรณีที่มี API อยู่
ฉันจะรู้ได้อย่างไรว่าปลายทางหายไปสำหรับงานเอเจนต์?
สังเกตว่าการเรียกใช้เครื่องมือใดล้มเหลวหรือถูกปฏิเสธ หากเอเจนต์ยังคงพยายามกลับไปใช้เบราว์เซอร์ นั่นคือปลายทางที่หายไปในพื้นผิวเครื่องมือของคุณ เพิ่มมันใน Apidog, สร้างสคีมาใหม่, และเอเจนต์จะหยุดการกลับไปใช้เบราว์เซอร์