Giọng nói đã trở thành tính năng mà mọi nền tảng tác nhân AI đều vội vã ra mắt. Một bước đi hiển nhiên là xây dựng nó như một kênh độc lập, một thứ gì đó nằm cạnh ứng dụng web, công cụ CLI hoặc bot Telegram của bạn. Điều này nghe có vẻ trực quan. Bạn thấy giọng nói, bạn tạo ra một giao diện giọng nói. Nhưng bản năng đó tạo ra một kiến trúc mong manh. Nó làm trùng lặp công việc, làm sai lệch nhật ký (logs) và dần dần làm biến dạng ngữ cảnh dự án của bạn.

Tại APC và APX, chúng tôi đã chọn một con đường khác. Giọng nói không phải là một kênh. Nó là một chế độ (mode). Nó nằm trên một bề mặt (surface) thay vì thay thế bề mặt đó. Việc phân biệt đúng đắn điều này chính là yếu tố giúp hệ thống không bị rời rạc.

Sự trừu tượng hóa sai lầm

Khi bạn coi giọng nói là một kênh riêng biệt, bạn ngầm định rằng việc nói chuyện với một tác nhân về cơ bản là một cuộc hội thoại khác với việc gõ văn bản cho nó. Các đội ngũ kỹ thuật sẽ phản ứng bằng cách chia tách mã nguồn. Đột nhiên, có một kênh CLI và một kênh voice-CLI riêng biệt. Có một kênh web và một kênh voice-web song song. Mỗi kênh lại đòi hỏi các biến thể prompt, quy tắc định dạng và logic xử lý ngữ cảnh riêng.

Đây là nơi sự hỗn loạn bắt đầu. Một thay đổi nhỏ trong hành vi của tác nhân giờ đây phải được sao chép qua nhiều cây prompt khác nhau. Nếu đội ngũ quên mất một bề mặt, trải nghiệm sẽ bị phân mảnh. Người dùng nhận được một tông giọng qua văn bản và một tính cách hơi khác một chút qua lời nói. Theo thời gian, những sự thiếu nhất quán nhỏ này tích tụ thành sự sai lệch hệ thống (system drift). Lớp ngữ cảnh có khả năng di động (portable context layer) không còn tính di động nữa vì nó phải tính đến cả cách truyền đạt bằng giọng nói ở một nhánh và văn bản im lặng ở một nhánh khác. Sự trừu tượng hóa bị rò rỉ, và định nghĩa dự án vốn thống nhất của bạn bị xé lẻ thành một tập hợp các bản vá lỗi dành riêng cho từng kênh.

Tách biệt Ngữ cảnh khỏi Runtime

Để ngăn chặn điều này, chúng tôi tách biệt trách nhiệm giữa hai lớp luôn giữ khoảng cách nghiêm ngặt với nhau.

APC nắm giữ ngữ cảnh dự án. Nó định nghĩa các tác nhân, các quy tắc và các kỹ năng tạo nên một dự án. Hãy coi nó như ý nghĩa ổn định của hệ thống. Nó trả lời các câu hỏi về cấu trúc: Tác nhân này biết gì? Nó được phép làm gì? Nó có thể gọi những công cụ nào? APC nên hoàn toàn không phụ thuộc vào việc một câu trả lời được hiển thị trên màn hình, được gửi qua API chat hay được phát qua loa.

APX xử lý lớp runtime (thực thi). Nó quản lý các bề mặt mà bạn thực sự chạm vào: CLI, ứng dụng web, giao diện desktop, bot Telegram. Khi người dùng gửi một yêu cầu, APX sẽ chọn nơi và cách thức để trình bày phản hồi. Việc quyết định xem nên định dạng câu trả lời để đọc hay tối ưu hóa để nói là một vấn đề thuộc về runtime. Nó thuộc về APX, không phải APC.

Sự phân tách này có nghĩa là một dự án được định nghĩa trong APC sẽ vẫn nguyên vẹn bất kể APX cung cấp bao nhiêu bề mặt. Bản hợp đồng không thay đổi. Chỉ có lớp trình diễn là thay đổi.

Cách các Chế độ thực sự hoạt động

Trong triển khai của chúng tôi, các bề mặt như Telegram, CLI và ứng dụng web là các kênh. Một kênh cho bạn biết tương tác đã xảy ra ở đâu. Giọng nói được lồng ghép thông qua siêu dữ liệu (metadata) của kênh dưới dạng một chế độ. Một chế độ cho bạn biết một câu trả lời nên hoạt động như thế nào.

