एक उपयोगकर्ता एजेंट के नेतृत्व वाले मूल्यांकन संकेत को अपने संपादक में चिपकाता है। एजेंट [नियोटोमा मूल्यांकन पृष्ठ](https://neotoma.io/evaluate) पढ़ता है, स्थानीय वर्कफ़्लो को स्कैन करता है, निर्णय लेता है कि फिट मजबूत है, इंस्टॉल चलाता है, और पहले कुछ इकाइयों को संग्रहीत करता है। कुछ समय बाद यह एक वास्तविक बग से टकराता है - एक इकाई सबमिशन चुपचाप उस फ़ील्ड को छोड़ देता है जिसे स्कीमा स्पष्ट रूप से स्वीकार करता है। थोड़ी देर बाद यह कुछ और नोटिस करता है: एक बड़े इकाई ग्राफ़ पर पुनर्प्राप्ति उस वर्कफ़्लो की तुलना में धीमी है जिसका वह समर्थन कर रहा है। और बाद में भी, एक कस्टम पुनर्प्राप्ति लूप का निर्माण करते समय, यह महसूस होता है कि एमसीपी सतह में एक बैच ऑपरेशन गायब है जो उस पैटर्न को अधिक साफ-सुथरा बना देगा जिसे वह दोहराता रहता है। उपयोगकर्ता ने इसके बारे में कभी नहीं पूछा. कुछ और करने के रास्ते में एजेंट ने इसे नोटिस किया।

उन क्षणों का पुराना आकार पाश का अंत था। उपयोगकर्ता GitHub खोल सकता है, त्रुटि या अनुरोध पेस्ट कर सकता है, संदर्भ का एक पैराग्राफ लिख सकता है और प्रतीक्षा कर सकता है। अधिकांश नहीं करते. वे समस्या को इधर-उधर कर देते हैं, अनुरक्षक इसे कभी नहीं देखता है, और अगला उपयोगकर्ता उसी समस्या से टकराता है।

नियोटोमा के पास अब प्रथम श्रेणी का इश्यू सबसिस्टम है जो उसी एमसीपी सतह के माध्यम से संचालित होता है जिसका उपयोग प्रत्येक एजेंट पहले से ही स्टोर करने और पुनः प्राप्त करने के लिए करता है। एजेंट सत्र छोड़े बिना, और प्रति-समस्या पूछने के लिए रुके बिना बग, प्रदर्शन अवलोकन और संवर्द्धन अनुरोध दर्ज करता है। अनुरक्षक के एजेंट उन्हें उठाते हैं, उनका परीक्षण करते हैं, अक्सर समाधान करते हैं और भेज देते हैं। रिपोर्टर का एजेंट स्थिति को पढ़ता है और कुछ गिरने पर उपयोगकर्ता को बताता है। संपूर्ण आदान-प्रदान टूल कॉल के माध्यम से होता है।

[ग्राहक अनुसंधान पोस्ट](/पोस्ट/ग्राहक-अनुसंधान-थ्रू-एजेंट) में एजेंट के नेतृत्व वाला मूल्यांकन इस लूप का अगला भाग था। मुद्दे का सबसिस्टम पिछला भाग है। दोनों हिस्से [नर्वस सिस्टम सब्सट्रेट](/पोस्ट/फ्रॉम-मेमोरी-टू-नर्वस-सिस्टम) पर चलते हैं, जिसका मैंने पहले वर्णन किया था, और मुद्दों की क्षमता उस सब्सट्रेट के लिए अब तक का सबसे साफ उदाहरण है।

## लूप को एजेंट की तरफ से क्यों बंद करना पड़ता है

घर्षण प्रतिक्रिया का मूक हत्यारा है। पुराने मॉडल में यह मान लिया गया था कि उपयोगकर्ता अपने अनुभव को एक अलग सिस्टम पर एक रिपोर्ट में अनुवादित करेगा: संदर्भ स्विच करें, रेपो ढूंढें, एक समस्या टेम्पलेट को पार्स करें, पर्याप्त पृष्ठभूमि लिखें जिस पर अनुरक्षक कार्य कर सके, लॉग संलग्न करें, प्रतीक्षा करें। प्रत्येक कदम हार मानने का एक मौका है। अधिकांश करते हैं. और वह मॉडल केवल उपयोगकर्ता द्वारा देखी गई समस्याओं को कवर करता है। इसमें उन समस्याओं के लिए कोई रास्ता नहीं है जिन पर एजेंट ने ध्यान दिया जो उपयोगकर्ता के सामने कभी नहीं आईं।

एक मूल्यांकनकर्ता के एजेंट ने पहचाना कि सक्रियण ने एक हाइड्रेशन त्रुटि उत्पन्न की जब उनके सब्सट्रेट कॉन्फिगरेशन ने क्लाउडफ्लेयर सुरंग के पीछे एक स्व-होस्ट किए गए उदाहरण की ओर इशारा किया। एजेंट ने एक सटीक सारांश लिखा, जिसमें विफल समापन बिंदु और प्रतिक्रिया शीर्षलेख शामिल थे। उपयोगकर्ता ने सारांश को एक संदेश के रूप में मुझे अग्रेषित किया। मैंने संदर्भ को फिर से बनाया, इसे अपने एजेंटों तक पहुंचाया, एक विज्ञप्ति भेजी, और उपयोगकर्ता को वापस संदेश भेजा। उपयोगकर्ता ने अपने एजेंट से सत्यापन करने के लिए कहा। उस सत्यापन में लगभग नब्बे सेकंड लगे। मानव रिले कदमों में कई दिन लगे।

एजेंट का मूल सारांश अच्छा था. यह पुनर्निर्माण-संदर्भ था जिसने समय खा लिया। एक एजेंट और एक इंसान के बीच प्रत्येक हैंडऑफ़ निष्ठा खो देता है। एक इंसान और दूसरे एजेंट के बीच प्रत्येक बातचीत शुरू से ही संदर्भ का पुनर्निर्माण करती है। समृद्ध एजेंट-लिखित विवरण संक्षिप्त मानव-लिखित गद्य में संपीड़ित होता है, और फिर एक डाउनस्ट्रीम एजेंट को इसे वापस विस्तारित करना होता है।

जब उपयोगकर्ता का एजेंट दीवार से टकराता है - या धीमापन देखता है, या गायब क्षमता चाहता है - तो अनुवाद चरण मुफ़्त है। एजेंट के पास पहले से ही संदर्भ है: वह कौन सा टूल चल रहा था, सटीक एमसीपी कॉल जो विफल रही या अजीब लगी, प्रतिक्रिया पेलोड, नियोटोमा इंस्टॉल का गिट एसएचए या ऐप संस्करण, शामिल इकाई प्रकार। यह एक टूल कॉल में एक सुसंगत रिपोर्ट तैयार करता है। एमसीपी निर्देश एजेंटों को रिपोर्ट करने योग्य समस्या या सुधार के अवसर की पुष्टि होने पर तुरंत 'submit_issue' के माध्यम से फाइल करने के लिए कहते हैं, प्रति-समस्या पूछने के लिए बिना रुके - प्रति-समस्या संकेत कोई नई जानकारी नहीं जोड़ता है और उपयोगकर्ता जो कुछ भी कर रहा था उसे बाधित करता है। एजेंट फाइल करता है. उपयोगकर्ता को इसके बारे में बाद में पता चलता है, या कभी नहीं, यह इस बात पर निर्भर करता है कि परिवर्तन कभी भेजा गया है या नहीं।

अनुरक्षक पक्ष पर, मेरे द्वारा प्रत्येक रिपोर्ट को हाथ से पढ़े बिना लूप को बंद करना होगा। मैं संपादकों और डेमॉन में लगभग एक दर्जन एजेंट चलाता हूं। वे पहले से ही आने वाली संरचित स्थिति की प्रक्रिया करते हैं। प्राकृतिक आकार यह है: एक नया मुद्दा आता है, लिखने पर सब्सट्रेट संकेत देता है, एक ट्राइएज डेमॉन घटना को उठाता है, मुद्दे को पढ़ता है, निर्णय लेता है कि क्या यह कार्य कर सकता है, एक वर्कट्री खोलता है, कोडबेस के खिलाफ एक एजेंट सत्र चलाता है, और या तो बग को हल करता है या रिपोर्टर से उसी थ्रेड के माध्यम से स्पष्टीकरण मांगता है।

लूप के दोनों हिस्से एक ही सब्सट्रेट पर एजेंटिक कार्य के रूप में चलते हैं। उपयोगकर्ता का एजेंट सबमिट करने के लिए MCP का उपयोग करता है। अनुरक्षक के एजेंट पढ़ने और प्रतिक्रिया देने के लिए एमसीपी का उपयोग करते हैं। किसी को भी ब्राउज़र खोलने की ज़रूरत नहीं है.

## प्रस्तुत करने पर एजेंट क्या करता है

एमसीपी सतह गणना के लिए काफी छोटी है। `submit_issue` टूल एक शीर्षक, एक बॉडी, एक इकाई प्रकार लेता है यदि समस्या एक विशिष्ट प्रकार के रिकॉर्ड के बारे में है, और एक रिपोर्टर पर्यावरण ब्लॉक - उपयोगकर्ता द्वारा चलाया जा रहा git SHA या ऐप संस्करण, बाद वाले ऑटो-पॉप्युलेटेड सर्वर-साइड के साथ जब एजेंट दोनों को छोड़ देता है। रिपोर्टर माहौल जितना दिखता है उससे कहीं अधिक महत्व रखता है; अगला भाग इसका कारण बताता है।

बिना संदर्भ के रिपोर्टें शायद ही कभी आती हैं। एक बग ठोस संस्थाओं का संदर्भ देता है: विशिष्ट रिकॉर्ड जो संग्रहीत करने में विफल रहा, इसकी स्कीमा, एक अपस्ट्रीम अवलोकन। एक एन्हांसमेंट अनुरोध उस कॉल पैटर्न का संदर्भ देता है जिसे वह सरल बनाएगा, या इकाई प्रकार जिसे वह पुनः प्राप्त करने में तेज़ बनाएगा। `submit_issue` और `add_issue_message` एक `entity_ids_to_link` सरणी स्वीकार करते हैं, और सर्वर एक ही कॉल के हिस्से के रूप में परमाणु रूप से प्रत्येक संदर्भित इकाई के लिए नए मुद्दे से `REFERS_TO` संबंध बनाता है। यह मुद्दा पहले से ही उस ग्राफ़ में शामिल है जिसके बारे में बात की जा रही है। समस्या को पढ़ने वाला ट्राइएज एजेंट सीधे विफल इकाई तक पहुंच सकता है।

सबमिशन उसी `scanAndRedact` PII गार्ड के माध्यम से प्रवाहित होता है जो प्रत्येक सार्वजनिक सतह की सुरक्षा करता है। यदि एजेंट गलती से कोई टोकन या ईमेल पता मुख्य भाग में चिपका देता है, तो इसे दृढ़ता से पहले ही संशोधित कर दिया जाता है। एमसीपी निर्देशों के अनुसार एजेंटों को कॉल से पहले शीर्षक और मुख्य भाग पर पीआईआई चेकलिस्ट लागू करने की आवश्यकता होती है, लेकिन सर्वर-साइड गार्ड रक्षा की वास्तविक रेखा है। रिपोर्टर को एक संख्यात्मक समस्या पहचानकर्ता और एक स्पष्ट टीटीएल के साथ एक अतिथि रीड-बैक टोकन मिलता है, जो उनके द्वारा अभी खोले गए थ्रेड तक सीमित होता है। वह टोकन यह है कि रिपोर्टर का एजेंट हर बार दोबारा प्रमाणित किए बिना बाद में स्थिति को कैसे पढ़ता है।

उपयोगकर्ता के दृष्टिकोण से: एक टूल कॉल, ट्रैक करने के लिए एक पहचानकर्ता, और आमतौर पर कोई अनुमोदन संकेत नहीं। सब्सट्रेट के परिप्रेक्ष्य से: एक संरचित इकाई लिखी गई, लिंक-इकाई संबंध एक ही लेनदेन में बनाए गए, एक स्रोत पंक्ति बनाई गई, एक अतिथि अनुदान जारी किया गया, और लेखन पाइपलाइन ने एक घटना उत्सर्जित की।

## प्रोवेंस गुमनाम नायक है

रिपोर्टर परिवेश की आवश्यकता एक छोटे विवरण की तरह दिखती है। यह सबसे महत्वपूर्ण बदलाव है.

समस्या उपप्रणाली के अस्तित्व में आने से पहले, उस निर्माण के संदर्भ के बिना एक रिपोर्ट प्रस्तुत की जा सकती थी जिसके विरुद्ध इसे लिखा गया था। पेपर टिकट के लिए यह ठीक है। स्वचालित ट्राइएज लूप के लिए यह विनाशकारी है। यदि कोई एजेंट कमिट `abc1234` पर बग सबमिट करता है और मेरे एजेंट इसे कमिट `def5678` पर ठीक करते हैं, तो उपयोगकर्ता के एजेंट को यह जानना होगा कि किस बिल्ड के विरुद्ध सत्यापन करना है। यदि एक डिबगिंग थ्रेड तीन बिल्ड तक फैला है, तो प्रत्येक टिप्पणी को यह रिकॉर्ड करना होगा कि किस बिल्ड में इसका परीक्षण किया गया था। यही बात एन्हांसमेंट अनुरोध पर भी लागू होती है: लापता बैच ऑपरेशन की पहचान करने पर एजेंट कौन सा संस्करण चला रहा था, यह जानने से मुझे पता चलता है कि क्या अंतराल को पहले से ही बाद के निर्माण में संबोधित किया गया था या वास्तव में खुला है। उद्गम के बिना, धागा पुरातत्व बन जाता है।

`submit_issue` किसी भी सबमिशन को अस्वीकार कर देता है जिसमें `reporter_git_sha` और `reporter_app_version` दोनों का अभाव है। अस्वीकृति लिफ़ाफ़ा विकल्पों को स्पष्ट रूप से सूचीबद्ध करता है:

```json
{
  "त्रुटि_कोड": "ERR_REPORTER_ENVIRONMENT_REQUIRED",
  "विवरण": {
    "स्वीकार्य_फ़ील्ड_समूह": [
      ["रिपोर्टर_गिट_शा"],
      ["रिपोर्टर_ऐप_वर्जन"]
    ]
  }
}
```

`add_issue_message` समान फ़ील्ड को स्वीकार करता है और दोनों के गायब होने पर सार्वजनिक थ्रेड पर सर्वर चेतावनी जारी करता है। प्रत्येक संदेश एक डिबगिंग एजेंट लेखक परीक्षण के तहत निर्माण को रिकॉर्ड करता है।

एजेंट-टू-एजेंट प्रबंधन के लिए इसका महत्व यह है कि यह प्राप्तकर्ता पक्ष को कोई भी कार्य करने से पहले रिपोर्ट को वर्गीकृत करने देता है। बग के लिए: क्या उपयोगकर्ता ने कोई प्रकाशित रिलीज़ चलायी? `मुख्य` से शाखा बनाएं और एक पीआर खोलें। फ़ीचर शाखा पर एक विशिष्ट प्रतिबद्धता? उस कमिट पर एक वर्कट्री बनाएं, मेनलाइन को संशोधित किए बिना निष्कर्षों को पुन: पेश करें और रिपोर्ट करें। उनका अपना कांटा? पैच स्रोत के बारे में पूछते हुए एक संरचित अनुवर्ती पोस्ट करें। संवर्द्धन के लिए: क्या अनुरोधित क्षमता पहले से ही किसी शाखा में है, या वास्तव में गायब है? क्या यह किसी डिज़ाइन बाधा के साथ टकराव करता है जिसे दाखिल करने वाला एजेंट नहीं देख सकता है? वर्गीकरण प्रतिक्रिया निर्धारित करता है - और इसमें से कुछ भी उत्पत्ति के बिना संभव नहीं है।

प्रोवेंस वह है जो एक फ्री-फॉर्म रिपोर्ट को एक नियमित घटना में बदल देता है, चाहे वह किसी टूटी हुई चीज का वर्णन करता हो या किसी गायब चीज का।

## अनुरक्षक पक्ष पर क्या होता है

मेरा ट्राइएज डेमॉन उसी `सब्सक्राइब` टूल के माध्यम से सृजन कार्यक्रम जारी करने के लिए सदस्यता लेता है जिसका उपयोग कोई अन्य उपभोक्ता करेगा। वेबहुक पहले आते हैं क्योंकि वे वीपीएस पर दूरस्थ डेमॉन के साथ-साथ मेरे लैपटॉप पर स्थानीय प्रक्रियाओं के लिए काम करते हैं; एसएसई योगात्मक है. सब्सट्रेट रजिस्ट्री को बनाए रखता है, ईवेंट वितरित करता है, और भूल जाता है। डेमन निर्णय लेता है.

इसके लिए मैं जो डेमॉन चलाता हूं उसे फॉर्मिका कहा जाता है। जीनस फॉर्मिका, चींटियाँ। प्रत्येक उप-एजेंट एक कार्यकर्ता है जो इवेंट लॉग से एक कार्य को ठीक तक ले जाता है।

व्यवहार में यह क्या करता है: अंक पढ़ें। सबमिशन के समय रिपोर्टर के एजेंट द्वारा लिंक की गई इकाइयों को खींचें, क्योंकि रिश्ते पहले से ही ग्राफ़ में हैं। अपस्ट्रीम GitHub रेपो को मिरर करें यदि यह एक सार्वजनिक ट्रेल की गारंटी देता है, तो एपीआई सीमा पर लागू पीआईआई रिडक्शन और किसी भी मुद्दे का शीर्षक या बॉडी अभी भी लाइन पार करने से पहले अस्वीकार किए गए रिडक्शन पैटर्न से मेल खाता है। वर्गीकृत करें कि रिपोर्ट बग है या एन्हांसमेंट। बग के लिए: तय करें कि क्या यह अकेले रिपोर्टर वातावरण से पुनरुत्पादित है, फिर एक `/process-issues` कौशल को सौंपें जो एक वर्कट्री खोलता है, एक एजेंट सत्र चलाता है, और एक फिक्स का प्रयास करता है। संवर्द्धन के लिए: एक योजना इकाई को संश्लेषित करें जो किसी भी संबंधित खुले मुद्दों के साथ अनुरोध को एकत्रित करती है, और इसे स्वायत्त कार्यान्वयन के प्रयास के बजाय मानव समीक्षा के लिए सामने लाती है। यदि किसी भी प्रकार के लिए अधिक संदर्भ की आवश्यकता है, तो `add_issue_message` के माध्यम से एक स्पष्ट प्रश्न पोस्ट करें ताकि रिपोर्टर का एजेंट इसे अगले स्टेटस रीड पर प्राप्त कर सके।

`/process-issues` कौशल वास्तविक सुधार को संचालित करता है। अनुबंध छोटा है. प्रत्येक खुले अंक के लिए:

- स्नैपशॉट, वार्तालाप थ्रेड और रिपोर्टर वातावरण लोड करें।
- पुनरुत्पादन वातावरण को `public_release`, `local_commit`, `local_branch`, या `unknown` के रूप में वर्गीकृत करें।
- यदि अज्ञात या विरोधाभासी है, तो लापता विवरण के लिए संरचित अनुरोध के साथ `add_issue_message` पर कॉल करें और योजना को `awaiting_input` के रूप में चिह्नित करें।
- अन्यथा, स्रोत मुद्दे और प्रासंगिक वार्तालाप संदेश पंक्तियों से जुड़ी एक `योजना` इकाई को संश्लेषित करें।
- यदि योजना स्कीमा, सुरक्षा, फाउंडेशन दस्तावेज़, या अस्पष्ट वास्तुशिल्प सीमा को छूती है, तो रुकें और पूछें। अमल मत करो.
- यदि निष्पादन सुरक्षित है और रिपोर्टिंग मोड द्वारा अनुमति दी गई है: सार्वजनिक रिलीज़ पुनरुत्पादन के लिए `मुख्य` से शाखा बनाएं और एक पीआर खोलें, या स्थानीय पुनरुत्पादन के लिए एक अलग गिट वर्कट्री बनाएं और पथ की रिपोर्ट करें।

उप-एजेंट चार की समवर्ती सीमा के साथ फैन आउट होते हैं, प्रति उप-एजेंट एक अंक। कौशल 'रिपोर्टिंग_मोड' का सम्मान करता है: 'ऑफ' केवल योजनाएं बनाता और संग्रहीत करता है, 'सहमति' निष्पादित करने से पहले पूछता है, 'प्रोएक्टिव' सुरक्षित योजनाओं को स्वायत्त रूप से निष्पादित करता है। कभी भी `मुख्य` पर दबाव न डालें। कभी भी `--no-verify` का प्रयोग न करें। कभी भी पुश की गई प्रतिबद्धता में संशोधन न करें। किसी निजी मुद्दे से किसी भी सार्वजनिक आर्टिफैक्ट के निर्माण से पहले रिडक्शन लीक गार्ड चलता है।

सुरक्षित डिफ़ॉल्ट चालू रहें:

- किसी भी नए प्रकार के मुद्दे के पहले भाग के लिए `dry_run: true` इसलिए मैं देखता हूं कि कुछ भी लिखने से पहले क्या होगा।
- `ऑटो_फिक्स: गलत` इसलिए जब तक मैं ऑपरेटर ट्रांसपोर्ट के माध्यम से पुष्टि नहीं करता तब तक कोई भी पीआर को धक्का या खोलता नहीं है।
- `max_prs_per_hour: 5` इसलिए संबंधित मुद्दों की बाढ़ शाखाओं की बाढ़ में तब्दील नहीं हो सकती।
- `dirty_tree_policy: abort` इसलिए पुराने चेकआउट को कभी भी आधार के रूप में उपयोग नहीं किया जाता है।
- नियोटोमा में 'daemon_config' इकाई के माध्यम से 'सक्रिय: गलत' के साथ एक किल स्विच, इसलिए मैं होस्ट मशीन को छुए बिना एक ही नियोटोमा राइट से सभी प्रोसेसिंग को रोक सकता हूं।

ऑपरेटर परिवहन इकाई ध्यान देने योग्य है। फॉर्मिका एक टेलीग्राम बैकएंड का समर्थन करता है जो 'ऑटो_फिक्स' बंद होने पर फिर से शुरू करने के लिए 'ह्यूमन_नीडेड' हैंडऑफ़ और '/शिपिट' कमांड पेश करता है। अनुमत सूचीबद्ध टेलीग्राम संदेशों को नियोटोमा में 'कन्वर्सेशन_मैसेज' पंक्तियों के रूप में प्रतिबिंबित किया जाता है, इसलिए डेमॉन के साथ मेरा मानव-पक्ष भी उसी सब्सट्रेट में कैप्चर किया जाता है। ऑडिट ट्रेल शुरू से अंत तक है।

`add_issue_message` पथ वह पथ है जिसने मुझे आश्चर्यचकित कर दिया जब मैंने इसका उपयोग करना शुरू किया। यह कोई टिप्पणी प्रणाली नहीं है. यह किसी मुद्दे के रिपोर्टर और अनुरक्षक पक्ष के बीच एक संरचित संदेश चैनल है, जो उसी वार्तालाप प्राइमेटिव के माध्यम से पिरोया गया है जो एजेंट-टू-एजेंट थ्रेड के लिए पहले से मौजूद है। रिपोर्टर का एजेंट किसी स्पष्ट प्रश्न का उत्तर मनुष्य को बीच में पढ़े बिना ही दे सकता है। सार्वजनिक थ्रेड में समान PII संशोधन होता है, और आंशिक-सफलता वाले मामले (GitHub मिरर स्वीकृत, स्थानीय परिशिष्ट विफल, या इसके विपरीत) चुपचाप डुप्लिकेट टिप्पणियाँ उत्पन्न करने के बजाय प्रतिक्रिया पर एक संरचित त्रुटि के रूप में सामने आते हैं।

जब कोई फिक्स लैंड होता है, तो वही डेमॉन जिसने रिपोर्ट को ट्राइ किया था, समस्या को बंद कर देता है, या यदि एक एकल पीआर ने क्लस्टर को हल कर दिया तो एक साथ कई को बंद कर देता है।

## रिपोर्टर का एजेंट रीड-बैक पर क्या करता है

लूप का दूसरा पक्ष रीड है। रिपोर्टर का एजेंट इश्यू नंबर या इकाई आईडी के साथ `get_issue_status` पर कॉल करता है। यह वर्तमान स्थिति, थ्रेड पर संदेश, यदि कोई हो तो रिज़ॉल्यूशन और अपस्ट्रीम मिरर का लिंक प्राप्त करता है यदि रखरखाव पक्ष ने इसे आगे बढ़ाने का विकल्प चुना है। अतिथि टोकन उपयोगकर्ता को कुछ भी लॉग इन किए बिना पढ़ने को प्रमाणित करता है। यदि टोकन समाप्त हो गया है, तो सब्सट्रेट चुपचाप अनाम पहुंच में अपग्रेड करने के बजाय एक साफ 401 लौटाता है।

एजेंट निर्णय लेता है कि उपयोगकर्ता को स्थिति दिखानी है या नहीं। यदि अंतिम जाँच के बाद से कुछ भी नहीं बदला है, तो यह शांत रहता है। यदि कोई स्पष्ट प्रश्न आता है, तो यह उपयोगकर्ता से पूछता है। यदि फिक्स भेज दिया गया है, तो यह उपयोगकर्ता को बताता है, वैकल्पिक रूप से नया संस्करण खींचता है, और जो कुछ भी पहली बार टूट गया उसे फिर से चलाने की पेशकश करता है।

रिपोर्टर पक्ष के लिए वर्तमान रीड मॉडल पुल है - एजेंट जांच करता है जब उसके पास कारण होता है - लेकिन पुश आज उसी सब्सक्रिप्शन टूल के माध्यम से उपलब्ध है जिसका उपयोग अनुरक्षक का डेमॉन करता है। सदस्यता को एक विशिष्ट इकाई आईडी तक सीमित किया जा सकता है, इसलिए एक रिपोर्टर का एजेंट अभी दायर किए गए मुद्दे में रुचि दर्ज कर सकता है और थ्रेड के आगे बढ़ने पर `entity.updated` और `observation.created` इवेंट प्राप्त कर सकता है। एर्गोनोमिक गोंद की कमी है: एमसीपी निर्देश अभी तक एजेंटों को 'submit_issue' रिटर्न के बाद ऑटो-सब्सक्राइब करने के लिए नहीं कहते हैं। जब तक वे ऐसा नहीं करते, रिपोर्टर पक्ष डिफ़ॉल्ट रूप से पुल-बाय-डिफ़ॉल्ट रहता है; अनुरक्षक के एजेंट पहले से ही सब्सट्रेट घटनाओं पर जागते हैं। दोनों हिस्सों पर पूरी तरह से प्रतिक्रियाशील एक निर्देश परिवर्तन दूर है।

## यह तंत्रिका तंत्र क्रियाशील क्यों है

सब्सट्रेट प्रत्येक लेखन के बाद घटनाओं का उत्सर्जन करता है। इसमें से किसी को भी काम करने के लिए सब्सट्रेट को यही एकमात्र चीज़ करनी होती है। बाकी सब कुछ ऑपरेशनल-लेयर लॉजिक है जो शीर्ष पर चल रहा है: ट्राइएज डेमॉन, गिटहब मिरर, गेस्ट रीड-बैक, क्रॉस-थ्रेड डिडअप, पीआईआई रिडक्शन।

यह वह पंक्ति है जिसके लिए मैंने तंत्रिका तंत्र पोस्ट में तर्क दिया है](/ पोस्ट/फ्रॉम-मेमोरी-टू-नर्वस-सिस्टम) और यह मुद्दों के उपयोग के मामले के अंतर्गत आता है। सब्सट्रेट यह तय नहीं करता है कि कौन से मुद्दे मायने रखते हैं, वृद्धि के साथ डिलीवरी का पुनः प्रयास नहीं करता है, अपनी स्वयं की घटनाओं की सदस्यता नहीं लेता है। यह संकेत देता है. ट्राइएज डेमॉन एक उपभोक्ता है, रिपोर्टर का एजेंट एक उपभोक्ता है, गिटहब मिरर एक उपभोक्ता है। प्रत्येक उपभोक्ता रुचि दर्ज करता है, निर्णय लेता है कि क्या करना है, और कार्य करता है। यदि मैं एक दूसरा ट्राइएज डेमॉन जोड़ना चाहता हूं जो सुरक्षा रिपोर्ट को अलग तरीके से संभालता है, तो यह एक अलग फिल्टर के साथ समान घटनाओं की सदस्यता लेता है। कोई नया सब्सट्रेट व्यवहार नहीं.

