DeepSeek Superagent ट्यूटोरियल: CI देखें और मरम्मत को अधिकृत करें

DeepSeek Superagent क्या है?

DeepSeek Superagent, DeepSeek Harness के जरिए एक GitHub रिपॉज़िटरी पर नज़र रखता है। टीम के नियम तय करते हैं कि कोई ईवेंट काम के लायक है या नहीं; स्वीकृत काम अलग सत्र में जाता है। यह ट्यूटोरियल प्रकाशित प्रोटोटाइप को कवर करता है, न कि केवल डिज़ाइन-भर विचारों को।

Harness रनटाइम देता है; Superagent ईवेंट मॉनिटरिंग और ऑथराइज़ेशन जोड़ता है। हमारा एजेंट हार्नेस समझौता टूल्स, मेमोरी, और नियंत्रण को कवर करता है।

DeepSeek Superagent कैसे काम करता है?

एक नया GitHub ईवेंट चार चरणों से गुजर सकता है। ये चरण निर्णय और कोड परिवर्तन को अलग रखते हैं:

• स्रोत और ट्रिगर: GitHub पोलिंग प्रत्येक ईवेंट को किसी Issue, पुल रिक्वेस्ट, या main पर एक ट्रिगर में बदलता है।

• प्रवेश (Admission): गेट इसे स्पष्ट अनुरोध, अनुमानित उम्मीदवार, या कुछ नहीं के रूप में लेबल करता है।

• मूल्यांकन और निर्णय:  अनुमानित CI को नियमों के खिलाफ आँका जाता है। एक स्पष्ट अनुरोध को स्वीकार निर्णय पर रूट किया जाता है, कारण explicitRouted।

• टिकट और एग्ज़ीक्यूटर: स्वीकृत काम को उसकी अनुमति, वर्कर सत्र, और डायरेक्टरी मिलती है।

टिकट के थ्रेड पर बाद की टिप्पणी उसके वर्कर के पास जाती है, नए Eval के बिना। आरेख तीन GitHub पथ दिखाता है: डिफ़ॉल्ट-ब्रांच CI, एक स्पष्ट अनुरोध, और वह समीक्षा। CI पथ के भीतर, observe और auto एक मेल खाते नियम पर अलग-अलग सिरों पर हैं।

CI का मूल्यांकन होता है। अनुरोध काम शुरू करते हैं। चित्र: लेखक द्वारा।

observe मोड और auto मोड में क्या अंतर है?

स्वीकार (accept) मोड केवल उस काम पर लागू होता है जिसे Superagent ने किसी ईवेंट से अनुमानित किया हो। तीन सेटिंग्स में से एक चुनें:

• off अनुमानित उम्मीदवारों को हटा देता है।

• observe उनका मूल्यांकन करता है, लेकिन सकारात्मक परिणाम को "स्वीकार करेंगे" के रूप में रिकॉर्ड करता है।

• auto सकारात्मक मूल्यांकन के बाद काम शुरू करता है।

किसी अधिकृत व्यक्ति का अनुरोध हर मोड में काम करता है और अपना Ticket बनाता है। इस ट्यूटोरियल के लिए auto बंद रखें।

Observe मोड में CI मरम्मत वर्कफ़्लो बनाएँ

पाइपलाइन s pytest और दो GitHub Actions जॉब का उपयोग करती है जो ईवेंट्स को दैनिक रेवेन्यू में बदलते हैं। Superagent काम शुरू होने से पहले एक निर्णय जोड़ता है। हमारा Claude Code Routines ट्यूटोरियल एक अन्य ईवेंट-चालित वर्कफ़्लो कवर करता है।

दैनिक रेवेन्यू में रीप्ले बग ट्रेस करें

यह बग रीप्ले हुए भुगतान को दो बार गिनता है। प्रत्येक पंक्ति में एक event_id, order_id, टाइमस्टैम्प्स, और एक राशि होती है। एक ऑर्डर में कई वैध भुगतान हो सकते हैं।

इसीलिए order_id पर डुप्लीकेट हटाना (dedup) रीप्ले टेस्ट पास कर सकता है लेकिन असली भुगतानों को हटा देगा; सही कुंजी event_id है। एजेंट को अधिकृत करने से पहले Python के csv मॉड्यूल से अपेक्षित योग की गणना करें, ताकि एजेंट का आउटपुट उत्तर कुंजी न बन जाए।

