Sự khác biệt giữa “cơn sốt” về tác nhân tự chủ và các tác nhân AI thực sự vận hành được trong môi trường production

• Trái với kỳ vọng rằng làn sóng bùng nổ tác nhân AI sẽ thực sự ập đến mạnh mẽ trong năm 2025, môi trường production thực tế vẫn tồn tại những giới hạn rất thực dụng
• Do sự tích lũy lỗi và bài toán chi phí token, hiện nay vẫn không thể tự động hóa hoàn toàn các workflow nhiều bước
• Phần lớn các hệ thống tác nhân thành công đều đòi hỏi miền bài toán bị giới hạn nghiêm ngặt cùng với sự phê duyệt của con người hoặc quy trình xác minh bắt buộc
• Điểm khó thực sự không nằm ở năng lực AI, mà ở thiết kế công cụ và hệ thống phản hồi để tác nhân có thể sử dụng hiệu quả
• Dự báo rằng trong năm 2025, các startup/doanh nghiệp lấy tác nhân hoàn toàn tự chủ làm trọng tâm sẽ gặp trở ngại lớn trong quá trình triển khai và mở rộng thực tế

---

Vì sao tôi cá rằng AI agent sẽ không thực sự xuất hiện trong năm 2025 (dù chính tôi đang phát triển AI agent)

• Cơn sốt cho rằng năm 2025 sẽ là năm của AI agent đang lan rộng khắp nơi
• Tác giả đã trực tiếp xây dựng nhiều hệ thống AI agent khác nhau hoạt động trong môi trường production suốt một năm qua
• Từ kinh nghiệm thực chiến đó, tác giả giữ quan điểm hoài nghi đối với cái gọi là “cuộc cách mạng agent” trên thị trường

Kinh nghiệm xây dựng nhiều loại hệ thống agent khác nhau

• Agent phát triển phần mềm: tạo React component từ ngôn ngữ tự nhiên, refactor mã legacy, tự động quản lý tài liệu API, sinh hàm dựa trên đặc tả, v.v.
• Agent dữ liệu & hạ tầng: xử lý truy vấn và migration phức tạp, tự động hóa DevOps đa đám mây
• Agent chất lượng & quy trình: tự sửa lỗi lint, tạo mã kiểm thử, tự động hóa code review và Pull Request chi tiết
• Các hệ thống này thực sự mang lại giá trị và tiết kiệm thời gian, nhưng chính trải nghiệm đó cũng là nền tảng cho góc nhìn phê phán với làn sóng thổi phồng hiện nay

Tóm tắt cốt lõi: ba sự thật lạnh lùng về AI agent

1. Tích lũy tỷ lệ lỗi: càng nhiều bước, xác suất thành công càng giảm theo cấp số nhân. Rất khó đáp ứng chuẩn production (99,9% trở lên)
2. Cửa sổ ngữ cảnh và chi phí: cuộc hội thoại càng dài thì chi phí token tăng theo bình phương, khiến tính kinh tế sụp đổ
3. Độ khó của thiết kế công cụ và phản hồi: thách thức lớn nhất không phải giới hạn kỹ thuật, mà là thiết kế công cụ và hệ thống phản hồi để agent có thể khai thác

Thực tế toán học của việc tích lũy lỗi

• Workflow tự chủ nhiều bước không thể khả thi ở quy mô vận hành thực tế vì lỗi sẽ tích lũy dần
• Ví dụ, nếu mỗi bước có độ tin cậy 95%, thì sau 20 bước tỷ lệ thành công cuối cùng chỉ còn 36% (trong khi production đòi hỏi: 99,9% trở lên)
• Ngay cả khi giả định độ tin cậy cao hơn, xác suất thất bại vẫn tăng mạnh khi số bước gia tăng
• Trong thực tế, thay vì tự động hóa hoàn toàn mọi quy trình, người ta thiết kế hệ thống với điểm xác minh độc lập và rollback ở từng bước, cùng với khâu kiểm tra của con người
• Mẫu hình của các hệ thống agent thành công: ngữ cảnh bị giới hạn rõ ràng, tác vụ có thể kiểm chứng, và con người tham gia vào các quyết định quan trọng

Cấu trúc chi phí token và giới hạn kinh tế

