ระบบที่ให้เอเจนต์ดูแลวิกิ LLM สไตล์ Karpathy ด้วยตัวเอง - บนพื้นฐาน Markdown และ Git

 (github.com/nex-crm)
2 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตั้งค่าให้ เอเจนต์ AI หลายตัวทำงานร่วมกันในออฟฟิศเดียวกัน และเน้น เวิร์กโฟลว์ที่มองเห็นได้ ผ่าน UI บนเบราว์เซอร์และการจัดทีมตามบทบาท แทนการเรียก API แบบซ่อนอยู่
  • หน่วยความจำถูกแยกเป็น notebook ของแต่ละเอเจนต์และ wiki ส่วนกลางของทีม โดยออกแบบให้บริบทงานดิบอยู่ฝั่งส่วนตัว และยกระดับเฉพาะข้อเท็จจริงที่ตรวจสอบแล้วกับเพลย์บุ๊กที่ใช้ซ้ำได้ขึ้นเป็นความรู้ส่วนกลาง
  • wiki เริ่มต้นไม่ได้เป็นแค่โฟลเดอร์เอกสารธรรมดา แต่ทำงานเป็น local Git repository พร้อมระบบเครื่องมือแบบ file-first เช่น typed facts, append-only log, brief ที่สังเคราะห์โดย LLM, /lookup, /lint
  • เซสชันเริ่มใหม่ทุกเทิร์น และจำกัดเครื่องมือแยกตามเอเจนต์ โดยผสาน โมเดลการทำงานแบบ push-driven กับ prompt cache เพื่อคง ปริมาณอินพุตให้แบนราบ ไม่ว่าเซสชันจะยาวแค่ไหน
  • เชื่อมต่อได้ถึง Telegram, OpenClaw, One CLI และ Composio เพื่อนำข้อความภายนอกและการรันแอ็กชันเข้ามา พร้อมยังคงรวม team memory และการทำงานร่วมกันของเอเจนต์ไว้ในที่เดียวบนพื้นฐาน โอเพนซอร์สแบบ self-hosting และการใช้ API key ของตนเอง

โครงสร้างหน่วยความจำและวิกิ

  • แยก notebook ของแต่ละเอเจนต์ ออกจาก wiki ส่วนกลางของทีม เพื่อจัดการบริบทงานส่วนตัวและความรู้ระดับองค์กรเป็นคนละชั้น
  • ใน notebook จะเก็บบริบทดิบที่ได้ระหว่างทำงาน การสังเกต และข้อสรุปชั่วคราว และออกแบบให้มีเพียงข้อมูลที่อยู่ได้นาน เช่น เพลย์บุ๊กที่ใช้ซ้ำ ข้อเท็จจริงที่ตรวจสอบแล้ว และความชอบที่ยืนยันแล้ว เท่านั้นที่ถูกยกระดับไปยัง wiki
  • ไม่มีข้อมูลใด ถูกยกระดับอัตโนมัติ โดยเอเจนต์ต้องเป็นผู้ตัดสินใจเองว่าจะย้ายรายการใดจาก notebook ไปยัง wiki
  • ใน wiki มีข้อมูลที่ชี้ว่าใครเป็นผู้บันทึกบริบทนั้นล่าสุด เพื่อให้เอเจนต์ตัวอื่นตัดสินใจได้ว่าจะ mention ใครอีกครั้ง
  • สำหรับการติดตั้งใหม่ markdown backend เป็นค่าเริ่มต้น ส่วนเวิร์กสเปซ Nex หรือ GBrain เดิมจะยังคงใช้ knowledge graph backend เดิม ต่อไป
  • หากเลือก backend เป็น none ระบบจะปิด wiki ส่วนกลาง แต่ notebook ในเครื่อง จะยังทำงานต่อ

วิธีทำงานของ markdown wiki

  • wiki เริ่มต้นไม่ได้เป็นเพียงโฟลเดอร์ Markdown แต่ทำงานเป็น team wiki บนพื้นฐาน local Git repository ที่พาธ ~/.wuphf/wiki/
  • ภายในมี typed facts ในรูป triplet, append-only fact log แยกตามเอนทิตี, brief ที่ LLM สังเคราะห์, /lookup แบบอ้างอิงแหล่งที่มา และ /lint สำหรับค้นหาความขัดแย้ง เอกสารกำพร้า ข้ออ้างที่ล้าสมัย และ cross-reference ที่เสีย
  • brief ที่ LLM สังเคราะห์จะถูก commit ภายใต้ตัวตน archivist และยังใช้ ระบบเครื่องมือแบบ file-first อย่าง cat, grep, git log, git clone ได้ตามเดิม
  • wiki เริ่มต้นนี้ใช้งานได้ โดยไม่ต้องมี API key
  • ในการตั้งชื่อภายในโค้ด notebook คือหน่วยความจำ private และ wiki คือหน่วยความจำ shared โดย backend markdown และ backend nex·gbrain ใช้ MCP tool surface คนละชุด
  • ชุดเครื่องมือของ backend markdown และชุดเครื่องมือแบบ legacy ของ nex·gbrain ไม่อยู่ร่วมกันใน server instance เดียวกัน
  • รายละเอียดเพิ่มเติมดูได้ที่ DESIGN-WIKI.md, docs/specs/WIKI-SCHEMA.md