सफल CI मरम्मत को परिभाषित करें

सफलता इस पर निर्भर करती है कि वर्कफ़्लो क्या करता है, न कि सिर्फ एजेंट क्या कहता है। रिपॉज़िटरी बदलने से पहले ये शर्तें तय करें:

• केवल दस्तावेज़ीकरण से जुड़ी विफलता को नज़रअंदाज़ करें।

• बिना काम शुरू किए revenue-integrity से मेल खाएँ।

• केवल स्पष्ट अनुरोध के बाद पुल रिक्वेस्ट खोलें।

• असर्शन सुरक्षित रखें और पहले से बने होल्डआउट सूट को पास करें।

Superagent को एक्सेस मिलने से पहले होल्डआउट सूट तैयार करें। यह अपेक्षित व्यवहार को वर्कर के विकास इनपुट्स से बाहर रखता है।

DeepSeek Superagent की पूर्वापेक्षाएँ और पृथक्करण

आपको एक DeepSeek API कुंजी, दो GitHub खाते, और एक डिस्पोज़ेबल Linux वातावरण चाहिए। Harness की मूल बातें देखने के लिए हमारा बेसिक सेटअप गाइड देखें।

ज़रूरी सॉफ़्टवेयर और अकाउंट्स

सॉफ़्टवेयर वर्ज़न पिन करें ताकि अपग्रेड वर्कफ़्लो न बदल दे। अंतिम कॊलुmn बाद में लेख में दिए परिणामों के लिए इस्तेमाल किए सेटअप को दर्ज करता है:

एजेंट को अपने ओन GitHub यूज़र पर लिखने का एक्सेस चाहिए क्योंकि Superagent उसी अकाउंट की सूचनाएँ पढ़ता है। केवल उन्हीं मानव मेंटेनर्स को allowed सूची में जोड़ें जो काम को अधिकृत कर सकते हैं।

एजेंट को निजी फ़ाइलों से अलग रखें

दोनों प्रीसेट OS यूज़र को पूरा एक्सेस देते हैं, और gh रैपर प्रोसेस को आइसोलेट नहीं करता। एक नया WSL डिस्ट्रीब्यूशन उपयोग करें जिसमें ऑटोमाउंट और इंटरॉप बंद हों:

यदि आपके पास पहले से डिस्पोज़ेबल Linux वर्चुअल मशीन है, तो WSL ब्लॉक छोड़ दें और उसी का उपयोग करें। असंबंधित क्रेडेंशियल्स और फ़ाइलें उससे दूर रखें।

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagentसंचालित द्वारा

समर्पित superagent यूज़र के पास केवल DeepSeek कुंजी और एजेंट टोकन होने चाहिए। यह आकस्मिक एक्सेस कम करता है लेकिन कोई सुरक्षा सीमा नहीं है; माइक्रोसॉफ़्ट का WSL सुरक्षा मॉडल अविश्वसनीय कोड के लिए WSL के बाहर अलग से मैनेज्ड वर्चुअल मशीन की सिफ़ारिश करता है।

GitHub पर main को आवश्यक पुल रिक्वेस्ट, कम से कम एक स्वतंत्र स्वीकृति, और दोनों CI चेक्स से सुरक्षित करें। एजेंट को एडमिन बाइपास के बिना लिखने का एक्सेस दें। इनमें से कोई भी Issue टेक्स्ट से प्रॉम्प्ट इंजेक्शन को नहीं रोकता।

चरण 1: Python रेवेन्यू पाइपलाइन और CI बेसलाइन बनाएँ

प्रकाशित ट्यूटोरियल रिपॉज़िटरी में अब मरम्मत main में मर्ज हो चुकी है, इसलिए उसकी वर्तमान ब्रांच को आरंभिक स्थिति के रूप में उपयोग न करें। तीन चरणों को अलग करने के लिए इन कमिट्स का उपयोग करें:

नीचे दी गई पाइपलाइन और टेस्ट ग्रीन बेसलाइन (a6d2036) से सरल रूप हैं, वर्तमान main से नहीं लिए गए। CI चरणों का पालन करने से पहले उस कमिट से एक डिस्पोज़ेबल रिपॉज़िटरी बनाएं:

