全部場數

082 · 企業 Agent 的三大結構破口

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

2026-07-2012:07Ishita Daga（Tesla）Agent評估開發工具看原片

原標題：Enterprise Agents Have a Structure Problem - Ishita Daga, Tesla

重點摘要

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

時間軸

時碼點下去會跳到影片的那一段。

時碼段落重點
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 需要更好的結構與持續評估脈絡的機制。

值得記的話

名詞與人物

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 這類檔案式記憶被提到是儲存偏好的做法之一，但講者認為它無法區分不同指標之間的差異。