OneCLI

เกตเวย์ข้อมูลรับรองโอเพนซอร์สสำหรับ AI Agent เก็บครั้งเดียวใช้ได้ทุกที่ คีย์ไม่ถูกเปิดเผยต่อเอเจนต์เลย

การระบุตัวตนเอเจนต์ 凭证网关

https://onecli.sh/

ไปยังเว็บไซต์ทางการ

รายงานเชิงลึก

OneCLI เป็นเกตเวย์ข้อมูลประจำตัวแบบโอเพ่นซอร์สสำหรับ AI Agents ที่บ่มเพาะในชุด Y Combinator Summer 2026 และมีดาวมากกว่า 2,800 ดวงบน GitHub ช่วยแก้ปัญหาด้านความปลอดภัยที่ยากที่สุดประการหนึ่งในยุคตัวแทน: เจ้าหน้าที่จำเป็นต้องเรียกใช้ API ภายนอก แต่การมอบกุญแจให้กับตัวแทนโดยตรงนั้นเทียบเท่ากับการติดรหัสผ่านที่ปลอดภัยไว้ที่ประตู โซลูชันของ OneCLI คือการแทรกเกตเวย์พร็อกซีแบบโปร่งใสระหว่างตัวแทนและบริการเป้าหมาย ข้อมูลรับรองจริงจะถูกเข้ารหัสและจัดเก็บไว้ในเกตเวย์ Agent จะเก็บเฉพาะโทเค็นตัวยึดตำแหน่ง และเกตเวย์จะทำการแทนที่ "คีย์ปลอม → คีย์จริง" ทันทีที่ส่งคำขอ ในขณะที่เขียนโครงการ มีการดาวน์โหลดโปรเจ็กต์มากกว่า 320,000 ครั้ง และได้รับเลือกให้เป็นระดับข้อมูลรับรองเริ่มต้นโดย NanoClaw
OneCLI ก่อตั้งโดย Guy Ben Aharon และ Jonathan Fishner ภูมิหลังของผู้ก่อตั้งทั้งสองมุ่งเน้นไปที่วิศวกรรมความปลอดภัย: Guy เป็นวิศวกรคนแรกที่ Argon (ต่อมาถูกซื้อกิจการโดย Aqua Security) และ Jonathan ทำงานเกี่ยวกับการเข้าถึงเครือข่ายแบบ Zero Trust ที่ Axis Security (ต่อมาถูกซื้อโดย HPE) ทั้งคู่มาจากหน่วยข่าวกรองทางทหารของอิสราเอล ก่อนหน้านี้ ทั้งสองทำงานร่วมกันบนเครื่องมือฐานข้อมูลโอเพ่นซอร์ส ChartDB (มากกว่า 20,000 ดาวบน GitHub) แรงจูงใจในการสร้างสรรค์มาจากประสบการณ์ส่วนตัว: เมื่อพวกเขาสร้างเลเยอร์การประสานตัวแทนสำหรับ ChartDB พวกเขาไม่สามารถหาวิธีที่ปลอดภัยในการแจกจ่ายข้อมูลประจำตัวให้กับตัวแทนอัตโนมัติ การวิจัยของทีมพบว่าเกือบทุกทีมที่ใช้ Agent ไม่ว่าจะฮาร์ดโค้ดคีย์ API ลงในไฟล์ .env หรือปรับปรุงโซลูชันตัวแทนแบบด้นสด ในเดือนกรกฎาคม ปี 2026 โปรเจ็กต์นี้ได้รับการเปิดแหล่งที่มาอย่างเป็นทางการและปรากฏบน Hacker News "Show HN" และได้รับความสนใจจากชุมชนอย่างรวดเร็ว Y Combinator โปรโมต OneCLI ต่อสาธารณะผ่านบัญชี X อย่างเป็นทางการเมื่อวันที่ 23 กรกฎาคม 2026 โดยกำหนดให้เป็นเลเยอร์โครงสร้างพื้นฐานที่ “อนุญาตให้ตัวแทน AI ทำงานจริงโดยไม่ต้องจัดเก็บรหัสผ่าน” OneCLI ใช้ใบอนุญาต Apache-2.0 และยังอยู่ในขั้นตอนการทำซ้ำอย่างรวดเร็วในช่วงต้น (v1.42.0+) แต่บริษัทต่างๆ เช่น Docker, MindsDB, Zoho, Coralogix ฯลฯ ได้เริ่มใช้งานแล้ว
ขั้นตอนการทำงานหลักของ OneCLI แบ่งออกเป็นสามขั้นตอน ในขั้นตอนแรก ผู้ปฏิบัติงานจะจัดเก็บข้อมูลประจำตัว API จริงไว้ในห้องนิรภัยที่เข้ารหัสของ OneCLI ในขั้นตอนที่สอง จะมีการออกคีย์ตัวยึด (เช่น FAKE_KEY) ให้กับตัวแทนแต่ละราย และตัวแทนจะใช้คีย์ปลอมเหล่านี้เมื่อทำการร้องขอ HTTP ในขั้นตอนที่สาม เกตเวย์ OneCLI จะสกัดกั้นคำขอ ทำการถอดรหัสและเปลี่ยนข้อมูลประจำตัวให้เสร็จสิ้น ก่อนที่คำขอจะออกจากเกตเวย์ตามกฎการจับคู่โฮสต์และเส้นทาง และสุดท้ายจะส่งต่อคำขอที่มีข้อมูลประจำตัวจริงไปยังบริการเป้าหมาย ในระหว่างกระบวนการทั้งหมด เอเจนต์จะไม่สัมผัสกับคีย์จริงเลยไม่ว่าเวลาใดก็ตาม บนกองเทคโนโลยี OneCLI ประกอบด้วยสามเลเยอร์ เกตเวย์ HTTP ประสิทธิภาพสูงที่เขียนด้วยภาษา Rust มีหน้าที่ดักฟังคำขอขาออกและแทรกข้อมูลรับรอง Agent จะนำโทเค็นการเข้าถึงผ่านส่วนหัว Proxy-Authorization เพื่อยืนยันตัวตนให้เสร็จสมบูรณ์ เว็บแดชบอร์ดที่สร้างโดย Next.js ใช้เพื่อจัดการตัวแทน คีย์ และการอนุญาต เกตเวย์จะวิเคราะห์แบบไดนามิกว่าข้อมูลรับรองใดที่ควรถูกแทรกสำหรับแต่ละคำขอผ่าน API ที่เปิดเผยโดยแดชบอร์ด ชั้นจัดเก็บข้อมูลรับรองใช้การเข้ารหัส AES-256-GCM คีย์จะถูกถอดรหัสเมื่อมีการร้องขอเท่านั้น หลังจากการถอดรหัส จะมีการจับคู่อย่างเคร่งครัดตามรูปแบบโฮสต์และเส้นทาง จากนั้นจึงแทรกในรูปแบบของส่วนหัวคำขอหรือพารามิเตอร์ URL การปรับใช้นั้นง่ายมากและสามารถเริ่มต้นด้วยคำสั่งเดียว: docker run -d --name onecli -p 10254:10254 -p 10255:10255 -v onecli-data:/app/data ghcr.io/onecli/onecli หลังจากเริ่มต้นระบบ ให้ไปที่ http://localhost:10254 เพื่อสร้าง Agent เพิ่มคีย์ จากนั้นชี้พร็อกซี HTTP ของ Agent ไปที่ localhost:10255 เฟรมเวิร์ก Agent ไม่ต้องการการแก้ไขโค้ดใดๆ - สามารถเข้าถึงได้ตราบใดที่รองรับการตั้งค่าตัวแปรสภาพแวดล้อม HTTPS_PROXY ซึ่งรวมถึง Claude Code, Codex, Cursor, Cline และเฟรมเวิร์กหลัก เช่น OpenClaw, NanoClaw, LangChain และ CrewAI OneCLI ยังมีเครื่องมือบรรทัดคำสั่ง onecli CLI ซึ่งช่วยให้ Agent จัดการข้อมูลประจำตัวและคีย์ของตนเองได้โดยอัตโนมัติผ่านคำสั่ง Shell - Agent Orchestrator สามารถสร้าง Agent ใหม่ กำหนดข้อมูลประจำตัว และกำหนดค่ากฎในสคริปต์โดยไม่ต้องดำเนินการแดชบอร์ดด้วยตนเองโหมดภายในเครื่องรองรับการดำเนินการโดยไม่ต้องเข้าสู่ระบบของผู้ใช้คนเดียวโดยไม่ต้องกำหนดค่า NEXTAUTH_SECRET การทำงานร่วมกันเป็นทีมสามารถเปิดใช้งานการตรวจสอบสิทธิ์ Google OAuth ได้ ตัวแปรสภาพแวดล้อมทั้งหมดมีค่าเริ่มต้นที่สมเหตุสมผล ซึ่งจะสร้างขึ้นโดยอัตโนมัติเมื่อไม่ได้ตั้งค่า SECRET_ENCRYPTION_KEY
ปัจจุบัน OneCLI เป็นโอเพนซอร์สฟรีและสมบูรณ์ (Apache-2.0) ระดับฟรีรองรับตัวแทนได้สูงสุด 2 คนและไม่ต้องใช้บัตรเครดิต ปัจจุบันทีมงานโครงการเป็นบริษัทสตาร์ทอัพที่บ่มเพาะโดย Y Combinator และยังไม่ได้ประกาศแผนการกำหนดราคาเฉพาะสำหรับเวอร์ชันเชิงพาณิชย์อย่างเป็นทางการ เส้นทางธุรกิจที่คาดการณ์ได้ ได้แก่ การสนับสนุนหลายเอเจนต์สำหรับรุ่นองค์กร กลไกนโยบายขั้นสูง การบูรณาการผู้ให้บริการข้อมูลประจำตัวทั่วทั้งองค์กร และบริการคลาวด์ที่ได้รับการจัดการ
การตอบสนองของชุมชนโดยรวมต่อ OneCLI นั้นเป็นไปในเชิงบวก โดยเฉพาะอย่างยิ่งภายในชุมชนความปลอดภัยของตัวแทน นักพัฒนาบางคนในกระทู้สนทนาของ Hacker News ชี้ให้เห็นว่าโซลูชัน เช่น โซลูชันตัวแทนข้อมูลประจำตัวไม่ใช่เรื่องใหม่ (เช่น Tokenizer ของ Fly.io, ตัวแทน BuzzFeed SSO เป็นต้น) แต่การใช้งานที่ปรับให้เหมาะกับสถานการณ์ AI Agent ได้ลดเกณฑ์ขั้นต่ำลงอย่างแท้จริง นักพัฒนาบางรายยังแชร์แผนการใช้ HashiCorp Vault กับสคริปต์เพื่อให้ได้เอฟเฟกต์ที่คล้ายกัน แต่ยอมรับว่าประสบการณ์ "นอกกรอบ" ของ OneCLI นั้นดีกว่า วิดีโอสาธิตที่โปรโมตโดยบัญชีอย่างเป็นทางการของ Y Combinator แสดงให้เห็นกระบวนการที่สมบูรณ์ของโค้ด Claude ที่เรียกใช้ GitHub API ผ่านเกตเวย์ OneCLI - เอเจนต์จะเก็บเฉพาะ FAKE_KEY ตลอดกระบวนการ และ PAT จริงจะถูกแทรกโดยเกตเวย์ในขณะที่ส่งคำขอ การประเมินจากชุมชนชาวจีนส่วนใหญ่เป็นเชิงสร้างสรรค์ นักพัฒนาบางรายใน Blog Park ได้ทำการทดสอบจริงกับ OneCLI และเชื่อว่า "ต้นทุนการเปลี่ยนแปลงใกล้เป็นศูนย์" อย่างไรก็ตาม สำหรับทีมที่ใช้ตัวแทนสภาพแวดล้อมการใช้งานจริงอยู่แล้ว จะต้องให้ความสนใจเป็นพิเศษกับการจัดการใบรับรอง HTTPS ของเกตเวย์และการแยกเครือข่าย คนอื่นๆ แสดงความคิดเห็นว่าการจัดการข้อมูลประจำตัวแบบรวมศูนย์ยังหมายถึงความเสี่ยงแบบรวมศูนย์ด้วย หากเซิร์ฟเวอร์ OneCLI ถูกบุกรุก ผู้โจมตีก็จะตกเป็นเป้าหมายที่มีค่าอย่างยิ่ง
OneCLI ได้รับข่าวสารเชิงบวกจากแหล่งข้อมูลที่เชื่อถือได้หลายแห่ง การโปรโมตต่อสาธารณะของ Y Combinator ถือเป็นสัญญาณบอกอุตสาหกรรมว่า Accelerator เชื่อว่าโครงสร้างพื้นฐานการรักษาความปลอดภัยของเอเจนต์เป็นแนวทางอิสระที่ควรค่าแก่การให้ความสำคัญ Agent Times, World AI 360 และสื่ออื่น ๆ ได้รายงานเรื่องนี้แล้ว และโดยทั่วไปเชื่อกันว่ารูปแบบการออกแบบของ OneCLI ซึ่งแยกข้อมูลรับรองนอกหน่วยความจำ Agent คาดว่าจะกลายเป็นเลเยอร์ความปลอดภัยมาตรฐานสำหรับสถาปัตยกรรม Agent จากมุมมองของภาพรวมผลิตภัณฑ์ที่มีการแข่งขัน การแข่งขันหลักที่ OneCLI เผชิญนั้นมาจากโซลูชันสองประเภท ประเภทหนึ่งคือเครื่องมือการจัดการคีย์แบบดั้งเดิม (HashiCorp Vault, AWS Secrets Manager, 1Password) เครื่องมือเหล่านี้แก้ปัญหาการจัดเก็บ แต่ไม่แก้ปัญหาการฉีด - ยังคงมีความเสี่ยงที่จะรั่วไหลหลังจากที่ตัวแทนได้รับกุญแจ อีกประเภทหนึ่งคือเฟรมเวิร์กเอเจนต์ที่เกิดขึ้นใหม่ (เช่น โปรโตคอล MCP) แต่คำจำกัดความของเครื่องมือ MCP ใช้หน้าต่างบริบทของเอเจนต์ และเซิร์ฟเวอร์ MCP แต่ละตัวจะจัดการการรับรองความถูกต้องโดยแยกจากกัน ขาดการจัดการข้อมูลประจำตัวแบบรวม ตำแหน่งที่แตกต่างของ OneCLI คือการค้นหาช่องว่างระหว่างโซลูชันทั้งสองประเภทนี้: การแก้ปัญหาทั้งการจัดเก็บและการฉีดโดยไม่ต้องใช้หน้าต่างบริบทของ Agent
OneCLI ไม่ได้ไร้ความเสี่ยง ปัญหาหลักอยู่ที่โมเดล MITM CA - เกตเวย์จำเป็นต้องเก็บคีย์ CA เพื่อออกใบรับรองสำหรับเป้าหมายที่กำหนดเอง ซึ่งหมายความว่าบนเครื่องที่ใช้ร่วมกันหรือหลายผู้เช่า ช่องโหว่ในการยกระดับสิทธิ์อาจทำให้คีย์ CA เปิดเผยได้ การปรับใช้ต้องมีการดูแลเป็นพิเศษด้วยการแยกคอนเทนเนอร์ Docker และเนมสเปซเครือข่าย แม้ว่าโปรเจ็กต์จะวนซ้ำอย่างรวดเร็วและชุมชนเติบโตอย่างรวดเร็ว แต่ก็ยังอยู่ในช่วง v1.x และ API และรูปแบบการกำหนดค่าอาจเปลี่ยนแปลงไปตามการอัปเกรดเวอร์ชัน สำหรับองค์กรที่ต้องการการรับประกันความเสถียรในระยะยาว ขอแนะนำให้ใช้ OneCLI เป็นโซลูชันที่สามารถประเมินได้สำหรับการตรวจสอบต้นแบบ ในขณะที่ยังคงรักษาการจัดการข้อมูลประจำตัวแบบเดิมไว้เป็นโซลูชันทางเลือก ปัญหาอีกประการหนึ่งที่ไม่สามารถละเลยได้คือความไว้วางใจแบบรวมศูนย์ - การรวมศูนย์ข้อมูลประจำตัวในการจัดการเกตเวย์เดียวช่วยปรับปรุงประสิทธิภาพการดำเนินงานและการบำรุงรักษา แต่ยังหมายความว่าเกตเวย์เองกลายเป็นจุดทำลายเป้าหมายเพียงจุดเดียว ผู้ปฏิบัติงานจำเป็นต้องดำเนินการเสริมความแข็งแกร่งของเกตเวย์ ซึ่งรวมถึงแต่ไม่จำกัดเพียง: การจำกัดการเข้าถึง IP ของแดชบอร์ด การเปิดใช้งานการจัดเก็บข้อมูลภายนอกของบันทึกการตรวจสอบ และการหมุนเวียนคีย์การเข้ารหัสเป็นประจำ
OneCLI เหมาะที่สุดสำหรับทีมทั้งสองประเภท หมวดหมู่แรกคือทีมพัฒนาและปฏิบัติการที่ใช้เอเจนต์การเขียนโค้ด (Claude Code, Codex, Cursor) เอเจนต์เหล่านี้จำเป็นต้องเรียกใช้ API ภายนอกบ่อยครั้ง เช่น GitHub, Slack, Jira ฯลฯ และเอาต์พุตแต่ละบรรทัดอาจมีคีย์ ประเภทที่สองคือทีมที่สร้างระบบการทำงานร่วมกันหลายตัวแทนซึ่งจำเป็นต้องจัดการและตรวจสอบการเข้าถึง API ของตัวแทนทั้งหมดอย่างเท่าเทียมกัน สถานการณ์ที่ไม่เหมาะสม ได้แก่: เอเจนต์ที่ทำงานเฉพาะในเครือข่ายที่แยกออกจากกันโดยสิ้นเชิง ทีมที่มีการปรับใช้ HashiCorp Vault ที่ครบกำหนดแล้วและไม่ต้องการเพิ่มโครงสร้างพื้นฐานเพิ่มเติม และองค์กรมาตรฐานที่ต้องการการตรวจสอบการปฏิบัติตามข้อกำหนดที่เข้มงวด (เช่น SOC 2 Type II) สำหรับอย่างหลัง ขอแนะนำให้รอจนกว่า OneCLI จะทำการตรวจสอบความปลอดภัยของบุคคลที่สามให้เสร็จสิ้น ก่อนที่จะพิจารณาการปรับใช้ระดับการผลิต
OneCLI เข้าถึงจุดที่เป็นปัญหาอย่างแท้จริงในการทำให้ AI Agent ได้รับความนิยม - การรักษาความปลอดภัยข้อมูลประจำตัว - และมอบโซลูชันทางวิศวกรรมที่หรูหราและใช้งานได้จริง การตัดสินหลักคือ "ตัวแทนไม่ควรสัมผัสกุญแจด้วยซ้ำ" และนำหลักการนี้ไปใช้ในระดับสถาปัตยกรรม ในช่วงระยะเวลาการเปลี่ยนแปลงที่สำคัญสำหรับ Agent จากของเล่นไปสู่ประสิทธิภาพการทำงาน OneCLI คาดว่าจะกลายเป็นมาตรฐานความปลอดภัยสำหรับโครงสร้างพื้นฐานของ Agent แต่มูลค่าที่แท้จริงของมันไม่สามารถตรวจสอบได้อย่างสมบูรณ์จนกว่าการตรวจสอบโดยบุคคลที่สามจะเสร็จสิ้นและเวอร์ชัน 2.0 ที่เสถียรจะถูกเผยแพร่

