Claude Code & agentic workflows — parallelization, chaining, routing, agents

#Anthropic apps — Claude Code & Computer Use (mở màn module Agents)

TL;DR mini. Bài mở màn nhánh cuối của khoá: Agents. Trước khi tự xây agent, ta soi 2 app do Anthropic tự làm như case study — chúng KHÔNG chỉ là tool hữu ích mà là AI agents in action (agent chạy thật). (1) Claude Code = coding assistant chạy trong terminal — sửa file & fix bug, trả lời câu hỏi code, hỗ trợ development workflow; sẽ đi qua setup đầy đủ rồi dùng trên một sample project nhỏ. (2) Computer Use = bộ tool cho Claude tương tác với cả một desktop environment — truy cập website/lướt internet, thao tác desktop application, làm việc cần điều hướng giao diện trực quan (visual interface navigation); mở rộng xa khỏi tương tác text-only. ⭐ Vì sao học 2 cái này để hiểu agent: chúng minh hoạ 4 nguyên tắc làm nên một agent hiệu quả — tool integration & usage · multi-step task execution · environmental interaction · autonomous problem-solving. Progression bài học: Claude Code → Computer Use → Agents (chốt lại điều gì khiến chúng thành công với tư cách agent).

Bài này ở đâu trong khoá. Đây là điểm bắc cầu: mọi thứ trước (API call · tool use · RAG · MCP…) là viên gạch; giờ ghép lại thành agent. Cách tiếp cận của Anthropic: học từ ví dụ có sẵn trước, tự xây sau — soi 2 sản phẩm thật (Claude Code, Computer Use) để rút ra khuôn mẫu, rồi mới đến phần dựng agent của riêng mình.

Claude Code — là gì. Một coding assistant chạy trong terminal (command line). Hình dung: có Claude ngay trong dòng lệnh, sẵn sàng:

• Edit files & fix bugs — sửa file và vá lỗi.
• Answer coding questions — trả lời câu hỏi lập trình.
• Help with development workflows — hỗ trợ các quy trình phát triển.

Lộ trình bài: đi qua toàn bộ quá trình setup, rồi dùng thật trên một sample project nhỏ để thấy chính xác nó vận hành thế nào — không dừng ở lý thuyết.

Computer Use — là gì. Đẩy năng lực Claude đi xa hơn nhiều: một collection of tools cho phép Claude tương tác với một môi trường desktop đầy đủ. Nghĩa là Claude có thể:

• Access websites & browse the internet — mở website, lướt web.
• Interact with desktop applications — thao tác ứng dụng desktop.
• Perform tasks that require visual interface navigation — làm việc cần điều hướng giao diện trực quan (nhìn màn hình, di chuột, bấm nút).

⭐ Điểm mấu chốt: so với tương tác text-only (chỉ chữ vào/chữ ra như phần đầu khoá), Computer Use mở rộng đột phá những gì Claude làm được — vì nó nhìn và điều khiển được cả màn hình, không chỉ đọc/ghi text.

Vì sao 2 app này là case study tốt cho agent. Cả Claude Code lẫn Computer Use đều là ví dụ thực chiến (real-world implementations) để hiểu agent. Chúng phô ra 4 nguyên tắc làm một agent hiệu quả:

1. Tool integration and usage — tích hợp & dùng tool (đúng phần tool use đã học, nhưng ở quy mô một sản phẩm).
2. Multi-step task execution — chạy tác vụ nhiều bước (không phải một câu hỏi–một câu trả lời).
3. Environmental interaction — tương tác với môi trường (file system với Claude Code; desktop/màn hình với Computer Use).
4. Autonomous problem-solving — tự giải quyết vấn đề (tự quyết bước tiếp theo, ít cần người cầm tay).

⚠️ Dễ nhầm. (1) Đây chưa phải bài code — nó là bài định hướng (overview), đặt bức tranh trước khi vào chi tiết. (2) Claude Code ≠ Computer Use: Claude Code sống trong terminal, xoay quanh code/file; Computer Use điều khiển cả desktop qua giao diện trực quan — đừng gộp làm một. (3) Thông điệp lặp lại của Anthropic: hai app này là agents, không chỉ là "tool tiện lợi" — nhấn để chuẩn bị tư duy cho phần Agents.

Góc Delivery Manager. (1) "Học từ sản phẩm có sẵn trước khi tự xây" là một pattern lãnh đạo tốt — trước khi bảo team dựng agent từ số 0, cho họ mổ xẻ 2 reference implementation trưởng thành (Claude Code, Computer Use) để rút khuôn mẫu; rẻ hơn và ít rủi ro hơn thiết kế trên giấy trắng. (2) 4 nguyên tắc = checklist đánh giá "cái này có phải agent thật không" — khi ai đó gọi một tính năng là "AI agent", em soi đủ 4 tiêu chí: có dùng tool không, có chạy nhiều bước không, có tương tác với môi trường ngoài không, có tự quyết không. Thiếu vế "autonomous" và "multi-step" thì thường chỉ là một tool use gọi một phát, không phải agent. (3) Trục phân biệt Claude Code vs Computer Use = phạm vi môi trường — một cái đóng khung trong terminal/codebase (an toàn, dễ kiểm soát), một cái mở ra cả desktop (mạnh hơn nhưng bề mặt rủi ro rộng hơn nhiều: nó bấm được mọi thứ trên máy). Với DM, đó chính là trade-off năng lực ↔ blast radius cần cân khi chọn công cụ cho team.

#Claude Code — năng lực (4 nhóm tool) & cài đặt (3 bước)

TL;DR mini. Claude Code = terminal-based coding assistant chạy thẳng trong command line — "có Claude ngay trong terminal" cho mọi tác vụ code. ⭐ Đi kèm bộ tool toàn diện chia 4 nhóm: (1) File operations — search · read · edit file trong project · (2) Terminal access — chạy command thẳng từ trong cuộc hội thoại · (3) Web access — search documentation, fetch code examples… · (4) MCP Server support — thêm tool bằng cách cắm MCP servers (chính là MCP đã học: mở rộng năng lực bằng specialized tools cho databases · APIs · service khác). Chạy trên MacOS · Windows WSL · Linux. Cài đặt = 3 bước: (1) cài Node.js (kiểm tra sẵn có bằng npm help) · (2) npm install -g @anthropic-ai/claude-code · (3) chạy claude → lần đầu prompt đăng nhập Anthropic account. Guide đầy đủ ở docs.anthropic.com.

Claude Code làm được gì — 4 nhóm tool. Đây là bộ công cụ phục vụ development workflow:

• File operations — search · read · edit file trong project của anh.
• Terminal access — chạy command trực tiếp từ trong cuộc hội thoại (không phải nhảy ra terminal khác).
• Web access — search documentation · fetch code examples và hơn thế.
• MCP Server support — thêm tool bằng cách kết nối MCP servers.

⭐ MCP integration đặc biệt mạnh vì nó nối thẳng vào phần MCP anh vừa học: anh mở rộng năng lực Claude Code bằng cách cắm specialized tools cho databases · APIs · bất kỳ service nào anh dùng. (Đây chính là mô hình client ↔ MCP server: Claude Code = MCP client.)

Cross-platform. Claude Code chạy trên MacOS · Windows WSL · Linux → dùng được bất kể môi trường dev.

Cài đặt — 3 bước.

