اینکه LLM دیگه کل Architecture نیست؛ فقط یکی از اجزای اونه.
مقاله از چیزهایی مثل Context Engineering، Agent Orchestration، Tool/MCP Architecture، Sandboxed Execution و Verification صحبت می‌کنه.
اما وقتی این بحث را می‌برم سمت Enterprise و مخصوصاً On-Prem، یک سؤال دیگه برام پررنگ‌تر می‌شه:
اینکه Agent دقیقاً اجازه داره چه کاری انجام بده؟
در محیط واقعی ممکنه مشتری:
- به LLMهای Cloud دسترسی نداشته باشد
- داده‌هاش نباید از شبکه خارج بشه
- اینترنت و سرویس‌های خارجی محدود باشه
- ما تو ایران هستیم و با محدودیت‌های تحریم مواجه باشه
- و مهم‌تر از همه، Agent قرار باشه روی سیستم واقعی مشتری Action انجام بده.
تو این شرایط، اینکه یک LLM رو داخل شبکه بیاریم، به‌تنهایی مسئله رو حل نمی‌کنه.
باید بدونیم:
این Agent با چه Identity ای کار می‌کنه؟
چه Permissionهایی داره؟
به چه داده‌ای دسترسی داره؟
چه Capabilityهایی در اختیارشه؟
کدوم Actionها نیاز به Approval دارن؟
و چطور می‌تونیم بعداً Audit کنیم که چه تصمیمی گرفته و چرا؟
برام این زنجیره داره تبدیل به یکی از بخش‌های اصلی معماری Agent می‌شه:
Identity → Permission → Capability → Approval → Audit
یک API معمولاً می‌گه:
Do Xاما Agent می‌گه:
I decided to do X.و این دو از نظر معماری خیلی با هم فرق دارن.
به نظرم یکی از تغییرات مهم معماری با ورود Agentها این نیست که Agent جای Service را می‌گیره.
تغییر مهم‌تر اینه که:
یک Decision Boundary تبدیل به یک Architectural Concern می‌شه.
در Enterprise، قبل از اینکه بپرسیم:
«کدوم LLM رو انتخاب کنیم؟»
شاید باید بپرسیم:
این «Agent رو تا کجا وارد سیستم کنیم و مرز اختیارش کجاست؟»
مقاله‌ای که این بحث رو ازش شروع کردم:
AI-Native Software Engineering: Architecture Patterns for Context, Agents and Developer Tools
اگر شما هم درگیر معماری AI در محیط‌های Enterprise یا On-Prem هستید، به نظرم این بخش از بحث، خیلی مهم‌تر از انتخاب صرف Model هستش.
پ.ن: لینک مقاله:
https://www.linkedin.com/pulse/ai-native-software-engineering-architecture-patterns-context-r-e6hoc/
@DevTwitter | <Mehdi Halvaei/>