บทเรียน DeepSeek Superagent: เฝ้าดู CI และอนุญาตให้ซ่อม

DeepSeek Superagent คืออะไร

DeepSeek Superagent เฝ้าดูรีโพ GitHub หนึ่งรายการผ่าน DeepSeek Harness กฎของทีมจะตัดสินว่าเหตุการณ์ใดสมควรได้รับงาน งานที่ยอมรับจะถูกส่งไปยังเซสชันแยก บทเรียนนี้ครอบคลุมเฉพาะต้นแบบที่เผยแพร่ ไม่ใช่แนวคิดเชิงออกแบบล้วน ๆ

Harness เป็นรันไทม์ ส่วน Superagent เพิ่มการเฝ้าดูเหตุการณ์และการอนุญาต บทความอธิบาย agent harness ของเราครอบคลุมเครื่องมือ หน่วยความจำ และการควบคุม

DeepSeek Superagent ทำงานอย่างไร

เหตุการณ์ GitHub ใหม่สามารถไหลผ่านสี่ขั้นตอน ขั้นตอนเหล่านี้ทำให้การตัดสินใจกับการเปลี่ยนโค้ดแยกจากกัน:

• แหล่งที่มาและ Trigger: การโพล GitHub แปลงแต่ละเหตุการณ์เป็น Trigger บน Issue, pull request หรือ main

• Admission: ตัวด่านจะติดป้ายว่าเป็นคำขอชัดแจ้ง ผู้สมัครจากการอนุมาน หรือไม่มีอะไร

• Eval และการตัดสินใจ:  CI ที่อนุมานได้จะถูกตัดสินตามกฎ คำขอชัดแจ้งจะถูกรูตไปยังการตัดสินใจ accept ด้วยเหตุผล explicitRouted

• Ticket และ Executor: งานที่ยอมรับจะได้รับการอนุญาต เซสชันของ worker และไดเรกทอรี

คอมเมนต์ภายหลังบน Thread ของ Ticket เองจะไปที่ worker เดิมโดยไม่มี Eval ใหม่ ไดอะแกรมแสดงสามเส้นทางของ GitHub: CI ของสาขาค่าเริ่มต้น คำขอชัดแจ้ง และการรีวิวนั้น ภายในเส้นทาง CI โหมดสังเกตการณ์และ auto ทิ้งกฎที่ตรงกันไว้คนละปลาย

CI ถูกตัดสิน คำขอเริ่มงาน ภาพโดยผู้เขียน

ความแตกต่างระหว่างโหมด observe และโหมด auto คืออะไร

โหมด accept ใช้เฉพาะกับงานที่ Superagent อนุมานจากเหตุการณ์ เลือกหนึ่งในสามการตั้งค่า:

• off ทิ้งผู้สมัครที่อนุมาน

• observe ประเมินและบันทึกผลบวกว่า "would accept"

• auto เริ่มงานหลังจากประเมินเป็นบวก

คำขอจากบุคคลที่ได้รับอนุญาตทำงานได้ในทุกโหมดและสร้าง Ticket ของตัวเอง สำหรับบทเรียนนี้ให้ปิด auto

สร้างเวิร์กโฟลว์ซ่อม CI ในโหมดสังเกตการณ์

ไปป์ไลน์นี้ใช้ pytest และงาน GitHub Actions สองงานเพื่อเปลี่ยนเหตุการณ์เป็นรายได้รายวัน Superagent แทรกการตัดสินใจก่อนเริ่มงาน บทเรียน Claude Code Routines ของเราครอบคลุมเวิร์กโฟลว์แบบขับเคลื่อนด้วยเหตุการณ์อีกแบบ

ไล่หาบั๊ก replay ในรายได้รายวัน

บั๊กนี้นับการชำระเงินที่ถูกส่งซ้ำซ้อนสองครั้ง แต่ละแถวมี event_id, order_id, เวลาประทับ และจำนวนเงิน คำสั่งซื้อหนึ่งคำสั่งสามารถมีการชำระเงินที่ถูกต้องหลายครั้ง

ดังนั้นการลบซ้ำด้วย order_id อาจผ่านการทดสอบ replay ได้แต่ลบการชำระเงินจริงออก คีย์ที่ถูกต้องคือ event_id คำนวณยอดรวมที่คาดหวังด้วยโมดูล csv ของ Python ก่อนอนุญาตเอเจนต์ เพื่อให้ผลลัพธ์ของเอเจนต์ไม่ใช่เฉลย

กำหนดนิยามความสำเร็จของการซ่อม CI

