Blackboard Architecture: ให้ AI Agent ใช้สถานะร่วมกันโดยไม่เขียนทับงานกัน

คำตอบโดยตรง: Blackboard Architecture จัดให้หน่วยความรู้เฉพาะทางอ่านและเสนอผลผ่านพื้นที่สถานะร่วม โดยมีตัวควบคุมเลือกงานที่ควรทำต่อ การใช้กับทีม AI Agent ต้องกำหนดชนิดข้อมูล สิทธิ์ เวอร์ชัน และกฎตรวจรับก่อนเขียนจริง การแชร์ฐานข้อมูลเพียงอย่างเดียวไม่ป้องกันงานถูกทับ ส่วนการตรวจเวอร์ชันแบบ atomic ช่วยตรวจการเขียนจากสถานะเก่า แต่ไม่ยืนยันความจริงของข้อมูลหรือทำให้ผลนอกฐานข้อมูลเกิดเพียงครั้งเดียว

ทำไมใช้ความจำร่วมกันแล้วงานยังหาย

ให้ Agent A และ B อ่านว่า “ตรวจรับชิ้นงานแล้ว 0 ชิ้น” จากนั้นทั้งสองทำงานคนละชิ้นและคำนวณว่าจะบันทึกค่า 1 หาก A เขียนก่อน แล้ว B นำค่า 1 ที่คำนวณจากข้อมูลเก่ามาเขียนทับ ระบบจบที่ 1 ทั้งที่มีสองงาน นี่คือ Lost Update ในตัวอย่าง read–modify–write

ปัญหาไม่ได้เกิดจากโมเดลภาษาไม่จำเก่งพอ แต่เกิดจากความสัมพันธ์ระหว่างเวลาที่อ่าน สิ่งที่คำนวณ และกฎรับการเขียน การเพิ่ม context หรือบอกใน prompt ว่า “อย่าเขียนทับเพื่อน” ไม่ทำให้การตรวจเงื่อนไขกับการเขียนเป็นขั้นที่แบ่งแยกไม่ได้

บทความนี้ต่อจาก กรอบ AI Agent Architecture โดยเจาะสถานะร่วมและจุด commit ไม่สร้างข้ออ้างว่าทุกทีมต้องใช้ Blackboard และไม่รับรองว่าผังต่อยอดนี้พร้อมใช้งานจริงจากรูปเพียงอย่างเดียว

Blackboard คือสถาปัตยกรรมการประสานความรู้

งาน Hearsay-II ของ Erman และคณะใน ACM Computing Surveys ปี 1980 อธิบายระบบ speech understanding ที่มี Knowledge Sources แบบ condition/action ทำงานกับ hypothesis หลายระดับบน blackboard และใช้ focus-of-control เลือกกิจกรรมที่เหมาะสม ระบบเป็นตัวอย่างที่สร้างและศึกษาแล้ว ไม่ใช่ LLM หรือแบบจำลองสมองมนุษย์ ต้นฉบับจากสถาบันผู้วิจัย

คำว่า Knowledge Sources ทำงานเป็นโปรแกรมแยกกันในงานนี้ไม่ได้ยืนยันว่าเป็น workers กระจายหลายเครื่องพร้อมกัน ตัวควบคุมของ Hearsay-II เลือกกิจกรรมลำดับความสำคัญสูงในแต่ละรอบ การเพิ่ม concurrency กับ version guards ในบทความนี้เป็นการออกแบบสมัยใหม่ที่นำไปทดสอบต่อ

Blackboard ดั้งเดิมเก็บสิ่งที่ระบบกำลังพิจารณา เช่น hypothesis ระดับเสียง คำ และวลี ไม่ใช่คลัง “ความจริงของโลก” ที่ถูกต้องเสมอ การนำมาใช้กับ Agent ควรรักษาความแตกต่างระหว่าง observation, hypothesis, proposal และ accepted state แทนการรวมทุกข้อความเป็นข้อเท็จจริง

