CH-06 反馈与安全：工具系统、沙箱与审计

6.1 工具系统：Agent 的手和眼

如果说大模型是 Agent 的大脑，工具就是 Agent 的手和眼。没有工具，Agent 只能生成文本；有了工具，Agent 才能读取文件、执行命令、搜索网络、生成图片、操作浏览器。豆包工作的工具系统在系统提示词中定义，通过 XML function call 格式调用，执行结果以工具返回值的形式注入模型上下文。

6.1.1 内置工具分类

豆包工作的初始工具集可以分为以下几类：「实测」

文件操作类：Read（读取文件）、Write（写入文件）、Edit（精确字符串替换）、Glob（文件名模式匹配）、Grep（正则内容搜索）。这些工具让 Agent 能直接操作本地文件系统，是编程辅助、文档处理、数据分析等场景的基础。

命令执行类：Bash（执行 shell 命令）。这是最强大也最危险的工具——它允许 Agent 在用户的机器上执行任意命令。Bash 工具有权限模式（沙箱/完全访问）和目录范围限制，在 6.3 节详细展开。

信息检索类：general_search（通用网络搜索）、enterprise_agentic_search（企业内部知识检索）、seed_finance_search（金融数据搜索）、medical_search（医疗知识搜索）、seed_legal_search（法律条文搜索）。这些工具连接不同的数据源，让 Agent 获取实时和专业信息。

内容生成类：image_gen（文生图）、image_edit（图片编辑）、text_to_video/image_to_video（视频生成）、text_to_audio/audio_to_audio_plus（音频生成）。这些工具调用字节的多模态生成模型。

通信与交付类：present_files（向用户交付文件）、send_message（向其他 Agent 发消息）、create_agent（创建子 Agent）、terminate_organizer（终止子 Agent）。这些工具负责 Agent 间协作和产物交付。

系统类：tool_search（延迟加载工具发现）、create_cron_job/list_cron_jobs/update_cron_job/delete_cron_job（定时任务管理）、start_recording/get_recording（录音与转写）、interaction.request_action/interaction.authorize_folder（用户交互与授权）。

6.1.2 tool_search：延迟加载机制

系统提示词中不列出所有工具的完整 schema，而是提供一个 tool_search 工具。当模型需要某个不在初始列表中的能力时，它先用关键词搜索可用工具，获取工具的完整 schema，然后像普通工具一样调用。

延迟加载的工具包括：

• visual_search：以图搜图，从全网搜索与输入图片相关的结果
• scholar_search：学术论文、书籍和专利搜索
• CanvasReadFile：读取 Canvas 文件
• get_current_time：获取当前世界时间
• NotebookEdit：编辑 Jupyter notebook 单元格

这种设计解决了一个实际问题：工具数量增长时，把所有 schema 注入系统提示词会消耗大量 token，降低有效上下文长度，还可能干扰模型的工具选择（太多工具描述会让模型"选择困难"）。延迟加载让模型按需获取工具定义，类似于编程语言的 import 机制。「实测」

6.1.3 present_files：受控交付

present_files 是 Agent 向用户交付产物的唯一通道。无论是生成的图片、写入的文档、下载的文件还是外部链接，都必须通过这个工具呈现给用户。

这个工具有几个设计约束：

1. 本地文件用绝对路径，外部链接用 URL。工具会验证文件路径的可访问性。
2. 每个交付物有名称和来源。名称用于在 UI 中显示，source 是文件路径或链接。
3. 媒体文件逐个交付。每次调用只交付一个媒体文件，配合独立的介绍文字，确保用户按顺序理解。
4. 搜索结果不作为产物交付。搜索返回的 URL 用引用标签标注，不通过 present_files 呈现。

这种受控交付机制确保了用户看到的每个产物都是 Agent 明确生成或选择的，防止了意外的文件泄露或恶意链接注入。

图 6-1：安全沙箱八层纵深防御

6.2 权限模式：沙箱与完全访问

图 6-2：权限决策流程

豆包工作的 Bash 工具有两种权限模式，用户可以在会话中切换：

6.2.1 沙箱模式（默认）

在沙箱模式下，Bash 命令在受限环境中执行：

