長程代理先做護欄，不要先拚更大模型

955 個 stars 指向同一件事：長程代理最快的進步來自護欄工程，不是只靠模型變大。

我站在護欄先行這一邊：長程代理要先把 runtime、記憶、工具、驗證做穩，才談得上更大的模型。RUC-NLPIR 的 survey 把外部化的 harness engineering 放在前面，這不是分類習慣，而是現實排序。因為真正卡住代理的，常常不是推理能力，而是跨步驟的狀態保存、錯誤恢復、工具調度與結果校驗。

第一個論點

第一個證據很直接：該 survey 的 GitHub repository 有 955 個 stars，代表這個方向不是紙上談兵，而是已經形成明確共識。更重要的是，它把 loops、workflows、context、memory、tools、orchestration、hooks、verification 排在 fine-tuning 與 RL 前面，這等於承認一件事：長程任務的第一瓶頸是執行可靠性，不是再多一點參數。

具體案例也支持這個排序。現在很多 agent demo 看起來會規劃、會反思、會呼叫工具，但一旦任務拉長到十幾步，就會在中途丟失狀態、重複操作或忽略失敗回報。這時候加大模型，效果常常只是在單步推理上更漂亮；真正讓任務完成率上升的，是加入 checkpoint、retry、fallback、verifier 這些工程機制。

第二個論點

第二個證據來自時間軸。survey 描述了從 2020 到 2023 的 prompt engineering，到 2023 到 2025 的 context engineering，再到 2025 之後的 runtime harnesses。這條路線很清楚：產業重心不是往「更會說話的模型」移，而是往「更能把事做完的系統」移。這不是理論推演，而是整個領域的演進方向。

再看長程能力的增長速度，資料顯示 frontier AI agents 的 time horizon 正在以「大約每幾個月翻倍」的速度成長。這個現象最能說明問題：同一個 base model，因為外層系統更會管理狀態、分支、重試與驗證，就能撐過更多回合。換句話說，市場買到的不是單純的模型智力，而是被 harness 放大的持續作戰能力。

反方可能怎麼說

最強的反對意見是：護欄只是補丁。若一個系統需要大量 orchestration、memory、retry 和 verification，代表模型本身不夠 agentic。真正的進步應該來自把策略內化到模型裡，讓外層系統越來越薄，最後只剩一個更強的 policy。

另一個合理批評是成本。runtime 系統會增加延遲、工程複雜度與失敗面，對簡單任務甚至是浪費。若產品場景只需要一次性回答，堆太多 harness 不但不划算，還會拖慢體驗。

但這些批評不推翻護欄先行，只是提醒護欄不是永久替代品。長程代理今天的核心問題，是如何把有限的模型能力轉成可重複完成的行動。這件事靠 harness 最快，因為它能立刻提升完成率，還能在運行中產生 trajectories、failure cases 與 feedback，反過來餵給後續的內化訓練。先把系統做穩，再把穩定性訓進模型，才是正路。

你能做什麼

如果你是工程師，先設計 state、recovery、tool routing、verification，再去追新 checkpoint；如果你是 PM，把成功指標改成多步任務完成率與失敗恢復率，而不是單輪流暢度；如果你是創辦人，先投資可重用的 runtime 基礎設施，因為那才是能跨模型累積的護城河。