SSD Nodes Learn 🎉 VPS dari $5.50/bln
Panduan Matt ConnorOleh Matt Connor

Cara Self-Host Runtime Ejen SandBase Sendiri

Panduan lengkap menjalankan SandBase Harness v0.3.2 pada VPS anda. Ketahui cara konfigurasi fail YAML, pelayan MCP, mod sandbox dan tetapan SDK Anthropic untuk akses tempatan.

Apa yang anda peroleh apabila melakukan self-hosting runtime ejen SandBase

Melakukan self-hosting runtime ejen SandBase bermaksud menjalankan SandBase Harness pada pelayan milik anda sendiri, supaya sesi, kelayakan, memori dan jejak audit disimpan pada cakera anda dan bukannya milik pihak lain. Ia merupakan servis Node. Ia mendengar pada 127.0.0.1:3000, menyediakan API HTTP /v1 serta konsol web, dan menyimpan statusnya dalam SQLite bersebelahan dengan fail ejen anda.

API /v1 dibentuk mengikut Claude Managed Agents (CMA), iaitu API ejen terurus yang dihoskan. Inilah yang menjadikan runtime ini menarik dalam kedua-dua arah: anda boleh menulis kod menggunakan Anthropic SDK dan menghalakan baseURL-nya ke pelayan anda sendiri, kemudian memindahkan kod yang sama ke persekitaran yang dihoskan pada masa hadapan.

SandBase Harness tidak menyertakan model. Ia memanggil model tersebut. Setakat Ogos 2026, ia menyokong OpenAI, Anthropic dan endpoint yang serasi dengan OpenAI, yang merangkumi gateway yang dihoskan sendiri serta penyedia seperti DeepSeek V4. Anda masih perlu menyediakan kunci API, atau pelayan tempatan yang menggunakan API OpenAI.

Keperluan sebelum bermula

  • Sebuah VPS yang menjalankan Ubuntu 24.04 dengan sekurang-kurangnya 2 GB RAM. Proses binaan TypeScript merupakan langkah paling berat dalam pemasangan ini.
  • Node.js 22 atau lebih baharu, dan npm 10 atau lebih baharu. Kedua-duanya adalah keperluan minimum yang ditetapkan oleh projek ini.
  • git, berserta kunci API bagi penyedia model yang anda rancang untuk gunakan.
  • Docker, tetapi hanya jika anda mahukan sandbox kontena bagi setiap sesi.

Ubuntu 24.04 membekalkan Node 18.19 dalam repositorinya sendiri, yang berada di bawah tahap minimum, jadi ambil Node daripada NodeSource sebaliknya.

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs git
node -v
npm -v

node -v sepatutnya memaparkan v22 atau lebih tinggi dan npm -v sepatutnya memaparkan 10 atau lebih tinggi. Jika node -v masih memaparkan v18.19.1, pakej pengedaran tersebut masih terpasang dan diutamakan dalam PATH. Buang pakej tersebut sebelum anda meneruskan, kerana proses binaan akan dijalankan menggunakan node yang ditemui oleh shell.

Memasang SandBase daripada tag v0.3.2

Pasang daripada tag, jangan sekali-kali daripada cawangan yang sentiasa berubah. main yang dibuat secara bare akan memberikan anda apa sahaja yang dimasukkan sejam yang lalu, dan kunci konfigurasi di bawah mungkin tidak sepadan dengannya. v0.3.2 ialah tag semasa setakat 16 Ogos 2026.

sudo install -d -o "$USER" -g "$USER" /opt/sandbase
cd /opt/sandbase
git clone --branch v0.3.2 --depth 1 https://github.com/sandbaseai/sandbase-harness.git
cd sandbase-harness
npm ci
npm run build

Gunakan npm ci, bukan npm install. ci memasang versi tepat yang direkodkan dalam lockfile yang telah dikomit, supaya pepohon anda sepadan dengan pepohon yang diuji oleh penyelenggara. npm install dibenarkan untuk menyelesaikan versi yang lebih baharu, yang merupakan cara tag yang dipinkan berhenti menjadi pin secara senyap.