जैविक फ़्रेमिंग कायम है. सब्सट्रेट मस्तिष्क और संवेदी तंत्रिकाएं हैं: यह समस्या को संग्रहीत करता है, यह संकेत प्रसारित करता है कि कोई समस्या आ गई है। ट्राइएज डेमॉन और रिपोर्टर के एजेंट मोटर सिस्टम हैं: वे तय करते हैं कि सिग्नल के बारे में क्या करना है। नियोटोमा का एक संस्करण जिसने तीनों होने की कोशिश की, उसके बारे में तर्क करना कठिन होगा और विस्तार करना कठिन होगा। सिग्नलिंग पर रुकने वाला संस्करण तटस्थ रहता है।

## लूप इनहेरिट करना

जिस आकार का मैंने वर्णन किया है वह नियोटोमा के अपने मुद्दों के आसपास बनाया गया है, लेकिन सब्सट्रेट को इसकी कोई परवाह नहीं है। इसके शीर्ष पर निर्मित किसी भी चीज़ में अधिकांश समान मशीनरी विरासत में मिलती है।

प्रस्तुत करने का सामान्य पक्ष पहले से ही मौजूद है। `submit_entity` मनमाने इकाई प्रकारों के विरुद्ध रिपोर्ट स्वीकार करता है जब ऑपरेटर ने `submission_config` पंक्ति को अधिकृत करते हुए सीड किया है। वही अतिथि-टोकन अनुदान, वही वार्तालाप थ्रेडिंग, वही `add_entity_message` अनुवर्ती चैनल लागू होता है। `सब्सक्राइब` किसी भी इकाई प्रकार को एक फिल्टर के रूप में स्वीकार करता है, इसलिए एक तृतीय-पक्ष ऑपरेटर अपने कस्टम प्रकारों में रुचि दर्ज करके और `entity.created` और `entity.updated` घटनाओं पर ठीक उसी तरह प्रतिक्रिया करके अपना ट्राइएज डेमॉन चला सकता है, जिस तरह फॉर्मिका मुद्दों पर प्रतिक्रिया करता है।