• 文件系统限制：只能写入授权目录（初始工作目录、用户共享目录、会话中授权的目录）和临时目录（/tmp）。系统目录和其他用户目录不可写。
• 网络限制：可能受到网络访问策略约束（通过审计 SDK 的 netAllow/netDeny 规则）。
• 命令限制：部分危险命令可能被拦截。
• 进程监控：所有子进程被审计 SDK 监控。

沙箱模式通过 macOS Seatbelt 实现，技术细节在 6.3 节展开。

6.2.2 完全访问模式

用户可以选择"完全访问"模式，此时 Bash 命令直接在用户系统上执行，不受沙箱限制。系统提示词明确要求：在完全访问模式下，Agent 仍需谨慎操作——考虑可逆性、不执行破坏性命令、高风险操作需用户确认。

完全访问模式不是"无安全"——审计 SDK 仍然监控进程行为，系统提示词层面的安全规则仍然生效，macOS 本身的权限系统（TCC 全磁盘访问、钥匙串授权等）仍然保护敏感资源。但沙箱层的隔离被移除了，Agent 的命令拥有与当前用户相同的权限。

6.2.3 目录授权

除了全局模式切换，豆包工作还支持细粒度的目录授权。当 Agent 需要访问工作目录之外的文件夹时，可以通过 interaction.authorize_folder 工具请求用户授权。用户在系统弹窗中选择文件夹后，该路径被加入授权列表，Agent 可以在其中读写。

这是一种"最小权限"设计：Agent 默认只能访问工作目录，需要更多权限时显式请求，用户逐次授权。授权范围精确到文件夹，不是全盘开放。

6.3 macOS Seatbelt 沙箱

6.3.1 Seatbelt 是什么

Seatbelt（安全带）是 macOS 内置的内核级沙箱系统，内部代号为 Sandbox.kext。它通过 TrustedBSD MAC 框架在内核层强制访问控制，使用 Scheme 语言编写的配置文件（sandbox profile）定义进程可以访问哪些资源。macOS 上的许多系统服务（如 Safari 的渲染进程、Chrome 的渲染进程、App Store 应用）都运行在 Seatbelt 沙箱中。

与 Docker 容器（基于 Linux namespace/cgroup）不同，Seatbelt 是 macOS 特有的轻量级沙箱，不需要虚拟机或容器运行时，直接在内核层过滤系统调用。它的优点是性能开销极小、与 macOS 深度集成；缺点是只能在 macOS 上使用，配置语言（Scheme）学习曲线陡峭。

6.3.2 豆包工作的沙箱架构

豆包工作的沙箱由三个组件协作实现：「源码」

sandbox-launcher（启动器）
    ├── dlopen libsandbox.dylib（Seatbelt 桥接）
    │   └── 应用 Seatbelt scheme 配置
    ├── dlopen libauditSboxSDK.dylib（审计 SDK）
    │   ├── AhaProcessMonitor（进程监控）
    │   ├── AhaSandboxIPCListener（沙箱 IPC 监听）
    │   └── AhaAuditEventReporter（事件上报）
    └── 通过 LaunchServices 启动目标应用/命令

sandbox-launcher 是沙箱的入口。当 Agent 需要执行命令或启动应用时，主进程不直接执行，而是启动 sandbox-launcher，由它在沙箱环境中启动目标进程。

libsandbox.dylib 是 Seatbelt 的桥接库。它的 strings 输出包含 aha-sandbox-seatbelt-bridge 标识符，以及大量 Seatbelt scheme 语法关键字（allow、deny、file-read、file-write、network、process、sysctl* 等）。它负责将豆包工作的沙箱配置转换为 Seatbelt scheme，并调用 sandbox_init() 或 sandbox_init_with_parameters() 应用沙箱策略。「源码」

libauditSboxSDK.dylib 是审计 SDK，负责监控沙箱内的行为并上报。它的 strings 输出包含三个核心类名和丰富的配置键：「源码」

• AhaProcessMonitor：监控沙箱内的进程创建和退出
• AhaSandboxIPCListener：监听沙箱内的 IPC 通信
• AhaAuditEventReporter：上报审计事件（使用 spdlog 日志库，支持 logEncrypt 加密）

