AI Agent 的 5 個層級：從 Prompt 到 Production

現在大家談到 Agent 時，總愛掛在嘴邊的五個詞：Context engineering、loop engineering、Jev engineering、harness engineering、eval engineering。

聽起來像是五種互相競爭的方法，其實不是。它們是同一套系統的五個層次，每一層只回答一個問題。

要理解它們，最簡單的方式就是想像你剛招了一位新員工：

• Context —— 當你問他事情時，他桌上擺了什麼
• Loop —— 他是照著你的清單做，還是自己判斷下一步該怎麼走
• Jev —— 負責分信的前台，讓他只看得到重要的東西
• Harness —— 他的辦公室。有哪些工具、哪些權限，以及誰來檢查他的工作
• Evals —— 每個月考同一份測驗，你才知道他是不是真的進步了

AI Agent 就是那位員工。模型是人本身，而這五個層次就是他身邊的一切。把這五層做對，小團隊就能接下過去非得靠加人才能做的活。重複性的工作交給能在正式環境穩定運作的 Agent，你的人則專注做決策。這就是「不加人手也能擴大規模」的真實樣貌。

針對每一層，我會拆解它是什麼、怎麼運作、用在哪裡，以及如何打造。

我也為每一層準備了一條捷徑——不用從零開始，就能達到同樣效果的簡單做法，專為新手設計。我的朋友 Viktor 團隊幫我整理了這些捷徑。

Viktor 是一位住在你的 Slack 或 Microsoft Teams 裡的 AI 員工。他跟所有人待在同一個頻道，像隊友一樣工作，而且你不需要開新職缺就能把他加進團隊。

跟他合作就像跟真人共事：

• 你在頻道或討論串裡標記他，描述任務。
• 他自己拆解步驟、跨工具完成工作，再把結果貼回同一個討論串。

設定很簡單。只要把 Viktor 加進你的工作區，他就會像其他成員一樣出現在參與者名單裡。如果你想邊讀邊試，可以使用代碼 YARCHI100。

圖 1. Agent 的五個層次

1. Context engineering

定義

每次提問前，你都會在員工桌上放幾張紙。放對三頁，他幾秒內就能回答；塞三百頁進去，答案就埋在紙堆中間，他根本找不到。

模型就是員工，桌子就是 context window（上下文視窗）：模型在回答前看到的所有東西。你的指令、目前的對話紀錄、從資料庫拉出來的文件、每個工具跑完的輸出。

Context engineering 就是決定桌上要放什麼、放在哪裡。

運作方式

上下文越多，不代表答案越好。超過某個臨界點後，反而會變差。

Stanford 直接測試過這件事。給模型 20 到 30 份文件，它對中間那些文件的準確率會掉到 50% 至 57% 左右。但一份文件都不給的時候，同一個模型卻能拿到 56%。答案明明就在視窗裡，表現卻比什麼都沒有還糟。

原因有兩個：

• 模型最注意視窗的開頭和結尾，最不注意的是中間。
• 每個 token 都要花錢花時間，不管它有沒有用。

唯一值得了解的機制是 prompt caching（提示快取）。服務商會儲存你 prompt 的開頭，下次呼叫時直接重用，而快取過的 token 成本大約只有全新 token 的十分之一。

但有個陷阱：只有當開頭內容「逐位元組完全相同」時，快取才會生效。只要改動前面任何一個字元，後面的內容就得按原價計費。所以順序永遠是：不變的內容放前面，會變的內容放最後。

如何打造

所有上下文都只會放進四個地方之一：

1. System prompt。 只放每次呼叫都成立的內容：角色、限制條件、輸出格式。保持逐位元組一致。開頭別放時間戳記，JSON key 也別亂排順序。
2. Tools。 不要在對話中途新增或移除工具。這會破壞快取，還會讓模型去呼叫已經不存在的工具。如果要在某個步驟限制使用某工具，請阻擋呼叫，但保留定義。
3. Disk。 體積大或長期存在的東西都放進檔案，視窗裡只留路徑。網頁也一樣：留 URL，丟掉內文。丟掉內容，只留能把它取回來的 key。
4. Tail。 每隔幾個步驟，就在上下文末尾重申一次當前目標。中間那段你救不了，所以別把重要的東西放在那裡。

