Ngữ cảnh, Không phải Kiểm soát
Mỗi quy tắc trong prompt của agent đều bắt nguồn từ một lỗi.
Ai đó thấy hành vi không đúng, viết một quy tắc, rồi bỏ qua. Người khác cũng làm vậy. Người thứ ba thêm một câu "không bao giờ làm X" vì mô hình từng làm điều kỳ lạ vào một ngày thứ Ba. Không ai xóa gì cả.
Sáu tháng sau, agent dành phần lớn cửa sổ ngữ cảnh để dò dẫm sổ tay quy tắc thay vì tập trung vào nhiệm vụ thực sự.
Đó là tư duy kiểu kiểm soát. Và tôi cho rằng đây là một trong những sai lầm thiết kế lớn nhất mà các nhóm mắc phải khi xây dựng AI agent.
Một Ví Dụ Nhỏ Phản Ánh Mô Hình Lớn Hơn
Chúng tôi từng gặp vấn đề khi một agent được kích hoạt bởi tác vụ định kỳ lại liên tục tạo tác vụ định kỳ mới trong quá trình thực thi. Đệ quy vô hạn, nhưng có tác động thực tế.
Có hai cách phản ứng.
Kiểu kiểm soát: Cấm. Viết mã chặn việc tạo lịch từ trong lịch. Thêm quy tắc vào prompt: "không bao giờ tạo lịch trong lịch." Xong việc.
Kiểu ngữ cảnh: Cho agent biết điều gì thực sự đang diễn ra.
Bạn được kích hoạt bởi một tác vụ định kỳ lúc 3:00 sáng giờ Thái Bình Dương. Mã lịch: sched_29x8f. Một lần chạy theo lịch là một lần thực thi độc lập với phạm vi đã được người dùng cấp quyền ban đầu. Việc tạo tác vụ định kỳ mới sẽ mở rộng phạm vi vượt quá sự cho phép ban đầu.
Cách đầu tiên chỉ vá một hành vi. Cách thứ hai cung cấp cho agent mô hình về tình huống.
Giờ đây, agent có thể suy luận về các câu hỏi liên quan: Tôi có nên gửi thông báo lúc 3 sáng không? Tôi có nên tạo quy trình tiếp theo mà người dùng chưa yêu cầu không? Tôi có nên sửa đổi điều gì vượt ra ngoài phạm vi lần chạy ban đầu không?
Không cần quy tắc. Agent tự hiểu vấn đề.
Nhiều nhóm chọn kiểm soát trong khi thực ra họ cần ngữ cảnh.
Sự Khác Biệt Này Cũng Xuất Hiện Trong Prompt
Không chỉ là vấn đề thực thi ở cấp hệ thống. Sự phân biệt giữa ngữ cảnh và kiểm soát cũng tồn tại trong prompt.
Prompt kiểu ngữ cảnh: chủ yếu là sự thật, ít ý kiến:
Bạn đang chạy vì một tác vụ định kỳ. Được kích hoạt lúc 3:00 sáng giờ Bắc Kinh. Mã tác vụ: sched_29x8f. Người dùng đã cấp quyền cho lần chạy này với phạm vi cụ thể.
Prompt kiểu kiểm soát: mang tính chỉ đạo, áp đặt:
Tránh tạo lịch mới. Bạn nên thông báo cho người dùng bằng công cụ X. Không bao giờ làm Y trừ khi Z.
Đôi khi hướng dẫn mang tính chỉ đạo là hữu ích. Nhưng rất thường chúng chỉ bù đắp cho sự thiếu hụt thông tin. Và một khi bạn bắt đầu bù đắp kiểu đó, nó dễ trở thành thói quen.
Prompt Trở Thành Bộ Máy Quan Liêu Như Thế Nào
Đây là dạng thất bại sâu sắc hơn.
Một nhóm thấy vấn đề và thêm quy tắc. Rồi lại thêm nữa. Mỗi quy tắc vá một vấn đề cục bộ, nhưng tổng thể tạo thành một hệ thống đầy quy tắc trung gian.
Bezos từng mô tả mô hình này trong thư gửi cổ đông năm 2016: quy trình tốt phục vụ bạn để bạn phục vụ khách hàng. Nhưng nếu không cẩn thận, quy trình sẽ trở thành mục đích.
Đó chính xác là điều xảy ra trong hệ thống agent.
Quy tắc không phải là mục tiêu. Quy tắc chỉ là đại diện cho kết quả bạn muốn. Và các đại diện này tích tụ. Một quy tắc tạo ra ngoại lệ, cần thêm quy tắc khác. Sớm thôi, agent phải suy luận qua nhiều lớp hướng dẫn tích tụ, mỗi lớp được thêm vào vì lý do lịch sử mà không ai còn nhớ rõ.
Trong tổ chức con người, điều này thành quan liêu. Trong hệ thống agent, nó thành prompt khổng lồ đầy vết sẹo.
Sự Thật Bền Vững. Ý Kiến Dễ Hỏng.
Một sự thật như "lần chạy này được kích hoạt bởi tác vụ định kỳ lúc 3 sáng" là ổn định. Nó đúng bất kể mô hình nào đọc: Claude, GPT, Gemini, hay bất kỳ mô hình nào ra mắt quý tới.
Một câu như "bạn nên tránh tạo lịch con" thì mong manh. Nó phụ thuộc vào cách hiểu. Có thể hữu ích trong một trường hợp, nhưng lại gây lỗi âm thầm ở trường hợp khác.
Khi bạn thay đổi mô hình, mọi ý kiến trong prompt đều có thể trở thành bẫy. Mô hình mới có xu hướng suy luận khác, và "tránh" mà bạn đã cân nhắc kỹ có thể bị hiểu hoàn toàn khác.
Nhưng các sự thật về môi trường, quyền hạn, phạm vi và ràng buộc thường có thể áp dụng chung cho nhiều mô hình và trường hợp ngoại lệ. Đó là lý do sự thật là vật liệu xây dựng tốt hơn.
Cái Bẫy Đặc Thù Mô Hình
Đây có thể là dạng kiểm soát nguy hiểm nhất: các nhóm liên tục biến lỗi tạm thời của mô hình thành cấu trúc hệ thống vĩnh viễn.
Một mô hình có hành vi không đúng trong trường hợp hẹp. Nhóm thêm rào chắn: vá prompt, kiểm tra mã, nhánh lạ chỉ để ngăn một lỗi cụ thể.
Bản vá đó là cược rằng đặc thù đó sẽ tồn tại. Nhưng gần như không bao giờ đúng.
Ba tháng sau, mô hình thay đổi. Hành vi gốc biến mất. Nhưng bản vá vẫn còn. Không ai muốn xóa, vì sợ nó có lý do tồn tại.
Đó là cách prompt hệ thống trở thành mã di sản.
Chúng ta dễ nhận ra nguy cơ khi nói lý thuyết. Nhưng thực tế, việc liên tục vá các xu hướng suy luận hiện tại của Sonnet trong từng prompt cũng là cùng một mô hình được ngụy trang.
Ghi nhận hành vi hệ thống ổn định là giá trị. Vá xu hướng suy luận của mô hình là chạy trên máy chạy bộ. Mô hình sẽ thay đổi nhanh hơn bạn có thể duy trì các bản vá.
Một Tình Huống Kiểm Tra Tốt: Bị Từ Chối Quyền
Bạn có thể thấy rõ sự khác biệt này trong chẩn đoán công cụ. Khi agent gặp lỗi quyền hạn:
Kiểu kiểm soát:
TOKEN bị thiếu. Chạy "zero permissions request gmail.send" để sửa.
Rõ ràng, nhưng agent không học được gì. Lần sau gặp lỗi quyền khác, nó lại bế tắc.
Kiểu ngữ cảnh:
process.env.GMAIL_TOKEN → tồn tại zero connectors inspect gmail → đã kết nối zero permissions inspect gmail.send → bị từ chối
Tùy chọn:
- Yêu cầu người dùng phê duyệt gmail.send
- Sử dụng đường dẫn đã được cấp quyền nếu có
Giờ agent biết token tồn tại, connector hoạt động, và quyền cụ thể bị từ chối. Nó hiểu trạng thái hệ thống và có thể suy luận về các tình huống mới mà người viết quy tắc chưa từng nghĩ tới.
Quy Tắc Kinh Nghiệm
Tôi luôn quay lại điều này:
Bất cứ khi nào bạn sắp viết "không được", "tránh", hoặc "không bao giờ" trong prompt, hãy dừng lại. Hỏi: quy tắc này đang bù đắp cho sự thật nào?
Thường là thiếu thông tin. Agent không hiểu môi trường, quyền người dùng cấp, hành động nào không thể đảo ngược, hoặc vì sao lần chạy này khác với trò chuyện thông thường.
Ghi lại sự thật đó. Xóa quy tắc đi.
Đôi khi bạn vẫn cần ràng buộc, nhất là với hành động phá hủy, giao dịch tiền, hoặc giới hạn an toàn. Kiểm soát cứng vẫn quan trọng.
Nhưng nhiều quy tắc prompt không phải ranh giới thực sự. Chúng chỉ bù đắp cho sự thiếu hiểu biết. Và chính những quy tắc đó sẽ tích tụ và mục nát.
Mục Tiêu
Mục tiêu không phải là agent ghi nhớ danh sách kiểm tra.
Mục tiêu là agent hiểu rõ tình huống để ra quyết định tốt trong ranh giới rõ ràng.
Một triết lý kiểm soát hành vi bằng cách chồng chất quy tắc. Triết lý còn lại cải thiện hành vi bằng cách làm cho thế giới dễ hiểu hơn.
Cách đầu dẫn đến quan liêu. Cách sau dẫn đến sự thấu hiểu.
Xây dựng ngữ cảnh. Xóa vết sẹo. Triển khai agent biết suy nghĩ.