审计配置键包括：rules、whitelist、blacklist、netAllow、netDeny、netRules，说明沙箱支持进程白/黑名单和网络访问控制。

6.3.3 AHA_SANDBOX_CONFIG 环境变量

沙箱配置通过环境变量 AHA_SANDBOX_CONFIG 传递给 sandbox-launcher。这是一个设计选择：配置不通过命令行参数传递（可能被 ps 命令看到），也不写入临时文件（可能残留），而是通过环境变量在 fork/exec 时传递。「源码」

"AHA" 是字节内部的代号前缀（可能是 "Aha!" 或某个内部项目名），在沙箱相关的二进制和符号中反复出现：aha-sandbox-seatbelt-bridge、AhaProcessMonitor、AhaSandboxIPCListener、AhaAuditEventReporter、Aha Sandbox Virtual Keychain。

6.3.4 沙箱文件系统策略

从 libsandbox.dylib 的 strings 输出中提取到的 Seatbelt scheme 规则，可以重建沙箱的文件系统访问策略：「源码」

允许读取的路径：

• /Applications（应用程序目录）
• /usr（系统工具和库）
• /etc（系统配置）
• /Library/Preferences（系统偏好设置）
• /opt/homebrew/lib（Homebrew 库，Apple Silicon Mac）

允许读写的路径：

• /tmp（临时文件）
• 用户授权的目录（通过 AHA_SANDBOX_CONFIG 动态注入）

隐式拒接：

• 用户主目录下的非授权路径（Documents、Desktop、Downloads 等）
• 其他用户的目录
• 系统敏感目录（/var/db、/private/var 等）

这种策略允许沙箱内的进程运行系统命令（如 ls、git、python3）和读取应用程序资源，但不能访问用户的个人文件，除非用户显式授权。

6.3.5 五个隐藏目录

在用户数据目录下发现了五个以 .sandbox_ 开头的隐藏目录：「源码」

.sandbox_config/   — 沙箱配置缓存
.sandbox_exec/     — 沙箱执行临时文件
.sandbox_meta/     — 沙箱元数据
.sandbox_tmp/      — 沙箱临时文件
.sandbox_deleted/  — 沙箱删除标记/回收站

这些目录为沙箱提供了文件系统隔离层：

• .sandbox_config/ 可能缓存了编译后的 Seatbelt scheme
• .sandbox_exec/ 可能存放沙箱内执行的脚本或二进制副本
• .sandbox_tmp/ 是沙箱内的临时目录（映射到 /tmp 或独立的 tmpfs）
• .sandbox_deleted/ 可能实现了"安全删除"——沙箱内删除的文件先移动到这里，而不是直接 unlink

6.3.6 虚拟钥匙串

libsandbox.dylib 的 strings 输出中包含 Aha Sandbox Virtual Keychain 字符串。「源码」这表明沙箱实现了一个虚拟钥匙串。

macOS 的 Keychain（钥匙串）是系统级的密码和证书存储。沙箱内的进程如果直接访问真实钥匙串，可能读取到用户保存的密码、API key 和证书。虚拟钥匙串的设计是：在沙箱内提供一个隔离的钥匙串实例，沙箱进程看到的是一个空的或受控的钥匙串，无法访问用户的真实凭证。

这是一个重要的安全设计。MCP 服务器和命令行工具可能尝试读取钥匙串（如 security find-generic-password），虚拟钥匙串阻止了这类凭证窃取。

6.3.7 父进程身份验证

sandbox-launcher 的 strings 输出包含代码签名验证相关符号。这意味着 sandbox-launcher 在启动前会验证父进程的身份和代码签名，确保它是由合法的豆包工作主进程启动的，而不是被恶意进程调用的。「源码」

这是一种防提权设计：即使攻击者知道 sandbox-launcher 的路径和参数，也无法直接调用它来绕过沙箱或执行特权操作，因为父进程签名验证会失败。

6.4 审计 SDK：行为可观测

libauditSboxSDK.dylib 为沙箱提供了行为审计能力。从 strings 分析中可以识别出以下功能：「源码」