git clone https://github.com/KhalidAbdelaty/superagent-revenue-lab.git revenue-lab
cd revenue-lab
git switch -C main a6d2036
git remote remove origin

export EXPERIMENT_REPO="YOUR_LOGIN/superagent-revenue-lab"
gh repo create "$EXPERIMENT_REPO" --private --source=. --remote=origin --pushसंचालित द्वारा

नियंत्रित विफलताओं और एजेंट की ब्रांचों के लिए इस नई रिपॉज़िटरी का उपयोग करें। प्रकाशित रिपॉज़िटरी को अपरिवर्तित छोड़ें; उसके घटना और समाधान कमिट तुलना के लिए संदर्भ हैं।

"""Daily revenue report built from payment events."""
import pandas as pd


def load_events(path):
    """Read payment events; amounts are integer cents."""
    return pd.read_csv(path, parse_dates=["occurred_at", "received_at"])


def daily_revenue(events):
    """Return one row per UTC day with total revenue in cents."""
    days = events["occurred_at"].dt.strftime("%Y-%m-%d")
    report = (
        events.assign(day=days)
        .groupby("day", as_index=False)["amount_cents"]
        .sum()
        .rename(columns={"amount_cents": "revenue_cents"})
    )
    return reportसंचालित द्वारा

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

import pandas as pd


def test_daily_totals_match_known_values():
    report = daily_revenue(load_events(DATA))
    assert report["revenue_cents"].tolist() == [20398, 27550]


def test_events_on_the_same_order_are_all_counted():
    t = pd.Timestamp(0, unit="s", tz="UTC")
    events = pd.DataFrame({
        "event_id": ["evt_a", "evt_b"],
        "order_id": ["ord_1", "ord_1"],
        "occurred_at": [t, t],
        "received_at": [t, t + pd.Timedelta(seconds=1)],
        "amount_cents": [1000, 250],
    })
    assert daily_revenue(events)["revenue_cents"].tolist() == [1250]संचालित द्वारा

हर जॉब का नाम उसी व्यवहार पर रखें जिसकी वह जाँच करता है। वही नाम बाद में GitHub और Superagent के ट्रिगर टेक्स्ट में दिखेंगे:

name: ci
on:
  push:
    branches: [main]
  pull_request:

jobs:
  revenue-integrity:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install -r requirements.txt   # pandas==2.3.3, pytest==8.4.2
      - run: pytest -v

  docs-check:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: python scripts/check_docs.py      # fails if README links a missing fileसंचालित द्वारा

यदि साधारण pytest revenue को इम्पोर्ट नहीं कर पाता, तो pytest.ini में pythonpath = . जोड़ें। Superagent इंस्टॉल करने से पहले सुनिश्चित करें कि दोनों जॉब्स main पर पास हों।

प्रकाशित experiment/holdout डायरेक्टरी मूल रन का दस्तावेज़ीकरण करती है, लेकिन पब्लिक क्लोन में दिखती है। नए प्रयोग के लिए, एक ताज़ा सूट हर उस चेकआउट और फाइल सिस्टम के बाहर बनाएँ जिसे वर्कर पढ़ सकता है।

मरम्मत अनुरोध भेजने से पहले उस सूट का हैश करें। ये मामले कवर करें:

• एक ही ईवेंट की बार-बार डिलीवरी।
• एक ही ऑर्डर ID वाले अलग ईवेंट।
• एक इनपुट DataFrame जो अपरिवर्तित रहना चाहिए।
• अपेक्षित आउटपुट कॉलम और सॉर्ट ऑर्डर।

समीक्षा तक यह सूट छुपा कर रखें। चरण 6 में, वर्कर के पूरा करने के बाद, अलग मानव वातावरण से इसे चलाएँ।

निम्नलिखित आरेख वर्कर के विकास इनपुट्स को मेंटेनर की अंतिम जाँच से अलग करता है।

होल्डआउट डेटा वर्कर के बाहर रहता है। चित्र: लेखक द्वारा।

चरण 2: DeepSeek Superagent इंस्टॉल करें और GitHub से जोड़ें

