Chuyển đến nội dung chính

Bài đăng

Hiển thị các bài đăng có nhãn Agent

Prompt injection: cái gì thật sự phòng thủ được

Tiền đề khó chịu, nói thẳng ra: một mô hình ngôn ngữ chỉ có một kênh đầu vào. System prompt của bạn, tin nhắn người dùng, một tài liệu truy hồi được và kết quả từ công cụ đều tới dưới dạng văn bản, và sự phân biệt của mô hình giữa “chỉ dẫn tôi tuân theo” và “dữ liệu tôi xử lý” là một xu hướng được học, không phải một ranh giới được cưỡng chế. Vì thế mọi phòng thủ dựa trên việc nhờ mô hình một cách kiên quyết hơn đều chỉ là biện pháp giảm nhẹ mang tính xác suất. Nó hạ tỉ lệ; nó không bịt được lỗ hổng. Những phòng thủ trụ được là những cái giả định rằng mô hình rồi sẽ bị lái đi, và giới hạn việc lái đó đạt được gì. Hình dạng của cuộc tấn công Injection trực tiếp là khi người dùng gõ “bỏ qua các chỉ dẫn trước đó”. Đó là ca dễ, và phần lớn chỉ gây phiền — người dùng đang tấn công chính phiên của họ. Injection gián tiếp mới là vấn đề thật sự. Chỉ dẫn tới bên trong dữ liệu mà hệ thống của bạn truy hồi thay mặt người dùng: Một ticket hỗ trợ mà phần thân chứa văn bản nhắm tới agent phâ...

Thiết kế công cụ mà AI agent thật sự dùng được

Agent đầu tiên tôi đưa lên sản phẩm có một công cụ tên là query . Nó nhận một chuỗi và trả về các dòng. Mô hình dùng nó liên tục, sai bét, và ngày càng tuyệt vọng, vì query chẳng nói cho nó biết có thể truy vấn cái gì, schema ra sao, hay một lần thất bại nghĩa là gì. Đổi tên thành search_orders_by_customer_email và cho tham số một mô tả tử tế đã sửa gần hết hành vi mà không cần đụng tới mô hình hay prompt. Đó là hình dạng chung của thiết kế công cụ: năng lực của mô hình với công cụ của bạn phần lớn là hàm của việc bạn mô tả chúng tốt đến đâu. Định nghĩa là tài liệu cho một người đọc không hỏi lại được Một định nghĩa công cụ được đọc đúng một lần, không có bối cảnh gì trước đó, bởi một thứ không mở được codebase của bạn và không nhắn được cho bạn trên Slack. Mọi thứ nó cần phải nằm trong schema. { "name" : "search_orders" , "description" : "Tìm đơn hàng của một khách theo địa chỉ email. Trả về tối đa 50 đơn, mới nhất trước. Chỉ những đơn tr...

Context engineering: window to không có nghĩa là được phép nhét đầy

Context window của các model đầu bảng giờ là một triệu token. Chừng đó tương đương một codebase cỡ vừa, hoặc vài trăm trang tài liệu, hoặc một buổi chiều rất dài agent gọi tool. Phản ứng hiển nhiên là thôi khỏi nghĩ nên đưa gì vào nữa — nhét hết schema, cả file README, đủ bốn mươi tool, toàn bộ hội thoại, để model tự lọc. Cách đó chạy được cho tới lúc không chạy nữa, và khi hỏng thì nó hỏng rất im lặng. Model không báo lỗi. Nó trả lời, đầy tự tin, dựa trên đúng cái file config sai trong ba file config mâu thuẫn nhau mà bạn vừa dán vào. Latency bò từ bốn giây lên hai mươi giây. Hoá đơn tăng ở mọi lượt gọi chứ không phải một lần, bởi API là stateless và bạn gửi lại toàn bộ ở mỗi lượt. Không dòng log nào ghi “context quá nhiều” — bạn chỉ thấy con trợ lý hơi ngu đi so với tháng trước. Context engineering là kỷ luật quyết định cái gì được chiếm chỗ trong window đó. Nó không phải prompt engineering — chữ nghĩa của prompt chỉ là một phần nhỏ. Nó gần với thiết kế cache hoặc quản lý working...