🧠 🚀هوش مصنوعی در تیم توسعه‌: ابزار روزمره به جای تقلب!

با رایج شدن مدل‌های هوش مصنوعی توی محیط‌های توسعه؛ مسیر تعامل برنامه‌نویس با مدل، از حالت پرسش ‌و پاسخ یا Ask، به توانمندی ویرایش یا Edit رسید و بعدتر به حالت Agent. در طول این مسیر، نیاز به سر و سامون دادن به رفتار مدل و اعمال تنظیمات دلخواه، ضرورتش بیشتر و بیشتر شد. حالا این تنظیمات می‌تونه پرامپت‌های از پیش ذخیره شده باشه برای صرفه‌جویی در زمان، یا مثلا دستورالعمل‌هایی مثل ساختار نامگذاری متغیرها یا اینکه همیشه لاگ‌ها رو به شیوه خاص بنویسه یا... برای همین فایل‌هایی مثل AGENTS.md یا .github/copilot-instructions.md یا .instructions.md به وجود اومدن.
توی این پست، اول این فایل‌ها رو با مثال مرور می‌کنم، بعدتر به اهمیت توجه به یکسان‌سازی/استانداردسازی اون‌ها در تیم‌های توسعه توسط platform engineering خواهم نوشت. این ابزارها خیلی سریع دارن توی ریپازیتوری‌های حرفه‌ای و شرکت‌ها، جا می‌افتن و مهمه که بدونیم دقیقاً چی‌ان؟ چرا مهم‌ان؟ و اصلاً چطور می‌تونن به تیم ما کمک کنن؟

✅ این فایل‌ها چی هستن؟

اگه بخوام ساده بگم، این فایل‌ها نقش «دستورالعمل استفاده از هوش مصنوعی» رو دارن برای توسعه‌دهنده‌ها و ابزارهای هوشمند مثل GitHub Copilot، Cody، یا حتی agentهای داخلی تیم‌ها.
به کمک این فایل‌ها، می‌تونیم به ابزار AI یاد بدیم که:

- چه سبکی از کدنویسی رو تو پروژه‌مون ترجیح می‌دیم
- از چه کتابخونه‌ها یا معماری‌هایی استفاده می‌کنیم
- چه چیزهایی ممنوعه یا نیاز به تایید دارن
- حتی چه تسک‌هایی رو می‌تونه خودش انجام بده یا نیمه‌کاره پیش‌نویس بزنه

🔧 مثال‌های کاربردی:

👨‍💻فایل copilot-instructions.md:
فایل ساده‌ایه که توش توضیح می‌دیم Copilot تو این ریپو چطوری باید رفتار کنه. مثلاً:

- از Flurl.Http استفاده کن، نه HttpClient
- وقتی اسم متد با Get شروع شد، حتماً یه تست یونیت بساز
- همیشه Exceptionهای گلوبال با ProblemDetails هندل می‌شن

 .github/copilot-instructions.md
# Shared Platform Coding Standards

- Use `async/await`, not callbacks.
- Follow project’s naming conventions.
- Include dependency vulnerability tagging in comments.
- Provide default error handling structure.
- Always include logging statements.

🤖 فایل AGENTS.md:
اگه تو تیم‌مون agent داریم (مثلاً برای اینکه PR می‌زنه یا کد جنریت می‌کنه؛ یا از منابع کانفلوئنس شرکت اطلاعات می‌خونه یا به جیرا دسترسی داره یا...)، این فایل نقش پروفایل اون agent رو داره.
توش توضیح می‌دیم که این agent قراره چی کار کنه، چه داده‌ای داره، چه دامنۀ تصمیم‌گیری‌ای داره و کی باید بررسی کنه خروجیاشو.

AGENTS.md
# AGENTS.md — Developer Platform Guide for AI Agents

## Environment Setup
- `make setup` to install dependencies.
- `make test` for running full test suite.
- `docker compose up` to launch local services.

## Code Style
- Pre-commit: `black`, `isort`, `eslint`.
- Linting: `./tools/lint`.
- Tests: coverage must exceed 85%.

## Development Workflow
- Branch naming: `feat/*`, `fix/*`.
- PR guidelines: include ticket link, test coverage, and description.

