Google เปิดซอร์ส Scion แพลตฟอร์มทดสอบการออร์เคสตราเอเจนต์เชิงทดลอง

• แพลตฟอร์มเชิงทดลองที่ออกแบบมาเพื่อจัดการเอเจนต์ที่อิง LLM ซึ่งรันพร้อมกันภายในคอนเทนเนอร์ ครอบคลุมทั้งเครื่องโลคัลและคลัสเตอร์ระยะไกล
• เอเจนต์แต่ละตัวทำงานเป็นโปรเซสที่แยกออกจากกัน พร้อม ตัวตน ข้อมูลรับรอง และเวิร์กสเปซที่เป็นอิสระ เพื่อขับเคลื่อนเป้าหมายหลากหลายแบบ เช่น การเขียนโค้ด การตรวจสอบ และการทดสอบ แบบไดนามิกและขนานกัน
• ถูกนิยามว่าเป็น "ไฮเปอร์ไวเซอร์สำหรับเอเจนต์" และเลือกแนวคิดการแยกจากภายนอกด้วยคอนเทนเนอร์, git worktree และนโยบายเครือข่าย แทนการฉีดกฎพฤติกรรมเข้าไปในคอนเท็กซ์
• ผสานเอเจนต์หลักอย่าง Gemini CLI, Claude Code, OpenCode และ Codex ผ่านอะแดปเตอร์ harness และรองรับ Docker, Podman, Apple Container และ Kubernetes เป็นรันไทม์
• ติดตามวงจรชีวิตเอเจนต์ (Phase), พฤติกรรมปัจจุบัน (Activity) และสถานะรายละเอียด (Detail) ด้วย โมเดลสถานะ 3 มิติ พร้อมสาธิตสถานการณ์การทำงานร่วมกันผ่านโค้ดเบสเกมเดโม

---

Scion คืออะไร?

• แพลตฟอร์มทดสอบการออร์เคสตราเชิงทดลองสำหรับ กลุ่มเอเจนต์ที่อิง LLM ซึ่งรันพร้อมกันในคอนเทนเนอร์ และจัดการได้ครอบคลุมทั้งเครื่องโลคัล, VM ระยะไกล และ Kubernetes cluster
• มอบตัวตน ข้อมูลรับรอง และเวิร์กสเปซที่เป็นอิสระให้แต่ละเอเจนต์ เพื่อรันเป้าหมายที่ต่างกัน เช่น รีเสิร์ช การเขียนโค้ด การตรวจสอบ และการทดสอบ ในรูปแบบ กราฟงานแบบขนานที่พัฒนาเปลี่ยนแปลงได้แบบไดนามิก
• Google นิยาม Scion ว่าเป็น "ไฮเปอร์ไวเซอร์สำหรับเอเจนต์" โดยรวมหน่วยความจำเอเจนต์ ห้องแชต และการจัดการงานเข้าไว้เป็นประเด็นที่แยกอิสระต่อกัน (orthogonal)

ปรัชญาการออกแบบหลัก: แยกให้ชัด มากกว่าจำกัดพฤติกรรม

• แทนที่จะจำกัดพฤติกรรมเอเจนต์ด้วยกฎ จะสร้างความปลอดภัยผ่านขอบเขตระดับอินฟราฯ เช่น คอนเทนเนอร์, git worktree และนโยบายเครือข่าย
• เอเจนต์สามารถรันได้อย่างอิสระในโหมด --yolo โดยมี เลเยอร์การแยก ทำหน้าที่เป็นราวกันตกจากภายนอก
• แนวทางนี้ทำให้ไม่จำเป็นต้องฉีดกฎที่ซับซ้อนเข้าไปในคอนเท็กซ์ของเอเจนต์ จึงช่วยให้เอเจนต์โฟกัสกับงานของตัวเองได้เต็มที่

แนวคิดหลัก (อภิธานศัพท์)

