n8n + AI Agent 提示工程：2025 年最有效的實操技巧

作者：AI研究生 2025-10-31 01:45:00

根據 Anthropic 的 Context Engineering 研究，在 2025 年，真正重要的不是“prompt engineering”，而是“context engineering”。問題不再是“如何打造完美的 prompt”，而是“哪種 context 組合能引發期望的行為”。

為什么大多數 Prompting 方法會失效

我會帶你走一遍當前研究（Anthropic、OpenAI、Google、Wharton）對 AI agent prompting 的結論——以及如何在 n8n 工作流中具體落地。

你將學到：

System Message vs User Prompt（以及為什么錯誤的分離會讓 token 成本翻倍）
2025 年真正有效的五大核心技巧（有研究背書）
高級模式（Chain-of-Thought、RAG、Structured Outputs、Tool Use）
為什么應該與模型一起生成 prompt，而不是手工堆砌
模型相關注意事項（只講實際相關的）
生產級模式（測試、錯誤處理、token 優化）

復制模板的陷阱

我經常見到：有人在 Reddit 上找到一個“完美”的 prompt 模板，復制到 AI Agent Node 里，然后期待它“魔法生效”。

劇透：不會。

復制模板失敗的原因：

Context mismatch：模板是為完全不同的用例、數據、工具寫的
Model differences：模板對 Claude 3 有效，而你用的是 GPT-4o-mini
Over-complexity：模板有 500 行，因為作者想覆蓋所有邊界情況
Under-specification：模板過于通用，對任何事都不夠好

Anthropic 的 Prompt Engineering 指南強調“找到合適的高度”（right altitude）——對指導足夠具體，但又為推理留有空間。模板對你的特定場景來說，幾乎總是在錯誤的高度。

第二個問題：Prompt 過于復雜

“越多越好”的思路會帶來巨大問題：

Ignored instructions：當 context 超過 800+ 行，模型會開始忽略指令——Context Engineering 研究顯示 LLM 有“有限注意力預算”
Increased latency：更多 tokens = 更慢響應
Higher costs：每個額外 token 都要花錢
Maintenance nightmare：800 行 prompt 幾乎無法調試或優化

解決方案：與模型一起生成 prompt

真正的游戲規則改變者是：讓模型為你寫 prompt。

不要花數小時打磨 prompt，而是給模型：

你的目標（agent 要做什么）
示例（輸入/輸出對）
約束（不該做什么）

模型會生成為你場景優化的 prompt。你測試、與模型迭代、再細化。

為什么有效：模型最了解自己的“偏好”。它知道哪種表述、結構、示例最有效。

稍后我會展示具體做法。

基礎：n8n 中的 System Message 與 User Prompt

n8n 的 AI Agent prompting 中最基礎也最常見的錯誤：混淆 System Message 和 User Prompt。

在 AI Agent Node 中，有兩個不同的 prompt 區域：

System Message（Options → System Message）：

定義 agent 的持久“DNA”
每次請求都會發送
幾乎不變/不應該頻繁更改
包含：role、tools、workflow、constraints

User Prompt（主輸入）：

只針對“本次請求”的具體任務
來自 Chat Trigger、Webhooks 或前置節點
每次請求都變化
只應包含本次的具體任務

圖片

為什么重要：Token 經濟學與 Prompt Caching

兩者都會隨每次 API 調用發送。但正確分離對成本和性能都至關重要：

錯誤做法（把一切都塞進 User Prompt）：

"You are Senior Support Engineer. Tools: search_docs, create_ticket.
Use search_docs first. Max 150 words. Friendly.
User question: {{$json.message}}"

若每天 1,000 次請求、每次 400 tokens： = 400,000 個冗余 tokens = 以 Claude Sonnet（$3/M）計：$1.20/天 = 每月 $36 的純冗余 context

正確做法：

System Message（只定義一次）：

You are Senior Support Engineer.
TOOLS:
- search_docs(query): Search Product Docs
- create_ticket(title, priority): Create Support Ticket
WORKFLOW:
1. FAQ → search_docs
2. Complex Issue → create_ticket
BEHAVIOR:
- Max 150 words
- When uncertain: Create ticket, don't guess