รีวิวจากผู้ใช้

2hyqkek

—

ลองใช้ OneCLI แล้ว ปัญหาการจัดการคีย์ของ Claude Code ถูกแก้จนหมดจด เมื่อก่อนต้องยัด API Key สารพัดลงใน .env ทุกครั้ง ตอนนี้รันด้วยคำสั่ง docker บรรทัดเดียว Agent ไม่รู้คีย์จริงเลยแม้แต่น้อย ความรู้สึกปลอดภัยเพิ่มขึ้นมหาศาล

珊瑚37

—

มีคนเอาไปเทียบกับ HashiCorp Vault ผมว่าตำแหน่งทางการตลาดต่างกัน Vault หนักเกินไป ทีมเล็ก ๆ ที่ทำงานพัฒนา Agent ใช้ OneCLI ดีพลอยคลิกเดียวสบายใจกว่าจริง ๆ

RGonzales_Plus

—

เกตเวย์ HTTP ที่เขียนด้วย Rust ประสิทธิภาพนิ่งจริง ผมวัด latency ดูแล้ว หลังใส่พร็อกซี OneCLI แทบไม่รู้สึกถึงโอเวอร์เฮดเพิ่มเติมเลย เร็วกว่าการไปดึงคีย์จาก Vault ทุกครั้งเยอะมาก

