CH-10 对照 WorkBuddy：两种 Harness 哲学

10.1 为什么要对照

ZJBB-003《WorkBuddy Harness 设计拆解》用同样的五层框架分析了 WorkBuddy。两本书并排阅读时，一个清晰的对照浮现出来：豆包工作和 WorkBuddy 代表了 Agent Harness 设计的两条路线——产品化封闭与工具化开放。

这不是"谁更好"的问题。两者的目标用户、使用场景和商业模型不同，设计选择是这些差异的结果。但对照它们的架构决策，可以帮助我们理解 Agent Harness 设计中的核心权衡，以及哪些选择是本质的、哪些是偶然的。

10.2 总览对照表

图 10-1：豆包工作 vs WorkBuddy 五层对照

10.3 运行环境层对照

豆包工作：Chromium + 原生 Helper

豆包工作用 1MB 的启动器拉起一个 977MB 的 Chromium 浏览器，UI 和 Agent 逻辑在渲染进程中运行，敏感操作通过 6 个原生 Helper 完成。这是一个"重内核、薄启动器"的架构。

这种架构的优势是：

• 原生 Helper 可以用 Rust/C++ 实现高性能、高安全性的组件
• Chromium 提供跨平台一致性和丰富的 Web 能力
• Helper 进程隔离提供安全边界

劣势是：

• 977MB 的浏览器内核占用大量磁盘和内存
• 渲染进程与 Helper 之间的 IPC 增加延迟
• 应用逻辑打包在 JS bundle 中，调试和定制困难

WorkBuddy：Electron + Node.js

WorkBuddy 基于 Electron，主进程是 Node.js，渲染进程是 Chromium。它没有独立的 Helper 进程体系——命令执行、MCP 通信、文件操作都在 Node.js 主进程或其子进程中完成。

这种架构的优势是：

• 开发效率高，全栈 JavaScript/TypeScript
• Node.js 生态丰富，MCP 服务器直接 npx 启动
• Harness 文件明文可见，用户可以理解和修改

劣势是：

• Node.js 进程的安全边界弱于原生 Helper
• 没有内核级沙箱，命令执行的安全性依赖系统权限
• Electron 的内存占用通常高于原生应用

对照判断

豆包工作选择了"安全优先"的运行环境架构：用 Rust 写 MCP Helper、用 Seatbelt 做沙箱、用审计 SDK 做监控，这些都是重工程投入。WorkBuddy 选择了"透明优先"：所有逻辑在用户可见的 JavaScript/Markdown 文件中，用户可以阅读和修改，但安全边界更依赖用户自身的判断。

这反映了两者的目标用户差异：豆包工作面向可能不懂技术的大众用户，安全必须由产品保证；WorkBuddy 面向开发者，他们有能力判断风险，透明度比自动安全更有价值。

10.4 引导层对照

系统提示词

豆包工作的系统提示词是运行时注入的黑盒。用户看不到、改不了，甚至不知道它的确切来源（远程配置还是 JS 打包）。这保证了所有用户获得一致的行为，但也意味着用户无法定制 Agent 的核心性格和规则。

WorkBuddy 的系统提示词是 prompt.tpl——一个 Jinja2 模板文件，用户可以用任何编辑器打开、修改、版本控制。用户可以让 Agent 更正式或更随意、添加团队规范、修改工具使用规则。这是极致的可定制性，但也意味着误配置可能导致 Agent 行为异常。

身份系统

豆包工作的身份是产品身份——"你是 Doubao"，固定不变。doubao-identity Skill 只管产品口径（会员价格、隐私政策），不管性格。用户唯一能影响身份的方式是 AGENTS.md（项目级规则）。

WorkBuddy 的身份是文件化的——SOUL.md 定义性格和价值观，IDENTITY.md 定义名称和角色，USER.md 定义用户信息。用户可以把 Agent 改成任何身份，从"严谨的代码审查员"到"毒舌的创意伙伴"。

记忆系统

豆包工作的记忆是服务端功能：自动跨设备同步、语义检索、用户无需管理。代价是黑盒——用户不知道 Agent 记住了什么、为什么记住、如何删除。

WorkBuddy 的记忆是本地文件：MEMORY.md 是 Markdown，memory/ 目录有条目，edge-sync 数据库做向量检索。用户可以直接阅读、编辑、删除记忆。代价是需要手动维护、不跨设备同步（除非用 Git 或云盘同步目录）。

对照判断

引导层的差异是两种产品最本质的分歧。豆包工作把引导层视为产品的核心 IP——系统提示词定义了"豆包是谁"，这是品牌资产，不能让用户修改。WorkBuddy 把引导层视为用户的私有财产——Agent 是谁、记住什么、如何说话，都应该由用户决定。

