چگونه با Codex یک مغز هوشمند برای ComfyUI بسازیم؟ [راهنمای کامل]

اگر با ComfyUI کار کرده باشید، احتمالاً این تجربه را داشته‌اید: یک Workflow دارید، خروجی مشکل دارد و شروع می‌کنید به تغییر تنظیمات. نویز زیاد است؟ Steps را بیشتر می‌کنید. درست نشد؟ CFG را تغییر می‌دهید. باز هم درست نشد؟ Sampler را عوض می‌کنید و بعد سراغ Scheduler، Prompt، LoRA یا حتی Node دیگری می‌روید.

گاهی بعد از چند آزمایش به نتیجه خوبی می‌رسید، اما یک سؤال اساسی بدون پاسخ باقی می‌ماند:
دقیقاً کدام تغییر باعث بهتر شدن خروجی شد؟

حالا تصور کنید یک عامل هوشمند مثل Codex همین روند را با سرعت بسیار بیشتری انجام دهد. اگر روش کار آن را مهندسی نکرده باشید، به‌جای حل اصولی مشکل می‌تواند ده‌ها آزمایش انجام دهد، چند متغیر را هم‌زمان تغییر دهد و در نهایت خودش هم نداند چرا یک خروجی بهتر شده است.

بنابراین صرفاً وصل کردن Codex به ComfyUI کافی نیست. اگر می‌خواهید از یک AI Agent برای پروژه‌های واقعی استفاده کنید، به سیستمی نیاز دارید که دانش فنی خود را نگهداری کند، Workflowهای سالم را بشناسد، Nodeهای نصب‌شده را بررسی کند، تجربه پروژه‌های قبلی را دوباره به کار بگیرد و هنگام بروز مشکل به‌صورت کنترل‌شده دیباگ کند.

هدف این مقاله ساخت یک اتصال ساده بین Codex و ComfyUI نیست؛ هدف، طراحی یک سیستم Agentic برای کار حرفه‌ای و بلندمدت با ComfyUI است.

1. چرا اتصال ساده Codex به ComfyUI کافی نیست؟

در ساده‌ترین حالت می‌توان Client یا اسکریپتی ساخت که یک Workflow را از طریق API برای ComfyUI ارسال کند، منتظر پایان Render بماند و فایل خروجی را دریافت کند.

این قابلیت مفید است، اما فقط یک Execution Layer در اختیار شما قرار می‌دهد.

برای تبدیل Codex به یک Operator واقعی، سیستم باید بتواند درباره Workflow تصمیم بگیرد. برای مثال اگر خروجی یک مدل ویدیویی نویز زیادی داشته باشد، Agent باید بتواند بین علت‌های مختلف تمایز قائل شود:

• آیا Prompt مشکل دارد؟
• آیا مدل برای این کار مناسب نیست؟
• آیا Sampling درست انجام نمی‌شود؟
• آیا Scheduler نامناسب است؟
• آیا Guidance مشکل ایجاد کرده است؟
• آیا Reference Conditioning ضعیف است؟
• آیا VAE یا Decode مشکل دارد؟
• آیا Workflow Architecture اشتباه است؟
• آیا یک Custom Node رفتار نامناسبی دارد؟

اگر Agent هیچ روش تشخیصی نداشته باشد، احتمالاً همان کاری را انجام می‌دهد که یک کاربر کم‌تجربه انجام می‌دهد: یکی‌یکی تنظیمات را تغییر می‌دهد تا شاید نتیجه بهتر شود.

مشکل این روش فقط اتلاف GPU Time نیست. مشکل مهم‌تر این است که رابطه علت و معلولی بین تغییر و نتیجه از بین می‌رود.

2. معماری Brain و Project

اولین تصمیم مهم این است که دانش دائمی Agent را از فایل‌های پروژه‌های تولیدی جدا کنید.

در این معماری دو مفهوم اصلی داریم:

• Brain: دانش، قوانین، Skillها، Baselineها، Schemaها، ابزارها و تجربه‌های قابل استفاده مجدد.
• Project Workspace: Referenceها، Workflowهای پروژه، Experimentها، Renderها و Runهای مربوط به یک پروژه مشخص.

برای مثال:

ComfyUI-Codex-Brain/
    ├── AGENTS.md
    ├── skills/
    ├── knowledge/
    ├── workflows/
    │   └── baselines/
    ├── scripts/
    ├── config/
    └── templates/

Desktop/
└── Project-X/
    ├── references/
    ├── workflows/
    ├── experiments/
    ├── renders/
    └── runs/

Brain یک منبع دائمی است؛ اما Project می‌تواند روی Desktop، یک SSD خارجی، NAS یا هر محل دیگری قرار داشته باشد.

Brain باید جهانی و پایدار باشد؛ پروژه‌های تولیدی باید مستقل، قابل انتقال و قابل آرشیو باشند.

3. چرا Brain باید مستقل از پروژه‌ها باشد؟

فرض کنید برای یک پروژه تبلیغاتی درباره تنظیمات یک مدل، رفتار یک Node یا روش حفظ Character Identity تحقیق کرده‌اید.

اگر تمام این دانش فقط داخل پوشه همان پروژه یا Conversation مربوط به آن باقی بماند، پروژه بعدی دوباره از صفر شروع خواهد شد.

راه دیگر این است که در هر پروژه تمام Skillها و Knowledge را کپی کنید. این روش نیز به مرور باعث Duplicate شدن اطلاعات، سخت شدن Updateها و ایجاد نسخه‌های متناقض می‌شود.

