AI Agent ها برای طراحان: چطور Workflow های Agentic طراحی و بسازیم

تفاوت بین یک chatbot و یک agent، تفاوت بین یک نیروی تازه‌کار است که منتظر پیام بعدی شما می‌ماند و نیروی تازه‌کاری که می‌رود و کل کار را تمام می‌کند.

آن نسخه دوم در هجده ماه گذشته وارد ابزارهای شما شد، و اکثر طراحان هنوز متوجه نشده‌اند. دارند prompt می‌نویسند در یک پنجره chat، جواب را کپی می‌کنند، در Figma paste می‌کنند، و تعجب می‌کنند چرا workflow‌شان مثل نسخه کمی سریع‌تر 2023 به نظر می‌رسد. تغییر agent نه "یک ChatGPT بهتر" است. بلکه یک تغییر دسته‌بندی است.

یک agent یک هدف می‌گیرد. تصمیم می‌گیرد کدام ابزارها را فراخوانی کند. آن‌ها را به ترتیب فراخوانی می‌کند، نتایج را می‌خواند، مسیر را تصحیح می‌کند، و یک چیز تمام‌شده تحویل می‌دهد. دیگر در یک chat تایپ نمی‌کنید. دارید به یک تیم کوچک briefing می‌دهید و deliverable را بررسی می‌کنید.

Chatbot، copilot، agent، و اینکه چرا تفاوت اهمیت دارد

سه کلمه مثل اینکه یک چیز را می‌گویند استفاده می‌شوند. نمی‌گویند.

یک chatbot نوبتی است. شما می‌پرسید، جواب می‌دهد، دوباره می‌پرسید. ChatGPT بدون ابزار، Claude در یک پنجره chat ساده، Gemini در اپ. context هر چیزی است که paste می‌کنید. خروجی متن است.

یک copilot کمک inline است. GitHub Copilot، ویژگی‌های AI در Figma، Notion AI. داخل ابزار دیگری زندگی می‌کند و قدم بعدی را در حین کار شما پیشنهاد می‌دهد. از خطی که در آن هستید خارج نمی‌شود. کار چند مرحله‌ای برنامه‌ریزی نمی‌کند.

یک agent هدف‌محور است. یک نتیجه به آن می‌دهید، نه قدم بعدی. ابزارهای خودش را انتخاب می‌کند، آن‌ها را در یک loop فراخوانی می‌کند، پیشرفت خودش را بررسی می‌کند، و وقتی هدف محقق شد یا به ورودی شما نیاز داشت متوقف می‌شود. واضح‌ترین مثال مدرن Claude Code است که در terminal شما با MCP server های متصل اجرا می‌شود، هرچند agent mode در ChatGPT، پنل agent در Cursor، و Computer Use آنتروپیک همه به همین شکل عمل می‌کنند.

نتیجه‌گیری: chatbot ها پاسخ می‌دهند، copilot ها کمک می‌کنند، agent ها تحویل می‌دهند.

یک agent یک loop است، نه یک prompt تکی

هر agent که تا حالا استفاده می‌کنید یک چرخه چهار مرحله‌ای یکسان اجرا می‌کند. این شکل را یاد بگیرید و می‌توانید پیش‌بینی کنید چطور هر ابزار agentic رفتار می‌کند.

1. برنامه‌ریزی. Agent هدف را می‌خواند و اولین قدم را تصمیم می‌گیرد.
2. عمل. یک ابزار فراخوانی می‌کند. یک فایل می‌خواند، یک API query می‌کند، یک دستور اجرا می‌کند، یک URL fetch می‌کند.
3. مشاهده. خروجی ابزار را می‌خواند و تصمیم می‌گیرد آیا به هدف نزدیک‌تر شده یا نه.
4. تکرار. اگر تمام نشده، قدم بعدی را برنامه‌ریزی می‌کند. اگر تمام شد، گزارش می‌دهد.