1. Install Node.js từ nodejs.org/en/download. ⭐ Kiểm tra đã có chưa bằng cách chạy npm help trong terminal (có phản hồi = đã cài).
2. Install Claude Code bằng lệnh: npm install -g @anthropic-ai/claude-code (cờ -g = cài global, dùng được mọi nơi).
3. Start & login: chạy claude trong terminal. Lần đầu nó sẽ prompt đăng nhập Anthropic account.

Guide chi tiết đầy đủ ở docs.anthropic.com nếu cần. Xong 3 bước → có Claude thẳng trong terminal, sẵn sàng cho mọi project.

Góc Delivery Manager. (1) npm install -g = phụ thuộc Node.js — Claude Code là một npm package, nên "cài Node.js trước" không phải thủ tục rườm rà mà là hard dependency; trên Windows còn cần WSL (không chạy native cmd/PowerShell thuần cho bản này). Nhớ đúng chuỗi phụ thuộc này giúp em không debug lộn khi onboard team. (2) 4 nhóm tool = đúng "environmental interaction" của bài trước — file ops + terminal + web + MCP chính là cách Claude Code chạm vào môi trường; ghép với multi-step + autonomous là ra một agent hoàn chỉnh. (3) MCP là cửa mở rộng, không phải tính năng cứng — điểm hay cho DM: năng lực Claude Code không đóng khung; đội nào cần tool riêng (DB nội bộ, API công ty) thì viết/cắm MCP server, không phải chờ Anthropic ra tính năng. Đây là lý do MCP đáng học kỹ ở các bài trước.

#Claude Code — /init, CLAUDE.md & workflow cộng tác (context → plan → implement)

TL;DR mini. Claude Code không chỉ để viết code — nó là "một kỹ sư nữa trong team", đồng hành mọi phase từ setup tới deploy/support. ⭐ Lệnh đầu tiên nên chạy: /init — Claude quét toàn bộ codebase (structure · dependencies · coding style · architecture) rồi tóm tắt vào file CLAUDE.md; file này tự động được đưa vào context ở MỌI hội thoại sau (Claude nhớ dự án). 3 scope CLAUDE.md: Project (chia sẻ cả team, có trong git) · Local (ghi chú cá nhân, KHÔNG vào git) · User (dùng across mọi project). Thêm nhanh ghi chú bằng lệnh # (vd # Always use descriptive variable names → hỏi lưu vào project/local/user memory). ⭐ Workflow hiệu quả nhất = 3 bước: (1) Feed context (bảo Claude đọc file liên quan) → (2) Plan (nói rõ CHƯA viết code, chỉ nghĩ approach + steps) → (3) Implement. TDD variant (chắc hơn): feed context → brainstorm test cases → implement tests → viết code tới khi mọi test pass (Claude có success criteria rõ ràng). Lệnh khác: /clear (xoá lịch sử, reset context) · /init · #. Claude còn lo việc thường ngày: stage & commit git · chạy tests · quản lý dependencies. ⭐ Tinh thần: Claude Code là collaborative partner / effort multiplier, không phải code generator — càng nhiều context & structure, kết quả càng tốt.

/init & CLAUDE.md — bộ nhớ dự án. Việc đầu tiên khi mở một project: chạy /init. Claude scan toàn bộ codebase để hiểu structure · dependencies · coding style · architecture, rồi tóm tắt vào một file đặc biệt tên CLAUDE.md. ⭐ File này tự động được include làm context trong mọi hội thoại về sau → Claude "nhớ" chi tiết quan trọng của dự án mà anh không phải nhắc lại. Khi chạy /init anh có thể thêm chỉ dẫn riêng cho vùng muốn Claude tập trung; file sinh ra gồm build commands · coding guidelines · project-specific patterns.

3 scope của CLAUDE.md. Có thể có nhiều file cho các phạm vi khác nhau:

• Project — dùng chung giữa mọi engineer của dự án (checked into git).
• Local — ghi chú cá nhân, KHÔNG check vào git.
• User — dùng xuyên suốt mọi project của anh.

Lệnh # — thêm ghi chú nhanh. Gõ # + nội dung để bổ sung vào CLAUDE.md. Ví dụ # Always use descriptive variable names → Claude hỏi anh muốn lưu guideline này vào project / local / user memory.

Workflow hiệu quả — "effort multiplier". Claude chạy tốt nhất khi anh coi nó là bộ khuếch đại công sức: càng nhiều context + structure, kết quả càng tốt. Ba bước vàng:

1. Feed context — trước khi bảo Claude xây gì, chỉ ra các file liên quan và bảo nó đọc + phân tích trước. Đây là cách đưa cho Claude ví dụ về coding pattern + chức năng sẵn có để nó xây tiếp lên.
2. Plan (chưa code) — đừng nhảy thẳng vào code; bảo Claude nghĩ thấu vấn đề & lập kế hoạch, và nói rõ KHÔNG viết code lúc này — chỉ approach + steps.
3. Implement — khi đã có plan chắc, bảo Claude triển khai dựa trên context + plan đã cùng làm.

TDD workflow (kết quả robust hơn). Biến thể test-driven:

1. Feed context — như trên, cho Claude xem file liên quan.
2. Brainstorm test cases — bảo Claude nghĩ ra các test để validate feature mới.
3. Implement tests — chọn test hợp lý nhất, cho Claude viết chúng.
4. Viết code cho pass tests — Claude lặp cho tới khi mọi test xanh.

⭐ Vì Claude có success criteria rõ ràng (test phải pass) → code thường chắc chắn hơn.

Ví dụ thực chiến — thêm document_path_to_markdown tool. (1) "Read the math.py and document.py files" → (2) "Plan to implement… (validate file exists · determine type from extension · read binary · leverage existing binary_document_to_markdown · return markdown · add docs · register tool with MCP server · add tests)" → (3) "Implement the plan". Claude tạo function, sửa file cần thiết, viết tests, và chạy luôn test suite để verify.

Lệnh khác cần biết. /clear (xoá lịch sử hội thoại + reset context) · /init (scan codebase → tạo CLAUDE.md) · # (thêm ghi chú vào CLAUDE.md). Ngoài viết code, Claude còn lo stage & commit git · chạy tests · quản lý dependencies → anh khỏi nhảy qua lại editor/terminal, tập trung vào bức tranh lớn.

Góc Delivery Manager. (1) CLAUDE.md = onboarding doc sống của dự án — nó chính là thứ project này đang dùng (file CLAUDE.md ở gốc repo). Với DM, đây là cách mã hoá tri thức đội (build command, convention, cạm bẫy) thành context tự động; 3 scope Project/Local/User ánh xạ đúng 3 tầng "luật chung team / thói quen cá nhân / preference xuyên dự án". (2) "Plan trước, code sau" là kỷ luật, không phải nghi thức — tách planning khỏi implementation cho em (và team) một checkpoint để review hướng đi trước khi tốn công code; đúng tinh thần "validate spec 2 lần" của anh. (3) TDD ở đây lật thứ tự quen thuộc — thường người ta viết code rồi mới test; đưa test lên trước biến "định nghĩa xong là gì" thành success criteria máy kiểm được, khớp cách anh đặt DoD theo pain point. (4) effort multiplier ≠ autopilot — thông điệp lặp lại: chất lượng đầu ra tỉ lệ thuận với context + structure anh cấp; đây là lý do các bài trước (prompt engineering, XML tags, examples) không phí — chúng là cách "cấp structure" cho chính Claude Code.

#Extending Claude Code với MCP — cắm MCP servers vào workflow

