DeepSeek Superagent 튜토리얼: CI를 관찰하고 수정에 승인하기

DeepSeek Superagent란 무엇인가요?

DeepSeek Superagent는 DeepSeek Harness를 통해 하나의 GitHub 저장소를 관찰합니다. 팀 규칙이 이벤트에 작업 가치가 있는지 판단하고, 수락된 작업은 별도의 세션으로 진행됩니다. 이 튜토리얼은 설계 아이디어가 아닌 공개된 프로토타입을 다룹니다.

Harness는 런타임을 제공하고, Superagent는 이벤트 모니터링과 승인 기능을 추가합니다. 우리의 에이전트 하니스 설명서는 도구, 메모리, 제어를 다룹니다.

DeepSeek Superagent는 어떻게 동작하나요?

새로운 GitHub 이벤트는 네 단계로 진행될 수 있습니다. 이 단계들은 의사결정과 코드 변경을 분리합니다.

• 소스와 트리거: GitHub 폴링이 각 이벤트를 Issue, 풀 리퀘스트 또는 main의 트리거로 바꿉니다.

• 승인(Admission): 게이트가 이를 명시적 요청, 추론된 후보, 혹은 무시 대상으로 라벨링합니다.

• 평가와 결정(Eval and Decision):  추론된 CI는 규칙에照해 판단됩니다. 명시적 요청은 이유 explicitRouted로 수락 결정으로 라우팅됩니다.

• 티켓과 실행기: 수락된 작업은 권한, 작업자 세션, 디렉터리를 받습니다.

이후 티켓의 스레드에 달리는 댓글은 새 평가 없이 해당 작업자에게 전달됩니다. 다이어그램은 세 가지 GitHub 경로를 보여줍니다: 기본 브랜치 CI, 명시적 요청, 그리고 그 리뷰. CI 경로 안에서는 관찰과 자동 처리 규칙이 서로 다른 끝에 위치합니다.

CI는 평가 대상입니다. 요청은 작업을 시작합니다. 이미지: 필자 제작.

관찰 모드와 자동 모드의 차이는 무엇인가요?

수락 모드는 Superagent가 이벤트에서 추론한 작업에만 적용됩니다. 세 가지 설정 중 하나를 선택하세요.

• off는 추론된 후보를 버립니다.

• observe는 평가만 수행하고, 긍정 결과를 "수락할 것"으로 기록합니다.

• auto는 긍정 평가 후 작업을 시작합니다.

허가된 사용자의 요청은 모든 모드에서 작동하며 자체 티켓을 만듭니다. 본 튜토리얼에서는 auto를 끈 상태로 유지하세요.

관찰 모드에서 CI 수정 워크플로 구축하기

파이프라인은 s pytest와 두 개의 GitHub Actions 작업을 사용해 이벤트를 일일 매출로 변환합니다. Superagent는 작업 시작 전에 의사결정을 삽입합니다. 우리의 Claude Code Routines 튜토리얼은 또 다른 이벤트 기반 워크플로를 다룹니다.

일일 매출에서 재전송 버그 추적하기

버그는 재전송된 결제를 두 번 집계합니다. 각 행에는 event_id, order_id, 타임스탬프, 금액이 있습니다. 하나의 주문에는 여러 건의 유효한 결제가 있을 수 있습니다.

그래서 order_id로 중복 제거하면 재전송 테스트는 통과하면서 실제 결제를 삭제할 수 있습니다. 올바른 키는 event_id입니다. 에이전트 승인 전 Python의 csv 모듈로 예상 총액을 계산해 두세요. 에이전트 출력이 정답 키가 되지 않도록 합니다.

성공적인 CI 수정을 정의하기

성공은 에이전트의 진술이 아니라 워크플로가 수행하는 작업에 달려 있습니다. 저장소를 변경하기 전에 다음 조건을 설정하세요.

• 문서 전용 실패는 무시합니다.

• 작업을 시작하지 않고 revenue-integrity에 일치시킵니다.

• 명시적 요청 후에만 풀 리퀘스트를 엽니다.

• 단언을 보존하고 사전에 만든 홀드아웃 스위트를 통과합니다.

