我是誰

Agenda

👥 預期聽眾

多數談 Harness Engineering 是在講 Claude Code、Codex 來做軟體開發流程。

本場不是這個角度，而是站在「自行開發 AI Agent」的切入點。你要做的可能是 Text-to-SQL Agent、知識庫 RAG Agent，場景各式各樣，用途不一定是軟體開發。

PART 1

Recap:
什麼是 Deep Agent

複習 Agent 1.0 迴圈

Agent 2.0 (Deep Agent) 的六項能力

這些能力讓 Agent 應付更大更複雜的任務，技術上都是用到 Function Calling 來實現的

Deep Agent 內建能力 ①: Plan & Todos

Deep Agent 內建能力 ②: Filesystem & Bash

Deep Agent 內建能力 ③: Sub-Agent

Deep Agent 內建能力 ④: Memory

Deep Agent 內建能力 ⑤: Skills

Deep Agent 內建能力 ⑥: 更多工具

但有能力 ≠ 把事情做好

PART 2

什麼是
Harness Engineering

「做完了」誰說了算?

什麼是 Harness? ➡️ Agent = Model + Harness

首先，harness 不只是技術功能列表

回顧 Prompt、Context、Harness 三層

常被講成一條「演進」之路，但其實技術累加的都會用上，只是各自凸顯一個新的工程焦點:

並沒有「XXX 已死」這回事，後者是基於前者的發展之上，而非取而代之。

Harness 核心策略: 先 generate，再 verify

核心策略就是: 驗證 (verification)，廣義的說就是 回饋(feedback)

兩個軸把 harness 拆解

Thoughtworks 用兩個軸拆解 harness 作法: 方向×型態:

好的 Harness 做兩件事

前饋 Guides

你的 system／developer prompt，要把「什麼是好的結果」以及「驗證流程」寫清楚。 例如 AGENTS.md／CLAUDE.md 都會要求 Agent 要去做驗證

前饋的限制

前饋終究是軟性、機率性的引導

你在 AGENTS.md 寫十遍「一定要驗證」，模型還是有可能跳過 😢

回饋 Sensors: 把 verify 變成自動執行

前饋是軟性引導；回饋則用程式自動執行，不靠模型自覺

這可以插在 Agent lifecycle 的不同位置，來給 Agent 回饋。

本場將深入講解回饋的四個時機點

當然，前饋和回饋缺一不可

本場將重點講「回饋訊號」:要有東西能判斷做得好不好、做得對不對、做完了沒。

回饋的四個時機點

把 agent 的迴圈由內而外拆解，回饋有四個時機點:

回饋的四個時機 ①②③④

PART 3 · 時機 ①

在工具執行內

Tool Call 裡面

工具呼叫內，有三個可以設計的地方:

工具輸出不只是 function output，
是你寫給 Agent 的回饋

寫程式習慣把回傳值當「資料」: 查到什麼回什麼，出錯就回傳 error code

案例: Text-to-SQL Agent

在工具內: 把 SQL 解析成語法樹(AST)，做確定性的檢查和改寫

import sqlglot
from sqlglot import exp

tree = sqlglot.parse_one(sql_query, dialect="postgres")

# 1. 只允許 SELECT（擋下來）
if not isinstance(tree, exp.Select):
    return "只允許 SELECT 查詢"

# 2. 資料表白名單（擋下來）
for table in tree.find_all(exp.Table):
    if table.name not in ALLOWED_TABLES:
        return f"資料表 {table.name} 不在允許範圍，可用：{ALLOWED_TABLES}"

# 3. 沒 LIMIT 就補安全上限（補強）
if tree.args.get("limit") is None:
    tree = tree.limit(200)

safe_sql = tree.sql(dialect="postgres") # 確保輸出 postgres 語法

工具回饋的設計

驗證沒過時，tool response 的品質決定 Agent 自我修正的能力

連「成功」都可以回傳更多狀態資訊

工具回傳的引導訊息

各種純運算式(Computational)的檢查，回傳的是對應的固定訊息:

def collect_feedback(output, source):
    # 純運算式檢查:規則直接判定,不靠 LLM,沒過就回寫死的固定訊息
    msgs = []
    if count_words(output) > 500:
        msgs.append("摘要超過 500 字，請縮短")
    if missing_required_terms(output):
        msgs.append("漏掉必留的專有名詞，請補回")
    if cosine_similarity(output, source) < 0.8:
        msgs.append("與原文語意偏離，請貼近來源重寫")
    return msgs

設計回傳值的另一個重點: 需要有意識地控制 context window

注意控制別塞滿 context。context 過了某個門檻，模型會變笨(context rot)

別忘了 Context Engineering 的整套策略，各種縮減 context 的技術:

案例: 知識庫 RAG Agent

知識庫問答 Agent 會配一個 search_knowledge(query) 工具 (關鍵字搜尋＋向量搜尋 等)

工具不只回傳搜尋結果，我們還可以回傳以下資訊，回饋給 Agent 更多資訊:

工具回傳除了 top-k，還夾帶統計與指示

<results query="API timeout issues">
  <ticket id="LIN-1247" status="Done">…</ticket>
  <ticket id="LIN-1189" status="Done">…</ticket>
</results>
<facets>
  <status_facet> <value name="Done" count="6"/> <value name="Open" count="5"/> </status_facet>
</facets>
<system-instruction>
  回傳的 2 筆全是 Done。facets 顯示另有 5 筆 Open 沒進 top-k，請改用 search(query, status="Open") 追查進行中的問題。
</system-instruction>