CH-09 体系内定位：AgentKit、DeerFlow 与豆包工作

图 9-1：字节 Agent 全栈定位

9.1 字节的 Agent 三条线

拆解豆包工作不能只看它本身。字节在 AI Agent 领域同时布局了三条产品线，它们共享设计哲学但面向不同场景：

1. BytePlus AgentKit Harness：云端 Agent 运行时，面向企业开发者，提供 API 和 SDK
2. DeerFlow 2.0：开源 SuperAgent 框架，面向开发者社区，GitHub 74K stars
3. 豆包工作（DoubaoWork）：桌面 Agent 客户端，面向终端用户和企业员工

三者的关系不是竞争，而是同一套 Agent 架构理念在不同运行环境和目标用户下的产品化。理解它们的共性和差异，才能看清豆包工作在字节 Agent 体系中的位置。

9.2 BytePlus AgentKit Harness：七组件模型

BytePlus 是字节跳动的海外企业服务品牌，AgentKit 是其 AI Agent 开发平台。AgentKit 的官方文档定义了一个 Harness 七组件模型：「官方」

9.2.1 API 端点

AgentKit Harness 暴露三类端点：

• POST /harness/invoke：同步调用 Agent，发送消息并接收响应
• ADK routes：Agent Development Kit 的路由，用于管理 Agent 配置、工具注册、会话管理
• A2A protocol：Agent-to-Agent 协议，用于 Agent 之间的通信和任务委派

A2A 协议特别值得关注。它是一个开放协议，允许不同 Agent 之间互相发现、通信和委派任务，类似于微服务之间的 API 调用。豆包含多 Agent 编排（create_agent/send_message）可能是 A2A 协议在桌面端的实现——MainAgent、OrganizeAgent、SubAgent 之间的通信遵循 A2A 规范。「推断」

9.2.2 记忆后端

AgentKit 文档明确列出了记忆系统的后端选项：

• 短期记忆：local（内存）、sqlite、mysql、postgresql
• 长期记忆：viking（字节向量数据库）、opensearch、redis、mem0（开源记忆层）

这证实了字节的 Agent 记忆系统是模块化的，可以根据部署环境选择不同的后端。豆包工作作为字节自家产品，短期记忆可能使用本地存储（Chromium 的 Local Storage 或 LevelDB），长期记忆使用 viking 向量数据库。「推断」

9.2.3 知识检索

AgentKit 的 knowledge_base 组件支持 RAG 管道：文档摄入 → 分块 → 向量化 → 检索 → 注入上下文。豆包含企业搜索工具（enterprise_agentic_search）和通用搜索工具（general_search）分别对应企业内部知识库和公共互联网的检索。

9.3 DeerFlow 2.0：开源 SuperAgent

DeerFlow 是字节开源的"SuperAgent"框架，在 GitHub 上获得了 74K stars。根据 Andrew 的深度评测文章，DeerFlow 2.0 的架构有几个核心设计：「社区」

9.3.1 Sub-agent 按需生成

DeerFlow 的 sub-agent 不是预定义的角色，而是根据任务需要动态生成。每个 sub-agent 有：

• 特定的角色描述（role）
• 独立的任务描述（task）
• 自动选择的工具和 Skill
• 独立的沙箱环境

这与豆包工作的 SubAgent 概念一致：OrganizeAgent 根据任务需要创建专门化的 SubAgent，每个 SubAgent 只关注自己的子任务。

9.3.2 Skill 自动拾取

DeerFlow 的 Skill 系统与豆包工作几乎完全一致：

• Skill 是包含 SKILL.md 的目录
• SKILL.md 有 frontmatter（name + description）
• 模型根据 description 自主判断何时加载
• 加载后读取完整 SKILL.md 正文并按指引执行

这种一致性强烈暗示两者共享同一套 Skill 规范——很可能是字节内部的 Agent 技能标准，DeerFlow 将其开源，豆包工作将其产品化。

9.3.3 三种沙箱模式

DeerFlow 支持三种执行沙箱：

豆包工作的 Seatbelt 沙箱相当于 DeerFlow 的 local 模式，但实现完全不同——Seatbelt 是 macOS 内核级沙箱，DeerFlow 的 local 模式可能只是进程级限制。Docker 和 K8s 模式在豆包工作的云电脑模式中有对应（云端容器/虚拟机）。

