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

Canonical source: https://maguyva.ai/th/blog/progressive-disclosure-cli-into-agents

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-01-20 · Author: Maguyva Team

> ระบบ agent นั้นมองการทำงานภายในได้ยากโดยค่าเริ่มต้น การเปิดเผยแบบค่อยเป็นค่อยไปมอบมุมมอง CLI แบบเป็นชั้นให้ผู้ควบคุม ตั้งแต่การตรวจสถานะอย่างรวดเร็วไปจนถึงรายละเอียดภายในของ agent และร่องรอยการตัดสินใจ

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

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

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

## ปัญหาการมองไม่เห็นการทำงานภายใน

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

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

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

คุณจะรู้ได้อย่างไรว่า 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: สุขภาพระบบ

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

```bash
$ orkestra system status
```
```json
{
  "agents": 40,
  "skills_internal": 466,
  "skills_vendor": 240,
  "skills_total": 706,
  "commands": 17
}
```

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

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

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

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

```bash
$ orkestra agents list
```

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

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

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

```bash
$ orkestra agents search "database"
```

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

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

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

```bash
$ orkestra agents info architecture-advisor
```

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

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

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

```jsonc
{
  "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 ปฏิบัติตามการตัดสินใจที่บันทึกไว้ เมื่อคุณต้องการเข้าใจ *ทำไม* บางอย่างถึงทำงานแบบเฉพาะ รีจิสทรีการตัดสินใจคือแหล่งความจริง

```bash
$ orkestra decisions search "agent"
```

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

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

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

```bash
$ orkestra decisions info DEC-SR-049
```

```json
{
  "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: โค้ดอินเทลลิเจนซ์ โดยตรง

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

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

```
mcp__maguyva__intelligent_search
  query: "agent context loading"
```

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

```
mcp__maguyva__find_symbol
  symbol_name: "load_agent_context"
```

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

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

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

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

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

```bash
$ orkestra search "database" --summary
```

```json
{
  "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. **เชื่อมต่อกับโค้ดอินเทลลิเจนซ์** ท้ายที่สุด ผู้ใช้ต้องเห็นการอิมพลีเมนต์

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

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