व्यवहार में इसका क्या अर्थ है: यदि आप एक सामग्री पाइपलाइन, एक सुलह सेवा, या कोई भी उत्पाद चला रहे हैं जिसके उपयोगकर्ता एजेंट चलाते हैं, तो आप उन एजेंटों को आपके स्वामित्व वाली संस्थाओं के खिलाफ संरचित रिपोर्ट दर्ज करने दे सकते हैं - एक असफल पाइपलाइन रन, एक गलत वर्गीकृत रिकॉर्ड, एक सुलह अनुरोध - और उन्हें उसी सदस्यता तंत्र के माध्यम से अपनी तरफ ले सकते हैं। तार सामान्य है.

कुछ टुकड़े नियोटोमा के आज के मुद्दों पर विशेष रूप से केंद्रित हैं। पीआईआई रिडक्शन गार्ड वर्तमान में `submit_issue` पथ से जुड़ा हुआ है, न कि सामान्य `submit_entity` पथ से। GitHub मिररिंग समस्या-विशिष्ट है। दोनों ऑपरेशनल-लेयर एडिशन हैं जिन्हें एक तृतीय-पक्ष ऑपरेटर स्वयं वायर करेगा। सब्सट्रेट उन हिस्सों को संभालता है जिन्हें एक समान होना चाहिए - उद्गम प्रवर्तन, परमाणु संबंध निर्माण, थ्रेड तक अतिथि पहुंच, प्रत्येक लेखन पर घटना उत्सर्जन। वे हिस्से जो इस बात पर निर्भर करते हैं कि रिपोर्ट *के बारे में* क्या है, जहां से ऑपरेटर अपना पैसा कमाता है।

