การเปิดเผยแบบค่อยเป็นค่อยไป: หน้าต่าง CLI สู่ระบบ Agent

ตัวเลขในบทความนี้สะท้อนระบบ ณ วันที่เผยแพร่ (มกราคม 2026) ดูหน้าทีมของเราสำหรับตัวเลขปัจจุบัน

ระบบ agent ทึบแสงโดยการออกแบบ พวกมันตัดสินใจ เรียกใช้เครื่องมือ และประสานงานข้ามผู้เชี่ยวชาญนับสิบคน แต่เมื่อมีบางอย่างผิดพลาด — หรือเมื่อคุณแค่อยากเข้าใจว่าเกิดอะไรขึ้น — คุณจะมองที่ไหน?

คำตอบคือการเปิดเผยแบบค่อยเป็นค่อยไป: อินเทอร์เฟซแบบเป็นชั้นที่เผยความซับซ้อนพอดีกับที่คุณต้องการ ในเวลาที่คุณต้องการมันพอดี

ปัญหาความทึบแสง

ระบบประสาน agent สมัยใหม่อาจมี:

• agent ผู้เชี่ยวชาญ 40+ ตัว แต่ละตัวมีความสามารถที่แตกต่างกัน
• skill 700+ รายการครอบคลุมทั้งระบบอัตโนมัติภายในและการผสานรวมกับ vendor
• การตัดสินใจเชิงสถาปัตยกรรม 470+ รายการที่หล่อหลอมพฤติกรรม
• เซิร์ฟเวอร์เครื่องมือ MCP หลายสิบตัวที่ให้ความสามารถภายนอก

ความซับซ้อนนี้ตั้งใจ agent ต้องการเข้าถึงบริบทที่หลากหลาย — ความรู้โดเมน, code intelligence, สคีมาฐานข้อมูล — เพื่อตัดสินใจได้ดี แต่ความหลากหลายเดียวกันนั้นสร้างปัญหาการมองเห็น

คุณจะรู้ได้อย่างไรว่า agent ตัวไหนจัดการการย้ายฐานข้อมูล? การตัดสินใจอะไรหล่อหลอมพฤติกรรมการจัดอันดับของระบบค้นหา? เครื่องมือใดที่ที่ปรึกษาสถาปัตยกรรมเข้าถึงได้?

หากไม่มีการเข้าถึงที่มีโครงสร้าง คุณจะเหลือแค่การอ่านซอร์สโค้ดหรือหวังว่าเอกสารจะเป็นปัจจุบัน

การเปิดเผยแบบค่อยเป็นค่อยไปในฐานะสถาปัตยกรรม

การเปิดเผยแบบค่อยเป็นค่อยไปไม่ใช่แค่รูปแบบ UI มันคือหลักการสถาปัตยกรรม: จัดระเบียบข้อมูลเป็นชั้นๆ แต่ละชั้นลึกกว่าชั้นก่อนหน้า เพื่อให้ผู้ใช้หยุดที่ระดับที่ตอบคำถามของตัวเองได้

สำหรับระบบ agent สิ่งนี้แปลงเป็นคำสั่ง CLI ที่ระดับความลึกเพิ่มขึ้น:

ระดับ	คำสั่ง	คำถามที่ตอบ
1	orkestra system status	ทุกอย่างสุขภาพดีไหม?
2	orkestra agents list	agent อะไรมีอยู่?
3	orkestra agents info <name>	agent นี้ทำอะไร?
4	orkestra decisions search	ทำไมมันถึงทำงานแบบนี้?
5	เครื่องมือ MCP ของ Maguyva	แสดงโค้ดให้ฉันดู

แต่ละระดับตอบคำถามติดตามผลตามธรรมชาติ คุณแทบไม่ต้องกระโดดตรงไปที่ระดับ 5 เลย

ระดับ 1: สุขภาพระบบ

คำถามแรกคือเสมอ: ทุกอย่างทำงานอยู่ไหม?

$ orkestra system status

on
{
  "agents": 40,
  "skills_internal": 466,
  "skills_vendor": 240,
  "skills_total": 706,
  "commands": 17
}

หนึ่งคำสั่ง สี่ตัวเลข พอที่จะรู้ว่าระบบถูกตั้งค่าและรีจิสทรีถูกเติมข้อมูลแล้ว

หากจำนวน agent ลดลงอย่างไม่คาดคิด หรือ skill โหลดไม่สำเร็จ คุณจะเห็นมันที่นี่เป็นที่แรก ไม่ต้องขุดบันทึก

ระดับ 2: รายการ Agent

เมื่อคุณรู้ว่าระบบสุขภาพดีแล้ว คำถามถัดไปคือ: มีอะไรบ้าง?

$ orkestra agents list

สิ่งนี้คืนข้อมูลที่มีโครงสร้าง — ชื่อ agent, คำอธิบาย, ค่าที่ต้องการของโมเดล, ความครอบคลุมโดเมน ผลลัพธ์เป็น JSON โดยค่าเริ่มต้น ทำให้ง่ายต่อการต่อเข้ากับ jq เพื่อกรอง:

