# Vòng đời một prompt: Claude Code và OMP (Oh-My-Pi)

[exit node](https://homus.dev/speakers/exit-node) · [exit node](https://homus.dev/orgs/exit-node)

> Đi theo một prompt qua harness: input system, progressive disclosure của skill, compaction, role và subagent, hooks, extensions và approvals trong Claude Code và OMP.

Topics: Context Engineering, Coding Agents, Dev Tools

Canonical: https://homus.dev/talks/the-life-of-a-prompt-claude-code-vs-omp-oh-my-pi

## 1. Đi theo một prompt để hiểu harness

exit node mở đầu bằng chủ đề của buổi hôm nay: harness. Anh muốn giải thích sự khác nhau giữa các harness, và lợi ích của việc làm việc trên một harness open source so với một harness closed source như Claude Code (theo exit node, video đăng ngày 17/10/2026). Theo anh, không có cách nào tốt hơn là đi theo vòng đời của một prompt duy nhất: từ lúc bạn gõ nó ra cho tới lúc nhận kết quả ở đầu bên kia, và chuyện gì xảy ra ở khoảng giữa. Anh nói quá trình đó thật ra khá phức tạp.

![exit node nói trước camera trong phòng làm việc có giá sách](https://homus.dev/photos/j24s_X0JDzg-0003.jpg)

exit node nói thẳng vào camera ở phần mở đầu, trước khi chuyển sang bảng vẽ so sánh Claude Code và OMP (video đăng ngày 17/10/2026).

Theo mô tả video (đăng ngày 17/10/2026), anh dùng Excalidraw để vẽ đường đi của prompt qua một agentic coding harness, so sánh Claude Code với OMP (Oh-My-Pi) trên từng chặng. Anh bắt đầu với "the humble prompt", một prompt bình thường, và cho nó đi qua cả Claude Code lẫn OMP. Trên bảng vẽ, ô Prompt nằm trên cùng, chia hai nhánh: một mũi tên sang Claude Code, một mũi tên sang OMP, mỗi bên có một khung "Build input system", tức phần harness ghép lại đầu vào gửi cho model.

## 2. System instructions và project instructions

Thứ đầu tiên mà cả hai harness có chung, theo exit node (video đăng ngày 17/10/2026), là system instructions. Về cơ bản đây là system prompt: các file như agents, claude.md và mọi file hướng dẫn khác được gom lại với nhau, và tất cả đều thuộc về ô này.

Ngoài system prompt, còn có project instructions, về cơ bản là các hướng dẫn riêng cho từng repo (theo exit node, video đăng ngày 17/10/2026). Anh lấy ví dụ ở chỗ làm: trong đó có mô tả về hệ thống Kubernetes của nhóm anh, những điểm kỳ quặc (quirks) riêng của các database, cách các service khác nhau tương tác với nhau, và những thứ tương tự.

Trong đó cũng có vài hướng dẫn chung, yêu cầu harness tự đi sửa lại (course correct) các skill nếu nó tìm thấy lỗi trong đó, để giữ mọi thứ luôn cập nhật, và những việc tương tự. Anh gọi đây là một hệ thống rất thông minh và khuyến khích mạnh mẽ mọi người tận dụng nó (theo exit node, video đăng ngày 17/10/2026).

## 3. Một repo cho mọi công cụ YouTube, rồi tới tool definitions

Một ví dụ tốt, theo exit node, là repo anh dùng cho việc làm YouTube. Trong đó anh có các tool để cắt video YouTube, cắt short, upload lên TikTok, Instagram, và nhiều thứ khác. Mỗi việc có một tool riêng mà anh tự build riêng cho nó (setup của exit node, video đăng ngày 17/10/2026).

Trong project instructions của repo đó, anh để thông tin cho từng tool, hướng dẫn cách khởi chạy ban đầu, bởi anh xử lý toàn bộ việc YouTube từ cùng một thư mục project chính (theo setup của exit node, video đăng ngày 17/10/2026).

Bên cạnh project instructions là tool definitions, và ô này có ở cả hai bên. Về cơ bản, đây là danh sách các tool mà chính harness có trong tay, cùng với skill descriptions (theo exit node, video đăng ngày 17/10/2026).

![Bảng vẽ: Prompt chia hai nhánh Claude Code và OMP, mỗi bên một khung Build input system với System instructions, project instructions, tool definitions, skill descriptions](https://homus.dev/photos/j24s_X0JDzg-0343.jpg)

Hai khung "Build input system" đặt cạnh nhau: bên Claude Code và bên OMP đều có System instructions, project instructions, tool definitions và skill descriptions, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

## 4. Skill descriptions và progressive disclosure

exit node lưu ý: anh không nói "skills", anh nói "skill descriptions". Lý do, theo anh (video đăng ngày 17/10/2026), là các skill được lộ ra cho model dần dần. Tên gọi hoa mỹ cho việc này là progressive disclosure; anh nói đây là một tính năng opt-in, nhưng về cơ bản nó được bật sẵn.

Để lấy ví dụ, một skill gồm hai phần. Phần thứ nhất là description, phần thứ hai là instructions. Description cực kỳ đơn giản, gần như chỉ một hai câu. Còn skill instructions thì khá đồ sộ, nhiều dòng hướng dẫn, và còn những chi tiết phức tạp khác bên trong. Ở đây, cho đầy đủ, anh chỉ cho thấy một skill trông thế nào, và chỉ phần description được lộ ra cho model (theo exit node, video đăng ngày 17/10/2026).

![Bốn khối skill, mỗi khối có dòng Description ở trên và phần Skill instructions lớn ở dưới; bên trái là bốn chữ Description đứng riêng](https://homus.dev/photos/j24s_X0JDzg-0323.jpg)

Mỗi skill là một khối gồm "Description" nhỏ ở trên và "Skill instructions" lớn ở dưới; bên trái, exit node kéo riêng bốn dòng Description ra để minh hoạ phần duy nhất được đưa vào đầu vào của model (video đăng ngày 17/10/2026).

Vì thế, mỗi lần dựng input system, thay vì đổ toàn bộ chỗ text đó vào model, thứ được đưa ra chỉ là một loạt description nhỏ. Model có khả năng invoke từng skill; khi nó invoke skill nào nó cần, nó mới kéo phần skill instructions của skill đó vào cuộc hội thoại (theo exit node, video đăng ngày 17/10/2026). Anh thấy điều này rất hữu ích, vì nó cho phép bạn có tới hàng trăm skill mà hệ thống vẫn cực kỳ hữu dụng.

## 5. Conversation history: turn nối turn

Mục thú vị cuối cùng trong danh sách là conversation history. Nó cũng có ở cả hai harness. exit node kể rằng chính hôm làm research cho video này anh mới phát hiện ra các cuộc hội thoại thật ra được xử lý khác nhau. Từng model có những tính năng dựng sẵn cho chuyện này. Anh nói anh không biết điều đó cho tới gần đây, nhưng hình như OMP có khả năng cắt bỏ (prune) những phần cũ của cuộc hội thoại không còn liên quan nữa (theo exit node, video đăng ngày 17/10/2026).

Anh muốn nói thêm một chút về conversation, vì gần đây anh phát hiện có vài mẹo hay được dùng để tối ưu nó. Để hiểu vì sao cần tối ưu, anh bảo hãy giả sử đây là message ta gửi cho model, và gọi cả phần này là "the conversation" (theo exit node, video đăng ngày 17/10/2026). Đây là message đầu tiên ta gửi. Sau đó ta nhận về một reply: có thể là model reply, có thể có cả tool calls và những thứ tương tự. Anh thả thêm ô tool calls vào hình.

Toàn bộ khối đó, theo cách exit node gọi, là một turn. Một cuộc hội thoại có nhiều turn. Sau khi gửi turn đầu, bạn chuẩn bị prompt tiếp theo, và gửi kèm mọi thứ khác trong đó nữa. Model lại trả lời, có thể kèm tool calls, có thể turn này không có tool call nào; anh nói điều đó cũng không khác gì mấy. Điểm chính là chuyện này sẽ cứ lặp đi lặp lại (theo exit node, video đăng ngày 17/10/2026).

![Hai khung Turn màu đỏ, mỗi khung chứa Build input system với Prompt và conversation, bên phải là Tool calls và Model reply màu xanh lá](https://homus.dev/photos/j24s_X0JDzg-0503.jpg)

Mỗi "Turn" (khung đỏ) gồm toàn bộ Build input system cộng Prompt và conversation, rồi tới Tool calls và Model reply (xanh lá); turn thứ hai chép lại nguyên khối đó, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

## 6. Context management: cắt bỏ những phần vô ích

Khi cuộc hội thoại kéo dài, context của bạn chính là cả khối đó. exit node đổi sang một màu khác để đóng khung nó và ghi "Context". Theo anh (video đăng ngày 17/10/2026), khi nói một harness có khả năng làm context management, ý là thế này.

Giả sử trong một cuộc hội thoại, ở đầu bạn nói "hello", model đáp "hey, what's up, how can I help you?", và mãi sau đó mới vào việc thật sự. Model có thể đi qua những phần trước của hội thoại và xoá những thứ vô ích, như cái prompt ngớ ngẩn của bạn; ở turn đó có lẽ cũng chẳng có tool call nào được gọi, nên phần đó vốn không tồn tại. Nó sẽ giữ lại một bản của những phần như description, conversation và vân vân. Ở turn chào hỏi thì conversation gần như vô nghĩa, nhưng ở những turn khác nó cũng không cần hết chỗ thông tin đó (theo exit node, video đăng ngày 17/10/2026).

Nếu dọn gọn lại một chút, nó có thể chỉ giữ prompt và model reply, chỉ giữ những phần hữu ích của một turn để dùng tiếp về sau, và cố gắng không lặp lại công việc của chính nó. Nhưng anh nhắc: hãy nhớ rằng mỗi lần bạn gửi một turn, toàn bộ context, tức cả phần conversation này, cũng được gửi đi theo. Mỗi turn bạn gửi đều mang theo phần thông tin thêm nằm trong đó (theo exit node, video đăng ngày 17/10/2026).

Ý tưởng context management theo lời exit node (video đăng ngày 17/10/2026): bỏ những turn vô ích như câu chào, và ở các turn còn lại có thể chỉ giữ prompt và model reply.

## 7. Ngưỡng 35% và compaction thành một handoff document

Đây là lý do context quan trọng sống còn, theo exit node (video đăng ngày 17/10/2026): ngay khi bạn vượt quá 35% với hầu hết các model hiện đại, gồm cả Opus 5.5, Astra, Fable và các model khác, tức là khi kích thước context vượt trên 35%, bạn sẽ khổ. Trên bảng vẽ, anh ghi "> 35% context = BAD". Và đó là lý do context window của anh tự compact ở mức 45% (theo setup của exit node, video đăng ngày 17/10/2026).

Vậy compaction ở đây nghĩa là gì? Theo exit node (video đăng ngày 17/10/2026), nó nghĩa là toàn bộ khối này sẽ được phân tích. Có nhiều phương pháp khác nhau để compaction diễn ra, nhưng một trong số đó, chẳng hạn, là model đọc hết mọi thứ ở đây, kiểu: "ok, ông này nói hello, nói vài câu vớ vẩn, rồi cuối cùng mới tới phần hội thoại đáng giá". Nó lấy đúng phần cốt lõi (the juice) và tạo ra một handoff document.

![Khung Context màu xanh bao quanh Conversation với nhiều Turn chồng lên nhau, dòng chữ lớn > 35% context = BAD, mũi tên sang ô handoff.md](https://homus.dev/photos/j24s_X0JDzg-0743.jpg)

Khung "Context" bao quanh cả chuỗi turn, dòng "> 35% context = BAD", và mũi tên dẫn sang ô "handoff.md", nơi compaction gom phần cốt lõi của cuộc hội thoại, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

Document này chỉ chứa một bản tóm tắt của mớ "yapping" đã diễn ra ở các turn cũ. Rồi một model mới được gọi lên với context hoàn toàn mới. Cuộc hội thoại sau compaction sẽ trông như thế này: chỉ có handoff document, cộng với prompt tiếp theo của người dùng; tool definitions và mọi thứ còn lại vẫn có mặt, nhưng file handoff.md cũng nằm trong đó. Và đó sẽ là turn đầu tiên của bạn (theo exit node, video đăng ngày 17/10/2026). Trên bảng vẽ, anh đặt ô handoff.md ngay bên trong khung Build input system phía OMP.

## 8. Agent trong OMP: role, effort và instructions

Nói chung, sau khi build input system được dựng xong, message sẽ được gửi tới một model. Nhưng phần model trong cuộc hội thoại không đơn giản như vậy. exit node vẽ một khung Agent bên dưới mỗi nhánh. Với OMP, theo anh (video đăng ngày 17/10/2026), agent gồm vài phần: một role, một effort và instructions.

Bản thân role, theo exit node (video đăng ngày 17/10/2026), là thế này: trong một role của OMP, bạn có thể đặt nhiều model. Ví dụ, ở role scout, anh có nhiều model khác nhau. Anh thường chạy Haiku 5.5, và effort của anh thường để "inherit", nghĩa là nó sẽ nhìn vào effort mặc định của cả hệ thống rồi gán theo đó. Effort có thể là low, medium, high, max và vân vân, hoặc bất cứ mức nào model đó hỗ trợ.

Với Haiku, anh định đặt inherit, rồi nhớ ra còn có "auto". Theo exit node (video đăng ngày 17/10/2026), effort auto cho một scout nghĩa là model sẽ tự cân nhắc effort cần cho việc: nó đánh giá task sắp được giao cho model đó, rồi tự đặt effort. Anh không dùng auto. Anh không tin nó, vì theo anh nó về cơ bản đặt mọi thứ hoặc max hoặc low, và anh ghét hai thái cực đó. Thường anh chạy mọi thứ ở high, có thể xhigh, và đôi khi medium cho những task cực đơn giản, cần nhanh gọn. Không đi quá sâu, anh thường để của mình ở inherit.

Cách exit node vẽ một agent của OMP (video đăng ngày 17/10/2026): Role chứa model, provider và Effort; instructions nằm ngoài role vì thuộc về chính agent.

## 9. Model dự phòng và provider trong một role

Scout của exit node có Haiku 5.5, nhưng role đó cũng có thể có một hệ thống dự phòng (fallback) phòng khi vì lý do gì đó không gọi được Haiku, chẳng hạn hết credit (theo setup của exit node, video đăng ngày 17/10/2026). Anh khá thích DeepSeek Flash cho các scout agent của mình, đơn giản vì nó là model nhanh hơn. Một model khác anh rất thích là Luna (trên bảng vẽ ghi Luna 6); anh đặt Luna nếu gói Codex subscription của anh đang còn, và cũng để nó ở inherit.

![Ô Scout, bên cạnh là chữ anthropic và ba dòng Haiku 5.5 - inherit, Luna 6 - inherit, Deepseek flash 4 - inherit](https://homus.dev/photos/j24s_X0JDzg-1023.jpg)

Cấu hình role scout của exit node trên bảng vẽ: "Haiku 5.5 - inherit", "Luna 6 - inherit", "Deepseek flash 4 - inherit", và anh đang gõ "anthropic" làm provider cho Haiku (setup của anh, video đăng ngày 17/10/2026).

Anh nói thêm một điều quên chưa nhắc về các model: bạn còn có thể đặt provider (theo exit node, video đăng ngày 17/10/2026). Với Haiku, provider là Anthropic và nó được gắn tag "anthropic"; đó cũng là cách nó hiện trong giao diện. Với Luna, anh nghĩ nó được định nghĩa là "openai-codex". Còn DeepSeek thì anh lấy qua một dịch vụ API trung gian cho model, và nó hiện tương ứng như vậy trong settings.

Đó là cho role scout; các role khác dĩ nhiên có model khác, nhưng trông cũng theo cùng kiểu này. Vậy là có effort, role và provider. exit node vẽ lại một khung gọn hơn để gói cách một agent thực sự trông như thế nào: instructions nằm ngoài role, vì chúng thuộc về agent. Effort thì bạn có thể đặt bên trong role hoặc bên ngoài role. Bạn sẽ có một effort, rồi có thể nhiều cặp provider và model xếp hàng cho một role; những cặp ở dưới chính là fallback. Anh nói đây là một cách biểu diễn tốt, và đó là cho OMP (theo exit node, video đăng ngày 17/10/2026).

## 10. Agent trong Claude Code: model, effort, instructions

Với Claude Code, theo exit node (video đăng ngày 17/10/2026), tình hình khác đi một chút. Cụ thể, vì với Claude Code bạn gần như chỉ dùng được model của Anthropic, bạn có ba lựa chọn model ở đây. Nên agent chỉ gồm model và effort; đó gần như là tất cả lựa chọn bạn có. Theo hiểu biết của anh, Claude Code không thật sự cho lựa chọn fallback, nhưng về cơ bản đó là các lựa chọn bạn có ở đây. À, và instructions nữa.

Về agent instructions trong Claude Code, exit node nói anh chưa từng tự làm việc này. Lý do anh đưa ra: tới lúc anh bắt đầu vọc các agentic harness và agentic orchestration, Claude Code ở cấu hình mặc định đã làm anh bực đến mức anh không muốn nhìn sâu thêm. Thay vào đó, anh chuyển sang một thứ mà anh cho là đầy đủ hơn nhiều (theo exit node, video đăng ngày 17/10/2026).

Nhưng về cơ bản, Claude Code có model, effort, instructions. Và toàn bộ phần build instructions phía trên sẽ được đưa vào chính các agent. Cả hai agent, bên Claude Code lẫn bên OMP, đều nhận phần đó (theo exit node, video đăng ngày 17/10/2026).

Hai khung Agent như trên bảng vẽ của exit node (video đăng ngày 17/10/2026): bên Claude Code là model, effort, instructions; bên OMP là role với nhiều cặp provider và model xếp chồng (các cặp dưới là fallback), cộng Effort và instructions.

## 11. Subagent nhận gì từ agent chính

Cả hai agent đều có khả năng spawn subagent, theo exit node (video đăng ngày 17/10/2026), và anh vẽ nhanh chúng ra: anh chỉ chép lại nội dung của khung agent rồi đổi tên thành "subagent". Các subagent được chính agent chính gọi lên, nhưng chúng vẫn có thông tin.

Rồi anh tự sửa: hình đó chưa chính xác lắm. Chính xác thì thứ được gửi đi là bất cứ thứ gì agent chính quyết định đưa vào subagent. Trong trường hợp này đó sẽ là phần hướng dẫn khởi đầu; anh nghĩ gọi nó là "input" là cách định nghĩa gọn nhất. Về cơ bản, đó là bất cứ định nghĩa nào agent chính cần ở subagent (theo exit node, video đăng ngày 17/10/2026).

![Khung subagent với model, effort, instructions và một bản Build input system nhỏ, mũi tên từ khung Agent của Claude Code sang trái](https://homus.dev/photos/j24s_X0JDzg-1243.jpg)

Khung "subagent" được chép từ khung Agent bên Claude Code (model, effort, instructions và một bản Build input system thu nhỏ), mũi tên cho thấy agent chính gọi subagent lên; bên phải là khung Agent của OMP với các cặp provider và model, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

Một use case, chẳng hạn: một agent muốn làm một plan. Anh nói điều này áp dụng cho cả Claude Code lẫn OMP. Để build plan, ta cần đi gom dữ liệu từ nhiều nguồn khác nhau, có thể là Jira, Confluence, Obsidian và vân vân. Thế là agent sẽ tách ra một scout, một subagent đi do thám (theo exit node, video đăng ngày 17/10/2026).

Theo exit node (video đăng ngày 17/10/2026), đây không hẳn là một thứ có trong Claude Code; nó là thứ của OMP nhiều hơn, vì trong OMP có những role riêng cho từng subagent mà bạn có thể tách ra. Role không có định nghĩa riêng của chúng, chỉ agent mới có. Nên anh lấy một ví dụ từ OMP để làm rõ hơn.

## 12. Các agent dựng sẵn của OMP: scout, planner, reviewer, task

exit node vẽ một phiên bản đơn giản hoá của các agent dựng sẵn (built-in agents) trong OMP: scout, planner, reviewer và task. Theo anh (video đăng ngày 17/10/2026), mỗi agent có giới hạn riêng. Ví dụ, scout chỉ được đọc. Planner được đặt dùng những model nặng nhất. Reviewer được đặt dùng model dành cho review. Còn task có khả năng viết và đọc code, và kiểu tổ chức như vậy.

![Sơ đồ đầy đủ Claude Code và OMP, bên phải là bốn ô scout, planner, reviewer, task](https://homus.dev/photos/j24s_X0JDzg-1403.jpg)

Bốn agent dựng sẵn của OMP theo bản rút gọn của exit node: scout, planner, reviewer, task, đặt cạnh sơ đồ Claude Code và OMP (video đăng ngày 17/10/2026).

Mỗi agent có description riêng, kiểu như task instructions, và anh gom chúng lại thành một ô "agent descriptions". Anh kéo ô đó vào bên trong khung Agent của OMP: agent chính sẽ có thông tin về các description của những agent này (theo exit node, video đăng ngày 17/10/2026).

## 13. Ví dụ lập plan: ba scout cho Obsidian, Slack và Jira

Giả sử việc đầu tiên agent này muốn làm là tạo một plan. Để tạo plan, nó cần đi thu thập thông tin. Nó có thể tách ra vài subagent: có thể một scout cho Obsidian, một cho Slack, một cho Jira. Những scout này dĩ nhiên cần quyền truy cập: Slack và Jira thì exit node truy cập qua MCP server, nên các scout sẽ có quyền vào những MCP server đó; còn scout đi vào Obsidian thì chỉ việc đào bới trong Obsidian (theo setup của exit node, video đăng ngày 17/10/2026).

![Khung Agent của Claude Code với ba mũi tên sang scout - obsidian, scout - slack, scout - jira](https://homus.dev/photos/j24s_X0JDzg-1543.jpg)

Ba mũi tên từ khung Agent bên Claude Code sang "scout - obsidian", "scout - slack" và "scout - jira": cùng một quy trình gom dữ liệu được chép sang phía Claude Code, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

Các scout nạp hết thông tin chúng lấy được, và khi đã gom xong, thông tin đó được đưa ngược về agent. exit node nói quy trình bên Claude Code rất giống, và anh chép luôn nó sang. Chỗ khác nhau, theo anh (video đăng ngày 17/10/2026): thay vì các agent trông như bên OMP với provider, model, effort và vân vân, bên Claude Code chỉ có model và effort, do agent chính đặt.

Theo exit node (video đăng ngày 17/10/2026), lẽ ra bạn nên có quyền truy cập vào cấu hình của từng agent ở đây, nhưng anh không nghĩ Claude Code cho bạn điều đó; ít nhất là lần cuối anh làm việc với nó, anh không nhớ nó cho anh mức kiểm soát chi tiết như vậy đối với việc fan-out subagent.

Điều bạn có thể làm, theo exit node (video đăng ngày 17/10/2026), là cứ gọi subagent lên rồi cầu cho nó làm đúng, hoặc làm một cách hiệu quả. Vì rất thường xuyên nó có thể tính sai lượng dữ liệu trong từng thư mục của bạn và những thứ tương tự. Ví dụ, Obsidian của anh có vài triệu token dữ liệu; còn Slack thì nhìn chung bạn dùng qua tìm kiếm, và có thể làm những tối ưu riêng ở đó. Anh có những tối ưu đó, nhưng sẽ cố không đi quá sâu vào chi tiết ở đây.

## 14. Extensions trong OMP, hooks trong Claude Code

Ngoài các agent và cách định nghĩa chúng, các harness, ít nhất là giữa Claude Code và OMP, có cách xử lý phần mở rộng khác nhau. Với OMP, theo exit node (video đăng ngày 17/10/2026), vì nó là open source nên bạn có thể đi sửa theo đúng nghĩa đen bất cứ thứ gì bạn muốn. Nhưng nó cũng cho bạn extensions; anh nghĩ chúng được gọi là extensions hoặc plugins, một trong hai.

Với Claude Code, thay vì extensions, bạn có hooks, và về cơ bản chúng có thể được cắm vào từng phần của hệ thống (theo exit node, video đăng ngày 17/10/2026). Ví dụ, mỗi khi một tool được gọi, bạn có thể gọi kèm một hook. Hoặc khi bạn làm việc với một thư mục cụ thể, mỗi lần có truy cập vào thư mục đó, bạn có thể kích hoạt một hook để chạy một bước kiểm tra bảo mật hay thứ gì đó tương tự. Đó là một ví dụ về hook.

Còn với phương án tương ứng của OMP là extensions, theo exit node (video đăng ngày 17/10/2026), một extension có thể là một tool definition hoàn toàn khác, hoặc một cách khác để xử lý system instruction hay các prompt.

![Sơ đồ đầy đủ: bên trái Claude Code có ô hooks và approvals, bên phải OMP có ô extensions và approvals; khung Agent của OMP có thêm Effort và agent descriptions](https://homus.dev/photos/j24s_X0JDzg-1903.jpg)

Phía Claude Code thêm hai ô "hooks" và "approvals", phía OMP thêm "extensions" và "approvals"; khung Agent của OMP giờ có cả ô "agent descriptions", theo sơ đồ của exit node (video đăng ngày 17/10/2026).

Anh đưa một ví dụ hook trong Claude Code mà chính anh gọi là cực kỳ ngớ ngẩn: mỗi khi bạn gửi prompt, bạn gửi kèm "+69". Theo đúng nghĩa đen, bạn gắn đoạn text "+69" vào cuối prompt. Vậy là mỗi khi prompt được nhận rồi chuyển tới các agent và mọi thứ phía sau, nó luôn mang theo "+69", vì đó là hook ta đang có. Nếu muốn có hook "+69" đó trong OMP, nó sẽ là một extension cho phần prompts, và bạn vẫn đạt được đúng y như vậy ở bên này (theo exit node, video đăng ngày 17/10/2026).

## 15. Approvals và advisor

Một thứ khác áp dụng cho mỗi tool call, và về cơ bản cho mọi bước, là approvals. exit node nói đây chỉ là RBAC, kiểm soát truy cập cho từng phần của hệ thống, và anh không nghĩ ở đây có gì quá ghê gớm (theo exit node, video đăng ngày 17/10/2026).

Với Claude Code, theo exit node (video đăng ngày 17/10/2026), việc này được xử lý sẵn. Ví dụ, nếu bạn chạy ở auto mode, nó vẫn phải qua approval: Anthropic chạy một model riêng chỉ để làm approval, kiểm tra từng lệnh agent muốn gọi, hay bất cứ thứ gì khác được kích hoạt, qua một bước approval. Trong OMP, theo anh, bạn có cái đó như một lựa chọn; nó lỏng lẻo hơn nhiều (loosey-goosey) trong OMP.

Nói chung, trong OMP còn có một role gọi là advisor, và advisor này có thể đi kèm từng lượt của mỗi agent. Theo cách exit node mô tả (video đăng ngày 17/10/2026): mỗi khi một agent gọi một thứ gì đó, trước khi lượt của nó thực sự được thực thi, nó sẽ đi qua advisor, và tất cả đều cấu hình được. Chỉ sau đó nó mới tiếp tục tới phần thực thi và đi vào một turn đầy đủ.

Thứ tự exit node mô tả cho OMP (video đăng ngày 17/10/2026): lời gọi của agent đi qua advisor trước khi được thực thi; bên Claude Code, ở auto mode, approval do một model riêng của Anthropic đảm nhận.

## 16. Gọi tool hay trả lời

Rồi tới phần tiếp theo, và với cả hai harness nó giống hệt nhau, theo exit node (video đăng ngày 17/10/2026): hoặc chạy một tool, hoặc đưa ra một câu trả lời. Anh nói anh có thể đi sâu hơn vào tools, answers và mọi thứ khác, nhưng về cơ bản là vậy.

![Hình thoi Tool or Answer nhận mũi tên từ Agent và từ Advisor, một nhánh sang ô tool có mũi tên quay lại, một nhánh xuống ô answer](https://homus.dev/photos/j24s_X0JDzg-2003.jpg)

Hình thoi "Tool or Answer": mũi tên đến từ Agent và từ khung Advisor; nhánh sang "tool" có mũi tên vòng quay lại, nhánh xuống "answer" là kết quả cuối, theo sơ đồ của exit node (video đăng ngày 17/10/2026).

Nếu là tool, tool đó sẽ gọi một loạt thứ, nhưng cuối cùng nó luôn quay về chính model. Tuỳ đó là tool hay câu trả lời: tool thường sẽ quay lại, hoặc trả kết quả của nó, rồi đi tiếp sang turn kế nếu cần gọi nhiều tool hay những thứ tương tự (theo exit node, video đăng ngày 17/10/2026). Anh nói đó là những chi tiết phức tạp mà anh không nghĩ cần đi vào, vì video đã khá dài, và anh chỉ muốn cho thấy vòng đời của một prompt, tức là một cuộc thảo luận về harness đội lốt.

Điều anh hy vọng cho thấy, theo exit node (video đăng ngày 17/10/2026): các harness thật ra không khác nhau là mấy, nhưng cấu trúc bên dưới lại khác nhau vô cùng, và tuỳ nhu cầu, bạn có thể thích cái này hơn cái kia.

## 17. Vì sao exit node dùng OMP

Về phần mình, exit node nói anh rất thích OMP. Lý do thứ nhất, theo anh (video đăng ngày 17/10/2026): nó là open source, nên anh có toàn quyền xem mọi thứ được gửi đi. Ví dụ, nếu anh muốn làm gọn system prompt, tức message đầu tiên anh gửi đi, và muốn cực kỳ dè sẻn, anh có toàn quyền trong OMP để giảm nó xuống, rút gọn nó đáng kể cho mục đích riêng của mình. Còn trong Claude, chẳng hạn, bạn không thật sự có quyền kiểm soát đó.

Để so sánh, theo số liệu exit node đưa ra (video đăng ngày 17/10/2026), message khởi đầu của Claude, tổng message sau khi gom lại, vào khoảng 30.000 token, trong khi ở OMP là khoảng 12k. Anh nói khoảng chênh lệch đó khá đáng kể.

Kích thước message khởi đầu theo số liệu exit node nói trong video (video đăng ngày 17/10/2026): khoảng 30.000 token ở Claude so với khoảng 12k ở OMP; độ dài thanh theo đúng tỉ lệ hai con số đó.

exit node cũng rất thích khả năng kiểm soát sâu và đầy đủ đối với các agent. Anh thích mô hình tư duy "một role, rồi provider, model, effort" cho việc định nghĩa agent, vì với anh nó rất logic. Và điều quan trọng nhất, theo anh (video đăng ngày 17/10/2026): với OMP, bạn có thể dùng model từ bất kỳ provider nào.

## 18. Một panel nhiều model để lập plan và review

exit node kể vài setup hay anh đã làm trước đây: anh cho nhiều agent chạy trên nhiều model khác nhau giao tiếp với nhau để review và lập plan. Anh gọi đó là một panel reviewer kiêm planner rất vui, thứ anh rất thích làm gần đây (theo exit node, video đăng ngày 17/10/2026).

![Ba ô trên bảng vẽ: Muse Wonder Full ở trên, opus 5.5 và sol 6.1 ở dưới](https://homus.dev/photos/j24s_X0JDzg-2223.jpg)

Panel ba model trên bảng vẽ của exit node: "Muse Wonder Full" ở trên, "opus 5.5" và "sol 6.1" ở dưới (setup của anh, video đăng ngày 17/10/2026).

Theo exit node (video đăng ngày 17/10/2026), thứ anh thiếu phần lớn thời gian là một model khá thông minh từ một lab thứ ba, và Muse Wonder Full thật ra khá giỏi việc này. Nó không thông minh bằng hai model kia, nhưng nó nhìn thế giới theo một cách khá khác. Bạn có thể cho cả ba model này tranh luận với nhau rồi đưa ra một kết luận rất chắt lọc. Cho việc lập plan và review, anh thật sự rất thích cách làm "panel chuyên gia" này.

exit node khép lại rằng với hôm nay anh nghĩ vậy là đủ, và anh hy vọng video hữu ích với người xem.

## Nguồn và liên kết

- Tên gốc: The Life of a Prompt: Claude Code vs OMP (Oh-My-Pi)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=j24s_X0JDzg](https://www.youtube.com/watch?v=j24s_X0JDzg)

- Kênh YouTube exit node (exit node): [youtube.com/channel/UCASjrPJfHsvX-0AVz9eSfAQ](https://www.youtube.com/channel/UCASjrPJfHsvX-0AVz9eSfAQ)

- OMP (Oh-My-Pi), repo open source, fork của Pi; README mô tả các role như default, smol, slow, plan, task, advisor và chuỗi fallback theo role (đọc ngày 27/10/2026): [github.com/can1357/oh-my-pi](https://github.com/can1357/oh-my-pi)

- Tài liệu extensions của OMP (đọc ngày 27/10/2026): [docs/extensions.md](https://github.com/can1357/oh-my-pi/blob/main/docs/extensions.md)

- Tài liệu advisor của OMP; trang này mô tả advisor là model review gắn vào session, đọc các cập nhật của agent chính và chèn lời khuyên lại, và ghi rằng advisor không trực tiếp approve hành động (đọc ngày 27/10/2026): [docs/advisor-watchdog.md](https://github.com/can1357/oh-my-pi/blob/main/docs/advisor-watchdog.md)

- Tài liệu compaction của OMP (đọc ngày 27/10/2026): [docs/compaction.md](https://github.com/can1357/oh-my-pi/blob/main/docs/compaction.md)

- Claude Code docs, hooks reference; trang liệt kê các hook event như UserPromptSubmit, PreToolUse, PostToolUse (đọc ngày 27/10/2026): [code.claude.com/docs/en/hooks](https://code.claude.com/docs/en/hooks)

- Claude Code docs, subagents (đọc ngày 27/10/2026): [code.claude.com/docs/en/sub-agents](https://code.claude.com/docs/en/sub-agents)

- Claude Code docs, skills (đọc ngày 27/10/2026): [code.claude.com/docs/en/skills](https://code.claude.com/docs/en/skills)

- Claude Code docs, permission modes; trang ghi rằng ở auto mode, một model thứ hai là classifier xem xét các hành động thay bạn (đọc ngày 27/10/2026): [code.claude.com/docs/en/permission-modes](https://code.claude.com/docs/en/permission-modes)

- Excalidraw, công cụ vẽ được nêu trong mô tả video: [excalidraw.com](https://excalidraw.com)

Nguồn: https://homus.dev/talks/the-life-of-a-prompt-claude-code-vs-omp-oh-my-pi · cập nhật 2026-10-27