隨著 AI Agent 技術(shù)的興起，許多開(kāi)發(fā)者都投入到構(gòu)建智能體的浪潮中，但很快就會(huì)發(fā)現(xiàn)，讓 Agent 穩(wěn)定、可靠地工作遠(yuǎn)非想象中容易。它們時(shí)而產(chǎn)生幻覺(jué)，時(shí)而偏離軌道，時(shí)而做出一些令人費(fèi)解的“愚蠢”行為。最近，來(lái)自 app.build 的 Arseni Kravchenko 分享了他們?cè)跇?gòu)建生產(chǎn)級(jí) AI Agent 過(guò)程中總結(jié)出的六大核心工程原則。這些原則摒棄了虛無(wú)縹緲的“提示詞黑魔法”，回歸到堅(jiān)實(shí)的軟件工程基礎(chǔ)。對(duì)于正在或計(jì)劃使用 Go 構(gòu)建 AI Agent 的開(kāi)發(fā)者來(lái)說(shuō)，這是一份寶貴的實(shí)踐指南。

原則一：投資你的系統(tǒng)提示 (System Prompt)

許多人對(duì)“提示詞工程”持懷疑態(tài)度，認(rèn)為它充滿了“我奶奶快不行了，請(qǐng)幫幫我”之類的奇技淫巧。然而，作者指出，現(xiàn)代 LLM 真正需要的是直接、詳細(xì)、清晰且無(wú)矛盾的上下文，而非情感操控。

對(duì)于開(kāi)發(fā)者而言，你要做的就是不要耍小聰明，要把系統(tǒng)提示當(dāng)作給 Agent 的API 文檔來(lái)寫(xiě)。

當(dāng)你為 Agent 提供一個(gè)通過(guò) os/exec 調(diào)用的工具時(shí)，不要只告訴它工具的名字。在系統(tǒng)提示中清晰地說(shuō)明：

• 工具的完整命令是什么。
• 每個(gè)參數(shù)的含義、類型和格式。
• 預(yù)期的輸出格式以及如何解析它。
• 前置條件和錯(cuò)誤情況。

一個(gè)詳盡的系統(tǒng)提示是 Agent 可靠行為的基石。

原則二：拆分上下文 (Split the Context)

“上下文工程”是比“提示詞工程”更重要的概念。巨大的、單一的上下文不僅成本高、延遲大，還會(huì)導(dǎo)致模型出現(xiàn)“注意力衰減”，忽略掉關(guān)鍵信息。

作者建議大家：默認(rèn)只提供最少必要知識(shí)，并通過(guò)工具讓 Agent 在需要時(shí)主動(dòng)獲取更多上下文。

與其在初始提示中塞入整個(gè)項(xiàng)目的源代碼，不如：

• 提供文件列表：在提示中只給出項(xiàng)目的文件樹(shù)結(jié)構(gòu)。
• 提供 read_file 工具：讓 Agent 在需要時(shí)，通過(guò)調(diào)用這個(gè)工具來(lái)讀取特定文件的內(nèi)容。
• 上下文壓縮：在 Agent 的反饋循環(huán)中，主動(dòng)使用工具（甚至另一個(gè) LLM）來(lái)壓縮和總結(jié)日志、工具輸出等動(dòng)態(tài)信息，避免上下文無(wú)限膨脹。

如上圖所示，將一個(gè)龐大的任務(wù)分解為多個(gè)具有專注上下文的、可編排的子任務(wù)，是構(gòu)建高效 Agent 的關(guān)鍵。

原則三：精心設(shè)計(jì)你的工具 (Design Tools Carefully)

工具是 AI Agent 的核心。設(shè)計(jì)給 Agent 用的工具，比設(shè)計(jì)給人用的 API 更具挑戰(zhàn)性，因?yàn)?LLM 不會(huì)“讀心術(shù)”，它們會(huì)毫不留情地濫用你留下的任何漏洞。

作者建議：把你的 Agent 當(dāng)成一個(gè)聰明但容易分心的初級(jí)開(kāi)發(fā)者，為它設(shè)計(jì) API：

• 保持粒度一致：工具（函數(shù)）應(yīng)該有相似的抽象層次。不要混用一個(gè) read_byte 和一個(gè) deploy_to_kubernetes。
• 限制數(shù)量和參數(shù)：一個(gè)典型的工程 Agent 通常只有不到 10 個(gè)核心工具，每個(gè)工具只有 1-3 個(gè)嚴(yán)格類型的參數(shù)。
• 追求冪等性：盡可能讓工具是冪等的，這可以極大地簡(jiǎn)化 Agent 的狀態(tài)管理和錯(cuò)誤恢復(fù)邏輯。
• 清晰、無(wú)歧義、無(wú)冗余：確保沒(méi)有兩個(gè)工具的功能是重疊的，這會(huì)讓 LLM 感到困惑。

原則四：設(shè)計(jì)一個(gè)反饋循環(huán) (Design a Feedback Loop)

