Agent Execution Environment

Agent Execution Environment Triggerfish की स्व-विकास क्षमता है -- एक प्रथम-श्रेणी कोड workspace जहाँ agent कोड लिख सकता है, उसे निष्पादित कर सकता है, आउटपुट और त्रुटियाँ देख सकता है, समस्याएँ ठीक कर सकता है, और तब तक पुनरावृत्ति कर सकता है जब तक कुछ काम न कर जाए। यही वह है जो agent को एकीकरण बनाने, विचारों का परीक्षण करने, और अपने दम पर नए tools बनाने में सक्षम बनाता है।

Plugin Sandbox नहीं

Execution environment Plugin Sandbox से मूलभूत रूप से भिन्न है। अंतर समझना महत्वपूर्ण है:

• Plugin Sandbox सिस्टम को अविश्वसनीय तृतीय-पक्ष कोड से सुरक्षित करता है
• Exec Environment agent को अपना कोड लिखने, चलाने, और डीबग करने के लिए सशक्त बनाता है

Plugin sandbox रक्षात्मक है। Exec environment उत्पादक है। ये विपरीत उद्देश्यों की पूर्ति करते हैं और अलग-अलग सुरक्षा प्रोफ़ाइल रखते हैं।

पहलू	Plugin Sandbox	Agent Exec Environment
उद्देश्य	अविश्वसनीय कोड से सिस्टम सुरक्षित	Agent को चीज़ें बनाने के लिए सशक्त
फ़ाइलसिस्टम	कोई नहीं (पूरी तरह सैंडबॉक्स्ड)	केवल Workspace निर्देशिका
नेटवर्क	केवल घोषित endpoints	Policy-शासित allow/deny सूचियाँ
पैकेज इंस्टॉल	अनुमति नहीं	अनुमत (npm, pip, deno add)
निष्पादन समय	सख्त timeout	उदार timeout (कॉन्फ़िगर करने योग्य)
पुनरावृत्ति	एकल रन	असीमित write/run/fix लूप
स्थायित्व	अल्पकालिक	Workspace sessions में बना रहता है

फीडबैक लूप

मुख्य गुणवत्ता विभेदक। यह वही पैटर्न है जो Claude Code जैसे tools को प्रभावी बनाता है -- एक तंग write/run/fix चक्र जहाँ agent ठीक वही देखता है जो एक मानव डेवलपर देखेगा।

चरण 1: लिखें

Agent write_file का उपयोग करके अपने workspace में फ़ाइलें बनाता या संशोधित करता है। Workspace वर्तमान agent के लिए एक वास्तविक फ़ाइलसिस्टम निर्देशिका है।

चरण 2: निष्पादित करें

Agent run_command के माध्यम से कोड चलाता है, पूर्ण stdout, stderr, और exit code प्राप्त करता है। कोई आउटपुट छिपाया या सारांशित नहीं किया जाता। Agent ठीक वही देखता है जो आप terminal में देखेंगे।

चरण 3: अवलोकन करें

Agent पूर्ण आउटपुट पढ़ता है। यदि त्रुटियाँ हुईं, तो यह पूर्ण stack trace, त्रुटि संदेश, और नैदानिक आउटपुट देखता है। यदि परीक्षण विफल हुए, तो यह देखता है कि कौन से परीक्षण विफल हुए और क्यों।

चरण 4: ठीक करें

Agent जो देखा उसके आधार पर कोड संपादित करता है, विशिष्ट फ़ाइलों को अपडेट करने के लिए write_file या edit_file का उपयोग करता है।

चरण 5: दोहराएँ

Agent फिर से चलाता है। यह लूप तब तक जारी रहता है जब तक कोड काम नहीं कर जाता -- परीक्षण पास होना, सही आउटपुट उत्पन्न करना, या बताए गए लक्ष्य को प्राप्त करना।

चरण 6: बनाए रखें

एक बार काम करने के बाद, agent अपने काम को skill (SKILL.md + सहायक फ़ाइलें) के रूप में सहेज सकता है, इसे एकीकरण के रूप में पंजीकृत कर सकता है, इसे cron job में जोड़ सकता है, या इसे tool के रूप में उपलब्ध करा सकता है।

बनाए रखने का चरण वह है जो exec environment को एक scratchpad से अधिक बनाता है। काम करने वाला कोड बस गायब नहीं होता -- agent इसे एक पुन: प्रयोज्य skill में पैकेज कर सकता है जो शेड्यूल पर चलता है, triggers पर प्रतिक्रिया करता है, या माँग पर लागू किया जाता है। :::

उपलब्ध उपकरण