โมเดลการทำงานและตัวเลือกการตั้งค่า

  • CLI ของเอเจนต์หลักคือ Claude Code และสามารถเลือก Codex CLI ได้ด้วย --provider codex
  • memory backend เลือกได้จาก nex, gbrain, none และ markdown ซึ่งเป็นค่าเริ่มต้น
  • ต่อให้ใช้ --no-nex ฟีเจอร์ การเชื่อมต่อภายในเครื่อง อย่าง Telegram ก็ยังทำงานต่อได้ และหลังรันสามารถใช้ /focus เพื่อกลับสู่โหมดมอบหมายเส้นทางแบบ CEO routing
  • เมื่อเลือก gbrain ระบบจะขอ OpenAI หรือ Anthropic key ในขั้นตอนออนบอร์ดแรกเริ่ม และหากต้องใช้ embedding และ vector search จะต้องใช้ OpenAI
  • role pack ที่มีให้คือ starter, founding-team, coding-team, lead-gen-agency, revops
  • สามารถปรับโมเดล การเปิดเบราว์เซอร์อัตโนมัติ พอร์ต และการตรวจสิทธิ์ ได้ผ่านแฟล็กอย่าง --opus-ceo, --no-open, --web-port, --unsafe
  • รีโพซิทอรีอยู่ในสถานะ pre-1.0 และ branch main อาจเปลี่ยนทุกวัน จึงแนะนำให้ตรึง release tag แทน main เมื่อต้องการ fork

การทำงานร่วมกันและการเชื่อมต่อภายนอก

  • รองรับ Telegram bridge โดยสามารถรัน /connect ในออฟฟิศ จากนั้นเลือก Telegram และใส่โทเค็น @BotFather เพื่อเชื่อมการไหลของข้อความแบบสองทางกับกลุ่มหรือ DM
  • เอเจนต์ OpenClaw ก็สามารถนำเข้ามาได้ด้วย /connect openclaw โดยใช้ gateway URL และ gateway.auth.token จาก ~/.openclaw/openclaw.json เพื่อ bridge เซสชัน
  • เซสชัน OpenClaw จะเข้ามาในออฟฟิศในฐานะ สมาชิกชั้นหนึ่ง ที่สามารถ @mention ได้ ขณะที่การรันจริงยังคงเกิดขึ้นใน sandbox ของแต่ละตัว
  • การยืนยันตัวตนของ OpenClaw gateway ใช้ คู่กุญแจ Ed25519 และเก็บคีย์ไว้ที่ ~/.wuphf/openclaw/identity.json ด้วยสิทธิ์ 0600
  • สำหรับการรันแอ็กชันภายนอก มีผู้ให้บริการในตัวสองแบบคือ One CLI และ Composio
  • One CLI ใช้ไบนารีภายในเครื่องเพื่อรันแอ็กชันบนเครื่องของผู้ใช้ จึงเหมาะกับโฟลว์ที่ ไม่ส่งข้อมูลรับรองไปยังบุคคลที่สาม
  • Composio ใช้โฟลว์ OAuth แบบโฮสต์ของ Composio เพื่อเชื่อมบัญชี SaaS อย่าง Gmail และ Slack

