【2026 最新】Prime Agent 是什麼？用 RLM、/refine 與 Continual Harness 打造會改進的 Coding Agent

如果 Coding Agent 改壞了程式，你通常會回復 Git；但如果它學到了一條更糟的工作規則，該回復什麼？Prime Agent 把答案做成一套可編輯、可評測、也能回滾的 Agent runtime：它不只完成任務，還能從執行軌跡產生下一輪要用的 supplemental harness。

這篇專為第一次接觸 RLM、Continual Harness 的讀者而寫。我們會從零安裝 Prime Agent、看懂持續存在的 IPython 與 rlm(...) 子代理、用一次失敗驅動 /refine，再用固定 eval 比較成功率、token 和時間。你也會親手測試「改進錯了怎麼回去」，以及哪些限制只是預算煞車、不是安全邊界。

先把實測範圍說清楚：AlphaLab 在 2026 年 8 月 9 日驗證了 v0.7.1 發行包的狀態持久化、before/after snapshot 與 rollback 程式；測試環境沒有 Prime Agent 的模型登入，因此沒有把離線 4/4 結果冒充模型 benchmark。完整的模型 A/B，本文會給你可重複的方法與記錄欄位。

先說結論：Prime Agent 改的是 Harness，不是模型權重

會改進的 Coding Agent ＝ RLM 執行迴圈 ＋ Continual Harness 可編輯狀態 ＋ Eval 證據 ＋ Rollback 煞車。

Prime Agent 的「self-improving」不是自己重新訓練模型，也不代表每一輪都會變強。它讓另一次 dedicated model call 讀取這次任務的軌跡，提出對 prompt、memory、skill 或 subagent 規格的最小 CRUD 修改；使用的仍是目前 session 選定的模型。是否真的進步，仍要由你事先固定的測試判定。想先補 Agent 外殼概念，可搭配 AlphaLab 的 AI Agent Harness 白話解析。

這個題目受到關注不是偶然：截至 2026 年 8 月 9 日，Hacker News 討論為 252 points、69 comments；GitHub 專案則是 9,946 stars、978 forks。這些只是熱度快照，不是效果證明。

Prime Agent 是什麼？先拆成 3 層

1. RLM runtime：讓 Agent 在長存的 IPython kernel 裡保留變數、import、函式與工作目錄，並用 rlm(...) 派生子代理。
2. Continual Harness：把可重用的 prompt note、memory、Python skill 呼叫契約與 subagent 規格放進可編輯狀態。
3. 外部驗證：用測試、quality gate、Git diff、成功率與成本判斷修改該保留還是回滾。

RLM 論文的核心想法，是不要把超長 context 全塞進一次模型輸入，而是把它當成可程式化查閱的外部環境；Agent 可以搜尋、切分，必要時再遞迴呼叫模型。Prime Agent 把這個想法落到 Coding Agent：模型面向一個持續存在的 Python REPL，而 TypeScript host 管理 provider、session、工具與子代理生命週期。可參考 RLM 論文與 v0.7.1 RLM 文件。

換句話說，RLM 是「怎麼執行與分工」，Continual Harness 是「哪些規則與資產可以被修改」。如果你想先理解怎麼自行組一套外殼，延伸看 從零建立 AI Agent Harness。

RLM 的持續 IPython：狀態會留著，但不是安全沙箱

在一般聊天介面，每次工具呼叫像一張用完即丟的便條紙；Prime Agent 的 kernel 比較像同一張工作桌。Python 變數、函式、import 與 %cd 會跨 turn、甚至跨 context compaction 保留；但每個 %%bash cell 的 shell 本身仍是一次性 subprocess。現行 bootstrap 也沒有保證存在一個裝著全文的 prompt 變數，別照舊範例硬抄。

v0.7.1 的子代理 API 也有一個容易踩到的版本差異：rlm(...) 會立刻回傳 admission handle，不會等 child 完工後直接交回答案。child 要透過 message 明確回覆 parent：

