AI Agent Sửa Lỗi Code: Xây Dựng Agent Tự Tái Hiện Bug Trước Khi Khắc Phục

Một AI agent tự sửa lỗi chỉ hoạt động hiệu quả khi tuân theo đúng một quy tắc: không tái hiện được thì không sửa. Agent biến báo cáo lỗi thành một bài kiểm thử thất bại ngay tại thời điểm hiện tại, vá code trên một branch cô lập, chạy lại bài kiểm thử đó cùng toàn bộ bộ test, và chỉ báo cáo lại khi mọi thứ đều xanh. Con người vẫn là người merge. Nếu không thể tái hiện lỗi, nó giữ im lặng.

Dùng thử Apidog ngay hôm nay

Đội ngũ DeepSeek Harness đã đưa ý tưởng này đến với đông đảo độc giả vào ngày 1 tháng 11 năm 2026, trong một bài viết về thiết kế super-agent. Hướng dẫn này biến ý tưởng đó thành một pipeline mà bạn có thể xây dựng ngay trong tuần này, với việc tái hiện lỗi được viết dưới dạng một bài kiểm thử API mà agent của bạn tự tạo và chạy từ terminal.

Tại sao "agent, sửa lỗi này" thất bại nếu không có bước tái hiện

Yêu cầu một coding agent sửa một báo cáo lỗi và bạn thường nhận lại một bản diff trông đầy tự tin. Nhưng bạn không thể biết nó sửa đúng lỗi của bạn, một lỗi mà nó tưởng tượng ra, hay chẳng sửa gì cả.

Thiếu bước tái hiện lỗi, ba điều sau sẽ xảy ra:

• Agent phỏng đoán nguyên nhân. Nó chọn dòng có khả năng cao nhất dựa trên thông báo lỗi và chỉnh sửa dòng đó.
• "Đã sửa" không có định nghĩa rõ ràng. Bằng chứng duy nhất là bản tóm tắt của chính agent.
• Lỗi hồi quy lọt lưới. Một bản vá vào một validator dùng chung có thể sửa được một endpoint nhưng làm hỏng bốn endpoint khác.

Một bài kiểm thử thất bại giải quyết cả ba vấn đề: nó cố định lỗi, định nghĩa "hoàn thành", và ở lại trong bộ test của bạn như một bước kiểm tra hồi quy.

Nguồn gốc của ý tưởng "tái hiện và sửa lỗi một cách thầm lặng"

Trong bài "Exploring Super-agent Design," đội ngũ DeepSeek Harness mô tả một chính sách từ nhóm người dùng của họ: khi có người báo cáo lỗi, một agent sẽ cố gắng tái hiện lỗi đó ở chế độ nền. Nó chỉ lên tiếng khi có một bản sửa lỗi đơn giản đã được xác nhận. Nếu không, nó im lặng.

Bài viết gọi đây là speculative execution và kết hợp nó với hai thành phần mà bạn sẽ tái sử dụng ở đây. Workers nhận một phiên cô lập cho mỗi tác vụ, đầy đủ công cụ và model mạnh nhất, và báo cáo cho một router thay vì nói chuyện trực tiếp với con người. Một watchdog là một phiên riêng biệt kiểm tra xem từng worker đang tiến triển hay đi chệch hướng.

Một lưu ý: bài viết mô tả một kiến trúc, không phải các tính năng DeepSeek Harness đã ra mắt. Một phần của nó nằm trong plugin nguyên mẫu dsh-superagent-prototype, mà các tác giả cho biết không phải sản phẩm chính thức của DeepSeek. Để tìm hiểu mô hình router và worker, xem cách xây dựng một super-agent.

Pipeline sửa lỗi của agent gồm năm bước

Một agent tự sửa lỗi chạy cùng một vòng lặp mỗi lần, với hai cổng kiểm soát:

1. Tiếp nhận: thu thập báo cáo, yêu cầu thất bại và phản hồi mà nó nhận được.
2. Tái hiện: viết một bài kiểm thử thất bại vì đúng lý do được báo cáo. Không có test thất bại, không sửa lỗi.
3. Sửa: vá code trên một branch hoặc worktree cô lập.
4. Chạy lại: bài kiểm thử mới phải đạt, và toàn bộ bộ test hiện có cũng vậy.
5. Giao nộp: mở một pull request kèm bằng chứng, hoặc giữ im lặng.

Bước 1: Tiếp nhận báo cáo lỗi

Agent của bạn không thể tái hiện lỗi kiểu "lịch sử mua lại bị hỏng rồi." Hãy cho bước tiếp nhận một định dạng cố định:

Trường	Ví dụ	Tại sao quan trọng
Endpoint	POST /orders	Handler nào cần đọc
Request	Body với "coupon": null	Đầu vào chính xác gây ra lỗi
Phản hồi thực tế	500, {"error":"internal"}	Điều test phải thấy thất bại
Phản hồi kỳ vọng	201 với một order id	Điều test xác nhận
Môi trường	staging	Nơi chạy việc tái hiện lỗi