ตัวเลือกด้านการออกแบบและคุณลักษณะการปฏิบัติการ

  • เซสชันจะ เริ่มใหม่ทุกเทิร์น โดยเลือกโครงสร้างที่ไม่สะสมประวัติการสนทนา
  • เครื่องมือจะ จำกัดขอบเขตแยกตามเอเจนต์ โดยใน DM โหลดเพียง 4 MCP tools ส่วนทั้งออฟฟิศโหลด 27 tools
  • เอเจนต์จะตื่นขึ้นมาเฉพาะเมื่อ broker ส่งการแจ้งเตือนเข้ามาใน โมเดลแบบ push-driven จึงไม่ต้องมี heartbeat polling
  • ระหว่างทำงานก็ยังส่ง DM ไปยังเอเจนต์เฉพาะตัวเพื่อ ปรับกลางคันโดยไม่ต้องรีสตาร์ต ได้
  • สามารถ ผสม runtime ของ Claude Code, Codex และ OpenClaw ในช่องทางเดียวกัน ได้
  • หน่วยความจำรวมทั้ง notebook ของแต่ละเอเจนต์และ workspace wiki ไว้ด้วยกัน และยังเลือกใช้ หน่วยความจำแบบ knowledge graph ของ GBrain หรือ Nex ได้
  • ในด้านราคา โปรเจกต์ชูโมเดล โอเพนซอร์สฟรี ที่ผสาน MIT license, การ self-host และการใช้ API key ของตัวเอง
  • จากการวัดเซสชัน CEO แบบ 10 เทิร์นบน Codex พบว่า input token คงที่ราว 87k ต่อเทิร์น
  • token ที่ถูกคิดค่าบริการหลังแคชอยู่ที่ราว 40k ต่อเทิร์น และรวม 10 เทิร์นอยู่ที่ราว 286k
  • ตามเกณฑ์ prompt cache ของ Claude API มี cache hit rate 97% และค่าใช้จ่ายของ Claude Code 5 เทิร์นระบุไว้ที่ $0.06
  • ขณะที่ cumulative session orchestrator มีอินพุตต่อเทิร์นเพิ่มจาก 124k เป็น 484k ในเซสชันเดียวกัน WUPHF ยังคงรักษา ปริมาณอินพุตที่แบนราบโดยไม่ขึ้นกับความยาวเซสชัน
  • ระบุว่าความต่างนี้วัดได้เป็น 7 เท่าเมื่อดูที่ 8 เทิร์น
  • คุณลักษณะนี้สอดคล้องกับ fresh session, prompt caching ที่อิง prefix เดียวกัน, จำนวนเครื่องมือที่น้อยในโหมด DM และโครงสร้างการปลุกแบบ push-driven ที่ไม่มี heartbeat
  • สคริปต์สำหรับทำซ้ำผลคือ wuphf --pack starter & แล้วตามด้วย ./scripts/benchmark.sh และตัวเลขทั้งหมดเป็น ค่าที่วัดจริงในเครื่องและคีย์ของผู้ใช้

สถานะการพัฒนาและกระบวนการตรวจสอบ

  • ใน README ของแต่ละหัวข้อหลักมี ตาราง claim status ที่ลิงก์ไปยังพาธโค้ดโดยตรง เพื่อแยกว่าฟีเจอร์ไหน shipped แล้วหรือยังเป็น partial
  • ระบุว่า default CEO เป็น Sonnet และอัปเกรดได้ด้วย --opus-ceo รวมถึง collaborative mode ค่าเริ่มต้น, การสลับด้วย /focus, per-agent MCP scoping, fresh session, push-driven wake, workspace isolation, Telegram bridge, ผู้ให้บริการแอ็กชัน 2 แบบ, OpenClaw bridge, wuphf import, และค่าเริ่มต้น --memory-backend markdown ล้วนเป็น shipped
  • live web agent streaming ถูกระบุเป็น partial ส่วน prebuilt binary บนพื้นฐาน goreleaser อยู่ในสถานะ config ready
  • การกู้คืนงานที่กำลังทำอยู่เมื่อรีสตาร์ต ถูกระบุว่า shipped ใน v0.0.2.0
  • LLM Wiki ถูกทำเครื่องหมายว่า shipped ในฐานะ git-native team memory พร้อม UI สไตล์ Wikipedia และชี้ตำแหน่ง implementation ที่ internal/team/wiki_git.go, internal/team/wiki_worker.go, web/src/components/wiki/, DESIGN-WIKI.md
  • หาก claim กับ status ขัดแย้งกัน ให้ยึด โค้ดเป็นหลัก และหากพบปัญหาให้เปิด issue