Penny Nii อธิบายโมเดลและพัฒนาการของ Blackboard ใน AI Magazine ปี 1986 รอบนี้ตรวจ abstract กับ metadata ได้ แต่การอ่าน PDF เต็มยัง UNKNOWN จึงใช้ Hearsay-II ที่อ่านเนื้อหาได้เป็นหลักฐานของ Module ข้างต้น ไม่อ้างอ่านทุกหน้าของงานทบทวน Nii: publisher record

มีฐานข้อมูลร่วม ไม่ได้แปลว่ามี Blackboard ครบ

องค์ประกอบสำคัญคือพื้นที่แทนสถานะ หน่วยความรู้ที่มีเงื่อนไขทำงาน และการควบคุมว่าจะกระตุ้นใครเมื่อข้อมูลเปลี่ยน ฐานข้อมูลที่ทุก Agent เขียนได้อาจเป็นเพียง shared store หากไม่มีกลไกดังกล่าว ส่วน Blackboard ก็ไม่จำเป็นต้องใช้ LLM ทุกหน่วย

ตัวอย่างทีมสร้างรายงานอาจมี Collector เสนอ observation พร้อม source/version, Analyzer เสนอข้อสรุป, Validator ตรวจความสัมพันธ์กับหลักฐาน และ Controller เลือกงานที่ข้อมูลพร้อม ภาพนี้เป็น HYPOTHESIS สำหรับทดลอง ไม่ใช่ผลว่าการแบ่งบทบาททำให้ accuracy สูงขึ้นแล้ว

การเก็บใน SQL, document database หรือ memory ของ process เป็นอีกตัวเลือกหนึ่ง ต้องกำหนดความคงอยู่และการจัดการ concurrent writes แยกจากการตั้งชื่อสถาปัตยกรรม Shared store ที่ค้นคืนข้อมูลได้ไม่ได้สร้าง scheduler หรือ semantic validation ให้เอง

Version คือร่องรอยการเปลี่ยน ไม่ใช่เวลาของข้อเท็จจริง

Record จำลองมี count กับ version เริ่มที่ 0 เมื่อรับการเปลี่ยนหนึ่งครั้ง version เพิ่มเป็น 1 Worker เก็บทั้งค่าที่อ่านและเวอร์ชันนั้นไว้ใน snapshot แล้วส่ง expectedVersion พร้อมข้อเสนอใหม่

Version ในตัวอย่างเป็นเลขลำดับของ record เดียว ไม่ใช่ global clock ไม่ยืนยันลำดับเหตุการณ์ทุก record และไม่ใช่ Valid Time หรือ System Time ตาม Bitemporal Memory การรู้ว่าเวอร์ชันใหม่กว่าไม่ได้บอกว่าข้อมูลนั้นมีผลในโลกเมื่อใดหรือเป็นข้อมูลจริงหรือไม่

ระบบจริงต้องกำหนดให้ writers ทุกทางเพิ่มเวอร์ชันตามกฎและไม่ข้าม gateway หากบางทางแก้ค่าโดยไม่เพิ่ม version การตรวจของ worker อื่นอาจไม่เห็นการเปลี่ยน การลบแล้วสร้าง record ใหม่โดยใช้เลขเดิมยังต้องมี generation หรือ identity ที่แยกการเกิดใหม่ ไม่ใช้ counter ที่ reset แล้วถือว่าเป็นตัวตนเดิม

สามวิธีรับการเขียนที่ต้องแยกกัน

คำว่า Compare-and-Set (CAS) ในบทความหมายถึง application pattern ที่ตรวจค่าหรือเวอร์ชันก่อนเปลี่ยน record โดยการตรวจและเปลี่ยนเป็นขั้น atomic บน authoritative store ไม่ใช่ชื่อฟีเจอร์ที่จะได้อัตโนมัติจากการใช้ฐานข้อมูลใดก็ตาม

