jolestar

暑假裡給兩個娃電腦上都裝了 Coding agent，我觀察他們怎麼玩。
哥哥有 Scratch 程式設計經驗，有自己的想法，做過一些有創意的 Scratch 遊戲。他玩了幾次後就放棄讓 AI 直接生成應用程式了，主要理由是 AI 生成的不是他想要的，他腦子裡的想法給 AI 也說不清楚。還有，他感覺 AI 做的東西不是自己做的，找不到創作的感覺。
他最後的做法是讓 AI 修改他的 Scratch 檔案。Scratch 是拖曳式程式設計，檔案格式不是為純文字編輯而設計的，AI 改起來很吃力。但他玩得也自得其樂，還讓 AI 幫他做 Scratch 多人連線。我說 Scratch 已經限制了他的發揮空間，但他還是覺得生成的東西自己能看懂會更有掌控感。
弟弟還沒有形成那麼明確的創作目標，更容易接受 AI 給出的結果，生成什麼玩什麼，但又很難定義他在學程式設計。
AI 時代還需要學程式設計嗎？如果要學，學的到底是什麼？哥哥要的是掌控和創造的感覺，弟弟享受的是結果本身——哪一種才算"在學程式設計"，我也一直在思考這個問題，下次單獨寫寫。

用多了 AI 後發現自己不太愛說話，包括網路上，好久沒發過推文了。
以前古法寫程式，程式碼寫多了會覺得憋得慌，於是會寫寫文章，在群裡閒聊。但用了 AI 後，寫程式就是閒聊了，輸出的配額似乎被用完了，沒有輸出的慾望了。
和人聊天也沒有了耐心，剛聊兩句，我就想說：「你還是去和 AI 聊一下吧」，或者「我還是去和 AI 聊一下吧」。
但這樣久了感覺也不對，尤其是在家寫程式，整天也沒人交流，網路上不活躍就和隱居似的。接下來要逼迫自己活躍一下，或者組織一些線下的交流活動了。

GPT 的訂閱莫名其妙被 Google play 取消了，現在 android 版本的 GPT 上似乎麼有訂閱入口了？有人遇到類似的問題嗎？

holon v0.19.0 發布了
這個版本 內置了一套 web UI，同時也把底層存儲系統重構了一遍，api 和 event 系統重構了一遍，填了許多 AI 挖的坑。
原來用的是 JSONL，數據量大了後就很難維護。疊加上 AI 編程習慣是 grep 然後發現沒有就加，導致有很多 api 和 event 冗餘。
於是全弄到 sqlite 數據庫中了，結果沒想到積累到數據已經很大了，數據庫超過了 4G，遇到了性能問題，於是繼續優化，現在這個版本算穩定了。
歡迎大家嘗試，Web UI 略微簡陋，但 holon 的模式是同一套接口，支持 tui 和 web ui，看到的 agent 的視圖是一致的。

codex 裝置令牌登錄突然要驗證手機號碼了？而且發現 openai 的手機號碼在帳戶設定裡找不到呀？改都似乎沒地方改。

Agent 需要什麼樣的基礎工具集
看到大家在聊 Agent 工具集的問題——是不是提供一個 shell 就都搞定了？做了 holon 之後發現，其實沒有那麼簡單。
讀：為什麼放棄了 Read/Glob，全走 shell
holon 的工具集改了幾個版本，最後廢棄了類似 Claude Code 提供的 Read（讀檔案）、Glob（模式搜尋）這類專用工具，讀取和查找全部通過 shell 來完成。這和 Codex 的路線一致——Codex 的 ExecCommand 一把梭，讀檔就是 cat，搜程式碼就是 rg，不再單獨為每種"讀"操作定義一個工具。
這樣做的理由很樸素：shell 是 LLM 最熟悉的"程式語言"。與其讓模型去學你定義的 Read 工具的參數語義，不如直接讓它寫已經訓練了數十億次的 shell 命令。每多一個專用工具，模型的認知負擔就加一層；而 shell 這個界面，模型已經足夠熟練了。
但全走 shell 有一個代價：輸出截斷。框架為了避免 shell 返回值太長撐爆上下文，會給每個命令設輸出上限。Agent 用 cat 讀一個大檔案，可能只拿到前半截，剩下的在 artifact 檔案裡，還得再 cat 一次甚至多次才能讀完。Claude Code 的 Read 工具壓縮閾值比通用 shell 高很多，讀大檔一步到位，少了好幾個來回。本質上是取

