Các vấn đề kiến trúc của LLM agent hiện đại

Một LLM agent khác với một client phần mềm thông thường ở chỗ có một mô hình xác suất nằm giữa ý định và hành động. Khi agent chỉ phản hồi bằng văn bản, cái giá của lỗi bị giới hạn trong phản hồi đó. Khi nó được cấp bộ nhớ, API, công cụ và quyền thay đổi dữ liệu thực, các giải pháp kiến trúc thông thường bắt đầu bộc lộ các lớp rủi ro mới.

Concept này là một node chung để hệ thống hóa các vấn đề đó. Nó không khẳng định rằng tất cả các vấn đề được liệt kê đã được giải quyết hoặc thậm chí được xây dựng hoàn chỉnh. Mục tiêu là tích lũy các quan sát thực tế từ hoạt động vận hành agent, liên kết chúng với các thực tiễn kỹ thuật hiện có và dần dần rút ra các nguyên tắc kiến trúc agent-native.

Các lớp vấn đề đã nhận thấy rõ

• Độ chi tiết của đột biến (Mutation Granularity). Agent thường được cấp một thao tác CRUD thay thế toàn bộ thực thể, mặc dù ý định của nó chỉ liên quan đến một phân đoạn duy nhất. Điều này làm tăng phạm vi lỗi tiềm ẩn.
• Ngữ cảnh cũ và tranh chấp thay đổi. Giữa thời điểm đọc và ghi, một đối tượng có thể bị thay đổi bởi người dùng, agent hoặc tiến trình khác.
• Xác thực và giới hạn hậu quả. Công cụ không chỉ phải cho phép hành động mà còn phải kiểm tra các điều kiện tiên quyết và giới hạn phạm vi thay đổi của nó.
• Khả năng đảo ngược. Các thay đổi do agent thực hiện tốt nhất nên có thể quan sát được, kiểm tra được và khôi phục được.
• Ngữ cảnh và chi phí truyền tải. Biểu diễn dữ liệu có cấu trúc hơn có thể làm tăng độ tin cậy của việc suy luận, nhưng lại làm tăng mạnh số lượng token và chi phí tương tác.
• Ngữ nghĩa của công cụ. Đối với agent, điều quan trọng là phải hiểu không chỉ giản đồ tham số mà còn cả các thuộc tính của thao tác: liệu nó có thay đổi trạng thái không, có mang tính phá hủy hay không, có tính lũy đẳng (idempotent) không, hoặc có thể lặp lại một cách an toàn hay không.

Mối liên hệ với các phương pháp hiện có

Vấn đề thay đổi một phần không xuất hiện cùng với LLM. HTTP PATCH được chuẩn hóa chính là để sửa đổi một phần tài nguyên thay vì thay thế hoàn toàn: RFC 5789. Đối với các tài liệu JSON có cấu trúc, đã có JSON Patch — RFC 6902.

Các coding agent hiện đại cũng sử dụng các phương pháp chỉnh sửa chi tiết (granular-edit). OpenAI cung cấp công cụ Apply Patch, nơi mô hình tạo, cập nhật và xóa tệp thông qua các thao tác diff có cấu trúc thay vì phải trả về toàn bộ tệp. Coding agent GitHub Copilot thực hiện các thay đổi trong một nhánh (branch) riêng và yêu cầu người dùng kiểm tra diff cuối cùng: GitHub Copilot coding agent.

Ở cấp độ giao thức công cụ (tool protocol), MCP mô tả riêng các công cụ như các thao tác tác động bên ngoài, và sự phát triển của thông số kỹ thuật giới thiệu một từ vựng rủi ro xung quanh các thuộc tính readOnly, destructive, idempotent và các thuộc tính khác: MCP Tools specification, Tool Annotations as Risk Vocabulary.

Các thực tiễn này giải quyết các phần khác nhau của bài toán tổng thể, nhưng chưa tạo thành một kiến trúc phổ quát hoàn chỉnh để chỉnh sửa an toàn nội dung CMS tùy ý bởi các LLM agent.

Trạng thái hiện tại

Đây là một hướng nghiên cứu. Việc triển khai tầng đột biến an toàn cho agent chung (agent-safe mutation layer) trong haih-agent vẫn chưa bắt đầu. Các vấn đề riêng lẻ sẽ được tách thành các Concept con khi chúng biểu hiện trong công việc thực tế và trở nên đủ rõ ràng để phân tích chuyên sâu.