---
read_when:
    - การออกแบบหรือการติดตั้งใช้งานการจัดเตรียมเวิร์กเกอร์บนคลาวด์ โหมดเวิร์กเกอร์ หรือการส่งต่อเซสชัน
    - การเปลี่ยนแปลง environments.*, โปรโตคอลของเวิร์กเกอร์, การนำเข้าบันทึกการสนทนา หรือ RPC ของพร็อกซีการอนุมาน
    - การตรวจสอบสถานะความปลอดภัยของการเรียกใช้เอเจนต์จากระยะไกล
summary: เรียกใช้เซสชันเอเจนต์บนเครื่องชั่วคราวที่เข้าถึงได้ผ่าน SSH โดยอนุมานผลผ่านพร็อกซีของ Gateway และสตรีมแบบเรียลไทม์ในแถบด้านข้าง
title: แผนเวิร์กเกอร์บนคลาวด์
x-i18n:
    generated_at: "2026-07-12T16:21:35Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 134c3f6e486837607225d95d12a3153525b14237b362b9f9957313d9bc379dc4
    source_path: plan/cloud-workers.md
    workflow: 16
---

## สถานะ

ข้อเสนอ ฉบับแก้ไขครั้งที่ 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; ไม่มีชื่อผู้ให้บริการหรือนโยบายในแกนกลาง):

```ts
type WorkerProvider = {
  id: string;
  provision(profile: WorkerProfile, opId: string): Promise<WorkerLease>; // → ssh host/port/user/key material
  inspect(lease: { leaseId: string; profile: WorkerProfile }): Promise<LeaseStatus>; // 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 จะเป็นส่วนหนึ่งของการจับมือเพื่ออนุญาตเข้าร่วม)
- รอบเริ่มต้นของการสร้างจุดตรวจสอบ: อิงตามรอบการโต้ตอบเทียบกับอิงตามเวลา สำหรับเซสชันที่มีการสนทนาถี่มาก
- วิธีที่โปรไฟล์สภาพแวดล้อมทำงานร่วมกับการกำหนดเส้นทางแบบหลายเอเจนต์ (โปรไฟล์เริ่มต้นต่อเอเจนต์เทียบกับการเลือกเฉพาะต่อเซสชัน)