Scion ใช้ระบบคำศัพท์เฉพาะของตนเอง ดังนั้นควรเข้าใจแนวคิดต่อไปนี้ก่อน

• Agent: โปรเซสที่แยกออกจากกันซึ่งรันลูป LLM + Harness เป็นหน่วยปฏิบัติการพื้นฐานของ Scion และมีตัวตน ข้อมูลรับรอง และเวิร์กสเปซเป็นของตัวเอง
• Grove: เวิร์กสเปซโปรเจกต์ที่เอเจนต์อาศัยอยู่ สอดคล้องกับไดเรกทอรี .scion ในระบบไฟล์ และอาจอยู่ที่รากของ git repository หรือโฮมโฟลเดอร์ของผู้ใช้
  • Grove แบบอิง git ใช้ UUID v5 (สร้างแบบกำหนดแน่นอนจาก URL ของ repository) ส่วน Grove แบบเนทีฟของ Hub ใช้ UUID v4
• Hub: คอนโทรลเพลนส่วนกลาง ของสถาปัตยกรรม Scion แบบโฮสต์ ทำหน้าที่เป็น "สมอง" ที่ประสานสถานะระหว่างผู้ใช้, Grove และ runtime broker
  • จัดการตัวตนและการยืนยันตัวตนด้วย OAuth, เก็บสถานะของเอเจนต์/Grove/เทมเพลตไว้ในฐานข้อมูลส่วนกลาง, กระจายคำสั่งตามวงจรชีวิต และให้มุมมองการทำงานร่วมกันผ่าน Web Dashboard
• Profile: ข้อกำหนดสภาพแวดล้อมการรัน ที่นิยามโดยผูกการตั้งค่า runtime กับ Harness เข้าด้วยกัน เช่น "Local Docker" หรือ "Production Kubernetes" โดยสามารถสลับสภาพแวดล้อมได้ด้วยการเปลี่ยน Profile โดยไม่ต้องแก้เทมเพลต
• Harness: อะแดปเตอร์ ที่ผสานเครื่องมือ LLM เฉพาะอย่าง Gemini CLI, Claude Code และ Codex เข้ากับระบบนิเวศของ Scion เพื่อให้คำสั่งทั่วไปของ Scion เช่น start, stop, attach, resume ทำงานอย่างสม่ำเสมอไม่ว่าเอเจนต์จะเป็นตัวใด
• Template: พิมพ์เขียวสำหรับการสร้างเอเจนต์ ใช้กำหนดค่าพื้นฐาน, system prompt และเครื่องมือต่าง ๆ และเก็บไว้ที่ .scion/templates/
  • นอกจากเทมเพลตที่มีมาให้ (gemini, claude, opencode, codex) ยังสามารถสร้าง เทมเพลตบทบาทแบบกำหนดเอง เช่น "ผู้ตรวจสอบความปลอดภัย" หรือ "ผู้เชี่ยวชาญ React" ได้
• Runtime: เลเยอร์อินฟราสตรักเจอร์ที่ใช้รันคอนเทนเนอร์ของเอเจนต์ รองรับ Docker, Podman, Apple Container และ Kubernetes
• Runtime Broker: โหนดคอมพิวต์ (เซิร์ฟเวอร์, แล็ปท็อป, K8s cluster) ที่ลงทะเบียนกับ Hub เพื่อให้ความสามารถด้านการรัน ทำหน้าที่จัดการวงจรชีวิตเอเจนต์ ซิงก์เวิร์กสเปซ และสตรีมล็อก

สถาปัตยกรรม: โครงสร้าง Manager-Worker