6.4.1 进程监控

AhaProcessMonitor 监控沙箱内的所有进程创建和退出。每当沙箱内的进程 fork/exec 一个新进程，监控器记录进程路径、命令行参数、父进程 ID 和时间戳。这使得 Agent 执行的每个命令都有审计轨迹。

6.4.2 IPC 监听

AhaSandboxIPCListener 监听沙箱内的 IPC 通信。在 macOS 上，进程间通信方式包括 XPC、Mach port、UNIX domain socket、分布式通知等。监控 IPC 可以检测沙箱内进程试图与外部进程通信的行为。

6.4.3 网络规则

审计配置中的 netAllow、netDeny、netRules 键表明沙箱支持网络访问控制：

• netAllow：允许访问的网络目标白名单
• netDeny：拒绝访问的网络目标黑名单
• netRules：更细粒度的网络规则（可能按端口、协议、域名）

这意味着沙箱不仅限制文件系统，还限制网络访问。Agent 执行的命令不能随意连接外部服务器——这阻止了数据外泄和恶意软件下载。

6.4.4 加密日志

审计日志使用 spdlog（一个高性能 C++ 日志库）写入，并支持 logEncrypt 加密。加密日志确保即使日志文件被读取，也无法直接获取审计内容。日志可能包含：

• 执行的命令和参数
• 文件访问记录
• 网络连接尝试
• 沙箱违规事件
• 进程生命周期事件

这些日志可能用于安全事件回溯、滥用检测和产品改进。

6.5 纵深防御体系

综合以上分析，豆包工作的安全体系是一个多层纵深防御：

第 1 层：系统提示词安全规则
  ↓ 模型被诱导绕过？
第 2 层：工具参数验证（schema 校验、路径检查）
  ↓ 参数注入？
第 3 层：权限模式（沙箱/完全访问）
  ↓ 用户授权完全访问？
第 4 层：Seatbelt 沙箱（文件系统/网络/进程隔离）
  ↓ 沙箱逃逸？
第 5 层：父进程签名验证（防止沙箱被直接调用）
  ↓ 绕过签名验证？
第 6 层：虚拟钥匙串（保护真实凭证）
  ↓ 凭证隔离被突破？
第 7 层：审计 SDK（行为监控和加密日志）
  ↓ 所有层都被绕过？
第 8 层：macOS 系统权限（TCC、SIP、Gatekeeper）

「推断」

这个防御体系的设计哲学是：不依赖任何单一安全机制，每一层都假设前一层可能被绕过。系统提示词层最容易被绕过（prompt injection），但沙箱层和系统权限层提供了硬约束。即使模型被完全劫持，攻击者仍然受限于 Seatbelt 沙箱和 macOS 权限系统。

6.6 沙箱的实际效果与局限

6.6.1 沙箱能防什么

基于 Seatbelt 策略和审计 SDK 的设计，豆包工作的沙箱能有效防御以下风险：

• 意外文件破坏：Agent 在沙箱模式下不能写入非授权目录，即使模型被诱导执行 rm -rf ~/，也只会影响授权目录和临时目录。
• 凭证窃取：虚拟钥匙串阻止沙箱内进程读取真实 Keychain，security 命令无法获取用户保存的密码和 API key。
• 数据外泄：网络规则（netAllow/netDeny）可以限制沙箱内进程的网络访问，阻止敏感数据被发送到外部服务器。
• 权限提升：父进程签名验证阻止恶意程序直接调用 sandbox-launcher 获取特权。
• 横向移动：沙箱内进程无法访问其他用户目录或系统敏感路径，阻止从 Agent 到系统的横向移动。

6.6.2 沙箱不能防什么

沙箱不是银弹，它不能防御以下风险：

