積沙成塔，滴水穿石

  AI 策略分析

 自從開始在教小朋友後，成為老師這個腳色也是一種學習。 如何與他們相處、如何和他們有話題、如何破冰、在他們身上會看到自我的反射。 你的一舉一動、你說出來的話，會戴上了放大鏡。 我也很常叫錯學生的名字，發生一些笑話。 有堂課有位同學在拆解積木的時候，會亂丟甚至會亂甩 我：「瑞宇，這樣的行為很危險，不能這樣做，東西要好好放，如果掉到地上，你不小心踩到，滑倒是會受傷的！」 學生：「老師，我不是瑞宇，我是瑞凡」 我：「😂😂 拍謝，可是瑞凡~我回不去了」 帶小朋友很開心也很快樂，也同樣是學習相處之道，如何說話讓小朋友聽得懂，不是一直說不行，而是要讓對方明白這樣做的處境+後果

Risk Engine 概念（核心定義） Risk Engine = 一個把「AI 的可信度」從主觀語言，轉換成可驗證、可計算、可阻斷的決策系統 它不是模型，也不是 prompt，而是： 一個位於 AI Worker 與 Git / 系統執行之間的「信任閘門（Trust Gate）」 Risk Engine 的作用是： 把「AI 說它做了什麼」變成「系統驗證它做了什麼」，再決定要不要讓它進入 production。  AI Agent 系統的問題不是「會不會寫錯 code」，而是：沒有人真的「驗證現實」

 最近設計了以git worktree為基底的多工agent 合作的模式，git worktree 的概念讓每個branch 有自己的空間，不會互相汙染branch，在這樣的方式下每個agent 有自己的branch 可做事，不會互相汙染和複製多份共有的大型圖片，參考GIT LFS概念用硬連結的方式來做指向，在不同的worktree 能將大型資源指向master 的位置 。 我自己的個人習慣是多工agent 來進行開發，每個agent 都是一個小組長，agent 各有自己所屬的分支。 換句話說 各自agent 不打架。 master AI (claude)  > master  sub agent (codex)  > chore  sub agent (grok)  > fix   效果還不錯，再搭配agent branch 調度管理器 Dispatch的workflow ，能同時管理多分支狀況。 一開始約束規則沒寫好，每個agent 在更新git 有的時候會切錯worktree branch。 git branch 的保護守則要寫好 ，可用 branch rule先做一層防護 pre-push、pre-commit。 遵守 master 只做合，不做任何更新、異動commit，可以確保 master（或 main）分支始終保持乾淨、穩定，且直接對應到上線的程式碼。

Architecture · AI Agent · Git Worktree-based Runtime Orchestrator for Multi-Agent Development 當多個 AI Agent 同時在同一個 repository 開工，傳統的 git 分支切換模式開始崩潰。 這篇文章介紹一套以 Git Worktree 為核心的開發流調度規範——用三個平面解耦邏輯、資產與 Runtime， 讓每個 Agent 擁有獨立的物理工作空間，同時共享同一個執行環境。 🗂️ Git Worktree Architecture ⚡ Runtime Orchestration 🤖 Multi-Agent Dev 1. 問題是怎麼來的 當工作流開始用 worktree 做多工處理，在做 git 追蹤的時候，多工 agent 就會遇到 branch 環境污染的問題。 想像四個 Agent 同時在跑： A agent → fix/something_wrong B agent → chore/design_system C agent → feat/realtime-sync-design D agent → doc/readme 在同一個 workspace 做 git checkout ，就會造成環境混亂——AI 的路徑索引失效、任務互相干擾、 Docker 需要重啟。這就是 Git Worktree 派上用場的地方。 git worktree allows you to have multiple branches of the same repository checked out simultaneously in separate directories。 換句話說，每個 Agent 有自己的實驗室，不用擔心互相影響， 只需存新工作目錄的檔案，不需...

 剛好拿到了新的model - MIMO v2.5 PRO 在試用，就用它做一個小產品observability-tool。 observability-tool 觀測 ------------------------------------------////**題目要求**///---------------------------------- 以下 請使用環境為 php 7.2.34 composer 1.10.15 Project - Server ∙ 功能 1 ： 設定 webhook /setWebhook?url=${url} ∙ 功能 2 ： 每 1-15( 隨機 ) 秒傳送一筆訊息訊息內容為 {"text": "Something is wrong", "env": "A1"} ∙ 功能 3 ： 設定功能 2 觸發測試 /setTesting?test=true ， 此設定會將秒數固定為 7 秒、設定為 false 則取消固定 7 秒 ∙ 功能 4 ： 功能 2 中的 env 共有三種 A1, A2, A3 頻率不可相同 ， 若遇隨機相同時可忽略 Project – Client ( 設定為 Server Webhook 對象 ) ∙ 功能 1 ： 以 env 為單位 ， 若 7 秒 ( 包含 7 秒 ) 內收到 {"text": "Something is wrong", "env": "A1"} 連續 5 分鐘後收取將跳出一個 Telegram 通知 ， 通知須顯示時間、 Env 、 text ∙ 功能 2 ： 根據功能 1 需具有插隊功能範例 :{"text": "Something is wrong", "time": "2025-12-31 23:59:59"} 。若插隊導致可觸發功能 1 時後續皆會觸發 ∙ 功能3 ： 需具有頁面查詢所有request並且查詢內容及時間 <備註> for Project – Client 功能1 -Tel...