• scion CLI: เครื่องมือฝั่งโฮสต์สำหรับออร์เคสตราวงจรชีวิตเอเจนต์ พร้อมฟังก์ชันจัดการ Grove (เวิร์กสเปซโปรเจกต์) และจัดการเทมเพลต (scion templates)
• Agents: รันซอฟต์แวร์เอเจนต์อย่าง Gemini CLI, Claude Code และ Codex ภายในคอนเทนเนอร์รันไทม์ที่แยกจากกัน เช่น Docker
• ลำดับการใช้งานพื้นฐาน:
  1. scion init — สร้างไดเรกทอรี .scion ที่รากโปรเจกต์
  2. scion start <agent-name> "<task>" — เริ่มรันเอเจนต์
  3. scion attach <agent-name> — เชื่อมต่อเข้าเซสชันของเอเจนต์แบบอินเทอร์แอ็กทีฟ หรือดูเอาต์พุตด้วย scion logs
  4. scion resume <agent-name> — เริ่มเอเจนต์ที่หยุดไว้ใหม่โดยคงสถานะเดิม

กลยุทธ์เวิร์กสเปซ: วิธีการแยกด้วย git

แนวทางมอบ git workspace แยกอิสระให้แต่ละเอเจนต์แบ่งออกเป็น 2 แบบ

• โหมดโลคัล — Git Worktrees: ใช้เมื่อรันโดยไม่มี Hub
  • สร้าง worktree พร้อมสาขาเฉพาะที่พาธ ../.scion_worktrees/<grove>/<agent>
  • ถูกเมานต์เป็น /workspace ภายในคอนเทนเนอร์ ทำให้มีไดเรกทอรีทำงานที่เป็นอิสระ ขณะยังแชร์ประวัติ repository เดียวกัน
  • หลังทำงานเสร็จให้รวมกลับด้วย git merge <agent-branch> แบบแมนนวล
• โหมด Hub — Git Init + Fetch: ใช้เมื่อเปิดใช้ Hub
  • broker จะฉีด SCION_GIT_CLONE_URL, SCION_GIT_BRANCH, GITHUB_TOKEN เข้าไปในคอนเทนเนอร์
  • ภายในคอนเทนเนอร์ sciontool init จะเริ่มต้นเวิร์กสเปซ, fetch repository ผ่าน HTTPS และ checkout สาขา scion/<agent-name>
  • ไม่ต้องใช้ข้อมูลรับรอง SSH ของโฮสต์ แต่ต้องมี GITHUB_TOKEN
  • รับประกัน การทำงานที่สม่ำเสมอ บนทุกเครื่อง broker โดยไม่ขึ้นกับว่ามี repository อยู่ในเครื่องหรือไม่

กลไกการแยกทรัพยากร

• ระบบไฟล์: เมานต์โฮมไดเรกทอรีเฉพาะของแต่ละเอเจนต์เข้าไปในคอนเทนเนอร์
• Shadow Mounts (tmpfs): ปิดกั้นการเข้าถึงข้อมูลตั้งค่า .scion หรือเวิร์กสเปซของเอเจนต์อื่นด้วย tmpfs shadow mount
• ข้อมูลรับรอง: ข้อมูลรับรองสำคัญ เช่น การยืนยันตัวตน gcloud จะถูกเปิดเผยให้เฉพาะเอเจนต์ที่เกี่ยวข้อง ผ่านการเมานต์แบบอ่านอย่างเดียวหรือการฉีดตัวแปรสภาพแวดล้อม
• การแยกข้อมูล Grove ออกภายนอก: ข้อมูล Grove ที่ไม่อยู่ใน git และโฮมไดเรกทอรีของเอเจนต์จะถูกแยกเก็บภายนอก เพื่อไม่ให้เอเจนต์เดินไล่เข้าถึงข้อมูลของเอเจนต์อื่นจากภายในเวิร์กสเปซได้

โมเดลสถานะของเอเจนต์ (3 มิติ)

ติดตามสถานะเอเจนต์ใน 3 มิติเพื่อแยกเหตุการณ์ระดับอินฟราฯ ออกจากสถานะการรับรู้ของเอเจนต์