Sekarang, cipta ruang kerja (workspace). Ruang kerja ialah direktori berasingan yang menyimpan fail ejen anda dan semua status masa jalan, dan menyimpannya di luar semakan sumber bermakna anda boleh menarik tag yang lebih baharu tanpa menjejaskan data anda.

mkdir -p /opt/sandbase/workspace
cd /opt/sandbase/workspace
node /opt/sandbase/sandbase-harness/dist/index.js init
node /opt/sandbase/sandbase-harness/dist/index.js start

init menulis direktori .managed-agents/ ke dalam ruang kerja. start memulakan konsol pada http://127.0.0.1:3000/dashboard dan API pada http://127.0.0.1:3000/v1. Kedua-duanya belum boleh dicapai daripada komputer riba anda lagi, ini adalah betul dan akan dibincangkan dengan lebih lanjut di bawah. Capai konsol melalui SSH buat masa ini:

ssh -N -L 3000:127.0.0.1:3000 you@your-server

Laluan node .../dist/index.js yang panjang itu memenatkan, jadi berikan nama kepadanya.

alias sandbase='node /opt/sandbase/sandbase-harness/dist/index.js'

Perintah di bawah ditulis sebagai sandbase <command> berdasarkan asas tersebut.

Jangan pasang daripada npm

Projek ini menyatakan perkara berikut dalam dokumentasi pemasangannya sendiri: pakej managed-agents tanpa skop yang kelihatan di npm bukanlah projek ini. Oleh itu, npx managed-agents dan npm install -g managed-agents akan mengambil sesuatu yang tidak berkaitan dengan runtime yang anda inginkan. Pasang daripada sumber GitHub yang bertanda (tagged) sehingga penyelenggara mengumumkan pakej rasmi yang mempunyai skop. Ini bukan sekadar nota kaki kecil dalam sejarah projek ini: v0.3.1 wujud terutamanya untuk menggantikan panduan permulaan pantas npm yang lama dengan laluan sumber bertanda yang telah ditetapkan (pinned).

Halakan ruang kerja kepada penyedia model

init menulis .managed-agents/config.yaml. Satu penyedia dikonfigurasikan untuk keseluruhan ruang kerja, dan ejen individu kemudian memilih ID model yang konkrit.

model:
  provider: openai
  api_key: ${OPENAI_API_KEY}
storage:
  metadata:
    provider: sqlite
    options: {}
  artifacts:
    provider: local
    options:
      base_path: files

Borang ${OPENAI_API_KEY} mengambil nilai daripada persekitaran proses, jadi kunci tersebut kekal di luar fail konfigurasi dan di luar setiap sandaran yang anda buat bagi fail tersebut. Letakkannya dalam fail persekitaran yang hanya boleh dibaca oleh root, memandangkan systemd membaca EnvironmentFile= sebagai root sebelum ia menurunkan keistimewaan (drop privileges).

sudo install -d -m 750 /etc/sandbase
sudo touch /etc/sandbase/runtime.env
sudo chmod 600 /etc/sandbase/runtime.env

Buka fail tersebut dalam editor dan tambah satu baris, OPENAI_API_KEY=sk-.... Kunci penyedia perlu diletakkan di sini. Rahsia yang digunakan oleh ejen semasa sesi perlu diletakkan dalam peti simpanan kelayakan (credential vaults) runtime, yang merupakan masalah berbeza dengan radius impak yang berbeza, dan menjauhkan rahsia daripada ejen AI adalah wajar dibaca sebelum anda menampal token pengeluaran (production token) ke dalam mana-mana lokasi tersebut.

YAML ejen: mcp_servers, alatan dan polisi kebenaran

Ejen ditakrifkan sebagai fail YAML dalam direktori ruang kerja agents/. Ini ialah bahagian runtime yang akan anda gunakan dengan kerap.

