CH-08 迭代层：任务模式、定时与多端

8.1 从即时对话到持续任务

传统聊天机器人的交互模式是"请求-响应"：用户发一条消息，模型回一条消息，对话结束。Agent 的交互模式更复杂：一个任务可能需要多步工具调用、长时间运行、在特定时间触发、在后台持续执行、在多个设备间同步。豆包工作的迭代层就是支撑这些"非即时"任务模式的基础设施。

8.2 两种模式：对话与工作任务

豆包工作在输入框左下角提供了一个模式切换按钮，在"对话"和"工作任务"之间切换。「实测」

8.2.1 对话模式

对话模式是标准的聊天机器人体验：模型生成文本回复，可以使用搜索等轻量工具，但不执行本地命令、不操作文件系统、不启动多 Agent 编排。这个模式适合问答、头脑风暴、文本写作等不需要"动手"的场景。

8.2.2 工作任务模式

工作任务模式激活完整的 Agent 能力：工具调用、文件操作、命令执行、浏览器自动化、多 Agent 编排、Skill 加载。这个模式下，Agent 可以执行需要"动手"的任务——写代码、处理文件、操作网页、生成文档。

模式切换的本质是系统提示词和工具集的切换。对话模式下，系统提示词不包含工具定义和编排规则，模型只做文本生成；工作任务模式下，完整的 Agent 系统提示词和工具集被加载。这避免了在简单对话中引入不必要的工具开销和安全风险。

8.2.3 执行环境：本地与云电脑

工作任务模式下还有一个执行环境选择：本地电脑或云电脑。「官方」

本地电脑：Agent 在用户的 Mac 上执行，使用本地文件系统、本地命令行和本地安装的软件。这是本书所有本地证据的来源环境。

云电脑：Agent 在字节提供的云端虚拟机中执行。根据 BytePlus Computer Use Agent 文档，云端环境是一个运行在字节云基础设施上的容器或虚拟机，Agent 通过远程桌面协议操作云端电脑。「官方」云电脑模式的优势是：

• 不占用本地资源
• 环境隔离（即使任务出问题也不影响本地机器）
• 可以 24 小时运行（本地电脑关机后任务继续）
• 预装了常用开发工具和软件

Preferences 中的 saman.task_mode.runtime.active_environment_id 记录了当前选择的执行环境 ID。切换环境时，Agent 的工具路由和权限策略随之改变。「源码」

8.3 定时任务

豆包工作内置了定时任务能力，通过 doubao-cron-scheduler Skill 和四个工具实现：create_cron_job、list_cron_jobs、get_cron_job、update_cron_job、delete_cron_job。「实测」

8.3.1 两种调度类型

定时任务支持两种格式：

cron（周期性）：标准 Linux cron 表达式，如 0 9 * * 1-5（每周一到周五早上 9 点）。适合每日报告、每周总结、定期监控等重复任务。

at（一次性）：Linux at 命令可识别的时间表达式，如 tomorrow 09:15、now + 1 hour、2026-09-01 10:00。适合提醒、延迟执行、未来某个时间点的一次性任务。

8.3.2 任务定义

创建定时任务时需要指定：

• title：任务标题
• query：任务触发时执行的操作描述（写入"本次请求是由定时任务触发的"）
• schedule：cron 表达式或 at 时间
• schedule_type：cron 或 at
• enable：是否启用
• deadline（可选）：任务截止时间，到期后自动停止

定时任务在本地持久化，即使豆包工作重启也不会丢失。任务触发时，豆包工作自动启动一个工作任务会话，执行 query 中描述的操作。

8.3.3 典型场景

• 每日晨报：每天早上 9 点自动搜索行业新闻、汇总邮件和日历、生成简报
• 定期监控：每小时检查某个网站或数据源的变化
• 延迟提醒：一小时后提醒我检查某个任务
• 周报生成：每周五下午自动汇总本周工作内容

定时任务让 Agent 从"被动响应"变成"主动执行"，是 Agent 从工具进化为助手的关键能力。

8.4 后台执行

8.4.1 background scheme

manifest.json 中定义了三个自定义 scheme：dola-background、doubao-background、doubaowork-background，它们拥有 "Danger API" 权限。「源码」这些 scheme 是后台页面的通信通道。

在 Chromium 架构中，后台页面（background page）是不显示 UI 的页面，可以在应用最小化或窗口关闭后继续运行。豆包含后台 Agent 能力很可能建立在这个机制上：当用户关闭窗口或切换到其他应用时，Agent 的任务在后台页面中继续执行，通过 background scheme 与主进程通信。

8.4.2 任务持续运行

多 Agent 任务（特别是 OrganizeAgent 委派的长任务）可能需要几分钟甚至几十分钟完成。后台执行允许：

• 用户关闭聊天窗口后任务继续
• 用户切换到其他应用时任务继续
• 任务完成后通过系统通知提醒用户
• 定时任务在后台自动触发

