作者 | Arseni Kravchenko

編譯 | 云昭

出品 | 51CTO技術棧（微信號：blog51cto）

有時候，總有人會問我：

“我剛接觸 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” 的方式：

1. 選定一個 baseline 版本；
2. 跑出一些軌跡 / 日志；
3. 用 LLM 分析這些日志（尤其是像 Gemini 這種大上下文模型）；
4. 根據 insight 調整系統設計。

大多數情況下，這個流程會揭示出上下文管理或工具設計的盲區。

原則六：讓你抓狂的行為，往往是系統問題

現在的大模型已經很強了，所以當 agent 做出明顯愚蠢的事時，你會本能地感到沮喪。但現實是：

agent 出錯不一定是 LLM 不行，往往是系統沒設計好 —— 缺工具、提示不清晰、上下文沒給夠。

有次我快氣瘋了：agent 為什么不調用我準備好的數據接口，非要生成一些隨機數據？我明明寫了“不準用模擬數據”啊！

結果我一看日志，發現鍋在我：我忘了給 agent 提供 API Key。它其實嘗試調過接口，失敗了幾次后才換了備選方案。

類似的還有：agent 寫文件失敗，是因為沒開文件系統權限。

總結：agent 出錯時，先別怪模型，先查查系統。

結語

構建高效 agent，不是靠一個神奇提示詞或酷炫框架，而是：

扎實的系統設計 + 可靠的軟件工程方法。

關注清晰的指令、簡潔的上下文管理、穩健的工具接口和自動化驗證閉環。遇到奇怪的行為，先從系統層排查：是不是少了工具？prompt 有歧義？上下文不夠？

最重要的：把錯誤分析當作一等公民。在迭代中用 LLM 找出失敗原因，一步步修正。

目標不是完美的 Agent，而是一個能可靠運行、出錯后能優雅恢復、可以不斷優化的系統。

參考鏈接：??https://www.app.build/blog/six-principles-production-ai-agents??

本文轉載自51CTO技術棧，編譯：云昭