n8n agent-এ অনুমোদন বসান—Approve না হলে tool চলবে না

|লেখক: QUASA সম্পাদকীয় দল|5 মিনিটের পাঠ| 1
n8n agent-এ অনুমোদন বসান—Approve না হলে tool চলবে না

n8n AI Agent-এর ঝুঁকিপূর্ণ টুল কল মানুষের অনুমোদন ছাড়া আটকাতে এজেন্ট ও সংশ্লিষ্ট টুলের মাঝখানে Human Review বসান। n8n-এর Human Review নির্দেশনা অনুযায়ী, অনুমোদন পেলে টুলটি এজেন্ট নির্ধারিত ইনপুটে চলে; প্রত্যাখ্যান করলে সেই কল বাতিল হয়। তাই অনুমোদন চাওয়ার নির্দেশ শুধু এজেন্টকে লিখে দিলেই হবে না, টুলের সংযোগেই বাধাটি রাখতে হবে।

তথ্য খোঁজার মতো কম ঝুঁকির টুল সরাসরি চালানো যেতে পারে। ইমেইল পাঠানো, রেকর্ড মোছা বা অর্থসংক্রান্ত কাজের টুল রাখুন পর্যালোচনার পেছনে। পর্যালোচককে কাজের প্রকৃত লক্ষ্য ও প্যারামিটার দেখাতে হবে; নির্ধারিত সময়ের মধ্যে উত্তর না এলে অনুমোদিত শাখায় যাওয়ার পথও বন্ধ রাখতে হবে।

পড়া ও পরিবর্তনের টুল আলাদা করুন

প্রথমে এজেন্টের নাগালে থাকা টুলগুলোর কাজ লিখে নিন। যে টুল শুধু তথ্য পড়ে বা খোঁজে, সেটি সরাসরি সংযোগের প্রার্থী। যে টুল বাইরের কাউকে বার্তা পাঠায়, তথ্য বদলায়, মুছে দেয় বা অর্থের লেনদেন শুরু করে, সেটি অনুমোদনের প্রার্থী। একই সেবায় তথ্য পড়া ও রেকর্ড বদলানোর কাজ থাকলে আলাদা টুল ব্যবহার করুন, যাতে একটি অনুমোদন দুই ধরনের ক্ষমতার জন্য প্রযোজ্য হয়ে না যায়।

ঝুঁকির সীমা কাজের প্রভাব দিয়ে ঠিক করুন। কোনো অভ্যন্তরীণ খসড়া তৈরি আর গ্রাহকের কাছে সেই লেখা পাঠানো একই সিদ্ধান্ত নয়; তথ্য দেখা আর স্থায়ীভাবে মুছে দেওয়াও এক নয়। কোন কাজের আগে মানুষের সিদ্ধান্ত প্রয়োজন, তা নির্ধারণে ঝুঁকি অনুযায়ী অনুমোদনের সীমা কাজে লাগতে পারে।

প্রতিটি ঝুঁকিপূর্ণ কাজের সব কার্যকর পথ খুঁজে দেখুন। অনুমোদনের পেছনে একটি ইমেইল টুল রেখে এজেন্টের সঙ্গে আরেকটি পাঠানোর টুল সরাসরি যুক্ত থাকলে বাধাটি সেই দ্বিতীয় পথে কাজ করবে না। একইভাবে অন্য কর্মপ্রবাহ বা সাব-এজেন্টের মাধ্যমে সংবেদনশীল কাজ চালানো গেলে সেখানেও সংযোগের অবস্থান যাচাই করতে হবে।

আমদানিযোগ্য নমুনা থেকে সংযোগ তৈরি করুন