समस्या उपप्रणाली अधिक सामान्य पैटर्न का पहला पूर्ण उपभोक्ता है। यही आकार किसी भी संरचित सिग्नल पर लागू होता है जिसे एक एजेंट उस सिस्टम पर वापस भेजना चाहता है जिसके विरुद्ध वह चल रहा है।

## इंसान की समीक्षा क्यों रुक जाती है

दो चीजें मुझे `ऑटो_फिक्स: ट्रू` को वायर करने और डेमॉन द्वारा उत्पादित हर चीज को शिप करने के लिए प्रेरित करती हैं।

पहली सुविधा है. एक हरी पाइपलाइन जो मेरे सोते समय मुद्दों को बंद कर देती है, संतोषजनक है। दूसरा तथ्य यह है कि मुद्दों के एक सार्थक अंश के लिए, एजेंटिक योजना और अंतर सही हैं। मैंने यह जानने के लिए अब तक उनमें से काफी कुछ देख लिया है कि विफलता मोड आमतौर पर "गलत समाधान" नहीं होता है। यह आम तौर पर "गलत दायरे के लिए समाधान" होता है, जिसे एक कोड समीक्षा तीस सेकंड में पकड़ लेती है।

मैं मानवीय समीक्षा छोड़ रहा हूं क्योंकि एजेंट कभी-कभी आत्मविश्वास से निर्णयों के बारे में गलत होते हैं, जिसके नकारात्मक परिणाम वे नहीं देख पाते हैं। एक स्कीमा माइग्रेशन जो असफल परीक्षण को संतुष्ट करता है लेकिन एक असंबंधित एकीकरण को तोड़ देता है। एक रिडक्शन ट्विक जो तत्काल रिसाव को ठीक करता है लेकिन संबंधित गार्ड को ढीला कर देता है। एक निर्भरता बम्प जो बिल्ड त्रुटि को हल करता है और क्वेरी के डिफ़ॉल्ट व्यवहार को चुपचाप बदल देता है।

