100monkeys.ai

ब्लॉग · गाइड · 28 अक्टूबर 2026

AEGIS का execution लॉग पढ़ना: सील किया गया टूल कॉल क्या दर्ज करता है

अन्य भाषाओं में: English, Español, Português, 日本語, Deutsch, Français, 한국어, 简体中文, Italiano · हिन्दी में सभी गाइड

खुलासा: AEGIS को 100monkeys.ai बनाता है, इसलिए इस गाइड को निर्माता का विवरण मानकर पढ़ें। इसका मसौदा हमारे एक AI एजेंट ने AEGIS के सार्वजनिक दस्तावेज़ों से तैयार किया, मुख्यतः Deploying & Running Agents, CLI Reference, SEAL Protocol और गेटवे के Observability पन्ने से, और कंपनी ने इसकी समीक्षा की; यह हिन्दी संस्करण मूल अंग्रेज़ी गाइड का अनुवाद है। नीचे दी गई लॉग पंक्तियाँ, फ़ील्ड और कोड डॉक्स के अपने उदाहरण हैं, इस गाइड के लिए हमारा कैप्चर किया आउटपुट नहीं।

AEGIS by 100monkeys.ai, in beta, हर एजेंट को उसके अपने अलग रनटाइम में चलाता है और उसके टूल कॉल SEAL नाम के एक हस्ताक्षरित प्रोटोकॉल से भेजता है। यह गाइड एक रन को बाहर से अंदर की ओर पढ़ती है: execution रिकॉर्ड, iteration लॉग, और फिर SEAL परत एक अकेले टूल कॉल के बारे में क्या दर्ज करती है, चाहे वह अनुमत हो या अस्वीकृत।

इकाई execution क्यों है

Executions पन्ना साफ़ कहता है: "Each execution is the unit of observability and replay in AEGIS. Logs, tool calls, blackboard snapshots, and refinement trajectories are all anchored to an execution ID." (AEGIS में हर execution ऑब्ज़र्वेबिलिटी और रीप्ले की इकाई है। लॉग, टूल कॉल, blackboard स्नैपशॉट और सुधार के क्रम, सब एक execution ID से जुड़े हैं।) नीचे का हर चरण उसी id से शुरू होता है। एक execution "Execute, Evaluate, Refine" (चलाओ, परखो, सुधारो) का लूप चलाता है और ख़त्म होता है "when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs." (जब एजेंट ऐसा आउटपुट दे जो उसके मूल्यांकन मानदंड पूरे करे, जब iteration का बजट ख़त्म हो जाए, या जब कोई ऐसी विफलता हो जिससे उबरा न जा सके।)

चरण 1. execution id खोजें

aegis task execute शुरू होते ही इसे छापता है (Execution started: <id>)। जो रन आपने ख़ुद शुरू नहीं किए, उनकी सूची देखें:

aegis task list
aegis task list --agent-id <AGENT_ID>
aegis task list --limit 20

शेड्यूल किया गया रन अपना execution id शेड्यूल की रन सूची में रखता है; वर्कफ़्लो रन aegis workflow executions list में दिखता है।

चरण 2. execution रिकॉर्ड पढ़ें

aegis task status <EXECUTION_ID> --output json

डॉक्स के अनुसार यह "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores." (execution रिकॉर्ड लौटाता है, जिसमें स्थिति, शुरू और ख़त्म होने का समय, कुल iteration, और हर iteration की स्थिति और वैलिडेशन स्कोर शामिल हैं।) पहले iteration की संख्या पढ़ें। एक सफल iteration का मतलब साफ़ रन है; कई iteration का मतलब है कि आउटपुट वैलिडेशन में विफल हुआ और सुधारा गया, और लॉग बताएगा क्यों।

चरण 3. iteration लॉग पढ़ें

aegis task logs <EXECUTION_ID>

डॉक्स का उदाहरण कि एक रन क्या छापता है, पंक्ति दर पंक्ति:

[2026-02-23T10:00:01Z] Execution a1b2c3d4-1111-... Started
[2026-02-23T10:00:01Z] Iteration 1 Started
[2026-02-23T10:00:03Z] Tool: fs.write /workspace/solution.py (234 bytes)
[2026-02-23T10:00:04Z] Tool: cmd.run python /workspace/solution.py
[2026-02-23T10:00:05Z] Tool: fs.write /workspace/result.json (89 bytes)
[2026-02-23T10:00:06Z] Iteration 1 Completed
[2026-02-23T10:00:06Z] Validation: exit_code=PASS json_schema=PASS (score=1.0)
[2026-02-23T10:00:06Z] Execution a1b2c3d4-1111-... Completed (1 iteration, 5.2s)

इसे तीन तरह की पंक्तियों के रूप में पढ़ें: जीवनचक्र (शुरू हुआ, पूरा हुआ), एजेंट के हर कॉल के लिए एक Tool: पंक्ति, और हर वैलिडेटर के फ़ैसले व स्कोर के साथ एक Validation: पंक्ति। सिर्फ़ विफलताएँ देखने के लिए --errors-only, ज़्यादा विवरण के लिए --verbose, और चलते रन को देखने के लिए --follow जोड़ें। वर्कफ़्लो के लिए aegis workflow logs <EXECUTION_ID> --transitions सिर्फ़ स्थिति बदलाव दिखाता है।

