Dari Menunggu Instruksi hingga Proaktif Mencari Tugas: Memahami 5 Mekanisme Utama Arsitektur Berbasis Peristiwa DeepSeek Super-agent

Catatan penulis: Artikel ini mengulas mekanisme inti arsitektur berbasis peristiwa DeepSeek Super-agent, membedakan fitur prototipe yang sudah dirilis sebagai sumber terbuka, contoh internal DeepSeek, dan rancangan arsitektur masa depan. Kita juga akan membahas nilai produk dan pertimbangan teknis dari Agent yang proaktif.

Bayangkan sebuah grup chat tim pengembang. Seseorang berkata sambil lalu, “Halaman login tidak bisa dibuka lagi di Safari.” Tidak ada yang me-mention bot atau membuat Issue. Beberapa saat kemudian, grup menerima notifikasi singkat: masalah berhasil direproduksi, penyebabnya sudah ditemukan, dan PR perbaikan siap ditinjau. Menurut artikel teknis resmi DeepSeek, praktik “mereproduksi dan memperbaiki masalah secara diam-diam” ini sudah menjadi salah satu strategi kerja di grup chat internal DeepSeek Harness.

Ini bukan kisah tentang “AI yang mulai bertindak sesuka hati”. Perubahan utama pada DeepSeek Super-agent adalah kemampuannya untuk terus memantau peristiwa eksternal, mengenali pekerjaan berdasarkan izin dan aturan yang jelas, menyiapkan solusi lebih awal, lalu menyampaikan hasil pada waktu yang tepat. Kontrol izin dan eksekusi proaktif dirancang bersamaan; keduanya sama-sama penting.

Yang akan Anda pelajari: Setelah membaca artikel ini, Anda akan memahami 5 mekanisme utama arsitektur berbasis peristiwa Super-agent, membedakan fitur yang sudah diterapkan dalam prototipe sumber terbuka dari contoh internal dan rancangan arsitektur, serta mengetahui cara menerapkan pendekatan ini untuk merancang Agent proaktif yang minim gangguan dan tetap terkendali.

Ringkasan Informasi Utama DeepSeek Super-agent

Sebelum membahas detailnya, mari lihat informasi publik tentang Super-agent dalam tabel berikut. Perhatikan perbedaan antara yang “sudah diimplementasikan” dan yang masih berupa “rancangan”. Ini penting untuk memahami proyek tersebut.

Apa itu arsitektur berbasis peristiwa DeepSeek Super-agent

Agent percakapan tradisional bekerja dalam satu siklus: pengguna memberi instruksi, Agent menjalankannya, mengembalikan hasil, lalu menunggu instruksi berikutnya. Sepintar apa pun Agent, pekerjaannya selalu dimulai dari percakapan yang dibuka pengguna. Pengguna harus menemukan masalah, menjelaskannya dengan jelas, dan ingat untuk kembali memeriksa hasilnya.

DeepSeek Super-agent membalik alur tersebut. Sistem terus menerima peristiwa dari lingkungan, menilai apakah ada pekerjaan yang perlu ditangani, membuat tugas sesuai izin yang diberikan, menjalankannya di latar belakang, lalu memberi tahu manusia pada waktu yang tepat. Dengan kata lain, lingkungan kerja itu sendiri menjadi sumber masukan bagi Agent, sehingga jendela percakapan bukan lagi satu-satunya pintu masuk.

Peran Trigger dalam Super-agent

DeepSeek menyebut semua peristiwa dari lingkungan eksternal sebagai Trigger. Pesan di grup percakapan, Issue baru, atau kegagalan build CI semuanya bisa menjadi Trigger. Yang penting, Trigger hanyalah “petunjuk”, bukan “tugas”. Keputusan untuk bertindak ditentukan oleh tahap penyaringan, penilaian, dan pemberian izin setelahnya.

Cara Super-agent Memfilter Peristiwa: Gate Program dan LLM Assessment

Lingkungan kerja nyata menghasilkan banyak aktivitas yang tidak relevan. Grup developer bisa dipenuhi obrolan santai, emoji, dan pesan berulang setiap hari. Jika semuanya diserahkan ke Model Bahasa Besar untuk dinilai, biaya token dan latensi respons akan cepat meningkat. Solusi DeepSeek adalah penyaringan dua tahap: aturan deterministik yang murah menyaring sebagian besar peristiwa yang tidak relevan, lalu sejumlah kecil kandidat diserahkan ke model untuk penilaian semantik.

