AI đã thực sự biết dùng máy tính chưa? Dữ liệu từ a16z cho câu trả lời bất ngờ

Mỹ | Công nghệ | Ý kiến | Văn hóa | Biểu đồ

Nghe có vẻ hiển nhiên, nhưng nếu bạn rời Thung lũng Silicon, đi ra thế giới bên ngoài và nói với họ rằng: “Có những thứ gọi là tác nhân (agent), chúng khá thông minh, có thể thực hiện các tác vụ cùng bạn và tự động hóa một số phần việc lặp đi lặp lại của bạn”, thì câu hỏi đầu tiên bạn nhận được khả năng cao sẽ là: “Chúng có biết sử dụng máy tính không?”

Đây là một câu hỏi hay! Liệu chúng có thực sự làm được không? Tầm nhìn dài hạn về tiềm năng năng suất mà chúng ta sẽ khai phá trong nền kinh tế thực suốt nhiều thập kỷ tới nằm ở những công việc thường nhật: liệu một tác nhân có thể (theo nghĩa bóng) ngồi vào bàn làm việc 24/7, được tin tưởng để sử dụng trình duyệt web, điền vào các biểu mẫu, nhấp vào đúng các nút và không mắc lỗi hay không? Đây là lĩnh vực của Thuê ngoài quy trình kinh doanh (BPO), vốn trước đây có nghĩa là “công việc này có thể thuê ngoài được không?”, nhưng giờ đây đã có một biên giới mới về tác nhân (agentic frontier). Chúng tôi đã viết về điều này vào năm ngoái, khi bối cảnh sử dụng máy tính của AI phần lớn vẫn chỉ là một loạt các bản demo. Rất nhiều điều đã thay đổi kể từ đó.

Các mô hình đã cải thiện nhanh hơn hầu hết mọi người mong đợi. Các tác nhân sử dụng máy tính đang bắt đầu trụ vững trong môi trường sản xuất ở quy mô lớn và trên các quy trình làm việc hẹp, có thể lặp lại: cập nhật hệ thống ghi chép, di chuyển dữ liệu qua các cổng thông tin, xử lý phiếu yêu cầu (tickets), kiểm tra hồ sơ và xử lý phần đuôi dài (long tail) của các phần mềm không có API sạch. Với cơ sở hạ tầng phù hợp, khả năng sử dụng máy tính hiện có thể được triển khai để giải quyết các tác vụ từ đầu đến cuối ở quy mô lớn, vốn trước đây đòi hỏi sự giám sát của con người hoặc do con người trực tiếp thực hiện.

Ngày nay, các quy trình làm việc tận dụng khả năng sử dụng máy tính vẫn còn xa mới hoàn hảo: các tác nhân trở nên kém ổn định khi công việc đi chệch khỏi quy trình chuẩn (runbook), và đối với một số trường hợp sử dụng mà việc lưu trữ đệm (caching) không khả thi (xem thêm bên dưới), chúng đắt đỏ đến mức bài toán kinh tế không phải lúc nào cũng hiệu quả. Tuy nhiên, chúng ta đang thấy các triển khai thực tế cho công việc văn phòng tiêu chuẩn, đặc biệt là ở những nơi mà nếu không có AI, con người sẽ phải nhấp chuột thủ công qua các hệ thống cũ; đường cong chi phí đang bắt đầu trở nên hấp dẫn, khi xét đến việc các quy trình làm việc tận dụng khả năng sử dụng máy tính mang lại những lợi thế cấu trúc như khả dụng 24/7 và - quan trọng nhất - khả năng mở rộng để đáp ứng nhu cầu.

Làn sóng cơ sở hạ tầng sử dụng máy tính đầu tiên tập trung vào việc làm cho các tác nhân có khả năng: nhìn, nhấp, gõ và phục hồi sau lỗi. Làn sóng tiếp theo là làm cho chúng trở nên hữu ích bên trong các công ty thực tế. Khi việc điều hướng giao diện người dùng (UI) thô trở thành một loại hàng hóa ở tầng mô hình, mô hình không còn là nút thắt chính nữa và lợi thế bền vững sẽ chuyển lên các tầng cao hơn: ngữ cảnh, quyền hạn, kiến thức quy trình, xác thực, leo thang, xử lý lỗi, lưu trữ đệm và sự thấu hiểu khó nhọc về cách công việc thực sự được thực hiện trong tổ chức của một khách hàng cụ thể để lập bản đồ quy trình từ đầu đến cuối. Nói cách khác, biên giới đang chuyển dịch từ “tác nhân có thể sử dụng máy tính không?” sang “nó có thể thực hiện công việc này một cách đáng tin cậy không?”

