Llm-Agent

OpenAI 在 4 月 15 日更新了 Agents SDK，加入了 sandbox 隔離、Harness/compute 分離、Manifest 工作區描述、Capabilities 分層。看完技術文件後我的第一反應是「這跟我們在做的事情不一樣」，第二反應是「但裡面有幾個結構性概念可以偷」。 這篇記錄我們從中借了什麼、怎麼落地到 openclaw-workspace-template v3.0.0，以及為什麼大部分東西我們選擇不抄。 兩個系統的定位差異 先把前提講清楚：OpenAI Agents SDK 跟我們的 workspace template 解決的是完全不同的問題。 OpenAI Agents SDK 我們的 workspace template 目標使用者 企業，多租戶 SaaS 個人，單使用者 執行環境 雲端 sandbox（Modal / E2B / Cloudflare / Vercel） 本機 Mac / Linux，直接 filesystem access 權限模型 Tool calls 在 unprivileged container 裡跑，隔離網路和 secret 跟使用者同權限，能碰 git / cron / Telegram / Obsidian State serialize_session_state() / resume()，snapshot 整個 workspace 檔案系統就是 state，git 就是 snapshot Memory 內建 Memory() capability，session close 自動 summarize → consolidate 自建 MemPalace：hall-tagged journal + 主題筆記 + weekly reflection + knowledge graph OpenAI 在解的是「怎麼讓 agent 安全可靠地跑在生產環境」。我們在解的是「怎麼讓一個人的知識和自動化系統持續累積和整合」。拿來直接比就像比 AWS Lambda 跟家裡的 crontab。 ...

給 LLM agent 用的記憶系統寫了半年，最後發現自己打開次數最多的不是 MEMORY.md 或主題筆記，而是 memory/YYYY-MM-DD.md 這份逐日 journal。日常查的也多半是「上次搞 PostgreSQL 是什麼時候」「那個 config 的決定寫在哪天」這種問題。 問題是：搜尋它不太好用。 grep 噪音太多。半年的 journal 把任何常用詞炸出幾百個 hit。 embedding-only 搜尋對 journal 不適合。journal 裡面多半是兩三行的短 entry，embedding 模型給短句的向量區分度不夠；而且 journal 每天長，每次 incremental embed 都要算 hash、做 rate limit、管 cache，出錯就是一整天的記憶搜不到。 最關鍵的是，journal 是本質上有時間性的資料。我問「上次搞 PostgreSQL 是什麼時候」，語意相似度幫不上忙，時間才是主角。 所以我把 journal 搜尋重新當成一個 ranking 問題，用三個分數軸融合：keyword overlap × temporal recency × hall-type boost。Python 不到 130 行，沒有外部依賴。 這篇記錄設計過程、實測結果，還有一個在 bootstrap 測試時才發現的 case-sensitivity bug。 為什麼不直接用 embedding 先說清楚：embedding 不是沒用。我自己在 notes/ 的相關筆記推薦也還是用 embedding 跑 cron。問題是把它用在 journal 搜尋上有幾個具體的不匹配： ...