CH-01 导论：从对话助手到桌面 Agent

图 1-1：五层 Harness 框架与本书章节映射

1.1 一个问题：豆包工作到底是什么

2026 年 8 月，字节跳动旗下的豆包桌面客户端更名为"豆包工作"，在输入框左下角新增了一个模式切换按钮。普通对话模式下，它和市面上大多数 AI 聊天应用没有本质区别——你问，它答。但切换到"工作任务"模式后，事情变得不一样了：它可以打开你电脑上的浏览器、读取你授权的文件夹、在终端里执行命令、调用飞书 API 拉取数据、把结果写成 PPT 或 Excel，甚至在你离开电脑后定时运行。

这不是一个加了"联网搜索"的聊天机器人。这是一个运行在你桌面上的 Agent——一个能感知环境、做出决策、调用工具、执行动作并交付结果的软件系统。

豆包工作的官方下载页用了一句话描述这个转变："让 AI 从问答助手进化成干活搭子"。「官方」这句话准确地指出了产品定位的变化，但"干活搭子"这个说法掩盖了底下的工程复杂度。一个能在你电脑上执行命令的 AI，和一个只能生成文本的 AI，在系统架构上是完全不同的两个物种。前者需要解决工具调用、权限控制、沙箱隔离、进程管理、多步规划、错误恢复、状态持久化等一系列工程问题。这些问题的总和，就是本书要拆解的对象——Harness。

1.2 什么是 Harness

Harness 这个词在 AI Agent 领域没有统一的中文翻译。它的字面意思是"马具"或"安全带"，在工程语境中指的是"把一个大模型固定在可执行环境中的支撑结构"。你可以把它理解为 Agent 的"底盘"——大模型是发动机，但发动机本身不能上路，需要底盘、传动、刹车、方向盘和安全气囊。

具体来说，一个 Agent Harness 通常包含五层：

1. 运行环境层：Agent 跑在哪里？浏览器里、桌面上、云端容器里，还是用户自己的机器上？这决定了它能访问什么资源、用什么权限运行。
2. 引导层：Agent 是谁？它遵守什么规则？它的"记忆"从哪里来？系统提示词如何组装？身份和行为边界如何定义？
3. 能力扩展层：Agent 能做什么？工具如何注册、发现和调用？第三方能力（MCP 服务器、插件、技能）如何接入？
4. 反馈与安全层：Agent 的动作如何被约束？文件系统和网络访问如何隔离？危险操作如何审计？执行结果如何返回？
5. 编排与迭代层：复杂任务如何拆解？多个 Agent 如何协作？任务如何在后台持续运行？状态如何在多端同步？

这五层不是豆包工作独有的概念。任何一个严肃的 Agent 产品——从 Anthropic 的 Claude Code 到 OpenAI 的 Operator，从字节自己的 DeerFlow 到各类开源 Agent 框架——都必须回答这五层的设计问题。不同产品给出的答案不同，这些答案构成了它们的架构指纹。

Harness 概念的来源

Harness 这个词在 AI Agent 领域的流行，与 Anthropic 在 2024 年底发布的 "Building effective agents" 文章有关。那篇文章区分了"workflow"（预定义的代码路径编排 LLM 和工具）和"agent"（LLM 自主决定流程和工具使用），并强调了 Agent 需要在一个"harness"中运行——这个 harness 提供工具访问、反馈循环、状态管理和安全约束。

BytePlus AgentKit 文档进一步把 Harness 具体化为七个组件：model、system_prompt、tools、skills、runtime、knowledge_base、memory。「官方」这个七组件模型提供了一个标准化的分析框架，本书的五层框架是对它的重组和简化——把七个组件按"从启动到执行"的时间线归并为五层。

理解 Harness 的重要性在于：大模型的能力在快速趋同（GPT、Claude、Gemini、豆包都在互相追赶），但 Harness 的质量决定了同样的模型能发挥多大的实际价值。一个 Harness 设计糟糕的 Agent，即使使用最强的模型，也会在工具调用、错误恢复、安全控制上频繁失败；一个 Harness 设计精良的 Agent，即使使用中等模型，也能稳定地完成复杂任务。

