Nuway × KINYO · 顧問會議 #2
01 / 19
Claude · → Claude Code · → 自訂 Harness
Agent=LLM+Harness
從 Claude 生態到 Agent Harness。把上次的概念，收斂成一個能在企業裡落地的框架。
RAG · Agentic search · LLM Wiki
Nuway 歆界科技 · 2026
今天的路線
02 / 19
Agenda
今天會講什麼
1
Harness Engineering
Agent = LLM + Harness；三個核心元素：Context Management、Tool Use、Evaluation。
2
Context Management 框架
harness 的重點；RAG 與 LLM Wiki 兩種實作怎麼定位、運作。
3
Demo
同一份資料，把 RAG 與 LLM Wiki 兩種實作實際跑一次。
一條線：把 context 經營好，讓 AI 的產出穩定、可被信任。
Harness · 核心問題
03 / 19
今天的核心問題
AI 如何進入穩定的工作流？
AI 已經能回答問題。真正的門檻，是能不能穩定地進入企業的工作流程。
01
回答對一次不難，難的是每次都一致。
02
企業要的是可重複、可檢查、可追溯，不是單次表現。
03
這條線，決定 AI 是停在「試用」，還是真的被採用。
今天的內容，都是在回答這一個問題。
Harness · 框架
04 / 19
Agent=LLM+Harness
不管實作手段怎麼分，harness 的設計本質上都在解決三件事。
核心元素 ①
Context Management
上下文管理 —— 決定每一次餵給 LLM 看什麼。塞太少答不好；塞太多注意力分散、變慢、又燒 token；塞過時的會答錯。
核心元素 ②
Tool Use
工具使用 —— 給 agent 動手的能力：查訂單、寄信、串 API。要決定給哪些、給什麼權限、出錯怎麼辦。給 tool 等於交出一部分 production access。
核心元素 ③
Evaluation
評估 —— 判斷做對了沒、做錯怎麼回頭、長任務怎麼存進度。這是目前最難、還沒有標準答案的一塊。
Skill、Sub-agent、Routine、Guardrail 都是實作手段 —— 本質上都在解決上面這三件事。
Harness · 具體例子
05 / 19
把框架落到具體
用客服 Agent 來理解
model 是會理解客戶問題、生成回答的大腦。真正讓它變成「客服 agent」的，是外面的 harness。
·
SOP：退款、發票、訂單查詢，各自怎麼處理。
·
工具：能查訂單、付款、車牌、場站狀態。
·
規則：不能自己承諾退款，不能亂說「已完成」。
·
轉人工：高風險或高情緒的客訴要升級。
·
Log：讓主管知道它哪裡答錯。
·
Review：把錯誤案例變成下一版規則。
這一整套才是客服 agent 的 harness。換一顆更聰明的模型，不會自動長出這些能力。
Harness · 企業意義
06 / 19
這些環節為什麼對企業重要
穩定、可靠、可檢查
①
同一份資料，產出要一致。不能同一份採購數據，跑出五種版本。
②
同一個任務，流程要可重複。下一次要能照同樣的步驟再跑一遍。
③
同一個結論，要能追溯依據。答案來自哪份文件、哪一頁，要說得清楚。
④
同一套工作偏好，要能被保存與繼承。規範不該綁在某個人身上，要能傳下去。
模型決定能力上限；harness 決定這個能力能不能被穩定、安全、可重複地釋放出來。
Context Management · 框架
07 / 19
Harness 的一大重點
Context Management：兩種實作方式
Context Management
上下文管理 —— 在 agent 回答之前，給它對的背景。
實作方式 ①
RAG
查詢時，從 raw data（PDF / Excel / CSV / TXT）取出與問題相關的內容，塞進這次對話的 prompt。
實作方式 ②
LLM Wiki
Karpathy 的架構。不像 RAG 每次都從原始資料抓，而是先建好一個產品知識庫；回答時直接從整理好的知識取 context。
兩者在同一個層級 —— 可以混用，也可以單獨使用。接下來先把 RAG 講細，後段再回到 LLM Wiki。
RAG · 常見誤解
08 / 19
一個常見的簡化
不要把 RAG 簡化成 Vector DB
RAG 是「取得正確背景」這件事，不等於某一種特定技術。取得背景的方法有很多：
A
Vector DB —— 把資料向量化，找語意相近的片段。
B
Grep —— 直接在檔案裡用關鍵字查找。
C
結構化查詢 —— 對資料庫 / 報表直接下條件。
D
Agentic search —— 讓 Agent 自己決定怎麼找、找哪裡。
把 RAG 等於 Vector DB，會讓你只看到其中一種選項。
RAG · 洞察一
09 / 19
一份研究：Is Grep All You Need?（PwC · LongMemEval）
Grep vs Vector，要看任務
PwC 用 LongMemEval（116 題、4 種 Agent harness）比較不同檢索方式的表現。
93%/84%
某組設定下，grep 的準確率高於 vector。多數設定都是這個方向。
不是絕對
不同任務、不同資料，結果會變。應該以任務為準去測，而不是預設某一種一定贏。
結論不是「grep 比較好」，而是檢索方式要對著任務選。
RAG · 洞察二
10 / 19
同模型、同 grep，只是換 harness
Harness 會改變結果
77% → 93%
同一個模型、同樣用 grep，只是換了 harness，準確率就有這樣的差距。
所以 harness 的設計本身，和檢索方式一樣，會直接影響結果。這就是為什麼我們花時間談 harness。
RAG · Demo
11 / 19
同一份 PDF，兩個 project
PG Vector RAG vs Agentic search
對照
PG Vector RAG
Query →
Embed →
PG Vector →
Top-K →
Answer
vs
主推
Agentic search
Query →
Agent 規劃 →
查檔 / grep / 工具 →
自我檢查 →
Answer
現場拆兩者的內部流程，看行為差異。先看清楚，再決定哪個適合哪種任務。
LLM Wiki · 動機
12 / 19
另一種實作，解決特定問題
為什麼需要 LLM Wiki？
有些場景需要的是一份被持續維護、可長期依賴的產品知識。LLM Wiki 就是為這件事設計的。
·
知識被整理成可讀、可導覽的頁面。
·
持續維護：過期、矛盾由 LLM 主動清理。
·
回答可追溯到來源頁。
·
知識會累積、被繼承，不綁在某個人身上。
人會放棄 wiki，是因為維護成本超過回報。LLM 不會累、不會忘記更新 cross-reference、可以一次動 15 個檔案 —— 維護成本被壓到接近零。
LLM Wiki · 方法論
13 / 19
通用的知識庫建構模式
LLM Wiki 方法論
Markdown · 人機協作 · 持續維護的 Context
三層架構
Raw Sources · 原始來源
源文檔、文章、數據。不可變，LLM 只讀。
↓
Wiki 層 · LLM 生成的 Markdown
綜述 / 實體頁 / 概念頁，互相連結。
↓
Schema 層 · CLAUDE.md / AGENTS.md
約定、結構、工作流。你和 LLM 共同演化。
三大操作
Ingest · 摄入
投入源文檔 → 讀取、寫摘要、更新索引。
Query · 查詢
向 Wiki 提問 → 搜尋、綜合、引用來源。
Lint · 維護
定期檢查矛盾、過期、孤立頁、缺漏引用。
索引與日誌 · 角色分工
index.md
內容導覽，先讀索引再查頁。
log.md
時間序操作紀錄。
你（人類）
策劃來源、提問、引導方向。
⇄
LLM
總結、交叉引用、維護一致性。
Ingest 摄入流程
新源文檔
→
LLM 讀取分析
→
與你討論要點
→
更新 Wiki
一份源文檔可能觸及 10–15 個 Wiki 頁面
摘要頁濃縮重點
實體頁 × N產品 / 客戶 / 規格
概念頁跨主題的觀念
更新 index維持導覽
LLM Wiki · 可靠性
14 / 19
這套流程怎麼換來可靠
LLM Wiki 如何讓結果可靠？
Cite
回答能回到來源頁 —— 可追溯，不是憑空生成。
Lint
定期清矛盾、過期、孤立頁 —— 知識不會爛掉。
Index
固定導覽，Agent 從同一個入口找 —— 行為穩定。
Schema
CLAUDE.md 固定處理規則 —— 同樣的問題，同樣的處理方式。
合起來就是企業要的兩件事：可重複與可稽核。
LLM Wiki · 企業契合
15 / 19
為什麼它適合放進組織
如何符合企業的偏好與需求？
①
工作偏好與規範可以寫進 schema，並被後續繼承。
②
權限、風格、風險控制可以內建在規則裡。
③
知識長期維護，不綁在某一個人身上。
④
跨部門可以共用同一份 context，減少各說各話。
LLM Wiki · Demo
16 / 19
實際走一次
從文件到可追溯的回答
> 這個產品的保固條件是什麼？
· 讀 index.md … 定位到「產品 / 保固」相關頁
· 順 link → 產品主檔、保固說明、FAQ
· 比對來源，確認沒有過期或矛盾
✓ 回答 + 附上來源頁（可點開查證）
重點不是答得快，而是答案可以追溯回來源。這正是企業敢採用的前提。
收斂 · 兩種實作
17 / 19
兩種實作，怎麼選
RAG 與 LLM Wiki：依場景選用或混用
RAG
查詢時取資料
  • 適合即時、量大、常變動的資料
  • 查詢當下從來源臨時取出相關片段
  • 不必先整理，接上就能用