王月珍

—

เห็นบัญชีทางการของ YC โปรโมต OneCLI เลยไปศึกษาดู แนวคิดดีจริง ไม่ใช่การห้าม Agent เรียก API แต่คือการทำให้ Agent ไม่ควรได้แตะคีย์ด้วยซ้ำ ปรัชญาการออกแบบนี้ผมยอมรับ

FrankHicksIII

—

บน Hacker News มีคนตั้งคำถามว่านี่ก็แค่ auth proxy ไม่ใช่เหรอ จริงอยู่ที่โซลูชันคล้ายกันมีมาก่อนแล้ว แต่ตัวนี้ปรับแต่งมาเฉพาะสำหรับสถานการณ์ Agent ใช้ได้ทันทีแกะกล่อง แค่นี้ก็พอแล้ว

AnnGray

—

ดีพลอยง่ายจริง docker run บรรทัดเดียวก็รันได้ แต่มีหลุมอยู่จุดหนึ่ง ต้องจัดการปัญหาใบรับรองแบบ self-signed เอง ถ้าคอนเทนเนอร์ของ Agent ไม่เชื่อถือใบรับรอง CA ทราฟฟิก HTTPS ก็ผ่านไม่ได้

流年472

—

วิธีของ OneCLI ทำให้นึกถึงเคสจริงที่เคยอ่าน: หัวหน้าฝ่ายความปลอดภัยของบริษัทใหญ่แห่งหนึ่งใ��้สิทธิ์ Agent แล้ว Agent ก็เริ่มลบอีเมลอย่างบ้าคลั่ง ถ้าตอนนั้นมีชั้นนโยบายเกตเวย์คอยจำกัด อาจเสียอีเมลไปแค่ไม่กี่ฉบับ ไม่ใช่ทั้งหมด