9.3.4 MCP 内置

DeerFlow 内置 MCP 客户端，可以连接任意 MCP 服务器获取工具。这与豆包工作的 mcp-helper 功能一致，但实现语言不同（DeerFlow 用 Python/TypeScript，豆包工作用 Rust）。

9.3.5 IM 集成

DeerFlow 支持 Lark（飞书）、Slack、Discord 作为交互界面。用户可以在 IM 中 @DeerFlow 发起任务，DeerFlow 在后台执行并返回结果。豆包工作没有 IM 集成（它本身就是桌面客户端），但它的 23 个飞书 Skill 让它能深度操作飞书生态。

9.4 三者的关系图谱

┌─────────────────────┐
                    │   字节 Agent 架构    │
                    │  （共享设计语言）     │
                    └──────────┬──────────┘
                               │
           ┌───────────────────┼───────────────────┐
           ↓                   ↓                   ↓
  ┌────────────────┐  ┌────────────────┐  ┌────────────────┐
  │  AgentKit      │  │  DeerFlow 2.0  │  │  豆包工作       │
  │  云端 Harness  │  │  开源框架       │  │  桌面客户端     │
  ├────────────────┤  ├────────────────┤  ├────────────────┤
  │ 目标：企业开发者 │  │ 目标：开发者社区 │  │ 目标：终端用户   │
  │ 形态：API/SDK  │  │ 形态：开源代码   │  │ 形态：桌面 App  │
  │ 运行：云端容器  │  │ 运行：Docker/K8s│  │ 运行：用户 Mac  │
  │ 交互：API 调用  │  │ 交互：IM/Web   │  │ 交互：GUI 对话  │
  │ 开源：否       │  │ 开源：是        │  │ 开源：否        │
  └────────────────┘  └────────────────┘  └────────────────┘

「推断」

9.4.1 共享的设计模式

三条线共享以下设计模式：

1. 七组件 Harness 模型：model、system_prompt、tools、skills、runtime、knowledge_base、memory 的分层在三者中一致。
2. Skill 自动拾取：基于 frontmatter description 的模型自主发现机制。
3. Sub-agent 按需生成：动态创建专门化 Agent 执行子任务。
4. MCP 作为工具扩展协议：内置 MCP 客户端，支持 STDIO/HTTP 传输。
5. 沙箱隔离执行：Agent 的代码执行在受限环境中进行。
6. 多传输协议：支持本地和远程的工具服务器连接。

9.4.2 差异化的实现

9.4.3 豆包工作的独特位置

豆包工作在三条线中有独特位置：

它是唯一运行在用户设备上的 Harness。 AgentKit 在云端，DeerFlow 在服务器或本地开发机，豆包工作在用户的 Mac 上。这带来了独特的挑战（本地安全、权限管理、系统集成）和独特的优势（访问本地文件、本地应用、低延迟）。

它是唯一面向非开发者的产品。 AgentKit 和 DeerFlow 都需要编程能力来配置和使用，豆包工作通过 GUI 和自然语言交互让非技术用户也能使用 Agent 能力。

它有最复杂的原生层。 AgentKit 和 DeerFlow 的运行时主要是容器和进程，豆包工作需要处理 macOS 特有的问题：Seatbelt 沙箱、代码签名、钥匙串、Finder 扩展、Chromium 嵌入。Rust MCP Helper 和审计 SDK 是这种复杂性的体现。

它是字节 Agent 能力的"展示窗"。 普通用户不会直接接触 AgentKit 或 DeerFlow，但他们会用豆包工作。豆包工作的体验质量直接影响市场对字节 Agent 能力的认知。

9.5 与 Coze/扣子的关系

信任域配置中包含 cici.com 和 ciciai.com，这是字节的 Coze（扣子）平台域名。Coze 是字节的 AI Bot 开发平台，允许用户创建和发布 AI Bot。「源码」

豆包工作与 Coze 的关系可能是：

1. 技能来源：在线技能商店中的部分技能可能由 Coze 平台的 Bot 提供，Preferences 中的 botId 字段支持这个推断。
2. 工作伙伴："工作伙伴"可能是 Coze Bot 在桌面端的包装——用户在 Coze 上配置的 Bot 可以作为工作伙伴在豆包工作中使用。
3. Agent 发布渠道：Coze 上开发的 Agent 可能可以一键发布到豆包工作，作为技能或工作伙伴。

