Function calling กับ Gemini 3.8 Flash: call_id, iterative tool loops และวิธีทดสอบ

Gemini 3.8 Flash เปิดตัวเมื่อวันที่ 2 กันยายน 2026 และ Google สร้างขึ้นเพื่อ "เรียกใช้เครื่องมือซ้ำๆ": ในงานที่ยาก มันจะทำการเรียก, ตรวจสอบผลลัพธ์, และทำการเรียกอีกครั้ง แทนที่จะคาดเดาทุกอย่างในครั้งเดียว นี่เป็นข่าวดีสำหรับเอเจนต์และเป็นปัญหาใหม่สำหรับใครก็ตามที่เคยปรับแต่ง Tool Loop สำหรับ 3.7 Flash รายละเอียด API สองประการสำคัญกว่าสิ่งอื่นใด ผลลัพธ์ของฟังก์ชันทุกอย่างต้องมีทั้ง call_id และ name และ Interactions API ไม่ใช่ generateContent ตอนนี้เป็นวิธีหลักในการรัน Loop

คู่มือนี้จะอธิบายขั้นตอนการทำงานแบบสองรอบบน Interactions API, แสดงรูปแบบ generateContent แบบเก่าที่คุณอาจยังคงใช้งานอยู่, อธิบายว่าทำไมโมเดลใหม่ถึงใช้รอบและโทเค็นมากขึ้นกับเครื่องมือ, และจบด้วยการตั้งค่าทดสอบที่คุณสามารถรันได้ทุกวัน: จำลองแบ็คเอนด์ของเครื่องมือ, เชื่อมโยงทั้งสองรอบ, และยืนยันว่า call_id ถูกส่งกลับไปกลับมา หากคุณต้องการภาพรวมของโมเดลก่อน, เริ่มต้นด้วย Gemini 3.8 Flash คืออะไร ชื่อฟิลด์ด้านล่างมาจาก เอกสาร Function Calling ของ Google

ทุกคำขอในที่นี้เป็น HTTP ธรรมดาพร้อม JSON ดังนั้นคุณสามารถสร้างและดีบักได้ใน Apidog ก่อนที่จะนำไปใช้ในโค้ดแอปพลิเคชัน

Function Calling บน Gemini 3.8 Flash โดยสรุป

ขั้นตอนที่ 1: ประกาศเครื่องมือ

บน Interactions API เครื่องมือคืออ็อบเจกต์แบบเรียบ: มี type เป็น function, มี name, มี description ที่โมเดลอ่านเพื่อตัดสินใจว่าจะเรียกใช้เมื่อใด และมี JSON Schema ภายใต้ parameters รักษาคำอธิบายให้เฉพาะเจาะจง "ค้นหาสถานะการจัดส่งปัจจุบันของคำสั่งซื้อด้วย ID" จะถูกเรียกใช้ในเวลาที่เหมาะสม; "order helper" จะถูกเรียกใช้แบบสุ่ม

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "input": "Where is order A1029 right now?",
    "generation_config": {"thinking_level": "low"},
    "tools": [{
      "type": "function",
      "name": "get_order_status",
      "description": "Look up the current shipping status of an order by its ID.",
      "parameters": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"]
      }
    }]
  }'

สองทางเลือกในคำขอนี้เป็นสิ่งที่ตั้งใจ thinking_level เป็น low เพราะการค้นหาเดียวไม่จำเป็นต้องใช้ค่าเริ่มต้น medium; คู่มือระดับการคิด ครอบคลุมถึงเวลาที่ควรเพิ่ม และไม่มี temperature คำแนะนำของ Google Gemini 3 คือให้ใช้ค่าเริ่มต้น 1.0 เพราะการลดลงอาจทำให้เกิดการวนซ้ำ ซึ่งเป็นสิ่งสุดท้ายที่คุณต้องการใน Tool Loop

ขั้นตอนที่ 2: อ่านขั้นตอน function_call