name: Incident commander
description: Triages alerts and coordinates response.
model: gpt-4o
system: |-
  You are an on-call incident commander.
mcp_servers:
  - name: sentry
    type: url
    url: https://mcp.sentry.dev/mcp
tools:
  - type: agent_toolset_20260401
    default_config:
      permission_policy: { type: always_ask }
    configs:
      - name: bash
        permission_policy: { type: always_ask }
  - type: mcp_toolset
    mcp_server_name: sentry
metadata:
  template: incident-commander

Muatkan fail tersebut dan pastikan ia telah berjaya diproses:

sandbase reload
sandbase list
sandbase chat agent_assistant --message "hello"

reload mengimport YAML benih ke dalam SQLite. list kini sepatutnya memaparkan ejen tersebut berserta ID. Jika list tidak memaparkannya, fail tersebut gagal dihurai, dan .managed-agents/logs/runtime.log ialah tempat di mana sebab kegagalan tersebut dicatatkan.

mcp_servers mengisytiharkan endpoint MCP (model context protocol). type: url bermaksud runtime berkomunikasi melalui HTTP dengan pelayan yang berjalan di tempat lain, jadi apa-apa yang anda kendalikan sekarang akan berfungsi di sini, termasuk pelayan MCP yang dihoskan pada VPS yang sama dengan runtime.

Mengisytiharkan pelayan tidak bermakna alatan pelayan tersebut diberikan kepada ejen. Senarai tools melakukan perkara itu, melalui entri mcp_toolset yang mana mcp_server_name sepadan dengan name di atas. Jika ejen berkelakuan seolah-olah alatan MCP tidak wujud, bandingkan kedua-dua rentetan tersebut aksara demi aksara sebelum anda memeriksa perkara lain.

agent_toolset_20260401 ialah set alatan terbina dalam. Akhiran bertarikh ialah versi skema, jadi ejen yang dipinkan kepadanya akan mengekalkan definisi alatan yang digunakan semasa ia ditulis. default_config menetapkan polisi untuk setiap alatan dalam set tersebut, dan setiap entri di bawah configs mengatasi satu alatan mengikut nama, contohnya bash dalam contoh tersebut.

permission_policy ialah tempat runtime membuktikan nilainya berbanding panggilan model biasa. always_ask menjeda sesi dan menunggu manusia meluluskan panggilan sebelum ia dijalankan. always_allow membenarkan ia diteruskan. Menetapkan bash kepada always_ask bermaksud ejen tidak boleh menjalankan arahan shell tanpa anda melihat arahan tepat tersebut terlebih dahulu, yang merupakan kawalan sama yang anda akan gunakan apabila menjalankan Claude Code dengan selamat pada VPS.

Tiga mod sandbox, dan kesesuaian penggunaannya

Panggilan alatan yang melaksanakan kod akan berjalan di dalam sandbox. Backend dipilih mengikut persekitaran, melalui sandbox_provider dalam objek config persekitaran tersebut, atau di bawah Settings kemudian Sandbox dalam konsol. Persekitaran dicipta melalui API di POST /v1/environments.

local menjalankan kod sebagai proses anak kepada runtime, pada hos, sebagai pengguna runtime itu sendiri. Ini adalah tetapan lalai, dan ia munasabah selagi anda merupakan satu-satunya pengguna dan ejen hanya membaca fail milik anda. Ia bukan satu bentuk pengasingan. Panggilan alatan yang memadam fail akan memadam fail anda, dan panggilan alatan yang membaca /etc/sandbase/runtime.env akan membaca kunci penyedia anda.

docker memulakan satu kontena bagi setiap sesi.

{
  "sandbox_provider": "docker",
  "image": "node:22-slim",
  "resources": { "memory": "1g", "cpu": 1 }
}

