當使用者提供的資料集、模型生成的程式碼、套件安裝、產生的圖表以及可下載的輸出必須在隔離且可觀察的環境中執行時，AI 資料分析工具就需要沙箱化的 Python。實務上的實作流程是：上傳檔案、用可信賴的程式碼檢查結構、要求模型提供計畫、審查生成的 Python、在受限制的沙箱中執行、驗證輸出成品，最後向使用者展示結果。
AI 資料分析工具架構：上傳、分析、審查
產品模式表面上看起來很簡單：使用者上傳 CSV 檔案，用自然語言提問，然後期望得到有用的表格、圖表和可下載的檔案。在幕後，應用程式正在執行一個帶有實際副作用的小型代理程式工作流程。模型負責規劃分析並草擬 Python 程式碼，而應用程式則決定哪些程式碼、套件、檔案、網路存取和輸出是被允許的。
建立第一個版本時，請遵循一條清晰的路徑：
- 接受一個 CSV 上傳，對應一個分析任務。
- 建立一個任務範圍的沙箱工作空間。
- 在要求模型產出 Python 程式碼之前，先執行自有結構檢查程式碼。
- 要求模型提出分析計畫，然後根據你的檔案和套件規則撰寫腳本。
- 在時間、記憶體、磁碟、套件和網路限制下執行腳本。
- 只從指定的輸出目錄收集經過驗證的成品。
- 向使用者展示答案、圖表、警告、日誌，以及供下載的檔案。
這種分離方式讓責任歸屬清晰。模型負責提出並解釋分析內容。後端則負責應用產品政策及編排工作。沙箱則在受限的檔案、套件、時間、記憶體、網路存取和機密資訊下執行程式碼。
Python 沙箱內執行哪些資料分析工作？
將分析工作空間放在沙箱內部，而不是你的主應用伺服器內。沙箱應接收一個針對單一分析任務的精簡輸入套件：上傳的檔案、一個小型的清單、一個生成的腳本，以及任何經核准的執行環境設定。應用程式後端應將驗證、計費、使用者身分、長期儲存和生產環境機密資訊保留在工作空間之外。
對於 AI 資料分析工具，沙箱通常負責以下任務：
| 沙箱任務 | 為什麼屬於這裡 |
|---|---|
| 檔案準備 | 上傳的 CSV 可以在 Python 處理之前被掃描並複製到隔離的工作目錄中。 |
| 結構檢查 | 應用程式可以推斷出欄位名稱、類型、空值率、資料列數和樣本值，而無需將完整檔案暴露給模型。 |
| Python 執行 | 模型生成的程式碼在遠離應用伺服器的地方執行，並且可以設定執行時間上限。 |
| 套件準備 | 只有經過核准的依賴項才會被安裝或提供給任務使用。 |
| 圖表繪製 | 繪圖影像會以檔案形式寫入，並在下載前進行審查。 |
| 結果打包 | 最終的成品可以從指定的輸出目錄中收集。 |
| 清理 | 暫存檔案、生成的程式碼和工作階段狀態可以被刪除或設定為過期。 |
讓模型的提示（prompt）小於資料量。傳送結構摘要、如果政策允許則傳送幾筆代表性的資料列、欄位描述、使用者意圖以及限制條件，例如「不要訓練模型」或「僅使用核准的套件」。原始資料集應保留在沙箱檔案系統中，除非你的產品有經過審查的特定理由需要暴露更多資料。
CSV 上傳和結構檢查該如何進行？
首先，將每個上傳都視為不可信的輸入。在模型介入之前，驗證檔案類型、大小、編碼、分隔符號、資料列數、欄位數以及可疑的公式。CSV 檔案可能包含一些值，這些值在稍後開啟時會觸發試算表公式的執行，因此匯出的檔案也應針對目標格式進行清理。
一個實務的上傳流程如下：
- 使用者將 CSV 上傳到應用程式。
- 後端將原始檔案儲存在任務範圍的物件鍵或暫存路徑下。
- 後端為該任務建立一個沙箱工作階段。
- 後端將檔案複製到沙箱的工作目錄中。
- 一個小型、確定性的檢查腳本讀取檔案並產生結構摘要。
- 模型接收結構摘要、使用者問題、允許使用的函式庫以及輸出需求。
檢查步驟應使用你擁有且確定的程式碼，而不是模型生成的程式碼。它可以產生一個精簡的 JSON 摘要，如下所示：
{
"file": "sales.csv",
"rows": 84231,
"columns": [
{"name": "order_date", "type": "date", "null_rate": 0.01},
{"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
{"name": "revenue", "type": "number", "null_rate": 0.0}
],
"safe_sample_rows": 5
}
這個摘要給了模型足夠的上下文來擬定分析，而無需將整個資料集交給它。對於敏感的工作負載，可以減少或移除樣本值、遮罩欄位，或要求使用者核准哪些欄位可以被使用。
模型如何安全地生成並執行 Python？
模型應該先產生計畫，然後再產生程式碼。一個好的計畫會說明它將使用的欄位、打算進行的轉換、預期建立的圖表以及將要寫入的輸出檔案。這為你的應用程式提供了一個政策和使用者審查的檢查點。
計畫被接受後，要求模型按照一個精簡的合約來產生 Python：
- 僅從
input/目錄讀取輸入檔案。 - 僅將成品寫入
output/目錄。 - 僅使用核准的套件。
- 除非任務政策明確允許，否則避免網路呼叫。
- 在結束時列印結構化的摘要。
- 當必填欄位缺失時，要清楚回報失敗。
在概念層面上，編排迴圈如下所示：
job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)
copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")
plan = ask_model_for_analysis_plan(
user_question=job.question,
schema=schema,
allowed_packages=["pandas", "numpy", "matplotlib"],
output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)
review_policy(plan)
script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)
result = run_python_in_sandbox(
sandbox=sandbox,
script=script,
working_dir="/work",
timeout_seconds=120,
memory_limit_mb=1024,
)
artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)
這是虛擬碼，不是產品 SDK 的合約。重點在於邊界：生成的程式碼會被審查、在超時限制下執行、限制在已知目錄中，然後進行輸出收集和審查。
如果腳本失敗，將錯誤訊息和一小段程式碼摘錄送回模型進行修復。不要發送無限制的日誌。錯誤修復應遵循與第一次嘗試相同的套件、檔案、網路和輸出政策。
用於 AI 資料分析的受控 Python 套件存取
套件存取是許多 AI 資料分析工具展示變得有風險的地方。模型可能會因為在某個教學中看過某個函式庫、因為套件名稱看起來合理，或因為使用者的提示暗示了它，而要求安裝該套件。你的應用程式不應該將這些建議轉化為不受限制的套件安裝。
使用與資料敏感性相符的政策：
| 套件政策 | 最適用時機 | 取捨 |
|---|---|---|
| 僅使用預建映像 | 具有可預測分析需求的生產工作負載 | 靈活性最低，審查面最簡單 |
| 允許清單中的套件 | 大多數 CSV 分析輔助工具 | 對於 pandas、繪圖和常見統計套件來說，平衡良好 |
| 鎖定版本的安裝 | 可重現的分析任務 | 需要套件維護和弱點審查 |
| 快取的內部鏡像 | 企業或受規範的資料工作流程 | 營運工作較多，但對供應鏈有更好的控制 |
| 使用者核准的安裝 | 供受信任使用者使用的探索性工具 | 更靈活，但較慢，且需要明確的警告 |
對於第一個生產版本，從預建環境或簡短的允許清單開始。大多數 CSV 問題可以透過一小組函式庫來回答：pandas、numpy、matplotlib、seaborn、scipy，有時還需要 scikit-learn。如果一個任務需要其他套件，請模型解釋原因，然後將該請求導向人工核准或套件審查工作流程。
記錄套件名稱、版本、來源註冊表、安裝時間以及請求該套件的理由。如果你的安全團隊使用依賴項掃描器或私有註冊表，請與該流程整合，而不是讓代理程式繞過它。
如何驗證圖表和輸出檔案
生成的檔案是產品體驗的一部分，但它們也是信任邊界的一部分。圖表可能出錯。CSV 可能包含類似公式的值。筆記本可能包含隱藏的程式碼。ZIP 檔案可能包含非預期的路徑。將輸出視為需要檢查的成品，而不僅僅是供下載的檔案。
定義一個簡單的輸出合約：
{
"required_files": ["summary.json"],
"optional_files": ["chart-*.png", "filtered-data.csv"],
"blocked_extensions": [".exe", ".sh", ".bat", ".html"],
"max_total_size_mb": 25
}
對於每個完成的任務，僅從預期的輸出目錄收集檔案。驗證 MIME 類型、副檔名、大小和路徑。對於圖片，產生預覽用的縮圖。對於 CSV 匯出，如果檔案可能會在 Excel 或 Google Sheets 中開啟，請跳脫試算表公式。對於 JSON 摘要，請在使用於 UI 之前根據結構進行驗證。
在使用者下載或分享結果之前，提供一個審查步驟。審查畫面應顯示：
- 原始問題。
- 所使用的資料集名稱和結構。
- 以平實語言說明的分析步驟。
- 生成的圖表和表格。
- 因政策原因被排除的任何欄位。
- 警告、錯誤、重試次數或套件請求。
模型可以撰寫敘述性說明，但應用程式應將該說明基於沙箱執行產生的檔案和日誌。
上線前的安全檢查點
只有當安全與平台團隊能夠理解其被允許執行的操作時，AI 資料分析工具才能成為一個有用的內部工具。審查應涵蓋隔離性、資源限制、套件政策、網路行為、機密資訊、日誌和刪除。
在超越原型階段之前，請使用此檢查清單：
| 檢查點 | 要回答的問題 |
|---|---|
| 隔離邊界 | 什麼將一個使用者的程式碼和檔案與主機及其他使用者分開？ |
| 檔案存取 | 生成的程式碼只能讀取任務目錄，還是可以看到更廣泛的儲存空間？ |
| 資源限制 | 哪些設定了 CPU 時間、記憶體、磁碟、行程數和實際時間的上限？ |
| 網路政策 | 出站網路存取是關閉、僅允許清單、透過代理還是完全開放？ |
| 套件政策 | 哪些套件可以安裝，從哪裡安裝，以及有哪些版本控制？ |
| 機密資訊邊界 | API 金鑰、資料庫憑證和服務權杖是否保留在沙箱之外，除非有明確範圍？ |
| 日誌 | 是否記錄了命令、套件安裝、錯誤、檔案讀寫以及輸出成品？ |
| 人工審查 | 哪些計畫、程式碼片段、套件請求和輸出需要核准？ |
| 清理 | 沙箱狀態、上傳的檔案、生成的腳本、日誌和輸出何時被刪除？ |
避免諸如「程式碼無法逃脫」或「資料無法洩漏」這類絕對的說法。實務標準更為具體：定義邊界、記錄控制措施、測試失敗模式，並保留足夠的稽核軌跡來調查非預期行為。
對於網路和套件政策，請記住，依賴項的安裝本身就是一種網路出口形式，除非套件來自預建映像或受控鏡像。如果資料集很敏感，預設情況下應封鎖網路存取或嚴格使用允許清單。如果分析工具需要即時的外部資料，請將其設為一個獨立的工具，並有自己的核准和記錄路徑。
使用 Novita Agent Sandbox 作為執行層
Novita Agent Sandbox 為 AI 代理程式提供了隔離、有狀態的執行環境。目前的 Novita 文件描述了對執行程式碼、安裝依賴項、存取檔案、使用瀏覽器以及跨工作階段保留執行狀態的支援。對於 AI 資料分析工具，這些原始功能直接對應到架構的執行部分：建立任務工作空間、移入檔案、執行分析程式碼、收集成品，以及根據工作階段設計來清理或保留狀態。
Novita Agent Sandbox SDK 和 CLI 文件 列出了對 Python 和 JavaScript/TypeScript 的官方 SDK 支援，這適合常見的應用程式後端。沙箱檔案系統文件 描述了一個隔離的檔案系統，為沙箱提供了固定的 20 GB 儲存空間，對於在任務範圍的工作空間中暫存 CSV 檔案和生成的成品非常有用。
請保持區別清晰：
- 本文中的實作指導描述了 AI 資料分析工具應用程式的通用架構。
- Novita Agent Sandbox 可以為這些工作流程提供沙箱執行層。
- 你的應用程式仍然擁有使用者驗證、資料保留政策、套件核准、網路政策、輸出審查以及發布/部署決策的責任。
這種分離有助於團隊建立清晰的責任歸屬模型。模型負責提出並解釋分析內容。應用程式負責執行產品政策。沙箱則提供受控的執行環境，讓程式碼、檔案、套件、圖表和日誌可以在遠離主應用伺服器的地方被處理。
結論
最強大的 AI 資料分析工具設計並不是「讓模型執行 Python」。它是一個受控的循環：檢查資料集、要求模型提出計畫、審查生成的程式碼、在沙箱中執行、收集驗證過的成品、向使用者展示結果，並在任務完成後清理狀態。這種結構既能讓使用者體驗保持快速，又能為工程和安全團隊提供具體的檢查點，以便在上線前進行評估。
對於正在建構此模式的團隊，請從小處著手：CSV 上傳、結構檢查、簡短的套件允許清單、圖表輸出、嚴格的超時設定，以及一個可見的審查畫面。只有在邊界被記錄和測試之後，才增加更廣泛的套件存取、網路工具、持久化和自動化功能。
常見問題
為什麼 AI 資料分析工具需要沙箱？
因為工作流程結合了不可信的檔案、模型生成的 Python、套件請求、圖表生成和可下載的成品。在不同的環境中執行這些工作，可以讓你的應用程式對檔案、資源、套件、網路、日誌記錄和清理控制進行管控。
模型應該看到完整的 CSV 檔案嗎？
通常不需要。先向模型發送結構摘要、安全的樣本、欄位描述和使用者的問題。將原始檔案保留在沙箱中，除非你的產品有經過審查的理由需要向模型暴露更多資料。
可以允許安裝套件嗎？
可以，但必須受到控制。使用預建映像、允許清單、鎖定版本、私有鏡像或核准工作流程。不要讓模型生成的程式碼在未經審查的情況下從公共網路安裝任意套件。
應用程式應該向使用者回傳哪些檔案？
只回傳來自已知輸出目錄的已驗證檔案，例如圖表影像、摘要 JSON 以及經過清理的 CSV 匯出檔案。封鎖非預期的副檔名、大型檔案、隱藏路徑以及不屬於輸出合約一部分的成品。
這算是合規保證嗎？
不是。沙箱只是執行架構的一部分。合規性和安全核准取決於你的資料、威脅模型、控制措施、日誌記錄、保留政策、審查流程和部署環境。