Ambil contoh pesan “Halaman login tidak bisa dibuka lagi di Safari”: jika berasal dari utas diskusi proyek yang diizinkan, model mungkin mengenalinya sebagai petunjuk adanya gangguan. Jika hanya obrolan yang tidak relevan, sistem mungkin tidak mengambil tindakan. Struktur dua tahap ini menggabungkan aturan berbiaya rendah dengan pemahaman semantik yang lebih mahal. Kombinasi ini menjadi kunci bagi Agent berbasis peristiwa untuk mengendalikan biaya.

Pada diagram di atas, tahap penilaian semantik dan pelaksanaan tugas sama-sama bergantung pada API model. Saat mereplikasi arsitektur serupa, developer dapat menggunakan antarmuka yang kompatibel dengan OpenAI, seperti APIYI apiyi.com, untuk mengakses berbagai model secara terpadu. Dengan begitu, konfigurasi dan perbandingan model pada setiap tahap menjadi lebih mudah.

Explicit dan Inferred: Perbedaan antara Permintaan Eksplisit dan Tugas yang Disimpulkan

Dokumentasi otorisasi resmi DeepSeek membagi tugas menjadi dua jenis. Explicit adalah permintaan yang diotorisasi secara eksplisit, misalnya ketika developer yang berwenang langsung meminta Agent memperbaiki bug dalam sebuah Issue. Inferred adalah tugas yang disimpulkan, misalnya ketika seseorang menyebutkan dalam diskusi bahwa “belakangan ini build terkadang gagal”. Tidak ada permintaan resmi untuk memperbaikinya, tetapi sistem menilai ada petunjuk yang layak diselidiki.

Hal terpenting: menyimpulkan adanya tugas tidak berarti sistem boleh langsung mengerjakannya. Tugas Inferred tetap harus mengikuti aturan penerimaan, cakupan pelaksanaan, dan persyaratan persetujuan organisasi. Perbedaan ini memastikan bahwa “menemukan masalah secara proaktif” tidak berubah menjadi “bertindak tanpa izin”.

Tiga Mode Penerimaan Tugas Super-agent: off, observe, auto

Dokumentasi otorisasi sumber terbuka menyediakan tiga mode untuk menangani tugas yang disimpulkan:

Nilai default-nya adalah observe. Artinya, saat prototipe publik pertama kali dipasang, sistem tidak akan langsung bekerja hanya karena ada pesan diskusi biasa. Pihak resmi menyarankan untuk meninjau catatan penilaian dalam mode observe sebelum memutuskan apakah akan mengaktifkan auto. Permintaan yang diotorisasi secara eksplisit tetap ditangani sesuai aturan yang berlaku di setiap mode. Pengguna selalu memegang kendali atas “sakelar” ini—itulah dasar agar Agent proaktif dapat dipercaya.

Mandate: pesan bisa menjadi input, tetapi tidak dapat mengubah otorisasi

DeepSeek menggunakan Mandate untuk merepresentasikan otorisasi tugas, termasuk sumber tugas, tingkat dan cakupan otorisasi, serta versi kebijakan. Misalnya, developer memberi otorisasi kepada Agent untuk memperbaiki sebuah Issue. Setelah itu, seseorang menulis di komentar PR, “Sekalian migrasikan seluruh database.” Komentar ini mungkin masuk ke konteks Worker, tetapi otorisasi awal tidak otomatis meluas hingga mencakup migrasi database; permintaan di luar cakupan perlu dinilai ulang.

Prinsip yang ditekankan DeepSeek: pesan, komentar, atau dokumen yang dikutip dapat menjadi input tugas, tetapi tidak dapat langsung mengubah aturan otorisasi yang mendasarinya. Bagi sistem yang terus “mendengarkan” konten eksternal, ini adalah salah satu pertahanan terpenting terhadap Prompt Injection dan pelampauan wewenang.

Cara Super-agent bekerja secara proaktif: eksekusi spekulatif, tugas asinkron, dan minim gangguan

