Dùng Jev và Clef cùng AgentKit

Bạn đang sửa một lỗi. Agent đã tìm ra nguyên nhân và cho rằng bản sửa đơn giản. Bạn muốn có thêm một nhận định trước khi tiếp tục. Jev hoặc Clef có thể đánh giá bản tóm tắt của công việc, rồi AgentKit đặt kết quả cạnh đánh giá ban đầu để bạn xem xét.

Bạn không cần nhớ lệnh hoặc tự viết JSON để làm việc theo cách này. Bạn có thể yêu cầu Agent chuẩn bị và chạy phép đối chiếu. Cần thiết lập tài khoản, khóa API và quyền sử dụng lần đầu; các lần sau dùng lại cấu hình đã lưu.

Jev và Clef giúp gì cho bạn?

Jev của TypeSafe và Clef của Cloudflare là các mô hình chuyên đưa ra nhận định theo câu hỏi có đáp án hoặc thang đánh giá xác định. Chẳng hạn: bản sửa này đơn giản, vừa hay phức tạp?

Agent lập trình vẫn tìm nguyên nhân, viết code và kiểm tra kết quả. Jev/Clef đánh giá thông tin mà Agent chuẩn bị. Chất lượng nhận định phụ thuộc vào thông tin đó: nếu bản tóm tắt bỏ sót ảnh hưởng quan trọng, câu trả lời vẫn có thể sai.

Bạn không cần bật tính năng này cho mọi công việc. Hãy bắt đầu với một quyết định cụ thể mà bạn muốn kiểm chứng. Với việc chưa rõ nguyên nhân, tiếp tục chẩn đoán cùng Agent trước.

Một lần đối chiếu diễn ra thế nào?

1. Agent đưa ra đánh giá ban đầu. Ví dụ: nguyên nhân đã rõ, bản sửa nằm trong một file nên được đánh giá là đơn giản.
2. Agent chuẩn bị bản tóm tắt. Bản tóm tắt chỉ chứa thông tin cần thiết và được kiểm tra để loại dữ liệu nhạy cảm.
3. AgentKit kiểm tra quyền sử dụng. Cần bật tính năng, cho phép đúng mục đích và có khóa API của nhà cung cấp đã chọn.
4. Jev/Clef đánh giá bản tóm tắt. AgentKit gửi thông tin đã chuẩn hóa cùng câu hỏi; đánh giá ban đầu được giữ cục bộ trong phép đối chiếu quyết định.
5. Agent báo lại hai kết quả. Bạn xem chỗ đồng ý, chỗ khác nhau và quyết định có hiệu lực.

Cách chạy này gọi là shadow, tức đối chiếu song song. Quyết định ban đầu vẫn có hiệu lực dù mô hình trả lời khác. Kết quả không tự chạy Skill, sửa file, phê duyệt triển khai hoặc thay model của Agent lập trình.

Bật cấu hình chỉ cho phép sử dụng. Nó không tự tạo phép đối chiếu cho mọi tin nhắn hay mỗi lần khởi động Skill. Khi muốn đối chiếu một công việc, hãy yêu cầu rõ mục đích và phạm vi.

Bắt đầu lần đầu

1. Chọn tài khoản bạn sẽ sử dụng

Chỉ cần chọn một nhà cung cấp. AgentKit không tự chuyển sang nhà cung cấp khác khi có lỗi. Xem TypeSafe hoặc hướng dẫn tạo token Workers AI để chuẩn bị tài khoản. Chưa có tài khoản? Bạn vẫn có thể nhờ Agent chuẩn bị và kiểm tra đầu vào cục bộ, nhưng chưa lấy được nhận định thật từ Jev/Clef.

2. Nhờ Agent thiết lập một lần

Ví dụ dưới đây chọn Clef Flash để thử đánh giá độ phức tạp của bản sửa. Bạn có thể chép vào cuộc trò chuyện với Agent:

Giúp tôi thiết lập Clef Flash trong AgentKit để đối chiếu độ phức tạp của bản sửa. Kiểm tra CLI có hỗ trợ trước. Hướng dẫn tôi lưu credential cục bộ, không yêu cầu tôi gửi key vào chat và không in giá trị bí mật. Tôi cho phép cấu hình ở cấp người dùng cho mục đích này; giữ nguyên các thiết lập không liên quan. Sau khi thiết lập, kiểm tra đầu vào cục bộ và báo rõ phần nào chưa xác minh. Chưa gọi provider cho tới khi tôi chọn công việc cần đối chiếu.

Nếu chọn Jev, thay câu đầu bằng "Giúp tôi thiết lập Jev qua TypeSafe trong AgentKit để đối chiếu độ phức tạp của bản sửa." Agent cần xác định model được tài khoản của bạn hỗ trợ.

Bạn cung cấp credential qua môi trường cục bộ hoặc .env cấp người dùng, thường là ~/.agentkit/.env, theo hướng dẫn của Agent. Không dán key vào chat hay lưu trong repository. AgentKit không lấy các credential này từ .env của dự án.

Cấu hình được lưu cho những lần sau. Không cần chạy lại lệnh bật tính năng mỗi khi mở phiên mới. Nếu Agent chạy trên máy hoặc môi trường khác, môi trường đó cũng cần cấu hình và quyền truy cập credential phù hợp.

3. Áp dụng vào một công việc

Sau khi Agent đã tìm ra nguyên nhân của lỗi, bạn có thể yêu cầu:

Đối chiếu đánh giá độ phức tạp của bản sửa vừa chẩn đoán bằng provider đã cấu hình. Chỉ dùng bản tóm tắt không chứa mã nguồn, dữ liệu cá nhân hoặc thông tin mật. Cho tôi xem nội dung sẽ gửi trước; nếu chưa thể loại thông tin nhạy cảm thì dừng ở bước chuẩn bị. Dùng ak eval decision với consumer fix-complexity, tức phần tích hợp đánh giá độ phức tạp. Kiểm tra đầu vào bằng --validate-only trước, chưa gọi provider. Giữ nguyên đánh giá ban đầu để so sánh.

Chưa có bug thật để thử? Sau bước thiết lập, dùng prompt dưới đây thay cho prompt chuẩn bị phía trên. Bạn không cần điền thêm thông tin:

Chuẩn bị một phép đối chiếu trong AgentKit cho tình huống hoàn toàn giả định: hàm định dạng trong một file biến số 0 thành chuỗi rỗng vì kiểm tra falsy. Trong tình huống này, nguyên nhân đã xác nhận; cách sửa là chỉ kiểm tra null hoặc undefined. Không có quyết định kiến trúc hay yếu tố bảo mật. Đánh giá ban đầu là simple. Không tạo hoặc sửa mã nguồn để dựng bug này. Dùng ak eval decision với consumer fix-complexity. Tự chuẩn bị JSON đúng schema mà CLI đang cài hỗ trợ; giữ đánh giá ban đầu ở phần legacy, không đưa vào state gửi provider. Chạy --validate-only, cho tôi xem dữ liệu sẽ gửi và kết quả kiểm tra cục bộ. Chưa gọi provider.

Mẫu này giúp kiểm tra đầu vào và, sau khi bạn cho phép gọi API, kết nối tới provider. Nó không chứng minh chất lượng đánh giá trên bug thật.

Sau khi đã xem nội dung của công việc thật hoặc mẫu giả định, bạn có thể cho phép một lần gọi:

Tôi đồng ý gửi bản tóm tắt này tới provider đã cấu hình cho một lần đối chiếu, bao gồm chi phí API có thể phát sinh. Hãy chạy bằng ak eval decision với consumer fix-complexity. Báo status, provider_attempted, model thực tế, hai đánh giá, điểm khác nhau và effective_decision (quyết định vẫn có hiệu lực). Nếu không hoàn tất, báo fallback_reason; không mô tả kết quả kiểm tra cục bộ như một lần gọi provider thành công.