这与 WorkBuddy 的"后台职责"概念类似——Agent 不把状态管理转交给用户，而是自己维护任务生命周期。

8.5 多端同步

8.5.1 native_sync

Preferences 中 saman.native_sync.enabled: true 表明豆包工作启用了原生同步。「源码」同步的数据类型包括：

• 书签双写同步（bookmark_sync.dual_write_enabled: true）：书签在本地和服务端双写
• 对话历史：跨设备同步对话记录
• 定时任务：可能跨设备同步（未确认）
• 技能配置：默认不同步（skill: false），但可能在未来开放

8.5.2 同步的边界

值得注意的是，并非所有数据都同步：

• 技能列表（skill: false）被标记为不同步到账号，说明技能目前是设备本地状态
• 文件系统操作天然不同步——在 MacBook 上创建的文件不会自动出现在 Mac mini 上
• 本地执行环境的状态（安装的依赖、运行的进程）不可同步

多端同步主要同步的是"对话"和"配置"，不是"执行环境"。如果用户在云端电脑模式下工作，执行环境本身在云端，天然跨设备可访问。

8.5.3 同步架构推断

Preferences 中的同步配置揭示了一个双轨同步架构：

• Chromium Sync：书签、历史记录、扩展设置等 Chromium 标准数据通过 Chromium 的同步机制同步（bookmark_sync.dual_write_enabled 表明书签同时写入本地 Chromium 存储和豆包服务端）。
• saman Native Sync：对话历史、定时任务、Agent 配置等豆包工作专属数据通过 saman 框架的原生同步通道同步（saman.native_sync.enabled: true）。

这种双轨设计合理：Chromium 标准数据复用成熟的 Chromium Sync 基础设施，豆包专属数据通过自有通道同步，避免了把业务数据塞进 Chromium 同步模型的别扭。「推断」

8.6 任务状态与通知

图 8-1：任务状态机

8.6.1 任务状态机

一个工作任务在豆包工作中经历多个状态：

pending（等待中）
  → running（执行中，可能包含多个工具调用和子 Agent）
  → waiting_user（等待用户输入或授权）
  → completed（完成，交付产物）
  → failed（失败，返回错误信息）
  → cancelled（用户取消或被 terminate_organizer 终止）

「推断」

waiting_user 状态特别重要：当 Agent 需要用户授权目录、确认危险操作、提供额外信息时，任务暂停并等待。用户响应后任务从断点继续，而不是重新开始。这要求 Agent 框架能序列化和恢复任务状态——包括已完成的步骤、已获取的中间结果、当前的工具调用栈。

8.6.2 系统通知

任务完成或需要用户注意时，豆包工作通过 macOS 系统通知中心发送通知。这使得用户可以在任务运行期间切换到其他应用，任务完成后被系统通知拉回。通知可能包含：

• 任务完成和产物摘要
• 需要授权或确认的请求
• 定时任务触发提醒
• 错误和异常通知

后台页面（通过 background scheme）在窗口关闭后仍能触发通知，这是 macOS 应用的标准后台能力。

8.6.3 任务恢复

豆包工作重启后，之前的任务状态可以恢复。证据包括：

• 定时任务在本地持久化（不依赖应用持续运行）
• 对话历史通过 native_sync 同步到服务端
• Chromium 的 Session Storage 和 Local Storage 持久化了渲染进程状态

但正在运行中的多 Agent 任务是否能在应用重启后恢复执行，目前没有直接证据。更可能的情况是：重启后任务标记为中断，用户可以选择重新运行或从中断处继续（取决于任务是否幂等）。「推断」

8.7 云电脑模式的架构推断

虽然云电脑模式未实测，但结合 BytePlus Computer Use Agent 文档和豆包工作的架构，可以做有限推断：

8.7.1 云端执行环境

云电脑模式下，Agent 的工具调用不在本地 Mac 上执行，而是发送到云端虚拟机：

• Bash 命令在云端 Linux 容器/VM 中执行
• 文件操作在云端文件系统中进行
• 浏览器自动化在云端 Chromium 中运行
• MCP 服务器在云端启动和管理

本地客户端只负责：显示 Agent 的思考过程和产物、接收用户输入、通过远程桌面协议（可能是 VNC、RDP 或字节自研协议）展示云端画面。

8.7.2 与本地模式的切换

active_environment_id 是一个 UUID，每个执行环境（本地电脑、云电脑实例）有独立的 ID。切换环境时：

• 工具调用路由到新环境
• 文件系统路径映射到新环境
• 沙箱策略可能不同（云端用容器隔离，本地用 Seatbelt）
• 已安装的工具和依赖不同

这解释了为什么豆包工作需要独立的"执行环境"抽象——它让同一套 Agent 逻辑可以在不同的基础设施上运行，本地和云端只是 runtime 的不同实现。

8.7.3 云电脑的安全含义

云电脑模式有独特的安全价值：