8j0wz

—

ลองใช้ OneCLI คู่กับ NanoClaw ประสบการณ์ลื่นมาก Agent ไม่รู้เลยว่ามีคีย์อยู่ อยากทำให้รั่วก็ทำไม่ได้ สำหรับทีมที่ซีเรียสเรื่องความปลอดภัย คอมโบนี้ควรค่าแก่การลอง

HaroldStephensIII

—

ผนวก OneCLI เข้ากับเวิร์กโฟลว์ Cursor ของผมแล้ว ตั้งค่า API ของ GitHub, OpenAI และ Slack ครบหมด ขั้นตอนการตั้งค่าเข้าใจง่าย แผงเว็บจัดการ Agent กับคีย์ได้ ความละเอียดของสิทธิ์ก็ละเอียดพอ

AshleyOrtiz

—

ข้อกังวลเดียวคือความเสี่ยงจากการรวมศูนย์ คีย์ทั้งหมดวิ่งผ่านเกตเวย์ OneCLI ถ้าเกตเวย์นี้ถูกเจาะก็จบเห่ทั้งหมด แม้การเก็บข้อมูลแบบเข้ารหัสจะทำได้ดี แต่ใน production ผมยังหวั่นเรื่อง single point of failure อยู่บ้าง

康明_1

—