Một năm trước, mô hình sử dụng máy tính tốt nhất đạt 42% trên OSWorld-Verified; mô hình tốt nhất hiện nay đạt 85%, cao hơn mức ~72% mà con người đạt được trên cùng các tác vụ (điều này có nghĩa là chúng đã hoàn thành thành công 85 trên 100 tác vụ). Trong sản xuất, các mô hình biên (frontier models) tổng quát này hoạt động khá giống với cách chúng thực hiện trong các bài kiểm chuẩn: các phòng thí nghiệm cung cấp khả năng sử dụng máy tính dưới dạng API - mô hình nhận ảnh chụp màn hình, trả về các cú nhấp chuột và phím bấm, với CUA của OpenAI còn bổ sung thêm dữ liệu cây hỗ trợ tiếp cận (accessibility-tree) hoặc DOM nếu có - và các nhà phát triển bao bọc vòng lặp đó trong bộ công cụ riêng của họ: một máy ảo (VM) hoặc trình duyệt được cô lập, cộng với logic điều phối, xác minh và thử lại. Đáng chú ý là hầu như không ai triển khai các sản phẩm tiêu dùng (Claude, chế độ tác nhân của ChatGPT) cho việc này - các nhà sáng lập và doanh nghiệp xây dựng trên các API thô, hoặc mua từ các nhà cung cấp đóng gói chúng. Và bước nhảy vọt về khả năng chính là điều làm cho các thiết lập đó trở nên khả thi - như một nhà sáng lập trong lĩnh vực này đã nói: “Các mô hình chưa đủ tốt để tự sử dụng trong sản xuất cho đến khi Opus 4.6 ra mắt vào tháng 2 năm 2026”. Đâu đó trong mười tám tháng qua, khả năng sử dụng máy tính đã chuyển từ bản demo sang trạng thái có thể triển khai thực tế.

Tất nhiên, các bài kiểm chuẩn không phải lúc nào cũng là thước đo tốt nhất cho tính khả thi của một triển khai trong thế giới thực. OSWorld đếm các tác vụ đã hoàn thành, vì vậy 85% vẫn có nghĩa là 15 trên 100 tác vụ thất bại, và một quy trình kinh doanh chỉ kết thúc nếu mọi bước đều hoàn tất. Công việc văn phòng không được chấm điểm theo đường cong: nếu một người phải xem xét lại mọi kết quả đầu ra, thì không có sức lao động nào được tiết kiệm. (Điều này tương tự với những gì đang xảy ra trong lập trình hiện nay: nguồn lực khan hiếm không còn là viết mã, mà là bảo chứng cho mã đó.)

Chúng tôi nhận thấy cách tốt nhất để suy nghĩ về những gì quan trọng là vượt ra ngoài các bài kiểm chuẩn và tập trung vào câu hỏi cốt lõi: liệu một quy trình kinh doanh có thể được tự động hóa một cách đáng tin cậy bằng khả năng sử dụng máy tính hay không? Dưới góc độ này, điều tạo ra sự khác biệt lớn nhất chính là mọi thứ xung quanh mô hình - đó là: xác minh, leo thang, xử lý lỗi khi cổng thông tin của nhà bán lẻ thay đổi bố cục chỉ sau một đêm.

Có lẽ dấu hiệu rõ ràng nhất là một nhà điều hành mà chúng tôi đã trao đổi, người chạy hàng triệu tác vụ tự động mỗi tháng, không thể cho chúng tôi biết mô hình nào đang thực hiện chúng; anh ấy không cần phải tìm hiểu. Nhà cung cấp của anh ấy thay đổi các mô hình bên dưới giống như cách một nhà cung cấp dịch vụ đám mây thay đổi phần cứng. Nhưng anh ấy tin tưởng vào tác nhân sử dụng máy tính để thực hiện các tác vụ này. Điểm mấu chốt: khi những người dùng nặng ký nhất của bạn ngừng kiểm tra bảng xếp hạng, thì bảng xếp hạng đó đã không còn là câu chuyện chính nữa.

