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.

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:
-
offloạ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". -
autobắ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-integritymà 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 |
|
|
Mô hình DeepSeek |
Nhà cung cấp Harness đã cấu hình |
|
|
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+, |
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:
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ì.

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 với quan sát CI. Ảnh: Tác giả.

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.

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.

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 đó.

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

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.
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:
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_idvà 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.