一個(gè)沒(méi)有驗(yàn)證和反饋的 Agent 是不可靠的。優(yōu)秀的 Agent 系統(tǒng)總是將 LLM 的創(chuàng)造力與傳統(tǒng)軟件的嚴(yán)格性結(jié)合起來(lái)，形成一個(gè)“演員-評(píng)論家”（Actor-Critic）模型：讓 LLM Actor 自由創(chuàng)造，讓嚴(yán)格的 Critic 程序來(lái)驗(yàn)證。

對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，這是一個(gè)天然的優(yōu)勢(shì)領(lǐng)域！

• Actor (LLM)：負(fù)責(zé)生成代碼、配置文件或執(zhí)行計(jì)劃。
• Critic：負(fù)責(zé)執(zhí)行一系列自動(dòng)化驗(yàn)證：

• 代碼能否編譯通過(guò)？
• 代碼能否通過(guò)測(cè)試？
• 代碼是否符合靜態(tài)檢查規(guī)范？
• 領(lǐng)域特定不變量：例如，如果 Agent 修改了訂單系統(tǒng)，是否依然滿足“訂單總價(jià)等于所有商品價(jià)格之和”這個(gè)業(yè)務(wù)規(guī)則？

這個(gè)反饋循環(huán)不僅能過(guò)濾掉錯(cuò)誤的輸出，更是 Agent 學(xué)習(xí)和改進(jìn)的基礎(chǔ)。

原則五：用 LLM 驅(qū)動(dòng)錯(cuò)誤分析

當(dāng) Agent 失敗時(shí)，手動(dòng)排查海量的日志是不現(xiàn)實(shí)的。我們可以構(gòu)建一個(gè)“meta Agent”來(lái)解決這個(gè)問(wèn)題，即讓另一個(gè) LLM 來(lái)分析失敗 Agent 的日志，找出問(wèn)題的根源。

流程：

1. 建立一個(gè)基線版本的 Agent。
2. 部署多個(gè)實(shí)例并收集它們的執(zhí)行軌跡和日志。
3. 將失敗的日志喂給一個(gè)具有更大上下文窗口（如 Gemini 1.5 Pro）的 LLM進(jìn)行分析。
4. 根據(jù) LLM 的分析洞察，改進(jìn)基線 Agent 的系統(tǒng)提示、工具或上下文管理。

這個(gè)元循環(huán)能高效地發(fā)現(xiàn)我們自己可能忽略的系統(tǒng)性問(wèn)題。

原則六：令人沮喪的行為是系統(tǒng)問(wèn)題的信號(hào)

當(dāng) Agent 做出一些“愚蠢”的行為，比如忽略你的明確指令，或者用一種奇怪的方式繞過(guò)問(wèn)題時(shí)，我們的第一反應(yīng)通常是“這個(gè)模型真笨”。

但作者建議：先調(diào)試你自己的系統(tǒng)，再怪罪模型。

作者分享了一個(gè)親身經(jīng)歷：他明確要求 Agent 使用一個(gè)集成工具來(lái)獲取數(shù)據(jù)，但 Agent 卻固執(zhí)地使用模擬的隨機(jī)數(shù)據(jù)。在憤怒地檢查日志后，他發(fā)現(xiàn)自己忘了給 Agent 配置正確的 API 密鑰。Agent 嘗試調(diào)用工具，連續(xù)失敗，最后只能選擇一個(gè)它能走的通的、但卻是錯(cuò)誤的路徑。

因此，當(dāng)你的 Agent 行為異常時(shí)，請(qǐng)檢查一下：

• 工具是否缺失？ 它是否需要一個(gè) write_file 的能力而你沒(méi)有提供？
• 提示是否模糊？ 你是否清晰地解釋了工具的用法和邊界？
• 上下文是否充分？ 它是否因?yàn)槿鄙俦匾畔ⅲū热缫粋€(gè) API 密鑰或文件權(quán)限）而無(wú)法執(zhí)行任務(wù)？

小結(jié)

構(gòu)建有效的 AI Agent，關(guān)鍵不在于尋找一個(gè)能解決所有問(wèn)題的“銀彈”提示或高級(jí)框架。它回歸到了系統(tǒng)設(shè)計(jì)和嚴(yán)謹(jǐn)?shù)能浖こ?/span>。

作為開(kāi)發(fā)者，我們應(yīng)該聚焦于：

• 清晰的指令（通過(guò)系統(tǒng)提示）
• 精簡(jiǎn)的上下文管理（通過(guò)工具和壓縮）
• 健壯的工具接口（簡(jiǎn)單、冪等、無(wú)歧義）
• 自動(dòng)化的驗(yàn)證循環(huán)（編譯、測(cè)試、靜態(tài)檢查）

當(dāng)你被 Agent 的行為所困擾時(shí)，記住，問(wèn)題很可能出在缺失的工具、模糊的提示或不足的上下文，而不是模型本身的局限性。將錯(cuò)誤分析視為開(kāi)發(fā)過(guò)程中的一等公民，我們的目標(biāo)不是構(gòu)建一個(gè)從不犯錯(cuò)的完美 Agent，而是構(gòu)建一個(gè)可靠的、可恢復(fù)的、能夠優(yōu)雅地失敗并被我們迭代改進(jìn)的Agent。