User Prompt 僅為：{{$json.message}}

= 每次 50 tokens 而非 400 = 節省：每天 350K tokens = 每月約 $31.50（以 Claude Sonnet 計）

Prompt Caching：為什么 System Message 應盡量保持靜態

Anthropic 和 OpenAI 提供 Prompt Caching——System Message 會被緩存，不必每次都重新處理。可將延遲降低 50–80%，對已緩存的 tokens 成本最高可降至 10%。

但：一旦你更改 System Message，緩存就會失效。因此：

設計 System Message 為靜態：基礎角色、工具、工作流邏輯
用 User Prompt 承載可變信息：動態數據、具體任務
僅在出現重大變更時更新 System Message：新增工具、工作流邏輯改變

緩存影響示例：

無緩存：請求 1：500 tokens 的 System Message = $0.0015 請求 2：500 tokens 的 System Message = $0.0015 請求 1000：500 tokens 的 System Message = $0.0015 總計：1,000 次請求 $1.50

有緩存（System Message 保持穩定）：請求 1：500 tokens 的 System Message = $0.0015（寫入緩存）請求 2：500 tokens 緩存命中 = $0.00015（便宜 90%）請求 1000：500 tokens 緩存命中 = $0.00015 總計：~$0.15/1000 次請求 = 90% 節省

Dynamic System Messages：強大但要謹慎

你可以用 n8n Expressions 讓 System Message 動態化——但要注意緩存：

You are Support Engineer for {{$('Get Config').item.json.company_name}}.

PRODUCT: {{$('Get Config').item.json.product_description}}
TONE: {{$('Get Config').item.json.support_tone}}

適用場景：多租戶系統——一個工作流，多個客戶配置。

工作流：Webhook（Customer ID） → DB Lookup → AI Agent（動態 System Message） → Response

緩存權衡：動態 System Message 會破壞緩存——僅在必要時使用。

五大核心技巧：2024–2025 年研究給出的答案

來自 Anthropic、OpenAI、Google 在 2024–2025 的研究顯示：有一些對所有模型都有效的基本技巧。以下五條最重要：

圖片

技巧 1：清晰與具體（“Altitude” 原則）

Anthropic 的 Prompt Engineering 指南稱之為“找到合適的高度”（right altitude）——既足夠具體以提供指導，又為推理保留靈活性。

“同事測試”：如果一個聰明的同事看不懂這條指令，AI 也不會懂。

反例：

Classify emails intelligently and accurately.

“intelligently” 是什么？有哪些類別？輸出格式是怎樣？

正例：

Classify emails into: sales, support, billing, general

URGENCY CRITERIA:
- high: contains "urgent", "asap", "immediately", "broken"
- medium: time-related request without extremity
- low: everything else
OUTPUT: JSON
{
  "category": "support",
  "urgency": "high",
  "confidence": 0.92
}

為何有效：

消除歧義（明確只有四類）
提供決策標準（非主觀）
明確輸出格式（無需猜測）
可度量（有 confidence 分數）

技巧 2：正向指令（質量提升 57%）

Bsharat 等（2024）研究顯示，正向指令明顯優于負向指令。將“不要做 X”改為“請做 Y”，平均帶來 57% 的質量提升。

負向指令為何失效：

模型先要理解你“不想要”的
再推斷你“想要”的
這個兩步推理經常失敗

負向反例：

Don't be too wordy.
Don't use technical jargon.
Don't make assumptions about customer intent.

正向改寫：

Keep responses under 150 words.
Use plain language that a non-technical customer understands.
When customer intent is unclear, ask clarifying questions.

實際影響：

在生產環境的郵件分類 agent 中，負向指令（“不要誤判緊急請求”）造成 31% 的漏判。正向改寫（“凡含時間限制的請求一律標記為 urgent”）將漏判降至 8%。

技巧 3：Few-Shot Learning（示范勝于告知）