• Phase (ขั้นของวงจรชีวิต): created → provisioning → cloning → starting → running → stopping → stopped (หรือ error)
• Activity (พฤติกรรมของเอเจนต์ระหว่าง running): idle, thinking, executing, waiting_for_input, blocked, completed, limits_exceeded, offline
  • completed, blocked, limits_exceeded เป็นสถานะแบบ "sticky" ที่จะคงอยู่จนกว่าเอเจนต์จะถูกเริ่มใหม่หรือหยุดอย่างชัดเจน
  • blocked เป็นสถานะที่เอเจนต์ตั้งด้วยตัวเอง เพื่อบอกว่ากำลังรอเอเจนต์ลูกทำงานเสร็จ ช่วยป้องกันไม่ให้ระบบ เข้าใจผิดว่าเป็นข้อผิดพลาด
  • offline จะเกิดขึ้นเมื่อไม่ตรวจพบ heartbeat ของเอเจนต์ตามเวลาที่กำหนด ซึ่งอาจมีสาเหตุมาจากการรีเฟรชโทเค็นยืนยันตัวตนล้มเหลว
• Detail: บริบทเพิ่มเติมของ Activity ปัจจุบัน (เช่น ชื่อเครื่องมือ, ข้อความ, สรุปงาน ฯลฯ ในรูปแบบอิสระ)

ระบบปลั๊กอิน

• สถาปัตยกรรมปลั๊กอินที่ขยายระบบได้โดยอิง hashicorp/go-plugin และใช้การสื่อสารแบบ gRPC
• ปลั๊กอิน message broker: มอบแบ็กเอนด์การส่งข้อความแบบกำหนดเองสำหรับการแจ้งเตือนเอเจนต์และการรับส่งข้อความแบบมีโครงสร้าง
• ปลั๊กอิน agent harness: สามารถสร้าง custom harness เพื่อผสานเครื่องมือ LLM ใหม่เข้ากับ Scion ได้โดยไม่ต้องแก้โค้ดเบสหลัก
• ปัจจุบันยังอยู่ใน ระยะเริ่มต้น (foundational stage) และมี implementation อ้างอิงให้สำหรับปลั๊กอินทั้งสองประเภท

[GN⁺]

ความคิดเห็นใน Hacker News

• อยากลองใช้ Scion มาก
  ก่อนหน้านี้เคยใช้ Gastown ที่อยู่ในแนวเดียวกัน ผลลัพธ์ดีแต่ความสม่ำเสมอยังแกว่งมาก
  ข้อไม่พอใจหลักของ Gastown คือ (1) แพง, (2) บังคับใช้เฉพาะโมเดล Claude, (3) สำรองฐานข้อมูลภายในหรือเชื่อมต่อจากระยะไกลได้ยาก, (4) เวลาอัปเกรดมักเกิด การสูญเสียบริบท บ่อย
  ถึงอย่างนั้นก็ยังให้ผลลัพธ์การสนทนาและการทำงานร่วมกันที่ “เหมือนเวทมนตร์” มากกว่าเครื่องมืออื่นในตลาด

• แนวทางของ Google น่าสนใจ
  ผมสร้าง แพลตฟอร์ม Agent Orchestration ชื่อ Optio โดยออกแบบให้เชื่อมกับระบบทิกเก็ตอย่าง Notion, Github Issues, Jira, Linear และให้โค้ดเอเจนต์ไปจนถึงขั้นรวม PR ได้เลย
  ความสามารถของ Scion ในด้าน เอเจนต์ที่รันระยะยาว และการรองรับ การสื่อสารระหว่างคอนเทนเนอร์ ดูน่าประทับใจ
  แต่ผมสร้างบน k8s ขณะที่ Scion ดูเหมือนพยายาม ทำ control plane ขึ้นใหม่เอง เลยค่อนข้างสงสัยอยู่เหมือนกัน

