Diagnosis agen

Panduan ini menunjukkan cara mengetahui mengapa sebuah agen tidak menghasilkan run.

Periksa dari atas ke bawah: run agen itu sendiri terlebih dahulu, lalu backend-nya, lalu server, lalu host.

1. Periksa riwayat run agen

Pengaturan → Ruang kerja → Agen → pilih agen → Log.

Setiap run menampilkan lencana status, durasi (“Berjalan…” saat masih berlangsung), waktu mulai dan penyelesaiannya, PID-nya, dan adapter yang dipakainya. Lihat membuka aliran peristiwa mentah run tersebut. Berhenti mematikan proses yang sedang berjalan dan menandai run itu “Dihentikan oleh pengguna”; Hentikan yang berjalan di header melakukan hal yang sama untuk setiap run agen tersebut yang sedang berlangsung.

Bacalah seperti ini:

Tidak ada run sama sekali — pengiriman tidak pernah terjadi. Sebutan di composer adalah @ ditambah karakter kata (huruf, angka, garis bawah). Resolusinya adalah pencocokan persis atau awalan pada nama agen, sehingga @code-reviewer diuraikan sebagai code dan tetap dapat membangunkan agen bernama code-reviewer. Nama yang mengandung spasi tidak dapat disebutkan sebagai satu token. Lalu lanjut ke langkah 2.
Run yang langsung berakhir dengan galat — buka Lihat. Kegagalan meluncurkan backend muncul di sini sebagai galat proses.
Run yang macet pada “Berjalan…” — hentikan, lalu periksa Batas waktu diam agen di tab Pengaturan. Batas waktu yang tidak diatur menggunakan default per mode.
Run yang selesai tanpa keluaran berguna — status log run tetap completed untuk run yang berakhir tanpa hasil kerja yang dideklarasikannya; sinyal yang jujur adalah teks ringkasan, bukan lencana.

Tab Log tidak menampilkan biaya. Untuk pengeluaran, gunakan tabel per agen di Observabilitas → Wawasan.

2. Periksa backend agen

Pengaturan → Server → Penyedia model (/settings/server/providers).

Daftar Runner terdeteksi menampilkan setiap adapter beserta hasil pemeriksaannya — versi yang terpasang, “Memeriksa…”, atau “Tidak ditemukan” — plus path yang diselesaikan dan chip kemampuan untuk CLI yang ditemukan. Klik Segarkan di header halaman untuk memeriksa ulang.

Pemeriksaan berjalan di mesin yang menghosting cc_server, bukan di mesin yang sedang Anda lihat. Jika Anda berada di klien web atau perangkat yang dipasangkan, “Tidak ditemukan” berarti CLI tersebut tidak ada di host server.

Dua hal yang perlu dipastikan:

Agen memang punya adapter yang diatur. Agen dengan adapter kosong dikirim ke Control Center (built-in) dan log run mencatat cc-harness, sehingga transkrip menyebutkan apa yang berjalan. Tanpa model juga, ia meminta default-nya kepada Anthropic — yang gagal dengan No credential for provider "anthropic" kecuali Anda telah menghubungkan akun Anthropic. Agen spesialis yang disemai hadir tanpa adapter.
Adapter bawaan punya model. Daftar modelnya diambil secara langsung dari penyedia yang terhubung di bagian bawah halaman yang sama ini, sehingga penyedia tanpa kredensial tersimpan menyumbang nol model.

Katalog adapter itu sendiri tetap — tidak ada cara untuk mendaftarkan adapter baru. Yang dapat Anda ubah per adapter di sini adalah argumen peluncuran dan variabel lingkungannya. Perhatikan bahwa penggantian lingkungan per adapter secara diam-diam mengalahkan akun penyedia yang terhubung saat kredensial diselesaikan.

3. Periksa server

Pengaturan → Server → Koneksi & status (/settings/server/connection) menunjukkan server mana yang sedang diajak bicara klien ini dan apa yang dilaporkannya.

Untuk server headless, GET /healthz adalah informasi yang sama tanpa klien. Endpoint ini tanpa autentikasi dan terbuka CORS secara sengaja:

curl http://localhost:9030/healthz

Endpoint ini mengembalikan status server, uptime dalam detik, jumlah koneksi aktif, port yang diikat, versi build dan SHA git, versi skema ruang kerja, versi katalog RPC, id server, nama dan sidik jari identitas, apakah binding tidak aman, serta blok codeGraph dengan jumlah watching / indexing / pending. Ketika sebuah cache telah menerima trafik, endpoint ini juga menyertakan blok caches; server demo menambahkan demo: true.