工具數量也有上限。Anthropic 測量過，光是 58 個工具定義，在使用者還沒打任何字之前，就會吃掉大約 55,000 個 token。讓模型自己去搜尋工具，而不是一次全部載入，Opus 4 在他們的基準測試上從 49% 提升到了 74%。

20 個工具以內，全部載入沒問題；超過這個數字，就改用搜尋。

處理大型任務還有一招：派 sub-agent 出去。它在自己的視窗裡讀完那 50 個檔案，交回一頁摘要。你的主上下文永遠只看得到那份摘要。

圖 2. 一次模型呼叫裡裝了什麼

捷徑

Viktor 幫你扛下了大部分工作，因為他的 context 是公司層級的。

• Memory。 他會在全團隊範圍內持續記住你的業務資訊。上週從你共同創辦人那裡學到的東西，今天不必再貼進你的請求裡。
• Connected sources。 接上 Notion、Google Drive 或 HubSpot 之後，你就不用再把檔案貼進聊天室。你只要說出文件或紀錄的名稱，他就自己去讀來源。這就是上面說的 disk 規則，他幫你做好了。
• Skills。 你錄一次螢幕操作，他把錄影轉成文字流程，你修改並核准。從此這份指令就固定下來且經過審查，就像一份優質的 system prompt。

剩下你要做的：

• 寫一次簡短的公司簡介：你們賣什麼、誰在買、哪些數字重要、他絕對不能做什麼。
• 一個討論串只做一件事，並在第一則訊息裡定義清楚「完成」是什麼意思。
• 如果他學錯了什麼，直接去設定裡清除記憶，別在每個討論串裡一直糾正他。

2. Loop engineering

定義

你可以給員工一張清單：打開檔案、改第 12 行、存檔。也可以給他一個目標：讓測試通過。

有了目標，他會先試一種做法、觀察結果，再決定下一步。清單是 workflow（工作流程），目標則是 loop（循環）。

運作方式

Loop 就是四個動作不斷重複：思考、行動、觀察、決定。修 bug 的過程長這樣：

1. 跑測試。三個失敗。
2. 看第一個錯誤。少了一個 import。
3. 補上 import，重跑。
4. 還有一個測試失敗。讀那個錯誤、修正、重跑。
5. 全部通過。停。

沒有人事先寫好這些步驟。模型是看完上一步的結果後，才選出下一步的。

這就是全部的差別。你自己寫的一百個步驟依然是 workflow；模型自己選的三個步驟才是 loop。

只有在你無法事先寫好步驟時，才用 loop。寫得出來就寫。Workflow 更便宜、能平行執行，而且第四步失敗時，你只需要重跑第四步，不用全部重來。

Loop 也很貴。Agent 消耗的 token 大約是單次呼叫的四倍。Multi agent 架構則高達十五倍左右。

如何打造

Loop 需要四個部分。拿掉任何一個，它就跑不起來：

1. 一個有明確「完成標準」的目標。 不是「修好 bug」，而是：「auth_test.py 裡失敗的測試通過了，而且沒有弄壞其他東西。」
2. Checker（檢查器）。 模型之外、能判定 pass 或 fail 的東西：測試套件、編譯器、linter。關於自我修正的研究結論很一致：有真正的外部回饋才行得通，只讓模型自己檢查自己就會失敗。沒有 checker 就不叫 loop，只是無底洞式的花錢。
3. 停止規則。 Checker 通過了、達到回合上限了，或者連續兩次嘗試產出一樣的結果。
4. 預算。 回合數和金額，兩者都要設。

在程式碼裡，整套邏輯只要幾行：

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # 完成
7    if repeated(history, 2):  break   # 卡住了
8    if spent() > BUDGET:      break   # 太貴了
9else:
10    fallback_workflow(goal)

