Những điều chúng tôi học được khi triển khai bằng ChatGPT Apps SDK

• Apps SDK là lựa chọn thiết thực nếu bạn sớm cần một quy trình làm việc trong ChatGPT hoặc muốn thử các công cụ tại đó trước khi đầu tư vào một hệ thống tác nhân tùy chỉnh. Nếu cần toàn quyền kiểm soát từng bước trong cách tác nhân hoạt động thì Apps SDK thường không phù hợp.

• Hãy chọn Apps SDK khi ChatGPT là giao diện chính và bạn muốn kết hợp công cụ với một vài thành phần UI nhỏ mà không phải xây dựng cả sản phẩm trò chuyện hoàn chỉnh. Hãy tự xây dựng hệ thống tác nhân khi bạn cần kiểm soát chặt chẽ luồng, bộ nhớ, câu lệnh và thao tác ghi.

• Apps SDK phù hợp với các sản phẩm kết hợp trò chuyện và một vài bước tương tác UI ngắn. Bạn triển khai nhanh hơn nhưng phải đánh đổi một phần quyền kiểm soát.

• Điều mang lại hiệu quả cho chúng tôi là công cụ rõ ràng, hành vi tiện ích rõ ràng và bước tiếp theo rõ ràng. Chúng tôi dựa vào những yếu tố đó để xác định luồng, thay vì dựa vào LLM. Mô hình hữu ích nhất khi giải thích những kết quả mà hệ thống đã chọn.

• Dưới đây là cách lựa chọn, tiếp đến là những gì hiệu quả và không hiệu quả.

Phần lớn các nhóm vẫn chỉ thử nghiệm AI hoặc triển khai AI cho những ứng dụng bên lề có mức rủi ro và lợi ích thấp. Rất ít nhóm triển khai một sản phẩm trọng yếu với doanh nghiệp mà người dùng sử dụng hằng tuần. ChatGPT Apps SDK là một cách thu hẹp khoảng cách đó nếu mục tiêu của bạn là hiện diện trong ChatGPT thay vì tự xây dựng toàn bộ trợ lý.

Những bài học của chúng tôi đến từ một dự án khách hàng có yêu cầu chọn ChatGPT làm giao diện chính và triển khai nhanh mà không phải đầu tư vào một sản phẩm trò chuyện riêng được thiết kế hoàn toàn theo nhu cầu.

Với yêu cầu đó, Apps SDK phù hợp vì khách hàng cần:

• Không phải xây dựng và lưu trữ một sản phẩm trò chuyện riêng—họ muốn tiếp cận người dùng trong ChatGPT, chứ không cần thêm một lớp vỏ trợ lý độc lập.

• Trò chuyện kết hợp UI nhỏ dành riêng cho từng tác vụ—một vài bước tiện ích tập trung, thay vì một sản phẩm hoàn chỉnh thứ hai nằm trong quy trình.

• Hành vi backend được cung cấp qua công cụ MCP—gọi công cụ theo chuẩn, thay vì sở hữu toàn bộ môi trường chạy tác nhân tùy chỉnh.

• Khả năng được khám phá trong ChatGPT—người dùng nên tiếp cận quy trình ngay tại nơi họ vốn làm việc.

Trong quá trình xây dựng, chúng tôi đã cùng khách hàng xác thực các lựa chọn này. Sự đánh đổi vẫn còn đó: khi ChatGPT lưu trữ phiên, bạn không sở hữu môi trường chạy bên ngoài. Bạn có thể định hướng nhưng không thể kiểm soát hoàn toàn.

Một ứng dụng Apps SDK kết nối ba thành phần:

1. Môi trường chạy tác nhân của ChatGPT

2. Các công cụ MCP của bạn

3. UI tiện ích của bạn

Luồng hoạt động thực tế:

1. Người dùng yêu cầu ChatGPT thực hiện một việc.

2. ChatGPT có thể gọi một trong các công cụ MCP của bạn.

3. Máy chủ của bạn trả về kết quả công cụ có cấu trúc.

