作者 | Arseni Kravchenko

編譯 | 云昭

有時(shí)候，總有人會問我：

“我剛接觸 agentic development，正在做一個(gè)項(xiàng)目，但總覺得好像少了點(diǎn)‘圈內(nèi)人’才知道的經(jīng)驗(yàn)。你能不能幫我補(bǔ)補(bǔ)課？”

我常常想推薦一些硬核的課程，比如 HuggingFace 或伯克利的多周訓(xùn)練營，但也理解不是每個(gè)人都想那么深入。

于是我決定寫下這篇文章，分享六條我在開發(fā) app.build 過程中總結(jié)出來的實(shí)用經(jīng)驗(yàn)。這篇更通用，也更適合作為 Agentic 工程入門者的快速參考。

原則一：認(rèn)真打磨你的 System Prompt

我曾經(jīng)對 Prompt Engineering 很懷疑，總覺得那像是某種巫術(shù)：什么“我會給你 $100 小費(fèi)”、"我奶奶命懸一線需要這份答案”、"請務(wù)必100%準(zhǔn)確否則后果嚴(yán)重"……這些技巧偶爾能奏效，本質(zhì)上是在利用模型的小瑕疵，但從來不是長期解法。

直到我意識到一件事，我才改變了對 Prompt 和 Context Engineering 的看法：

現(xiàn)代大模型其實(shí)并不需要什么套路，它們只需要明確、具體、不含矛盾的信息。

沒錯(cuò)，就是這么簡單。不用操控、也不用博感情。它們擅長執(zhí)行指令，真正的問題往往是：你的指令本身就不清晰。

現(xiàn)在，各大 LLM 廠商（比如 Anthropic 和 Google）都有一些 prompt 編寫的最佳實(shí)踐文檔。你只需要照著做：保持清晰具體，不要玩“聰明人把戲”。比如我們給 Claude 生成 ast-grep 規(guī)則的系統(tǒng)提示里，沒有用任何花招，只是非常詳盡地解釋工具的使用方式而已。

我們有個(gè)小技巧：可以用像 Deep Research 這種風(fēng)格的 LLM 來生成系統(tǒng) prompt 初稿，再由人類潤色。這種方式雖然不是最終答案，但是一個(gè)非常不錯(cuò)的起點(diǎn)。

同時(shí)，把一些上下文內(nèi)容長期固化在 prompt 里，有利于 prompt 緩存機(jī)制的命中率。技術(shù)上當(dāng)然可以緩存用戶輸入，但我們發(fā)現(xiàn)把系統(tǒng)部分設(shè)為大而穩(wěn)定、用戶部分保持小而動態(tài)，是一種很有效的結(jié)構(gòu)。

原則二：把上下文拆分開來

你已經(jīng)有了一個(gè)不錯(cuò)的 system prompt。但為什么現(xiàn)在“上下文工程”比“提示詞工程”更火？因?yàn)楝F(xiàn)實(shí)中，管理上下文是一個(gè)很有取舍的工程活。

缺少上下文，模型容易胡說八道、偏離主題，甚至直接拒絕回答；上下文太大，又會出現(xiàn)注意力衰減（attention attrition）的問題 —— 模型很難聚焦到真正重要的中間細(xì)節(jié)，還會帶來算力開銷和響應(yīng)延遲。

我們發(fā)現(xiàn)一個(gè)非常實(shí)用的原則是：

一開始只提供最小必要的信息，后續(xù)需要的話可以通過工具再拉取更多上下文。

比如在我們的項(xiàng)目中，我們會在提示中列出所有項(xiàng)目文件，并給模型一個(gè)“讀取文件”的工具，這樣它只需要在必要時(shí)調(diào)用就好。如果我們明確知道某個(gè)文件對當(dāng)前請求至關(guān)重要，也可以提前把它的內(nèi)容放進(jìn)上下文里。

但也要小心：日志和反饋環(huán)節(jié)的其他產(chǎn)物很容易讓上下文“腫脹”。定期做上下文壓縮非常有幫助。

一句話總結(jié)就是：封裝很重要 —— 把不同的上下文職責(zé)分開，只給每個(gè)子任務(wù)分配它絕對需要的上下文。

原則三：精心設(shè)計(jì)工具集

AI Agent 的核心能力就是調(diào)用工具：一個(gè) LLM + 工具接口 + 控制流操作符，構(gòu)成了最基本的 agent。

給 Agent 設(shè)計(jì)工具集其實(shí)有點(diǎn)像設(shè)計(jì) API，但更復(fù)雜。人類開發(fā)者可以“意會”，能看懂復(fù)雜文檔，甚至能繞過 bug；但 Agent 不行。工具太多容易污染上下文，接口不清晰就會用錯(cuò)。

給 Agent 設(shè)計(jì)工具時(shí)，請記住：

工具要接口直接、功能清晰、邏輯干凈，就像你要交給一個(gè)聰明但容易分神的新手程序員。

好工具的特點(diǎn)：

• 粒度相似
• 參數(shù)數(shù)量少而明確（最好是強(qiáng)類型）
• 功能單一但可靠
• 盡量冪等，避免狀態(tài)混亂