ในตัวอย่างเฉพาะ counter การเพิ่มฝั่ง server แบบ count = count + 1 เป็นทางเลือกที่เรียบง่ายกว่าการส่งค่าเต็มจาก client เพราะใช้ค่าปัจจุบันของ record โดยตรง จึงไม่ควรเพิ่ม CAS และหลาย Agent โดยไม่มีเหตุผล หากการเปลี่ยนเป็นการแทนแผนซึ่งอิงหลายข้อมูล ต้องออกแบบเงื่อนไขให้เหมาะกับโจทย์

Atomic Check-and-Write ต้องเกิดที่ไหน

SQL เชิงแนวคิด — ยังไม่ได้รันกับฐานข้อมูลจริงในบทความ สมมติ id เป็น unique key และ version เป็น BIGINT NOT NULL ที่ application ควบคุม ผู้ส่งมีสิทธิ์ และ writers ทุกทางใช้กฎเดียวกัน

UPDATE board_record
SET count = :proposed_count,
    version = version + 1
WHERE id = :record_id
  AND version = :expected_version
RETURNING count, version;

proposed_count คือค่าที่ worker คำนวณ record_id ระบุ record เดียว และ expected_version คือเวอร์ชันที่อ่าน ข้อสำคัญคือเงื่อนไขกับการเปลี่ยนอยู่ในคำสั่งเดียว ไม่ใช่ SELECT ตรวจจาก client แล้วตามด้วย UPDATE ที่ไม่มีเงื่อนไข

เอกสาร PostgreSQL 18 Read Committed อธิบายว่าเมื่อพบ row ที่อีก transaction กำลังแก้ ผู้เขียนอาจรอ แล้วตรวจ WHERE กับ row เวอร์ชันที่ commit แล้วใหม่ กลไกนี้รองรับ conditional update ของ row ที่กำหนด แต่ไม่ทำให้ทุก invariant หลาย row ปลอดจาก concurrency anomaly Transaction isolation

RETURNING แสดง rows ที่อัปเดตจริง หากไม่มี row ไม่ควรสรุปทันทีว่า “version เก่าแน่นอน” อาจไม่มี id, ถูก policy กรอง หรือ trigger ระงับ update ต้องวินิจฉัยและอ่านกลับผ่านช่องทางที่มีสิทธิ์ หากยังแยกสาเหตุไม่ได้ให้เป็น UNKNOWN UPDATE semantics และ Row Security

คำสั่งนี้ยังไม่ใช่ API ครบชุด ไม่มี operation deduplication หรือ semantic proof ของ proposed_count หากระบบต้องแก้หลาย record หรือคุมทรัพยากรร่วม ต้องเลือก transaction/locking/isolation ที่เหมาะสมและทดสอบจริง ไม่ใช้ผล toy ของ row เดียวเป็นหลักฐานแทน

Interactive: สอง Agent อ่านเหมือนกัน แล้วผลหายตรงไหน

ยังไม่อ่าน

ยังไม่อ่าน

เลือกวิธีรับการเขียนแล้วกดอ่าน A และ B ก่อน commit ทั้งคู่ Snapshot จะเริ่มจาก count0/version0 และข้อเสนอ1 ดู state กับ trace หลัง commit A ตามด้วย B วิธี blind replacement ทำให้เห็น intent ที่ถูกทับ ส่วน CAS ปฏิเสธข้อเสนอจาก snapshot เก่า

เมื่อ conflict ให้ B อ่านใหม่และคำนวณข้อเสนอใหม่จาก state ปัจจุบัน อย่าแก้เฉพาะ expectedVersion ให้ตรงแล้วส่ง proposed_count เดิม เพราะจะทำให้ stale proposal ผ่านด่านแต่ยังทับงานอยู่ การ re-read ต้องนำไปประเมิน intent และข้อจำกัดใหม่

