智能体执行环境

智能体执行环境是 Triggerfish 的自我开发能力——一个一流的代码工作区，智能体可以在其中编写代码、执行代码、观察输出和错误、修复问题并迭代直到代码正常工作。这是使智能体能够构建集成、测试想法和自行创建新工具的核心能力。

不是 Plugin 沙箱

执行环境与 Plugin 沙箱有根本区别。理解这种区别很重要：

• Plugin 沙箱保护系统免受不受信任的第三方代码的影响
• 执行环境赋予智能体编写、运行和调试自己代码的能力

Plugin 沙箱是防御性的。执行环境是生产性的。它们服务于相反的目的，具有不同的安全特征。

方面	Plugin 沙箱	智能体执行环境
目的	保护系统免受不受信任代码的影响	赋予智能体构建能力
文件系统	无（完全沙箱化）	仅工作区目录
网络	仅声明的端点	策略管控的允许/拒绝列表
包安装	不允许	允许（npm、pip、deno add）
执行时间	严格超时	宽裕超时（可配置）
迭代	单次运行	无限的写入/运行/修复循环
持久性	临时的	工作区跨会话持久化

反馈循环

核心质量差异化因素。这与 Claude Code 等工具有效的模式相同——一个紧密的写入/运行/修复循环，智能体看到的与人类开发者完全相同。

第 1 步：编写

智能体使用 write_file 在其工作区中创建或修改文件。工作区是一个真实的文件系统目录，范围限于当前智能体。

第 2 步：执行

智能体通过 run_command 运行代码，接收完整的 stdout、stderr 和退出代码。不会隐藏或摘要任何输出。智能体看到的与您在终端中看到的完全相同。

第 3 步：观察

智能体读取完整输出。如果发生错误，它可以看到完整的堆栈跟踪、错误消息和诊断输出。如果测试失败，它可以看到哪些测试失败以及原因。

第 4 步：修复

智能体根据观察结果编辑代码，使用 write_file 或 edit_file 更新特定文件。

第 5 步：重复

智能体再次运行。此循环持续进行，直到代码正常工作——通过测试、产生正确的输出或实现既定目标。

第 6 步：持久化

代码正常工作后，智能体可以将其保存为技能（SKILL.md + 支持文件），将其注册为集成，连接到定时任务，或使其作为工具可用。

持久化步骤使执行环境不仅仅是一个临时记事本。正常工作的代码不会消失——智能体可以将其打包为可重用的技能，按计划运行、响应触发器或按需调用。 :::

可用工具

工具	描述	输出
write_file	在工作区中写入或覆盖文件	文件路径，写入字节数
read_file	从工作区读取文件内容	字符串形式的文件内容
edit_file	对文件应用定向编辑	更新后的文件内容
run_command	在工作区中执行 shell 命令	stdout、stderr、退出代码、持续时间
list_directory	列出工作区中的文件（可选递归）	带大小的文件列表
search_files	搜索文件内容（类似 grep）	带文件:行引用的匹配行

工作区结构

每个智能体都有一个隔离的工作区目录，跨会话持久化：

~/.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>/                 # 后台任务的临时工作区

工作区在智能体之间是隔离的。一个智能体不能访问另一个智能体的工作区。后台任务（定时任务、触发器）获得自己的临时工作区，范围限于会话。

集成开发流程

当您要求智能体构建新集成（例如，"连接我的 Notion 并同步任务"）时，智能体遵循自然的开发工作流：

1. 探索——使用 run_command 测试 API 端点、检查认证、了解响应结构
2. 脚手架——使用 write_file 编写集成代码，同时创建测试文件
3. 测试——使用 run_command 运行测试，查看失败，迭代
4. 安装依赖——使用 run_command 添加所需包（npm、pip、deno add）
5. 迭代——写入、运行、修复循环直到测试通过且集成端到端正常工作
6. 持久化——保存为技能（编写带元数据的 SKILL.md）或连接到定时任务
7. 审批——自主创作的技能进入 PENDING_APPROVAL 状态；您审核并批准

语言和运行时支持

执行环境在主机系统上运行（不在 WASM 中），可以访问多个运行时：

运行时	可用方式	用例
Deno	直接执行	TypeScript/JavaScript（一等支持）
Node.js	run_command node	npm 生态系统访问
Python	run_command python	数据科学、机器学习、脚本
Shell	run_command sh / run_command bash	系统自动化、胶水脚本

智能体可以检测可用的运行时并为任务选择最佳的一个。包安装通过每个运行时的标准工具链工作。

安全边界

执行环境比 plugin 沙箱更宽松，但在每一步都受策略控制。

策略集成

• 每个 run_command 调用都会以命令作为上下文触发 PRE_TOOL_CALL 钩子
• 在执行前检查命令允许/拒绝列表
• 输出被捕获并通过 POST_TOOL_RESPONSE 钩子
• 执行期间访问的网络端点通过血统追踪
• 如果代码访问已分级数据（例如，从 CRM API 读取），会话污染会升级
• 执行历史记录到 .exec_history 用于审计

硬边界

这些边界永远不会被跨越，无论配置如何：

• 不能在工作区目录之外写入
• 不能执行拒绝列表上的命令（rm -rf /、sudo 等）
• 不能访问其他智能体的工作区
• 所有网络调用受策略钩子管控
• 所有输出都被分级并贡献于会话污染
• 执行资源限制：磁盘空间、每次执行的 CPU 时间、内存

安全 智能体运行的每个命令都通过 PRE_TOOL_CALL 钩子。策略引擎在执行开始前根据命令允许/拒绝列表检查它。危险命令被确定性地阻止——LLM 不能影响此决策。 :::

企业控制

企业管理员对执行环境有额外的控制：

• 完全禁用特定智能体或角色的执行
• 限制可用运行时（例如，只允许 Deno，阻止 Python 和 shell）
• 设置资源限制每个智能体（磁盘配额、CPU 时间、内存上限）
• 要求审批高于分级阈值的所有执行操作
• 自定义命令拒绝列表超出默认危险命令列表