在多數(shù)軟件工程場景里，agent 工具不超過 10 個(gè)，典型的有 read_file, write_file, edit_file, execute 等，每個(gè) 1-3 個(gè)參數(shù)即可。

有時(shí)候，讓 agent 寫一段 DSL（領(lǐng)域?qū)Ｓ谜Z言）來表示動作，比一個(gè)個(gè)工具調(diào)用更優(yōu)雅。這種做法被 smolagents 帶火了。但前提是：你要先設(shè)計(jì)好這套 DSL 的語義和函數(shù)，不能只做表面功夫。

原則四：設(shè)計(jì)反饋閉環(huán)（Feedback Loop）

一個(gè)真正有生產(chǎn)力的 Agent 系統(tǒng)，往往融合了傳統(tǒng)軟件工程和 LLM 的優(yōu)勢。

我們借鑒了“Actor-Critic”結(jié)構(gòu)：Actor 負(fù)責(zé)做動作，Critic 負(fù)責(zé)評估結(jié)果。

在 app.build 中，我們讓 Actor 生成文件或修改文件，讓 Critic 檢查它們是否符合我們的預(yù)期。這個(gè)預(yù)期是根據(jù)編譯成功、測試通過、類型檢查、代碼格式等硬性標(biāo)準(zhǔn)來的。

不同領(lǐng)域的 agent，都需要類似的“驗(yàn)證機(jī)制”。這其實(shí)是引入“歸納偏置”（inductive bias）的一種方式 —— 即不管 agent 怎么操作，結(jié)果必須滿足某些永遠(yuǎn)不變的規(guī)則。

比如，旅行類 Agent 規(guī)劃多段航班時(shí)，要驗(yàn)證這些航班真的存在；財(cái)務(wù)類 Agent 要滿足復(fù)式記賬原則，否則結(jié)果就不成立。

Feedback loop 和“guardrails（護(hù)欄）”關(guān)系密切。Agent 有一定的恢復(fù)能力，如果結(jié)果不好，可以嘗試提示“你的答案錯(cuò)在 X”，引導(dǎo)其修復(fù)。但如果連續(xù)幾輪都修不好，那就該放棄這個(gè)路徑，重新開始。

這就像蒙特卡洛樹搜索：有些分支值得繼續(xù)，有些該盡早砍掉。

原則五：用 LLM 做錯(cuò)誤分析

當(dāng)你已經(jīng)有了 agent + feedback loop，下一步就是持續(xù)優(yōu)化。

AI/ML 工程中，錯(cuò)誤分析一直是最核心的環(huán)節(jié)，agent 也一樣。

問題是：agent 太能干了。你一旦開跑幾十個(gè) agent 并發(fā)任務(wù)、產(chǎn)出大量日志，幾乎不可能手動讀懂它們。

這個(gè)時(shí)候就該用 “meta-agentic” 的方式：

1. 選定一個(gè) baseline 版本；
2. 跑出一些軌跡 / 日志；
3. 用 LLM 分析這些日志（尤其是像 Gemini 這種大上下文模型）；
4. 根據(jù) insight 調(diào)整系統(tǒng)設(shè)計(jì)。

大多數(shù)情況下，這個(gè)流程會揭示出上下文管理或工具設(shè)計(jì)的盲區(qū)。

原則六：讓你抓狂的行為，往往是系統(tǒng)問題

現(xiàn)在的大模型已經(jīng)很強(qiáng)了，所以當(dāng) agent 做出明顯愚蠢的事時(shí)，你會本能地感到沮喪。但現(xiàn)實(shí)是：

agent 出錯(cuò)不一定是 LLM 不行，往往是系統(tǒng)沒設(shè)計(jì)好 —— 缺工具、提示不清晰、上下文沒給夠。

有次我快氣瘋了：agent 為什么不調(diào)用我準(zhǔn)備好的數(shù)據(jù)接口，非要生成一些隨機(jī)數(shù)據(jù)？我明明寫了“不準(zhǔn)用模擬數(shù)據(jù)”??！

結(jié)果我一看日志，發(fā)現(xiàn)鍋在我：我忘了給 agent 提供 API Key。它其實(shí)嘗試調(diào)過接口，失敗了幾次后才換了備選方案。

類似的還有：agent 寫文件失敗，是因?yàn)闆]開文件系統(tǒng)權(quán)限。

總結(jié)：agent 出錯(cuò)時(shí)，先別怪模型，先查查系統(tǒng)。

結(jié)語

構(gòu)建高效 agent，不是靠一個(gè)神奇提示詞或酷炫框架，而是：

扎實(shí)的系統(tǒng)設(shè)計(jì) + 可靠的軟件工程方法。

關(guān)注清晰的指令、簡潔的上下文管理、穩(wěn)健的工具接口和自動化驗(yàn)證閉環(huán)。遇到奇怪的行為，先從系統(tǒng)層排查：是不是少了工具？prompt 有歧義？上下文不夠？

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

目標(biāo)不是完美的 Agent，而是一個(gè)能可靠運(yùn)行、出錯(cuò)后能優(yōu)雅恢復(fù)、可以不斷優(yōu)化的系統(tǒng)。

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