LightVela

คุณสามารถเปลี่ยน Hermes สมองของตัวแทนได้หรือไม่? ชั้นของโมเดล vs ชั้นของตัวแทน

สรุป

'สมอง' ของเอเจนต์ Hermes สามารถถูกแทนที่ได้ แต่สิ่งที่ถูกแทนที่มีเพียงชั้นของโมเดล ไม่ใช่เอเจนต์ทั้งหมด ชั้นของโมเดลจะเป็นตัวตัดสินวิธีคิดในครั้งนี้ — การวิเคราะห์คำขอ, การวางแผนขั้นตอน, การเลือกเครื่องมือที่จะเรียกใช้, และการร่างคำตอบ ชั้นเอเจนต์จะคงการคิดนั้นไว้ต่อเนื่องตลอดเวลา: ตัวตน (SOUL.md), โปรไฟล์ผู้ใช้ (USER.md), ข้อเท็จจริงข้ามเซสชัน (MEMORY.md และ memories/), วิธีที่บันทึกไว้ (skills/), ช่องทางการส่งข้อความ, งานที่กำหนดเวลาไว้, และไดเรกทอรีการทำงาน ทั้งหมดนี้อยู่นอกโมเดล นั่นเป็นเหตุผลว่าทำไมการสลับโมเดลจึงไม่ทำให้ข้อมูลเหล่านี้ถูกลบ ใน LightVela หนึ่งเอเจนต์จะใช้โมเดลหนึ่งตัวในแต่ละครั้งและการสลับโมเดลจะไม่ลบหน่วยความจำ, ไฟล์ในคลาวด์, ทักษะ, หรือการตั้งค่างานที่กำหนดเวลา — มันเพียงแค่เปลี่ยนเครื่องยนต์เบื้องหลังการตอบในอนาคต หากเอเจนต์รู้สึกเหมือนเป็นคนแปลกหน้าหลังการสลับ โมสาเหตุเกือบทั้งหมดมาจากการปฏิบัติตามคำสั่ง, การบีบอัดบริบท, และพฤติกรรมการร่างคำตอบที่ต่างออกไปในโมเดลใหม่ ไม่ใช่หน่วยความจำที่หายไป.


ทำไมคำถามนี้ถึงเกิดขึ้นบ่อย

“ฉันสามารถย้าย Agent ของฉันไปยังโมเดลที่ทรงพลังมากขึ้นได้ไหม?” เป็นหนึ่งในคำถามที่พบบ่อยที่สุดที่ผู้คนถามเกี่ยวกับผลิตภัณฑ์ Agent คำถามต่อมาทันทีคือ: “มันยังจำฉันได้อยู่ไหม?”

การถามทั้งสองพร้อมกันเผยให้เห็นความเข้าใจผิดที่แพร่หลาย — ว่าโมเดลและเอเจนต์คือสิ่งเดียวกัน ในโมเดลทางจิตนั้น เอเจนต์เป็นเพียงอินเทอร์เฟซแชทที่ห่อรอบ LLM ดังนั้น การแทนที่โมเดลหมายถึงการแทนที่ผู้ช่วยทั้งหมด และการเริ่มต้นใหม่ดูเหมือนหลีกเลี่ยงไม่ได้

ถ้านั่นเป็นความจริงจริงๆ ไม่มีเอเจนต์ใดเลยที่จะสามารถสร้างคุณค่าในระยะยาวได้ บริบทของโครงการที่คุณอธิบายเมื่อสัปดาห์ที่แล้ว น้ำเสียงที่คุณปรับอย่างระมัดระวัง กระบวนการทำงานที่คุณจับภาพ — ทุกอย่างจะถูกรีเซ็ตทุกครั้งที่มีการอัปเกรดทางเทคนิค นั่นไม่ใช่ผลิตภัณฑ์ที่ใครสามารถพึ่งพาได้

Hermes เอเจนต์ถูกสร้างขึ้นบนสมมติฐานตรงข้าม: โมเดลเป็นส่วนประกอบที่สามารถเปลี่ยนได้ และเอเจนต์คือตัวสิ่งที่คงอยู่ บทความนี้จะอธิบายว่าในทางปฏิบัติแล้วหมายความว่าอย่างไร


1. แยกสามสิ่งออกมาก่อน: โมเดล รันไทม์ และสินทรัพย์ระยะยาว

