سیگنال پیکره
الگویی مکرر در آزمایش‌های معاملات عاملی این است که عاملی که موجودی نقدی و فید بازار دریافت می‌کند، صرفاً چند سفارش سنجیده ثبت نمی‌کند. بلکه دچار آشفتگی می‌شود. می‌خرد، می‌فروشد، دوباره می‌خرد، و گزارش معاملات پر می‌شود از رفت‌وبرگشت‌هایی که هیچ استراتژی اعلام‌شده‌ای آن‌ها را توضیح نمی‌دهد. وسوسه‌کننده است که این را شکست استراتژی تعبیر کنیم — سیگنال‌های بد، ریسک‌پذیری ضعیف، پرامپت بیش‌ازحد مشتاق. این تعبیر سیگنال مفیدتر را از دست می‌دهد. شکست جالب ساختاری است: هیچ مرز تسویه‌ای بین قصد عامل و وضعیتی که بر اساس آن اقدام بعدی را انجام می‌دهد وجود ندارد.
در یک سیستم معاملاتی متعارف، حلقه صریح است. یک سفارش مجاز می‌شود، ارسال می‌شود، تأیید می‌شود، پر می‌شود و سپس تسویه می‌گردد. هر مرحله بازنمایی خود را دارد، و موقعیتی که استراتژی می‌بیند یک نمای تطبیق‌شده است، نه سفارشی که امید داشت ثبت کند. عاملی که بدون آن مرز عمل می‌کند، مراحل را فرو می‌ریزد. یک اقدام مجاز را به‌عنوان اقدام اجراشده می‌پندارد، و یک اقدام اجراشده را به‌عنوان موقعیت تسویه‌شده. نتیجه، رفت‌وبرگشت‌های مکرر است زیرا عامل هرگز نمی‌آموزد که واقعاً چه اتفاقی افتاده است.
مجاز با اجراشده یکی نیست
مجوز و نتیجه دو چیز متفاوتند، و چارچوب‌های عاملی به‌طور معمول آن‌ها را یکی می‌گیرند. یک عامل می‌تواند اختیار معتبری برای معامله داشته باشد و همچنان بر اساس وضعیت کهنه عمل کند. اختیار می‌گوید چه کاری می‌تواند انجام دهد؛ درباره آنچه جهان اکنون در بر دارد چیزی نمی‌گوید. وقتی این دو از هم جدا نشوند، تصمیم بعدی عامل بر پایه یک فرض بنا می‌شود نه یک واقعیت.
سه شیء متمایزی را در نظر بگیرید که یک حلقه معاملاتی باید از هم جدا نگه دارد:
- سفارش — دستوری که عامل اختیار صدور آن را دارد.
- پر شدن — اجرای جزئی یا کامل آن سفارش توسط بازار.
- موقعیت ثبت‌شده — دارایی تطبیق‌شده و تسویه‌شده پس از تسویه.
سفارش، پر شدن نیست. پر شدن، موقعیت نیست. موقعیت، موجودی قابل خرج مجدد نیست. هر گذار می‌تواند شکست بخورد، ناقص کامل شود، یا خارج از ترتیب برسد. عاملی که قصد خود را بازخوانی می‌کند گویی وضعیت است، دستورات را علیه موقعیتی که وجود ندارد دوباره صادر می‌کند، یا علیه نقدی که قبلاً تعهد شده است.
رفت‌وبرگشت‌های مکرر نشانه آشکار تطبیق ناقص است. اگر عامل نتواند آنچه را که دارد بازخوانی کند، نمی‌تواند بداند آیا اقدام قبلی‌اش انجام شده است. پس دوباره اقدام می‌کند. و باز هم. این آشفتگی یک استراتژی نیست؛ شکاف تطبیقی است که به‌صورت فعالیت معاملاتی بیان می‌شود. همین پویایی هر زمان که به عاملی قابلیتی بدون مسیر بازخوانی متناظر داده شود ظاهر می‌شود.
لایه تسویه چه چیزی باید حمل کند
لایه تسویه برای عامل‌ها یک جدول پایگاه داده که در انتها پیچ شده باشد نیست. این مؤلفه‌ای است که قصد و وضعیت را تطبیق می‌دهد. سه ویژگی بیشترین وزن را حمل می‌کنند.
کلیدهای idempotency برای هر اقدام موردنظر، نه برای هر درخواست
بیشتر پیاده‌سازی‌های idempotency بر درخواست HTTP کلید می‌زنند. این واحد اشتباهی برای یک عامل است. یک عامل ممکن است درخواست را دوباره تلاش کند، پرامپت را بازنویسی کند، یا زیرعاملی ایجاد کند که همان اقدام منطقی را از مسیر دیگری صادر می‌کند. اگر کلید از درخواست مشتق شود، همان قصد می‌تواند اثرات متعددی تولید کند. کلید باید از اقدام موردنظر مشتق شود — یک شناسه پایدار که عامل قبل از اقدام به آن متعهد می‌شود، و در هر تلاش مجدد و هر انتقال دوباره استفاده می‌کند.
intent_id = hash(agent_id, action_type, target, quantity, window)
عامل intent_id را یک‌بار تولید می‌کند، ثبت می‌کند، و به هر تلاش پیوست می‌کند. لایه تسویه اولین اثر برای آن کلید را می‌پذیرد و بقیه را رد یا حذف تکراری می‌کند. این همان چیزی است که یک عامل حداقل یک‌بار را به اثر دقیقاً یک‌بار تبدیل می‌کند بدون اینکه از مدل بخواهد قابل اعتماد باشد.
مسیر بازگشت با همان اختیار مسیر رفت
اگر عاملی بتواند اقدامی را متعهد شود اما نتواند آن را به‌طور تمیز برگرداند، هر اشتباه دائمی می‌شود و هر عدم قطعیت دلیلی برای اقدام مجدد می‌شود. بازگشت باید یک عملیات درجه‌یک با همان اختیار، همان رد حسابرسی، و همان انضباط idempotency به‌عنوان اقدام رفت باشد. یک اقدام جبرانی یک مدیریت‌کننده استثنا نیست؛ بخشی از رابط عادی است. بدون آن، عامل‌ها یا منجمد می‌شوند یا بیش‌ازحد معامله می‌کنند، زیرا تنها راه تصحیح یک خطای مشکوک صدور اقدام رفت دیگری است.
media/server-rack-closeup-79da28-73e14b.jpg)
تطبیق معمولاً یک کار دسته‌ای پایین‌دستی است: فرآیندی شبانه که سوابق داخلی را با بازار مقایسه می‌کند. برای یک عامل، این بسیار کند و بسیار دور از تصمیم است. تطبیق باید به‌عنوان ابزاری که عامل می‌تواند قبل از اقدام مجدد فراخوانی کند افشا شود. ابزار به یک پرسش محدود پاسخ می‌دهد: وضعیت تسویه‌شده من در این لحظه چیست، و کدام یک از قصدهای من هنوز حل نشده است؟ عاملی که می‌تواند این را بپرسد از حدس زدن دست می‌کشد. عاملی که نمی‌تواند، بر اساس وضعیت کهنه به اقدام ادامه می‌دهد.
تعمیم فراتر از مالی
ساختار مختص معامله نیست. هر حوزه‌ای با یک مرحله تسویه همین شکل را دارد، و همان حالت شکست را وقتی به عامل مجوز بدون مسیر بازخوانی داده شود.
- تسویه حساب. عاملی پرداختی را مجاز می‌کند، پردازشگر پرداخت آن را ضبط می‌کند، و وضعیت سفارش به‌صورت ناهمگام تسویه می‌شود. عاملی که پرداخت مجاز را به‌عنوان سفارش تکمیل‌شده می‌پندارد، تسویه حساب را دوباره تلاش می‌کند، دوبار شارژ می‌کند، یا موجودی‌ای را وعده می‌دهد که در اختیار ندارد. کلید idempotency به قصد خرید تعلق دارد، نه به فراخوانی API.
- رزرو. یک رزرو درخواست می‌شود، تأیید می‌شود، و سپس در برابر ظرفیتی که می‌تواند آزاد شود نگه داشته می‌شود. عاملی که تأیید را به‌عنوان رزرو تسویه‌شده می‌خواند، وقتی نگه‌داشت منقضی شود بیش‌ازحد رزرو می‌کند، زیرا هرگز آن دو را تطبیق نداده است.
- تأمین. یک منبع درخواست می‌شود، ایجاد می‌شود، و سپس پس از تأخیری در دسترس قرار می‌گیرد. عاملی که بر اساس درخواست عمل می‌کند گویی منبع در حال اجراست، اقدامات وابسته را علیه چیزی که هنوز وجود ندارد صادر می‌کند.
در هر مورد راه‌حل یکسان است: عامل باید قبل از اقدام مجدد وضعیت را بازخوانی کند، و سیستم باید بر اساس قصد حذف تکراری کند نه بر اساس درخواست. حوزه واژگان را تغییر می‌دهد، نه مکانیزم را.
معاوضه صادقانه
یک مرز تسویه هزینه‌هایی از نظر تأخیر و پیچیدگی دارد. بازخوانی وضعیت قبل از اقدام به هر تصمیم یک رفت‌وبرگشت اضافه می‌کند، و نگهداری کلیدهای قصد، مسیرهای بازگشت، و ابزارهای تطبیق کار مهندسی واقعی است که یک حلقه عامل ساده‌لوحانه از آن اجتناب می‌کند. وسوسه‌ای برای نادیده گرفتن آن در حوزه‌های عمدتاً خواندنی یا کم‌ریسک وجود دارد، جایی که هزینه یک اقدام تکراری کم است.
این معاوضه مشروع است، اما باید به‌صراحت انجام شود نه با حذف. حالت شکست نادیده گرفتن آن یک عامل کند نیست؛ عاملی است که نمی‌تواند بگوید چه کرده است. در معامله این به‌صورت آشفتگی ظاهر می‌شود. در تسویه حساب به‌صورت شارژهای تکراری ظاهر می‌شود. در تأمین به‌صورت منابع یتیم ظاهر می‌شود. لایه تسویه همان چیزی است که به یک عامل اجازه می‌دهد با اختیار عمل کند و همچنان تفاوت بین آنچه خواسته و آنچه درست است را بداند.
یک قاعده طراحی
اگر عاملی می‌تواند اقدامی انجام دهد که مرحله تسویه دارد، به سه چیز نیاز دارد: هویتی پایدار برای قصد، مسیری برای بازگشت با اختیار برابر، و ابزاری که وضعیت تسویه‌شده را بازخوانی کند. مجوز به‌تنهایی کافی نیست. سیگنال پیکره از معاملات عاملی این نیست که عامل‌ها بد معامله می‌کنند؛ این است که وقتی هیچ مرزی قصد آن‌ها را از جهان جدا نمی‌کند، مکرراً معامله می‌کنند. مرز را بسازید، و آشفتگی از یک نشانه به یک تصمیم تبدیل می‌شود.