Few-shot 示例非常有效——但大多數人用錯了。

研究共識：

大多數任務 2–5 個示例最優（更多幫助不大）
示例要“多樣化”（avoid 相似堆砌）
應包含 edge cases
Label bias 重要：Zhao 等（2021）顯示示例順序會影響結果

糟糕的 few-shot（過于相似）：

EXAMPLES:
1."How do I reset my password?"→category:support,urgency:low
2."Where is the password reset option?"→category:support,urgency:low
3."I can't find password settings."→category:support,urgency:low

全是同一種問題。模型學不到邊界處理。

良好的 few-shot（多樣且含 edge cases）：

Example 1 (Standard):
Input: "How do I reset my password?"
Output: {"category": "support", "urgency": "low", "confidence": 0.95}

Example 2 (Urgent):
Input: "URGENT: System down, can't access customer data!"
Output: {"category": "support", "urgency": "high", "confidence": 0.98}

Example 3 (Mixed Intent):
Input: "I want to upgrade my plan but also report a billing error."
Output: {"category": "billing", "urgency": "medium", "confidence": 0.78, "note": "Multiple intents detected"}

Example 4 (Edge Case - Unclear):
Input: "help"
Output: {"category": "general", "urgency": "low", "confidence": 0.45, "action": "request_clarification"}

為何有效：

覆蓋不同場景（標準、緊急、混合、不清楚）
示范如何處理邊界（低置信度 → 追問澄清）
展示一致的輸出格式
讓模型學習決策模式，而非僅做類別匹配

技巧 4：Constraints & Grounding（對抗幻覺）

AI agents 的大問題之一：hallucination（幻覺）。找不到答案時它們會編造。

解決方案：顯式約束，將 agent “落地”。

糟糕做法（無約束）：

Answer customer support questions based on our documentation.

后果：找不到信息時 agent 會胡編。

良好做法（顯式約束）：

Answer customer support questions using ONLY information from the documentation you can access via search_docs tool.

CONSTRAINTS:
- If information is not in docs: "I don't have that information in our current documentation. I'll create a ticket for our team to help you."
- Never make assumptions about features or functionality
- Never provide workarounds that aren't documented
- If multiple solutions exist: Present all documented options
ESCALATION CRITERIA:
- Customer mentions "urgent", "broken", "down" → create ticket immediately
- Question requires account-specific data → create ticket with details
- Documentation is incomplete/contradictory → create ticket noting the issue

為何有效：

清晰邊界（ONLY 文檔中的信息）
明確兜底行為（不確定時怎么做）
升級標準（何時轉人類）
不留“自由發揮”的空間

生產影響：

在每月處理 2000+ 詢問的客服 agent 中，加入約束將幻覺率從 23% 降至 3%。升級的人工工單質量顯著提升，因為工單會包含具體的文檔缺口信息。

技巧 5：Context Engineering（最小高信號 token 集）

Anthropic 的研究很明確：不是“更多 context”，而是“正確的 context”。

原則：Smallest High-Signal Token Set

你的 context 中每一個 token 都應提供價值
冗余信息會稀釋關鍵信號
更多 context ≠ 更好表現（往往適得其反）

糟糕的 context（冗長、重復）：

You are a helpful AI assistant designed to help customers with their questions and concerns. You should always be polite, professional, and courteous in your responses. Make sure to read the customer's question carefully and provide a thorough and complete answer that addresses all of their concerns. If you're not sure about something, it's better to say you don't know than to provide incorrect information...

350 個 token 的空話，幾乎沒有可執行指導。

良好的 context（密度高、具體）：

You are Support Agent.

RESPONSE REQUIREMENTS:
- Max 150 words
- Plain language (non-technical)
- Structure: Problem acknowledgment → Solution → Next steps
TOOLS:
- search_docs(query) → search product documentation
- create_ticket(title, priority, details) → escalate to human team
WORKFLOW:
1. Search docs for relevant information
2. If found: Provide answer with doc reference
3. If not found OR customer mentions "urgent"/"broken": Create ticket