Do đó, biểu đồ trên giải thích lý do tại sao các triển khai sản xuất tồn tại vào năm 2026 mà không có vào năm 2024. Từ đó trở đi, yếu tố quyết định liệu chúng có hoạt động hay không chính là tất cả những thứ còn lại - và đó là phần còn lại của bài viết này.

Chúng tôi đã có nhiều cuộc trò chuyện với các nhóm đang chạy các quy trình làm việc tận dụng khả năng sử dụng máy tính trong sản xuất, và chúng tôi học được từ kinh nghiệm của họ rằng các tác vụ tuân thủ giao thức (protocol following) hoạt động tốt nhất. Không có gì ngạc nhiên khi các tác nhân sử dụng máy tính thất bại ở những quy trình phức tạp hơn, nơi độ chính xác khó xác minh hơn. Bài học rút ra tổng thể là các tác nhân sử dụng máy tính mạnh nhất ở các tác vụ tiêu chuẩn, có thể lặp lại với lộ trình rõ ràng, được xác định cụ thể. Điểm đột phá thực sự là phần đuôi dài của phần mềm nơi không có API sạch và con người nếu không sẽ phải nhấp chuột thủ công qua giao diện người dùng. Trong thực tế, công việc này giống như cập nhật hồ sơ trong CRM, QA, đăng nhập vào các cổng thông tin chính phủ và bảo hiểm, lấy dữ liệu từ cơ sở dữ liệu và các trang quy định, xử lý đơn hàng bán lẻ, xử lý hợp đồng hoặc các phiếu yêu cầu CNTT trong ServiceNow.

Chúng tôi tin rằng tiếng nói của người dùng ở đây kể câu chuyện tốt hơn bất kỳ lý thuyết nào. Một số ví dụ: một nền tảng dữ liệu CPG đã hướng dẫn chúng tôi cách họ chạy ~15-20 triệu tương tác cổng thông tin tự động mỗi tháng, sử dụng các tác nhân như một phương án dự phòng tự phục hồi cho các trình cào dữ liệu (scrapers) viết tay - khi cổng thông tin của nhà bán lẻ thay đổi giao diện, tác nhân sẽ chẩn đoán lỗi, sửa lỗi tự động hóa và giữ cho dữ liệu lưu thông trước khi kỹ sư kịp nhìn thấy lỗi đó. Họ cho biết sau khi triển khai, họ đã cắt giảm một nửa đội ngũ kỹ sư chuyên bảo trì trình cào dữ liệu và tái phân bổ nhân sự cho các quy trình làm việc khác. Trong một trường hợp khác, từ một nhà tích hợp hệ thống toàn cầu, chúng tôi biết rằng họ có 27 quy trình làm việc trực tiếp tận dụng các tác nhân sử dụng máy tính để xử lý ~1.500-2.100 phiếu yêu cầu CNTT mỗi ngày, với mục tiêu cuối cùng là tái triển khai 20-25% nhân sự vào các hợp đồng dịch vụ quản lý có biên lợi nhuận thấp. Cuối cùng, một công ty dịch vụ đã hướng dẫn chúng tôi cách họ tự động hóa quy trình tuyển dụng từ đầu đến cuối để điền dữ liệu vào nền tảng theo dõi ứng viên ngay khi cuộc phỏng vấn kết thúc. Để làm điều đó, họ chạy một mô hình giá rẻ không phải mô hình biên vì nó “làm mọi thứ chúng tôi cần và làm rất tốt”.