ก่อนที่จะพูดถึงการสลับโมเดล จะเป็นประโยชน์ที่จะเข้าใจว่าเอเจนต์ประกอบด้วยอย่างน้อยสามชั้นที่มีวัฏจักรชีวิตต่างกันอย่างมาก

ชั้นคืออะไรวงจรชีวิตเมื่อเปลี่ยนโมเดล
ชั้นโมเดลLLM ที่ให้เหตุผลและการสร้างปรับค่าได้ สามารถเปลี่ยนได้ตลอดเวลาถูกแทนที่
เวลารันเอเจนต์กระบวนการที่รันเครื่องมือ ช่องทาง I/O และการจัดตารางรันระยะยาวไม่เปลี่ยนแปลง
สินทรัพย์ระยะยาวSOUL.md, USER.md, MEMORY.md, memories/, skills/, ไฟล์ในไดเรกทอรีทำงานสะสมตามเวลาไม่เปลี่ยนแปลง

คนส่วนใหญ่มักเห็นเพียงชั้นแรกและหน้าต่างแชท โดยพลาดชั้น runtime ตรงกลางและชั้นสินทรัพย์ด้านล่าง อย่างไรก็ตามสองชั้นล่างนี้เองที่ทำให้ Agent เป็นที่จดจำว่า "เป็นตัวเดิม" ในช่วงหลายเดือนของการใช้งาน

อุปมาอุปไมยที่มีประโยชน์: โมเดลคือวิธีที่คนหนึ่งคิดในตอนนี้, runtime คือร่างกายและมือของคนนั้น, และสินทรัพย์ระยะยาวคือเอกลักษณ์ ความทรงจำ และนิสัยทางวิชาชีพ การเปลี่ยนวิธีที่ใครสักคนคิดไม่ได้ทำให้พวกเขาเป็นคนอื่น เพราะเอกลักษณ์และความทรงจำไม่ได้เปลี่ยนไปตามนั้น


2. ชั้นโมเดล: รับผิดชอบในเรื่อง "จะคิดอย่างไรครั้งนี้"

ภายในหนึ่งการแลกเปลี่ยน ชั้นของโมเดลทำมากกว่าการสร้างข้อความ มันตัดสินใจอย่างน้อยสี่สิ่ง:

  1. การตีความ — แปลงข้อความของคุณให้เป็นเป้าหมายที่ชัดเจน รวมถึงข้อจำกัดที่คุณบอกเป็นนัยแต่ไม่ได้พูดออกมา
  2. การวางแผน — ประเมินจำนวนขั้นตอนที่งานต้องใช้ ขั้นตอนใดมาก่อน และว่าจำเป็นต้องทำการค้นคว้าก่อนลงมือทำหรือไม่
  3. การตัดสินใจเรียกใช้เครื่องมือ — ตัดสินใจว่าจะอ่านไฟล์ ค้นหาเว็บ หรือรันคำสั่ง และใช้พารามิเตอร์ใด
  4. การแสดงออก — จัดระเบียบผลลัพธ์ให้อ่านเข้าใจง่าย รวมถึงกำหนดระดับรายละเอียดที่จะใส่และรูปแบบที่จะใช้

ทั้งสี่อย่างนี้เป็นส่วนหนึ่งของการประมวลผลอนุมาน นี้ พวกมันสร้างประสบการณ์โดยตรงให้กับคุณทันที ซึ่งเป็นสาเหตุที่การสลับโมเดลทำให้รู้สึกถึงการเปลี่ยนแปลงได้ชัดเจน

สิ่งที่สำคัญไม่แพ้กันคือสิ่งที่ชั้นโมเดลไม่ได้เป็นเจ้าของ:

  • โมเดลไม่ใช่ฐานข้อมูลของคุณ มันไม่เก็บความชอบของคุณ สถานะโครงการ หรือข้อสรุปในอดีตของคุณ
  • โมเดลไม่ใช่ตัวจัดกำหนดการ มันไม่รู้ว่าสิ่งใดต้องทำทุกเช้าเวลาเจ็ดโมง
  • โมเดลไม่ใช่ตัวจัดการช่องทาง มันไม่ตัดสินใจว่าการตอบกลับใดจะกลับไปยังการสนทนา Telegram