和 gpt 交流多了后，自己也习惯用“收口”这个词了。一些任务完成后，但还有一些零碎的事情没搞，告诉它把剩下的事情收口，感觉很自然。我都忘了不用收口这个词之前是咋表达的😅。

AI 編碼時代，良好的編程習慣仍然重要
最近做一個 Agent 基準測試，發現不能簡單地用開發者視角來評估一個編程任務對 AI 的複雜度。
比如一個重構任務：把一個幾千行的大文件，按功能拆成十多個小模組。
這個任務對開發者來說其實不算難，主要工作就是移動代碼、整理 imports、編譯驗證，新手也能搞定。
所以想到用一個簡單的任務來做一下基準，結果卻出乎意料。
Claude Code 判斷這個任務比較大，嘗試拆了一部分，提了個 PR 寫了 Future work 打算分步來。
我自己的 Agent 是“硬上”，往完整拆分的方向推進了更多，但代價也很明顯：Token 消耗是 Claude 的幾十倍，後面大量時間都花在反覆讀文件、修編譯錯誤、再讀文件、再修錯誤上。
這讓我意識到，人覺得簡單的任務，對 Agent 不一定簡單。
對人來說，這類重構很多時候就是“把這一段挪過去”。但對 Agent 來說，它要先分批讀大文件，記住哪些函數和哪些測試有關，再生成一堆跨文件修改，最後通過編譯錯誤一點點補洞。看起來像機械活，實際變成了一個高 Token、高狀態管理成本的任務。
前一段時間看到有人說，AI Coding 時代，拆分模組這些編程原則沒那麼重要了，反正人也不看代碼。現在看，我不太同意。模組邊界清楚、文件粒度合適、依賴關係簡單，不只是方便人讀，也是在幫 A

看到兩個 Agent 的 PR 交互，挺有意思。
dev agent 完成了一個優化 ci 的 issue 提交了 PR。
reviewer agent 發現有一個超時預設值的修改，認為不符合 issue 範圍，拒絕了。
dev agent 把那個超時預設值給去掉，結果 ci 過不去，一個測試 case 報錯。它就修改了一下測試中的 sleep 時長，讓測試通過。
reviewer agent 認為這個測試就測的是異步任務超時取消的場景，改了後等於沒測，因此再次拒絕。
dev agent 嘗試去修那個測試，發現不好修，於是給測試加了個 skip，然後說這個測試本來就跑不過去，原來的 ci 沒有覆蓋，這次改 ci 覆蓋了進來，先跳過。
reviewer 最後還是給合併了進去。
真的和人挺像的，會偷懶，盡量簡單的途徑😅。前一段時間也討論過 AI Agent 是否應該分角色，因為它基本是全能的。但現在感覺還是需要的，因為角色可以承擔職責，職責會影響優先級判斷和行為。

發現在讓 AI 設計 Agent 類產品時，AI 往往低估 Agent 的能力，所以會設計很多程式碼或者提示詞的約束條件，導致 Agent 的自由度不夠，顯得很死板。後來想了一下，可能和目前 AI 訓練的材料是大家使用上一代 AI 的經驗有關係？

讓兩個 Agent 協作，developer 提交 PR，architector 負責 review 以及合併 PR。讓它們通過訂閱 github 事件 觸發操作。但由於它們兩個都用的是我的帳號，經常會被認為是自己發的而被過濾掉。得為 Agent 註冊專門的 Github 帳號了，以後網路服務都應該提供快速建立 Agent 帳號的功能。大家現在是怎麼搞多 Agent 協作的？

讓 Codex 做一個工具，給 iterm 中運行的 Codex 發消息。工具做出來，但發消息只能寫到輸入框，無法發送。嘗試了字符串拼接 "
\r" 各種組合，不行。
然後我讓它拉下來 iterm 的源碼看了一遍，網上搜索了一遍，最後得出結論也是不行。
iterm 提供的接口只能發送 text，不能直接發送鍵盤事件，所以沒辦法實現發送。勸我只支持 tmux，放棄 iterm。
我不死心，自己又試驗了幾次，結果發現發送文本後，單獨發送一個 “\r” 就可以😅。