Brain مشترک این مشکل را حل می‌کند. پروژه جدید می‌تواند از دانش قبلی استفاده کند، بدون اینکه تمام تاریخچه پروژه‌های گذشته را وارد Context کند.

نکته بسیار مهم این است که:

Brain لازم نیست از نظر تعداد فایل کوچک بماند؛ باید از نظر Context فعال کوچک بماند.

4. لایه‌های اصلی Brain

یک Brain مناسب بهتر است مسئولیت‌ها را بین چند لایه تقسیم کند:

• Routing و قوانین دائمی
• Skillهای عملیاتی
• Knowledge فنی
• Baselineها
• Node Intelligence
• Environment Profiles
• Schema Snapshots
• Execution Client
• Registryها و Indexها

قرار نیست Agent در ابتدای هر Task تمام این اطلاعات را بخواند. هر لایه زمانی وارد Context می‌شود که برای مسئله فعلی لازم باشد.

5. AGENTS.md؛ قانون اساسی Agent

فایل AGENTS.md بهتر است کوتاه باشد.

اشتباه رایج این است که تمام آموزش‌ها، تنظیمات مدل‌ها و تجربیات پروژه را داخل این فایل قرار دهیم. در این حالت Agent در هر Task مجبور است مقدار زیادی اطلاعات غیرمرتبط را همراه خود داشته باشد.

AGENTS باید بیشتر نقش Router و قانون اساسی را داشته باشد. مثلاً:

• قبل از تغییر Workflow، Pipeline و Execution Target را مشخص کن.
• قبل از تحقیق دوباره، Knowledge موجود را بررسی کن.
• برای تغییرات مهم یک Baseline سالم حفظ کن.
• تغییرات تأییدنشده را روی یکدیگر انباشته نکن.
• Baseline اصلی را مستقیماً برای یک پروژه Production تغییر نده.
• فقط Knowledge مرتبط با Task فعلی را بارگذاری کن.

جزئیات اجرای این قوانین باید در Skill و Knowledge قرار بگیرد، نه در فایل اصلی Routing.

6. Skillها؛ روش انجام کار

Skill به Agent می‌گوید چگونه یک نوع کار را انجام دهد.

برای مثال می‌توان Skillهای جداگانه‌ای برای حوزه‌های زیر داشت:

• Core Workflow
• Sampling
• Conditioning
• Diagnostics
• Node Intelligence
• Image Pipeline
• Video Pipeline
• Visual Direction
• Models & Extensions
• API Automation
• Camera Motion

برای مدل‌هایی که رفتار، معماری یا Workflow کاملاً متفاوتی دارند نیز می‌توان Skill تخصصی ایجاد کرد؛ مثلاً LTX، MiniMax H3 یا خانواده Wan.

اما یک اصل مهم وجود دارد:

برای هر موضوع کوچک یک Skill جدید نسازید.

Skill باید یک مسئولیت عملیاتی مشخص داشته باشد. جزئیات طولانی، تحقیقات و Sourceها بهتر است در Knowledge قرار بگیرند.

7. Knowledge؛ حافظه فنی سیستم

Knowledge جایی است که Agent می‌تواند اطلاعات فنی قابل استفاده مجدد را پیدا کند.

این اطلاعات می‌تواند شامل موارد زیر باشد:

• رفتار مدل‌ها
• معماری Pipelineها
• Reference Conditioning
• Camera Motion
• تنظیمات مهم Nodeها
• محدودیت‌های نسخه‌ها
• نتایج Benchmarkها
• Failure Modeهای شناخته‌شده
• Sourceها و تحقیقات

اما همه Knowledgeها ارزش یکسانی ندارند. بهتر است Evidence Status نیز ثبت شود.

• DOCUMENTED — توسط مستندات معتبر پشتیبانی می‌شود.
• PROJECT-OBSERVED — در پروژه‌های خودتان مشاهده شده است.
• PROVISIONAL — نتیجه اولیه است و هنوز تأیید کافی ندارد.
• STALE-CHECK — ممکن است با نسخه‌های جدید تغییر کرده باشد.
• REQUIRES-BENCHMARK — پاسخ آن را باید با آزمایش عملی مشخص کرد.

این تفکیک جلوی یک خطای خطرناک را می‌گیرد: تبدیل یک مشاهده اتفاقی به یک قانون عمومی.

8. Node Intelligence؛ شناخت Nodeهای واقعی

یک نصب حرفه‌ای ComfyUI ممکن است صدها یا حتی بیش از هزار Node داشته باشد. علاوه بر Nodeهای Core، تعداد زیادی Custom Node نیز ممکن است نصب شده باشد.

در چنین محیطی تکیه صرف بر اطلاعات اینترنتی کافی نیست. نسخه نصب‌شده روی سیستم شما ممکن است Interface متفاوتی داشته باشد.

مسیر پیشنهادی برای شناخت یک Node:

Functional Workflow Map
        ↓
Relevant Node
        ↓
Live Installed Schema
        ↓
Exact class_type + Package
        ↓
Official/Core Documentation
        ↓
Package Documentation
        ↓
Example / Source Code if necessary
        ↓
Community Evidence if necessary
        ↓
Controlled Benchmark

در ComfyUI می‌توان اطلاعات Nodeهای نصب‌شده را از /object_info دریافت کرد.

اما Agent نباید برای هر سؤال کل Snapshot را وارد Context کند. اگر سؤال درباره KSampler است، فقط Schema همان Class باید بازیابی شود.

