درون معماری OpenAI؛ تمرکز پیچیدگی در فایل‌های ارکستراسیون

تصور کنید یک دستور ساده بتواند کل ساختار یک مخزن کد عظیم و فعال را به مجموعه‌ای از داده‌های معماری قابل جست‌وجو تبدیل کند. برای هر برنامه‌نویسی که با SDKهای پیچیده سروکار دارد، دانستن اینکه تغییر یک خط کد در کجا باعث تخریب کل سیستم می‌شود، مرز بین موفقیت و شکست است.

بر اساس مستندات فنی، در ۳۰ جولای ۲۰۲۶، با استفاده از توزیع ۰.۱۰.۰ ابزار ArchSteer، تحلیلی روی OpenAI Agents SDK برای پایتون انجام شد که در آن دقیقاً ۸۴۴ مؤلفه در سراسر مخزن نقشه‌برداری شد. هدف این بود تا مشخص شود آیا یک بررسی معماری بدون نیاز به تنظیمات (Zero-config architecture pass)، می‌تواند برای پروژه‌ای با حدود ۲۷,۰۰۰ ستاره در گیت‌هاب، بینش‌های کاربردی و عملی ایجاد کند یا خیر.

مدیریت نرم‌افزارهای عامل‌محور (Agentic) — یعنی سیستم‌هایی که مانند کارمندان مستقل، خودشان تصمیم می‌گیرند و ابزارها را اجرا می‌کنند — به‌طور بنیادین با توسعه اپلیکیشن‌های سنتی متفاوت است. در حالی که بیشتر توسعه‌دهندگان روی پرامپت‌ها و جابه‌جایی‌ها (Handoffs) تمرکز می‌کنند، وزن اصلی مهندسی در واقع در وضعیت‌های پایدار (Durable State)، مالکیت فراخوانی ابزار (Tool-call Ownership) و ترجمه ارائه‌دهنده‌ها (Provider Translation) نهفته است. همان‌طور که در پوشش‌های قبلی خود درباره ضرورت سرمایه‌گذاری سنگین لابراتوارهای هوش مصنوعی در داده‌های هدفمند برای بهبود عملکرد مدل‌ها اشاره کردیم، این تحلیل اکنون تمرکز را به سلامت ساختاری نرم‌افزاری می‌برد که این مدل‌ها را مصرف می‌کند.

نقشه‌ی راه زمان اجرا

این تحلیل با یک توالی عملیاتی مشخص آغاز شد: ابتدا کلون کردن کامیت 974733e، سپس نصب ArchSteer از طریق pipx و در نهایت اجرای دستور archsteer xray. این عملیات کاملاً «فقط خواندنی» (Read-only) است. ابزار به‌صورت استاتیک مخزن را می‌خواند و نتایج را در دایرکتوری .archsteer/ می‌نویسد، بدون اینکه نیاز باشد SDK را اجرا کند، مدل خاصی را فراخوانی نماید یا کدی را آپلود کند.

اسکن اولیه مخزن، دیدگاهی کلی از مقیاس کد ایجاد کرد. طبق گزارش منتشر شده در dev.to، این بررسی گسترده توانست ۴۳۱ نقطه فراخوانی خارجی (External call sites) را شناسایی کرده و به‌طور خودکار دو لایه معماری را استنباط نماید.

برای استخراج سیگنال‌های دقیق‌تر و یافتن داده‌های معنادار، تحلیل روی دایرکتوری src/agents/ که بسته اجرایی ارسالی (Shipped runtime package) را در خود جای داده، متمرکز شد. این نمای دقیق‌تر موارد زیر را آشکار کرد:

• ۲۹۵ مؤلفه پایتونی
• ۱۰۳,۱۹۷ خط کد نقشه‌برداری شده
• ۳,۳۷۰ لبه واردات (Import Edge)
• ۱۴۹ نقطه فراخوانی خارجی

شناسایی نقاط داغ ارکستراسیون

بستر معماری در این SDK به‌طور یکنواخت توزیع نشده است و به‌شدت حول مجموعه‌ کوچکی از فایل‌های ارکستراسیون (Orchestration) متمرکز شده است؛ شبیه به برج کنترل فرودگاهی که تمام ترافیک داده‌ها را مدیریت می‌کند. فایل openai_realtime.py با ۶۲ لبه واردات در صدر لیست بود و پس از آن، حلقه اجرای داخلی (Internal run loop) با ۵۶ لبه قرار داشت. سایر گره‌های حیاتی شامل agent.py، بخش اجرای ابزار و وضعیت اجرا (Run state) هستند.