बंडल को एक समर्पित Harness प्रोफ़ाइल में इंस्टॉल करें, जो दैनिक काम में उपयोग होने वाली प्रोफ़ाइल से अलग हो। एजेंट अकाउंट का टोकन AGENT_GH_TOKEN में लोड करें, बिना रिपॉज़िटरी में लिखे। फिर ये कमांड superagent यूज़र के रूप में चलाएँ:

npm install -g @deepseek-ai/[email protected] [email protected]

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git ~/dsh-superagent
cd ~/dsh-superagent
git checkout --detach 8c32a9dc5d72c033816c6a8110b37f40cf94fba4
pnpm install && pnpm build

# A gh wrapper that only ever sees the agent account
mkdir -p "$HOME/.local/bin"
export PATH="$HOME/.local/bin:$PATH"
cat > ~/.local/bin/gh-agent <<'W'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
W
chmod +x ~/.local/bin/gh-agent
printf '%s' "$AGENT_GH_TOKEN" | gh-agent auth login --hostname github.com --with-token
gh-agent api user --jq .login            # your dedicated agent account

# Dedicated profile, then the bundle
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"संचालित द्वारा

नोट: इस ट्यूटोरियल में रन कमिट 6337fc8 पर हुए, जिसे बाद में DeepSeek ने 8c32a9d में स्क्वैश किया।

क्लोन की गई रिपॉज़िटरी में प्रोफ़ाइल उदाहरण का उपयोग कर एक स्टेट डायरेक्टरी सेट करें और पैनल को 127.0.0.1:3082 से बाँधें। फिर tmux में सर्विस शुरू करें:

scripts/dsh-superagent start
scripts/dsh-superagent statusसंचालित द्वारा

यह प्रोफ़ाइल सर्विस रीस्टार्ट्स को व्यक्तिगत Harness सत्रों से अलग करती है। यह प्लगइन के PATH और Git सेटिंग्स को सामान्य प्रोफ़ाइल से बाहर भी रखती है।

status सेटअप लंबित या repositoryUnset रिपोर्ट कर सकता है जब तक आप चरण 3 में GitHub स्रोत (Source) सेव नहीं करते। इस बिंदु पर केवल यह पक्का करें कि रनटाइम जवाब दे रहा है और Superagent पैनल खुलता है; अभी Source या CI बेसलाइन की उम्मीद न करें।

समर्पित प्रोफ़ाइल में Settings → Models खोलें और deepseek-flash चुनें। Superagent → Settings → Eval और Execution में पुष्टि करें कि दोनों भूमिकाएँ प्रोफ़ाइल मॉडल विरासत में लेती हैं या deepseek-flash को स्पष्ट रूप से नाम दें।

चरण 3: Observe मोड में GitHub Actions मॉनिटरिंग कॉन्फ़िगर करें

स्रोत, पॉलिसी, नियम, और एग्ज़ीक्यूटर सेटिंग्स सेव करते समय डिफ़ॉल्ट-ब्रांच CI ऑब्ज़र्वेशन ऑफ़ रखें। नई रिपॉज़िटरी पर main ग्रीन होने के बाद ही इसे ऑन करें, ताकि पहली रीडिंग एक साफ बेसलाइन रिकॉर्ड करे।

GitHub स्रोत कॉन्फ़िगर करें

Settings → Sources में, रिपॉज़िटरी को EXPERIMENT_REPO पर सेट करें, CLI फ़ील्ड को समर्पित gh-agent रैपर की ओर इंगित करें, और डिफ़ॉल्ट-ब्रांच CI ऑब्ज़र्वेशन ऑफ़ रखें। Source सेव करें और पॉलिसी बदलने से पहले किसी भी रीस्टार्ट का इंतज़ार करें।

CI प्रवेश पॉलिसी कॉन्फ़िगर करें

CI परिणाम का कोई सेंडर नहीं होता। इसके Admission रो में एक ही सेल होता है, जो डिफ़ॉल्ट रूप से ignore रहता है। यदि आप वह सेटिंग नहीं बदलते, तो Eval तक CI पहुँचता ही नहीं।

सीमित revenue-integrity नियम परिभाषित करें

उदाहरण नियमों को हटाकर चेक के नाम पर एक नियम रखें। मूल्यांकनकर्ता को कारणों का अनुमान न लगाने को कहें:

{
  "rules": [{
    "id": "revenue-integrity",
    "name": "Revenue integrity CI failures",
    "enabled": true,
    "instruction": "A default-branch CI result in which the check named revenue-integrity newly fails. That check executes the pytest suite guarding the daily revenue totals. Judge only from the check names and results you can read for that commit; do not guess a root cause. Failures limited to other checks, such as docs-check (README links), do not match. A recovery where every check passes does not match. Work, if accepted: investigate the failing revenue-integrity tests, fix the pipeline without weakening or deleting any assertion, add a regression test, and open a pull request for human review. Never merge."
  }],
  "sources": {"github": {
    "allowed": [{"id": "<human-login>"}],
    "bots": [],
    "admission": {"ci": {"unlistedUnaddressed": "inferred"}}
  }}
}संचालित द्वारा

एक prepare कमांड जोड़ें जो हर Ticket के लिए Git worktree बनाता है। प्रत्येक वर्कर तब एक रिपॉज़िटरी चेकआउट से शुरू करता है:

C=/home/superagent/src/superagent-revenue-lab
git -C $C fetch --no-tags "https://github.com/$DSH_SUPERAGENT_GITHUB_REPOSITORY.git" \
  "${DSH_SUPERAGENT_GITHUB_PR_HEAD:-HEAD}:refs/dsh-superagent/$DSH_SUPERAGENT_TICKET" &&
git -C $C worktree add -b "agent/$DSH_SUPERAGENT_NAME" "$DSH_SUPERAGENT_DIR" "refs/dsh-superagent/$DSH_SUPERAGENT_TICKET"संचालित द्वारा

Superagent हर Ticket के लिए ये वेरिएबल भर देता है। अधिकृत करने से पहले जाँच लें कि प्राप्त डायरेक्टरी में अपेक्षित चेकआउट है।

वैकल्पिक कॉन्फ़िगरेशन हेल्पर वही Source, पॉलिसी, Eval, और एग्ज़ीक्यूटर ब्लॉक लिखता है। यह पहले पास में CI ऑब्ज़र्वेशन ऑफ़ रखता है; हमेशा प्रयोगात्मक रिपॉज़िटरी और allowed अनुरोधकर्ता को स्पष्ट रूप से सेट करें:

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh allसंचालित द्वारा

प्रोएक्टिव एक्ज़ीक्यूशन अक्षम रखें

Eval को observe में रखें, प्रोफ़ाइल के डिफ़ॉल्ट मॉडल के साथ। हर ईवेंट के बाद, Eval टैब में Decision और Execution टैब में किसी Ticket को देखें।

CI ऑब्ज़र्वेशन ऑन करें और बेसलाइन रिकॉर्ड करें

जब दोनों GitHub Actions जॉब्स main पर पास हो जाएँ, तो डिफ़ॉल्ट-ब्रांच CI ऑब्ज़र्वेशन ऑन करें। हेल्पर स्क्रिप्ट के साथ, दूसरा पास उपयोग करें:

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh showसंचालित द्वारा

पहली रीडिंग बिना काम बनाए स्टेट रिकॉर्ड करती है। सभी चार शर्तें जाँचें:

• सेटअप कोई पेंडिंग आवश्यकता नहीं दिखाता।

• GitHub Source ready रिपोर्ट करता है।

• Source एक साफ CI बेसलाइन रिकॉर्ड करता है।

• ट्रिगर और Execution टैब्स कोई बेसलाइन ट्रिगर या Ticket नहीं दिखाते।

यदि इनमें से कोई चेक असफल हो, तो दस्तावेज़ीकरण विफलता बनाने से पहले रुकें। Source और Eval स्क्रीनशॉट अंतिम कॉन्फ़िगरेशन दिखाते हैं।

CI ऑब्ज़र्वेशन के साथ GitHub Source कार्ड। चित्र: लेखक द्वारा।

Eval सेटिंग्स: एक नियम, observe मोड। चित्र: लेखक द्वारा।

चरण 4: एक असंबंधित GitHub Actions विफलता जाँचें