Sesi tersebut mendapat sistem failnya sendiri, had memori sendiri dan bahagian CPU sendiri, dan kontena tersebut akan dibuang bersama sesi berkenaan. Beralihlah kepada mod ini sebaik sahaja ejen menjalankan kod yang bukan anda tulis. Kosnya ialah pengguna runtime memerlukan akses kepada Docker socket, dan keahlian dalam kumpulan docker adalah setara dengan root pada hos. Kontena bagi setiap sesi mempunyai bentuk yang sama seperti sandbox ejen yang dihoskan sendiri dengan satu kontena bagi setiap pelaksanaan, jadi penaakulan tentang perkara yang boleh dicapai oleh proses yang terlepas (escaped process) terpakai di sini tanpa perubahan.

kubernetes menjalankan beban kerja sesi sebagai pod dan menggerakkannya dengan kubectl exec dan kubectl cp. Imej runtime memerlukan kubectl tersedia, dan ServiceAccount miliknya memerlukan kebenaran RBAC (role-based access control) untuk mencipta, memadam, mendapatkan, menyenaraikan dan memantau (watch) pod dalam namespace sasaran, serta sub-sumber exec. Mod ini hanya berbaloi untuk disediakan jika anda sudah pun menjalankan kluster.

Mengapa runtime terikat pada 127.0.0.1?

Kerana ia bermula dengan pengesahan dimatikan. Runtime mendayakan pengesahan bearer-token apabila sekurang-kurangnya satu API key wujud, dan init yang baharu tidak mencipta sebarang kunci. Mengikat pada 0.0.0.0 dengan tetapan lalai tersebut akan meletakkan runtime ejen yang tidak disahkan, yang memegang alatan shell dan kunci pembekal anda, pada internet awam.

Jadi, apabila anda mahu ia boleh dicapai, biarkan alamat bind seperti sedia ada dan lakukan dua perkara lain.

Pertama, hidupkan pengesahan. Tetapkan MANAGED_AGENTS_API_KEY dalam fail persekitaran servis, atau cipta kunci dengan POST /v1/api-keys, yang akan memaparkan medan secret_key sekali sahaja dan tidak akan menunjukkannya lagi. Pelanggan kemudian perlu menghantar Authorization: Bearer <key> pada setiap permintaan.

Kedua, letakkan reverse proxy di hadapan dan tamatkan TLS (transport layer security) di sana. Runtime menyediakan HTTP biasa secara reka bentuk dan menjangkakan sesuatu yang lain untuk mengendalikan sijil.

server {
    listen 443 ssl;
    server_name agents.example.com;

    ssl_certificate     /etc/letsencrypt/live/agents.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/agents.example.com/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Connection "";
        proxy_buffering off;
        proxy_read_timeout 3600s;
    }
}

Dua daripada baris tersebut bukan sekadar hiasan. proxy_buffering off penting kerana sesi distrim melalui server-sent events (SSE), dan dengan penimbalan (buffering) dihidupkan, nginx menahan respons sehingga penimbalnya penuh, menyebabkan konsol tidak menunjukkan apa-apa semasa ejen bekerja dan kemudian memaparkan segala-galanya pada akhir proses. proxy_read_timeout 3600s penting kerana nilai lalai ialah 60 saat, jadi strim yang senyap melebihi satu minit akan ditutup oleh proksi di tengah-tengah giliran, dan kegagalan itu kelihatan seperti runtime yang terhempas.

Pada firewall, buka port 22 dan 443. Biarkan 3000 tertutup, kerana proksi mencapainya melalui loopback dan tiada apa-apa dari luar kotak yang sepatutnya boleh mengaksesnya.

Halakan SDK Anthropic ke pelayan anda sendiri

Runtime ini melaksanakan permukaan /v1 berbentuk CMA, jadi klien SDK Anthropic boleh berhubung dengannya dengan hanya menukar satu medan.

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic({
  apiKey: process.env.MANAGED_AGENTS_API_KEY ?? 'local-dev-key',
  baseURL: 'http://127.0.0.1:3000'
});