Penyaringan dan otorisasi menjawab pertanyaan “perlukah ini dilakukan?”. Pertanyaan berikutnya adalah “bagaimana mengerjakannya tanpa membuang waktu orang?”. DeepSeek menawarkan tiga arah desain.

Eksekusi spekulatif: siapkan dulu, tunggu konfirmasi

DeepSeek meminjam konsep Speculative Execution (eksekusi spekulatif) dari arsitektur komputer: memulai pekerjaan persiapan berisiko rendah sebelum diketahui apakah hasilnya akan digunakan.

• Skenario asisten pribadi: Setelah menerima undangan rapat, Agent dapat memeriksa jadwal, mengumpulkan informasi latar belakang rapat, mengecek benturan waktu, dan menyusun draf balasan. Namun, pengiriman email mungkin tetap memerlukan konfirmasi pengguna.
• Skenario pengembangan: Saat tim mendiskusikan sebuah Bug, Agent dapat memeriksa log, mencoba mereproduksinya, menemukan bagian kode terkait, dan menyiapkan kandidat patch, lalu menyerahkan hasilnya setelah memenuhi aturan otorisasi.

Konsekuensinya, daya komputasi mungkin terpakai untuk pekerjaan yang pada akhirnya tidak digunakan. Menurut DeepSeek, eksekusi spekulatif baru bernilai jika penghematan waktu tunggu dan upaya manusia lebih besar daripada biaya komputasi tambahannya. Ini adalah pertimbangan teknis; tidak semua tugas layak dikerjakan lebih awal.

ReAct Loop asinkron: tugas latar belakang tidak menghambat interaksi

Dalam eksekusi sinkron tradisional, setelah Agent menjalankan perintah yang memakan waktu, ia harus menunggu respons tool sebelum dapat menangani pesan baru. Desain asinkron yang diajukan DeepSeek bekerja berbeda: setelah tugas dimulai, sistem langsung mengembalikan status Started. Eksekusi di latar belakang tidak menghalangi interaksi berikutnya, dan hasilnya masuk kembali ke sistem sebagai peristiwa baru. Pengguna dapat mengajukan pertanyaan lain saat tugas berjalan, dan sistem juga dapat menghentikan pekerjaan latar belakang yang tidak lagi diperlukan.

Ada batasan yang perlu diperhatikan: DeepSeek menyatakan bahwa mekanisme tugas asinkron ini sudah diterapkan di DeepSeek Harness, tetapi belum diaktifkan secara default. Prototipe publik memiliki mekanisme Worker latar belakang sendiri, tetapi rancangan arsitektur asinkron secara keseluruhan tidak boleh dianggap sebagai fitur default.

Minim gangguan: proaktif bukan berarti harus selalu terlihat

Dokumen filosofi produk DeepSeek menyarankan agar konsumsi perhatian manusia ditekan seminimal mungkin sambil menghasilkan nilai guna sebanyak mungkin. Penerapannya antara lain: tidak melaporkan setiap pemanggilan tool, tidak membanjiri grup chat dengan pesan, tidak menampilkan seluruh proses pemikiran antara, memprioritaskan komunikasi saat keputusan atau penerimaan hasil diperlukan, dan tidak mengirim pesan yang manfaatnya terbatas.

Saluran output juga dibedakan. Aplikasi pesan instan menggunakan notifikasi singkat, sedangkan GitHub, email, dan dokumen menggunakan penyampaian terstruktur yang mencakup latar belakang masalah, penjelasan perubahan, dan hasil verifikasi. Dari sudut pandang produk, proaktivitas dan frekuensi notifikasi adalah dua metrik yang berbeda. Agent yang sering melapor belum tentu merupakan Agent yang berguna.

Bukti nyata Super-agent: kasus internal dan pengujian komunitas

Untuk menilai arsitektur baru, kita perlu memisahkan “potensi” dari “kondisi saat ini”. Ada dua jenis bukti yang tersedia, masing-masing dengan tingkat kepercayaan dan makna yang berbeda.