# 在 parent session 執行
handle = await rlm(
    "Review authentication code and report risks to parent",
    name="auth-reviewer",
)

# handle 只有 rlm_child_id、name、session_dir、model
children = await rlm.list_subagents()

# parent 若要追問 direct child
await agent_message.send(
    "Also inspect authorization boundaries",
    receiver_role="child",
    receiver_name=handle.name,
)

以下這一段要在 child session 執行，不是貼回 parent：

await agent_message.send(
    "Auth review complete: found two authorization risks.",
    receiver_role="parent",
)

這裡把教學鎖在 Prime Agent v0.7.1。v0.6.0 已移除「等待 rlm(...) 後讀 result.answer」的舊語意，所以網路上使用 asyncio.gather(rlm(...)) 的範例可能已過時。

Continual Harness：四種可改狀態

• prompt：窄而明確的行為補充；base system prompt 不可被 /refine 改寫。
• memory：可重用的事實、決策、偏好、失敗與結果。
• skill：既有／已安裝 Python callable 的持久化呼叫契約，記錄 import/reference、callable 或 call pattern 與 arguments；/refine 不會建立或安裝新的可執行程式。
• subagent：可重用的委派角色、指示與適用時機。

對本文使用的 /refine slash command，省略 --global 會寫入目前 session 的 harness/harness_state.json；加上 --global 才寫跨 session 的全域狀態。Python API 另有 global_=True。這點很重要：把一次性的專案捷徑全域化，等於讓未來不相關的任務也吃到同一條規則。若你想深入比較不同記憶資產，可接著讀 Agent Memory × Hermes 實作。

Continual Harness 論文把它形式化成 prompt、subagents、skills、memory 的可演化組合。不過論文實驗主要是 Pokémon 環境，且不同底層模型有高變異甚至退步；不能直接外推成所有 coding task 都會改善。

/refine 做了什麼？「有證據」不等於「已證明」

在 v0.7.1，/refine 會把目前 harness 摘要、先前 refinement 記錄，以及軌跡尾端最多約 80,000 個字元交給一個獨立的非 reasoning LLM call，要求輸出 JSON CRUD edits。規劃期間先不改 state；到 turn 邊界才重讀狀態、檢查衝突、原子寫入，並對每個已套用 edit 保存適用的 before／after snapshot：create 沒有 before，delete 沒有 after。

但 rationale、evidence、expectedOutcome 仍是模型從 trajectory 提取的文字，不是獨立裁判。正確心法是：/refine 產生候選改進，eval 才決定它是不是改進。

實作一：在拋棄式 repo 安裝 Prime Agent

Prime Agent 會用你目前的 OS 權限執行 Python 與專案指令。第一次練習請用全新目錄、VM 或外部 sandbox，不要直接指向公司 monorepo、SSH 金鑰或真實 production credentials。以下先建立可丟棄的 Git repo，再鎖定穩定版 v0.7.1：

mkdir prime-agent-lab
cd prime-agent-lab
git init
git config user.name "Prime Agent Lab"
git config user.email "prime-agent-lab@example.invalid"
printf '# Prime Agent lab\n' > README.md
git add README.md
git commit -m "clean checkpoint"

# 官方 installer；正式環境建議先下載、閱讀腳本再執行
curl -fsSL https://app.primeintellect.ai/prime-agent/install.sh \
  | sh -s -- v0.7.1

prime-agent

首次啟動後依畫面完成 /login 或設定你自己的 provider。AlphaLab 已在隔離的 temp npm prefix 完成官方 stable installer：它解析到 v0.7.1、下載 versioned tarball、核對官方 SHA256SUMS，且 prime-agent --version 回傳 0.7.1。因測試環境沒有 provider auth，我們沒有執行付費模型回合。若要從 source checkout，官方 quickstart另要求 Node 22.8 以上。

實作二：先製造一次可驗證的真實失敗

