Module 1. Claude Platform & Solution Design

Danh sách các bài học và nội dung ánh xạ.

↓↓↓ Hiểu mục tiêu của Module 1.

Thiết kế solution với Claude vượt xa việc chỉ lựa chọn một model

↓↓↓ Ánh xạ vào kiến trúc Multi-Agent

4 đặc tính cốt lõi mà các Architect dùng làm căn cứ thiết kế

Bài này chưa tạo component cụ thể, nhưng đặt ra 4 nguyên tắc nền mà kiến trúc sau này phải tuân theo:

4 nguyên tắc kiến trúc cần ghi nhớ

1. Non-deterministic → cần Evaluation + Verification, không coi output là deterministic.

2. Context là tài nguyên hữu hạn → cần quản lý context/token budget.

3. Confidence ≠ Validity → các output quan trọng cần verification / HITL.

4. Knowledge boundary → dùng RAG / Tools / MCP làm source of truth khi cần.

👉 LEGO được đặt xuống ở bài này:
Agent không nên tự làm tất cả. Kiến trúc cần có chỗ cho Tools + Retrieval + Verification + Context Management + Evaluation.

↓↓↓

Entry points, build-time interfaces, delivery routes | HungPH. Blog

Phác thảo kiến trúc của chúng ta như bên dưới.

Developer

│

▼

Claude Code

│

▼

AI-DLC Orchestrator

│

├── Planner Agent

├── Developer Agent

├── Reviewer Agent

├── Test Agent

├── Deploy Agent

└── Production Verify Agent

│

▼

Claude Agent SDK

│

▼

Anthropic API

│

▼

Claude

↓↓↓

Các thành phần cấu tạo nên solution của một Architect | HungPH. Blog

Các thành phần này thuộc layer AI-DLC Orchestrator.

Claude Code

│

▼

┌─────────────────────────────┐

│ AI-DLC Orchestrator │

│ │

│ Agent Teams │

│ Dynamic Workflows │

│ Subagents │

│ Skills │

│ Tools │

│ Hooks │

│ MCP │

└─────────────┬───────────────┘

│

▼

Claude Agent SDK

│

▼

Anthropic API

│

▼

Claude

Cụ thể như bên dưới.

AI-DLC Orchestrator

│

├── Agent Team

│ ├── Planner

│ ├── Developer

│ ├── Reviewer

│ ├── Tester

│ └── Deploy/Verify

│

├── Dynamic Workflow

│ └── Plan → Code → Review → Test

│ ↑ │

│ └── Fix ←─┘

│

├── Subagents

│ └── isolated context cho từng task

│

├── Tools

│ ├── Git

│ ├── File/Code

│ ├── Test

│ ├── Vercel

│ ├── Render

│ └── Production verification

│

├── Hooks

│ └── deterministic guardrails

│

└── Skills

├── deploy procedure

├── testing procedure

└── coding procedure

↓↓↓

Claude nằm ở đâu trong hệ thống (Claude / systems / humans)

Zoom vào AI-DLC Orchestrator

Trước đây ta đang hình dung:

AI-DLC Orchestrator
    │
    ├── Planner
    ├── Developer
    ├── Reviewer
    ├── Tester
    └── Deploy/Verify

Bây giờ cần bổ sung Delegation Boundary:

AI-DLC Orchestrator
    │
    ├── Claude / Agents
    │     ├── Understand requirement
    │     ├── Plan
    │     ├── Generate code
    │     ├── Review
    │     └── Analyze test results
    │
    ├── Existing / Deterministic Systems
    │     ├── Git
    │     ├── Test Runner
    │     ├── Vercel
    │     ├── Render
    │     └── Production systems
    │
    └── Human
          ├── Approval
          └── Exception / high-stakes decision

LEGO mới của bài này

Delegation Map trở thành một phần của architecture.

Ví dụ:

↓↓↓

Kết hợp các primitives thành Augmented Call, Workflow, Agent

1. Big picture — bài này tác động vào đâu?

Bài này tác động trực tiếp vào layer AI-DLC Orchestrator, cụ thể là cách chúng ta định hình control flow của Agent Team.