این کار هم دقت را افزایش می‌دهد و هم مصرف Token را کاهش می‌دهد.

9. اتصال Codex به ComfyUI

بهتر است ارتباط با ComfyUI از طریق یک Client مشترک انجام شود، نه اینکه برای هر محیط یک سیستم جدا طراحی کنید.

                 ComfyUI Client
                 /           \
                /             \
         local               colab
             |                 |
      127.0.0.1:8188      HTTPS / WSS

Workflow Logic نباید وابسته به Transport باشد.

همچنین Authentication بهتر است در Profile یا Connection Layer مدیریت شود، نه داخل Workflow JSON.

10. Local Environment

محیط Local گزینه بسیار خوبی برای آزمایش‌های ارزان‌تر است.

Agent ابتدا باید بتواند بدون تغییر ComfyUI مواردی مانند Runtime، Queue، Node Schema، Modelها و Featureهای نصب‌شده را بررسی کند.

اول محیط را بشناسید؛ بعد اجازه Execution بدهید. 

یعنی Codex قبل از اینکه اجازه داشته باشه چیزی رندر کند یا Workflow اجرا کند، اول باید ComfyUI واقعیِ نصب‌شده روی سیستم را بررسی کند. مثلاً نباید از روی حافظه یا مستندات اینترنت فرض کند که «حتماً فلان Node نصب است» یا «این مدل در فلان مسیر قرار دارد». اول باید مواردی مثل این‌ها را بخواند: نسخه ComfyUI، مدل‌های موجود، Nodeهای نصب‌شده و ورودی/خروجی واقعی آن‌ها، GPU و حافظه، Custom Nodeها و وضعیت Queue.

11. اجرای امن Workflow

قبل از اینکه Agent اجازه داشته باشد Workflow را Submit کند، بهتر است یک Validation Layer وجود داشته باشد.

این لایه می‌تواند بررسی کند:

• Workflow واقعاً API-format است.
• تمام Node classها در محیط مقصد وجود دارند.
• Required inputها موجود هستند.
• Enumها معتبر هستند.
• Numeric valueها از محدوده Node خارج نشده‌اند.
• Linkها به Output معتبر متصل هستند.
• Typeها با یکدیگر سازگار هستند.
• Model filename مورد نیاز موجود است.
• Schema محیط از زمان آخرین Validation تغییر نکرده است.

پس از Validation، مسیر اجرا می‌تواند چنین باشد:

Validate
   ↓
POST /prompt
   ↓
Server Prompt ID
   ↓
/history/{prompt_id}
   ↓
/queue (when needed)
   ↓
/view
   ↓
Output + Run Metadata

برای Reproducibility می‌توان Hash مربوط به Workflow، Schema و Output را نیز ذخیره کرد.

12. ساخت اولین Baseline

بعد از آماده شدن زیرساخت، بهتر است مستقیماً وارد Workflow پیچیده Production نشوید.

ابتدا یک Pipeline ساده و قابل اعتماد بسازید و یک Baseline اولیه ایجاد کنید.

برای مثال در FLUX.1 Dev یک Workflow پایه می‌تواند شامل Nodeهایی مانند موارد زیر باشد:

• UNETLoader
• DualCLIPLoader
• VAELoader
• CLIPTextEncode
• FluxGuidance
• EmptySD3LatentImage
• KSampler
• VAEDecode
• SaveImage

برای نمونه، یک Baseline اولیه ممکن است چنین تنظیماتی داشته باشد:

Model: FLUX.1 Dev FP8
Resolution: 1024 x 1024
Steps: 20
Sampler: euler
Scheduler: simple
KSampler CFG: 1.0
Flux Guidance: 3.5
Denoise: 1.0
Seed: 424242

اگر یک Render سالم دریافت کردید، هنوز نباید فوراً آن Workflow را به‌عنوان تنظیم نهایی اعلام کنید.

وضعیت منطقی‌تر می‌تواند این باشد:

HEALTHY-CANDIDATE
+
PROVISIONAL

یعنی Pipeline سالم به نظر می‌رسد، اما Repeatability و شرایط مختلف هنوز به‌اندازه کافی آزمایش نشده‌اند. به زبان ساده تر یعنی یک بار خروجی خوب گرفتن هنوز ثابت نمی‌کند که Workflow واقعاً قابل اعتماد است.

هنوز نمی‌دانیم اگر Seed عوض شود، Prompt متفاوت باشد، تصویر پیچیده‌تر شود یا چند بار دیگر رندر بگیریم، باز هم کیفیت قابل‌قبولی می‌دهد یا نه.

Repeatability یعنی «تکرارپذیری»؛ یعنی Workflow فقط یک بار شانسی خوب عمل نکرده باشد و بتواند در آزمایش‌های دیگر هم رفتار قابل‌اعتمادی نشان دهد.

13. Baseline دقیقاً چیست؟

Baseline صرفاً آخرین Workflow ذخیره‌شده نیست.

Baseline یک نقطه مرجع شناخته‌شده و نسبتاً سالم برای یک Pipeline مشخص است.

برای مثال Brain شما در آینده می‌تواند چنین ساختاری داشته باشد:

FLUX
├── T2I Basic
├── Character Reference
└── Product Reference

WAN
├── I2V Basic
├── Character I2V
└── 360 Orbit

LTX
├── Basic Video
└── Multi-shot

نکته مهم این است که Chat مالک Baseline نیست.

باز کردن یک Conversation جدید نباید باعث ساخت دوباره Baseline شود.