我見過公開發表的最佳正式環境架構是混合式。Atlan 會先跑一層確定性過濾，只有大約 14% 的進站警報會真正送到 Agent 手上。

接著 loop 最多跑三輪。如果三輪後信心度仍低於 50%，就換固定的 Python workflow 接手。

先過濾、短暫循環、不行就退回備案。

圖 3. 如何在 workflow 與 loop 之間做選擇

捷徑

你在討論串裡交給 Viktor 的每個任務都是一個 loop。你寫目標，他挑步驟、跨工具執行，再帶著結果回到討論串。

四個部分的對應方式如下：

• Goal。 遇到不完整的 brief 他會反駁，寧可發問也不瞎猜。但你還是得寫清楚「完成」的定義。「上週營收報告，總數要對得上 Stripe，週一早上 9 點前貼到 #finance」絕對比「做份報告」有用。
• Checker。 貼出來之前，他會標記看起來不對的數字。你可以指定要比對的來源讓它更強：Stripe 總額、資料列數、測試套件。
• Stop rule。 敏感操作會暫停等人確認，結果也一定會回到你手上。
• Budget。 Credits。推理等級決定了每一步的價格，而對定期任務來說，頻率很關鍵。每小時跑一次的報告比每週一次貴得多。

Atlan 的混合架構不用寫程式也能做到。重複的工作變成排程任務：由他提議，在你核准前保持暫停。那就是你的 workflow。

開放式的任務就丟進討論串，那就是你的 loop。而你本人就是備案。

3. Jev engineering

定義

辦公室裡的專家不會親自拆每一封信。前台有人負責分信：帳單一堆、垃圾郵件進垃圾桶、合約轉給法務。

你的 Agent 做兩種事：寫東西，以及做決定。現在是一個大模型兩件事全包，等於你花律師的錢去分信。

Jev 就是前台。它不寫東西，只負責挑選。

運作方式

你事先給 Jev 一個問題和可能的答案選項。它會回傳以下三種結果之一，外加一個信心分數：

• yes 或 no
• 從選項集合中挑一個
• 量表上的一個數字

因為它只負責挑，所以又快又便宜。官方宣稱的數據是 70 到 500 毫秒，對比一般的 3 到 329 秒；每百萬 input token 收費 $0.042，output 免費。

現在說點實話。Jev 才推出兩週，獨立測試才剛開始出現。

• 在信件分類上，普通的 logistic regression 拿到 98.9%，Jev 是 98.6%。
• 在釣魚郵件偵測上，Jev 拿到 62.6%，而 Claude Haiku 4.5 是 81.3%。
• 「零幻覺」這個數字附帶作者自己的註腳：這不是實證結果，只代表輸出永遠符合 schema。

信心分數也不是開箱即用的真實機率。把它當成排序依據，並用你自己的標註資料設定閾值。

如何打造

合理的架構是在昂貴模型前面加一道關卡：

1. 所有請求進來。
2. Jev 針對每一項回答一個狹窄的問題。
3. 有信心且例行的：便宜處理。標註、分流或直接丟掉。
4. 沒把握或不尋常的：送給主模型。

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # 預設走安全路線：沒把握的就送昂貴路徑

在做這些之前，先試最笨但可能有效的做法。標註幾百個真實案例，訓練一個基本分類器，只有不夠好的時候才往上換。

這只要三十分鐘，而且是任何廠商宣稱都必須打敗的底線。

圖 4. Jev 回答的三種問題類型

捷徑

Jev 目前不在 Viktor 公開的技術堆疊裡，但這個概念可以用在你掌控的兩個地方：

• 推理等級。 他有三種模式：Smart 跑 Claude Opus，Balanced 跑 Claude Sonnet（成本約一半），Ultra 跑 Claude Fable（成本約兩倍）。分類請求或抓一個數字，根本不需要最高等級。
• 他前面的關卡。 如果你想讓他處理客服信件或警報這類資料流，別把整條流都丟給他。先加一個分類器或 Jev 呼叫，只有真正需要判斷的項目才會變成他的任務。

這是即使用了 Viktor，你自己的工程能力依然關鍵的兩個層次之一。