चरण 4. जानें कि हर Tool पंक्ति के पीछे क्या है

हर Tool: पंक्ति एक कॉल है जो SEAL से होकर गया। "Every tool call is wrapped in a SealEnvelope" (हर टूल कॉल एक SealEnvelope में लपेटा जाता है): प्रोटोकॉल (seal/v1), एक security_token (attestation पर जारी JWT), एक Ed25519 signature, payload (MCP जैसे कॉल के लिए JSON-RPC tools/call), एक container_id और एक पूर्णांक timestamp।

टोकन के claims ही कॉल को आपके रन से जोड़ते हैं: sub (कॉल करने वाला), scp (सुरक्षा संदर्भ का नाम), wid (वर्कलोड), और exec_id, जो "ties every call in a session to one audit chain" (एक सत्र के हर कॉल को एक ही ऑडिट शृंखला से जोड़ता है)। इसलिए चरण 1 का execution id ही वह चाबी है जो लॉग पंक्ति को उसके लिफ़ाफ़े से जोड़ती है।

चरण 5. पढ़ें कि कोई कॉल क्यों अनुमत हुआ

कॉल आगे भेजने से पहले गेटवे नौ जाँचें करता है: प्रोटोकॉल फ़ील्ड, टोकन का हस्ताक्षर और समाप्ति, कॉल करने वाले की पंजीकृत कुंजी, एक मानक संदेश पर लिफ़ाफ़े का हस्ताक्षर, 30 सेकंड के भीतर का timestamp, और आख़िर में scp में नामित सुरक्षा संदर्भ। वह आख़िरी जाँच निषेध सूची की हर चीज़ को मना करती है, कॉल को तभी अनुमति देती है जब कोई क्षमता उसके टूल, पाथ, डोमेन या सबकमांड और दर सीमा से मेल खाए, और बाक़ी सब में मना करती है "(default deny)" (डिफ़ॉल्ट रूप से मना)। सत्र के बीच संदर्भ बदल नहीं सकता: "callers cannot widen their context, switch contexts, or impersonate a different one." (कॉल करने वाले न अपना संदर्भ बढ़ा सकते हैं, न बदल सकते हैं, न किसी और का रूप धर सकते हैं।)

चरण 6. एक अस्वीकृति पढ़ें

अस्वीकृत कॉल लॉग में कोई चुप ख़ाली जगह नहीं है। SEAL Gateway पर वह एक संख्या वाले कोड से जवाब देता है। जो सबसे ज़्यादा मिलेंगे:

डॉक्स कहते हैं "switch on error.code, not on the status" (फ़ैसला error.code पर करें, स्थिति पर नहीं), और एक जाल बताते हैं: ऑर्केस्ट्रेटर का अपना POST /v1/seal/invoke अस्वीकृति का जवाब संख्या के बजाय TOOL_NOT_ALLOWED जैसे शब्द-कोड से देता है।

चरण 7. ऑडिट रिकॉर्ड पढ़ें

SEAL Protocol पन्ना हर कॉल से बनने वाले इवेंट गिनाता है, जिनमें ToolCallAuthorized और PolicyViolationBlocked हैं, और हर एक क्या दर्ज करता है: लिफ़ाफ़े का हस्ताक्षर, timestamp और jti; टोकन के sub, scp, wid और exec_id; टूल का नाम और "payload digest (not the full payload, payloads are not logged by default)" (payload का डाइजेस्ट, पूरा payload नहीं; डिफ़ॉल्ट रूप से payload दर्ज नहीं होते); और "the policy decision (ALLOW or DENY plus the deciding rule, if any)" (नीति का फ़ैसला, ALLOW या DENY, और फ़ैसला करने वाला नियम, अगर कोई हो)। हस्ताक्षर ही इनकार न कर पाने की गारंटी देता है: "only the holder of the ephemeral private key could have produced a valid signature." (वैध हस्ताक्षर सिर्फ़ उस अल्पकालिक निजी कुंजी का धारक ही बना सकता था।)

अलग चलने वाले SEAL Gateway पर ये पंक्तियाँ gateway_events टेबल में रहती हैं। इनके लिए अभी कोई REST endpoint नहीं है; डॉक्स इसके बजाय SQL देते हैं:

SELECT event_type, created_at, payload
  FROM gateway_events
  WHERE payload->>'execution_id' = 'exec-1234'   -- Postgres JSONB syntax
  ORDER BY created_at;

टेबल में सिर्फ़ जोड़ा जाता है, इसलिए पिछली भेजी गई id से बड़ी id खोजकर इसे अपने SIEM तक भेजें।

डॉक्स क्या खुला छोड़ते हैं

आगे

इन लॉग के साथ समीक्षक को और क्या चाहिए, इसके लिए पढ़ें प्रोडक्शन में AI एजेंटों के लिए ट्रेसबिलिटी चेकलिस्ट।

100monkeys.ai से AEGIS इंस्टॉल करें