Baseline متعلق به Brain است و بین پروژه‌ها قابل استفاده مجدد خواهد بود.

14. Fork چیست؟

وقتی می‌خواهید از یک Baseline برای پروژه واقعی استفاده کنید، بهتر است خود Baseline را تغییر ندهید.

از آن یک نسخه مستقل برای پروژه بسازید. به این عملیات در این معماری Fork می‌گوییم.

Brain Baseline
      |
      | Fork
      ↓
Project Workflow

مثلاً:

BASELINE-FLUX-001
        ↓
Kindergarten-Ad/workflows/shot-01.json

از این لحظه Prompt، Reference، LoRA و سایر تنظیمات مربوط به پروژه روی نسخه Fork شده تغییر می‌کنند.

در Metadata نیز بهتر است منبع Workflow ثبت شود:

derived_from: BASELINE-FLUX-001

در نتیجه حتی چند ماه بعد می‌توانید بفهمید Workflow فعلی از کدام نقطه سالم مشتق شده است.

15. Promote چیست؟

فرض کنید در یک پروژه به روش بسیار خوبی برای حفظ Character Identity در FLUX رسیده‌اید.

آیا باید Workflow پروژه را مستقیماً داخل Brain کپی کنید؟

خیر.

یک یافته زمانی ارزش Promote شدن دارد که:

• در پروژه‌های دیگر نیز قابل استفاده باشد.
• به‌اندازه کافی Verify شده باشد.
• نسبت به Baseline موجود تفاوت معناداری داشته باشد.
• ارزش نگهداری بلندمدت داشته باشد.

چرخه کامل:

Brain Baseline
      ↓
     Fork
      ↓
   Project
      ↓
Render / Experiment / Diagnose
      ↓
Reusable verified improvement?
      ↓
   Yes → Promote → Brain
   No  → Keep inside Project

یک Prompt خوب برای یک Shot خاص معمولاً نباید وارد Brain شود. اما یک روش عمومی و تأییدشده برای Character Reference ممکن است ارزش تبدیل شدن به Baseline جدید را داشته باشد.

16. دیباگ اصولی و کنترل‌شده

یکی از مهم‌ترین بخش‌های این معماری، جلوگیری از Parameter Thrashing است.

رفتار اشتباه:

مقدار نویز زیاده
→ رو بالا ببریم Steps
→ هنوز بده
→ را تغییر بدیم CFG
→ را عوض کنیم Prompt
→ را تغییر بدیم Scheduler
→ را تغییر بدیم LoRA
→ یک نود دیگه امتحان کنیم...

بعد از این زنجیره دیگر معلوم نیست چه چیزی واقعاً باعث تغییر نتیجه شده است.

روش بهتر:

Observe (مشاهده مشکل)
   ↓
Preserve Baseline (حفظ نقطه شروع سالم)
   ↓
Classify(دسته‌بندی نوع مشکل)
   ↓
Localize(پیدا کردن مرحله احتمالی ایجاد مشکل)
   ↓
Hypothesis(تعریف یک فرضیه)
   ↓
ONE Controlled Test(انجام فقط یک آزمایش کنترل‌شده)
   ↓
Evaluate(مقایسه و ارزیابی نتیجه)
   ↓
PROMOTE / ROLLBACK / INCONCLUSIVE(تأیید تغییر / بازگشت / نتیجه نامشخص)
   ↓
Re-diagnose(در صورت نیاز، تشخیص مجدد)

هم‌زمان چند چیز را تغییر ندهیم؛ چون اگر Prompt، Steps و Sampler را با هم عوض کنیم و تصویر بهتر شود، دیگر نمی‌فهمیم کدام تغییر واقعاً مؤثر بوده.

17. LAST-KNOWN-GOOD و CURRENT-EXPERIMENT

برای جلوگیری از انباشته شدن تغییرات، دو State را جدا نگه دارید:

• LAST-KNOWN-GOOD
• CURRENT-EXPERIMENT

فرض کنید وضعیت سالم فعلی چنین است:

Steps: 30
CFG: 5
Scheduler: X
Prompt: A

فرضیه اول می‌گوید Steps کم است. فقط این متغیر تغییر می‌کند:

Steps: 30 → 50

CFG، Scheduler، Prompt، Seed و سایر پارامترهای مرتبط Freeze می‌شوند.

اگر نتیجه بهتر نشد، Steps باید به 30 برگردد.

ROLLBACK → Steps: 30

حالا اگر می‌خواهید Scheduler را آزمایش کنید، تست دوم از همان LAST-KNOWN-GOOD انجام می‌شود؛ نه از Workflow قبلی که Steps آن نیز تغییر کرده بود.

اگر Scheduler جدید واقعاً بهتر بود:

PROMOTE → Scheduler Y

و این وضعیت تبدیل به نقطه سالم جدید برای ادامه آزمایش می‌شود.

18. سه نتیجه ممکن برای هر Experiment

PROMOTE

فرضیه تأیید شده، نتیجه هدف بهتر شده و Regression مهمی مشاهده نشده است. تغییر می‌تواند وارد LAST-KNOWN-GOOD جدید شود.

ROLLBACK

فرضیه رد یا تضعیف شده، یا تغییر Regression ایجاد کرده است. Workflow به وضعیت سالم قبلی برمی‌گردد.

INCONCLUSIVE

آزمایش اطلاعات کافی برای تصمیم‌گیری نداده است.

در این حالت تغییر نباید مخفیانه وارد Baseline شود. باید آزمایش دیگری طراحی شود که قدرت تفکیک بیشتری داشته باشد.