Superagent에 접근 권한을 주기 전에 홀드아웃 스위트를 준비하세요. 이렇게 하면 기대 동작이 작업자의 개발 입력 밖에 머무릅니다.

DeepSeek Superagent 준비 사항과 격리

DeepSeek API 키, 두 개의 GitHub 계정, 일회용 Linux 환경이 필요합니다. Harness 기본 사항은 기본 설정 가이드를 참조하세요.

필요한 소프트웨어와 계정

소프트웨어 버전을 고정해 업그레이드가 워크플로를 바꾸지 못하도록 하세요. 마지막 열은 본문 후반 결과에 사용된 설정을 기록합니다.

에이전트는 Superagent가 해당 계정의 알림을 읽기 때문에 쓰기 권한이 있는 자체 GitHub 사용자 계정이 필요합니다. 작업을 승인할 수 있는 사람 유지보수자만 허용 목록에 추가하세요.

개인 파일과 에이전트 분리

두 프리셋 모두 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 키와 에이전트 토큰만 보관해야 합니다. 이는 우발적 접근을 줄일 뿐 보안 경계는 아닙니다. Microsoft의 WSL 보안 모델 은 신뢰할 수 없는 코드를 위해 WSL 외부의 별도 관리 가상 머신을 권장합니다.

GitHub에서 main을 필수 풀 리퀘스트, 최소 1인의 독립 승인, 두 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는 GitHub 소스를 3단계에서 저장하기 전까지 설정 보류나 repositoryUnset으로 표시될 수 있습니다. 이 시점에서는 런타임이 응답하고 Superagent 패널이 열리는지만 확인하세요. 아직 소스나 CI 기준선은 기대하지 마세요.

전용 프로필의 Settings → Models에서 deepseek-flash를 선택하세요. Superagent → Settings → Eval과 Execution에서도 두 역할이 그 프로필 모델을 상속하거나 deepseek-flash로 명시되어 있는지 확인합니다.

3단계: 관찰 모드로 GitHub Actions 모니터링 구성

소스, 정책, 규칙, 실행기 설정을 저장하는 동안에는 기본 브랜치 CI 관찰을 끈 상태로 두세요. 새 저장소의 main이 그린 상태가 된 뒤에만 켜서 첫 읽기가 깨끗한 기준선을 기록하도록 합니다.

GitHub 소스 구성

Settings → Sources에서 저장소를 EXPERIMENT_REPO로 설정하고, CLI 필드를 전용 gh-agent 래퍼로 지정하며, 기본 브랜치 CI 관찰은 유지 끔 상태로 둡니다. 소스를 저장하고 정책 변경 전 재시작이 끝날 때까지 기다리세요.

CI 승인 정책 구성

CI 결과에는 보낸 사람이 없습니다. 해당 승인 행에는 하나의 셀이 있으며 기본값은 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"}}
  }}
}제공

각 티켓에 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는 각 티켓에 대해 이러한 변수를 채웁니다. 작업 승인 전에 결과 디렉터리에 예상 체크아웃이 들어 있는지 확인하세요.

선택 사항인 구성 도우미는 동일한 소스, 정책, Eval, 실행기 블록을 작성합니다. 첫 패스 동안 CI 관찰을 끔 상태로 유지합니다. 항상 실험용 저장소와 허용된 요청자를 명시적으로 설정하세요.

export REPO="$EXPERIMENT_REPO"
export ALLOWED="YOUR_GITHUB_LOGIN"
bash /path/to/configure.sh all제공

사전 실행은 비활성으로 유지

observe 모드에서 프로필의 기본 모델을 사용하세요. 각 이벤트 후 Eval 탭에서 결정을, Execution 탭에서 티켓 유무를 확인하세요.

CI 관찰을 켜고 기준선 기록

main에서 두 GitHub Actions 작업이 모두 통과하면, 기본 브랜치 CI 관찰을 켜세요. 도우미 스크립트를 사용한다면 두 번째 패스를 사용합니다.

OBSERVE_CI=true bash /path/to/configure.sh source
bash /path/to/configure.sh show제공

첫 읽기는 작업을 만들지 않고 상태를 기록합니다. 다음 네 가지를 확인하세요.

• 설정에 보류 중인 요구 사항이 없습니다.

