แผนเวิร์กเกอร์บนคลาวด์

สถานะ

ข้อเสนอ ฉบับแก้ไขครั้งที่ 3 ยังไม่ได้ดำเนินการ มีการตกลงทิศทางในเดือน 2026-07; ฉบับแก้ไขครั้งที่ 2 ได้รวมข้อค้นพบจากการตรวจสอบเชิงปฏิปักษ์ (โปรโตคอล worker เฉพาะ, เครื่องสถานะสำหรับตำแหน่งการทำงาน/สภาพแวดล้อม, การซิงค์ขาเข้าที่รับรู้สถานะ git, การส่งมอบทางเดียวใน v1, และถ้อยคำด้านความปลอดภัยเกี่ยวกับการรับส่งข้อมูลขาออกแบบควบคุม) ฉบับแก้ไขครั้งที่ 3 กำหนดโมเดลความเป็นเจ้าของการซิงค์ให้ชัดเจน (worker เป็นผู้สร้าง commit ส่วน Gateway รับช่วงและเผยแพร่), เพิ่มโหมดซิงค์แบบธรรมดาที่ไม่ใช้ git, แก้การทำงานของ exec บน worker ให้เป็นแบบเต็มรูปแบบภายในเครื่อง, ย้ายนโยบายอินเทอร์เน็ตไปยังเวลาจัดเตรียม และนำการส่งงานของเอเจนต์กลับมาไว้ที่หมุดหมายที่ 3

ปัญหา

เซสชันเอเจนต์ของ OpenClaw ทำงานลูป เครื่องมือ และการอนุมานภายในโปรเซส Gateway บนเครื่องเดียว ทรัพยากรประมวลผลจึงถูกจำกัดด้วยเครื่องนั้น งานที่ใช้เวลานานจะครอบครองเครื่อง และงานแบบขนานต้องแย่งทรัพยากรกัน ผลิตภัณฑ์แบบโฮสต์ (Cursor cloud agents, Claude Code on the web, Codex cloud) แก้ปัญหานี้ด้วยแซนด์บ็อกซ์คลาวด์ชั่วคราวแยกตามงาน แต่ต้องพึ่งพาโครงสร้างพื้นฐานและความไว้วางใจต่อผู้ให้บริการ

ผู้ดูแลระบบที่มีเครื่องสำรองอยู่แล้ว (หรือสามารถเช่าได้ในราคาถูก) ยังไม่มีวิธีระบุว่า: ให้เรียกใช้เซสชันนี้บนเครื่องนั้น แสดงเซสชันในแถบด้านข้างเหมือนเซสชันอื่น และทิ้งเครื่องเมื่อเสร็จงาน

เป้าหมาย

• เรียกใช้เซสชันเอเจนต์เต็มรูปแบบ (ลูป + เครื่องมือ) บนเครื่องระยะไกลชั่วคราว ("cloud worker") โดยเซสชันจะปรากฏและสตรีมใน Control UI เหมือนเซสชันภายในเครื่องทุกประการ
• ไม่มีข้อมูลประจำตัวคงค้างอยู่บน worker (ไม่มีการยืนยันตัวตนกับผู้ให้บริการและไม่มีโทเค็นของ forge) และไม่มีการรับส่งข้อมูลขาออกผ่านเครือข่ายโดยตรง เครื่องต้องมีเพียง sshd ที่เข้าถึงได้
• จัดเตรียม ซิงค์ เรียกใช้ รวบรวม ทำลาย — เป็นระบบอัตโนมัติทั้งหมดและรองรับผู้ให้บริการแบบเสียบเปลี่ยนได้ (ผู้ให้บริการรายแรก: CLI สำหรับเช่าเครื่องรูปแบบ Crabbox)
• ส่งงานที่กำลังทำจาก Gateway ไปยัง worker ที่ขอบเขตระหว่างเทิร์นโดยไม่สูญเสียทรานสคริปต์ ตัวตนของเซสชัน หรือความสัมพันธ์กับแคชของผู้ให้บริการ (เมื่อไบต์ของคำขอยังคงเทียบเท่ากัน) และดึงผลลัพธ์กลับมาอย่างปลอดภัย
• ทั้งมนุษย์ (UI) และเอเจนต์ (เครื่องมือ) สามารถส่งงานไปยัง cloud worker ได้
• รองรับเซสชันที่ทำงานนานหลายวัน อายุการใช้งานเป็นนโยบาย ไม่ใช่ขีดจำกัดที่เขียนตายตัว

สิ่งที่ไม่ใช่เป้าหมาย (v1)