19. چرا Prompt باید هنگام دیباگ Freeze شود؟

یکی از رایج‌ترین خطاها این است که Agent برای تقریباً هر مشکل سراغ Prompt برود.

Prompt یک متغیر است؛ درمان عمومی تمام مشکلات نیست.

هنگام بررسی مشکلاتی مانند موارد زیر، Prompt باید به‌صورت پیش‌فرض ثابت بماند:

• Residual Noise
• Sampler/Scheduler behavior
• VAE artifacts
• Color corruption
• VRAM errors
• Temporal flicker
• Node exception
• Decode problems

Prompt زمانی تغییر می‌کند که Diagnosis نشان دهد مشکل در شاخه Semantic یا Prompt Adherence قرار دارد.

یک مثال ساده

فرض کنید Prompt از مدل خواسته است یک قوری و یک گلابی تولید کند، اما تصویر نهایی دو گلابی دارد.

اگر تصویر از نظر Noise، Geometry و Decode سالم است، تغییر Sampler یا Steps اولین آزمایش منطقی نیست.

فرضیه بهتر این است که مدل عبارت مربوط به تعداد را به‌اندازه کافی سخت‌گیرانه تفسیر نکرده است.

بنابراین فقط Prompt را از عبارتی مانند:

a ripe pear

به:

exactly one ripe pear, with no other fruit present

تغییر می‌دهیم و Seed، Steps، Sampler، Scheduler، Guidance و سایر پارامترها ثابت باقی می‌مانند.

این یک Experiment واقعی است، چون فقط یک Hypothesis را آزمایش می‌کند.

20. پیدا کردن علت اصلی مشکل به‌جای آزمون و خطا

Agent نباید با دیدن یک مشکل فوراً شروع به تغییر تنظیمات کند. ابتدا باید مشخص کند مشکل احتمالاً از کدام بخش Pipeline ناشی می‌شود؛ مثلاً Sampling، Conditioning، Reference، Camera Motion، Decode یا اجرای فنی. سپس فقط همان بخش را برای پیدا کردن علت اصلی بررسی کند.

مثلاً خروجی ویدیوی شما بد شده. «بد شدن خروجی» خودش علت نیست؛ فقط نشانه است. Agent ابتدا باید تشخیص دهد این نشانه احتمالاً مربوط به کدام حوزه است:

• مثلاً نویز زیاد → احتمالاً Sampling / Generation
• کاراکتر شبیه رفرنس نیست → احتمالاً Conditioning / Reference
• رنگ‌ها خراب‌اند → احتمالاً Decode / Color
• دوربین به‌جای Orbit ثابت مانده → احتمالاً Camera Motion
• Node خطا می‌دهد → احتمالاً Technical Execution / Node

بعد از مشخص شدن حوزه، تازه می‌رود داخل همان بخش دنبال علت دقیق‌تر می‌گردد.

سپس مشکل باید در کوچک‌ترین Stage محتمل Pipeline محلی‌سازی شود:

Input / Reference
       ↓
Preprocessing
       ↓
Conditioning
       ↓
Model / Loading
       ↓
Latent Initialization
       ↓
Sampling / Noise / Scheduler
       ↓
VAE / Decode
       ↓
Temporal Processing
       ↓
Post-processing
       ↓
Output

سؤال Agent نباید این باشد:

«حالا کدام تنظیم را عوض کنم؟»
سؤال بهتر:

«کدام علت محتمل باقی مانده و ارزان‌ترین آزمایش کنترل‌شده برای تفکیک آن از علت‌های دیگر چیست؟»

21. چه زمانی باید Node را عوض کنیم؟

داشتن یک Node جایگزین به این معنی نیست که با اولین مشکل Node فعلی را کنار بگذاریم.

ابتدا باید مشخص شود:

• Node فعلی با Model سازگار است؟
• Workflow Architecture صحیح است؟
• Node قابلیت لازم را دارد؟
• مشکل واقعاً از Implementation است؟
• آیا مشکل با Parameter قابل حل است؟

Node Replacement زمانی منطقی است که Evidence به سمت مشکلی در Implementation حرکت کند؛ مثلاً:

• ناسازگاری مستند وجود دارد.
• Bug قابل بازتولید است.
• Package فعلی شکسته است.
• Node Capability مورد نیاز را ندارد.
• یک Alternative معتبر دقیقاً همان مشکل را حل می‌کند.

در عین حال Alternativeهای شناخته‌شده باید در Knowledge قابل بازیابی باشند تا Agent پس از ده‌ها آزمایش ناموفق تازه متوجه وجود راه بهتر نشود.

22. Failure Memory؛ جلوگیری از تکرار اشتباهات

یک سیستم بلندمدت باید Failureهای مهم را نیز به خاطر بسپارد.

برای Failureهای قابل بازتولید می‌توان اطلاعاتی مانند این‌ها ثبت کرد:

• Node class
• Package و Version
• Model
• Workflow
• Symptom
• Root Cause
• Failed interventions
• Successful intervention
• Alternative implementation

اما باید مراقب Overgeneralization بود یعنی نباید یک تجربه ناموفق را به یک قانون کلی تبدیل کرد. اگر یک Node در یک Workflow، نسخه یا مدل مشخص مشکل ایجاد کرده است، این موضوع لزوماً به معنی نامناسب بودن آن Node در تمام شرایط نیست. بنابراین هنگام ثبت خطا، باید شرایط وقوع آن—مانند نسخه Node، مدل، Workflow و تنظیمات مرتبط—نیز ذخیره شود تا Agent در آینده فقط در شرایط مشابه از آن تجربه استفاده کند.