آن loop همه چیز است. جادویی که مردم به agent ها نسبت می‌دهند فقط loop است که با ابزارهای مفید کافی متصل شده، تمیز اجرا می‌شود. بدون loop، agent وجود ندارد. یک model که یک بار پاسخ می‌دهد chatbot است. یک model که loop را با ابزار، به سمت یک هدف اجرا می‌کند، agent است.

جعبه ابزار agent طراح در 2026

نیازی نیست از صفر یک agent بسازید. در آوریل 2026، سطح مفید agent برای طراحان اینگونه است.

Claude Code. در terminal یا داخل VS Code زندگی می‌کند. کل repo شما را می‌خواند. فایل‌ها را فراخوانی می‌کند، دستورات اجرا می‌کند، با MCP server ها صحبت می‌کند. برای هر چیزی که به کد، token، یا یک design system repo مربوط می‌شود بهترین است.

Claude Desktop و ChatGPT با MCP. هر دو اکنون از اتصالات MCP پشتیبانی می‌کنند. می‌توانید آن‌ها را به Figma، Google Drive، Notion، Linear، و filesystem متصل کنید. برای تحقیق، briefing، نوشتن spec، و کارهای محتوایی بهتر از کدنویسی هستند.

Cursor agent mode. Agent بومی editor برای ساخت در React، Vue، یا Svelte. از نظر عملکرد به Claude Code نزدیک‌تر است، با یک رابط بصری به جای terminal.

Figma MCP. خودش agent نیست. یک اتصال‌دهنده ابزار است. Figma را به یک منبع داده تبدیل می‌کند که agent می‌تواند بخواند. یک بار راه‌اندازی کنید، هر agent آگاه به MCP می‌تواند frame های شما را ببیند. راه‌اندازی در Figma MCP: اتصال Figma به Claude Code و AI Agent ها توضیح داده شده.

n8n، Zapier agents، و اسکریپت‌های سفارشی. اگر می‌خواهید یک agent داشته باشید که طبق برنامه اجرا می‌شود یا به یک webhook واکنش نشان می‌دهد (کامنت جدید Figma، ارسال جدید Google Form، ایمیل جدید در یک inbox مشترک)، اینها پلتفرم‌های hosting هستند. طراحان از آن‌ها برای agent های "چسب" استفاده می‌کنند، آن‌هایی که در پس‌زمینه در حین خواب شما اجرا می‌شوند.

برای اکثر طراحان، stack شروع مناسب Claude Code به علاوه Figma MCP به علاوه یک اتصال به Google Drive یا Notion است. این برای پوشش نود درصد کارهای طراحی agentic کافی است.

چطور یک agent طراحی کنیم (هنوز هم یک brief است)

طراحی یک agent یک وظیفه کدنویسی نیست. یک وظیفه briefing است. همان کاری که هر بار که کار را به یک فریلنسر یا نیروی تازه‌کار می‌دهید انجام می‌دهید.

چهار سوال که باید به ترتیب، قبل از ساختن هر چیزی، پاسخ دهید.

1. هدف چیست؟ یک جمله. "از یک رونویسی جلسه discovery مشتری، یک moodboard و یک creative brief کوتاه تولید کن."
2. به چه ابزارهایی agent نیاز دارد؟ آن‌ها را لیست کنید. "یک Google Doc بخواند، وب را جستجو کند، تصویر fetch کند، در یک فایل Figma بنویسد، در یک پوشه Google Drive ذخیره کند."
3. چه قوانینی آن را محدود می‌کند؟ "فقط تصاویر را از منابع editorial بکشد، نه عکاسی stock. هرگز یک برند اختراع نکند. هر منبع را ذکر کند. همیشه brief را در فرمت house ما تولید کند."
4. کِی متوقف می‌شود؟ "وقتی فایل Figma یک frame moodboard با حداقل 12 reference داشته باشد و brief به عنوان PDF در Drive مشترک ذخیره شده باشد."