ความสามารถทั้งหมดเหล่านั้นอยู่ภายนอกโมเดล นั่นคือพื้นฐานทางเทคนิคสำหรับ "การสลับโมเดลไม่ใช่การสลับเอเยนต์"


3. ชั้นเอเจนต์: รับผิดชอบในการทำให้การคิดต่อเนื่อง

ความรับผิดชอบของชั้นเอเจนต์แบ่งออกเป็นห้ากลุ่ม จัดตามปัญหาที่แต่ละกลุ่มแก้ไข

3.1 เอกลักษณ์และกฎพฤติกรรม: SOUL.md

SOUL.md กำหนดว่าเอเจนต์นี้คือใคร ทำงานในโทนใด วิธีการจัดลำดับความสำคัญ และสิ่งที่มันจะไม่ทำ มันเป็นชุดกฎที่คงที่ ไม่ใช่อารมณ์ที่แต่งขึ้นตามการสนทนาแต่ละครั้ง

หลังจากเปลี่ยนโมเดล, SOUL.md ยังคงอยู่ในตำแหน่งเดิมพอดี โมเดลใหม่อ่านและใช้กฎเดียวกัน — อาจปฏิบัติตามกฎเหล่านั้นอย่างหลวมหรือเข้มงวดมากขึ้น แต่กฎเองไม่ได้เปลี่ยนแปลง ความแตกต่างนี้คือกุญแจสำคัญในการเข้าใจส่วน 'รู้สึกต่างไป' ต่อมา

3.2 โปรไฟล์ผู้ใช้: USER.md

USER.md เก็บข้อมูลที่มั่นคงเกี่ยวกับคุณ: นิสัยการใช้ภาษา จังหวะการสื่อสารที่ชื่นชอบ เครื่องมือที่คุณใช้เป็นประจำ สิ่งที่ชัดเจนว่าต้องหลีกเลี่ยง มันช่วยป้องกันไม่ให้เอเจนต์ถามว่า "คุณต้องการเวอร์ชันยาวหรือตัวสั้น" ทุกครั้ง

3.3 ข้อเท็จจริงข้ามเซสชัน: MEMORY.md และ memories/

ชั้นนี้จัดเก็บข้อเท็จจริงและข้อสรุปที่ได้เกิดขึ้นแล้วและถูกตัดสินว่าควรเก็บไว้: โครงการนี้ถูกเรียกว่าอะไร, อะไรที่ถูกตัดสินเมื่อสัปดาห์ที่แล้ว, ทำไมพารามิเตอร์ถูกตั้งค่าแบบนั้น Hermes สร้างดัชนีข้อความเต็ม (full-text index) ด้วย SQLite + FTS5 บนรายการเหล่านี้ และเรียกคืนรายการที่ตรงกันเมื่อคุณหยิบยกหัวข้อที่เกี่ยวข้อง แทนที่จะยัดประวัติทั้งหมดลงในบริบท

ความจำไม่ได้เป็นเพียงการเพิ่มข้อมูลอย่างเดียวตลอดไป มันถูกบำรุงรักษาผ่านการดำเนินการ atomic add / replace / remove และสามารถตรวจสอบได้ผ่าน /memory pending สำหรับการออกแบบทั้งหมด ดูที่ "ทำไมความจำมากขึ้นไม่ดีเสมอไป: วิธีที่ Hermes Agent เลือก คัดสรร และอัปเดตความจำระยะยาว"

3.4 วิธีที่ถูกจับ: skills/

skills/ เก็บขั้นตอนมาตรฐานสำหรับ "เมื่อเกิดสถานการณ์ X ให้ทำสิ่งนี้" แต่ละ SKILL.md มักจะมี YAML frontmatter ที่ระบุเงื่อนไขทริกเกอร์ของมัน นี่คือความทรงจำเชิงกระบวนการ ซึ่งเป็นเส้นทางแยกต่างหากจากความทรงจำเชิงบรรยาย — ดู "Memory Is Not a Skill: How Hermes Agent Separates Factual and Procedural Memory."

3.5 การเชื่อมต่อและการกำหนดเวลา: ช่องทาง, งานที่กำหนดเวลา, ไดเรกทอรีการทำงาน

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

ทั้งสามอย่างเป็นการตั้งค่าชั้นเอเจนต์ ไม่ขึ้นอยู่กับว่าโมเดลใดกำลังใช้งานอยู่ในปัจจุบัน