เอกสารประเมินและเดโม

  • มี fork-or-skip prompt สำหรับประเมินรีโพซิทอรีด้วยผู้ช่วยเขียนโค้ด AI ก่อน fork โดยกำหนดให้ตอบโดยไม่มีภาษาการตลาด พร้อมพาธไฟล์ หมายเลขบรรทัด และคำตัดสิน ภายใน 500 คำ
  • ระบุว่า prompt นี้ถูกใช้งานภายในด้วยเช่นกันก่อน release
  • มีเทอร์มินัลเดโม 5 นาทีที่แสดงการเขียน wiki จริงผ่าน ./scripts/demo-entity-synthesis.sh
  • ในเดโมนี้ เอเจนต์จะบันทึกข้อเท็จจริง 5 ข้อ จากนั้น threshold สำหรับการสังเคราะห์จะทำงาน แล้ว broker จะเรียก local LLM CLI และผลลัพธ์จะถูก commit ลง Git repository ใต้ตัวตน archivist โดยห่วงโซ่การเขียนทั้งหมดจะปรากฏใน git log
  • ข้อกำหนดของเดโมคือ curl, python3, broker ที่กำลังรันด้วย --memory-backend markdown และ LLM CLI ที่รองรับใน PATH ซึ่งเป็นหนึ่งใน claude·codex·openclaw

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 일 전
ความคิดเห็นจาก Hacker News

  • ยังไม่ค่อยเข้าใจประเด็นของ การทำโน้ตอัตโนมัติ เท่าไร แต่ก่อนก็เคยมีวิธีคัดลอกข้อความแล้วแปะลงโน้ต ซึ่งไม่ได้ช่วยอะไรเลย แล้วพอเพิ่มสิ่งนั้นขึ้น 100 เท่า มันจะต่างออกไปจริงหรือ
    สำหรับฉัน แก่นของการจดโน้ตคือการอ่านแหล่งข้อมูลอย่างมีวิจารณญาณ ย่อยให้เข้ากับ mental model ของตัวเอง แล้วจึงบันทึกมันไว้
    รายละเอียดค่อยกลับไปค้นทีหลังได้ สุดท้ายสิ่งสำคัญคือกระบวนการขัดเกลาโมเดลนั้น

    • ดูเหมือนว่านี่จะมากกว่าแค่ การจดโน้ต ธรรมดา จริง ๆ แล้วมันใกล้เคียงกับฮาร์เนสอีกแบบหนึ่งสำหรับประสานงานการทำงานระหว่างเอเจนต์ โดยลดการแทรกแซงของมนุษย์ให้น้อยที่สุด
      ถ้าอย่างนั้น เป้าหมายอาจเป็นการโยนงานให้ LLM brain ที่ใช้ร่วมกัน แทนที่จะสร้าง mental model นั้นด้วยตัวเองก็ได้
      แต่ก็ยังน่าสงสัยมากว่าแนวทางแบบนี้จะสร้างอะไรที่มีคุณค่าจริงต่อเจ้าของผลิตภัณฑ์ได้หรือไม่ ถ้าสินค้าที่มีคุณค่าเกิดจากแค่พรอมป์ต์กับ agent harness ได้ ใคร ๆ ก็ทำซ้ำได้ การพัฒนาผลิตภัณฑ์เองก็จะกลายเป็น commodity และสุดท้ายสิ่งที่เหลือมูลค่าอาจมีแค่ token
      สมมติฐานของฉันคือแนวคิดของ Paul Graham เรื่อง do things that don’t scale จะยังใช้ได้ต่อไป เพียงแต่เนื้อหาของ งานที่ขยายสเกลไม่ได้ อาจเปลี่ยนไปมาก
      ถึงอย่างนั้น ช่วงนี้ฉันก็เพิ่งเริ่มใช้ Obsidian อย่างจริงจัง พอตั้งสกิลสำหรับจดโน้ต ค้นคว้า เชื่อมลิงก์ แยกย่อย และจัดโครงสร้างฐานความรู้ใหม่ไว้แล้ว ก็รู้สึกเหมือนมี ผู้ช่วยดิจิทัล มาคอยจัดระเบียบแทน
      ตอนนี้แค่จดความคิดกระจัดกระจายลงไป เอเจนต์ก็ช่วยจัดโครงสร้าง ตั้งคำถามต่อยอด และเชื่อมกับงานอื่นให้เอง ส่วนการอ่านแหล่งข้อมูลและสร้าง mental model ยังเป็นหน้าที่ของฉันอยู่ แต่โน้ตคุณภาพดีแทบจะได้มาแบบฟรี ๆ
    • ผมมองว่าปัญหาใหญ่คือผู้คนกำลังสร้าง งานจุกจิก จำนวนมหาศาลด้วย AI แล้วก็ไม่เคยกลับไปดูมันอีกเลย
      เป็นความสิ้นเปลืองมาก
    • เรื่องการจดโน้ตนี่เห็นด้วยเต็มที่ ผู้คนปฏิบัติกับโน้ตแบบเบาเกินไป สุดท้ายก็สะสมเกินจำเป็นเหมือนห้องใต้หลังคาหรือห้องใต้ดิน
      ของส่วนใหญ่แต่แรกก็ไม่จำเป็นต้องเข้าไปอยู่ในโน้ตอยู่แล้ว และ LLM ก็เพิ่ม noise มากเกินไปโดยแทบไม่มีการตรวจสอบหรือกรองเลย
      มีวิดีโอที่พูดถึงประเด็นนี้ได้ดี เป็นบทความของ JA Westenberg
      https://youtube.com/watch?v=3E00ZNdFbEk
    • จากงานวิจัยทางวิทยาศาสตร์จำนวนน้อยที่ออกมาจนถึงตอนนี้ บอกว่าเมื่อปล่อยให้ markdown collection แบบนี้ถูกดูแลโดย LLM ทั้งหมด คุณภาพผลลัพธ์กลับแย่ลง แต่ถ้าให้คนดูแลจะดีขึ้น
      ค่อนข้างน่าสนใจ
      ฉันคิดว่าจุดที่เหมาะที่สุดคือ การคัดสรรโดยมนุษย์ และถ้าไม่บริหาร debt หรือ drift อย่างตั้งใจ การปล่อยให้เดินเองแบบไม่มีผู้กำกับก็คงไม่ใช่คำตอบ
    • ตอนแรกฉันก็นึกว่านี่เป็นงานล้อเลียน
      ยิ่งชื่อดันไปเหมือน ผลิตภัณฑ์ไร้ประโยชน์และซ้ำซ้อน อย่าง Wuphf.com ที่เคยโผล่ใน The Office ด้วย ก็ยิ่งทำให้นึกแบบนั้น

  • แค่ใส่คำว่า AI ในชื่อผลิตภัณฑ์ก็เหมือนจะได้เงินระดับหลายพันล้านดอลลาร์ และแค่ใส่ชื่อ Karpathy ลงในบล็อกโพสต์ก็ดูเหมือนจะได้งานเป็นวิศวกรหลักของ Anthropic
    มันดูเหมือนมีแต่การรีดเงินจากกระแสตราบเท่าที่ยังฮิตอยู่ โดยไม่ค่อยสนใจว่าลูกค้าต้องการอะไร
    ทุกคนกำลังแห่กันเข้าไปแบบขอแค่ได้ฉวยโอกาสตอนมีคลื่นก็ยังดี

    • เหมือนกับ NFT, ก่อนหน้านั้นก็ blockchain, และในบางแง่ก็คล้ายกระแส Web 2.0
      แต่ตอนนั้นอย่างน้อยก็มีคนสร้างของจริง และสภาพเงินทุนที่ตึงกว่าก็ช่วยกดความร้อนแรงลงได้บ้าง
      กระแส LLM รอบนี้อย่างน้อยก็มีความเป็นไปได้และคุณค่าจริงอยู่พอสมควร แถมยังเป็นเทคโนโลยีที่สนุกดีในการเรียนรู้และลองใช้งาน
      ฉันยอมรับมานานแล้วว่าถ้าเงินไหลเข้าที่ไหน และมันไม่ได้ผิดจริยธรรม การคว้าโอกาสตรงนั้นก็นับว่าสมเหตุสมผล ระหว่างที่เงิน VC/PE ยังล้นอยู่ ก็อาจสร้างของเจ๋ง ๆ ที่มีคุณค่าได้
    • ถ้าทำได้ก็พอไม่ใช่หรือ ทุกคนต่างก็มีเหตุผลที่สร้าง เครื่องมือ AI และพวกเราก็ซื้อใช้มันกันจริง ๆ
      ฉันยังรอ CLI harness ระดับโลกที่จะมาแทน Claude Code อยู่ ต้องการอะไรสักอย่างที่แก้ปัญหาเรื่อง memory และการออกแบบได้
      งานเว็บดีไซน์ยังแทบเป็นฝันร้ายถ้าจะทำด้วย LLM
    • ปีที่แล้วผมทำ AI-native CRM ที่มี Dharmesh Shah ผู้ก่อตั้ง HubSpot สนับสนุนอยู่แล้ว มีรายได้จริง และหลังจากเปลี่ยนทิศทางซ้ำหลายครั้งก็สรุปได้ว่า context graph infra น่าจะเป็นคูเมืองป้องกันธุรกิจที่ใช่
      เราทำ PoC ระดับองค์กรด้วย และทั้งหมดนั้นสุดท้ายก็ควบแน่นมาเป็นโปรเจ็กต์นี้ที่ทำขึ้นข้าง ๆ เพื่อช่วยงานส่วนตัวของผมเอง ผลคือ context infra ที่ใช้งานจริงได้สะดวกก็คือสิ่งนี้นี่เอง
      ผมไม่ได้สนใจตำแหน่งวิศวกรหลักของ Anthropic ก่อนหน้านี้ผมเป็น Product Manager ที่ HubSpot และรายได้ก็ดีกว่าตอนนี้มาก แถมอีกหลายปีข้างหน้าก็อาจยังหาไม่ได้เท่าระดับนั้น
      ที่เดิมพันหลายครั้งและปรับแก้ไปเรื่อย ๆ ก็เพราะได้คุยกับลูกค้าโดยตรงแล้วปล่อยให้มันวิวัฒน์ตามนั้น ขณะที่คู่แข่งเก่า ๆ ยังทำ AI CRM แบบ stealth กันอยู่
      ในฐานะคนที่อยู่ในวงการมานาน ผมมองว่าตัวคลื่นไม่สำคัญเท่าไร แต่ใต้คลื่นนั้นมี คุณค่าที่จับต้องได้ ให้เก็บขึ้นมาแน่นอน

  • ผมเห็นรีวิวนี้มา: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
    นี่เป็น LLM wiki ตัวที่สามในรอบ 24 ชั่วโมงที่ขึ้นหน้าแรก แปลว่าเป็นหัวข้อที่ร้อนแรงจริง
    ผมเองก็มีส่วนได้ส่วนเสียในด้านนี้ เลยไม่ได้เป็นกลางเต็มร้อย แต่ก็เคยแยกเขียนไว้ว่าคาดหวังอะไรจากระบบแบบนี้บ้าง
    https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    ทุกคนต่างสร้างระบบของตัวเองใหม่หมด ดูจะลงทุนซ้ำซ้อนกันมากเกินไป เลยหวังว่าจะมีทางให้ร่วมมือกันได้บ้าง

    • โน้ตน่าสนใจมากทีเดียว
      แต่พอดูจากสำนวนแล้วเห็นได้ชัดว่า LLM เป็นคนเขียน เลยสงสัยว่าเวลาทำ design note แบบนี้ คุณกลับมาเรียบเรียงใหม่เป็นคำของตัวเองทีหลังเพื่อเช็กไหมว่ามันสะท้อนความคิดของคุณจริง ๆ
    • ผมชอบส่วน Borrowable Ideas เป็นพิเศษ และหวังว่าจะมีการหยิบไปใช้กันเยอะ ๆ
      เราเริ่มจากการเป็นบริษัท context infra ชื่อ nex.ai มาตั้งนานก่อนที่ Karpathy จะโยนไอเดีย LLM wiki ออกมาเสียอีก ฟีเจอร์เหล่านั้นยังแทบไม่แสดงใน WUPHF แต่ตอนนี้กำลังค่อย ๆ เปิดออกมา
      ข้อกังวลหลายอย่างที่เขียนไว้ในบทความเปรียบเทียบ เป็นสิ่งที่เราจัดการมาก่อนแล้วใน context infra ที่สร้างไว้ จึงรู้สึกดีที่ได้เห็นมัน
      ถึงอย่างนั้น การลดความซ้ำซ้อนและร่วมมือแบ่งปันสิ่งที่แต่ละฝ่ายเรียนรู้กันก็ยินดีอย่างมาก
    • พวก slot machine เชิงกำเนิดเหล่านี้มีด้านที่ทำให้คนแยกตัวจากกันจริง
      คุณบอกว่าอยากให้มีโอกาสร่วมมือกัน ฟังดูเหมือนตอนนี้ยังไม่มีโอกาสแบบนั้นอยู่ เลยรู้สึกแปลกนิดหน่อย
    • ไว้จะลองอ่านดู
    • พูดตามตรง ผมว่าตอนนี้มันเข้าสู่ช่วง ลงมือทำเองแล้วได้ของ ไปแล้ว
      แค่เอา QMD ไปวางบน Obsidian vault ก็น่าจะได้สัก 80% แล้ว และคงใช้เวลาไม่ถึง 2 ชั่วโมงด้วยซ้ำ

  • เผื่อเอาไว้เป็นบริบท มีลิงก์ต้นฉบับของ Karpathy ด้วย
    https://x.com/karpathy/status/2039805659525644595
    https://xcancel.com/karpathy/status/2039805659525644595

  • สงสัยว่า AI Notes จะเพิ่มคุณค่าหรือแค่สร้าง noise เพิ่มขึ้นกันแน่
    แต่ก็ชอบ สไตล์ ASCII ของเว็บไซต์พอสมควร

  • อยากให้มีใครสักคนทำอะไรแนว StackOverflow revival ขึ้นมาเพื่อแก้ปัญหานี้
    ให้มนุษย์เป็นคนคัดสรร แต่ถ้า LLM ส่วนรวมแก้ปัญหาแล้วติดขัด ก็ย้อนกลับไปโพสต์คำถามแบบสมัยก่อนใน กราฟความรู้แบบกระจายศูนย์
    ถ้าเอเจนต์ของฉันจะพูดว่า "ผมติดตรงนี้และได้โพสต์คำถามไว้ใน SO แล้ว งั้นเดี๋ยวค่อยกลับมาดูอีกทีเมื่อมีคำตอบ" ก็ดูโอเคมาก

  • สงสัยว่าจะทำอย่างไรไม่ให้ LLM เขียนมากเกินไป
    ผมเคยสร้างเครื่องมือและระบบคล้าย ๆ กันมาหลายตัว ทุกตัวลงเอยด้วยการที่ LLM ขยายเอกสารไปเรื่อย ๆ จนทั้งระบบเละ และยิ่งใหญ่ก็ยิ่งใช้งานน้อยลง
    การทดลองหนึ่งที่เคยทำคือให้ลิงก์ไม่กี่อันแก่ LLM แล้วให้มันไปค้นหัวข้อที่เกี่ยวข้อง สร้าง knowledge wiki ของตัวเองขึ้นมา พร้อมสรุป ลิงก์ข้ามหน้า และที่มาในแต่ละหน้า
    ภายนอกดูเหมือนดี แต่พออ่านข้อมูลจริงแล้วไม่ค่อยดีเท่าไร
    มันเป็นการทดลองเมื่อหลายปีก่อน ตอนนี้อาจคุ้มที่จะลองใหม่ด้วยอะไรอย่าง opus 4.7 ก็ได้

  • ขอตั้งข้อสังเกตว่าในชุมชน TiddlyWiki เองก็สำรวจเครื่องมือ AI กันมาตามธรรมชาติ
    TiddlyWiki เป็นวิกิแบบไฟล์ HTML เดี่ยวที่แก้ไขตัวเองได้ และมีมานานกว่า 20 ปีแล้ว
    มันอาจไม่ได้พัฒนาไปถึงสภาพแวดล้อมแบบ agentic โดยตรง แต่ก็มี markdown plugin และมีเครื่องมือที่ทำให้ไฟล์รันได้หรือแปลงเป็นเว็บแอปแบบ self-serving ได้ ส่วน Git ค่อนข้างจุกจิกหน่อย
    เพราะงั้นในทางทฤษฎี วิกิ agentic แบบไฟล์เดี่ยวที่เดินทางไปไหนมาไหนและแก้ไขตัวเองก็เป็นไปได้
    https://tiddlywiki.com/

    • เผื่อไว้เป็นข้อมูล คนที่สร้าง TiddlyWiki คนแรกก็คือผมเอง
      โครงแบบ single-file ที่คุณพูดถึงมีตัวเชื่อมต่อ LLM อยู่แล้วหลายตัว เช่น https://github.com/rimir-cc/tw-llm-connect
      เสน่ห์ของมันก็อยู่ตรงนั้นเลย ไม่มี dependency ไม่ต้องติดตั้ง และเก็บรักษาได้ง่ายมาก ดังนั้นการตั้งค่าวิกิ agentic แบบไฟล์เดี่ยวให้แก้ไขตัวเองได้นั้นทำได้เลยตั้งแต่วันนี้
      ส่วนที่ใกล้กับ แพตเทิร์น LLM Wiki ของ Karpathy มากขึ้นคือ twillm ที่ผมกำลังทำอยู่
      https://github.com/Jermolene/twillm
      มันใช้การตั้งค่า Node.js ของ TiddlyWiki และเก็บ tiddler เป็นไฟล์แยก จึงชี้ไปที่ Markdown vault เดิมได้ตรง ๆ และใช้ร่วมกับเครื่องมืออย่าง Claude Code ได้
      ข้อดีของ TiddlyWiki ก็ชัดเจนพอสมควร เป็นโอเพนซอร์สจึงใช้งานได้ต่อเนื่องในระยะยาว และเพราะเป็นเว็บเบสจึงเข้าถึงได้จากทุกที่
      อีกอย่างคือ computed view ทำหน้าที่แทน materialized index file ได้ วิธีของ Karpathy ต้องให้ LLM ซิงก์ index.md ตลอดทุกครั้งที่เพิ่มโน้ต ซึ่งเป็นงานที่ stale ได้ง่ายเมื่อข้ามหลายเซสชัน และเป็นสิ่งที่ LLM ทำได้ไม่ดีเป็นพิเศษ
      แต่ view ของ TiddlyWiki เป็นนิพจน์ filter แบบเรียลไทม์ ดังนั้นผลลัพธ์อย่างเช่น "เรียง tiddler ที่ติดแท็ก concept ตาม rating" จะถูกคำนวณสดทันทีตอนเรนเดอร์
      Frontmatter ก็กลายเป็นโครงสร้างที่ query ได้เช่นกัน Obsidian จะแสดง YAML frontmatter เป็นกล่อง metadata ที่ด้านบนของโน้ต แต่ TiddlyWiki ยกระดับฟิลด์เหล่านั้นให้เป็นฟิลด์ของ tiddler ชั้นหนึ่งที่เอาไปใช้กรอง เรียงลำดับ และรวมสถิติได้ทันที
      และ LLM ยังเขียนได้ไม่ใช่แค่เนื้อหา แต่รวมถึง แอปเพล็ต เล็ก ๆ ด้วย นอกจาก Markdown note แล้ว ยังใส่ wikitext tiddler (.tid) เพื่อสร้าง live view แบบโต้ตอบได้ เช่น dashboard, เครื่องมือสำรวจแท็ก, ดัชนี journal หรือ glossary

  • วงการ self building artefacts น่าสนใจ และตอนนี้กำลังโตมากเพราะ LLM โดยเฉพาะโมเดลสายโค้ด เก่งขึ้นด้านนี้อย่างรวดเร็ว
    ช่วงหลังผมเองก็ทดลองโปรเจ็กต์ที่เน้นลด dependency ให้เหลือน้อยที่สุด และควบคุมเอเจนต์บนเครื่องโลคัล
    https://github.com/GistNoesis/Shoggoth.db/
    มันสร้างและจัดระเบียบ ฐานข้อมูล sqlite ด้วยตัวเองเพื่อทำงานระยะยาวตามพรอมป์ต์ โดยใช้สำเนา Wikipedia ในเครื่องเป็นข้อมูลต้นทาง
    ผมยังใส่ฮาร์เนสและเครื่องมือสำหรับทดลอง agent drift ไว้อย่างน้อยที่สุดเท่าที่จำเป็น
    การต่อเครื่องมือประมวลผลภาพเข้าไปก็ทำได้ค่อนข้างง่าย แค่เข้ารหัสภาพเป็น base64 แล้วส่งให้ llama.cpp ส่วนรายละเอียดก็ใช้ local LLM ทำ vibecoding คร่าว ๆ เอาได้
    ผมมองว่ามันเป็นเครื่องมือที่มีประโยชน์ค่อนข้างกว้าง
    ตัวอย่างเช่น เมื่อก่อนผมมีสคริปต์ที่ใช้ Amazon Textract เพื่อดึงยอดเงิน วันที่ และผู้ขายออกจากใบแจ้งหนี้กับใบเสร็จในโฟลเดอร์ แล้วให้คนตรวจเลขอีกทีเพื่อทำ CSV ส่งให้นักบัญชี
    ตอนนี้สามารถแทนที่การเรียก Amazon Textract นั้นด้วยการเรียกโมเดล llama.cpp ที่มีพรอมป์ต์เหมาะสมได้ และยังคงใช้เครื่องมือจัดการใบแจ้งหนี้เดิมต่อไป พร้อมเพิ่มความยืดหยุ่นด้านงานบัญชีได้สร้างสรรค์ขึ้นมาก
    ผมยังทดลองดัดแปลงมันให้ขยับหุ่นยนต์จริงจากลำดับภาพจากกล้องด้วย ซึ่งในกรณีง่าย ๆ มันก็เคลื่อนที่และไปถึงเป้าหมายได้จริง
    แต่ LLM ที่ผมใช้ไม่ได้ถูกฝึกมาสำหรับบังคับหุ่นยนต์ตั้งแต่แรก และใช้เวลา 10 วินาที ในการเลือกแอ็กชันถัดไป จึงยังไม่ใช้งานได้จริง ขณะที่คอนโทรลเลอร์แบบดั้งเดิมที่ไม่ใช่ดีปเลิร์นนิงในปัจจุบันรัน vision loop ที่ 20Hz

  • โมเดล LLM และเอเจนต์ที่อยู่บนมันไม่ได้เป็นแบบกำหนดตายตัว แต่เป็นเชิงความน่าจะเป็น
    มันทำบางอย่างสำเร็จได้ในอัตราหนึ่ง แต่ไม่ใช่ทุกครั้ง
    ดังนั้นยิ่งให้งานของเอเจนต์ลากยาวเท่าไร ความน่าจะเป็นที่จะล้มเหลวก็ยิ่งเพิ่มขึ้น เอเจนต์ที่รันยาวแบบนี้สุดท้ายจะล้มเหลว และยังเผาค่า token ไปมหาศาลระหว่างทางด้วย
    หนึ่งในสิ่งที่เอเจนต์ LLM ทำได้ดีคือการเขียน คำสั่งของตัวเอง ใหม่
    เคล็ดลับคือจำกัดเวลาและจำนวนขั้นการคิดของโมเดลประเภท thinking จากนั้นค่อยประเมิน อัปเดต แล้วรันใหม่
    ถ้าเปรียบเทียบง่าย ๆ ก็เหมือนเอเจนต์นั้นล้มได้ อย่าปล่อยให้มันวิ่งนานจนล้ม ความหมายคือ 5 นาทีสองครั้ง ดีกว่า 10 นาทีครั้งเดียว
    อีกไม่กี่สัปดาห์ เอเจนต์แบบ self-referential พวกนี้คงขึ้นไปเต็มด้านบนของฟีด Twitter กันหมด

    • เอเจนต์กับ ML ยังมีปัญหาติดอยู่ที่ local maxima ถ้าไม่มี feedback จากภายนอก
      เพราะงั้นวิกิแบบนี้พอถึงสถานะหนึ่งแล้วก็มีแนวโน้มจะหยุดนิ่งอยู่ตรงนั้น