110 個 token，信號密度很高。每行都有可執行信息。

Token 審計：

對 prompt 中每個句子問一句：“刪掉它，agent 會變差嗎？”如果不會，就刪。

高級模式：何時用（何時別用）

核心技巧適用于所有場景。下面這些高級模式非常強，但要“對癥下藥”。

模式 1：Chain-of-Thought（CoT）——用于復雜多步推理

沃頓商學院 2025 年 6 月的研究給出了迄今最全面的分析：CoT 對復雜推理有幫助，但對簡單任務效果參差。

何時使用 CoT：

需要多步邏輯推理
數學計算
有依賴關系的復雜決策樹
中間步驟重要的任務

不該用 CoT 的場景：

簡單分類（增加負擔無益）
模式匹配型任務
對速度極其敏感（CoT 會增加延遲）

圖片

在 n8n 中的實現：

TASK: Analyze customer request and determine best resolution path.

REASONING PROCESS (think step-by-step):
1. IDENTIFY: What is the core issue? (Quote specific parts of message)
2. CLASSIFY: Which category? (sales/support/billing/general)
3. ASSESS URGENCY: Time-sensitive keywords? Tone indicators?
4. CHECK PREREQUISITES: Can we resolve with available tools?
5. DECIDE: Route to appropriate handler with reasoning
Think through each step explicitly before providing your final answer.

性能影響：

準確度提升：復雜推理任務提升 2–5%
延遲增加：20–40%（模型輸出更多 tokens）
成本增加：與輸出 token 增長成正比

結論：只有當準確度提升能抵消成本和延遲的權衡時，才使用 CoT。

模式 2：RAG（Retrieval-Augmented Generation）——用于外部知識

當你的 agent 需要：

動態/頻繁更新的內容（產品目錄、文檔）
體量巨大、放不進 context 的知識庫
客戶特定數據（訂單記錄、賬戶詳情）
訓練語料之外的專有信息

RAG 就是必需的。

n8n 中的 RAG 基本流程：

Webhook/Trigger
  ↓