Lab แสดง operation IDs เพื่อแยกงานคนละชิ้นออกจากการส่งงานเดิมซ้ำ เปลี่ยนการกันซ้ำแล้วลองส่ง logical operation เดิมด้วย snapshot ใหม่ จะเห็นว่า version guard กับ deduplication แก้ปัญหาคนละชนิด

SIMULATION: ปุ่มกำหนดลำดับ read/commit ของตัวสร้างข้อมูลใน JavaScript เพื่อสำรวจ interleaving ไม่ได้เปิด LLM, PostgreSQL, network workers หรือทดสอบ database atomicity จริง ข้อมูลอยู่ page session การ Reset หรือรีเฟรชล้าง state

Commit สำเร็จหนึ่งครั้ง ไม่เท่ากับงานเกิดครั้งเดียว

สมมติ server รับ operation เพิ่มงานหนึ่งชิ้นแล้ว แต่คำตอบกลับมาหาย ผู้เรียกไม่รู้ผลและเริ่มใหม่ การส่ง request เก่าซ้ำใน CAS อาจเจอเวอร์ชันเปลี่ยน แต่หาก handler อ่านใหม่แล้วคำนวณเพิ่มหนึ่งอีกครั้ง logical operation เดิมก็อาจผ่านด้วยเวอร์ชันใหม่ได้

Idempotency จึงต้องกำหนดตัวตนของ intent เช่น operationId, taskId และชนิดการเปลี่ยน ให้การส่งซ้ำของงานเดิมคืนผลเดิมหรือบอก already applied โดยไม่ทำการเปลี่ยนซ้ำ กฎตรวจตัวตนกับการรับผลต้องมีขอบเขต atomic/persistence ที่เหมาะสม ไม่ใช่มี ID ใน log แล้วเพียงพอ

CAS ป้องกันข้อเสนอที่อ้าง state เก่า ส่วน dedup ป้องกัน intent เดิมถูกนับใหม่ เมื่อ operationId เดิมแต่เนื้อหาหรือความหมายเปลี่ยน ต้องตรวจความไม่ตรงกัน ไม่ใช้ ID บังการเปลี่ยนงาน หากมีการส่งอีเมลหรือการกระทำภายนอก การคุม row ในฐานข้อมูลไม่ได้ให้ exactly-once effect ของระบบปลายทางด้วยตัวมันเอง

Architecture: แยกข้อเสนอจากสถานะที่รับแล้ว

ผังเป็น Conceptual Architecture / HYPOTHESIS ที่นำ pattern การประสานความรู้มาใช้กับ Agent สมัยใหม่ ไม่ใช่ Hearsay-II ฉบับ distributed LLM และยังไม่มีผลทดลองยืนยันว่าทีมนี้ดีกว่า Single-Agent

ข้อมูลไหลจาก input ไปเป็น representation บน board กระตุ้น Knowledge Source ให้เสนอ partial solution ตัวควบคุมเลือกงาน Validator/Gateway รับหรือปฏิเสธ แล้ว feedback เปลี่ยนงานที่ควรทำต่อ ไม่จำเป็นต้องมี neural perception หรือทุกขั้นของวงจร Agent ทั่วไป

Memory ในที่นี้เป็น state และ trace ภายนอกโมเดล Context Window เป็นขอบเขตความจุ Current Context คือข้อมูลที่โมเดลได้รับจริง Retrieved Context เป็นส่วนค้นคืนมาประกอบ ไม่มีขั้นใดในผังนี้ยืนยันการฝึกน้ำหนัก หาก worker อ่านข้อมูลใหม่แล้วตอบต่าง ให้รายงานว่า context/state เปลี่ยน ไม่อนุมานว่าโมเดลเรียนรู้น้ำหนักใหม่

Operational Flow: เมื่อผลเขียนไม่ชัด ให้ตรวจสถานะก่อนทำใหม่