4. Harness engineering

定義

同一個員工，兩間辦公室。第一間裡他有正確的工具、牆上有操作手冊、有同事檢查他的工作，但沒有保險箱鑰匙。第二間裡他只有一台筆電和你的管理員密碼。

技能一樣，結果天差地遠。員工是模型，辦公室就是 harness。

Agent = 模型 + harness。

運作方式

Harness 就是模型以外的一切：工具、權限、沙盒、說明專案的文件、輸出的檢查機制。

它在 2026 年成為一門獨立學科，因為大家開始實際測量，發現模型的解釋力不如預期：

• Anthropic 只改了容器資源，基準測試分數就差了 6 分。
• LangChain 凍結模型，只改 harness，同一個基準測試就提升了 13.7 分。
• 接著他們用便宜十倍的開源模型調校 harness，直到它拿到 0.86，逼近 Opus 4.8 的 0.87。

你買的不再只是模型，而是模型加上 harness 的組合。

只要 Agent 碰到真實的東西——repo、收件匣、付款、正式環境資料庫——你就立刻需要一套 harness。

如何打造

由外而內建構：

1. Containment（隔離）。 Agent 物理上碰不到的東西。容器、獨立分支、唯讀資料庫使用者、除了白名單外沒有網路。在第一次 prompt 之前就要做好。
2. Guides（指引）。 在它行動前引導它的東西。Repo 裡的 AGENTS.md 這類檔案、清楚到讓模型能選對的工具描述、幾個良好輸出的範例。
3. Sensors（感測器）。 在它行動後檢查它的東西。Linter、型別檢查器、測試套件：速度快且結果確定，所以每樣東西都跑。較慢的檢查，例如用第二個模型 review diff，只用在重要的地方。
4. Permissions（權限）。 當 Agent 請求核准時，人類有 93% 的時間會直接放行。核准提示幾乎保護不了什麼。真正的保護是那些根本不可用的操作。把核准留給少數真正無法復原的事。

指引檔不需要很長。四行就足以改變行為：

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

Hook 是同一個概念的強制版。在 Claude Code 裡，hook 是一段在工具呼叫前執行、並能阻擋該呼叫的小腳本。「絕對不能 push 到 main」應該做成 hook，而不是 prompt 裡的一行字。

提醒一下。你 harness 裡的每一個元件，都是在賭模型做不到某件事，而這些賭注是有期限的。Anthropic 曾在模型升級後刪掉一整塊 scaffolding 元件，因為它變得沒必要了。

每隔幾個月重新檢視你的 harness，刪掉模型已經不再需要的部分。

圖 5. Harness 的四道防線

捷徑

如果 Agent = 模型 + harness，那你用 Viktor 得到的大部分東西都是 harness。底層模型是 Claude，而模型周圍的一切都現成可用：

• Tools。 3,200+ 整合：GitHub、Linear、HubSpot、Stripe、Notion、Google Drive 等等。遇到沒有現成連線的工具，他能自己建一個。
• Guides。 Skills。你不用自己寫 AGENTS.md，而是錄下螢幕操作，他草擬流程，你再編輯。
• Sensors。 他會標記兜不攏的資料，也會質疑缺漏的 brief。而且每一步都會落在團隊看得到的 Slack 討論串裡。
• Permissions。 客戶信件和財務變動會暫停等核准。新的排程自動化會保持暫停，直到有人開啟。

沒有任何產品能幫你做好的部分是 containment，因為它是由你交出去的憑證構成的。記住那個 93%，並且用完成工作所需的最低權限連接他：

• 唯讀的資料庫使用者
• 受限的 Stripe key
• 共用客服信箱，而不是你的個人信箱
• 限定特定 repo 範圍的 GitHub token

他碰不到的東西，就弄不壞。

圖 6. Viktor 的 harness

5. Evals engineering

定義

你怎麼知道新員工進步了？拿上個月考過的那份測驗再考一次，然後比較。

沒有同一份測驗，你做的每個改動都只是猜。Evals 就是你給 Agent 的那份測驗：一組你早就知道正確答案的任務，每次改動後都要跑一遍。