Mô hình rõ ràng nhất là các quy trình làm việc mà về lý thuyết, một tác nhân sử dụng máy tính có thể vận hành và giải quyết tác vụ, nhưng lại không có câu trả lời rõ ràng cho việc “thế nào là tốt” (tức là khó đánh giá) hoặc không có cách đáng tin cậy để xác định xem tác vụ đó có thành công hay không. Thông thường, các vấn đề phát sinh nhanh chóng khi: (1) bạn không thể đối chiếu kết quả đầu ra - hãy nghĩ đến một tác nhân trích xuất các điều khoản thanh toán từ hợp đồng vào ERP: nếu nó đọc “net 60” thành “net 30”, hồ sơ trông hoàn toàn hợp lý, vượt qua mọi kiểm tra trực quan và không ai phát hiện ra cho đến khi hóa đơn sai lệch được gửi đi; và (2) trong một số trường hợp, không có tín hiệu nào để xác minh thành công tại thời điểm tác vụ chạy - hãy nghĩ đến một tác nhân gửi yêu cầu bồi thường trên cổng thông tin bảo hiểm: yêu cầu được gửi đi, màn hình hiển thị “đã nhận”, tác vụ hoàn tất. Ngoại trừ việc hai ngày sau, nhân viên điều chỉnh gọi đến văn phòng vì cần xác nhận số chính sách trước khi yêu cầu có thể được xử lý. Một con người đã nộp yêu cầu đó sẽ nhấc điện thoại và giải quyết trong ba mươi giây; tác nhân không hề biết cuộc gọi đó đã xảy ra và yêu cầu bồi thường lặng lẽ bị đình trệ. Kết luận là một mô hình thông minh hơn không sửa được một quy trình mà sự thật khách quan chỉ xuất hiện dưới dạng một cuộc gọi điện thoại đến bàn làm việc của ai đó một tuần sau đó, trừ khi bộ công cụ được thiết kế để xử lý các trường hợp ngoại lệ ngay từ đầu.

Đối với những người mua mà chúng tôi đã trao đổi, bản thân mô hình hiếm khi là yếu tố quyết định, vì “các mô hình ngày nay đã đủ tốt rồi”. Trong thực tế, họ đánh giá và trả tiền cho mọi thứ xung quanh mô hình: cơ sở hạ tầng để chạy ổn định ở quy mô lớn, vượt qua kiểm tra bảo mật và chứng minh ROI. Người dùng không quan tâm liệu giải pháp có sử dụng một mô hình biên cụ thể nào hay không; thay vào đó, họ tập trung vào việc liệu nó có thực sự hoàn thành tác vụ ở quy mô lớn và đáng tin cậy hay không. Chấm hết.

Hệ quả là, các chế độ thất bại (failure modes) quan trọng hơn bất kỳ bài kiểm chuẩn nào, và việc thiết kế để xử lý thất bại cần phải là mối quan tâm hàng đầu ngay từ đầu, bởi vì một giải pháp không xử lý tốt các thất bại sẽ không bao giờ được chấp nhận trong sản xuất. Một ví dụ về điều này trong thực tế và một mô hình mà chúng tôi đã gặp nhiều lần: tác nhân chạy quy trình làm việc một lần, hệ thống lưu trữ nó dưới dạng mã xác định (deterministic code), các lần chạy sau đó thực thi như mã có thể lặp lại giá rẻ, và mô hình chỉ quay lại khi có sự cố - để chẩn đoán, sửa lỗi và lưu trữ lại. Với cách tiếp cận này, chi phí cho mỗi lần chạy giảm dần theo vòng đời của quy trình làm việc, và các mô hình rẻ hơn chỉ làm giảm hóa đơn. Điều thú vị ở đây là cách nó xử lý sự không chắc chắn. Trong khi trước đây mã xác định đơn giản là thất bại, hoặc con người phải xem xét và sửa mọi lỗi, thì ở đây tác nhân tự hấp thụ sự không chắc chắn đó. Đó là một cách thiết kế để xử lý thất bại, và nó cho thấy những gì người mua thực sự đang khen thưởng và sử dụng ở quy mô lớn.

Chúng tôi không gặp các trường hợp sử dụng phức tạp hơn ở những người dùng mà chúng tôi đã trao đổi, điều này cho thấy thị trường vẫn đang khai thác những “quả chín thấp” (low-hanging fruit). Tuy nhiên, có một danh sách dài các quy trình làm việc có thể được tự động hóa theo cách này trước khi bất kỳ ai cần đến những tác vụ khó hơn.

Đối với các nhà sáng lập, sự thay đổi quan trọng hơn là những gì đang trở nên phổ biến hóa (commoditized). Xây dựng một tác nhân sử dụng máy tính từng có nghĩa là phải vật lộn với Selenium hoặc Playwright, hoặc gần đây hơn là Stagehand, và chắp vá các bản ghi DOM hoặc video để nắm bắt một quy trình làm việc. Toàn bộ tầng thực thi đó đang được trừu tượng hóa, giống như cách Claude Code đã trừu tượng hóa phần giàn giáo xung quanh các tác nhân lập trình. Nếu việc nhấp vào đúng nút không còn là phần khó, thì nó không còn là lợi thế cạnh tranh (moat) nữa.