• ไม่มีชุดควบคุมการเขียนโค้ดภายนอก (Claude Code, Codex CLI) บน worker เซสชัน worker จะเรียกใช้เฉพาะตัวรันแบบฝังของ OpenClaw เท่านั้น การรองรับชุดควบคุมเป็นตัวเลือกแบบยินยอมใน v2 เพราะชุดควบคุมเหล่านี้ทำการอนุมานเองโดยใช้ข้อมูลประจำตัวของตนเอง
• ไม่มีการกระจายการลองแบบขนานหรือเลือกผลลัพธ์ที่ดีที่สุดจาก N ครั้ง
• ไม่พึ่งพา VPN/tailnet การรับส่งข้อมูลใช้ SSH เท่านั้น
• ไม่มีรันไทม์แซนด์บ็อกซ์ใหม่ เครื่อง worker เป็นขอบเขตการแยกออกจากกัน และสามารถเพิ่มแซนด์บ็อกซ์ระดับระบบปฏิบัติการภายในเครื่องได้ภายหลัง
• ไม่มีการย้ายแบบสดสมมาตรใน v1: การส่งงานเป็นจากภายในเครื่อง → worker; การย้ายจาก worker → ภายในเครื่องต้องใช้เซสชันที่หยุดแล้วและดำเนินการกระทบยอดพื้นที่ทำงานให้เสร็จสิ้น การส่งมอบแบบสดสองทางจะสร้างต่อยอดบนกลไกกำแพงกั้นเดียวกันในภายหลัง
• ไม่มีสถานะเสริมแบบ JSON บน Gateway; สถานะสภาพแวดล้อม ตำแหน่งการทำงาน เคอร์เซอร์ และสิทธิ์อนุญาตจะอยู่ใน SQLite

งานที่มีมาก่อน (สิ่งที่เรานำมาใช้ สิ่งที่เรากลับด้าน)

• Cursor cloud agents: ลูปเอเจนต์ทำงานในคลาวด์ของผู้ให้บริการ; VM เป็นเป้าหมายสำหรับเรียกใช้เครื่องมือ; ที่เก็บการสนทนาแบบเพิ่มต่อท้ายเท่านั้นจะสตรีมไปยังไคลเอนต์ทั้งหมด; เริ่มต้นอย่างรวดเร็วจากสแนปช็อตหลังติดตั้ง; worker แบบโฮสต์เองเป็นโปรเซสที่เชื่อมต่อออกเท่านั้น เรานำแนวคิด "แหล่งข้อมูลจริงของการสนทนายังคงอยู่ที่ตัวประสานงาน" และโมเดลการสตรีมมาใช้ แต่กลับด้านตำแหน่งของลูป (ดูการตัดสินใจด้านล่าง)
• Codex cloud: รันไทม์สองระยะ — ระยะตั้งค่าที่มีเครือข่าย ตามด้วยระยะเอเจนต์แบบออฟไลน์ที่นำข้อมูลลับออกแล้ว; แคชสถานะคอนเทนเนอร์เพื่อเร่งงานต่อเนื่อง เรานำการแยกระยะมาใช้เป็นแนวทางควบคุมการรับส่งข้อมูลขาออก และนำแนวคิดแคชมาใช้กับอิมเมจพร้อมใช้งานใน v2
• Claude Code on the web: VM แยกตามเซสชัน; พร็อกซี git ที่แยกข้อมูลประจำตัว (โทเค็นจริงไม่เคยเข้าแซนด์บ็อกซ์ และจำกัดการ push ไว้ที่ branch ของเซสชัน); สแนปช็อตระบบไฟล์หลังตั้งค่า; การส่งมอบแบบ teleport = branch ที่ push แล้ว + ประวัติที่เล่นซ้ำ เรานำการแยกข้อมูลประจำตัวและกรอบแนวคิดการส่งมอบมาใช้ แต่การซิงค์ขาออกใช้ rsync จาก Gateway เพื่อให้รองรับ working tree ที่ยังไม่สะอาด และไม่มีโทเค็นของ forge อยู่ใกล้เครื่องเลย
• Copilot coding agent: ปฏิเสธการรับส่งข้อมูลขาออกโดยปริยาย พร้อมรายการอนุญาตสำหรับรีจิสทรีแพ็กเกจ ค่าเริ่มต้นระหว่างการทำงานปกติของเราเข้มงวดยิ่งกว่า (ไม่มีการรับส่งข้อมูลขาออกโดยตรงเลย) เพราะการอนุมานและการค้นหาเว็บมาถึงผ่านอุโมงค์ SSH — แต่โปรดดูหัวข้อความปลอดภัยว่าทำไมสิ่งนี้จึงเป็น "การรับส่งข้อมูลขาออกแบบควบคุม" ไม่ใช่ "ไม่มีการรับส่งข้อมูลขาออก"

การตัดสินใจด้านสถาปัตยกรรม: ลูปอยู่บน worker การอนุมานผ่าน Gateway

มีการพิจารณาตำแหน่งการทำงานสามแบบ:

1. ลูปยังอยู่บน Gateway ส่วน worker เรียกใช้เครื่องมือ (โมเดลของ Cursor) มีโดเมนความล้มเหลวที่ปลอดภัยที่สุด (ทรานสคริปต์ การอนุมาน การอนุมัติ และการกู้คืนหลังรีสตาร์ตยังอยู่ภายในเครื่องทั้งหมด) และเป็นหมุดหมายแรกที่ผู้ตรวจสอบต้องการ ปฏิเสธไม่ให้เป็นสถาปัตยกรรมผลิตภัณฑ์: เครื่องมือที่ไม่ใช่ exec ของ OpenClaw เป็นการดำเนินการกับระบบไฟล์ภายในโปรเซส ดังนั้นการอ่าน/แก้ไข/grep ไฟล์ทุกครั้งจะกลายเป็นการเดินทางไปกลับผ่านเครือข่าย หรือจำเป็นต้องปรับโครงสร้างพื้นผิวเครื่องมือครั้งใหญ่ให้เป็น RPC สำหรับพื้นที่ทำงานแบบหยาบ พฤติกรรมของรันไทม์มีการสื่อสารถี่และถูกจำกัดด้วยเวลาแฝง เรานำแนวคิดนี้มาใช้ในจุดที่สร้างไว้แล้ว (การถ่ายโอนงาน exec ไปยัง Node) แต่จะไม่สร้างชั้นรีโมตเครื่องมือ
2. ทั้งลูปและการอนุมานอยู่บน worker มีโดเมนความล้มเหลวเรียบง่ายที่สุด แต่ต้องส่งข้อมูลประจำตัวของโมเดล (รวมถึงโปรไฟล์ OAuth) ไปยังเครื่องชั่วคราว Gateway สูญเสียการควบคุมนโยบาย/การกำหนดเส้นทาง/การตรวจสอบ และการย้ายจะเปลี่ยนตัวตนที่ใช้เรียกผู้ให้บริการ ทำให้แคชของผู้ให้บริการใช้ไม่ได้
3. ลูป + เครื่องมืออยู่บน worker และพร็อกซีการเรียกโมเดลผ่าน Gateway เลือกแบบนี้ เดินทางไปกลับหนึ่งครั้งต่อเทิร์นของโมเดลแทนที่จะเป็นต่อการเรียกเครื่องมือ; เครื่องมือทำงานใกล้กับโค้ด; Gateway ยังคงเป็นเจ้าของเพียงรายเดียวของโปรไฟล์การยืนยันตัวตน การกำหนดเส้นทางผู้ให้บริการ และนโยบาย; worker ไม่มีข้อมูลลับ

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

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

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

องค์ประกอบ

1. เครื่องสถานะสภาพแวดล้อม + สัญญาของผู้ให้บริการ

environments.* ในโปรโตคอล Gateway ปัจจุบันเป็นเพียงภาพฉายสถานะ แกนกลางที่คงทนคือระเบียนสภาพแวดล้อมและเครื่องสถานะที่ SQLite เป็นเจ้าของ ซึ่งออกแบบก่อนรูปร่างของ RPC:

requested → provisioning → bootstrapping → ready → (attached|idle) → draining → destroying → destroyed | failed | orphaned

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

สัญญาของผู้ให้บริการ (ดำเนินการโดย Plugin; ไม่มีชื่อผู้ให้บริการหรือนโยบายในแกนกลาง):

