Chuyển đến nội dung chính

Hướng dẫn DeepSeek Superagent: Quan sát CI và Cấp quyền Sửa lỗi

Xây dựng quy trình sửa CI GitHub với DeepSeek Superagent, sau đó dùng chế độ observe, pytest, dữ liệu holdout và rà soát của con người để kiểm tra một bản sửa pandas.
· 14 phút đọc

Khám phá cùng AI

DeepSeek tung nguyên mẫu dsh-superagent lên GitHub mà không ồn ào, và chưa đầy bốn ngày đã vượt 17.000 sao. Đây là một nguyên mẫu nghiên cứu xây dựng trên DeepSeek Harness, công cụ theo dõi sự kiện trong repository và đối chiếu chúng với các quy tắc của đội ngũ. Chế độ observe ghi nhận quyết định mà không chỉnh sửa mã.

Tôi muốn thử nghiệm và xem DeepSeek Superagent xử lý hai kết quả GitHub Actions màu đỏ như thế nào. Một lỗi do liên kết README hỏng; lỗi còn lại do khoản thanh toán bị tính hai lần. Chỉ lỗi doanh thu mới nên dẫn đến sửa mã.

Dự án là một pipeline doanh thu nhỏ dùng pandas. Liệu agent có thể bỏ qua lỗi README, chờ được cho phép, và sửa lỗi phát lại mà không xóa các khoản thanh toán hợp lệ của cùng một đơn hàng? Thay đổi tự động dừng ở pull request. Rà soát thủ công, kiểm chứng bằng bộ holdout, hợp nhất thủ công, và CI phục hồi sẽ hoàn tất thí nghiệm.

Bạn sẽ học cách:

  • Cô lập nguyên mẫu và tài khoản GitHub của nó.
  • Theo dõi CI của nhánh mặc định mà không thay đổi mã.
  • Tách lỗi tài liệu và lỗi doanh thu bằng một quy tắc.
  • Cấp quyền và kiểm tra một bản sửa.

Hiểu biết về Python, pytest và GitHub Actions là đủ để theo dõi. Nếu cần ôn lại, tôi khuyên bạn nên học khóa Introduction to Testing in Python hoặc Intermediate GitHub Concepts.

Tóm tắt nhanh

Quy trình làm việc tách chất lượng quyết định khỏi chất lượng sửa lỗi:

  • Lọc CI theo quy tắc: bỏ qua lỗi và phục hồi của tài liệu; lỗi doanh thu được đánh dấu "sẽ chấp nhận".

  • Chế độ observe không thay đổi mã: chỉ bắt đầu công việc sau khi người có quyền cho phép gửi yêu cầu.

  • Tiếp nhận GitHub không ổn định: đề cập trong nội dung Issue thất bại ba lần, và một lần tái hiện bị mất hai bình luận.

  • Bản sửa tái hiện được: mọi cách khắc phục đều dùng event_id và vượt qua bộ holdout.

Các kết quả này đến từ một kịch bản lặp lại ba lần. Chúng không chứng minh độ tin cậy sản xuất.

DeepSeek Superagent là gì?

DeepSeek Superagent theo dõi một repository GitHub thông qua DeepSeek Harness. Quy tắc của đội ngũ quyết định liệu một sự kiện có xứng đáng để làm việc; các công việc được chấp nhận sẽ vào một phiên riêng. Hướng dẫn này đề cập đến nguyên mẫu đã công bố, không phải các ý tưởng mới ở mức thiết kế.

Harness cung cấp runtime; Superagent bổ sung giám sát sự kiện và cấp quyền. Bài giải thích về agent harness của chúng tôi trình bày công cụ, bộ nhớ và điều khiển.

DeepSeek Superagent hoạt động thế nào?

Một sự kiện GitHub mới có thể đi qua bốn giai đoạn. Những giai đoạn này giữ quyết định tách biệt với thay đổi mã:

  • Nguồn và Kích hoạt (Trigger): việc thăm dò GitHub biến mỗi sự kiện thành một Trigger trên Issue, pull request, hoặc main.

  • Tiếp nhận (Admission): cổng phân loại thành yêu cầu rõ ràng, ứng viên suy luận, hoặc không gì cả.

  • Đánh giá và Quyết định: CI suy luận được so với các quy tắc. Yêu cầu rõ ràng được điều hướng đến Quyết định chấp nhận, lý do explicitRouted.

  • Vé (Ticket) và Trình thực thi: công việc được chấp nhận nhận ủy quyền, phiên worker và thư mục riêng.