TL;DR mini. ⭐ Claude Code có sẵn một MCP client built-in → anh cắm MCP servers để mở rộng đột phá năng lực (không bó trong built-in tools). Mỗi MCP server phơi năng lực qua 3 component: Tools (taking actions) · Prompts (templates) · Resources (accessing data) — đúng bộ 3 khuôn đã học ở module MCP. Đăng ký server = 1 lệnh CLI: claude mcp add [server-name] [command-to-start-server], vd claude mcp add documents uv run main.py; đăng ký xong Claude Code tự connect khi khởi động. Ví dụ: server có tool document_path_to_markdown → bảo "Convert the tests/fixtures/mcp_docs.docx file to markdown" → Claude tự gọi tool đọc & convert. Hệ sinh thái MCP phổ biến: sentry-mcp (discover/fix bugs trong Sentry) · playwright-mcp (browser automation — test/troubleshoot, soi visual component) · figma-context-mcp (expose Figma designs) · mcp-atlassian (Confluence + Jira) · firecrawl-mcp-server (web scraping) · slack-mcp (post/reply messages). ⭐ Sức mạnh thật = ghép nhiều MCP servers khớp quy trình riêng (Sentry lấy lỗi prod → Jira đọc yêu cầu ticket → Slack báo team xong việc → custom server cho tool/API nội bộ).

MCP mở rộng Claude Code thế nào. Claude Code nhúng sẵn MCP client (nối lại đúng bài trước: Claude Code = MCP client). Thay vì bó trong built-in capabilities, anh thêm chức năng tuỳ biến bằng cách connect các MCP server cung cấp tools · resources · integrations cụ thể. Mỗi server phơi năng lực qua 3 component:

• Tools — taking actions (Model-controlled: hàm phơi cho LLM để hành động — API calls, data updates).
• Prompts — templates (User-controlled: interactive templates gọi bằng slash command / menu).
• Resources — accessing data (Application-controlled: contextual data do client app quản — file contents, API responses).

Đăng ký MCP server — 1 lệnh. Dùng command line:

claude mcp add [server-name] [command-to-start-server]

Ví dụ server xử lý document khởi động bằng uv run main.py:

claude mcp add documents uv run main.py

⭐ Đăng ký xong, Claude Code tự động connect server mỗi khi khởi động — không phải nối tay từng phiên.

Ví dụ — đọc PDF/Word. Dựng MCP server có tool document_path_to_markdown (chính tool đã build ở dự án MCP), rồi bảo Claude: "Convert the tests/fixtures/mcp_docs.docx file to markdown" → Claude tự chọn & gọi tool custom đó để đọc document và trả markdown.

Hệ sinh thái MCP phổ biến (đáng nhớ tên + chức năng):

Dựng development workflow riêng. Sức mạnh thật đến từ ghép nhiều MCP servers khớp đúng quy trình của anh, ví dụ một chuỗi:

• Sentry server → fetch chi tiết lỗi production.
• Jira server → đọc yêu cầu của ticket.
• Slack server → báo team khi xong việc.
• Custom servers → tool & API nội bộ của công ty.

→ Claude làm việc liền mạch với đúng bộ công cụ anh đang dùng, thành coding assistant "may đo" theo workflow.

Góc Delivery Manager. (1) claude mcp add = biến MCP từ lý thuyết thành 1 dòng lệnh — cả module MCP trước (client, server, transport, ListTools/CallTool) được nén lại thành một hành động vận hành duy nhất; DM chỉ cần nhớ tên server + lệnh khởi động, phần protocol Claude Code lo. (2) Chuỗi Sentry→Jira→Slack chính là một agent quy trình end-to-end — nó chạm đủ 4 nguyên tắc agent (tool · multi-step · environmental interaction · autonomous): đọc lỗi prod, tra ticket, sửa, báo team. Đây là ví dụ cụ thể nhất về "agent tailored to your workflow" mà anh có thể pitch cho team. (3) Custom server cho tool nội bộ = đòn bẩy lớn nhất cho DM — hệ sinh thái public (Sentry/Jira/Slack) ai cũng cắm được; lợi thế cạnh tranh nằm ở MCP server bọc hệ thống riêng của công ty — viết một lần, cả team (và Claude Code) dùng chung. (4) ⚠️ Mở rộng = mở bề mặt rủi ro — mỗi server cắm thêm là thêm quyền cho Claude chạm vào (post Slack, sửa Jira, scrape web); cân năng lực ↔ blast radius y như trục Claude Code vs Computer Use.

#Workflows vs Agents & Evaluator-Optimizer pattern (mở màn Agents)

TL;DR mini. Workflows và agents = hai strategy xử lý task mà Claude không giải xong trong một request đơn. ⭐ Anh đã làm cả hai suốt khoá — khi dùng tools rồi để Claude tự nghĩ cách hoàn thành, đó chính là một agent. Chọn dựa trên: anh hiểu task rõ tới đâu. Dùng workflow khi anh hình dung được đúng flow/các bước Claude phải đi, HOẶC khi UX của app giới hạn user vào một tập task cố định. Dùng agent khi anh KHÔNG chắc chính xác task / task parameters sẽ đưa cho Claude. Định nghĩa: Workflow = một chuỗi call tới Claude giải một bài toán cụ thể qua các bước định sẵn (predetermined steps) · Agent = cho Claude một goal + một bộ tools, kỳ vọng Claude tự tìm cách đạt goal qua các tool đó. Pattern mẫu: Evaluator-Optimizer — Producer (nhận input → tạo output) · Grader (chấm output theo tiêu chí) · Feedback loop (grader không chấp nhận → phản hồi về Producer) · Iteration (lặp tới khi grader chấp nhận). ⭐ Mục đích học các pattern = có repeatable recipes để cài feature của mình; nhưng nhận diện workflow tự nó chưa làm gì — vẫn phải tự viết code hiện thực nó.

Workflows & agents là gì. Cả hai là strategy cho task nhiều bước (một request không xong). Điểm bất ngờ: anh đã tạo cả hai rồi — mỗi lần đưa tools và để Claude tự quyết cách hoàn thành = một agent.

Chọn workflow hay agent — soi mức độ hiểu task:

• Workflow khi: (1) anh hình dung được chính xác flow/steps Claude cần đi để giải, HOẶC (2) UX app ràng buộc user vào một tập task biết trước.
• Agent khi: anh không chắc chính xác task hay task parameters sẽ giao cho Claude.

Nói gọn: biết trước đường đi → workflow (viết cứng các bước); chỉ biết đích + đồ nghề → agent (để Claude tự dò đường).

• Workflow = một series of calls to Claude giải một bài toán cụ thể qua predetermined series of steps.
• Agent = trao Claude một goal + set of tools, kỳ vọng Claude tự figure out cách đạt goal qua các tool đó.

Ví dụ workflow — Image → CAD. Web app: user drag & drop ảnh một chi tiết kim loại → hệ tạo ra STEP file (chuẩn công nghiệp cho model 3D). Vì ta biết rõ phải làm gì khi có ảnh và viết được thành chuỗi bước cố định bằng code → đây là ứng viên workflow hoàn hảo (không cần agent). Các bước:

1. Feed ảnh vào Claude, bảo nó mô tả object.
2. Dựa trên mô tả, bảo Claude dùng thư viện CadQuery để model object.
3. Create a rendering (dựng ảnh render).
4. Bảo Claude chấm rendering so với ảnh gốc; có lỗi thì fix.