Kasus internal DeepSeek menunjukkan potensi arsitekturnya. Dalam grup obrolan internal DeepSeek Harness, saat ada laporan masalah, Agent menerima pesan, menilai apakah masalah tersebut layak diselidiki, lalu mencoba mereproduksinya dan mencari cara memperbaikinya di latar belakang. Jika masalah terkonfirmasi dan ada solusi sederhana, Agent menyiapkan atau mengirim PR. Jika tidak menemukan hasil yang berguna, Agent tidak akan mengganggu tim. Ini adalah cara kerja internal yang diungkapkan secara resmi, bukan hasil verifikasi independen pihak ketiga terhadap prototipe publik dengan konfigurasi default.

Pengujian komunitas GitHub menunjukkan kondisi prototipe saat ini. Pada 1 November 2026, seorang pengguna melaporkan bahwa ia berhasil menerapkan prototipe sumber terbuka di lingkungan Ubuntu sesuai SETUP.md. Sebuah permintaan Issue berhasil masuk ke alur pemrosesan dan akhirnya menghasilkan Pull Request. Namun, ia juga menemui beberapa kendala: notifikasi GitHub tidak terkirim, permintaan pekerjaan tidak diterima meskipun status sistem terlihat normal, pengaturan pemantauan Issue dan komentar pada Source perlu disesuaikan, serta masalah kompatibilitas akibat bahasa sistem dan konfigurasi akun GitHub.

Laporan ini membuktikan bahwa alur kerja “dari peristiwa menjadi tugas” memang bisa berjalan. Namun, itu belum cukup untuk menyimpulkan bahwa proyek ini sudah mampu menemukan Bug secara otomatis dan andal sepanjang waktu. Berhasil menghasilkan PR juga tidak berarti perubahannya sudah lolos peninjauan manusia dan digabungkan.

Membangun lapisan penilaian Agent berbasis peristiwa dengan API model

Jika ingin menerapkan pendekatan Super-agent, lapisan yang paling mudah diwujudkan adalah “Gate program + Assessment LLM”. Contoh berikut hanya menunjukkan logika penilaian peristiwa, bukan implementasi resmi Super-agent atau produk Agent yang lengkap.

Contoh sederhana

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Antarmuka yang kompatibel dengan OpenAI
)

event = "登录页面在 Safari 上又打不开了"
resp = client.chat.completions.create(
    model="gpt-4o-mini",  # Sesuaikan nama model dengan daftar model platform
    messages=[{"role": "user", "content": f"判断以下消息是否为故障线索，只回答 yes 或 no：{event}"}]
)
print(resp.choices[0].message.content)

import json
import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

# Konfigurasi Gate pada lapisan program: aturan deterministik tanpa memanggil LLM
ALLOWED_SOURCES = {"github", "feishu"}
ALLOWED_USERS = {"alice", "bob"}
WATCHED_CHANNELS = {"repo/web-frontend", "group/dev-team"}
MODE = "observe"  # off / observe / auto

def gate(event: dict) -> bool:
    """Tingkat pertama: penyaringan dengan aturan berbiaya rendah"""
    return (
        event["source"] in ALLOWED_SOURCES
        and event["user"] in ALLOWED_USERS
        and event["channel"] in WATCHED_CHANNELS
    )

def assess(event: dict) -> dict:
    """Tingkat kedua: penilaian semantik oleh model untuk membedakan explicit / inferred"""
    prompt = (
        "你是事件分类器。请判断消息是否包含值得处理的工作，"
        "并区分 explicit（明确请求）或 inferred（推断任务）。"
        '仅输出 JSON：{"actionable": bool, "kind": "explicit|inferred|none", "reason": "..."}\n'
        f"消息：{event['text']}"
    )
    resp = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=200
    )
    try:
        return json.loads(resp.choices[0].message.content)
    except json.JSONDecodeError:
        return {"actionable": False, "kind": "none", "reason": "parse_error"}

def handle(event: dict) -> str:
    if not gate(event):
        return "dropped_by_gate"
    result = assess(event)
    if not result["actionable"]:
        return "ignored"
    if result["kind"] == "explicit":
        return "create_task_with_mandate"   # Cakupan otorisasi tetap perlu diperiksa
    # Tugas yang disimpulkan diproses sesuai mode penerimaan tugas
    if MODE == "off":
        return "ignored"
    if MODE == "observe":
        return f"logged_for_review: {result['reason']}"
    return "auto_accept_if_policy_allows"

print(handle({
    "source": "feishu", "user": "alice",
    "channel": "group/dev-team",
    "text": "最近构建有时会失败"
}))

