- ระบบเอเจนต์สำหรับรีโพซิทอรีแบบอัตโนมัติ ที่ทำงานอย่างการปรับปรุงโค้ด ดูแลเอกสาร และเสริมความแข็งแรงของการทดสอบได้เองภายใน GitHub Actions
- ทุกเช้า ระบบจะส่งโค้ดที่ปรับปรุงแล้วโดยอัตโนมัติในรูปแบบ Pull Request
- ทำงานอย่าง คัดแยก issue, วิเคราะห์ความล้มเหลวของ CI, ดูแลเอกสาร, ปรับปรุง test coverage, และติดตามการปฏิบัติตามข้อกำหนด ได้โดยอัตโนมัติ
- ระบบอัตโนมัติทั้งหมดนิยามด้วย ไฟล์ Markdown แบบง่าย และสามารถสั่งงานด้วยภาษาธรรมชาติได้โดยไม่ต้องเขียนโค้ดซับซ้อน
- ใช้เอนจิน AI ได้หลากหลาย เช่น Copilot, Claude, Codex เพื่อทำงานแบบอิงเหตุการณ์และตามรอบเวลา
- เสริมความปลอดภัยด้วย การรันแบบแซนด์บ็อกซ์และหลักสิทธิ์น้อยที่สุด
- พัฒนาร่วมกันโดย GitHub Next และ Microsoft Research พร้อม การออกแบบที่เน้นความปลอดภัยและ guardrail ที่แข็งแรง ในตัว
ฟีเจอร์หลัก (Key Features)
- Automated Markdown Workflows
- เขียนระบบอัตโนมัติด้วย Markdown แทน YAML ที่ซับซ้อน
- แปลงคำสั่งภาษาธรรมชาติให้เป็นเวิร์กโฟลว์ GitHub Actions
- AI-Powered Decision Making
- เวิร์กโฟลว์ เข้าใจบริบทและปรับตัวตามสถานการณ์
- AI วิเคราะห์โค้ดและสถานะของรีโพซิทอรีเพื่อดำเนินการที่เหมาะสม
- GitHub Integration
- ผสานการทำงานอย่างลึกซึ้งกับ Actions, Issues, PRs, Discussions
- ทำให้การจัดการรีโพซิทอรีโดยรวมเป็นอัตโนมัติ
- Safety First
- เสริมความปลอดภัยด้วย การรันแบบแซนด์บ็อกซ์, หลักสิทธิ์น้อยที่สุด, และ การจัดการเอาต์พุตอย่างปลอดภัย
- Multiple AI Engines
- รองรับ Copilot, Claude, Codex และ AI processor แบบกำหนดเอง
- Continuous AI
- ปรับปรุงการทำงานร่วมกันและคุณภาพโค้ดแบบอัตโนมัติผ่าน Continuous AI
Guardrails Built-In
- โดยค่าเริ่มต้น เวิร์กโฟลว์จะทำงานด้วย สิทธิ์แบบอ่านอย่างเดียว
- งานเขียนข้อมูลจะอนุญาตได้ผ่าน safe outputs ที่ได้รับอนุมัติล่วงหน้า เท่านั้น
- ควบคุมขอบเขตการทำงานของ AI agent ด้วย การรันแบบแซนด์บ็อกซ์, whitelist ของเครื่องมือ, และการแยกเครือข่าย
ตัวอย่าง: Daily Issues Report
- ขั้นตอนการสร้างระบบอัตโนมัติ
- Write: สร้างไฟล์
.md ที่เขียนด้วยภาษาธรรมชาติ
- Compile: แปลงเป็นเวิร์กโฟลว์ GitHub Actions ในรูปแบบ
.lock.yml ด้วยคำสั่ง gh aw compile
- Run: GitHub Actions จะทำงานอัตโนมัติตาม trigger
- AI agent จะอ่านบริบทของรีโพซิทอรี และทำงานอย่าง วิเคราะห์ issue, สร้างภาพข้อมูล, และเขียนรายงาน
- ทุกขั้นตอนทำงานใน สภาพแวดล้อมแบบคอนเทนเนอร์ เพื่อให้ได้ทั้งความปลอดภัยและการทำซ้ำได้
Gallery
- Issue & PR Management: คัดแยกอัตโนมัติ ติดป้ายกำกับ และปรับโครงการ
- Continuous Documentation: ดูแลเอกสารและรักษาความสม่ำเสมอ
- Continuous Improvement: ทำให้โค้ดเรียบง่ายขึ้น รีแฟกเตอร์ และปรับปรุงสไตล์
- Metrics & Analytics: รายงานรายวัน วิเคราะห์แนวโน้ม และติดตามสถานะเวิร์กโฟลว์
- Quality & Testing: วินิจฉัยความล้มเหลวของ CI ปรับปรุงการทดสอบ และตรวจสอบคุณภาพ
- Multi-Repository: ซิงก์และติดตามฟังก์ชันการทำงานข้ามหลายรีโพซิทอรี
- Continuous Refactoring: วิเคราะห์และทำงานอัตโนมัติผ่านคำสั่งแบบสแลช
- Continuous Scanning & Compliance: สแกนความปลอดภัย คัดแยกคำเตือน และเฝ้าติดตามการปฏิบัติตามข้อกำหนด
- Scheduled Workflows: งานปฏิบัติการประจำวัน งานวิจัย และงานบำรุงรักษาอัตโนมัติ
เริ่มต้นด้วย CLI (Getting Started)
- หลังติดตั้งส่วนขยายแล้ว สามารถเพิ่มเวิร์กโฟลว์ตัวอย่างและรันครั้งแรกได้ จากบรรทัดคำสั่งภายในไม่กี่นาที
- ติดตั้งด้วย
gh extension install github/gh-aw
- ใน Repo ของตนเอง เพิ่ม
gh aw add-wizard githubnext/agentics/daily-repo-status เพื่อให้ติดตั้งแบบอินเทอร์แอ็กทีฟและเริ่มทำงานอัตโนมัติ
สร้างเวิร์กโฟลว์บนเว็บ (Creating Workflows)
- สามารถสร้าง agentic workflow แบบกำหนดเองได้โดยตรงด้วยภาษาธรรมชาติในแท็บ "Agents" ของเว็บอินเทอร์เฟซ GitHub
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สงสัยขึ้นมาหลังเห็นไวยากรณ์
replaceแปลก ๆ ใน go.modปกติจะใช้
go get github.com/Masterminds/semver/v3@v3.4.0แต่ใน PR นี้(ลิงก์) Copilot agent กลับเพิ่มreplaceด้วยวิธีที่ผิดดูเหมือนว่า Dependabot สร้าง issue สำหรับอัปเกรดเวอร์ชันที่ไม่จำเป็น แล้ว Copilot ก็เข้ามาจัดการพร้อมใส่การแก้ไขมั่ว ๆ เพิ่มเข้าไปด้วย
ผู้รีวิวชี้จุดแปลกนี้แล้ว แต่สุดท้ายเหมือนคนรีวิวจะพลาดและ merge เข้าไปอยู่ดี เป็นตัวอย่างที่ผิดพลาดไปหมดในหลายด้าน
แทนที่จะใช้
npm i fooมันกลับแก้สตริงตรง ๆ แล้ว หลอน(hallucinate) เวอร์ชันขึ้นมาใส่เองแม้แต่การ rename โค้ดก็ยังจัดการด้วยการแทนที่สตริง แทนที่จะใช้เครื่องมือ refactoring ทำให้สิ้นเปลือง GPU มาก
replaceตัวเดิมถูกสะสมซ้ำถึงสามครั้ง ในที่สุดก็ถูกแก้ใน PR 14543แต่หลังจากนั้นก็มีการเพิ่มคอมมิต “แก้ unit test” อีกสองตัว ตัวหนึ่งคือเปลี่ยน Claude → Copilot อีกตัวทำให้ Markdown ของเอกสารพัง
ให้ความรู้สึกเหมือนกลายเป็น สมรภูมิของ agent workflow ไปแล้ว
ฉันใช้ Gemini และ Codex เพื่อตรวจสอบข้อมูลเวอร์ชัน แล้วใช้ sub-agent ของ Claude Opus เพื่อตรวจดูว่าจำเป็นต้องเปลี่ยนโค้ดหรือไม่
ถ้าเป็น major version ก็จะ git clone ทั้งสองแพ็กเกจมาเทียบการเปลี่ยนแปลงของอินเทอร์เฟซ แล้วรันทดสอบเพื่อตรวจสอบในขั้นสุดท้าย
มันไม่สมบูรณ์แบบหรอก แต่คนเราก็ไม่ได้สมบูรณ์แบบเหมือนกัน เลยถือว่าโอเค
อยากให้ GitHub ขัดเกลาฟีเจอร์หลักให้ดีเสียก่อน
ก่อนหน้านี้ฉันเลิกใช้มันหลังเจอ ปัญหา เกี่ยวกับ GH Actions และแม้จะผ่านไป 1 ปี คนก็ยังลำบากกับปัญหาเดิมอยู่
ติดตั้งง่าย และผสานเข้ากับเครือข่าย Microsoft LDAP/ADFS ได้ดี
worker แบบเรียบง่ายจะรัน action ที่กำหนดไว้ในโฟลเดอร์
.giteaได้อย่างเสถียรทำให้สร้าง CI pipeline แบบ พึ่งพาตัวเองได้ทั้งหมด และยังมี UI ที่แทบไม่ต่างจาก GitHub
สุดท้ายทางออกก็ง่ายมาก — คือ ซื้อผลิตภัณฑ์ของพวกเขาโดยตรง
มันให้ความรู้สึกเหมือน ลูกเล่นง่อย ๆ ที่พยายามหลอกให้จ่ายเงิน
ส่วนขยาย
gh awรับไฟล์ Markdown เป็นอินพุตแล้วสร้าง GitHub Actions workflow ขนาดใหญ่ระหว่างรัน
gh aw initฉันเผลอกด Y กับพรอมป์ที่ไม่ถูกต้อง แล้วระบบก็สร้างCOPILOT_GITHUB_TOKENด้วยโทเคนบัญชีของฉันเรื่องแบบนี้ควรมีขั้นตอนยืนยันเพิ่มเติมอย่างแน่นอน
ลิงก์ทางการคือ github.com/github/gh-aw
ฉันสงสัยว่าทำไมถึงปล่อยผ่าน GitHub Pages โดยไม่ใช้โดเมนอื่น
ORGNAME.github.ioตามชื่อบัญชีดังนั้น
github.github.ioจึงหมายถึงบัญชีทางการของ GitHub เป็นผู้เผยแพร่githubnextมายังองค์กรgithubgithub.github.ioคือโดเมน Pages เริ่มต้นขององค์กร GitHubฉันเพิ่งใช้เวลาตลอดสุดสัปดาห์สร้าง workflow CI แบบใช้ agent
อินสแตนซ์ CC ทำงานใน VM ที่แยกออกมาในโหมดจำกัดสิทธิ์ และเมื่อ CI ผ่านก็จะสร้าง PR อัตโนมัติ
ตอนนี้กำลังทดลองโครงสร้างที่ Claude หนึ่งตัวคอยจัดการ Claude หลายตัวอีกที
รู้สึกว่า GitHub กำลัง ยัด agent เข้ามาแบบฝืน ๆ แทนที่จะปรับปรุงระบบเดิม
มันดูเหมือน กลยุทธ์รีดเงินที่ขับเคลื่อนด้วยการตลาด
เลยอดสงสัยไม่ได้ว่าพวกเขากำลังพยายามทำให้ใช้ Claude ยากขึ้น เพื่อบังคับให้ใช้ agent ของตัวเองหรือเปล่า
สำหรับ GitHub Actions ที่อ้างหลักการ ออกแบบโดยยึดความปลอดภัยเป็นศูนย์กลาง นั้น ฉันกลับ ไว้ใจน้อยที่สุด
ฉันเข้าใจแนวทางของ Microsoft และ GitHub
คุณค่าของโค้ดไม่ได้อยู่ที่ตัวโค้ดล้วน ๆ แต่คือ รูปแบบที่บรรจุความรู้ขององค์กร เอาไว้
เพราะแบบนี้ กระแสการปรับปรุงอย่างต่อเนื่องและอัตโนมัติ จึงสำคัญ
การรีแฟกเตอร์ครั้งใหญ่แบบหักดิบจะทำลาย mental model ขององค์กร ดังนั้นการปรับปรุงเล็ก ๆ อย่างต่อเนื่องจึงเป็นอุดมคติ
โครงสร้างที่ดีคือให้ระบบเชิงกำหนดแน่นอนตรวจจับปัญหา แล้วให้ LLM แก้เฉพาะส่วนที่จำเป็น
ฉันต้องทำคำแนะนำละเอียดมากในสไตล์ Deep Wiki เอง เลยค่อนข้างยุ่งยาก
ต้องการเครื่องมือที่ช่วยมองเห็นโครงสร้างได้แบบ C4 diagram
เอกสารที่เกี่ยวข้อง: DataOps pattern
ช่วงนี้ผลิตภัณฑ์คลาวด์แทบทุกตัว ฟีเจอร์หลักหยุดนิ่ง แต่ฟีเจอร์รอบนอกเพิ่มขึ้นเรื่อย ๆ
พอองค์กรใหญ่ขึ้น นักพัฒนาก็ต้องสร้างฟีเจอร์ใหม่ ๆ ปรากฏการณ์แบบนี้เลยเกิดขึ้น
ถ้ายังไม่หยุด การไล่ล่าการเติบโตแบบไม่สิ้นสุด ผลิตภัณฑ์ก็จะ enshittification ต่อไปเรื่อย ๆ
บน landing page ยังไม่ชัดเจนว่า workflow นี้มอบ คุณค่าที่จับต้องได้ อะไรให้ผู้ใช้
ยังขาดตัวอย่างหรือ use case ที่เป็นรูปธรรม
เช่น workflow จัดการ issue ที่แสดงกรณีการจัดการ PR และ issue แบบอัตโนมัติ
คุณค่าหลักคือ มอบหมายงานซ้ำ ๆ ที่จัดการด้วย heuristic ไม่ได้ ออกไป
และบอกว่ายังกำลังปรับแต่งการเล่าเรื่องให้ดีขึ้นอยู่