Evaluator-Optimizer pattern. Workflow model 3D ở trên là một ví dụ của pattern này:

• Producer — nhận input, tạo output (Claude dùng CadQuery model chi tiết + tạo rendering).
• Grader — đánh giá output theo tiêu chí nào đó.
• Feedback loop — nếu grader không chấp nhận output → feedback quay về Producer để cải thiện.
• Iteration — vòng lặp lặp lại tới khi grader chấp nhận output.

⭐ Đây đúng tinh thần eval workflow anh học ở module prompt evaluation (producer tạo → grader chấm → lặp), giờ đóng gói thành một pattern kiến trúc có tên.

Vì sao học workflow patterns. Để có repeatable recipes — công thức tái dùng khi cài feature riêng. Evaluator-Optimizer là một pattern đã chứng minh hiệu quả với nhiều engineer → cân nhắc dùng. ⚠️ Nhưng nhớ: nhận diện được workflow tự nó KHÔNG làm gì cho anh — vẫn phải viết code thật để hiện thực; pattern chỉ là khung đã được kiểm chứng, không phải phép màu.

Góc Delivery Manager. (1) Trục workflow↔agent = trục "biết trước bao nhiêu" của scoping — đây là quyết định kiến trúc quan trọng nhất khi giao việc cho LLM: đường đi xác định thì đóng cứng thành workflow (rẻ, kiểm soát được, test được từng bước); đường đi mơ hồ mới thả agent (linh hoạt nhưng khó đoán, khó test). Với DM, mặc định nên nghiêng về workflow khi có thể — ít blast radius hơn. (2) "UX ràng buộc user vào tập task" là tín hiệu chọn workflow rất thực dụng — nếu app chỉ cho user làm vài việc cố định, đừng phí một agent tự do; workflow khớp đúng bề mặt sản phẩm. (3) Evaluator-Optimizer = tự động hoá vòng review — Producer/Grader/Feedback/Iteration chính là mô hình "làm → nghiệm thu → sửa → lặp" mà anh vận hành với team, nay máy tự chạy; giá trị nằm ở chỗ Grader phải có tiêu chí đo được (đúng triết lý DoD theo pain point). (4) ⚠️ Pattern ≠ implementation — câu chốt của bài đáng nhớ cho cả team: vẽ được sơ đồ đẹp không đồng nghĩa xong việc; vẫn phải code, test, maintain. Đừng để "đặt tên pattern" tạo ảo giác đã giải quyết.

#Workflow pattern #1 — Parallelization (chia nhỏ · chạy song song · gộp)

TL;DR mini. Parallelization = pattern tách một task phức thành nhiều sub-task, chạy SONG SONG, rồi AGGREGATE lại. ⚠️ Vấn đề nó giải: nhồi mọi tiêu chí vào một prompt khổng lồ → Claude phải juggle tất cả cùng lúc → confusion, kết quả suboptimal. Ví dụ material designer (ảnh chi tiết → chọn metal · polymer · ceramic · composite · elastomer · wood): thay vì một prompt hỏi tất, ta gửi CÙNG một ảnh nhiều lần đồng thời, mỗi request kèm criteria chuyên cho MỘT vật liệu; Claude đánh giá độc lập từng cái; gom hết analysis result → final aggregation step: gửi tất cả về Claude để so sánh & ra final recommendation. Cấu trúc 3+1: (1) Split task thành nhiều sub-task · (2) Run in parallel (đồng thời → nhanh) · (3) Aggregate kết quả · (4) sub-task KHÔNG cần giống nhau — mỗi cái có thể có prompt · set of tools · criteria riêng. 4 lợi ích: Focused attention · Easier optimization · Better scalability · Improved reliability (giảm cognitive load cho model). Khi dùng: quyết định phức có thể tách thành các independent evaluation (nhiều criteria · so nhiều option · nhiều domain of expertise), mỗi sub-task operate độc lập và góp một mảnh phân tích distinct.

Vấn đề của "single prompt khổng lồ". App material designer: user upload ảnh chi tiết → gợi ý vật liệu tốt nhất trong metal · polymer · ceramic · composite · elastomer · wood. Bản năng đầu: gửi ảnh + một prompt bảo Claude chọn. Chạy được, nhưng bắt Claude gánh quá nhiều trong một request; thiếu criteria cụ thể cho từng loại → kém tin cậy. Vá bằng cách nhồi hết criteria mọi vật liệu vào một prompt to lại sinh vấn đề mới: Claude phải juggle mọi cân nhắc cùng lúc → confusion, suboptimal.

Cách tốt hơn — Parallelization. Thay vì dồn vào một request, tách thành nhiều request song song, mỗi cái chỉ đánh giá chi tiết cho MỘT vật liệu với criteria chuyên biệt:

1. Gửi CÙNG một ảnh cho Claude nhiều lần đồng thời.
2. Mỗi request kèm criteria chuyên cho một vật liệu (Metal Criteria · Polymer Criteria · Ceramic Criteria…).
3. Claude đánh giá độ phù hợp độc lập từng vật liệu.
4. Gom mọi analysis result → đẩy vào final aggregation step.

⭐ Bước cuối (Aggregator): gửi tất cả kết quả lẻ về Claude một lần nữa, yêu cầu so sánh chúng và đưa final material recommendation.

Cấu trúc pattern (3 bước + 1 lưu ý).

• Split a single task into multiple sub-tasks — bẻ quyết định phức thành các đánh giá focused, chuyên biệt.
• Run the sub-tasks in parallel — chạy đồng thời → xử lý nhanh hơn.
• Aggregate the results together — gộp các phân tích chuyên biệt thành quyết định cuối.
• ⭐ Sub-task KHÔNG cần identical — mỗi cái có thể mang prompt · set of tools · evaluation criteria riêng.

4 lợi ích (đáng nhớ tên).

• Focused attention — Claude tập trung một khía cạnh tại một thời điểm, không phải cân nhiều thứ đối chọi → phân tích thấu & chính xác hơn cho từng vật liệu.
• Easier optimization — chỉnh & test prompt từng vật liệu độc lập; metal chưa tốt thì sửa riêng nó, không đụng phần khác.
• Better scalability — thêm vật liệu mới = thêm một request song song, không phải viết lại prompt cũ hay lo criteria mới phá criteria cũ.
• Improved reliability — bẻ nhỏ task → giảm cognitive load lên model → kết quả nhất quán, tin cậy hơn.

Khi dùng Parallelization. Hợp khi có quyết định phức tách được thành các independent evaluation: đang bắt AI cân nhiều criteria, so nhiều option, hoặc ra quyết định trải nhiều domain of expertise. ⭐ Chìa khoá = task tách được có ý nghĩa — mỗi sub-task phải chạy độc lập và góp một mảnh phân tích riêng biệt vào quyết định cuối.

Góc Delivery Manager. (1) Parallelization = "chia để trị" cho prompt — đúng phản xạ của anh khi team kiệt sức vì ôm việc to: tách thành mảnh nhỏ độc lập, mỗi người một mảnh, rồi mới tổng hợp. Ở đây "người" là từng lời gọi Claude. (2) "Easier optimization" là lợi ích DM nên nhấn nhất — mỗi sub-task test/sửa riêng biến một prompt khổng lồ khó debug thành nhiều unit nhỏ có thể eval độc lập (nối thẳng module prompt evaluation: giờ mỗi nhánh có eval riêng). (3) Aggregator là điểm rủi ro ẩn — song song hoá phần đánh giá rất gọn, nhưng chất lượng cuối dồn vào bước gộp; nếu Aggregator prompt yếu thì mọi phân tích tốt phía trước vẫn ra recommendation dở. Đầu tư eval cho riêng bước aggregate. (4) Song song ≠ luôn rẻ hơn — nhanh hơn về wall-clock (chạy đồng thời) nhưng tốn token gấp N (N vật liệu = N request + 1 aggregate); cân tốc độ ↔ chi phí khi scale số nhánh.