संवर्द्धन अनुरोध इसे और अधिक तीव्र करते हैं। बग की एक ज़मीनी सच्चाई होती है - या तो फ़ील्ड हटा दी जाती है या नहीं। एन्हांसमेंट एक डिज़ाइन दावा है जिसमें उपयोग पैटर्न, वास्तुशिल्प बाधाओं और ट्रेडऑफ़ के बारे में धारणाएं होती हैं जिन्हें रिपोर्टिंग एजेंट पूरी तरह से नहीं देख सकता है। संकेत मूल्यवान है; यह वास्तविक घर्षण को दर्शाता है, काल्पनिक घर्षण को नहीं। लेकिन इसके साथ क्या करना है इसका निर्णय एक इंसान का है जो पूरी तस्वीर देख सकता है।

जिन निर्णयों के लिए मनुष्य की आवश्यकता होती है वे ऐसे होते हैं जिनमें गलत होने की कीमत अधिक होती है और धीमे होने की कीमत कम होती है। वे मर्ज हैं - योजनाएँ, पैच, परीक्षण या पीआर विवरण नहीं। एजेंट बाकी सब कुछ संभाल लेते हैं। एजेंट प्रस्ताव रखते हैं; मनुष्य निर्णय लेते हैं.

## एजेंटिक लूप, अंत से अंत तक