这两种哲学没有对错。苹果不会让用户修改 iOS 的系统行为，Linux 允许用户修改一切；豆包工作和 WorkBuddy 的区别类似。

10.5 能力扩展层对照

Skill 系统

两者都采用了基于 SKILL.md frontmatter 的模型拾取机制，这部分高度一致——都遵循 Anthropic AgentSkills 规范。差异在于：

• 豆包工作预装 103 个 Skill，覆盖飞书、金融、法律、医疗等专业领域；WorkBuddy 的 Skill 数量较少，更聚焦于开发和内容创作场景。
• 豆包含在线技能商店（200+），支持从服务端添加技能；WorkBuddy 的 Skill 主要来自本地和社区。
• 豆包工作的 .user_skills/ 是唯一的用户 Skill 目录；WorkBuddy 的插件系统更复杂，支持注册新工具类型和 MCP 服务器。

MCP 集成

两者都支持 MCP，但实现方式不同：

• 豆包工作用 Rust 实现 MCP 运行时（rmcp 3.0.0），通过 FFI 与 Chromium 桥接，支持三种传输和完整 OAuth。
• WorkBuddy 用 Node.js/TypeScript 实现 MCP 客户端，配置在 mcp.json 中，用户可以直接编辑。

豆包工作的 MCP 实现更"重"——原生代码、FFI、OAuth 内置；WorkBuddy 的 MCP 实现更"轻"——JSON 配置、npx 启动、标准 Node.js 生态。前者更安全、性能更好，后者更透明、更容易调试和扩展。

对照判断

在能力扩展层，两者的 Skill 机制趋同（都遵循 AgentSkills），但 MCP 实现和扩展模型分化。豆包工作走"平台"路线——技能商店、连接器、工作伙伴，构建生态；WorkBuddy 走"工具箱"路线——用户自己配置 MCP、写插件、改 Skill，自由度最大。

10.6 反馈与安全层对照

沙箱

这是两者差距最大的层。

豆包工作实现了 macOS Seatbelt 内核级沙箱：文件系统策略、网络规则、虚拟钥匙串、父进程签名验证、五个沙箱隐藏目录。加上审计 SDK（进程监控、IPC 监听、加密日志），这是一个接近企业级的安全体系。

WorkBuddy 的安全模型更接近"用户自负其责"：命令在用户权限下执行，没有内核级沙箱隔离。它依赖系统提示词中的安全规则和用户确认来约束危险操作，但没有技术层面的强制隔离。

权限模式

豆包工作有明确的双模式：沙箱（默认）和完全访问。用户可以逐目录授权，最小权限原则贯穿始终。

WorkBuddy 的权限控制更粗粒度：Agent 通常在用户完整权限下运行，安全主要靠提示词约束和用户判断。

对照判断

安全层的差异完全可以用目标用户解释。豆包工作可能被企业大规模部署到员工电脑上，一个安全漏洞可能影响数百万用户和企业数据，必须有内核级沙箱和审计能力。WorkBuddy 的用户主要是开发者和技术团队，他们在自己的机器上运行自己配置的 Agent，安全边界由用户自己把控。

这并不意味着 WorkBuddy"不安全"——它意味着安全责任的分配不同。豆包工作说"我来保护你"，WorkBuddy 说"我给你工具，你自己决定"。

10.7 编排与迭代层对照

多 Agent

豆包工作内置三层 Agent 架构（Main/Organize/Sub），通过 create_agent/send_message/terminate_organizer 实现任务委派和上下文隔离。这是系统提示词和工具系统的原生能力。

WorkBuddy 主要是单 Agent 模式，复杂任务通过 Skill 指引和工具编排完成，没有内置的多 Agent 层级。

定时任务与后台执行

豆包工作内置 cron/at 定时任务、后台页面持续执行、系统通知。Agent 可以在用户离开后继续工作。

WorkBuddy 的定时任务依赖外部调度（系统 cron、CI/CD、手动触发），没有内置的后台执行框架。

多端同步

豆包工作有 native_sync，对话和书签跨设备同步，云电脑模式支持环境级跨设备。

WorkBuddy 的跨设备依赖用户自己用 Git 或云盘同步 Harness 目录，没有内置同步机制。

对照判断

在编排和迭代层，豆包工作明显更"重"——多 Agent、定时任务、后台执行、多端同步都是产品级能力。WorkBuddy 更像一个"单点工具"——在当前会话中帮你完成任务，持续性工作交给外部系统。

这反映了产品愿景的差异：豆包工作想成为"7×24 小时的工作伙伴"，能主动、持续、跨设备地工作；WorkBuddy 想成为"召唤即来的专家工具"，在你需要时提供深度能力，不需要时不占资源。