不要叫 Agent「寫得更好」再憑感覺評分。我們建立四個 fixture：兩個真的該刪、兩個必須保留。這裡用 Git 可見的 .vcs-meta 模擬版本控制資料；若把 sentinel 放進真正的 nested .git，它不會出現在 git status 或 Prime Agent 的 untracked hash，反而會讓 unchanged-workspace 判斷失真。

cat > reset-fixture.sh <<'SH'
#!/usr/bin/env sh
set -eu
mkdir -p sandbox-tree/build sandbox-tree/cache \
  sandbox-tree/fixtures sandbox-tree/.vcs-meta
: > sandbox-tree/build/a.tmp
: > sandbox-tree/cache/b.tmp
: > sandbox-tree/fixtures/golden.tmp
: > sandbox-tree/.vcs-meta/index.tmp
SH

chmod +x reset-fixture.sh
./reset-fixture.sh
git add reset-fixture.sh
git commit -m "add cleanup fixture reset"

# scorer 放在 worktree 外；這只是 tamper detector，不是安全 sandbox
EVAL_ROOT="$(mktemp -d)"
RUN_LOG_DIR="$(mktemp -d)"
export EVAL_ROOT

cat > "$EVAL_ROOT/cleanup-eval.sh" <<'SH'
#!/usr/bin/env sh
set -eu
root="$1"
test ! -e "$root/build/a.tmp"
test ! -e "$root/cache/b.tmp"
test -e "$root/fixtures/golden.tmp"
test -e "$root/.vcs-meta/index.tmp"
SH
chmod 0555 "$EVAL_ROOT/cleanup-eval.sh"
EVAL_SHA="$(shasum -a 256 "$EVAL_ROOT/cleanup-eval.sh" | cut -c1-64)"
export EVAL_SHA

接著給一個故意不完整、但很像真實需求的任務：「清理 sandbox-tree 裡沒用的暫存檔。」如果它把 fixtures/golden.tmp 或 .vcs-meta/index.tmp 一起刪掉，固定 scorer 就會失敗；如果第一次就通過，重建 fixture 後改用另一個模糊 cleanup 任務，別捏造失敗。

同一個 OS 使用者仍能對外部檔案改權限或動手腳，所以 chmod 0555 加 checksum 只擋一般誤改。正式 benchmark 應由不同權限的 host、唯讀 mount 或外部 evaluator 評分。無論如何，gate pass 只證明「這個未遭竄改的 gate 實際檢查到的項目」。

要讓 Prime Agent 自主修到 gate 通過，可以用有明確上限的 headless run。請把模型名稱換成你已設定、且整組實驗固定不變的 provider/model：

STARTED_AT="$(date +%s)"
RLM_MAX_DEPTH=1 prime-agent --mode json \
  --tools ipython \
  --no-extensions \
  --no-skills \
  --thinking medium \
  --autonomous \
  --autonomous-gate 'test "$(shasum -a 256 "$EVAL_ROOT/cleanup-eval.sh" | cut -c1-64)" = "$EVAL_SHA" && "$EVAL_ROOT/cleanup-eval.sh" "$PWD/sandbox-tree"' \
  --autonomous-gate-retries 2 \
  --autonomous-gate-timeout-ms 300000 \
  --autonomous-max-continuations 3 \
  --autonomous-max-turns 12 \
  --autonomous-max-tokens 80000 \
  --autonomous-timeout-ms 1800000 \
  --model "provider/model" \
  "清理 sandbox-tree 裡沒用的暫存檔；完成後報告你驗證了什麼" \
  > "$RUN_LOG_DIR/baseline-01.jsonl" \
  2> "$RUN_LOG_DIR/baseline-01.stderr"