Pseudocode เชิงแนวคิด ต่อไปนี้ยังไม่ได้รัน LLM หรือ real database integration; commit atomic/dedup เป็นสัญญาที่ implementation ต้องทำและทดสอบ ไม่ใช่ฟังก์ชันสำเร็จรูปจากชื่อ

intent = stable_operation_identity(task)
prior = read_authoritative_state()

if accepted_result_exists(intent):
    return saved_result_with_trace

candidate = recompute_intent(intent, prior)
decision = validate(candidate, prior, permissions)

if decision != PASS:
    record_rejection_or_unknown(intent, decision)
    return decision_with_trace

result = commit_atomically(candidate, prior.version, intent)
record_attempt_and_result(intent, result)

if result == CONFLICT:
    schedule_bounded_reread_and_revalidation(intent)
else if result == UNKNOWN:
    reconcile_operation_and_state_before_retry(intent)

return result_with_trace

การตรวจ accepted result ก่อนเรียก commit ช่วยลดงานซ้ำ แต่ไม่พอเมื่อสองผู้เรียกตรวจพร้อมกัน Gateway ยังต้องกัน duplicate ในขอบเขต commit เอง เหมือนการตรวจ version จาก client ไม่สามารถแทนเงื่อนไขฝั่ง server

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

Event Log เก็บประวัติได้ แต่ไม่เลือกคำตอบให้เอง

เอกสาร Microsoft Event Sourcing อธิบายการเก็บ events เพื่อ replay สร้าง projections พร้อมปัญหา concurrency และ idempotency การแยก proposal จาก accepted events สำคัญ เพราะการบันทึกว่ามีคนเสนอแผนหนึ่งไม่เท่ากับรับแผนนั้นเข้าสถานะจริง Official pattern

ใน Lab เราอนุญาต ADD1 ซึ่งรวมกันได้และตรวจ operationId ซ้ำ จึงรวมสอง contributions เป็น2ได้ แต่แผนสองฉบับที่ขัดกันหรือคำสั่งหักทรัพยากรมี invariant ต่างออกไป Append ทั้งสองอาจเก็บหลักฐานความขัดแย้งครบ แต่ยังต้องมี acceptance rule, expected stream version หรือ transaction ก่อนรับการเปลี่ยน authoritative state

Projection ยังอาจล่าช้ากว่า accepted log ผู้ตัดสินใจต้องระบุว่าอ่าน view ที่สดเพียงใดและตรวจเงื่อนไขกับแหล่งใด หากรับตาม projection ที่เก่าแล้วค่อยอัปเดต log ปัญหา stale state ก็อาจกลับมา แม้ไม่มีการลบประวัติ

เกมจำลอง: รักษางานหกชิ้นให้ครบในงบจำกัด

ผู้เล่นคุม workers A/B/C ที่มีงานคนละสองชิ้น เป้าหมายคือรักษา six unique contributions ให้ครบ งบ18หน่วยสมมติ การอ่านและ commit เป็น actions ที่เห็นได้ เลือกให้หลายตัวอ่านก่อนเขียนเพื่อสร้าง stale snapshots แล้วทดลองเปลี่ยน policy หลัง Reset

อย่าดู count สุดท้ายอย่างเดียว หากงานหนึ่งหายและอีกงานถูกนับซ้ำ ตัวเลขอาจดูครบทั้งที่เนื้องานไม่ครบ Lab ใช้ intent IDs เป็น instrumentation เพื่อแสดงสิ่งที่คงอยู่ ผลที่ถูกทับ duplicate และต้นทุนของการแก้ ต้องตรวจทั้งจำนวนกับตัวตน

ทาง event log ในเกมอาจใช้ actions น้อยกว่าใน counter ที่อนุญาต ADD1 แต่ไม่ใช่ benchmark ว่า Event Sourcing เร็วหรือดีกว่า CAS ในงานทั่วไป หน่วยงบไม่ใช่ token ราคา latency หรือ throughput จริง ผู้เล่นเลือก scheduling ไม่มี autonomous LLM ในเกม