運作方式

檢查分為兩種：

• End to end（端對端）。 最終答案對了嗎？它只能告訴你分數變了，不能告訴你為什麼。
• Behavioral（行為）。 某個特定動作發生了嗎？回答前有先呼叫 search 嗎？需求模糊時有先問清楚嗎？說「完成」前有先驗證嗎？

行為檢查跑的是 trace（Agent 所有操作的日誌），而不只是最終答案。Google 的原則是這套測試要在五秒內跑完，這樣才能每次改動都執行。

如果用模型來評分，那就是 judge（裁判），而裁判也需要被檢查。Airbnb 發現，他們由模型產生的參考答案中，大約有四分之三在相同輸入的重複執行中會出現差異。他們的 eval 量到的其實是自身的雜訊。

如何打造

1. 從真實失敗案例出發。 翻閱實際執行紀錄，找出哪裡出錯，把每個錯誤轉成測試案例。Airbnb 的黃金資料集會跑 50 到 100 個範例，而且一定要包含失敗案例。
2. 每個案例寫一個行為檢查。 一個案例，只驗證一件事。
3. 檢查你的 judge。 人工抽樣評分，看看你和模型的共識有多高，再決定要不要信任它。
4. 從正式環境抽樣。 Airbnb 每天抽取 5% 的線上流量。當真實使用情境偏離時，你的 eval 資料集就會失效。

單一案例可以小到這種程度：

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

別只盯著整體通過率。它可能上升，但某個特定行為卻悄悄壞掉了。要看個別檢查項目的變化。

圖 7. 好的 eval 案例從哪來

捷徑

沒有產品能幫你把這一層做好，因為只有你知道對你的業務來說，正確答案長什麼樣。不過方法可以直接套用：

• 兩週後，挑出 20 個你知道正確答案的討論串。把你不得不糾正他的那些全部算進去。
• 每個案例寫一個簡單的檢查。每個數字都有附上來源嗎？Brief 模糊時他有發問嗎？任何東西離開公司前他有暫停嗎？
• 每次改動後重跑這組測試：新增 skill、修改 brief、切換等級。從 Smart 換到 Balanced 大約能省下一半 credits，所以在永久切換前先測試。
• 每週人工抽評五個隨機討論串。

整合起來

五個層次，五個問題。Context 是它看到什麼。Loop 是誰來決定。Jev 處理便宜的決策。Harness 是它能碰到什麼、誰來檢查它。Evals 是你怎麼知道它行不行。

用 Viktor 的話，其中三層大致上都內建好了：context、loop 和 harness。Jev、evals，以及你交出去的憑證，依然是你的工程責任。

如果你今天就要開始，每一層最划算的做法是：

• Context： 把穩定的指令搬進 system prompt，然後別再改它。
• Loop： 放手讓它跑之前，先設好回合上限和金額上限。
• Jev： 針對 Agent 最常做的決定，標註 200 個範例。
• Harness： 用一個無法刪除任何東西的使用者身分來跑 Agent。
• Evals： 把最近五次失敗寫成測試案例。

換成 Viktor，同一天會變成這樣：

• Context： 寫好公司簡介，錄下你的第一個 skill。
• Loop： 在每個任務裡寫清楚「完成」的定義，並有意識地挑選推理等級。
• Jev： 在任何資料流變成他的任務之前先過濾。
• Harness： 用唯讀、限定範圍的憑證連接他。
• Evals： 存下 20 個真實討論串作為你的第一組測試集。

這是一天的工作量，而且五層全顧到了。

我的看法：模型已經不再是難的部分，圍繞它的這五層才是。把它們做對，你就能在不加人的情況下提升產能。多數團隊應該直接採用前三層的現成方案，把自己的時間花在決定品質的後兩層上：便宜的決策和 evals。

感謝 Viktor 贊助本文。

到 @viktor_com 免費試用。$100 credits，不用綁卡。完整連結在我的第一則回覆裡。

註冊時請使用代碼 YARCHI100。

付費合作