$ orkestra agents list | jq '.agents[] | select(.model == "opus") | .name'

ต้องการ agent ที่จัดการงานฐานข้อมูล? คำสั่ง search ช่วยจำกัดให้แคบลง:

$ orkestra agents search "database"

สิ่งนี้สแกนชื่อ, คำอธิบาย และความสามารถ คุณเจอผู้เชี่ยวชาญที่ถูกต้องโดยไม่ต้องอ่านคำนิยาม agent 40 ตัว

ระดับ 3: เจาะลึก Agent

เจอ agent ที่ดูเกี่ยวข้องแล้ว? คำสั่ง info เผยทุกอย่าง:

$ orkestra agents info architecture-advisor

ผลลัพธ์รวมถึง:

• Metadata: ชื่อ, หมวดหมู่, ค่าที่ต้องการของโมเดล, คำอธิบาย
• Domains: โดเมนความรู้ไหนที่ agent นี้ครอบคลุม
• Identity: ลักษณะนิสัย (architect, strategist, knowledge-architect)
• คู่มือเครื่องมือ: เอกสารเครื่องมือไหนที่ถูกฉีดเข้าในบริบท
• เครื่องมือ: รายการเครื่องมือ MCP ทั้งหมดที่ agent นี้เข้าถึงได้

นี่คือตัวอย่างสิ่งที่คุณเห็น:

on
{
  "metadata": {
    "name": "architecture-advisor",
    "model": "opus",
    "description": "Strategic decision-making and architectural guidance..."
  },
  "domains": [
    "product",
    "development/architecture",
    "meta/strategy"
  ],
  "tools": {
    "mcp_tools": [
      "mcp__maguyva__intelligent_search",
      "mcp__maguyva__analyze_dependencies",
      "mcp__supabase__execute_sql",
      ...
    ]
  }
}

สิ่งนี้บอกคุณอย่างชัดเจนว่า agent ทำอะไรได้บ้าง ไม่ต้องดูซอร์สโค้ด

ระดับ 4: โบราณคดีการตัดสินใจ

agent ปฏิบัติตามการตัดสินใจที่บันทึกไว้ เมื่อคุณต้องการเข้าใจ ทำไม บางอย่างถึงทำงานแบบเฉพาะ รีจิสทรีการตัดสินใจคือแหล่งความจริง

$ orkestra decisions search "agent"

สิ่งนี้คืนการตัดสินใจเชิงสถาปัตยกรรมที่ตรงกัน:

on
{
  "results": [
    {
      "id": "DEC-SR-049",
      "title": "AI-Agent-First Defaults with Graph Intelligence",
      "domain": "search",
      "status": "active"
    }
  ]
}

แต่ละการตัดสินใจมีที่มาที่ไปครบถ้วน — เมื่อไหร่ที่มันถูกทำ ทำไม ข้อแลกเปลี่ยนอะไรถูกพิจารณา commit ไหนนำไปใช้จริง:

$ orkestra decisions info DEC-SR-049

on
{
  "id": "DEC-SR-049",
  "title": "AI-Agent-First Defaults with Graph Intelligence",
  "summary": "Changes default values for search tools to AI-agent-optimal behavior...",
  "rationale": [
    "AI agents work better with pre-ranked, importance-weighted results",
    "Graph metrics already computed by pipeline - leverage them",
    "Community context helps agents understand feature scope in single query"
  ],
  "source_commits": [
    {
      "sha": "156a880d05eae295669ef7c194b039023f245511",
      "message": "feat(maguyva): enable boost_by_importance..."
    }
  ]
}

นี่คือเอกสารเชิงสถาปัตยกรรมที่ทันสมัยอยู่เสมอ เพราะมันถูกขุดมาจาก commit ไม่ใช่ดูแลด้วยมือ

ระดับ 5: Code Intelligence โดยตรง

เมื่อคุณต้องการเห็นการนำไปใช้งานจริง — ไม่ใช่แค่ metadata เกี่ยวกับมัน — เครื่องมือ MCP ของ Maguyva ให้การเข้าถึงโดยตรง

จากภายในเซสชัน agent:

mcp__maguyva__intelligent_search
  query: "agent context loading"

สิ่งนี้ส่งผ่านอัตโนมัติข้าม semantic, text และ AST search เพื่อหาโค้ดที่เกี่ยวข้อง สำหรับ symbol เฉพาะ:

mcp__maguyva__find_symbol
  symbol_name: "load_agent_context"

สำหรับการวิเคราะห์ dependency:

mcp__maguyva__analyze_dependencies
  target: "packages/orchestration/core/agents.py"

สิ่งเหล่านี้ไม่ใช่แค่ตัวแทน grep พวกมันรับรู้ graph มีดัชนีเชิงความหมาย และผสานรวมกับ code intelligence เดียวกันที่ขับเคลื่อน ตัว agent เอง

