داگوود - Dogwood: زبان متنباز AWS برای کنترل agent هایی که «حافظه» دارن ولی checkpoint هاشون ندارن
حدود ۵ دقیقه مطالعه
یه سناریوی هشداردهنده رو تصور کن: یه agent رو مسئول پردازش خودکار پرداخت به vendor ها کردی. یه روز یه فاکتور میرسه، agent هم تراکنش رو خودکار انجام میده. همهچیز عالی پیش میره تا صبحی که میبینی حساب بانکیت overdraft شده؛ وقتی دقیقتر نگاه میکنی، میبینی به vendor هایی پرداخت شده که اصلاً فاکتوری ثبت نکرده بودن، یا بعضی وقتها اصلاً چیزی تحویل نداده بودن. AWS ششم آگوست، Dogwood رو دقیقاً برای جلوگیری از همین نوع خطا منتشر کرد؛ یه زبان متنباز برای نوشتن قوانین authorization که میتونن به تاریخچهی کارهای قبلی agent هم توجه کنن.
مشکلی که Dogwood حلش میکنه
مشکل اصلی، به قول Marc Brooker (نایبرئیس و مهندس برجستهی AWS)، یه ناهماهنگی بنیادیه: agent ها همهی کارهایی که تا الان انجام دادن رو به یاد میسپارن، ولی checkpoint ای که هر اقدام جدید رو تأیید میکنه، هیچی از قبل به یاد نداره. هر تصمیم authorization فقط بر اساس همون یه درخواست لحظهای گرفته میشه، بدون در نظر گرفتن اینکه قبلش چه اتفاقی افتاده.
قوانینی مثل «قبل از پرداخت، حتماً باید فاکتور ثبت شده باشه»، «سقف مصرف روزانهی agent فلان مبلغه»، یا «قبل از این مرحلهی مهم، حتماً باید یه انسان تأیید کنه»، رو کاغذ ساده به نظر میرسن، ولی طبق گفتهی Brooker، تو زبانهای authorization موجود، تمیز و دقیق قابلبیان نیستن؛ چون این زبانها اصولاً stateless طراحی شدن.
رابطهش با Cedar
AWS از قبل یه زبان authorization به اسم Cedar داره که سال ۲۰۲۳ متنبازش کرد؛ زبانی که طبق توصیف خود Brooker «قابلتحلیل» طراحی شده، یعنی میشه قبل از اجرا، دقیقاً اثبات کرد که یه مجموعه قانون چه چیزی رو مجاز میکنه و چه چیزی رو نه. Cedar تصمیمات point-in-time رو خیلی خوب مدیریت میکنه؛ هر درخواست بر اساس شایستگیهای خودش، سریع و با قابلیت اثبات، بررسی میشه.
Dogwood این زبان رو گسترش میده، نه جایگزینش میکنه؛ کاملاً backward-compatible با Cedار است و نیازی به migration نداره. چیزی که Dogwood اضافه میکنه، شرطهای زمانی (temporal) است: الگوهایی مثل ترتیب workflow، دروازهی تأیید انسانی، تطبیق آرگومانها، چک کردن تازگی داده، و محدودیت جمعی رو چند تا درخواست همزمان.
پایهی نظری: Metric First-Order Temporal Logic
از نظر فنی، Dogwood رو یه فرمالیسم از رشتهی runtime verification به اسم MFOTL (Metric First-Order Temporal Logic) ساخته شده. عملگرهایی که به Cedar اضافه میکنه شامل چیزهایی مثل formerly (چیزی قبلاً اتفاق افتاده؟)، count_within (چند بار تو یه بازهی زمانی؟)، count_distinct_within، و sum_within (مجموع یه مقدار تو یه بازه) هستن؛ دقیقاً همون عملگرهایی که برای بیان قوانین بالا لازمه.
ادغام با Amazon Bedrock AgentCore
Dogwood مستقیم پشت یه قابلیت جدید تو AgentCore Policy قرار گرفته؛ لایهای تو Amazon Bedrock AgentCore که مستقل از خود مدل عمل میکنه: مدل یه tool call رو پیشنهاد میده، policy engine قبولش میکنه یا ردش میکنه، و خود مدل هیچوقت مستقیم درگیر اجرای enforcement نمیشه. تا قبل از این، این چکها کاملاً stateless بودن؛ حالا با «temporal policies» که Dogwood قدرتش رو میده، این تصمیمات میتونن به تاریخچهی سشن agent هم نگاه کنن.
AWS همچنین یه ابزار به اسم Policy Authoring هم معرفی کرده که با هوش مصنوعی، سند policy نوشتهشده به زبون طبیعی رو مستقیم به قوانین Dogwood درست تبدیل میکنه؛ یعنی لازم نیست حتماً خودت سینتکس Dogwood رو یاد بگیری تا بتونی قوانین سازمانیت رو پیاده کنی.
چطور همین الان امتحانش کنیم
Dogwood زیر لایسنس Apache 2.0 منتشر شده و شامل یه راهنمای زبان و یه پیادهسازی مرجع (reference interpreter) روی گیتهابه. برای شروع:
git clone https://github.com/cedar-policy/dogwood
یه نمونهی خیلی ساده از یه قانون Dogwood که همون سناریوی پرداخت اول مقاله رو حل میکنه، تقریباً اینطور به نظر میرسه (بر پایهی گسترش Cedar):
permit (
principal,
action == Action::"processPayment",
resource
)
when {
formerly(action == Action::"invoiceReceived" && resource == context.resource)
&& sum_within(1.day, context.amount) <= 5000
};
یعنی پرداخت فقط زمانی مجازه که قبلش یه فاکتور برای همون resource ثبت شده باشه، و مجموع پرداختهای همون روز از یه سقف مشخص بیشتر نشه.
اگه از قبل رو Amazon Bedrock AgentCore کار میکنی، AgentCore Policy همین الان از Dogwood پشتیبانی میکنه و میتونی مستقیم ازش استفاده کنی. اگه رو یه استک دیگه کار میکنی، میتونی پیادهسازی مرجع رو مستقیم از گیتهاب بگیری و باهاش آزمایش کنی.
نکتهی مهم: هنوز برای production آماده نیست
خود AWS صراحتاً اعلام کرده که پیادهسازی مرجع Dogwood برای اکتشاف و تست طراحی شده، نه استفادهی production. اگه بخوای این رو تو یه محیط واقعی اجرا کنی، باید خودت چیزهایی مثل نگهداری قابلاعتماد تاریخچهی رویدادها، ایزولهسازی بین tenant های مختلف، و سیاست نگهداری داده رو پیادهسازی کنی؛ اینها جزو خود زبان یا reference interpreter نیستن.
چرا این موضوع مهمه
با گسترش استفاده از agent های خودمختار برای کارهای حساس (پرداخت، دسترسی به دادهی حساس، تغییرات زیرساختی)، مشکلی که Dogwood حلش میکنه دقیقاً همون چیزیه که این روزها تو خیلی از تیمهای مهندسی مطرحه: چطور میشه به یه agent اجازه داد کار واقعی انجام بده، بدون اینکه مجبور بشیم به کل هیستوری رفتارش اعتماد کورکورانه داشته باشیم؟ Dogwood با اضافه کردن حافظه به لایهی authorization (بدون از دست دادن قابلیتهای اثباتپذیر Cedar)، یه جواب مشخص و متنباز به این سؤال میده؛ و چون AWS از جامعه دعوت کرده که Dogwood رو تو محصولات و پروژههای خودشون هم بسازن، این رویکرد میتونه فراتر از خود AWS هم به یه استاندارد غیررسمی تبدیل بشه.
