由寫 prompt 到設計工作手冊：Agent 工程方法論進化論

「寫 prompt」呢個詞，本身就係一個陷阱。

佢暗示緊 AI 互動嘅本質係「文字創作」——你愈有文采、愈識得用比喻、愈曉得喺 system prompt 裡面落咒語式嘅指令，個 AI 就愈聽你話。呢個想像喺 2023 年仲勉強 work，但到咗 2026 年，當我哋見到嘅生產力差距，唔再係寫得好唔好 prompt 之間嘅分別，而係有冇系統性 Agent 方法論之間嘅鴻溝，整個遊戲規則已經變咗。

我喺過去兩年親身經歷咗三次思維升級。每一次都痛苦，每一次都係將自己以前嘅作品推倒重來。但最有趣嘅係：每一次升級嘅核心問題都一樣——點樣令 AI 唔係「聰明一次」，而係「 consistently 可靠」？

從 Prompt 工匠到 Prompt 科學家

第一個階段，大家都經歷過：不斷 tweak system prompt，加 few-shot examples，試 chain-of-thought，試角色扮演。呢階段嘅產出極不穩定——同一條 prompt 今日得，聽日唔得；俾 A 模型得，俾 B 模型亂嚟。

關鍵轉折點係當我開始用 git 管理 prompt 版本。聽落好 trivial，但呢個動作代表本質認知改變：你唔再將 prompt 當作「一次性嘅 magic spell」，而係當作程式碼。程式碼要 version control、要 diff、要 rollback、要有 test suite。

我開始為每個 prompt 寫「測試用例」：已知嘅 edge case、預期輸出格式、唔可以犯嘅錯誤類型。每次改 prompt，先跑 test suite，pass 咗先 deploy。呢個流程响傳統軟件工程係 ABC，但响 prompt engineering 領域，2024 年中之前幾乎冇人做。

結果呢？穩定性大幅提升。但好快我發現另一個問題：即使 prompt 完美，context 都會背叛你。

Context Engineering：XMem 改變咗乜嘢？

2025 年尾到 2026 年嘅最大突破，唔係模型本身（雖然 Claude 4 同 GPT-5 都確實在進步），而係 Context Engineering 呢個 discipline 嘅成形。

傳統 prompt engineering 嘅最大盲點係：佢假設「輸入等於意圖」。你寫咗 system prompt，然後每次俾 user message，模型就應該理解你想點。但現實係，一個複雜任務嘅 context 係動態嘅——user 喺對話中途改變方向、新資訊令舊 plans 作廢、過去 50 條 message 入面有 3 條關鍵 constraints 被沖淡。

XMem 嘅出現解決咗呢個核心矛盾。佢本質上係一個結構化嘅工作記憶層，唔係將所有嘢塞入 context window，而係將資訊分為：

• 長期記憶：domain knowledge、規則、constraints（類似 system prompt 嘅進化版）
• 短期記憶：當前任務狀態、中間產出、user 最新指示
• 工作記憶：active execution context——模型而家做緊咩、下一個 step 係咩、有咩 pending decisions

呢個 triple-memory architecture，係 Agent 方法論嘅關鍵基礎。佢令到 model 唔再係「每次從頭讀晒成個 conversation」，而係好似人類工程師咁：長期記住公司規矩，短期記住呢個 sprint 做緊咩，工作記憶 focus 喺而家呢個 task。

實際效果極其驚人。我其中一個 production agent，導入 XMem 之後，task completion rate 由 73% 升到 94%，而且每個任務嘅 token consumption 反而降低咗 40%。點解？因為模型唔再需要喺每個 request 入面重讀大量 redundant context。

工作手冊：Agent 方法論嘅終極形態

Context Engineering 解決咗「模型記唔記得」嘅問題，但未解決「模型知唔知點做」嘅問題。呢個就係我哋需要 Agent Methodology 嘅原因。

傳統做法係喺 system prompt 入面寫 step-by-step instruction。但複雜 task 嘅 step 唔係線性嘅——有 branch、有 conditional、有 exception handling、有 human-in-the-loop 嘅 decision point。用文字描述呢啲 logic flow，唔單止冗長，而且模型容易迷失。

解決方案係工作手冊（Working Handbook）——一個結構化嘅 agent execution framework，包含：

1. Decision Tree：唔係 prompt 入面寫「如果 A 就做 B」，而係用 structured format（JSON/YAML）定義 decision nodes，每個 node 有 condition、action、fallback
2. Tool Registry：agent 可以 call 咩 tool、每個 tool 嘅 input/output schema、rate limit、error handling strategy
3. State Machine：task 嘅 lifecycle states，每個 state 有 allowed transitions、timeout behavior、rollback plan
4. Human Handoff Protocol：咩情況一定要問人、點樣 summarise context俾人、點樣接收 feedback 之後繼續

呢個 framework 嘅威力在於：佢將 agent 嘅行為從「黑盒 text generation」變成「白盒 state execution」。你可以 test 每個 decision node、可以 mock tool response、可以 replay 成個 execution trace 嚟 debug。

我而家嘅 workflow 係：先用 handbook 定義成個 agent 嘅行為邏輯，然後先開始寫 implementation。Handbook 本身會經過 code review，同 functional spec 一樣對待。Prompt 反而變成最後先寫嘅嘢——而且寫嘅時候，因為已經知道晒所有 decision points 同 state transitions，prompt 嘅目的好清晰：唔係「叫 AI 做晒成件事」，而係「喺已知嘅 framework 入面執行當前 step」。

結語：工程化係唯一出路

俾個 concrete advice。

如果你仲係用緊單一 system prompt 去 handle 複雜 task，停一停。你唔係喺度寫 prompt——你係喺度 build 一個 production system。對待佢嘅方式，應該同你寫 backend service 一樣：

1. 用 version control 管理 prompt 同 handbook，每次改動要有 diff 同 changelog
2. 為每個 agent 寫 test case，唔係 test AI 嘅能力，而係 test 你自己嘅 definition 有冇漏洞
3. 引入 structured context management——無論你用 XMem、mem0、定自建 solution，context 唔可以再係一條平嘅 text stream
4. 定義 state machine——你嘅 agent 必須知道自己喺邊個 state、可以去邊個 state、唔可以去邊個 state

2026 年嘅 AI 開發者，最大嘅競爭優勢唔係 prompt 寫得靚，而係有冇能力 design 一個系統——一個令 AI consistently 做到嘢、你可以 consistently debug、你可以 consistently improve 嘅系統。

由寫 prompt 到設計工作手冊，係一條從工匠到工程師嘅必經之路。呢條路唔易行，但係唯一行得通嘅路。