14 KiB
14 KiB
Ygent 与 WorkBuddy AI 实现对比及可实施项
日期：2026-10-14 对比对象：WorkBuddy-AI-实现分析报告（对该报告所述 WorkBuddy 桌面版能力的静态逆向结论）× Ygent 代码库实际实现
状态说明：本文是差距分析 + 可实施项评估，不是实施方案，也不改动任何既有交付承诺。文中"已实现"以代码为据（附文件路径）；docs/*.md 与 AGENTS.md 的目标描述不计为已实现。
0. 结论速览
- 两者不是同类产品，不能逐项对齐。 WorkBuddy 是「自带 Agent 内核 + 云端多模型网关 + 自研 OS 沙盒」的一体化商业桌面端；Ygent 是「接入外部内核（OMP）+ 用户自带渠道（BYO Key）+ 宿主权限治理」的可控桌面端。内核不是自己的，这是最大的结构性差异。
- Ygent 在六个方向的实现深度已超过 WorkBuddy（团队/岗位 80+ 表、项目任务、资料库版本化、A2A 协作预算、LSP 自管、grants+审计），这些不需要对齐，属于反向优势。
- 真正值得补的差距集中在宿主层，且大部分不需要碰内核：进程治理、删除安全、循环防护、预热、少量高频工具缺口、内置连接器预设。这批属于低风险可直接做。
- 唯一的大工程差距是 OS 级沙盒（WorkBuddy 的 tsbx + shim 双层），但当前用户取向（2026-10-12「给全部的授权，现阶段不考虑在现实上做这么多工作」）与重型限制机制相反，不建议现在做，继续如实声明"规则隔离不是沙盒"。
- 报告本身是静态逆向，提示词全文、服务端模型路由、鉴权细节本地不可见，不能当作实现规格照抄。
1. 逐层对比
1.1 整体架构
| 层 | WorkBuddy（报告） | Ygent（实测） | 判定 |
|---|---|---|---|
| 桌面壳 | Electron + app.asar，含 workbuddy-editor-sdk（Office 编辑）、baas-v2 | Tauri 2 + React 18 + zustand 5（package.json） |
等价不同技术，无需改造 |
| UI↔引擎协议 | ACP（@agentclientprotocol/sdk），本地 HTTP /api/v1/acp |
自研 NDJSON RPC over stdin/stdout（src-tauri/src/sidecar.rs:448-489, 667-726） |
能力等价；除非要接第三方 UI，否则不必换 ACP |
| Agent 内核 | 自带 @genie/agent-cli（Claude Code 血统，9.4MB bundle + 66 懒加载分块） |
外部 omp-*-pc-windows-msvc.exe，--mode rpc-ui（sidecar.rs:506-544, 647） |
结构性差异：内核非自有 |
| 模型接入 | 云端网关 /plugin 前缀 + Bearer + X-User-Id，服务端路由 |
用户渠道表 + 直连 OpenAI 兼容 / Responses / Anthropic Messages / Gemini（commands/channel.rs, llm.rs） |
BYO 渠道 vs 服务端托管，各有取舍 |
1.2 内核与循环
| 项 | WorkBuddy | Ygent | 可实施性 |
|---|---|---|---|
| 循环原语 | @openai/agents + 自研 genie 工作区包 |
由 OMP 提供，宿主不自建循环 | ❌ 不建议（违反"不创建第二套聊天内核"约定） |
| 死循环防护 | CBC_LOOP_GUARD_CONSECUTIVE_THRESHOLD / _SEQUENCE_REPEATS / _DISABLED |
未见实现 | ✅ 可在宿主对工具名/参数序列做重复检测 |
| 进程守护 | daemon-supervisor.cjs + windows-job.cjs（Job Object 绑子进程树） |
仅 buildtest/process_windows.rs:86-290 用 Job Object（构建进程强杀），OMP 子进程未绑定 |
✅ 低成本高收益 |
| 启动预热 | cbc-prewarm、preload-lazy-chunks |
有空闲回收 trim_idle_processes(8)（collaboration_runtime.rs:263），无启动预热 |
✅ 可补 |
| 低内存模式 | codebuddy-lowmem（RSS 阈值触发 heap snapshot） |
无 | ⚠️ 可选，Node 内核才有意义 |
1.3 工具系统
Ygent 的工具体系不是更少，而是不同：宿主侧有 ygent_*、library_*、experience_*、collaboration_*、project_tasks_*、以及大批 team_*（team/*.rs），前端标签字典 src/lib/toolSummaryRules.ts 头部注释标明「verified against installed WorkBuddy 5.7.6」——字典里有 WorkBuddy 工具名，但后端并不产出。
后端确证缺失的 WorkBuddy 侧高频工具：
- 联网：
web_search、web_fetch - 规划：
enter_plan_mode/exit_plan_mode/plan_* - 待办：
todo_write - 交互：
ask_followup_question（Ygent 有questions.rs问答机制，但非同名工具体系） - 可视化：
visualize:show_widget、widget_guidelines（前端turnFold.ts:91-95能识别 widget 渲染，后端不产出） - 多媒体：
image_gen（Ygent 完全无多媒体生成） - 静态检查：
read_lints（Ygent 已有 LSP 自管 +ygent_code_analysis，基础具备） - MCP 侧：
mcp_call_tool/mcp_get_tool_description/fetch_mcp_resource - 集成：
call_*_integration、automation_update
文件类工具靠 OMP 原生 read/write/edit/bash/grep/glob 替代（sidecar.rs:596），命名与 WorkBuddy 不同，但功能覆盖。
1.4 模型层
| 项 | WorkBuddy | Ygent |
|---|---|---|
| 推理位置 | 云端网关（本地不推理） | 用户渠道直连（llm.rs 真流式 SSE） |
| 协议 | OpenAI 兼容 /chat/completions + SSE |
OpenAI 兼容 + Responses + Anthropic Messages + Gemini（ygent-model-metadata-plan.md） |
| 降级/回退 | 有降级标记（如 deepseek_flash_unavailable） |
未见渠道级降级/回退路由 |
| 多模态 | ASR（wb-asr / gpt-4o-mini-transcribe）、图像生成/编辑（hunyuan-image-*） |
无多媒体生成 |
1.5 沙盒与安全（最大差距）
| 层 | WorkBuddy | Ygent | 判定 |
|---|---|---|---|
| 策略/审批 | @anthropic-ai/sandbox-runtime + 权限提升桥 |
审批网关：内核恒 --approval-mode always-ask，宿主决定放行/弹卡（sidecar.rs:648-650） |
✅ 已有 |
| 执行层沙盒 | 腾讯自研 tsbx.dll + sandbox-center.exe + betterleaks.exe + tsbxldr.dll |
无 OS 级沙盒（无 seccomp/AppContainer/文件系统隔离） | ❌ 大工程 |
| Shim 层 | brokered-fs-shim（fs 走 broker IPC）、sitecustomize.py、safe-delete（删除进回收站 GENIE_TRASH_DIR + bulk-guard）、brokered-bin 白名单命令目录 |
无 | ✅ safe-delete 与命令白名单可移植 |
| 授权模型 | 会话/账号级 | grants 表白名单（fnv1a(method|title) 哈希）+ audit_log + 完全访问 + 经理只读白名单（omp.rs:318-341, approval.rs:54-118） |
Ygent 更细 |
1.6 扩展体系
| 项 | WorkBuddy | Ygent | 缺口 |
|---|---|---|---|
| MCP | @modelcontextprotocol/sdk 1.29.0，配置文件驱动 |
stdio + Streamable HTTP 自研（connectors/client.rs），协议协商 2025-11-25→2024-11-05，凭证进 Windows 保险库（connectors/vault.rs） |
OAuth、SSE、CLI 适配器、resources/prompts、市场 |
| Skills | SKILL.md（兼容 Anthropic Agent Skills） | SKILL.md 按需 ygent_load_skill(id)，SHA256 摘要 + 回合冻结快照 |
ZIP/Git/市场导入 |
| 专家 Expert | 专家包（plugin.json + agents/*.md）、专家团 | 无独立专家概念：「专家」tab 实为团队岗位（TeamRolePane.tsx, CapabilityCenter.tsx:41） |
P3 专家闭环待实现（方案 §9 已列） |
| A2A | @a2a-js/sdk |
自研 collaboration 体系 + 80+ team_* 表，含预算/取消/恢复 |
Ygent 更强 |
| IM 渠道 | /api/v1/channels/wechat|wecom + 客服/群机器人 API |
无（channels 表是模型渠道，非 IM） |
可做，依赖连接器可用 |
1.7 部署与治理
| 项 | WorkBuddy | Ygent |
|---|---|---|
| 部署变体 | product.json 四变体（cloudhosted/selfhosted/ioa/internal），ACC_PRODUCT_CONFIG_V2/V3 |
无（单机桌面） |
| 认证 | 腾讯云账号 + Bearer + X-User-Id |
本机，无账号体系 |
| 可观测 | @tencent/galileo-node-sdk + OpenTelemetry /v1/traces |
audit_log 表；无 OTEL |
| 资源分发 | COS 加速桶 | 本地 |
2. 可实现清单（按成本分档）
A 档：宿主层、低风险、可直接做（不碰内核协议）
| # | 事项 | 依据/落点 | 收益 | 前置 |
|---|---|---|---|---|
| A1 | OMP 子进程纳入 Windows Job Object，进程退出时回收整棵子进程树 | 对标 windows-job.cjs；现 sidecar.rs 启动 OMP 未绑定 Job |
异常退出/崩溃不再残留 OMP 进程 | 无 |
| A2 | safe-delete：删除类操作进回收站 + 批量删除 guard | 对标 shim safe-delete + GENIE_TRASH_DIR + bulk-guard；Ygent 完全无 |
直接降低误删不可逆损失 | 需用户确认（见 §4） |
| A3 | 危险命令 / 危险路径黑名单拦截（宿主 Shell 工具包装层） | 对标 brokered-bin 白名单；Ygent 有 grants 但无命令级策略 |
挡住高危命令 | 需用户确认 |
| A4 | 工具调用死循环检测（同名+同参序列阈值告警/中断） | 对标 CBC_LOOP_GUARD_*；Ygent 无 |
省 token、防卡死 | 无 |
| A5 | 内核启动预热（新对话页提前拉起/复用内核） | 对标 cbc-prewarm；Ygent 有回收无预热 |
缩短首字延迟 | 无 |
| A6 | 补 read_lints（复用已有 LSP + ygent_code_analysis） |
lsp/*.rs, code_analysis.rs 基础设施已具备 |
近乎白送的工具补齐 | 无 |
| A7 | 补 web_fetch / web_search（可基于内置浏览器或直连 fetch） |
对标 WB 同名工具；Ygent 有 ygent_browser 可复用 |
联网研究类任务能力 | 需授权策略 |
| A8 | 内置 连接器预设扩充（现仅 GitHub / DeepWiki） | connectors/presets.rs:17-33 |
降低接入门槛 | 无 |
| A9 | 前后端工具名对齐：把 toolSummaryRules.ts 里已有但后端不产出的名字清点，避免"能渲染但不产出"的错位 |
src/lib/toolSummaryRules.ts vs sidecar.rs:973-1004 |
消除认知错位 | 无 |
B 档：中等成本，需设计与验收
| # | 事项 | 说明 |
|---|---|---|
| B1 | 多媒体生成接入：文生图 / 图生视频 / 音频转写，走现有渠道体系 | Ygent 目前零多媒体生成，是明显功能空白；参考 WB 的 image_gen、AudioTranscribe |
| B2 | 专家（Expert）闭环 P3 | 方案 §9 已定；导入 WorkBuddy .codebuddy-plugin/plugin.json + agents/*.md 到 Ygent 模型（映射表见方案 §5）。当前"专家 tab = 团队岗位"需明确区分 |
| B3 | MCP 增强：OAuth 授权流、CLI 连接器适配、resources/prompts 读取、mcp_get_tool_description 等价工具 |
现只支持 stdio + Streamable HTTP，无 OAuth/SSE/CLI |
| B4 | 渠道级降级/回退路由 | 对标 WB 的降级标记（如 deepseek_flash_unavailable） |
| B5 | 非完全访问时把 write/edit 纳入 cwd 范围校验 |
目前经理有只读路径校验（approval.rs:95-118），普通会话主要靠审批网关 |
| B6 | 结构化 trace / OpenTelemetry 导出 | 在 audit_log 与已有渲染性能诊断之上，便于定位渲染长任务 |
| B7 | IM 渠道接入（企业微信/微信机器人） | 依赖连接器可用；当前会话企业微信连接器为关闭状态 |
C 档：大工程 / 不建议现在做
| # | 事项 | 不建议理由 |
|---|---|---|
| C1 | OS 级沙盒（tsbx 等价物） | Windows 需文件过滤驱动/内核态组件，成本极高；且与用户 2026-10-12「不做这么多现实工作」的取向相反。建议保持规则隔离 + 审批 + 审计，继续如实声明"不是沙盒"（ygent-team-integration.md:91） |
| C2 | 自建 agent 循环 / 换自研内核 | 违反"不创建第二套聊天内核"约定，收益低 |
| C3 | 改用 ACP 协议 | 现 NDJSON RPC 已满足；除非要接第三方 UI 或多内核 |
| C4 | 市场 / 云同步 / 多设备 / 云资产 | 方案 §9 已列为后续，不在首期 |
| C5 | 产品四变体配置 | 单机桌面场景价值低 |
| C6 | 遥测上报（galileo 类） | 涉及隐私，桌面版不建议引入 |
3. 反向优势（Ygent 已超 WorkBuddy，不需要对齐）
- 团队 / 岗位：80+
team_*表，覆盖成员、岗位、计划、执行、复核、产出、恢复、调度（team/*.rs,TeamOffice.tsx）。 - 项目任务：版本化任务、验收/复核/续跑（
project_tasks.rs,ProjectTasks.tsx）。 - 资料库：版本化物料 + 冻结引用 + 经验沉淀（
library.rs,knowledge.rs）；P0/P1 已接入。 - A2A 协作：自研调度器 + 因果预算 + 取消归属 +
agent_live/agent_replay重放（collaboration_runtime.rs）。 - 权限治理：
grants白名单 +audit_log+ 经理只读白名单 + 员工分级冻结，层次比报告所述更细。 - LSP / 代码分析：宿主自管 LSP 生命周期，禁用 OMP 原生 LSP（
lib.rs:78-94）。
4. 前置条件与冲突提醒
- 内核范围：
AGENTS.md明确"当前只使用 OMP 内核""Codex 内核适配和验收暂不纳入本轮"。涉及内核的改动只按 OMP 验收。 - 授权取向冲突（重要）：用户 2026-10-12 明确"给全部的授权，现阶段不考虑在现实上做这么多工作"，取代了逐工具授权方案。⇒ A2 / A3（删除回收站、命令黑名单）属于新增限制性机制，与"完全访问不逐次确认"的当前取向存在张力，实施前必须与用户确认。A1 / A4 / A5 / A6 / A8 / A9 与授权无关，可直接做。
- 报告不可当规格：报告为纯静态逆向，提示词全文、服务端模型路由、鉴权细节本地不可见（报告 §9 自述）；tsbx 内部行为、
product.json变体语义均无字节级证据。只参考其架构分层与机制存在性，不照抄实现细节。 - 不虚构能力：本文 A 档各项均为"可实施"，不代表已实现；落地时仍需按各域既有 SOP 完成真实验收（不支持项继续如实标注）。
- 不引入 WorkBuddy 数据依赖：任何导入格式兼容都是配置适配，不写其他软件的配置、不复制其凭证。
5. 建议的下一步
- 先确认 §4.2 的授权取向：是否允许新增删除回收站 / 命令黑名单这类限制机制。
- 若允许，按 A1 → A2/A3 → A4 → A5 → A6/A8/A9 顺序落地（A1 无争议可先做）。
- B 档单独立项：建议先做 B1（多媒体） 或 B2（专家 P3），前者是功能空白、用户可感知，后者方案已定稿。
- C 档维持"不做"，在相关文档中继续如实声明现有局限。