北京
3/50。這是我在一次AI崗位技術測試中的得分，換算成百分制只有6分。
但諷刺的是，我拿到了這份工作。
當時我對完全自主的智能體架構幾乎一無所知。雖然做過大語言模型流水線和一些小工具，但"讓AI自己決定下一步做什么"這種設計模式，對我來說是全新的領域。這次失敗反而讓我學到了關鍵一課——不是關于智能體本身，而是關于如何面對陌生的工程問題。
面試時，我展示了測試結果?，F在的CTO注意到我一直在用便宜的迷你模型做 endless testing，賬單已經相當可觀。他順手用我的智能體跑了一遍當時最強的Opus模型。結果更尷尬：得分從3分掉到了2分。
問題根本不在模型。
我的代碼結構其實很干凈：基于插件的工具系統、一致的接口設計、半自主流水線，還加了結構約束。我的策略是"先限制再擴展"——給智能體特定工具解決一部分問題，再圍繞這些抽象慢慢擴充能力，直到覆蓋全部場景。
紙面上，這套架構無懈可擊。實戰中，它解不了題。
CTO告訴我，如果當初我只做一個最簡單的循環：大模型+while循環+Python沙盒，讓智能體執行代碼（當然不是完全無限制的），基準測試能拿到80%的分數。不需要提示工程，不需要特殊工具，不需要高級抽象。
這不是說生產環境就該放任AI隨便跑代碼。核心教訓是：我在"知道"之前就"建造"了。我假設自己懂該用什么抽象、該造什么工具、該怎么約束智能體。實際上我完全不懂，甚至對測試題目的領域毫無概念。
回頭看，正確的做法是從簡單開始。
先搭一個能跑通的基線：循環結構+安全的Python執行環境。有了這個底子，工具、約束、抽象這些附加層才有意義——它們只服務于三個目標：可靠性、成本、延遲。
更重要的是，這次經歷讓我真正理解了"智能體"是什么。傳統軟件里，要解決多種問題就得把復雜度顯式編碼進系統。智能體把這個邏輯顛倒了：復雜度藏在模型內部。
我總結了兩點收獲。
第一，實踐層面。行業趨勢是給智能體更多自主權，但諷刺的是，編程類智能體似乎還沒跟上。Claude這類工具反而傾向于讓我做更少自主、更"流水線化"的設計。如果給智能體安全的Python執行能力，Python本身就是一件靈活強大的工具。而隨著Pydantic Monty這類框架出現，這件事正變得越來越簡單。
第二，工程思維。從簡單開始。在理解問題之前，別預設自己知道答案。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
