別再迷信Prompt了，這才是Agent的真正戰(zhàn)場(chǎng)

曾經(jīng)被奉為AI魔法咒語的Prompt Engineering，如今在大模型Agent開發(fā)中的權(quán)重已大幅下降。本文探討了Prompt權(quán)重下降的原因，以及現(xiàn)代Agent開發(fā)的核心挑戰(zhàn)和替代方案，幫助從業(yè)者適應(yīng)這一范式轉(zhuǎn)移。

———— / BEGIN / ————

我們?cè)孕臥rompt Engineering是AI的魔法咒語，但隨著大模型智商飆升和應(yīng)用深入，Agent競(jìng)爭(zhēng)的主戰(zhàn)場(chǎng)早已轉(zhuǎn)移。

大模型Agent的核心還是Prompt嗎？

如果這個(gè)問題在2023年上半年提出，我會(huì)毫不猶豫地告訴你：是的，Prompt就是咒語，就是魔法，誰掌握了Prompt誰就是大法師。那時(shí)我們還在為如何讓GPT-3.5不”胡說八道”而絞盡腦汁地嘗試”Let’s think step by step”。

但在即將進(jìn)入2026年的今天，如果仍認(rèn)為Agent的核心競(jìng)爭(zhēng)力是Prompt，那在AI落地的一線戰(zhàn)場(chǎng)上，可能尚未經(jīng)歷真正的實(shí)戰(zhàn)洗禮。

觀點(diǎn)先行：Prompt權(quán)重的斷崖式下跌：

在2025年的當(dāng)下，Prompt在Agent開發(fā)中的權(quán)重，已從原來的90%降至最多30%。 Agent現(xiàn)在的核心是工作流編排、記憶管理、工具生態(tài)接口標(biāo)準(zhǔn)化，以及最關(guān)鍵的——自動(dòng)化評(píng)估體系。Prompt現(xiàn)在更多充當(dāng)前端交互層，是API調(diào)用的一個(gè)參數(shù)而已。

為什么Prompt不再占據(jù)主導(dǎo)地位？

前兩年大家迷信Prompt Engineering，是因?yàn)槟Ｐ捅旧淼倪壿嬐评砟芰Σ蛔?，需要通過精巧的話術(shù)引導(dǎo)甚至”哄著”模型工作。然而，當(dāng)今的DeepSeek V3、Claude 4.5 Sonnet等先進(jìn)模型，其意圖理解能力已大幅提升。即使給出粗糙的Prompt，模型也能大概率領(lǐng)會(huì)意圖。

真實(shí)案例對(duì)比：以往需數(shù)百字Prompt加少樣本示例才能讓Agent將混亂的會(huì)議紀(jì)要整理成JSON格式?，F(xiàn)在，只需簡(jiǎn)單指令”轉(zhuǎn)成標(biāo)準(zhǔn)JSON，字段自行判斷”，結(jié)果基本可用。

當(dāng)模型智商提升，Prompt這一”拐杖”的作用自然減弱。但這反而提高了Agent開發(fā)的門檻，因?yàn)楝F(xiàn)在要解決的是復(fù)雜任務(wù)。

以我們的供應(yīng)鏈Agent為例，其任務(wù)包括：檢測(cè)庫存安全水位、分析歷史銷量、預(yù)測(cè)需求、對(duì)比供應(yīng)商、生成補(bǔ)貨單并發(fā)送審批。這種多步驟流程無法依靠單一Prompt實(shí)現(xiàn)，必須依賴流程工程。

技術(shù)轉(zhuǎn)向：Agent開發(fā)的核心已從Prompt設(shè)計(jì)轉(zhuǎn)向Flow Engineering。如LangChain團(tuán)隊(duì)的LangGraph和吳恩達(dá)推崇的Agentic Patterns所示，現(xiàn)代Agent是由大模型驅(qū)動(dòng)的狀態(tài)機(jī)，需要明確定義步驟、成功/失敗路徑和數(shù)據(jù)傳遞邏輯。