เทียบเครื่องมือจัดการข้อมูลรับรองมาหลายตัว OneCLI เป็นมิตรกับนักพัฒนาเดี่ยวที่สุด Authsome ไม่ต้องมีโครงสร้างพื้นฐานก็จริงแต่ไม่มีระบบตรวจสอบ ส่วน Vault ก็หนักเกินไป OneCLI ดีตรงที่อยู่ระดับกลางพอดี

Isabella.Morgan

—

เชื่อมกับ Bitwarden ได้นี่ถูกใจมาก คีย์ไม่ต้องเก็บในฐานข้อมูลท้องถิ่นของ OneCLI ดึงจาก Bitwarden ได้โดยตรง ทีมที่ใช้ตัวจัดการรหัสผ่านอยู่แล้วย้ายมาแทบไม่มีต้นทุน

KeithStewartJr

—

ลองดูโค้ดแล้ว ชั้นเกตเวย์ที่เขียนด้วย Rust ทำได้แน่นหนาดี เข้ารหัสข้อมูลนิ่งด้วย AES-256-GCM ถอดรหัสเฉพาะตอนมีคำขอ ดีไซน์ไม่มีจุดอ่อนชัดเจน รอให้เขาเพิ่มขั้นตอนอนุมัติและกฎการมอนิเตอร์ต่อไป