Extract Query (user's question)
  ↓
Vector Search (retrieve relevant chunks from knowledge base)
  ↓
AI Agent (answer using retrieved context)
  ↓
Response

關鍵 RAG 要點（基于 kapa.ai 的分析）：

Chunk size：每塊 500–800 tokens（大多任務的最佳區間）
Overlap：塊間重疊 50–100 tokens（避免邊界信息丟失）
Number of chunks：返回 3–5 個最相關塊
Reranking：向量召回后做語義重排以提升相關性
Metadata：包含來源、時間戳、置信度

RAG Prompt 示例：

Answer the customer's question using ONLY the information provided below.

CONTEXT FROM DOCUMENTATION:
{{$json.retrieved_chunks}}
CUSTOMER QUESTION:
{{$json.user_message}}
INSTRUCTIONS:
- Base answer strictly on provided context
- If context doesn't contain the answer: "I don't have that information in our current documentation."
- Include source reference: "According to [doc_title]..."
- If multiple relevant sections: Synthesize information from all
CONFIDENCE ASSESSMENT:
- High confidence: Answer directly stated in context
- Medium confidence: Answer can be inferred from context
- Low confidence: Context is incomplete → escalate

模式 3：Document Repacking——順序比你想的更重要

Wang 等（2024）研究發現：context 的“順序”影響顯著。

發現要點：

Primacy bias：模型更注意開頭的信息
Recency bias：也更注意結尾的信息
Middle neglect：中間的信息更容易被忽略
性能影響：通過最優排序可提升 5–10% 準確度

最優排序策略：

最相關/最重要的信息放最前
次要的支持信息放中間
約束與提醒放最后（利用近因效應）

示例（RAG context）：

MOST RELEVANT DOCUMENTATION:
[Chunk with highest relevance score]

ADDITIONAL CONTEXT:
[Supporting chunks]
CONSTRAINTS (IMPORTANT):
- Answer only from provided context
- If uncertain: Escalate to human team

模式 4：Structured Outputs——為數據抽取提供 100% 可靠性

OpenAI 的 Structured Outputs（GPT-4o）及其他模型的類似能力，解決了一個大問題：獲得一致、可解析的輸出。

傳統 prompting 的問題：

Output format: JSON with fields category, urgency, confidence

模型可能會輸出：

合法 JSON
帶多余字段的 JSON
缺字段的 JSON
格式錯誤的 JSON
先文字解釋再給 JSON

你得為這些情況全部做兜底。

Structured Outputs 的方案：

定義 JSON schema，配合 Structured Output Parser 節點攔截異常即可。

示例 schema：

{
  "type":"object",
"properties":{
    "category":{
      "type":"string",
      "enum":["sales","support","billing","general"]
    },
    "urgency":{
      "type":"string",
      "enum":["low","medium","high"]
    },
    "confidence":{
      "type":"number",
      "minimum":0,
      "maximum":1"
    },
    "reasoning": {
      "type": "string"
    }
  },
  "required": ["category", "urgency", "confidence"]
}

好處：

不再有解析錯誤
保證 schema 合規
下游處理更簡單
Enum 約束（只允許有效值）

何時使用：

非結構化文本的數據抽取
固定類別的分類
需要特定格式的 API 集成
任何對輸出格式一致性要求高的任務

元技能：與模型一起生成 prompt

我構建 AI agents 的方式就此改變：別再手寫 prompt，讓模型來生成。

流程：

定義需求（agent 要做什么）
提供示例（能代表期望行為的輸入/輸出對）
指定約束（絕不該做什么）
讓模型生成“優化后的”prompt
測試并迭代（基于實際表現微調）

Meta-prompt 示例：

I'm building an AI agent for customer support email classification. Help me create an optimal system message prompt.

REQUIREMENTS:
- Classify emails into: sales, support, billing, general
- Assess urgency: low, medium, high
- Output format: JSON with category, urgency, confidence
- Must handle edge cases: unclear intent, multiple topics, spam
TOOLS AVAILABLE:
- search_docs(query): Search documentation
- create_ticket(title, priority, description): Escalate to humans
EXAMPLES OF DESIRED BEHAVIOR:
[Include 3-5 diverse examples with input and expected output]
CONSTRAINTS:
- Never make up information
- When uncertain (confidence < 0.7): Escalate
- Response under 150 words for direct answers
- Include reasoning in output
Generate an optimized system message that will consistently produce these results.

模型會生成一個：

結構與措辭最優
融合有效技巧
在具體與靈活間取得平衡
針對你用例的 prompt

為何有效：

模型了解自己的“偏好”
它會采用最優結構和表述
你能省下大量試錯時間

模型相關注意事項：哪些真的重要

大多數“模型特定技巧”并不靠譜。但有些差異確實重要：

Claude（Anthropic）：

優勢：復雜推理、長 context（200K tokens）
劣勢：有時過度謹慎，會拒絕無害請求
最佳實踐：明確寫清 constraints，再讓其自由推理
Prompt caching：對 >1024 tokens 的 System Messages 啟用

GPT-4o（OpenAI）：

優勢：Structured Outputs（100% schema 合規）、速度快
劣勢：context 較短（128K），較少“深思熟慮”
最佳實踐：數據抽取使用 Structured Outputs，配合精確指令
Prompt caching：對 System Messages 自動啟用

GPT-4o-mini：

優勢：便宜（$0.15/M vs $3/M），適合簡單任務
劣勢：復雜指令魯棒性較弱
最佳實踐：使用具體、結構化的 prompts，配 few-shot 示例

Gemini（Google）：

優勢：多模態（圖像、視頻）、超長 context（2M tokens）
劣勢：tool-use 支持較弱，有時不穩定
最佳實踐：用于多模態場景，避免復雜工具編排

選型經驗法則：

復雜推理 + 長文檔 → Claude Sonnet
數據抽取 + Structured Outputs → GPT-4o
簡單分類 + 預算敏感 → GPT-4o-mini
多模態（圖/視頻）→ Gemini

生產級模式：測試、錯誤處理、優化

好 prompt 遠遠不夠——你需要生產級工作流。

測試策略

用真實的 edge cases 測，別只測“快樂路徑”：

Test cases for email triager:
? Standard support request
? Angry customer (caps, exclamation marks)
? Sales inquiry with technical questions (mixed intent)
? Very short message ("help")
? Wrong language (if only English supported)
? Spam/irrelevant content

錯誤處理

AI agents 可能失敗——要有兜底：

n8n workflow:
AI Agent Node
  → IF Error OR confidence < 0.7:
     → Fallback: Route to Human
  → ELSE:
     → Continue with automated workflow

帶 confidence 的 System Message 約定：

If you're uncertain (confidence < 70%):
Set "needs_human_review": true in output

Token 優化

高并發下，每個 token 都很寶貴：

移除冗余：例如 “Please”、“Thanks”、“I think”
合理縮寫：“Maximum”→“Max”，“Information”→“Info”
使用符號：“→” 代替 “then”，“?” 代替 “correct”
用 JSON 替代散文：結構化數據優于長句

監控與日志

跟蹤關鍵指標：

Latency：agent 響應耗時
Token usage：每次請求的輸入 + 輸出 tokens
Error rate：失敗頻率
Confidence distribution：置信度分布

在 n8n 中：用 Webhook → Google Sheets 進行輕量記錄：

After AI Agent Node:
→ Set Node (Extract Metrics):
   - latency: {{$now - $('AI Agent').json.startTime}}
   - input_tokens: {{$('AI Agent').json.usage.input_tokens}}
   - output_tokens: {{$('AI Agent').json.usage.output_tokens}}
   - confidence: {{$('AI Agent').json.confidence}}
→ Google Sheets (Append Row)

上線檢查清單

上線前：

Prompt 質量：

System Message 與 User Prompt 是否正確分離？
System Message 是否穩定以利用 prompt caching？
是否使用正向指令（而非“避免 X”）？
是否有含 edge cases 的 few-shot 示例？
約束是否清晰？
輸出格式是否明確？

測試：

是否用 10+ 個真實測試用例？
邊界情況（短輸入、錯別字、混合意圖）是否覆蓋？
錯誤處理是否有效？
不確定時是否有 fallback 策略？

性能：

Token 是否優化（無冗余）？
是否啟用 prompt caching？
延遲是否可接受（< 3s）？
單次請求成本是否核算？

監控：

是否記錄 token 使用？
是否實現錯誤跟蹤？
是否啟用置信度評分？
是否有關鍵指標儀表板？

迭代：

是否有 A/B 測試策略來改進 prompt？
是否建立基于真實用戶數據的反饋回路？
是否規劃定期復盤？

總結：2025 年真正有效的是什么

五大通用核心技巧：

Clarity & Specificity：合適的“高度”——具體且保留推理空間
Positive Instructions：質量提升 57%（Bsharat 等，2024）
Few-Shot Learning：多樣示例 + 邊界情況
Constraints & Grounding：以清晰邊界對抗幻覺
Context Engineering：最小高信號 token 集

情境性高級模式：

Chain-of-Thought：僅用于復雜多步推理（提升 2–5%）
RAG：應對外部/更新知識（chunk 500–800 tokens）
Document Repacking：通過排序提升 5–10% 準確度
Structured Outputs：數據抽取 100% 可靠（GPT-4o）

元結論：

復制模板會失敗——與模型一起生成 prompts
保持 System Message 穩定以發揮 prompt caching（可省 90% 成本）
Token 經濟學比“完美措辭”更重要
用 edge cases 做測試比“再加幾個 few-shot”更關鍵

圖片

你的下一步：挑一個現有的 n8n AI Agent 工作流，套用以上五大核心技巧。對比前后 token 使用。通常你會看到成本大幅下降，同時輸出質量不降反升。

這就是“勉強可用”的 prompting 與“可規模化、可上生產”的 prompting 的區別。

責任編輯：武曉燕來源： AI大模型觀察站

n8n AI Agent