Không có gì ngạc nhiên khi ngữ cảnh và kiến thức về quy trình làm việc là những thứ bền vững. Phần khó không phải là liệu một tác nhân có thể điều hướng màn hình SAP hay không, mà là liệu nó có hiểu cách một công ty cụ thể thực sự hoàn thành công việc hay không: kiến thức nội bộ, thuật ngữ nội bộ, định dạng ưu tiên, ai cần leo thang và khi nào, cách xử lý thất bại, cách xác minh kết quả đầu ra một cách đáng tin cậy. Trong thực tế, ngữ cảnh đó nằm trong các runbook, trong quyền truy cập và thông tin xác thực, trong các trường hợp kiểm thử và các rào cản khi quy trình làm việc đi chệch kịch bản, và ngày càng nhiều trong một video ghi lại cảnh ai đó thực hiện công việc một lần. Không có gì trong số đó là chung chung. Tất cả đều cụ thể cho một công ty, và thường là cho một nhóm. Tuy nhiên, đó chính xác là loại vấn đề cụ thể, không hào nhoáng mà các công ty khởi nghiệp tập trung thường giải quyết tốt hơn các nhà cung cấp mô hình, đó là lý do tại sao chúng tôi nghĩ rằng thế hệ đồng nghiệp tác nhân tiếp theo được xây dựng ở tầng ứng dụng và ngữ cảnh, chứ không phải tầng mô hình.

Những người mua mà chúng tôi đã trao đổi hoàn toàn xác nhận điều này. Họ chọn nhà cung cấp dựa trên việc sản phẩm có báo cáo số giờ tiết kiệm được mà không cần thêm công sức hay không, và liệu một kỹ sư cấp dưới có thể vận hành nó hay không. Hiện tại, lợi thế cạnh tranh không phải là khả năng biên - thay vào đó, đó là việc trở thành nhà cung cấp mà doanh nghiệp được phép và có khả năng sử dụng ở quy mô lớn trong sản xuất.

Dữ liệu chi phí cũng rất đáng khích lệ. Hãy coi các con số trên là bậc độ lớn, không phải báo giá chính xác. Chạy một tác nhân tốn khoảng 6-8 đô la mỗi giờ suy luận hiện nay, nhưng trong thực tế dao động từ 3 đến 15 đô la tùy thuộc vào cách xây dựng bộ công cụ - tần suất chụp ảnh màn hình, lượng ngữ cảnh mang theo, bao nhiêu phần công việc có thể chuyển giao cho mã xác định. Những con số này mô tả tác nhân vận hành giao diện người dùng từng ảnh chụp màn hình một với một mô hình biên - chế độ đắt đỏ nhất hiện có. Các bộ công cụ được xây dựng tốt sẽ dành chế độ đó cho những gì thực sự cần thiết, và để mã xác định giá rẻ xử lý các phần có thể lặp lại - không phải quy trình làm việc nào cũng có thể tối ưu hóa theo cách này, nhưng ở những nơi có thể, chi phí hỗn hợp sẽ giảm nhanh chóng. Vì vậy, hãy đọc sự so sánh này như trường hợp xấu nhất, và ngay cả khi đó, một tác nhân vẫn gần như hòa vốn so với BPO nước ngoài ở mức ~10 đô la/giờ (đã bao gồm mọi chi phí), và mang lại biên lợi nhuận gộp 70-80% so với lao động văn phòng tại Mỹ ở mức ~30-45 đô la/giờ. Trong sản xuất, bộ công cụ thúc đẩy chi phí thực tế nhiều như mô hình vậy.

Lưu ý tương tự về tốc độ. Ở chế độ tác nhân, các tác nhân vẫn chậm hơn con người, và khoảng cách không hề nhỏ - một tác vụ mà ai đó hoàn thành trong hai đến ba phút có thể mất tám đến mười phút đối với tác nhân, và các bài kiểm chuẩn học thuật còn cho thấy khoảng cách lớn hơn nữa. Các lần chạy xác định đảo ngược điều này: mã thực thi nhanh hơn bất kỳ con người nào - nhưng đối với công việc tác nhân, lập luận không phải là tốc độ. Đó là việc một tác nhân chạy suốt ngày đêm, tốn một phần nhỏ chi phí lao động Mỹ và mở rộng quy mô mà không cần tuyển dụng thêm.

