All Posts
The complete archive.
Every post on the blog, newest first.
Part 5 — QM 深度解析(五):Sandbox、Skills、Cron 與部署 — 讓 Agent 擁有一台持久的電腦
拆解 QM 的持久化能力:三種沙箱後端與能力損失偵測、Skills 的簽章與 git pack 匯入、Cron 的 leader lease 與收件人同意、三種記憶策略的抽取 prompt,以及部署目錄與私有 fork 兩種客製路線。
Part 4 — QM 深度解析(四):安全模型 — 三種 Posture、命令政策與誠實的威脅模型
拆解 QM 的分層防禦:三種 security posture 如何組合、命令政策的 scannableCommand 如何遞迴拆解八層 shell 混淆、ReDoS 防護的自製 regex 編譯器、內容篩檢分類器的分塊與重試,以及三個「刻意不給 Agent」的動作與 12 條誠實列出的已知限制。
Part 3 — QM 深度解析(三):Harness 抽象 — 一套核心驅動四種 Agent 引擎
拆解 QM 如何讓 Pi、OpenCode、Codex、Claude Code 四種完全不同的 Agent 引擎驅動同一個核心:Harness 契約的三軸能力宣告、60 欄位的 HarnessTurnInput 依賴注入、Entries 與 Tape 雙軌重放、context 壓縮的 throughSeq 錨點,以及 runtime 選擇的三層繼承。
Part 2 — QM 深度解析(二):Scope 與 Resolution — 一次對話如何解析出身分、權限與工作區
拆解 QM 多人隔離的核心:五種 ScopeId、workspace 分層掛載、soul 指令的不可覆寫疊層、audience floor 如何用「受眾交集」防止頻道洩漏、ACL grant 變成 shared/ handle,以及 session 租約與 tape 雙軌記錄。
Part 1 — QM 深度解析(一):多人協作 Agent 平台的架構全景
拆解 yc-software/qm — 一個為公司而非個人設計的開源 Agent 平台。從「每個人一個隔離工作區」的核心命題出發,看懂它的無頭核心 + 外掛式介面架構、76K 行 TypeScript 的目錄分工,以及一次 Slack 對話如何走完整條路徑。
Part 5 — OpenWorker 深度解析(五):能力擴充 — Tools、Skills、Personas、MCP 與排程
拆解 OpenWorker 的五層能力擴充體系:ToolRegistry 與封閉式 Capability 目錄、Persona 作為資料而非程式碼、Skills 的漸進式揭露、explore 子代理的 context 隔離、MCP 客戶端的單任務生命週期,以及排程器的 catch-up 與 skip-on-overlap 策略。
Part 4 — OpenWorker 深度解析(四):LLM 層 — Provider 抽象、能力降級與 Context 自動壓縮
拆解 OpenWorker 如何同時支援 OpenAI、Anthropic、Gemini、Bedrock、Vertex、Ollama 與多家轉售商:ProviderClient 契約為何刻意同步且無迴圈、能力矩陣如何驅動 vision/PDF 降級、TokenUsage 的快取拆分,以及 561 行 compaction.py 的完整壓縮演算法。
Part 3 — OpenWorker 深度解析(三):Harness — 權限模型、Inbox 與人機協作
拆解 OpenWorker 的安全外殼:58 行的 RiskClass 如何撐起整個權限系統、五種執行模式的決策流程、shell allowlist 的前綴比對陷阱、跨 session 的 Inbox 決策佇列與 durable resume,以及 SSRF 防護、prompt injection 防線與稽核軌跡。
Part 2 — OpenWorker 深度解析(二):TurnEngine — Agent 迴圈的完整解剖
逐行拆解 OpenWorker 的 1192 行 agent 迴圈:訊息的真實形狀、blocking provider 如何橋接到 async loop、工具呼叫的授權與併發分流、四種中斷狀態下的「不留孤兒 tool_call」不變式,以及 canonical history 與 outbound view 的分離設計。
Part 11 — AIO / GEO - Part 11 - 商業化:市場長什麼樣、誰在買、誰在賣
把 GEO 當生意做之前,先看清楚市場。本篇拆解需求端與供給端、服務型態與毛利結構,並誠實處理一件事:關於 GEO 的市場數據,絕大多數是賣 GEO 的人寫的。附三種可行的商業定位與風險清單。
Part 1 — OpenWorker 深度解析(一):架構全景 — 一個能交付成果的桌面 AI 同事
從零拆解 Andrew Ng 團隊的開源專案 OpenWorker:它為什麼強調「交付成果而非聊天」、三層本地優先架構如何組成、37000 行 Python 後端的目錄職責分工,以及一次任務從輸入到產出的完整生命週期。
Part 10 — AIO / GEO - Part 10 - 實戰案例:私有 Repo 與內部知識庫(把 GEO 反過來用)
最後一個案例沒有搜尋引擎。一家 400 人公司把 GEO 的原則用在自己的內部 AI 助手上——私有 repo、Confluence、Slack 全接進 RAG,答案卻錯得離譜。診斷結果和公開網站一模一樣:內容不是不存在,是不可引用。
Part 9 — AIO / GEO - Part 9 - 實戰案例:線上課程平台(付費牆 + 影片內容)
一個 8,000 名付費學員的線上課程平台,跑在 GCP Cloud Run 上。內容 90% 是影片、且全在付費牆後——這是 GEO 最困難的組合。看付費牆怎麼分層、影片怎麼變成可引用文字,以及「開放多少才不會傷害營收」的實測。
Part 8 — AIO / GEO - Part 8 - 實戰案例:單頁式 Landing Page(內容只有 800 字)
一個 3 人團隊的 SaaS 產品,全站只有一頁 Landing Page 加一份文件。內容量是最小的,資源也是最少的——這反而讓「該做什麼、不該做什麼」變得極度清楚。從 0 到被引用的 8 週實錄。
Part 7 — AIO / GEO - Part 7 - 實戰案例:電商網站(12,000 SKU + 價格新鮮度)
一家台灣戶外用品電商,12,000 個 SKU、跑在 Vercel + Shopify Headless 上。電商 GEO 的兩個獨有難題:長尾商品頁怎麼模板化才不變成薄內容,以及價格與庫存怎麼讓模型抓到最新的。
Part 6 — AIO / GEO - Part 6 - 實戰案例:大型企業官網(多語系 + AWS + 法遵)
一家 3,000 人製造業集團的六語系官網,跑在 AWS CloudFront + WAF 上。看 GEO 在大企業環境的真正瓶頸:不是技術,是治理。附 WAF 規則、hreflang 與實體一致性的實作。
Part 5 — AIO / GEO - Part 5 - 量測與案例篇:建立監測系統與六個月實戰復盤
GEO 的最後一哩:設計 prompt set、用 Python 建置多引擎引用監測系統、計算 AI Visibility Score、從伺服器日誌與 GA4 辨識 AI 流量,最後以一個 B2B SaaS 站的六個月完整復盤(含失敗的部分)與 ROI 試算收尾。
Part 4 — AIO / GEO - Part 4 - 實作篇:把一個網站改造成 AI 可引用
八個步驟的完整實作:AI crawler 存取層與 CDN 白名單、llms.txt 產生器、JSON-LD 自動注入、chunk 邊界工程、Markdown 雙軌輸出、SSR 決策樹,附 Hugo / Next.js 可直接複製的程式碼與可放進 CI 的自動化驗收腳本。
Part 3 — AIO / GEO - Part 3 - 方法篇:內容、結構、技術三層優化策略
把 GEO 拆成內容層、結構層、技術層與實體層四個可執行的工作面:可引用性寫作的九條規則、Schema.org / JSON-LD 完整配方、Entity SEO 與站外一致性,最後給出影響 × 成本優先矩陣與 90 天執行路線圖。
Part 2 — AIO / GEO - Part 2 - 原理篇:AI 引擎如何檢索、選擇與引用你的內容
拆解生成式引擎的檢索管線:AI crawler 名單與行為差異、內容如何被切成 chunk、rerank 階段淘汰了什麼、grounding 如何決定引用誰。附 8 個讓頁面永遠不被引用的技術死因與逐項診斷方法。
Part 1 — AIO / GEO - Part 1 - 概念篇:當搜尋結果不再是十條藍色連結
AIO(AI Overview)與 GEO(Generative Engine Optimization)到底在優化什麼?本篇釐清 SEO / AEO / GEO / LLMO 的定義邊界,拆解生成式引擎產生答案的內部流程,並提出一套從 Ranking 思維轉向 Citation Share 思維的可見度指標與成熟度模型。
AI System on Native AWS - Part 10 - 企業 AI 平台工程
系列終章。當一個企業有幾十個團隊、上百個 AI 專案時,讓每個團隊各自接 Bedrock、各自寫 CDK、各自處理合規,是災難。平台團隊要把前九篇的能力打包成『內部產品』:多帳號落地區(Control Tower)、統一的 LLM Gateway(集中路由/限流/快取/日誌/分帳)、Service Catalog 與可重用 CDK Construct 黃金路徑、FinOps 分帳、平台級可觀測性。全部用 CDK(CloudFormation)描述,並以一張橫跨 Part 1–10 的總表收束整個系列。
AI System on Native AWS - Part 9 - 企業 AI 安全、合規與資料治理
當 AI 系統處理的是病歷、金流、個資,而且要通過稽核時,資安與合規不是加分項而是上線的門票。本篇把這個橫跨所有系統的維度單獨講透:用 PrivateLink/VPC endpoint 讓資料永不觸網、KMS 客戶金鑰全程加密、Macie + Comprehend 做 PII 偵測與去識別化、Lake Formation 做資料湖細粒度授權、Organizations SCP 從組織層鎖死可用模型與區域、CloudTrail + Guardrails 做全鏈稽核,全部用 CDK(CloudFormation)描述,對應 HIPAA/GDPR 的實際控制點。
AI System on Native AWS - Part 8 - 即時串流 ML 與詐欺偵測
詐欺偵測是即時 ML 的極限測試:要在幾十毫秒內對每筆交易做出放行或攔截的決定,特徵要用『此刻及過去幾秒』的行為即時算出,對手還會主動規避你的規則。本篇用純 AWS 原生服務打造即時串流風控:Kinesis 收交易流、Managed Service for Apache Flink 做串流特徵、SageMaker/Fraud Detector 毫秒級評分、Neptune 圖資料庫抓詐欺團夥、DynamoDB 當線上特徵與決策存放,全部用 CDK(CloudFormation)描述,深入談串流特徵一致性、時間窗、圖偵測與規則+ML 混合決策。
AI System on Native AWS - Part 7 - 基礎模型客製化與模型治理
當通用模型不夠好、或你有大量專有資料想讓模型內化時,就得客製基礎模型。但企業真正的難題不是『怎麼 fine-tune』,而是『如何治理』——訓練資料哪來的、評估過了沒、誰核准上線、出問題能不能回溯。本篇用純 AWS 原生服務打造一條可治理的模型客製管線:RAG/Prompt/Fine-tune/蒸餾的決策框架、資料準備、Bedrock 客製模型與 SageMaker 微調、Model Registry、自動評估關卡、Model Cards 與審批工作流,全部用 CDK(CloudFormation)描述。