## Platform Behavior
- Always run `make build` before tests.
- Platform maintains shared Docker images, secrets, and env configurations.

📘 فایل .instructions.md:
یه فایل کلی‌تر برای راهنمایی خود ابزارها یا هم‌تیمی‌ها. توش ممکنه توضیح بدیم تو این پروژه چه Naming Convention داریم، چطوری باید migration ساخت، یا اینکه اصلاً ساختار پوشه‌ها چطوریه.

backend.instructions.md
---
applyTo: "backend/**/*.py"
---
# Backend Python Guidelines

- Format using Black (line length 88).
- Use Pydantic for input validation.
- Comment public functions with docstrings.
- Follow platform’s API client patterns.

ادامه در پست بعدی...

ادامه و جمع‌بندی:

🏗 پیشنهاد برای تیم‌ها و شرکت‌ها:
قبل از اینکه مدل‌های زبانی تبدیل به ابزار تقلب یا تولید کدهای «نفهمیده‌شده» بشن، سعی کنید ساختارمند و صحیح به عنوان ابزار کمکی به تیم معرفی کنید و براش برنامه و آموزش و منابع در نظر بگیرید.

اگه تبدیل بشن به بخشی از یه زیرساخت مشترک تیمی، دقیقاً مثل تمپلیت‌های .editorconfig یا CI/CDهای سراسری، اون‌وقت واقعاً اثر می‌ذارن و سرعت توسعه و کیفیت محصول رو افزایش می‌دن. و به نظرم این‌کار باید توسط تیم پلتفرم یا DevEx انجام بشه. اونا می‌تونن یه repo مرکزی بسازن برای این دستورالعمل‌ها، یا حتی یه پک آماده بدن که با هر پروژه جدید بشه cloneش کرد. مثلا می‌تونید از این ریپو برای دیدن انواع پرامپت‌ها یا دستورالعمل‌ها الهام بگیرید و نسخه بومی تیمتون رو بسازید...

💡 اگه می‌خوایم هوش مصنوعی رو به عنوان یه همکار قابل‌اعتماد و سازنده وارد تیم کنیم، نه یه ابزار دیمی و فانتزی، لازمه این زیرساخت‌های ساده ولی مهم رو جدی بگیریم.

فایل‌هایی مثل AGENTS.md یا copilot-instructions.md شاید کوچیک باشن، ولی یه قدم بزرگ‌ان برای کار تیمی، استانداردسازی، و استفاده درست از AI تو توسعه‌ی نرم‌افزار.

🎯 معرفی گیت‌وی اختصاصی هوش مصنوعی: AgentGateway چیه و چرا به وجود اومده؟

این روزها که گاهی عاقلانه و گاهی جوگیرانه، استفاده از agentها و MCPها رایج شده، و ارتباط و یکپارچگی نرم‌افزارها با مدل‌های هوش مصنوعی داغه، باید یه مشکل اساسی رو بررسی کنیم:

💡 چطوری این agentها بتونن ابزارهای مختلف رو کشف کنن، بهشون متصل بشن، احراز هویت کنن، نتیجه بگیرن و اگه لازم شد fallback بزنن؟ برای پاسخ به این نیاز، گیت‌وی‌هایی اختصاصی برای ارتباط با agents وارد می‌شن!

🛠 حالا AgentGateway چیه؟
پروژه AgentGateway یه پروژه متن‌بازه که agents هوش مصنوعی، سرورهای MCP و ارائه‌دهنده‌های LLM رو در هر محیطی به هم وصل می‌کنه. این اتصالات دوطرفه، امن، مقیاس‌پذیر و stateful هستن و امکانات لازم مثل امنیت سازمانی، observability، انعطاف‌پذیری و multi-tenancy رو ارائه می‌ده.

✅ وظایف کلیدی AgentGateway:

🔗 ارتباط یکپارچه:
- اتصال امن و مقیاس‌پذیر بین agentها و ابزارها
- پشتیبانی از پروتکل‌های agent مثل MCP و A2A
- تبدیل REST APIهای موجود به ابزارهای agent-native

🛡 امنیت و مدیریت:
- احراز هویت JWT و سیستم RBAC قدرتمند
- محافظت در مقابل حملات tool poisoning
- کنترل دسترسی در سطح agent، tool و tenant