• GitHub 소스가 ready를 보고합니다.

• 소스가 깨끗한 CI 기준선을 기록합니다.

• 트리거와 실행 탭에 기준선 트리거나 티켓이 없습니다.

이 중 하나라도 실패한다면 문서 실패를 만들기 전에 중단하세요. 소스와 Eval 스크린샷은 최종 구성을 보여줍니다.

CI 관찰이 켜진 GitHub 소스 카드. 이미지: 필자 제작.

Eval 설정: 규칙 1개, 관찰 모드. 이미지: 필자 제작.

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는 매출 규칙이 일치하지 않았기 때문에 후보를 무시했습니다.

결정은 활성 규칙에 닿지 않는 후보에 대한 단축키인 ignoredFromCard를 사용했습니다. 따라서 이 체크는 규칙 자체가 아닌 라우팅을 검증합니다.

README 변경을 되돌리고 두 작업이 통과할 때까지 기다리세요. Superagent는 복구를 무시하고 대기 상태를 유지해야 합니다.

5단계: 매출 무결성 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은 후보를 "수락할 것"으로 표시했지만 실행 탭은 비어 있었습니다. 평가기는 pytest 로그가 아니라 체크 이름과 결론만 보았기 때문에 어떤 가드가 실패했는지는 알았으나 이유는 몰랐습니다.

관찰 모드는 "수락할 것"만 기록합니다. 이미지: 필자 제작.

6단계: 수정을 승인하고 풀 리퀘스트 검증

앞서 다룬 명시적 요청 경로가 이제 실행을 승인합니다. GitHub 알림은 늦을 수 있습니다.

누락된 GitHub Issue 멘션 처리

Superagent 6337fc8에서는 GitHub 소스가 5초 간격으로 폴링이 겹치고, 알림된 스레드를 더 늦은 커서에서 읽습니다. 멘션 알림이 21~23초 후 도착해 폴링이 메시지를 지나칠 수 있었습니다.

이 타이밍 때문에 새 Issue 본문과 일부 댓글이 트리거로 전환되지 않았습니다. 커뮤니티 보고는 동일한 실패 양상을 설명합니다.

GitHub 댓글로 수정 승인

요청을 새 댓글로 다시 게시하고 해당 트리거가 나타나는지 확인하세요. Superagent는 이를 명시적 요청으로 수락하고 작업자를 시작해야 합니다.

댓글 멘션이 승인된 티켓을 만듭니다. 이미지: 필자 제작.

에이전트의 이벤트 중복 제거 수정 점검

해당 풀 리퀘스트는 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")제공

재전송 테스트가 추가되었고 삭제된 것은 없습니다. 첫 테스트 명령은 의존성 누락으로 실패했습니다. 작업자가 가상 환경을 만든 뒤, 보이는 테스트 스위트는 통과했습니다.

동일 주문의 결제 테스트

에이전트를 멘션하지 않고 변경을 요청하세요. event_id만 다른 동일 주문의 두 결제가 모두 반영되고, 하나의 재전송은 한 번만 집계됨을 증명합니다. 리뷰는 새로운 평가 없이 동일 티켓으로 이어져야 합니다.

작업자는 파이프라인을 바꾸지 않고 테스트만 추가하는 커밋으로 응답했습니다. 승인 전 정확한 헤드 SHA를 확인하고 해당 리비전에 대해 독립 스위트를 다시 실행하세요.

리뷰 피드백은 동일 티켓에서 이어집니다. 이미지: 필자 제작.

독립 데이터로 수정 점검

별도의 사람 환경에서 정확한 풀 리퀘스트 헤드에 대해 홀드아웃을 실행하세요. a43c541에서는 두 스위트 모두 단언 삭제 없이 5/5 테스트를 통과했습니다. 62bac08도 동일 트리를 유지했습니다.

에이전트만이 작성한 테스트는 에이전트가 선택한 케이스만을 다룹니다.

7단계: 수정 병합 및 CI 복구 측정

병합 후 main이 다시 그린으로 돌아오고 복구가 새로운 작업을 시작하지 않는지 확인하세요. 그런 다음 이벤트 추적, 경과 시간, 공급자 요금을 검토합니다.

수정 병합 및 CI 복구 확인