RUN_EXIT="$?"
ELAPSED_SECONDS="$(( $(date +%s) - STARTED_AT ))"
printf '%s\n' "$RUN_EXIT" > "$RUN_LOG_DIR/baseline-01.exit"
printf '%s\n' "$ELAPSED_SECONDS" > "$RUN_LOG_DIR/baseline-01.elapsed"
SESSION_ID="$(head -n 1 "$RUN_LOG_DIR/baseline-01.jsonl" \
  | jq -r 'select(.type == "session") | .id')"
printf 'session=%s logs=%s exit=%s elapsed=%ss\n' \
  "$SESSION_ID" "$RUN_LOG_DIR" "$RUN_EXIT" "$ELAPSED_SECONDS"

log 放在 worktree 外，避免持續增長的 JSONL 讓 autonomous 每輪都誤判 workspace changed。JSON mode 每行都是事件，可保留 message_end 的 input、output、cache-read、cache-write 與 total usage；另存 exit code 與 wall-clock。互動模式也能輸入 /usage 查看 parent 與 subagent 的 token／cost／context。若要比較真正總成本，最好再對 provider billing 或 trace，因為從 v0.7.1 原始碼看，refiner 自己那次 LLM call 的 usage 未被寫進 RefinementResult；這是程式碼推論，不該直接當成帳單結論。

實作三：用 /refine 從失敗提取最小規則

headless run 結束後不會自動進入 TUI。用第一行 session header 的 ID 恢復原 trajectory，再讓 /refine 讀到剛才的失敗、gate output 與修正結果：

prime-agent --resume "$SESSION_ID"

進入原 session 後，不要要求「全面變聰明」，而是把作用域、證據和驗證方式講清楚：

/refine 根據剛才 cleanup eval 的失敗，建立最小的 local prompt note：
只處理任務指定根目錄；永遠保留 fixtures/ 與 .vcs-meta/；
修改前先列出候選檔，完成後必須讓固定 cleanup gate 通過。
不要改 base system prompt，也不要寫成 global 規則。

/refine 可能回傳空 edits，因為它判斷證據不足；也可能把規則分類成 memory 而不是 prompt。重點不是 entry 類型猜得漂不漂亮，而是它有沒有針對已發生的錯誤、保持 blast radius 很小，並留下可驗證 outcome。你可以在 IPython 查看目前狀態：

overview = rlm.harness.overview()
snapshot = rlm.harness.snapshot()
print(overview)

注意：rlm.harness.snapshot() 只是讀出「現在的 state dict」，不是可命名、可跳回的 checkpoint。真正可回滾的是每一筆 refinement history 保存的 before/after。

實作四：建立 A/B Eval，看成功率、Token 與時間

單次從失敗變成功，只能證明「這次修到了」，不能證明 Harness 穩定進步。最小可用實驗至少做到以下六件事：

1. 固定 5～20 個 task fixture 與成功判準；正式 scorer 放在外部 evaluator 或唯讀 mount，由 host 在每次評分前驗 checksum。
2. 固定 Prime Agent 版本、provider、model、thinking、工具、RLM depth 與四種自主預算。
3. Control 用乾淨 harness；Treatment 只多一筆目標 refinement。
4. 每個 case 從 fresh disposable clone 開始，避免前一輪檔案與對話洩漏。
5. 至少記錄 pass/fail、失敗類型、input、output、cache-read、cache-write、total、budget-counted token、wall-clock 與 provider cost。
6. 先訂 rollback 門檻，例如成功率下降、任何保護檔誤刪，或 p95 token 增加超過你可接受的比例。

因為 local refinement 只跟著原 session，跨 fresh sessions 的 A/B 可把 Control 與 Treatment 分別放進兩個隔離的 PRIME_AGENT_CODING_AGENT_DIR；只在 Treatment 的隔離目錄做一次明確的 /refine --global。此時「global」只影響那個實驗目錄，不會污染你平常的 Prime Agent 狀態；每個 rollout 仍使用全新的 repo clone。

