Tính năng Computer Use của AI đắt hơn API có cấu trúc tới 45 lần

 (reflex.dev)
1 điểm bởi GN⁺ 1 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Với cùng một tác vụ trên bảng quản trị, vision agent thao tác UI bằng ảnh chụp màn hình và các cú nhấp, còn API agent gọi cùng các handler của ứng dụng bằng phản hồi có cấu trúc, khiến giao diện trở thành biến số duy nhất tạo khác biệt về chi phí
  • Với prompt cơ bản, API agent hoàn thành tác vụ sau 8 lần gọi, nhưng vision agent đã bỏ sót 3 review đang chờ nằm bên dưới vùng đang hiển thị và chỉ phê duyệt được 1 trong 4 review
  • Khi thêm UI walkthrough gồm 14 bước, vision agent cũng hoàn thành được, nhưng mất khoảng 14 phút và khoảng 500 nghìn input token để chạy, và chính phần hướng dẫn chi tiết này cũng là một chi phí kỹ thuật riêng
  • Trong kết quả tổng thể, theo Sonnet, đường vision dùng trung bình 53 bước, 1003 giây, 550.976 input token, còn đường API kết thúc với 8 lần gọi, 19,7 giây, 12.151 input token, đồng thời độ biến động về chi phí và thời gian cũng nhỏ hơn rất nhiều
  • Khoảng cách chi phí đến từ cấu trúc giao diện hơn là năng lực mô hình; khi có thể tự động tạo HTTP endpoint từ event handler như Reflex 0.9, bài toán chi phí nghiêng hẳn về hướng API có cấu trúc đối với các công cụ nội bộ do doanh nghiệp tự xây

Mục tiêu benchmark và cấu hình thí nghiệm

  • Chi phí của cách dùng trình duyệt / dùng máy tính được đo bằng cách cho vision agent và cách API có cấu trúc cùng thao tác trên một bảng quản trị
  • Khi AI agent phải thao tác một web app không cung cấp API, vision agent thường dễ trở thành lựa chọn mặc định
  • Trong bối cảnh mỗi đội có hơn 20 công cụ nội bộ, việc viết bề mặt MCP hay REST cho từng ứng dụng trở thành một dự án kỹ thuật riêng, nên nhiều đội chọn vision agent
  • Ứng dụng thử nghiệm là bảng quản trị để quản lý khách hàng, đơn hàng và review, lấy react-admin Posters Galore demo làm mẫu
  • Cả hai agent dùng cùng một ứng dụng đang chạy, cùng Claude Sonnet, cùng bộ dữ liệu cố định, cùng tác vụ, và chỉ khác ở giao diện
  • Tác vụ là tìm khách hàng tên “Smith” có nhiều đơn hàng nhất, tìm đơn hàng đang chờ gần đây nhất của khách đó, sau đó phê duyệt toàn bộ review đang chờ và đánh dấu đơn hàng là đã giao
  • Tác vụ này chạm vào ba loại tài nguyên, bao gồm lọc, phân trang, tra cứu giữa các thực thể, đọc và ghi, nên khá giống công việc thường gặp với công cụ nội bộ

Hai đường thực thi

  • Đường A: Vision agent

    • Claude Sonnet dùng browser-use 0.12 ở chế độ vision để thao tác UI bằng ảnh chụp màn hình và cú nhấp

  • Đường B: API agent

    • Claude Sonnet trực tiếp gọi các HTTP endpoint của ứng dụng theo cách dùng công cụ
    • Mỗi công cụ được ánh xạ tới một hoặc nhiều event handler của state ứng dụng, dùng chính các hàm mà thao tác nhấp nút vẫn gọi
    • Thay vì trang đã render, agent nhận phản hồi có cấu trúc

Vì sao vision agent thất bại với prompt cơ bản

  • Cùng một tác vụ gồm sáu câu được đưa cho cả hai agent để chạy
  • API agent hoàn thành công việc với 8 lần gọi
    • Liệt kê review của khách hàng đã lọc theo trạng thái chờ
    • Phê duyệt từng review
    • Đánh dấu đơn hàng là đã giao
  • Cả hai agent đều gọi cùng logic ứng dụng, nhưng API agent đọc trực tiếp phản hồi có cấu trúc thay vì nhìn vào trang đã render
  • Với cùng prompt đó, vision agent chỉ tìm và phê duyệt được 1 trong 4 review đang chờ rồi chuyển sang bước tiếp theo
  • 3 review còn lại nằm bên dưới vùng đang hiển thị của trang review, và agent không có tín hiệu rằng cần phải cuộn
  • Thất bại này không đến từ vấn đề suy luận của mô hình, mà từ việc trang đã render không phát tín hiệu rằng nó chưa hiển thị toàn bộ nội dung
  • API agent gọi cùng handler mà UI gọi, nhưng phản hồi bao gồm toàn bộ tập kết quả do handler trả về chứ không chỉ các hàng đang được render trên màn hình
  • API agent không cần diễn giải điều khiển phân trang từ pixel, mà đọc trực tiếp những thông tin như “trang 1 trong 4 trang, mỗi trang hiển thị 50 mục”

