একজন ব্যবহারকারী তাদের সম্পাদকে এজেন্ট-নেতৃত্বাধীন মূল্যায়ন প্রম্পট পেস্ট করে। এজেন্ট [নিওটোমা ইভালুয়েশন পেজ](https://neotoma.io/evaluate) পড়ে, স্থানীয় ওয়ার্কফ্লো স্ক্যান করে, ঠিক করে যে ফিটটি শক্তিশালী, ইনস্টল চালায় এবং প্রথম কয়েকটি সত্তা সংরক্ষণ করে। কিছু সময় পরে এটি একটি বাস্তব বাগ আঘাত করে — একটি সত্তা জমা নিঃশব্দে একটি ক্ষেত্র ফেলে দেয় যা স্কিমা স্পষ্টভাবে গ্রহণ করে। একটু পরে এটি অন্য কিছু লক্ষ্য করে: একটি বড় সত্তা গ্রাফের উপর পুনরুদ্ধার এটি যে কার্যপ্রবাহ সমর্থন করছে তার চেয়ে ধীর। এবং পরেও, একটি কাস্টম পুনরুদ্ধার লুপ তৈরি করার সময়, এটি বুঝতে পারে যে MCP পৃষ্ঠে একটি ব্যাচ অপারেশন অনুপস্থিত রয়েছে যা প্যাটার্নটিকে আরও পরিষ্কার করে তুলবে। ব্যবহারকারী কখনও এই সম্পর্কে জিজ্ঞাসা করেননি। এজেন্ট অন্য কিছু করার পথে এটি লক্ষ্য করে।

সেই মুহূর্তগুলির পুরানো আকৃতি লুপের শেষ ছিল। ব্যবহারকারী গিটহাব খুলতে পারে, ত্রুটি বা অনুরোধ পেস্ট করতে পারে, প্রসঙ্গের একটি অনুচ্ছেদ লিখতে পারে এবং অপেক্ষা করতে পারে। অধিকাংশই না. তারা সমস্যার চারপাশে রুট করে, রক্ষণাবেক্ষণকারী কখনই এটি দেখতে পায় না এবং পরবর্তী ব্যবহারকারী একই দেয়ালে আঘাত করে।

Neotoma এখন একটি প্রথম-শ্রেণির সমস্যা সাবসিস্টেম রয়েছে যা একই MCP পৃষ্ঠের মাধ্যমে কাজ করে যা প্রতিটি এজেন্ট ইতিমধ্যে সংরক্ষণ এবং পুনরুদ্ধার করতে ব্যবহার করে। এজেন্ট বাগ, কর্মক্ষমতা পর্যবেক্ষণ, এবং বর্ধিতকরণ অনুরোধগুলি সেশন ছাড়াই ফাইল করে, এবং প্রতি-ইস্যু জিজ্ঞাসা না করেই। রক্ষণাবেক্ষণকারীর এজেন্টরা তাদের বাছাই করে, ট্রাইএজ করে, প্রায়শই সমাধান করে এবং জাহাজে করে। প্রতিবেদকের এজেন্ট স্ট্যাটাসটি পড়ে এবং ব্যবহারকারীকে বলে যখন কিছু পড়ে। পুরো বিনিময় টুল কল মাধ্যমে ঘটে.

[গ্রাহকের গবেষণা পোস্ট](/posts/customer-research-through-agents) এ এজেন্ট-নেতৃত্বাধীন মূল্যায়ন এই লুপের সামনের অর্ধেক ছিল। ইস্যু সাবসিস্টেম হল পিছনের অর্ধেক। উভয় অর্ধেকই [নার্ভাস সিস্টেম সাবস্ট্রেট](/posts/from-memory-to-nervous-system) এর উপর চলে যা আমি আগে বর্ণনা করেছি, এবং সেই সাবস্ট্রেট কিসের জন্য সমস্যাগুলির সক্ষমতা এখনও সবচেয়ে পরিষ্কার উদাহরণ।

## কেন লুপ এজেন্ট সাইডে বন্ধ করতে হবে

ঘর্ষণ প্রতিক্রিয়ার নীরব ঘাতক। পুরানো মডেল ধরে নিয়েছে ব্যবহারকারী তাদের অভিজ্ঞতাকে একটি পৃথক সিস্টেমে একটি প্রতিবেদনে অনুবাদ করবে: প্রসঙ্গ পরিবর্তন করুন, রেপো খুঁজুন, একটি ইস্যু টেমপ্লেট পার্স করুন, যথেষ্ট পটভূমি লিখুন যা একজন রক্ষণাবেক্ষণকারী কাজ করতে পারে, লগ সংযুক্ত করতে পারে, অপেক্ষা করতে পারে। প্রতিটি পদক্ষেপ হাল ছেড়ে দেওয়ার সুযোগ। অধিকাংশই করে। এবং সেই মডেলটি ব্যবহারকারীর লক্ষ্য করা সমস্যাগুলিকে কভার করে৷ সমস্যাগুলির জন্য এটির কোনও পথ নেই এজেন্ট লক্ষ্য করেছে যে ব্যবহারকারী কখনই সামনে আসেনি।

একজন মূল্যায়নকারীর এজেন্ট সনাক্ত করেছে যে সক্রিয়করণ একটি হাইড্রেশন ত্রুটি তৈরি করেছে যখন তাদের সাবস্ট্রেট কনফিগার একটি ক্লাউডফ্লেয়ার টানেলের পিছনে একটি স্ব-হোস্ট করা উদাহরণ নির্দেশ করে। এজেন্ট একটি সুনির্দিষ্ট সারসংক্ষেপ লিখেছে, যার মধ্যে ব্যর্থ শেষ পয়েন্ট এবং প্রতিক্রিয়া শিরোনাম রয়েছে। ব্যবহারকারী একটি বার্তা হিসাবে আমাকে সারসংক্ষেপ ফরোয়ার্ড. আমি প্রসঙ্গটি পুনর্নির্মাণ করেছি, এটি আমার এজেন্টদের কাছে পাঠিয়েছি, একটি রিলিজ পাঠিয়েছি এবং ব্যবহারকারীকে আবার বার্তা পাঠিয়েছি। ব্যবহারকারী তাদের এজেন্টকে যাচাই করতে বলেছেন। সেই যাচাইকরণে প্রায় নব্বই সেকেন্ড সময় লেগেছিল। মানুষের রিলে পদক্ষেপ কয়েক দিন লেগেছিল.

এজেন্ট এর মূল সারাংশ ভাল ছিল. এটি ছিল পুনর্নির্মাণ-প্রসঙ্গ যা সময় খেয়েছিল। একজন এজেন্ট এবং একজন মানুষের মধ্যে প্রতিটি হ্যান্ডঅফ বিশ্বস্ততা হারায়। একজন মানুষ এবং অন্য এজেন্টের মধ্যে প্রতিটি হ্যান্ডঅফ স্ক্র্যাচ থেকে প্রসঙ্গ পুনর্নির্মাণ করে। রিচ এজেন্ট-রচিত বিশদটি মানব-রচিত গদ্যে সংকুচিত হয়, এবং তারপরে একটি নিম্নধারার এজেন্টকে এটিকে আবার প্রসারিত করতে হয়।

ব্যবহারকারীর এজেন্ট যখন দেয়ালে আঘাত করে — বা ধীরগতি লক্ষ্য করে, বা অনুপস্থিত ক্ষমতা চায় — তখন অনুবাদের ধাপটি বিনামূল্যে। এজেন্টের কাছে ইতিমধ্যেই প্রসঙ্গ রয়েছে: এটি কোন টুলে চলছে, সঠিক MCP কল যা ব্যর্থ হয়েছে বা বিশ্রী মনে হয়েছে, প্রতিক্রিয়া পেলোড, নিওটোমা ইনস্টলের গিট SHA বা অ্যাপ সংস্করণ, সত্তার ধরন জড়িত। এটি একটি টুল কলে একটি সুসংগত প্রতিবেদন রচনা করে। MCP নির্দেশাবলী এজেন্টদেরকে 'submit_issue'-এর মাধ্যমে ফাইল করতে বলে যখন রিপোর্টযোগ্য সমস্যা বা উন্নতির সুযোগ নিশ্চিত করা হয়, প্রতি-ইস্যু জিজ্ঞাসা করা বন্ধ না করে — প্রতি-ইস্যু প্রম্পটে কোনও নতুন তথ্য যোগ করে না এবং ব্যবহারকারী যা কিছু করছেন তাতে বাধা দেয় না। এজেন্ট ফাইল. ব্যবহারকারী এটি সম্পর্কে পরে জানতে পারেন, বা কখনই না, পরিবর্তনটি কখনও পাঠানো হয় কিনা তার উপর নির্ভর করে।

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

লুপের উভয় অর্ধেক একই সাবস্ট্রেটের উপর এজেন্টিক কাজ হিসাবে চলে। ব্যবহারকারীর এজেন্ট জমা দেওয়ার জন্য MCP ব্যবহার করে। রক্ষণাবেক্ষণকারীর এজেন্টরা পড়তে এবং প্রতিক্রিয়া জানাতে MCP ব্যবহার করে। কাউকে ব্রাউজার খুলতে হবে না।

## দাখিল করার সময় এজেন্ট যা করে

MCP পৃষ্ঠটি গণনা করার জন্য যথেষ্ট ছোট। 'submit_issue' টুলটি একটি শিরোনাম, একটি বডি, একটি সত্তার ধরন নেয় যদি সমস্যাটি একটি নির্দিষ্ট ধরনের রেকর্ড এবং একটি রিপোর্টার এনভায়রনমেন্ট ব্লক সম্পর্কে হয় — ব্যবহারকারী যে গিট SHA চালাচ্ছেন বা অ্যাপ সংস্করণ, যখন এজেন্ট উভয়ই বাদ দেয় তখন স্বয়ংক্রিয়ভাবে জনবহুল সার্ভার-সাইড সহ। প্রতিবেদক পরিবেশ যেমন দেখায় তার চেয়ে বেশি ওজন বহন করে; পরবর্তী অধ্যায় কেন আনপ্যাক.

প্রসঙ্গ ছাড়াই রিপোর্ট খুব কমই আসে। একটি বাগ কংক্রিট সত্তাকে উল্লেখ করে: নির্দিষ্ট রেকর্ড যা সংরক্ষণ করতে ব্যর্থ হয়েছে, এর স্কিমা, একটি আপস্ট্রিম পর্যবেক্ষণ। একটি বর্ধিতকরণ অনুরোধ উল্লেখ করে যে কল প্যাটার্নটি এটিকে সহজ করবে, বা সত্তার ধরনটি পুনরুদ্ধার করা আরও দ্রুত করবে৷ `submit_issue` এবং `add_issue_message` একটি `entity_ids_to_link` অ্যারে গ্রহণ করে, এবং সার্ভার একই কলের অংশ হিসেবে পরমাণুভাবে প্রতিটি উল্লেখিত সত্তার সাথে নতুন সমস্যা থেকে `REFERS_TO` সম্পর্ক তৈরি করে। সমস্যাটি ইতিমধ্যেই গ্রাফের সাথে যুক্ত হয়ে গেছে। সমস্যাটি পড়ার ট্রাইজ এজেন্ট সরাসরি ব্যর্থ হওয়া সত্তার কাছে যেতে পারে।

জমাটি একই `scanAndRedact` PII গার্ডের মধ্য দিয়ে প্রবাহিত হয় যা প্রতিটি পাবলিক পৃষ্ঠকে রক্ষা করে। যদি এজেন্ট ঘটনাক্রমে একটি টোকেন বা একটি ইমেল ঠিকানা বডিতে পেস্ট করে, তবে এটি অধ্যবসায়ের আগে সংশোধন করা হয়। MCP নির্দেশাবলীর জন্য এজেন্টদের কলের আগে শিরোনাম এবং বডিতে PII চেকলিস্ট প্রয়োগ করতে হবে, কিন্তু সার্ভার-সাইড গার্ড হল প্রতিরক্ষার আসল লাইন। রিপোর্টার একটি সংখ্যাসূচক সমস্যা শনাক্তকারী এবং একটি সুস্পষ্ট TTL সহ একটি গেস্ট রিড-ব্যাক টোকেন পায়, যে থ্রেডটি তারা সবেমাত্র খুলেছে। সেই টোকেনটি হল প্রতিবার পুনরায় প্রমাণীকরণ না করে কীভাবে রিপোর্টারের এজেন্ট স্ট্যাটাসটি পরে পড়ে।

ব্যবহারকারীর দৃষ্টিকোণ থেকে: একটি টুল কল, ট্র্যাক করার জন্য একটি শনাক্তকারী, এবং সাধারণত কোনও অনুমোদনের প্রম্পট নেই৷ সাবস্ট্রেটের দৃষ্টিকোণ থেকে: একটি কাঠামোগত সত্তা লেখা হয়েছে, একই লেনদেনে সংযুক্ত-সত্তা সম্পর্ক তৈরি করা হয়েছে, একটি উত্স সারি তৈরি করা হয়েছে, একটি অতিথি অনুদান জারি করা হয়েছে এবং লিখিত পাইপলাইন একটি ইভেন্ট নির্গত করেছে৷

## প্রোভেন্যান্স হল আনসাং হিরো

রিপোর্টার পরিবেশের প্রয়োজনীয়তা একটি ছোট বিস্তারিত মত দেখায়. এটা সবচেয়ে গুরুত্বপূর্ণ পরিবর্তন.

ইস্যু সাবসিস্টেম বিদ্যমান থাকার আগে, এটি যে বিল্ডের বিরুদ্ধে রচিত হয়েছিল তার কোনও রেফারেন্স ছাড়াই একটি প্রতিবেদন জমা দেওয়া যেত। এটা একটা কাগজের টিকিটের জন্য ঠিক আছে। এটি একটি স্বয়ংক্রিয় ট্রাইজ লুপের জন্য বিপর্যয়কর। যদি কোনো এজেন্ট কমিট `abc1234` এ একটি বাগ জমা দেয় এবং আমার এজেন্টরা তা কমিট `def5678` এ ঠিক করে, তাহলে ব্যবহারকারীর এজেন্টকে জানতে হবে কোন বিল্ডের বিরুদ্ধে যাচাই করতে হবে। যদি একটি ডিবাগিং থ্রেড তিনটি বিল্ডে বিস্তৃত থাকে, প্রতিটি মন্তব্যকে রেকর্ড করতে হবে কোন বিল্ডে এটি পরীক্ষা করা হয়েছে। এটি একটি বর্ধিতকরণ অনুরোধের ক্ষেত্রেও প্রযোজ্য: অনুপস্থিত ব্যাচ অপারেশন শনাক্ত করার সময় এজেন্ট কোন সংস্করণটি চালাচ্ছিল তা জেনে আমাকে বলে যে ব্যবধানটি ইতিমধ্যেই পরবর্তী বিল্ডে সমাধান করা হয়েছে নাকি সত্যিকারভাবে খোলা হয়েছে। প্রমাণ ছাড়া, থ্রেড প্রত্নতত্ত্ব হয়ে ওঠে।

`submit_issue` যেকোন দাখিল প্রত্যাখ্যান করে যেটিতে `reporter_git_sha` এবং `reporter_app_version` উভয়েরই অভাব রয়েছে। প্রত্যাখ্যান খামে বিকল্পগুলি স্পষ্টভাবে তালিকাভুক্ত করে:

``জসন
{
  "error_code": "ERR_REPORTER_ENVIRONMENT_REQUIRED",
  "বিস্তারিত": {
    "গ্রহণযোগ্য_ক্ষেত্র_গোষ্ঠী": [
      ["প্রতিবেদক_গীত_শা"],
      ["reporter_app_version"]
    ]
  }
}
```

`add_issue_message` একই ক্ষেত্রগুলিকে গ্রহণ করে এবং যখন উভয়টি অনুপস্থিত থাকে তখন সর্বজনীন থ্রেডগুলিতে একটি সার্ভার সতর্কতা নির্গত করে। প্রতিটি বার্তা একটি ডিবাগিং এজেন্ট লেখক পরীক্ষার অধীনে বিল্ড রেকর্ড.

এজেন্ট-থেকে-এজেন্ট পরিচালনার জন্য এটি গুরুত্বপূর্ণ হওয়ার কারণ হল এটি কোনও কাজ করার আগে গ্রহীতা পক্ষকে প্রতিবেদনটি শ্রেণীবদ্ধ করতে দেয়। একটি বাগ জন্য: ব্যবহারকারী একটি প্রকাশিত রিলিজ চালান? 'প্রধান' থেকে শাখা এবং একটি পিআর খুলুন। একটি বৈশিষ্ট্য শাখা একটি নির্দিষ্ট প্রতিশ্রুতি? মেইনলাইন পরিবর্তন না করে সেই প্রতিশ্রুতিতে একটি ওয়ার্কট্রি তৈরি করুন, পুনরুত্পাদন করুন এবং ফলাফলের প্রতিবেদন করুন। তাদের নিজেদের কাঁটা? প্যাচ উত্সের জন্য জিজ্ঞাসা করে একটি কাঠামোগত ফলো-আপ পোস্ট করুন। একটি বর্ধিতকরণের জন্য: অনুরোধ করা ক্ষমতা ইতিমধ্যে একটি শাখায় আছে, নাকি প্রকৃতপক্ষে অনুপস্থিত? এটি কি একটি ডিজাইনের সীমাবদ্ধতার সাথে বিরোধপূর্ণ যা এজেন্ট ফাইলিং এটি দেখতে পাচ্ছে না? শ্রেণিবিন্যাস প্রতিক্রিয়া নির্ধারণ করে — এবং এর কোনোটিই প্রমাণ ছাড়া সম্ভব নয়।

প্রোভেন্যান্স হল যা একটি ফ্রি-ফর্ম রিপোর্টকে একটি রাউটেবল ইভেন্টে পরিণত করে, এটি ভাঙ্গা বা অনুপস্থিত কিছু বর্ণনা করে।

## রক্ষণাবেক্ষণকারীর পক্ষে কী ঘটে

আমার ট্রাইজ ডেমন একই `সাবস্ক্রাইব` টুলের মাধ্যমে ক্রিয়েশন ইভেন্ট ইস্যু করার জন্য সাবস্ক্রাইব করে যা অন্য কোনো ভোক্তা ব্যবহার করবে। ওয়েবহুকগুলি প্রথমে আসে কারণ তারা আমার ল্যাপটপে ভিপিএসের পাশাপাশি স্থানীয় প্রক্রিয়াগুলির জন্য দূরবর্তী ডেমনগুলির জন্য কাজ করে; SSE যোজক। সাবস্ট্রেট রেজিস্ট্রি রক্ষণাবেক্ষণ করে, ইভেন্ট বিতরণ করে এবং ভুলে যায়। ডেমন সিদ্ধান্ত নেয়।

আমি এটির জন্য যে ডেমন চালাই তাকে ফর্মিকা বলা হয়। জেনাস _ফরমিকা_, পিঁপড়া। প্রতিটি সাবএজেন্ট হল একজন কর্মী যা ইভেন্ট লগ থেকে একটি ফিক্স পর্যন্ত কাজ করে।

এটি কি করে, বাস্তবে: সমস্যাটি পড়ুন। জমা দেওয়ার সময় রিপোর্টারের এজেন্ট লিঙ্ক করা সত্তাগুলিকে টানুন, যেহেতু সম্পর্কগুলি ইতিমধ্যেই গ্রাফে রয়েছে৷ আপস্ট্রিম গিটহাব রেপোতে মিরর করুন যদি এটি একটি পাবলিক ট্র্যাল নিশ্চিত করে, যেখানে API সীমানায় PII রিডাকশন প্রয়োগ করা হয় এবং যে কোনও সমস্যা যার শিরোনাম বা বডি এখনও রেখা অতিক্রম করার আগে প্রত্যাখ্যান করা রিডাকশন প্যাটার্নের সাথে মেলে। প্রতিবেদনটি একটি বাগ বা একটি পরিবর্ধন কিনা তা শ্রেণিবদ্ধ করুন৷ বাগগুলির জন্য: শুধুমাত্র রিপোর্টার পরিবেশ থেকে এটি পুনরুত্পাদনযোগ্য কিনা তা স্থির করুন, তারপর একটি `/প্রসেস-ইস্যুস' দক্ষতার কাছে হস্তান্তর করুন যা একটি ওয়ার্কট্রি খোলে, একটি এজেন্ট সেশন চালায় এবং একটি সমাধান করার চেষ্টা করে৷ বর্ধিতকরণের জন্য: একটি প্ল্যান সত্তা সংশ্লেষিত করুন যা যেকোনো সম্পর্কিত উন্মুক্ত সমস্যাগুলির সাথে অনুরোধকে একত্রিত করে, এবং স্বায়ত্তশাসিত বাস্তবায়নের চেষ্টা না করে মানুষের পর্যালোচনার জন্য এটিকে সারফেস করুন। যেকোনও প্রকারের জন্য যদি আরও প্রসঙ্গ প্রয়োজন হয়, তাহলে `add_issue_message` এর মাধ্যমে একটি স্পষ্ট প্রশ্ন পোস্ট করুন যাতে রিপোর্টারের এজেন্ট পরবর্তী স্ট্যাটাস পড়ার সময় এটি গ্রহণ করে।

`/প্রসেস-ইস্যুস' দক্ষতা প্রকৃত সমাধান চালায়। চুক্তিটি সংক্ষিপ্ত। প্রতিটি খোলা সমস্যার জন্য:

- স্ন্যাপশট, কথোপকথন থ্রেড এবং রিপোর্টার পরিবেশ লোড করুন।
- প্রজনন পরিবেশকে `পাবলিক_রিলিজ`, `লোকাল_কমিট`, `স্থানীয়_শাখা`, বা `অজানা` হিসাবে শ্রেণীবদ্ধ করুন।
- অজানা বা বিরোধপূর্ণ হলে, অনুপস্থিত বিশদ বিবরণের জন্য একটি কাঠামোগত অনুরোধ সহ `add_issue_message` কল করুন এবং প্ল্যানটিকে চিহ্নিত করুন `অপেক্ষারত_ইনপুট`।
- অন্যথায়, উৎস সমস্যা এবং প্রাসঙ্গিক কথোপকথন বার্তা সারিগুলির সাথে লিঙ্কযুক্ত একটি `প্ল্যান` সত্তা সংশ্লেষিত করুন৷
- যদি প্ল্যানটি স্কিমা, নিরাপত্তা, ফাউন্ডেশন ডক্স, বা একটি অস্পষ্ট স্থাপত্য সীমানা স্পর্শ করে, থামুন এবং জিজ্ঞাসা করুন। কার্যকর করবেন না।
- যদি এক্সিকিউশন নিরাপদ হয় এবং রিপোর্টিং মোড দ্বারা অনুমোদিত হয়: একটি পাবলিক রিলিজ রিপ্রোডাকশনের জন্য `প্রধান` থেকে শাখা এবং একটি পিআর খুলুন, বা স্থানীয় প্রজননের জন্য একটি বিচ্ছিন্ন গিট ওয়ার্কট্রি তৈরি করুন এবং পথের প্রতিবেদন করুন।

সাবএজেন্ট প্রতি সাবএজেন্টের জন্য একটি ইস্যু, চারটির কনকারেন্সি ক্যাপ সহ ফ্যান আউট। দক্ষতা 'রিপোর্টিং_মোড'কে সম্মানিত করে: 'অফ' শুধুমাত্র পরিকল্পনা তৈরি করে এবং সঞ্চয় করে, 'সম্মতি' কার্যকর করার আগে জিজ্ঞাসা করে, 'প্রোঅ্যাকটিভ' নিরাপদ পরিকল্পনাগুলি স্বায়ত্তশাসিতভাবে সম্পাদন করে। কখনই 'প্রধান'-এ ঠেলে দেবেন না। কখনই `--no-verify` ব্যবহার করবেন না। একটি ধাক্কা কমিট সংশোধন করবেন না. একটি ব্যক্তিগত সমস্যা থেকে কোনো পাবলিক আর্টিফ্যাক্ট তৈরি করার আগে রিডাকশন লিক গার্ড চলে।

নিরাপদ ডিফল্ট চালু থাকে:

- `dry_run: true` যেকোন নতুন ইস্যু টাইপের প্রথম রানের জন্য তাই আমি দেখি কিছু লেখার আগে কী ঘটবে।
- `অটো_ফিক্স: মিথ্যা` তাই অপারেটর ট্রান্সপোর্টের মাধ্যমে নিশ্চিত না হওয়া পর্যন্ত কিছুই পিআর ঠেলে বা খুলবে না।
- `সর্বোচ্চ_prs_per_hour: 5` তাই সংশ্লিষ্ট সমস্যার বন্যা শাখার বন্যায় পরিণত হতে পারে না।
- `dirty_tree_policy: abort` তাই একটি বাসি চেকআউট কখনই বেস হিসাবে ব্যবহার করা হয় না।
- নিওটোমাতে একটি `ডেমন_কনফিগ` সত্তার মাধ্যমে `সক্রিয়: মিথ্যা` সহ একটি কিল সুইচ, তাই আমি হোস্ট মেশিনে স্পর্শ না করেই একটি একক নিওটোমা লেখা থেকে সমস্ত প্রক্রিয়াকরণ বিরাম দিতে পারি।

অপারেটর পরিবহন টুকরা একটি নোট প্রাপ্য. Formica একটি টেলিগ্রাম ব্যাকএন্ড সমর্থন করে যেটি `অটো_ফিক্স` বন্ধ থাকলে পুনরায় শুরু করার জন্য `মানব_প্রয়োজনীয়` হ্যান্ডঅফ এবং `/শিপিট` কমান্ডগুলিকে সারফেস করে। অনুমোদিত টেলিগ্রাম বার্তাগুলি নিওটোমাতে `কথোপকথন_বার্তা` সারি হিসাবে মিরর করা হয়, তাই ডেমনের সাথে আমার মানব-সদৃশও একই সাবস্ট্রেটে ক্যাপচার করা হয়। অডিট ট্রেইল শেষ থেকে শেষ হয়.

'add_issue_message' পথটি এমন একটি যা আমি যখন এটি ব্যবহার করা শুরু করি তখন আমাকে অবাক করে দিয়েছিল৷ এটি একটি মন্তব্য সিস্টেম নয়. এটি একটি ইস্যু রিপোর্টার এবং রক্ষণাবেক্ষণকারী পক্ষের মধ্যে একটি কাঠামোগত বার্তা চ্যানেল, একই কথোপকথনের আদিম মাধ্যমে থ্রেড করা হয় যা এজেন্ট থেকে এজেন্ট থ্রেডের জন্য ইতিমধ্যেই বিদ্যমান। প্রতিবেদকের এজেন্ট একটি স্পষ্ট প্রশ্নের উত্তর দিতে পারে, মানুষের মাঝে এটি পড়া ছাড়াই। পাবলিক থ্রেড একই PII রিডাকশন বহন করে এবং আংশিক-সাফল্যের ক্ষেত্রে (GitHub মিরর গৃহীত, স্থানীয় সংযোজন ব্যর্থ, বা বিপরীত) নীরবে নকল মন্তব্য তৈরি করার পরিবর্তে প্রতিক্রিয়াতে একটি কাঠামোগত ত্রুটি হিসাবে পৃষ্ঠ।

যখন একটি ফিক্স ল্যান্ড হয়, সেই একই ডেমন যেটি রিপোর্টটিকে ট্রাইজ করেছে সমস্যাটি বন্ধ করে দেয়, অথবা যদি একটি একক পিআর একটি ক্লাস্টার সমাধান করে তবে একযোগে অনেকগুলি বাল্ক-ক্লোজ করে।

## রিড-ব্যাক এ রিপোর্টারের এজেন্ট যা করে

লুপের অন্য দিকটি হল রিড। প্রতিবেদকের এজেন্ট ইস্যু নম্বর বা সত্তা আইডি সহ `get_issue_status` কল করে। এটি বর্তমান অবস্থা, থ্রেডের বার্তাগুলি, রেজোলিউশন যদি থাকে, এবং আপস্ট্রিম মিররের লিঙ্ক যদি রক্ষণাবেক্ষণকারী পক্ষ এটিকে বৃদ্ধি করতে বেছে নেয় তবে এটি গ্রহণ করে। গেস্ট টোকেন ব্যবহারকারীকে কোনো কিছুতে লগ ইন না করেই পড়াকে প্রমাণীকরণ করে। যদি টোকেনের মেয়াদ শেষ হয়ে যায়, তাহলে সাবস্ট্রেটটি বেনামী অ্যাক্সেসে নিঃশব্দে ডাউনগ্রেড করার পরিবর্তে একটি পরিষ্কার 401 প্রদান করে।

এজেন্ট সিদ্ধান্ত নেয় ব্যবহারকারীর কাছে স্ট্যাটাস প্রকাশ করবে কিনা। শেষ চেক থেকে যদি কিছুই পরিবর্তিত না হয় তবে এটি শান্ত থাকে। যদি একটি স্পষ্ট প্রশ্ন আসে, এটি ব্যবহারকারীকে জিজ্ঞাসা করে। যদি ফিক্সটি পাঠানো হয়, তবে এটি ব্যবহারকারীকে বলে, ঐচ্ছিকভাবে নতুন সংস্করণটি টেনে আনে এবং প্রথমবার যা ভেঙেছে তা পুনরায় চালানোর প্রস্তাব দেয়।

প্রতিবেদক পক্ষের বর্তমান পঠিত মডেলটি হল পুল — এজেন্ট যখন তার কারণ থাকে তখন পরীক্ষা করে — কিন্তু রক্ষণাবেক্ষণকারীর ডেমন ব্যবহার করে একই সাবস্ক্রিপশন টুলের মাধ্যমে আজ পুশ উপলব্ধ। সাবস্ক্রিপশনগুলি একটি নির্দিষ্ট সত্তা আইডিতে স্কোপ করা যেতে পারে, তাই একজন রিপোর্টারের এজেন্ট এইমাত্র দায়ের করা সমস্যাটিতে আগ্রহ নিবন্ধন করতে পারে এবং থ্রেডটি অগ্রসর হওয়ার সাথে সাথে `entity.updated` এবং `observation.created` ইভেন্টগুলি পেতে পারে। যেটি অনুপস্থিত তা হল এরগনোমিক আঠা: MCP নির্দেশাবলী এখনও এজেন্টদেরকে `submit_issue` রিটার্ন করার পরে স্বয়ংক্রিয় সদস্যতা নিতে বলে না। তারা না করা পর্যন্ত, প্রতিবেদক পক্ষ পূর্বনির্ধারিতভাবে টানতে থাকে; রক্ষণাবেক্ষণকারীর এজেন্টরা ইতিমধ্যেই সাবস্ট্রেট ইভেন্টে জেগে উঠেছে। উভয় অর্ধেক সম্পূর্ণরূপে প্রতিক্রিয়াশীল একটি নির্দেশ পরিবর্তন দূরে.

## কেন এই স্নায়ুতন্ত্র কর্মে

সাবস্ট্রেট প্রতিটি লেখার পরে ইভেন্ট নির্গত করে। এই যে কোনো কাজ করার জন্য সাবস্ট্রেটকে এটাই করতে হবে। বাকি সবকিছুই উপরে চলছে অপারেশনাল-লেয়ার লজিক: ট্রাইজ ডেমন, গিটহাব মিরর, গেস্ট রিড-ব্যাক, ক্রস-থ্রেড ডিডআপ, পিআইআই রিডাকশন।

এই লাইনটিই আমি [স্নায়ুতন্ত্রের পোস্টে যুক্তি দিয়েছিলাম](/posts/from-memory-to-nervous-system) এবং এটি সমস্যার ব্যবহারের ক্ষেত্রে ধরে রাখে। সাবস্ট্রেট কোন বিষয়গুলি গুরুত্বপূর্ণ তা নির্ধারণ করে না, বৃদ্ধির সাথে ডেলিভারির পুনরায় চেষ্টা করে না, তার নিজস্ব ইভেন্টগুলিতে সদস্যতা নেয় না। এটি সংকেত দেয়। ট্রাইজ ডেমন একজন ভোক্তা, রিপোর্টারের এজেন্ট একজন ভোক্তা, গিটহাব মিরর একজন ভোক্তা। প্রতিটি ভোক্তা আগ্রহ নিবন্ধন করে, কি করতে হবে তা সিদ্ধান্ত নেয় এবং কাজ করে। যদি আমি একটি দ্বিতীয় ট্রাইজ ডেমন যোগ করতে চাই যা নিরাপত্তা প্রতিবেদনগুলিকে ভিন্নভাবে পরিচালনা করে, এটি একটি ভিন্ন ফিল্টার সহ একই ইভেন্টগুলিতে সদস্যতা নেয়। নতুন সাবস্ট্রেট আচরণ নেই।

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

## লুপ ইনহেরিট করা

আমি যে আকারটি বর্ণনা করেছি তা নিওটোমার নিজস্ব সমস্যাগুলির চারপাশে তৈরি করা হয়েছে, তবে স্তরটি যত্ন করে না। এটির উপরে নির্মিত যে কোনও জিনিস একই যন্ত্রপাতির বেশিরভাগ উত্তরাধিকারসূত্রে পায়।

জমা দেওয়ার জেনেরিক দিকটি ইতিমধ্যেই রয়েছে। যখন অপারেটর এটিকে অনুমোদন করার জন্য একটি `submission_config` সারি সিড করে তখন `submit_entity` নির্বিচারে সত্তা প্রকারের বিরুদ্ধে প্রতিবেদন গ্রহণ করে। একই অতিথি-টোকেন অনুদান, একই কথোপকথন থ্রেডিং, একই `add_entity_message` ফলো-আপ চ্যানেল প্রযোজ্য। `সাবস্ক্রাইব` ফিল্টার হিসেবে যেকোনো সত্তার ধরনকে গ্রহণ করে, তাই কোনো তৃতীয় পক্ষের অপারেটর তাদের নিজস্ব ট্রাইজেন ডেমন চালাতে পারে তাদের কাস্টম প্রকারে আগ্রহ নিবন্ধন করে এবং `entity.created` এবং `entity.updated` ইভেন্টে ঠিক যেভাবে Formica সমস্যার প্রতিক্রিয়া জানায়।

অনুশীলনে এর অর্থ কী: আপনি যদি একটি সামগ্রী পাইপলাইন, একটি পুনর্মিলন পরিষেবা বা এমন কোনও পণ্য চালান যার ব্যবহারকারীরা এজেন্ট চালান, আপনি সেই এজেন্টদের আপনার মালিকানাধীন সত্তার বিরুদ্ধে কাঠামোগত প্রতিবেদন ফাইল করতে দিতে পারেন — একটি ব্যর্থ পাইপলাইন চালানো, একটি ভুল শ্রেণিবদ্ধ রেকর্ড, একটি পুনর্মিলনের অনুরোধ — এবং একই সাবস্ক্রিপশন মেকানিজমের মাধ্যমে সেগুলি আপনার পক্ষ থেকে তুলে নিন৷ তারটি সাধারণ।

কয়েকটি টুকরা আজ নিওটোমার নিজস্ব সমস্যাগুলির জন্য নির্দিষ্ট থাকে। PII রিডাকশন গার্ড বর্তমানে `submit_issue` পাথের সাথে আবদ্ধ, জেনেরিক `submit_entity` পাথে নয়। গিটহাব মিররিং সমস্যা-নির্দিষ্ট। উভয়ই অপারেশনাল-লেয়ার সংযোজন একটি তৃতীয় পক্ষের অপারেটর নিজেরাই ওয়্যার করবে। সাবস্ট্রেট সেই অংশগুলিকে পরিচালনা করে যা অভিন্ন হতে হবে — প্রোভেন্যান্স এনফোর্সমেন্ট, পারমাণবিক সম্পর্ক তৈরি, থ্রেডে স্কোপ করা গেস্ট অ্যাক্সেস, প্রতিটি লেখায় ইভেন্ট নির্গমন। যে অংশগুলি রিপোর্টটি *সম্পর্কে* তার উপর নির্ভর করে যেখানে অপারেটর তাদের রাখা উপার্জন করে।

ইস্যু সাবসিস্টেম হল আরও সাধারণ প্যাটার্নের প্রথম সম্পূর্ণ ভোক্তা। একই আকৃতি যেকোন কাঠামোগত সংকেতের ক্ষেত্রে প্রযোজ্য যে একটি এজেন্ট যে সিস্টেমের বিরুদ্ধে চলছে সেটিতে ফেরত পাঠাতে চাইতে পারে।

## কেন মানুষের রিভিউ থাকে

দুটি জিনিস আমাকে `অটো_ফিক্স: সত্য` ওয়্যার করতে প্রলুব্ধ করে এবং ডেমনের উৎপাদিত সবকিছু পাঠায়।

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

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

বর্ধিতকরণ অনুরোধগুলি এটিকে আরও তীক্ষ্ণ করে। একটি বাগের একটি বাস্তব সত্য আছে — হয় ক্ষেত্রটি বাদ দেওয়া হয়েছে বা তা নয়৷ একটি বর্ধিতকরণ একটি ডিজাইনের দাবি যা ব্যবহারের ধরণ, স্থাপত্যের সীমাবদ্ধতা এবং রিপোর্টিং এজেন্ট সম্পূর্ণরূপে দেখতে পারে না এমন ট্রেডঅফ সম্পর্কে অনুমান বহন করে। সংকেত মূল্যবান; এটি বাস্তব ঘর্ষণ পৃষ্ঠতল, কল্পনা করা ঘর্ষণ নয়. কিন্তু এর সাথে কী করবেন সে বিষয়ে সিদ্ধান্ত একজন মানুষের যে সম্পূর্ণ ছবি দেখতে পারে।

যে সিদ্ধান্তগুলি একজন মানুষের প্রয়োজন সেগুলি হল সেইগুলি যেখানে ভুল হওয়ার মূল্য বেশি এবং ধীর হওয়ার মূল্য কম। সেগুলি হল একত্রীকরণ — পরিকল্পনা, প্যাচ, পরীক্ষা বা PR বর্ণনা নয়। এজেন্টরা বাকি সবকিছু পরিচালনা করে। এজেন্টদের প্রস্তাব; মানুষ সিদ্ধান্ত নেয়।

## এজেন্টিক লুপ, শেষ থেকে শেষ

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

উভয় অর্ধেক একটি কাঠামোগত পৃষ্ঠের মাধ্যমে এজেন্টদের সাথে কথা বলা এজেন্টদের উপর কাজ করে। যে ঘর্ষণটি ঐতিহাসিকভাবে অধিগ্রহণ লুপ এবং প্রতিক্রিয়া লুপ উভয়কেই হত্যা করেছিল তা চলে গেছে কারণ প্রতিটি অনুবাদ পদক্ষেপ একটি টুল কলে শোষিত হয়েছে৷ নিচের সাবস্ট্রেট ছাড়া অর্ধেকও সম্ভব হবে না: এজেন্ট-নেতৃত্বাধীন মূল্যায়নের জন্য ব্যবহারকারীর কর্মপ্রবাহ সম্পর্কে কাঠামোগত অবস্থার প্রয়োজন, এবং সমস্যা সাবসিস্টেমের জন্য ইভেন্ট সিগন্যালিং এবং বিশ্বাসের সীমানা জুড়ে গেস্ট অ্যাক্সেস প্রয়োজন। উভয় একই আদিম উপর নির্ভর করে.

## যা আমি নির্মাণ করছি না

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

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

সীমাবদ্ধতা হল বৈশিষ্ট্য। একটি রাষ্ট্রীয় স্তর যা সমস্যাগুলির সংকেত দেয় কিন্তু কোন বিষয়গুলি গুরুত্বপূর্ণ তা নির্ধারণ করে না একটি রাষ্ট্রীয় স্তর যে কোনও ভোক্তা ভবিষ্যদ্বাণীমূলকভাবে আচরণ করতে বিশ্বাস করতে পারেন৷

## আমি কি মতামত চাই

সমস্যা সাবসিস্টেম লাইভ. আপনার যদি নিওটোমা ইনস্টল করা থাকে এবং আপনার এজেন্ট কিছু রুক্ষভাবে আঘাত করে — একটি বাগ, একটি কার্যক্ষমতার ব্যবধান, একটি অনুপস্থিত ক্ষমতা এটির ইচ্ছা থাকে - আপনাকে আর একটি সমস্যা ফাইল করার জন্য এটি বলার দরকার নেই। একটি বিদ্যমান ইনস্টলে এটি নিতে, `npm install -g neotoma@latest` দিয়ে আপগ্রেড করুন। কনফিগার করার জন্য প্রতি-ব্যবহারকারীর সম্মতি টগল নেই; সম্মতি হল ইনস্টল করা। এটি একটি নতুন ইনস্টল হলে, `নিওটোমা রিপোর্টার সেটআপ` ওয়ান-টাইম রিপোর্টার-সাইড কনফিগারেশনের মধ্য দিয়ে চলে যাতে আপনার এজেন্ট ফাইলের প্রথম সমস্যাটি কোথাও অবতরণ করতে পারে।

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

আপনি যদি এমন একটি পণ্য তৈরি করেন যার ব্যবহারকারীরা এজেন্ট চালায়, মডেলটি বহনযোগ্য। আকর্ষণীয় কাজ তারের উভয় পাশে নয়; এটা তারের নিজেই.