उपकरण	विवरण	आउटपुट
write_file	Workspace में फ़ाइल लिखें या अधिलेखित करें	फ़ाइल पथ, लिखे गए बाइट
read_file	Workspace से फ़ाइल सामग्री पढ़ें	स्ट्रिंग के रूप में फ़ाइल सामग्री
edit_file	फ़ाइल में लक्षित संपादन लागू करें	अपडेट की गई फ़ाइल सामग्री
run_command	Workspace में शेल कमांड निष्पादित करें	stdout, stderr, exit code, अवधि
list_directory	Workspace में फ़ाइलें सूचीबद्ध करें (पुनरावर्ती वैकल्पिक)	आकार के साथ फ़ाइल सूची
search_files	फ़ाइल सामग्री खोजें (grep-जैसा)	file:line संदर्भों के साथ मिलान पंक्तियाँ

Workspace संरचना

प्रत्येक agent को एक पृथक workspace निर्देशिका मिलती है जो sessions में बनी रहती है:

~/.triggerfish/workspace/
  <agent-id>/                     # प्रति-agent workspace
    scratch/                      # अस्थायी कार्य फ़ाइलें
    integrations/                 # विकसित किया जा रहा एकीकरण कोड
      notion-sync/
        index.ts
        index_test.ts
        package.json
      salesforce-report/
        main.py
        test_main.py
    skills/                       # लिखे जा रहे Skills
      morning-briefing/
        SKILL.md
        briefing.ts
    .exec_history                 # ऑडिट के लिए निष्पादन लॉग
  background/
    <session-id>/                 # पृष्ठभूमि कार्यों के लिए अस्थायी workspace

Workspaces agents के बीच पृथक हैं। एक agent दूसरे agent के workspace तक पहुँच नहीं सकता। पृष्ठभूमि कार्य (cron jobs, triggers) को session के लिए अपना अस्थायी workspace मिलता है।

सुरक्षा सीमाएँ

Exec environment plugin sandbox से अधिक अनुमोदक है, लेकिन फिर भी हर कदम पर policy-नियंत्रित है।

Policy एकीकरण

• प्रत्येक run_command कॉल कमांड को संदर्भ के रूप में PRE_TOOL_CALL hook सक्रिय करता है
• निष्पादन से पहले कमांड allowlist/denylist की जाँच की जाती है
• आउटपुट कैप्चर किया जाता है और POST_TOOL_RESPONSE hook से गुज़रता है
• निष्पादन के दौरान एक्सेस किए गए नेटवर्क endpoints को lineage के माध्यम से ट्रैक किया जाता है
• यदि कोड वर्गीकृत डेटा एक्सेस करता है (उदाहरण के लिए, CRM API से पढ़ता है), तो session taint बढ़ता है
• निष्पादन इतिहास ऑडिट के लिए .exec_history में लॉग किया जाता है

कठोर सीमाएँ

ये सीमाएँ कॉन्फ़िगरेशन की परवाह किए बिना कभी पार नहीं की जाती हैं:

• Workspace निर्देशिका के बाहर लिख नहीं सकता
• Denylist पर कमांड निष्पादित नहीं कर सकता (rm -rf /, sudo, आदि)
• अन्य agents के workspaces तक पहुँच नहीं सकता
• सभी नेटवर्क कॉल policy hooks द्वारा शासित
• सभी आउटपुट वर्गीकृत और session taint में योगदान करते हैं
• संसाधन सीमाएँ लागू: डिस्क स्थान, प्रति निष्पादन CPU समय, मेमोरी

सुरक्षा Agent द्वारा चलाया गया प्रत्येक कमांड PRE_TOOL_CALL hook से गुज़रता है। Policy engine निष्पादन शुरू होने से पहले इसे कमांड allowlist/denylist के विरुद्ध जाँचता है। खतरनाक कमांड नियतात्मक रूप से अवरुद्ध किए जाते हैं -- LLM इस निर्णय को प्रभावित नहीं कर सकता। :::

एंटरप्राइज़ नियंत्रण

एंटरप्राइज़ admins के पास exec environment पर अतिरिक्त नियंत्रण हैं:

• विशिष्ट agents या भूमिकाओं के लिए exec पूरी तरह अक्षम करें
• उपलब्ध runtimes प्रतिबंधित करें (उदाहरण के लिए, केवल Deno अनुमत, Python और shell अवरुद्ध)
• प्रति agent संसाधन सीमाएँ सेट करें (डिस्क कोटा, CPU समय, मेमोरी सीमा)
• Classification सीमा से ऊपर सभी exec ऑपरेशन के लिए अनुमोदन आवश्यक
• डिफ़ॉल्ट खतरनाक-कमांड सूची से परे कस्टम कमांड denylist