• Prompt injection：如果 Agent 读取了包含恶意指令的网页或文件，模型可能被诱导执行非预期操作。沙箱限制了操作的影响范围，但不能阻止模型"想"做坏事。
• 授权目录内的破坏：用户授权了某个目录后，沙箱内进程对该目录有完整读写权限，Agent 仍可能误删或覆盖该目录中的文件。
• 完全访问模式：用户切换到完全访问模式后，Seatbelt 沙箱被禁用，所有保护降级为提示词规则和审计日志。
• 供应链攻击：如果 Agent 安装的 npm/pip 包本身是恶意的，它在沙箱内仍能执行代码、访问网络（受网络规则限制）和读取授权目录。
• 内核漏洞：Seatbelt 是内核级沙箱，但如果 macOS 内核本身存在漏洞，沙箱可能被逃逸。这是所有操作系统级沙箱的共同局限。

6.6.3 与其他桌面 Agent 的安全对比

安全特性	豆包工作	Claude Code	Cursor	WorkBuddy
内核级沙箱	Seatbelt	无（依赖系统权限）	无	无
虚拟钥匙串	有	无	无	无
父进程验证	有	无	无	无
审计 SDK	有（加密日志）	基础日志	基础日志	基础日志
网络规则	netAllow/netDeny	无	无	无
权限模式切换	沙箱/完全访问	无	无	无

「推断」

这个对比基于公开信息和本地观测，可能不完整。但它表明豆包工作在桌面 Agent 安全上的投入显著高于同类产品。这与其大众市场定位一致——面向非技术用户的产品必须在安全上做得更多。

6.7 企业部署的安全考量

对于考虑在企业内部署豆包工作的 IT 团队，以下安全特性值得关注：

6.7.1 审计与合规

审计 SDK 的进程监控、IPC 监听和加密日志为企业提供了"Agent 做了什么"的可追溯性。结合定时任务和 MCP 连接器的配置管理，企业可以构建完整的 Agent 操作审计链。

6.7.2 数据边界

本地模式下，Agent 在员工 Mac 上执行，数据不离开设备（除了模型 API 调用和服务端记忆）。云电脑模式下，数据在字节云端容器中处理，不落地员工设备。企业可以根据数据敏感程度选择执行环境。

6.7.3 连接器管控

MCP 连接器配置了 OAuth 认证和 scope 管理，企业可以控制 Agent 能访问哪些内部系统、以什么权限访问。网络规则可以进一步限制连接器的网络访问范围。

6.7.4 待确认的企业特性

以下企业安全特性在本地证据中未确认，需要向字节销售团队咨询：

• 是否支持 MDM（移动设备管理）批量配置
• 是否支持 SSO（单点登录）和 SCIM（用户自动开通）
• 是否支持 DLP（数据防泄漏）策略
• 审计日志是否可以导出到企业 SIEM 系统
• 是否支持私有化部署

6.8 安全层的架构判断

判断一：Seatbelt 沙箱是豆包含 Harness 中最被低估的组件。 大多数用户只看到"豆包工作能执行命令"，很少有人注意到命令运行在内核级沙箱中。这个沙箱的文件系统策略、网络规则、虚拟钥匙串和父进程验证构成了一个相当完整的本地安全边界。在同类桌面 Agent 产品中，这种级别的原生沙箱并不多见。「推断」

判断二：安全设计遵循"默认安全、按需授权"原则。 默认沙箱模式、最小文件系统访问、目录级授权、虚拟钥匙串——这些设计都遵循最小权限原则。用户需要主动切换到完全访问模式或显式授权目录，Agent 才能获得更多权限。「推断」

判断三：审计能力是企业场景的关键。 进程监控、IPC 监听、网络规则和加密日志为企业部署提供了合规基础。当企业考虑让 AI Agent 访问内部系统时，"Agent 做了什么"的可审计性与"Agent 能做什么"的权限控制同等重要。「推断」

判断四：沙箱的代价是兼容性。 Seatbelt 沙箱可能阻止某些合法操作——比如访问 Homebrew 安装的工具（只允许了 /opt/homebrew/lib，未允许 /opt/homebrew/bin）、访问 Docker daemon、访问网络服务。用户在遇到沙箱限制时需要切换到完全访问模式或授权目录，这增加了使用摩擦。「推断」

下一章将进入编排层，分析豆包工作的多 Agent 架构——MainAgent、OrganizeAgent 和 SubAgent 如何分工协作，任务如何委派和终止。

CHAPTER 07 · ZJBB-004