4. ChatGPT đọc kết quả đó và quyết định bước tiếp theo: gọi thêm công cụ, trả lời người dùng hoặc thực hiện cả hai. Nếu đã gắn một tiện ích vào công cụ đó, tiện ích có thể xuất hiện trong lượt này.

5. Người dùng tiếp tục trong cuộc trò chuyện hoặc tiện ích (nhập nội dung tiếp theo, đưa ra lựa chọn hoặc gọi công cụ từ tiện ích). Thao tác đó cập nhật chuỗi hội thoại; ChatGPT chạy một lượt khác và lặp lại các bước 2–4 cho đến khi hoàn tất tác vụ.

Điểm cốt lõi chính là sự kết hợp giữa trò chuyện, thao tác backend và các bước UI ngắn. Điều đó cũng có nghĩa là những điểm dễ xảy ra lỗi nằm ở khâu chuyển giao giữa cuộc trò chuyện, công cụ và UI.

Bạn không phải xây dựng lại từ đầu UI trò chuyện, kết nối công cụ, quy trình xác thực hay lớp vỏ tiện ích. Với nhiều sản phẩm, điều này rút ngắn đáng kể thời gian xây dựng để bạn tập trung vào logic nghiệp vụ và các biện pháp bảo vệ.

Xây dựng trong ChatGPT không giống với việc vận hành tác nhân của riêng bạn. Phần khó của dự án không nằm ở các thủ thuật viết câu lệnh. Thách thức là làm rõ công cụ, tiện ích và bước tiếp theo để mô hình luôn đồng bộ với UI.

Apps SDK tạo ra một dạng sản phẩm khác với frontend thông thường, nhưng bạn cần hiểu rõ SDK này phù hợp nhất với những trường hợp nào.

Dùng Apps SDK khi bạn muốn

• Nhanh chóng triển khai một quy trình làm việc trong ChatGPT.

• Để ChatGPT lưu trữ cuộc trò chuyện.

• Kết hợp ngôn ngữ tự nhiên với một vài bước UI tập trung.

• Không phải tự xây dựng giao diện trò chuyện, vùng chứa tác nhân và tính năng khám phá.

Điểm cuối cùng đặc biệt quan trọng khi người dùng của bạn vốn đã làm việc trong ChatGPT.

Tự xây dựng tác nhân khi bạn cần

• Một luồng cố định theo từng bước mà bạn có thể áp đặt bằng mã.

• Một UI và quy trình xác nhận tùy chỉnh do bạn sở hữu toàn diện.

• Mô hình bộ nhớ và trạng thái của riêng bạn.

• Hành vi phải có thể dự đoán trong mọi lần chạy.

• Dữ liệu theo dõi, nhật ký và chỉ số của tác nhân.

Nếu bộ lập kế hoạch, câu lệnh hệ thống và toàn bộ quy trình chính là sản phẩm của bạn, một hệ thống tùy chỉnh thường phù hợp hơn.

Trong dự án này, vấn đề luôn được nhắc đến là quyền kiểm soát: một bên là tốc độ và nền tảng quen thuộc; bên kia là chỉ sở hữu một phần môi trường chạy. Đó là sự đánh đổi mà khách hàng chấp nhận khi ưu tiên tiếp cận người dùng trong ChatGPT hơn là sở hữu toàn bộ hệ thống.

Luồng lý tưởng nghe có vẻ đơn giản: người dùng đưa ra yêu cầu, công cụ chạy, dữ liệu trả về và tiện ích xuất hiện khi cần lựa chọn.

Trên thực tế, khó khăn nằm ở các khâu chuyển giao. Tiện ích không phải là thành phần trang trí. Khi xuất hiện trên màn hình, tiện ích sẽ thay đổi những gì mô hình nhìn thấy và thực hiện tiếp theo. Hãy coi thao tác trên tiện ích là các sự kiện có tên rõ ràng, không phải nội dung trò chuyện tùy ý.