• Chi phí token để duy trì context window và hội thoại trở thành một thực tế phi kinh tế khi mở rộng hệ thống
• Agent dạng hội thoại phải xử lý toàn bộ lịch sử trao đổi ở mỗi lượt, nên chi phí tăng vọt theo bình phương khi số vòng tương tác tăng lên
• Một cuộc hội thoại kéo dài 100 lượt có thể tốn 50~100 USD chỉ riêng chi phí token, và khi áp dụng cho lượng lớn người dùng thì bài toán kinh tế sẽ sụp đổ
• Ngược lại, các agent sinh chức năng theo kiểu Stateless (không lưu trạng thái), một lượt, không cần ngữ cảnh, lại có lợi thế hơn về chi phí và khả năng mở rộng
• Những agent production thành công nhất thực ra gần với các công cụ thông minh có mục tiêu rõ ràng hơn là “agent hội thoại”

Bức tường của thiết kế công cụ và hệ thống phản hồi

• Trở ngại thực sự trong việc phát triển agent có năng suất cao là năng lực thiết kế công cụ, thứ mà nhiều đội ngũ hiện nay vẫn đánh giá thấp
• Độ chính xác của tool call đã tăng lên, nhưng mấu chốt là thiết kế cách tóm tắt trạng thái và kết quả phức tạp để phản hồi lại cho agent một cách hiệu quả
• Ví dụ:
  • Khi một công việc chỉ thành công một phần, cần quyết định nên cung cấp bao nhiêu thông tin và kiểu tóm tắt nào là phù hợp
  • Chẳng hạn nếu kết quả truy vấn có 10.000 bản ghi, cần một lớp trừu tượng hóa phục vụ nhận biết trạng thái như “thành công, 10.000 bản ghi, chỉ hiển thị 5 bản ghi đầu”
  • Khi tool thất bại, cần điều tiết lượng thông tin phục hồi và tránh làm ô nhiễm ngữ cảnh
• Trọng tâm của các agent cơ sở dữ liệu thành công trong thực tế là: cung cấp phản hồi có cấu trúc để agent thực sự có thể ra quyết định
• Trong thực tế, AI chỉ làm khoảng 30% công việc; 70% còn lại thuộc về năng lực kỹ thuật truyền thống như phản hồi công cụ, khôi phục, quản lý ngữ cảnh, v.v.

Giới hạn của việc tích hợp với hệ thống thực tế

• Ngay cả khi giải quyết được vấn đề độ tin cậy và chi phí, bài toán tích hợp với thế giới thực vẫn là một bức tường khác
• Các hệ thống trong tổ chức thực tế không có API nhất quán; chúng chứa độ phức tạp khó đoán trước như tính chất legacy, lỗi ngoại lệ, cơ chế xác thực thay đổi, giới hạn biến động, yêu cầu tuân thủ, v.v.
• Một agent cơ sở dữ liệu thực tế vẫn cần lập trình truyền thống cho quản lý connection pool, rollback transaction, tôn trọng read-only replica, timeout truy vấn, logging, v.v.
• Lời hứa rằng “AI sẽ tích hợp toàn bộ stack một cách hoàn toàn tự chủ” sẽ va vào bức tường hiện thực khi bắt tay xây dựng thật

Các mẫu hình thực sự hoạt động tốt

• Các nguyên tắc chung của những hệ thống agent thành công
  1. Agent tạo UI: con người kiểm tra cuối cùng trải nghiệm người dùng (AI chỉ xử lý phần phức tạp là chuyển ngôn ngữ tự nhiên → React)
  2. Agent cơ sở dữ liệu: các thao tác phá hủy luôn phải có con người xác nhận (AI chỉ chuyển đổi sang SQL, còn quyền kiểm soát bảo toàn dữ liệu do con người nắm)
  3. Agent sinh hàm: chỉ hoạt động trong đặc tả rõ ràng (không có trạng thái, tác dụng phụ hay tích hợp phức tạp)
  4. Tự động hóa DevOps: AI tạo mã hạ tầng, còn triển khai, quản lý phiên bản và khôi phục vẫn thuộc về pipeline hiện có
  5. Agent CI/CD: mỗi bước được thiết kế với tiêu chí thành công rõ ràng và cơ chế rollback
• Tóm tắt mẫu hình: AI xử lý phần phức tạp, con người giữ quyền kiểm soát, và độ tin cậy được bảo đảm bằng kỹ thuật phần mềm truyền thống

Triển vọng và dự báo thị trường