• ปรัชญาแบบ “แยกกักกันแทนการจำกัด” น่าจะมาถูกทางแล้ว
  คอนเทนเนอร์ให้ขอบเขตการแยก แต่เราไม่เห็นว่าเกิดอะไรขึ้นภายในระหว่างการรัน
  เลยสงสัยว่า Scion จะเปิดเผย บริบทรันไทม์ ได้มากแค่ไหน ไม่อย่างนั้นก็อาจเกิดกรณีแบบการโจมตี LiteLLM ที่รู้ความเสียหายก็ตอนรันเสร็จแล้ว

  • ผมเป็น นักพัฒนาหลัก ของ Scion
    มีทั้งสถานะหลายระดับและ telemetry
    โดยพื้นฐานแล้วระบบ hook จะเก็บข้อมูล และถ้ารองรับ OpenTelemetry ก็จะส่งต่อไปยัง cloud collector
    กิจกรรมบางส่วนเอเจนต์จะรายงานเอง และข้อมูลนี้จะสะท้อนเข้าไปใน control plane

• โค้ดถูกซ่อนไว้ลึกมากในเอกสาร
  ต้องไปตามหา GitHub repository เอง

  • ใช่เลย ผมก็เคยกดดาวไว้ตั้งแต่ปลายมีนาคมแล้วลืมไป พอกลับมาดูรอบนี้ก็น่าสนใจพอสมควร

• ทิศทางคล้าย Gastown แต่ดูเหมือนจะขาดฟีเจอร์หลักบางอย่างไป
  โดยเฉพาะ ฟีเจอร์ formula ที่ถือว่าเปลี่ยนเกมเลย

  • ผมเป็น นักพัฒนาหลัก ของ Scion
    ฟีเจอร์ที่ไม่มีเป็นเรื่องที่ออกแบบไว้ตั้งแต่แรก Scion ใกล้เคียงกับสิ่งที่ Gastown เรียกว่า “gascity” มากกว่า — คือเป็นโครงสร้างที่ให้ผู้ใช้เอาตัวละครและนิยามของ orchestration มาเอง
    ดูจาก ตัวอย่างนี้ จะเห็นว่าเป็น orchestration แบบอิง Markdown ที่เรียบง่าย
    Scion ทำหน้าที่เป็น game engine และตอนนี้ก็กำลังมีงานพอร์ต Gastown มารันบน Scion

• โปรเจกต์ยังอยู่ใน ช่วงทดลองระยะแรก เลยทำให้กังวล
  โหมด local ค่อนข้างเสถียร แต่เวิร์กโฟลว์แบบอิง Hub ผ่านการตรวจสอบไปราว 80% ส่วน Kubernetes runtime ยังหยาบอยู่
  ดังนั้นตอนนี้ Gastown อาจยังเป็นตัวเลือกที่ดีกว่า

  • นึกภาพยากมากที่จะบอกว่า Gastown ดีกว่าอย่างอื่นทั้งหมด

• เห็นชื่อแล้วนึกถึง SCION ตัวอื่น (สถาปัตยกรรมอินเทอร์เน็ต) ขึ้นมาเลย
  ดู บทความวิกิ ได้

• อยากทดลองเอเจนต์เพิ่มอีก แต่บริษัทจ่ายให้แค่ Claude Code
  แถมตาม TOS ก็ห้ามเอา API ไปใช้ในวัตถุประสงค์อื่น
  มีใครอยู่ในสถานการณ์คล้ายกันไหม? แบบคิดค่าบริการตามโทเค็นก็แพงเร็วเหมือนกัน

  • อันนี้โดยพื้นฐานคือรัน Claude Code ภายในคอนเทนเนอร์ เลยไม่ถือว่าผิด TOS

• เจ๋งมาก! ผมเองก็เพิ่งทำอะไรคล้าย ๆ กันเมื่อเร็ว ๆ นี้
  ลองแฮ็ก Parallax ดู และเขียนสรุปไว้ในบล็อก