Bình luận về sau trên luồng (Thread) của chính Ticket sẽ đến worker của nó mà không có Eval mới. Sơ đồ cho thấy ba đường GitHub: CI của nhánh mặc định, một yêu cầu rõ ràng, và phần rà soát đó. Bên trong đường CI, observe và auto để lại một quy tắc khớp ở hai đầu khác nhau.

Sơ đồ ba đường GitHub trong DeepSeek Superagent: CI nhánh mặc định đi qua admission và Eval theo quy tắc tới bỏ qua, sẽ chấp nhận, hoặc tự tạo Ticket; một yêu cầu rõ ràng được chấp nhận với lý do explicitRouted; một phần review quay lại cùng Ticket và một worker

CI được đánh giá. Yêu cầu sẽ bắt đầu công việc. Ảnh: Tác giả.

Khác biệt giữa chế độ observe và auto là gì?

Chế độ accept chỉ áp dụng cho công việc Superagent suy luận từ một sự kiện. Chọn một trong ba thiết lập:

  • off loại bỏ các ứng viên suy luận.

  • observe đánh giá nhưng ghi kết quả dương tính là "sẽ chấp nhận".

  • auto bắt đầu công việc sau một đánh giá dương tính.

Yêu cầu từ người được phép sẽ hoạt động ở mọi chế độ và tạo Ticket riêng. Để auto tắt cho hướng dẫn này.

Xây dựng quy trình sửa CI ở chế độ Observe

Pipeline sử dụng pytest và hai job GitHub Actions để biến sự kiện thành doanh thu hằng ngày. Superagent chèn một quyết định trước khi bắt đầu công việc. Bài hướng dẫn Claude Code Routines của chúng tôi đề cập một quy trình theo sự kiện khác.

Lần theo lỗi phát lại trong doanh thu hằng ngày

Lỗi đang tính một khoản thanh toán phát lại hai lần. Mỗi dòng có event_id, order_id, dấu thời gian và số tiền. Một đơn hàng có thể có nhiều khoản thanh toán hợp lệ.

Vì vậy khử trùng lặp theo order_id có thể vượt qua kiểm thử phát lại nhưng xóa mất thanh toán thực; khóa đúng là event_id. Hãy tính tổng dự kiến bằng mô-đun csv của Python trước khi cấp quyền cho agent, để đầu ra của agent không trở thành đáp án.

Định nghĩa một lần sửa CI thành công

Thành công phụ thuộc vào những gì quy trình làm việc thực hiện, không chỉ những gì agent nói. Đặt các điều kiện này trước khi thay đổi repository:

  • Bỏ qua lỗi chỉ thuộc tài liệu.

  • Khớp revenue-integrity mà không bắt đầu công việc.

  • Mở pull request chỉ sau một yêu cầu rõ ràng.

  • Giữ nguyên các khẳng định và vượt qua bộ holdout dựng sẵn.

Chuẩn bị bộ holdout trước khi Superagent có quyền truy cập. Điều này giữ hành vi kỳ vọng nằm ngoài dữ liệu phát triển của worker.

Điều kiện tiên quyết và cô lập cho DeepSeek Superagent

Bạn cần khóa API của DeepSeek, hai tài khoản GitHub, và một môi trường Linux dùng rồi bỏ. Về cơ bản Harness, xem hướng dẫn thiết lập cơ bản của chúng tôi.

Phần mềm và tài khoản cần có

Ghim phiên bản phần mềm để một lần nâng cấp không thể làm thay đổi quy trình. Cột cuối ghi lại thiết lập dùng cho kết quả ở phần sau của bài:

Thành phần

Yêu cầu

Dùng tại đây

Hệ điều hành

Linux hoặc WSL

Ubuntu 24.04 LTS trên WSL 2.4.11

Node.js

22.19+ hoặc 24+

22.20.0

DeepSeek Harness

Tương thích với ^0.2.1-alpha.2

0.2.1-rc.3

Mô hình DeepSeek

Nhà cung cấp Harness đã cấu hình

deepseek-flash

pnpm, Git, tmux, jq

pnpm, Git 2.32+, tmux; jq cho script hỗ trợ

11.7.0, 2.43.0, 3.4, 1.7

Python, GitHub CLI

Python 3.8+, gh 2.48+

3.12.3, 2.83.1