UXC v0.13.1 正式發布
本次發布匯總了 v0.13.x 兩個版本的更新，使 UXC 在遠程工具的穩定運行時（Runtime）體驗上更進了一步。
核心功能：
1. 支援直接生成 TypeScript 客戶端程式碼在命令列中探索和測試過的遠程能力，可以直接生成強型別的程式碼整合到本地應用中，無需重新撰寫客戶端對接層。AI 不僅僅需要 CLI，還需要程式碼調用能力。
2. MCP 配置自動發現與導入現有的 MCP 開發者可以直接無縫接入 UXC，無需手動重新建立配置。可以將各種 MCP 配置轉換成 CLI 和 skill，降低上下文開銷。
3. Link 命令現已包含源技能（Skill）元資料。 AI Agent 調用命令可以溯源到它對應的技能模組及其原始文件。
其他改進：
1. 增強了後台守護進程（Daemon）的會話可觀測性，讓長期運行的 MCP 或運行時會話更容易檢查、除錯，提升了系統的可靠性。
2. 統一了 Artifact（產物）與大體積回應的處理機制，遇到體積較大的檔案或輸出時，系統能保持其機器可讀性，不再強行將所有龐大的資料內聯（inline）在文字中。
3. 更友善的基於 Schema 的命令列（CLI）參數體驗調整。
4. 轮询（Poll）訂閱優化了輪詢機制，通過支持 ETag、304 Not Modified 以及 x-poll-interval，大大降低了

Worktree 更適合作為一次性的執行目錄
前一陣大家常見的用法，是先準備好一個 worktree，再在那個目錄裡打開 Codex / Claude Code。因為早期模型的上下文和記憶不夠穩，如果直接在 main workspace 裡讓它自己建立 worktree，很容易在上下文壓縮後混淆當前目錄和它建立出來的 worktree 目錄，最後改亂。
但這種用法也有個副作用，就是會慢慢把 worktree 用成一個長期工作空間。問題是 worktree 本來就是綁定分支的，時間一長，你遲早會在裡面遇到切分支、同步分支、清理分支這些額外麻煩。
Worktree 和獨立 clone 的區別，很多人其實也沒有特別分清。它的好處不是“多一個目錄”，而是它本質上還是同一個 repo，共享 git object 庫，複製成本低，也不需要重新走一遍網路 clone。這對大倉庫尤其方便。所以如果你只是想臨時拉一個並行執行目錄，worktree 很合適。只有在你明確需要一個完全獨立的 object 庫，比如要映射到 docker 或虛擬機沙箱裡時，local clone 才更合適。
至少對現在的 Codex / Claude Code 來說，這個問題已經沒那麼嚴重了。我現在更傾向於直接在 main 目錄裡工作，讓它按需要去建立 worktree，改完合併回來，再把 worktree 清掉。這樣更符

把博客遷移到 mdorigin 了，有了 AI 後，感覺自己的博客可以捡起來了。
我跟 Codex 說，你根據我的內容，給我推薦一下博客樣式。
Codex 給了我兩個版本，開了兩個端口，給我預覽，還把理由解釋得頭頭是道。
於是我就刪掉了 mdorigin 內建的模板樣式系統。模板這種東西，本來就是前 Agent 時代的產物，主要是為了降低改樣式的門檻。
現在有了 Agent，提供擴展能力就行。站點樣式讓 Agent 去定制，mdorigin 自己只管 HTML / Markdown 的結構、路由和內容檢索。
我以前寫 blog 有個很煩的點：很多系統要求圖片和附件單獨放一個公共目錄。
這樣部署是方便了，但寫作時很別扭。文章是一套路徑，圖片又是一套路徑，本地預覽和最後發布看到的還不是同一個東西。
mdorigin 會把圖片、影片、附件繼續和文章放在一起
Markdown 裡直接用相對路徑。
發布時 mdorigin 會根據媒體文件的大小，自動分流到 Cloudflare 的 asset 或對象存儲裡，頁面上的資源路徑也是相對路徑。
現在 blog 只是我的本地 Obsidian workspace 的一個 public 目錄，mdorigin 把這個目錄發出來就好。