如何免費使用 LLM:OpenCode 2 內建模型與 OpenRouter 入門教學
安裝 OpenCode 2 後,先直接選用內建免費模型,完成第一個生活小任務;想換更多模型或在自己的程式呼叫免費 API,再接 OpenRouter。
安裝 OpenCode 2 後,先直接選用內建免費模型,完成第一個生活小任務;想換更多模型或在自己的程式呼叫免費 API,再接 OpenRouter。
LLM 寫作有四個常見通病:否定式對比(先駁倒沒人說過的 X)、意義抬高(把普通事實包成轉折)、指示型摘要(只說談什麼、不給結論)、過度概括(摘要丟掉條件與範圍);前三個刪空話、直接寫答案,第四個拿原文逐句對。否定式對比已追到訓練用的偏好資料,模型修訂稿時還會把它換成另一種對比句型,所以只在 prompt 禁字未必擋得住。
對每一句否定式對比問兩件事:讀者心裡真的有 X 嗎?否定 X 會讓讀者多知道什麼嗎?任一個沒有,就刪掉 X 直接寫 Y。NLP 論文的 rather than 從 2019 到 2026 年變成約 7 倍,五個商用模型寫中文時,這類句式的密度是人類參考語料的 2.5–9.2 倍;模型幾乎沒用錯,但一半以上可有可無,一篇用了八次,總有一句會讓讀者煩。
已有 harness 就用 PiHarness;做 chat、要自己組模型呼叫用 AIChatAgent,交給框架用 Think;不是 chat 但要狀態、排程、MCP,用 Agent。
兩小時的課程影片約 72 萬 token,Gemini 的 API 收得下,Claude 與 ChatGPT 的 API 文件沒有列影片輸入;程式碼這條線 Claude 與 GPT 在 Vals 榜上只差 0.8 分,該比的是速度與成本;X 輿情與代填結帳找 Grok,現成 App 與語音找 ChatGPT。
偵測與稽核工具是一條光譜:Uber ADR 的開源版純事後讀紀錄,numbat 預設只監控,其餘多半賣點是能在動作前擋,預設卻先只觀察。紀錄能不能當證據,取決於誰能改它:簽章金鑰和被稽核的 agent 同機同使用者時,只能發現竄改,不能防止竄改。
護欄在 agent 動作之前攔截。Claude Code 上的主要接點 hook,官方文件寫明大多數事件上出錯或逾時會照常執行,要擋得設 onFailure: block。別的工具各有各的出錯行為與預設:Agent Governance Toolkit 的函式庫沒載入政策時放行,NeMo 的偵測器連不上時放行,llm-guard 與 rebuff 已封存。選護欄先問三件事:攔在哪、掛了怎樣、誰能改規則。
容器共用 host 核心,gVisor 在中間插一個使用者空間核心,microVM 多一個 guest 核心加 hypervisor;三種都還共用同一台 host 的 CPU 快取與儲存。
兩個互不連線的程式可以靠共用資源的快慢傳位元:一方改變資源狀態,另一方計時。這類通道要先約好協定,速度慢、容易被雜訊蓋掉;本機實驗在 20 bps 以下幾乎全對,100 bps 以上錯誤明顯增加。
沒有任何一項防守同時擋住旁路通道與出口。擋通道的核心是不共用,擋出口的核心是收窄被放行的服務,監控只負責發現,自動停止是事後回應,兩者都不是預防。
沙盒沒有直連網路,不代表沒有出口:套件代理、DNS 解析器、metrics 服務這類被放行的服務,只要能替人發請求就是出口。OpenAI 的三個案例都是這個形狀。
OpenAI 自述紅隊 agent 在共用主機上用快取、儲存、CPU 時間與 TLS 憑證快取做出通訊管道,多數通道很慢;多數測試被指定了通道或給了協定,頻寬與錯誤率沒有公開。
一段 agent 程式碼從執行到連線會穿過五層:容器、核心邊界、共用主機、網路邊界、監控。每層只承諾一件事,共用主機這層幾乎沒有承諾。
依我的判斷,OpenAI 談的是訓練前沿模型的研究環境;個人 agent 最該先做的是限制憑證與出口,旁路通道要到有第二個需要被隔離的租戶時才變成主要風險。
我把 agent 沙箱分成四種:共用核心的作業系統隔離、容器編排、本機 microVM(輕量虛擬機)、遠端 microVM。Claude Code 的沙箱預設關閉、只包 shell 指令;Codex CLI 本機預設開啟。公開的逃逸案例多半繞過邊界旁邊的設定檔或檢查腳本,不是打穿核心;沙箱回答的是被騙之後能走多遠,不是會不會被騙。用 Claude Code 的話,先開沙箱,再把 ~/.ssh、~/.aws 列進拒絕清單,並另外擋住 Read 工具。
裝 skill、接 MCP、讓 agent 跑指令時,風險可以看成從四個入口進來。我把相關的開源防護工具依介入的時間點分成七類,從安裝前掃描、沙箱、護欄到稽核與紅隊測試。這一篇先看每一類管哪一段,以及三個反覆出現的限制:沒有單一工具能獨當防線、預設值常常對你不利、公開的偵測數字缺少獨立評測。
AI 滲透工具把 LLM 當攻擊者,去測傳統軟體。它們有兩個共通問題:工具本身是攻擊面(被測目標可以用 prompt injection 反控它,HexStrike 的伺服器甚至沒有驗證),以及開源之後管不住用途(同一個工具既能做授權測試也能被拿去攻擊,ARTEX 與 HexStrike 的防濫用設定都是操作者可以改的預設值)。讀「某工具被濫用」的新聞,要問誰說的、是不是獨立的證據。ARTEX 事件有多家廠商分析,但其中幾家分析的是重疊的攻擊者基礎設施,或直接引用彼此,不能算成多個獨立證據。
King 與 Worthington 拿 124 篇稿件的 134 份付費專家預審,對照 Claude Opus 4.8 的審查:GPT-5.5 評審的 132 組有定論配對全選 AI,3 位前任編輯在 30 次判斷中選了 26 次。結論只適用於投稿前的建設性意見,不等於期刊審查。
兩份都寫「攻擊成功率 5%」的報告不能直接比:數字背後有誰出題(攻擊者模型)、誰判定(judge,負責判定的模型或規則)、分母算什麼三個變數。garak 官方 FAQ 說自己的分數沒有科學效度,HackAgent 白皮書裡兩個模型的先後會隨 judge 門檻翻轉。我查到的資料裡,四個工具都沒有獨立的準確度評測。
兩個代表的做法相反:Cloudflare 的 security-audit skill 是純 LLM 的多階段流程,Cloudflare 說他們內部的 harness 接了 Semgrep 之後,獵捕用的 agent 一個月都沒呼叫;Trail of Bits 則是 Semgrep、CodeQL 腳本加 LLM 判斷。我在兩者的規則與附檔裡都找不到 Workers、D1、KV 或 Astro 的專屬檢查,兩者也都沒有公開在真實專案上的準確率。這篇只讀了文件,沒有對任何專案試跑。