ENDEAVOR AGENT LITE ทำงานอย่างไร — สถาปัตยกรรมรุ่นปัจจุบัน

เผยแพร่ 12 สิงหาคม 2569 · อัปเดต 11 กันยายน 2569

ภาพประกอบ: ENDEAVOR AGENT LITE ทำงานอย่างไร — สถาปัตยกรรมรุ่นปัจจุบัน

Agent Lite ใช้โมเดลเล็ก 2B แต่ไม่ฝากทุกอย่างไว้กับความสามารถของโมเดล หลักการคือ ให้โมเดลเลือกเจตนาและขั้นต่อไป ส่วน scope, safety, retries, provenance และงาน deterministic ให้โค้ดเป็นคนคุม

ภาพรวม architecture

ผู้ใช้
  │
  ▼
CLI / Web UI
  │
  ▼
ReAct agent + routing/turn guards
  │
  ├─ local MLX VLM (Qwen3.5-2B)
  │
  └─ Tools
      ├─ MCP-RagDoc (Knowledge Base)
      ├─ local_search (Desktop/Documents)
      ├─ bash (read-only fallback/inspection)
      ├─ read_file (batch 4)
      ├─ read_image (progressive vision-first, batch 4)
      ├─ web_search (1–4 queries in parallel)
      ├─ write_file (workspect only)
      └─ generic MCP list/call for provisioned servers

1. Knowledge Base แยกออกจาก agent เป็น MCP-RagDoc

รุ่นปัจจุบันไม่ให้ Agent Lite เป็นเจ้าของ RAG implementation โดยตรง แต่เปิด MCP-RagDoc/rag_server.py เป็น local stdio MCP server ชื่อ lite-rag

Agent เรียกผ่าน generic MCP client:

mcp_call_tool(server="lite-rag", tool_name="rag_search", ...)

MCP-RagDoc เป็น agent-agnostic: มันรู้จัก source directory, SQLite index, semantic state และ sync jobs แต่ไม่ import Agent Lite หรือ routing logic ของ agent

ผลคือ RAG backend ทดสอบ/ใช้งานแยกได้ และ Agent Lite เปลี่ยน orchestration โดยไม่ต้องเปลี่ยน retrieval engine

2. Routing แยก “Knowledge Base” ออกจาก “ไฟล์ทั่วไป”

ปัญหาเดิมของ file-search agent คือคำว่า “หาไฟล์” อาจหมายถึงคนละขอบเขต รุ่นใหม่จึงให้โค้ดแยก scope ก่อน:

Knowledge Base / rag_document → lite-rag.rag_search
Desktop / Documents          → local_search
explicit outside-RAG/bypass  → bash read-only
current web information      → web_search

ถ้าผู้ใช้ถาม “RAG คืออะไร” เป็นคำถามความรู้ทั่วไป ไม่ใช่คำสั่งค้น KB จึงไม่ควรยิง rag_search โดยอัตโนมัติ

3. ถ้า RAG/MCP ใช้ไม่ได้ ให้ fallback โดยไม่ขยาย scope

ถ้า runtime ไม่มี server lite-rag, tool หาย หรือ MCP เชื่อมไม่ได้ ระบบจะหยุด retry เดิม แล้วเปลี่ยนเป็น bash แบบ read-only

แต่ fallback ต้องรักษา scope เดิม:

  • KB request → ค้นเฉพาะ rag_document/
  • project/repository request → ค้นเฉพาะ project root
  • local file request → จำกัด Desktop/Documents ตาม routing ที่กำหนด

ไม่อนุญาตให้ความล้มเหลวของ RAG กลายเป็นเหตุให้ agent ค้นทั้ง Home หรือใช้เว็บแทนข้อมูล local

4. MCP-RagDoc retrieval ภายในยัง deterministic

rag_search ของ MCP-RagDoc ใช้หลายชั้น:

filename-first lookup
→ SQLite FTS5/BM25
→ Thai/mixed normalization + aliases
→ OCR fuzzy recovery
→ optional MiniLM semantic retrieval
→ deterministic RRF fusion

semantic worker เป็น subprocess อายุสั้น จึงไม่ทำให้ ONNX/NumPy runtime ค้างใน MCP server ตลอดเวลา ถ้า semantic model/dependency ไม่พร้อม ระบบยังใช้ lexical/OCR path ได้

5. read_file: parallel ภายใน tool call เดียว

read_file รองรับสูงสุด 4 ไฟล์ต่อ call

  • paths=[...] เมื่อทุกไฟล์ใช้ options เดียวกัน
  • requests=[{path, ...}, ...] เมื่อแต่ละไฟล์มี contains, line range หรือ context ต่างกัน

