امضاهای فکری، بازنماییهای رمزگذاریشدهای از فرآیند فکری داخلی مدل هستند و برای حفظ زمینه استدلال در تعاملات چند نوبتی استفاده میشوند. هنگام استفاده از مدلهای فکری (مانند سری Gemini 3 و 2.5)، API ممکن است یک فیلد thoughtSignature را در بخشهای محتوای پاسخ (مثلاً بخشهای text یا functionCall ) برگرداند.
به عنوان یک قاعده کلی، اگر در یک پاسخ مدل، امضای فکری دریافت کردید، باید آن را دقیقاً همانطور که دریافت کردهاید، هنگام ارسال تاریخچه مکالمه در نوبت بعدی، ارسال کنید. هنگام استفاده از Gemini 3 Pro، باید امضای فکری را هنگام فراخوانی تابع ارسال کنید، در غیر این صورت با خطای اعتبارسنجی (کد وضعیت 4xx) مواجه خواهید شد .
چگونه کار میکند؟
تصویر زیر معنای «نوبت» و «مرحله» را در رابطه با فراخوانی تابع در رابط برنامهنویسی کاربردی Gemini نشان میدهد. «نوبت» یک تبادل واحد و کامل در مکالمه بین کاربر و مدل است. «مرحله» یک عمل یا عملیات جزئیتر است که توسط مدل انجام میشود و اغلب به عنوان بخشی از یک فرآیند بزرگتر برای تکمیل یک نوبت انجام میشود.

