logo
การพัฒนา
ภาพรวมพื้นที่นักพัฒนาพื้นที่ทำงานเอกสาร APIแนวปฏิบัติที่ดีบันทึกการเปลี่ยนแปลง
ค้นหา
ภาษาไทย
พื้นที่ทำงาน / ภาพรวม / Web เทียบกับ APP
การเปรียบเทียบความสามารถระหว่าง Web กับ APP
อัปเดตล่าสุด：30 วันที่ผ่านมา

การเปรียบเทียบความสามารถระหว่าง Web กับ APP

ภาพรวม

พื้นที่ทำงานของ GPTBots มีวิธีใช้งานให้เลือกสองแบบ ได้แก่ ฝั่ง Web（เข้าถึงผ่านเบราว์เซอร์）และ APP บนเดสก์ท็อป（ไคลเอนต์เดสก์ท็อป macOS/Windows/Linux）ทั้งสองฝั่งใช้คอมโพเนนต์ UI หลักและ API ฝั่งหลังบ้านร่วมกัน แต่มีความแตกต่างเชิงพื้นฐานในเรื่องAgent ทำงานจริงที่ใด

พูดง่าย ๆ คือ:

  • Web คือสมอง —— เริ่มต้นการสนทนา จัดการพื้นที่ ดูผลลัพธ์
  • APP คือมือและเท้า —— ลงมือทำงานจริง จัดการไฟล์ รันคำสั่ง เชื่อมต่อ IM

แยกความต่างในประโยคเดียว

คำถามของผู้ใช้ คำตอบ
ฉันใช้แค่เบราว์เซอร์พอไหม？ สำหรับดู Work / Search / เวิร์กโฟลว์ / เอเจนต์ / การจัดการพื้นที่ ถือว่าเพียงพอ —— แต่การทำงานจริงต้องมีโหนด APP ออนไลน์อย่างน้อยหนึ่งเครื่อง
APP บนเดสก์ท็อปใช้งานแบบแยกจาก Web ได้ไหม？ ได้ ฝั่ง APP เป็นพื้นที่ทำงานที่สมบูรณ์ในตัว มีเอนจิน Agent อยู่ในเครื่อง
ทุกคนในทีมต้องติดตั้ง APP ไหม？ ไม่ต้อง หากมีใครสักคนเปิด APP ออนไลน์ไว้ สมาชิกในทีมทุกคนก็สามารถส่งงานผ่าน Web ไปยัง APP เครื่องนั้นได้（ต้องตั้งค่าโหนดเป็น enterprise）
ตัวเลือกการตั้งค่าที่ไม่เห็นบน Web อยู่ที่ไหน？ อยู่ใน "การตั้งค่า" ของ APP บนเดสก์ท็อป —— Key ของโมเดล ทักษะ เครื่องมือ งานตั้งเวลา ช่องทาง เอเจนต์ย่อย หน่วยความจำ ความปลอดภัยขณะรัน

ตารางเปรียบเทียบฟังก์ชัน