Kiến trúc hiện tại:

Claude Code
    │
    ▼
┌─────────────────────────────────────┐
│         AI-DLC Orchestrator         │
│                                     │
│  Agent Team                         │
│  Dynamic Workflow                   │
│  Subagents                          │
│  Tools / MCP                        │
│  Hooks                              │
│  Skills                             │
└──────────────────┬──────────────────┘
                   │
                   ▼
            Claude Agent SDK
                   │
                   ▼
             Anthropic API
                   │
                   ▼
                Claude

Bài này cho chúng ta thêm một quyết định quan trọng:

Không phải cứ có Agent Team thì toàn bộ AI-DLC phải là Agent.

Với mỗi phần việc, phải chọn: Augmented LLM / Workflow / Agent.

2. Zoom vào AI-DLC Orchestrator

Với use case của chúng ta:

Developer → create feature A → AI tự Plan → Code → Review → Test → Deploy → Verify

Nếu nhìn toàn bộ AI-DLC, đây là một Workflow + Agent kết hợp, chứ không phải pure Agent.

                    AI-DLC Orchestrator
                            │
             ┌──────────────┴──────────────┐
             │                             │
        WORKFLOW                         AGENT
   control flow cố định          tự quyết định bước tiếp theo
             │                             │
             ▼                             ▼
      Plan → Code → Review          Explore codebase
             → Test                     │
             → Deploy                   ├─ đọc file
             → Verify                   ├─ tìm dependency
                                        ├─ chạy tool
                                        └─ quyết định tiếp

Vì sao?

Một số bước của AI-DLC predictable:

Plan
 ↓
Code
 ↓
Review
 ↓
Test
 ↓
Deploy
 ↓
Production Verify

Ta hoàn toàn biết trước các stage này.

Nhưng bên trong từng stage, đặc biệt Developer/Reviewer, model có thể cần tự khám phá:

Developer
   │
   ├── đọc requirement
   ├── tìm relevant files
   ├── đọc dependency
   ├── sửa code
   ├── chạy test
   ├── thấy lỗi
   ├── tìm nguyên nhân
   └── sửa tiếp

Không thể viết trước chính xác:

read A
→ read B
→ edit C
→ test D
→ edit E

=> phần này có Agent autonomy.

3. Cập nhật kiến trúc

Kiến trúc trước đây hơi đơn giản:

AI-DLC Orchestrator
 ├── Agent Team
 └── Dynamic Workflow

Bây giờ cần tách rõ:

AI-DLC Orchestrator
│
├── Workflow Engine
│     │
│     ├── Plan
│     ├── Code
│     ├── Review
│     ├── Test
│     ├── Deploy
│     └── Verify
│
└── Agents
      │
      ├── Planner Agent
      ├── Developer Agent
      └── Reviewer Agent

Điểm thay đổi quan trọng:

Workflow quyết định cấu trúc lớn của AI-DLC.

Agent được dùng ở những stage mà không thể biết trước trajectory.

4. Các Workflow sub-pattern áp vào AI-DLC thế nào?

Đây mới là phần rất quan trọng của bài.

Chaining

AI-DLC chắc chắn có:

Requirement
    ↓
Plan
    ↓
Code
    ↓
Review
    ↓
Test
    ↓
Deploy
    ↓
Verify

=> Chaining là backbone.

Routing

Có thể xuất hiện khi xử lý kết quả:

Test Result
     │
     ▼
  Router
     │
 ┌───┼──────────┐
 │   │          │
PASS FAIL    ENV ERROR
 │   │          │
 ▼   ▼          ▼
Deploy Fix      Infra Agent

Ví dụ:

Test PASS
 → Deploy

Test FAIL
 → Developer Agent sửa

Deploy FAIL
 → Deployment/Infrastructure handling

=> Routing cần thiết.

Parallelization

Review có thể chạy song song:

                 Code
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
  Code Review  Security     Test Analysis
       │           │           │
       └───────────┼───────────┘
                   ▼
               Aggregate

=> Nếu các kiểm tra độc lập, dùng Parallelization.