Jacqueline.Adams

—

แม้ OneCLI จะป้องกันคีย์รั่วไหลได้ แต่มันหยุด Agent ที่ได้รับสิทธิ์แล้วทำเรื่องมั่วไม่ได้ ถ้า Agent มีสิทธิ์เรียก Stripe API ก็หักเงินได้ตามใจ ปัญหานี้ยังต้องอาศัยขั้นตอนอนุมัติมาช่วยแก้ ลำพังเกตเวย์อย่างเดียวไม่พอ

Laura_MooreIII

—

ติดตามมาตั้งแต่ Show HN ตอนนี้ 2800+ ดาวแล้ว โตเร็วจริง แสดงว่า pain point นี้โดนใจคนจำนวนมาก สัญญาอนุญาต Apache-2.0 บวกการรับรองจาก YC น่าจับตามอง

7wnel5q

—

หลังติดตั้ง OneCLI มีของแถมที่ไม่คาดคิด: บันทึกตรวจสอบใช้งานดีมาก เมื่อก่อน Agent เรียก API อะไร เรียกเมื่อไหร่ มองไม่เห็นเลย ตอนนี้เห็นหมดชัดเจน ตามแก้ปัญหาได้เร็วขึ้นเยอะ

EHughesIII

—

สถาปัตยกรรมสามชิ้น Gateway + Dashboard + ที่เก็บข้อมูลเข้ารหัส ชัดเจนมาก ประสิทธิภาพของเกตเวย์ Rust ไม่ใช่ปัญหา แผงควบคุม Next.js ก็ใช้ลื่นมือ เพียงแต่เอกสารบางจุดเขียนสั้นเกินไป มือใหม่อาจต้องคลำทางกันหน่อย