Ia juga menerima pengepala beta yang dihantar oleh klien Claude Managed Agents, iaitu anthropic-beta: managed-agents-2026-04-01 dan anthropic-beta: agent-memory-2026-07-22. Pengepala ini adalah pilihan jika digunakan dengan runtime tempatan. Ia wujud supaya kod yang ditulis untuk penggunaan dihoskan boleh dijalankan di sini tanpa sebarang perubahan.

Keserasian adalah hampir penuh, tetapi tidak menyeluruh. Baca docs/api-matrix.md dalam direktori projek sebelum anda menganggap sesuatu permukaan itu wujud, kerana projek ini mendokumentasikan kekurangannya di sana, termasuk alatan tersuai bahagian klien, yang masih memerlukan pendaftaran bernama di luar protokol hasil-acara semasa.

HTTP biasa juga berfungsi dengan baik, dan merupakan cara terpantas untuk membuktikan runtime tersebut aktif:

curl -N -X POST http://127.0.0.1:3000/v1/sessions/SESSION_ID/messages \
  -H "Content-Type: application/json" \
  -d '{"content": "Hello", "stream": true}'

Respons yang sihat ialah aliran acara yang terus tiba. Jika sambungan terputus, sambung semula daripada acara terakhir yang anda lihat dan bukannya memainkan semula keseluruhan giliran:

curl -N http://127.0.0.1:3000/v1/sessions/SESSION_ID/events/stream \
  -H "Last-Event-ID: EVENT_ID"

Aliran yang boleh disambung semula inilah sebabnya sesuatu sesi bertahan walaupun komputer riba ditutup. Acara-acara tersebut dikekalkan pada pelayan, jadi klien memainkan semula log dan bukannya menyimpan satu-satunya salinan.

Tempat kelayakan, memori dan jejak audit disimpan pada cakera

Segala milik runtime berada di bawah .managed-agents/ dalam ruang kerja.

.managed-agents/
├── config.yaml
├── data.db
├── logs/runtime.log
├── files/
├── skills/
├── snapshots/
└── sandbox/
  • data.db ialah metadata SQLite: ejen, sesi, entri peti kelayakan, entri stor memori dan kunci API.
  • files/ menyimpan bait fail yang dimuat naik dan skills/ menyimpan pakej kemahiran yang dimuat naik.
  • snapshots/ menyimpan syot kilas ruang kerja sesi, dan sandbox/ menyimpan direktori kerja bagi sesi mod tempatan.
  • logs/runtime.log ialah tempat pertama untuk diperiksa apabila sesuatu perkara tidak menunjukkan sebarang tindak balas.

Peti kelayakan ialah kumpulan rahsia, setiap satunya ditambah dengan auth_type seperti environment_variable, dan dilampirkan pada sesi melalui vault_ids apabila sesi dicipta. Stor memori menyimpan entri bernama yang anda lekapkan ke dalam sesi sebagai memory_store dengan tetapan akses dan arahannya sendiri. Kedua-duanya berada dalam data.db, yang merupakan perbezaan tepat antara ini dengan panggilan model mentah: runtime mengingati merentas sesi, dan ia merekodkan apa yang berlaku.

Oleh kerana ia merupakan satu direktori, buat sandaran sebagai satu unit.

sudo systemctl stop sandbase
sudo tar czf /root/sandbase-$(date +%F).tgz -C /opt/sandbase/workspace .managed-agents
sudo systemctl start sandbase

Hentikan servis terlebih dahulu. Menyalin pangkalan data SQLite semasa runtime sedang menulis kepadanya boleh menghasilkan fail yang tidak dapat dibuka semasa pemulihan, dan anda hanya akan mengetahuinya pada hari anda memerlukannya. Jika anda lebih suka menyimpan YAML ejen dalam git dan keadaan (state) di tempat lain, dokumen penempatan menyokong penetapan lokasi keadaan dengan --data-dir pada start.