n8n-এর আমদানিযোগ্য Exercise 2 নমুনায় এজেন্টের চুক্তি পাঠানোর টুলের আগে মানুষের অনুমোদন রাখা হয়েছে। নমুনাটিতে সিদ্ধান্ত চ্যাটে নেওয়া হয় এবং পর্যালোচক সম্মতি দেওয়ার পরেই পাঠানোর কাজ চলে। এটিকে নিজের ইনস্ট্যান্সে এনে সংযোগের ধরন বুঝতে পারেন; ব্যবহারের আগে নিজের ক্রেডেনশিয়াল, অনুমোদন চ্যানেল ও কাজের টুল কনফিগার করতে হবে।

  1. AI Agent-এর Tools সংযোগ খুলে Human review ধাপ যোগ করুন। ইমেইল পাঠানো, রেকর্ড মোছা বা অর্থসংক্রান্ত কাজের টুল ওই ধাপের টুল সংযোগে রাখুন; শুধু তথ্য খোঁজার টুল প্রয়োজন অনুযায়ী সরাসরি এজেন্টে যুক্ত রাখুন।
  2. পর্যালোচনার চ্যানেল হিসেবে Slack বা Microsoft Teams বেছে নিন। সংশ্লিষ্ট ক্রেডেনশিয়াল দিয়ে অনুরোধ কোন ব্যক্তি, চ্যাট বা চ্যানেলে যাবে, তা ঠিক করুন; নমুনার চ্যাট সেটিং নিজের দলের চ্যানেল হিসেবে ধরে নেবেন না।
  3. টুলের নাম কাজ বুঝিয়ে রাখুন এবং এজেন্টের নির্দেশনায় কোন টুলে অনুমোদন লাগে তা লিখুন। প্রত্যাখ্যানের পরে ব্যবহারকারীকে কী জানাবে, সেটিও উল্লেখ করুন; টুলের মাঝখানে থাকা বাধাটিই কাজ থামাবে।

সংযোগ তৈরি হয়ে গেলে এজেন্টের সম্ভাব্য কাজের তালিকা আবার দেখুন। ‘ইমেইল পাঠানো’ নামে টুলটির পাশাপাশি একই ফল আনে এমন সাধারণ এপিআই কল যুক্ত থাকলে সেটিও পর্যালোচনার আওতায় আনতে হবে। অনুমোদন কোনো টুলের নামের ওপর নয়, নির্দিষ্ট কার্যকর পথের ওপর বসে।

পর্যালোচনায় কার্যকর মান দেখান

শুধু ‘ইমেইল পাঠাতে চায়’ ধরনের বার্তা দিয়ে সম্মতি চাইবেন না। ইমেইলে প্রাপক, বিষয় ও লেখা; রেকর্ড মোছায় রেকর্ডের শনাক্তকারী; অর্থসংক্রান্ত কাজে প্রাপক, পরিমাণ ও মুদ্রা দেখান। এগুলো শর্তসাপেক্ষ উদাহরণ: নিজের টুল যে মান ব্যবহার করবে, সিদ্ধান্তের বার্তায় সেই মানগুলোই থাকতে হবে। তাতে পর্যালোচক কাজটির ধরন যেমন বোঝেন, তেমনি ভুল ঠিকানা, রেকর্ড বা পরিমাণও ধরতে পারেন।

Human Review বার্তায় {{ $tool.name }} দিয়ে টুলের নাম এবং {{ JSON.stringify($tool.parameters, null, 2) }} দিয়ে এজেন্ট পাঠানো প্যারামিটার দেখানো যায়। তবে এই প্যারামিটারে টুলের ইনপুট স্কিমায় এজেন্টের জন্য নির্ধারিত মান থাকে। টুল নোডে আগে থেকে স্থির করা প্রাপক, অ্যাকাউন্ট বা অন্য সেটিং স্বয়ংক্রিয়ভাবে ওই তালিকায় আছে ধরে নেবেন না। সিদ্ধান্তে প্রয়োজন হলে স্থির মানগুলোও বার্তায় আলাদা করে দেখান।

ধরা যাক, এজেন্ট ইমেইলের লেখা তৈরি করেছে, কিন্তু পাঠানোর টুলে প্রাপকের ঠিকানা আগে থেকে বসানো আছে। শুধু এজেন্টের খসড়া দেখলে পর্যালোচক আসল প্রাপককে অনুমোদন দিতে পারবেন না। তাই বার্তায় দেখা মানের সঙ্গে টুলে কার্যকর মান মিলিয়ে নিন। গোপন ক্রেডেনশিয়াল প্রকাশ না করেও কাজের লক্ষ্য, বিষয়বস্তু ও প্রভাব দেখানো সম্ভব।