Kết quả khi thêm hướng dẫn UI 14 bước

  • Để so sánh công bằng, prompt cho vision được viết lại thành một UI walkthrough tường minh
  • Các thành phần UI mà agent phải tương tác ở từng bước như mục sidebar, tab, trường form được nêu rõ bằng tên
  • Quá trình điều hướng mà trước đó agent không tự tìm ra được được viết thành 14 chỉ dẫn đánh số
  • Sau khi có hướng dẫn này, vision agent đã hoàn thành tác vụ
  • Tuy nhiên, quá trình chạy mất 14 phút và tiêu tốn khoảng 500 nghìn input token
  • Mỗi chỉ dẫn đánh số không hiện ra trong số token, nhưng lại mang ý nghĩa của một chi phí kỹ thuật thực tế
  • Muốn triển khai vision agent cho công cụ nội bộ, hoặc phải viết prompt chi tiết ở mức này, hoặc phải chấp nhận khả năng agent âm thầm bỏ sót công việc

Cách chạy và mức độ biến động

  • Đường API được chạy 5 lần, đường vision được chạy 3 lần
  • Mỗi lần chạy đường vision mất 14–22 phút và tiêu tốn 400 nghìn–750 nghìn token, nên chỉ được giới hạn ở 3 lần
  • Đường vision có độ phân tán lớn giữa các lần chạy
    • Trong 3 lần chạy, thời gian thực tế dao động từ 749 giây đến 1257 giây
    • Input token dao động từ 407 nghìn đến 751 nghìn
    • Lần chạy ngắn nhất mất 43 chu kỳ, lần dài nhất mất 68 chu kỳ
  • Vòng lặp chụp màn hình–suy luận–nhấp có đủ tính không xác định để một lần chạy đơn lẻ khó đại diện cho chi phí điển hình
  • Đường API không có kiểu biến động này
    • Sonnet dùng đúng 8 lần gọi công cụ trong cả 5 lần chạy
    • Số input token trên toàn bộ 5 lần chạy chỉ dao động trong khoảng ±27
    • Phản hồi có cấu trúc không tạo lý do để agent đi chệch hướng, nên nó gọi cùng handler theo cùng thứ tự

Kết quả tổng thể

Chỉ số Vision agent (Sonnet) API (Sonnet) API (Haiku)
Bước / lần gọi 53 ± 13 8 ± 0 8 ± 0
Thời gian thực tế 1003 giây ± 254 giây, khoảng 17 phút 19,7 giây ± 2,8 giây 7,7 giây ± 0,5 giây
Input token 550.976 ± 178.849 12.151 ± 27 9.478 ± 809
Output token 37.962 ± 10.850 934 ± 41 819 ± 52
  • Các con số là trung bình ± độ lệch chuẩn mẫu (n−1); đường API có n=5, đường vision có n=3
  • Chi tiết đầy đủ của các lần chạy có trong kho mã
  • Haiku không hoàn thành được đường vision
  • Thất bại này chỉ giới hạn ở schema đầu ra có cấu trúc của browser-use 0.12; Haiku không tạo được ổn định schema đó ở cả chế độ vision lẫn chỉ văn bản
  • Ở đường API, Haiku hoàn thành trong chưa đến 8 giây và dưới 10 nghìn input token, là cấu hình rẻ nhất trong các cấu hình được thử