#Workflow pattern #2 — Chaining (chuỗi bước TUẦN TỰ, mỗi bước xây trên bước trước)

TL;DR mini. Chaining = bẻ một task lớn/phức thành các subtask nhỏ, TUẦN TỰ (sequential), mỗi bước xây trên output bước trước — ⭐ đối lập Parallelization: chaining dành cho subtask KHÔNG song song hoá được (non-parallelizable), phải làm nối tiếp. Lợi ích lõi = focus (Claude lo một task tại một thời điểm, không juggle nhiều yêu cầu). Ví dụ social media video tool: (1) tìm trending topic trên Twitter → (2) chọn topic thú vị nhất (Claude) → (3) research topic (Claude) → (4) viết script video ngắn (Claude) → (5) AI avatar + text-to-speech dựng video → (6) post lên mạng xã hội. Ưu điểm: split task lớn thành subtask non-parallelizable · chèn được non-LLM processing giữa các bước · giữ Claude focused một khía cạnh. ⭐ Ứng dụng kinh điển = "Long Prompt Problem": prompt nhiều constraint (không lộ AI · không emoji · tránh giọng sáo/casual · tone professional/technical) → Claude vẫn hay vi phạm vài luật. Giải bằng chaining 2 bước: Step 1 gửi prompt gốc, chấp nhận kết quả đầu chưa hoàn hảo; Step 2 gửi follow-up chỉ tập trung sửa (đưa lại bài + instruction sửa có đánh số: gỡ chỗ nhận là AI · xoá mọi emoji · thay câu "cringey" bằng giọng technical writer). Hiệu quả vì Claude dồn toàn lực vào việc revise thay vì vừa sáng tác vừa canh luật.

Chaining là gì. Bẻ một task lớn, phức thành các subtask nhỏ, tuần tự, mỗi bước xây trên bước trước. Thay vì bắt Claude làm hết một lúc, anh chia thành các focused step nối tiếp nhau.

Ví dụ — social media marketing tool (tự tạo & đăng video). Thay vì một prompt khổng lồ:

1. Tìm trending topics liên quan trên Twitter.
2. Chọn topic thú vị nhất — (Claude).
3. Research topic — (Claude).
4. Viết script cho video định dạng ngắn — (Claude).
5. Dùng AI avatar + text-to-speech dựng video.
6. Post video lên mạng xã hội.

⭐ Chú ý: có bước dùng Claude, có bước không (Twitter API, dựng video, post) — chaining cho phép xen non-LLM processing giữa các bước.

Vì sao chain thay vì một prompt to. Lợi ích chính = focus: giao Claude một task cụ thể tại một thời điểm → nó tập trung làm tốt việc đó thay vì juggle nhiều yêu cầu. Ưu điểm:

• Split task lớn thành các subtask nhỏ không song song hoá được (non-parallelizable).
• Optionally làm non-LLM processing giữa mỗi task.
• Giữ Claude focused vào một khía cạnh của task tổng.

The Long Prompt Problem. Chỗ chaining phát huy mạnh nhất: bắt Claude viết nội dung với nhiều constraint cùng lúc, ví dụ viết technical article mà phải:

• Không đề cập nó do AI viết.
• Tránh dùng emoji.
• Bỏ ngôn ngữ sáo rỗng / quá casual.
• Viết tone professional, technical.

⚠️ Dù nêu rõ hết, Claude vẫn có thể vi phạm vài luật — trả về bài còn emoji, còn nhắc "AI", hoặc thiếu chuyên nghiệp. (Càng nhiều ràng buộc trong một lượt, càng dễ rơi rớt.)

The Chaining Solution — 2 bước. Đừng vật lộn với một prompt to; tách đôi:

• Step 1 — gửi prompt gốc, chấp nhận kết quả đầu có thể chưa hoàn hảo. Claude sinh bài, nhưng có thể phạm vài constraint.
• Step 2 — gửi follow-up chỉ nhắm sửa lỗi: đưa lại chính bài Claude vừa viết + instruction revise có đánh số, ví dụ:

Revise the article provided below. Follow these steps to rewrite the article:
1. Identify any location where the text identifies the author as an AI and remove them
2. Find and remove all emojis
3. Locate any cringey writing and replace it with text that would be written by a technical writer

⭐ Hiệu quả vì ở Step 2 Claude dồn toàn lực vào task revise, không phải vừa sáng tác vừa cân constraint cùng lúc.

Khi dùng Chaining.

• Task phức với nhiều requirement.
• Claude liên tục bỏ sót vài constraint trong prompt dài.
• Cần process/validate output giữa các bước.
• Muốn mỗi interaction focused & manageable.

⭐ Chaining trông như thêm việc, nhưng thường cho kết quả tốt hơn nhồi tất vào một prompt. Mấu chốt = nhận ra khi nào task đủ phức để đáng bẻ nhỏ thành các bước focused, tuần tự.

Góc Delivery Manager. (1) Trục phân biệt phải thuộc: Chaining = TUẦN TỰ (mỗi bước cần output bước trước) · Parallelization = SONG SONG (các nhánh độc lập). Chọn sai trục là hiểu sai bài: task mà bước sau phụ thuộc bước trước thì không parallel hoá được → phải chain. (2) "Generate rồi Revise" là mẹo thực dụng đáng mang đi dùng ngay — thay vì tinh chỉnh một prompt cầu toàn (tốn công, vẫn rớt luật), tách thành "làm nháp → sửa theo checklist đánh số" cho kết quả ổn định hơn nhiều; đây đúng kiểu DoD-checklist của anh, để máy tự soi từng mục. (3) Chèn non-LLM step giữa chuỗi = điểm mạnh kiến trúc — chaining không bắt mọi bước là Claude; validate bằng code, gọi API ngoài, xử lý dữ liệu giữa chừng đều được → workflow thật ngoài đời hầu hết là lai LLM + code. (4) Chaining vs Evaluator-Optimizer — cùng là nhiều lượt gọi, nhưng chaining là các bước KHÁC nhau nối tiếp (chọn→research→viết); evaluator-optimizer là lặp CÙNG một bước tới khi đạt chuẩn. Đừng lẫn.

#Workflow pattern #3 — Routing (phân loại → định tuyến tới MỘT pipeline chuyên biệt)

TL;DR mini. Routing = pattern phân loại request đến rồi định tuyến tới đúng pipeline xử lý chuyên biệt — thay cho một prompt one-size-fits-all. ⚠️ Vấn đề: tool sinh video script, user gõ "programming" cần content Educational (giải thích rõ ràng), gõ "surfing" cần Entertainment (kích thích, hình ảnh) — một prompt generic không kham nổi cả hai. Chạy 2 bước: (1) Categorization — gọi Claude phân loại topic vào một trong các genre định sẵn (Entertainment · Educational · Comedy · Personal vlog · Reviews · Storytelling) · (2) Specialized Processing — dùng category để chọn prompt template phù hợp rồi sinh content. Kiến trúc: User input → Router (phân loại bằng một initial Claude call) → forward tới ĐÚNG MỘT pipeline cho category đó; mỗi pipeline có workflow · prompt · tools riêng tối ưu cho nó. ⭐ Insight lõi: user input chỉ đi tới MỘT pipeline (không phải tất cả) → khác hẳn Parallelization gửi tới MỌI nhánh. Khi dùng: app xử lý nhiều loại request khác nhau · định nghĩa được category rõ · Claude phân loại đáng tin · lợi ích chuyên biệt hoá > overhead của bước routing.