• Các startup mạo hiểm lấy agent hoàn toàn tự chủ làm trung tâm sẽ là nhóm đầu tiên đụng phải vấn đề lợi nhuận
• Với workflow 5 bước, bản demo có thể rất ấn tượng, nhưng doanh nghiệp thực tế thường cần hơn 20 bước và sẽ chạm vào giới hạn toán học
• Những công ty chỉ đơn giản gắn thêm AI agent vào phần mềm hiện có nhiều khả năng sẽ gặp đình trệ trong việc được chấp nhận, do tích hợp thực tế chưa đủ
• Người chiến thắng thực sự sẽ là những đội ngũ áp dụng AI chỉ cho các tác vụ khó trong một miền giới hạn rõ ràng, đồng thời đặt con người và các điều kiện biên vào những quyết định quan trọng
• Thị trường nhiều khả năng sẽ học được sự khác biệt giữa “AI chạy demo rất tốt” và “AI thực sự đáng tin cậy” thông qua những bài học đắt giá

Nguyên tắc xây dựng hệ thống agent đúng đắn

• Thiết lập ranh giới rõ ràng: định nghĩa rõ vai trò của agent và các điểm handoff sang con người/hệ thống hiện có
• Thiết kế cho thất bại: bắt buộc phải có cấu trúc rollback và phục hồi khi AI mắc lỗi
• Kiểm chứng tính kinh tế: thiết kế dựa trên chi phí mỗi lượt tương tác và khả năng mở rộng (không lưu trạng thái kinh tế hơn lưu trạng thái)
• Ưu tiên độ tin cậy hơn tính tự chủ: một hệ thống hoạt động nhất quán sẽ giành được niềm tin của người dùng tốt hơn một hệ thống thỉnh thoảng làm được điều kỳ diệu
• Xây trên nền tảng vững chắc: chỉ giao cho AI phần khó (diễn giải ý định, sinh nội dung, v.v.), còn phần còn lại (thực thi, xử lý lỗi, v.v.) để phần mềm truyền thống đảm nhiệm

Bài học thật sự từ kinh nghiệm thực chiến

• Khoảng cách giữa “chạy được trong demo” và “vận hành ở quy mô lớn ngoài thực tế” là cực kỳ lớn
• Độ tin cậy của agent, tối ưu chi phí, độ phức tạp tích hợp vẫn là những bài toán lớn chưa được giải quyết trên toàn ngành
• Kinh nghiệm triển khai thực tế và việc chia sẻ trung thực các trải nghiệm đó là chìa khóa cho sự tiến bộ của ngành
• Càng nhiều người có kinh nghiệm thực chiến cùng thảo luận về phương pháp hợp lý và các ca thất bại thực tế, khả năng thành công chung càng được nâng cao

[GN⁺]

Ý kiến trên Hacker News

• Tôi từng nói chuyện với một kỹ sư AI production của Amazon, và theo người đó thì hiện tại không có công ty nào chỉ dùng riêng AI tạo sinh ở những nơi giao tiếp trực tiếp với khách hàng; mọi phản hồi tự động đều dùng công nghệ “kiểu cũ” không phải tạo sinh, vì vấn đề độ tin cậy của AI tạo sinh vẫn quá lớn để doanh nghiệp đem danh tiếng của mình ra đặt cược

  • Trước đây tôi rất quan tâm tới các agent kết hợp kỹ thuật AI “kiểu cũ” mang tính biểu tượng với machine learning truyền thống, nhưng phần lớn lại làm việc với mạng nơ-ron thời tiền-transformer; rốt cuộc thì lúc nào cũng phải xây hệ thống có con người can thiệp trước, rồi thu thập dữ liệu đánh giá và huấn luyện, sau đó mới để hệ thống đảm nhiệm một phần công việc và đồng thời nâng chất lượng phần còn lại; đặc biệt với các tác vụ “mang tính chủ quan” thì nhất định phải đánh giá cả hệ thống symbolic; nếu đã phải huấn luyện hệ thống thì không thể tránh khâu đánh giá

  • Trên thực tế, nhiều công ty công nghệ đã triển khai AI tạo sinh vào hỗ trợ khách hàng qua chatbot thời gian thực; tôi biết những nơi như Sonder và Wealthsimple, và nếu LLM không trả lời được truy vấn thì cuộc trò chuyện sẽ được chuyển ngay sang nhân viên hỗ trợ con người

