Cara Membina AI Agent dengan OpenAI Assistants (Kini Responses API)
Turn this article into takeaways for your work.
Each assistant summarizes the article only for you and suggests best practices for your work.
Assistants API OpenAI membolehkan pembangun membina aplikasi gaya agent dengan thread perbualan yang kekal, retrieval fail, pelaksanaan kod, dan function calling, tanpa perlu menguruskan semua keadaan itu secara manual. Ia penting, dan untuk integrasi sedia ada ia masih berjalan hari ini. Namun OpenAI mengumumkan penamatannya pada 26 Ogos 2025, dengan tarikh penamatan penuh pada 26 Ogos 2026, dan telah mengarahkan semua pembangunan baharu ke Responses API dan Agents SDK. Jika anda memulakan projek baharu, bina di sana. Panduan ini merangkumi apa yang dilakukan oleh Assistants API, apa penggantinya, dan cara sebenar membina agent di atas alat semasa OpenAI hari ini.
Apa Itu Assistants API, dan Mengapa Ia Akan Ditamatkan
Dilancarkan pada persidangan pembangun OpenAI 2023, Assistants API memberi pembangun empat primitif teras: Assistant (agent yang dikonfigurasikan, dengan arahan dan alat), Thread (perbualan yang kekal), Run (satu pelaksanaan assistant terhadap sesuatu thread), dan Run Steps (tindakan individu yang diambil semasa satu run). Ia menggabungkan retrieval ke atas fail yang dimuat naik, code interpreter, dan function calling, yang buat seketika menjadikannya cara terpantas untuk menegakkan agent berkeadaan yang menggunakan alat tanpa membina sendiri saluran paip tersebut.
Masalahnya, menurut kata OpenAI sendiri, ialah kerumitan. Apabila syarikat itu melancarkan Responses API pada Mac 2025, ia menyatakan dengan jelas bahawa ia merancang membawa setiap ciri Assistants ke dalam API yang lebih ringkas dan menamatkan yang asal, dan ia menunaikannya: notis penamatan dihantar kepada pembangun pada 26 Ogos 2025, dengan pembuangan daripada API tepat setahun kemudian. Panduan migrasi OpenAI mengesahkan tiada fungsi yang hilang dalam peralihan ini, ciri-ciri disusun semula, bukan digugurkan.
Apa yang Menggantikannya: Responses API dan Agents SDK
Responses API bukan sekadar penamaan semula, ia model yang benar-benar lebih ringkas: hantar item input, terima item output terus, tanpa polling objek Run sehingga statusnya berubah. Empat konsep Assistants dipetakan kepada empat konsep Responses.
| Assistants API | Setara dalam Responses API | Apa yang berubah |
|---|---|---|
| Assistants | Prompts | Konfigurasi kini berada dalam dashboard dengan versi terbina dalam, dan bukan diurus sepenuhnya melalui panggilan API |
| Threads | Conversations | Diperluas untuk menyimpan lebih daripada mesej: panggilan alat, output, dan jenis item lain |
| Runs | Responses | Anda menghantar input dan menerima output terus; tiada gelung polling diperlukan |
| Run steps | Items | Objek umum yang merangkumi pelbagai data yang boleh terkandung dalam sesuatu respons |
Responses API juga menyediakan lima alat terbina dalam yang tidak perlu anda bina sendiri: web search, file search, code interpreter, computer use, dan sambungan pelayan MCP jauh. File search ialah pengganti langsung ciri retrieval Assistants API, corak penambatan dokumen yang sama seperti yang dibincangkan dalam RAG untuk AI agent dan, pada peringkat corak, corak RAG assistant.
Untuk apa-apa yang melangkaui satu agent, OpenAI turut menawarkan Agents SDK, pengganti sedia produksi kepada rangka kerja eksperimen "Swarm" terdahulunya. Jika Responses API memberi anda blok binaan, satu panggilan masuk, satu respons keluar, Agents SDK memberi anda orkestrasi di sekelilingnya: Agents (model ditambah arahan dan alat), Handoffs (membenarkan satu agent mewakilkan tugas kepada agent lain), dan Guardrails (mengesahkan apa yang masuk dan apa yang keluar). Rumusan OpenAI sendiri jelas: gunakan Responses API apabila anda mahu memiliki gelung agent itu sendiri, gunakan Agents SDK apabila anda mahu SDK menjalankan gelung itu untuk anda. Tambahan SDK pada 2026 termasuk integrasi Realtime API asli untuk agent suara dan sokongan pelayan Model Context Protocol kelas pertama, jadi mana-mana alat yang menyokong MCP menjadi keupayaan yang boleh disambungkan tanpa kod penyambung tersuai.
Panduan Binaan
- Tentukan siapa yang memiliki gelung. Untuk satu agent yang agak ringkas, panggil Responses API terus dan kendalikan kitaran input/output/function-call dalam kod anda sendiri. Untuk beberapa agent yang berkoordinasi, atau jika anda tidak mahu menulis gelung itu sendiri, mulakan dengan Agents SDK.
- Tulis arahan agent. Ini ialah blok Role dan Rules daripada cara membina AI agent, dinyatakan sebagai system prompt: apa yang dimiliki agent, apa yang tidak boleh dilakukannya sama sekali.
- Lampirkan alat terbina dalam mengikut keperluan. File search jika ia perlu menjawab daripada dokumen anda sendiri, web search jika ia memerlukan maklumat terkini, code interpreter untuk pengiraan, computer use hanya jika ia benar-benar perlu mengendalikan antara muka pengguna.
- Pasang alat function-calling tersuai untuk sistem anda sendiri. Takrifkan skema JSON bagi setiap fungsi (nama, parameter, penerangan); model meminta panggilan dengan argumen tertentu, kod aplikasi anda yang sebenarnya melaksanakannya terhadap CRM, pangkalan data, atau API anda, dan memulangkan hasilnya supaya model dapat menyambung penaakulannya. Ini ialah mekanik panggilan alat yang sama seperti yang dibincangkan secara mendalam dalam cara AI agent menggunakan alat.
- Gunakan Conversations untuk apa-apa yang perlu kekal merentas sesi, pengganti langsung Threads dalam Assistants.
- Tambah Handoffs jika kerja itu terbahagi dengan kemas kepada beberapa agent pakar, corak orkestrasi yang sama seperti yang dibincangkan dalam sistem berbilang agent.
- Tambah Guardrails untuk mengesahkan input dan output, dan tambah tracing (integrasi Sentry asli SDK, atau pengelogan anda sendiri) supaya anda dapat melihat dengan tepat alat mana yang dijalankan dan sebabnya sebelum anda mempercayai agent dengan volum sebenar.
- Deploy di belakang backend anda sendiri. Tiada hos visual di sini; anda memiliki pelayan, pengesahan, dan logik cuba semula.
Pelaksanaan bergerak daripada pemilikan gelung dan arahan, melalui alat, keadaan yang kekal, handoff, guardrail, dan tracing.
Contoh Kerja: AI Knowledge Base Agent
Knowledge base agent sesuai secara semula jadi untuk Responses API, kerana ia bersandar terus pada alat terbina dalam file search dan bukan kod retrieval tersuai.
Seorang pengguna bertanya soalan. Arahan agent menghadkannya untuk menjawab hanya daripada set dokumen syarikat yang dimuat naik dan diindeks, disambungkan melalui alat file search. Ia mencari, menemui petikan yang berkaitan, dan menjawab dengan rujukan kepada dokumen sumber dan bukan dakwaan semata-mata. Jika file search tidak memulangkan padanan yang meyakinkan, arahan menyuruhnya menyatakannya secara jelas dan bukan meneka, dan alat function-calling tersuai membolehkannya melakukan eskalasi soalan itu ke baris gilir manusia apabila ia tidak dapat menjawab.
Itulah struktur peraturan dan guardrail yang sama yang dinyatakan sepenuhnya dalam pelan pembinaan AI Knowledge Base Agent, hadkan kepada sumber yang diluluskan, nyatakan dari mana jawapan datang, lakukan eskalasi dan jangan meneka. Membinanya di atas Responses API kebanyakannya bermakna memasang alat file search dan fungsi eskalasi, kemudian membiarkan penaakulan model sendiri memutuskan bila setiap satu terpakai.
Kos dan Had
API OpenAI membilkan mengikut token (input dan output dihargai berasingan, berbeza mengikut model), dan setiap alat terbina dalam mempunyai meternya sendiri: web search dan file search mengenakan caj setiap panggilan atau mengikut volum dokumen yang disimpan, code interpreter dan computer use mengenakan caj untuk masa pengiraan yang dijalankan. Kadar berubah cukup kerap sehingga wajar menyemak halaman harga OpenAI sendiri secara terus dan bukan menganggap sebarang angka di sini sebagai terkini. Yang penting untuk perancangan ialah bentuk kosnya, berasaskan penggunaan merentas beberapa meter berasingan, bukan satu harga tetap, jadi baca jumlah kos pemilikan AI sebelum anda menganggarkan agent yang berat dan sentiasa aktif berdasarkan bil pilot yang ringan.
Had yang lebih besar bagi kebanyakan pasukan bukan kos, tetapi hakikat bahawa laluan ini tidak memberi anda pembina visual langsung. Setiap bahagian yang n8n, Make, atau Lindy kendalikan untuk anda (hosting, cuba semula, antara muka untuk bukan jurutera melaraskan agent) menjadi tugas pasukan anda di sini. Itulah pertukaran yang wajar dinyatakan dengan jelas: anda mendapat akses langsung kepada model dan alat OpenAI dengan abstraksi paling sedikit antara anda dengan API, sebagai ganti memiliki keseluruhan runtime sendiri. Dan jika anda mempunyai integrasi Assistants API sedia ada, migrasi bukan pilihan. Ia mesti dilakukan sebelum 26 Ogos 2026, menggunakan pemetaan di atas, atau integrasi itu berhenti berfungsi sepenuhnya.
Bila Memilih Ini Berbanding Alternatif
| Jika anda mahu... | Pilih |
|---|---|
| Kawalan kod penuh terus pada model OpenAI, abstraksi minimum, pasukan anda sudah menulis perisian | Responses API dan Agents SDK OpenAI |
| Laluan terpantas ke agent yang berfungsi tanpa sebarang kod | Lindy |
| Katalog aplikasi pra-bina yang paling luas dengan pembina visual | Make |
| Hos sendiri dengan kanvas visual serta jalan keluar ke kod | n8n |
Ini bukan pilihan yang benar-benar saling eksklusif. n8n, Make, dan Lindy semuanya boleh memanggil model OpenAI sebagai enjin penaakulan di sebalik agent yang dibina di platform mereka; anda memilih lapisan orkestrasi, bukan semestinya memilih untuk meninggalkan model OpenAI itu sendiri. Bina terus di atas Responses API dan Agents SDK apabila pasukan anda sudah menghantar kod dan mahukan lapisan paling sedikit antara aplikasi anda dengan model. Pilih platform visual apabila anda sanggup menukar sebahagian kawalan peringkat rendah dengan lelaran yang lebih pantas dan pembina yang boleh disentuh oleh bukan jurutera. Desakan di sebalik pilihan itu nyata: Gartner meramalkan 40% aplikasi enterprise akan menampilkan AI agent khusus tugas menjelang akhir 2026, meningkat daripada kurang 5% pada 2025, iaitu jenis lengkung penerimaan yang menjadikan pembinaan di atas platform yang sedang dihentikan oleh OpenAI sebagai pertaruhan yang salah sekarang.
Fakta Utama
- OpenAI mengumumkan penamatan Assistants API pada 26 Ogos 2025, dengan tarikh penamatan penuh pada 26 Ogos 2026. Projek baharu patut dibina di atas Responses API.
- Responses API menggantikan empat konsep Assistants: Assistants menjadi Prompts, Threads menjadi Conversations, Runs menjadi Responses, dan Run steps menjadi Items.
- Responses API menyediakan lima alat terbina dalam: web search, file search, code interpreter, computer use, dan sambungan pelayan MCP jauh.
- Agents SDK, pengganti produksi kepada rangka kerja eksperimen Swarm OpenAI, menambah Agents, Handoffs, dan Guardrails untuk menyelaraskan lebih daripada satu agent.
- Gartner meramalkan 40% aplikasi enterprise akan menampilkan AI agent khusus tugas menjelang akhir 2026, meningkat daripada kurang 5% pada 2025.
Soalan Lazim tentang Membina AI Agent dengan OpenAI Assistants
Adakah Assistants API OpenAI masih boleh digunakan pada 2026?
Ya, sehingga tarikh penamatannya pada 26 Ogos 2026, selepas itu ia dibuang sepenuhnya daripada API. Integrasi sedia ada terus berjalan sehingga itu, tetapi OpenAI telah mengarahkan semua pembangunan baharu ke Responses API dan Agents SDK sejak mengumumkan penamatan pada 26 Ogos 2025.
Apakah yang menggantikan Assistants API?
Responses API, yang menyatukan dan memudahkan keupayaan yang sama (keadaan kekal, retrieval, pelaksanaan kod, function calling) ke dalam model di mana anda menghantar item input dan menerima item output terus, tanpa polling objek Run. Untuk menyelaraskan beberapa agent, Agents SDK OpenAI berada di atas Responses API dan menambah handoff serta guardrail.
Adakah saya perlu memigrasikan integrasi Assistants API sedia ada saya?
Ya, sebelum 26 Ogos 2026. Panduan migrasi OpenAI memetakan setiap konsep Assistants kepada setara dalam Responses API (Assistants kepada Prompts, Threads kepada Conversations, Runs kepada Responses, Run steps kepada Items), dan mengesahkan tiada fungsi yang hilang, hanya disusun semula.
Apakah perbezaan antara Responses API dengan Agents SDK?
Responses API ialah primitif asas, anda menghantar permintaan dan menerima respons, dan anda memiliki gelung memanggilnya berulang kali, melaksanakan panggilan fungsi, dan menyuap hasilnya semula. Agents SDK dibina di atasnya dan menjalankan gelung itu untuk anda, dengan menambah handoff berbilang agent serta guardrail input/output, berguna apabila logik satu agent sudah cukup kompleks untuk memerlukan struktur sedemikian.
Bolehkah saya membina AI agent di atas model OpenAI tanpa menulis kod?
Tidak secara terus melalui API OpenAI sendiri, kerana tiada pembina visual. Platform seperti n8n, Make, dan Lindy boleh memanggil model OpenAI sebagai enjin penaakulan di sebalik agent yang anda bina secara visual, iaitu laluan yang lebih mudah diakses jika pasukan anda tidak mahu menulis dan menghoskan kod orkestrasi sendiri.
Ke Mana Seterusnya
Jika pasukan anda sudah menulis perisian dan mahukan lapisan paling sedikit antara kod anda dengan model OpenAI, Responses API dan Agents SDK ialah titik permulaan yang tepat, cuma bina di sana dan bukan di atas API yang sedang dihentikan. Jika anda lebih suka membina secara visual, lihat cara membina AI agent dengan n8n, cara membina AI agent dengan Make, atau cara membina AI agent dengan Lindy bergantung pada sejauh mana anda memerlukan kawalan berbanding kepantasan. Rumusan alat dev dan panduan cara memilih platform chatbot AI ialah persinggahan seterusnya yang berguna jika anda masih membandingkan alat OpenAI sendiri dengan platform yang dihoskan.