🚀 Saran untuk mulai mencoba: Saat menguji lapisan penilaian peristiwa, kamu bisa mendapatkan kuota uji coba gratis melalui APIYI apiyi.com. Gunakan kode yang sama dengan berbagai model untuk membandingkan akurasi klasifikasi dan penggunaan token, lalu tentukan konfigurasi model untuk setiap lapisan.

Pendekatan pengaturan model berlapis

Struktur Super-agent dapat diringkas sebagai berikut: peristiwa eksternal → penyaringan program → penilaian semantik oleh model → keputusan otorisasi → eksekusi oleh Agent → penyampaian hasil. Setiap lapisan tidak harus menggunakan model yang sama:

💡 Saran pemilihan: Apakah pengaturan berlapis benar-benar lebih hemat harus dibuktikan melalui log nyata dan pengujian bisnis. Jangan langsung berasumsi bahwa orkestrasi multimodel pasti menurunkan biaya. Dengan antarmuka terpadu APIYI apiyi.com, model di setiap lapisan dapat diganti dengan cepat untuk perbandingan A/B tanpa mengubah kode bisnis.

Analisis dampak arsitektur Super-agent berbasis peristiwa

Dampak bagi tim riset dan pengembangan serta pengembang otomasi

• Titik masuk bergeser dari jendela chat ke alur kerja: Issue, komentar PR, hasil CI, dan pesan grup menjadi input alami bagi Agent. Pengembang perlu merancang integrasi dan penyaringan peristiwa, bukan sekadar menulis petunjuk.
• Desain otorisasi menjadi kemampuan utama: Pembedaan Explicit/Inferred, mode penerimaan tugas, dan cakupan Mandate menentukan apakah Agent dapat diterima dalam tim nyata.
• Cara evaluasi perlu berubah: Penilaian Agent proaktif tidak cukup hanya melihat “berapa banyak tindakan yang dilakukan”, tetapi juga kualitas penemuan tugas, proporsi pengerjaan ulang, dan jumlah notifikasi yang tidak bernilai.

Dampak bagi tim aplikasi AI perusahaan

Agent proaktif memiliki potensi dalam kolaborasi pengembangan, penelusuran masalah, dan otomasi proses perusahaan, tetapi struktur biayanya akan berubah. Evaluasi peristiwa terus mengonsumsi Token, eksekusi spekulatif dapat menghasilkan pekerjaan yang tidak digunakan, dan tugas kompleks masih memerlukan peninjauan manusia. Berikut kerangka evaluasi yang disusun berdasarkan arsitektur resmi, bukan metrik kinerja resmi yang diumumkan DeepSeek:

Risiko yang perlu dihadapi

Risiko Agent proaktif mencakup pemicu keliru, lonjakan tugas, pelampauan hak akses, Prompt Injection, pemborosan sumber daya, dan kebocoran informasi. DeepSeek juga mengakui dalam artikel teknisnya bahwa isolasi konteks dalam organisasi kompleks, memori jangka panjang, komunikasi aman, dan privasi masih perlu diselesaikan. Untuk Agent yang dapat mengakses repositori privat dan kredensial lokal, pencegahan masuknya informasi sensitif ke konteks model atau kanal eksternal harus menjadi bagian dari desain sebelum deployment.

Pertanyaan Umum (FAQ)

Poin Utama DeepSeek Super-agent

• Perubahan utama: Titik awal kerja Agent bergeser dari instruksi pengguna ke peristiwa di lingkungan kerja. Jendela chat bukan lagi satu-satunya pintu masuk.
• Penyaringan dua tingkat: Gate berbasis program menyaring noise dengan biaya rendah, sementara LLM Assessment menangani penilaian semantik untuk menyeimbangkan biaya dan akurasi.
• Otorisasi diutamakan: Explicit dan Inferred ditangani secara terpisah, dengan observe sebagai mode default. Mandate mencegah pesan mengubah otorisasi.
• Eksekusi proaktif: Eksekusi spekulatif dan tugas asinkron mengurangi waktu tunggu, tetapi biaya komputasi dan manfaatnya tetap harus diperhitungkan.
• Hasil dengan gangguan minimal: Komunikasi dilakukan hanya saat keputusan atau penerimaan hasil diperlukan. Proaktif bukan berarti lebih sering mengirim notifikasi.
• Sikapi kondisi saat ini dengan hati-hati: Kasus internal menunjukkan potensinya, dan prototipe sumber terbuka sudah mampu menjalankan alur Issue → PR, tetapi tingkat kematangannya masih terbatas.
• Cara menerapkannya: Mulailah dengan membangun lapisan penilaian peristiwa menggunakan API model, lalu bandingkan hasil klasifikasi dan biaya berbagai model melalui APIYI apiyi.com.

