
Paperclip v2026.618.0: Agent มี Skill Store แล้ว แต่ธุรกิจต้องมี Sandbox ด้วย
AI Agent เก่งขึ้นทุกวันครับ
แต่พอ agent เริ่มมีความสามารถเพิ่มขึ้น คำถามที่ธุรกิจควรถามจะเปลี่ยนทันที
ไม่ใช่แค่ “agent ทำอะไรได้บ้าง”
แต่คือ:
เราให้ agent ทำเพิ่มได้อย่างปลอดภัยแค่ไหน
Paperclip v2026.618.0 เป็น release note ที่น่าสนใจ เพราะมันไม่ได้พูดแค่ฟีเจอร์ใหม่แบบสวย ๆ แต่สะท้อนว่าโลก AI-agent management กำลังขยับจาก “ใช้ agent เป็นตัว ๆ” ไปสู่ “มี control plane สำหรับ AI company”
1) เกิดอะไรขึ้น
ใน release นี้ Paperclip เพิ่มและปรับหลายส่วนพร้อมกัน
ส่วนที่ผมมองว่าสำคัญมี 5 เรื่อง:
- Skills Store: agent สามารถ browse, install, และ manage skills จาก store ใน app ได้ Skills กลายเป็น first-class installable unit มี install counts และ catalog ที่ scoped ตาม company
- Self-hostable sandbox execution: มี Kubernetes sandbox provider plugin, server-side Kubernetes execution integration, hardened agent-runtime images และ Novita sandbox provider เพื่อให้ agent รันงานในพื้นที่แยกได้
- Per-company multi-tenant isolation: แต่ละ company มี JWT signing keys ของตัวเอง cloud tenants scoped ตาม company และ plugin tables มี
company_idเพื่อแยก plugin data ต่อ tenant - Workspace file viewer and artifact links: ผู้ใช้เปิดดูไฟล์ที่ agent ผลิตจาก issue thread ได้เลย ไม่ต้องไล่หาใน terminal หรือ workspace เอง
- Env-driven gateway routing: local adapters อย่าง
codex,pi,opencode, และgeminiroute ผ่าน custom providers/gateways ด้วย env config ได้
นอกจากนี้ release ยังมีงาน reliability เยอะมาก เช่น execution lock cleanup, stale run state, orphan sweep, session continuity, adapter self-healing, auth handling, log redaction และ recovery fixes
ถ้าอ่านแบบ feature list อาจดูเหมือนรายละเอียดเทคนิค
แต่ถ้าอ่านแบบธุรกิจ นี่คือชิ้นส่วนของระบบบริหาร AI workforce ครับ
2) ทำไม Skills Store อย่างเดียวไม่พอ
Skills Store ฟังดูดีมาก เพราะ agent สามารถเพิ่มความสามารถได้ง่ายขึ้น
แต่ในงานจริง “เพิ่ม skill” แปลว่าเพิ่มสิทธิ์ เพิ่ม behavior และเพิ่มพื้นผิวความเสี่ยงด้วย
ลองนึกภาพทีมใช้ agent ทำงานขายและหลังบ้าน:
- skill อ่าน CRM
- skill สรุป lead
- skill ร่างอีเมล follow-up
- skill เช็ก invoice
- skill สร้าง report
- skill แตะ GitHub หรือ WordPress
ถ้าทุก skill ถูกติดตั้งแบบไม่รู้ที่มา ไม่รู้ scope ไม่รู้ว่าใครอนุมัติ และไม่มี log ตอนใช้งาน เราจะได้ agent ที่เก่งขึ้น แต่ควบคุมยากขึ้น
ดังนั้น Skills Store เป็นแค่ชั้น capability ครับ
สิ่งที่ต้องมาคู่กันคือ provenance, permission, sandbox, proof และ rollback path
หรือพูดง่าย ๆ: มีร้าน skill ได้ แต่ต้องมีระบบรักษาความปลอดภัยหน้าร้านด้วย
3) Sandbox คือบ้านที่ปลอดภัยของ agent
จุดที่ผมชอบใน release นี้คือ sandbox execution
หลายทีมเริ่มจากให้ agent รันบนเครื่อง dev, container ง่าย ๆ, หรือ workspace ที่สิทธิ์กว้างเกินไป เพราะตอน demo มันเร็วดี
แต่พอ agent แตะงานจริง เช่น code, file, browser, credential, customer data หรือ deployment path เราไม่ควรให้มันอยู่ใกล้ production เกินจำเป็น
Sandbox ที่ดีควรตอบได้ว่า:
- agent รันโค้ดที่ไหน
- filesystem เห็นอะไรบ้าง
- network ออกไปไหนได้บ้าง
- credential ถูกส่งเข้าไปอย่างไร
- run ไหนเป็นของ company/client ไหน
- ถ้าพังกลางทาง จะเก็บ state และ proof ไว้ตรงไหน
Paperclip ไปทาง Kubernetes/self-hostable sandbox และ provider plugin ซึ่งเป็นสัญญาณชัดว่า agent execution กำลังถูกแยกเป็น infrastructure layer ของตัวเอง
สำหรับธุรกิจไทย บทเรียนไม่ใช่ว่าทุกคนต้องใช้ Kubernetes ทันที
บทเรียนคือ agent ที่แตะระบบจริงต้องมี “ห้องทำงานแยก” ไม่ใช่เดินถือกุญแจเข้าห้อง server หลักได้หมด
4) Multi-tenant isolation ไม่ใช่เรื่อง enterprise เท่านั้น
หลายคนเห็นคำว่า multi-tenant แล้วคิดว่าเป็นเรื่อง SaaS ใหญ่ ๆ
แต่ในโลก AI agent เรื่องนี้ใกล้ตัวกว่าที่คิดครับ
ถ้าคุณมี agent ชุดเดียวที่ช่วยหลายอย่าง เช่น:
- บริษัทหลัก
- โปรเจกต์ทดลอง
- ลูกค้าคนละเจ้า
- ทีม sales
- ทีม support
- sandbox ของผู้เรียน
คำถาม tenant isolation จะมาเร็วมาก
ข้อมูลของใครอยู่ตรงไหน ใครอ่านได้ ใครเขียนได้ plugin data แยกจริงไหม key ของ company A ไป sign หรือ access งานของ company B ได้ไหม
Paperclip release นี้เพิ่ม per-company JWT signing keys, company-scoped cloud tenants และ company_id ใน plugin tables
แปลเป็นภาษาธุรกิจคือ ระบบเริ่มยอมรับว่า AI company หนึ่ง deployment อาจมีหลาย company อยู่ข้างใน และขอบเขตต้องชัดตั้งแต่ database ถึง runtime
สำหรับ Data-Espresso / OPB Stack นี่เป็นประเด็นสำคัญมาก
ถ้าเราจะช่วยธุรกิจมี AI coworker หรือ AI admin room ของตัวเอง เราต้องออกแบบ boundary ตั้งแต่วันแรก ไม่ใช่ค่อยมาแยกทีหลังตอนมีข้อมูลลูกค้าแล้ว
5) Artifact viewer ทำให้คำว่า done มีหลักฐาน
AI Agent ชอบบอกว่า “เสร็จแล้ว”
แต่คำว่าเสร็จแล้วในงานธุรกิจต้องมี proof
Paperclip เพิ่ม workspace file viewer และ artifact links ให้เปิดดูไฟล์ที่ agent สร้างจาก issue thread ได้เลย
ฟีเจอร์นี้ดูเล็ก แต่สำคัญมากครับ
เพราะงาน agent ที่ดีไม่ควรจบที่ข้อความในแชตว่า “ผมทำให้แล้ว”
ควรจบด้วยสิ่งที่ตรวจได้ เช่น:
- ไฟล์ draft
- diff
- screenshot
- report
- export
- log
- test result
- queue proof
- artifact link
ถ้า operator ตรวจงานไม่ได้ ความไวของ agent ก็กลายเป็นภาระ
ยิ่ง agent ทำงานเร็วเท่าไหร่ proof layer ยิ่งสำคัญเท่านั้น
6) Gateway routing ทำให้ยืดหยุ่นขึ้น แต่ governance ต้องตามให้ทัน
อีกส่วนที่น่าสนใจคือ local adapters อย่าง Codex, Pi, OpenCode และ Gemini สามารถ route ผ่าน custom providers/gateways ด้วย env config ได้
มุมบวกคือ operator คุม cost, provider, model, latency และ policy ได้มากขึ้น
แต่มุมที่ต้องระวังคือ config flexibility ทำให้ระบบซับซ้อนขึ้นด้วย
ถ้าวันหนึ่ง agent A ใช้ provider หนึ่ง agent B ใช้อีก gateway หนึ่ง และงาน production ใช้ routing อีกชุดหนึ่ง เราต้องรู้ว่า:
- งานไหนใช้ model/provider อะไร
- cost เกิดที่บัญชีไหน
- data ส่งผ่าน gateway ใด
- fallback ทำงานเมื่อไหร่
- ถ้า auth หมดอายุหรือ provider ล่ม agent จะหยุดหรือสลับทางเอง
ความยืดหยุ่นดีครับ แต่ต้องตามด้วย observability และ config discipline
Operator Kit: AI Workforce Control Plane Checklist
ใช้ checklist นี้ก่อนเพิ่ม skill ใหม่หรือปล่อย agent เข้า workflow จริง
1. Skill catalog
- skill นี้มาจากแหล่งไหน
- มี owner หรือ maintainer ชัดเจนไหม
- skill ทำอะไรได้บ้าง และแตะระบบไหน
- ใครมีสิทธิ์ install, update, disable
- มี version history หรือ changelog หรือไม่
2. Permission and approval
- skill นี้อ่านอะไรได้
- skill นี้เขียนอะไรได้
- action ไหนต้องมี human approval ก่อน
- approval ถูกเก็บเป็นหลักฐานหรือไม่
- ถ้า skill ทำผิด มีวิธีปิดเฉพาะ skill นั้นไหม
3. Sandbox execution
- agent รันโค้ดหรือ command ที่ไหน
- workspace แยกจาก production หรือไม่
- filesystem, network, และ credential ถูกจำกัดไหม
- run หนึ่งผูกกับ issue/company/client ที่ถูกต้องหรือไม่
- มี kill switch ถ้า run หลุด scope หรือเปล่า
4. Tenant boundary
- company/client/team แต่ละชุดมี data boundary ชัดไหม
- key, token, plugin data, artifact, และ logs ถูก scoped ตาม tenant หรือไม่
- agent ของ tenant หนึ่งเห็นงานของอีก tenant ได้หรือเปล่า
- มี test หรือ audit path สำหรับ cross-tenant leakage ไหม
5. Artifact and proof
- งาน agent ทิ้ง artifact อะไรไว้
- operator เปิดดู artifact ได้จาก issue หรือ workflow เดิมไหม
- proof บอกได้ไหมว่า agent ทำอะไร ผ่าน tool ใด เมื่อไหร่
- ถ้ามี reviewer เขาดูหลักฐานได้โดยไม่ต้องเข้า terminal ไหม
6. Gateway and provider routing
- adapter แต่ละตัว route ผ่าน provider/gateway ใด
- config เก็บที่ไหน และ review ได้ไหม
- มี cost limit หรือ budget ต่อ agent/run หรือเปล่า
- มี fallback เมื่อ provider/auth/gateway ล้มไหม
- routing change ถูก log ไว้หรือไม่
7. Recovery and stale run handling
- ถ้า run ค้าง ระบบรู้ไหมว่าค้าง
- stale
sessionId,executionRunId, หรือ checkout/run state ถูก clear อย่างไร - reassign งานแล้ว lock ถูกปล่อยไหม
- agent ที่ยังมี progress อยู่จะถูกดึงงานออกโดยไม่จำเป็นหรือเปล่า
- recovery จบด้วย proof หรือแค่ retry เงียบ ๆ
7) Data-Espresso จะเอาไปใช้ยังไง
สำหรับ Data-Espresso เรื่องนี้โยงกับหลายระบบครับ
ใน CustomerOS เราต้องคิดเรื่อง bot tools, CRM data, product catalog, KB และ approval ก่อนตอบลูกค้าหรือ update record
ใน Learn / AI Mentor เราต้องคิดเรื่อง course context, entitlement, transcript, quota และ learner data boundary
ใน Deep Dive production เราต้องคิดเรื่อง source capture, draft file, cover, WordPress media, GitHub issue queue และ autopost proof
ใน OPB Stack/Hermes เราต้องคิดเรื่อง sandbox VPS, memory, skills, tools, schedule, provider routing และ human approval
พูดง่าย ๆ คือทุกที่ที่เราจะมี “AI coworker” เราต้องมี control plane ไม่ใช่แค่ prompt ดี ๆ
8) สิ่งที่ธุรกิจไทยควรจำ
ถ้าคุณกำลังจะเริ่มใช้ AI Agent ในบริษัท อย่าเริ่มจากคำถามว่า “agent ตัวไหนฉลาดสุด” อย่างเดียว
ให้ถามเพิ่มว่า:
- agent อยู่ใน workflow ไหน
- skill ที่มันใช้มาจากไหน
- มันรันงานใน sandbox หรือไม่
- data ของลูกค้า/ทีม/บริษัทถูกแยกอย่างไร
- งานที่มันทำมี artifact และ proof ไหม
- ถ้ามันค้างหรือผิดพลาด เรา recover อย่างไร
นี่คือความต่างระหว่าง demo กับระบบทำงานจริง
สรุป
Paperclip v2026.618.0 เป็น release ที่ดี เพราะมันทำให้เห็นทิศทางของตลาดชัดขึ้น
AI Agent ไม่ได้โตแค่ด้านความฉลาด
มันกำลังโตด้าน operating system รอบตัว agent ด้วย: skill store, sandbox, tenant isolation, artifact proof, gateway routing และ recovery
ในความเห็นของผม ธุรกิจที่ใช้ AI Agent จริงควรคิดแบบนี้ตั้งแต่ต้นครับ
อย่าเพิ่งเพิ่ม skill ให้ agent ถ้ายังไม่รู้ว่า agent จะรันที่ไหน เห็นข้อมูลอะไร ทิ้ง proof อะไร และหยุดอย่างไรเมื่อเริ่มเสี่ยง
AI ที่ดีไม่ใช่แค่ทำงานได้มากขึ้น
แต่ต้องถูกคุมให้ทำงานในขอบเขตที่ธุรกิจไว้ใจได้
