admin/ycode

0 Fork 0

Files

T

xiaohan.yuan 6dc59f89ba chore: establish YCode replication baseline and TODO

2026-10-17 02:43:49 +08:00

10 KiB

Raw Permalink Blame History

WorkBuddy AI 能否「1:1 复刻」——基于 REA 的可行性评估

历史评估，结论已由 1比1复刻重新评估-2026-10-15.md 修正。本文把“行为复刻”等同于“源码复制”、从体积/压缩/工具未配置推出“不可能”的推理不成立；原生和云端未覆盖项应标为条件或未知，不沿用本文的一概否定。

评估对象：《WorkBuddy-AI-实现分析报告.md》所述目标（本机安装的 WorkBuddy 桌面版 v37.10.3-42） 评估方法：REA MCP 实测（analyze_javascript_application、binary_session 能力探测）+ asar 清单解析 + 混淆度/源码可得性度量 评估日期：2026-10-14

0. 结论（TL;DR）

不能 1:1 复刻。 REA 足以支撑「读懂」和「功能等价重写（clean-room）」，但达不到「1:1 复刻」——这是三重封死，不是工具能力不足：

维度	能否 1:1	决定性原因
法律	❌	1:1 复刻 = 复制腾讯专有代码，直接侵权。分析可以，照抄不行
原生二进制	❌	≈360MB 原生代码（含单个 199.5MB 的 `editor_sdk.exe`）；本机无任何反编译器可用，即便装上 Ghidra 也只出伪代码
压缩 JS	❌	主 bundle 全部 rolldown/rspack 压缩，0 个 source map、`.js.map` 不含 `sourcesContent`、无 `.ts` 源
云依赖	⚠️	排除云部分后，本地引擎不推理，AI 能力实质归零——复刻出来是个没有大脑的壳

一句话：REA 能给你一张足够精确的「建筑图纸」，但拿不到「原始建材」；而且这栋楼的主脑（模型+提示词）本来就在云上，拆掉之后剩下的部分 1:1 复刻也没有意义。

1. 先说法律红线（这条是决定性的）

「1:1 复刻」在工程上等价于逐字节/逐逻辑复制专有软件。WorkBuddy 的 @genie/agent-cli、tsbx 沙盒、editor_sdk.exe 均为腾讯闭源资产，package.json 的 private: true + 无开源许可声明。因此：

可以做：逆向分析、理解架构、提取可公开观察的接口契约、用干净室（clean-room）方式独立实现等价系统。
不能做：1:1 复制代码、重新打包分发。

下面所有技术结论都建立在「即使技术上允许」这一假设上——结论依然是做不到 1:1。

2. REA 实测：工具链本身的能力边界

在本机（Windows 11 / x64）实测 binary_session，得到关键事实：

Provider	状态	影响
JavaScript/Electron 分析	✅ 可用	唯一能真正跑起来的主力
Ghidra（原生反编译）	❌ `not_configured` — `GHIDRA_INSTALL_DIR` 未设置	无法反编译任何 .dll/.exe
Hopper	❌ `unsupported_host`（仅 macOS）	Windows 上不可用
IDA	❌ `not_configured`	不可用
`recover_javascript_sources`（Wakaru 反压缩）	❌ `provider_missing`（仅 Linux x64）	无法把压缩 bundle 还原成可读命名
PE 资源 / .NET 静态分析	✅ 可用	只能看结构，不能出伪代码

这就是第一个硬约束：本机对原生层是「黑盒」。REA 自己声明其伪代码产物 "not original source and not text-equivalent"——即便配上 Ghidra，也只是逼近语义，不是还原源码。

实测运行记录：对 app.asar 限定 2 个源文件分析，结果——

parsed_javascript_files: 2、visited_ast_nodes: 11395、findings: 10、parse_failures: 0
但 coverage.status: partial，遗留 11,387 application unknowns / 128,327 semantic unknowns
12 个语义族（call-flow、data-flow、boundary…）全部 partial

对比原报告 §8：跑主 bundle（2,238,569 AST 节点）耗时 5 分钟 / 6GB 堆，语义图被父级预算截断。结论一致：REA 出的是抽样级证据，不是完整重建。

3. 逐层拆解：哪些能量化，哪些不能

3.1 实际体积构成（asar 清单 + unpacked 实测）

安装总体积 ≈ 935MB（Electron 运行时 279MB + app.asar 94MB + app.asar.unpacked 562MB），共 14,475 + 4,596 个文件。

类别	体积	REA 可得性	能否 1:1
原生二进制	≈360MB	❌ 本机无反编译器	❌
首方压缩 JS（renderer 116.7MB、extensions 49.9MB、plugins 31.5MB、cli/dist 13.1MB、main/server.js 3.4MB）	≈235MB	⚠️ 语义可恢复，命名/注释丢失	❌
首方可读源码（`cli/vendor/shim/.cjs`、`cli/bin/.cjs`）	≈2.7MB	✅ 就是完整源码	✅（但复制=侵权）
第三方 OSS（OpenAI Agents SDK、MCP SDK、OpenTelemetry、node-pty、koffi、zod、hono、@larksuiteoapi…）	≈58MB	✅ 公开可得	✅ 直接 `npm install`，无需复刻

3.2 无法 1:1 的「不可还原物」清单（实测）

A. 原生二进制（决定性障碍）

199.5 MB  node_modules/@tencent/tencent-docs-ai-engine/bin/win32-x64/editor_sdk.exe   ← Office 编辑器引擎（CEF 级）
 22.0 MB  cli/vendor/sandbox/5.8.5/betterleaks.exe
  9.7 MB  node_modules/@genie/im-channels-native/build/Release/ImSDK.dll
  9.0 MB  cli/vendor/sandbox/5.8.5/sandbox-center.exe
  2.3 MB  cli/vendor/sandbox/5.8.5/sandbox_ffi.dll
