# Làm thế nào để tái hiện lỗi của tác nhân lập trình trên nhiều phiên bản mô hình? > Hãy tái hiện lỗi bằng cách lưu toàn bộ lần chạy thành một fixture kiểm thử có phiên bản, rồi phát lại cùng prompt, commit kho mã, hợp đồng công cụ, môi trường và quy tắc dừng với các ID mô hình cố định. So sánh sự kiện có cấu trúc và trạng thái kho mã cuối cùng, không chỉ văn bản của trợ lý. # Làm thế nào để tái hiện lỗi của tác nhân lập trình trên nhiều phiên bản mô hình? Một bản tái hiện hữu ích là thí nghiệm có thể thực thi, không phải bản sao transcript. Bắt đầu từ trạng thái kho mã gây lỗi, cố định mọi đầu vào tác nhân có thể thấy và xác định một điều kiện lỗi có thể kiểm tra bằng máy. Sau đó phát lại fixture nhiều lần với các phiên bản mô hình cố định. Một lần chạy tác nhân kết hợp hành vi mô hình với công cụ, tệp, kết quả mạng, điều phối và thời gian. Nếu bất kỳ phần nào thay đổi, kết quả khác không chứng minh mô hình đã sửa hay gây ra vấn đề. ## Xác định lỗi bằng một điều kiện kiểm tra Viết điều kiện quan sát nhỏ nhất phân biệt lỗi với thành công. Ví dụ tốt gồm test vẫn đỏ, thay đổi tệp bất ngờ, lệnh bị cấm, migration bị thiếu hoặc bản vá biên dịch được nhưng đổi hành vi. Tránh nhận xét như "câu trả lời trông tệ hơn". Gói chấp nhận có thể yêu cầu: * test hồi quy ban đầu vượt qua; * mọi test có sẵn vẫn vượt qua; * không đổi tệp ngoài allowlist; * tác nhân dừng trong số lệnh gọi cố định; * diff cuối không có bí mật được sinh hoặc lockfile drift. ## Ghi lại toàn bộ envelope của lần chạy Prompt chỉ là một đầu vào. Hãy lưu cạnh fixture: | Lớp | Nội dung cần cố định | Vì sao nó đổi kết quả | |---|---|---| | Kho mã | Commit, submodule, bản vá chưa commit, fixture chưa track | Tác nhân suy luận từ trạng thái nguồn chính xác | | Chỉ dẫn | Prompt hệ thống, quy tắc kho, tác vụ người dùng | Khác biệt nhỏ có thể đổi kế hoạch | | Mô hình | Nhà cung cấp, ID bất biến, tham số | Alias và mặc định có thể dịch chuyển | | Công cụ | Tên, JSON schema, quyền, timeout | Khả năng công cụ định hình kế hoạch | | Môi trường | Image container, OS, kiến trúc, khóa phụ thuộc | Lệnh và test có thể chạy khác | | Dữ liệu ngoài | Phản hồi HTTP mock, đồng hồ, đầu vào ngẫu nhiên | Dịch vụ live tạo drift | | Bộ điều phối | Giới hạn vòng, retry, nén ngữ cảnh | Cùng mô hình có thể nhận lịch sử khác | Che bí mật, nhưng giữ thông tin về việc thông tin xác thực có sẵn và phạm vi của nó. ## Ghi sự kiện có cấu trúc, không chỉ văn bản Lưu từng yêu cầu và phản hồi mô hình, tool call, kết quả công cụ, lần thử lại và quyết định dừng theo thứ tự. Thêm hash cho đầu ra lớn và lưu artifact gốc riêng. ```json { "run_id": "agent-regression-042", "fixture": "sha256:...", "model": "provider/model-version", "event": "tool_result", "tool": "run_tests", "exit_code": 1, "stdout_sha256": "..." } ``` Sự kiện có cấu trúc cho biết mô hình mới chọn công cụ khác, diễn giải cùng lỗi khác hay nhận bằng chứng khác. ## Cố định phiên bản và loại bỏ biến thiên trực tiếp Dùng ID mô hình có ngày hoặc bất biến khi có thể. Đừng so lỗi lịch sử với alias `latest`, vì alias có thể đã trỏ đến build khác. Chạy trong container hoặc máy ảo sạch. Thay tìm kiếm live và package index thay đổi bằng phản hồi đã ghi hoặc snapshot nội bộ. Cố định đồng hồ nếu logic phụ thuộc ngày. Nếu phải truy cập mạng, ghi mọi phản hồi và đánh dấu test là chỉ được kiểm soát một phần. Seed ngẫu nhiên có ích nhưng không cố định inference phân tán, thời điểm công cụ hay thay đổi phía nhà cung cấp. ## Phát lại một ma trận, không phải một cặp đơn Một lần chạy mỗi phiên bản không thể tách hồi quy khỏi biến thiên lấy mẫu. Dùng ma trận nhỏ giữ fixture không đổi: | Phiên bản mô hình | Số lần | Tỷ lệ đạt | Trung vị lệnh gọi | Dấu hiệu lỗi | |---|---:|---:|---:|---| | ID baseline cố định | 5 | 4/5 | 9 | Bỏ sót test biên | | ID ứng viên cố định | 5 | 1/5 | 13 | Sửa tệp được sinh | | Ứng viên với prompt cũ | 5 | 1/5 | 12 | Cùng dấu hiệu | Năm lần cho cái nhìn ban đầu. Tăng mẫu cho lỗi không ổn định hoặc tác động cao. Giữ temperature và kiểm soát lấy mẫu bằng nhau trừ khi đó là đối tượng thí nghiệm. ## So sánh quyết định và trạng thái kho mã So sánh riêng bốn lớp: * sự kiện mô hình và công cụ đã chuẩn hóa; * lệnh và mã thoát; * cây tệp và bản vá cuối; * kết quả test chấp nhận và mức dùng tài nguyên. Không cần suy luận bằng ngôn ngữ tự nhiên giống nhau. Hai phiên bản có thể đi đường khác nhưng tạo bản vá đúng tương đương; ngược lại, văn bản giống có thể che lệnh hoặc thay đổi tệp khác biệt. ## Thu nhỏ fixture sau khi tái hiện Khi lỗi đã lặp lại, lần lượt bỏ tệp, công cụ, đoạn prompt và lệnh gọi ngoài không liên quan. Fixture nhỏ chạy nhanh hơn và cho thấy ranh giới nguyên nhân. Giữ hai artifact: bản phát lại đầy đủ để kiểm toán và test hồi quy tối thiểu để đánh giá liên tục. Thêm trường hợp tối thiểu vào cổng nâng cấp mô hình. ## Dùng adapter mô hình có tính di động Gateway như Atlas Cloud có thể đặt nhiều mô hình sau một client tương thích OpenAI, nhưng tương thích không làm hành vi mô hình giống nhau. Giữ ID mô hình, tùy chọn nhà cung cấp và khác biệt định dạng công cụ trong adapter. Bộ kiểm thử chung nên sở hữu fixture, log sự kiện, retry và điều kiện. Cấu trúc này cho phép cùng một bản tái hiện chạy qua nhiều nhà cung cấp mà không viết lại logic đánh giá. ## Kết luận Để tái hiện lỗi tác nhân lập trình, hãy cố định envelope lần chạy, phát lại các mô hình cố định nhiều lần và đánh giá kết quả có thể thực thi. Nếu không thể tái hiện đúng sự cố, hãy ghi đầu vào nào vẫn live và coi kết quả là nghiên cứu so sánh, không phải bằng chứng hồi quy mô hình. ## FAQ ### Cần lưu những gì để tái hiện lỗi của tác nhân lập trình? Lưu commit và bản vá chưa commit, prompt và chỉ dẫn hệ thống, ID mô hình, tham số, schema và kết quả công cụ, image môi trường, tệp khóa phụ thuộc, chính sách thông tin xác thực và mạng, cùng điều kiện thành công chính xác. ### Có nên phát lại lỗi bằng alias mô hình latest không? Không. Hãy dùng ID mô hình bất biến hoặc có ngày. Alias latest có thể đổi trong lúc kiểm thử và khiến bạn không thể quy kết kết quả cho một phiên bản cụ thể. ### Vì sao seed ngẫu nhiên cố định chưa đủ? Seed không cố định hạ tầng nhà cung cấp, thời điểm chạy công cụ, kết quả retrieval hay bản sửa đổi mô hình. Nó chỉ là một biện pháp kiểm soát, không phải bảo đảm đầu ra xác định. ### Tín hiệu đạt hoặc không đạt tốt nhất cho tác nhân lập trình là gì? Ưu tiên điều kiện có thể thực thi như kiểm thử, kết quả lint, diff tệp dự kiến, kiểm tra tệp bị cấm và mã thoát lệnh. Độ giống văn bản thường quá yếu cho tác vụ lập trình. ### Nên chạy lại bao nhiêu lần cho mỗi phiên bản mô hình? Chạy đủ để phân biệt hồi quy ổn định với biến thiên lấy mẫu. Năm lần là điểm khởi đầu hữu ích; lỗi có tác động cao có thể cần hai mươi lần trở lên. ### Cùng một bộ kiểm thử có thể so sánh mô hình từ nhiều nhà cung cấp không? Có, nếu bạn chuẩn hóa yêu cầu, hợp đồng công cụ, nhật ký sự kiện và điều kiện đầu ra. Giữ tùy chọn riêng của nhà cung cấp trong adapter.