这是一个合理的平台战略：Coze 是生产端（创建 Agent），豆包工作是消费端（使用 Agent），AgentKit 是基础设施（运行 Agent），DeerFlow 是开源参考实现。四者构成完整的 Agent 生态。「推断」

9.6 AgentKit Harness 的组件细节

9.6.1 Harness 调用流程

根据 AgentKit 文档，一次 Harness 调用的流程如下：「官方」

1. 客户端发送消息到 POST /harness/invoke
2. Harness 加载 system_prompt 和注册的 tools/skills
3. 从 memory 组件检索相关上下文
4. 从 knowledge_base 检索相关文档
5. 将组装好的上下文发送给 model
6. 模型返回响应或工具调用请求
7. Harness 执行工具调用，将结果返回模型
8. 模型生成最终响应
9. Harness 将对话写入 memory，返回响应给客户端

这个流程与 CH-03 重建的豆包工作上下文组装流程高度一致：系统提示词 → 工具定义 → Skill → 记忆 → 对话历史 → 用户消息。区别在于 AgentKit 的每个组件都是可插拔的（可以选择不同的 memory 后端、knowledge_base 实现、model 提供商），而豆包工作的组件是固定的产品实现。

9.6.2 A2A 协议的意义

AgentKit 暴露的 A2A（Agent-to-Agent）协议值得特别关注。在微服务架构中，服务通过 API 互相调用；在 Agent 架构中，Agent 通过 A2A 协议互相委派任务。

A2A 协议定义了：

• Agent Card：Agent 的能力描述（类似于 Skill 的 frontmatter）
• Task：任务对象，包含状态、历史和产物
• Message：Agent 间的消息格式
• Streaming：任务执行过程的流式推送

豆包含 create_agent/send_message/terminate_organizer 三个工具，可以看作 A2A 协议在桌面端的具体实现：create_agent 对应 A2A 的任务发起，send_message 对应消息追加，terminate_organizer 对应任务取消。「推断」

9.6.3 沙箱与代码执行

AgentKit 文档提到了代码执行沙箱能力。在云端，沙箱通常通过容器（Docker）或轻量虚拟机（Firecracker）实现。每个 Agent 会话获得一个隔离的执行环境，会话结束后环境销毁。

豆包工作在本地用 Seatbelt 实现了等效的隔离，在云电脑模式下很可能使用容器或 VM。这再次印证了"同一架构、不同实现"的判断——桌面端和云端遵循相同的安全原则，但根据运行环境选择不同的技术。

9.7 DeerFlow 2.0 的架构细节

9.7.1 核心组件

根据开源代码和 Andrew 的评测，DeerFlow 2.0 的架构包含以下核心组件：「社区」

• Orchestrator：编排器，负责任务分解和 sub-agent 管理（对应豆包工作的 OrganizeAgent）
• Sub-agent Pool：动态生成的子 Agent 池，每个 sub-agent 有独立角色和工具
• Skill Engine：Skill 发现和加载引擎（与豆包含 Skill 机制一致）
• Sandbox Manager：沙箱管理器，支持 local/Docker/K8s 三种模式
• MCP Client：MCP 客户端，连接外部工具服务器
• Memory Manager：记忆管理器，支持短期和长期记忆
• IM Gateway：IM 网关，支持 Lark/Slack/Discord 交互

9.7.2 与豆包工作的架构映射

9.7.3 DeerFlow 的 SuperAgent 概念

DeerFlow 自称 "SuperAgent"，核心理念是：一个 Agent 可以自动生成专门化的子 Agent 来完成复杂任务，而不需要用户手动编排。这与豆包含三层架构理念一致，但 DeerFlow 更激进——sub-agent 的层级和数量完全动态，Orchestrator 根据任务需要决定生成多少个子 Agent、每个子 Agent 做什么。

豆包含三层架构更保守：MainAgent 只创建 OrganizeAgent，OrganizeAgent 创建 SubAgent，层级固定。这种保守设计可能是出于产品稳定性和可预测性的考虑——固定层级更容易调试和向用户解释。

9.7.4 开源的战略价值