1.6 MB 合计  tsbx.dll / tsbx_sdk.dll / tsbxldr.dll / tsbxlow.dll   ← 腾讯自研沙盒核心
   + 各 .node：turing_sdk、perf_metrics、wechat_copydata_decoder、job-object、ripgrep、qimei、os-bridge…

tsbx.dll（795KB）是自研沙盒的策略执行核心，betterleaks.exe（22MB）是泄漏检测引擎——这两个是 WorkBuddy 安全模型的关键差异点，恰恰是最不可能被还原的部分。而 199.5MB 的 editor_sdk.exe 基本可以判定为「不可重建」。

B. 压缩 JS（语义可读，源码不可还原）

主 bundle 度量：

cli/dist/codebuddy-lite-wb.mjs  9.48MB  2679 行  平均行长 3539 字符  最长 488,181 字符
main/server.js                  3.60MB  1185 行  平均行长 3037 字符

证据：

sourceMappingURL 出现次数 = 0
全文 .js.map 共 60 个，抽样解析 @genie/im-channels-sidecar/.../*.js.map → 无 sourcesContent 字段
安装包内 .ts 源文件 = 0 个（仅 65 个 .d.ts 类型声明，只给接口形状、不给实现）

好消息：压缩不算彻底——保留了 235 个可读函数名（doIsToolCall、isProxyToolCalls、bindAutowiredProvider、applyServiceDecorator…）和几乎全部字符串字面量。这让 REA 的语义恢复质量明显高于典型混淆产物，但仍无法还原原始文件划分与命名。

C. 可读源码层（这块确实能 1:1）

cli/vendor/shim/ 与 cli/bin/ 下的 .cjs 是未压缩完整源码，带缩进、带注释：

1162 行  node-brokered-fs-shim.cjs      (fs 走 broker IPC)
 861 行  node-safe-delete-shim.cjs      (删除进回收站)
 465 行  safe-delete-bulk-guard.cjs     (批量误删防护，DEFAULT_THRESHOLD=20)
 311 行  broker-ipc-client.cjs
 128 行  daemon-supervisor.cjs

沙盒 shim 层可以 100% 读懂并等价重写——但这是全栈里最容易的部分。

3.3 「排除云部分」反而掏空了核心

原报告 §4 已明确：本地不推理，@genie/model-compatibility 只做 API 适配，模型选择/路由在服务端按套餐决定。被排除的云部分包括：

多模型网关与路由策略（GLM/混元/DeepSeek/Qwen/Kimi/MiniMax/GPT/Gemini/Claude）
主系统提示词全文（本地仅有碎片，例如 bundle 里可检索到 You are a background fork of the main agent. Follow these rules strictly:）
账号鉴权（Bearer + X-User-Id）、套餐/配额、可观测上报

也就是说：排除云部分后，你要复刻的「AI 能力」其智能来源本身就在被排除的那部分里。剩下的本地引擎即使 100% 重写，接不上自己的模型网关也只是个空壳——除非你自建网关，那又变成另一件事（自研产品，而非复刻）。

4. 能力光谱：REA 究竟能带你走到哪一步

目标	可行性	说明
读懂架构 / 写分析报告	✅ 完全可行	原报告已是范例，REA + 字符串证据足够
导出接口契约（ACP 协议、工具 schema、MCP/Skill 约定、`.d.ts`）	✅ 可行	协议与类型声明清晰可提取
等价重写可读 JS 层（shim / daemon / bin）	✅ 可行	有完整源码参考
等价重写压缩 JS 层（agent 循环、工具系统、模型适配）	⚠️ 可行但成本极高	语义可恢复 ≠ 源码可还原；需逐模块重建，且缺服务端提示词
重建原生沙盒（tsbx + sandbox-center + betterleaks）	❌	无反编译器；即便有，伪代码也无法 1:1
重建编辑器引擎（`editor_sdk.exe` 199.5MB）	❌	实质不可行
1:1 复刻整体	❌	法律 + 原生 + 压缩 + 云依赖，四重封死

5. 如果目标是「自己做一个同类产品」，正确路径

不要走「复刻」，走「参照 + 自研」：

复用 OSS 底座：Electron + Anthropic 沙盒 runtime（开源）+ MCP SDK + OpenAI Agents SDK —— WorkBuddy 自己也是这么拼的。
自研 agent 内核：参照 Claude Code 的公开架构（工具循环、hooks、Skill/Plugin 约定、CLAUDE.md 体系），这些是公开文档级别的知识，不需要逆向。
自建模型网关：这是被排除的「云部分」，也是真正的护城河——自己实现多模型路由 + 提示词工程。
沙盒另选方案：Windows 上可用 AppContainer / Job Object + 文件系统虚拟化，或直接用已开源的 anthropic sandbox-runtime，不必也无法复刻 tsbx。
明确边界：抄协议与公开约定是安全的，抄二进制与压缩代码是侵权。

6. 最终判断

用 REA 做「理解」是够的，做「1:1 复刻」是不够的，且不需要——因为被排除的云部分才是核心价值所在。

REA 在本机的实际天花板：JS/Electron 层语义分析（coverage 明确为 partial），原生层完全黑盒（无 Ghidra/Hopper/IDA）。
结构上可 1:1 的只有约 2.7MB 的 shim/daemon 可读源码；占大头的 360MB 原生二进制 + 235MB 压缩 JS 都无法 1:1。
「排除云部分」这一前提，使复刻产物失去智能来源，投入产出比极低。

建议：把这次分析定位为「架构学习 + 接口提取」，产出「设计说明书」而非「副本」。若真要落地产品，按 §5 的自研路径走。

10 KiB Raw Permalink Blame History Unescape Escape