ความสำเร็จขึ้นอยู่กับสิ่งที่เวิร์กโฟลว์ทำ ไม่ใช่แค่สิ่งที่เอเจนต์บอก ตั้งเงื่อนไขเหล่านี้ก่อนเปลี่ยนรีโพ:

• มองข้ามความล้มเหลวที่เป็นเอกสารเท่านั้น

• ตรงกับ revenue-integrity โดยไม่เริ่มงาน

• เปิด pull request เฉพาะเมื่อมีคำขอชัดแจ้ง

• คง assertions ไว้และผ่านชุด holdout ที่เตรียมไว้

เตรียมชุด holdout ก่อน Superagent จะได้สิทธิ์เข้าถึง เพื่อให้พฤติกรรมที่คาดหวังอยู่นอกอินพุตการพัฒนาของ worker

ข้อกำหนดและการแยกสภาพแวดล้อมของ DeepSeek Superagent

ต้องมีคีย์ API ของ DeepSeek บัญชี GitHub สองบัญชี และสภาพแวดล้อม Linux ที่ทิ้งได้ สำหรับพื้นฐาน Harness โปรดดู คู่มือเริ่มต้นใช้งาน ของเรา

ซอฟต์แวร์และบัญชีที่ต้องใช้

ตรึงเวอร์ชันซอฟต์แวร์เพื่อไม่ให้อัปเกรดแล้วเปลี่ยนเวิร์กโฟลว์ คอลัมน์สุดท้ายบันทึกสภาพแวดล้อมที่ใช้สำหรับผลลัพธ์ในบทความ:

เอเจนต์ต้องมีผู้ใช้ GitHub ของตัวเองที่มีสิทธิ์เขียน เพราะ Superagent อ่านการแจ้งเตือนของบัญชีนั้น เพิ่มเฉพาะผู้ดูแลมนุษย์ที่สามารถอนุญาตงานลงในรายการ allowed

แยกเอเจนต์ออกจากไฟล์ส่วนตัว

ทั้งสองพรีเซ็ตให้ผู้ใช้ของระบบปฏิบัติการ (OS) มีสิทธิ์เต็ม และตัวห่อ gh ก็ไม่ได้แยกโปรเซส ใช้ดิสทริบิวชัน WSL ใหม่ โดยปิด automount และ interop:

หากมีเครื่องเสมือน 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 ของ Microsoft แนะนำให้ใช้เครื่องเสมือนที่จัดการแยกต่างหากนอก WSL สำหรับโค้ดที่ไม่น่าไว้วางใจ

บน GitHub ปกป้อง main ด้วยการบังคับใช้ pull request การอนุมัติอิสระอย่างน้อยหนึ่งครั้ง และการตรวจ CI ทั้งสอง ให้เอเจนต์มีสิทธิ์เขียนโดยไม่มีการเลี่ยงสิทธิ์ผู้ดูแล ทั้งหมดนี้ไม่สามารถหยุด prompt injection ผ่านข้อความ 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 ตรวจยอดรวมที่ทราบและกรณีคำสั่งร่วมกัน และยังไม่มีการทดสอบ replay:

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 และในข้อความ Trigger ของ 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 = . ยืนยันว่างานทั้งสองผ่านบน main ก่อนติดตั้ง Superagent

ไดเรกทอรี experiment/holdout ที่เผยแพร่เอกสารรันเดิม แต่มองเห็นได้ในโคลนสาธารณะ สำหรับการทดลองใหม่ สร้างชุดสดนอกทุก checkout และนอกไฟล์ซิสเต็มที่ worker อ่านได้

แฮชชุดนั้นก่อนส่งคำขอซ่อม ครอบคลุมกรณีเหล่านี้:

• การส่งเหตุการณ์เดิมซ้ำ
• เหตุการณ์ต่างกันที่มี order ID เดียวกัน
• DataFrame อินพุตที่ต้องคงเดิม
• คอลัมน์เอาต์พุตและลำดับการเรียงที่คาดหวัง

เก็บชุดนี้ไว้เป็นความลับจนถึงการรีวิว ขั้นตอนที่ 6 จะรันจากสภาพแวดล้อมของมนุษย์ที่แยกต่างหากหลัง worker เสร็จ

ไดอะแกรมต่อไปนี้แยกอินพุตการพัฒนาของ worker ออกจากการตรวจสุดท้ายของผู้ดูแล

ข้อมูล holdout อยู่นอกตัว worker ภาพโดยผู้เขียน

ขั้นตอนที่ 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 จนกว่าจะบันทึก Source ของ GitHub ในขั้นตอนที่ 3 ตอนนี้ให้ยืนยันเพียงว่ารันไทม์ตอบสนองและแผง Superagent เปิดได้ ยังไม่ต้องคาดหวัง Source หรือ CI พื้นฐาน

