The New Form of Software Is the Harness
When AI agents become first-class users, software itself must change.
Tony Bùi · Đăng ngày
When AI agents become first-class users, software itself must change.
Hãy hình dung bạn đang vận hành một hệ thống bán khóa học trực tuyến. Bạn muốn mở một khóa học Excel mới, giá 890.000 đồng, có mã ưu đãi giảm 20% và chỉ xuất bản sau khi kiểm tra mọi thông tin.
Với phần mềm quản trị thông thường, bạn sẽ đăng nhập, tìm đến phần quản lý khóa học, tạo nội dung, thiết lập giá, cấu hình mã giảm giá, kiểm tra quyền truy cập rồi lưu lại. Có thể bạn cần đi qua năm hoặc sáu màn hình để hoàn thành công việc. Đó là một trải nghiệm khá quen thuộc, ngay cả với những hệ thống được thiết kế tốt.
Nhưng nếu bạn có thể giao việc này cho AI agent bằng một yêu cầu duy nhất thì sao?
“Tạo khóa học Excel mới, giá 890.000 đồng, giảm 20% bằng mã EXCEL20. Chuẩn bị bản nháp để mình kiểm tra trước khi mở bán.”
Agent có thể tìm những năng lực phù hợp trong hệ thống, tạo khóa học, thiết lập giá bán, cấu hình mã ưu đãi và gửi lại bản xem trước. Trong quá trình đó, nó không cần mở giao diện quản trị, tìm kiếm các nút bấm hay mô phỏng những thao tác của con người trên trình duyệt.
Phía sau, phần mềm vẫn thực hiện những công việc quen thuộc. Nó kiểm tra dữ liệu, lưu trạng thái, áp dụng quy tắc tính giá và bảo đảm rằng một khóa học chưa được phê duyệt sẽ không thể xuất bản. Agent không tự quyết định mã giảm giá có hợp lệ hay không, cũng không có quyền bỏ qua quy tắc nghiệp vụ chỉ vì một câu lệnh của người dùng.
Cùng một công việc
Hai cách tiếp cận năng lực của phần mềm
Con người, qua giao diện quản trị
- Đăng nhập
- Quản lý khóa học
- Tạo nội dung
- Thiết lập giá
- Cấu hình mã giảm giá
- Kiểm tra quyền, lưu
Năm hoặc sáu màn hình cho một việc.
AI agent, qua capability
"Tạo khóa học Excel mới, giá 890.000 đồng, giảm 20% bằng mã EXCEL20…"
course.createprice.setcoupon.createcourse.preview
Không mở giao diện quản trị, không tìm nút bấm, không mô phỏng thao tác trên trình duyệt.
Trong tình huống này, phần mềm không hề trở nên đơn giản hơn. Độ phức tạp của nó vẫn tồn tại, nhưng cách con người tiếp cận và sử dụng những năng lực bên trong đã khác trước rất nhiều.
Điều khiến mình quan tâm là nếu AI agent có thể trở thành một đối tượng trực tiếp sử dụng phần mềm, thay vì chỉ là công cụ hỗ trợ người dùng thao tác trên giao diện, liệu chúng ta có nên xem xét lại cách xây dựng sản phẩm phần mềm ngay từ đầu?
Mình nghĩ là có. Và hướng tiếp cận mà mình muốn phát triển được thể hiện qua một tuyên bố:
The New Form of Software Is the Harness.
Đây là một luận điểm về kiến trúc phần mềm, không phải dự đoán rằng mọi application sẽ biến mất hay toàn bộ phần mềm sẽ được thay thế bằng AI. Mình muốn tìm hiểu điều gì xảy ra khi chúng ta xem AI agent là một first-class user, và tổ chức phần mềm để nó có thể được sử dụng một cách trực tiếp, linh hoạt và đáng tin cậy bởi loại người dùng mới này.
Phần mềm đã được thiết kế xoay quanh giao diện quá lâu
Trong nhiều thập kỷ, chúng ta xây dựng phần mềm dựa trên một giả định rất tự nhiên: người sử dụng phần mềm là con người.
Giả định này ảnh hưởng đến gần như toàn bộ cấu trúc sản phẩm. Chúng ta tạo ra menu để tổ chức chức năng, dashboard để hiển thị dữ liệu, biểu mẫu để nhập thông tin và những workflow để dẫn người dùng đi qua từng bước. Khi một nhu cầu mới xuất hiện, đội ngũ phát triển thường phải tìm cách đưa nó vào một màn hình hiện có hoặc xây dựng thêm một luồng thao tác phù hợp.
Ngay cả khi kiến trúc bên dưới đã chuyển từ monolithic sang microservices, từ server-rendered applications sang API-first và headless, trải nghiệm mà chúng ta cung cấp cho người dùng vẫn thường xoay quanh những application có giao diện được thiết kế sẵn.
Có lý do chính đáng cho cách tiếp cận đó. Con người cần nhìn thấy thông tin, hiểu cấu trúc hệ thống và nhận được phản hồi khi thực hiện hành động. Giao diện giúp giảm bớt độ phức tạp của phần mềm bằng cách trình bày các lựa chọn trong một phạm vi có thể hiểu và kiểm soát.
Tuy nhiên, những yêu cầu ấy không còn áp dụng theo cùng một cách khi bên sử dụng là AI agent.
Một agent không cần nhìn thấy dashboard để biết doanh thu trong tháng. Nó có thể yêu cầu hệ thống trả về dữ liệu có cấu trúc, phân tích biến động và xác định những khoản cần kiểm tra. Nếu được cấp quyền phù hợp, nó có thể tiếp tục sử dụng các năng lực khác để xử lý công việc. Đặc biệt, agent có khả năng lựa chọn trình tự hành động dựa trên mục tiêu và kết quả nhận được, thay vì chỉ thực hiện một chuỗi thao tác đã được lập trình sẵn.
Đây là điểm làm cho AI agent khác với nhiều hình thức automation truyền thống.
Một workflow thông thường được xây dựng để xử lý những tình huống mà developer đã dự đoán. Khi xuất hiện trường hợp mới, chúng ta thường phải điều chỉnh logic hoặc bổ sung một workflow. Agent có thể tiếp nhận một yêu cầu chưa được mô tả thành quy trình cụ thể, tìm các công cụ liên quan và xây dựng trình tự thực hiện ngay trong quá trình làm việc.
Khả năng này vẫn còn những giới hạn rõ ràng. Agent có thể hiểu sai yêu cầu, lựa chọn hành động không phù hợp hoặc không nhận ra rằng mình đang thiếu thông tin. Tuy nhiên, khả năng suy luận và phối hợp công cụ đã đủ để chúng ta xem nó như một loại đối tượng sử dụng phần mềm riêng biệt.
Trong software engineering, một đối tượng được xem là first-class khi những yêu cầu của nó được tính đến ngay từ thiết kế nền tảng, thay vì được bổ sung về sau bằng những giải pháp tình thế.
Với người dùng là con người, chúng ta đầu tư vào usability, navigation, information architecture và accessibility. Với AI agent, chúng ta cần quan tâm tương tự đến capability discovery, machine-readable contracts, authorization, execution state và verification.
Một người có thể nhìn thấy nút “Hoàn tiền” và đọc thông báo xác nhận trước khi thực hiện. Agent cần được cung cấp thông tin chính xác về điều kiện hoàn tiền, tác động của hành động, những trường hợp cần phê duyệt và kết quả chứng minh giao dịch đã hoàn tất.
Chúng ta cần thiết kế để agent hiểu và sử dụng những năng lực này mà không phụ thuộc vào việc diễn giải giao diện dành cho con người.
Đây cũng là lúc mình bắt đầu quan tâm đến một cách tổ chức phần mềm khác.
Software Harness là gì?
Trong hệ sinh thái AI, thuật ngữ harness thường được dùng để mô tả lớp môi trường bao quanh một model, giúp model sử dụng công cụ, quản lý context và thực hiện công việc qua nhiều bước. Một agent harness có thể chứa execution loop, cơ chế gọi tools, quản lý trạng thái và những giới hạn trong quá trình vận hành.
Mình muốn mở rộng cách nhìn này sang phía sản phẩm phần mềm.
Nếu một agent harness giúp AI thực hiện công việc, thì phần mềm mà AI sử dụng cũng cần được thiết kế để công bố các năng lực của nó, tiếp nhận hành động từ agent và bảo đảm rằng những hành động ấy được thực thi đúng.
Mình đề xuất định nghĩa:
A Software Harness is a capability-oriented software architecture that enables AI agents to discover, compose, execute, and verify business operations through explicit contracts, controlled permissions, and observable execution.
Hay diễn đạt bằng tiếng Việt:
Software Harness là một kiến trúc phần mềm tổ chức các năng lực nghiệp vụ để AI agent có thể khám phá, phối hợp và thực thi công việc thông qua những hợp đồng rõ ràng, trong phạm vi quyền hạn được kiểm soát, với kết quả có thể được kiểm chứng và quá trình thực hiện có thể được truy vết.
Có ba đặc điểm mình xem là cốt lõi của định nghĩa này.
Thứ nhất là capability-oriented. Phần mềm được tổ chức xoay quanh những năng lực nghiệp vụ có thể sử dụng độc lập với giao diện. Một capability có thể đơn giản như lấy thông tin đơn hàng, hoặc phức tạp như đối soát thanh toán, cấp quyền truy cập hay hoàn tất một giao dịch. Độ phức tạp bên trong được đóng gói sau một hợp đồng sử dụng rõ ràng.
Thứ hai là agent-operable. Các năng lực đó được công bố theo cách mà agent có thể khám phá, hiểu điều kiện sử dụng và phối hợp với nhau. Agent có thể sử dụng phần mềm thông qua API, SDK, MCP hoặc những giao thức phù hợp khác mà không cần phụ thuộc vào trình tự thao tác trên UI.
Đặc điểm thứ ba, cũng là điều mình cho rằng không thể thiếu, là execution-accountable. Phần mềm phải có trách nhiệm với những hành động mà nó cho phép thực hiện. Việc kiểm tra quyền hạn, bảo toàn quy tắc nghiệp vụ, duy trì trạng thái, xử lý lỗi và cung cấp bằng chứng thực thi không thể chỉ phụ thuộc vào khả năng suy luận của model.
Software Harness
Ba đặc điểm cốt lõi
01
Capability-oriented
Tổ chức quanh năng lực nghiệp vụ, dùng được độc lập với giao diện. Độ phức tạp nằm sau một hợp đồng rõ ràng.
02
Agent-operable
Agent khám phá, hiểu điều kiện sử dụng và phối hợp được, qua API, SDK, MCP. Không phụ thuộc trình tự thao tác trên UI.
03
Execution-accountable
Quyền hạn, quy tắc nghiệp vụ, trạng thái, lỗi và bằng chứng thực thi do phần mềm chịu trách nhiệm, không phó mặc cho model.
Một sản phẩm có MCP server chưa đương nhiên trở thành Software Harness theo định nghĩa này. Nó có thể mới chỉ cung cấp một phương thức để agent gọi các chức năng hiện có. Để tiến xa hơn, những năng lực đó cần có hợp đồng thực thi và cơ chế kiểm soát đủ rõ để agent có thể sử dụng trong những tình huống không được dự đoán hoàn toàn từ trước.
Tương tự, harness cũng không phải một AI agent được nhúng vào phần mềm.
Model có thể chạy bên ngoài, chẳng hạn trong ChatGPT, Claude hoặc một agent runtime độc lập. Phần mềm cung cấp những năng lực cho các hệ thống đó sử dụng. Nếu cần, sản phẩm vẫn có thể tích hợp một agent riêng để mang đến trải nghiệm thống nhất hơn cho người dùng.
Sự phân tách này có ý nghĩa rất lớn về mặt kiến trúc. Nó cho phép phần mềm giữ trách nhiệm đối với nghiệp vụ, trong khi agent có thể được thay đổi, nâng cấp hoặc thay thế mà không buộc chúng ta phải viết lại toàn bộ hệ thống.
Một capability cần được thiết kế như thế nào?
Để hiểu rõ hơn, chúng ta có thể xem xét một năng lực cụ thể trong hệ thống quản lý đào tạo: course.publish.
Trong một application thông thường, hành động xuất bản khóa học có thể bắt đầu từ một nút bấm. Người dùng nhấn nút, frontend gửi request đến backend, hệ thống kiểm tra dữ liệu rồi cập nhật trạng thái. Những quy tắc nghiệp vụ cần thiết có thể đã được triển khai hoàn chỉnh phía sau giao diện.
Khi đưa năng lực này cho agent sử dụng, chúng ta cần mô tả rõ hơn hợp đồng của nó.
Agent phải biết hành động course.publish cần những thông tin nào, người gọi phải có quyền gì và trạng thái khóa học cần thỏa mãn những điều kiện nào. Nó cần biết hành động có tác động gì đến hệ thống, khi nào phải yêu cầu xác nhận và những lỗi nào có thể xảy ra.
Chẳng hạn, hợp đồng của capability có thể quy định rằng khóa học phải có nội dung hợp lệ, thông tin giá bán đầy đủ và thuộc phạm vi quản lý của người yêu cầu. Agent cần có quyền course:publish. Nếu khóa học đã được người khác cập nhật sau khi agent đọc dữ liệu, hệ thống có thể từ chối yêu cầu bằng lỗi VERSION_CONFLICT để tránh ghi đè trạng thái không mong muốn.
Sau khi thực hiện, capability trả về trạng thái mới, phiên bản dữ liệu và những thông tin cần thiết để kiểm tra kết quả.
Agent không phải tự suy luận rằng một khóa học thiếu giá bán vẫn có thể xuất bản hay không. Quy tắc đó thuộc về domain logic và phải được thực thi bởi phần mềm.
Với cách thiết kế này, hợp đồng của capability vừa giúp agent hiểu cách sử dụng, vừa tạo ra một ranh giới rõ ràng giữa quyết định của agent và trách nhiệm của hệ thống.
Hợp đồng của một capability
course.publish
- Đầu vào
- Khóa học cần xuất bản, phiên bản dữ liệu agent đã đọc
- Quyền
course:publish- Điều kiện
- Nội dung hợp lệ · Giá bán đầy đủ · Thuộc phạm vi quản lý của người yêu cầu
- Tác động
- Khóa học chuyển sang trạng thái đã xuất bản; khi nào cần xác nhận
- Lỗi
VERSION_CONFLICTkhi khóa học đã bị người khác cập nhật sau khi agent đọc dữ liệu- Trả về
- Trạng thái mới · Phiên bản dữ liệu · Thông tin để kiểm tra kết quả
Tất nhiên, những phần mềm API-first được thiết kế tốt đã có nhiều đặc điểm tương tự. Validation, authorization, versioning và idempotency đều là những thực hành quen thuộc trong software engineering. Harness không tạo ra các nguyên tắc này từ đầu.
Sự khác biệt nằm ở việc chúng ta xem khả năng được khám phá và sử dụng trực tiếp bởi agent là một yêu cầu thiết kế chính thức.
Một API có thể được mô tả rất chi tiết cho developer, nhưng vẫn đòi hỏi developer tự viết chương trình để xác định các bước thực hiện. Với Software Harness, hợp đồng của các capability cần đủ rõ để một agent có thể lựa chọn và phối hợp chúng trong quá trình xử lý công việc.
Mình nghĩ đây là sự tiếp nối tự nhiên của API-first, chứ không phải một sự phủ nhận những kiến trúc đã có.
Bên trong một Software Harness
Nếu phải cụ thể hóa harness thành một kiến trúc có thể triển khai, mình hình dung nó bao gồm một số nhóm trách nhiệm. Chúng không nhất thiết phải trở thành những microservices độc lập. Một sản phẩm nhỏ có thể triển khai tất cả trong cùng một backend, trong khi hệ thống lớn hơn có thể phân tách theo những ranh giới phù hợp.
Bên trong một Software Harness
Các nhóm trách nhiệm, từ agent đến dữ liệu
Software Harness
✕ Agent không được đi vòng qua business logic để thao tác trực tiếp lên dữ liệu nghiệp vụ.
Điểm khởi đầu là Capability Registry, nơi hệ thống công bố các năng lực mà nó cung cấp. Mỗi capability có định danh, mô tả, hợp đồng dữ liệu, điều kiện sử dụng và những thông tin cần thiết để agent hiểu cách gọi. Registry cũng có thể hỗ trợ các module mở rộng hoặc plugin được cài đặt sau này. Agent không cần được cung cấp tài liệu của mọi chức năng ngay từ đầu; nó có thể khám phá những năng lực hiện có và được phép sử dụng, rồi tìm hiểu chi tiết khi cần.
Tiếp theo là Agent Access Layer, lớp cung cấp những phương thức để agent tương tác với phần mềm. MCP có thể là một trong những giao thức tại đây, bên cạnh SDK hoặc các API thông thường. Lớp này còn tiếp nhận thông tin định danh và ngữ cảnh truy cập, giúp hệ thống phân biệt những yêu cầu đến từ các agent, công cụ và chủ thể khác nhau.
Một vấn đề rất quan trọng là agent thường thực hiện công việc thay mặt một người dùng hoặc tổ chức. Vì vậy, hệ thống không thể chỉ xác thực rằng request đến từ một công cụ hợp lệ. Nó còn phải xác định công cụ đó đang hành động với quyền hạn nào và quyền ấy do ai cấp.
Đó là trách nhiệm của Policy & Authorization. Một agent có thể được phép đọc báo cáo nhưng không được thay đổi dữ liệu. Một agent khác có quyền chuẩn bị nội dung và tạo bản nháp, nhưng phải yêu cầu chủ sở hữu phê duyệt trước khi xuất bản. Những giới hạn này cần được kiểm tra trong quá trình thực thi, không thể chỉ đặt trong prompt rồi kỳ vọng model luôn tuân thủ.
Khi agent thực hiện công việc dài, Execution Coordinator có thể giúp theo dõi trạng thái, xử lý timeout, retry, những bước cần phê duyệt và các tình huống thất bại giữa chừng. Thành phần này đặc biệt hữu ích với những hành động bất đồng bộ hoặc những quy trình liên quan đến nhiều hệ thống.
Tuy nhiên, không phải mọi harness đều cần một workflow engine riêng. Nếu agent runtime bên ngoài đã quản lý kế hoạch và trình tự công việc, harness có thể tập trung vào trạng thái thực thi của từng operation và các cam kết nghiệp vụ cần duy trì. Việc phân chia trách nhiệm phải tránh tạo ra hai bộ điều phối cùng kiểm soát một quy trình mà không có ranh giới rõ ràng.
Sau mỗi hành động là câu chuyện Verification. Một API trả về HTTP 200 chưa đủ để kết luận mục tiêu của người dùng đã hoàn thành. Ví dụ, khóa học có thể đã được tạo thành công nhưng mã ưu đãi chưa được cấu hình, hoặc đơn hàng đã được cập nhật nhưng quyền truy cập của học viên vẫn chưa được cấp.
Harness cần cung cấp trạng thái và bằng chứng để agent hoặc một cơ chế kiểm tra độc lập có thể xác định kết quả thực tế. Những điều kiện nghiệp vụ bắt buộc nên được kiểm tra bởi domain services. Với các yêu cầu mang tính chủ quan, chẳng hạn chất lượng một bản thiết kế hay sự phù hợp của một bài viết, việc kiểm chứng có thể vẫn cần đánh giá của con người.
Cuối cùng là Observability. Khi phần mềm được sử dụng bởi những agent có khả năng tự lựa chọn hành động, việc truy vết quá trình thực thi trở nên đặc biệt quan trọng. Hệ thống cần ghi nhận agent nào đã gọi capability nào, trong ngữ cảnh quyền hạn nào, kết quả trả về ra sao và những lỗi nào đã xảy ra. Thông tin đó phục vụ debugging, audit và cả việc xem lại các lần thực thi để cải thiện hệ thống.
Mình cũng quan tâm đến khả năng retrospective của harness: sau một công việc thất bại, chúng ta có thể phân tích xem vấn đề xuất phát từ hợp đồng công cụ thiếu rõ ràng, quyền hạn chưa phù hợp, logic nghiệp vụ hay quyết định của agent. Những kết luận này có thể dẫn đến thay đổi trong tài liệu, capability, test hoặc chính sách thực thi. Việc cải thiện cần có kiểm tra và phê duyệt phù hợp, thay vì để agent tự ý thay đổi các quy tắc của hệ thống sau mỗi lần thất bại.
Tất cả những thành phần này phối hợp để tạo ra một môi trường mà các năng lực phần mềm có thể được sử dụng bởi nhiều loại agent, với những bảo đảm tương ứng.
Và vẫn còn một nguyên tắc cần được giữ xuyên suốt: agent không được đi vòng qua business logic để thao tác trực tiếp lên dữ liệu nghiệp vụ.
Harness không phải một lớp cho phép AI làm bất cứ điều gì với database. Nó cung cấp con đường được kiểm soát để agent sử dụng những năng lực đã được phần mềm định nghĩa và bảo vệ.
Từ một yêu cầu đến một chuỗi thực thi
Quay lại ví dụ tạo khóa học Excel ban đầu.
Agent nhận yêu cầu và tìm trong Capability Registry những năng lực liên quan. Giả sử hệ thống có course.create, price.set, coupon.create và course.preview, agent có thể đọc hợp đồng của các capability này rồi quyết định trình tự thực hiện.
Trước hết, nó tạo một khóa học ở trạng thái bản nháp. Khi backend trả về course_id, agent sử dụng định danh này để thiết lập giá bán. Sau đó, nó tạo mã ưu đãi với mức giảm 20% và phạm vi áp dụng cho khóa học tương ứng.
Mỗi hành động đều được kiểm tra quyền hạn và điều kiện nghiệp vụ. Nếu người dùng không có quyền tạo mã giảm giá, yêu cầu sẽ bị từ chối. Nếu mã EXCEL20 đã tồn tại và không thể tạo trùng, hệ thống trả về lỗi cụ thể để agent biết cần xử lý tình huống đó.
Giả sử mã ưu đãi được tạo thành công nhưng bước tiếp theo gặp lỗi mạng, agent không nên lập tức tạo lại một mã mới. Nó cần có cách kiểm tra trạng thái hoặc sử dụng cơ chế idempotency để tránh thực hiện trùng một hành động có tác động lên dữ liệu.
Khi các bước hoàn thành, agent đọc lại thông tin khóa học, kiểm tra giá bán, mã ưu đãi và trạng thái xuất bản. Nó gửi cho người dùng bản xem trước cùng thông tin những gì đã thực hiện.
Nếu người dùng chỉ yêu cầu chuẩn bị bản nháp, khóa học vẫn phải ở trạng thái chưa xuất bản. Agent không được tự suy luận rằng vì mọi thông tin đã hợp lệ nên có thể mở bán ngay.
Từ một yêu cầu đến một chuỗi thực thi
Khóa học Excel, bản nháp để kiểm tra trước khi mở bán
course.createKhóa học ở trạng thái bản nháp, trả về course_idprice.setGiá bán 890.000 đồng cho course_idcoupon.createEXCEL20, giảm 20%, áp dụng cho khóa học nàycourse.previewĐọc lại giá, mã ưu đãi, trạng thái; gửi bản xem trước
Bây giờ hãy tưởng tượng thay vì tạo khóa học, agent được giao một công việc phức tạp hơn: kiểm tra những đơn hàng đã thanh toán nhưng chưa được cấp quyền truy cập.
Công việc này có thể cần phối hợp nhiều capability: đọc đơn hàng, kiểm tra giao dịch, đối chiếu điều kiện thanh toán, xác định quyền truy cập và kích hoạt những trường hợp hợp lệ.
Agent có thể tự lựa chọn trình tự xử lý phù hợp, nhưng việc xác định một giao dịch đã thanh toán đầy đủ phải thuộc về logic đối soát của phần mềm. Điều kiện cấp quyền học viên cũng phải được thực thi tại domain service tương ứng.
Nếu một đơn hàng chưa thanh toán đủ, agent có thể ghi nhận tình huống và đề xuất xử lý. Nó không được cấp quyền truy cập chỉ vì dự đoán rằng số tiền còn thiếu là không đáng kể.
Khi một hành động thất bại ở giữa quy trình, hệ thống cần biết những bước nào đã hoàn thành và những bước nào chưa. Một số hành động có thể thử lại an toàn, một số cần kiểm tra trạng thái trước, còn những trường hợp liên quan đến giao dịch không thể đảo ngược có thể cần chuyển cho người vận hành.
Đây là lý do mình xem harness như một kiến trúc thực thi, thay vì chỉ là một danh sách các công cụ mà AI có thể gọi.
Trong những ví dụ này, agent chịu trách nhiệm diễn giải mục tiêu, lựa chọn năng lực và tổ chức công việc. Harness cung cấp những hợp đồng, quyền hạn, trạng thái thực thi và bằng chứng cần thiết. Domain services thực thi các quy tắc nghiệp vụ và duy trì tính nhất quán của dữ liệu.
Ai chịu trách nhiệm phần nào
Agent
Diễn giải mục tiêu, lựa chọn năng lực, tổ chức công việc
Harness
Hợp đồng, quyền hạn, trạng thái thực thi, bằng chứng
Domain services
Quy tắc nghiệp vụ, tính nhất quán của dữ liệu
Let AI reason about what to do. Let software enforce what must be true.
Mình nghĩ nguyên tắc này giúp xác định khá rõ ranh giới giữa sự linh hoạt của AI và tính đúng đắn của phần mềm.
Tại sao không chỉ gọi đây là API-first kết hợp MCP?
Đây có lẽ là câu hỏi cần được trả lời nghiêm túc nhất nếu muốn sử dụng thuật ngữ Software Harness.
API-first đã cho phép chúng ta tách business logic khỏi presentation layer. MCP cung cấp một giao thức để các ứng dụng AI khám phá và sử dụng công cụ, tài nguyên. Agent frameworks có thể quản lý vòng lặp thực thi, trạng thái hội thoại và việc gọi công cụ.
Tất cả đều là những thành phần có thể góp mặt trong một hệ thống theo hướng harness.
Mình không cho rằng chúng ta cần tạo ra một cách gọi mới chỉ vì đã kết nối được AI với những thành phần có sẵn.
Tuy nhiên, API-first thường tập trung vào việc cung cấp giao diện lập trình ổn định cho các bên tích hợp. MCP chủ yếu giải quyết cách công bố và trao đổi với những công cụ, tài nguyên đó. Còn các agent frameworks thường tập trung vào việc giúp agent lập kế hoạch, gọi công cụ và duy trì quá trình làm việc.
Software Harness, theo cách mình định nghĩa, đặt trọng tâm vào phía sản phẩm phần mềm: làm thế nào để các năng lực nghiệp vụ có thể được vận hành bởi agent một cách có kiểm soát, có khả năng phối hợp và có thể kiểm chứng?
Cùng góp mặt, khác trọng tâm
Mỗi thành phần giải quyết phần nào
Đó là một mối quan tâm ở cấp độ kiến trúc sản phẩm, rộng hơn một giao thức kết nối.
Điều này cũng giải thích vì sao mình không xem agent runtime là thành phần bắt buộc phải nằm bên trong harness.
Một sản phẩm có thể phục vụ Claude, ChatGPT hay nhiều agent khác nhau thông qua cùng một tập capability. Những agent này sử dụng runtime, model và phương pháp lập kế hoạch riêng. Harness tập trung vào việc công bố các năng lực, kiểm soát hành động và duy trì những cam kết nghiệp vụ mà sản phẩm cung cấp.
Nếu sản phẩm muốn tích hợp một agent riêng để phục vụ người dùng, nó hoàn toàn có thể làm như vậy. Nhưng agent nhúng bên trong và agent bên ngoài nên tiếp cận cùng những năng lực nghiệp vụ, thay vì được phép thực hiện hai con đường xử lý khác nhau với những quy tắc không nhất quán.
Nhìn theo cách này, Software Harness là một hướng tổ chức phần mềm có thể được hiện thực hóa bằng các công nghệ đã quen thuộc. Nó không phụ thuộc vào một model, framework hay giao thức duy nhất.
Mình cũng muốn giữ rõ một giới hạn về thuật ngữ. Agent harness đã có nghĩa tương đối phổ biến trong cộng đồng phát triển AI, chủ yếu nói về môi trường thực thi dành cho model. Software Harness trong bài viết này là khái niệm kiến trúc mình đang đề xuất để mô tả phía phần mềm cung cấp năng lực cho agent. Chúng có thể phối hợp với nhau, nhưng không nên bị đánh đồng.
Liệu tên gọi này có trở thành một thuật ngữ được sử dụng rộng rãi hay không thì còn cần thời gian. Điều quan trọng trước mắt là định nghĩa đủ rõ để có thể thiết kế, triển khai và đánh giá bằng những tiêu chí kỹ thuật cụ thể.
Khi capability trở thành đơn vị thiết kế chính
Có một hệ quả mà mình cho rằng sẽ ảnh hưởng đáng kể đến cách chúng ta phát triển sản phẩm: thay đổi đơn vị mà developer sử dụng để tổ chức và mở rộng phần mềm.
Hiện nay, khi nghiên cứu nhu cầu người dùng, chúng ta thường bắt đầu từ use case, user journey và workflow. Từ đó, đội ngũ phát triển xác định các chức năng, màn hình và quy trình cần xây dựng.
Cách tiếp cận này phù hợp khi người dùng trực tiếp điều khiển phần mềm thông qua giao diện.
Nhưng nếu agent có thể tự phối hợp các capability, chúng ta có thêm khả năng phục vụ những nhu cầu mà không phải xây dựng một workflow riêng cho từng tình huống.
Chẳng hạn, một người quản lý website yêu cầu kiểm tra mười bài viết có lượng truy cập giảm trong tháng, xác định nội dung lỗi thời, đề xuất cập nhật và chuẩn bị bản nháp.
Công việc này liên quan đến nhiều năng lực khác nhau: truy xuất dữ liệu analytics, đọc nội dung website, tìm kiếm thông tin, biên tập văn bản và quản lý bản nháp.
Với ứng dụng truyền thống, chúng ta có thể phải thiết kế một workflow cụ thể để đáp ứng trọn vẹn yêu cầu. Trong môi trường có các capability được mô tả và cung cấp đầy đủ, agent có thể phối hợp chúng mà không cần một màn hình hay quy trình cố định được xây dựng riêng từ trước.
Những workflow thường xuyên được sử dụng vẫn có thể được đóng gói để tăng hiệu quả và độ ổn định. Agent không cần suy luận lại tất cả mọi thứ trong mỗi lần làm việc. Nhưng với những yêu cầu mới hoặc ít gặp, khả năng kết hợp các năng lực sẵn có có thể giúp phần mềm thích ứng linh hoạt hơn.
Điều này cũng làm thay đổi cách chúng ta đánh giá chất lượng của một capability.
Khi một chức năng chỉ được gọi từ một workflow cụ thể, developer biết tương đối rõ bối cảnh sử dụng và những giả định xung quanh nó. Khi capability có thể được phối hợp bởi nhiều agent trong nhiều tình huống khác nhau, những giả định ngầm trở nên nguy hiểm.
Chúng ta cần làm rõ điều kiện đầu vào, các tác động có thể xảy ra, ranh giới quyền hạn, trạng thái lỗi và những điều kiện phải được bảo toàn. Một capability càng có khả năng tái sử dụng rộng, hợp đồng của nó càng cần được thiết kế cẩn thận.
Nếu mở rộng mô hình này theo hướng plugin-first, các capability còn có thể được cung cấp bởi những module được cài đặt sau khi phần mềm đã triển khai. Agent khám phá những năng lực mới tại runtime, đọc tài liệu và hợp đồng liên quan, rồi sử dụng chúng trong phạm vi cho phép.
Phần lõi của phần mềm có thể giữ tương đối ổn định, trong khi hệ sinh thái capability tiếp tục phát triển.
Đây là một hướng thú vị đối với các hệ thống cần hỗ trợ nhiều loại nghiệp vụ, dịch vụ tích hợp hoặc các module mở rộng mà chúng ta không thể dự đoán hết ngay từ đầu.
Tuy nhiên, càng mở rộng hệ thống theo cách này, yêu cầu về quyền hạn, versioning, compatibility và kiểm soát các tác động giữa capability càng trở nên quan trọng.
Khả năng phối hợp linh hoạt chỉ thực sự có giá trị khi các thành phần riêng lẻ đủ đáng tin cậy để được sử dụng trong những ngữ cảnh mới.
Giao diện người dùng sẽ thay đổi vai trò
Mình không nghĩ hướng phát triển này dẫn đến một tương lai mà mọi người chỉ làm việc qua cửa sổ chat.
Ngôn ngữ tự nhiên rất thuận tiện khi chúng ta muốn diễn đạt mục tiêu, giao công việc hoặc hỏi về trạng thái hệ thống. Nhưng nó không phải hình thức tương tác tốt nhất cho mọi tình huống.
Một người biên tập video vẫn cần preview và timeline để đánh giá nhịp dựng. Một người làm thiết kế vẫn cần nhìn thấy bố cục và tương tác trực tiếp với các thành phần. Một nhà quản lý có thể muốn sử dụng dashboard để khám phá những biến động của dữ liệu thay vì chỉ đọc bản tóm tắt do agent tạo ra.
Hơn nữa, giao diện còn giúp con người kiểm tra và xác nhận những quyết định quan trọng. Khi agent chuẩn bị một giao dịch, một chiến dịch marketing hoặc một thay đổi lớn trong hệ thống, việc trình bày kết quả dưới dạng trực quan có thể hiệu quả hơn nhiều so với mô tả bằng hội thoại.
Vì vậy, mình nghiêng về mô hình UI-optional, capability-first software.
Ở đây, các capability nghiệp vụ là nền tảng chung. Agent sử dụng chúng thông qua hợp đồng máy có thể đọc, developer thông qua API hoặc SDK, còn con người tiếp cận bằng những giao diện phù hợp với công việc.
UI-optional, capability-first
Một nền năng lực chung, nhiều cách tiếp cận
Con người
Giao diện phù hợp công việc: application, dashboard, màn hình phê duyệt
Developer
API hoặc SDK
AI agent
Hợp đồng máy có thể đọc
Một phần mềm có thể cung cấp UI rất phong phú mà vẫn vận hành tốt với agent. Ngược lại, một sản phẩm có thể có rất ít giao diện truyền thống, vì phần lớn công việc được xử lý qua agent và chỉ cần những màn hình chuyên biệt khi người dùng muốn xem xét hoặc phê duyệt kết quả.
Nếu thiết kế lại một sản phẩm theo hướng này, chúng ta có thể bắt đầu từ năng lực nghiệp vụ rồi quyết định giao diện nào thực sự cần thiết.
Một số năng lực cần một application hoàn chỉnh. Một số chỉ cần báo cáo, biểu đồ hoặc màn hình phê duyệt. Những thao tác có thể xác định rõ đầu vào và đầu ra đôi khi không cần giao diện riêng.
UI trở thành một trong những cách tương tác với phần mềm. Giá trị của sản phẩm được xây dựng và duy trì ở lớp năng lực nghiệp vụ, dữ liệu và những quy tắc mà hệ thống có trách nhiệm bảo đảm.
Ranh giới của sản phẩm phần mềm cũng có thể thay đổi
Từ lâu, chúng ta đã quen với việc đóng gói phần mềm thành application để phân phối và thương mại hóa.
Một CRM, một LMS, một booking system hay một phần mềm xử lý nội dung thường được xây dựng như sản phẩm hoàn chỉnh, với một tập hợp chức năng và trải nghiệm riêng. Khách hàng lựa chọn sản phẩm dựa trên khả năng giải quyết nhu cầu, mức độ phù hợp với quy trình, chi phí và chất lượng hỗ trợ.
Trong kiến trúc capability-oriented, một số năng lực bên trong các application này có thể được xem là những tài sản phần mềm độc lập.
Cơ chế cấp quyền truy cập sau thanh toán có thể phục vụ hệ thống đào tạo, nền tảng membership hoặc cửa hàng sản phẩm số. Năng lực quản lý booking có thể được sử dụng trong những lĩnh vực có quy tắc đặt lịch khác nhau. Các capability xử lý video, tài liệu và tài nguyên số có thể xuất hiện trong nhiều sản phẩm mà không cần mang theo một bộ giao diện cố định.
Khả năng tái sử dụng này không mới. Các thư viện, SDK, APIs và dịch vụ chuyên biệt đã tồn tại từ lâu.
Điều AI agent có thể bổ sung là một phương thức sử dụng linh hoạt hơn. Thay vì phải lập trình sẵn toàn bộ cách kết hợp các thành phần, agent có thể lựa chọn những capability phù hợp để giải quyết yêu cầu trong từng ngữ cảnh.
Từ đây, mình nghĩ có cơ sở để nghiên cứu mô hình phân phối các capability packages như những sản phẩm phần mềm có thể sử dụng độc lập hoặc kết hợp với nhau.
Một capability package có thể bao gồm business logic, hợp đồng dữ liệu, cơ chế phân quyền, tài liệu dành cho agent, các thành phần thực thi và những công cụ kiểm tra cần thiết. Khách hàng hoặc developer tích hợp nó vào hệ thống của mình, sau đó cung cấp khả năng sử dụng cho các agent thông qua một môi trường phù hợp.
Điều này đặc biệt đáng quan tâm với những studio phát triển software IP có thể tái sử dụng.
Thay vì đầu tư vào một application hoàn chỉnh cho từng nhóm khách hàng, chúng ta có thể xây dựng những năng lực nghiệp vụ ổn định, rồi sử dụng chúng để tạo ra nhiều sản phẩm với giao diện và cách vận hành khác nhau.
Dù vậy, khả năng tái sử dụng về kỹ thuật chưa đủ để tạo ra một mô hình kinh doanh tốt.
Một capability có thể rất đẹp về kiến trúc nhưng không đem lại giá trị nếu khách hàng không có nhu cầu rõ ràng, tích hợp quá phức tạp hoặc tổng chi phí vận hành cao hơn giải pháp hiện tại.
Khách hàng cũng không nhất thiết muốn tự lắp ghép nhiều capability để giải quyết công việc. Một application hoàn chỉnh vẫn mang lại giá trị lớn nhờ trải nghiệm thống nhất, hỗ trợ vận hành và trách nhiệm rõ ràng từ nhà cung cấp.
Vì vậy, mình xem capability packages là một lựa chọn mới cần được kiểm chứng, thay vì một mô hình chắc chắn sẽ thay thế SaaS truyền thống.
Nhưng nếu AI agent ngày càng trở thành một cách sử dụng phần mềm phổ biến, thị trường có thể bắt đầu đánh giá và mua các năng lực phần mềm theo những cách khác trước. Một sản phẩm có thể được định giá dựa trên công việc nó thực hiện được, những cam kết mà nó bảo đảm và khả năng phối hợp với các hệ thống hiện có, thay vì chủ yếu thông qua danh sách chức năng và màn hình.
Mình nghĩ đây là một trong những hướng đáng theo dõi nhất đối với các developer và product studio trong những năm tới.
Thử thách lớn nhất nằm ở độ tin cậy
Chúng ta đã chứng kiến nhiều demo AI agent có khả năng thực hiện những công việc phức tạp qua hàng chục lần gọi công cụ. Những ví dụ đó cho thấy một khả năng rất đáng chú ý: người dùng có thể giao mục tiêu thay vì tự điều khiển từng bước.
Nhưng giữa một demo thành công và một hệ thống có thể vận hành lâu dài vẫn còn khoảng cách lớn.
Một agent có thể tạo thành công một trăm đơn hàng thử nghiệm, nhưng nếu lần thứ một trăm lẻ một nó vô tình thực hiện trùng một giao dịch, chúng ta cần có cơ chế để phát hiện và xử lý. Nếu một tác vụ dài bị gián đoạn sau khi đã thay đổi dữ liệu, hệ thống phải biết trạng thái thực tế của công việc. Nếu agent hiểu sai yêu cầu hoặc sử dụng công cụ không phù hợp, những giới hạn nghiệp vụ phải ngăn hành động vượt quá quyền hạn được cấp.
Những vấn đề này vốn đã quen thuộc trong software engineering. Chúng ta có transaction management, idempotency, validation, audit logging, access control và nhiều kỹ thuật khác để bảo vệ tính nhất quán của hệ thống.
AI không làm các nguyên tắc đó trở nên lỗi thời. Khi agent có quyền tự lựa chọn và phối hợp hành động, chúng càng quan trọng hơn.
Mình cho rằng một Software Harness tốt phải được thiết kế để hệ thống vẫn giữ được những điều kiện bảo đảm cần thiết ngay cả khi agent đưa ra quyết định sai.
Điều này không có nghĩa mọi công việc đều phải được kiểm tra bởi con người hoặc mọi hành động đều cần phê duyệt. Chúng ta có thể phân loại rủi ro và thiết kế cơ chế kiểm soát tương ứng.
Một agent đọc dữ liệu để chuẩn bị báo cáo có phạm vi tác động khác với agent được phép hoàn tiền, xóa thông tin khách hàng hoặc thay đổi quyền truy cập. Những hành động có tác động lớn cần giới hạn chặt chẽ hơn, có thể bao gồm xác nhận của người dùng, kiểm tra điều kiện bổ sung hoặc cơ chế phục hồi phù hợp.
Phân loại rủi ro
Tác động càng lớn, giới hạn càng chặt
Tác động thấp
Đọc dữ liệu, chuẩn bị báo cáo, tạo bản nháp
quyền đọc · tự chạyTác động lớn
Hoàn tiền, xóa thông tin khách hàng, thay đổi quyền truy cập
xác nhận · kiểm tra bổ sung · phục hồiKhả năng quan sát cũng rất quan trọng. Khi một yêu cầu thất bại, chúng ta cần biết chuyện gì đã xảy ra thay vì chỉ nhận được thông báo rằng agent không hoàn thành công việc.
Lịch sử thực thi có thể giúp xác định một capability được mô tả chưa rõ, một chính sách ngăn hành động hợp lệ, một lỗi đồng bộ dữ liệu hoặc một quyết định thiếu căn cứ của agent.
Dữ liệu này còn giúp chúng ta cải thiện chất lượng hệ thống theo thời gian. Nhưng việc cải thiện nên diễn ra qua quá trình đánh giá và thay đổi có kiểm soát, nhất là khi liên quan đến quyền hạn và business rules.
Không có một model nào đủ thông minh để thay thế hoàn toàn những trách nhiệm này của phần mềm.
Đây là lý do mình không muốn định nghĩa harness bằng khả năng kết nối AI với càng nhiều tools càng tốt. Số lượng công cụ không nói lên khả năng vận hành đáng tin cậy. Một harness với vài capability được thiết kế tốt có thể hữu ích hơn nhiều so với hệ thống công bố hàng trăm chức năng nhưng thiếu hợp đồng rõ ràng và không thể kiểm tra kết quả thực thi.
Chúng ta nên bắt đầu xây dựng phần mềm khác đi như thế nào?
Nếu chấp nhận AI agent là một first-class user, một số quyết định thiết kế có thể cần được đưa ra sớm hơn trong quá trình phát triển sản phẩm.
Ngay từ lúc phân tích nghiệp vụ, chúng ta có thể xác định các capability cốt lõi, những điều kiện mà mỗi capability phải bảo đảm và các tác động mà nó có thể tạo ra.
Khi xây dựng API, chúng ta quan tâm thêm đến khả năng khám phá, hợp đồng dữ liệu và cách agent nhận biết kết quả. Khi thiết kế quyền hạn, chúng ta tính đến trường hợp nhiều agent hoặc công cụ cùng hành động thay mặt một người dùng, nhưng được cấp những phạm vi truy cập khác nhau.
Khi triển khai các operation, chúng ta kiểm tra kỹ khả năng thực hiện lặp lại, trạng thái lỗi và cách phục hồi. Những hành động quan trọng cần có bằng chứng và lịch sử thực thi đủ rõ để kiểm tra về sau.
Và khi thiết kế giao diện, chúng ta có thể tự hỏi liệu người dùng có thực sự cần thao tác trực tiếp, hay chỉ cần giao mục tiêu, theo dõi tiến trình và xác nhận kết quả.
Không phải mọi phần mềm đều cần đi theo hướng harness. Những ứng dụng đơn giản, những sản phẩm có tính tương tác trực quan cao hoặc các hệ thống có quy trình ổn định vẫn có thể phù hợp với kiến trúc truyền thống.
Ngay cả với những sản phẩm có AI agent, mức độ đầu tư vào harness cũng nên tương xứng với giá trị và rủi ro của những công việc mà agent được phép thực hiện.
Mình nghĩ chúng ta sẽ còn phải thử nghiệm nhiều trước khi xác định được những mẫu kiến trúc tốt nhất. Cách tổ chức registry, quản lý execution state, phân phối capability, phối hợp nhiều agent và xác minh kết quả đều là những vấn đề cần được phát triển qua thực tế.
Nhưng điều mình thấy khá rõ là cách chúng ta định nghĩa một người sử dụng phần mềm đang thay đổi.
Trước đây, phần mềm chủ yếu được thiết kế để con người trực tiếp tương tác. Các hệ thống khác có thể kết nối thông qua API, nhưng phần lớn những hành vi phức tạp vẫn cần developer lập trình trước.
Giờ đây, chúng ta có một loại người dùng có thể tiếp nhận mục tiêu, khám phá công cụ và tổ chức công việc ngay trong quá trình thực hiện. Nó có khả năng sử dụng phần mềm theo những cách mà đội ngũ phát triển chưa mô tả thành một workflow cụ thể.
Nếu đây trở thành một hình thức tương tác phổ biến, thiết kế phần mềm chỉ xoay quanh giao diện dành cho con người có thể sẽ ngày càng hạn chế những khả năng mà sản phẩm thực sự cung cấp.
Một hệ thống được tổ chức tốt cần cho phép các năng lực nghiệp vụ được tiếp cận qua nhiều hình thức, với những hợp đồng và giới hạn phù hợp. Con người có thể tiếp tục sử dụng UI khi cần. Developer vẫn tích hợp qua API. AI agent có thể trực tiếp khám phá và phối hợp những năng lực được cấp quyền.
Điểm chung của tất cả những hình thức sử dụng đó là phần mềm phải duy trì được tính đúng đắn của nghiệp vụ và trách nhiệm đối với những hành động mà nó thực hiện.
Đó là hướng kiến trúc mình muốn gọi là Software Harness.
The New Form of Software Is the Harness
Khi nhìn lại những thay đổi lớn của ngành phần mềm, chúng ta có thể thấy nhiều bước tiến xuất phát từ việc mở rộng khả năng tiếp cận các năng lực tính toán.
Giao diện đồ họa giúp máy tính trở nên dễ sử dụng hơn với con người. Web tạo ra một môi trường phân phối phần mềm rộng lớn. API mở ra khả năng tích hợp giữa các hệ thống. Cloud thay đổi cách phần mềm được triển khai, mở rộng và vận hành.
AI agent đang mở ra một thay đổi khác: phần mềm bắt đầu có thêm một loại người dùng có khả năng tự diễn giải mục tiêu và phối hợp các năng lực để hoàn thành công việc.
Mở rộng khả năng tiếp cận năng lực tính toán
- Giao diện đồ họaMáy tính dễ dùng hơn với con người
- WebMôi trường phân phối phần mềm rộng lớn
- APITích hợp giữa các hệ thống
- CloudCách triển khai, mở rộng và vận hành
- AI agentMột loại người dùng tự diễn giải mục tiêu
Mình không biết hình thái cuối cùng của các sản phẩm này sẽ ra sao. Có thể phần lớn application sẽ phát triển thêm các capability dành cho agent. Có thể chúng ta sẽ thấy những sản phẩm gần như không có UI truyền thống. Cũng có thể thị trường sẽ xuất hiện những capability packages được phân phối và thương mại hóa theo cách mà hiện nay chúng ta chưa hình dung đầy đủ.
Những khả năng đó còn phụ thuộc vào mức độ tin cậy của AI, chi phí vận hành, trải nghiệm thực tế và cả những yêu cầu về an toàn, trách nhiệm.
Nhưng về mặt thiết kế, mình nghĩ chúng ta đã có đủ cơ sở để bắt đầu đặt một câu hỏi mới mỗi khi xây dựng phần mềm:
Nếu AI agent cũng là một người sử dụng chính thức của sản phẩm, mình sẽ thiết kế hệ thống này như thế nào?
Câu hỏi ấy có thể dẫn chúng ta đến việc xây dựng ít màn hình hơn, hoặc giữ nguyên những giao diện đã chứng minh giá trị. Nó có thể khiến chúng ta tổ chức lại business logic, thiết kế các capability độc lập hơn, đầu tư nhiều hơn vào hợp đồng thực thi và nghiêm túc hơn với những vấn đề về quyền hạn, trạng thái và khả năng kiểm chứng.
Sau cùng, điều quan trọng nằm ở khả năng của phần mềm trong việc phục vụ công việc thực tế.
Một Software Harness, theo định nghĩa mình đang đề xuất, là kiến trúc đưa những năng lực ấy trở thành các thành phần có thể được khám phá, phối hợp và vận hành bởi AI agent, trong khi vẫn bảo toàn những quy tắc và trách nhiệm mà phần mềm phải thực hiện.
Khi đó, chúng ta có thể bắt đầu nghĩ về sản phẩm phần mềm thông qua những năng lực mà nó cung cấp, những điều kiện nó bảo đảm và những cách mà con người cùng các hệ thống thông minh có thể sử dụng chúng.
The New Form of Software Is the Harness.
Đây chưa phải một kết luận cuối cùng về tương lai của software engineering. Nó là một hướng thiết kế mà mình cho rằng đáng để xây dựng, thử nghiệm và kiểm chứng ngay từ bây giờ.
Đọc tiếp trong Sản phẩm & công nghệ
tab-pilot: để AI agent thao tác trên Chrome, mình giữ quyền quyết định
tab-pilot cho AI agent làm việc trên ChatGPT, Substack, LinkedIn và TikTok ngay trong Chrome mà bạn đã đăng nhập. Agent lo thao tác; bạn quyết định nội dung và có tiếng nói cuối cù
Ghi chép Sản phẩm & công nghệ 20/10/2026AI code 30 phút, nhưng hệ thống mất 2 tiếng chỉ để... tự kiểm tra nhau
Một thử nghiệm nhỏ trong phát triển phần mềm khiến mình phải xem lại cách phân công công việc, sử dụng AI và cả cách chúng ta xác định thế nào là một kết quả đáng tin cậy.
Ghi chép Sản phẩm & công nghệ 12/10/2026Kết nối MCP A Realistic Dreamer với Claude và ChatGPT
Đưa nội dung, quyền truy cập và thông tin tài khoản ARD vào cuộc chat AI của chính bạn.
Giải thích Sản phẩm & công nghệ