type WorkerProvider = {  id: string;  provision(profile: WorkerProfile, opId: string): Promise&lt;WorkerLease&gt;; // → ssh host/port/user/key material  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise&lt;LeaseStatus&gt;; // adopt/health/orphan sweep  renew?(leaseId: string): Promise<void>; // long-lived sessions vs provider TTLs  destroy(lease: { leaseId: string; profile: WorkerProfile }): Promise<void>; // idempotent, returns only on proof of teardown};

RPC: environments.create, environments.destroy, และ environments.list/status แบบขยาย (ผู้ให้บริการ, รหัสการเช่า, สถานะ, อายุ, เวลาว่าง, เซสชันที่เชื่อมอยู่) ผู้ให้บริการชุดแรก: ตัวครอบ CLI สำหรับการเช่าในรูปแบบ Crabbox (เส้นทางผลิตภัณฑ์) และผู้ให้บริการโฮสต์ SSH แบบคงที่ที่ทำเครื่องหมายว่าสำหรับการพัฒนาเท่านั้น — worker บนโฮสต์ที่ใช้ร่วมกันสามารถอ่านข้อมูลอื่นที่ไม่เกี่ยวข้องบนโฮสต์ได้ ดังนั้นโฮสต์แบบคงที่จึงใช้สำหรับพัฒนาคุณลักษณะ ไม่ใช่แนวทางเริ่มต้น

2. การเริ่มต้น worker: ติดตั้ง OpenClaw บนเครื่อง

ไม่มีอาร์ติแฟกต์ worker ที่สร้างขึ้นเฉพาะ และไม่พึ่งพาความพร้อมใช้งานของ npm:

• การติดตั้งมาตรฐานสำหรับทุกโหมด: บันเดิล worker ที่ Gateway สร้างและแฮชตามเนื้อหา (ผลลัพธ์บิลด์ของ Gateway เองที่แพ็กเป็น tarball) ส่งผ่าน SSH และติดตั้งบนเครื่อง วิธีนี้ครอบคลุมบิลด์สำหรับการพัฒนาและ commit ที่ยังไม่เผยแพร่โดยโครงสร้าง
• npm i -g openclaw@<exact gateway version> เป็นการปรับให้เหมาะสมเมื่อ Gateway ใช้เวอร์ชันที่เผยแพร่แล้ว; ห้ามใช้ latest
• การเริ่มต้นทำซ้ำได้อย่างปลอดภัย; การเช่าที่พร้อมใช้งานซึ่งมีแฮชบันเดิลตรงกันจะข้ามการติดตั้ง เครื่องเปล่าอาจต้องมีระยะชุดเครื่องมือที่เชื่อมต่อเครือข่าย (รันไทม์ Node) — เป็นส่วนหนึ่งของระยะตั้งค่า และจะปิดเครือข่ายภายหลัง
• การจับมือตรวจสอบแฮชบิลด์ของ worker ชุดคุณลักษณะของโปรโตคอล และความเข้ากันได้ของรันไทม์ การตรวจสอบเวอร์ชัน/โปรโตคอลของ Gateway ที่มีอยู่ไม่เพียงพอสำหรับกรณีนี้ (Node ที่เชื่อมผ่านอุโมงค์ SSH ได้รับการยกเว้นจากการปฏิเสธเมื่อเวอร์ชันไม่ตรงกันทุกประการ) ดังนั้นการรับ worker จึงตรวจสอบบิลด์ที่ตรงกันทุกประการด้วยตนเอง

โหมด worker (openclaw worker) เป็นจุดเริ่มต้น ไม่ใช่ fork: การจัดการการเชื่อมต่อร่วมกับตัวรันเอเจนต์แบบฝัง โดยมีการเก็บเซสชันถาวรและการเรียกโมเดลที่มี RPC ของ Gateway รองรับ โหมดนี้ต้องไม่เริ่มพื้นผิวของ Gateway: ไม่มีช่องทาง ไม่มีการเริ่ม Plugin อัตโนมัตินอกเหนือจากชุดเครื่องมือของเซสชัน ใช้ไดเรกทอรีสถานะชั่วคราว และไม่มีโปรไฟล์การยืนยันตัวตนภายในเครื่อง

3. การรับส่งข้อมูล: ทุกอย่างผ่าน SSH

Gateway เป็นเจ้าของการเชื่อมต่อ; worker ไม่ต้องมีสิ่งใดนอกจาก sshd:

• Gateway เปิด SSH ไปยัง worker (ข้อมูลประจำตัวจากการเช่าของผู้ให้บริการ โดยตรึงคีย์โฮสต์จากผลลัพธ์การจัดเตรียม — ไม่ใช้ StrictHostKeyChecking=no) และสร้างอุโมงค์ย้อนกลับที่ส่งต่อซ็อกเก็ตภายใน worker ไปยังปลายทาง WS ของ Gateway
• ทราฟฟิกควบคุม/โมเดลและการถ่ายโอนพื้นที่ทำงานใช้การเชื่อมต่อ SSH แยกกัน โดยใช้ข้อมูลความเชื่อถือที่ตรึงไว้ชุดเดียวกัน เพื่อไม่ให้ rsync ปิดกั้นสตรีมโทเค็นที่หัวคิว
• วงจรชีวิตของอุโมงค์ (keepalive, เชื่อมต่อใหม่พร้อมการหน่วงเวลาแบบเพิ่มขึ้น) เป็นความรับผิดชอบของรันไทม์สภาพแวดล้อมบน Gateway การสะดุดของอุโมงค์จะไม่ปรากฏในระดับเซสชัน: สถานะโปรโตคอลที่คงทน (ด้านล่าง) ช่วยให้ worker เชื่อมต่อกลับและทำงานต่อได้

4. โปรโตคอล worker (เฉพาะทาง; ไม่ใช่โปรโตคอล Node)

การตรวจสอบเชิงปฏิปักษ์เทียบกับรอยต่อ Node ปัจจุบันตัดความเป็นไปได้ในการนำมาใช้ซ้ำโดยตรง: การเรียก Node ที่รอดำเนินการเป็นพรอมิสภายในโปรเซสซึ่งจะหายไปพร้อมการเชื่อมต่อ, คีย์การทำซ้ำอย่างปลอดภัยของ Node ถูกแยกวิเคราะห์แต่ไม่มีการขจัดรายการซ้ำ และ — ที่ชี้ขาด — Node ที่เชื่อมต่อสามารถส่งเหตุการณ์ Node ปกติได้ (รวมถึงคำขอเรียกใช้เอเจนต์) ดังนั้น "ชนิด Node + เพดานความสามารถ" จึงไม่ใช่ขอบเขตความปลอดภัยของข้อมูลขาเข้า ด้วยเหตุนี้ worker จึงได้รับบทบาท worker ที่ผ่านการยืนยันตัวตน พร้อมรายการอนุญาต RPC/เหตุการณ์แบบปิดและมีการกำหนดเวอร์ชัน; การเชื่อมต่อ worker ไม่สามารถเข้าถึงตัวจัดการเหตุการณ์ Node แบบเดิมใด ๆ

ตัวตนและข้อมูลประจำตัว: การจัดเตรียมจะสร้างข้อมูลประจำตัว worker อายุสั้นที่ผูกกับรหัสสภาพแวดล้อม คีย์ worker แฮชบันเดิล เซสชันเดียวที่อนุญาต ชุด RPC ที่อนุญาต และเวลาหมดอายุ การจับคู่ที่ตรวจสอบด้วย SSH ยังคงมีผล (เราเป็นผู้จัดเตรียมเครื่องและถือคีย์) แต่การอนุญาตมาจากข้อมูลประจำตัวที่สร้างขึ้น ไม่ใช่จากพื้นผิว Node ที่ประกาศ

ความหมายของการดำเนินการแบบคงทน (รูปร่างนำมาจากรันไทม์ ACP ที่มีอยู่และบัญชีบันทึกเหตุการณ์ของรันไทม์ — แฮนเดิลที่เสถียร, การทำงานแบบอนุกรมต่อเซสชัน, การเล่นซ้ำ (session, seq) แบบคงทน):

• ทุกการดำเนินการอยู่ในขอบเขต (sessionId, lifecycleRevision, runId, ownerEpoch, streamKind, seq)
• ยุคความเป็นเจ้าของใช้กั้น worker ที่ล้าสมัย: worker ทดแทนจะเลื่อนยุคไปข้างหน้า; ผลลัพธ์ที่มาช้าจากยุคเก่าจะถูกปฏิเสธแบบกำหนดแน่นอน
• ส่งอย่างน้อยหนึ่งครั้ง พร้อมเคอร์เซอร์ ACK ที่บันทึกถาวรและผลลัพธ์สุดท้ายที่แคชใน SQLite; การขจัดรายการซ้ำเป็นแบบกำหนดแน่นอน ไม่มีการรับประกันว่าจะดำเนินการเพียงครั้งเดียวอย่างแท้จริง
• มีเฟรมชัดเจนสำหรับการยกเลิก ปิด ทำต่อ และผลลัพธ์สุดท้าย; ใช้การควบคุมการไหลตามเครดิต/ขนาดหน้าต่างบนสตรีม
• การเจรจาชุดคุณลักษณะของโปรโตคอลเป็นอิสระจากเวอร์ชันโปรโตคอล Node ทั่วไป

5. RPC แบ็กเอนด์เซสชัน

สัญญาสองแบบที่แยกจากกัน — โค้ดเบสปัจจุบันแยกการเปลี่ยนแปลงทรานสคริปต์แบบคงทน (อยู่ภายใต้การดูแลของตัวจัดการเซสชัน เป็นโครงสร้างต้นไม้ JSONL ที่มีสถานะพาเรนต์/ลีฟ) ออกจากเหตุการณ์สดภายในโปรเซส (เดลตาแบบสตรีม วงจรชีวิตเครื่องมือ การอนุมัติ) และโปรโตคอลของเวิร์กเกอร์ต้องคงการแยกนี้ไว้:

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

พร็อกซีการอนุมาน: ใช้คำศัพท์เหตุการณ์ของไคลเอนต์สตรีมพร็อกซีรันไทม์ที่มีอยู่ (src/agents/runtime/proxy.ts) ซ้ำ แต่ย้ายขอบเขตความเชื่อถือ เวิร์กเกอร์ส่งเฉพาะข้อมูลประจำตัวของเซสชัน/รัน การอ้างอิงโมเดลที่ได้รับอนุมัติ บริบท และตัวเลือกการสร้างที่ถูกจำกัด ส่วน Gateway จะจำแนกผู้ให้บริการ เอนด์พอยต์ การยืนยันตัวตน เฮดเดอร์ การกำหนดเส้นทาง และนโยบายค่าใช้จ่ายจากแค็ตตาล็อกของตนเอง ออบเจ็กต์โมเดลที่เวิร์กเกอร์ระบุ (เช่น baseUrl ที่ผู้โจมตีควบคุม) จะถูกปฏิเสธ ใช้ข้อจำกัดขนาดคำขอ การยกเลิก การตรวจสอบย้อนหลัง และการเล่นซ้ำผลลัพธ์สุดท้าย เครื่องมือที่อยู่บน Gateway (websearch) จะทำงานบน Gateway และส่งผลลัพธ์กลับผ่านช่องทางเดียวกัน

6. การซิงค์พื้นที่ทำงาน

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

การแบ่งความเป็นเจ้าของ — คอมมิตกับเผยแพร่:

• เอเจนต์ฝั่งเวิร์กเกอร์สร้างคอมมิตตามปกติในสำเนาของตน (git commit เป็นการดำเนินการภายในที่ไม่ต้องใช้ข้อมูลประจำตัว โดยข้อมูลผู้เขียนจะถูกฉายมาจากการกำหนดค่าของ Gateway) คอมมิตเหล่านั้นเป็นออบเจ็กต์ที่ยังไม่มีผลจนกว่า Gateway จะรับมาใช้
• Gateway ดำเนินการทุกอย่างที่ต้องอาศัยความเชื่อถือ: ตรวจสอบว่าคอมมิตขาเข้าต่อยอดจากฐานที่บันทึกไว้ เลื่อนเวิร์กทรีภายในแบบกรอไปข้างหน้า พุช สร้าง PR และลงนาม/ลงนามใหม่หากเลือกใช้ — ทั้งหมดใช้ข้อมูลประจำตัวภายใน Gateway เวิร์กเกอร์จะไม่มีข้อมูลประจำตัวของ git หรือแพลตฟอร์มโฮสต์ซอร์สโค้ด และจะไม่ติดต่อรีโมต

มีโหมดการซิงค์สองแบบ โดยเลือกตามว่าพื้นที่ทำงานเป็นที่เก็บ git หรือไม่:

• โหมด Git ขาออก: ใช้ rsync กับเวิร์กทรี (รวมไฟล์ที่ยังไม่คอมมิตและไฟล์ที่ยังไม่ถูกติดตามซึ่งเข้าเกณฑ์ ใช้กฎรวม/ยกเว้นแบบ crabbox และเคารพ .worktreeinclude) ผ่านข้อมูลประจำตัว SSH ของทันเนล แล้วบันทึกเป็นแมนิเฟสต์ฐานที่แก้ไขไม่ได้ (แฮชเนื้อหา + คอมมิตฐาน) ขาเข้า: คอมมิตใหม่ส่งกลับมาเป็นบันเดิล git หรือการอ้างอิงชั่วคราวเทียบกับฐานที่บันทึกไว้ ส่วนอาร์ติแฟกต์ที่ยังไม่ถูกติดตามส่งกลับมาผ่านแมนิเฟสต์ที่ระบุชัดเจน พร้อมการตรวจสอบขนาด/ชนิด/การจำกัดซิมลิงก์ให้อยู่ภายในขอบเขต ขั้นตอนการรับมาใช้จะตรวจสอบลำดับบรรพบุรุษของฐานและหยุดเมื่อเกิดการแยกสาย — ไม่มีสิ่งใดเขียนทับข้อมูลของฝ่ายใดอย่างเงียบ ๆ การลบ การเปลี่ยนชื่อ ซับโมดูล และซิมลิงก์ที่หลุดออกนอกขอบเขตจะจัดการด้วยกฎของแมนิเฟสต์ ไม่ใช่การคาดเดาของ rsync
• โหมดธรรมดา (ไม่มี git — เช่น การสร้างโปรเจกต์ใหม่ตั้งแต่ต้นบนเครื่อง) ขาออกใช้ rsync + แมนิเฟสต์ฐานแบบเดียวกัน ขาเข้าเป็นการมิเรอร์กลับตามความแตกต่างของแมนิเฟสต์ไปยังไดเรกทอรีเป้าหมายที่ Gateway เป็นเจ้าของ พร้อมส่งต่อการลบ เหตุผลที่ปลอดภัยเหมือนโหมด git คือ ความเป็นเจ้าของแต่เพียงผู้เดียวหมายความว่าไม่มีการแก้ไขภายในพร้อมกันให้เกิดข้อขัดแย้ง และแมนิเฟสต์ฐานยังคงตรวจพบการเปลี่ยนแปลงภายในที่ไม่คาดคิดและหยุดแทนที่จะเขียนทับ

การสร้างจุดตรวจปกป้องเซสชันที่ทำงานหลายวันจากการสูญเสียลีส: สร้างจุดตรวจขาเข้าเป็นระยะ (คอมมิตในแบรนช์เซสชันสำหรับโหมด git และสแนปช็อตแมนิเฟสต์สำหรับโหมดธรรมดา) โดยความถี่เป็นนโยบายของโปรไฟล์ (ค่าเริ่มต้นอิงตามเทิร์น)

7. สเตตแมชชีนการจัดวาง เซสชัน และ UI

การจัดวางรันไทม์เป็นสเตตแมชชีนที่ SQLite เป็นเจ้าของและผูกกับเซสชัน ไม่ใช่ฟิลด์สองช่องในแถวที่แยกจากกัน:

ภายใน → ร้องขอแล้ว → กำลังจัดเตรียม → กำลังซิงค์ → กำลังเริ่ม → ทำงานอยู่(เวิร์กเกอร์) → กำลังระบาย → กำลังกระทบยอด → ภายใน | ถูกเรียกคืน | ล้มเหลว

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

UI:

• เซสชันเวิร์กเกอร์คือแถวเซสชันปกติพร้อมเมทาดาทาการจัดวาง โดยอยู่ในที่เก็บปกติ แสดงรายการผ่าน sessions.list และสตรีมผ่านการสมัครรับข้อมูลที่มีอยู่ — แถบด้านข้างและแชตไม่ต้องมีเส้นทางข้อมูลใหม่ มีเพียงการนำเสนอเพิ่มเติม ได้แก่ ป้ายเวิร์กเกอร์และสถานะการจัดวาง/สภาพแวดล้อม (กำลังจัดเตรียม / กำลังซิงค์ / กำลังทำงาน / ไม่ได้ใช้งาน / กำลังกระทบยอด / ถูกเรียกคืน)
• ประสบการณ์การสร้าง: แถบเป้าหมายเซสชัน (การออกแบบแถบด้านข้างของเซสชันใหม่) เพิ่มปลายทางเวิร์กเกอร์บนคลาวด์ควบคู่กับ Gateway และ Node ต้องมีโปรไฟล์ผู้ให้บริการที่กำหนดค่าไว้ และฟีเจอร์นี้จะไม่ปรากฏจนกว่าจะกำหนดค่า
• การส่งงานของเอเจนต์: เครื่องมือเซสชันช่วยให้เอเจนต์ส่งมอบงานให้เวิร์กเกอร์บนคลาวด์ได้เช่นเดียวกับมนุษย์ (เซสชันย่อยที่รองรับด้วยเวิร์กเกอร์ในรูปแบบซับเอเจนต์) เปิดตัวในไมล์สโตนเดียวกับการส่งงานโดยมนุษย์ และควบคุมด้วยการกำหนดค่าผู้ให้บริการแบบเลือกรับชุดเดียวกัน การเรียกซ้ำถูกจำกัดด้วยโครงสร้าง (เซสชันเวิร์กเกอร์ไม่สามารถส่งงานให้เวิร์กเกอร์อื่นได้ใน v1) การควบคุมค่าใช้จ่ายใช้การบันทึกบัญชี/การตรวจสอบย้อนหลังแยกตามสภาพแวดล้อม ไม่ใช่กลไกโควตา

การส่งงานและส่งมอบ

v1 จงใจออกแบบให้ไม่สมมาตร:

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

แบริเออร์การย้าย ("ขอบเขตเทิร์น" เพียงอย่างเดียวไม่เพียงพอ — การอนุมัติ โปรเซสเบื้องหลัง และการผสานทรานสคริปต์หลังปล่อยล็อกอาจคร่อมขอบเขตนี้):

1. หยุดรับเทิร์นใหม่ (อ้างสิทธิ์การจัดวาง)
2. ยกเลิกหรือระบายรันที่ทำงานอยู่
3. เพิกถอนการอนุมัติ exec และสิทธิ์การดำเนินการที่รอดำเนินการ
4. ระบายการเขียนทรานสคริปต์ด้านข้างและ ACK ของเหตุการณ์สด
5. ยุติโปรเซสลูกของเวิร์กเกอร์
6. กั้นเจ้าของเดิมโดยเลื่อนเอพ็อกของเจ้าของ
7. กระทบยอดพื้นที่ทำงาน (ขาเข้า โดยรับรู้ข้อขัดแย้ง)
8. เปิดใช้งานเจ้าของใหม่

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

โมเดลความปลอดภัย

กล่าวอย่างแม่นยำ: เวิร์กเกอร์ไม่มีการส่งทราฟฟิกออกสู่เครือข่ายโดยตรงและไม่มีข้อมูลประจำตัวของผู้ให้บริการ/แพลตฟอร์มโฮสต์ซอร์สโค้ดแบบถาวร แต่ไม่ใช่ "ไม่มีทราฟฟิกขาออกเลย" — การอนุมานและเครื่องมือที่ทำงานบน Gateway เป็นช่องทางขาออกที่ควบคุมได้ (เวิร์กเกอร์ที่ถูกฉีดพรอมป์ยังคงสามารถใส่ไบต์จากพื้นที่ทำงานลงในบริบทของโมเดลหรือคำค้น websearch ได้) ดังนั้น:

• การบันทึกบัญชีของทราฟฟิกขาออกที่ควบคุม: มีการตรวจสอบย้อนหลังแยกตามสภาพแวดล้อมและการบันทึกบัญชีที่ผู้ปฏิบัติงานมองเห็นได้บนพร็อกซีการอนุมานและเครื่องมือของ Gateway ขีดจำกัดอัตรา/ไบต์มีไว้เป็นการควบคุมโฟลว์ของโปรโตคอล (ความจุ) ไม่ใช่กลไกโควตาค่าใช้จ่าย
• ทราฟฟิกขาเข้าจากเวิร์กเกอร์ไปยัง Gateway จำกัดอยู่ในรายการที่อนุญาตแบบปิดของโปรโตคอลเวิร์กเกอร์ การเขียนทรานสคริปต์ถูกจำกัดเชิงโครงสร้าง (รหัสที่ Gateway สร้าง และผูกกับเซสชันเดียว)
• exec ของเวิร์กเกอร์มีสิทธิ์เต็มภายในเครื่อง เครื่องเป็นแบบใช้แล้วทิ้งและไม่มีข้อมูลประจำตัว ดังนั้นการอนุมัติแยกแต่ละคำสั่งจึงเพิ่มความยุ่งยากโดยไม่ปกป้องสิ่งใด ขอบเขตที่ได้รับการคุ้มครองคือการกระทบยอดขาเข้าและการตรวจสอบย้อนหลัง exec จะไม่ผ่านเส้นทางการอนุมัติ Node ของ Gateway
• นโยบายอินเทอร์เน็ตเป็นการตัดสินใจของผู้ให้บริการในเวลาจัดเตรียม: โปรไฟล์สภาพแวดล้อมจะตัดสินใจขณะสร้างเครื่อง (ไฟร์วอลล์/กลุ่มความปลอดภัย/เครือข่ายที่ไม่มีทราฟฟิกขาออก) และอาจมีระยะตั้งค่าที่เชื่อมต่อเครือข่ายซึ่งผู้ให้บริการจะปิดก่อนเข้าสู่ระยะเอเจนต์ Core จะไม่สร้างสวิตช์เครือข่ายขณะรันไทม์
• สุขอนามัยของเครื่องขณะจัดเตรียม: บล็อกเอนด์พอยต์เมทาดาทาบนคลาวด์หรือตรวจสอบว่าไม่มีอยู่ ไม่มีโปรไฟล์อินสแตนซ์ ไม่มีเอเจนต์ SSH ที่รับช่วงมา ไม่มีซ็อกเก็ต Docker และใช้สภาพแวดล้อม/โฮมที่สะอาด คีย์โฮสต์ SSH ถูกตรึงจากเอาต์พุตการจัดเตรียม
• การอนุมัติและนโยบายสำหรับทุกสิ่งที่อยู่ฝั่ง Gateway (พุช PR การเรียกผู้ให้บริการ) ยังคงทำงานบน Gateway

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

ความจุ

Gateway ถ่ายทอดพรอมป์และสตรีมโทเค็นทั้งหมดสำหรับเวิร์กเกอร์ N ตัว ดังนั้น v1 จึงกำหนดโมเดลความจุไว้แทนที่จะไปรับรู้ในระบบจริง: ขีดจำกัดเวิร์กเกอร์พร้อมกันต่อ Gateway หน้าต่างเครดิตต่อสตรีม (คิวสตรีมเหตุการณ์ปัจจุบันไม่มีขอบเขต และเพดานบัฟเฟอร์ซ็อกเก็ตของ Node จะบังคับปิดผู้บริโภคที่ช้า — ทั้งสองแบบไม่เหมาะหากนำมาใช้โดยไม่แก้ไข) การพักข้อมูลลงดิสก์แบบมีขอบเขตสำหรับช่วงพุ่งสูง และการลดโหลดพร้อมสถานะแรงดันย้อนกลับที่มองเห็นได้ใน UI การถ่ายโอนพื้นที่ทำงานยังคงใช้ช่องทาง SSH แยกต่างหาก

วงจรชีวิต

• การหยุดอัตโนมัติเมื่อไม่ได้ใช้งานและ TTL เป็นนโยบายของโปรไฟล์ผู้ให้บริการ ไม่ใช่ค่าคงที่ ค่าเริ่มต้นผ่อนปรนพร้อมการคงการทำงานที่ระบุชัดเจน งานหลายวันถือเป็นกรณีใช้งานหลัก (มี renew ของผู้ให้บริการสำหรับแบ็กเอนด์ที่ใช้ลีส) เซสชันที่มีเทิร์นกำลังดำเนินการหรือมีกิจกรรมล่าสุดจะไม่ถูกเรียกคืน
• เมื่อเวิร์กเกอร์หยุดทำงานหรือถูกเรียกคืน: การจัดวางจะเปลี่ยนเป็น reclaimed แถวเซสชันยังคงอยู่ ข้อความถัดไปจะจัดเตรียมเวิร์กเกอร์ใหม่และซิงค์อีกครั้งจากจุดตรวจล่าสุด การสนทนาจะไม่สูญหาย (อยู่ในที่เก็บฝั่ง Gateway) การเปลี่ยนแปลงพื้นที่ทำงานนับจากจุดตรวจล่าสุดจะสูญหาย และ UI จะแจ้งให้ทราบ
• รองรับการนำลีสที่ยังอุ่นกลับมาใช้ตั้งแต่วันแรก (สำหรับผู้ให้บริการที่รองรับ) การสร้างสแนปช็อตอิมเมจหลังบูตสแตรปเป็นเส้นทางเริ่มต้นอย่างรวดเร็วของ v2

พื้นผิวการกำหนดค่า

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

ไมล์สโตน

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

1. รากฐาน: สเตตแมชชีนสภาพแวดล้อม + สัญญาผู้ให้บริการ + ผู้ให้บริการรูปแบบ crabbox (ใช้ static-SSH เป็นชุดทดสอบสำหรับการพัฒนา) บูตสแตรปบันเดิลเวิร์กเกอร์ + แฮนด์เชกรับเข้า ทันเนล SSH + การตรึงคีย์โฮสต์ สแนปช็อตเวิร์กทรีที่มีการจัดการ + การซิงค์ขาออก (โหมด git + โหมดธรรมดา) การกวาดทรัพยากรกำพร้า + การรับช่วงหลังรีสตาร์ต
2. โปรโตคอลเวิร์กเกอร์ + ลูปเวิร์กเกอร์: บทบาทเวิร์กเกอร์ที่ยืนยันตัวตนแล้ว การดำเนินการแบบคงทน/เอพ็อก/เคอร์เซอร์ ACK สัญญาการคอมมิตทรานสคริปต์ + เหตุการณ์สด พร็อกซีการอนุมานพร้อมโมเดลที่ Gateway จำแนก การควบคุมโฟลว์ ผู้ให้บริการหนึ่งราย การส่งงานเซสชันใหม่โดยมนุษย์เท่านั้น ไม่มีการส่งมอบ ต้องผ่านการทดสอบแทรกข้อผิดพลาด (ทันเนลถูกตัดขาด Gateway รีสตาร์ต เวิร์กเกอร์หยุดทำงาน) ก่อนจบไมล์สโตน
3. การส่งงาน + ดึงกลับ + การส่งงานของเอเจนต์: แบริเออร์การย้าย สเตตแมชชีนการจัดวางที่เชื่อมกับแถบเป้าหมายใน UI การกระทบยอดขาเข้า + จุดตรวจ การตรวจสอบย้อนหลังแยกตามสภาพแวดล้อม ขีดจำกัดความจุ เครื่องมือส่งงานของเอเจนต์ (เซสชันเวิร์กเกอร์ไม่สามารถเรียกซ้ำได้) การทดสอบความเทียบเท่าระดับไบต์ของแคชพรอมป์
4. การส่งมอบแบบสดที่สมมาตร หลังจากมีหลักฐานจากการทดสอบแทรกข้อผิดพลาดของไมล์สโตน 3

ภายหลัง: ชุดทดสอบ ACP บนเวิร์กเกอร์ในรูปแบบการเติมข้อมูลประจำตัวแบบเลือกรับแยกตามสภาพแวดล้อม การเริ่มต้นอย่างรวดเร็วด้วยสแนปช็อต/อิมเมจอุ่น การกระจายงาน (N ลีส พรอมป์เดียวกัน) แซนด์บ็อกซ์ระดับระบบปฏิบัติการภายในเครื่อง และการเก็บอาร์ติแฟกต์ที่สมบูรณ์ยิ่งขึ้นผ่านสคีมาอาร์ติแฟกต์

คำถามที่ยังเปิดอยู่

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