Nếu thiếu trường thông tin, agent hỏi lại một lần hoặc truy xuất yêu cầu từ log. Các body lỗi tuân theo RFC 9457 problem details sẽ hữu ích, vì loại lỗi được truyền theo định dạng dễ dự đoán.

Bước 2: Tái hiện lỗi dưới dạng một bài kiểm thử API thất bại

Đây là cổng kiểm soát. Agent biến bản ghi tiếp nhận thành một test case với hai xác nhận — mã trạng thái kỳ vọng và một trường mà phản hồi nên chứa — rồi chạy nó với môi trường thực tế. Ba kết quả có thể xảy ra:

• Nó thất bại vì lý do được báo cáo. Bạn đã có một bản tái hiện lỗi. Tiếp tục.
• Nó đạt. Lỗi không thể tái hiện như mô tả. Ghi log và dừng.
• Nó thất bại vì lý do khác (lỗi xác thực, thiếu dữ liệu, timeout). Đó là một bản tái hiện bị hỏng, không phải lỗi đã xác nhận. Dừng lại.

Chỉ kết quả đầu tiên mở khóa việc sửa lỗi. Đó là ý nghĩa thực tế của chữ "thầm lặng": hai trường hợp còn lại chỉ tạo một dòng log cho người duyệt hàng đợi, chứ không phải tin nhắn trong chat của người dùng.

Hãy viết việc tái hiện lỗi dưới dạng bài kiểm thử API, không phải unit test: agent gọi đúng interface mà người dùng đã gọi, nên nó không thể vô tình tái hiện một lỗi khác.

Bước 3: Sửa code trên một branch cô lập

Khi bản tái hiện lỗi đỏ, worker nhận một bản sao code riêng. Một git worktree là lựa chọn nhẹ nhất: một thư mục làm việc thứ hai trên một branch mới, nên các chỉnh sửa của agent không bao giờ chạm vào checkout của bạn. Chạy dịch vụ từ đó và trỏ môi trường kiểm thử về đó.

Giữ hai ràng buộc chặt chẽ. Bản sửa phải nhỏ: đặt giới hạn như 3 tệp hoặc 50 dòng thay đổi, và coi mọi thứ lớn hơn là báo cáo cho con người. Và nó phải nhắm vào bản tái hiện lỗi: không refactor, đổi tên hay dọn dẹp, vì mỗi thay đổi thừa là thêm việc cho người duyệt phải kiểm tra.

Bước 4: Chạy lại bản tái hiện lỗi và toàn bộ bộ test

Cổng thứ hai gồm hai phần. Trước tiên, agent chạy lại chính test case ở bước 2, không thay đổi, và nó phải đạt. Nếu agent chỉnh sửa các xác nhận để đạt được điều đó, bản sửa lỗi bị coi là thất bại; pipeline của bạn phát hiện điều này bằng cách so diff tệp test trước và sau.

Thứ hai, bộ test hiện có phải giữ màu xanh. Một bản sửa làm một test xanh nhưng ba test đỏ thì quay lại bước 3. Giới hạn thời gian cho vòng lặp, ví dụ 3 lần thử hoặc 20 phút, sau đó dừng và ghi log những gì đã thử. Đây là chỗ watchdog phát huy tác dụng: nó có thể tắt một worker cứ liên tục chỉnh cùng một dòng hoặc đi lạc vào những tệp mà bản tái hiện lỗi không hề chạm tới.

Bước 5: Chỉ giao nộp bản sửa lỗi đơn giản đã được xác nhận

Khi cả hai cổng đều xanh, agent mở một pull request kèm bằng chứng, không phải một câu chuyện: báo cáo, lần chạy thất bại, bản diff, và lần chạy đạt kèm kết quả bộ test. Con người duyệt và merge. Protected branches đảm bảo token của agent có thể push một branch nhưng không bao giờ merge vào main. Nếu bất kỳ cổng nào thất bại, người báo cáo không nhận được gì; agent ghi một dòng log và tiếp tục.

Các rào chắn cho một AI agent tự sửa lỗi

Thiết lập các hàng rào này trước lần chạy tự động đầu tiên:

Rào chắn	Cài đặt	Ngăn chặn điều gì
Phạm vi	Số tệp và dòng tối đa mỗi lần sửa	Việc viết lại code được ngụy trang thành bản sửa lỗi
Giới hạn thời gian	Số lần thử và số phút tối đa mỗi lỗi	Các vòng lặp mất kiểm soát đốt token
Thông tin xác thực	Chỉ staging, không có key production	Một bản tái hiện lỗi tạo ra đơn hàng thật
Quyền merge	Chỉ push branch, không bao giờ merge	Code chưa được duyệt lọt vào main
Toàn vẹn test	So diff tệp test trước và sau	Các xác nhận bị chỉnh sửa cho đạt
Im lặng	Không gửi thông báo cho người dùng khi thất bại	Ồn ào và các tuyên bố chưa được xác nhận trọn vẹn