1.3 为什么拆解豆包工作

在豆包工作之前，我用同样的五层框架拆解过 WorkBuddy（见智见 AI 蓝皮书 ZJBB-003）。WorkBuddy 是一个典型的"文件化 Harness"：它把系统提示词、身份定义、记忆、插件配置、MCP 服务器列表全部以明文文件的形式放在用户目录下，用户可以直接阅读和修改。拆解 WorkBuddy 就像拆解一辆引擎盖透明的汽车——所有零件都摆在眼前。

豆包工作走了一条几乎相反的路。它是一个闭源的商业产品，基于 Chromium 构建，核心逻辑打包在渲染进程的 JavaScript 或远程配置中，用户能直接看到的本地 Harness 文件只有一个 Skills 目录。但它在原生层面做了大量工作：用 Rust 写了 MCP 助手、基于 macOS Seatbelt 实现了沙箱、内置了审计 SDK、支持三层多 Agent 编排。这些能力在文件系统中留下了痕迹——二进制文件中的字符串、配置文件中的键值、目录结构中的约定——就像地质层中的化石，足以还原出整个架构的轮廓。

拆解豆包工作有三个价值：

第一，理解字节的 Agent 工程哲学。 字节是国内在 Agent 基础设施上投入最大的公司之一。它有云端的 AgentKit Harness、开源的 DeerFlow SuperAgent、桌面端的豆包工作，三条线共享同一套设计语言。通过桌面端这个最具体的产品，可以反推字节对"Agent 应该如何运行"这个问题的系统性回答。

第二，为 Agent 开发者提供架构参考。 如果你在构建自己的 Agent 产品或框架，豆包工作的五层设计——特别是它的 Rust MCP 助手、Seatbelt 沙箱、Skill 自动发现机制、三层 Agent 编排——提供了一个经过大规模用户验证的参考实现。

第三，建立评估 Agent 产品的分析框架。 市面上的 Agent 产品越来越多，宣传话术越来越花哨。五层框架提供了一个穿透营销语言的工具：不管产品叫"工作伙伴"还是"AI 员工"，你都可以问——它的运行环境是什么？提示词怎么组装？工具怎么接入？权限怎么控制？任务怎么编排？答案比口号重要。

1.4 研究方法与证据来源

本书是一本"源码机制"（Source Mechanism）类型的技术书，主体语法是"可见行为 → 假设 → 调用链 → 实现 → 架构判断 → 对使用者的启示"。它不是产品手册，不教你怎么用豆包工作写周报；它也不是官方文档，不代表字节的立场。

证据来自四条路线：

本地源码观测。 目标版本为豆包工作 2.25.18（commit 345d9dd，发布渠道 release）。在声明的 macOS 环境中，对应用包（DoubaoWork.app）进行了文件结构分析、Info.plist 和 manifest.json 解析、Helper 二进制文件的 strings 观测、103 个预装 Skill 的 frontmatter 全量提取、Chromium 用户数据目录的结构分析。所有二进制观测仅限于 strings 输出，未进行反编译。「源码」

运行时实测。 在当前版本的豆包工作中，实际使用了工具调用、Skill 加载、多 Agent 委派、定时任务创建、浏览器自动化等功能，观测了系统提示词的模块结构、工具接口的参数规范、tool_search 延迟加载机制、create_agent/send_message 编排接口的行为。系统提示词原文受安全约束不进入公开面，本书只描述其模块结构和机制。「实测」

官方文档。 BytePlus AgentKit Harness 官方文档提供了字节 Harness 组件模型的权威定义；豆包官方帮助中心和下载页提供了产品功能的官方口径。「官方」

社区分析。 CSDN 和掘金上的技术拆解文章、GitHub 上的第三方 doubao-mcp-bridge 项目、DeerFlow 2.0 的开源架构和评测文章，提供了补充视角和交叉验证。社区来源不独立支撑关键结论，只用于发现线索和对照。「社区」

当证据不足以闭合调用链时，本书使用推断并明确标注。推断 Claim 会列出前提、推理步骤和反证搜索结果，不会把猜测包装成事实。