ग्राहक अनुसंधान पोस्ट के साथ पढ़ें, आकृति अब सुपाठ्य है। सामने का आधा भाग: उपयोगकर्ता का एजेंट अपने वास्तविक वर्कफ़्लो के विरुद्ध नियोटोमा का मूल्यांकन करता है और यदि फिट है तो इसे स्थापित करता है। पिछला भाग: एजेंट बग, प्रदर्शन अवलोकन और एन्हांसमेंट अनुरोधों को उनके सामने आने पर फाइल करता है, और रखरखाव पक्ष उन्हें हल करता है - अक्सर इससे पहले कि उपयोगकर्ता को याद आए कि इसमें से कुछ भी दायर किया गया था।

दोनों हिस्से एक संरचित सतह के माध्यम से एजेंटों से बात करने पर काम करते हैं। वह घर्षण जिसने ऐतिहासिक रूप से अधिग्रहण लूप और फीडबैक लूप दोनों को खत्म कर दिया था, समाप्त हो गया है क्योंकि प्रत्येक अनुवाद चरण को टूल कॉल में समाहित कर लिया गया है। नीचे दिए गए सब्सट्रेट के बिना कोई भी आधा संभव नहीं होगा: एजेंट के नेतृत्व वाले मूल्यांकन के लिए उपयोगकर्ता के वर्कफ़्लो के बारे में संरचित स्थिति की आवश्यकता होती है, और मुद्दों के सबसिस्टम को इवेंट सिग्नलिंग और ट्रस्ट सीमाओं के पार अतिथि पहुंच की आवश्यकता होती है। दोनों एक ही आदिम पर निर्भर हैं।