เปิด Settings → Models ในโปรไฟล์เฉพาะและเลือก deepseek-flash ใน Superagent → Settings → Eval และ Execution ยืนยันว่าทั้งสองบทบาทสืบทอดโมเดลของโปรไฟล์นั้นหรือระบุชื่อ deepseek-flash อย่างชัดเจน

ขั้นตอนที่ 3: ตั้งค่าการเฝ้าดู GitHub Actions ในโหมดสังเกตการณ์

ปิดการสังเกตการณ์ CI ของสาขาค่าเริ่มต้นไว้ขณะบันทึกการตั้งค่า Source, นโยบาย, กฎ และ executor เปิดเฉพาะหลังจากรีโพใหม่มี main สีเขียว เพื่อให้การอ่านครั้งแรกบันทึกฐานที่สะอาด

ตั้งค่า GitHub Source

ใน Settings → Sources ตั้งรีโพเป็น EXPERIMENT_REPO ชี้ฟิลด์ CLI ไปที่ตัวห่อ gh-agent ที่กำหนดไว้ และคงปิดการสังเกตการณ์ CI ของสาขาค่าเริ่มต้น บันทึก Source และรอให้การรีสตาร์ตใด ๆ เสร็จสิ้นก่อนเปลี่ยนนโยบาย

ตั้งค่านโยบาย admission ของ CI

ผล CI ไม่มีผู้ส่ง แถว admission ของมันมีเซลล์เดียว ซึ่งค่าเริ่มต้นคือ ignore หากปล่อยไว้เช่นนั้น Eval จะไม่เห็น CI เลย

กำหนดกฎ revenue-integrity ที่แคบ

แทนที่ตัวอย่างกฎด้วยกฎเดียวที่ตั้งชื่อตามการตรวจ แจ้ง evaluator ไม่ให้เดาสาเหตุ:

{
  "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 ที่สร้าง Git worktree สำหรับแต่ละ Ticket จากนั้น worker แต่ละตัวจะเริ่มจาก checkout ของรีโพ:

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 ตรวจว่าดิเรกทอรีที่ได้มี checkout ที่คาดหวังก่อนอนุญาตงาน

ตัวช่วยตั้งค่าแบบเลือกใช้ สคริปต์ configure เขียน Source, นโยบาย, Eval และบล็อก executor แบบเดียวกัน โดยคงปิดการสังเกตการณ์ CI ในรอบแรก เสมอตั้งค่ารีโพทดลองและผู้ร้องขอที่อนุญาตอย่างชัดเจน:

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 ที่สะอาด

• แท็บ Trigger และ Execution ไม่แสดง Trigger หรือ Ticket ของฐาน

หากข้อใดไม่ผ่าน ให้หยุดก่อนสร้างความล้มเหลวของเอกสาร สกรีนช็อตของ Source และ Eval แสดงการตั้งค่าสุดท้าย

การ์ด GitHub Source พร้อมการสังเกตการณ์ CI ภาพโดยผู้เขียน

การตั้งค่า 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: กระตุ้นความล้มเหลว CI ด้านความถูกต้องของรายได้

ใช้เส้นทางที่เฉพาะมนุษย์เท่านั้นอีกครั้งเพื่อเพิ่มข้อมูลเหตุการณ์จากรีโพบทเรียน สรุปนี้แสดง replay และการชำระเงินแยกต่างหากในคำสั่งเดียวโดยไม่รวมคอลัมน์เวลา:

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 หรือการลบเทสต์ replay ก็ทำให้ CI เขียวได้เช่นกัน แต่นั่นไม่ใช่การซ่อม

เวิร์กโฟลว์ GitHub Actions ที่ล้มเหลว แสดงเพียง revenue-integrity ล้มเหลว Trigger มาถึงหลังช่วงโพลประมาณหนึ่งรอบ

Eval ทำเครื่องหมายผู้สมัครว่า "would accept" ขณะที่แท็บ Execution ว่างอยู่ ตัว evaluator เห็นชื่อเช็คและบทสรุป ไม่ใช่ล็อกของ pytest จึงรู้ว่าเกราะอันไหนล้มเหลวแต่ไม่รู้สาเหตุ

โหมด observe บันทึกเพียง "would accept" ภาพโดยผู้เขียน

ขั้นตอนที่ 6: อนุญาตการซ่อมและตรวจสอบ Pull Request

เส้นทางคำขอชัดแจ้งที่กล่าวถึงก่อนหน้านี้ตอนนี้อนุญาตให้รันได้ การแจ้งเตือน GitHub อาจมาช้า

จัดการกรณีการกล่าวถึงใน Issue ที่พลาด

ที่ Superagent 6337fc8 GitHub Source ซ้อนการโพลห้าวินาทีและอ่านเธรดที่ถูกแจ้งเตือนจากเคอร์เซอร์ที่มาทีหลัง การแจ้งเตือนการกล่าวถึงมาถึงช้ากว่า 21 ถึง 23 วินาที จึงอาจมีรอบโพลที่ขยับผ่านข้อความไป

จังหวะเวลานี้อธิบายว่าทำไมเนื้อหา Issue ใหม่และบางคอมเมนต์จึงไม่กลายเป็น Trigger มี รายงานจากชุมชน ที่อธิบายโหมดล้มเหลวเดียวกัน

อนุญาตการซ่อมด้วยคอมเมนต์ใน GitHub

โพสต์คำขออีกครั้งเป็นคอมเมนต์ใหม่และยืนยันว่า Trigger ของมันปรากฏ Superagent ควรยอมรับเป็นคำขอชัดแจ้งและเริ่ม worker

การกล่าวถึงในคอมเมนต์สร้าง Ticket ที่ได้รับอนุญาต ภาพโดยผู้เขียน

ตรวจการแก้การลบซ้ำของเหตุการณ์โดยเอเจนต์

pull request ที่ได้ ผูกคีย์การแก้ไว้ที่ event_id ให้รีวิว diff แทนที่จะพึ่งคำอธิบาย

 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")ขับเคลื่อนโดย

เพิ่มเทสต์ replay และไม่ได้ลบอะไร คำสั่งทดสอบแรกพังเพราะขาด dependency หลัง worker สร้าง virtual environment ชุดเทสต์ที่มองเห็นก็ผ่าน

ทดสอบการชำระเงินที่แชร์คำสั่งเดียวกัน

ร้องขอการเปลี่ยนแปลงโดยไม่กล่าวถึงเอเจนต์: พิสูจน์ว่าการชำระเงินสองรายการในคำสั่งเดียวกันที่ต่างกันแค่ event_id ถูกนับทั้งคู่ และ replay ของหนึ่งรายการถูกนับครั้งเดียว การรีวิวควรเข้าถึง Ticket เดิมโดยไม่มี Eval ใหม่

worker ตอบด้วยคอมมิตที่เพิ่มเทสต์อย่างเดียวและไม่แตะไปป์ไลน์ ก่อนอนุมัติ ให้ตรวจ SHA หัวอย่างแม่นยำและรันชุดอิสระซ้ำกับรีวิชันนั้น

ฟีดแบ็กรีวิวดำเนินต่อใน Ticket เดิม ภาพโดยผู้เขียน

ตรวจการซ่อมด้วยข้อมูลอิสระ

รันชุด holdout จากสภาพแวดล้อมมนุษย์ที่แยกต่างหากกับหัวของ pull request ที่แน่นอน บน a43c541 ชุดทั้งสองผ่าน 5 จาก 5 เทสต์โดยไม่ลบ assertion ใด ๆ; 62bac08 คงต้นไม้เดียวกัน

เทสต์ที่เขียนโดยเอเจนต์ล้วนครอบคลุมเฉพาะกรณีที่เอเจนต์เลือก

ขั้นตอนที่ 7: รวมการแก้และวัดการกู้คืน CI

หลัง merge ตรวจว่า main กลับมาเป็นสีเขียวและการกู้คืนไม่เริ่มงานใหม่ จากนั้นรีวิวร่องรอยเหตุการณ์ เวลาที่ผ่านไป และค่าบริการผู้ให้บริการ

รวมการแก้และยืนยันการกู้คืน CI

หลังการอนุมัติและรวมแบบแมนนวล เช็คของสาขาค่าเริ่มต้นทั้งสองผ่าน Superagent มองข้ามการกู้คืน ไม่เริ่มงานเพิ่ม และปิด Ticket เดิมด้วยผลลัพธ์ merged

ประเมินการรับเหตุการณ์และการตัดสินใจ

ติดตามแต่ละเหตุการณ์ตั้งแต่การรับเข้าจนถึงผลลัพธ์ ตามที่ คู่มือประเมินเอเจนต์ AI ของเราอธิบาย ตลอดสามการทำซ้ำ เหตุการณ์ที่ไปถึง Eval เดินเส้นทางตามคาด; การพลาดเกิดขึ้นระหว่างการรับเข้า ไม่ใช่การตัดสินใจของโมเดล

วัดความถูกต้อง เวลา และต้นทุนการซ่อม

สถานการณ์เดียวกันรันในรีโพและดิสทริบิวชัน WSL ใหม่สามชุด ด้วย Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash และนโยบายเดียว ค่าบริการใช้ เรตนอกชั่วโมงที่ต่ำกว่า ของ DeepSeek; นี่คือการทำซ้ำ ไม่ใช่ benchmark

การซ่อมทั้งสามใช้ event_id และเทสต์ holdout ผ่านทุกข้อ การรับเข้าแปรผันมากกว่า: การกล่าวถึงในเนื้อหา Issue พลาดทุกครั้ง และการทำซ้ำครั้งที่สามยังพลาดคอมเมนต์สองรายการก่อนที่หนึ่งรายการจะมาถึง

การทำซ้ำครั้งที่สองเขียนคอมมิตใหม่ และการอนุมัติมาถึงก่อนรัน holdout ซ้ำ การตรวจภายหลังผ่าน แต่ลำดับที่ปลอดภัยกว่าคือ SHA หัว, holdout, แล้วค่อยอนุมัติ

ข้อจำกัดและการแก้ปัญหาของ DeepSeek Superagent

ความล้มเหลวหลายอย่างที่นี่ดูเหมือนความเงียบ เริ่มจากการหาว่าเหตุการณ์หยุดที่ไหน ส่วนที่น่าหงุดหงิดคือการแจ้งเตือนที่พลาดและการมองข้ามที่ถูกต้องอาจดูเหมือนกัน

ความล้มเหลวของ CI ที่ไม่ก่อให้เกิด Trigger

Superagent ติดตามการเปลี่ยนแปลงในชุดที่ล้มเหลว ดังนั้นการอ่านฐาน เช็คที่ยังคงล้มเหลว และเช็คที่ยังรันอยู่จะไม่สร้างอะไร Trigger ที่ไม่มี Decision มักชี้ไปที่เซลล์ admission ของ CI ไม่ใช่โมเดล

คำขอ GitHub ที่ไม่เคยมาถึง

คำขออาจล้มเหลวเมื่อผู้ส่งไม่ได้รับอนุญาต ปิด Source หยุดการประมวลผล หรือ GitHub แจ้งช้า หากการตรวจเหล่านั้นผ่าน ให้โพสต์คอมเมนต์ใหม่ การแก้ไขเนื้อหา Issue จะไม่สร้างเหตุการณ์

ขีดจำกัดของการซ่อม CI แบบอัตโนมัติ

ต้นแบบนี้ไม่มีขอบเขตความปลอดภัย Worker มีสิทธิ์เข้าถึงเต็มในระดับผู้ใช้ OS และกฎการเปิดเผยเป็นเพียงข้อความพรอมต์ แยกบัญชีเอเจนต์และจำกัดไว้ที่รีโพทิ้งได้

ก่อนสลับไป auto รวบรวมการตัดสินใจที่สังเกตได้นานหลายสัปดาห์ นับทั้งการยอมรับผิดและการมองข้ามผิด และย้าย worker จาก WSL ไปยังเครื่องเสมือนแยกต่างหาก

ข้อคิดส่งท้าย

ความต่างในตอนต้นยังคงอยู่: สถานะ CI สีแดงสองงานไม่ได้นำไปสู่การกระทำเดียวกัน Superagent มองข้าม docs-check และทำเครื่องหมาย revenue-integrity ว่า "would accept" ขณะที่โหมดสังเกตการณ์คงโค้ดไว้จนกว่าจะมีผู้ร้องขอให้ซ่อม

แพตช์ event_id ตรงไปตรงมา ส่วนการรับการแจ้งเตือนนั้นไม่น่าเชื่อถือกว่า: การกล่าวถึงในเนื้อหา Issue ไม่เคยไปถึง Eval ดังนั้นกฎที่ถูกต้องก็ช่วยไม่ได้

ยังไม่ขอสรุปผลนี้ไปสู่การซ่อม CI แบบอัตโนมัติ รีโพมีขนาดเล็ก กฎแคบ และการ merge ควบคุมโดยมนุษย์ ในที่อื่น เริ่มจากสถานะเขียว ตรวจการตัดสินใจ อนุญาตอย่างชัดแจ้ง แยกข้อมูล holdout และค่อย merge หลังการตรวจอิสระ

ขั้นตอนต่อไปคือแก้เส้นทางการแจ้งเตือนของ GitHub และทำเวิร์กโฟลว์ซ้ำกับความล้มเหลวหลากหลายประเภท จนกว่าจะมีหลักฐานนั้น ควรปิดโหมด auto ไว้