作者 | Arseni Kravchenko
編譯 | 云昭
有時候，總有人會問我：
“我剛接觸 agentic development，正在做一個項目，但總覺得好像少了點‘圈內人’才知道的經驗。你能不能幫我補補課？”
我常常想推薦一些硬核的課程，比如 HuggingFace 或伯克利的多周訓練營，但也理解不是每個人都想那么深入。
于是我決定寫下這篇文章，分享六條我在開發 app.build 過程中總結出來的實用經驗。這篇更通用，也更適合作為 Agentic 工程入門者的快速參考。
原則一：認真打磨你的 System Prompt
我曾經對 Prompt Engineering 很懷疑，總覺得那像是某種巫術：什么“我會給你 $100 小費”、"我奶奶命懸一線需要這份答案”、"請務必100%準確否則后果嚴重"……這些技巧偶爾能奏效，本質上是在利用模型的小瑕疵，但從來不是長期解法。
直到我意識到一件事，我才改變了對 Prompt 和 Context Engineering 的看法：
現代大模型其實并不需要什么套路，它們只需要明確、具體、不含矛盾的信息。
沒錯，就是這么簡單。不用操控、也不用博感情。它們擅長執行指令，真正的問題往往是：你的指令本身就不清晰。
現在，各大 LLM 廠商（比如 Anthropic 和 Google）都有一些 prompt 編寫的最佳實踐文檔。你只需要照著做：保持清晰具體，不要玩“聰明人把戲”。比如我們給 Claude 生成 ast-grep 規則的系統提示里，沒有用任何花招，只是非常詳盡地解釋工具的使用方式而已。
我們有個小技巧：可以用像 Deep Research 這種風格的 LLM 來生成系統 prompt 初稿，再由人類潤色。這種方式雖然不是最終答案，但是一個非常不錯的起點。
同時，把一些上下文內容長期固化在 prompt 里，有利于 prompt 緩存機制的命中率。技術上當然可以緩存用戶輸入，但我們發現把系統部分設為大而穩定、用戶部分保持小而動態，是一種很有效的結構。
原則二：把上下文拆分開來
你已經有了一個不錯的 system prompt。但為什么現在“上下文工程”比“提示詞工程”更火？因為現實中，管理上下文是一個很有取舍的工程活。
缺少上下文，模型容易胡說八道、偏離主題，甚至直接拒絕回答；上下文太大，又會出現注意力衰減（attention attrition）的問題 —— 模型很難聚焦到真正重要的中間細節，還會帶來算力開銷和響應延遲。
我們發現一個非常實用的原則是：
一開始只提供最小必要的信息，后續需要的話可以通過工具再拉取更多上下文。
比如在我們的項目中，我們會在提示中列出所有項目文件，并給模型一個“讀取文件”的工具，這樣它只需要在必要時調用就好。如果我們明確知道某個文件對當前請求至關重要，也可以提前把它的內容放進上下文里。
但也要小心：日志和反饋環節的其他產物很容易讓上下文“腫脹”。定期做上下文壓縮非常有幫助。
一句話總結就是：封裝很重要 —— 把不同的上下文職責分開，只給每個子任務分配它絕對需要的上下文。
原則三：精心設計工具集
AI Agent 的核心能力就是調用工具：一個 LLM + 工具接口 + 控制流操作符，構成了最基本的 agent。
給 Agent 設計工具集其實有點像設計 API，但更復雜。人類開發者可以“意會”，能看懂復雜文檔，甚至能繞過 bug；但 Agent 不行。工具太多容易污染上下文，接口不清晰就會用錯。
給 Agent 設計工具時，請記住：
工具要接口直接、功能清晰、邏輯干凈，就像你要交給一個聰明但容易分神的新手程序員。
好工具的特點：
- 粒度相似
- 參數數量少而明確（最好是強類型）
- 功能單一但可靠
- 盡量冪等，避免狀態混亂
在多數軟件工程場景里，agent 工具不超過 10 個，典型的有 read_file, write_file, edit_file, execute 等，每個 1-3 個參數即可。
有時候，讓 agent 寫一段 DSL（領域專用語言）來表示動作，比一個個工具調用更優雅。這種做法被 smolagents 帶火了。但前提是：你要先設計好這套 DSL 的語義和函數，不能只做表面功夫。
原則四：設計反饋閉環（Feedback Loop）
一個真正有生產力的 Agent 系統，往往融合了傳統軟件工程和 LLM 的優勢。
我們借鑒了“Actor-Critic”結構：Actor 負責做動作，Critic 負責評估結果。
在 app.build 中，我們讓 Actor 生成文件或修改文件，讓 Critic 檢查它們是否符合我們的預期。這個預期是根據編譯成功、測試通過、類型檢查、代碼格式等硬性標準來的。
不同領域的 agent，都需要類似的“驗證機制”。這其實是引入“歸納偏置”（inductive bias）的一種方式 —— 即不管 agent 怎么操作，結果必須滿足某些永遠不變的規則。
比如，旅行類 Agent 規劃多段航班時，要驗證這些航班真的存在；財務類 Agent 要滿足復式記賬原則，否則結果就不成立。
Feedback loop 和“guardrails（護欄）”關系密切。Agent 有一定的恢復能力，如果結果不好，可以嘗試提示“你的答案錯在 X”，引導其修復。但如果連續幾輪都修不好，那就該放棄這個路徑，重新開始。
這就像蒙特卡洛樹搜索：有些分支值得繼續，有些該盡早砍掉。
原則五：用 LLM 做錯誤分析
當你已經有了 agent + feedback loop，下一步就是持續優化。
AI/ML 工程中，錯誤分析一直是最核心的環節，agent 也一樣。
問題是：agent 太能干了。你一旦開跑幾十個 agent 并發任務、產出大量日志，幾乎不可能手動讀懂它們。
這個時候就該用 “meta-agentic” 的方式：
- 選定一個 baseline 版本；
- 跑出一些軌跡 / 日志；
- 用 LLM 分析這些日志（尤其是像 Gemini 這種大上下文模型）；
- 根據 insight 調整系統設計。
大多數情況下，這個流程會揭示出上下文管理或工具設計的盲區。
原則六：讓你抓狂的行為，往往是系統問題
現在的大模型已經很強了，所以當 agent 做出明顯愚蠢的事時，你會本能地感到沮喪。但現實是：
agent 出錯不一定是 LLM 不行，往往是系統沒設計好 —— 缺工具、提示不清晰、上下文沒給夠。
有次我快氣瘋了：agent 為什么不調用我準備好的數據接口，非要生成一些隨機數據？我明明寫了“不準用模擬數據”啊！
結果我一看日志，發現鍋在我：我忘了給 agent 提供 API Key。它其實嘗試調過接口，失敗了幾次后才換了備選方案。
類似的還有：agent 寫文件失敗，是因為沒開文件系統權限。
總結：agent 出錯時，先別怪模型，先查查系統。
結語
構建高效 agent，不是靠一個神奇提示詞或酷炫框架，而是：
扎實的系統設計 + 可靠的軟件工程方法。
關注清晰的指令、簡潔的上下文管理、穩健的工具接口和自動化驗證閉環。遇到奇怪的行為，先從系統層排查：是不是少了工具？prompt 有歧義？上下文不夠？
最重要的：把錯誤分析當作一等公民。在迭代中用 LLM 找出失敗原因，一步步修正。
目標不是完美的 Agent，而是一個能可靠運行、出錯后能優雅恢復、可以不斷優化的系統。
參考鏈接：https://www.app.build/blog/six-principles-production-ai-agents