4. ทำไมการแยกส่วนจึงจำเป็น: สี่เหตุผลเชิงปฏิบัติ

การแยกโมเดลออกจากเอเจนต์ไม่ใช่ความบริสุทธิ์ทางสถาปัตยกรรม มันสร้างประโยชน์ที่เป็นรูปธรรม

เหตุผลข้อหนึ่ง: โมเดลพัฒนาได้เร็วกว่าเงินส่วนตัวสะสมมาก โมเดลที่แข็งแกร่งอย่างมีนัยสำคัญอาจเปิดตัวได้ภายในไม่กี่เดือน ในขณะที่ความทรงจำร่วม ความชอบ และเวิร์กโฟลว์ของคุณสะสมขึ้นอย่างช้า ๆ หากทั้งสองถูกเชื่อมโยงกัน การอัปเกรดแต่ละครั้งจะทำให้คุณเสียการสะสมเหล่านั้น — และผู้ใช้ก็คงปฏิเสธที่จะอัปเกรด

เหตุผลข้อที่สอง: งานที่ต่างกันต้องการโมเดลที่ต่างกัน การร่างอย่างรวดเร็วและการคิดวิเคราะห์อย่างหนักไม่จำเป็นต้องใช้โมเดลเดียวกัน การแยกส่วนช่วยให้คุณสลับใช้ต่อภารกิจได้โดยไม่ต้องสร้างเอเจนต์แยก พร้อมหน่วยความจำแยกสำหรับงานแต่ละประเภท

เหตุผลที่สาม: การมีผู้ให้บริการไม่สามารถรับประกันได้ตลอดเวลา. เมื่อผู้ให้บริการจำกัดอัตรา เกิดข้อผิดพลาด หรือเปลี่ยนนโยบาย คุณจำเป็นต้องเปลี่ยนไปใช้โมเดลที่ตั้งค่าไว้ทันที หากความจำถูกผูกกับโมเดล การสลับนั้นจะมีค่าใช้จ่ายที่ยอมรับไม่ได้

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


5. สิ่งที่เกิดขึ้นจริงเมื่อคุณเปลี่ยนโมเดลบน LightVela

ส่วนข้างต้นอธิบายกลไก ส่วนนี้อธิบายพฤติกรรมของผลิตภัณฑ์จริง

เอเจนต์หนึ่งตัวใช้โมเดลที่ใช้งานได้เพียงหนึ่งตัวในครั้งเดียว การสลับหมายถึงการเลือกว่ามอเดลที่กำหนดค่าไว้ใดกำลังใช้งานอยู่ — มันไม่ได้สร้างเอเจนต์ใหม่ คุณไม่จำเป็นต้องมีเอเจนต์หลายตัวเพียงเพื่อใช้หลายโมเดล

การสลับไม่ได้ล้างหน่วยความจำ ไฟล์ในคลาวด์ สกิล หรือการตั้งค่างานที่กำหนดเวลาไว้ การสลับโมเดลจะเปลี่ยนเพียงเครื่องยนต์ที่ใช้สำหรับการตอบกลับในอนาคตเท่านั้น ไม่ได้ย้ายประวัติการแชท เขียนไฟล์ในคลาวด์ใหม่ หรือเปลี่ยนการตั้งค่าสกิลและงานที่กำหนดเวลาไว้

การเตรียมและยืนยันการสลับ, ตามลำดับขั้นตอนที่บันทึกไว้:

  1. ยืนยันว่าโมเดลเป้าหมายถูกตั้งค่าแล้วและสามารถใช้งานได้กับบัญชีของคุณ หากยังไม่ได้ตั้งค่า ให้ทำการตั้งค่าโมเดลก่อน
  2. เตรียมข้อความทดสอบสั้น ๆ เพื่อยืนยันว่าโมเดลใหม่ตอบสนองตามปกติ
  3. หลังจากสลับแล้ว ส่งข้อความทดสอบนั้นในแชทและยืนยันทั้งว่า Agent ตอบกลับและคอนโซลแสดงโมเดลที่คุณเลือก
  4. หากการตอบกลับครั้งแรกหลังจากสลับช้าเล็กน้อย ให้รอสั้น ๆ และลองส่งอีกครั้งก่อนที่จะเปลี่ยนสิ่งอื่นใด