問題 1：Channel denied access based on given capability 現象：Ably 訂閱被拒絕，401 錯誤。 根本原因：Channel 命名格式錯誤。 ❌ 錯誤：env-{env_id}   → capability: env-* ✅ 正確：env:{env_id}   → capability: env:* Ably 的 wildcard capability 只支援冒號分隔，env-* 是非法格式，Ably 伺服器無法匹配，每個訂閱都被拒絕。 解法：把所有 channel 命名和 capability 從 - 改成 :。 問題 2：PHP SDK v1 createTokenRequest + JS SDK v2 不相容 現象：Token 格式問題，authCallback 各種嘗試都失敗。 根本原因：JS SDK v2 移除了 callback-based API，authCallback(tokenParams, callback) 的 callback 方式在 v2 已不支援，必須用 Promise 或 authUrl。 解法：改用 authUrl 方式讓 Ably SDK 自己打後端取 Token，繞過 callback 格式問題。 問題 3：authUrl 打後端時沒有帶 X-UI-Key header 現象：authUrl 設定了 authHeaders，但 Ably SDK 不保證每次都帶，導致後端 401。 解法：把 /api/ably-token 從 UI_KEY 驗證中移除，TokenRequest 本身有 HMAC 簽名保護，就算公開也只能 subscribe，不能 publish。 問題 4：requestToken vs createTokenRequest 現象：試用 PHP requestToken 產生 TokenDetails，Ably REST 回 201 但 JS SDK 還是連不上。 根本原因：PHP SDK v1.1 的 requestToken 產生的 TokenDetails 格式，JS SDK v2 無法直接使用。 解法：改回 createTokenRequest（產生 TokenRequest），讓 Ably SDK 自己去換 Toke...

我用了一個新專案，用xiaomi mimo-v2.5-pro 來開始專案。 就做了一個簡易的cmd 介面: 百萬億申請token 過了之後，用的是tp- 開頭的金鑰，api 後台:  https://platform.xiaomimimo.com/console/plan-manage 之前有用到sk，那個就是要費用的，那百萬億計畫token 用的是tp   目前用下來~~ 還算很順，很快😄 用roo 的方式 ，很快。roo 的麻煩是 有的時候 聊天室窗的對話模式 會多開視窗混淆。 多開視窗 同時間 code、architect 的時候，另一邊就有可能產生卡點。 使用roo +MiMo  ，再讓他調取 mimo-cli 他會等cli 執行完 才會繼續進行任務，無法在使用roo 中 做平行 ---- 用了MiMo  5hr 之後 發現他的效能比意外還要好。 目前用了codex，要用0.80 版

今天有人和我提了一下ulimit，做一下卡片式的筆記。   https://q248269673.pixnet.net/blog/posts/12066596238 https://www.mongodb.com/zh-cn/docs/v8.0/reference/ulimit/ https://www.runoob.com/linux/linux-comm-ulimit.html