3 tuần trước, trong Show GN đầu tiên, tôi đã chia sẻ rằng mình đang làm một 5-tier firewall; trong thời gian đó, tôi muốn cập nhật phần chỉnh sửa thiết kế + những gì đã thực sự ship. Bài trước chìm nghỉm với 1 vote/1 bình luận, nhưng vì đã có tiến triển nên đăng lại lần nữa.
▶ Chỉnh từ 5-tier → 4-tier (PUSH / QUEUE / SILENT / AUTO)
Tier "Call" được loại ra và tạm hoãn. Tôi quyết định điều này dựa trên dữ liệu trong quá trình PoC.
▶ Hoàn thiện end-to-end cho agent loop
Email yêu cầu họp đến → phân loại tier → Klorn kiểm tra xung đột lịch → soạn trả lời + bản nháp sự kiện lịch → chờ ở PendingAction → người dùng 1-click approve → gửi đi. Mọi action đều được ký bằng payload hash trước khi phát đi; nếu không khớp với ActionReceipt thì không thể thực thi.
▶ Phần tốn thời gian nhất: invariant test (chưa tới 100 dòng code)
Một bài test sẽ làm build fail nếu action như send_email được thực thi mà không có approval của người dùng. Nếu ai đó gỡ approval check → test fail → build fail → deploy fail. Việc lách qua cơ chế này tự nó không còn là một lựa chọn. Đây là lý do vì sao câu "agent không tự ý gửi" không phải khẩu hiệu marketing mà là sự thật.
▶ Tôi cũng bắt được một bug prod ngoài đời thực
OpenRouter đã retire SKU model :free, khiến toàn bộ autonomous cycle chết với lỗi "404 No endpoints found". Cơ chế failover cũ chỉ xử lý 402 / 403 / 429. Trường hợp "model biến mất" thì chưa xử lý được. Tôi đã thêm multi-model fallback chain, nên dù một SKU upstream chết thì agent cũng không chết theo.
▶ Đang đo retention Day 14+7
Mốc để PoC pass là kích hoạt được 5 ICP. Thành thật mà nói, chỉ một dòng feedback cũng rất được hoan nghênh.
▶ Video 60 giây: https://klorn.ai
▶ Mã nguồn: https://github.com/k08200/klorn
Beta miễn phí + tự động áp dụng PRO. Thật sự cảm ơn những ai đã góp ý cho bài viết đầu tiên.
3 bình luận
Một câu hỏi — với những ai đang vận hành agent / SaaS, khi agent hành động không đúng với ý định của người dùng thì failure mode mà mọi người thấy thường xuyên nhất là gì?
Theo tần suất tôi gặp trong lúc vận hành:
Tôi tò mò về pattern mà những người khác đã gặp.
Trường hợp số 2 xảy ra thường xuyên, và khi dùng fallback làm phương án thay thế thì tùy theo prompt lại phát sinh trường hợp số 1, kéo theo trường hợp số 3 luôn haha
Nếu lúc nào cũng dùng model cao cấp thì chắc sẽ không có chuyện đó, nhưng với dịch vụ hướng tới khách hàng cuối thì mức từ Sonnet trở lên vẫn khá là gánh nặng ..
Haha, tôi thật sự rất đồng cảm với đúng cái trình tự đó. Tôi cũng bị dính #2 nhiều nhất, và khi hạ xuống bản free thì prompt không còn khớp nên cũng gặp y hệt kiểu #1.
Vì thế đến một lúc nào đó tôi bỏ hẳn việc tin vào model, và thay vào đó, bất kể model rẻ hay đắt, hay có bị retire đi nữa, tôi chặn không cho model tự quyết những việc như gửi mail, xóa, hay chuyển ra bên ngoài. Mấy việc đó bắt buộc phải có người duyệt rồi mới được thực hiện. Thứ chạy tự động chỉ là những việc có thể hoàn tác như phân loại, đánh dấu đã đọc, hay briefing thôi.
Làm như vậy xong thì kể cả model có drift, tình huống xấu nhất cũng chỉ là "một đề xuất kỳ quặc để tôi xem rồi từ chối", chứ không phải "một email trả lời đã lỡ gửi đi rồi". #1 sẽ không lan thành #3.
Còn #2 thì tôi bắt lỗi free SKU báo 404 bằng cách kiểm tra catalog mỗi ngày và lách qua bằng chuỗi fallback, nhưng chỉ cố định bộ phân loại ở flash trả phí thôi. Dùng full cỡ Sonnet cho khách hàng cuối thì với tôi cũng là gánh nặng... nên tôi chỉ tốn tiền cho phân loại, còn phần tạo đề xuất thì để free, và để approval gate gánh phần rủi ro.
Cuối cùng thì có vẻ mấu chốt là không đặt chi phí và độ an toàn lên cùng một trục. Model có thể rẻ, nhưng gate thì không thể rẻ được.