Trình xây dựng prompt (prompt builder) tôn trọng ranh giới này. Nó lấy dữ liệu từ ngữ cảnh dự án trong APC, sau đó kiểm tra siêu dữ liệu của kênh. Nếu bề mặt desktop đang chạy ở chế độ giọng nói, trình xây dựng sẽ chỉ thêm các hướng dẫn mục tiêu vào đúng thời điểm đó. Có thể nó sẽ điều hướng mô hình hướng tới các câu ngắn hơn, dấu câu rõ ràng hơn để tổng hợp giọng nói, hoặc các quy ước về số khi nói. Nếu cùng bề mặt desktop đó đang chạy ở chế độ văn bản, những hướng dẫn giọng nói đó sẽ không bao giờ đi vào prompt.

Kết quả là một cây prompt duy nhất cho mỗi bề mặt. Không có nhánh voice-desktop riêng biệt. Không có biến thể whisper-web. Bộ sửa đổi chỉ áp dụng khi runtime yêu cầu, và chỉ vào thời điểm cuối cùng cần thiết. Prompt cốt lõi luôn giữ nguyên.

Những gì bạn nhận được

Kiến trúc này mang lại hiệu quả theo ba cách cụ thể.

Chi phí bảo trì thấp hơn. Nếu giọng nói là một kênh riêng, mọi bề mặt sẽ cần một "bản sao song sinh". Bạn sẽ phải duy trì một kênh CLI và một kênh voice-CLI, một kênh Telegram và một kênh voice-Telegram, v.v. Mỗi khi bạn điều chỉnh một system prompt, sửa một lỗi định dạng hoặc tinh chỉnh mô tả kỹ năng, bạn sẽ phải lan truyền thay đổi đó qua cả hai cây prompt. Nếu bỏ lỡ một cái, người dùng sẽ nhận ra sự khác biệt. Bằng cách sử dụng một chế độ, bạn chỉ cần duy trì một cây prompt cho mỗi bề mặt. Giọng nói trở thành một lớp phủ có điều kiện thay vì là một ngã rẽ, vì vậy khối lượng công việc của bạn vẫn duy trì ở mức tuyến tính khi bạn thêm các cách tương tác mới.

Ghi nhật ký chính xác. Các kênh ghi lại nơi một tương tác diễn ra. Các chế độ ghi lại cách câu trả lời được truyền tải. Một tương tác trên desktop vẫn là một tương tác desktop cho dù người dùng đọc hay nghe nó. Khi đội ngũ của bạn truy vết lỗi hoặc xem xét phân tích, họ không phải đối chiếu giữa "desktop-voice" với "desktop-text" như thể chúng là các giao diện sản phẩm khác nhau. Định danh kênh luôn sạch sẽ, và cờ chế độ nằm gọn gàng bên cạnh nó trong siêu dữ liệu. Nhật ký của bạn luôn trung thực, và việc gỡ lỗi luôn đơn giản vì vị trí và hành vi không bị trộn lẫn với nhau.

Ngữ cảnh dự án rõ ràng. APC định nghĩa các quy ước. Nó không nên quan tâm liệu một câu trả lời được nói ra, thì thầm, hay được hiển thị bằng phông chữ monospace. Đó là những vấn đề thuộc về runtime. Bằng cách giữ định dạng giọng nói bên trong APX, chúng ta bảo toàn tính di động của APC. Bạn có thể lấy một định nghĩa dự án APC và đưa nó vào một môi trường runtime hoàn toàn mới mà không phải kéo theo các giả định định dạng đặc thù cho giọng nói hay các thành phần thừa thãi để tối ưu hóa giọng nói. Ranh giới được giữ vững, và ý nghĩa của dự án vẫn ổn định.

Minh chứng trên Desktop

Luồng desktop của chính chúng tôi chứng minh điều này trong quá trình sử dụng hàng ngày. Desktop là giao diện. Khi người dùng bật tính năng giọng nói, hệ thống sẽ chạy chính giao diện desktop đó ở chế độ giọng nói. Vì giọng nói nằm ở lớp chế độ, kênh desktop vẫn giữ nguyên đầy đủ ngữ cảnh và hành vi của nó. Nó không trở thành một sản phẩm khác với các quy tắc khác. Trình xây dựng prompt chỉ đơn giản là nhận biết cờ và chỉ thêm các hướng dẫn giọng nói khi cần thiết. Khi người dùng chuyển lại sang văn bản, các hướng dẫn đó sẽ biến mất hoàn toàn. Ngữ cảnh dự án bên dưới chưa bao giờ thay đổi. Desktop vẫn luôn là desktop.

Bài học cốt lõi

Ý tưởng cốt lõi rất đơn giản. APC mô tả ý nghĩa dự án ổn định. APX mô tả việc thực thi runtime. Giọng nói là một yếu tố điều chỉnh trên một giao diện, chứ không phải là sự thay thế cho giao diện đó. Hãy xử lý theo cách đó, và các prompt của bạn sẽ luôn gọn nhẹ. Nhật ký của bạn sẽ luôn rõ ràng. Của bạn