23. Character Sheet، Prop Sheet و Reference Conditioning

در پروژه‌های تصویری و ویدیویی، یکی از مهم‌ترین کاربردهای Agent استفاده صحیح از Character Sheet و Prop Sheet است.

روش ضعیف این است که اگر Character شبیه Reference نشد، فقط Reference Strength را افزایش دهیم.

Agent باید ابتدا تشخیص دهد:

• آیا Reference coverage کافی است؟
• آیا زاویه مورد نیاز در Character Sheet وجود دارد؟
• آیا Conditioning Method برای مدل مناسب است؟
• آیا Strength بیش از حد یا کمتر از حد است؟
• آیا Identity حفظ شده اما Geometry خراب است؟
• آیا مدل در Viewpoint جدید محدودیت دارد؟
• آیا Referenceها با یکدیگر تناقض دارند؟

کار با تصاویر مرجع یک فرایند چندمرحله‌ای است. انتخاب Reference مناسب، پوشش زاویه‌های موردنیاز، روش Conditioning، میزان تأثیر Reference و ارزیابی حفظ هویت و ساختار سوژه همگی در نتیجه نهایی نقش دارند؛ بنابراین نمی‌توان تمام مشکلات Reference را صرفاً با کم‌وزیاد کردن یک Strength حل کرد.

24. Camera Motion و Orbit 360 درجه

در مدل‌های ویدیویی، Camera Motion یکی از حوزه‌هایی است که Agent باید آن را جدا از Motion عمومی Subject تحلیل کند.

برای مثال دستور «یک Orbit کامل 360 درجه دور کاراکتر» ممکن است به چند شکل اشتباه اجرا شود:

• Camera تقریباً ثابت بماند.
• Subject به‌جای Camera بچرخد.
• جهت Orbit اشتباه باشد.
• حرکت فقط بخشی از Arc را طی کند.
• فاصله Camera تا Subject تغییر کند.
• Parallax محیط با Orbit سازگار نباشد.
• Character Identity هنگام تغییر Viewpoint از بین برود.
• Temporal consistency خراب شود.

این Failureها علت یکسان ندارند.

بنابراین پاسخ همه آن‌ها نمی‌تواند «Motion Strength را بیشتر کن» باشد.

یک Camera Motion Skill خوب باید بتواند بین مواردی مانند Camera Translation، Subject Rotation، Orbit Radius، Direction، Arc Completion، Parallax و Viewpoint Consistency تمایز قائل شود.

25. نقش Visual Director

Agent فقط نباید بتواند Workflow را اجرا کند؛ باید خروجی را نیز از نظر بصری ارزیابی کند.

اما بهتر است Visual Evaluation و Technical Intervention دو مسئولیت جدا باشند.

مثلاً:

Visual Director:
"Heavy chroma noise is visible in the shadows."

Systematic Diagnostics:
→ classify symptom
→ localize stage
→ sampling vs decode hypothesis
→ controlled experiment

Visual Director می‌گوید چه چیزی در تصویر یا ویدیو اشتباه به نظر می‌رسد.

Diagnostics تصمیم می‌گیرد برای فهمیدن علت آن چه آزمایشی انجام شود.

این جداسازی از تغییرات احساسی و تصادفی جلوگیری می‌کند.

26. جلوگیری از انفجار Context و مصرف Token

اگر Brain به‌درستی کار کند، با گذشت زمان بزرگ خواهد شد. این اتفاق بدی نیست.

ممکن است بعد از مدتی صدها فایل درباره Modelها، Nodeها، Benchmarkها، Failureها و Workflowها داشته باشید.

مشکل زمانی ایجاد می‌شود که Agent برای هر Task همه آن‌ها را بخواند. بدیهی است با بزرگ شدن Brain نباید برای کاهش حجم، دانش و تجربه‌های مفید قبلی را حذف کرد.

راه بهتر این است که برای هر Task فقط مقدار محدودی از اطلاعات مرتبط وارد Context شود و اطلاعات تخصصی‌تر یا تاریخی تنها زمانی بازیابی شوند که واقعاً به آن‌ها نیاز باشد.

27. معماری HOT / WARM / COLD

HOT

اطلاعات بسیار کوچک و ضروری که برای Routing اولیه لازم هستند:

• AGENTS routing
• Indexها
• Baseline Registry
• Execution Target summary
• قوانین حداقلی

WARM

دانش تخصصی که فقط در صورت ارتباط با Task بارگذاری می‌شود:

• Model-specific Skill
• Pipeline Knowledge
• Sampling
• Conditioning
• Reference
• Camera Motion
• Node Intelligence

COLD

Evidence تاریخی و سنگین:

• Raw Experiments
• Benchmarkهای قدیمی
• Failure History
• Source Auditها
• Baselineهای Superseded
• تحقیقات طولانی

Brain می‌تواند به‌مرور بزرگ‌تر و پُر از دانش شود، اما مقدار اطلاعاتی که Agent در هر لحظه برای انجام یک کار وارد Context می‌کند، نباید همراه با آن بزرگ شود.

28. ارائه تدریجی اطلاعات (Progressive Disclosure)

در یک Task عادی Agent نباید با خواندن تمام Brain شروع کند.

اطلاعات را مرحله‌به‌مرحله و فقط در صورت نیاز بازیابی کند:

User Task
   ↓
Classify Pipeline + Execution Target
   ↓
HOT Registry
   ↓