Thông tin xác thực quan trọng nhất: một bản tái hiện lỗi gọi API thực sự, nên hãy dùng staging hoặc dữ liệu local có sẵn.

Để coding agent của bạn xây dựng bản tái hiện lỗi với Apidog CLI

Bước 2 là trái tim của pipeline, và đó chính là điều Apidog CLI được xây dựng để làm. Coding agent của bạn (Claude Code, Codex, Cursor hoặc OpenCode) viết test case dưới dạng JSON, tạo nó trong dự án Apidog của bạn và chạy nó từ terminal. Bạn chỉ cần viết một prompt.

Thiết lập một lần:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Sau đó đưa cho agent báo cáo lỗi và prompt này:

Here is a bug report for POST /orders in Apidog project <projectId>.
Turn it into an Apidog test case that fails today: assert status 201
and that $.id exists. Run it against staging and confirm it fails for
the reported reason. If it does, fix the handler on a new worktree
branch until the same test passes, run the endpoint's other cases, and
open a PR with both JSON reports. If it doesn't reproduce, stop and log why.

Agent không xây dựng payload từ trí nhớ. Nó đọc schema, tìm một danh mục, xác thực tệp của mình và chỉ sau đó mới tạo test case:

apidog cli-schema get test-case-create
apidog test-case category --project <projectId>
apidog cli-schema validate test-case-create --file repro-orders.json
apidog test-case create --project <projectId> --file repro-orders.json

Tệp nó tạo ra trông như thế này (các ID lấy từ dự án của bạn):

{
  "name": "Repro: POST /orders with null coupon returns 500",
  "apiDetailId": 123456,
  "categoryId": 1,
  "method": "post",
  "path": "/orders",
  "parameters": {},
  "commonParameters": {},
  "requestBody": {
    "type": "application/json",
    "data": "{\"items\":[{\"sku\":\"A-100\",\"qty\":1}],\"coupon\":null}"
  },
  "postProcessors": [
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "status is 201", "subject": "httpCode", "comparison": "equal", "path": "", "value": "201" } },
    { "type": "assertion", "defaultEnable": true, "enable": true,
      "data": { "name": "order id exists", "subject": "responseJson", "comparison": "exists", "path": "$.id" } }
  ]
}

Bây giờ là lần chạy đỏ chứng minh lỗi:

apidog run --test-case <caseId> --project <projectId> -e <stagingEnvId> -r cli,json --out-file repro-before

Trình báo cáo CLI hiển thị xác nhận trạng thái thất bại với mã 500, và repro-before.json được lưu vào apidog-reports/. Sau khi sửa lỗi, agent chạy đúng lệnh đó với --out-file repro-after và cả hai xác nhận đều đạt. Hai tệp đó chính là bằng chứng trong pull request. Cho bước 4, nó chạy mọi test case trên endpoint để bản sửa không thể âm thầm làm hỏng một phần lân cận:

apidog test-case run --project <projectId> --endpoint <endpointId> -e <stagingEnvId> -r cli,json

Thêm --upload-report để hiển thị lần chạy trong ứng dụng Apidog. Sau khi merge, test case tái hiện lỗi ở lại trong dự án của bạn như một bài kiểm thử hồi quy, và cùng lệnh apidog run với -r junit có thể tích hợp vào CI, như được trình bày trong chạy Apidog CLI trong pipeline CI/CD. Để xem thêm các thiết lập khác, xem quy trình làm việc của Apidog CLI với agent và Apidog CLI trong Claude Code. Apidog Free hỗ trợ tới 4 người dùng, nên bạn có thể thử toàn bộ vòng lặp mà không cần gói trả phí.

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

AI agent có thực sự sửa được lỗi mà không cần con người không?

Nó có thể tự tái hiện, vá và chứng minh nhiều lỗi đơn giản, nhưng không nên tự merge chúng. Hãy giữ con người ở bước merge, và để branch protection thực thi điều đó.

Điều gì xảy ra nếu agent không thể tái hiện lỗi?

Nó dừng lại và ghi log những gì đã thử. Một lỗi không thể tái hiện là một bản sửa không thể xác nhận, nên mọi bản vá đều chỉ là phỏng đoán. Sau đó con người sẽ bổ sung chi tiết cho báo cáo hoặc đóng nó.

Làm sao ngăn agent chỉnh sửa bài kiểm thử để nó đạt?

Lưu một bản sao hoặc hash của test case khi nó lần đầu thất bại và so sánh trước khi chấp nhận bản sửa lỗi. Giữ tệp test ngoài các đường dẫn mà worker được phép chỉnh sửa.

Tôi có cần DeepSeek Harness để xây dựng điều này không?

Không. Bài viết mô tả một thiết kế, và plugin nguyên mẫu của nó không phải sản phẩm chính thức của DeepSeek. Bất kỳ coding agent nào chạy được lệnh shell đều dùng được, kể cả Claude Code trong GitHub Actions. Xem DeepSeek Harness là gì nếu bạn muốn thử nó ở đó.