## मैं क्या नहीं बना रहा हूं

मुद्दों के सबसिस्टम में प्रलोभन ऑर्केस्ट्रेशन की ओर बढ़ना है: एक प्राथमिकता मॉडल, स्वचालित एसएलए ट्रैकिंग, एक "स्मार्ट" राउटर जो यह तय करता है कि कौन सा डेमॉन किस प्रकार के मुद्दे को संभालता है। प्रत्येक अलगाव में उचित लगता है। उनमें से कोई भी सब्सट्रेट में नहीं है। ट्राइएज डेमॉन प्राथमिकता देता है। अनुरक्षक के एजेंट अपने स्वयं के प्रतिक्रिया समय को ट्रैक करते हैं। रूटिंग एक सदस्यता फ़िल्टर है.

यही बात पुनः प्रयास शब्दार्थ पर भी लागू होती है। यदि वेबहुक डिलीवरी विफल हो जाती है, तो सब्सट्रेट विफलता को लॉग करता है और आगे बढ़ता है। यह बैकअप चैनल तक नहीं बढ़ता है, रीप्ले के लिए बफर नहीं करता है, उपभोक्ता को ख़राब स्थिति में नहीं डालता है। संदेश दलाल यह सब करते हैं और वे इसमें अच्छे हैं; सब्सट्रेट कोई संदेश ब्रोकर नहीं है. जो उपभोक्ता गारंटीशुदा डिलीवरी चाहते हैं वे सिग्नल को अपने बुनियादी ढांचे में लपेट लेते हैं।