Evaluator-optimizer

Đây là pattern rất phù hợp với AI-DLC:

Developer Agent
      │
      ▼
  Code Draft
      │
      ▼
Reviewer Agent
      │
      ├── PASS ──────────→ Test
      │
      └── FAIL
           │
           ▼
     Feedback
           │
           ▼
    Developer Agent
           │
           └──────→ Review

Và tương tự:

Code
 ↓
Test
 ↓
FAIL
 ↓
Analyze
 ↓
Fix
 ↓
Test again

Nhưng ở đây cần phân biệt:

Model không tự giả định rằng code đã đúng.

Test runner phải thực sự chạy test và trả kết quả.

5. Vậy Dynamic Workflow trước đây có bị thay đổi không?

Có, nhưng không bị loại bỏ.

Trước:

Dynamic Workflow
└── Plan → Code → Review → Test → Fix

Bây giờ chính xác hơn:

Workflow
│
├── Chaining
│     └── Plan → Code → Review → Test
│
├── Routing
│     └── PASS / FAIL / DEPLOY ERROR
│
├── Parallelization
│     └── Review các khía cạnh độc lập
│
└── Evaluator-Optimizer
      └── Code → Review → Fix → Review

Và bên trong các node:

Workflow
   │
   ├── Planner Agent
   ├── Developer Agent
   ├── Reviewer Agent
   └── ...

Đây chính là LEGO mới của bài này.

6. Augmented LLM dùng ở đâu?

Không phải mọi thứ đều cần Agent.

Ví dụ:

Requirement
     │
     ▼
Planner Agent

Nếu chỉ cần:

"Tóm tắt requirement thành structured format"

thì có thể chỉ cần:

Requirement
     ↓
Augmented LLM
     ↓
Structured Plan

Không cần Agent tự gọi 20 tools.

Tương tự:

Test result
    ↓
Augmented LLM
    ↓
Explain failure

Nếu task đơn giản, đừng nâng lên Agent.

7. Agent dùng ở đâu?

Task kiểu:

"Implement feature A trong một codebase chưa biết trước."

thì:

Developer Agent
    │
    ├── inspect repository
    ├── search files
    ├── understand architecture
    ├── modify code
    ├── run tests
    ├── inspect failures
    ├── modify again
    └── stop when done

Đây là Agent pattern vì:

• bước tiếp theo phụ thuộc kết quả bước trước;

• không thể liệt kê trajectory hoàn chỉnh từ đầu;

• model cần tự quyết định tool nào cần gọi;

• task có thể kéo dài nhiều lượt.

8. Skills cũng được cập nhật theo bài này

Bài trước chúng ta nói:

Agent ≠ Skill

Bài này càng củng cố điều đó.

Ví dụ:

Developer Agent
   │
   ├── Skill: coding-standard
   ├── Skill: implementation-procedure
   │
   └── Tools
        ├── File
        ├── Git
        └── Test

Skill không phải control flow.

Nó là:

đóng gói procedure/how-to

Còn:

Plan → Code → Review → Test

là Workflow.

9. Fine-tuning: hiện tại chưa cần đưa vào architecture

Với project AI-DLC của chúng ta:

Prompt
   ↓
Tools / Retrieval
   ↓
Workflow / Agent
   ↓
Evaluator
   ↓
Fine-tuning

Fine-tuning chưa phải một component của kiến trúc hiện tại.

Hiện tại chỉ cần:

Claude
 + Prompt
 + Tools
 + Context
 + Workflow/Agent
 + Verification

Nếu production sau này chứng minh rằng prompting + tools + workflow vẫn không đủ thì mới xem xét.

10. Kiến trúc tổng thể sau bài này

Đây là version nên giữ làm baseline mới:

Claude Code
    │
    ▼
