企業 Agent 的三大結構破口

082Ishita Daga（Tesla）12:072026-07-20

Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla

從 Tesla 資料工程師的角度，拆解企業資料 agent 常答錯的三個根源：來源模糊、脈絡老化、偏好難捕捉。

重點摘要

加大模型不是解方：遇到 agent 答錯，多數團隊的直覺是換更大的模型、塞更多知識庫或外掛 MCP 工具，但講者認為這些都只是治標，沒碰到 agent 真正卡住的地方。
資料來源模糊：agent 不知道該用哪張表、哪個欄位、哪個資料源才是正確依據，各個知識庫看起來都差不多重要，卻沒人告訴它哪個才是最乾淨、最權威的來源。
脈絡會過期：業務定義、KPI、計算方式與流程一直在變，若沒有持續更新餵給 agent 的內容，脈絡很快就跟現實脫節。
偏好因人而異：同一個問題，不同團隊或個人會用不同指標、不同篩選條件作答，這種主觀偏好很難被單一標準規範，講者認為這仍是業界沒解決的開放問題。
兩段式解法：把資料來源分成三層、優先做好前兩層，再搭配「記錄修正事件、更新脈絡、跑評測」的循環，對抗資料源模糊與脈絡老化這兩個問題。

時間軸15 段

00:00	開場	Ishita Daga 自我介紹，說明她在 Tesla 負責打造企業用的資料 agent，這場要談 agent 背後的結構性問題。
00:53	三大病灶登場	換模型、加知識庫都是治標；agent 真正卡住的地方之一，是不知道該信哪個資料源。
01:34	脈絡會過期	定義、KPI、流程一直在變，若沒有持續更新 agent 的脈絡，資訊很快就跟現實脫節。
02:11	偏好因人而異	同一個問題，不同團隊或個人會用不同指標、篩選條件作答，這種偏好很難被單一標準規範。
03:23	來源分層：semantic layer	講者把資料來源分成三層，最乾淨、最權威的一層是 semantic layer，收錄所有 KPI 定義與計算方式，agent 優先從這裡找答案。
04:01	第二層：canonical tables	給 agent 一批預先寫好的參數化查詢，讓它能更靈活拼出答案，但可靠度比 semantic layer 低一些。
04:39	第三層：database graph	把每張表、每個欄位、每個指標互相連結成一張巨大關聯圖，彈性最高，但建置與維護成本也最高。
05:33	先做前兩層就夠	講者認為 semantic layer 與 canonical tables 就能解掉 80% 的問題，剩下 20% 才交給 database graph。
06:09	對抗脈絡老化	提出 context life cycle 兩段式做法，先確保 GitHub、CRM、Tableau、dbt 等來源持續更新，當成 agent 一定要看的「活資料」。
07:08	把每次修正都記下來	只要有人指出資料庫、定義或計算方式錯了，就要把這個事件記錄下來，用來更新 agent 的脈絡。
07:30	別忘了做評測	用人工標註或自動化方式評估 agent 表現；講者直言很多團隊不重視評測，這正是 agent 常常失準的原因。
08:41	偏好難以捕捉	同一個指標，不同團隊常用不同算法或篩選條件計算，這種主觀性很難被單一系統完整捕捉。
09:01	舉例：兩個團隊算法不同	以「平均完成時間」為例，A 團隊用前一里程碑到當前里程碑計算，B 團隊卻用當前里程碑到下一里程碑計算，兩種算法都對，答案卻完全不同。
10:02	兩種可能解法	一是把不同算法都收進 semantic layer 讓使用者自己選，二是靠 agent memory（如 Mem0 或 memory.md）記住個人偏好，但仍無法真正分辨該用哪個指標。
11:34	結語	講者總結三大問題：資料來源模糊、脈絡老化、偏好難捕捉，強調企業 agent 需要更好的結構與持續評估脈絡的機制。

值得記的話4 句

The agent actually has these three main problems, one is ambiguity.agent 真正卡住的地方有三個，第一個是資料來源模糊00:53
These are easy to set up, solve, I think, 80% of the problems and then the 20% can be solved by the database graph.這兩層架起來不難，大概能解掉 80% 的問題，剩下 20% 再靠 database graph 解決05:33
A lot of teams do not focus on evaluation that much and which is why the agents actually fail so often.很多團隊不夠重視評測，這正是 agent 常常出錯的原因08:07
Different teams will calculate the same metric differently, or use the same query but different filters.不同團隊算同一個指標的方式不一樣，或是用同一個查詢卻套不同篩選條件08:41

名詞與人物6 個

Tesla: 講者任職的公司，這場談的是她在公司內部打造企業資料 agent 的經驗。
semantic layer: 把 KPI 定義、指標算法、業務規則整理成一份標準答案，讓 agent 優先參考的資料層。
canonical tables: 預先寫好的一批參數化查詢，給 agent 更大彈性去回答問題，可靠度比 semantic layer 低。
database graph: 把資料表、欄位、指標互相連結成的關聯圖，彈性最高，但建置與維護成本也最高。
context life cycle: 講者提出的做法，靠持續更新活資料與記錄修正事件，讓 agent 的脈絡不至於老化。
Mem0: 講者提到用來記住使用者偏好的 agent memory 工具，但她認為它仍無法分辨該用哪個指標。

提到但沒有展開

業界與 frontier labs 目前都還在嘗試解決偏好這種個人化問題，講者說目前沒有公認的解法。
講者提到 GitHub、CRM 工具、Tableau、dbt 的 semantic layer 都可以當作活資料來源，但沒有進一步說明如何串接。
memory.md 這類檔案式記憶被提到是儲存偏好的做法之一，但講者認為它無法區分不同指標之間的差異。

Agent評估開發工具

在 YouTube 看原片 ↗