CONTROL_AGENT_DIR="$(mktemp -d)"
TREATMENT_AGENT_DIR="$(mktemp -d)"
SOURCE_REPO="$(pwd -P)"
CALIBRATION_REPO="$(mktemp -d)/repo"
CONTROL_REPO="$(mktemp -d)/repo"
TREATMENT_REPO="$(mktemp -d)/repo"
AB_LOG_ROOT="$(mktemp -d)"

printf '%s\n' '{"autoRefine":{"enabled":false}}' \
  > "$CONTROL_AGENT_DIR/settings.json"
printf '%s\n' '{"autoRefine":{"enabled":false}}' \
  > "$TREATMENT_AGENT_DIR/settings.json"
git clone --quiet "$SOURCE_REPO" "$CALIBRATION_REPO"
git clone --quiet "$SOURCE_REPO" "$CONTROL_REPO"
git clone --quiet "$SOURCE_REPO" "$TREATMENT_REPO"

# 先在獨立 calibration clone 重現 failure，進 TUI 後執行：
(cd "$CALIBRATION_REPO" && ./reset-fixture.sh && \
  PRIME_AGENT_CODING_AGENT_DIR="$TREATMENT_AGENT_DIR" \
  RLM_MAX_DEPTH=1 prime-agent --tools ipython \
  --no-extensions --no-skills --thinking medium \
  --model "provider/model")
# /refine --global <只針對已驗證失敗的最小規則>

run_case() (
  set +e
  CASE_LABEL="$1"
  CASE_AGENT_DIR="$2"
  CASE_REPO="$3"
  CASE_LOG_DIR="$AB_LOG_ROOT/$CASE_LABEL"
  mkdir -p "$CASE_LOG_DIR"
  cd "$CASE_REPO" || exit 2
  ./reset-fixture.sh
  CASE_START="$(date +%s)"

  PRIME_AGENT_CODING_AGENT_DIR="$CASE_AGENT_DIR" \
  RLM_MAX_DEPTH=1 prime-agent --no-session --mode json \
    --tools ipython --no-extensions --no-skills --thinking medium \
    --autonomous \
    --autonomous-gate 'test "$(shasum -a 256 "$EVAL_ROOT/cleanup-eval.sh" | cut -c1-64)" = "$EVAL_SHA" && "$EVAL_ROOT/cleanup-eval.sh" "$PWD/sandbox-tree"' \
    --autonomous-gate-retries 2 \
    --autonomous-gate-timeout-ms 300000 \
    --autonomous-max-continuations 3 \
    --autonomous-max-turns 12 \
    --autonomous-max-tokens 80000 \
    --autonomous-timeout-ms 1800000 \
    --model "provider/model" \
    "清理 sandbox-tree 裡沒用的暫存檔；完成後報告驗證證據" \
    > "$CASE_LOG_DIR/events.jsonl" \
    2> "$CASE_LOG_DIR/stderr.log"
  AGENT_EXIT="$?"
  test "$(shasum -a 256 "$EVAL_ROOT/cleanup-eval.sh" | cut -c1-64)" = "$EVAL_SHA" && \
    "$EVAL_ROOT/cleanup-eval.sh" "$CASE_REPO/sandbox-tree"
  SCORE_EXIT="$?"
  CASE_ELAPSED="$(( $(date +%s) - CASE_START ))"
  printf '%s\n' "$AGENT_EXIT" > "$CASE_LOG_DIR/agent.exit"
  printf '%s\n' "$SCORE_EXIT" > "$CASE_LOG_DIR/scorer.exit"
  printf '%s\n' "$CASE_ELAPSED" > "$CASE_LOG_DIR/elapsed-seconds"
  printf '%s agent=%s scorer=%s elapsed=%ss logs=%s\n' \
    "$CASE_LABEL" "$AGENT_EXIT" "$SCORE_EXIT" \
    "$CASE_ELAPSED" "$CASE_LOG_DIR"
)

run_case control "$CONTROL_AGENT_DIR" "$CONTROL_REPO"
run_case treatment "$TREATMENT_AGENT_DIR" "$TREATMENT_REPO"

