從昨天要把整個流程建立到現在，一直沒有完整的串連起來。前後換了多個Agent，沒有一個能完美的處理這個流程。不過，至少確定整個流程用GraphQL搭配Personal Access Token(PAT)，是很重要的環節，就算是用”gh cli”，也要避免REST API的使用。

Using GitHub Copilot to work on an issue - GitHub Docs

目前整個流程是從GitHub Issue開始，一但指定該Issue由Copilot進行，則後續的GitHub PR，Branch和Runner都會由該Copilot處理。但coding agent在runner裡完成後，PR會進入到一個需要手動按”Ready for Review”而後才能行Auto Merge的步驟。也就是這裡，一直沒有辦法讓整個PR自行進入到Open的階段，後續的auto merge無法進行，則Issue無法關閉，自然就沒有辦法再選另一個Issue進行。

經過多個agent的協助下，依然是沒有任何的改變，只能在現有的專案先加入一些簡易的測試。提到測試，這裡有個很有趣的問題浮現出來，其實從語法的角度來看Agent寫出來的程式碼，也一樣是會有錯誤的，只是它一看到compile出來的編譯錯誤它編譯錯誤它修正的很快。但如果是動態語言，像是python，它就必需要等到執行時，出現錯誤(也就是讀取log)時，才有辦法修正。

且在撰寫GitHub workflow的yml檔時，會常常用很複雜的bash script，也很容易出現indentation的錯誤，在知道AI也無法一次產出正確的程式碼的情況下，還是要請AI撰寫測試，這樣才能稍稍避免上到runner後才能看到的問題。不過，在程式碼依然會有錯的情況下，到底AI寫的測試是否有涵蓋到該測試部份，這樣很難說了。

況且，現在最重要的問題在於整個流程上有不確定的部份，以至於一直有問題，但光靠單元測試也沒有找出實際是哪個環節出錯。也沒有辦法用Integration的測試，因為這是只有在實際的GitHub裡才能測到的問題，也就只能一直commit, push, gh cli的方式行除錯。就算是AI，也是很花時間沒有效率的。而且，光是這樣不停的除錯，執行，就花費了300多分鐘的runner時間。對於一個月只有2000方鐘可以執行的比例來看，實在是很可怕。還好是public repo，沒有限制(應該也還是有，只是沒有寫出來吧)。

看這個情況，今天應該會沒有任何進展。等到明天有空時再來了解要怎麼解決這個問題。若是真的還是卡住，也就只能手動的去做PR merge的動作。