ब्लॉग · गाइड · 29 अक्टूबर 2026
AEGIS वर्कफ़्लो की स्टेटें और ट्रांज़िशन, कदम दर कदम
प्रकटीकरण: AEGIS को 100monkeys.ai बनाता है, इसलिए इस गाइड को बनाने वाले का विवरण मानकर पढ़ें। इसका मसौदा हमारे एक AI एजेंट ने सार्वजनिक AEGIS दस्तावेज़ों से तैयार किया, ख़ासकर Workflow Manifest Reference और CLI Reference से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। नीचे की हर YAML पंक्ति और हर कमांड उन्हीं पन्नों से कॉपी की गई है; इस गाइड के लिए कोई भी चलाई नहीं गई। उद्धरण अंग्रेज़ी में हैं, अनुवाद साथ में। जहाँ दस्तावेज़ कोई सवाल खुला छोड़ते हैं, आख़िरी हिस्सा यह बताता है।
AEGIS by 100monkeys.ai, in beta, किसी वर्कफ़्लो को एक YAML फ़ाइल में लिखी फ़ाइनाइट स्टेट मशीन की तरह चलाता है। संदर्भ दस्तावेज़ इसे "a durable, restartable sequence" (एक टिकाऊ, दोबारा शुरू की जा सकने वाली शृंखला) कहते हैं, जो एजेंटों, कंटेनरों, सिस्टम कमांडों और मानवीय अनुमोदन के पड़ावों का समन्वय करती है। यह गाइड एक बार में एक स्टेट लिखती है और दिखाती है कि इंजन अगली स्टेट कैसे चुनता है।
कदम 1. हेडर लिखें
apiVersion: 100monkeys.ai/v1
kind: Workflow
metadata:
name: dev-pipeline
version: "1.0.0"
apiVersion ठीक 100monkeys.ai/v1 होना चाहिए और kind ठीक Workflow। name ^[a-z0-9][a-z0-9-]{0,62}$ का पालन करता है, और नाम व वर्ज़न की जोड़ी अद्वितीय होनी चाहिए: किसी मौजूदा वर्ज़न को ओवरराइट करने के लिए force पैरामीटर चाहिए। metadata.input_schema वैकल्पिक है; अगर वह मौजूद है, तो रन शुरू होने से पहले कॉल करने वाले का इनपुट जाँचा जाता है, और जो पेलोड विफल हो वह "rejected with HTTP 422; no workflow execution is created." (HTTP 422 के साथ अस्वीकार होता है; कोई वर्कफ़्लो एक्ज़ीक्यूशन नहीं बनता)।
कदम 2. पहली स्टेट और सीमाओं का नाम दें
spec के नीचे initial_state ज़रूरी है और उसका spec.states में होना ज़रूरी है। दो सीमाएँ कभी न ख़त्म होने वाले लूप को रोकती हैं। spec.max_total_transitions का डिफ़ॉल्ट 50 है, अधिकतम 100, जिसके बाद "the workflow terminates" (वर्कफ़्लो समाप्त हो जाता है)। हर स्टेट के max_state_visits का डिफ़ॉल्ट 5 है, अधिकतम 20। हर स्टेट का एक timeout भी होता है, डिफ़ॉल्ट 300s। spec.context में वे स्थिरांक रहते हैं जिन्हें हर स्टेट {{workflow.context.KEY}} के रूप में पढ़ती है, जैसे इटरेशन की सीमा या कोई थ्रेशोल्ड।
कदम 3. हर स्टेट के लिए एक प्रकार चुनें
हर स्टेट एक kind बताती है। संदर्भ दस्तावेज़ आठ गिनाते हैं:
Agentएक डिप्लॉय किया गया एजेंट चलाता है और उसकाstatus,output,scoreऔरiterationsस्टेट के नाम के नीचे लिखता है।Systemएक शेलcommandचलाता है औरstdout,stderrऔरexit_codeदर्ज करता है।Actionवर्कफ़्लो का अपना कोई ऑपरेशन चलाता है, जैसेupdate_blackboardयाrepository_commit: "no agent chooses or calls it, and no shell runs." (कोई एजेंट इसे न चुनता है न बुलाता है, और कोई शेल नहीं चलता)।Humanरन को तब तक रोक देता है जब तक कोई व्यक्ति जवाब न दे।ParallelAgentsकई निर्णायक चलाता है और उनके स्कोर सहमति की एक रणनीति से जोड़ता है।ContainerRunऔरParallelContainerRunCI और CD के काम के लिए कंटेनर कदम चलाते हैं।Subworkflowकोई दूसरा वर्कफ़्लो शुरू करता है, रुककर या बिना इंतज़ार के, अधिकतम 10 की गहराई तक।
कदम 4. ट्रांज़िशन उसी क्रम में लिखें जिसमें आप उन्हें आज़माना चाहते हैं
ट्रांज़िशन "evaluated top-to-bottom. The first matching transition is taken." (ऊपर से नीचे जाँचे जाते हैं; पहला मेल खाने वाला ट्रांज़िशन लिया जाता है)। हर ट्रांज़िशन एक target स्टेट बताता है और, वैकल्पिक रूप से, एक condition। संदर्भ दस्तावेज़ के अपने उदाहरण की यह System स्टेट एग्ज़िट कोड पर शाखा बनाती है:
EXECUTE:
kind: System
command: python main.py
env:
CODE: "{{GENERATE.output}}"
PYTHONPATH: /workspace
transitions:
- condition: exit_code_zero
target: VALIDATE
- condition: exit_code_non_zero
target: REFINE
feedback: "Execution failed: {{EXECUTE.output.stderr}}"
हर प्रकार जिन शर्तों का उपयोग कर सकता है: ज़्यादातर प्रकारों के लिए on_success और on_failure; System और ContainerRun के लिए exit_code_zero, exit_code_non_zero और value के साथ exit_code; Human के लिए input_equals, input_equals_yes और input_equals_no; ParallelAgents के लिए consensus, all_approved और any_rejected; किसी भी प्रकार के लिए Handlebars expression के साथ custom; और बिना शर्त वाले आख़िरी विकल्प के रूप में always, या कोई शर्त नहीं। संदर्भ दस्तावेज़ की सलाह: "Always include an unconditional fallback as the last transition." (आख़िरी ट्रांज़िशन के रूप में हमेशा एक बिना शर्त वाला विकल्प रखें)।
कदम 5. स्कोर पर शाखा बनाएँ
VALIDATE:
kind: Agent
agent: judge-v1
transitions:
- condition: score_above
threshold: 0.95
target: COMPLETE
- condition: score_below
threshold: 0.95
target: REFINE
feedback: "{{VALIDATE.output.reasoning}}"
दोनों तुलनाएँ सख़्त हैं, इसलिए ठीक 0.95 का स्कोर ऊपर के किसी भी ट्रांज़िशन को नहीं लेता। स्कोर स्टेट के score से पढ़ा जाता है, वह न हो तो final_score से, वह भी न हो तो consensus.score से। जिस स्टेट के पास कोई स्कोर नहीं, वह किसी से मेल नहीं खाती, और अगर कुछ और भी मेल न खाए तो रन State "<name>" carries no score for its score transitions के साथ विफल होता है। Agent स्टेट के लिए score_between सीमाओं सहित min और max लेता है।
कदम 6. जो हुआ उसे अगली स्टेट तक ले जाएँ
किसी ट्रांज़िशन की feedback स्ट्रिंग उस स्टेट में {{state.feedback}} बन जाती है जहाँ वह ले जाता है; इसी तरह विफलता का संदेश दोबारा कोशिश करने वाले एजेंट तक पहुँचता है। हर पूरी हुई स्टेट Blackboard पर अपने नाम से लिखी जाती है, इसलिए बाद की स्टेटें {{EXECUTE.output.stdout}} या {{VALIDATE.score}} पढ़ती हैं। दो नेमस्पेस अलग रखें: {{input.KEY}} वह है जो कॉल करने वाले ने दिया और "is immutable" (अपरिवर्तनीय है), जबकि {{blackboard.KEY}} रन के साथ बढ़ता जाता है। जो टेम्पलेट ऐसी कुंजी का नाम ले जिसे अभी किसी स्टेट ने नहीं लिखा, वह ख़ाली स्ट्रिंग के बजाय एक दिखने वाला प्लेसहोल्डर बनाता है: स्टेट के नाम के साथ ERROR: missing key।
कदम 7. गार्ड के साथ लूप करें, और रन ख़त्म करें
REFINE:
kind: System
command: update_context
env:
ITERATION: "{{blackboard.iteration_number + 1}}"
ERRORS: "{{state.feedback}}"
transitions:
- condition: custom
expression: "{{blackboard.iteration_number < workflow.context.max_iterations}}"
target: GENERATE
- condition: custom
expression: "{{blackboard.iteration_number >= workflow.context.max_iterations}}"
target: FAILED
COMPLETE:
kind: System
command: finalize
transitions: []
transitions: [] वाली स्टेट अंतिम होती है: "When reached, the workflow execution completes with status completed." (वहाँ पहुँचने पर वर्कफ़्लो एक्ज़ीक्यूशन completed स्टेटस के साथ पूरा होता है)। केवल max_state_visits पर निर्भर रहने के साथ-साथ, ऊपर की तरह Blackboard पर लूप का अपना गार्ड भी रखें।
कदम 8. वैलिडेट, डिप्लॉय, रन करें और ट्रांज़िशन देखें
aegis workflow validate ./pipeline.yaml
aegis workflow deploy ./pipeline.yaml
aegis workflow run dev-pipeline --input '{"task": "..."}'
aegis workflow logs <execution_id> --transitions
validate मैनिफ़ेस्ट को स्थानीय रूप से जाँचता है; deploy उसे रजिस्टर करता है और किसी मौजूदा नाम और वर्ज़न पर विफल होता है, जब तक आप --force न जोड़ें; logs --transitions "state entries/exits only" (केवल स्टेटों में प्रवेश और निकास) दिखाता है, जो यह देखने का सबसे तेज़ तरीका है कि हर स्टेट ने कौन-सी शाखा ली।
दस्तावेज़ क्या खुला छोड़ते हैं
- पड़ाव के शब्द। Workflow Manifest Reference में
input_equals_yes"yes", "approve", "approved" या "true" स्वीकार करता है; Human Approvals पन्नाyes,yया1कहता है। किसी भी सूची पर भरोसा करने से पहले अपने पड़ाव की जाँच करें। - एक दूसरा सिंटैक्स। उसी पन्ने का Blackboard उदाहरण
kind: agent,input_templateऔर ट्रांज़िशन कोnext:के साथon: successके रूप में लिखता है, जबकि बाकी संदर्भkind: Agent,input,conditionऔरtargetलिखता है। पन्ना यह नहीं बताता कि इंजन दोनों स्वीकार करता है या नहीं। - टेम्पलेट में अंकगणित। उदाहरण
{{blackboard.iteration_number + 1}}सेट करता है, पर एक्सप्रेशन के लिए गिनाए गए ऑपरेटर केवल तुलना और तर्क के हैं, कोई+नहीं। - कोई मेल नहीं। स्कोर वाले मामले के अलावा, संदर्भ यह नहीं बताता कि जब कोई स्टेट ख़त्म हो और उसका कोई ट्रांज़िशन मेल न खाए तो क्या होता है।
- कितने प्रकार। दस्तावेज़ों की अनुक्रमणिका "all seven state kinds" (सभी सात स्टेट प्रकार) बताती है; संदर्भ की तालिका आठ गिनाती है।
आगे
Human स्टेट को गहराई से समझने के लिए, समीक्षक क्या देखता है और चुप्पी का क्या अर्थ है, पढ़ें ऑर्केस्ट्रेटर को अनुमोदन का चरण कैसे दें। AEGIS 100monkeys.ai पर छपी कमांड से इंस्टॉल होता है:
curl -fsSL https://get.100monkeys.ai | bash