- Với các agent cần xử lý ổn định những tác vụ phức tạp, thứ cần thiết không phải là chuỗi prompt tinh vi hơn mà là luồng điều khiển mang tính quyết định được mã hóa trong phần mềm
- Nếu còn phụ thuộc vào các cụm như MANDATORY hay DO NOT SKIP trong prompt thì tức là bạn đã chạm đến giới hạn của prompting
- Hãy tưởng tượng một ngôn ngữ lập trình nơi câu văn hoạt động như gợi ý và hàm thì ảo giác rồi trả về “Success”; khi độ phức tạp tăng lên, việc suy luận trở nên bất khả thi và độ tin cậy sụp đổ
- Phần mềm mở rộng nhờ tính kết hợp đệ quy, được cấu thành từ thư viện, mô-đun và hàm, và vì cung cấp hành vi có thể dự đoán nên cho phép suy luận cục bộ
- Chuỗi prompt hữu ích cho các tác vụ hẹp, nhưng vì không mang tính quyết định, đặc tả yếu và khó kiểm chứng nên không có được những tính chất tương tự
Cấu trúc cần thiết cho độ tin cậy của agent
- Để đảm bảo độ tin cậy, cần đưa logic ra khỏi phần mô tả bằng ngôn ngữ tự nhiên và chuyển nó vào runtime
- Cấu trúc cần thiết là một scaffold mang tính quyết định coi LLM là một thành phần của hệ thống chứ không phải toàn bộ hệ thống
- Scaffold này phải bao gồm các chuyển đổi trạng thái tường minh và các checkpoint xác thực
- Chỉ orchestration mang tính quyết định thôi là chưa đủ; với những hệ thống có thể thất bại âm thầm, cần cơ chế phát hiện lỗi mạnh tay
- Nếu không có xác thực bằng chương trình, các lựa chọn sẽ chỉ còn lại ba kiểu
-
Người giám sát (Babysitter)
- Con người phải ở trong vòng lặp để bắt lỗi trước khi chúng lan truyền
-
Người kiểm toán (Auditor)
- Sau khi chạy xong phải xác minh kỹ lưỡng toàn bộ kết quả
-
Cầu nguyện (Prayer)
- Cuối cùng sẽ phải dựa vào cách chấp nhận kết quả theo cảm tính
1 bình luận
Ý kiến trên Hacker News
Đồng ý 1000%. Càng lúc tôi càng khó tin vào điệp khúc mà Anthropic cứ lặp đi lặp lại: “hãy xây theo hiệu năng của các mô hình tương lai, chúng sẽ sớm tốt hơn thôi”
Tôi đã làm một QA agent duyệt qua 200 file Markdown yêu cầu trong một phiên trình duyệt, và đó là một hệ thống tốt giúp tăng mạnh hiệu suất của nhóm. Nhưng khi giao cho mô hình luồng điều khiển cấp cao kiểu như “xem các file yêu cầu trong thư mục này và với mỗi file, hãy tạo một mục việc cần làm để kiểm tra xem ứng dụng có đáp ứng yêu cầu đó không”, thì nó bắt đầu sụp từ khoảng 30 file
Nó bỏ sót file, hoặc test lặp lại cùng một nhóm file tới ba lần khiến việc đáng ra mất 3 phút thành 10 phút, hoặc chỉ vì lỗi ở một file mà vô cớ test lại 4 file trước đó. Trên Opus 4.6 và GPT 5.4, cũng như khi tôi xem qua Opus 4.7 và GPT 5.5, khả năng điều phối workflow vẫn thiếu nhất quán
Cuối cùng tôi dựng một harness mang tính quyết định rất đơn giản bao quanh mô hình, gọi mô hình cho từng test case, lưu kết quả vào mảng rồi ghi ra file, và độ tin cậy của hệ thống tăng vượt trội. Nhưng các nền tảng agent được quản lý như Cursor Cloud Agents hay Anthropic có vẻ quá ám ảnh với việc “agent phải tự chạy mọi thứ”, nên không nhìn ra giá trị của việc chèn một chút tính quyết định ở đúng chỗ
Vì điều đó dội gáo nước lạnh vào tuyên bố rằng công nghệ này sẽ thay thế trọn vẹn con người hay toàn bộ workflow, toàn bộ dự án. Tôi nghĩ nó có thể tăng năng suất rất mạnh và gây tác động tai hại lên thị trường tuyển dụng cùng mức lương của lập trình viên, nhưng tôi không nghĩ phiên bản hiện tại của công nghệ này sẽ đạt tới mức họ đang quảng bá. Nếu họ định vị nó là “một công cụ rất hữu ích giúp giảm đáng kể việc lặt vặt cho đội ngũ phát triển”, thì lập trình viên sẽ muốn còn lãnh đạo cấp cao sẽ bớt hứng thú hơn, và nhà đầu tư chắc cũng không để yên
Ngoài ra, các bước được kiểm soát chặt và chi tiết cũng phù hợp hơn nhiều để gắn các mô hình nhỏ hơn, rẻ hơn và chuyên biệt hơn, thay vì một mô hình khổng lồ chuyên tự động hóa kiểm thử hay viết ngay 5 tập fanfic CSI trong chớp mắt
Chẳng phải có những benchmark cho phép thử một bài nhiều lần, rồi bỏ qua tỉ lệ thất bại và chỉ cần có một lần ra kết quả đúng thì lấy luôn kết quả đó sao?
check_compilationvàrun_unit_testsvào một công cụ nhưapply_patch. Tên công cụ vẫn làapply_patch, nhưng giờ nếu patch thành công thì nó còn trả thêm thông tin về build và testTỉ lệ thành công của agent tăng từ khoảng 80% lên mức đến giờ trông gần như mang tính quyết định. Giờ tôi không cần phải mô tả quá trình compile và unit test trong prompt nữa; chỉ cần khi nó chạy dưới các điều kiện phụ thuộc nào đó thì trả về kết quả tương ứng
Dạo này tôi cũng có cảm giác đang rời xa xu hướng chung. Tôi dùng token trả trước và harness tùy biến từ rất lâu rồi, và nó đơn giản là hoạt động tốt. Phần lớn tin tức có thể bỏ qua. Với những bài toán được nhắm đích rõ ràng, các công cụ kiểu Copilot không còn hữu dụng, và trong một số codebase thì dù cùng dùng mô hình nền GPT 5.4, mức khác biệt hiệu năng là hoàn toàn khác hẳn
Mọi người đều bỏ lỡ mẫu này trong skills. Nếu đặt code cạnh
SKILL.mdthì có thể bảo đảm một số hành vi nhất định, vậy mà mọi người kỳ lạ thay lại nghiện viết prompt. Cũng không cần làm CLI, chỉ mộtskill.pyđơn giản chứa tác vụ là đủ. Có thể đặt thêm helper gọiclaude -pSẽ buồn cười nếu vài năm nữa người ta vẫn dùng LLM, nhưng rốt cuộc chỉ dùng được thông qua một tập từ vựng và ngữ pháp bị kiểm soát mà ai cũng phải học. Giống như 15 năm trước mọi người đổ xô sang NoSQL rồi ngay sau đó lại dựng schema bên trong JSON
Một phần vấn đề có lẽ là ngay từ đầu người ta đã áp dụng LLM sai chỗ. Như đã được nói ở nơi khác, prompt của agent có lẽ nên là hãy viết code để thực hiện công việc theo cách có thể lặp lại, kiểm chứng được và mang tính quyết định nhất có thể
Việc kiểm chứng đầu ra của agent cũng nên được đưa vào. Mục tiêu tổng thể là loại LLM ra khỏi những tác vụ mà chương trình có thể xử lý hiệu quả hơn và thường còn chính xác hơn
Gắn AI vào production rồi để nó trực tiếp làm gì đó qua API call là một ý tưởng tệ. Theo tôi, thứ duy nhất AI nên làm trong ứng dụng là đọc, phân loại và những việc tương tự. Kiểu như thay thế phần “R” trong ứng dụng CRUD ngày xưa
Dùng cùng một endpoint “R” dựa trên AI để tự điền form “C”, “U”, “D” tùy theo prompt thì được, nhưng không nên thay đổi gì cho khách hàng trước khi con người xem lại. Ứng dụng CRUD vẫn là ứng dụng CRUD và sẽ còn như vậy; chỉ là giờ nó có thêm một endpoint “R” cực kỳ thông minh để tự động điền biểu mẫu hay gợi ý hành động cho khách hàng, công cụ nội bộ, Jenkins pipeline v.v. Nó có thể đề xuất hành động, nhưng không được tự thực thi
llm -> prompt -> result, sangllm -> prompt + prompt encoded as skill -> result, rồi đếnllm -> prompt + deterministic code encoded as skill -> resultNếu bắt mô hình sinh code bằng prompt ngay từ đầu thì có thể rút ngắn đường tới code quyết định, nhưng vẫn là đặt code quyết định bên trong một wrapper không quyết định. Muốn bài toán dài hạn thành công thì trong nhiều trường hợp vẫn cần một lớp quyết định còn đang thiếu
Cần đặt code quyết định ra ngoài ranh giới không quyết định thông qua agent loop hoặc framework. Khi đó nó thành kiểu
luồng agent quyết định -> ra quyết định không quyết định -> công cụ quyết định, tức là phán đoán không quyết định được kẹp giữa các lớp quyết định. Trong thực nghiệm đây là một mẫu cực mạnh, và còn mạnh hơn nếu agent tự tạo ra tính quyết định bằng công cụ như auto-researcherGiờ chúng tôi dùng một ngôn ngữ đặc thù miền nhỏ cùng một công cụ duy nhất, và để agent nhập vào script viết bằng ngôn ngữ đó. Nó xử lý được các trường hợp dùng động hơn, và cú pháp sai thì parser dễ dàng bắt được rồi trả ngược cho agent
Nhóm điều khiển phần cứng chuyển đặc tả bằng tài liệu và bảng tính, còn nhóm di động đọc chúng rồi code thư viện giao tiếp và kiểm tra khớp với server. Tôi chuyển tài liệu sang TSV và gửi một phần cho Claude, để nó viết parser TSV giữ được các sắc thái tinh tế trong bản đặc tả do con người viết
Tôi phải lặp hơn 150 lần mới xử lý hết mọi trường hợp biên và tạo được kết quả trung gian ở dạng JSON. Sau đó Claude giúp viết một code generator đặt lớp glue code tùy biến lên trên Apollo để sinh ra code mà ứng dụng di động tiêu thụ
Toàn bộ pipeline này chạy như một phần của Github Actions, và chỉ gọi Claude khi bộ kiểm tra thư viện thất bại. Khi thất bại, có một file md được đưa vào yêu cầu để bảo nó tìm xem lỗi ở đâu, đề xuất cách sửa và tạo PR. Sau đó con người sẽ review, chỉnh sửa và merge. Tổng số credit đến thời điểm đó chưa tới 350 USD
Tôi đồng ý với tinh thần chung, nhưng cho rằng kết luận nên khác đi. Khi đụng trần của prompt, thay vì cố dùng LLM để thực hiện công việc ở thời điểm chạy, nên dùng LLM để viết ra phần mềm sẽ thực hiện công việc đó
Vai trò của LLM lúc runtime thường sẽ thu hẹp lại thành giúp người dùng chọn đầu vào phù hợp cho một hệ thống phần mềm đã nhúng sẵn các quy tắc nghiệp vụ chặt chẽ
Tuần đầu thì prompt cứ phình ra còn hiệu năng đi xuống. Sang tuần thứ hai, chúng tôi tập trung định nghĩa thật chính xác các đối tượng như ghi chú, công việc, dự án, con người, rồi định nghĩa các method thực hiện thao tác rõ ràng trên các đối tượng ấy. Đúng như bạn nói, bề mặt của agent thu hẹp thành một lớp dịch biến ngôn ngữ tự nhiên thành lệnh và đối số đi qua bộ kiểm tra đầu vào
Một LLM như vậy có lẽ đã làm tốt hơn trong bài test strawberry
Tôi đã để Claude tự viết vài shell script xử lý các trường hợp thường gặp như chạy test trong workflow của mình. Giờ thì thay vì quay vòng 30 phút, nó chỉ việc chạy các công cụ đó để hoàn tất cấu hình
Mỗi lần nó xin quyền chạy một shell hay Python one-liner kỳ quặc chỉ để làm việc gì đó một lần, tôi lại nghĩ xem có nên buộc nó dùng một công cụ có thể auto-approve hay không
Vì vậy người ta mới hay nói “AI thế hệ tiếp theo”. Không chỉ đơn thuần là LLM. LLM khá tuyệt, và ngay cả khi không có thêm bước tiến nền tảng nào thì tôi vẫn nghĩ sẽ tiếp tục khai thác được giá trị bằng những cách thú vị hơn và tối ưu hơn
Nhưng có những phần dường như cần cải tiến nền tảng của thế hệ kế tiếp dưới một hình thức nào đó. Việc LLM làm mờ câu “tuyệt đối đừng làm X”, rồi sau một chuỗi tác vụ dài lại hiểu thành kiểu “làm ơn hãy làm X”, có vẻ là thứ nằm gần với nền móng vận hành của nó. Chúng ta đang ở trong giai đoạn hưng phấn ban đầu khi còn khám phá xem có thể làm được gì, nên dễ quên rằng LLM không phải là tất cả những gì ta tìm kiếm trong AI
Phải có một cấu trúc biết xử lý “tuyệt đối đừng làm X” theo kiểu gần với con người hơn. Cũng phải có một cấu trúc có tầng nhớ gần giống con người thay vì chỉ có “cửa sổ ngữ cảnh”. Kiểu như hai người nói chuyện đủ lâu với cùng một AI ban đầu, rồi cuối cùng sẽ thành hai AI khác nhau chứ không chỉ là cùng một AI với cửa sổ ngữ cảnh khác nhau
Tất nhiên không ai biết nó sẽ trông như thế nào. Chỉ là cũng không có lý do gì để nghĩ LLM là câu trả lời cuối cùng cho AI
Với tư cách người đã đi một vòng từ ép bằng prompt → luồng quyết định → lại quay về ép bằng prompt, tôi không đồng ý
Việc “đừng bỏ sót” thất bại là vì agent đang ôm quá nhiều việc, và những thứ khác trong ngữ cảnh làm nó xao lãng khỏi chỉ thị đó
Nhưng chẳng ai nói agent chịu trách nhiệm ép buộc phải là cùng một agent với agent tạo ra kết quả. Có thể mã hóa một phần logic ra quyết định thông minh vào luồng điều khiển quyết định, nhưng nếu làm quá cứng thì nó sẽ không hoạt động tốt, còn nếu làm quá phức tạp thì thà dùng agent còn rẻ hơn về chi phí thiết lập và bảo trì
Về cơ bản thứ cần là ba loại agent. Một supervisor quản lý vòng lặp và kích hoạt đúng thứ khi có vấn đề, một orchestrator ủy quyền cho agent phù hợp và áp guardrail ở nơi cần thiết, và một worker thực thi đơn vị công việc
Theo tôi thì mọi harness đều làm sai ở khía cạnh này, và một số thì sai rất nặng
Ví dụ, slash command là một tính năng sai lầm. Bạn không nên phải chờ chatbot kết thúc một lượt thì mới kiểm tra được trạng thái cửa sổ ngữ cảnh hay số tiền đã tiêu trong phiên này. Phần điều khiển phải trực giao với vòng lặp chat
Những thứ chẳng liên quan gì tới việc điều khiển đầu vào đầu ra của bộ sinh văn bản lại bị buộc vào hành vi chat chỉ vì kiểu “đã là chat thì cứ vận hành như bot IRC đi”
Bây giờ có vô số LLM agent, nhưng gần như chẳng có cái nào tách bạch tử tế giữa điều khiển, vòng lặp agent và lớp biểu diễn. Một số ít ít nhất có headless mode, và điều đó là tốt
/statushoạt động tốt ngay cả giữa một lượtNhững cái khác thì không
Cũng tiện hơn để nhảy qua lại giữa các cuộc hội thoại và xem cập nhật. Thỉnh thoảng tôi dùng Claude Code hoặc opencode trong terminal, nhưng trải nghiệm kém hơn nhiều so với ứng dụng desktop của Codex
Câu “hãy tưởng tượng một ngôn ngữ lập trình mà câu văn là lời gợi ý còn hàm thì ảo giác trả về ‘Success’. Khi độ phức tạp tăng lên, suy luận trở nên bất khả thi và độ tin cậy sụp đổ” về bản chất khá gần với lập trình khai báo
Phần lớn lập trình truyền thống là mệnh lệnh, thứ mà lập trình viên thấy quen thuộc. Bạn đưa ra một tập chỉ thị chính xác và kỳ vọng nó làm đúng như đã viết. Agent thì gần với khai báo hơn nhiều so với mệnh lệnh: bạn đưa kết quả mong muốn, rồi nó làm việc để đạt kết quả đó
Dĩ nhiên trong các hệ khai báo như SQL, kết quả khá nhất quán và được xác định rõ, nhưng bạn vẫn đang tin vào bộ máy bên trong về cách nó xử lý. Nghĩ về agent theo hướng khai báo giúp tôi nhiều hơn là cố thiết kế các hệ thống “điều khiển” kiểu Rube Goldberg. Nếu không đúng thì kiểm chứng, báo là sai, rồi thử lại hoặc chọn cách tiếp cận khác
Nếu thật sự cần tính mệnh lệnh, thì cứ viết theo kiểu mệnh lệnh. Hoặc để agent viết như vậy. Nghe giống như đang cố dùng sai công cụ cho công việc
Nó có thể trông như khai báo, nhưng đó là trong ảo giác. Thực ra chúng ta không mô tả mục tiêu và để AI diễn giải; mà là có một tài liệu kể chuyện nơi một nhân vật đóng thế cho con người trò chuyện với một nhân vật máy tính, còn chúng ta ngoài đời hy vọng LLM ghép tiếp phía sau thành một câu chuyện mạch lạc hơn để rút ra thứ gì đó hữu ích từ đó
Đây không chỉ là phân biệt học thuật. Nhận ra có yếu tố câu chuyện giúp xây mô hình tốt hơn về quan hệ giữa đầu vào và đầu ra để lập chiến lược. Ví dụ nó giúp hiểu các rủi ro như prompt injection, và cũng cho định hướng về việc nên thêm hay bớt loại dữ liệu huấn luyện nào
Khi đó bạn gặp các vấn đề khá giống với LLM: nếu không cực kỳ cẩn thận thì sẽ có thất bại im lặng, lặp lại, mâu thuẫn. Có khi bản chất vẫn là cùng một vấn đề giả định thế giới khép kín. Với LLM thì nó hiện ra thành ảo giác thay vì thừa nhận là không biết
Và như bạn nói, nếu bảo một LLM không quyết định theo cách khai báo kiểu “hãy đưa tôi tới trạng thái cuối này” thì khả năng nó trật đường ray còn cao hơn
Nhưng bản thân truy vấn không thay đổi như LLM
Tôi đã nghĩ khá nhiều về vấn đề này. Nó cũng có thể liên hệ tới câu chuyện chuyên biệt hóa. Có vẻ mô hình càng chuyên biệt thì năng lực nền tảng lại càng suy giảm, và nếu nhắm tới một mức trừu tượng chỉ nhỉnh hơn rất ít thì có thể lấy được ưu điểm của cả hai phía
Đây là ví dụ khá cụ thể nhưng cũng đáng để suy ngẫm
Tóm tắt podcast 20 phút: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
Bài báo: https://arxiv.org/abs/2605.00225
Thời Auto-GPT năm 2023 đã thấy rõ điều này rồi. Người ta để GPT “lái”, nhưng trong đa số trường hợp thứ thực sự cần chỉ là mười dòng Python và có lẽ vài lệnh gọi
llm()Phương án thay thế là chạy mười dòng Python đó theo cách đắt nhất, chậm nhất và kém tin cậy nhất có thể. Dĩ nhiên là nó rất hút truyền thông
Ví dụ, đa số dùng agent để nghiên cứu trên internet. Nó chạy hàng giờ, rồi tản mạn hoặc quên mất việc ban đầu
Trong khi đó, với
import duckduckgovàimport llm, bạn có thể viết mười dòng code làm cùng việc trong 20 giây, chạy quyết định thật sự, và tốn ít hơn 50 lầnCác mô hình hiện nay tốt hơn rất nhiều, và đã đủ tốt để Auto-GPT giờ có thể trở thành hiện thực. Nhưng việc chạy luồng điều khiển được đặc tả cẩu thả theo cách đắt đỏ nhất có thể vẫn là một ý tưởng tồi