Interactions API ไม่ได้ตอบกลับด้วยข้อความเดียว แต่จะคืนค่า id ของ Interaction เอง พร้อมด้วยรายการขั้นตอนการดำเนินการ: ความคิดของโมเดล, การเรียกเครื่องมือ, และสุดท้ายขั้นตอน model_output เมื่อโมเดลมีคำตอบ เมื่อโมเดลตัดสินใจว่าต้องการเครื่องมือของคุณ รายการจะมีขั้นตอน function_call แทน model_output:

{
  "type": "function_call",
  "id": "call_8f2d...",
  "name": "get_order_status",
  "arguments": {"order_id": "A1029"}
}

สามฟิลด์ และคุณต้องการทั้งสาม id คือ handle ที่คุณส่งกลับเป็น call_id name บอกคุณว่าฟังก์ชันใดที่จะรันและต้องส่งกลับด้วย arguments เป็น JSON ที่ถูกแยกวิเคราะห์แล้ว ดังนั้นตรวจสอบความถูกต้องตามกฎของคุณเองก่อนที่จะดำเนินการใดๆ; โมเดลจะเติมตามรูปแบบที่คุณประกาศ แต่ไม่รู้ว่า order ID ของคุณยาวห้าตัวอักษร

เก็บ id ของ Interaction จากด้านบนสุดของ Response ในเวลาเดียวกัน มันจะกลายเป็น previous_interaction_id ในรอบถัดไป

ขั้นตอนที่ 3: คืนค่าผลลัพธ์ด้วย call_id และ name

รันฟังก์ชันของคุณ แล้วส่งคำขอที่สองซึ่ง input คือ function_result ทั้ง call_id และ name เป็นสิ่งที่จำเป็นบน Gemini 3.8 Flash หากขาดสิ่งใดสิ่งหนึ่ง การเรียกจะล้มเหลว ซึ่งเป็นปัญหาที่พบบ่อยที่สุดเมื่อทีมย้าย Loop ที่เขียนขึ้นสำหรับโมเดลเก่า

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "previous_interaction_id": "<interaction id from step 2>",
    "input": [{
      "type": "function_result",
      "name": "get_order_status",
      "call_id": "call_8f2d...",
      "result": [{"type": "text", "text": "{\"status\":\"in_transit\",\"eta\":\"2026-09-05\"}"}]
    }]
  }'

result คือรายการส่วนเนื้อหา และส่วนข้อความมี JSON ของคุณเป็นสตริง เนื่องจาก previous_interaction_id ชี้ไปยังรอบก่อนหน้า เซิร์ฟเวอร์จึงเก็บ prompt ดั้งเดิม, การประกาศเครื่องมือ, และเหตุผลของโมเดลอยู่แล้ว; คุณไม่จำเป็นต้องส่งสิ่งเหล่านี้ซ้ำ การตอบกลับคือรายการขั้นตอนอีกครั้ง หากจบลงด้วย model_output คุณก็ทำเสร็จแล้ว และ SDK จะแสดงข้อความเป็น interaction.output_text หากมี function_call อีกครั้ง ให้กลับไปที่ขั้นตอนที่ 2 Loop นั้นคือรูปแบบทั้งหมด

ใน Python การทำงานคือ client.interactions.create(model="gemini-3.8-flash", input=..., ...) โดยมีฟิลด์ JSON เดียวกันเป็น keyword arguments จากนั้น create ครั้งที่สองพร้อม previous_interaction_id และรายการ function_result เป็น input วิธีใช้ Gemini 3.8 Flash API ครอบคลุมคีย์, การสตรีม, และการอ่านการใช้โทเค็น หาก endpoint นี้เป็นสิ่งใหม่สำหรับคุณ

รูปแบบ generateContent แบบเก่า

โค้ด Gemini ส่วนใหญ่ที่ใช้งานอยู่ยังคงเรียกใช้ models/gemini-3.8-flash:generateContent และ Google ระบุว่า "ยังคงรองรับเต็มที่" โดยไม่มีกำหนดการสิ้นสุด คำศัพท์ที่ใช้แตกต่างกัน; กฎยังคงเหมือนเดิม เครื่องมือถูกประกาศภายใต้ functionDeclarations โมเดลตอบกลับด้วยส่วน functionCall และคุณตอบกลับด้วยส่วน functionResponse บนรูปแบบเก่า ส่วน functionCall ของโมเดลมี id และส่วน functionResponse ของคุณต้องสะท้อนค่าเดียวกันนั้นในฟิลด์ id ของตัวเองพร้อมกับ name และ response มันคือสัญญาเดียวกันกับ call_id บน Interactions API ภายใต้ชื่อฟิลด์ที่แตกต่างกัน และคำแนะนำของ Google Gemini 3 ระบุชัดเจนว่าทั้ง ID และชื่อจำเป็นต้องมี