DeerFlow 在 GitHub 上获得 74K stars，这不是一个小数字。字节开源 DeerFlow 的战略价值包括：

1. 建立标准：通过开源实现推广字节的 Agent 架构模式（Skill、sub-agent、MCP、沙箱），影响行业标准。
2. 吸引开发者：开发者使用 DeerFlow 后，更容易迁移到字节的云端 AgentKit 平台。
3. 收集反馈：开源社区的 issue 和 PR 帮助改进 Agent 架构，反哺豆包工作等闭源产品。
4. 人才吸引：开源项目是最好的技术品牌，吸引 Agent 领域的工程师加入字节。

9.8 字节 Agent 战略的逻辑

把 AgentKit、DeerFlow、Coze 和豆包工作放在一起看，可以发现字节 Agent 战略的清晰逻辑：

9.8.1 三层战略

基础设施层（AgentKit）：提供 Agent 运行时、记忆、知识库、沙箱等基础能力，面向企业开发者，通过 API/SDK 交付。这是"卖水人"角色——不管谁做 Agent，都需要运行时。

框架层（DeerFlow）：开源 SuperAgent 框架，建立技术标准和开发者生态。74K stars 意味着大量开发者在学习和使用字节的 Agent 模式，这些开发者未来更可能选择 AgentKit 作为生产部署平台。

应用层（豆包工作 + Coze）：Coze 让用户创建 Agent，豆包工作让用户使用 Agent。两者构成"创建-消费"闭环，豆包工作是桌面端消费入口，Coze 是生产工具。

9.8.2 与其他大厂的对比

字节是唯一在四个层面都有布局的公司。OpenAI 有最强的模型和 GPTs 生态，但没有开源框架和独立的桌面 Agent 客户端；Anthropic 有 MCP 协议和 Claude Desktop，但没有 Bot 平台和开源框架。字节的全栈布局虽然每个单点不一定最强，但体系化协同是差异化优势。

9.8.3 MCP 作为战略支点

字节在所有四条产品线中都内置了 MCP 支持。这不是偶然——MCP 是 Anthropic 提出的开放协议，但字节是最积极的采用者之一。通过全面支持 MCP，字节：

1. 避免了自己定义私有协议的生态阻力
2. 让 AgentKit/DeerFlow/豆包工作可以连接任何 MCP 服务器，快速扩展能力
3. 通过 Rust MCP Helper 等高质量实现建立技术领导力
4. 为未来的 Agent 间互联（A2A + MCP）打下基础

9.9 体系内定位的架构判断

判断一：豆包工作不是孤立产品，而是字节 Agent 平台的桌面终端。 七组件模型、Skill 规范、MCP 集成、sub-agent 模式在 AgentKit、DeerFlow 和豆包工作之间高度一致，说明字节内部有统一的 Agent 架构标准。豆包工作是这个标准在桌面端的产品化实现。「推断」

判断二：Rust MCP Helper 和 Seatbelt 沙箱是桌面端的独特贡献。 云端 Agent 不需要考虑本地安全和 macOS 集成，豆包工作在这两个组件上的工程投入（Rust、FFI、内核沙箱、审计 SDK）是桌面端独有的。这些组件未来可能反哺 DeerFlow 的 local 模式或 AgentKit 的本地开发工具。「推断」

判断三：DeerFlow 是理解豆包工作内部架构的最佳窗口。 豆包工作是闭源的，但 DeerFlow 是开源的。两者在 Skill、sub-agent、MCP、沙箱上的设计一致性意味着，阅读 DeerFlow 源码可以合理推断豆包工作的内部实现。当然，桌面端和云端的差异需要谨慎区分。「推断」

判断四：字节正在构建"创建-运行-消费"的 Agent 全栈。 Coze 创建 Agent、AgentKit 运行 Agent、豆包工作消费 Agent、DeerFlow 开源吸引开发者。这个全栈战略如果成功，字节将拥有从开发到分发到使用的完整 Agent 生态，类似于云计算时代的"开发工具-云平台-终端应用"链条。「推断」

下一章将把豆包工作与 WorkBuddy 直接对照，分析两种 Harness 设计哲学的差异、各自的适用场景，以及它们代表的 Agent 产品化的两条路线。

CHAPTER 10 · ZJBB-004