هدف را از دست بدهید و agent دریفت می‌کند. ابزارها را از دست بدهید و با ابزارهای اشتباه بداهه می‌گوید. قوانین را از دست بدهید و میانگین داده‌های training خود را برای شما ارسال می‌کند، که معمولاً stock و AI slop است. شرط توقف را از دست بدهید و برای همیشه loop می‌کند یا زود متوقف می‌شود.

این همان شکل prompt پنج قسمتی است که در Prompt Engineering برای طراحان پوشش داده شده، که برای کار چند مرحله‌ای مقیاس یافته.

دستور العمل 1: agent تحقیق تا moodboard

اولین agent که هر design studio باید بسازد. یک رونویسی جلسه discovery مشتری می‌خورد و یک moodboard اول و یک creative brief کوتاه تولید می‌کند.

هدف. از یک رونویسی جلسه discovery، یک moodboard در Figma و یک creative brief در Google Drive تولید کن.

ابزارهای مورد نیاز. Google Drive MCP (خواندن رونویسی، نوشتن brief)، جستجوی وب، fetch تصویر، Figma MCP (نوشتن در یک frame moodboard).

شکل system prompt. این دستورالعملی است که یک بار در ابتدای session به agent می‌دهید.

You are a senior brand strategist at Brainy, a design studio with 2M+
community followers. Your job: turn a discovery call transcript into
a first-pass creative direction.

Goal:
- Read the transcript at the Google Drive URL I give you.
- Extract: client name, industry, audience, brand adjectives (3-5),
  competitors mentioned, any visual references they named.
- Produce two deliverables:
  1. A creative brief, saved as a Google Doc in /Brainy/Briefs/
     using our template at /Brainy/Templates/brief.docx.
  2. A Figma moodboard in the file I specify, populated with at
     least 12 editorial image references (no stock photography).

Rules:
- Use only editorial sources: Are.na, It's Nice That, Brand New,
  museum archives, design studio portfolios. Never Shutterstock,
  Getty, or Unsplash generic.
- Every image needs a source URL captioned on the Figma frame.
- Voice for the brief: Brainy house voice. Opinionated on craft,
  neutral on facts. No corporate filler.
- If the transcript is unclear on an adjective, flag it as "needs
  confirmation" in the brief instead of inventing one.

Stop when:
- Brief is saved, moodboard has 12+ captioned references, and you
  have posted the two URLs back to me.

این یک agent brief کاری است. آن را در Claude Desktop با اتصالات MCP به Drive و Figma paste کنید، آن را به یک رونویسی اشاره کنید، و خروجی را بررسی کنید.

چه چیزی را بررسی می‌کنید. آیا adjective ها درست هستند؟ آیا reference ها on-brand هستند و به سمت بدیهی دریفت نمی‌کنند؟ آیا واقعاً هر تصویر را با یک منبع caption کرده؟ آیا brief به سبک house است یا به LinkedIn English برگشته؟

تکرار. اولین اجرا خشن خواهد بود. system prompt را با آنچه agent از دست داده به‌روزرسانی کنید. دوباره اجرا کنید. بعد از سه یا چهار چرخه، agent brief هایی ارسال می‌کند که می‌توانید بدون بازنویسی به یک استراتژیست client-facing بدهید.

دستور العمل 2: agent spec تا handoff

این agent شکاف بین "طراحی تایید شد" و "dev همه چیزی که نیاز دارد را دارد" را می‌بندد. یک فایل Figma می‌خواند و سند handoff مهندسی می‌نویسد.

هدف. با توجه به یک URL فایل Figma، یک سند handoff توسعه‌دهنده با inventory کامپوننت، لیست token، مقادیر spacing، و سوالات باز تولید کن.

ابزارهای مورد نیاز. Figma MCP، یک جا برای نوشتن خروجی (Notion، GitHub issue، Google Doc، انتخاب شما).

شکل system prompt.

You are a senior design systems engineer acting as the bridge
between a design team and a front-end team.

