หลายทีมยังใช้ coding agent แบบแชทครั้งเดียว: เปิดเทอร์มินัล สตาร์ทโปรเซสเย็น จ่ายค่า context เต็ม ๆ แล้วทิ้งเซสชัน เราอยากได้สิ่งที่คล้ายโครงสร้างพื้นฐาน production มากกว่า — บริการที่อยู่ยาว เรียกจากตารางงาน สคริปต์ และ (เร็ว ๆ นี้) เบราว์เซอร์ใดก็ได้บน LAN
สัปดาห์นี้เราใส่แพทเทิร์นนั้นในสแต็กของเรา: coding agent ที่รันยาว ไคลเอนต์ ACP (Agent Client Protocol) บาง ๆ และจุดเชื่อมแรกให้ myawx งานตามตารางคุยกับ agent ตัวเดียวกัน แทนการสตาร์ท Grok เย็นทุกครั้ง
ทำไม long session ดีกว่า cold start
ทุกจ็อบที่เปิด agent binary เต็มตัว คุณจ่ายซ้ำสำหรับ config, เครื่องมือ และเทิร์นแรกที่แค่กู้ session continuity สำหรับงานโต้ตอบมันน่ารำคาญ สำหรับ automation มันสิ้นเปลือง: token cost สูงขึ้น จ็อบช้าลง และโอกาสรักษา prompt cache ให้อุ่นข้ามงานที่เกี่ยวข้องน้อยลง
โมเดล long session พลิกค่าเริ่มต้น เก็บโปรเซส agent หนึ่งตัวไว้ที่ที่งานอยู่แล้ว — ข้างเครื่องมือ deploy, Git และ control plane — แล้วให้ไคลเอนต์อายุสั้นต่อ แนบ ส่งพรอมต์ สตรีมผล แล้วตัดการเชื่อมต่อ โปรเซสหนักอยู่ต่อ ไคลเอนต์ยังบาง
ACP: โปรโตคอลไคลเอนต์จริง ไม่ใช่ไซโลแชทใหม่
เรายึด Agent Client Protocol แบบเปิด: เซสชัน JSON-RPC บน WebSocket (หรือ stdio ในเอดิเตอร์) แนวเดียวกับ language server — เส้นแบ่ง client/agent ชัด — ไม่ใช่ UI ปิดของเจ้าหนึ่งราย
ฝั่งเราหมายถึง:
- บริการ Grok Build agent รันยาว (systemd) พร้อมสำหรับ automation
- CLI acp เล็ก ๆ (Python stdlib) สำหรับเชลล์ cron และจ็อบ: ต่อ พรอมต์ พิมพ์ ออก
- ทดลอง UI เดสก์ท็อป ACP สำหรับงานโต้ตอบ — ใช้ดูเร็วได้ แต่ไม่ใช่กระดูกสันหลังของ ops
เรายังโคลนและศึกษาซอร์สสาธารณะของ Grok / Grok Build ในส่วนที่เปิด โปร่งใสนั้นสำคัญต่อ AI engineering บน infrastructure ที่เราเดินเอง: เห็นว่าโหมด serve, เซสชัน และเครื่องมือออกแบบมาอย่างไร ไม่ต้องเดาจากกล่องดำ
ตาราง myawx ที่เรียก Grok อยู่แล้ว
ออร์เคสเตรเตอร์ภายใน — myawx — ยิงงานซ้ำอยู่แล้ว: ดูแล mirror, งานจากเมล, ตาม incident, แบตช์โต๊ะคอนเทนต์ และงาน fleet อื่น บางตารางส่ง brief ให้ Grok เมื่อคนจะแปะเช็กลิสต์เดิมในเทอร์มินัล
ก่อนหน้านี้หลายเส้นทางสตาร์ท agent เต็มตัวเย็นทุกรัน เราย้ายไป agent รันยาวผ่าน ACP CLI เพื่อให้จ็อบตามตารางเป็น “ส่ง brief นี้ไป agent ที่รันอยู่” ไม่ใช่ “บูตทั้งจักรวาลแล้วค่อยถามหนึ่งข้อ” รักษา session continuity เมื่อมีประโยชน์ ตัด startup เกิน และให้เส้น automation คล้ายเส้นโต้ตอบ
ไม่ใช่ทุกจ็อบต้องมีโมเดล งาน desired-state ก้อนใหญ่ยังเป็นของ Ansible และไพพ์ไลน์ที่ทำซ้ำได้ ที่ซึ่งต้องใช้วิจารณญาณ สอบสวนหลายขั้นบนโฮสต์ หรือ brief ภาษาธรรมชาติ agent กลายเป็น callee ชั้นหนึ่งของ scheduler — ไม่ใช่งานอดิเรกบนแล็ปท็อป
สิ่งที่เรายังไม่ทำ
เราไม่แทนที่ GitLab, OTAP หรือ change control ด้วยแชท managed hosting สาธารณะและการแยกลูกค้ายังใช้กฎเดิม: inventory, รีวิว และเกต production agent นั่งข้างเครื่องนั้น ไม่ละลายมัน
เราระวังการเปิดเผยด้วย ACP บน WebSocket ธรรมดาเป็นโปรโตคอล ไม่ใช่การเข้ารหัสฟรี ในเครือข่ายส่วนตัวที่เชื่อถือได้พร้อมยืนยันตัวตน มันเป็นพื้นผิว ops ที่ใช้ได้ บนอินเทอร์เน็ตเปิดต้องมี TLS และนโยบายเข้ม — สามัญสำนึกเดียวกับ admin API ใด ๆ
ถัดไป: HTTP ↔ ACP gateway สำหรับทุกเบราว์เซอร์บน LAN
CLI พอสำหรับ myawx และคนที่อยู่กับเชลล์ ขั้นถัดไปตามธรรมชาติคือ HTTP ↔ ACP gateway เล็ก ๆ: หน้าเว็บโลคอลที่พูด HTTPS ปกติกับเบราว์เซอร์บน LAN และ ACP กับ agent ด้านหลัง ไม่ต้องแอปเดสก์ท็อปพิเศษ — เบราว์เซอร์ใดบนเน็ตส่วนตัวอาจเปิดเซสชัน เลือกโฟลเดอร์งาน และขับ agent รันยาวตัวเดียวกับที่ตารางใช้
เกตเวย์นั้นเป็นงานที่วางแผน ไม่ใช่เปิดตัวผลิตภัณฑ์ เมื่อลงตัว จุดเข้าโต้ตอบและอัตโนมัติจะแชร์ agent เดียว เรื่อง audit เดียว และที่เดียวคิดเรื่องต้นทุน (cache hit-rate, โตของ context และเมื่อไหร่ควรเซสชันใหม่หรือต่อ long session)
เข้ากับ 3DN อย่างไร
3DN เป็นครอบครัวผลิตภัณฑ์และ infrastructure ใต้หลังคาเดียว: compute กับ managed hosting บวกพื้น work · money · politics อย่าง DutchBud, PolitiCap และ ZZP2ZZP coding agent ไม่ใช่เดโมข้างทาง — เป็นส่วนหนึ่งของวิธีรันระบบ production ด้วย hand-off ที่เปราะน้อยลง
Digital sovereignty ที่นี่ใช้ได้จริง: รัน agent ที่ที่เครื่องมือและนโยบายอยู่แล้ว เปิดโปรโตคอลพอสลับไคลเอนต์ และปฏิเสธเท automation ทั้งหมดลงแชท SaaS ปิดที่ไม่เห็น fleet ของคุณ
สรุป
- บริการ Grok agent รันยาวสำหรับ ops และ automation
- ACP CLI บาง ๆ สำหรับสคริปต์และตาราง myawx ที่เรียก Grok อยู่แล้ว
- ซอร์ส Grok Build เปิดเป็นแผนที่ ไม่ใช่แค่ทิ้งไบนารี
- โรดแมป: HTTP ↔ ACP gateway ให้เบราว์เซอร์ LAN ถึง agent ตัวเดียวกัน
ถ้าคุณรัน agent ของตัวเองบนเครื่องตัวเอง คำถามที่น่าสนใจไม่ใช่แค่ “โมเดลไหน?” — แต่เป็น “โปรเซสไหนอยู่ต่อ ใครเรียกได้ และพรอมต์ถัดไปถูกแค่ไหนเมื่อแคชอุ่นแล้ว?”
ใส่ความเห็น