5 คะแนน โดย GN⁺ 2026-02-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระบบเอเจนต์สำหรับรีโพซิทอรีแบบอัตโนมัติ ที่ทำงานอย่างการปรับปรุงโค้ด ดูแลเอกสาร และเสริมความแข็งแรงของการทดสอบได้เองภายใน 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 ความคิดเห็น

 
GN⁺ 2026-02-10
ความคิดเห็นจาก Hacker News
  • สงสัยขึ้นมาหลังเห็นไวยากรณ์ replace แปลก ๆ ใน go.mod
    ปกติจะใช้ go get github.com/Masterminds/semver/v3@v3.4.0 แต่ใน PR นี้(ลิงก์) Copilot agent กลับเพิ่ม replace ด้วยวิธีที่ผิด
    ดูเหมือนว่า Dependabot สร้าง issue สำหรับอัปเกรดเวอร์ชันที่ไม่จำเป็น แล้ว Copilot ก็เข้ามาจัดการพร้อมใส่การแก้ไขมั่ว ๆ เพิ่มเข้าไปด้วย
    ผู้รีวิวชี้จุดแปลกนี้แล้ว แต่สุดท้ายเหมือนคนรีวิวจะพลาดและ merge เข้าไปอยู่ดี เป็นตัวอย่างที่ผิดพลาดไปหมดในหลายด้าน

    • ทุก agent ที่ฉันเคยใช้ล้วนก่อปัญหาคล้ายกันใน package.json ของ npm
      แทนที่จะใช้ 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 ทั้งสองแพ็กเกจมาเทียบการเปลี่ยนแปลงของอินเทอร์เฟซ แล้วรันทดสอบเพื่อตรวจสอบในขั้นสุดท้าย
      มันไม่สมบูรณ์แบบหรอก แต่คนเราก็ไม่ได้สมบูรณ์แบบเหมือนกัน เลยถือว่าโอเค
    • สถานการณ์นี้ทำให้นึกถึงคำสั่ง secure sleep ของ GitHub Actions
  • อยากให้ GitHub ขัดเกลาฟีเจอร์หลักให้ดีเสียก่อน
    ก่อนหน้านี้ฉันเลิกใช้มันหลังเจอ ปัญหา เกี่ยวกับ GH Actions และแม้จะผ่านไป 1 ปี คนก็ยังลำบากกับปัญหาเดิมอยู่

    • ขอแนะนำ Gitea อย่างแรง
      ติดตั้งง่าย และผสานเข้ากับเครือข่าย Microsoft LDAP/ADFS ได้ดี
      worker แบบเรียบง่ายจะรัน action ที่กำหนดไว้ในโฟลเดอร์ .gitea ได้อย่างเสถียร
      ทำให้สร้าง CI pipeline แบบ พึ่งพาตัวเองได้ทั้งหมด และยังมี UI ที่แทบไม่ต่างจาก GitHub
    • ยิ่งมีผู้ใช้ฟรีมาก ภาระการซัพพอร์ตก็ยิ่งสูงขึ้น เป็น ภาวะกลืนไม่เข้าคายไม่ออกของการผลักไปสู่พรีเมียม
      สุดท้ายทางออกก็ง่ายมาก — คือ ซื้อผลิตภัณฑ์ของพวกเขาโดยตรง
    • ในฐานะผู้ใช้แบบจ่ายเงิน ฉันไม่พอใจที่เงินของฉันไม่ได้ถูกใช้ไปกับการปรับปรุงฟีเจอร์หลัก แต่ไปลงกับ การพัฒนาฟีเจอร์ AI
    • ทิศทางแบบนี้ดูเหมือนเป็นความพยายามของบริษัทที่จะยังรักษา ภาพลวงตาของหุ้นเติบโต เอาไว้
    • ทั้งที่ฉันไม่ได้ใช้ Copilot แต่บนหน้าแรกของ GitHub ก็ยังขึ้นข้อความ “เกินขีดจำกัด” ตลอด
      มันให้ความรู้สึกเหมือน ลูกเล่นง่อย ๆ ที่พยายามหลอกให้จ่ายเงิน
  • ส่วนขยาย gh aw รับไฟล์ Markdown เป็นอินพุตแล้วสร้าง GitHub Actions workflow ขนาดใหญ่
    ระหว่างรัน gh aw init ฉันเผลอกด Y กับพรอมป์ที่ไม่ถูกต้อง แล้วระบบก็สร้าง COPILOT_GITHUB_TOKEN ด้วยโทเคนบัญชีของฉัน
    เรื่องแบบนี้ควรมีขั้นตอนยืนยันเพิ่มเติมอย่างแน่นอน

    • ตอนนี้บอกว่าได้ ยกเลิกการใช้โทเคนในเครื่องแล้ว และเพิ่มขั้นตอนยืนยันเพิ่มเติมเข้ามาแล้ว
  • ลิงก์ทางการคือ github.com/github/gh-aw
    ฉันสงสัยว่าทำไมถึงปล่อยผ่าน GitHub Pages โดยไม่ใช้โดเมนอื่น

    • GitHub Pages ให้โดเมน ORGNAME.github.io ตามชื่อบัญชี
      ดังนั้น github.github.io จึงหมายถึงบัญชีทางการของ GitHub เป็นผู้เผยแพร่
    • ฉันมองว่าการที่ GitHub ใช้ผลิตภัณฑ์ของตัวเองบนโดเมนของตัวเองก็เป็นรูปแบบหนึ่งของ dogfooding
    • คนอื่นไม่สามารถครอบครองลิงก์นี้ได้ จึง ไม่มีความเสี่ยงด้านฟิชชิง
    • มีคนบอกว่าเพิ่งย้ายจากองค์กร githubnext มายังองค์กร github
      github.github.io คือโดเมน Pages เริ่มต้นขององค์กร GitHub
    • ตอนนี้แก้ redirect เป็น github.github.com/gh-aw แล้ว
  • ฉันเพิ่งใช้เวลาตลอดสุดสัปดาห์สร้าง workflow CI แบบใช้ agent
    อินสแตนซ์ CC ทำงานใน VM ที่แยกออกมาในโหมดจำกัดสิทธิ์ และเมื่อ CI ผ่านก็จะสร้าง PR อัตโนมัติ
    ตอนนี้กำลังทดลองโครงสร้างที่ Claude หนึ่งตัวคอยจัดการ Claude หลายตัวอีกที

    • มีคนถามว่าค่าใช้จ่ายเท่าไร
    • อีกคนตอบว่า “ยุคสมัยมันบ้าคลั่งจริง ๆ”
  • รู้สึกว่า GitHub กำลัง ยัด agent เข้ามาแบบฝืน ๆ แทนที่จะปรับปรุงระบบเดิม
    มันดูเหมือน กลยุทธ์รีดเงินที่ขับเคลื่อนด้วยการตลาด

    • ถึงอย่างนั้น การมี agent อยู่กับ ผู้ให้บริการศูนย์กลาง ที่เข้าถึง CI, issue และซอร์สโค้ดได้ ก็อาจถือว่าสมเหตุสมผล
    • Claude ของ Anthropic ผสานกับ GitHub ได้ดีอยู่แล้ว เลยทำให้ agent ของ GitHub เอง ดูไร้ประโยชน์
      เลยอดสงสัยไม่ได้ว่าพวกเขากำลังพยายามทำให้ใช้ Claude ยากขึ้น เพื่อบังคับให้ใช้ agent ของตัวเองหรือเปล่า
  • สำหรับ GitHub Actions ที่อ้างหลักการ ออกแบบโดยยึดความปลอดภัยเป็นศูนย์กลาง นั้น ฉันกลับ ไว้ใจน้อยที่สุด

    • ประโยคสุดท้ายของหน้าจริง ๆ ก็ยังบอกว่า “โปรดใช้อย่างระมัดระวัง และรับความเสี่ยงเอง
  • ฉันเข้าใจแนวทางของ Microsoft และ GitHub
    คุณค่าของโค้ดไม่ได้อยู่ที่ตัวโค้ดล้วน ๆ แต่คือ รูปแบบที่บรรจุความรู้ขององค์กร เอาไว้
    เพราะแบบนี้ กระแสการปรับปรุงอย่างต่อเนื่องและอัตโนมัติ จึงสำคัญ
    การรีแฟกเตอร์ครั้งใหญ่แบบหักดิบจะทำลาย mental model ขององค์กร ดังนั้นการปรับปรุงเล็ก ๆ อย่างต่อเนื่องจึงเป็นอุดมคติ
    โครงสร้างที่ดีคือให้ระบบเชิงกำหนดแน่นอนตรวจจับปัญหา แล้วให้ LLM แก้เฉพาะส่วนที่จำเป็น

    • เรายังขาดนามธรรมที่ดีพอสำหรับนิยาม invariants ของโปรเจกต์แล้วส่งต่อให้ agent
      ฉันต้องทำคำแนะนำละเอียดมากในสไตล์ Deep Wiki เอง เลยค่อนข้างยุ่งยาก
      ต้องการเครื่องมือที่ช่วยมองเห็นโครงสร้างได้แบบ C4 diagram
    • แนวทางผสมขั้นตอนอัลกอริทึมกับขั้นตอนของ agent แบบ DataOps pattern มีประโยชน์
      เอกสารที่เกี่ยวข้อง: DataOps pattern
  • ช่วงนี้ผลิตภัณฑ์คลาวด์แทบทุกตัว ฟีเจอร์หลักหยุดนิ่ง แต่ฟีเจอร์รอบนอกเพิ่มขึ้นเรื่อย ๆ
    พอองค์กรใหญ่ขึ้น นักพัฒนาก็ต้องสร้างฟีเจอร์ใหม่ ๆ ปรากฏการณ์แบบนี้เลยเกิดขึ้น
    ถ้ายังไม่หยุด การไล่ล่าการเติบโตแบบไม่สิ้นสุด ผลิตภัณฑ์ก็จะ enshittification ต่อไปเรื่อย ๆ

  • บน landing page ยังไม่ชัดเจนว่า workflow นี้มอบ คุณค่าที่จับต้องได้ อะไรให้ผู้ใช้
    ยังขาดตัวอย่างหรือ use case ที่เป็นรูปธรรม

    • มีตัวอย่างจริงอยู่ใน ส่วนแกลเลอรี
      เช่น workflow จัดการ issue ที่แสดงกรณีการจัดการ PR และ issue แบบอัตโนมัติ
      คุณค่าหลักคือ มอบหมายงานซ้ำ ๆ ที่จัดการด้วย heuristic ไม่ได้ ออกไป
      และบอกว่ายังกำลังปรับแต่งการเล่าเรื่องให้ดีขึ้นอยู่