Sự so sánh này hiệu quả với người mua BPO và các nhóm vận hành, nhưng kinh tế đơn vị trông khác nếu bạn là người bán giờ tác nhân, vì chi phí ít dự đoán được hơn trong môi trường thực tế. Giá vốn hàng bán (COGS) là suy luận cộng với thử lại (tức là các lần chạy thất bại vẫn tiêu tốn token) và biên lợi nhuận bị thu hẹp khi ngữ cảnh tăng lên hoặc tần suất chụp ảnh màn hình tăng lên. Các nhà cung cấp quản lý điều này bằng cách định giá theo tác vụ, theo giờ hoặc theo kết quả, mỗi loại có hồ sơ rủi ro khác nhau tùy thuộc vào sự biến động của quy trình làm việc. Ngoài ra còn có những thực tế như giám sát, bảo trì và leo thang cho con người, những thứ đang được tính vào giá, giống như cách họ làm với lực lượng lao động con người. Chưa có mô hình kinh doanh “một kích cỡ cho tất cả” ở đây, và câu trả lời thay đổi tùy theo ngành dọc.

Và bài toán kinh tế chỉ ngày càng tốt hơn - suy luận ngày càng rẻ hơn, và các mô hình mã nguồn mở đang trở nên đủ tốt cho một phần ngày càng tăng của các quy trình làm việc này. Đối với bất kỳ tác vụ nào mà một tác nhân có thể giải quyết một cách đáng tin cậy, việc nhúng khả năng sử dụng máy tính có khả năng sẽ thuận tiện hơn nhiều so với lao động con người. Vì vậy, câu hỏi thực sự không còn là liệu bài toán kinh tế có hiệu quả hay không - mà là tập hợp các tác vụ có thể giải quyết một cách đáng tin cậy sẽ mở rộng đến đâu, đó là nơi mọi thứ đang hướng tới tiếp theo.

Trong năm qua, các phòng thí nghiệm và một làn sóng các công ty khởi nghiệp đã đổ hàng trăm triệu đô la vào các môi trường RL sử dụng máy tính - các sandbox nơi mô hình thực hành các tác vụ thực tế và được thưởng khi hoàn thành chúng - với các công ty như Mechanize, Habitat, Fleet, Chakra, Deeptune, Matrices và Originator xây dựng nền tảng đào tạo và đánh giá bên dưới các mô hình biên. Khoản chi đó là thứ thể hiện dưới dạng khả năng suy luận tốt hơn, theo dõi trạng thái tốt hơn và khả năng chịu đựng tốt hơn đối với các ứng dụng hoạt động không ổn định. Các mô hình vẫn cần bộ công cụ cẩn thận để trụ vững trong sản xuất - lưu trữ đệm quy trình (run-caching) là ví dụ rõ ràng nhất - nhưng khả năng thô đã được mua, một cách có chủ đích, thông qua cơ sở hạ tầng đào tạo này và sẽ chỉ tốt hơn theo thời gian.

Tuy nhiên, kiến trúc lại là một câu chuyện khác. Hầu hết các hệ thống sử dụng máy tính được triển khai trong sản xuất hiện nay đều là đơn tác nhân: một mô hình, một tác vụ, một phiên. Khi các quy trình làm việc trở nên phức tạp hơn và độ trễ trở thành một ràng buộc, các kiến trúc đa tác nhân bắt đầu trở nên quan trọng. Ví dụ, một bộ lập kế hoạch phân tách quy trình làm việc, các tác nhân thực thi xử lý các tác vụ con song song và các tác nhân chạy lâu dài mang đến những vấn đề riêng: bộ nhớ, sự tin tưởng và tỷ lệ thất bại tích lũy theo thời gian. Các nhóm đang thực hiện công việc thú vị ở đây đều đang xây dựng sự điều phối tùy chỉnh, vì chưa có khung chuẩn nào tồn tại. Sự tương tự với Claude Code rất đáng học hỏi: khi các tác nhân lập trình trưởng thành, một tầng giàn giáo đã xuất hiện để trừu tượng hóa sự điều phối. Điều tương tự có khả năng xảy ra đối với các quy trình làm việc tận dụng khả năng sử dụng máy tính, và tầng trừu tượng đó là một trong những vấn đề cơ sở hạ tầng chưa được giải quyết thú vị nhất trong không gian này.