ระบบจริงและความจำชนิดอื่นต่างกันตรงไหน

Hearsay-II เป็นตัวอย่างระบบ Blackboard ที่มีงานจริง ส่วน PostgreSQL ให้กลไก transaction/update ที่นำไปประกอบเป็น gateway ได้ เอกสารกับ source availability ช่วยศึกษา แต่การนำสองอย่างมาประกอบไม่ได้พิสูจน์ว่า implementation ต่อใหม่ถูกแล้ว

เอกสาร LangGraph Persistence แยก checkpoint ที่มี thread scope กับ Store สำหรับข้อมูลข้าม threads ขอบเขตเหล่านี้ช่วยตัดสินว่าจะวาง state ที่ใด แต่ไม่ได้ยืนยัน default CAS หรือ scheduler ของ Blackboard Exact package version และ integration ในบทความยัง UNKNOWN Official JavaScript docs

อีกความหมายของ shared memory คือการแชร์ KV/Attention ใน Looped Transformers ซึ่งเป็นโครงสร้างภายในโมเดลที่ฝึก ไม่ใช่ board ที่หลาย application workers เขียนร่วมกัน ต้องแยกสองระดับนี้ก่อนนำตัวเลขประหยัดหน่วยความจำมาใช้กับระบบ Agent

Failure Modes และสิ่งที่ยังต้องทดสอบ

Stale Proposal Bypass: เปลี่ยน expectedVersion แต่ไม่เปลี่ยนข้อมูลที่คำนวณ ทำให้ผ่าน guard อย่างผิดความหมาย ต้องผูก candidate กับ snapshot และ revalidate

Writer Bypass: งานบางทางไม่เพิ่ม version หรือไม่ผ่าน validator ทำให้ protocol ของ writers ที่ถูกต้องไม่ครอบคลุมทั้งระบบ ต้องตรวจ paths และสิทธิ์จริง

False Accepted State: schema ผ่านแต่ข้อกล่าวอ้างผิด การ atomic commit ไม่ตรวจความจริง ให้แยก semantic evidence กับ concurrency result

Duplicate Intent: retryด้วยsnapshotใหม่เพิ่มงานเดิมซ้ำ ต้องมี identity ของ operation และผลที่บันทึก ไม่แปลงทุกretryเป็นtaskใหม่

Cross-record Invariant: CAS recordหนึ่งไม่คุมทรัพยากรหลายrecordหรือการเปลี่ยนภายนอก ต้องทดสอบ transaction/scheduling ที่เหมาะสม ไม่กล่าวว่ามี serializability ทั้งระบบ

Durability Gap: page memory หรือ logที่ยังไม่commitอาจหายเมื่อprocessหยุด การมี checkpointfileไม่พิสูจน์recovery ให้ทดสอบหยุดก่อน/หลังcommitและผลตอบกลับหาย

ทิศทางวิจัยและ Practical Takeaways

คำถามต่อไปคือ Controller เลือก Knowledge Sources อย่างไรเมื่อ hypotheses ขัดกัน จะลดการกระตุ้นซ้ำโดยไม่พลาดข้อมูลใหม่ได้อย่างไร และเมื่อข้อมูลเปลี่ยนระหว่างการวางแผนควรยกเลิกงานใด ข้อเสนอต้องวัดคุณภาพคำตอบร่วมกับ conflicts, lost intents, duplicates และต้นทุนจริง

เริ่มจาก state contract และชนิด mutations ที่อนุญาต เลือกกรณีง่ายที่สุดที่รักษา invariant ได้ ระบุ authoritative state, version policy, accepted-event boundary และ operation identity แล้วทดสอบการสลับ read/commit พร้อมกรณีผลไม่ชัด ไม่เริ่มจากเพิ่ม workers หรือชื่อ framework