Hệ thống dùng trong dự án khá đơn giản: FastMCP, Pydantic, React và TypeScript. Việc tích hợp chúng không có vấn đề gì. Công việc thực sự là khiến mô hình, công cụ và UI thống nhất về những gì sẽ xảy ra tiếp theo.

Làm rõ từng khâu chuyển giao

Chúng tôi không còn xem kết quả công cụ là dữ liệu thô từ backend. Mỗi kết quả trả về đều trở thành một khâu chuyển giao.

Một kết quả công cụ tốt sẽ:

• Cung cấp cho tiện ích dữ liệu cần thiết để hiển thị.

• Cung cấp cho ChatGPT các dữ kiện có cấu trúc để làm cơ sở trả lời.

• Khi luồng yêu cầu, nêu rõ việc cần làm tiếp theo để mô hình không phải phỏng đoán.

Các thao tác trên tiện ích không nên gửi nội dung mơ hồ trở lại chuỗi hội thoại. Chúng cần nêu rõ người dùng đã làm gì và bước tiếp theo là gì.

Độ tin cậy tăng lên khi các khâu chuyển giao trở nên rõ ràng.

Mô hình làm theo những chỉ dẫn ngắn gọn, rõ ràng khi chúng nằm trong đầu ra của công cụ và thao tác trên tiện ích.

Dưới đây là một cấu trúc Pydantic nhỏ mà chúng tôi đã dùng. Trường output chứa dữ liệu có cấu trúc mà tiện ích cần khi được hiển thị, cùng các dữ kiện ChatGPT nên dùng trong phiên. Trường agent_directions chứa một dòng ngắn cho biết trợ lý nên làm gì tiếp theo. Trường Reason là tùy chọn.

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

Giữ cho tiện ích gọn nhẹ

Các tiện ích hiệu quả chỉ xử lý một quyết định rồi trả lại quyền điều khiển. Danh sách ngắn, bước xác nhận hoặc màn hình đánh giá gọn gàng hiệu quả hơn việc biến tiện ích thành một ứng dụng thu nhỏ. Một chút logic trong tiện ích, chẳng hạn như xác thực đơn giản hoặc bước tiếp theo cố định, vẫn hữu ích khi chúng tôi muốn luồng có tính xác định cao hơn.

Dùng ngôi thứ ba trong thông báo của tiện ích

Chúng tôi không còn viết nội dung tiếp theo của tiện ích như lời người dùng trong cuộc trò chuyện (“Tôi đã chọn…”, “Tôi đã xác nhận…”). Thay vào đó, chúng tôi viết thành báo cáo ngắn về thao tác của người dùng (“Người dùng đã chọn…”, “Người dùng đã xác nhận…”). Chúng tôi thử cách này vì ChatGPT thêm thông báo của tiện ích dưới dạng thông báo công cụ thay vì thông báo người dùng.

Thực hiện trực tiếp khi bước tiếp theo đã rõ ràng

Nếu một nút thể hiện rõ lần gọi công cụ tiếp theo, để tiện ích trực tiếp kích hoạt công cụ sẽ hiệu quả hơn việc buộc hệ thống chạy thêm một lượt trò chuyện. Cách này chỉ áp dụng khi lần gọi công cụ tiếp theo không cần dữ liệu đầu vào từ ChatGPT.

Cách này giúp thực thi các luồng có tính xác định và giảm độ trễ nhờ tránh thêm một lượt trò chuyện.

Xử lý lỗi

Khi gọi công cụ thất bại, chúng tôi trả về đúng mã lỗi MCP cùng thông báo ngắn gọn, dễ hiểu từ công cụ. Nhờ đó, khi lệnh gọi thất bại, ChatGPT có thông tin thực tế để đọc, giải thích vấn đề cho người dùng và/hoặc chọn bước tiếp theo hợp lý.

Quản lý ngữ cảnh công cụ

Chúng tôi lưu trạng thái phiên trên máy chủ của mình. ChatGPT gửi ngữ cảnh trong phạm vi phiên khi gọi công cụ; trong FastMCP, chúng tôi cung cấp cho mỗi công cụ một tham số Context để trình xử lý có thể đọc và cập nhật trạng thái đó.