在我們的代碼庫中，邏輯控制代碼的規(guī)模遠(yuǎn)超Prompt字符數(shù)。我們通過代碼約束模型行為，而非依靠自然語言祈禱模型表現(xiàn)良好。

當(dāng)前Agent開發(fā)的核心挑戰(zhàn)

隨著Prompt權(quán)重的下降，真正的挑戰(zhàn)浮出水面，主要體現(xiàn)在以下三個(gè)方面，這些問題在傳統(tǒng)Prompt優(yōu)化中找不到答案：

1. 規(guī)劃與執(zhí)行的脫節(jié)

大模型擅長制定計(jì)劃，但長鏈條執(zhí)行中容易”迷路”。例如，供應(yīng)鏈Agent中，模型規(guī)劃”先查A數(shù)據(jù)庫，再查B系統(tǒng)”，但當(dāng)A數(shù)據(jù)庫返回含特殊字符的數(shù)據(jù)，模型生成查詢B系統(tǒng)的SQL時(shí)會(huì)失敗，并陷入死循環(huán)。

解決方案：需要大量Guardrails代碼校驗(yàn)?zāi)Ｐ洼敵龅膮?shù)合法性，這是傳統(tǒng)Prompt工程無法解決的魯棒性問題。

2. 上下文污染與記憶管理難題

盡管當(dāng)今模型的上下文窗口可達(dá)128K甚至1M，但存在”中間迷失”現(xiàn)象：上下文越長，模型性能越受影響。在Agent運(yùn)行過程中，歷史消息快速積累，如何動(dòng)態(tài)管理上下文成為關(guān)鍵挑戰(zhàn)。

我們的實(shí)踐：引入”總結(jié)Agent”在關(guān)鍵節(jié)點(diǎn)對(duì)對(duì)話記錄進(jìn)行摘要，保留關(guān)鍵變量，替換原始對(duì)話。這要求精準(zhǔn)判斷哪些記憶長期有用（存向量數(shù)據(jù)庫），哪些短期相關(guān)（放上下文），哪些可丟棄。

3. 評(píng)估的黑盒問題

這是大模型落地團(tuán)隊(duì)最頭疼的問題。傳統(tǒng)軟件有單元測(cè)試（輸入A，輸出必為B），但Agent的輸出具有不確定性：輸入A，可能輸出B1或B2，語義相同卻形式各異。

更棘手的是隱性錯(cuò)誤：如供應(yīng)鏈Agent決策”補(bǔ)貨500件”，而算法計(jì)算為520件，結(jié)果看似可接受，但若依據(jù)錯(cuò)誤邏輯（如混淆月度數(shù)據(jù)），這種隱患難以檢測(cè)。

行業(yè)現(xiàn)狀：尚無完美解決方案，我們采用LLM-as-a-Judge方法，以更強(qiáng)模型評(píng)估小模型或Agent的執(zhí)行過程。

從Prompt Engineering到DSPy：范式轉(zhuǎn)移

既然Prompt不再是核心，那么什么是更好的替代方案？如果你仍在手動(dòng)調(diào)整Prompt，如將”You are a helpful assistant”改為”You are an expert data scientist”，那么是時(shí)候了解DSPy框架了。

DSPy由斯坦福大學(xué)開發(fā)，其核心理念極為超前：Prompt不應(yīng)由人工編寫，而應(yīng)由模型自我優(yōu)化。在這一框架下，你只需定義任務(wù)邏輯（Signature）并準(zhǔn)備高質(zhì)量數(shù)據(jù)集，DSPy便會(huì)自動(dòng)優(yōu)化Prompt，嘗試各種少樣本組合，調(diào)整指令，直至在測(cè)試集上達(dá)到最優(yōu)效果。

這類似于從匯編語言（手寫Prompt）升級(jí)到C++（使用DSPy），編譯器負(fù)責(zé)生成匯編代碼。我們團(tuán)隊(duì)已用DSPy Module替代許多手寫Prompt模塊，效率顯著提升。

實(shí)戰(zhàn)案例：保險(xiǎn)理賠核查Agent的演進(jìn)

讓我們通過一個(gè)保險(xiǎn)理賠核查Agent案例，具體理解這種思維轉(zhuǎn)變：