• Một điểm vẫn chưa được bàn tới là context window; con người trong lĩnh vực chuyên môn của mình có thể xử lý lượng ngữ cảnh gần như “vô hạn”, còn mô hình thì có thể phần nào vượt qua giới hạn này nhờ dữ liệu huấn luyện lớn hơn và đa dạng hơn, nhưng tôi không nghĩ đó là lời giải thực sự; hiện tại con người phải tự nén ngữ cảnh của mình vào prompt, nên với những ngôn ngữ linh hoạt như tiếng Anh, cảm giác này giống niệm thần chú hay đoán mò hơn là làm kỹ thuật, và tôi có cảm giác đang đánh mất rất nhiều dữ liệu thay vì làm theo cách có tính quyết định

  • Ở con người, “ngữ cảnh” và “trọng số” không bị tách biệt cố định như vậy; theo thời gian, trải nghiệm và kết quả liên tục thay đổi chính “trọng số” của tôi, còn với LLM thì điều đó là bất khả thi vì về mặt kiến trúc, trọng số là chỉ đọc

  • Có ý kiến hoài nghi rằng liệu con người có thật sự sở hữu một context window khổng lồ như vậy không; bản thân tôi thường xuyên chạm phải giới hạn “context window” riêng của con người khi giải quyết các vấn đề phức tạp, nên tôi tò mò không biết có ví dụ thực tế nào cho điều đó hay không

• Trải nghiệm dùng công cụ AI của tôi nhìn chung khá tích cực; nó rất hữu ích để giao các việc nhỏ lúc cần nghỉ, hoặc để sắp xếp và khởi động công việc, nhưng vấn đề chi phí xuất hiện rất nhanh; ví dụ dùng Claude Code với một codebase lớn thì tốn khoảng $25 trong 1–2 giờ, còn nếu gắn thêm khâu hiệu chỉnh tự động thì có thể lên tới $50/hr; luôn có bài toán đánh đổi giữa tốc độ, độ chính xác và chi phí; các Agent mới ra gần đây cũng vẫn chưa rõ đang nằm ở đâu trong tam giác đó, nên dù các thử nghiệm rất thú vị, tôi vẫn nghĩ rủi ro còn lớn

  • Nếu nhìn hơi mỉa mai một chút, cấu trúc LLM liên tục tự re-prompt để sửa lỗi của chính nó, cùng với cách tiếp cận kiểu “không cần RAG! cứ ném toàn bộ code vào context window 1m token đi” thực ra là một khung rất hợp với mô hình kinh doanh “tính phí theo token”

  • Một ý tưởng tôi đang cân nhắc là để AI tạo ra nhiều bản nháp commit ngay từ đầu, rồi con người sẽ trực tiếp hoặc tự động lọc kết quả và chỉnh sửa thủ công; công việc càng lớn thì những sai lệch nhỏ ở giai đoạn đầu càng dễ phá hỏng toàn bộ kết quả, nên ngay cả với SOTA hiện tại, nếu để agent thử nhiều phương án song song thì sẽ giảm thời gian refactor thủ công; tôi từng viết về quy trình liên quan trên GitHub

  • Tôi muốn hỏi là có phải đây là dịch vụ thuê bao không

• Workflow nhiều bước của con người thường có các checkpoint kiểm chứng, vì ngay cả con người cũng không chính xác trên 99%; trong tương lai, agent cũng sẽ được thiết kế quy trình kiểm chứng cho đầu ra và được huấn luyện để chỉ chuyển sang bước tiếp theo sau khi vượt qua giai đoạn đó; cũng có thể đánh giá trước mức độ rủi ro kiểu như “đoạn này bắt buộc phải chính xác trên 99%”

  • Claude Code liên tục dừng lại trước mỗi khi tiếp tục công việc để hỏi người dùng có muốn đi tiếp không, đồng thời cho xem trước các thay đổi được đề xuất; điều này hiệu quả trong việc ngăn lãng phí token và tránh làm việc kém hiệu quả

  • Nhiều ứng dụng có lẽ cũng cần được thiết kế lại cho phù hợp với cấu trúc này; theo tôi, kiến trúc microservices khá hợp với LLM nên có thể sẽ thịnh hành trở lại