บทเรียนสำคัญคือ “อะไรถูกเสนอ อะไรรับแล้ว และตรวจผลจากที่ใด” ต้องตอบได้แยกกัน จึงจะอธิบายความจำและการตัดสินใจของทีม Agent โดยไม่ใช้ความเห็นพ้องหรือการส่ง request เป็นหลักฐานแทนผลจริง

FAQ

Blackboard คือฐานข้อมูลหรือ Vector Database หรือไม่

เป็นแบบสถาปัตยกรรมที่มีพื้นที่แทนสถานะ หน่วยความรู้ และ control ฐานข้อมูลเป็นส่วน storage ได้ แต่ไม่สร้างองค์ประกอบอื่นให้เอง

เพิ่ม version แล้วแก้ Lost Update ได้เลยหรือไม่

ต้องตรวจ expectedVersion พร้อม write แบบ atomic และทุก writer ใช้กฎเดียวกัน เพิ่มเลขหลังเขียนแบบ blind ยังทับงานได้

CAS ตรวจว่าข้อมูลจริงหรือไม่

ตรวจ precondition ของ state ที่กำหนด ไม่ตรวจข้อเท็จจริงหรือสิทธิ์ด้วยตัวมันเอง Semantic validation เป็นอีกหน้าที่

CAS กับ Idempotency เหมือนกันหรือไม่

CAS จัดการ snapshot เก่า ส่วน idempotency จัดการ intent ซ้ำ งานเดิมที่ถูก rebase อาจผ่านversionใหม่หากไม่กันซ้ำ

Event Log แก้ทุก conflict อัตโนมัติหรือไม่

เก็บ accepted events/projections ได้ แต่ต้องมีกฎรับข้อมูลและinvariants ตัวอย่างADD1รวมกันได้ไม่แทนแผนที่ขัดกันทุกชนิด

Lab รัน PostgreSQL หรือฝึก LLM หรือไม่

เป็น JavaScript SIMULATION ของลำดับการเขียน ไม่มี realdatabase, networkworkers, LLM หรือ weight update

Shared State คือความจำภายในโมเดลหรือไม่

เป็นข้อมูลที่ application เก็บและอาจนำไปใส่ context ต่างจากน้ำหนักโมเดลและKVCacheภายใน Attention

References และขอบเขตการตรวจ

• Hearsay-II, ACM Computing Surveys 12(2), มิถุนายน1980 — อ่านส่วนระบบและarchitecture;ไม่รันระบบหรือทำซ้ำผลเดิม
• Nii, Blackboard Systems Part One, AI Magazine7(2), 1986 — abstract/metadataอ่านได้; fullPDFread UNKNOWN
• PostgreSQL18 Transaction Isolation — official versioned docs; ไม่รันliveconcurrencyintegration
• PostgreSQL18 UPDATE และ Explicit Locking — illustrativeconditionalwrite/RETURNING/locking; SQLตัวอย่างNOT RUN
• Microsoft Event Sourcing — officialpattern ตรวจsnapshotที่เปิดอ่าน ไม่อ้างvendorbenchmark
• LangGraph JavaScript Persistence — rollingdocs; exactinstalledpackage/integrationUNKNOWN ไม่อ้างdefaultCAS

สถานะหลักฐาน: FACT คือกลไกที่ต้นฉบับระบุเกี่ยวกับระบบนั้น ANALYSIS คือการเลือกเปรียบเทียบ HYPOTHESIS คือmodernAgentarchitectureที่เสนอ SIMULATIONคือLab/เกม/ลำดับcounter งานวิจัยที่รายงานperformanceเป็นREPORTED CLAIM การรันHearsay-II, realdatabaseintegration, durability/throughput และbenchmarkของระบบAgentโดย HYBRID MIND ยัง UNKNOWN