今天利用local agent進行嘗試的部份主要是文件管理，由於每個agent都會產生文件，在docs裡的文件格式變得很不統一，而且目錄也越來越多，根本很難知道哪些文件是暫時產生，又或是哪些文件是已經過時的。 不過今天也沒有辦法很全面的整理並規範，就只能針對現有的文件進行處理後，額外加上一些文件的規則，看那些agent能不能在產生文件時注意到。

而另一個主要的嘗試就是使用GitHub Copilot CLI

GitHub - github/copilot-cli: GitHub Copilot CLI brings the power of Copilot coding agent directly to your terminal.

目前還在Preview階段，但使用起來和OpenAI的codex cli很接近。這二個cli和claude code比起來最大的不同之處在於沒有queue下一段對話。現行的多數agent chat，大多都是要等到agent停下來後才能再和他提下一個需求。如果想要覆蓋上一個需求，則多數是要取消做到一半的agent task，而有些動作是不可逆的，一但取消就可能會在一個很麻煩的地方。雖然agent能很快的回復到之前的狀態，但就是會浪費一些token。

回到GitHub copilot cli，使用時感覺就算是用同一個AI model(預設是Claude Sonnet 4.5了)，它也和Visual Studio Code(vsc)裡的不一樣。在vsc裡，總覺得它在處理一個需求時會很想快速的解決，像是很趕時間一般，但這裡的很想快速的解決是指它會做到一部份就認為自己已經完成了，就很快的給出結論，認為自己做到了什麼，馬上要進下一個步驟。但在GitHub copilot cli，個性剛好相反，有種一直做不停的感覺。

個性上雖然是反差很大，但並不代表它們有本質上的不同，會出錯的地方還是一樣會出錯。這也是為什麼要能夠選取不同的AI model對現階段的AI使用來說相當的重要。像是今天請agent(claude sonnet 4.5)修正一個網頁上的錯誤，它會在試了三、四次後和你說它花了很多時間都沒有辧法完成，還是直接放棄這個做法，改其它的方式。這時就只好轉換成gpt-5，它就順利的將它完成了。

這並不代表gpt-5比claude sonnet 4.5優異，實際上這二個模型都有可能會有某個點會被卡住，如果剛好卡住的點都一樣，這時就只能使用像是gemini 2.5 pro等其它的模型，看能不能繞過去。不過github copilot裡的gemini 2.5 pro對我來說是長時間都無法使用的，每次轉換到這個模型，送出的request都直接顯示server error，被迫要換到像是grok code fast 1等選擇。簡單來說用GitHub copilot cli的體驗明顯是比較好的(和同樣為GitHub copilot vsc做較)。

除了文件的管理外，另一個部份就是建置的管理。為了方便將tui以pty為中介將其呈現在web的xterm裡，所以一次要有三個建置，雖然實際上只能算一個，因為另外二個是用nodejs撰寫的，沒有建置的問題，只有打包的事情要進行。但還是需要統一的方式來進行。而在建置的管理上又不想使用傳統的make，於是agent推薦了just和task

GitHub - casey/just: 🤖 Just a command runner

GitHub - go-task/task: A task runner / simpler Make alternative written in Go

我看了二個專案後，我還是不太清楚just對建置到底有什麼實值上的幫助，所以最後我就選擇了task當做此專案建置的管理。而c#仍是保留讓nuke進行

GitHub - nuke-build/nuke: 🏗 The AKEless Build System for C#/.NET

一樣還是在初期，只是先把建置的方案做基本的處理。目前是可以進行正常的c#建置並打包nodejs到指定的位置，接下來的時間應該會再陸續調整。