Agent cần tài khoản GitHub riêng có quyền ghi vì Superagent đọc thông báo của tài khoản đó. Chỉ thêm những người bảo trì con người có thể cấp quyền làm việc vào danh sách cho phép.

Cô lập agent khỏi tệp cá nhân

Cả hai preset đều cấp quyền đầy đủ cho người dùng hệ điều hành (OS), và trình bao gh không cô lập tiến trình. Hãy dùng một bản phân phối WSL mới với automount và interop tắt:

Nếu bạn đã có máy ảo Linux dùng rồi bỏ, hãy bỏ qua khối WSL và dùng máy đó. Giữ các thông tin xác thực và tệp không liên quan ở ngoài.

# /etc/wsl.conf inside the disposable distribution
[automount]
enabled = false
mountFsTab = false
[interop]
enabled = false
appendWindowsPath = false
[user]
default = superagent

Một người dùng riêng superagent chỉ nên giữ khóa DeepSeek và token của agent. Điều này giảm truy cập vô tình nhưng không phải ranh giới bảo mật; mô hình bảo mật WSL của Microsoft khuyến nghị một máy ảo quản lý riêng biệt bên ngoài WSL cho mã không tin cậy.

Trên GitHub, bảo vệ main bằng yêu cầu pull request, ít nhất một phê duyệt độc lập, và cả hai kiểm tra CI. Cấp quyền ghi cho agent mà không cho phép bỏ qua bằng quản trị viên. Không điều gì trong số này ngăn prompt injection qua nội dung Issue.

Bước 1: Xây dựng Pipeline Doanh thu Python và CI cơ sở

Repository hướng dẫn đã công bố hiện đã có bản sửa được hợp nhất trên main, vì vậy đừng dùng nhánh hiện tại của nó làm trạng thái bắt đầu. Dùng các commit này để tách ba giai đoạn:

Giai đoạn

Commit

Mục đích

Cơ sở xanh

a6d2036

Mã và kiểm thử khởi đầu, trước dữ liệu phát lại

Sự cố thất bại

a29b51b

Dữ liệu phát lại và kiểm thử hồi quy

Bản sửa đã hợp nhất

62bac08

Bản sửa event_id do con người hợp nhất

Pipeline và kiểm thử dưới đây được đơn giản hóa từ cơ sở xanh (a6d2036), không lấy từ main hiện tại. Tạo một repository dùng rồi bỏ từ commit đó trước khi làm theo các bước 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

Hãy dùng repository mới này cho các lỗi có kiểm soát và các nhánh của agent. Để nguyên repository đã công bố; các commit sự cố và giải pháp của nó là tham chiếu để đối chiếu.