Từ đây, các phát triển trong tương lai đi theo ba hướng: độ chính xác, độ trễ và chi phí. Độ chính xác là quan trọng nhất, và như chúng tôi đã giải thích ở trên, đại diện cho sự khác biệt giữa một bản demo thú vị và việc thực sự giải quyết vấn đề - phát hiện các điểm bất thường, tự kiểm tra công việc của chính mình, chỉ leo thang khi thực sự cần thiết. Độ trễ là yếu tố có khả năng gây ngạc nhiên nhất cho mọi người: một số nhóm đã cắt giảm nó ngay hôm nay bằng cách dựa trên cây hỗ trợ tiếp cận thay vì ảnh chụp màn hình. Mô hình hành động máy tính tổng quát của Standard Intelligence được đào tạo trên tập dữ liệu video 11 triệu giờ, chạy ở tốc độ 30 FPS, và là một tín hiệu sớm cho thấy vòng lặp ảnh chụp màn hình từng bước làm chậm các tác nhân ngày nay là một vấn đề có thể giải quyết được, không phải là một loại thuế vĩnh viễn. Chi phí tiếp tục giảm khi suy luận rẻ hơn, và các mô hình nhỏ hơn không phải mô hình biên sẽ đảm nhận các cú nhấp chuột thường lệ. Ba vectơ này cùng với bảo mật và quản trị (ví dụ: thông tin xác thực, nhật ký kiểm toán, lưu giữ dữ liệu, tiêm lệnh (prompt injection) và trách nhiệm giải trình, phân quyền).

Các doanh nghiệp có thể và đang hưởng lợi từ các tác nhân sử dụng máy tính cho các quy trình làm việc hẹp có khối lượng lớn, các bước lặp đi lặp lại, các quy tắc kinh doanh ổn định với các giao diện cũ hoặc thiếu API. Hiện tại, chúng phù hợp nhất cho các tác vụ có bằng chứng thành công tức thì, có thể quan sát được bằng máy, hậu quả thất bại có thể chấp nhận được và các lộ trình leo thang rõ ràng. Nhưng với những phát triển trên, các cải tiến là có thật và nhanh chóng, làm cho các tác nhân sử dụng máy tính trở nên khả thi hơn cho nhiều loại công việc hơn.

Hãy cứ nói rằng - tương lai cho khả năng sử dụng máy tính thật tươi sáng!

Bản tin này chỉ được cung cấp cho mục đích thông tin và không nên được coi là lời khuyên về pháp lý, kinh doanh, đầu tư hoặc thuế. Hơn nữa, nội dung này không phải là lời khuyên đầu tư, cũng không nhằm mục đích sử dụng bởi bất kỳ nhà đầu tư hoặc nhà đầu tư tiềm năng nào trong bất kỳ quỹ a16z nào. Bản tin này có thể liên kết đến các trang web khác hoặc chứa thông tin khác thu được từ các nguồn của bên thứ ba - a16z chưa xác minh độc lập cũng như không đưa ra bất kỳ tuyên bố nào về tính chính xác hiện tại hoặc lâu dài của thông tin đó. Nếu nội dung này bao gồm quảng cáo của bên thứ ba, a16z chưa xem xét các quảng cáo đó và không xác nhận bất kỳ nội dung quảng cáo hoặc công ty liên quan nào có trong đó. Bất kỳ khoản đầu tư hoặc công ty danh mục đầu tư nào được đề cập, tham chiếu hoặc mô tả đều không đại diện cho tất cả các khoản đầu tư trong các phương tiện do a16z quản lý; truy cập https://a16z.com/investment-list/ để biết danh sách đầy đủ các khoản đầu tư. Các thông tin quan trọng khác có thể được tìm thấy tại a16z.com/disclosures. Bạn đang nhận bản tin này vì bạn đã chọn tham gia trước đó; nếu bạn muốn chọn không nhận các bản tin trong tương lai, bạn có thể hủy đăng ký ngay lập tức.

Không có bài đăng nào