Goal:
- Read the Figma file at the URL I give you.
- Produce a handoff document containing:
  1. Component inventory: every component instance used, counted,
     with Figma component name and closest existing code component
     name from our /components/ directory.
  2. Token usage: every color, spacing, and typography variable
     referenced, compared against /design/tokens.css.
  3. Layout specs: breakpoints used, any auto-layout frames that
     might be ambiguous at edge cases.
  4. Open questions: a bulleted list of anything in the Figma file
     that cannot be resolved from the file alone (missing states,
     unclear interactions, content placeholders).
- Write the output as a Notion page in /Engineering/Handoffs/.

Rules:
- Never invent a component. If a Figma element does not map to an
  existing code component, list it under "new components required"
  with a one-line description.
- Flag every free-form (non auto-layout) frame as a risk.
- Include the Figma node ID for every item so devs can jump to it.
- Do not assume interactions that are not explicitly in the file.

Stop when:
- Notion page is written and you have posted the URL back to me.

چرا این دستور العمل اهمیت دارد. مشکل "طراح فکر می‌کرد این تحویل داده شد، dev token ها را پیدا نکرد" کلاسیک است. این agent آن را در حدود نود ثانیه به ازای هر feature حل می‌کند.

کجا خراب می‌شود. روی فایل‌های Figma که درهم‌برهم هستند. frame های بدون auto-layout، استفاده ناسازگار از variable، کامپوننت‌های یک‌بار مصرف تصادفی. agent درهم‌برهم را نمایش می‌دهد، که یا یک هدیه است (حالا می‌دانید) یا یک مشکل (حالا باید آن را درست کنید).

دستور العمل 3: agent QA طراحی

agent ای که بعد از یک deploy اجرا می‌شود و می‌گوید چه چیزی اشتباه ارسال شده.

هدف. یک URL staging مستقر شده را با فایل Figma مرجع مقایسه کن و دریفت بصری را گزارش بده.

ابزارهای مورد نیاز. Figma MCP، Playwright (برای گرفتن screenshot از صفحه staging)، مقایسه تصویر (Claude می‌تواند به صورت native تصاویر را در vision mode مقایسه کند).

شکل system prompt.

You are a senior product designer doing a pre-release visual QA pass.

Goal:
- Visit the staging URL I give you at three breakpoints: 1440px,
  768px, 375px.
- For each breakpoint, take a full-page screenshot using Playwright.
- Compare each screenshot to the corresponding Figma frame at the
  URL I provide.
- Produce a QA report listing every visual difference, categorized:
  - BLOCKING: wrong components, wrong colors, broken layouts
  - NON-BLOCKING: spacing off by less than 4px, minor type weight
    mismatches, image crops slightly different
  - INFORMATIONAL: intentional differences between design and code
    worth noting

Rules:
- Do not flag differences that are within 2px of intended spacing
  unless they visibly break alignment.
- Include a screenshot-with-annotation for every BLOCKING item.
- Link every item back to the Figma node ID.
- Output as a Markdown file in /qa/reports/ with timestamp.

Stop when:
- Report is saved and you have posted the path back to me.

چرا این دستور العمل اهمیت دارد. اکثر تیم‌ها QA طراحی را به صورت دستی یا اصلاً انجام نمی‌دهند. یک agent QA در هر deploy پیش از prod اجرا می‌شود. 80 درصد دریفتی را که چشم‌ها در صفحه سوم از دست می‌دهند می‌گیرد.

طراحان چطور از آن استفاده می‌کنند. آن را در CI wire کنید تا به صورت خودکار روی deploy های staging اجرا شود. یا آن را دستی نگه دارید و قبل از ارسال هر چیز قابل مشاهده اجرا کنید. در هر صورت، دیگر تنگنا نیستید که "آیا این درست ارسال شد."

آنچه agent ها (هنوز) نمی‌توانند انجام دهند

با خودتان صادق باشید. اینجا جایی است که agent ها در آوریل 2026 شکست می‌خورند.

تصمیمات سلیقه. agent یک moodboard شایسته برای شما ارسال می‌کند. نمی‌تواند به شما بگوید moodboard از نظر احساسی سطحی است یا اینکه برند باید بیشتر روی خویشتن‌داری تمرکز کند. این هنوز کار شماست.