Pemulihan adalah sebaliknya: semak tag yang sama pada mesin baharu, nyahpek arkib ke dalam ruang kerja, kemudian mulakan servis. Kunci pembekal anda tidak berada dalam arkib jika anda menggunakan borang ${OPENAI_API_KEY}, jadi simpan kunci tersebut di tempat yang anda boleh akses kemudian.

Jalankan di bawah systemd

Berikan runtime pengguna sendiri supaya panggilan alat dalam mod sandbox tempatan tidak boleh bertindak sebagai anda.

sudo adduser --system --group --no-create-home --home /opt/sandbase sandbase
sudo chown -R sandbase:sandbase /opt/sandbase

Simpan ini sebagai /etc/systemd/system/sandbase.service.

[Unit]
Description=SandBase Harness runtime
After=network-online.target

[Service]
User=sandbase
Group=sandbase
WorkingDirectory=/opt/sandbase/workspace
EnvironmentFile=/etc/sandbase/runtime.env
ExecStart=/usr/bin/node /opt/sandbase/sandbase-harness/dist/index.js start --host 127.0.0.1 --port 3000
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

Contoh penempatan projek itu sendiri memanggil binari managed-agents pada PATH. Pemasangan daripada sumber bertag tidak mencipta binari tersebut, jadi ExecStart menjalankan node terhadap titik masuk (entry point) yang dibina sebagai ganti.

sudo systemctl daemon-reload
sudo systemctl enable --now sandbase
sudo systemctl status sandbase
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/dashboard

Hasil yang sihat ialah active (running) daripada status dan 200 daripada curl. Jika mendapat hasil lain, baca journalctl -u sandbase -n 50 dahulu dan .managed-agents/logs/runtime.log kemudian. enable --now ialah bahagian yang penting, kerana proses yang dimulakan secara manual akan hilang selepas but semula (reboot) yang seterusnya.

Perkara yang tergendala dan mesej yang akan anda lihat

npm run build ditamatkan tanpa ralat daripada npm. Pada VPS 1 GB, proses kompilasi TypeScript dihentikan oleh kernel out-of-memory killer, yang melaporkan perkara tersebut ke log kernel dan bukannya kepada npm. Sahkan dengan journalctl -k | grep -i "out of memory", yang akan memaparkan baris yang menamakan proses node yang telah ditamatkan. Tambahkan swap, atau lakukan binaan pada instans yang lebih besar dan salin dist/ ke destinasi.

Error: listen EADDRINUSE: address already in use 127.0.0.1:3000. Proses lain sudah menggunakan port tersebut. sudo ss -lntp | grep 3000 akan menamakan proses itu. Anda boleh menghentikan proses tersebut atau memulakan runtime dengan --port 3001 dan mengemas kini proksi.

Papan pemuka tidak dimuatkan daripada komputer riba anda. Ini adalah tingkah laku yang dijangkakan, kerana runtime terikat pada loopback. Gunakan terowong SSH di atas, atau selesaikan konfigurasi reverse proxy. Jangan cuba membaikinya dengan --host 0.0.0.0, kerana pengesahan dimatikan sehingga kunci wujud.

Sandbox Docker gagal dengan permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock. Pengguna sandbase tidak berada dalam kumpulan docker. Selesaikan dengan sudo usermod -aG docker sandbase dan mulakan semula servis tersebut. Fahami perkara yang anda berikan: kumpulan itu adalah root pada hos, jadi ia membatalkan sebahagian daripada sebab anda memberikan runtime pengguna sendiri.

Sandbox Kubernetes gagal dengan Error from server (Forbidden). ServiceAccount kehilangan kebenaran pod atau sub-sumber exec. Semak secara terus dengan kubectl auth can-i create pods/exec -n <namespace>, yang akan memberikan jawapan yes atau no.

Setiap permintaan mengembalikan 401 selepas anda menambah API key. Pengesahan diaktifkan apabila kunci pertama wujud, dan ia terpakai pada konsol serta API. Hantar Authorization: Bearer <key>, dan jika anda kehilangan kunci tersebut, cipta kunci baharu, kerana secret_key hanya dipaparkan sekali dan tidak disimpan dalam bentuk yang boleh dibaca.