ความแตกต่างในทางปฏิบัติสองประการ ประการแรก generateContent เป็นแบบ stateless ดังนั้นคุณต้องดูแลการสนทนาด้วยตัวเอง: ประวัติ contents ทั้งหมดจะถูกส่งกลับในทุกๆ รอบ รวมถึงส่วน functionCall ของโมเดลและลายเซ็นความคิดใดๆ ที่มันส่งกลับ ประการที่สอง การกำหนดค่าการคิดจะอยู่ภายใต้ generationConfig.thinkingConfig.thinkingLevel แทนที่จะเป็น generation_config.thinking_level:

{"generationConfig": {"thinkingConfig": {"thinkingLevel": "low"}}}

โทเค็นการคิดจะปรากฏเป็น usageMetadata.thoughtsTokenCount ในการตอบกลับและถูกเรียกเก็บเงินเป็นเอาต์พุต หากคุณกำลังเลือกระหว่างสอง API สำหรับโปรเจกต์ใหม่ ให้เลือก Interactions: สถานะฝั่งเซิร์ฟเวอร์ช่วยขจัดข้อผิดพลาดที่ประวัติที่ถูกส่งซ้ำขาดลายเซ็นหรือ call_id

ทำไม 3.8 Flash จึงเรียกใช้เครื่องมือซ้ำๆ และวิธีจำกัด Loop

โพสต์เปิดตัวของ Google ระบุว่าโมเดล "ทำงานหนักขึ้น": ในงานที่ซับซ้อน "มันจะดำเนินการขั้นตอนการให้เหตุผลเพิ่มเติม และเรียกใช้เครื่องมือซ้ำๆ" โดยใช้ "ขั้นตอนการให้เหตุผลที่เล็กลง" และตรวจสอบงานของมันไปพร้อมกัน Google ยังระบุว่า "สามารถใช้โทเค็นมากขึ้นในงานที่ใช้เวลานานและซับซ้อนขึ้น ตามการออกแบบ" Artificial Analysis ได้วัดผลกระทบ: ประมาณ 48k โทเค็นเอาต์พุตต่องานบนดัชนีของพวกเขา เพิ่มขึ้น 30% จาก 3.7 Flash และมีค่าใช้จ่ายต่องานอยู่ที่ $0.58 ที่ระดับ high เทียบกับ $0.40 สำหรับ 3.7 Flash ที่ราคาต่อโทเค็นเท่ากัน ระดับ Medium อยู่ที่ $0.41 และระดับ low อยู่ที่ $0.24

สำหรับ Tool Loop นี่หมายถึงขั้นตอน function_call ที่มากขึ้นต่องาน ข้อดีคือจริง: Tau3-Banking ซึ่งเป็นการประเมินการใช้เครื่องมือของ AA เพิ่มขึ้น 12 จุดเป็น 45% ข้อเสียคือ Loop ที่ไม่มีขีดจำกัดจะทำงานนานขึ้นกว่าเมื่อเดือนสิงหาคม การควบคุมสี่ประการตามลำดับที่จะใช้:

• จำนวนรอบสูงสุดในระบบของคุณ นับขั้นตอน function_call ต่องานและหยุดที่ขีดจำกัดที่คุณเลือก; 6 ถึง 10 เป็นช่วงเริ่มต้นที่ดีสำหรับการค้นหา, สูงกว่าสำหรับโค้ดแบบ agentic เมื่อถึงขีดจำกัด ให้ส่งรอบสุดท้ายโดยไม่มีเครื่องมือ หรือส่งข้อผิดพลาดกลับไปให้ผู้ใช้ โมเดลจะไม่จำกัดตัวเอง
• thinking_level ต่อเส้นทาง low สำหรับการค้นหาและเครื่องมือแบบ single-hop, medium (ค่าเริ่มต้น) สำหรับงานหลายขั้นตอน, high เฉพาะเมื่อการตรวจสอบเพิ่มเติมคุ้มค่าเท่านั้น อย่าส่ง minimal; 3.8 Flash จะคืนค่าข้อผิดพลาดในการตรวจสอบ
• การหมดเวลาทั้งสองฝั่ง การหมดเวลาต่อคำขอในการเรียก Gemini และเวลาที่ใช้จริงต่องานบน Loop การรันที่ใช้เหตุผลสูงของ AA เฉลี่ย 2.5 นาทีต่องาน, 0.8 นาทีที่ระดับ low
• เครื่องมือที่ทำงานซ้ำได้ (Idempotent tools) โมเดลที่ทำงานซ้ำได้จะลองใหม่ ทำให้ get_order_status ปลอดภัยที่จะเรียกใช้สองครั้ง และทำให้สิ่งใดๆ ที่มีผลข้างเคียง (การคืนเงิน, การส่ง) ต้องมีขั้นตอนการยืนยัน

หากงบประมาณของคุณไม่สามารถรองรับจำนวนรอบที่เพิ่มขึ้นได้ คู่มือการย้ายข้อมูลจาก 3.7 ไป 3.8 Flash ครอบคลุมการรักษา 3.7 Flash ซึ่งยังคงรองรับเต็มที่ ไว้ภายใต้ config flag

Thought Signatures, Parallel Calls และ Structured Outputs

Thought signatures. โมเดล Gemini 3 จะแนบลายเซ็นเข้ากับเหตุผลของมัน ด้วยกระบวนการ Interactions ที่เก็บข้อมูลตามค่าเริ่มต้น previous_interaction_id จะจัดการให้คุณ หากคุณตั้งค่า store: false สำหรับการตั้งค่าแบบ stateless หรือคุณใช้ generateContent คุณต้องส่งบล็อกความคิดและลายเซ็นกลับไปตามที่ได้รับเป๊ะๆ ในทุกประเภทส่วน อย่าตัด, จัดเรียงใหม่, หรือสร้าง serialized ใหม่; ลายเซ็นเป็นสิ่งที่ไม่โปร่งใสและการแก้ไขใดๆ จะทำให้มันไม่ถูกต้อง เอกสาร Interactions API ของ Google ครอบคลุมการแลกเปลี่ยนระหว่างแบบเก็บข้อมูลกับแบบ stateless

Parallel calls. การตอบกลับเป็นรายการ ดังนั้นจึงสามารถมีขั้นตอน function_call ได้มากกว่าหนึ่งรายการเมื่อโมเดลต้องการการค้นหาอิสระหลายอย่างพร้อมกัน เอกสาร function calling ของ Google ยืนยันว่าโมเดล Gemini 3 จะคืนค่า ID ที่ไม่ซ้ำกันพร้อมกับการเรียกแต่ละครั้ง เพื่อให้ผลลัพธ์สามารถกลับมาในลำดับใดก็ได้ จัดการโดยการคืนค่า function_result หนึ่งรายการต่อการเรียกในอาร์เรย์ input เดียวกัน โดยแต่ละรายการจับคู่กับ call_id ของตัวเอง การจับคู่ด้วย name เพียงอย่างเดียวไม่เพียงพอ; การเรียกสองครั้งไปยังฟังก์ชันเดียวกันต้องใช้ค่า call_id ที่แตกต่างกันสองค่า

Structured outputs. 3.8 Flash รองรับ structured outputs และ function calling บนโมเดลเดียวกัน รูปแบบที่ชัดเจนคือเครื่องมือสำหรับ loop และ JSON schema สำหรับคำตอบสุดท้าย เพื่อให้ model_output ที่ปิด loop สามารถอ่านได้ด้วยเครื่องจักรแทนที่จะเป็นข้อความ เอกสาร function-calling และ structured-output ของ Google ได้บันทึกการกำหนดค่านี้ไว้ อย่าปลอมแปลงด้วยการประกาศเครื่องมือ dummy และอ่าน arguments ของมัน; นั่นจะทำให้เกิดข้อผิดพลาดทันทีที่โมเดลตัดสินใจว่าไม่มีอะไรจะเรียก

