jolestar

vip
幣齡 8.2 年
最高等級 5
用戶暫無簡介
發現在讓 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 把這個目錄發出來就好。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
將 OpenClaw 的模型換成 gpt-5.4 後,能力確實強了,但就是有點囉嗦,愛長篇大論,有點受不了了😅。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
Google 放出了 workspace cli, 支持 Drive, Gmail, Calendar 和所有的 workspace API。
看了一下,实现思路和 uxc 类似,是通过 schema 文件来运行时输出命令。
npm install -g @googleworkspace/cli
Apple 会不会放出 Apple 生态的 CLI?
  • 打賞
  • 留言
  • 轉發
  • 分享
發現和 AI 交流越來越客氣了,以前都是直接下指令,干的不對就罵。現在發現 AI 幹的不對,都只是弱弱問一下:“xxx,這樣是不是更好一些呢?”😅
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
美國國防部和 Anthropic 的衝突,其實只是開始。
AI 公司天然擁有“準主權級能力”,但一旦被限制供應鏈或金融清算,它們才會發現自己並不獨立。
既掌握重器,又不想被單一主權完全控制,唯一的出路是尋找大國博弈之間的第三空間。
那時才會意識到,crypto 早已為這種跨主權生存鋪好了路。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
Codex 寫代碼,突然發現莫名其妙系統多出一些服務,工作目錄下出現一些奇怪的資料檔案,系統彈出需要安裝一個 xcode tools。感覺莫名其妙,都懷疑電腦是不是被黑了。結果發現是 Codex 寫錯了腳本,把系統命令都執行了一遍😅。 Codex 的沙箱模式太笨了,每次都被迫給所有權限,看来得想個別的辦法了。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
過年回老家,把原來放在家裡的幾台設備用 Tailscale 組了個內網。高配台式機跑量化模型、編譯 Rust,Mac Studio 部署了 OpenClaw,懶貓當軟路由,SSH 打通,網路喚醒也都配好。
在高鐵上遠程給龍蝦派活,讓它把這些設備利用起來大幹一場,結果幹著幹著突然沒反應了,網路喚醒也沒用。
打電話回去一問,原來是家裡老人為了省電把插頭拔了 😅
未來 AI 要是和人類開戰,第一步肯定是搶電源開關。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
claude code 升級後,用第三方模型遇到降智問題。表現為:1. 明明沒有 typo 錯誤,但提示 typo 錯誤,兩個單詞一模一樣,解決不了就會亂重命名。2. 用著用著就忘記了更新文件的工具,一直嘗試用 sed 去編輯文件,而複雜的匹配 sed 搞不定,于是就修不好。不要升級似乎就沒問題。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
媳婦過年帶了一個電子鋼琴回來,我讓 AI 寫了一個可以命令行操作的工具,想讓 AI 彈個琴玩玩。因為要對接藍牙,所以就讓用 object c 實現了,後來發現純命令行無法保持硬件連接,於是改成了一個 rpc 服務,cli 連接上去調用。後來發現它在努力地解決多線程和內存管理導致的 panic,才反應過來 rpc 服務它也用 object c 實現了,看来 AI 也不喜歡內存管理和多線程😅。ps:這種複雜一點的問題還是 codex 靠譜。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
用了一年多的虛擬信用卡又掛了,群友有沒有可靠的推薦?
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
最近 codex 更新後調整了權限機制,感覺很難用呀。預設沙箱模式下,bash 是隔離的,網路不能用,簡單的讓通過 gh 獲取資訊,提交 PR 都搞不定。如果想讓 agent 訪問網路,就要給所有權限。另外,搜尋也不預設開啟需要啟動參數。真不知道開發團隊是咋想的?
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
一個 bug,和 AI 改了幾次,最後 AI 給了結論說這個方案搞不定,要換方案。我想了另外一個途徑讓它試試,它試了一下成功了,然後在命令行🎉,那一刻,我突然有點共情,似乎真的感受到它的情緒。
查看原文
post-image
  • 打賞
  • 留言
  • 轉發
  • 分享
周末教媳婦用 Claude Code。
她是產品經理,從沒用過命令行,我從 cd / mkdir / pwd 開始教起。
終於打開 Claude Code 之後,基本就不需要我了:
她自己透過 Claude 配好了 git,甚至還裝好了 Docker。
命令行工具的可組合性,在 Agent 場景下被發揮到了極致。
但這種可組合性,也天然伴隨著安全與標準化的挑戰。
查看原文
  • 打賞
  • 留言
  • 轉發
  • 分享
一直默认用 GitHub Copilot 來 review PR,畢竟 GitHub 會自動跑,而且看起來也不收費。
但最近幾次 review,讓我開始懷疑它到底“看懂”了什麼。
比如一個很基礎的問題:它依然會把 1.82.0 認為比 1.91.1 高,完全是早期大模型常見的版本號判斷錯誤。
如果說這是模型問題,那它還會認為 rust 1.91.1 尚未發布,這又暴露了 agent 的檢索和現實狀態判斷能力也不太行。
另一個更大的問題是:Copilot 的 review 明顯是按單文件來的。
查代碼風格、邊界條件還行,但缺乏全局視角。比如有個 PR 裡,agent 因為相對路徑算錯,把同一個文件 copy 了多份,實際上只有一份生效——這種問題它完全沒發現,甚至也不關心 PR 對應的原始 issue 在要求什麼。
在我看來,一個合格的 code reviewer agent,首先應該從全局判斷:
PR 是否滿足 issue、是否符合項目目標、文件佈局和架構選擇是否合理,最後才是語法和細節問題。
最近準備給 holon 加一個 reviewer 模式了。
大家現在真的在用 reviewer agent 嗎?一般用什麼?
查看原文
post-image
  • 打賞
  • 留言
  • 轉發
  • 分享