این سند بر مدیریت تابع فراخوانیشده برای Gemini 3 Pro تمرکز دارد. برای مشاهدهی مغایرتها با نسخهی ۲.۵ به بخش رفتار مدل مراجعه کنید.
Gemini 3 Pro با فراخوانی یک تابع، امضاهای فکری را برای همه پاسخهای مدل (پاسخهای دریافتی از API) برمیگرداند. امضاهای فکری در موارد زیر ظاهر میشوند:
- وقتی فراخوانیهای تابع موازی وجود دارد، اولین بخش فراخوانی تابع که توسط پاسخ مدل برگردانده میشود، یک امضای فکری خواهد داشت.
- وقتی فراخوانیهای تابع به صورت متوالی (چند مرحلهای) وجود دارد، هر فراخوانی تابع یک امضا خواهد داشت و شما باید تمام امضاها را برگردانید.
- پاسخهای مدل بدون فراخوانی تابع، یک امضای فکری را در آخرین بخش برگردانده شده توسط مدل، برمیگردانند.
جدول زیر، با ترکیب تعاریف نوبتها و مراحل با مفهوم امضاهای معرفی شده در بالا، تصویری از فراخوانیهای تابع چند مرحلهای ارائه میدهد:
نوبت | قدم | درخواست کاربر | پاسخ مدل | تابع پاسخ |
۱ | ۱ | request1 = user_prompt | FC1 + signature | FR1 |
۱ | ۲ | request2 = request1 + (FC1 + signature) + FR1 | FC2 + signature | FR2 |
۱ | ۳ | request3 = request2 + (FC2 + signature) + FR2 | text_output(بدون FC) | هیچکدام |
امضاها در بخشهای فراخوانی تابع
وقتی Gemini یک functionCall تولید میکند، برای پردازش صحیح خروجی ابزار در نوبت بعدی به thought_signature متکی است.
- رفتار :
- فراخوانی تک تابع : بخش
functionCallشامل یکthought_signatureخواهد بود. - فراخوانیهای تابع موازی : اگر مدل در یک پاسخ، فراخوانیهای تابع موازی ایجاد کند،
thought_signatureفقط به اولین بخشfunctionCallمتصل میشود. بخشهای بعدیfunctionCallدر همان پاسخ، حاوی امضا نخواهند بود.
- فراخوانی تک تابع : بخش
- الزامات : شما باید این امضا را دقیقاً در همان قسمتی که هنگام ارسال تاریخچه مکالمه دریافت شده است، برگردانید.
- اعتبارسنجی : اعتبارسنجی دقیق برای تمام فراخوانیهای تابع در نوبت فعلی اعمال میشود. (فقط نوبت فعلی مورد نیاز است؛ ما نوبتهای قبلی را اعتبارسنجی نمیکنیم)
- این API در تاریخچه (از جدیدترین به قدیمیترین) به عقب برمیگردد تا جدیدترین پیام کاربر را که حاوی محتوای استاندارد (مثلاً
text) است (که شروع نوبت فعلی خواهد بود) پیدا کند. این یکfunctionResponseنخواهد بود . - تمام نوبتهای
functionCallمدل که پس از آن پیام استفاده خاص رخ میدهند، بخشی از نوبت در نظر گرفته میشوند. - اولین بخش
functionCallدر هر مرحله از نوبت فعلی باید شاملthought_signatureآن باشد. - اگر در هر مرحله از نوبت فعلی، برای اولین بخش
functionCall، یکthought_signatureحذف کنید، درخواست با خطای ۴۰۰ شکست میخورد.
- این API در تاریخچه (از جدیدترین به قدیمیترین) به عقب برمیگردد تا جدیدترین پیام کاربر را که حاوی محتوای استاندارد (مثلاً
- اگر امضاهای صحیح برگردانده نشوند، در اینجا نحوهی بروز خطا آمده است.
-
gemini-3-pro-preview: عدم درج امضاها منجر به خطای ۴۰۰ خواهد شد. متن به شکل زیر خواهد بود:- فراخوانی تابع
<Function Call>در بلوک محتوای<index of contents array>فاقدthought_signatureاست. برای مثال، فراخوانی تابعFC1در بلوک محتوای1.فاقدthought_signatureاست.
- فراخوانی تابع
-
مثال فراخوانی تابع ترتیبی
این بخش مثالی از فراخوانیهای چندگانه تابع را نشان میدهد که در آن کاربر یک سوال پیچیده میپرسد که نیاز به چندین وظیفه دارد.
بیایید یک مثال فراخوانی تابع چند نوبتی را بررسی کنیم که در آن کاربر یک سوال پیچیده میپرسد که نیاز به چندین وظیفه دارد: "Check flight status for AA100 and book a taxi if delayed" .
نوبت | قدم | درخواست کاربر | پاسخ مدل | تابع پاسخ |
۱ | ۱ | request1="Check flight status for AA100 and book a taxi 2 hours before if delayed." | FC1 ("check_flight") + signature | FR1 |
۱ | ۲ | request2 = request1 + FC1 ("check_flight") + signature + FR1 | FC2("book_taxi") + signature | FR2 |
۱ | ۳ | request3 = request2 + FC2 ("book_taxi") + signature + FR2 | text_output(بدون FC) | None |
کد زیر توالی موجود در جدول بالا را نشان میدهد.
نوبت ۱، مرحله ۱ (درخواست کاربر)
{
"contents": [
{
"role": "user",
"parts": [
{
"text": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
}
]
}
],
"tools": [
{
"functionDeclarations": [
{
"name": "check_flight",
"description": "Gets the current status of a flight",
"parameters": {
"type": "object",
"properties": {
"flight": {
"type": "string",
"description": "The flight number to check"
}
},
"required": [
"flight"
]
}
},
{
"name": "book_taxi",
"description": "Book a taxi",
"parameters": {
"type": "object",
"properties": {
"time": {
"type": "string",
"description": "time to book the taxi"
}
},
"required": [
"time"
]
}
}
]
}
]
}
نوبت اول، مرحله ۱ (پاسخ مدلسازی شده)
{
"content": {
"role": "model",
"parts": [
{
"functionCall": {
"name": "check_flight",
"args": {
"flight": "AA100"
}
},
"thoughtSignature": "<Signature A>"
}
]
}
}
نوبت ۱، مرحله ۲ (پاسخ کاربر - ارسال خروجیهای ابزار) از آنجایی که این نوبت کاربر فقط شامل یک functionResponse است (بدون متن جدید)، ما هنوز در نوبت ۱ هستیم. ما باید <Signature_A> حفظ کنیم.
{
"role": "user",
"parts": [
{
"text": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
}
]
},
{
"role": "model",
"parts": [
{
"functionCall": {
"name": "check_flight",
"args": {
"flight": "AA100"
}
},
"thoughtSignature": "<Signature A>" //Required and Validated
}
]
},
{
"role": "user",
"parts": [
{
"functionResponse": {
"name": "check_flight",
"response": {
"status": "delayed",
"departure_time": "12 PM"
}
}
}
]
}
نوبت ۱، مرحله ۲ (مدل) اکنون مدل بر اساس خروجی ابزار قبلی تصمیم به رزرو تاکسی میگیرد.
{
"content": {
"role": "model",
"parts": [
{
"functionCall": {
"name": "book_taxi",
"args": {
"time": "10 AM"
}
},
"thoughtSignature": "<Signature B>"
}
]
}
}
نوبت ۱، مرحله ۳ (کاربر - خروجی ابزار ارسال) برای ارسال تأیید رزرو تاکسی، باید امضاهایی را برای همه فراخوانیهای تابع در این حلقه ( <Signature A> + <Signature B> ) لحاظ کنیم.
{
"role": "user",
"parts": [
{
"text": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
}
]
},
{
"role": "model",
"parts": [
{
"functionCall": {
"name": "check_flight",
"args": {
"flight": "AA100"
}
},
"thoughtSignature": "<Signature A>" //Required and Validated
}
]
},
{
"role": "user",
"parts": [
{
"functionResponse": {
"name": "check_flight",
"response": {
"status": "delayed",
"departure_time": "12 PM"
}
}
}
]
},
{
"role": "model",
"parts": [
{
"functionCall": {
"name": "book_taxi",
"args": {
"time": "10 AM"
}
},
"thoughtSignature": "<Signature B>" //Required and Validated
}
]
},
{
"role": "user",
"parts": [
{
"functionResponse": {
"name": "book_taxi",
"response": {
"booking_status": "success"
}
}
}
]
}
}
مثال فراخوانی تابع موازی
بیایید یک مثال فراخوانی تابع موازی را بررسی کنیم که در آن کاربران میپرسند "Check weather in Paris and London" تا ببینیم مدل کجا اعتبارسنجی میکند.
نوبت | قدم | درخواست کاربر | پاسخ مدل | تابع پاسخ |
|---|---|---|---|---|
۱ | ۱ | request1="بررسی آب و هوای پاریس و لندن" | FC1 ("پاریس") + امضا FC2 ("لندن") | FR1 |
۱ | ۲ | درخواست ۲ = درخواست ۱ + FC1 ("پاریس") + امضا + FC2 ("لندن") | خروجی_متن (بدون FC) | هیچکدام |
کد زیر توالی موجود در جدول بالا را نشان میدهد.
نوبت ۱، مرحله ۱ (درخواست کاربر)
{
"contents": [
{
"role": "user",
"parts": [
{
"text": "Check the weather in Paris and London."
}
]
}
],
"tools": [
{
"functionDeclarations": [
{
"name": "get_current_temperature",
"description": "Gets the current temperature for a given location.",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city name, e.g. San Francisco"
}
},
"required": [
"location"
]
}
}
]
}
]
}
نوبت اول، مرحله ۱ (پاسخ مدلسازی شده)
{
"content": {
"parts": [
{
"functionCall": {
"name": "get_current_temperature",
"args": {
"location": "Paris"
}
},
"thoughtSignature": "<Signature_A>"// INCLUDED on First FC
},
{
"functionCall": {
"name": "get_current_temperature",
"args": {
"location": "London"
}// NO signature on subsequent parallel FCs
}
}
]
}
}
نوبت ۱، مرحله ۲ (پاسخ کاربر - ارسال خروجیهای ابزار) ما باید <Signature_A> در قسمت اول دقیقاً همانطور که دریافت شده است، حفظ کنیم.
[
{
"role": "user",
"parts": [
{
"text": "Check the weather in Paris and London."
}
]
},
{
"role": "model",
"parts": [
{
"functionCall": {
"name": "get_current_temperature",
"args": {
"city": "Paris"
}
},
"thought_signature": "<Signature_A>" // MUST BE INCLUDED
},
{
"functionCall": {
"name": "get_current_temperature",
"args": {
"city": "London"
}
}
} // NO SIGNATURE FIELD
]
},
{
"role": "user",
"parts": [
{
"functionResponse": {
"name": "get_current_temperature",
"response": {
"temp": "15C"
}
}
},
{
"functionResponse": {
"name": "get_current_temperature",
"response": {
"temp": "12C"
}
}
}
]
}
]
امضاها در بخشهای غیر از functionCall
Gemini همچنین ممکن است در قسمت پایانی پاسخ در بخشهای غیر فراخوانی تابع thought_signatures برگرداند.
- رفتار : بخش محتوای نهایی (
text, inlineData…) که توسط مدل برگردانده میشود، ممکن است حاوی یکthought_signatureباشد. - توصیه : بازگرداندن این امضاها برای اطمینان از حفظ استدلال با کیفیت بالا توسط مدل، به ویژه برای دنبال کردن دستورالعملهای پیچیده یا گردشهای کاری عاملمحور شبیهسازی شده، توصیه میشود.
- اعتبارسنجی : API الزام خاصی به اعتبارسنجی ندارد . اگر آنها را حذف کنید، خطای مسدود شدن دریافت نخواهید کرد، اگرچه ممکن است عملکرد کاهش یابد.
استدلال متنی/درون متنی (بدون اعتبارسنجی)
نوبت اول، مرحله ۱ (پاسخ مدلسازی شده)
{
"role": "model",
"parts": [
{
"text": "I need to calculate the risk. Let me think step-by-step...",
"thought_signature": "<Signature_C>" // OPTIONAL (Recommended)
}
]
}
نوبت ۲، مرحله ۱ (کاربر)
[
{ "role": "user", "parts": [{ "text": "What is the risk?" }] },
{
"role": "model",
"parts": [
{
"text": "I need to calculate the risk. Let me think step-by-step...",
// If you omit <Signature_C> here, no error will occur.
}
]
},
{ "role": "user", "parts": [{ "text": "Summarize it." }] }
]
امضاها برای سازگاری با OpenAI
مثالهای زیر نحوه مدیریت امضاهای فکری برای یک API تکمیل چت با استفاده از سازگاری OpenAI را نشان میدهد.
مثال فراخوانی تابع ترتیبی
این مثالی از فراخوانی چندین تابع است که در آن کاربر یک سوال پیچیده میپرسد که نیاز به چندین وظیفه دارد.
بیایید یک مثال فراخوانی تابع چند نوبتی را بررسی کنیم که در آن کاربر میپرسد Check flight status for AA100 and book a taxi if delayed میتوانید ببینید وقتی کاربر یک سوال پیچیده میپرسد که نیاز به چندین کار دارد، چه اتفاقی میافتد.
نوبت | قدم | درخواست کاربر | پاسخ مدل | تابع پاسخ |
۱ | ۱ | request1="Check the weather in Paris and London" | FC1 ("Paris") + signatureFC2 ("لندن") | FR1 |
۱ | ۲ | request 2 = request1 + FC1 ("Paris") + signature + FC2 ("London") | text_output(بدون FC) | None |
کد زیر دنباله داده شده را طی میکند.
نوبت ۱، مرحله ۱ (درخواست کاربر)
{
"model": "google/gemini-3-pro-preview",
"messages": [
{
"role": "user",
"content": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
}
],
"tools": [
{
"type": "function",
"function": {
"name": "check_flight",
"description": "Gets the current status of a flight",
"parameters": {
"type": "object",
"properties": {
"flight": {
"type": "string",
"description": "The flight number to check."
}
},
"required": [
"flight"
]
}
}
},
{
"type": "function",
"function": {
"name": "book_taxi",
"description": "Book a taxi",
"parameters": {
"type": "object",
"properties": {
"time": {
"type": "string",
"description": "time to book the taxi"
}
},
"required": [
"time"
]
}
}
}
]
}
نوبت اول، مرحله ۱ (پاسخ مدل)
{
"role": "model",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature A>"
}
},
"function": {
"arguments": "{\"flight\":\"AA100\"}",
"name": "check_flight"
},
"id": "function-call-1",
"type": "function"
}
]
}
مرحله ۱، مرحله ۲ (پاسخ کاربر - ارسال خروجیهای ابزار)
از آنجایی که این نوبت کاربر فقط شامل یک functionResponse است (بدون متن جدید)، ما هنوز در نوبت ۱ هستیم و باید <Signature_A> حفظ کنیم.
"messages": [
{
"role": "user",
"content": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
},
{
"role": "model",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature A>" //Required and Validated
}
},
"function": {
"arguments": "{\"flight\":\"AA100\"}",
"name": "check_flight"
},
"id": "function-call-1",
"type": "function"
}
]
},
{
"role": "tool",
"name": "check_flight",
"tool_call_id": "function-call-1",
"content": "{\"status\":\"delayed\",\"departure_time\":\"12 PM\"}"
}
]
نوبت ۱، مرحله ۲ (مدل)
اکنون مدل بر اساس خروجی ابزار قبلی تصمیم به رزرو تاکسی میگیرد.
{
"role": "model",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature B>"
}
},
"function": {
"arguments": "{\"time\":\"10 AM\"}",
"name": "book_taxi"
},
"id": "function-call-2",
"type": "function"
}
]
}
مرحله ۱، مرحله ۳ (کاربر - خروجی ابزار ارسال)
برای ارسال تأیید رزرو تاکسی، باید امضاهایی را برای همه فراخوانیهای تابع در این حلقه ( <Signature A> + <Signature B> ) لحاظ کنیم.
"messages": [
{
"role": "user",
"content": "Check flight status for AA100 and book a taxi 2 hours before if delayed."
},
{
"role": "model",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature A>" //Required and Validated
}
},
"function": {
"arguments": "{\"flight\":\"AA100\"}",
"name": "check_flight"
},
"id": "function-call-1d6a1a61-6f4f-4029-80ce-61586bd86da5",
"type": "function"
}
]
},
{
"role": "tool",
"name": "check_flight",
"tool_call_id": "function-call-1d6a1a61-6f4f-4029-80ce-61586bd86da5",
"content": "{\"status\":\"delayed\",\"departure_time\":\"12 PM\"}"
},
{
"role": "model",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature B>" //Required and Validated
}
},
"function": {
"arguments": "{\"time\":\"10 AM\"}",
"name": "book_taxi"
},
"id": "function-call-65b325ba-9b40-4003-9535-8c7137b35634",
"type": "function"
}
]
},
{
"role": "tool",
"name": "book_taxi",
"tool_call_id": "function-call-65b325ba-9b40-4003-9535-8c7137b35634",
"content": "{\"booking_status\":\"success\"}"
}
]
مثال فراخوانی تابع موازی
بیایید یک مثال فراخوانی تابع موازی را بررسی کنیم که در آن کاربران میپرسند "Check weather in Paris and London" و میتوانید ببینید که مدل کجا اعتبارسنجی را انجام میدهد.
نوبت | قدم | درخواست کاربر | پاسخ مدل | تابع پاسخ |
۱ | ۱ | request1="Check the weather in Paris and London" | FC1 ("Paris") + signatureFC2 ("لندن") | FR1 |
۱ | ۲ | request 2 = request1 + FC1 ("Paris") + signature + FC2 ("London") | text_output(بدون FC) | None |
در اینجا کدی برای پیمایش توالی داده شده آمده است.
نوبت ۱، مرحله ۱ (درخواست کاربر)
{
"contents": [
{
"role": "user",
"parts": [
{
"text": "Check the weather in Paris and London."
}
]
}
],
"tools": [
{
"functionDeclarations": [
{
"name": "get_current_temperature",
"description": "Gets the current temperature for a given location.",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "The city name, e.g. San Francisco"
}
},
"required": [
"location"
]
}
}
]
}
]
}
نوبت اول، مرحله ۱ (پاسخ مدل)
{
"role": "assistant",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature A>" //Signature returned
}
},
"function": {
"arguments": "{\"location\":\"Paris\"}",
"name": "get_current_temperature"
},
"id": "function-call-f3b9ecb3-d55f-4076-98c8-b13e9d1c0e01",
"type": "function"
},
{
"function": {
"arguments": "{\"location\":\"London\"}",
"name": "get_current_temperature"
},
"id": "function-call-335673ad-913e-42d1-bbf5-387c8ab80f44",
"type": "function" // No signature on Parallel FC
}
]
}
مرحله ۱، مرحله ۲ (پاسخ کاربر - ارسال خروجیهای ابزار)
شما باید <Signature_A> در قسمت اول دقیقاً همانطور که دریافت کردهاید، حفظ کنید.
"messages": [
{
"role": "user",
"content": "Check the weather in Paris and London."
},
{
"role": "assistant",
"tool_calls": [
{
"extra_content": {
"google": {
"thought_signature": "<Signature A>" //Required
}
},
"function": {
"arguments": "{\"location\":\"Paris\"}",
"name": "get_current_temperature"
},
"id": "function-call-f3b9ecb3-d55f-4076-98c8-b13e9d1c0e01",
"type": "function"
},
{
"function": { //No Signature
"arguments": "{\"location\":\"London\"}",
"name": "get_current_temperature"
},
"id": "function-call-335673ad-913e-42d1-bbf5-387c8ab80f44",
"type": "function"
}
]
},
{
"role":"tool",
"name": "get_current_temperature",
"tool_call_id": "function-call-f3b9ecb3-d55f-4076-98c8-b13e9d1c0e01",
"content": "{\"temp\":\"15C\"}"
},
{
"role":"tool",
"name": "get_current_temperature",
"tool_call_id": "function-call-335673ad-913e-42d1-bbf5-387c8ab80f44",
"content": "{\"temp\":\"12C\"}"
}
]
سوالات متداول
چگونه میتوانم تاریخچه را از یک مدل دیگر به Gemini 3 Pro با یک بخش فراخوانی تابع در نوبت و مرحله فعلی منتقل کنم؟ من باید بخشهای فراخوانی تابعی را ارائه دهم که توسط API تولید نشدهاند و بنابراین امضای فکری مرتبطی ندارند؟
اگرچه تزریق بلوکهای فراخوانی تابع سفارشی به درخواست اکیداً توصیه نمیشود، در مواردی که نمیتوان از آن اجتناب کرد، مثلاً ارائه اطلاعات به مدل در مورد فراخوانیهای تابع و پاسخهایی که به طور قطعی توسط کلاینت اجرا شدهاند، یا انتقال یک ردیابی از مدل دیگری که شامل امضاهای فکری نیست، میتوانید امضاهای ساختگی زیر را با عنوان
"context_engineering_is_the_way_to_go"یا"skip_thought_signature_validator"در فیلد امضای فکری تنظیم کنید تا از اعتبارسنجی صرف نظر شود.من فراخوانیها و پاسخهای توابع موازی درهمتنیده را ارسال میکنم و API خطای ۴۰۰ را برمیگرداند. چرا؟
وقتی API فراخوانیهای تابع موازی "FC1 + signature, FC2" را برمیگرداند، پاسخ مورد انتظار کاربر "FC1+ signature, FC2, FR1, FR2" است. اگر آنها را به صورت "FC1 + signature, FR1, FC2, FR2" در جای خود قرار دهید، API خطای ۴۰۰ را برمیگرداند.
وقتی استریمینگ انجام میشود و مدل فراخوانی تابع را برنمیگرداند، نمیتوانم امضای فکر را پیدا کنم
در طول پاسخ مدل که حاوی FC با درخواست استریمینگ نیست، مدل ممکن است امضای فکری را در بخشی با محتوای متنی خالی برگرداند. توصیه میشود کل درخواست تا زمان برگرداندن
finish_reasonتوسط مدل تجزیه شود.
رفتار امضای فکری توسط سری مدلها
مدلهای Gemini 3 Pro و Gemini 2.5 در فراخوانیهای تابع، رفتار متفاوتی با امضای فکری دارند:
- اگر در یک پاسخ، فراخوانی تابع وجود داشته باشد،
- Gemini 3 Pro همیشه امضای اولین بخش فراخوانی تابع را خواهد داشت. بازگرداندن آن بخش الزامی است.
- Gemini 2.5 امضا را در بخش اول خواهد داشت (صرف نظر از نوع). برگرداندن آن بخش اختیاری است.
- اگر در یک پاسخ هیچ فراخوانی تابعی وجود نداشته باشد،
- اگر مدل ایدهای را ایجاد کند، Gemini 3 Pro امضای خود را روی آخرین قسمت خواهد داشت.
- جمینی ۲.۵ در هیچ بخشی امضا نخواهد داشت.
برای مدلهای Gemini 2.5 با عنوان «رفتار با امضای فکری»، به صفحه «تفکر» مراجعه کنید.