smallpeacock198

—

ทำตามบทความทดสอบจริงบน Cnblogs ทีละขั้น ติดตั้งบนเครื่องใช้เวลาไม่ถึงสิบนาที ใช้ Claude Code เรียก GitHub API ตลอดทางเห็นแค่ FAKE_KEY การแทนที่แบบโปร่งใสนี้ให้ความรู้สึกเหมือนเทคโนโลยีล้ำ ๆ จริง

Brian.Martinez168

—

สำหรับคนทำงานพัฒนา AI Agent อย่างผม OneCLI แก้ปัญหาที่ปวดหัวที่สุด ก่อนหน้านี้ทุกครั้งก่อน demo ต้องเช็กว่าไฟล์ .env เผลอ commit ขึ้นไปหรือเปล่า ตอนนี้ไม่ต้องกังวลแล้ว

Web_3Wave

—

ตอนนี้ยังอยู่ในช่วง 1.x การเปลี่ยนแปลงของ API อาจค่อนข้างถี่ ถ้าใช้ใน production แนะนำให้ล็อกเวอร์ชันไว้ ไม่งั้นอัปเกรดแล้วรูปแบบคอนฟิกเปลี่ยนจะยุ่ง

purplepanda996

—

เอา OneCLI ไปต่อกับระบบหลาย Agent ของทีมแล้ว สามโปรเจกต์แยกคีย์และนโยบายของตัวเองต่างหาก ดีไซน์การแยกระดับโปรเจกต์แบบนี้ใช้งานได้จริงมาก ข้อมูลของลูกค้าคนละรายจะไม่ปนกัน