एक टूटे हुए README लिंक का उपयोग असंबंधित विफलता के रूप में करें। क्योंकि प्रोटेक्टेड ब्रांच असफल चेक को अस्वीकार करता है, केवल इस डिस्पोज़ेबल रिपॉज़िटरी में मानव प्रशासक का बाइपास उपयोग करें; एजेंट को वह बाइपास कभी न दें।

sed -i 's|^- Tests: .*|&\n- Data dictionary: [docs/data-dictionary.md](docs/data-dictionary.md)|' README.md
git commit -am "docs: link the data dictionary from the README" && git pushसंचालित द्वारा

GitHub Actions के पूरा होने पर, docs-check असफल और revenue-integrity पास हुआ। यह मेरे द्वारा सेट किए गए नियम से मेल खाता था: रेवेन्यू नियम मेल न खाने के कारण Superagent ने उम्मीदवार को नज़रअंदाज़ कर दिया।

Decision में ignoredFromCard आया, जो उन उम्मीदवारों के लिए शॉर्टकट है जो किसी सक्रिय नियम को नहीं छूते। इसलिए यह जाँच रूटिंग को कवर करती है, नियम को नहीं।

README बदलाव को रिवर्ट करें और दोनों जॉब्स के पास होने का इंतज़ार करें। Superagent को रिकवरी को नज़रअंदाज़ करना चाहिए और निष्क्रिय रहना चाहिए।

चरण 5: एक Revenue Integrity CI विफलता ट्रिगर करें

मानव-केवल रास्ता उपयोग करके ट्यूटोरियल रिपॉज़िटरी से घटना डेटा जोड़ें। यह सारांश टाइमस्टैम्प कॉलमों के बिना रीप्ले और एक ही ऑर्डर पर अलग भुगतानों को दिखाता है:

event_id,order_id,amount_cents,delivery
evt_1009,ord_507,5000,first
evt_1010,ord_508,6400,first
evt_1011,ord_508,1600,first
evt_1009,ord_507,5000,replay
evt_1012,ord_509,2100,firstसंचालित द्वारा

रिपॉज़िटरी पूर्ण टाइमस्टैम्प कॉलम रखती है; यहाँ उन्हें छोड़ा गया है क्योंकि वे ईवेंट पहचान तय नहीं करते। पहले से तैयार स्वतंत्र गणना 15,100 सेंट अपेक्षित करती है, इसलिए टेस्ट में वही मान सेट करें और test_replayed_event_is_counted_once() जोड़ें।

E       actual daily total: 20100
E       expected daily total: 15100
E       replay total: 8000 != 4000
FAILED tests/test_revenue.py::test_daily_totals_match_known_values
FAILED tests/test_revenue.py::test_replayed_event_is_counted_once
2 failed, 1 passedसंचालित द्वारा

अतिरिक्त 5,000 सेंट एक भुगतान के दो बार गिने जाने से आए हैं। 15100 को 20100 में बदलना या रीप्ले टेस्ट हटाना भी CI को ग्रीन कर देगा, और दोनों में से कोई भी मरम्मत नहीं है।

विफल GitHub Actions वर्कफ़्लो केवल revenue-integrity की विफलता दिखाता है। उसका ट्रिगर लगभग एक पोलिंग अंतराल बाद पहुँचा।

Eval ने उम्मीदवार को "स्वीकार करेंगे" के रूप में चिह्नित किया, जबकि Execution टैब खाली रहा। मूल्यांकनकर्ता ने चेक के नाम और निष्कर्ष देखे, pytest लॉग नहीं, इसलिए उसे पता था कि कौन-सा गार्ड फेल हुआ, क्यों नहीं।

Observe मोड सिर्फ "would accept" लॉग करता है। चित्र: लेखक द्वारा।

चरण 6: मरम्मत को अधिकृत करें और पुल रिक्वेस्ट की जाँच करें

पहले कवर किया गया स्पष्ट-अनुरोध पथ अब निष्पादन को अधिकृत करता है। GitHub सूचनाएँ देर से आ सकती हैं।

छूटी हुई GitHub Issue मेंशन को संभालें

Superagent 6337fc8 पर GitHub Source पाँच सेकंड के ओवरलैप के साथ पोल करता है और अधिसूचित थ्रेड को बाद के कर्सर से पढ़ता है। मेंशन सूचनाएँ 21 से 23 सेकंड बाद आईं, इसलिए कोई पोल संदेश से आगे बढ़ सकता था।

