AI 程式代理研究
36,710 個 GitHub 專案只留下 85 份代理計畫，多數尚非長期維護文件
新研究區分常駐的 AGENTS.md 與針對單一任務的 Agent Plan，檢查計畫如何進入公開版本歷史。樣本高度集中於少數專案，顯示「計畫即協作產物」仍是早期且不穩定的實務。
一項獲 ESEM 2026 接受的新研究，首次大規模檢查程式代理產生的任務計畫是否被保存在開源專案中。研究者掃描 36,710 個具工程活動特徵的 GitHub 專案，只在 10 個專案找到 85 份 Markdown 計畫；其中 72 份位於 `.cursor/plans`，13 份位於 `.claude/plans`，預設搜尋的 `.gemini/plans` 沒有命中。
Agent Plan 與 AGENTS.md、CLAUDE.md 等常駐指令不同。後者描述建置命令、架構及編碼慣例，前者則對應一項具體工作，記錄預定步驟、應修改的位置與完成條件。研究分析 592 個一、二級標題後，發現最常見內容是實作步驟、檔案與位置、測試與驗證；分別出現在 54、46 與 40 份計畫中。任務類型則以重構與遷移最多，其次為測試、功能開發及 CI/CD。
公開保存尚未形成普遍規範。Salesforce 的 `salesforcedx-vscode` 單一專案便貢獻 66 份，占全部樣本近八成；排除它後只剩 19 份，任務分布也明顯改變。85 份計畫中只有七份跨多次提交修訂；在可取得完整中繼資料的 72 次提交裡，31 次帶有 Claude 或 Cursor 的明確共同作者標記，但沒有標記不能證明文件由人類獨立撰寫。
這項結果對代理治理的意義，不是證明計畫模式已普及，而是揭示一種可版本化的中介層：團隊可在代理修改程式前審查範圍、限制與驗證方法，事後再把計畫與實際 diff 對照。不過搜尋只涵蓋三個工具專屬目錄及預設分支，會漏掉 `docs`、issue、PR 或本機未提交計畫。下一步需要量測保存計畫是否真的降低返工與缺陷，而非僅增加一份很快過時的文件。