Agent 執行環境

Agent 執行環境是 Triggerfish 的自我開發能力——一個第一級的程式碼工作區，代理可以在此撰寫程式碼、執行、觀察輸出和錯誤、修復問題並迭代直到程式碼正常運作。這使代理能夠自行建構整合、測試想法和建立新工具。

不是 Plugin 沙箱

執行環境與 Plugin 沙箱有本質上的不同。理解這個區別很重要：

Plugin 沙箱保護系統免受不受信任的第三方程式碼的影響
Exec 環境賦予代理撰寫、執行和除錯自己程式碼的能力

Plugin 沙箱是防禦性的。Exec 環境是生產性的。它們服務於相反的目的並具有不同的安全特性。

面向	Plugin 沙箱	Agent Exec 環境
目的	保護系統免受不受信任程式碼的影響	賦予代理建構事物的能力
檔案系統	無（完全沙箱化）	僅工作區目錄
網路	僅宣告的端點	策略管控的允許/拒絕清單
套件安裝	不允許	允許（npm、pip、deno add）
執行時間	嚴格的逾時限制	寬鬆的逾時限制（可設定）
迭代	單次執行	無限的寫入/執行/修復循環
持久性	短暫的	工作區跨 session 持久

回饋迴圈

核心品質差異化因素。這與讓 Claude Code 等工具有效的模式相同——一個緊密的寫入/執行/修復循環，代理看到的與人類開發者看到的完全一樣。

步驟 1：撰寫

代理使用 write_file 在其工作區中建立或修改檔案。工作區是一個範圍限定於當前代理的真實檔案系統目錄。

步驟 2：執行

代理透過 run_command 執行程式碼，接收完整的 stdout、stderr 和退出碼。沒有輸出被隱藏或摘要。代理看到的與您在終端機中看到的完全一樣。

步驟 3：觀察

代理讀取完整的輸出。如果發生錯誤，它會看到完整的堆疊追蹤、錯誤訊息和診斷輸出。如果測試失敗，它會看到哪些測試失敗以及原因。

步驟 4：修復

代理根據觀察到的內容編輯程式碼，使用 write_file 或 edit_file 更新特定檔案。

步驟 5：重複

代理再次執行。這個循環持續到程式碼正常運作——通過測試、產生正確的輸出或達到既定目標。

步驟 6：持久化

一旦正常運作，代理可以將其工作儲存為技能（SKILL.md + 支援檔案）、註冊為整合、連接到 cron 任務，或使其作為工具可用。

持久化步驟使 exec 環境不僅僅是一個暫存區。正常運作的程式碼不會消失——代理可以將其打包成可重用的技能，按排程執行、回應觸發器或按需呼叫。 :::

可用工具

工具	說明	輸出
`write_file`	在工作區中寫入或覆蓋檔案	檔案路徑、寫入的位元組數
`read_file`	從工作區讀取檔案內容	檔案內容字串
`edit_file`	對檔案套用目標編輯	更新後的檔案內容
`run_command`	在工作區中執行 shell 命令	stdout、stderr、退出碼、持續時間
`list_directory`	列出工作區中的檔案（可選遞迴）	含大小的檔案列表
`search_files`	搜尋檔案內容（類似 grep）	含有 file:line 參考的匹配行

工作區結構

每個代理獲得一個跨 session 持久的隔離工作區目錄：

~/.triggerfish/workspace/
  <agent-id>/                     # 每個代理的工作區
    scratch/                      # 臨時工作檔案
    integrations/                 # 正在開發的整合程式碼
      notion-sync/
        index.ts
        index_test.ts
        package.json
      salesforce-report/
        main.py
        test_main.py
    skills/                       # 正在撰寫的技能
      morning-briefing/
        SKILL.md
        briefing.ts
    .exec_history                 # 稽核用的執行日誌
  background/
    <session-id>/                 # 背景任務的臨時工作區

工作區在代理之間是隔離的。一個代理無法存取另一個代理的工作區。背景任務（cron 任務、觸發器）獲得自己的臨時工作區，範圍限定於 session。

整合開發流程

當您要求代理建構新的整合時（例如「連接到我的 Notion 並同步任務」），代理遵循自然的開發工作流程：

探索——使用 run_command 測試 API 端點、檢查驗證、了解回應格式
建立腳手架——使用 write_file 撰寫整合程式碼，在旁邊建立測試檔案
測試——使用 run_command 執行測試，看到失敗，迭代
安裝相依性——使用 run_command 新增所需的套件（npm、pip、deno add）
迭代——寫入、執行、修復循環直到測試通過且整合端到端正常運作
持久化——儲存為技能（撰寫帶有 metadata 的 SKILL.md）或連接到 cron 任務
核准——自行撰寫的技能進入 PENDING_APPROVAL 狀態；您審查並核准

語言和執行環境支援

執行環境在主機系統上執行（不在 WASM 中），可以存取多個執行環境：

執行環境	可透過	使用場景
Deno	直接執行	TypeScript/JavaScript（第一級）
Node.js	`run_command node`	npm 生態系統存取
Python	`run_command python`	資料科學、ML、腳本
Shell	`run_command sh` / `run_command bash`	系統自動化、膠水腳本

代理可以偵測可用的執行環境並為任務選擇最佳的一個。套件安裝透過每個執行環境的標準工具鏈進行。

安全邊界

Exec 環境比 plugin 沙箱更寬鬆，但在每個步驟都受策略控制。

策略整合

每個 run_command 呼叫都會以命令作為上下文觸發 PRE_TOOL_CALL 鉤子
在執行前檢查命令允許/拒絕清單
輸出被擷取並通過 POST_TOOL_RESPONSE 鉤子
執行期間存取的網路端點透過溯源追蹤
如果程式碼存取分類資料（例如從 CRM API 讀取），session 汙染會升級
執行歷史記錄到 .exec_history 供稽核使用

硬性邊界

這些邊界永遠不會被跨越，無論設定為何：

無法寫入工作區目錄以外
無法執行拒絕清單上的命令（rm -rf /、sudo 等）
無法存取其他代理的工作區
所有網路呼叫受策略鉤子管控
所有輸出被分類並貢獻到 session 汙染
執行資源限制：磁碟空間、每次執行的 CPU 時間、記憶體

安全代理執行的每個命令都通過 PRE_TOOL_CALL 鉤子。策略引擎在執行開始前根據命令允許/拒絕清單進行檢查。危險命令被確定性地封鎖——LLM 無法影響此決定。 :::

企業控制

企業管理員對 exec 環境有額外控制：

完全停用 exec——針對特定代理或角色
限制可用的執行環境（例如僅允許 Deno，封鎖 Python 和 shell）
設定每個代理的資源限制（磁碟配額、CPU 時間、記憶體上限）
要求核准——超過分類閾值的所有 exec 操作
自訂命令拒絕清單——超出預設危險命令清單

Agent 執行環境 ​

不是 Plugin 沙箱 ​

回饋迴圈 ​

步驟 1：撰寫 ​

步驟 2：執行 ​

步驟 3：觀察 ​

步驟 4：修復 ​

步驟 5：重複 ​

步驟 6：持久化 ​

可用工具 ​

工作區結構 ​

整合開發流程 ​

語言和執行環境支援 ​

安全邊界 ​

策略整合 ​

硬性邊界 ​

企業控制 ​