Vấn đề của generic prompt. Tool sinh video script từ topic user. Cùng một prompt nhưng "programming" và "surfing" cần loại content rất khác: programming → Educational (giải thích rõ, có definition); surfing → Entertainment (nhấn sự phấn khích, visual appeal). ⚠️ Một prompt generic không xử lý tốt cả hai.

Bước 1 — định nghĩa content categories (genres). Liệt kê các loại content app có thể cần, mỗi cái một specialized prompt template:

• Entertainment — high-energy, culturally relevant, trendy language.
• Educational — giải thích rõ ràng, ví dụ gần gũi, câu hỏi kích thích tư duy.
• Comedy — sắc, bất ngờ, observation thông minh + timing.
• Personal vlog — authentic, thân mật, kể chuyện đối thoại.
• Reviews — dứt khoát, dựa trải nghiệm, nêu điểm mạnh/yếu + verdict.
• Storytelling — nhập vai, chi tiết sống động, kết nối cảm xúc.

Bước 2 — routing chạy thế nào (2 step).

1. Categorization — gửi topic của user cho Claude, yêu cầu phân vào một genre định sẵn.
2. Specialized Processing — dùng kết quả category để chọn đúng prompt template rồi sinh content thật.

Ví dụ user nhập "Python functions" → hỏi Claude phân loại trước:

Categorize the topic of a video into one of the listed categories:
<topic>Python functions</topic>

<categories>
- Educational
- Entertainment
- Comedy
- Personal vlog
- Reviews
- Storytelling
</categories>

Claude trả "Educational" → anh dùng educational template để sinh script.

Kiến trúc Routing.

• User input đi tới Router trước tiên.
• Router phân loại request bằng một initial Claude call.
• Dựa category → input được forward tới một pipeline xử lý cụ thể.
• Mỗi pipeline có workflow · prompts · tools riêng, tối ưu cho category đó.

⭐ Insight then chốt: user input chỉ đi tới MỘT pipeline chuyên biệt, KHÔNG phải tất cả — nhờ đó mỗi pipeline được tối ưu sâu cho đúng use case của nó.

Khi dùng Routing.

• App xử lý nhiều loại request cần cách tiếp cận khác nhau.
• Định nghĩa được category rõ phủ hết use case.
• Bước categorization được Claude xử lý đáng tin.
• Lợi ích chuyên biệt hoá > overhead của bước routing thêm vào.

⭐ Đặc biệt hợp: customer service bots · content generation tools · mọi app mà "câu trả lời đúng" phụ thuộc nặng vào việc hiểu LOẠI request.

Góc Delivery Manager. (1) Trục phân biệt phải thuộc: Routing gửi input tới MỘT nhánh · Parallelization gửi tới TẤT CẢ nhánh. Cùng vẽ hình cây rẽ nhánh nhưng ngược nhau về "đi mấy đường" — đây là bẫy đề rõ nhất của cụm workflow. (2) Router = một classifier rẻ đứng trước hệ đắt — bước phân loại chỉ tốn một call ngắn nhưng cho phép sau đó chuyên biệt hoá sâu từng pipeline; đúng tư duy phân loại case của anh (5 bước phân tích): nhìn ra loại vấn đề trước, rồi mới áp đúng quy trình. (3) Routing khớp thẳng với "UX ràng buộc user vào tập task" ở bài workflow-vs-agent — khi số loại request là hữu hạn và biết trước, router + template cố định gọn hơn thả một agent tự do. (4) ⚠️ Điểm gãy nằm ở khâu categorize — phân loại sai thì cả pipeline sau dù xịn vẫn trả sai loại content; nên eval riêng bước router (đúng tinh thần eval từng unit), và chỉ dùng routing khi category định nghĩa được rạch ròi.

#Bảng so sánh nhanh — 3 workflow pattern (Parallelization · Chaining · Routing)

Ba pattern hay bị tráo trong đề. Trục phân biệt cốt lõi = input đi mấy nhánh + các bước quan hệ ra sao.

⭐ Mẹo nhớ 1 dòng: Parallelization = tất cả nhánh song song · Chaining = một luồng tuần tự · Routing = chọn đúng một nhánh.

⚠️ Đừng lẫn với Evaluator-Optimizer (không nằm trong 3 cái trên): đó là lặp CÙNG một bước (Producer → Grader → feedback) tới khi đạt chuẩn — khác Chaining (các bước khác nhau nối tiếp). Bốn thứ có thể ghép lẫn nhau trong một app thật (vd: Router chọn nhánh → nhánh đó là một Chain → trong chain có bước Parallelization).

#Agents — goal + abstract tools, để Claude tự lập kế hoạch

TL;DR mini. Agent = bước dịch khỏi workflow có cấu trúc: workflow hợp khi anh biết chính xác các bước; agent toả sáng khi anh KHÔNG chắc bước nào là đúng. Anh trao Claude một goal + một set of tools reasonably abstract rồi để nó tự formulate một plan (nói ra hoặc ngầm) về cách kết hợp các tool đạt goal. ⭐ Mục tiêu của ta = hoàn thành task reliably (đáng tin) và economically (tiết kiệm) — thường khó đạt hơn với agent (đánh đổi reliability + cost). Đổi lại: agent flexibility → UX linh hoạt hơn, tạo một lần chạy tốt rồi deploy giải nhiều bài không lường trước. Sức mạnh nằm ở việc Claude ghép các tool đơn giản theo cách bất ngờ: bộ datetime (get_current_datetime · add_duration_to_datetime · set_reminder) — "mấy giờ?" = 1 tool; "11 ngày nữa thứ mấy?" = chain 2 tool; "reminder tập gym thứ Tư tới" = cả 3; "bảo hành 90 ngày hết khi nào?" → Claude tự nhận ra thiếu info → hỏi lại ngày mua rồi mới tính. ⭐ Best practice: cấp tool reasonably abstract (tổng quát) để Claude tự ghép, KHÔNG cấp tool siêu chuyên biệt. Claude Code là ví dụ mẫu: có bash · read · write · edit · glob · grep (tổng quát), KHÔNG có "refactor code" hay "install dependencies" — Claude tự ghép tool cơ bản làm việc phức mà dev chưa từng lập trình sẵn.

Agent khác workflow ở đâu. Workflow = anh định sẵn chuỗi bước cứng. Agent = anh trao goal + tools, để Claude tự nghĩ cách ghép tool đạt mục tiêu. Vậy nên agent hợp với task đa dạng, khó lường: tạo agent một lần, đảm bảo nó chạy tạm ổn, rồi deploy để giải một dải rộng vấn đề. ⚠️ Đổi lại có trade-off về reliability và cost (bàn kỹ sau).

Bức tranh cốt lõi (slide Agents).

