Programmatic Tool Calling؛ وقتی مدل چند نتیجه ابزار را در کد جمع می‌کند

راهنمای مدل‌های تازه OpenAI در ژوئن ۲۰۲۶، Programmatic Tool Calling را برای workflowهایی توضیح می‌دهد که باید چند ابزار را صدا بزنند و نتیجه‌های میانی زیادی دارند. در حالت معمول، مدل یک tool call می‌فرستد، برنامه نتیجه را برمی‌گرداند و مدل دوباره درباره گام بعد تصمیم می‌گیرد. در PTC، مدل می‌تواند JavaScript بنویسد تا ابزارهای مجاز را در runtime میزبانی‌شده فراخوانی و نتیجه را پیش از بازگرداندن خلاصه نهایی پردازش کند.

#چه مشکلی حل می‌شود؟

فرض کنید عامل باید صدها رکورد را فیلتر، join و aggregate کند. فرستادن هر نتیجه میانی به مدل هم token و هم رفت‌وبرگشت ایجاد می‌کند. PTC اجازه می‌دهد کد این پردازش predictable را انجام دهد و فقط خروجی ساختاریافته کوچک‌تر به مدل برسد. این الگو برای deduplication، validation، ranking و جمع‌بندی حجیم مناسب است.

این قابلیت برای هر workflow بهتر نیست. اگر نتیجه هر ابزار به قضاوت تازه مدل نیاز دارد، تصمیم باید بین callها به مدل برگردد. همچنین اقدامی که نیاز به approval دارد یا side effect ایجاد می‌کند، نباید صرفاً به‌خاطر موازی‌سازی داخل program پنهان شود. OpenAI توصیه می‌کند PTC را برای stage محدود و مستند به کار ببرید.

#قرارداد اجرا

توسعه‌دهنده باید ابزارهای مجاز، شکل ورودی و خروجی، retry و شرط توقف را روشن کند. پاسخ‌های program، function call و message نهایی جدا هستند و برنامه باید linkageهایی مانند call_id و caller را حفظ کند. اگر این رابطه گم شود، trace کردن اینکه کدام برنامه کدام ابزار را صدا زده دشوار می‌شود.

همچنین باید میان ابزار read-only و ابزار side-effecting فرق گذاشت. خواندن داده و محاسبه محلی را می‌توان با آزادی بیشتری اجرا کرد؛ ارسال ایمیل، تغییر ticket یا حذف رکورد به confirmation و idempotency نیاز دارد. کد تولیدشده مدل نیز باید در محیط محدود و با timeout اجرا شود.

#ارزیابی موفقیت

کاهش تعداد call یا token به‌تنهایی بهبود نیست. OpenAI پیشنهاد می‌کند task success، کامل بودن پاسخ، evidence، مجموع token، latency، cost و retry مقایسه شوند. اگر برنامه واسطه سریع‌تر باشد اما یک مدرک لازم را حذف کند، بهینه‌سازی شکست خورده است.

PTC یک ابزار orchestration است، نه مجوز خودکار کردن همه تصمیم‌ها. برای pipelineهای بسته و قابل پیش‌بینی، می‌تواند هزینه و latency را کاهش دهد؛ برای کارهای مبهم، مستقیم صدا زدن ابزار شفاف‌تر است. مرز میان این دو را باید از شکل مسئله، نه از مد روز بودن قابلیت، انتخاب کرد.

یک تیم می‌تواند با وظیفه‌ای شروع کند که خروجی مرجع دارد؛ مثلاً جمع کردن رکوردهای تکراری و بازگرداندن یک JSON اعتبارسنجی‌شده. سپس همان workflow را با مسیر مستقیم مقایسه کند. اگر مزیت PTC فقط در یک نمونه کوچک دیده شود، فعال‌سازی آن در همه درخواست‌ها تصمیم زودهنگامی است.