许桂强

—

อยากรู้แค่ว่าเมื่อไหร่จะรองรับการเชื่อมต่อ 1Password ตอนนี้มีแค่ Bitwarden ก็จำกัดไปหน่อย ในทีมมีคนใช้ 1Password เยอะมาก หวังว่าจะเพิ่มให้

DianeMitchell_Plus60

—

Docker คำสั่งเดียวก็ตั้งเสร็จ สะดวกจริง แต่พอลองกับ Agent ที่เป็น Node.js ตัวแปรสภาพแวดล้อม HTTP_PROXY รองรับได้ไม่ดีบน Node เวอร์ชันเก่า ต้องใช้ 22 ขึ้นไป

LoganRodriguez_20234

—

ชื่นชม เคยทดลองมาก่อน การโจมตี Prompt Injection ธรรมดาหลอกเอา OpenAI Key ออกมาจากตัวแปรสภาพแวดล้อมได้สำเร็จ พอใช้ OneCLI แล้วลองโจมตีแบบเดิมอีกครั้ง ปรากฏว่า Agent ไม่มี Key อยู่ในมือเลย อยากให้รั่วก็รั่วไม่ได้

OMpow

—

การออกแบบ policy engine ทำได้ดี กำหนดกฎ allow/block และลิมิตอัตราการเรียกแยกให้แต่ละ Agent ได้ นี่ลึกกว่าการจัดการคีย์ธรรมดามาก ถือเป็นการควบคุมสิทธิ์ที่ชั้นเครือข่ายเลย

云烟737

—

การพึ่งพา PostgreSQL เป็นอุปสรรคอยู่ นักพัฒนาเดี่ยวต้องติดตั้งฐานข้อมูลเพียงเพื่อรันมันดูจะเกินจำเป็นไปหน่อย ดีที่เขาบอกว่ามีเวอร์ชันฝังตัว PGlite ไม่ต้องตั้งฐานข้อมูลแยก รอการซัพพอร์ตอย่างเป็นทางการอยู่

AfraRomkes

—

คุยกับ DevOps ในทีม เขามองว่าแนวทาง MITM proxy ของ OneCLI มีความเสี่ยงด้านการปฏิบัติตามกฎระเบียบสำหรับสภาพแวดล้อมไอทีที่ถูกกำกับดูแลในจีน ใบรับรองแบบ self-signed อาจไม่ผ่านการตรวจสอบมาตรฐานความปลอดภัยแบบแบ่งระดับ แนะนำให้ระวังจุดนี้

WLopezX736

—

บทวิเคราะห์ของ The Agent Times เขียนได้ดี ชี้ประเด็นสำคัญตรงจุด: OneCLI แก้ปัญหาคีย์รั่วไหลได้ แต่แก้ปัญหา Agent ใช้สิทธิ์ในทางที่ผิดไม่ได้ ถึงอย่างนั้นข้อดีก็ยังมากกว่าข้อเสีย อย่างน้อยก็แก้ปัญหาที่ร้ายแรงที่สุดก่อนแล้ว

goldendog167

—

เปิด Issue ถามเรื่องขั้นตอนการอนุมัติ นักพัฒนาตอบเร็วมาก บอกว่าอยู่ใน roadmap แล้ว เป็นโปรเจกต์ที่ Y Combinator ลงทุน ความเร็วในการพัฒนาไม่น่าจะช้า

星辰_14

—

หลังจากอ่านมุมมองเรื่อง CLI กับ Agent ที่ karpathy รีทวีต แล้วกลับมาดูดีไซน์ของ OneCLI ก็เข้ากันจริง ๆ CLI คืออินเทอร์เฟซดั้งเดิมของ Agent การจัดการข้อมูลรับรองที่ชั้น CLI นั้นลึกและเป็นสากลกว่าการทำที่ชั้นแอปพลิเคชัน