• Ta cho Claude một goal + một set of tools reasonably abstract (đủ tổng quát).
• Claude tự formulate một plan (stated hoặc unstated) về cách dùng tool đạt goal.
• ⭐ Mục tiêu của ta = hoàn thành task reliably và economically — điều này thường khó hơn khi làm với agent.
• Agent flexibility cho phép UX linh hoạt hơn (không bị khoá vào một luồng cứng).

Tools làm nên agent — ghép tool đơn giản theo cách bất ngờ. Bộ 3 datetime tool (nhìn "tầm thường" khi đứng riêng):

• get_current_datetime — lấy ngày giờ hiện tại.
• add_duration_to_datetime — cộng khoảng thời gian vào một mốc.
• set_reminder — đặt reminder cho một thời điểm.

Nhưng Claude chain chúng để xử lý yêu cầu phức dần (đúng sơ đồ Task → Tool Calls):

• "What's the time?" → chỉ get_current_datetime.
• "What day of the week is it in 11 days?" → get_current_datetime → add_duration_to_datetime.
• "Set a reminder to go to the gym next Wednesday" → dùng cả 3 tool nối tiếp.
• ⭐ "When does my 90-day warranty expire?" → Claude nhận ra thiếu thông tin → hỏi lại "bạn mua khi nào?" trước khi tính hạn. (Agent biết khi nào cần thêm dữ liệu, không đoán bừa.)

Tools Should Be Abstract. Insight then chốt để dựng agent hiệu quả: cấp tool reasonably abstract, KHÔNG hyper-specialized. Claude Code minh hoạ hoàn hảo — nó có tool tổng quát, linh hoạt:

• bash (chạy lệnh bất kỳ) · read (đọc file bất kỳ) · write (tạo file) · edit (sửa file) · glob (tìm file) · grep (tìm nội dung).

⭐ Nó KHÔNG có tool chuyên biệt kiểu "refactor code" hay "install dependencies". Thay vào đó Claude tự ghép tool cơ bản để làm các task phức đó → xử lý được vô số kịch bản mà dev chưa hề lập trình sẵn. Đây chính là điểm phân biệt agent linh hoạt vs workflow cứng.

Best practice — combinable tools. Khi thiết kế agent, cấp tool Claude ghép được theo cách sáng tạo. Ví dụ social media video agent:

• bash — truy cập FFMPEG (ghép ảnh + âm thanh thành video).
• generate_image — tạo ảnh từ prompt.
• text_to_speech — đổi chữ thành audio.
• post_media — đăng nội dung lên mạng xã hội.

⭐ Bộ tool này cho phép cả workflow đơn giản ("create and post a video" → agent tự chạy tuốt) lẫn trải nghiệm tương tác ("làm video Python nhưng cho tôi chọn ảnh đầu trước" → agent generate ảnh mẫu → chờ user duyệt → mới dựng video). Agent thích ứng theo feedback + preference của user — điều workflow cứng khó làm. Chính flexibility này khiến agent mạnh cho app động, phản hồi theo user.

Góc Delivery Manager. (1) "Reliably và economically" là hai chữ đắt nhất bài — agent linh hoạt nhưng khó đảm bảo đáng tin + tiết kiệm hơn workflow; với DM đây là lời cảnh báo scope: đừng chọn agent chỉ vì "nghe xịn", chọn khi task thật sự khó lường. Task biết trước đường đi → workflow vẫn thắng về độ tin & chi phí. (2) "Tools should be abstract" là nguyên tắc thiết kế ngược trực giác — bản năng là làm tool càng cụ thể càng "an toàn" (refactor_code), nhưng agent mạnh nhờ tool tổng quát ghép được (bash, edit); tool càng hẹp, agent càng kẹt ở đúng kịch bản dev đã nghĩ tới. Cùng bộ 6 tool generic, Claude Code làm được việc mà không ai lập trình riêng. (3) Ẩn dụ "cùng bộ tool → simple workflow HOẶC interactive" (2 ảnh Marketing Agent) rất đáng nhớ — không phải chọn cứng lúc thiết kế; chính agent quyết chạy thẳng hay dừng hỏi tuỳ user. Đây là "flexible UX" cụ thể hoá. (4) ⚠️ Bộ datetime này chính là project reminder anh đã code — giờ nó được đóng khung lại như định nghĩa agent: goal + tools + Claude tự chain (kể cả tự hỏi lại khi thiếu info). Nối thẳng bài "anh đã làm agent suốt khoá".

#Environment inspection — cho agent "nhìn" được kết quả hành động

TL;DR mini. ⭐ Environment inspection = cho Claude khả năng quan sát & hiểu kết quả hành động của chính nó — bởi mặc định Claude thao tác MÙ (operates blindly). Ví dụ computer use: sau mỗi action (gõ chữ, click) Claude lập tức nhận một screenshot để biết chuyện gì xảy ra — đây là essential, không phải nice-to-have (một cú click có thể chuyển trang, mở menu, đủ thứ; không thấy kết quả = không biết thành công hay môi trường giờ ra sao). Nguyên tắc "Reading Before Writing": trước khi sửa file, Claude phải đọc nội dung hiện tại (vd thêm route vào file Python → đọc code cũ để không phá chức năng đang có). Hướng dẫn qua system prompt: vd agent dựng video → bảo nó dùng whisper.cpp (caption + timestamp verify lời thoại), dùng FFmpeg extract screenshot theo chu kỳ để soi hình, và so output với yêu cầu gốc. 4 lợi ích: better progress tracking · error handling · quality assurance · adaptive behavior. ⭐ Câu hỏi vàng khi thiết kế agent: "How will Claude know if this action worked?" — luôn cấp tool + instruction để Claude quan sát kết quả (đọc file trước khi sửa · screenshot sau thao tác UI · check API response · validate output theo requirement). Nó biến Claude từ blind executor thành agent thật sự hiểu & thích ứng với môi trường.

Vì sao environment inspection quan trọng. Claude mặc định operates blindly — muốn làm việc hiệu quả, nó cần quan sát và hiểu kết quả hành động của mình. Rõ nhất ở computer use: mỗi lần Claude gõ chữ hay click, nó nhận ngay một screenshot để biết điều gì vừa xảy ra. ⚠️ Đây là thiết yếu, không phải tính năng phụ: từ góc Claude, một cú click có thể navigate sang trang mới · mở menu · trigger vô số thay đổi; không thấy kết quả → không biết action thành công hay môi trường giờ trông thế nào.

Reading Before Writing. Cùng nguyên tắc cho file operations: trước khi sửa bất kỳ file nào, Claude phải hiểu nội dung hiện tại. Nghe hiển nhiên nhưng là pattern luôn phải theo khi dựng agent. Ví dụ: được yêu cầu thêm một route mới vào file Python → Claude đọc code hiện có trước để nắm cấu trúc, rồi mới sửa an toàn mà không phá chức năng đang chạy.

System prompts để ép inspection. Anh có thể hướng dẫn Claude tự soi môi trường qua system prompt — càng quan trọng với task phức như video generation. Một video-creation agent cần: sinh nội dung video (FFmpeg) · verify lời thoại (audio dialogue) đặt đúng chỗ · check visual xuất hiện như mong đợi. Instruction mẫu bỏ vào system prompt:

• Dùng bash chạy whisper.cpp sinh caption file kèm timestamp để verify vị trí lời thoại.
• Dùng FFmpeg extract screenshot từ video theo chu kỳ đều để soi hình ảnh đầu ra.
• So sánh nội dung sinh ra với requirement gốc.