┌─────────────────────────────────────────────┐
│              AI-DLC Orchestrator             │
│                                             │
│  ┌───────────────────────────────────────┐  │
│  │          Workflow Engine              │  │
│  │                                       │  │
│  │  Chaining                             │  │
│  │  Routing                              │  │
│  │  Parallelization                      │  │
│  │  Evaluator-Optimizer                  │  │
│  └──────────────────┬────────────────────┘  │
│                     │                       │
│        ┌────────────┼────────────┐          │
│        ▼            ▼            ▼          │
│     Planner     Developer     Reviewer      │
│      Agent        Agent        Agent        │
│        │            │            │          │
│        └────────────┼────────────┘          │
│                     │                       │
│          ┌──────────┴──────────┐            │
│          │                     │            │
│       Skills                 Tools          │
│          │                     │            │
│          └──────────┬──────────┘            │
│                     │                       │
│                  Hooks/MCP                  │
└─────────────────────┬───────────────────────┘
                      │
                      ▼
               Claude Agent SDK
                      │
                      ▼
                Anthropic API
                      │
                      ▼
                   Claude

Chốt LEGO của bài này

Kết luận kiến trúc: AI-DLC của chúng ta không nên được thiết kế là “một Agent làm tất cả”. Nó nên là Workflow làm xương sống + các Agent ở những stage cần autonomy + deterministic systems/tools ở những nơi cần kết quả chắc chắn.

↓↓↓

Các hệ thống Multi-agent và sự điều phối (Orchestration)

1. Big picture — Bài này tác động vào đâu?

Cập nhật kiến trúc: Orchestrator và Subagents

Bài này làm rõ cách phân chia trách nhiệm và quản lý lỗi trong AI-DLC. Không cần thay đổi 3 pattern đã chọn ở bài trước.

AI-DLC Orchestrator
        │
        ├── Workflow: Plan → Code → Review → Test
        │
        ├── Orchestrator
        │      ├── Phân rã công việc
        │      ├── Ủy quyền
        │      └── Tổng hợp kết quả
        │
        └── Subagents
               ├── Developer
               ├── Reviewer
               └── Tester

2. Zoom vào Orchestrator và Subagents

Lưu ý: Orchestrator không trực tiếp làm tác vụ con; nó chỉ điều phối và tổng hợp.

3. Áp dụng vào AI-DLC

Ví dụ khi Developer Agent cần kiểm tra một codebase lớn:

       Orchestrator
             │
       Phân chia task
             │
      ┌──────┼──────┐
      ▼      ▼      ▼
   Agent A Agent B Agent C
      │      │      │
    Files  Files  Files
      │      │      │
      └──────┼──────┘
             ▼
       Validate kết quả
             │
        Tổng hợp
             ▼
       Kết quả chung

Chỉ nên chạy song song khi các task độc lập. Nếu task nhỏ, không cần tạo thêm subagent.

4. Các thay đổi cần bổ sung vào kiến trúc

Các thành phần mới cần thiết

• Task Decomposition: chia công việc thành các task nhỏ.

• Result Validation: kiểm tra kết quả subagent và độ bao phủ.

• Synthesis: tổng hợp kết quả, xử lý xung đột.

• Checkpoint & Resume: lưu trạng thái để tiếp tục khi orchestrator gặp lỗi.

• Shared Trace ID: theo dõi toàn bộ lượt chạy giữa các agent.

• Human Approval Gate: yêu cầu con người duyệt trước hành động rủi ro cao.

5. Xử lý lỗi

Các task có thể retry cần được thiết kế idempotent để tránh tác dụng phụ khi chạy lại.

6. Kiến trúc sau bài học

AI-DLC Orchestrator
│
├── Workflow Engine
│     └── Plan → Code → Review → Test → Deploy
│
├── Orchestrator
│     ├── Task Decomposition
│     ├── Delegation
│     ├── Result Validation
│     ├── Synthesis
│     └── Checkpoint / Resume
│
├── Subagents
│     ├── Developer
│     ├── Reviewer
│     └── Tester
│
├── Human Approval Gate
│
└── Observability
      └── Shared Trace ID

Kết luận — LEGO mới của bài này

Orchestrator chịu trách nhiệm điều phối và tổng hợp; Subagents thực hiện công việc độc lập. Bổ sung cơ chế validate, retry, checkpoint và human approval để hệ thống có thể phục hồi và tránh kết quả thiếu sót.