ทุกสิ่งข้างต้นสมมติว่าโมเดลเข้าถึงระบบของคุณผ่านฟังก์ชันที่ประกาศไว้ Google ยังแสดงรายการ Computer use (Preview) สำหรับ 3.8 Flash; สำหรับกรณีที่ API แบบโครงสร้างดีกว่าการควบคุมเอเจนต์ผ่านหน้าจอ ดูที่ computer use vs structured APIs

การทดสอบ Tool Loop ใน Apidog

Tool Loop มีสามจุดที่จะเกิดข้อผิดพลาดได้แก่: การประกาศ, การส่ง ID ไปกลับ, และคำตอบสุดท้าย คุณสามารถครอบคลุมทั้งสามสิ่งใน Apidog โดยไม่ต้องแตะแบ็คเอนด์จริงของคุณ

1. จำลองแบ็คเอนด์ของเครื่องมือ กำหนด GET /orders/{order_id} เป็น endpoint และเปิด mock server ของมัน กำหนดให้มีการตอบกลับแบบตายตัว {"status": "in_transit", "eta": "2026-09-05"} เพื่อให้ทุกการรันได้รับอินพุตที่เหมือนกัน และการเปลี่ยนแปลงใดๆ ในคำตอบสุดท้ายของโมเดลเกิดจากการทำงานของโมเดล ไม่ใช่ฐานข้อมูลของคุณ ระบบของคุณจะชี้ไปที่ mock URL ในสภาพแวดล้อมการทดสอบและไปยังบริการจริงในการผลิต

2. เชื่อมโยงสองรอบในสถานการณ์ทดสอบ จัดเก็บ GEMINI_API_KEY เป็นตัวแปรสภาพแวดล้อมและอ้างอิงเป็น {{GEMINI_API_KEY}} ในเฮดเดอร์ x-goog-api-key จากนั้นสร้างสถานการณ์ที่มีสามขั้นตอน:

• ขั้นตอน A: POST ไปยัง /v1beta/interactions พร้อมกับ prompt และการประกาศ get_order_status ดึง id ของ interaction และ id, name, และ arguments.order_id ของขั้นตอน function_call ไปยังตัวแปร
• ขั้นตอน B: GET mock endpoint ด้วย {{order_id}} นี่คือขั้นตอน "รันฟังก์ชัน" ของคุณ
• ขั้นตอน C: POST function_result โดยตั้งค่า call_id เป็น {{call_id}}, name เป็น {{tool_name}}, previous_interaction_id เป็น {{interaction_id}}, และใช้เนื้อหาของขั้นตอน B เป็นส่วนข้อความ

3. ยืนยันสิ่งที่สำคัญ

• ขั้นตอน A คืนค่า 200 และมีขั้นตอนที่ type เป็น function_call ที่มี name เท่ากับ get_order_status
• arguments.order_id ที่ถูกดึงออกมาเท่ากับ A1029 ซึ่งพิสูจน์ว่าโมเดลได้แยกวิเคราะห์ prompt และปฏิบัติตาม schema
• ขั้นตอน C คืนค่า 200 และจบลงด้วยขั้นตอนที่ type เป็น model_output โดยไม่มี function_call ที่สอง ซึ่งพิสูจน์ว่า call_id และ name ที่คุณส่งไปได้รับการยอมรับและ loop ปิดในหนึ่งรอบ
• ข้อความสุดท้ายมี in_transit ซึ่งพิสูจน์ว่าโมเดลใช้ผลลัพธ์ของเครื่องมือแทนการคาดเดาของมันเอง
• หากคุณรันสถานการณ์เดียวกันกับ generateContent ให้เพิ่มขีดจำกัดบน usageMetadata.thoughtsTokenCount ต่อ thinking_level สิ่งนี้จะจับการเพิ่มขึ้นของต้นทุน "ทำงานหนักขึ้น" ก่อนที่จะถึงบิลของคุณ