มิติความสามารถ 🌐 ฝั่ง Web 🖥️ ฝั่ง APP
การสนทนา Work เชื่อมต่อโหนด Agent ระยะไกลผ่าน Gateway รันโดยตรงผ่าน Sidecar ในเครื่อง
Agent Loop พึ่งพาโหนดระยะไกลในการทำงาน ลูปอัตโนมัติ 25 รอบในเครื่อง
การบีบอัดบริบท ประมวลผลโดยโหนดระยะไกล กลยุทธ์บีบอัด 5 ชั้นในเครื่อง
ระบบไฟล์ ❌ ไม่มีสิทธิ์เข้าถึงไฟล์ในเครื่อง ✅ อ่านเขียนและค้นหาไฟล์ในเครื่องได้อย่างสมบูรณ์
การรันในแซนด์บ็อกซ์ ❌ ไม่รองรับ ✅ รันแบบแยกอิสระด้วยไมโครเวอร์ชวลแมชชีน VirtIO
เครื่องมือ MCP ❌ ไม่รองรับ ✅ รองรับการรับส่งสามแบบ stdio / SSE / HTTP
ทักษะ（Skills） ❌ ไม่รองรับทักษะในเครื่อง ✅ 21 รายการที่ตั้งไว้ล่วงหน้า + กำหนดเอง + ทักษะระดับองค์กร
ช่องทาง（IM） ❌ ไม่รองรับการตั้งค่า ✅ 14+ แพลตฟอร์ม（Telegram、WhatsApp、DingTalk ฯลฯ）
งานตั้งเวลา ❌ ไม่รองรับ ✅ ครั้งเดียว / เป็นรอบ / Cron
เอเจนต์ย่อย พึ่งพาโหนดระยะไกล ✅ สร้างในเครื่อง + ส่งงานข้ามโหนด
การจัดการหน่วยความจำ ✅ หน่วยความจำระดับองค์กร（หน้าจอผู้ดูแลระบบ） ✅ ครบทุกมิติ บัญชี + องค์กร + เซสชัน
การตั้งค่าโมเดล ❌ ไม่รองรับการตั้งค่าในเครื่อง ✅ จัดการ API Key จากหลายผู้ให้บริการ
แผงการตั้งค่า ไม่มี（ฟังก์ชันที่เกี่ยวข้องอยู่ในการจัดการพื้นที่） ✅ การตั้งค่าครบถ้วน
AI Search ✅ รองรับ ✅ รองรับ
Agent เอเจนต์ ✅ การจัดการเอเจนต์ A2A + การสนทนา ✅ การจัดการเอเจนต์ A2A + การสนทนา
Workflow ✅ รายการเวิร์กโฟลว์ + รายละเอียด + การรัน ✅ รายการเวิร์กโฟลว์ + รายละเอียด + การรัน
การจัดการพื้นที่ ✅ ฟังก์ชันผู้ดูแลระบบครบถ้วน ✅ เข้าถึงได้ผ่านหน้าต่างฝังตัว
การแสดงตัวอย่างมัลติโมดัล ✅ แสดงตัวอย่างไฟล์ 9 ชนิด ✅ แสดงตัวอย่างไฟล์ 9 ชนิด

ความแตกต่างด้านสถาปัตยกรรม

ฝั่ง Web: โมเดลการเชื่อมต่อผ่าน Gateway

浏览器 ──WebSocket──► Gateway ──WebSocket──► 远程 APP 节点 │ 智能路由 (LLM → BM25 → 兜底)
                      
                      浏览器 ──WebSocket──► Gateway ──WebSocket──► 远程 APP 节点
                        │
                    智能路由
                 (LLM → BM25 → 兜底)
บล็อกโค้ดนี้ในหน้าต่างลอย
  • ฝั่ง Web เองนั้นไม่รัน Agent Engine
  • การทำงานของทุกการสนทนาพึ่งพาโหนด APP ระยะไกลที่ออนไลน์อย่างน้อยหนึ่งเครื่อง
  • Gateway ทำหน้าที่ค้นหาโหนด กำหนดเส้นทางอัจฉริยะ และส่งต่อข้อความ
  • เหมาะกับ: การใช้งานแบบเบา ๆ การจัดการพื้นที่ การเริ่มงานจากระยะไกล

ฝั่ง APP: โมเดลสามโปรเซสในเครื่อง

React UI ──IPC──► Tauri Rust ──stdio──► Node.js Sidecar (Agent Engine)
                      
                      React UI ──IPC──► Tauri Rust ──stdio──► Node.js Sidecar (Agent Engine)
บล็อกโค้ดนี้ในหน้าต่างลอย
  • ฝั่ง APP รันเอนจิน Agent ที่สมบูรณ์ในเครื่อง（โปรเซส Sidecar）
  • มีสิทธิ์เข้าถึงระบบไฟล์ในเครื่องอย่างเต็มที่
  • สามารถลงทะเบียนเป็นโหนด Gateway เพื่อให้ฝั่ง Web หรือ APP อื่นเรียกใช้จากระยะไกลได้
  • เหมาะกับ: การพัฒนาเชิงลึก งานอัตโนมัติ การรันเครื่องมือในเครื่อง

กลไกการใช้ UI ร่วมกัน

