TanStack AI 1.0 giúp đổi mô hình dễ hơn và làm rõ trách nhiệm của ứng dụng
TanStack AI 1.0 ổn định API cốt lõi nhưng vẫn giữ bộ khung tác tử ở giai đoạn thử nghiệm. Khả năng đổi nhà cung cấp, ba tình huống ứng dụng và cách nâng cấp thận trọng từ 0.x.
Sơ đồ biên tập gốc do Ken Jo thực hiện, dựa trên các nguồn được liệt kê bên dưới.
Đổi mô hình nên là quyết định về sản phẩm. Nhưng khi ứng dụng đã tích lũy định dạng thông điệp riêng của nhà cung cấp, trạng thái trình duyệt và hàm gọi lại của công cụ, việc đó có thể thành dự án di chuyển trước khi ai đó kịp so sánh câu trả lời mới.
TanStack AI 1.0, công bố ngày 23 tháng 10 năm 2026, đưa ra cam kết cụ thể tại ranh giới này: API cốt lõi ổn định, 23 bộ chuyển đổi nhà cung cấp và hỗ trợ nhiều framework giao diện. Bộ khung chạy tác tử mới vẫn mang tính thử nghiệm. Khi chọn nền tảng phát triển hôm nay, sự phân biệt ấy quan trọng hơn số phiên bản. Thông báo của TanStack.
TanStack phát triển thư viện mã nguồn mở cho người xây dựng ứng dụng. Bản phát hành này nói về phần mềm giữa mô hình AI và sản phẩm: truyền câu trả lời theo luồng, công cụ, giao diện và trạng thái ứng dụng. Chúng ta sẽ xem cách đánh giá khả năng chuyển đổi, lợi ích trong ba dự án thông thường và những việc ứng dụng 0.x cần làm trước khi nâng cấp.
Ví dụ chính thức TanStack AG-UI, © 2025 Tanner Linsley, giấy phép MIT. Hình thể hiện giao diện mẫu của dự án và mô hình được chọn, không phải một lần chạy phục vụ bài viết này.
Giao diện chung thu hẹp phạm vi đổi nhà cung cấp
Bộ chuyển đổi dịch giữa định dạng ứng dụng mong đợi và API của nhà cung cấp. Nó tạo một điểm nhất quán để yêu cầu mô hình trả lời rồi nhận kết quả. Ứng dụng có thể giữ cách hiển thị hội thoại và quy tắc nghiệp vụ trong khi thay phần kết nối với nhà cung cấp.
Hãy hình dung lớp này như một tổng đài. Nó tạo kết nối dễ hiểu mà không biến mọi hệ thống phía bên kia thành giống nhau. Điều đó hữu ích vì mô hình, nơi lưu trữ vận hành và yêu cầu sản phẩm liên tục thay đổi độc lập.
Thông báo ngày 23 tháng 10 nêu 23 bộ chuyển đổi và một lựa chọn tương thích OpenAI cho dịch vụ dùng dạng API ấy. Đồng thời, thông báo tách lõi ổn định khỏi các gói khung tác tử thử nghiệm. Đây là cam kết về tương thích và bảo trì, không phải lời hứa mọi nhà cung cấp đều hỗ trợ mọi tính năng mô hình. Phạm vi phát hành.
Vì thế, câu hỏi đầu tiên cần cụ thể: phần nào của ứng dụng hiện tại có thể giữ nguyên sau khi đổi nhà cung cấp? Thành phần hiển thị câu trả lời có thể chuyển dễ dàng. Quy trình phụ thuộc mã tệp riêng, hành vi công cụ khác thường hoặc giả định đầu ra riêng của mô hình có thể vẫn cần điều chỉnh có chủ đích.
Theo chúng tôi, đó là cách đo tiến bộ phù hợp. Khả năng chuyển đổi có giá trị khi giảm lượng mã sản phẩm cần xem xét lại. Số nhà cung cấp được hỗ trợ ít quan trọng hơn việc đổi thành công đúng phụ thuộc mà sản phẩm thực tế cần thay.
Ứng dụng vẫn quyết định thế nào là thành công
API chung không làm hai mô hình đưa ra quyết định tương đương. Một mô hình có thể tuân thủ hợp đồng đầu ra có cấu trúc tốt hơn; mô hình khác phản ứng khác với hội thoại dài hoặc kết quả công cụ mơ hồ. Bộ chuyển đổi chuẩn hóa đường đi của yêu cầu, nhưng không chứng minh câu trả lời đáp ứng yêu cầu ứng dụng.
Điều này ảnh hưởng trực tiếp đến kiểm thử. Hãy tách kiểm thử tích hợp nhà cung cấp khỏi các ví dụ định nghĩa hành vi sản phẩm chấp nhận được. Yêu cầu hoàn tất đúng xác minh một hợp đồng; câu trả lời chính xác, chọn công cụ phù hợp và giao diện dễ hiểu xác minh các hợp đồng khác.
Ví dụ, trợ lý hỗ trợ có công cụ tra đơn hàng và công cụ chuẩn bị yêu cầu hoàn tiền. Cả hai nhà cung cấp có thể gọi công cụ đúng ở cấp giao thức. Câu hỏi quan trọng là mỗi mô hình có chọn đúng thao tác, tuân thủ cùng quy tắc quyền hạn và mô tả chính xác kết quả hay không.
Trước khi chuyển, hãy dùng bộ đánh giá nhỏ có tên rõ ràng. Bao gồm yêu cầu thiếu thông tin, đầu vào bất thường, công cụ không khả dụng và hội thoại tiếp tục từ lượt trước. Đây là quy trình kỹ thuật được đề xuất, không phải benchmark của TanStack. Mục tiêu là lặp lại được định nghĩa thành công của chính nhóm.
Bộ chuyển đổi có thể giữ hợp đồng kết nối. Đánh giá riêng của ứng dụng xác định hành vi phía bên kia còn chấp nhận được hay không.
Ba dự án cho thấy những dạng chuyển đổi khác nhau
Trước hết, hãy nghĩ đến ứng dụng hỗ trợ khách hàng đã có tài khoản, quyền truy cập và lịch sử hội thoại. Thêm câu trả lời theo luồng nên phù hợp với sản phẩm, không đòi thay điều hướng hay trách nhiệm dữ liệu. Lớp AI chung hấp dẫn khi cho phép giữ cấu trúc ấy và đánh giá nhà cung cấp phía sau.
Trong dự án minh họa này, hãy bắt đầu bằng tra cứu tài liệu trợ giúp chỉ đọc. Kiểm tra câu trả lời có dẫn tài liệu được cung cấp không và hủy yêu cầu có để lại trạng thái hội thoại hợp lý không. Chỉ thêm hành động khi giao diện phân biệt rõ đề xuất với thao tác đã hoàn tất. Khi đổi mô hình sau này, hãy dùng lại các kiểm tra ấy.
Tình huống thứ hai là công cụ viết nội bộ. Nhóm muốn người dùng chọn một đoạn, yêu cầu sửa rồi so sánh với bản gốc. Giao diện là trình soạn thảo, không phải cửa sổ chat thông thường. Tích hợp không áp đặt giao diện hữu ích vì sản phẩm phải quyết định văn bản sinh ra xuất hiện ở đâu và khi nào được chấp nhận.
Ở đây, khả năng đổi nhà cung cấp phải bảo vệ công sức người dùng. Đừng ghi đè đoạn gốc chỉ vì luồng đã kết thúc. Giữ riêng đề xuất, cho phép kiểm tra và quy định cách bỏ phần sinh bị dừng hoặc thất bại. Đó là trách nhiệm của ứng dụng, dù SDK nào cung cấp luồng.
Tình huống thứ ba là nhóm đã có máy chủ viết bằng ngôn ngữ khác. Ví dụ AG-UI chính thức của TanStack nối ứng dụng React với sáu ngôn ngữ máy chủ qua Server-Sent Events. README giải thích các máy chủ thực hiện giao thức truyền mà không cần gói TanStack phía máy chủ. Ví dụ đa ngôn ngữ chính thức.
Ví dụ này cụ thể hóa lời hứa chuyển đổi. Nhóm có thể đánh giá giao diện trình duyệt mà không lập tức viết lại máy chủ đang hoạt động. Họ vẫn phải triển khai đúng sự kiện, bảo vệ điểm cuối và gắn trạng thái hội thoại với người dùng của mình. Trình diễn giao thức tương thích chỉ là bước đầu.
| Dự án | Lớp chung có thể giữ gì | Ứng dụng cần đánh giá gì |
|---|---|---|
| Trợ lý hỗ trợ | Hiển thị hội thoại và ranh giới tích hợp nhà cung cấp | Độ chính xác nguồn, hành động được phép và phục hồi lỗi |
| Giao diện viết | Cơ chế truyền luồng trong trình soạn thảo sẵn có | Giữ bản gốc, chấp nhận, hủy và chất lượng sửa |
| Máy chủ sẵn có không dùng JavaScript | Ứng dụng khách dùng giao thức sự kiện chung | Thứ tự sự kiện, xác thực, quyền sở hữu hội thoại và lưu trữ lâu dài |
Các tình huống cho thấy lựa chọn này rộng hơn việc so sánh thư viện chat. Câu hỏi là bao nhiêu phần sản phẩm giữ được sự nhất quán khi một thành phần thay đổi. Dù dùng cùng mô hình, các nhóm vẫn quan tâm những ranh giới khác nhau.
Lõi ổn định và khung thử nghiệm cần hai quyết định riêng
Bản phát hành xác nhận cam kết 1.0 cho lõi, còn bộ khung tác tử mới vẫn dùng API thử nghiệm 0.x. Hãy ghi nhận chúng là hai lựa chọn phụ thuộc khác nhau. Cài cả hai không mở rộng cam kết ổn định của lõi sang khung tác tử. Thông báo ngày 23 tháng 10.
Với chức năng có giới hạn, vòng đời đơn giản thường dễ hiểu hơn: yêu cầu đến, mô hình làm việc, ứng dụng xử lý kết quả. Tác tử chạy lâu hơn thêm các câu hỏi về thông điệp đồng thời, phục hồi, trạng thái đã lưu và hành động kéo dài hơn kết nối trình duyệt. Khung tác tử tạo nơi tổ chức những vấn đề đó.
Nhãn thử nghiệm là thông tin bảo trì, không phải lý do tránh mọi thử nghiệm. Tách đánh giá khỏi luồng sản phẩm quan trọng, chỉ rõ người chịu trách nhiệm và dự trù thay đổi API. Nguyên mẫu giúp nhóm hiểu giá trị của tương tác kéo dài trước khi cam kết vận hành.
Nếu mục tiêu trước mắt là câu trả lời theo luồng trên màn hình sẵn có, hãy bắt đầu ở đó. Thêm điều phối khi quy trình người dùng cần. Một lớp trừu tượng phong phú hơn nên giải quyết vấn đề vòng đời cụ thể, không trở thành điều kiện của mọi tính năng AI nhỏ.
Bắt đầu bằng tương tác nhỏ nhưng hoàn chỉnh
Hướng dẫn hiện tại nối tuyến máy chủ, thông tin xác thực nhà cung cấp và giao diện framework. Ví dụ React dùng lời gọi mô hình phía máy chủ cùng SSE, với mã hội thoại rõ ràng. Khóa API được giữ ngoài trình duyệt. Hướng dẫn nhanh, kiểm tra ngày 27 tháng 10 năm 2026.
Trong đánh giá đầu tiên, thực hiện chuỗi sau trên nhánh phát triển riêng. Mục tiêu là một tương tác nhóm có thể xem từ yêu cầu đến kết quả. Không cần chuyển hạ tầng không liên quan để biết tích hợp có phù hợp không.
- Chọn một màn hình sẵn có và một nhiệm vụ giới hạn. Câu hỏi chỉ đọc về tài liệu trợ giúp đã cấp dễ kiểm tra hơn quy trình lập tức sửa hồ sơ khách hàng.
- Cài cùng lúc các gói ổn định của giao diện. Với điểm khởi đầu React/OpenAI trong tài liệu, dùng
npm i @tanstack/ai@^1 @tanstack/ai-react@^1 @tanstack/ai-openai@^1. Lưu lockfile vào kho mã để nhận diện phiên bản đã đánh giá. - Triển khai ranh giới máy chủ theo hướng dẫn hiện hành. Giữ thông tin xác thực trên máy chủ. Gắn yêu cầu với người dùng đã xác thực và mã hội thoại do ứng dụng quản lý.
- Hiển thị rõ trạng thái truyền, hoàn tất và hủy. Người dùng cần biết câu trả lời đang đến, đã xong hay bị ngắt. Giữ đầu vào khi yêu cầu thất bại.
- Thử cùng nhiệm vụ với nhà cung cấp thứ hai được hỗ trợ. Giữ nguyên nguồn và ca đánh giá. Ghi khác biệt hành vi riêng với thay đổi tích hợp.
- Xem kết quả như một tính năng sản phẩm. Trước khi mở rộng, kiểm tra màn hình người dùng, dữ liệu được giữ và lỗi cần can thiệp.
Quy trình được cố ý làm nhỏ để lặp lại. Một câu trả lời thành công đáng mừng, nhưng lỗi dễ hiểu cũng cung cấp thông tin tương đương. Lớp trừu tượng hữu ích giúp bảo trì cả hai đường đi.
Nâng cấp từ 0.x bao gồm cả dữ liệu
Hướng dẫn di chuyển bỏ API đã bị đánh dấu lỗi thời trong 0.x và mô tả cập nhật phối hợp các gói. Hội thoại, lần chạy và tệp đã lưu được xem là vấn đề riêng. Vì thế, vượt kiểm tra kiểu chỉ xác nhận một phần mức sẵn sàng. Hướng dẫn lên 1.0, kiểm tra ngày 27 tháng 10.
Điều này dễ bị bỏ sót khi ứng dụng có vẻ bình thường trong phiên trình duyệt mới. Hội thoại mới có thể thành công nhưng hội thoại cũ chứa trạng thái mà ứng dụng khách mới không thể tiếp tục. Việc di chuyển phải gồm bản ghi lưu trữ đại diện, không chỉ yêu cầu mới.
Hướng dẫn phân biệt đổi tên thuộc tính với cấp đúng giá trị. threadId rõ ràng cần mô hình quyền sở hữu thật; chỉnh sửa tự động không quyết định được tuyến hay cơ sở dữ liệu nhận diện hội thoại thế nào. Tương tự, không nên thay một tùy chọn body trông giống ở nơi khác bằng thao tác thay văn bản hàng loạt.
Dùng codemod được hướng dẫn ở chế độ xem trước, kiểm tra khác biệt và cập nhật cùng lúc gói ổn định phía khách và máy chủ. Sau đó thực hiện các bước dữ liệu đã lưu trong môi trường thử trước khi triển khai. Giữ gói khung thử nghiệm theo dòng phát hành được mô tả, không giả định mọi gói liên quan có cùng phiên bản chính.
Nâng cấp hoàn tất khi hội thoại cũ và giao diện vẫn hoạt động, chứ không chỉ khi mã mới biên dịch được.
Định nghĩa kiểm tra phát hành bằng hành vi nhìn thấy được. Mở và tiếp tục hội thoại cũ, hủy câu trả lời khác, thử luồng công cụ được phép lẫn bị từ chối. Xác nhận quyết định quyền hạn vẫn gắn đúng người dùng. Nhờ đó có thể xem xét hệ quả mà không biến phiên bản SDK thành điểm chất lượng.
Khả năng chuyển đổi cần được duy trì
TanStack AI 1.0 đưa ra hướng hữu ích cho nhóm muốn chủ động chọn mô hình và giao diện. Lý do áp dụng mạnh nhất là ứng dụng có ranh giới rõ mà thư viện có thể đơn giản hóa. Lý do yếu nhất là kỳ vọng bộ chuyển đổi xóa mọi khác biệt hành vi giữa nhà cung cấp.
Phép thử thực tế nằm ở thay đổi thứ hai: nhà cung cấp khác, hội thoại được tiếp tục, hợp đồng công cụ đã sửa hoặc bản ghi cũ mở bằng ứng dụng khách mới. Giữ các thay đổi có thể quan sát được, khả năng chuyển đổi sẽ thành năng lực vận hành thay vì lời hứa trong tài liệu kiến trúc.
Nguồn
- Thông báo TanStack AI 1.0, ngày 23 tháng 10 năm 2026.
- Hướng dẫn nhanh TanStack AI, kiểm tra ngày 27 tháng 10 năm 2026.
- Nâng cấp lên 1.0, kiểm tra ngày 27 tháng 10 năm 2026.
- Ví dụ AG-UI đa ngôn ngữ chính thức và giấy phép MIT, kiểm tra ngày 27 tháng 10 năm 2026. Các tình huống và quy trình mang tính minh họa; không thực hiện benchmark so sánh nhà cung cấp.
Gợi ý từ Telli.sh
Giữ yêu cầu, nguồn và quyết định phía sau tích hợp AI trong bộ tài liệu có thể tìm kiếm. Tạo tài khoản Telli.sh để sắp xếp ghi chú dự án và tài liệu đánh giá.