แก้ไขความเข้าใจผิดทั่วไป: การกําหนดค่าของงานที่กําหนดเวลาประกอบด้วยชื่อ ตารางเวลา (วันธรรมดาคงที่, ช่วงเวลาคงที่ หรือครั้งเดียว — เลือกหนึ่งอย่าง), คําสั่งงาน, ช่วงเวลาที่ใช้งานอยู่ และช่องทางการแจ้งเตือน**ไม่มีช่อง "ปักหมุดงานที่กําหนดเวลานี้กับโมเดลเฉพาะ"**ดังนั้นคําแนะนําที่ว่าคุณต้องตรวจสอบงานที่ตั้งเวลาและซิงค์โมเดลใหม่หลังสลับจึงไม่สามารถนํามาใช้ได้สิ่งที่ควรทบทวนหลังจากเปลี่ยนคือคุณภาพของผลลัพธ์ของงาน ไม่ใช่ฟิลด์โมเดลที่ไม่มีอยู่จริง


6. ทำไมมันถึง 'รู้สึกต่างออกไป' หลังจากนั้น

นี่คือขั้นตอนที่มักวินิจฉัยผิดว่าเป็นอาการความจำเสื่อม การเปลี่ยนแปลงพฤติกรรมและการสูญเสียข้อมูลเป็นปัญหาที่แตกต่างกัน และการสับสนระหว่างกันจะทำให้คุณไปทางผิดในการดีบัก

โมเดลแตกต่างกันจริง ๆ ตามมิติเหล่านี้:

มิติแสดงออกอย่างไรมักถูกเข้าใจผิดว่า
การปฏิบัติตามคำสั่งใช้ข้อจำกัด SOUL.md อย่างเข้มงวดหรือผ่อนคลายมากขึ้น"บุคลิกของมันเปลี่ยนไป"
การย่อบริบทให้ข้อมูลพื้นหลังน้อยลง"มันลืมสิ่งที่เราพูดคุยกัน"
ความชอบความยาวคำตอบคำตอบสั้นหรือยาวขึ้นอย่างสังเกตได้"มันโง่ลง / พูดมากขึ้น"
แนวโน้มการใช้เครื่องมืออ่านไฟล์หรือค้นหาอย่างกระตือรือร้นมากขึ้นหรือน้อยลง"มันหยุดใช้เครื่องมือ"
สไตล์ภาษาการใช้คำต่าง การเรียกและน้ำเสียงแตกต่าง"มันกลายเป็นคนอื่น"

การทดสอบนั้นตรงไปตรงมา: ถามเกี่ยวกับข้อเท็จจริงที่คุณมั่นใจว่ามันควรรู้ หากคุณเคยบอกชื่อโครงการหรือความชอบเฉพาะเจาะจงให้กับมันก่อนหน้านี้ ให้ถามเกี่ยวกับสิ่งนั้นโดยตรงหลังจากเปลี่ยน หากมันตอบถูก แสดงว่าชั้นความทรงจำยังคงอยู่และคุณกำลังเห็นความแตกต่างของสไตล์ ถ้ามันไม่สามารถตอบได้จริง ๆ ให้ไปตรวจสอบว่าไฟล์และรายการความทรงจำยังอยู่หรือไม่

กฎปฏิบัติ: เปลี่ยนเพียงปัจจัยเดียวในแต่ละครั้ง และทดสอบหลังจากการเปลี่ยนแต่ละครั้ง การเปลี่ยนโมเดล แก้ไขบุคลิกภาพ และเพิ่มทักษะพร้อมกันจะทำให้คุณไม่สามารถบอกได้ว่าชั้นใดเป็นสาเหตุของปัญหา


7. เมื่อไหร่ที่การสลับโมเดลคุ้มค่า

การเลือกตามความต้องการมีประโยชน์กว่าการไล่ตามโมเดลใดก็ตามที่ปัจจุบันถูกเรียกว่าแรงที่สุด

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

หากเอเจนต์ไม่สามารถทำงานหลังจากสลับแล้ว ให้แก้ไขปัญหาโดยเรียงลำดับดังนี้: ยืนยันว่าแบบจำลองเป้าหมายมีข้อมูลรับรองและการตั้งค่าผู้ให้บริการครบถ้วน → ยืนยันว่าแบบจำลองสามารถใช้งานได้กับบัญชีของคุณและมีโควต้าพอเพียง → ทดสอบด้วยแบบจำลองที่ทราบว่าทำงานได้ → หากยังล้มเหลว ให้ตรวจสอบบันทึกล่าสุดใน Diagnostics


