北京
過去幾個月，我一直在跟AI編程代理死磕。不是簡單地用它們寫代碼，而是跟它們一起構建項目，針對自己的使用場景反復調優。我在Claude Code、VScode Copilot、Codex和Cursor這些代理上設計并測試了各種技能，仔細觀察它們在哪些地方撐得住，又在哪些地方悄悄地崩掉。
它們確實會崩，而且崩法出奇地一致。代理前三步做得漂漂亮亮，第四步突然犯蠢，然后開始回溯、分析哪里出了錯。等它終于搞清楚問題所在，上下文窗口已經快滿了，留給你的不是完成的任務，而是三四個“我目前做了什么”的匯總文件。這種事情經歷多了以后，我徹底放棄讓代理變聰明的嘗試，轉向完全重新思考技能設計這件事。這篇文章要講的，就是這個轉變以及隨之浮現出來的設計模式。
讓我真正開竅的那個例子，是一個叫confluence-publisher的技能。起因很平常：公司沒有給我Confluence MCP服務器的訪問權限，代理自然沒法原生地發布頁面。我沒等IT部門解決，自己搭了座橋——一個能把Markdown內容發布到Confluence的技能。我把這個技能設計當成了新技能框架的試驗場。之前在其他技能上踩過的坑，在這里全部復現了，所以正好借它來搞清楚到底什么能讓一個代理技能真正可靠。
當技能出問題的時候，本能反應是去約束代理：加更多規則、更多護欄、更多“不要干這個”的提示詞。這是擰錯了旋鈕。你最后會變成跟模型對著干。更好的做法是去約束工具，而不是約束代理。讓代理伸手去拿的那些腳本變得確定、可預測，然后放手讓代理做它真正擅長的一件事：理解用戶想要什么，并對此進行推理。代理負責讀懂意圖、做出決策，腳本負責執行動作。
這么做有兩個好處。首先，不確定性結果大幅減少，因為高風險的工作以普通、經過測試的代碼運行，你可以迭代它，也可以為它寫測試。其次，代理的上下文窗口被壓縮了，因為它在窗口里保留的只是決策，而不是實現細節。后面要講的幾乎所有內容，本質上都是這條思路在不同場景下的應用。整個設計中最重要的選擇是：代理不在運行時寫代碼。它運行預先寫好的腳本，并根據正確的上下文做決定。工作流中的每一步都是一個獨立的Python腳本——step_01_convert.py、step_02_publish.py——帶著干凈的接口，跟代理工具包里任何工具一樣。命令行參數傳進去，結構化輸出和退出碼返回來。代理的工作被收斂到四件事：決定傳什么參數、運行腳本、讀取輸出、決定下一步做什么。這樣一來，模糊地帶消失了。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