প্রত্যাখ্যান ও সময়সীমার ফল আলাদা রাখুন

Human Review-তে অনুমোদন ও প্রত্যাখ্যানের ফল স্পষ্ট: প্রথমটিতে নির্বাচিত টুল চলে, দ্বিতীয়টিতে কল বাতিল হয়। নির্ধারিত সময়ের মধ্যে কেউ উত্তর না দিলে কী হবে, তার জন্য আলাদা পথ সাজাতে হয়। n8n-এর Human Oversight playbook Slack ও Microsoft Teams-এ ‘Send and Wait for Response’, অপেক্ষার সীমা এবং অনুমোদন, প্রত্যাখ্যান ও উত্তর না আসার পৃথক শাখার নকশা দেখায়।

এই তিন শাখা নিয়ন্ত্রণ করতে চাইলে এজেন্টকে প্রথমে প্রস্তাবিত কাজ ও তার প্যারামিটার তৈরি করতে দিন। ঝুঁকিপূর্ণ পাঠানো বা মোছার টুল এজেন্টের সঙ্গে সরাসরি যুক্ত করবেন না। প্রস্তাবটি Slack বা Teams-এর অপেক্ষার ধাপে পাঠান; তারপর Switch ধাপে প্রথমে জবাব আছে কি না দেখুন। জবাব থাকলে কেবল স্পষ্ট অনুমোদনকে কাজ চালানোর শাখায় পাঠান, প্রত্যাখ্যানকে বাতিলের শাখায় পাঠান। জবাব না থাকলে অনুরোধ বন্ধ রাখুন অথবা অন্য পর্যালোচকের কাছে নতুন অনুরোধ পাঠান।

আসল ইমেইল পাঠানো, রেকর্ড মোছা বা অর্থসংক্রান্ত নোডটি কেবল অনুমোদিত শাখায় রাখুন। অপেক্ষার সীমা পেরিয়ে কর্মপ্রবাহ আবার চললেও জবাবের তথ্য অনুপস্থিত থাকলে ওই নোডে যাওয়ার পথ থাকবে না। পরে কাজটি প্রয়োজন হলে নতুন অনুরোধ তৈরি করে বর্তমান প্যারামিটার আবার দেখান; মেয়াদ পেরোনো পুরোনো সিদ্ধান্তকে সম্মতি হিসেবে ব্যবহার করবেন না।

সিদ্ধান্তের প্রমাণ সংরক্ষণ করুন

অনুমোদনের সঙ্গে কোন কাজের কোন মান দেখানো হয়েছিল, তা সংরক্ষণ করুন। প্রতিটি অনুরোধের জন্য চালনার শনাক্তকারী, টুলের নাম, পর্যালোচককে দেখানো প্যারামিটার, সিদ্ধান্ত, সিদ্ধান্তের সময় এবং পরিচয় পাওয়া গেলে সিদ্ধান্তদাতার পরিচয় রাখুন। Slack বা Teams-এর জবাব থেকে সেই পরিচয় নিজের কনফিগারেশনে পাওয়া যাচ্ছে কি না দেখুন; ভাগ করা চ্যানেলে অনুরোধ পৌঁছানো নির্দিষ্ট ব্যক্তির সম্মতির প্রমাণ নয়।

চালুর আগে শর্তসাপেক্ষ পরীক্ষায় অনুমোদন, প্রত্যাখ্যান ও উত্তর না আসার ফল আলাদা করে চালিয়ে দেখুন। অনুমোদনে নির্ধারিত কাজ চলবে; অন্য দুই ফলে সংবেদনশীল নোডে পৌঁছানো যাবে না। সংরক্ষিত প্যারামিটার ও সিদ্ধান্তের সঙ্গে প্রতিটি চালনার ফল মিললে ভুল টুল কল অনুসন্ধান এবং অনুমোদনের নিয়ম সংশোধন করা সহজ হবে।

আরও পড়ুন:

শেয়ার করুন:

আমাদের নিউজলেটার নিন

সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।

0