1.5 五层框架与本书结构

本书的章节组织复用 ZJBB-003 的五层框架，但根据豆包工作的实际架构做了调整：

1.6 边界与不做什么

为了让这本书的结论可验证，需要明确几条边界：

不反编译闭源二进制。 所有对 Helper 进程的分析基于 strings 命令的输出，只能证明符号和日志字符串存在，不能还原完整的运行时逻辑。当 strings 证据不足以闭合调用链时，本书会明确说"这部分无法从本地证据确认"。

不引用系统提示词原文。 系统提示词是豆包工作的核心知识产权，也是安全机制的一部分。本书只描述它的模块结构（身份、安全、工具、Skill 发现、编排、交付），不逐字引用。

不泄露个人信息。 本地文件分析中遇到的 device_id、user_id、sec_user_id、Cookies 等敏感字段全部脱敏。

不覆盖 Windows 版本。 所有本地证据来自 macOS 版本。Windows 版本的沙箱机制（可能使用 AppContainer 或 Job Object）和 Helper 实现可能不同，本书不做推断。

不做性能评测。 本书不测量响应延迟、任务成功率、token 消耗等运行时指标。这些指标受模型版本、网络状况、任务类型影响很大，单次测量没有参考价值。

云电脑模式未实测。 豆包工作支持"本地电脑"和"云电脑"两种执行环境，本书的本地证据和运行时实测都针对本地电脑模式。云电脑模式的架构基于 BytePlus Computer Use Agent 文档和官方 FAQ 做有限推断。

1.7 适合谁读

本书有两条读者路线：

Agent 开发者和架构师可以重点读 CH-02、CH-05、CH-06、CH-07、CH-09。这五章涉及进程架构、MCP 集成、沙箱设计、多 Agent 编排和字节的 Harness 体系，是工程密度最高的部分。

AI 落地顾问、培训师和企业决策者可以重点读 CH-01、CH-03、CH-04、CH-08、CH-10、CH-11。这六章解释产品定位、引导机制、Skill 生态、任务模式和竞品对照，帮助判断豆包工作适合什么场景、边界在哪里。

两条路线在 CH-11 汇合。

1.8 版本与时效

豆包工作是一个快速迭代的产品。2026 年 8 月 21 日，它刚刚上线了"技能·连接器·工作伙伴"功能，官方宣布已上架超过 200 个技能和连接器。「官方」本书的证据冻结日期为 2026 年 8 月 26 日，目标版本为 2.25.18。书中描述的机制在后续版本中可能发生变化——Skill 数量会增长、Helper 实现会更新、功能会增减。本书的价值不在于提供一份永久准确的功能清单，而在于展示一套可复用的拆解方法和一个时间切片上的架构快照。

当你读到这本书时，如果豆包工作已经更新了大版本，建议先对照 CH-02 的版本检查方法，确认哪些机制发生了变化，再决定哪些结论需要修正。

1.9 2026 年桌面 Agent 竞争格局

豆包工作不是唯一的桌面 Agent。2026 年，这个赛道已经有多个玩家：

• OpenAI ChatGPT Desktop：ChatGPT 的桌面客户端，支持连接器和基本工具调用，但没有内核级沙箱和多 Agent 编排。
• Anthropic Claude Desktop：Claude 的桌面客户端，内置 MCP 客户端支持，是 MCP 生态的主要推动者，但工具能力和沙箱机制相对简单。
• Cursor / Windsurf：面向开发者的 AI IDE，深度集成代码编辑和终端，但不是通用桌面 Agent。
• WorkBuddy：开源/开放路线的代表，Harness 文件完全透明，面向开发者和技术团队。

豆包工作的差异化在于：它是唯一在桌面端实现了内核级沙箱（Seatbelt）、原生 Rust MCP 运行时、三层多 Agent 编排和 103+ 预装 Skill 的产品。这个组合反映了字节在 Agent 基础设施上的工程投入，也定义了桌面 Agent 的安全和能力基准。

CHAPTER 02 · ZJBB-004