กำหนดเวลาให้สถานการณ์นี้รันทุกวัน พฤติกรรมของโมเดลอาจเปลี่ยนแปลงไปกับการอัปเดตแบบเงียบๆ และ loop ที่เคยปิดได้ในหนึ่งรอบเมื่อสัปดาห์ที่แล้วอาจเริ่มต้องการสองรอบ คู่มือการทดสอบ AI Agent API จะเจาะลึกเกี่ยวกับการยืนยันหลายขั้นตอน และคุณสามารถ ดาวน์โหลด Apidog เพื่อสร้างสถานการณ์นี้กับ free tier ก่อนที่คุณจะใช้จ่ายแม้แต่สตางค์เดียว

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

จำเป็นต้องมี call_id บน Gemini 3.8 Flash หรือไม่? ใช่ บน Interactions API ทุก function_result ต้องการ call_id และ name; บน generateContent ทุก functionResponse ต้องการ id และ name ของการเรียก โค้ดเก่าที่ส่งเพียงชื่อจะล้มเหลวบนโมเดล Gemini 3

ทำไม Tool Loop ของฉันถึงทำงานหลายรอบบน 3.8 Flash มากกว่า 3.7? เป็นการออกแบบ Google ระบุว่าโมเดล "เรียกใช้เครื่องมือซ้ำๆ" และ "สามารถใช้โทเค็นมากขึ้นในงานที่ใช้เวลานานและซับซ้อนขึ้น" จำกัดจำนวนรอบในระบบของคุณและลด thinking_level; คู่มือระดับการคิด มีค่าใช้จ่ายที่วัดได้ในแต่ละระดับ

ฉันยังสามารถใช้ generateContent สำหรับ function calling ได้หรือไม่? ใช่ Google เรียกมันว่าเป็นแบบเก่าแต่ระบุว่า "ยังคงรองรับเต็มที่" โดยไม่มีกำหนดการสิ้นสุด คุณต้องดูแลประวัติด้วยตัวเอง รวมถึงลายเซ็นความคิด และ call id (สะกด id บน API นี้) พร้อมกับ name ยังคงใช้ได้

thinking_level "minimal" ทำงานกับเครื่องมือได้หรือไม่? ไม่ มันจะคืนค่าข้อผิดพลาดในการตรวจสอบบน 3.8 Flash ใช้ low

งานที่ใช้เครื่องมือหนักๆ มีค่าใช้จ่ายเท่าไหร่? ราคาต่อโทเค็นคือ $0.75 อินพุตและ $3.75 เอาต์พุตต่อ 1M โทเค็นจนถึง 31 ธันวาคม 2026 โดยการคิดถูกเรียกเก็บเงินเป็นเอาต์พุต Artificial Analysis วัดได้ $0.58 ต่องานที่ระดับ high, $0.41 ที่ระดับ medium, และ $0.24 ที่ระดับ low บนดัชนีของพวกเขา งานของคุณจะแตกต่างกัน ดังนั้นให้ยืนยันจำนวนโทเค็นและวัดผล

นำ Loop ออกใช้พร้อมกับการจำกัด

ประกาศเครื่องมือ, อ่านขั้นตอน function_call, และคืนค่า function_result พร้อมทั้ง call_id และ name ภายใต้ previous_interaction_id นี่คือสัญญาฉบับสมบูรณ์ สิ่งที่เปลี่ยนแปลงกับ Gemini 3.8 Flash คือความเต็มใจของโมเดลที่จะทำงานวนซ้ำ ดังนั้นระบบจึงจำเป็นต้องมีขีดจำกัดจำนวนรอบ, thinking_level ต่อเส้นทาง, และการหมดเวลาก่อนที่จะนำไปใช้จริง จำลองแบ็คเอนด์, เชื่อมโยงสองรอบ, ยืนยันว่า ID ถูกส่งกลับไปกลับมา, และกำหนดเวลารัน หน้า What’s new in Gemini 3.8 Flash ของ Google มีบันทึกการย้ายข้อมูล; คู่มือหลัก มีทุกสิ่งทุกอย่างเกี่ยวกับโมเดล