LLM tidak menceroboh kod anda – ia menyerahkan permintaan kepada anda, dan anda menjalankan fungsi tersebut. Fakta ringkas itu mematahkan mitos bahawa “model memanggil rutin Python saya secara ajaib” dan memaksa pembangun untuk berfikir semula tentang penyahpepijatan (debugging) dan keselamatan.

Gelung penghantaran (dispatch loop), langkah demi langkah

Apabila model bahasa (LLM) memerlukan alatan, ia mengikut urutan deterministik:

  1. Perancangan – model memutuskan bahawa tindakan diperlukan (cth., “bayar balik pembayaran”).
  2. Menjana permintaan – ia menghasilkan teks berstruktur—biasanya JSON—yang menamakan alatan dan membekalkan hujah (arguments).
  3. Parsing – aplikasi anda atau rangka kerja (framework) sokongan membaca teks tersebut.
  4. Padanan – rangka kerja mencari nama tersebut dalam daftar fungsi sebenar yang anda dedahkan.
  5. Pengesahan – ia menyemak sama ada hujah sepadan dengan skema fungsi dan sama ada pemanggil diberi kuasa.
  6. Pelaksanaan – fungsi yang sepadan dijalankan dalam persekitaran anda, melakukan kerja tersebut.
  7. Pemulangan – keputusan dibungkus dan dihantar semula kepada model untuk penaakulan lanjut.

Anggaplah LLM sebagai perancang, rangka kerja sebagai penghantar (dispatcher), dan fungsi sebagai pekerja yang sebenarnya menggerakkan data atau wang.

Mengapa mitos “keajaiban” ini berterusan

Kebanyakan pembangun melihat satu baris output model yang kelihatan seperti panggilan fungsi dan menganggap model itu sendiri yang melakukan operasi tersebut. Istilah “tool calling” dalam dokumentasi penyedia kedengaran seolah-olah model sedang memanggil kod secara langsung.

Hakikatnya, model hanya menghasilkan teks yang menghuraikan satu panggilan. Proses anda yang melakukan kerja berat—pencarian, pemeriksaan jenis (type checking), penguatkuasaan kebenaran, dan pengendalian ralat.

Rangka kerja yang menyembunyikan kerumitan teknikal (plumbing)

Perpustakaan seperti PydanticAI dan LangChain mengabstraksikan gelung tersebut supaya anda boleh fokus pada logik perniagaan. Ia secara automatik:

  • Mengesahkan hujah terhadap skema (cth., model Pydantic).
  • Menguatkuasakan kebenaran, memastikan pengguna boleh mencetuskan alatan tersebut.
  • Cuba semula jika gagal, kembali ke model apabila alatan mengembalikan ralat.
  • Melindungi daripada gelung tanpa kawalan, mengehadkan panggilan alatan berturut-turut.
  • Mengekalkan keadaan perbualan, menyatukan hasil alatan ke dalam dialog.

Walaupun dengan pembantu ini, coraknya tetap sama: model tidak pernah melaksanakan kod.

Sokongan panggilan alatan asli (native) daripada penyedia

Sesetengah penyedia menyediakan antara muka panggilan alatan “asli” yang menyeragamkan definisi alatan dan format permintaan. Ia memudahkan integrasi tetapi tidak menghapuskan langkah penghantaran (dispatch). Anda masih perlu menulis (atau mengimport) kod yang sebenarnya menjalankan operasi yang diminta.

Penyahpepijatan menjadi lebih mudah apabila anda menamakan semula masalah tersebut

Daripada menyalahkan “ejen yang keliru,” katakan masalahnya ialah “respons model tidak mengandungi sebarang panggilan alatan.” Perbezaan ini penting:

  • Tiada panggilan alatan – model menjawab secara terus atau gagal menjana permintaan dengan format yang betul.
  • Permintaan tidak sah (malformed) – JSON salah dari segi sintaks atau kekurangan medan yang diperlukan, jadi penghantar menolaknya.
  • Kegagalan pengesahan – hujah tidak sepadan dengan skema, mencetuskan ralat sebelum pelaksanaan.

Pengkategorian kegagalan membolehkan anda merekodkan setiap peringkat gelung dan mengenal pasti di mana sesuatu perkara tersasar.

Tip praktikal untuk saluran paip (pipeline) yang boleh dipercayai

  • Anggap output model sebagai input yang tidak dipercayai. Jalankan setiap permintaan melalui pengesahan deterministik sebelum memanggil sebarang kod yang mempunyai kesan sampingan (side-effecting code).
  • Log permintaan mentah dan hasil setiap langkah pengesahan. Ini mewujudkan jejak yang boleh dimainkan semula apabila sesuatu berlaku.
  • Tetapkan had yang jelas pada panggilan alatan berturut-turut; gelung tanpa kawalan boleh menghabiskan sumber atau mencapai had kadar (rate limits).
  • Bungkus setiap fungsi dalam blok try/except yang mengembalikan objek ralat berstruktur yang boleh difahami oleh model, untuk mencetuskan cubaan semula atau sandaran (fallback) yang lancar.
  • Asingkan semakan kebenaran daripada logik perniagaan. Sahkan hak pemanggil sebelum fungsi dijalankan, terutamanya untuk tindakan istimewa seperti “padam pengguna.”
  • Gunakan definisi berasaskan skema (cth., model Pydantic) supaya rangka kerja boleh menjana skema JSON secara automatik yang mesti diikuti oleh model.

Apa yang perlu diperhatikan seterusnya

Apabila penyedia memperhalusi API panggilan alatan asli, jangkakan kontrak yang lebih ketat di sekeliling format permintaan dan kod ralat yang lebih kaya. Perubahan tersebut akan memudahkan pengesahan dan membolehkan pembangun membina pagar keselamatan yang lebih ketat. Perhatikan kemas kini perpustakaan—banyak yang sedang menambah sokongan terbina dalam untuk ciri penyedia terbaru.

Rumusan

LLM ialah penjana teks yang canggih, bukan pelaksana. Kod anda kekal sebagai satu-satunya pihak berkuasa yang melaksanakan tindakan, dan 'dispatcher' yang anda bina (atau import) ialah penjaga pintu yang mengesahkan, memberi kuasa, dan menjalankan tindakan tersebut. Merangka semula aliran kerja ini menghapuskan mitos "magis", menajamkan proses penyahpepijatan, dan menguatkuasakan disiplin keselamatan yang diperlukan oleh setiap sistem pengeluaran.