Khoảng cách chi phí mang tính cấu trúc

  • Chênh lệch chi phí đến trực tiếp từ kiến trúc
  • Một agent phải nhìn thấy mới có thể hành động thì dù mô hình tốt hơn vẫn luôn phải trả chi phí để nhìn
  • Mô hình vision tốt hơn có thể làm giảm tỷ lệ lỗi trên mỗi ảnh chụp màn hình, nhưng không làm giảm số ảnh chụp cần có để chạm tới dữ liệu liên quan
  • Mỗi lần render là một ảnh chụp màn hình, và ảnh chụp màn hình trở thành hàng nghìn input token
  • Hai agent đi qua cùng một logic ứng dụng
    • Cả hai đều lọc, phân trang và cập nhật theo cách mà UI vẫn làm
    • Khác biệt nằm ở việc chúng đọc gì ở mỗi bước
  • Vision agent đọc pixel và phải render rồi diễn giải mọi trạng thái trung gian
  • API agent đọc phản hồi có cấu trúc từ chính các handler đó, và phản hồi này đã chứa sẵn dữ liệu mà UI định hiển thị
  • Mô hình tốt hơn có thể giảm chi phí trên mỗi bước, nhưng số bước do giao diện quyết định nên không giảm được

Khi chi phí kỹ thuật API giảm xuống, cách đánh đổi cũng thay đổi

  • Benchmark này được chạy với chi phí thấp nhờ Reflex 0.9
  • Reflex 0.9 có plugin tự động tạo HTTP endpoint từ event handler của ứng dụng Reflex
  • Luận điểm mang tính cấu trúc không phụ thuộc vào Reflex, nhưng Reflex giúp có thể chạy đường API mà không cần một codebase riêng
  • Điểm mấu chốt là điều gì trở nên khả thi khi chi phí kỹ thuật của bề mặt API tiến gần về 0
  • Vision agent vẫn phù hợp cho những ứng dụng không do bạn kiểm soát trực tiếp
    • Sản phẩm SaaS của bên thứ ba
    • Hệ thống legacy
    • Ứng dụng không thể chỉnh sửa
  • Với các công cụ nội bộ do chính bạn xây, bài toán chi phí sẽ nghiêng theo hướng ngược lại

Phạm vi thí nghiệm và lưu ý

  • Kết quả vision chỉ giới hạn trong chế độ vision của browser-use 0.12; các vision agent khác có thể hoạt động khác
  • Runner của đường B đóng gói các endpoint tự sinh thành một bề mặt công cụ REST nhỏ cỡ khoảng 30 dòng
  • Agent nhìn thấy chúng như các công cụ kiểu list_customers, update_order
  • Bộ dữ liệu là cố định và nhỏ
    • 900 khách hàng
    • 600 đơn hàng
    • 324 review
  • Chưa có đo lường về cách hành xử với dữ liệu quy mô production
  • Vision agent được chạy thông qua ChatAnthropic của LangChain
  • API agent được chạy bằng cách dùng trực tiếp Anthropic SDK
  • Số token được báo cáo là input token không dùng cache

Tài liệu tái hiện

  • Kho mã bao gồm tạo dữ liệu seed, bản vá cho demo react-admin, script của cả hai agent và kết quả thô

Bài viết liên quan