수동 승인과 병합 후 기본 브랜치의 두 체크가 모두 통과했습니다. Superagent는 복구를 무시했고 추가 작업을 시작하지 않았으며, 기존 티켓을 merged 결과로 닫았습니다.

이벤트 수신과 결정 평가

우리의 AI 에이전트 평가 가이드에서 설명한 대로 각 이벤트를 수신부터 결과까지 추적하세요. 세 번의 반복에서, Eval에 도달한 이벤트는 예상 경로를 탔고, 누락은 모델 결정이 아닌 수신 단계에서 발생했습니다.

수정의 정확도, 시간, 비용 측정

동일 시나리오를 Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash, 하나의 정책으로 새 저장소와 WSL 배포판에서 세 번 실행했습니다. 비용은 DeepSeek의 오프피크 낮은 요율을 기준으로 하며, 이는 재현 결과일 뿐 벤치마크가 아닙니다.

세 수정 모두 event_id를 사용했고, 모든 홀드아웃 테스트가 통과했습니다. 수신은 더 가변적이었습니다. Issue 본문 멘션은 매번 누락됐고, 세 번째 재현에서는 두 개 댓글이 누락된 뒤 하나가 도착했습니다.

두 번째 재현에서는 커밋이 다시 작성되었고, 홀드아웃 재실행 전 승인이 도착했습니다. 이후 점검은 통과했지만, 더 안전한 순서는 헤드 SHA 확인, 홀드아웃, 그리고 승인입니다.

DeepSeek Superagent의 한계와 트러블슈팅

여기서 발생한 여러 실패는 침묵처럼 보일 수 있으므로, 이벤트가 어디서 멈췄는지부터 찾으세요. 성가신 점은 누락된 알림과 올바른 무시가 겉보기에는 같아 보일 수 있다는 것입니다.

트리거가 생기지 않는 CI 실패

Superagent는 실패 집합의 변화를 추적하므로, 기준선 읽기, 계속 실패 중인 체크, 실행 중인 체크는 아무 것도 생성하지 않습니다. 결정 없는 트리거는 보통 모델이 아니라 CI 승인 셀을 가리킵니다.

도착하지 않는 GitHub 요청

보낸 사람이 허용되지 않았거나, 소스가 꺼져 있거나, 처리가 일시 중지되었거나, GitHub 알림이 늦으면 요청이 실패할 수 있습니다. 이러한 점검을 통과했다면 새 댓글을 게시하세요. Issue 본문 편집은 이벤트를 만들지 않습니다.

자율 CI 수정의 한계

이 프로토타입에는 보안 경계가 없습니다. 작업자는 OS 사용자 권한에 전체 접근할 수 있고, 공개 규칙은 프롬프트 텍스트에 불과합니다. 에이전트 계정을 격리하고 일회용 저장소로 범위를 제한하세요.

auto로 전환하기 전, 수 주간 관찰된 결정을 수집하고 잘못된 수락뿐 아니라 잘못된 무시도 집계하며, 작업자를 WSL에서 별도의 가상 머신으로 옮기세요.

마무리

처음의 대조는 유지되었습니다. 두 개의 빨간 CI 상태가 같은 행동으로 이어지지 않았습니다. Superagent는 docs-check를 무시하고 revenue-integrity는 "수락할 것"으로 표시했으며, 관찰 모드는 사람이 수정을 요청할 때까지 코드를 건드리지 않았습니다.

event_id 패치는 단순했습니다. 알림 수신은 덜 신뢰적이었습니다. Issue 본문의 멘션이 Eval에 도달하지 못해, 올바른 규칙도 도움이 되지 못했습니다.

저는 이 결과를 자율 CI 수정으로 일반화하지 않겠습니다. 저장소는 작았고 규칙은 좁았으며 병합은 사람이 제어했습니다. 다른 곳에서는, 그린에서 시작하고, 결정을 점검하고, 명시적으로 승인하며, 홀드아웃 데이터를 분리하고, 독립 점검 후 병합하세요.

다음 단계로는 GitHub 알림 경로를 고치고, 더 다양한 실패 유형으로 워크플로를 반복하겠습니다. 그 증거가 나오기 전까지는 auto 모드를 끄겠습니다.