• Tôi đồng ý rằng “vấn đề thật sự không nằm ở năng lực của AI, mà là ở việc thiết kế công cụ và hệ thống phản hồi để agent có thể dùng chúng một cách hiệu quả trong thực tế”; vì không chắc thị trường sẽ đón nhận thế nào nên ban đầu tôi chỉ đứng ngoài quan sát, rồi sau đó gia nhập một startup rất nhỏ chuyên xây agent; chỉ trong 5 tháng, tôi đã chuyển từ hoài nghi → đồng tình → tin chắc; khi giới hạn phạm vi chủ đề cực hẹp và tập trung vào tooling để mô hình làm việc, chúng tôi có tỷ lệ hoàn thành rất cao; mọi người thường không thích tính phi quyết định, nhưng nếu có tooling tốt và phạm vi ngày càng hẹp thì thực tế nó khá dùng được; bản thân tooling có vẻ khó, nhưng tôi nghĩ có thể giải quyết ổn, và tôi lạc quan về tương lai

• Tôi nghĩ đây đều là các vấn đề có thể giải được, chỉ là nhiều startup không tập trung vào đó vì đang chạy đua có ARR thật nhanh; quan điểm cho rằng agent vô dụng như những gì đã hứa không phải không có lý, nhưng thực tế đây là một bài toán kỹ thuật; nếu tiếp cận theo góc khác thì tôi tin nó sẽ hoạt động được (cá nhân tôi thiên về phía RL hơn), ví dụ cần một verifier tốt; với nhiều công việc, việc xác minh còn dễ hơn tự làm; chỉ cần 5 kết quả được sinh song song với độ chính xác 80% thì đã có xác suất 99.96% là ít nhất một cái đúng, và verifier có thể chọn ra cái đó; trong bối cảnh nhiều bước, điều này còn có lợi về mặt toán học; đó là một cách tiếp cận khác với trước đây, và bài viết cũng nhắc đến mô hình workflow 3–5 bước, tôi thấy nó thật sự phù hợp; chúng ta cần có nhiều mô hình kiểu này hơn trong tương lai

  • Có ý kiến cho rằng trong nhiều công việc, việc xác minh thực ra còn khó hơn chính công việc đó; đặc biệt trong QA phần mềm, lập luận này thường được dùng để tái cơ cấu nhân sự, và kết quả là chất lượng đi xuống; verifier trở nên cực kỳ khó vì số tổ hợp trạng thái khả dĩ của hệ thống và thế giới bên ngoài tăng theo cấp số nhân; LLM hấp dẫn ở chỗ có thể thay con người làm các việc lặp đi lặp lại như mock dependency hoặc điền sẵn dữ liệu trong những môi trường tác vụ phức tạp như vậy, nhưng để bài kiểm chứng có ý nghĩa thì lại luôn kéo theo yêu cầu phải chính xác 100%, và rốt cuộc với mỗi tiền điều kiện lại cần thêm một verifier khác; nếu mọi bước đều phải đạt 100% thì xác suất tích lũy sẽ giảm dần; con người đa phần chỉ kiểm thử cẩn thận theo từng case cụ thể chứ không xác minh hoàn hảo mọi trường hợp (white-box test phổ biến hơn rất nhiều so với black-box); nếu LLM sinh ra quá nhiều code thì cuối cùng người làm vẫn phải hiểu toàn bộ code mới có thể kiểm chứng kiểu white-box, và như vậy thời gian tiết kiệm được lại mất đi; hiện tại thì LLM tạo ra thứ gì tôi cũng phải tự sửa hết lỗi, nên tôi càng ít tự tin hơn và còn tốn nhiều thời gian hơn; trong một số tình huống có thể giải quyết bằng cách điều chỉnh interface cho khớp với kỳ vọng của LLM, nhưng cách này không mang tính phổ quát; còn ra ngoài lĩnh vực phần mềm thì nhiều khi việc xác minh là bất khả thi hẳn (ví dụ: “chọn ra 5 startup game triển vọng nhất”), nên nếu cứ vô tư giao cả những mảng như vậy cho máy thay vì con người thì rất khó cứu vãn

  • Tôi thắc mắc liệu có thể giả định rằng năm lần sinh kết quả đó là độc lập với nhau hay không

  • Đúng vậy, để nhiều agent cùng thử, lặp đi lặp lại và áp dụng nhiều lời giải khác nhau là cách thực tế và hiệu quả; tôi từng trải nghiệm trường hợp một phương pháp nhận phản hồi tiêu cực nhưng lại thành công khi đổi sang hướng tiếp cận khác

