> For the complete documentation index, see [llms.txt](https://getsquish.gitbook.io/squish/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://getsquish.gitbook.io/squish/th/the-primitive/the-navigation-loop.md).

# วงจรการนำทาง

ลูปการนำทางคือวิธีที่เอเจนต์ใช้ Squish จริง ๆ: อ่านชีตสรุปภาพรวม มองหาโซนที่สำคัญ รัน Squish ซ้ำเฉพาะช่วงเวลานั้นด้วยความหนาแน่นที่สูงขึ้น และทำซ้ำจนกว่าจะเห็นคำตอบ — จากนั้นอ้างอิงไทม์สแตมป์แบบสัมบูรณ์ แทนการดึงข้อมูลแทนการเล่นซ้ำ

## ห้าขั้นตอน

1. **ภาพรวม** รัน Squish กับคลิปทั้งหมด — `squish clip.mov --json` (CLI) หรือ `squish_video` เครื่องมือ (MCP) — แล้วอ่านชีตด้วยการมองเห็น เซลล์เรียงตามลำดับเวลา ซ้าย→ขวา บน→ล่าง
2. **นำทาง** มองหาโซนที่สำคัญ; ทุกเซลล์มีไทม์โค้ดแบบสัมบูรณ์ เซลล์ที่อยู่ติดกันและดูคล้ายกันแปลว่าแทบไม่มีอะไรเปลี่ยน; ถ้าระหว่างเซลล์สองอันมีการตัดภาพแบบชัดเจน แปลว่ามีเหตุการณ์เกิดขึ้น somewhere ในช่องว่างนั้น
3. **ซูม** เรียกอีกครั้งโดยตั้ง `จุดเริ่มต้น`/`จุดสิ้นสุด` เป็นไทม์โค้ดที่คุณมองเห็น — ชีตที่หนาแน่นขึ้นในช่วงเวลาที่แคบลง โดยเหลือเฉพาะจุดที่ยังไม่แน่ใจอยู่ ที่อยู่ยังคงเป็นแบบสัมบูรณ์
4. **ทำซ้ำ** จนกว่าจะมองเห็นคำตอบ อย่ากลับไปอ่านคลิปทั้งก้อนด้วยความหนาแน่นสูงเมื่อมีแค่ช่วงหนึ่งที่สำคัญ
5. **อ้างอิง** ตอบด้วยไทม์สแตมป์แบบสัมบูรณ์ ("ที่ 0:07 แท่นกดจะลงมา") — ใครก็ตรวจสอบเทียบกับวิดีโอต้นฉบับได้

## การรันจริง: 34 เฟรมแทน 3,088

ในเซสชันเอเจนต์จริง ฉากตัดถูกระบุไว้ที่ **0.2 วินาที** โดยการดึง **34 เฟรม — ไม่ใช่ 3,088 เฟรมของคลิป** (ภาพรวม → ซูม → ซูม):

1. **ภาพรวม** รันผ่านคลิปทั้งหมดหนึ่งรอบ ฉากตัดปรากฏเป็นรอยตัดภาพชัดเจนระหว่างเซลล์ที่อยู่ติดกันสองอัน — ดังนั้นมันเกิดขึ้น somewhere ระหว่างไทม์โค้ดทั้งสองนั้น แต่ช่องว่างระหว่างเซลล์ยังคงกว้างเป็นระดับวินาที
2. **ซูม** รันซ้ำโดยตั้ง `จุดเริ่มต้น`/`จุดสิ้นสุด` เป็นไทม์โค้ดของสองจุดที่คร่อมเหตุการณ์นั้น ตอนนี้เหตุการณ์เดียวกันตกอยู่ระหว่างที่อยู่สองจุดที่ใกล้กันมากขึ้นบนชีตที่หนาแน่นขึ้นในช่วงเวลาที่แคบลงนี้
3. **ซูมอีกครั้ง** ตอนนี้ช่วงเวลาสั้นพอที่เซลล์จะประทับไทม์โค้ดระดับต่ำกว่าวินาทีได้แล้ว ฉากตัดอยู่ระหว่างเซลล์สองอันที่ห่างกัน 0.2 วินาที — คำตอบมองเห็นได้โดยตรง

เรียกใช้สามครั้ง ดึงมา 34 เฟรม และได้คำตอบสุดท้ายที่แม่นยำถึง 0.2 วินาที ซึ่งตรวจสอบได้เทียบกับต้นฉบับ ถ้าไล่ดูคลิปแบบเส้นตรง จะต้องประมวลผลเฟรมทั้งหมด 3,088 เฟรม ทั้งที่คำถามนี้อยู่ในเสี้ยววินาทีเดียว

## เงื่อนไขคงที่ที่ทำให้ลูปปลอดภัย

**ไทม์โค้ดเป็นแบบสัมบูรณ์เสมอ** เซลล์ภายในหน้าต่าง `1:00–1:30` ประทับ `1:07`เสมอ ไม่ใช่ `0:07` — ในทุกระดับของการซูม ที่อยู่จะอยู่ในระบบพิกัดของวิดีโอต้นฉบับ ไทม์โค้ดที่อ้างอิงตามหน้าต่างจะทำให้ค่าคลาดเคลื่อนสะสมยิ่งขึ้นในการซูมครั้งถัดไปทันที; ไทม์โค้ดแบบสัมบูรณ์ทำให้ที่อยู่ใด ๆ ที่อ่านได้ในทุกระดับสามารถนำไปอ้างอิงในคำตอบ หรือส่งต่อเข้าสู่การเรียกครั้งถัดไปได้ตรง ๆ

**ความละเอียดปรับตามหน้าต่าง** เซลล์ที่ห่างกันตั้งแต่หนึ่งวินาทีขึ้นไปจะประทับ `m:ss`. หน้าต่างที่สั้นกว่าจะประทับไทม์โค้ดที่ละเอียดขึ้นโดยอัตโนมัติ — `m:ss.d` เมื่อเซลล์ห่างกันน้อยกว่า 1 วินาที, `m:ss.dd` น้อยกว่า 0.1 วินาที, `m:ss.ddd` น้อยกว่า 0.01 วินาที — ดังนั้นเซลล์ที่ติดกันจะยังแยกเป็นที่อยู่คนละจุดได้เสมอ ไม่ว่าซูมลึกแค่ไหน ไทม์โค้ดในผลลัพธ์ JSON จะตรงกับพิกเซลที่ประทับบนชีตเสมอ

**ขั้นต่ำที่ระบุที่อยู่ได้คือ 2 มิลลิวินาทีต่อเซลล์** หน้าต่างที่แคบกว่า *เซลล์ × 2 มิลลิวินาที* จะถูกปฏิเสธด้วยข้อผิดพลาดที่บอกวิธีดำเนินการต่อ (ซูมออก หรือ ลดความหนาแน่น) แทนที่จะทำเหมือนว่าสามารถระบุที่อยู่ช่วงเวลาที่เอนจินยังแยกค้นหาไม่ออกได้

{% hint style="info" %}
ระหว่างขั้นต่ำ 2 มิลลิวินาทีและช่วงเฟรมของวิดีโอต้นฉบับเอง ที่อยู่ที่แตกต่างกันอาจแสดง *เฟรม*เหมือนกัน นั่นคือคำตอบที่ซูมได้สูงสุดอย่างซื่อสัตย์ — วิดีโอไม่มีเฟรมมากกว่านี้ในช่วงนั้น — ไม่ใช่ความล้มเหลวในการระบุที่อยู่
{% endhint %}

**สิ่งใดก็ตามที่ชีตแสดงถือเป็นข้อมูลนำเข้าที่ใช้ได้** ลูปนี้วนกลับไปมา: อ่าน `1:07.3` จากชีต แล้วส่งกลับเป็น `จุดเริ่มต้น`ทั้ง `จุดเริ่มต้น` และ `จุดสิ้นสุด` รับทั้งวินาทีแบบธรรมดา (`90`, `67.4`) และสตริงไทม์โค้ด (`1:30`, `01:02:03`, `0:02.5`). สิ่งที่คุณอ่านคือสิ่งที่คุณอ้างอิง และคือสิ่งที่คุณระบุที่อยู่

## ลูปเดียวกันนี้ใช้ได้เหมือนกันทุกหน้าสัมผัส

ลูปทำงานเหมือนกันทุกประการผ่านทางเข้าหลักสองแบบของเอนจินนี้:

* **CLI** — `squish clip.mov --start 1:00 --end 1:15 --density 5x5`. การรันแบบมีหน้าต่างจะสะท้อน `"window": { "start": …, "end": … }` ใน JSON; ผลลัพธ์ของการรันแบบไม่มีหน้าต่างจะไม่เปลี่ยนแปลง ดู [เอกสารอ้างอิง CLI](/squish/th/reference/cli.md).
* **MCP** — `squish_video` เครื่องมือนี้รับ `จุดเริ่มต้น`/`จุดสิ้นสุด` พารามิเตอร์เสริม (วินาทีหรือไทม์โค้ดของชีต) และส่งคืน `timecodes[][]` ที่ตรงกับพิกเซลที่ประทับ ดู [เอกสารอ้างอิง MCP](/squish/th/reference/mcp.md).

ส่วน [API ที่ให้บริการบนโฮสต์](/squish/th/reference/http-api.md) ประมวลผลคลิปทั้งก้อนต่อหนึ่งคำขอ และไม่รับ `จุดเริ่มต้น`/`จุดสิ้นสุด` — ให้ใช้ลูปนี้กับเครื่องมือภายในเครื่อง

ถ้าจะสอนลูปนี้ให้เอเจนต์แบบครบชุด ให้ติดตั้ง [ทักษะสำหรับเอเจนต์](/squish/th/recipes/agent-skill.md); สำหรับรูปแบบคำถามที่ใช้ถามบนชีต ดู [คลังพรอมป์ต์](/squish/th/recipes/prompt-library.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://getsquish.gitbook.io/squish/th/the-primitive/the-navigation-loop.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.