"""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

Bộ dữ liệu cơ sở trải qua hai ngày và gồm nhiều khoản thanh toán thực cho một đơn hàng. Pytest kiểm tra tổng đã biết và tình huống đơn hàng chung, và hiện chưa có kiểm thử phát lại:

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]

Đặt tên cho mỗi job theo hành vi nó kiểm tra. Khi đó các tên giống nhau sẽ xuất hiện trong GitHub và trong văn bản Trigger của 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

Nếu pytest thuần không thể import revenue, hãy thêm pytest.ini với pythonpath = .. Xác nhận cả hai job đều vượt qua trên main trước khi cài Superagent.

experiment/holdout đã công bố ghi lại lần chạy gốc nhưng hiển thị trong bản sao công khai. Với thí nghiệm mới, hãy tạo một bộ suite mới nằm ngoài mọi checkout và hệ thống tệp mà worker có thể đọc.

Băm (hash) bộ suite đó trước khi gửi yêu cầu sửa. Bao phủ các trường hợp sau:

  • Giao lại nhiều lần của một sự kiện.
  • Các sự kiện khác nhau có cùng order ID.
  • Một DataFrame đầu vào phải giữ nguyên.
  • Các cột đầu ra kỳ vọng và thứ tự sắp xếp.

Giữ kín bộ suite này cho đến khi review. Bước 6 chạy nó từ môi trường của con người riêng biệt sau khi worker hoàn thành.

Sơ đồ sau tách đầu vào phát triển của worker khỏi lần kiểm tra cuối của người bảo trì.

Sơ đồ tách repository và kiểm thử hiển thị khỏi dữ liệu holdout do con người giữ dùng trước khi merge

Dữ liệu holdout nằm ngoài worker. Ảnh: Tác giả.

Bước 2: Cài DeepSeek Superagent và kết nối GitHub

Cài gói trong một hồ sơ (profile) Harness chuyên dụng, tách khỏi hồ sơ dùng cho công việc hằng ngày. Nạp token tài khoản agent vào AGENT_GH_TOKEN mà không ghi nó vào repository. Sau đó chạy các lệnh này với người dùng 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"

Lưu ý: Các lần chạy trong hướng dẫn này dùng commit 6337fc8, sau đó DeepSeek gộp (squash) vào 8c32a9d.

Dùng ví dụ profile trong repository đã clone để đặt thư mục trạng thái và gắn bảng điều khiển vào 127.0.0.1:3082. Sau đó khởi động dịch vụ trong tmux:

scripts/dsh-superagent start
scripts/dsh-superagent status

Profile này tách việc khởi động lại dịch vụ khỏi các phiên Harness cá nhân. Nó cũng giữ PATH của plugin và thiết lập Git nằm ngoài profile thường dùng.

status có thể báo đang chờ thiết lập hoặc repositoryUnset cho đến khi bạn lưu GitHub Source ở Bước 3. Lúc này, chỉ cần xác nhận runtime phản hồi và bảng Superagent mở được; chưa cần kỳ vọng có Source hay CI cơ sở.

Mở Settings → Models trong profile chuyên dụng và chọn deepseek-flash. Trong Superagent → Settings → Eval và Execution, xác nhận cả hai vai trò thừa kế mô hình của profile đó hoặc đặt tên deepseek-flash rõ ràng.

Bước 3: Cấu hình giám sát GitHub Actions ở chế độ Observe

Để tắt quan sát CI của nhánh mặc định trong khi bạn lưu Source, policy, rule và cài đặt executor. Chỉ bật sau khi repository mới có main xanh, để lần đọc đầu ghi lại trạng thái cơ sở sạch.

Cấu hình GitHub Source

Trong Settings → Sources, đặt repository là EXPERIMENT_REPO, trỏ trường CLI về trình bao gh-agent chuyên dụng, và giữ tắt quan sát CI nhánh mặc định. Lưu Source và chờ bất kỳ khởi động lại nào hoàn tất trước khi thay đổi policy.

Cấu hình chính sách tiếp nhận CI

Một kết quả CI không có người gửi. Hàng tiếp nhận của nó chỉ có một ô, mặc định là ignore. Nếu bạn giữ nguyên thiết lập đó, Eval sẽ không bao giờ thấy CI.

Định nghĩa quy tắc hẹp cho revenue-integrity

Thay các quy tắc ví dụ bằng một quy tắc đặt theo tên kiểm tra. Yêu cầu bộ đánh giá không phỏng đoán nguyên nhân:

{
  "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"}}
  }}
}

Thêm lệnh prepare tạo worktree Git cho mỗi Ticket. Mỗi worker khi đó bắt đầu từ một checkout của repository:

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 điền các biến này cho mỗi Ticket. Kiểm tra thư mục tạo ra có chứa checkout như mong đợi trước khi cấp quyền công việc.

Trình hỗ trợ cấu hình không bắt buộc sẽ ghi cùng Source, policy, Eval và khối executor. Nó giữ tắt quan sát CI trong lần chạy đầu; luôn đặt rõ repository thí nghiệm và người gửi yêu cầu được phép:

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

Giữ tắt thực thi chủ động

Giữ Eval ở observe với mô hình mặc định của profile. Sau mỗi sự kiện, kiểm tra tab Eval để xem Quyết định và tab Execution để xem bất kỳ Ticket nào.

Bật quan sát CI và ghi lại cơ sở

Sau khi cả hai job GitHub Actions vượt qua trên main, hãy bật quan sát CI nhánh mặc định. Với script hỗ trợ, dùng lượt chạy thứ hai:

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

Lần đọc đầu ghi lại trạng thái mà không tạo công việc. Xác minh bốn điều kiện sau:

  • Thiết lập không còn yêu cầu đang chờ.

  • GitHub Source báo ready.

  • Source ghi lại một cơ sở CI sạch.

  • Tab Trigger và Execution không hiển thị Trigger hay Ticket của cơ sở.

Nếu một trong các kiểm tra này thất bại, hãy dừng trước khi tạo lỗi tài liệu. Ảnh chụp Source và Eval thể hiện cấu hình cuối cùng.

Thẻ GitHub Source trong tab Settings của Superagent hiển thị repository, agent CLI và công tắc quan sát CI nhánh mặc định bật

Thẻ GitHub Source với quan sát CI. Ảnh: Tác giả.

Cài đặt Eval của Superagent hiển thị quy tắc revenue-integrity, tiếp nhận CI đặt là inferred, và chế độ accept observe

Cài đặt Eval: một quy tắc, chế độ observe. Ảnh: Tác giả.

Bước 4: Kiểm thử một lỗi GitHub Actions không liên quan

Dùng liên kết README bị hỏng làm một lỗi không liên quan. Vì nhánh được bảo vệ từ chối kiểm tra thất bại, hãy dùng quyền bỏ qua của quản trị viên con người chỉ trong repository dùng rồi bỏ này; không bao giờ cấp quyền đó cho agent.

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

Khi GitHub Actions hoàn tất, docs-check thất bại và revenue-integrity vượt qua. Điều đó khớp với quy tắc tôi đã đặt: Superagent bỏ qua ứng viên vì quy tắc doanh thu không khớp.

Quyết định dùng ignoredFromCard, một lối tắt cho các ứng viên không chạm tới quy tắc đang hoạt động. Vậy nên kiểm tra này bao phủ phần điều hướng, chứ không phải bản thân quy tắc.

Hoàn nguyên thay đổi README và chờ cả hai job vượt qua. Superagent nên bỏ qua lần phục hồi và không làm gì.

Bước 5: Kích hoạt lỗi CI revenue-integrity

Dùng cùng con đường chỉ dành cho con người để thêm dữ liệu sự cố từ repository hướng dẫn. Tóm tắt này cho thấy bản phát lại và các khoản thanh toán riêng trên một đơn hàng mà không có các cột dấu thời gian:

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

Repository giữ đầy đủ các cột dấu thời gian; chúng bị lược bỏ ở đây vì không quyết định danh tính sự kiện. Phép tính độc lập chuẩn bị trước kỳ vọng 15.100 cent, nên hãy đặt giá trị đó trong kiểm thử và thêm 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

Thêm 5.000 cent là do một khoản thanh toán bị tính hai lần. Sửa 15100 thành 20100 hoặc xóa kiểm thử phát lại cũng khiến CI xanh, nhưng cả hai đều không phải là sửa lỗi.

Workflow GitHub Actions thất bại chỉ hiển thị revenue-integrity thất bại. Trigger của nó đến sau khoảng một chu kỳ thăm dò.

Eval đánh dấu ứng viên là "sẽ chấp nhận", trong khi tab Execution vẫn trống. Bộ đánh giá thấy tên và kết luận của kiểm tra, không thấy log pytest, nên biết kiểm tra nào thất bại nhưng không biết lý do.

Quyết định Eval của Superagent được đánh dấu would accept với quy tắc revenue-integrity khớp và không tạo Ticket

Chế độ observe chỉ ghi "sẽ chấp nhận". Ảnh: Tác giả.

Bước 6: Cấp quyền sửa và xác minh Pull Request

Con đường yêu cầu rõ ràng đã nêu ở trên giờ cho phép thực thi. Thông báo GitHub có thể đến muộn.

Xử lý việc bỏ lỡ đề cập trong GitHub Issue

Tại Superagent 6337fc8, GitHub Source chồng lấn các lần thăm dò 5 giây và đọc một luồng đã thông báo từ con trỏ về sau. Thông báo đề cập đến muộn 21 đến 23 giây, nên một lần thăm dò có thể vượt qua tin nhắn.

Thời gian đó giải thích tại sao phần thân Issue mới và một số bình luận không bao giờ thành Trigger. Một báo cáo cộng đồng mô tả cùng kiểu lỗi.

Cấp quyền sửa bằng bình luận trên GitHub

Đăng lại yêu cầu dưới dạng bình luận mới và xác nhận Trigger của nó xuất hiện. Superagent nên chấp nhận như một yêu cầu rõ ràng và khởi động worker.

Cuộc trò chuyện Issue trên GitHub hiển thị bình luận đề cập được lặp lại và xác nhận của tài khoản agent

Bình luận đề cập tạo Ticket đã cấp quyền. Ảnh: Tác giả.

Kiểm tra bản sửa khử trùng lặp sự kiện của agent

Pull request kết quả đặt khóa bản sửa theo event_id. Hãy rà diff thay vì dựa vào mô tả:

 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")

Bản sửa thêm một kiểm thử phát lại và không xóa gì. Lệnh kiểm thử đầu tiên thất bại vì thiếu phụ thuộc. Sau khi worker tạo môi trường ảo, bộ kiểm thử hiển thị đã vượt qua.

Kiểm thử các khoản thanh toán chung một đơn hàng

Yêu cầu thay đổi mà không đề cập agent: chứng minh hai khoản thanh toán trên một đơn hàng, chỉ khác event_id, đều được tính, và một bản phát lại chỉ tính một lần. Việc review nên đi tới cùng Ticket mà không có Eval mới.

Worker phản hồi bằng một commit chỉ thêm kiểm thử và giữ nguyên pipeline. Trước khi phê duyệt, hãy kiểm tra chính xác SHA đầu và chạy lại bộ suite độc lập với revision đó.

Cuộc trò chuyện pull request hiển thị yêu cầu thay đổi, xác nhận của agent, và commit kiểm thử mới

Phản hồi review tiếp tục cùng Ticket. Ảnh: Tác giả.

Kiểm tra bản sửa bằng dữ liệu độc lập

Chạy bộ holdout từ môi trường của con người riêng biệt với đúng đầu pull request. Trên a43c541, cả hai bộ suite vượt 5/5 kiểm thử mà không xóa khẳng định; 62bac08 giữ nguyên cây.

Các kiểm thử do agent tự viết chỉ bao phủ các trường hợp agent chọn.

Bước 7: Hợp nhất bản sửa và đo phục hồi CI

Sau khi hợp nhất, kiểm tra main trở lại xanh và việc phục hồi không khởi động công việc mới. Sau đó xem lại vết sự kiện, thời gian trôi qua, và chi phí nhà cung cấp.

Hợp nhất bản sửa và xác nhận CI phục hồi

Sau phê duyệt và hợp nhất thủ công, cả hai kiểm tra nhánh mặc định đều vượt qua. Superagent bỏ qua lần phục hồi, không bắt đầu việc mới, và đóng Ticket hiện có với kết quả merged.

Đánh giá tiếp nhận sự kiện và quyết định

Theo dõi mỗi sự kiện từ tiếp nhận đến kết quả, như hướng dẫn đánh giá AI agent của chúng tôi mô tả. Qua ba lần tái hiện, các sự kiện đến được Eval đi đúng lộ trình kỳ vọng; những lần bỏ lỡ xảy ra trong tiếp nhận, không phải ở Quyết định của mô hình.

Đo độ đúng của bản sửa, thời gian và chi phí

Cùng kịch bản chạy trong ba repository và phân phối WSL mới với Superagent 6337fc8, Harness 0.2.1-rc.3, deepseek-flash, và một policy. Chi phí dùng mức off-peak thấp hơn của DeepSeek; đây là tái hiện, không phải benchmark.

Lần tái hiện

Bỏ lỡ đề cập trong nội dung Issue

Bỏ lỡ bình luận bổ sung

Từ Ticket đến PR

Holdout

Chi phí mô hình

1

Có

0

91 s

5/5

$0.0282

2

Có

0

87 s

5/5

$0.0283

3

Có

2

140 s

5/5

$0.0310

Cả ba bản sửa đều dùng event_id; mọi kiểm thử holdout đều vượt qua. Khác biệt nhiều hơn ở tiếp nhận: đề cập trong nội dung Issue bị bỏ lỡ mỗi lần, và lần tái hiện thứ ba cũng bỏ lỡ hai bình luận trước khi có một bình luận đến.

Lần tái hiện thứ hai viết lại commit, và phê duyệt đến trước khi holdout chạy lại. Lần kiểm sau đó vượt qua, nhưng thứ tự an toàn hơn là SHA đầu, holdout, rồi phê duyệt.

Hạn chế và khắc phục sự cố của DeepSeek Superagent

Vài lỗi ở đây trông như im lặng, vì vậy hãy bắt đầu bằng việc tìm nơi sự kiện dừng lại. Phần khó chịu là một thông báo bị bỏ lỡ và một lần bỏ qua đúng có thể trông giống nhau.

Lỗi CI không tạo Trigger

Superagent theo dõi thay đổi trong tập lỗi, vì thế lần đọc cơ sở, một kiểm tra cứ tiếp tục thất bại, và các kiểm tra đang chạy sẽ không tạo gì. Một Trigger không có Quyết định thường chỉ vào ô tiếp nhận CI, không phải mô hình.

Yêu cầu GitHub không bao giờ đến

Yêu cầu có thể thất bại khi người gửi không được phép, Source tắt, xử lý bị tạm dừng, hoặc GitHub thông báo muộn. Nếu những kiểm tra đó đều qua, hãy đăng một bình luận mới; chỉnh sửa phần thân Issue không tạo sự kiện.

Giới hạn của sửa CI tự động

Nguyên mẫu không cung cấp ranh giới bảo mật. Worker có toàn quyền người dùng OS, và quy tắc tiết lộ chỉ là văn bản prompt. Hãy cô lập tài khoản agent và giới hạn nó với repository dùng rồi bỏ.

Trước khi chuyển sang auto, hãy thu thập nhiều tuần Quyết định được quan sát, đếm cả chấp nhận sai lẫn bỏ qua sai, và chuyển worker từ WSL sang một máy ảo riêng.

Kết luận

Sự đối chiếu mở đầu vẫn đúng: hai trạng thái CI đỏ không dẫn đến cùng hành động. Superagent bỏ qua docs-check và đánh dấu revenue-integrity là "sẽ chấp nhận", trong khi chế độ observe giữ mã không đổi cho đến khi có người yêu cầu sửa.

Bản vá event_id tương đối thẳng thắn. Tiếp nhận thông báo kém tin cậy hơn: đề cập trong phần thân Issue không bao giờ đến được Eval, nên một quy tắc đúng cũng không giúp được.

Tôi sẽ không khái quát kết quả này cho sửa CI tự động. Repository nhỏ, quy tắc hẹp, và việc hợp nhất do con người kiểm soát. Ở nơi khác, hãy bắt đầu từ trạng thái xanh, kiểm tra Quyết định, cấp quyền rõ ràng, giữ dữ liệu holdout tách biệt, và hợp nhất sau các kiểm tra độc lập.

Bước tiếp theo của tôi sẽ là khắc phục đường thông báo GitHub và lặp lại quy trình với nhiều loại lỗi hơn. Cho đến khi có bằng chứng đó, tôi sẽ giữ tắt chế độ auto.

Câu hỏi thường gặp

DeepSeek Superagent là gì?

DeepSeek Superagent là một plugin của DeepSeek Harness. Nó theo dõi một repository GitHub, nhận đầu vào Feishu tùy chọn, và cấp cho mỗi Ticket được chấp nhận một phiên worker riêng. Nguyên mẫu nghiên cứu đã công bố lược bỏ một số ý tưởng từ bài viết thiết kế.

DeepSeek Superagent có tự động sửa lỗi GitHub Actions không?

Có, nhưng auto chỉ kiểm soát việc một ứng viên CI được suy luận có khớp có thể tạo Ticket hay không. Nó không cấp quyền hợp nhất hay bỏ qua bảo vệ nhánh. Tôi vẫn sẽ yêu cầu rà soát của con người và hợp nhất thủ công.

Chế độ observe hoạt động thế nào trong DeepSeek Superagent?

Chế độ observe lưu một đánh giá suy luận dương tính dưới dạng bỏ qua được đánh dấu "sẽ chấp nhận", cùng với phiên bản Policy đã tạo ra nó. Yêu cầu rõ ràng vẫn hoạt động. Hãy dùng lịch sử Quyết định đó để siết chặt quy tắc trước khi cân nhắc auto.

DeepSeek Superagent có giám sát kiểm tra CI của pull request không?

Superagent theo dõi CI cho các pull request gắn với Ticket đang mở. Trạng thái kiểm tra đầu tiên đặt cơ sở; các thay đổi về sau đi vào Ticket như ngữ cảnh.

DeepSeek Superagent đã sẵn sàng cho sản xuất chưa?

Không. Worker có thể gọi chương trình theo đường dẫn tuyệt đối, vì vậy chặn tên lệnh và trình bao tài khoản không phải sandbox. Hãy chạy trong máy ảo cô lập với thông tin xác thực riêng, bảo vệ nhánh, và hợp nhất thủ công.

Khalid Abdelaty

Tác giả

Khalid Abdelaty

Tôi là một kỹ sư dữ liệu và người xây dựng cộng đồng, làm việc với pipeline dữ liệu, đám mây và công cụ AI, đồng thời viết các hướng dẫn thực hành, tác động cao cho DataCamp và các nhà phát triển mới nổi.

Chủ đề

Liên quan