การค้นหาแบบรวมข้ามรีจิสทรี

บางครั้งคุณไม่รู้ว่ารีจิสทรีไหนมีคำตอบ การค้นหาแบบรวมครอบคลุมทุกอย่าง:

$ orkestra search "database" --summary

on
{
  "query": "database",
  "total": 254,
  "counts": {
    "agents": 40,
    "skills": 59,
    "decisions": 476,
    "truths": 2,
    "packages": 1
  }
}

254 ผลลัพธ์ที่ตรงกันข้ามรีจิสทรีห้าตัว สรุปบอกคุณว่าจะเจาะลึกที่ไหน ลบ --summary ออกเพื่อผลลัพธ์ที่ละเอียด หรือเพิ่ม --limit 5 เพื่อให้ผลลัพธ์จัดการได้ง่าย

เหตุใดสิ่งนี้จึงสำคัญ

การเปิดเผยแบบค่อยเป็นค่อยไปไม่ใช่แค่เรื่องความสะดวก มันเปลี่ยนวิธีที่คุณโต้ตอบกับระบบที่ซับซ้อน

การดีบักกลายเป็นเรื่องจัดการได้ เมื่อ agent ตัดสินใจอย่างไม่คาดคิด คุณไม่ต้อง grep ผ่านบันทึก คุณตรวจสอบเครื่องมือที่มันเข้าถึงได้ (agents info) การตัดสินใจอะไรหล่อหลอมพฤติกรรมของมัน (decisions search) และตามรอยการนำไปใช้จริงถ้าจำเป็น (intelligent_search)

การออนบอร์ดเร็วขึ้น สมาชิกทีมใหม่ไม่ต้องอ่านโค้ดเบสทั้งหมด พวกเขาเริ่มด้วย system status สำรวจด้วย agents list และเจาะลึกเฉพาะเมื่อพวกเขา เจอบางอย่างที่ไม่เข้าใจ

เอกสารทันสมัยอยู่เสมอ เพราะ CLI อ่านจากรีจิสทรีเดียวกับที่ตั้งค่า agent ผลลัพธ์จึงถูกต้องเสมอ ไม่มีการเบี่ยงเบนระหว่างสิ่งที่เอกสาร บอกกับสิ่งที่ระบบทำ

CLI ในฐานะอินเทอร์เฟซ

เราสามารถสร้างแดชบอร์ดเว็บได้ เราสามารถเขียนเอกสารอย่างละเอียดได้ แต่แทนที่จะทำอย่างนั้น เราสร้าง CLI ที่อ่านจากแหล่งความจริง

CLI มีข้อได้เปรียบ:

• ประกอบได้: ต่อผลลัพธ์ผ่าน jq ผสานรวมกับสคริปต์
• เขียนสคริปต์ได้: ทำการตรวจสอบอัตโนมัติ สร้างรายงาน
• เร็ว: ไม่มีการโหลดหน้า ไม่มีขั้นตอน authentication
• แม่นยำ: อ่านการตั้งค่าจริง ไม่ใช่ตัวแทนที่แคชไว้

สำหรับระบบที่ความถูกต้องสำคัญกว่าความสวยงาม CLI ชนะ

การสร้างการเปิดเผยแบบค่อยเป็นค่อยไปของคุณเอง

หากคุณกำลังสร้างระบบ agent ให้พิจารณาว่าผู้ใช้จะตรวจสอบมันอย่างไร:

1. เริ่มด้วยการตรวจสุขภาพ หนึ่งคำสั่งที่บอกคุณว่าสิ่งต่างๆ ทำงานอยู่หรือไม่
2. มอบมุมมองรายการ แสดงรายการสิ่งที่มีอยู่ก่อนอธิบายว่ามันทำอะไร
3. เปิดใช้การคิวรีแบบเจาะจง การค้นหาชนะการเรียกดูในระดับใหญ่
4. เปิดเผยที่มาที่ไป ให้ผู้ใช้ตามรอยการตัดสินใจไปยังต้นกำเนิดของมันได้
5. เชื่อมต่อกับ code intelligence ท้ายที่สุด ผู้ใช้ต้องเห็นการนำไปใช้จริง

แต่ละชั้นตอบคำถามติดตามผล สร้างพวกมันตามลำดับความถี่ — ผู้ใช้ส่วนใหญ่หยุดที่ชั้น 2 หรือ 3 มีเพียงผู้ใช้ขั้นสูงเท่านั้นที่ไปถึงชั้น 5

เป้าหมายไม่ใช่การเปิดเผยทุกอย่าง มันคือการเปิดเผยสิ่งที่จำเป็นพอดี ในเวลาที่จำเป็นพอดี นั่นคือการเปิดเผยแบบค่อยเป็นค่อยไปที่นำไปใช้กับสถาปัตยกรรม agent