LLM WIKI
維護一份知識
  • 適合要長期維護、可追溯、跨部門共用的知識
  • 先整理成一份持續維護的知識庫
  • 回答從整理好的知識取用
兩者在同一個層級 —— 可以單獨用，也可以混用。不是誰取代誰、也沒有優劣。
收斂 · 全場回顧
18 / 19
整場分享的三條線
今天談的三件事
①
什麼是 Harness Engineering，為什麼現在都在談？Agent = LLM + Harness；三個核心元素：Context Management、Tool Use、Evaluation。
②
Context Management 的方法論框架。它是 harness 的重點；RAG 與 LLM Wiki 兩種實作怎麼定位、怎麼運作。
③
Demo：把兩種實作實際跑一次。用同一份資料，看 RAG 與 LLM Wiki 的行為差異。
一句收斂：把 context 經營好，讓 agent 的產出穩定、可被信任。
收斂 · 下一步
19 / 19
給 KINYO 的下一步
做一個最小的 Knowledge Harness 實驗
1
選一個任務
挑一件每個月都會做的高頻工作（例如保固查詢、報價前資料整理）。
2
建最小 wiki
一份 raw + 一個 CLAUDE.md + 一個 index + 幾頁整理好的知識。
3
跑一次
query → 回答 → 附上來源頁，確認答案可追溯。
4
下次帶來
一起看哪裡可靠、哪裡要補，再決定要不要擴大。
先做小、做到可檢查，再談規模。
1 / 19 點右側下一步 · F 全螢幕