‏هماهنگی عامل‌های هوش مصنوعی با Amazon S3 Files

شرکت‌ها دارن از هوش مصنوعی تک‌مدلی به سمت معماری‌های چندعامل حرکت می‌کنن، جایی که هر عامل یه بخش از کار رو انجام می‌ده. تو این معماری‌ها، عامل‌ها به‌جای اینکه همه‌چیزو تو prompt نگه دارن، نتیجه‌ی میانی‌شونو تو فایل می‌نویسن؛ چون یه prompt بزرگ هم هزینه رو بالا می‌بره هم کیفیت جواب مدل رو پایین میاره. آمازون از Amazon S3 Files حرف می‌زنه: یه سیستم فایل با سازگاری POSIX روی داده‌های S3، که چند عامل روی سرویس‌های مختلف هم‌زمان بهش وصل می‌شن و از طریق پوشه‌های مشترک هماهنگ می‌شن.

برای نشون‌دادن این ایده، یه خط تولید پنج‌مرحله‌ای پردازش سند طراحی کردن: یه عامل روی EC2 اسناد ورودی رو دسته‌بندی می‌کنه، یه عامل روی Lambda ریسک رو می‌سنجه، یه عامل روی EKS انطباق رو چک می‌کنه، یه عامل روی ECS/Fargate گزارش می‌سازه، و یه عامل روی Bedrock AgentCore خلاصه‌ی نهایی رو می‌نویسه. هر عامل از یه پوشه (intake/، analyzed/، validated/، reports/، summaries/) می‌خونه و تو پوشه بعدی می‌نویسه. کد هر عامل تقریباً یکسانه، فقط prompt سیستم و مسیر پوشه فرق می‌کنه:

with open('/mnt/s3files/intake/doc-abc.json') as f:
    doc = json.load(f)
result = agent(f"Analyze this document for risks: {doc['content']}")
with open('/mnt/s3files/analyzed/analysis-abc.json', 'w') as f:
    json.dump(result, f)

خط تولید با آپلود یه فرم مشتری تو S3 شروع می‌شه که یه پیام SQS رو فعال می‌کنه و عامل EC2 اونو می‌گیره. از اونجا به بعد، هماهنگی فقط از طریق سیستم فایله: سرویس‌هایی مثل EKS و ECS هر ۱۰ تا ۱۵ ثانیه پوشه رو چک می‌کنن، ولی Lambda و AgentCore هر یک دقیقه با EventBridge صدا زده می‌شن. یه فایل به محض بسته‌شدن (close) بلافاصله برای بقیه عامل‌ها قابل‌دیدنه، هرچند حدود یه دقیقه طول می‌کشه تا به‌عنوان یه آبجکت تو باکت S3 هم ظاهر بشه.

چون هر عامل مرتب پوشه ورودیشو لیست می‌کنه، باید بفهمه کدوم فایل‌ها رو قبلاً پردازش کرده. راه‌حل هرکدوم فرق می‌کنه: عامل EKS با ساخت یه فایل نشانه (marker) به‌صورت atomic مطمئن می‌شه هر سند فقط یه بار پردازش بشه؛ عامل ECS وضعیت پردازش‌شده‌هارو تو یه فایل روی همون مانت ذخیره می‌کنه؛ بقیه فقط چک می‌کنن آیا فایل خروجی موردنظر از قبل وجود داره یا نه.

نویسنده چندتا نکته عملی هم اضافه می‌کنه: مجوزهای IAM باید هم برای mount کردن (s3files:ClientMount, s3files:ClientWrite) و هم برای خوندن داده خام (s3:GetObject) تنظیم بشن، وگرنه خطاهایی می‌گیری که تشخیصش سخته. EC2 و EKS مستقیم و بدون access point مانت می‌شن و به‌عنوان root اجرا می‌شن، ولی Lambda، ECS Fargate و AgentCore از یه access point مشترک با شناسه یکسان (UID/GID ۱۰۰۰) استفاده می‌کنن. نتیجه اینه که کل وضعیت pipeline رو می‌شه فقط با یه دستور ls روی مسیر مانت‌شده دید.

نکات کلیدی:

• Amazon S3 Files یه سیستم فایل با سازگاری POSIX روی S3 هست که EC2، Lambda، EKS، ECS/Fargate و Bedrock AgentCore می‌تونن باهاش مانت بشن.
• خط تولید نمونه پنج مرحله داره: دسته‌بندی (EC2)، ریسک‌سنجی (Lambda)، انطباق (EKS)، گزارش‌سازی (ECS) و خلاصه اجرایی (AgentCore).
• همه‌ی عامل‌ها از Strands SDK و مدل‌های Bedrock استفاده می‌کنن و از طریق پوشه‌های intake تا summaries هماهنگ می‌شن.
• یه فایل بلافاصله بعد از بسته‌شدن برای بقیه عامل‌ها قابل‌دیدنه، ولی حدود یه دقیقه طول می‌کشه تا تو باکت S3 هم به‌شکل آبجکت دربیاد.
• مجوزهای IAM باید هم‌زمان شامل s3files:ClientMount/s3files:ClientWrite و s3:GetObject باشن، وگرنه خطای مانت پیش میاد.