Suara telah menjadi ciri yang dikejar-kejar oleh setiap platform ejen AI untuk dilancarkan. Langkah yang jelas adalah membina ia sebagai saluran berdiri sendiri, sesuatu yang berada di samping aplikasi web, alat CLI, atau bot Telegram anda. Ia terasa intuitif. Anda melihat suara, anda mencipta antara muka suara. Namun, naluri tersebut mewujudkan seni bina yang rapuh. Ia menggandakan kerja, merosakkan log anda, dan secara perlahan-lahan merosakkan konteks projek anda.

Di APC dan APX, kami memilih laluan yang berbeza. Suara bukanlah satu saluran. Ia adalah satu mod. Ia berada di atas sesuatu permukaan dan bukannya menggantikannya. Memahami perbezaan ini dengan betul adalah kunci untuk mengelakkan sistem daripada mengalami penyimpangan.

Abstraksi yang Salah

Apabila anda melayan suara sebagai saluran tersendiri, anda secara tersirat menganggap bahawa bercakap dengan ejen adalah perbualan yang secara asasnya berbeza daripada menaip kepadanya. Pasukan kejuruteraan bertindak balas dengan membahagikan kod sumber. Tiba-tiba wujud saluran CLI dan saluran voice-CLI yang berasingan. Wujud saluran web dan saluran voice-web yang selari. Setiap satu memerlukan variasi prompt, peraturan pemformatan, dan logik pengendalian konteks yang tersendiri.

Di sinilah kekacauan bermula. Penambahbaikan pada tingkah laku ejen kini perlu disalin ke pelbagai pohon prompt. Jika pasukan terlepas pandang satu permukaan, pengalaman pengguna akan terfragmentasi. Pengguna mendapat nada yang berbeza melalui teks dan personaliti yang sedikit berbeza melalui pertuturan. Lama-kelamaan, ketidakkonsistenan kecil ini terkumpul menjadi penyimpangan sistem. Lapisan konteks mudah alih tidak lagi menjadi mudah alih kerana ia perlu mengambil kira penyampaian vokal dalam satu cabang dan teks senyap dalam cabang yang lain. Abstraksi tersebut bocor, dan definisi projek anda yang dahulunya bersatu kini terurai menjadi koleksi penyelesaian sementara (hacks) khusus untuk saluran tertentu.

Memisahkan Konteks daripada Runtime

Untuk mengelakkan perkara ini, kami membahagikan tanggungjawab antara dua lapisan yang kekal terasing sepenuhnya.

APC memegang konteks projek. Ia mentakrifkan ejen, peraturan, dan kemahiran yang membentuk sesuatu projek. Anggap ia sebagai makna sistem yang stabil. Ia menjawab soalan struktur. Apa yang ejen ini tahu? Apa yang dibenarkan untuk dilakukan? Apakah alatan yang boleh dipanggil? APC harus kekal agnostik sepenuhnya tentang sama ada jawapan dipaparkan pada skrin, dihantar melalui API sembang, atau disalurkan melalui pembesar suara.

APX mengendalikan lapisan runtime. Ia menguruskan permukaan yang anda gunakan: CLI, aplikasi web, antara muka desktop, bot Telegram. Apabila pengguna menghantar permintaan, APX memilih di mana dan bagaimana untuk membentangkan respons tersebut. Keputusan sama ada untuk memformat jawapan bagi tujuan pembacaan atau mengoptimumkannya untuk pertuturan adalah urusan runtime. Ia milik APX, bukan APC.

Pengasingan ini bermakna projek yang ditakrifkan dalam APC kekal utuh tidak kira berapa banyak permukaan yang didedahkan oleh APX. Kontrak tidak berubah. Hanya lapisan persembahan yang berubah.

Bagaimana Mod Sebenarnya Berfungsi

Dalam pelaksanaan kami, permukaan seperti Telegram, CLI, dan aplikasi web adalah saluran. Saluran memberitahu anda di mana interaksi berlaku. Suara diletakkan sebagai satu mod melalui metadata saluran. Mod memberitahu anda bagaimana sesuatu respons harus bertindak.

Pembina prompt menghormati sempadan ini. Ia mengambil data daripada konteks projek dalam APC, kemudian memeriksa metadata saluran. Jika permukaan desktop sedang berjalan dalam mod suara, pembina tersebut akan menambah arahan khusus hanya pada ketika itu. Mungkin ia memberi isyarat kepada model untuk menggunakan ayat yang lebih pendek, tanda baca yang lebih jelas untuk sintesis, atau konvensyen nombor pertuturan. Jika permukaan desktop yang sama sedang berjalan dalam mod teks, arahan vokal tersebut tidak akan masuk ke dalam prompt.

Hasilnya ialah satu pohon prompt bagi setiap permukaan. Tiada cabang voice-desktop yang berasingan. Tiada varian whisper-web. Pengubah suai hanya digunakan apabila runtime memintanya, dan hanya pada saat terakhir yang diperlukan. Prompt teras kekal malar.

Apa Yang Anda Perolehi

Seni bina ini memberikan pulangan dalam tiga cara yang nyata.

Kos penyelenggaraan yang lebih rendah. Jika suara adalah salurannya sendiri, setiap permukaan memerlukan kembar. Anda perlu menyelenggara saluran CLI dan saluran voice-CLI, saluran Telegram dan saluran voice-Telegram, dan seterusnya. Setiap kali anda melaraskan prompt sistem, membaiki pepijat pemformatan, atau memperhalusi huraian kemahiran, anda perlu menyebarkan perubahan tersebut ke kedua-dua pohon. Jika terlepas satu, pengguna akan menyedari jurang tersebut. Dengan menggunakan mod, anda mengekalkan satu pohon prompt bagi setiap permukaan. Suara menjadi lapisan tambahan bersyarat dan bukannya persimpangan jalan, jadi beban kerja anda kekal linear apabila anda menambah cara baharu untuk berinteraksi.

Accurate logging. Channels record where an interaction happened. Modes record how the reply was delivered. A desktop interaction remains a desktop interaction whether the user read it or heard it. When your team traces a bug or reviews analytics, they do not have to reconcile "desktop-voice" against "desktop-text" as if they were different product surfaces. The channel identifier stays clean, and the mode flag sits neatly beside it in the metadata. Your logs stay honest, and debugging stays straightforward because location and behavior are not tangled together.

Clean project context. APC defines the contract. It should not care if a reply is spoken, whispered, or rendered in monospace font. Those are runtime concerns. By keeping voice formatting inside APX, we preserve APC's portability. You can lift an APC project definition and drop it into an entirely new runtime environment without dragging along voice-specific formatting assumptions or speech-optimization cruft. The boundary holds, and the project meaning remains stable.

Proof on the Desktop

Our own desktop path demonstrates this in daily use. Desktop is the surface. When a user enables speech, the system runs that same desktop surface in voice mode. Because voice lives in the mode layer, the desktop channel retains its full context and behavior. It does not become a different product with different rules. The prompt builder simply notices the flag and adds voice instructions only when necessary. When the user switches back to text, those instructions disappear entirely. The underlying project context never shifted. The desktop was always the desktop.

The Real Takeaway

The core idea is simple. APC describes stable project meaning. APX describes runtime execution. Voice is a modifier on a surface, not a replacement for one. Treat it that way, and your prompts stay small. Your logs stay clear. Your