初始階段（Prompt思維）：編寫長達(dá)3000token的System Prompt，詳細(xì)規(guī)定車險(xiǎn)理賠規(guī)則。結(jié)果上線后，面對(duì)模糊照片，Agent幻覺出責(zé)任認(rèn)定書并錯(cuò)誤拒賠。原因是過長Prompt導(dǎo)致指令沖突，模型在信息不足時(shí)強(qiáng)行腦補(bǔ)。

進(jìn)階階段（Agentic Flow思維）：將大Prompt拆解為三個(gè)獨(dú)立Agent：材料初審Agent（檢查清晰度）、規(guī)則提取Agent（RAG檢索條款）、最終裁決Agent（綜合判斷）。Agent間通過代碼邏輯連接，如if 材料初審Agent.result == “不清晰”: return “請(qǐng)重傳”。

此案例中，各Agent的Prompt極為簡(jiǎn)單，核心競(jìng)爭(zhēng)力在于問題拆解架構(gòu)和Workflow設(shè)計(jì)能力。

給從業(yè)者的務(wù)實(shí)建議

基于實(shí)戰(zhàn)經(jīng)驗(yàn)，為同行提供以下建議：

• 放棄“通才”模型幻想，轉(zhuǎn)向“專才”協(xié)同趨勢(shì)是Multi-Agent System，如微軟AutoGen和LangGraph所示。需要掌握的是如何讓多個(gè)AI協(xié)作甚至辯論，而非單一Prompt技巧。

• 掌握結(jié)構(gòu)化輸出Agent內(nèi)部數(shù)據(jù)流轉(zhuǎn)必須是JSON或Pydantic對(duì)象。OpenAI的Structured Outputs和開源模型的Function Calling是接入傳統(tǒng)IT系統(tǒng)的橋梁。

• 重視SOP（標(biāo)準(zhǔn)作業(yè)程序）的數(shù)據(jù)轉(zhuǎn)化Agent所需的數(shù)據(jù)并非傳統(tǒng)訓(xùn)練集，而是企業(yè)SOP。例如，開發(fā)高效HR Agent依賴員工手冊(cè)和歷年案例。將這些SOP轉(zhuǎn)化為Agent可理解的工具或知識(shí)庫，才是核心競(jìng)爭(zhēng)力。

• 回歸代碼工程本質(zhì)Agent開發(fā)不能違背軟件工程原則：版本控制、單元測(cè)試、日志監(jiān)控、灰度發(fā)布等缺一不可。代碼錯(cuò)誤會(huì)報(bào)錯(cuò)，Agent錯(cuò)誤則會(huì)一本正經(jīng)地胡說八道，危害更大。

大模型Agent的核心早已不是Prompt。當(dāng)下的Prompt如同代碼中的變量命名：良好的變量名增強(qiáng)可讀性，但僅靠變量名無法構(gòu)建淘寶或微信這樣的系統(tǒng)。

真正的護(hù)城河在于系統(tǒng)架構(gòu)設(shè)計(jì)、數(shù)據(jù)流轉(zhuǎn)邏輯、異常處理以及垂直領(lǐng)域的行業(yè)知識(shí)，這些要素封裝于Workflow和工具中。因此，不必過度糾結(jié)Prompt的雕琢，而應(yīng)積極學(xué)習(xí)LangGraph、DSPy，提升RAG準(zhǔn)確率，將業(yè)務(wù)SOP代碼化。這才是應(yīng)對(duì)未來挑戰(zhàn)的關(guān)鍵。

Prompt是對(duì)話的起點(diǎn)，而智能的工作流與堅(jiān)實(shí)的工程化能力，才是Agent價(jià)值持續(xù)增長的基石。

本文來自公眾號(hào)：栗子 作者：栗子

想要第一時(shí)間了解行業(yè)動(dòng)態(tài)、面試技巧、商業(yè)知識(shí)等等等？加入產(chǎn)品經(jīng)理進(jìn)化營，跟優(yōu)秀的產(chǎn)品人一起交流成長！