8. แนวทางของ LightVela: แบบจำลองในฐานะตัวเลือก, สินทรัพย์ถูกเก็บโดยผู้ใช้

Hermes แยกโมเดลออกจากเอเจนต์ในระดับกลไก แต่ยังคงมุ่งเป้าไปที่ผู้คนที่สะดวกในการจัดการไฟล์ Markdown และสภาพแวดล้อมท้องถิ่นโดยตรง ทิศทางของ LightVela คือการทำให้การแยกนั้นเป็นประสบการณ์สินค้าพื้นฐาน:

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

ผลลัพธ์ก็คือ ความก้าวหน้าของโมเดลจะมาถึงคุณโดยตรง ในขณะที่สิ่งที่คุณสะสมมาแล้วนั้นไม่เคยกลายเป็นราคาของความก้าวหน้านั้น


ประเด็นสำคัญ

  • Agent มีอย่างน้อยสามชั้น: ชั้นโมเดลที่เปลี่ยนได้, รันไทม์ ที่ทํางานระยะยาว และ ทรัพย์สินระยะยาว ที่สะสมอย่างต่อเนื่อง
  • ชั้นโมเดลจัดการการตีความ การวางแผน การเรียกเครื่องมือ และการแสดงออกสําหรับเทิร์นปัจจุบันไม่เก็บค่าความชอบ ตารางการรัน หรือจัดการช่องทาง
  • SOUL.md, USER.md, MEMORY.md, memories/, skills/ และไดเรกทอรีทํางานทั้งหมดอยู่นอกโมเดล ดังนั้นการเปลี่ยนโมเดลจึงไม่ทําให้โมเดลเหล่านั้นต้องทํางานพร้อมกัน
  • บน LightVela เอเจนต์หนึ่งคนจะมีโมเดลที่ใช้งานทีละหนึ่งตัว;การสลับจะไม่ล้างหน่วยความจํา, คลาวด์สตอเรจ, ทักษะ หรืองานที่ตั้งเวลาไว้
  • งานที่กําหนดเวลาไม่มีการตั้งค่า "โมเดลปักหมุด" ดังนั้นการอ้างว่าต้องซิงค์โมเดลงานที่ตั้งเวลาไว้ใหม่หลังเปลี่ยนจึงไม่ถูกต้อง
  • ความรู้สึกแตกต่างหลังเปลี่ยนมักเกิดจากความแตกต่างในการปฏิบัติตามคําสั่ง การบีบอัดบริบท และความแตกต่างของถ้อยคํา — ไม่ใช่ความทรงจําที่สูญหายตรวจสอบด้วยข้อเท็จจริงที่ทราบเพียงข้อเดียว

อัปเดตล่าสุดเมื่อ 2026-10-09

บนหน้านี้

สรุปทำไมคำถามนี้ถึงเกิดขึ้นบ่อย1. แยกสามสิ่งออกมาก่อน: โมเดล รันไทม์ และสินทรัพย์ระยะยาว2. ชั้นโมเดล: รับผิดชอบในเรื่อง "จะคิดอย่างไรครั้งนี้"3. ชั้นเอเจนต์: รับผิดชอบในการทำให้การคิดต่อเนื่อง3.1 เอกลักษณ์และกฎพฤติกรรม: SOUL.md3.2 โปรไฟล์ผู้ใช้: USER.md3.3 ข้อเท็จจริงข้ามเซสชัน: MEMORY.md และ memories/3.4 วิธีที่ถูกจับ: skills/3.5 การเชื่อมต่อและการกำหนดเวลา: ช่องทาง, งานที่กำหนดเวลา, ไดเรกทอรีการทำงาน4. ทำไมการแยกส่วนจึงจำเป็น: สี่เหตุผลเชิงปฏิบัติ5. สิ่งที่เกิดขึ้นจริงเมื่อคุณเปลี่ยนโมเดลบน LightVela6. ทำไมมันถึง 'รู้สึกต่างออกไป' หลังจากนั้น7. เมื่อไหร่ที่การสลับโมเดลคุ้มค่า8. แนวทางของ LightVela: แบบจำลองในฐานะตัวเลือก, สินทรัพย์ถูกเก็บโดยผู้ใช้ประเด็นสำคัญ