When Agents Meet Physical Data: The Other Physics of Agent Harnesses - Dmitry Petrov, DataChain
三句話摘要
編碼代理必須搭配專用數據框架才能有效處理視頻、傳感器等非結構化物理數據。 編碼代理只有通過專為物理數據設計的框架（Pydantic模型、執行引擎、增量更新、知識庫），而不是單靠提升模型強度，才能高效應對非結構化數據的指數級複雜性。 代理在非結構化物理數據上失效率高（Anthropic 21%準確度、OpenAI需6層上下文），單靠更強模型無解。問題根本上是結構化商業邏輯與物理二進制數據的架構差異。
重點整理
重點- 1
代理在非結構化物理數據上失效率高（Anthropic 21%準確度、OpenAI需6層上下文），單靠更強模型無解。問題根本上是結構化商業邏輯與物理二進制數據的架構差異。
- 2
非結構化數據複雜度指數爆增。視頻內含片段→幀→物體→置信度→標籤的多層嵌套（「中子星效應」），90支影片產生100,000筆記錄，分析數千支影片輕易衝破百萬筆。傳統JSON+S3或單數據庫方案都引發一致性或系統複雜度問題。
- 3
統一架構層是突破口。用Pydantic定義數據模型，包含文件路徑、幀ID、時間戳、類別、置信度、邊界框及嵌套的元數據欄位，讓Python代碼、數據架構、查詢邏輯用同一語言表達，消除SQL孤島。
- 4
四層框架缺一不可：Pydantic數據模型、分布式執行引擎（支援40台機器平行處理）、增量更新機制（失敗後只補算新增）、多維元數據層（採星型架構，代理先檢查現成數據集，沒有才構建）。知識庫以Markdown檔案記錄每個數據集的創建理由、會話背景、源代碼、預覽、架構、統計，下次查詢可復用結果。
實用技巧與重點
乾貨- 測試結果
- Anthropic無框架代理數據準確度：21%
- OpenAI數據代理所需上下文層級：6層
- 工具與框架
- 模式定義：Pydantic
- 分布式計算對比：Dask（推薦，整合計算+存儲）、Ray、Spark
- 開源項目：DataChain（物理AI數據處理）
- 案例數據
- 資料集：行車記錄儀開源數據，1月份91個影片
- 模型選擇：YOLO（最小版本）
- 速度追蹤：簡單速度計算方式
- 粒度：每幀檢測
- 結果：90個視頻 → 100,000筆檢測記錄 → 24分鐘分析完成
- 查詢例：92/91個視頻含人物檢測
- 數據建模技術
- 多維數據建模（Multidimensional Data Modeling）
- 星型架構（Star Schemas）
- 單大表方法（One Big Table）
- 知識庫文件結構
- 數據集描述
- 會話上下文（為何建立此數據集）
- 存儲依賴（指向原始檔案位置）
- 數據預覽
- 架構定義
- 統計指標
- 源代碼（最關鍵）
- 數據譜系
- 源數據（Object Storage）→ 計算引擎 → 數據集與元數據 → 數據倉庫 → 知識庫
結論
結論“編碼代理只有通過專為物理數據設計的框架（Pydantic模型、執行引擎、增量更新、知識庫），而不是單靠提升模型強度，才能高效應對非結構化數據的指數級複雜性。”
完整解析
詳細編碼代理在非結構化物理數據上表現不佳。Anthropic和OpenAI的研究發現，通用代理處理數據項目的準確度僅21%，OpenAI甚至需要6層專用上下文才能運作。這不是模型大小問題，而是結構化商業邏輯世界與非結構化物理數據世界的根本差異。
非結構化數據的複雜性呈指數增長，就像「中子星」—表面看起來只是幾個或幾千個視頻檔案，但內部包含片段、幀、物體、置信度分數、標籤等層層嵌套結構。演講者以實際案例說明：分析90個行車記錄儀視頻，光是人物檢測就產生100,000筆記錄。若擴大到數千個視頻，記錄數輕易破百萬；再細化到物體層級，規模可能增加10到100倍。
傳統的數據組織方式效率低下。許多團隊將元數據存為JSON檔案，放在S3旁邊，結果產生數百萬個JSON、高延遲和一致性問題。進階團隊改用集中式數據庫，卻引入了兩個系統、兩種編程語言和複雜的系統棧，研究人員往往不願處理這種複雜度。解決方案是統一使用Pydantic模式—用同一Python語言定義數據結構、架構和代碼，徹底消除代碼庫中的「SQL孤島」。
完整的數據框架由四層組件構成。第一層是基於Pydantic的數據模型，定義視頻檔案、幀ID、時間戳、類別ID（代表人物或車輛等）、置信度分數、邊界框坐標，以及嵌套的檔案元數據（路徑、版本控制ETag、文件大小）。第二層是執行引擎，負責高效的並行或分布式處理。研究人員只需指定所需資源數量（例如40台機器），引擎自動分配任務。第三層是增量更新和檢查點機制，如果處理失敗，修復後只需補算新增的檔案，無須從頭開始，大幅節省成本。第四層是元數據層組織，採用傳統數據倉庫的多維建模和星型架構等技術。關鍵創新是：代理在回答問題前，先自問「我是否已有適當的數據集能快速回答」，若無才構建新的元數據層，且構建時採取足夠通用的設計，以服務一類相關問題而非單次查詢。
知識共享機制防止重複計算。每個數據集應在知識庫（以Markdown檔案組織）中完整記錄：數據集創建的理由、會話背景、存儲依賴路徑、數據預覽、架構定義、統計指標和生成代碼。源代碼是最關鍵的部分，讓下次遇到類似問題的代理和團隊成員能直接理解和復用。整個系統形成完整的數據譜系：原始數據→計算引擎→數據集→數據倉庫→知識庫，每一層都相互連接，讓代理和人類都能看到全貌。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