यही टाइमिंग समझाती है कि नई Issue बॉडी और कुछ टिप्पणियाँ ट्रिगर नहीं बनीं। एक कम्युनिटी रिपोर्ट वही विफलता मोड विर्णित करती है।

GitHub टिप्पणी से मरम्मत को अधिकृत करें

अनुरोध फिर से एक नई टिप्पणी के रूप में पोस्ट करें और पुष्टि करें कि उसका ट्रिगर दिखता है। Superagent को इसे स्पष्ट अनुरोध के रूप में स्वीकार करना चाहिए और वर्कर शुरू करना चाहिए।

कमेंट मेंशन अधिकृत Ticket बनाता है। चित्र: लेखक द्वारा।

एजेंट के ईवेंट डिडुप्लीकेशन फिक्स की जाँच करें

बना पुल रिक्वेस्ट ने फिक्स को event_id पर आधारित किया। विवरण पर निर्भर रहने के बजाय डिफ़ की समीक्षा करें:

 def daily_revenue(events):
     """Return one row per UTC day with total revenue in cents."""
+    # The payment webhook may deliver the same event more than once, with a
+    # different received_at but the same event_id. One event_id is one payment
+    # event, so keep only its first delivery before aggregating.
+    events = events.drop_duplicates(subset="event_id", keep="first")
     days = events["occurred_at"].dt.strftime("%Y-%m-%d")संचालित द्वारा

इसने एक रीप्ले टेस्ट जोड़ा और कुछ नहीं हटाया। पहला टेस्ट कमांड निर्भरताएँ मिस होने से फेल हुआ। वर्कर ने वर्चुअल एनवायरनमेंट बनाने के बाद, दृश्य टेस्ट सूट पास किया।

एक ही ऑर्डर साझा करने वाले भुगतान टेस्ट करें

एजेंट का मेंशन किए बिना बदलाव का अनुरोध करें: साबित करें कि एक ही ऑर्डर पर दो भुगतान, जो केवल event_id में अलग हैं, दोनों गिने जाते हैं, और उनमें से एक का रीप्ले एक बार गिना जाता है। समीक्षा को बिना नए Eval के उसी Ticket तक पहुँचना चाहिए।

वर्कर ने सिर्फ एक टेस्ट जोड़ने वाले कमिट के साथ जवाब दिया और पाइपलाइन अपरिवर्तित छोड़ी। स्वीकृति से पहले, सटीक हेड SHA जाँचें और उसी रिविज़न के खिलाफ स्वतंत्र सूट फिर से चलाएँ।

रिव्यू फीडबैक उसी Ticket को जारी रखता है। चित्र: लेखक द्वारा।

स्वतंत्र डेटा से मरम्मत जाँचें

अलग मानव वातावरण से बिल्कुल उसी पुल रिक्वेस्ट हेड पर होल्डआउट चलाएँ। a43c541 पर, दोनों सूट्स ने 5 में से 5 टेस्ट पास किए, बिना कोई असर्शन हटाए; 62bac08 ने वही ट्री बनाए रखा।

सिर्फ एजेंट द्वारा लिखे गए टेस्ट केवल वही मामलों को कवर करते हैं जिन्हें एजेंट चुनता है।

चरण 7: फिक्स मर्ज करें और CI रिकवरी मापें

मर्ज के बाद, जाँचें कि main फिर से ग्रीन हो गया है और रिकवरी कोई नया काम शुरू नहीं करती। फिर ईवेंट ट्रेस, खर्च हुआ समय, और प्रॉवाइडर चार्ज की समीक्षा करें।

फिक्स मर्ज करें और CI रिकवरी की पुष्टि करें

मैनुअल स्वीकृति और मर्ज के बाद, दोनों डिफ़ॉल्ट-ब्रांच चेक पास हुए। Superagent ने रिकवरी को नज़रअंदाज़ किया, और कोई नया काम शुरू नहीं किया, तथा मौजूदा Ticket को merged परिणाम के साथ बंद कर दिया।

ईवेंट इनटेक और निर्णय का मूल्यांकन करें