Tools pelayan MCP tidak muncul dalam sesi. Semak mcp_server_name dalam blok tools berbanding name dalam mcp_servers, kemudian semak sama ada runtime boleh mencapai URL tersebut daripada pelayan itu sendiri dengan curl -i <url>. Pelayan MCP jenis URL merupakan dependency rangkaian, dan VPS menyelesaikan nama serta menghalakan trafik secara berbeza daripada komputer riba anda.

FAQ

Bolehkah saya menjalankan SandBase Harness tanpa kunci OpenAI atau Anthropic?

Boleh, jika anda mempunyai endpoint yang serasi dengan OpenAI. Runtime ini menyokong penyedia OpenAI, Anthropic dan penyedia yang serasi dengan OpenAI, jadi pelayan tempatan yang menggunakan API OpenAI boleh berfungsi. Tetapkan penyedia ruang kerja dalam .managed-agents/config.yaml dan halakan api_key serta endpoint kepadanya. Runtime ini tidak menyertakan modelnya sendiri, jadi sesuatu perlu menjawab panggilan tersebut.

Adakah selamat untuk mendedahkan runtime pada port awam?

Tidak seperti yang dipasang secara lalai. Ia terikat pada 127.0.0.1:3000 dan bermula dengan pengesahan dimatikan, dan penyelesaiannya bukan dengan menukar alamat ikatan. Cipta kunci API, atau tetapkan MANAGED_AGENTS_API_KEY, supaya pengesahan bearer-token diaktifkan. Kemudian, letakkan nginx atau Caddy di hadapan untuk TLS, dan pastikan port 3000 ditutup pada firewall supaya satu-satunya laluan masuk adalah melalui proksi.

Apakah perbezaan antara sandbox tempatan, Docker dan Kubernetes?

local menjalankan kod alatan sebagai proses anak bagi runtime pada hos, dengan kebenaran pengguna runtime dan tanpa pengasingan. docker memberikan setiap sesi bekasnya sendiri dengan sistem fail, had memori dan bahagian CPU sendiri, serta membuangnya apabila sesi berakhir. kubernetes menjalankan sesi sebagai pod dan menggerakkannya dengan kubectl exec, yang memerlukan kubectl di dalam imej runtime dan RBAC pada pod serta sub-sumber exec dalam namespace sasaran.

Apakah yang perlu saya sandarkan dengan tepat?

Direktori .managed-agents/ dalam ruang kerja. Ia menyimpan config.yaml, pangkalan data SQLite data.db yang mengandungi ejen, sesi, entri peti simpanan kelayakan dan entri memori, serta fail yang dimuat naik, pakej kemahiran dan syot kilas sesi. Hentikan servis sebelum menyalinnya supaya SQLite tidak ditulis semasa proses arkib sedang berjalan. Kunci API penyedia yang dirujuk sebagai ${OPENAI_API_KEY} tidak berada di dalam sandaran, jadi simpan kunci tersebut secara berasingan.

Mengapa perlu mengklon tag v0.3.2 dan bukannya main?

Tag ialah pepohon yang tetap, jadi kunci konfigurasi dan arahan CLI yang anda baca adalah yang anda akan perolehi. main sentiasa berubah, dan kunci konfigurasi boleh dinamakan semula antara masa panduan ditulis dan masa anda menjalankannya. Projek ini juga memberi amaran bahawa pakej managed-agents yang tidak diskop pada npm bukanlah projek ini, jadi npx managed-agents akan memasang sesuatu yang tidak berkaitan. Keluaran v0.3.1 wujud terutamanya untuk menggantikan permulaan pantas npm tersebut dengan laluan sumber bertag yang dipinkan.

#ai-agents#mcp#self-hosting#sandboxing#anthropic-sdk