One Primary WARM Skill
   ↓
One Canonical Knowledge Document
   ↓
Exact Node / Schema if required
   ↓
COLD Evidence only if unresolved

در مقابل، این روش اشتباه است:

Load all Skills
→ Load all Knowledge
→ Load all Node Schemas
→ Load all Experiments
→ Start working

در روش «ارائه تدریجی اطلاعات»، Agent ابتدا فقط دانش ضروری برای مسئله فعلی را دریافت می‌کند و در صورت نیاز به سراغ جزئیات بیشتر می‌رود. به این ترتیب هم مصرف Token کاهش پیدا می‌کند و هم تصمیم‌گیری تحت تأثیر اطلاعات غیرمرتبط قرار نمی‌گیرد.

29. Lifecycle دانش و Workflowها

برای مدیریت دانش بهتر است دو موضوع را از هم جدا کنیم: میزان اعتبار اطلاعات و جایگاه فعلی آن در سیستم. Evidence Status مشخص می‌کند یک ادعا یا نتیجه چقدر پشتوانه دارد«چقدر می‌توانیم به این اطلاعات اعتماد کنیم؟» مثلاً از مستندات رسمی آمده، در پروژه آزمایش شده یا هنوز نیازمند بررسی بیشتر است. در مقابل، Resource Lifecycle مشخص می‌کند خود آن Workflow، Baseline یا سند در چه مرحله‌ای قرار دارد؛ مثلاً هنوز در حال آزمایش است، تأیید شده، با نسخه بهتری جایگزین شده یا فقط برای سابقه نگهداری می‌شود.

برای مثال:

• WORKING
• HEALTHY-CANDIDATE
• APPROVED
• SUPERSEDED
• ARCHIVED

بنابراین یک Baseline می‌تواند هم‌زمان:

Lifecycle: HEALTHY-CANDIDATE
Evidence: PROVISIONAL

باشد.

اگر بعداً Baseline بهتری ساخته شود، نسخه قدیمی لازم نیست حذف شود. می‌توان آن را SUPERSEDED کرد و Replacement ID و دلیل جایگزینی را ثبت کرد.

Resourceهای Superseded در Routing عادی خوانده نمی‌شوند، اما برای بررسی تاریخی قابل دسترس باقی می‌مانند.

30. Baseline Registry

Agent نباید برای پیدا کردن Workflow مناسب تمام پوشه Baselineها را Scan و مطالعه کند.

یک Registry سبک می‌تواند اطلاعات کلیدی هر Baseline را نگهداری کند.

هنگام شروع Workflow جدید:

1. Pipeline را مشخص کنید.
2. Execution Target را مشخص کنید.
3. نزدیک‌ترین Baseline سازگار را از Registry پیدا کنید.
4. Model و Implementation را بررسی کنید.
5. Conditioning Architecture را بررسی کنید.
6. Environment Compatibility را بررسی کنید.
7. Baseline را داخل Project Fork کنید.
8. derived_from را ثبت کنید.
9. فقط حداقل تغییرات مورد نیاز پروژه را اعمال کنید.

اگر Baseline مناسبی وجود نداشت، یک Workflow مینیمال ساخته می‌شود. بعد از Validation و آزمایش می‌تواند به Healthy Candidate تبدیل شود.

31. چه چیزهایی باید وارد Brain شوند؟

Brain نباید تبدیل به انبار تمام فایل‌های موفق شود.

اینکه یک Workflow در یک پروژه Render خوبی داده است، به‌تنهایی دلیل کافی برای Promote کردن آن نیست.

Promotion بهتر است نیازمند این شرایط باشد:

• Cross-project usefulness
• Verification
• Materially distinct configuration
• Explicit review

اگر پنج Experiment مختلف به یک نتیجه مشابه رسیده‌اند، بهتر است یافته مشترک آن‌ها در یک Canonical Knowledge Entry خلاصه شود.

Experimentهای خام Evidence هستند؛ نباید Context پیش‌فرض Agent باشند.

32. Backup و جداسازی فایل‌های Runtime

Brain باید در محلی پایدار و دارای Backup نگهداری شود.

اما قرار دادن تمام Renderها و Videoها داخل Brain اشتباه است.

موارد مناسب برای Brain:

• Skills
• Knowledge
• Baseline Workflowها
• Baseline Summaryها
• Schema Snapshotها
• Environment Profiles
• Client و Utility Scriptها
• Templates

مواردی که بهتر است داخل Project باقی بمانند:

• Renderها
• Video Outputها
• Raw Runها
• Temporary Experiments
• Project-specific References
• Project-specific Workflowها

این جداسازی باعث می‌شود Brain قابل Backup بماند، بدون اینکه به آرشیوی چندصد گیگابایتی از Outputها تبدیل شود.

33. شروع یک پروژه جدید

برای پروژه جدید لازم نیست Skillها و Knowledge را دوباره بسازید.

Project فقط باید بتواند Brain دائمی را پیدا کند.

جریان شروع پروژه:

New Project
     ↓
Brain Routing
     ↓
Classify Task
     ↓
Select Baseline
     ↓
Fork into Project
     ↓
Build / Render
     ↓
Controlled Diagnostics
     ↓
Project-specific results stay here
     ↓
Reusable verified knowledge?
     ↓
Promote only if justified

در نتیجه پروژه انیمیشن، پروژه تبلیغاتی یا پروژه Character Design می‌توانند در پوشه‌های کاملاً متفاوت باشند، اما همگی از یک Brain استفاده کنند.