این فایل‌ها نقاط اتصالی هستند که ارائه‌دهندگان مدل، ردیابی (Tracing)، حفاظ‌ها (Guardrails) و استریمینگ در آنجا به هم می‌رسند. تغییر در این فایل‌ها به بستر و درک بسیار بیشتری نسبت به یک ویرایش در یک آداپتور کوچک نیاز دارد و آن‌ها را به نقاط پرریسک برای هر دو گروه بازبین‌های انسانی و عامل‌های برنامه‌نویس تبدیل می‌کند. اگر یک عامل به حلقه اجرا دست بزند، ArchSteer می‌تواند پیش از آنکه عامل شروع به کپی‌برداری از یک الگوی مجاور کند، شناسایی کند که کدام مرزها و تصمیمات معماری در آن نقطه اهمیت دارند.

اندازه‌گیری شعاع تخریب

دستور graph در ArchSteer به توسعه‌دهندگان اجازه می‌دهد از امتیازات کلی پیچیدگی عبور کرده و وابستگی‌های خاص و دقیق را ببینند. برای مثال، وقتی فایل src/agents/agent.py از طریق دستور archsteer graph src/agents/agent.py تحلیل شد، ابزار نشان داد که این فایل ۲۹ وابستگی محلی مستقیم و ۵۵ وابسته‌ی مستقیم (Dependents) دارد.

این نقشه محلی دوطرفه دقیقاً نشان می‌دهد که agent.py برای عملکرد به چه چیزهایی نیاز دارد و در صورت تغییر، «شعاع تخریب» (Blast Radius) احتمالی تا کجا گسترش می‌یابد. این ۵۵ وابسته شامل کدهای زمان اجرا، تست‌ها و مثال‌ها می‌شوند، زیرا ایکس‌ری تمام مخزن را پوشش می‌دهد.

این نما بسیار کاربردی‌تر از یک امتیاز استاندارد است. در حالی که نمودار import-edge تمام لبه‌های تجزیه شده شامل واردات خارجی را می‌شمارد، دستور graph به‌طور خاص مؤلفه‌های مستقیم مخزن را تحلیل می‌کند. برای یک عامل برنامه‌نویس، این بستر حیاتی است تا از تقلید الگوهای قدیمی و منسوخ که در نقاط دیگر مخزن یافت می‌شوند، جلوگیری کند.

درزهای حاکمیتی

تلاش مهندسی در این SDK در فایل‌هایی متمرکز شده که وضعیت (State) و اجرای ابزار را مدیریت می‌کنند. بزرگ‌ترین فایل‌های زمان اجرا شناسایی شده عبارت‌اند از:

• run_state.py (۳,۸۲۰ خط کد نقشه‌برداری شده)
• tool.py (۲,۷۳۵ خط کد نقشه‌برداری شده)
• run_internal/tool_execution.py (۲,۵۵۴ خط کد نقشه‌برداری شده)
• run_internal/turn_resolution.py (۲,۵۰۰ خط کد نقشه‌برداری شده)

این فایل‌ها «درزهای حاکمیتی» معماری هستند. وزن مهندسی در اینجا مربوط به وضعیت‌های پایدار، توقف و ازسرازی (Interruption and Resumption) و رفتار در مواجهه با خطا است. این‌ها دقیقاً نقاطی هستند که یک وصله (Patch) ممکن است به‌ظاهر پذیرفتنی باشد و از تست‌های محدود عبور کند، اما همچنان معماری را تخریب کند — برای مثال، نشت یک نوع داده خاص از ارائه‌دهنده به وضعیت هسته یا ایجاد یک مسیر اجرای جدید که حفاظ‌ها (Guardrails) را دور می‌زند.

مدیران پروژه می‌توانند از ArchSteer برای تبدیل این انتظارات به قوانین صریح استفاده کنند. مجموعه‌ای از قوانین احتمالی برای این SDK می‌تواند شامل موارد زیر باشد:

• وضعیت هسته اجرا نباید به یک ارائه‌دهنده مدل خاص وابسته باشد.
• آداپتورهای ارائه‌دهنده می‌توانند به رابط‌های هسته وابسته باشند، اما نه برعکس.
• اجرای ابزار باید حتماً از مسیرهای تأیید شده‌ی ردیابی و حفاظ‌ها عبور کند.
• بک‌اندهای جلسه (Session backends) باید در پشت انتزاع session باقی بمانند.
• ادغام‌های ارائه‌دهنده سندباکس نباید به حلقه اجرای هسته نفوذ کنند.

مقابله با لغزش معماری