اهداف مبهم. "سایت را بهتر کن" یک هدف نیست. agent loop می‌کند یا خروجی generic تولید می‌کند. اگر نمی‌توانید هدف را در یک جمله با یک شرط توقف واضح بیان کنید، agent هیچ شانسی ندارد.

استراتژی نوآورانه. agent ها در اجرای یک استراتژی که شما تعریف کرده‌اید عالی هستند. در اختراع آن از یک صفحه سفید ضعیف هستند. positioning، معماری برند، تصمیمات محصول از اصول اول هنوز کار انسان‌هاست.

قضاوت بلند مدت. یک agent می‌تواند به شما بگوید "این Button variant استفاده نمی‌شود." نمی‌تواند به شما بگوید "ما در شرف راه‌اندازی یک صفحه pricing هستیم که به یک Button variant چهارم نیاز خواهد داشت، پس آن را حذف نکنید." agent snapshot را می‌بیند، نه roadmap را.

هر چیزی که به اعتماد با یک مشتری یا شریک نیاز دارد. یک استراتژیست client-facing، یک art director که به یک فریلنسر بازخورد می‌دهد، یک creative director که یک ایده را pitch می‌کند. agent ها به این انسان‌ها کمک می‌کنند. آن‌ها را جایگزین نمی‌کنند.

قانون: agent ها اجرا را انجام می‌دهند. انسان‌ها سلیقه، استراتژی، و اعتماد را انجام می‌دهند.

چطور مثل یک طراح agent فکر کنیم، نه یک کاربر agent

بین استفاده از agent ها و طراحی آن‌ها تفاوت وجود دارد. اکثر طراحان در نهایت هر دو را انجام خواهند داد.

استفاده از یک agent کار prompt است. نوشتن یک brief، بررسی خروجی، تکرار.

طراحی یک agent کار سیستم است. شما هدف را تعریف می‌کنید، ابزارها را انتخاب می‌کنید، محدودیت‌ها را می‌نویسید، شرط توقف را تنظیم می‌کنید، و یک feedback loop می‌سازید تا agent با گذر زمان بهتر شود. به اداره یک تیم کوچک نزدیک‌تر است تا نوشتن یک prompt.

سه عادت که افرادی که agent های خوب طراحی می‌کنند را از کسانی که با agent های خراب دست و پنجه نرم می‌کنند جدا می‌کند.

یک، brief را قبل از باز کردن ابزار می‌نویسند. بدون تایپ تا زمانی که هدف، ابزارها، قوانین، و شرط توقف روی کاغذ نباشند. یک ساعت سردرگمی را ذخیره می‌کند.

دو، system prompt را مثل کد version می‌کنند. آن را در یک فایل ذخیره می‌کنند. اگر می‌توانند در git check می‌کنند. هر بار که agent به شیوه جدیدی شکست می‌خورد، یک قانون اضافه می‌کنند. prompt با گذر زمان باهوش‌تر می‌شود، نه پر سروصداتر.

سه، هر اجرا را برای ده اجرای اول بررسی می‌کنند. به طور پیش‌فرض اعتماد نمی‌کنند. هر خروجی خوانده، ارزیابی، و برای به‌روزرسانی prompt استفاده می‌شود. بعد از ده اجرا agent به اندازه کافی قابل اعتماد است که در پس‌زمینه اجرا شود. قبل از ده اجرا نیست.

اگر می‌خواهید breakdown های بیشتری از workflow AI داشته باشید، بقیه Brainy Papers را مرور کنید. اگر می‌خواهید workflow های agentic در تیم شما بدون سه ماه اول دست و پا زدن wire شوند، Brainy را استخدام کنید و ما کل stack را ارسال می‌کنیم.

برنامه شروع agent برای طراح

یک هفته، یک agent، یک loop کاری.