Dua hal yang perlu diketahui ketika sebuah perubahan “berhasil di pengujian tetapi tidak di aplikasi”:

Aplikasi desktop meluncurkan biner cc_server yang sudah dibangun alih-alih dari sumber. Operasi RPC atau alat MCP baru tidak muncul sampai biner tersebut dibangun ulang, dan log boot mencatat peringatan ketika SHA git proses anak berbeda dari milik aplikasi.
Aplikasi desktop mematikan server yang dijalankan jika belum mencetak banner siapnya dalam 20 detik dan beralih ke layar galat.

4. Periksa host

Pengaturan → Server → Diagnostik & privasi (/settings/server/diagnostics) adalah halaman tingkat host. Halaman ini memuat:

Sandboxing — tombol utama, backend yang terdeteksi, dan petunjuk instalasi. Hanya backend yang terdeteksi yang berasal dari server; lihat peringatan di bawah. Tidak ada kontrol reset.
Pencarian semantik — siklus hidup model embedding di perangkat: terpasang, sedang diunduh dengan persentase, belum terpasang, atau galat instalasi. Sampai model tersebut terpasang, pencarian memori dan kode tetap hanya berdasarkan kata kunci.
Perilaku sistem — jaga komputer tetap terjaga saat agen berjalan.
Level log — naikkan sebelum mereproduksi kegagalan.
Privasi — apakah konten diff mentah boleh diteruskan ke model agen dan apakah laporan kerusakan dikirim.

Deteksi dan penegakan kini sejalan: di tempat detektor melaporkan backend native, run agen di host itu benar-benar dibungkus olehnya. Tetapi detektor adalah satu-satunya hal yang aktif di bagian ini. Tombol utama dan pemilih backend adalah preferensi yang disimpan di perangkat Anda dan server tidak membaca satu pun darinya — sakelar milik server sendiri adalah --sandbox (on secara default, off untuk tidak ikut).

Jadi peringatan di sini layak ditindaklanjuti, tetapi biasanya bukan penyebab agen gagal. Untuk memastikan kondisi server, bacalah log startup-nya: log mencetak agent sandbox ON dengan catatan backend, no OS-native agent sandbox on this host dengan petunjuk instalasi, atau agent sandbox DISABLED by --sandbox off. GET /healthz tidak memuat kolom sandbox.

Di tempat yang tidak ada backend — Windows selalu, Linux atau WSL2 tanpa bwrap dan socat — run tidak di-sandbox dan yang membatasinya adalah checkout milik percakapan itu sendiri, token forge hanya-baca dan gateway push, pagar pengaman tindakan, sanitasi lingkungan, dan permukaan alat yang diizinkan modenya.

Kegagalan umum

Run tidak pernah dimulai dan adapter menampilkan “Tidak ditemukan”

Instal CLI di host server, lalu klik Segarkan di halaman Penyedia model. Atau alihkan agen ke adapter bawaan, yang tidak memerlukan CLI, dan hubungkan penyedia di halaman yang sama.

Agen tidak dapat push atau membuka pull request

Baca apa yang dicetak git atau agen. Control Center policy: … berarti sebuah aturan aksi menolaknya atau persetujuan tidak dijawab: periksa Push ke remote dan Buka pull request di Pengaturan → Ruang kerja → Izin agen. Jika git menyatakan Control Center tidak punya kredensial GitHub yang dapat push, pasang GitHub App di repo itu atau hubungkan GitHub.

Pencarian semantik tidak mengembalikan apa pun yang berguna

Periksa Pengaturan → Server → Diagnostik & privasi → Pencarian semantik. Sampai model embedding terpasang, pencarian hanya berdasarkan kata kunci. Baris yang ditulis sebelum model terpasang tidak pernah diisi ulang, jadi tetap hanya berdasarkan kata kunci bahkan setelahnya.

Server sama sekali tidak mau boot

Pustaka native diperlukan dan tidak ada mode terdegradasi. Dylib yang hilang membuat cc_server menolak untuk mulai dan menyebutkan pelakunya dalam galat. Siapkan pustaka native dengan scripts/natives/build_natives.sh dan bangun ulang biner server.

Tindakan ditolak secara diam-diam

Keputusan pagar pengaman prompt tanpa penyetuju yang terhubung akan ditolak, memang begitu desainnya. Periksa aturan ruang kerja di Pengaturan → Ruang kerja → Izin agen.