งานถูกกระจายแบบ bounded parallelism แต่ output ต่อไฟล์ยัง cap ไว้ และ error ของไฟล์หนึ่งถูกแยกไม่ให้ทำลายผลของทั้ง batch

สำหรับไฟล์ใหญ่ยังใช้แนวทาง streaming/sampling แทน materialize ทั้งเอกสารขึ้น RAM

6. read_image: vision-first ก่อน OCR ที่มองเห็นได้

รุ่นปัจจุบันเปลี่ยนจากแนว “OCR ก่อนเสมอ” เป็น progressive vision-first

ครั้งแรกของภาพ ระบบทำ DLP/sensor preflight แบบซ่อน แล้วคิว original pixels เข้า direct-vision context ให้ VLM ดูก่อน ถ้าต้องการอ่านตัวอักษร, หา keyword หรือ zoom region ค่อยเรียก sensor ต่อ

batch ได้สูงสุด 4 ภาพใน call เดียว และเลือก OCR เป็นรายภาพได้ แต่ OCR ที่ผู้ใช้/โมเดลมองเห็นจะถูก defer ถ้าภาพนั้นยังไม่ผ่าน overview เพื่อรักษา contract ว่าเห็นภาพจริงก่อน

7. web_search: multi-query โดยไม่ใช้ LLM ภายใน tool

web_search รับ 1 query หรือ list 2–4 query ใน call เดียว หลาย query รันพร้อมกัน จากนั้นโค้ดทำ relevance ranking, source diversity, URL/network validation และดึง query-matching passages

ตัว tool ไม่เรียก LLM เพื่อ filter ผลเว็บ จึงลด latency และไม่สร้างวงจร model-within-model โดยไม่จำเป็น

URL ที่ผ่าน filter ถูกเก็บเป็น source evidence และ agent layer มี deterministic citation handling เพื่อไม่ต้องฝากการ “จำแนบลิงก์” ไว้กับโมเดล 2B

8. Generic MCP client แต่โมเดลเพิ่ม server เองไม่ได้

Agent Lite มี mcp_list_tools และ mcp_call_tool เพื่อใช้ MCP server ที่ developer provision ไว้ แต่ไม่มี dynamic add/remove registration ให้โมเดล

stdio server ถูกตรวจ command/cwd และรันผ่าน sandbox ที่ deny network และจำกัด write paths ตาม capability ที่ตั้งไว้ เช่น MCP-RagDoc เขียนได้เฉพาะ private state ไม่เขียน source documents

9. Tool-loop guard ไม่ได้บล็อกแค่ “tool เดิม”

ระบบแยกสองแนวคิด:

  • exact consecutive repeat — หยุดเร็วเมื่อ tool+args เดิมซ้ำ
  • changed recovery attempts — ถ้าเปลี่ยน command/query จริง สามารถลอง tool เดิมต่อได้ แต่มี quota ต่อ tool ต่อ turn (default 10)

จึงไม่เกิดปัญหาว่า agent แก้ command แล้วแต่โดนบล็อกเพราะชื่อ tool เหมือนเดิม ขณะเดียวกันก็ยังไม่ปล่อย loop ไม่จำกัด

10. PDF to Text แยกจาก read_file

หน้า PDF to Text ใน Web UI เป็น pipeline สำหรับสร้างไฟล์ .txt จริง ไม่ใช่แค่ดึง sample เข้า context

ทำงานทีละ physical page:

  1. ใช้ embedded PDF text เมื่อมี
  2. ถ้าเป็น image-only page จึง rasterize หน้าเดียวและใช้ Apple Vision OCR
  3. พยายาม reconstruct table แบบ conservative
  4. เขียน page state ลง SQLite ทันที
  5. optional: ใช้ local Lite model ช่วย clean Thai OCR prose แบบ no-think; native text/OCR tables ไม่ต้องผ่าน LLM
  6. stream output ตามลำดับหน้าไปยังไฟล์ใน workspect/

จึงไม่ต้องเก็บ PDF ทั้งเล่มเป็น Python string ก้อนเดียว

11. Guardrails รอบโมเดลเล็ก

นอกจาก routing ยังมี code-owned checks เช่น:

  • sensitive-path/content DLP
  • bounded tool/output budgets
  • source citation append สำหรับ web/RAG evidence
  • write-file verification/retry path
  • date/runtime path injection จากเครื่องจริง ไม่ hardcode username
  • bash allow-list + per-command validation + macOS sandbox-exec
  • image QR/OCR secret preflight

หลักคิดคือ อย่าขอให้โมเดลเล็ก “ระวังให้มากขึ้น” ในเรื่องที่โค้ดตรวจได้แน่นอนกว่า

อ่านต่อ

ความคิดเห็น

กำลังโหลดความคิดเห็น...