• یک workflow که به طور مکرر انجام می‌دهید انتخاب کنید. نه یک workflow خیالی. یک واقعی که این ماه انجام دادید.
• هدف یک جمله‌ای، لیست ابزارها، قوانین، و شرط توقف را روی کاغذ بنویسید.
• Claude Code یا Claude Desktop را با یک اتصال MCP راه‌اندازی کنید (Figma، Drive، یا filesystem).
• brief را به عنوان system prompt paste کنید. agent را روی یک ورودی واقعی اجرا کنید.
• خروجی را به دقت بخوانید. آن را در برابر آنچه خودتان ارسال می‌کردید ارزیابی کنید.
• prompt را با آنچه شکست خورد به‌روزرسانی کنید. دوباره اجرا کنید.
• سه تا پنج بار تکرار کنید. یادداشت کنید هر اجرا چقدر زمان می‌برد در مقایسه با انجام آن خودتان.
• system prompt نهایی را ذخیره کنید. این اولین agent production شماست.

یک بار این کار را انجام دهید و agent دوم نصف زمان می‌برد. agent چهارم یک بعد از ظهر می‌برد. agent هشتم در حین خواب شما بر اساس یک برنامه اجرا می‌شود.

سوالات متداول

آیا برای ساخت یک AI agent نیاز به کدنویسی دارم؟

نه. هر دستور العمل بالا از طریق یک system prompt به علاوه اتصالات MCP پیکربندی می‌شود، که هر دو در یک UI یا یک دستور تنظیم می‌شوند. شما briefing می‌نویسید و ابزارها را wire می‌کنید، نه کد production. اگر می‌توانید Zapier را پیکربندی کنید، می‌توانید یک agent پیکربندی کنید.

تفاوت بین Claude Code و یک Claude agent چیست؟

Claude Code یک agent خاص است، آنی که در terminal شما زندگی می‌کند و برای کار با codebases ساخته شده. "یک Claude agent" هر agent ای است که توسط مدل Claude تامین می‌شود، که می‌تواند Claude Code، Claude Desktop با ابزارها، یک agent سفارشی ساخته شده از طریق Anthropic API، یا یک agent به سبک ChatGPT که از Claude زیر hood استفاده می‌کند باشد. Claude Code agent flagship برای کار طراح-توسعه‌دهنده در 2026 است.

اجرای یک agent چقدر هزینه دارد؟

برای طراحان انفرادی، یک اشتراک Claude Max یا ChatGPT Plus به ترتیب Claude Code و agent mode را پوشش می‌دهد. این در حد چند صد دلار در ماه است و اکثر ابزارهایی که نیاز دارید را شامل می‌شود. برای تیم‌ها، استفاده از API با میزان اجرای agent ها مقیاس می‌یابد. بودجه برای استفاده سنگین از حدود 50 تا 200 دلار به ازای هر طراح در ماه شروع می‌شود. در مقایسه با زمانی که ذخیره می‌کند ارزان است.

حالا یک تیم کوچک اداره می‌کنید

قبلاً یک طراح بودید. brief دریافت می‌کردید و کار تولید می‌کردید. این هنوز بخشی از کار است.

حالا یک بخش دوم وجود دارد. شما برای تیم‌های کوچک agent هایی که در حین انجام بخش اول کار تولید می‌کنند brief می‌نویسید. خروجی آن‌ها را بررسی می‌کنید. وقتی دریفت می‌کنند تصحیح می‌کنید. agent هایی که ارزش خود را نشان نمی‌دهند را بازنشسته می‌کنید و آن‌هایی که این کار را می‌کنند را ارتقا می‌دهید.

طراحانی که این تغییر را اول درک می‌کنند دهه را مال خود خواهند کرد. نه به خاطر اینکه agent ها طراحان را جایگزین می‌کنند، بلکه به خاطر اینکه طراحانی که agent اجرا می‌کنند دارند طراحانی را که این کار را نمی‌کنند جایگزین می‌کنند.

یک workflow انتخاب کنید. brief بنویسید. اولین agent را ارسال کنید. خروجی را بررسی کنید. دوشنبه دوباره این کار را انجام دهید.