Đây là cách bắt đầu với phạm vi rõ ràng. Quyền cấu hình được lưu không có nghĩa là mọi dữ liệu của dự án đều phù hợp để gửi. Nếu bạn đã cho phép một phạm vi công việc cụ thể, Agent có thể làm trong phạm vi đó mà không cần hỏi lại từng lệnh; quyền kỹ thuật trong AgentKit vẫn phải hợp lệ.

Bạn nên nhận được gì?

Một báo cáo dễ đọc cần nói rõ lần gọi đã hoàn tất hay chưa, model đã dùng, đánh giá ban đầu, nhận định của provider và quyết định có hiệu lực. status: completed cho biết đã nhận kết quả đánh giá từ provider; provider_attempted: true riêng lẻ chỉ cho biết đã thử gọi, chưa bảo đảm thành công. effective_decision là quyết định vẫn được dùng trong workflow.

Ví dụ minh họa, không phải kết quả đã đo:

Đã hoàn tất đối chiếu bằng Clef Flash. Đánh giá ban đầu: đơn giản. Clef Flash: mức vừa. Hai đánh giá khác nhau; quyết định có hiệu lực vẫn là đơn giản. Cần kiểm tra lại phạm vi ảnh hưởng trước khi thay đổi cách xử lý.

Bạn có thể yêu cầu Agent kiểm tra nguyên nhân bất đồng trong code hoặc bằng bằng chứng hiện có. Câu trả lời khác nhau chỉ là lý do để xem xét thêm; provider không nhất thiết trả về lời giải thích cho lựa chọn của nó.

Độ tin cậy cao không bảo đảm nhận định đúng. Trong shadow, công việc ban đầu vẫn chạy; không coi số việc mô hình đề xuất bỏ qua là chi phí thực sự đã tiết kiệm.

Dùng tiếp và dừng sử dụng

Lần sau, bạn chỉ cần nêu việc cần đối chiếu. Muốn áp dụng cho lựa chọn Skill, review hoặc quy trình khác, nhờ Agent kiểm tra phần tích hợp tương ứng và quyền riêng cho mục đích đó. Quyền đánh giá độ phức tạp không tự cấp quyền cho mọi phần tích hợp. Mỗi phần cũng cần dạng đầu vào phù hợp.

Đối chiếu chọn Skill có giới hạn kích thước danh mục. Agent cần giữ đầy đủ các lựa chọn liên quan hoặc bỏ qua phép đối chiếu khi vượt giới hạn; không được bớt Skill cạnh tranh để vừa đầu vào. Phần đánh giá UI nhận bản tóm tắt bằng văn bản, không nhận ảnh hay video trực tiếp qua tích hợp này.

Với đánh giá tác động đến test, shadow giữ kế hoạch hiện có; advisory chỉ được bổ sung kiểm tra hoặc mở rộng xác minh, không bỏ kiểm tra bắt buộc hay quan trọng. Phân loại E2E chỉ đưa ra khuyến nghị. Các giới hạn và yêu cầu phê duyệt của quy trình vẫn áp dụng.

Khi muốn dừng, bạn có thể nói:

Tắt semantic decision ở cấp người dùng trong AgentKit. Giữ nguyên các cấu hình khác và xác nhận đã tắt mà không in credential.

Tắt tính năng sẽ dừng sử dụng provider qua cơ chế này. Nếu ngừng dùng tài khoản, bạn còn cần xóa credential cục bộ và thu hồi key tại nhà cung cấp.

Tham khảo lệnh

Xem chi tiết cấu hình, nguồn credential, quyền consumer và ví dụ CLI tại Chạy thử nghiệm semantic decision và tham khảo ak eval decision.