⚡️ عملکرد سریع:
- با Rust نوشته شده تا کارایی بالا، تأخیر کم، قابلیت اطمینان و پایداری رو حفظ کنه
- مدیریت اتصالات طولانی‌مدت و الگوهای fan-out داره

📊 نظارت و مدیریت:
- از metrics و tracing داخلی برای رصد تعاملات پشتیبانی می‌کنه
- پورتال سلف‌سرویس برای توسعه‌دهنده ارائه می‌کنه

❓فرق اساسیش با API Gateway چیه؟

نوع درخواست‌ها:
- گیت‌وی API: عمدتاً REST/HTTP
- گیت‌وی Agent: تعاملات پیچیده مثل Agent ↔️ Tool، Agent ↔️ Agent، Agent ↔️ LLM

پروتکل ارتباطی:
- گیت‌وی API: HTTP
- گیت‌وی Agent: MCP و A2A که پروتکل‌های JSON-RPC برای ارتباط agents و tools هستن

مدیریت session:
- گیت‌وی API: درخواست‌های کوتاه‌مدت HTTP
- گیت‌وی Agent: می‌تونه sessionهای stateful که باید context جلسه رو حفظ کنن و پیام‌ها رو مداوماً ارسال و دریافت کنن رو ارائه کنه

پیچیدگی پردازش:
- گیت‌وی API: قادر به forward کردن ساده درخواست‌ها است
- گیت‌وی Agent: دسترسی به چندین سرور MCP، تجمیع پاسخ‌ها و بازگردوندن نتیجه منسجم رو داره

🚫 چرا گیت‌وی‌های سنتی کافی نیستند؟

گیت‌وی‌های سنتی برای معماری microservices RESTful طراحی شدن که درخواست‌های HTTP کوتاه‌مدت دریافت می‌کنن، backend رو انتخاب می‌کنن و درخواست رو forward می‌کنن. ولی:

🔴 مشکلات اساسی:
- عدم پشتیبانی از session awareness
- ضعف در مدیریت ارتباطات دوطرفه
- این الگوهای ارتباطی resource intensive هستند و می‌تونن گیت‌وی‌های سنتی رو مختل کنن
- نیاز به بازطراحی اساسی برای پشتیبانی از use caseهای agentic AI دارن

🚀 ویژگی‌های منحصربه‌فرد AgentGateway

ارائه data plane یکپارچه:
مدیریت اتصال agent با پشتیبانی از پروتکل‌های agent و قابلیت یکپارچه‌سازی REST APIهای موجود

امکان multiplexing و federation:
ارائه endpoint واحد برای federation چندین سرور MCP و مجازی‌سازی tool server بر اساس هر client

پشتیبانی از هر framework:
سازگاری با هر framework agentic که از پروتکل‌های MCP و A2A پشتیبانی می‌کنه، مثل LangGraph، AutoGen، kagent، Claude Desktop و OpenAI SDK

خصوصیت platform-agnostic:
قابلیت اجرا در هر محیطی از bare metal تا virtual machine، containers و Kubernetes

به‌روزرسانی پویا:
امکان به‌روزرسانی از طریق رابط xDS بدون downtime

🛡 سیاست‌های امنیتی و ترافیک:

مدیریت ترافیک:
- دستکاری headerها، redirect، rewrite
- پاسخ مستقیم بدون ارسال به backend

امنیت پیشرفته:
- تنظیمات CORS، احراز هویت MCP
- پشتیبانی از TLS برای backend، محدودیت نرخ محلی و توزیع شده
- پشتیبانی از JWT Auth و external authorization

انعطاف‌پذیری:
- قابلیت‌های request mirroring، timeout، retry logic

🎯 کی از AgentGateway استفاده کنه خوبه؟

- سازمان‌های بزرگ: مدیریت ارتباطات پیچیده بین agents
- توسعه‌دهنده‌های AI: یکپارچه‌سازی tools و agents
- تیم‌های DevOps: استقرار در محیط‌های مختلف
- محققین: آزمایش فریم‌ورک‌های جدید agent

مخزن گیت‌هاب
مستندات رسمی