1 bình luận

 
GN⁺ 1 giờ trước
Ý kiến trên Hacker News

  • Đây là cách làm cho việc duyệt web của agent trở nên đắt đỏ: di chuyển các phần tử trên màn hình khi chuột di chuyển, buộc UI chỉ hoạt động nếu chuột phải di chuyển theo kiểu tự nhiên, đổi ngẫu nhiên nhãn nút bằng JS mỗi lần truy cập, và bắt người dùng cuộn xuống tận cuối màn hình mới thấy các tác vụ ẩn bổ sung
    Khoan đã, nghe như một ứng dụng SaaS doanh nghiệp điển hình vậy

    • Thật kỳ lạ khi những người trước đây không tin lại bỗng vì AI mà chăm chỉ áp dụng các thực hành kỹ nghệ phần mềm tốt, đặc biệt là viết đặc tả
      Điều thú vị mà cũng hơi buồn là họ không sẵn sàng làm điều này cho con người, nhưng vì AI cần nên ai cũng lao vào. Có vẻ cuối cùng họ chỉ làm cho AI vì cảm thấy nó mang lại lợi ích trực tiếp cho bản thân hơn là cho một ai đó mơ hồ trong tương lai
    • Mấu chốt là biến nó thành thứ con người muốn làm. Như [0], có thể làm cho các phần tử tương tác di chuyển và khiến chúng tương tác với môi trường theo ngữ cảnh
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • Vậy ra cuối cùng ASP WebForms mới là công nghệ chúng ta luôn cần
    • Trước đây từng có một ứng dụng desktop cố tình ẩn toàn bộ nội dung điều khiển dạng lưới khỏi Windows accessibility API, chặn việc chọn checkbox hay radio button qua accessibility API không được phản ánh, và toàn bộ chức năng xuất dữ liệu đều bị bảo vệ bằng CAPTCHA
      Thời đó còn chưa có AI tạo sinh, nhưng để chạy ứng dụng và xuất dữ liệu, chúng tôi phải kết hợp OCR, mô phỏng đầu vào người dùng và chụp bản in. Nếu các nhà phát triển biết đến Windows DRM API có thể chặn chụp màn hình, hoặc biết rằng văn bản có thể được khôi phục khá dễ từ file PostScript với định dạng tối thiểu, tôi không biết họ còn làm gì nữa
      Trớ trêu thay, quy trình trước khi thay thế cái này là cấp quyền truy cập từ xa chỉ đọc vào toàn bộ dữ liệu hệ thống cho lao động giá rẻ ở nước ngoài, mà đó lại là rủi ro bảo mật nghiêm trọng hơn nhiều so với việc nhân viên được phê duyệt dùng công cụ cục bộ của nhà cung cấp đáng tin cậy để tự động hóa công việc mà không cần truy cập mạng

  • Tôi đang làm thứ giải quyết đúng vấn đề này[1]
    Trên landing page vẫn chưa nêu bật, nhưng về bản chất nó cung cấp cho agent một bộ công cụ nhỏ để khám phá bề mặt ứng dụng, cùng với các feature API của macOS nói chung, đặc biệt là phần accessibility
    Agent có thể duyệt ứng dụng, sau đó viết workflow có thể lặp lại và về sau chạy từ CLI như invoke chrome pinTab
    Lý do dùng accessibility là vì rốt cuộc nó chính là một DOM tốt cho ứng dụng. Không phải ứng dụng nào cũng triển khai hoàn hảo, nhưng đủ nhiều ứng dụng làm được để điều này rất hữu ích
    [1] https://getinvoke.com - landing page hiện tại hướng đến creator nên chưa đề cập use case này

    • Nếu nhờ agent mà có accessibility (a11y) tốt hơn thì tôi chấp nhận được. Vẫn sẽ càu nhàu, nhưng vẫn chấp nhận
    • Nếu bạn quan tâm đến lĩnh vực này trên macOS, tôi cực kỳ khuyến nghị mở Accessibility Inspector.app do hệ thống cung cấp và tự nghịch với ứng dụng lẫn trình duyệt
      Bạn sẽ thấy các ô màu xanh có thể hướng dẫn LLM chỉ đọc một phần cụ thể của màn hình hoặc chỉ cần OCR như thế nào, có bao nhiêu văn bản đã được tích hợp sẵn trong engine accessibility, và điều này có thể dẫn không chỉ đến MCP mà còn đến các trình sinh mã tự xây và chạy script để crawl lớp accessibility của workflow
      Tôi nghĩ đây là một vùng đất rất màu mỡ. Các lab lớn phải dùng cách tiếp cận hoạt động trên nhiều nền tảng và workflow tùy ý, nên thị giác toàn màn hình là mẫu số chung thấp nhất. Cách tiếp cận theo từng nền tảng là một không gian mở thực sự thú vị
    • Đây là giải pháp hay theo kiểu chia sẻ workflow, thay vì để mọi người lặp lại cùng một tác vụ dùng máy tính rồi lãng phí token
      Chỉ là có lẽ phải đảm bảo tuyệt đối rằng sẽ không có workflow nào dùng để trích xuất thông tin người dùng như mật khẩu bị đem chia sẻ
    • Thú vị đấy. Tôi cũng có bắt đầu một thứ tương tự, tuy độ hoàn thiện thấp hơn nhiều và khá khác, nhưng cũng dùng các phần tử UI accessibility
      Vấn đề lớn là quá nhiều ứng dụng phơi bày những phần tử này rất tệ. Cách tiếp cận của tôi là dùng UIAccess hoặc một lượt đi qua của vision model để tạo UI template: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      Phản biện reddit về việc này là trải nghiệm thực tế lại gần như ngược lại. UIA trông đồng nhất trên tài liệu, nhưng WPF, WinForms và Win32 đều phơi bày các control pattern khác nhau, nên cuối cùng phải dùng handler riêng cho từng toolkit. Qt thì phải biên dịch QAccessible và nạp accessibility plugin lúc runtime mới lộ ra được gì đó, mà với binary phát hành thì chuyện đó hầu như không xảy ra. Electron cũng mù mờ trên Windows chẳng kém gì macOS, vì rốt cuộc vẫn là cùng một Chromium vẽ lên canvas. Khác biệt thực sự không phải hệ điều hành này với hệ điều hành kia, mà là toolkit native so với tất cả phần còn lại

  • Nói rằng phải viết một bề mặt MCP hay REST cho mỗi ứng dụng là cả một dự án kỹ thuật riêng thì không hẳn đúng, nếu backend được tách đủ tốt khỏi frontend và các tác vụ phía server đã được thiết kế cẩn thận, có tính khái quát

  • Tôi tự hỏi liệu có thể cho một vision agent “lập bản đồ” UI, rồi cho một agent khác truy cập nó dưới dạng một tập giao diện trông giống API hơn không
    Hiểu của tôi là hiện tại vision agent phải biết cả việc “trang tiếp theo” sẽ hiện thêm kết quả, lẫn việc ngay từ đầu phải đi lấy thêm kết quả
    Nếu một agent chỉ khám phá UI trong môi trường kiểu test để tạo ra một mô tả có phần cấu trúc về các phần tử UI và hành động, rồi agent khác nhận mô tả đó, thì không biết nó có làm tốt hơn agent vừa phải khám phá UI vừa phải hoàn thành tác vụ không
    Ví dụ, “lấy tất cả review” có thể được định nghĩa là phải vào từng trang và bấm “xem toàn bộ review” ở mỗi tóm tắt review, còn “đi từng trang” thì được định nghĩa là bắt đầu từ trang 1 mặc định của tab review và bấm “tiếp” cho đến khi nút “tiếp” biến mất
    Khi đó agent thứ hai đã có sẵn kỹ năng này nên có thể bớt phải suy nghĩ về cách duyệt, còn agent thứ nhất chỉ cần khám phá UI một lần trong môi trường test mà không lo làm sai. Có thể tôi đã hiểu hoàn toàn sai bài viết, nhưng vẫn thấy thú vị

    • Tôi cũng nghĩ y như vậy lúc đầu. Phát triển web ngày nay phụ thuộc nặng vào sinh mã, rồi phủ lên bằng làm rối và nén, sau đó JavaScript phía client lại tái cấu trúc mọi thứ một lần nữa
      Rốt cuộc bạn phải mò mẫm qua đống HTML/CSS/JavaScript phức tạp. Dù tốt hay xấu thì một web app nặng 5~10MiB cũng chẳng hiếm
      Thay vì tiếp cận “từ dưới lên” như kiểu đảo ngược những gì browser engine làm, nhìn vào biểu diễn trực quan như con người và đi “từ trên xuống” có vẻ dễ hơn
    • Có vẻ đúng vậy. Có thể cho agent học cách website hoạt động như chúng ta, rồi phơi bày mô hình đó dưới dạng API đơn giản
      Việc duyệt vẫn sẽ còn chút công việc thị giác, nhưng đó sẽ là dạng thị giác đơn giản không cần suy nghĩ
    • Tôi nghĩ bảo vision agent “lập bản đồ” là khó. Phần lớn vision model khi làm image→text chỉ tập trung vào một phần của ảnh tại một thời điểm
      Còn image→image thì dùng toàn bộ ảnh

  • Tôi không hiểu tiền đề lắm. Nếu là ứng dụng nội bộ thì tại sao lại lôi computer use ra, thay vì để agent tạo CLI hay MCP
    Hiển nhiên computer use tệ hơn. Đó là phương án cuối cùng. Không nên dùng nó khi xử lý trạng thái nằm trong DB mà tôi sở hữu
    Ngược lại, việc nó chỉ tệ hơn 50 lần lại còn khá ấn tượng

  • Hoàn toàn đồng ý. Gần đây khi làm công cụ thị giác AI, tôi đã thử cả hai hướng và độ trễ cùng chi phí của kiểu dùng trình duyệt “mang tính agent” hiện nay là chí mạng với các ứng dụng tiêu dùng thời gian thực
    API có cấu trúc, thậm chí chỉ là chuỗi lời gọi LLM dùng JSON schema nghiêm ngặt, không chỉ rẻ hơn 40 lần mà còn mang tính quyết định để thật sự đưa được một sản phẩm ổn định lên production. Computer use là demo đẹp mắt, nhưng thứ trả nổi chi phí máy chủ là API có cấu trúc

    • “Kỹ nghệ kiểu agent” chỉ là một mốt để tăng doanh thu cho các nhà cung cấp token
      Nếu bạn nghĩ LLM phù hợp với việc gì đó, hãy xây một lớp middleware được định nghĩa rõ ràng và rất có tính quyết định trên Openrouter cho đúng mục đích đó

  • API có cấu trúc đòi hỏi phải suy nghĩ thật sự, mà dạo này việc suy nghĩ lại không được xem trọng

  • Vài tháng trước tôi làm một desktopctl CLI để điều khiển ứng dụng GUI, lấy cảm hứng từ kubectl
    Trên Mac, nó kết hợp OCR và Accessibility API để biểu diễn UI bằng Markdown và phơi bày thao tác chuột cùng bàn phím
    Ý tưởng cốt lõi là vòng lặp nhận thức “nhanh” được tối ưu GPU hoàn toàn cục bộ cho việc token hóa UI và phát hiện thay đổi, còn vòng lặp điều khiển “chậm” cần LLM round-trip và dùng giao diện Markdown tiết kiệm token cho đầu ra CLI
    Các control dùng định danh tương đối ổn định, nên agent có thể script các thao tác chung như desktopctl pointer click --id btn_save mà không cần vòng lặp token hóa UI
    https://github.com/yaroshevych/desktopctl/tree/main

    • So với API, giao diện cho con người thì chậm và lộn xộn hơn, nhưng tôi học được rằng đằng sau nó vẫn có khá nhiều khoa học
      Ứng dụng tốt sẽ bộc lộ thông tin rõ ràng và được tối ưu cho việc bấm, gõ, v.v.
      GUI tốt nhất tận dụng rất tốt trí nhớ cơ bắp, nên là ứng viên hoàn hảo để script hóa thành CLI. Ví dụ, một chuỗi đơn giản như “mở Notes, nhấn Cmd+F, nhập từ khóa, đọc danh sách kết quả” có thể trở thành một lệnh Bash duy nhất mà AI agent gọi

  • Tôi luôn hoài nghi về toàn bộ khái niệm “computer use”. Nó giống như thuê ai đó vào nhà, để họ ngủ trên giường, dùng nhà vệ sinh, ăn đồ trong tủ lạnh, xem TV, rồi còn bảo luôn mã két sắt cũng ở đây
    Chỉ có điều người bạn thuê đó lại là một con khỉ

    • Hay là tôi điên rồi. Tôi ngạc nhiên là thay vì có khả năng tạo ra cách để một phần mềm truy vấn và ra lệnh cho phần mềm khác, ta lại cho AI lượn lờ với con chuột rồi bấm lung tung như thế này
    • Nói công bằng thì, tôi chỉ muốn con khỉ đó làm giúp những việc khỉ gió mà chính tôi không muốn làm

  • Những website hiện đang cố chặn Claude Code hay các AI agent khác đang đánh một trận thua sẵn
    Computer use vẫn còn ở giai đoạn đầu, và thứ ngăn nó phổ biến dường như là số token cần thiết. Nếu agent thử sai 10 lệnh CLI trước khi tìm ra lệnh đúng thì chúng ta hầu như không bận tâm
    Nhưng với các vision agent như dùng trình duyệt hay computer use, dù cuối cùng nó có đến đúng chỗ thì chúng ta cũng không đủ kiên nhẫn để chờ 20 phút chỉ để bấm một cái nút. Nếu token rẻ và nhanh hơn, rất có thể sẽ xuất hiện các mô hình dùng giao diện UI tự nhiên như CLI

    • Tôi không nghĩ token sẽ rẻ hơn đâu. Token được trợ giá bằng vốn đầu tư mạo hiểm là để xây dựng tập người dùng, và khi họ chuyển từ tăng trưởng sang lợi nhuận thì có vẻ giá token sẽ tăng
    • Và còn bộ ba chí mạng nữa. Ít nhất ở thời điểm này, dù đúng là mọi agent đều vậy, nhưng tất cả nhà cung cấp AI đều gắn cảnh báo rất mạnh về việc cho AI truy cập dữ liệu cá nhân trong trình duyệt
    • Thực tế thì không ai chặn nổi các nhà cung cấp LLM. Họ dùng request ngụy trang để quét nội dung, thậm chí đôi khi còn dùng proxy dân dụng
    • Không cần hiệu quả 100%. Chỉ cần hù đủ để người ta sợ bị khóa tài khoản mà thôi ý định thử là được
    • Thứ cản trở phổ biến không hẳn là số token mà gần hơn với chi phí khổng lồ, lượng điện lãng phí ngày càng tăng, và lượng nước khả dụng bị lãng phí