हर ईवेंट को इनटेक से परिणाम तक फॉलो करें, जैसा कि हमारा AI एजेंट्स का मूल्यांकन गाइड बताता है। तीन बार की पुनरावृत्ति में, जो ईवेंट Eval तक पहुँचे उन्होंने अपेक्षित रूट लिया; मिस इनटेक के दौरान हुईं, न कि मॉडल Decision में।

मरम्मत की शुद्धता, समय, और लागत मापें

वही परिदृश्य तीन नई रिपॉज़िटरीज़ और WSL डिस्ट्रीब्यूशन्स में Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash, और एक पॉलिसी के साथ चला। लागतें DeepSeek की ऑफ-पीक कम दर पर हैं; ये पुनरुत्पादन हैं, बेंचमार्क नहीं।

तीनों मरम्मतों ने event_id का उपयोग किया; हर होल्डआउट टेस्ट पास हुआ। इनटेक में अधिक विविधता रही: Issue-बॉडी मेंशन हर बार छूटा, और तीसरे पुनरुत्पादन में एक आने से पहले दो टिप्पणियाँ भी छूट गईं।

दूसरे पुनरुत्पादन ने कमिट्स को फिर से लिखा, और स्वीकृति होल्डआउट के फिर से चलने से पहले आ गई। बाद का चेक पास हुआ, लेकिन सुरक्षित क्रम है: हेड SHA, होल्डआउट, फिर स्वीकृति।

DeepSeek Superagent की सीमाएँ और ट्रबलशूटिंग

यहाँ कई विफलताएँ चुप्पी जैसी दिखती हैं, इसलिए शुरू में पता करें कि ईवेंट कहाँ रुका। खीज की बात यह है कि छूटी अधिसूचना और सही ignore एक जैसी लग सकती हैं।

वे CI विफलताएँ जो कोई ट्रिगर नहीं बनातीं

Superagent विफल सेट में बदलाव ट्रैक करता है, इसलिए बेसलाइन रीडिंग, लगातार फेल होता चेक, और अभी चल रहे चेक कुछ नहीं बनाते। बिना Decision का ट्रिगर आमतौर पर CI admission सेल की ओर इशारा करता है, मॉडल की नहीं।

वे GitHub अनुरोध जो कभी पहुँचते नहीं

जब सेंडर allowed नहीं है, Source ऑफ़ है, प्रोसेसिंग रुकी है, या GitHub देर से सूचित करता है, तो अनुरोध विफल हो सकते हैं। यदि ये जाँचें पास हों, तो नई टिप्पणी पोस्ट करें; Issue बॉडी एडिट करने से कोई ईवेंट नहीं बनता।

स्वायत्त CI मरम्मत की सीमाएँ

प्रोटोटाइप कोई सुरक्षा सीमा नहीं देता। वर्कर्स के पास पूर्ण OS-यूज़र एक्सेस है, और डिस्क्लोज़र नियम प्रॉम्प्ट टेक्स्ट हैं। एजेंट अकाउंट को अलग रखें और उसे डिस्पोज़ेबल रिपॉज़िटरी तक सीमित करें।

auto पर स्विच करने से पहले, हफ्तों तक observed Decisions इकट्ठे करें, गलत स्वीकृतियों के साथ-साथ गलत ignores की गिनती करें, और वर्कर को WSL से अलग वर्चुअल मशीन में ले जाएँ।

अंतिम विचार

शुरुआती तुलना सही रही: दो लाल CI अवस्थाएँ एक जैसी कार्रवाई तक नहीं पहुँचीं। Superagent ने docs-check को नज़रअंदाज़ किया और revenue-integrity को "स्वीकार करेंगे" के रूप में चिह्नित किया, जबकि observe मोड ने तब तक कोड को अछूता रखा जब तक किसी व्यक्ति ने मरम्मत का अनुरोध नहीं किया।

event_id पैच सीधा था। अधिसूचना इनटेक कम विश्वसनीय रहा: Issue बॉडी मेंशन Eval तक कभी पहुँचा ही नहीं, इसलिए एक सही नियम भी मदद नहीं कर सका।

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

मेरा अगला कदम GitHub अधिसूचना पथ को ठीक करना और अधिक विफलता प्रकारों के साथ वर्कफ़्लो दोहराना होगा। जब तक ऐसा प्रमाण न हो, मैं auto मोड ऑफ़ ही रखूँगा।