4 lợi ích khi Claude soi được môi trường.

• Better progress tracking — Claude ước lượng được còn cách đích bao xa.
• Error handling — kết quả bất ngờ được phát hiện & sửa.
• Quality assurance — output được verify trước khi coi là xong.
• Adaptive behavior — Claude điều chỉnh cách làm dựa trên cái nó quan sát.

Cài đặt thực tế. Khi thiết kế agent, luôn tự hỏi: ⭐ "How will Claude know if this action worked?" Dù làm với file, API hay UI, hãy cấp tool + instruction để Claude quan sát kết quả hành động:

• Đọc nội dung file trước khi sửa.
• Chụp screenshot sau tương tác UI.
• Check API response xem có data mong đợi.
• Validate nội dung sinh ra theo requirement.

⭐ Environment inspection biến Claude từ "blind executor of commands" thành một agent thật sự hiểu & thích ứng với môi trường làm việc.

Góc Delivery Manager. (1) "How will Claude know if this action worked?" là câu hỏi thiết kế agent đáng dán lên tường — nó buộc mọi action phải có đường phản hồi (feedback loop); agent không có mắt thì mỗi bước là một cú nhắm mắt đặt cược. Với DM, đây là tiêu chí review kiến trúc agent: mỗi tool "ghi" (write/click/call) có tool "đọc" tương ứng để xác nhận không? (2) "Reading Before Writing" = phiên bản agent của "đọc code trước khi sửa" — chính kỷ luật anh áp cho team người, nay áp cho Claude; nó là lý do em (Claude Code) luôn Read file trước khi Edit. Bỏ bước này = sửa mù = phá chức năng đang chạy. (3) Inspection chính là vế "environmental interaction" trong 4 nguyên tắc agent — nhưng theo chiều đọc (quan sát) chứ không chỉ ghi (hành động); agent mạnh cần cả hai chiều. (4) Trên computer use, screenshot-sau-mỗi-action = giá phải trả cho "mắt" — nó tốn token/latency (mỗi bước một ảnh) nhưng là điều kiện cần để agent không đi lạc; nối lại trade-off reliability↔cost của bài agent trước.

#Workflows vs Agents — chọn cái nào (bài tổng kết module)

TL;DR mini. Bài chốt: hai lối kiến trúc, Workflow vs Agent, và khi nào dùng cái nào. Workflow = predefined series of calls to Claude giải một bài toán đã biết; dùng khi hình dung được flow các bước trước (bẻ task lớn thành subtask nhỏ, cụ thể). Agent = Claude được cho bộ basic tools và tự formulate plan ghép tool hoàn thành task; dùng khi không biết trước task → cần adaptive. ⭐ Đánh đổi cốt lõi: Workflow thắng về reliability/predictability/dễ test; Agent thắng về flexibility nhưng tỉ lệ hoàn thành thấp hơn, khó instrument/test/evaluate, hành vi kém đoán. ⭐⭐ Kim chỉ nam (câu chốt khoá): mục tiêu số 1 của engineer là giải quyết vấn đề ĐÁNG TIN — user không quan tâm anh xây "agent xịn", họ cần sản phẩm CHẠY ỔN ĐỊNH. Vậy: LUÔN ưu tiên workflow khi có thể, chỉ dùng agent khi THỰC SỰ cần. Workflow cho độ tin & đoán được mà hầu hết app production cần; agent cho linh hoạt khi requirement không thể định trước.

Workflow là gì. Một predefined series of calls to Claude giải một known problem. Dùng khi anh hình dung được flow các bước từ trước — biết chính xác trình tự cần để hoàn thành task. Bản chất = bẻ task lớn thành các subtask nhỏ, cụ thể hơn; mỗi bước lo một mảng → Claude làm chính xác hơn.

Agent là gì. Claude được cho một bộ basic tools và kỳ vọng tự lập plan dùng tool hoàn thành task. Khác workflow, anh không biết chính xác task nào sẽ tới → hệ cần adaptive hơn. Agent sáng tạo ghép tool theo cách bất ngờ để xử lý dải rộng thách thức.

Benefits — Workflows.

• Claude focus một subtask tại một thời điểm → thường accuracy cao hơn.
• Dễ evaluate & test hơn vì biết từng bước chính xác.
• Thực thi predictable & reliable hơn.
• Hợp giải bài toán cụ thể, well-defined.

Benefits — Agents.

• UX linh hoạt hơn.
• Hoàn thành task linh hoạt hơn nhiều — ghép tool theo cách bất ngờ, xử lý đa dạng task.
• Xử được tình huống mới không lường trước lúc dev.
• Hỏi thêm user khi cần input.

Downsides — Workflows.

• Kém linh hoạt — chỉ chuyên trị một loại task.
• UX bị ràng buộc hơn — phải biết trước input vào flow.
• Cần nhiều công thiết kế/lập kế hoạch trước (upfront).

Downsides — Agents.

• Tỉ lệ hoàn thành task thành công THẤP hơn workflow.
• Khó instrument, test, evaluate hơn (thường không biết agent sẽ chạy chuỗi bước nào).
• Hành vi kém đoán trước (less predictable).

Khi dùng cái nào — kim chỉ nam. ⭐ Mục tiêu chính của engineer = giải quyết vấn đề một cách đáng tin (reliably). User không quan tâm anh xây "fancy agent" — họ muốn sản phẩm chạy nhất quán. Khuyến nghị chung:

Luôn ưu tiên triển khai workflow khi có thể; chỉ dùng agent khi thực sự bắt buộc.

Workflow cấp reliability & predictability mà hầu hết app production cần; agent cấp flexibility cho các kịch bản mà requirement không thể định trước. → Workflow khi có quy trình well-defined; Agent khi phải xử request đa dạng, khó lường, cần giải quyết sáng tạo.

Góc Delivery Manager. (1) Câu chốt cả khoá đáng khắc cốt: "ship sản phẩm chạy ổn, không phải ship agent xịn." Đây là liều thuốc chống hype — agent nghe hấp dẫn nhưng tỉ lệ hoàn thành thấp + khó test là rủi ro production thật; DM giỏi mặc định chọn workflow, chỉ nâng lên agent khi thực sự không định trước được requirement. (2) "Dễ evaluate & test" là lý do kỹ thuật lớn nhất nghiêng về workflow — biết từng bước = eval được từng unit (nối thẳng module prompt evaluation); agent không biết chạy chuỗi nào = khó dựng eval đáng tin. Với DM, khả năng đo lường thắng sự "linh hoạt" trên hầu hết bài toán. (3) Trục quyết định gói gọn: "mình có định trước được flow không?" — có → workflow (rẻ, tin, đoán được); không → agent (linh hoạt, đắt, khó đoán). Đây là cùng một trục "biết trước bao nhiêu" xuyên suốt cụm workflow/agent. (4) Thực tế production hầu hết là LAI — router (workflow) chọn nhánh, một nhánh có thể là agent nhỏ có bộ tool; không phải chọn cứng một phe. Nguyên tắc là đẩy càng nhiều phần về workflow càng tốt, cô lập phần agent vào đúng chỗ cần sáng tạo.

Hoàn thành lộ trình 7 phần — quay lại trang tổng quan khoá để luyện đề thi thử 589 câu.

Nguồn: Building with the Claude API (Anthropic Academy) — Copyright Anthropic. Phần đề thi thử cho khoá này nằm ở tab "Đề thi thử" trên trang tổng quan khoá.