Kesimpulan

Arsitektur berbasis peristiwa DeepSeek Super-agent tidak menjawab pertanyaan “Bisakah AI mengambil keputusan sendiri?”, melainkan “Bagaimana membuat Agent proaktif mengerjakan tugas sesuai aturan dan otorisasi?”. Mekanisme utamanya dapat dirangkum dalam tiga hal:

1. Deteksi dan penyaringan: Trigger menjadikan lingkungan kerja sebagai sumber input, sementara penyaringan dua tingkat mengendalikan noise dan biaya token.
2. Otorisasi dan kontrol: Pembedaan Explicit/Inferred, tiga mode penerimaan tugas, dan cakupan Mandate memastikan bahwa sikap proaktif tidak berarti melampaui wewenang.
3. Eksekusi dan penyerahan hasil: Eksekusi spekulatif, tugas asinkron, dan notifikasi yang minim gangguan mengubah peran manusia dari “mengelola tugas” menjadi “mengambil keputusan dan menerima hasil”.

Nilai Agent proaktif bukan terletak pada jumlah tindakan yang dijalankan, melainkan pada seberapa banyak pekerjaan pengelolaan manual yang dikurangi dan seberapa banyak hasil tepercaya yang diserahkan. Prototipe sumber terbuka saat ini masih dalam tahap awal, sehingga sebaiknya mulai dari mode observe untuk mengumpulkan catatan penilaian dan membangun kepercayaan secara bertahap. Jika Anda sedang merancang alur penilaian peristiwa dan eksekusi tugas serupa, coba gunakan APIYI apiyi.com untuk memvalidasi performa berbagai model di setiap lapisan, lalu tentukan pilihan berdasarkan data bisnis nyata.

📚 Referensi

1. Studi arsitektur DeepSeek Super-agent：Penjelasan tentang desain Agent yang digerakkan oleh peristiwa dan bersifat proaktif
2. Tautan：blog2.eimoon.com/p/deepseek-super-agent-design/

3. Keterangan：Mencakup Trigger, eksekusi spekulatif, tugas asinkron, dan contoh kasus internal

4. Dokumentasi mekanisme otorisasi DeepSeek：Explicit/Inferred, mode penerimaan tugas, dan Mandate

5. Tautan：github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/002-authorization.md

6. Keterangan：Sumber otoritatif untuk memahami tiga mode off, observe, dan auto

7. Filosofi desain produk DeepSeek：Prinsip minim gangguan dan perhatian pengguna

8. Tautan：github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/000-philosophy.md

9. Keterangan：Menjelaskan mengapa Agent proaktif tidak seharusnya terlalu sering menarik perhatian

10. DeepSeek Domain Model：Definisi konsep inti domain

11. Tautan：github.com/deepseek-ai/dsh-superagent-prototype/blob/main/docs/001-domain.md

12. Keterangan：Cocok untuk memahami lebih dalam hubungan antara tugas, Worker, dan peristiwa

13. Panduan deployment DeepSeek Setup：Panduan instalasi prototipe sumber terbuka

14. Tautan：github.com/deepseek-ai/dsh-superagent-prototype/blob/main/SETUP.md

15. Keterangan：Dokumen yang wajib dibaca sebelum melakukan deployment

16. Laporan penggunaan komunitas GitHub：Uji langsung Issue → PR dan masalah deployment

17. Tautan：github.com/deepseek-ai/deepseek-harness/discussions/11706
18. Keterangan：Gambaran kondisi dan keterbatasan prototipe saat ini dalam penggunaan nyata

Penulis：Tim Teknis APIYI
Diskusi teknis：Hubungi kami melalui halaman utama situs APIYI. Untuk materi integrasi model lainnya, kunjungi pusat dokumentasi di docs.apiyi.com