順便再題外話，我說 cli agent 大於 網頁版，是基於 input 的落差。cli 才是最能發揮模型威力的玩法。

順便再題外話，我說 cli agent 大於 網頁版，是基於 input 的落差。cli 才是最能發揮模型威力的玩法。 至於 cursor 跟其他方案的問題是，他們把焦距縮窄了，只在專案裡面，然後他們試圖省token的方法有很明顯的副作用，所以我沒有非常推薦。 但他們有沒有幫助，基本上就是有，我之前的評估是15-30％左右。有幫助，但不會到你想大力引用的程度，人為的介入感還是很重，這是我再說的事情。 但 claude code 這類 cli agent 方案，我保守估計 100％ 真的沒問題。 ＝＝＝＝＝＝ 至於 Antigravity 這類，我覺得要分兩個角度看，Antigravity 搭配 google 自家模型當然是有加成的（就如同claude code+claude 自己模型一樣概念）。 搭配其他模型，那就要考慮成本問題跟會不會有一天被斷供（莫忘Windsurf 當初被斷供的事件）。 但我自己這個階段幾乎完全不買單多 agent 概念，我覺得未來某個時間點多 agent 可能會是下一個讓人驚艷的東西，但此刻就我自己覺得他就是個控制起來非常累而且不好掌握 token 的東西。 主要的問題是，目前主流的 agent 目前在挑戰的其實是「thinking」要放多少空間給他去使用token，比方說 claude code 近期的 effort，跟 openai-codex-5.3 早就有的思考模式(xhigh等)。 有在用 opus 4.6 或 codex-5.3 xhigh 的，應該都能體會到 thinking 雖然可以強化品質，但同時也會拉長時間（等於一個內心戲很多要等他演完的開發者），而且還有一件很殘酷的事情是 read/think/write 都佔 context。 所以假設上下文都是一樣的 200k，那 think 佔的越多也意味著 compat 會越頻繁。這裡面有一個神秘的競和賽局。 目前顯然大家朝向稍微再放多一點 think，到哪裡， claude code 一開始選擇讓使用者可以自己設定(setMaxThinkingToken)，但最近看起來 claude 也是走向使用者設定級距，而由模型自己決定問題他要用多少，把設定tokens上線這件事情拿掉了。 接下來可以預期的可能方向是，一個是 context windows 有沒有機會再打開，另一個就是 token 有沒有機會作的更有效率（更少的token做更多的事情或更好的 compat ）。最後就是在 think 的比重上找到更適合的黃金比例，各家應該都在累積各種試誤的經驗跟答案。 在這點上 claude code 自己同時又是出題者又是回答者，其實先行者優勢是比其他人明顯的。我對A的信心還是遠比其他家來得高很多。 順帶一題，我並沒有非常信任跑分的結果，現在跑分的 benchmark 跟實際的使用還存在著一定的落差，之前 chatgpt 4 前後我就覺得對當前能力評分的機制不是很有信任感。現在我也覺得應該以實證為主。 ＝＝＝＝＝ 在這個視角上，我暫時還看不出來多Agent有什麼魔術可以處理這件事情，因為現在多agent的核心方向是，把一個大的 context 切割成多個子 context，比方說有的人專心處理伺服器，有的人專心處理畫面，有的人處理檔案分析。 藉由分工降低 context 的耦合，但實際上這是一個「變笨」的角度，因為我們之所以需要這些context多數情況下就是需要綜合判斷，怎麼讓這些context適當的壓縮跟傳遞，這就是 skill 在扮演的角色。 但這件事情「並不通用」，只要一個不通用就會開始變成 context 的連集，開始消耗 token 。 我是覺得現在還沒有需要那麼急著挑戰多agent，因為單一agent跟單一工作queue在一定難度的問題上，價值已經非常顯著。 除非問題低到可能單純就是個文字辨識之類的，不然多agent要搶到好處的題目，以我自己的場景並沒有非常明顯。 真有需要我可以直接執行多組 claude code分開下context就好。實在是不需要挑在單一session中多 context 管理。 ＝＝＝＝ 但當然，不同的AI使用場景，包括真的就是想要使用便宜token導入的需求，當然也都是存在的，只是說，這個時間點的最佳策略，我覺得並不是努力白嫖。而是努力賺錢，趁著還有快錢可以賺。

原始 Facebook 貼文