• Điều khá bất ngờ là một cá nhân (hoặc một nhóm cực nhỏ) lại có thể tạo ra hơn 12 AI agent đang chạy thực tế trong các mảng như phát triển, DevOps, data operations; nhìn vào tỷ lệ thất bại của startup thì ngay cả làm được “một” sản phẩm tốt đã khó, nên việc làm ra tới 12 cái thật đáng ngạc nhiên; bên tôi cũng làm công cụ data stack + AI agent như Definite suốt 2 năm, mà chỉ khoảng 6 tháng gần đây mới thấy ổn ổn, Definite

  • Thực ra không phải 12 sản phẩm độc lập, mà là 12 công cụ với mục đích rất cụ thể được làm ra để dùng trong công việc khi cần; đúng như chủ đề của cả bài viết, agent chỉ thật sự hữu ích khi tập trung vào những mục tiêu cực kỳ đơn giản và rõ ràng

  • Việc vừa làm full-time suốt 3 năm mà vẫn tạo ra hơn 12 thứ như vậy nghe có gì đó hơi lạ

• Công việc của tôi cũng là phát triển agent/AI automation, và các coding agent kiểu open-ended đơn giản là một ý tưởng ngớ ngẩn; checkpoint kiểm chứng bởi con người, không gian tìm kiếm nhỏ, câu hỏi/prompt cực kỳ cụ thể (ví dụ: email này có invoice không YES/NO) mới là hướng thực tế; tôi hiểu mong muốn có agent hoàn toàn tự động, nhưng công nghệ vẫn chưa tới đó; tôi không đụng vào việc tạo content (văn bản, hình ảnh, code), vì sớm muộn gì nó cũng sẽ phản tác dụng

  • Tôi cũng dùng chat coding cùng framework agent và đã giảm được khoảng 50% khối lượng công việc; tôi thật sự thấy GPT mang lại hiệu quả, nhưng cứ khoảng 1 trong 10 lần là chắc chắn có lỗi; nếu không thay đổi tận gốc kiến trúc LLM thì tôi không nghĩ sẽ sửa được tỷ lệ lỗi này; ở thời điểm hiện tại, miễn là hype không làm mất niềm tin của developer thì tôi tin sau này sẽ có những hệ thống vững chắc hơn nhiều; mức tăng năng suất rõ rệt tới mức giờ đây chúng tôi có thể tuyển ít người hơn hẳn so với trước; đường cong học tập ở nhiều chủ đề cũng giảm mạnh vì LLM bù lại cho chất lượng Google Search đang đi xuống; trong workflow tự động hóa, cấu trúc quan trọng nhất là một orchestration framework để LLM đảm nhiệm một phần công việc của con người, đồng thời báo cả mức độ tự tin của chính nó, và nếu confidence % thấp thì chuyển ngay cho người; chỉ cần test, guardrail các thứ được làm tốt thì hoàn toàn có thể thay thế con người ở những việc không cốt lõi; mục tiêu không phải thay con người mà là tự động hóa công việc để giảm quy mô đội ngũ; ví dụ như ở các sàn thương mại điện tử lớn, tôi tin sẽ tới ngày LLM xử lý các việc con người từng làm như mô tả sản phẩm, kiểm tra hình ảnh, lỗi chính tả, hay hình ảnh không khớp

  • Tôi nhìn chung đồng ý, nhưng nếu tiếp cận như vậy thì thứ còn lại có thể chỉ là “một hệ thống workflow đắt đỏ”; tôi băn khoăn liệu có thật sự cần LLM cho những việc mà công nghệ cũ cũng làm được hay không

  • Tôi cũng đồng ý, hiện tại điểm phù hợp nhất cho agent là “phạm vi hẹp, rủi ro thấp, công việc lặp đi lặp lại và nhàm chán”; ví dụ, tôi từng dùng agent cho các tác vụ hỗ trợ markdown của dev-log và có ghi lại ở đây

  • Dù đúng là kiểm chứng bởi con người là cách đáng tin nhất để tạo checkpoint, vẫn còn nhiều cách khác như unit test, kiểm chứng tạm thời toàn hệ thống (ad-hoc validation), v.v.

• Tôi thực sự nghĩ tác giả nên lạc quan với các agent tự chủ hơn nữa so với hiện tại; 90% những gì đang làm bây giờ là điều không thể thực hiện được vào đầu năm 2024, nên không nên đánh giá thấp đường cong tiến bộ

• Tôi cũng nghĩ vậy; một bài blog liên quan nói khá đúng rằng khác biệt cốt lõi là HITL (Human in the loop) giúp giảm lỗi, còn HOTL (Human out of the loop) thì ngược lại tạo ra vấn đề