عامل‌های برنامه‌نویس در ایجاد سازگاری محلی مهارت دارند و تمایل دارند الگوهای نزدیک را کپی کنند. این موضوع ریسکی ایجاد می‌کند که عامل ممکن است از یک الگوی مهاجرتی نیمه‌تمام پیروی کند؛ نتیجه این است که کد کامپایل شده و تست‌ها را پاس می‌کند، اما معماری مورد نظر به‌کندی تخریب می‌شود (Architectural Drift).

ابزار ArchSteer یک حلقه کنترل چهار مرحله‌ای برای مبارزه با این لغزش پیشنهاد می‌دهد: نقشه‌برداری (Map)، قصد (Intent)، هدایت (Steer) و بررسی (Check).

این مدل چهار لحظه متمایز در چرخه توسعه را پوشش می‌دهد:

• پیش از ویرایش: نمایش مؤلفه‌ها، وابستگی‌ها، نقاط داغ و فراخوانی‌های خارجی.
• حین کار عامل: ارائه راهنمایی‌های معماری در سطح فایل (File-scoped guidance).
• در طول بررسی و CI: شناسایی نقض‌های جدید در مرزهای معماری.
• پس از تغییر: ثبت تکامل سیستم و پیش‌نویس تصمیماتی که ارزش حفظ کردن دارند.

مرحله «بررسی» مانند یک جغد یا چرخ‌دندانه یک‌طرفه (Ratchet) عمل می‌کند. تیم‌ها می‌توانند تخلفات موجود را به‌عنوان خط پایه (Baseline) ثبت کنند و فقط جلوی لغزش‌های معماری جدید را بگیرند تا بتوانند بدهی فنی را مدیریت کنند، بدون اینکه نیاز باشد ابتدا کل مخزن کد را به‌طور کامل پاک‌سازی کنند.

محدودیت‌های تحلیل استاتیک

این اجرا محدودیت‌های ایکس‌ری‌های استاتیک را نیز برجسته کرد. ArchSteer تنها دو لایه (مدل و ابزار) را در src/agents/ استنباط کرد و ۲۶۶ مؤلفه از ۲۹۵ مورد بدون تخصیص ماندند. شکل واقعی SDK بسیار غنی‌تر است و مواردی چون انتزاع‌های هسته عامل، جابه‌جایی‌ها، ارائه‌دهنده‌ها، جلسات، ادغام‌های MCP و سندباکس‌ها را شامل می‌شود که ابزار به‌طور خودکار آن‌ها را دسته‌بندی نکرد. نمودار دو لایه صرفاً یک فرضیه اولیه است که از نام‌ها و ساختار استخراج شده و نه یک نقشه قطعی.

علاوه بر این، شناسایی ذخیره‌گاه‌های داده (Data-store detection) با نویز همراه بود و ۶۰ سیگنال «شبیه به ذخیره» را علامت زد. این لیست ترکیبی از مفاهیم واقعی پایداری با توکن‌های SQL، نام متغیرها و کدهای نمونه بود. با این حال، ابزار اجازه می‌دهد این مثبت‌های کاذب به‌جای پنهان شدن پشت یک امتیاز متقاعدکننده، به‌صورت دستی بررسی و اصلاح شوند.

این تحلیل ثابت می‌کند که اگرچه یک اسکن استاتیک واحد نمی‌تواند امنیت یا قابلیت اطمینان را تضمین کند — به‌ویژه در زبان‌های پویا مثل پایتون که تزریق وابستگی (Dependency Injection) و رفتار زمان اجرا می‌تواند لبه‌ها را پنهان کند — اما می‌تواند فوراً یک مخزن بزرگ را به یک مجموعه داده قابل بازرسی تبدیل کند. این ابزار شناسایی می‌کند که فشار معماری در کجا بیشترین است و نقطه‌ای معتبر برای مدیریت فرآیندهای توسعه مبتنی بر عامل فراهم می‌کند.

شما می‌توانید ایکس‌ری محلی مشابهی را با نصب ArchSteer از طریق pipx، رفتن به مخزن خود و اجرای دستور archsteer xray برای باز کردن فایل report.html انجام دهید. بهترین پرسش اولیه این است: «ArchSteer چه چیزی به من نشان داد که می‌خواهم یک عامل برنامه‌نویس پیش از ویرایش بعدی‌اش از آن آگاه باشد؟»

گام بعدی شما

• ابزار ArchSteer را روی یکی از پروژه‌های پایتونی خود نصب کنید تا نقاط داغ (Hotspots) وابستگی‌ها را شناسایی کنید.
• فهرستی از قوانین «عدم وابستگی» (مثلاً عدم دسترسی لایه‌های پایین به لایه‌های بالا) برای کد خود تعریف کنید.
• در بررسی‌های PR، از نقشه‌های وابستگی برای سنجش «شعاع تخریب» تغییرات عامل‌های برنامه‌نویس استفاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.