คอมโพเนนต์หลักของหน้าจอสนทนาระหว่าง Web และ APP ใช้ร่วมกันผ่าน PlatformAdapter + การตั้งชื่อพาธของรีโพพี่น้อง —— รีโพ Web และรีโพ APP วางอยู่ในระดับเดียวกันภายในไดเรกทอรีเวิร์กสเปซเดียวกัน ฝั่ง APP อ้างอิงซอร์สโค้ดของรีโพ Web โดยตรงผ่าน alias ~/* ของ Vite/tsconfig

ชั้น คำอธิบาย
ชั้นที่ใช้ร่วมกัน（claw-shared） คอมโพเนนต์กว่า 40 รายการ เช่น WorkPage、PromptInput、SessionList、Preview โดยต้นทางอยู่ในรีโพ Web
ตัวปรับ Web webPlatformAdapter.ts — แมป Redux Store ให้เป็น WorkState
ตัวปรับ APP appPlatformAdapter.ts — แมป Redux + coworkService ให้เป็น WorkState

นั่นหมายความว่าหน้าจอสนทนา Work ที่เห็นบน Web กับที่เห็นบน APP นั้นเหมือนกันทุกประการ —— เป็นโค้ดชุดเดียวกัน คอมโพเนนต์ชุดเดียวกัน เพียงแต่วิธีการทำงานเบื้องล่างต่างกันเท่านั้น

คำแนะนำในการเลือกใช้

สถานการณ์ของคุณ แนะนำให้ใช้ เหตุผล
คุยกับ AI เป็นครั้งคราว ถามอะไรสักอย่าง ฝั่ง Web ไม่ต้องติดตั้ง เข้าถึงผ่านเบราว์เซอร์ได้เลย
จัดการพื้นที่ทำงาน（สมาชิก สิทธิ์ การใช้งาน） ฝั่ง Web การจัดการพื้นที่ให้ประสบการณ์ที่ดีที่สุดบนฝั่ง Web
จัดการไฟล์ในเครื่อง เขียนโค้ด ฝั่ง APP ต้องใช้สิทธิ์ระบบไฟล์ในเครื่อง + เครื่องมือ Bash
ให้ AI ช่วยทำงานซ้ำ ๆ ประจำวันแบบอัตโนมัติ ฝั่ง APP งานตั้งเวลารองรับเฉพาะ APP เท่านั้น
เชื่อม AI เข้ากับ IM ของทีม（Telegram、DingTalk ฯลฯ） ฝั่ง APP การตั้งค่าช่องทางรองรับเฉพาะ APP เท่านั้น
ทำงานร่วมกันหลายอุปกรณ์（ที่บ้าน + ที่ทำงาน） Web + APP หลายเครื่อง Web เป็นผู้เริ่ม โหนด APP เป็นผู้ทำงาน
ฉันเป็นผู้ดูแลระบบองค์กร ต้องการจัดการการใช้งาน AI ของทุกคน ฝั่ง Web หน้าจอการจัดการพื้นที่

รูปแบบการใช้งานทั่วไปของการทำงานร่วมกันหลายอุปกรณ์

"คุณอยู่บ้าน ใช้เบราว์เซอร์ฝั่ง Web เริ่มการสนทนา → Gateway กำหนดเส้นทางไปยัง APP ที่ออฟฟิศซึ่งเปิดอยู่ตลอด → APP ที่ออฟฟิศอ่านไฟล์ในเครื่องและทำงานให้เสร็จ → ผลลัพธ์แสดงในเบราว์เซอร์ของคุณแบบเรียลไทม์"

ในสถานการณ์นี้:

  1. คอมพิวเตอร์ที่ออฟฟิศ: ติดตั้ง APP เข้าสู่ระบบด้วยบัญชี ตั้งค่าโหนดเป็น account（เห็นเฉพาะตัวเอง）หรือ enterprise（เพื่อนร่วมงานก็ใช้ได้）
  2. เบราว์เซอร์ที่บ้าน: เข้าสู่ระบบด้วยบัญชีเดียวกัน เข้าไปที่ Work เมื่อส่งข้อความ ระบบจะเลือกโหนด APP เครื่องนั้นให้อัตโนมัติที่ด้านล่างของกล่องข้อความ
  3. การทำงาน: คำสั่งทั้งหมดรันบน APP ที่ออฟฟิศ ผลลัพธ์ส่งกลับไปยังเบราว์เซอร์ที่บ้านแบบสตรีมผ่าน Gateway