• Các ID ổn định và kết quả trước đó được lưu trong phiên, thay vì yêu cầu ChatGPT truyền lại chúng dưới dạng đối số công cụ trong mỗi lần gọi.

• Khi xuất hiện vòng lặp gọi công cụ, chúng tôi có thể phát hiện lệnh gọi trùng lặp và trả về lỗi rõ ràng qua kết quả công cụ.

• Nhật ký phiên được lưu ở phía chúng tôi để gỡ lỗi và hỗ trợ.

Lúc đầu, chúng tôi hiển thị một tiện ích, cho rằng mô hình “đã hiểu” rồi chờ nó gọi đúng công cụ tiếp theo. Đôi khi điều đó xảy ra. Nhưng thường thì không.

Khi không có khâu chuyển giao rõ ràng, ChatGPT có thể tóm tắt trong khi chúng tôi muốn nó hành động, yêu cầu người dùng lặp lại lựa chọn hoặc tiếp tục lập kế hoạch khi đáng lẽ phải dừng.

Cách khắc phục là nêu rõ bước tiếp theo trong đầu ra có cấu trúc và tải trọng tiện ích, thay vì hy vọng mô hình tự suy ra.

Chúng tôi từng thử cách phân tách phản hồi một cách khéo léo giữa đầu ra công cụ, siêu dữ liệu ẩn và nội dung trò chuyện theo tài liệu Apps SDK. Tuy nhiên, chúng tôi không thể đọc siêu dữ liệu ẩn trong các tiện ích. Vì vậy, chúng tôi không thể dùng cách này.

Tài liệu Apps SDK mô tả cách loại một số công cụ khỏi danh sách công cụ của tác nhân để tác nhân không chọn chúng, nhưng tiện ích vẫn có thể gọi. Khi chúng tôi đặt chế độ hiển thị thành app-only, những công cụ đó cũng không còn khả dụng với tiện ích, chứ không chỉ với tác nhân. Chúng tôi không thể thiết lập để tác nhân không nhìn thấy công cụ nhưng tiện ích vẫn có thể dùng.

Im lặng hoặc trả về thông báo chung chung “thành công” khi không có kết quả hữu ích còn tệ hơn một lỗi rõ ràng. Vì vậy, chúng tôi coi lỗi công cụ và tiện ích là đầu ra quan trọng: nếu không thể tiếp tục một bước, chúng tôi nói rõ bằng ngôn ngữ dễ hiểu và trả về lỗi cụ thể, thay vì để người dùng nhìn vào một tiện ích đã hiển thị nhưng không giúp họ tiến thêm. Điều này cải thiện khả năng sử dụng và giúp hành vi của mô hình đáng tin cậy hơn.

Nếu mục tiêu của bạn là tạo một quy trình làm việc trong ChatGPT mà không phải tự xây dựng nhiều thành phần nền tảng, Apps SDK là cách thiết thực để đạt được điều đó. Bạn đánh đổi một phần quyền kiểm soát để có tốc độ và tiếp cận người dùng ngay tại nơi họ vốn làm việc.

Nếu cần sở hữu mọi nhánh của luồng, UI và quyền quyết định từng bước, hãy lên kế hoạch tự xây dựng hệ thống tác nhân ngay từ đầu. Nhiều khả năng bạn sẽ sớm cần vượt ra ngoài phạm vi chỉ xây dựng trong ChatGPT.

Bạn cũng có thể dùng Apps SDK để chạy máy chủ MCP trong ChatGPT trước khi tự xây dựng phần trò chuyện, xác thực và kết nối tác nhân, rồi chuyển sang hệ thống riêng khi sản phẩm cần.

Bước tiếp theo cho các nhóm ở hoàn cảnh tương tự: chọn một quy trình có kết quả rõ ràng, ghi lại các khâu chuyển giao giữa cuộc trò chuyện, công cụ và tiện ích, sau đó kiểm thử kỹ việc thử lại và xử lý lỗi trước khi dành nhiều thời gian tinh chỉnh câu lệnh.