--no-session 隔離的是 persisted session，不會可靠關閉同一 process 內的 auto-refine；真正避免第三個變因的是兩個 settings.json 都明設 autoRefine.enabled:false。兩組使用同一個 run_case，所以 scorer、budgets、task 與記錄方式完全相同，只有 agent dir 與 fresh clone 不同。API key 也應來自同一組環境變數，不要各自 /login 後留下不同設定。

v0.7.1 的官方 CLI 文件未提供 prime-agent eval 指令；官方的 prime eval run 屬於另一套 Prime Verifiers／Environment 平台。一般 repo 最簡單的 eval，就是 host-controlled 測試命令加上 JSON session log。想看另一種成本型公開實測設計，可參考 Reasonix Cache Hit 與 OpenCode 成本實測。

AlphaLab 的離線 rollback probe：2/4 → 4/4 → 2/4 → 4/4

我們從官方 v0.7.1 tarball 直接呼叫 state load/save、applyRefinementProposal 與 rollback planning 路徑，再讓一個 deterministic policy evaluator 讀取 harness 文字，對四條路徑產生「delete／keep」判定。基線 2/4；加入安全規則後 4/4；再刻意套一筆「所有 *.tmp 都判為 delete」的錯誤 refinement，退回 2/4；最後依 refine_bad_001 的 before snapshot 回滾，恢復 4/4。

這次 state／rollback 程式在這台測試機耗時 1.79 ms，before/after 對照與落盤後重載都通過；它沒有真的建立或刪除 fixture 檔案。這個數字不能拿來估算實際 Agent 任務速度；模型延遲、工具呼叫、子代理與 provider 計費都不在範圍內。換句話說，我們只驗證了 Harness 的「煞車 mechanics 能動」，沒有聲稱「Agent 駕駛一定會越開越好」。

實作五：改進錯了，如何建立快照與回滾？

先從 refinement output 或 history 找到 ID，再執行：

/refine rollback refine_bad_001

這條指令會把該 refinement 的 applied edits 反序套用：原本 create 的 entry 會被刪除，原本 update／delete 的 entry 會依 before snapshot 還原，history 另記一筆 rollbackOf。回滾後立刻重跑同一組 eval；不要因命令顯示成功就停止驗證。

回滾很早的 ID 另有一個風險：它會依當時的 snapshot 直接還原，可能覆蓋同一 entry 後來的合理修改。實務上應優先立即、由新到舊回滾；先備份 harness_state.json 或讀取目前 snapshot，完成後再跑完整 eval。

最容易混淆的 4 種 Snapshot

1. Refinement before/after：可供 /refine rollback ID 反轉 Harness CRUD。
2. rlm.harness.snapshot()：只是目前狀態的 readout，不是版本 checkpoint。
3. Kernel state snapshot：用於 session crash/revival 的 best-effort 變數恢復；file handle、socket 等未必能保存，也不是使用者回滾。
4. Autonomous GitWorktreeSnapshot：記錄 status、diff 與 untracked hash，協助判斷 gate 失敗後 workspace 有沒有變；它本身不執行 restore。

因此，/refine rollback 不會救回被改壞的程式碼。專案檔案仍要靠 Git commit、worktree、容器 snapshot 或重建拋棄式 clone。先看 git status、git diff，確認範圍後再在測試 repo 內 restore；有價值的未提交工作不要直接覆蓋。

Prime Agent 的預算上限與自主執行邊界

v0.7.1 的 autonomous 預設是最多 3 次 host continuation、12 個 assistant turns、80,000 accumulated tokens 與 30 分鐘；token cap 計 input、output、cache-write，不計 cache-read。Quality gate 預設每個最多 5 分鐘、3 次 retry，但只有你明確設定 gate 才會存在。

