Aegis chỉ đăng những comment mà một test đỏ đã chứng minh
Một AI review thông thường đọc diff rồi viết ra những chỗ mà model cho là sai. Dev nhận về cả nhận xét đúng lẫn nhận xét bịa, và chỉ phân biệt được hai loại ấy khi tự kiểm từng câu.
Aegis làm khác ở một điểm. Phần AI của aegis có tên là proposer, và proposer không được chỉ nói rằng có lỗi. Với mỗi nghi ngờ, proposer phải viết kèm một test. Bộ lọc chạy test ấy trong một container cô lập. Nếu test đỏ, và đỏ ổn định qua nhiều lần chạy, thì nghi ngờ trở thành một mệnh đề có thật. Aegis lưu mệnh đề ấy vào sổ cái rồi đăng lên merge request. Nếu test xanh thì aegis bỏ nghi ngờ ấy.
Quy trình hoạt động
Một lượt review đi qua mười bước và bốn thành phần. Sơ đồ dưới đây vẽ lượt review gần nhất của project demo: bước đã xong sáng màu, bước đang chạy nhấp nháy, bước lỗi hiện màu đỏ. Màn Demo và màn MR dùng đúng mười bước này.
Từng bước làm gì
- CI gọi aegisDev mở merge request. GitLab CI chạy một job nhỏ, và job ấy gọi API của aegis.
- Lấy mã nguồnServer lấy mã nguồn của merge request về một thư mục làm việc riêng cho lượt này.
- Nạp sổ cáiServer xuất các mệnh đề cũ của project ra file, để proposer không nêu lại điều đã có.
- Khởi động jobServer chạy job image trong một container và đưa thông tin của merge request vào container ấy.
- Đọc cấu hìnhChương trình trong container đọc cấu hình của project từ nhánh đích.
- Proposer nêu nghi ngờProposer đọc diff, tài liệu của project và sổ cái, rồi nêu nghi ngờ. Mỗi nghi ngờ đi kèm một test.
- Bộ lọc chạy testBộ lọc chạy từng test trong một container không có mạng. Ở bước này không model nào chấm điểm. Bộ lọc chỉ đọc kết quả test đỏ hay xanh.
- Đăng commentAegis dùng reviewdog để đăng lên merge request những mệnh đề đã qua bộ lọc.
- Lưu sổ cáiServer nhập kết quả của lượt này vào sổ cái trong Postgres.
- Kết thúcServer ghi lượt review là xong hoặc lỗi, và dashboard hiện kết quả ấy.
Sổ cái
Sổ cái chỉ là một bảng trong Postgres. Mỗi dòng là một mệnh đề, kèm test chứng minh mệnh đề ấy và một trạng thái. Trạng thái proven nghĩa là bộ lọc đã xác nhận mệnh đề nhưng aegis chưa đăng nó. Published nghĩa là comment đã lên merge request. Covered nghĩa là dev đã sửa code, và khi chạy lại thì test của mệnh đề đã xanh. Ở lượt sau, proposer đọc sổ cái trước khi nêu nghi ngờ mới.
| Trạng thái | Mức độ | Mệnh đề | Test chứng minh |
|---|
Phạm vi của bản demo
Bản demo này có
- Một repository thật trên GitLab,
minkhe-group/wallet-api. Đây là một API ví trả trước. - Một merge request tại mỗi thời điểm, cho task WALLET-1042 về hạn mức gửi tiền mỗi ngày.
- Bộ lọc thật, chạy test thật trong container thật.
- Sổ cái thật trong Postgres.
- Comment đăng thật lên merge request bằng reviewdog.
- Dashboard này, để theo dõi từng lượt review và dữ liệu của sổ cái.
Bản demo này chưa có
- Nhiều repository chạy cùng một lúc.
- Nhiều lượt review song song.
- Phục hồi khi server hoặc container dừng đột ngột giữa lượt.
- Quy mô và cách vận hành của môi trường production.
Cách đọc dashboard
Màn Demo cho bạn bấm từng bước: bật hoặc tắt CI, tạo hoặc đóng merge request, chạy AI review thông thường, rồi sửa code. Kết quả của mỗi bước hiện ngay bên dưới các nút. Màn MR dùng để theo dõi. Màn ấy liệt kê mọi lượt review của mọi project, hiện tiến trình từng bước cùng log sự kiện, và cho xem dữ liệu của sổ cái theo từng project.
Chạy aegis trên một merge request thật
Project của bản demo là minkhe-group/wallet-api. Đây là một API ví trả trước, viết riêng để demo. Task WALLET-1042 thêm hạn mức gửi tiền mỗi ngày, và phần code của task này có vài chỗ sai mà phải review kỹ mới thấy.
Bản demo gồm ba pha. Pha một cho AI review thông thường đọc merge request. Sang pha hai, aegis đọc chính merge request ấy. Cuối cùng, ở pha ba, server đẩy một bản sửa lên và aegis đọc lại.
Aegis lấy context của project như thế nào
Trước mỗi lượt, server đọc sẵn một số file của project ở nhánh của merge request rồi đưa vào prompt, nên proposer không phải tự đi tìm tài liệu của project. Các file ấy đến từ hai nguồn.
Nguồn thứ nhất: các file có tên cố định ở gốc project
| Đường dẫn | Có trong project | Số ký tự |
|---|
Nguồn thứ hai: các file mà project tự khai
File AGENTS.md của project có thể chứa một khối aegis-context-prompts, liệt kê thêm tối đa mười file, ví dụ tài liệu về nghiệp vụ hay quy tắc về tiền. Project tự quyết định proposer cần đọc gì, và aegis không đoán thay.
| Đường dẫn | Có trong project | Số ký tự |
|---|
Cấu hình của project
Aegis đọc file .aegis/config.yml từ nhánh đích, không đọc từ nhánh của merge request. Nhờ vậy một merge request không thể tự nâng giới hạn của chính nó. File ấy khai báo model của proposer, số nghi ngờ tối đa mỗi lượt, lệnh chạy test của project, mẫu để nhận ra mã task trong tiêu đề merge request và ngân sách tối đa cho mỗi lượt. Khoá nào không khai thì aegis dùng giá trị mặc định.
Điều khiển
Việc nên làm tiếp
Đang tải trạng thái của bản demo.
Ba pha của bản demo
Pha 1: AI review thông thường
- Bấm Tắt CI, để aegis không chạy trên merge request này.
- Bấm Tạo MR.
- Bấm Chạy AI review thông thường và chờ model đọc xong.
- Đọc kết quả ở phần Kết quả của AI review thông thường.
- Bấm Đóng MR.
Pha 2: proposer của aegis
- Bấm Xoá sổ cái nếu sổ cái còn mệnh đề của lần chạy trước. Proposer không nêu lại một hành vi đã có mệnh đề, nên nếu không xoá thì lượt mới sẽ không có mệnh đề nào.
- Bấm Bật CI.
- Bấm Tạo MR. Pipeline chạy và gọi API của aegis.
- Theo dõi từng bước của lượt review ở phần Kết quả của proposer.
- Đọc các mệnh đề mà bộ lọc đã chứng minh.
Pha 3: sửa code rồi review lại
- Bấm Sửa code. Server đẩy một commit sửa lỗi lên merge request.
- Pipeline chạy lại và proposer review lần nữa.
- Chọn lượt mới nhất ở phần Kết quả của proposer rồi so với lượt trước.
Kết quả của AI review thông thường
chưa chạyKết quả của proposer
Các mệnh đề của merge request này
| Trạng thái | Mức độ | Mệnh đề | Test chứng minh |
|---|
Reviews
Progress
Event log
| Time | Source | Event | Level | Details |
|---|
| State | Severity | Statement | Files | Tests | Updated |
|---|