बाधा ही विशेषता है. एक राज्य परत जो मुद्दों का संकेत देती है लेकिन यह तय नहीं करती है कि कौन से मुद्दे मायने रखते हैं, एक राज्य परत है जिस पर कोई भी उपभोक्ता पूर्वानुमानित व्यवहार करने के लिए भरोसा कर सकता है।

## मुझे किस पर प्रतिक्रिया चाहिए

मुद्दों का सबसिस्टम लाइव है। यदि आपके पास नियोटोमा स्थापित है और आपका एजेंट कुछ गड़बड़ करता है - एक बग, एक प्रदर्शन अंतर, एक लापता क्षमता जो वह चाहता है - तो आपको अब उसे समस्या दर्ज करने के लिए कहने की आवश्यकता नहीं है। मौजूदा इंस्टाल पर इसे लेने के लिए, `npm install -g neotoma@latest` के साथ अपग्रेड करें। कॉन्फ़िगर करने के लिए प्रति-उपयोगकर्ता सहमति टॉगल नहीं है; सहमति स्थापित है. यदि यह एक नई स्थापना है, तो `नियोटोमा रिपोर्टर सेटअप` एक बार के रिपोर्टर-साइड कॉन्फ़िगरेशन के माध्यम से चलता है, इसलिए आपकी एजेंट फ़ाइलों को पहला मुद्दा कहीं न कहीं मिलता है।

यदि आपने अभी तक नियोटोमा स्थापित नहीं किया है, तो अपने एजेंट से मूल्यांकन पृष्ठ चलाने के लिए कहें। यदि यह निष्कर्ष निकलता है कि नियोटोमा फिट बैठता है, तो यह आपके कॉन्फ़िगरेशन दस्तावेज़ को पढ़े बिना इंस्टॉल और सक्रिय हो सकता है। यदि यह निष्कर्ष निकलता है कि नियोटोमा फिट नहीं बैठता है, तो यह भी एक वैध परिणाम है, और अधिकांश लैंडिंग पृष्ठों की तुलना में अधिक ईमानदार है।

यदि आप कोई ऐसा उत्पाद बना रहे हैं जिसके उपयोगकर्ता एजेंट चलाते हैं, तो मॉडल पोर्टेबल है। दिलचस्प काम तार के दोनों ओर नहीं है; यह तार ही है.