• Agent 的命令执行完全在云端沙箱中，即使逃逸也只影响临时容器
• 企业数据不落地员工设备，满足数据安全合规
• IT 部门可以预装和管控云端环境，防止未授权软件
• 任务完成后容器销毁，不留痕迹

这与本地模式的 Seatbelt 沙箱形成互补：本地模式保护用户设备不受 Agent 伤害，云电脑模式保护企业数据不离开受控环境。

8.8 浏览器自动化

豆包含两个浏览器自动化 Skill：

• browser-task：通用浏览器自动化，用于需要真实浏览器 GUI 的场景（登录、授权、复杂交互）
• browser-use-automation / browser-use-automation-mac：基于 CNGC Browser Use 栈的浏览器控制，通过 computer_use_tool / mac_computer_use_tool 实现

8.8.1 computer_use_tool

computer_use_tool 和 mac_computer_use_tool 是豆包含浏览器操作工具。它们在一个独立的浏览器环境中执行 Python 代码，通过 seed_browser_use 库控制页面：导航、点击、输入、截图、读取 DOM。「实测」

这个工具的特点是：

• 每次调用是一个独立的 Python 进程
• 可以截图并返回图像（视觉观测）
• 支持页面交互（点击、填写表单、滚动）
• 可以提取页面文本和 DOM 结构

浏览器自动化让 Agent 能操作那些没有 API 的网站——登录后台、下载报表、填写表单、抓取数据。这是 RPA（机器人流程自动化）能力在 Agent 中的体现。

8.8.2 内置浏览器的角色

浏览器自动化使用的是豆包工作内置的 DoubaoWork Browser.app，而不是系统默认浏览器。这确保了：

• 自动化操作不干扰用户的日常浏览
• Agent 的登录状态与用户的个人登录隔离
• 可以通过 CDP 程序化控制

8.8.3 浏览器自动化的安全边界

浏览器自动化在沙箱中的行为值得关注。当 Agent 通过 computer_use_tool 操作网页时：

• 自动化运行在内置浏览器中，不访问用户的个人浏览器 Profile
• 网页中的 JavaScript 在 Chromium 渲染器沙箱中运行
• 文件下载受 Seatbelt 沙箱策略约束
• Agent 能看到的页面内容通过截图和 DOM 提取返回，不直接暴露给外部

但浏览器自动化也有独特风险：Agent 可能被诱导访问钓鱼网站、在网页中输入敏感信息、下载恶意文件。这些风险主要靠系统提示词中的安全规则和模型判断力来缓解，而不是技术层的硬阻断。「推断」

8.9 录音与会议纪要

豆包工作内置了录音能力（doubao-record Skill 和 start_recording/get_recording 工具），以及飞书妙记集成（lark-minutes Skill）。「实测」

• start_recording：启动录音，返回 record_id
• get_recording：按 record_id 查询录音内容，返回转写文本和摘要

结合飞书视频会议（lark-vc Skill）和会议纪要工作流（lark-workflow-meeting-summary Skill），豆包工作可以实现：加入会议 → 录音转写 → 生成纪要 → 提取待办 → 发送给参会人的完整闭环。

8.10 Finder 扩展

finder-ext.appex 是一个 Finder 同步扩展，允许用户从 Finder 的右键菜单直接与豆包工作交互。「源码」典型场景：

• 在 Finder 中右键一个文件 → "用豆包工作处理"
• 选中多个文件 → "用豆包工作总结"
• 右键文件夹 → "用豆包工作分析"

这个扩展是豆包工作融入 macOS 桌面体验的触点，让用户不需要先打开豆包工作窗口就能发起任务。

8.11 迭代层的架构判断

判断一：双模式切换是安全与能力的平衡。 对话模式轻量安全，工作任务模式完整强大。用户在简单问答时不需要面对工具调用的开销和风险，在复杂任务时才激活完整能力。这种渐进式能力暴露比"一刀切"的全功能模式更合理。「推断」

判断二：云电脑模式是企业场景的关键。 本地模式适合个人开发者，云电脑模式适合企业场景——IT 部门可以管控云端环境、预装工具、限制网络访问，员工通过 Agent 操作云端电脑而不接触敏感数据。这与 BytePlus Computer Use Agent 的企业定位一致。「推断」

判断三：定时任务让 Agent 从"工具"变成"助手"。 一个只能被动等待指令的 Agent 是工具，一个能在指定时间主动执行任务的 Agent 是助手。定时任务 + 后台执行 + 多端通知的组合，让豆包工作可以承担日报、监控、提醒等持续性工作。「推断」

判断四：同步策略反映了产品优先级。 书签和对话同步开启，技能不同步——这说明豆包工作目前把"对话连续性"视为跨设备核心体验，而把"技能配置"视为设备本地状态。随着技能生态的成熟，技能同步很可能会开放。「推断」

下一章将把豆包工作放到字节的 AI 体系中，分析它与 BytePlus AgentKit Harness、DeerFlow 2.0 的关系，以及它在字节 Agent 战略中的位置。

CHAPTER 09 · ZJBB-004