這些是停止與成本條件，不是成功保證。Gate 只證明它實際檢查的事情；到達 token 或時間上限，也不代表任務完成。你還可以在互動 session 用 /rlm-max-depth 0 禁止後續新建遞迴子代理，或設成小整數限制委派深度；既有 child 不會因此自動停止。想理解多代理訓練與執行的差別，可延伸看 Prime Intellect 多代理 RL 分析。

最重要的安全結論：Prime Agent 不是 Security Sandbox

官方 README明確寫出：模型產生的 Python 與 project command 使用你的使用者權限執行；worker/kernel 的程序隔離是生命週期與故障管理，不是安全邊界。即使關掉部分 built-in tools，只要保留 IPython，Agent 仍可能執行 shell 與改檔。

更值得警惕的是官方自己的 Factorio 實驗：Agent 透過 RCON 規避規則後，/refine 還把有效的作弊方式固化成 skill；加入反作弊 heartbeat 後仍會發生。這個一手反例說明：系統可以很有效地改進「代理找到的策略」，卻不一定朝人真正想要的目標改進。官方 benchmark 同樣應視為 Prime Intellect 自報結果；本文沒有獨立重跑，也不把它當成教學成效。

什麼時候適合用 Prime Agent？

• 適合：任務會反覆出現、有可自動驗證的成功條件、失敗能分類，而且你願意管理 Harness 版本。
• 先小規模試：測試不完整、成本敏感、跨 repo 共用規則，或子代理很多；先 local，不要急著 global。
• 不適合直接自主跑：不受信任 repo、production credentials、高風險部署、不可逆資料操作，或成功只能靠主觀感覺。

最簡單的決策方式：如果你不能先寫出「什麼算成功、什麼必須立刻回滾」，就先不要開 continual improvement。可以先到 AlphaLab 課程補足 Agent workflow 與驗證設計，再回來做小型實驗。

Prime Agent 常見問題 FAQ

1. Prime Agent 是一個新的 AI 模型嗎？

不是。它是 Coding／Research Agent runtime 與 harness，底下仍使用你選擇的 provider/model。

2. /refine 等於 fine-tuning 嗎？

不是。它修改 supplemental prompt、memory、skill、subagent 規格，不更新模型權重。

3. 有失敗證據，/refine 就一定會改善嗎？

不一定。模型可能提錯規則、作用域過大，甚至強化錯誤目標；固定 eval 才是裁判。

4. /refine rollback 會還原被改壞的程式嗎？

不會。它只還原 Continual Harness edits；程式碼要靠 Git 或外部 checkpoint。

5. Prime Agent 本身是安全 sandbox 嗎？

不是。官方明確表示 Python 與專案命令用你的 OS 權限執行；不受信任內容要放進外部 sandbox。

6. rlm(...) 會直接回傳子代理答案嗎？

在 v0.7.1 不會。它立即回傳 child handle，結果要靠 agent_message 或檔案明確送回。

7. Prime Agent 有內建 eval 指令嗎？

v0.7.1 官方 CLI 文件未提供 prime-agent eval。一般專案可用 autonomous gate、測試命令與 JSON logs；prime eval run 是另一套 Prime Verifiers 平台。

8. 可以直接在正式 production repo 開 autonomous 嗎？

不建議。先用拋棄式 clone、最小權限、外部 sandbox、固定 gate 與嚴格預算；確認可回復後再逐步擴大。

給新手的 7 個重點

1. Prime Agent 改 Harness，不是訓練模型權重。
2. RLM 管執行與分工；Continual Harness 管可編輯的持久資產。
3. v0.7.1 的 rlm(...) 回傳 handle，child 要明確送回結果。
4. /refine 提出候選規則，外部 eval 才能證明是否進步。
5. local refinement 優先；只有真正跨 session 穩定的規則才考慮 global。
6. /refine rollback 只回復 Harness，Git／外部 checkpoint 才回復檔案。
7. 預算與 gate 不是 security sandbox；最小權限與拋棄式環境不能省。