10.8 成本与商业模式对照

豆包工作：订阅制 + 企业版

豆包工作面向消费者提供免费版和 Pro 订阅（Turbo/Pro 档位），面向企业提供企业版。Pro 订阅解锁更强的模型、更多的任务时长、云电脑时长和高级技能。企业版增加管理后台、数据管控和审计能力。

这种商业模式下，Harness 的成本（Rust Helper 开发、沙箱维护、云电脑基础设施、审计系统）由订阅费覆盖。字节有动力持续投入安全和可靠性，因为企业客户会为这些能力付费。

WorkBuddy：自带模型 + 本地运行

WorkBuddy 的模式更轻：用户自带模型 API Key（或使用本地模型），Harness 本身开源或免费。成本主要是用户自己的 API 调用费和本地计算资源。

这种模式下，Harness 的开发成本由社区或核心团队承担，没有订阅收入支撑重工程投入（如 Rust MCP Helper、内核沙箱）。但用户避免了供应商锁定，数据完全在本地。

10.9 可观测性与调试对照

豆包工作：黑盒可观测

豆包工作的用户能看到：

• Agent 的思考过程（工具调用、中间结果，在 UI 中展示）
• 最终产物
• 任务状态和进度

但看不到：

• 系统提示词内容
• 工具路由的内部逻辑
• SubAgent 之间的消息传递细节
• 沙箱策略的具体规则
• 审计日志（可能只对企业管理员开放）

开发者可以通过 CDP 连接内置浏览器观测渲染进程的消息（如 doubao-mcp-bridge 项目所示），但这是非正式的调试方式，可能随版本更新失效。

WorkBuddy：白盒可观测

WorkBuddy 的用户能看到：

• 所有 Harness 配置文件（明文 Markdown/JSON）
• 系统提示词模板
• MCP 服务器配置和通信日志
• Agent 的完整执行轨迹
• 记忆文件和向量数据库

开发者可以直接修改配置、添加断点、查看日志，调试体验接近传统软件开发。

10.10 两条路线的本质

这两条路线不是非此即彼的。未来可能出现融合：豆包工作可能开放更多定制能力（.user_skills 已经是第一步），WorkBuddy 可能增加可选的沙箱和审计能力。但核心哲学——"我来保护你" vs "你自己决定"——会长期存在，因为它们服务于不同的用户和场景。

10.11 混合使用策略

对于同时使用两种工具的团队，可以考虑以下分工：

10.11.1 豆包工作负责标准化工作流

• 飞书生态操作（文档、表格、日历、审批）
• 定时任务和日报/周报自动化
• 非技术员工的日常 AI 辅助
• 需要安全沙箱的代码执行
• 多 Agent 协作的复杂研究任务

10.11.2 WorkBuddy 负责定制化和深度开发

• 需要自定义系统提示词和身份的场景
• 需要完全控制 MCP 服务器配置的开发工作
• 需要审计和版本控制 Harness 文件的团队
• 需要本地模型或私有模型部署的场景
• 深度代码开发和系统管理任务

10.11.3 两者协作的可能性

两种 Harness 可以通过文件系统协作：豆包工作生成的报告和数据文件保存在共享目录中，WorkBuddy 读取这些文件进行深度处理；或者反过来，WorkBuddy 编写的脚本和配置由豆包工作的定时任务调度执行。

Skill 格式的兼容性（两者都遵循 AgentSkills 规范）使得自定义 Skill 可以在两个平台之间复用——在 WorkBuddy 中开发和测试的 Skill，可以复制到豆包工作的 .user_skills/ 目录中使用。

10.12 对 Agent 产品设计者的启示

豆包工作和 WorkBuddy 的对照为 Agent 产品设计者提供了几个关键决策点：

1. Harness 可见性：你的用户需要看到和修改 Harness 吗？如果是，提供文件化配置；如果否，提供产品化默认值。
2. 安全边界：你的 Agent 执行不可信代码吗？如果是，内核级沙箱不是可选项。
3. 扩展模型：你希望用户如何扩展能力？Markdown Skill 降低门槛，代码插件提供灵活性，MCP 连接外部生态。
4. 多 Agent 策略：你的任务复杂度需要多 Agent 吗？固定三层更可控，动态层级更灵活。
5. 状态管理：记忆和配置放本地还是服务端？本地透明但不同步，服务端便利但黑盒。

这些决策没有标准答案，取决于目标用户、使用场景和商业模型。豆包工作和 WorkBuddy 分别给出了两个端点的参考实现，大多数产品会落在两者之间的某个位置。

下一章将总结全书的核心发现，讨论豆包工作 Harness 设计的启示、局限，以及对 Agent 开发者和使用者的建议。

CHAPTER 11 · ZJBB-004