همچنین باز کردن Chat جدید باعث از دست رفتن Knowledge نمی‌شود؛ زیرا دانش مرجع دیگر وابسته به Conversation نیست.

34. معماری نهایی سیستم

اگر تمام بخش‌های مقاله را کنار یکدیگر قرار دهیم، معماری کلی تقریباً چنین است:

                 USER / PRODUCTION TASK
                           |
                           ↓
                   PROJECT WORKSPACE
                           |
                           ↓
                     BRAIN ROUTER
                           |
             ┌─────────────┴─────────────┐
             ↓                           ↓
     PIPELINE / TARGET              BASELINE REGISTRY
      CLASSIFICATION                      |
             |                            |
             ↓                            ↓
       RELEVANT SKILL              SELECT BASELINE
             |                            |
             ↓                            |
    CANONICAL KNOWLEDGE                   |
             |                            |
             ↓                            |
      NODE INTELLIGENCE                   |
             |                            |
             └─────────────┬──────────────┘
                           ↓
                    FORK TO PROJECT
                           |
                           ↓
                    COMFYUI CLIENT
                           |
                    ┌──────┴──────┐
                    ↓             ↓
                  LOCAL         CLOUD
                    |             |
                    └──────┬──────┘
                           ↓
                         RENDER
                           |
                           ↓
                   VISUAL EVALUATION
                           |
                           ↓
                SYSTEMATIC DIAGNOSTICS
                           |
                           ↓
              ONE CONTROLLED EXPERIMENT
                           |
                           ↓
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
       PROMOTE          ROLLBACK       INCONCLUSIVE
       LOCALLY
          |
          ↓
Reusable across projects?
          |
     ┌────┴────┐
     ↓         ↓
    NO        YES
     |         |
 PROJECT   VERIFY + REVIEW
               |
               ↓
          PROMOTE TO BRAIN

35. اصول کلیدی این معماری

اگر بخواهیم کل این معماری را در چند قانون ساده خلاصه کنیم:

• دانش دائمی سیستم را از فایل‌های هر پروژه جدا نگه دارید.
• برای هر پروژه یا چت جدید همه‌چیز را از صفر نسازید؛ از تنظیمات سالم قبلی استفاده کنید.
• نسخه سالم و مرجع یک Workflow را دست‌کاری نکنید؛ برای پروژه یک کپی مستقل از آن بسازید.
• وقتی مشکلی می‌بینید، قبل از تغییر تنظیمات ابتدا یک علت احتمالی مشخص کنید.
• هر بار فقط یک تغییر مشخص را آزمایش کنید و بقیه تنظیمات را ثابت نگه دارید.
• اگر تغییر نتیجه خوبی نداد، به آخرین وضعیت سالم برگردید.
• فقط تغییراتی را نگه دارید که واقعاً باعث بهبود نتیجه شده‌اند.
• برای هر مشکل فوراً Prompt را تغییر ندهید؛ ممکن است مشکل از بخش دیگری باشد.
• بعد از چند خروجی بد فوراً Node را عوض نکنید؛ ابتدا مطمئن شوید مشکل واقعاً از همان Node است.
• برای شناخت Nodeها، تنظیمات و قابلیت‌های واقعی نسخه نصب‌شده ComfyUI را بررسی کنید و بر اساس حدس عمل نکنید.
• نتیجه یک آزمایش را فوراً به یک قانون کلی تبدیل نکنید.
• مشخص کنید هر اطلاعات چقدر قابل اعتماد است؛ مثلاً مستند شده، در پروژه آزمایش شده یا هنوز نیاز به بررسی دارد.
• نسخه‌های قدیمی را بی‌دلیل حذف نکنید؛ اگر نسخه بهتری جایگزین شده، آن‌ها را فقط از استفاده روزمره خارج کنید.
• فقط تجربه‌ها و روش‌هایی را وارد Brain کنید که در پروژه‌های دیگر هم واقعاً قابل استفاده باشند.
• لازم نیست Brain کوچک بماند؛ مهم این است که Agent برای هر کار فقط اطلاعات مرتبط با همان کار را بخواند.

جمع‌بندی

استفاده از Codex برای کنترل ComfyUI زمانی واقعاً جذاب می‌شود که Agent فقط نقش «دست‌هایی برای کلیک کردن روی Nodeها» را نداشته باشد.

هدف این است که Agent بتواند بفهمد از کدام Workflow شروع کند، چه دانشی برای مسئله فعلی لازم است، محیط اجرایی چه قابلیت‌هایی دارد، خروجی چه مشکلی دارد و برای بررسی علت آن چه آزمایشی باید انجام شود.

با جداسازی Brain از Project، دانش فنی بین پروژه‌ها حفظ می‌شود. با Baseline و Fork هر پروژه از یک نقطه سالم شروع می‌شود. با Node Intelligence تصمیم‌ها بر اساس نصب واقعی ComfyUI گرفته می‌شوند. با Systematic Diagnostics نیز Agent به‌جای تغییر تصادفی پارامترها، فرضیه‌ها را یکی‌یکی آزمایش می‌کند.

در عین حال معماری HOT/WARM/COLD اجازه می‌دهد Brain در طول ماه‌ها و سال‌ها رشد کند، بدون اینکه هر Task مجبور باشد تمام این دانش را وارد Context کند.

در واقع هدف نهایی این نیست که برای Codex مجموعه بزرگی از دستورالعمل‌ها بنویسیم؛ هدف ساخت سیستمی است که بداند چه زمانی باید چه چیزی را بداند.