BUILDING EFFECTIVE AGENTS: BA NGUYÊN TẮC VÀNG

Tản mạn

Có những hôm ngồi code, tự nhiên nghĩ "ừm, hay là build một AI agent để tự động hóa cái này đi"...

Rồi anh em dev chúng mình bắt đầu hype:

• "Agent này sẽ tự động review code!"
• "Agent kia sẽ tự động viết test!"
• "Agent nọ sẽ tự động deploy production!"

Nghe thì ngon lành, nhưng thực tế:

• Chi phí API tokens tăng vọt (haizz)
• Agent chạy chậm như rùa bò
• Sai một phát là toang cả hệ thống
• Context window lúc nào cũng tràn ngập

Vậy thì làm sao để build agents hiệu quả?

Gần đây mình có đọc được bài talk của Barry từ Anthropic tại AI Engineer Summit, share về cách họ build effective agents sau nhiều năm nghiên cứu. Ba nguyên tắc cốt lõi mà anh ấy chia sẻ thực sự đã thay đổi cách mình nghĩ về agents.

Bài này mình sẽ đi sâu vào 3 ý chính:

1. Đừng build agents cho mọi thứ (seriously, đừng)
2. Giữ mọi thứ đơn giản nhất có thể
3. Suy nghĩ như agent của bạn

1. Từ Simple Features Đến Agentic Systems

Trước khi đi vào 3 nguyên tắc, hãy cùng nhìn lại hành trình chúng ta đã đi qua.

Giai đoạn 1: Simple Features (2021-2022)

• Summarization (tóm tắt văn bản)
• Classification (phân loại)
• Extraction (trích xuất thông tin)

Những thứ này giờ đã trở thành table stakes – ai cũng có rồi.

Giai đoạn 2: Workflows (2023-2024) Khi một model call không đủ, chúng ta bắt đầu orchestrate nhiều model calls theo flow định sẵn:

# Workflow ví dụ
def process_document(doc):
    # Step 1: Extract key info
    key_info = llm.extract(doc)

    # Step 2: Classify category
    category = llm.classify(key_info)

    # Step 3: Generate summary
    if category == "technical":
        summary = llm.summarize_technical(doc)
    else:
        summary = llm.summarize_general(doc)

    return summary

Đây chính là workflow – luồng xử lý định sẵn, có thể optimize từng bước.

Giai đoạn 3: Agents (2025+) Khác với workflow, agents có thể tự quyết định trajectory của mình:

• Tự chọn tool nào cần dùng
• Tự điều chỉnh hành vi dựa trên kết quả
• Hoạt động gần như độc lập

Nhưng đổi lại:

• Cost tăng (nhiều token hơn)
• Latency tăng (chậm hơn)
• Error consequences nghiêm trọng hơn

Và đây chính là lý do cho nguyên tắc đầu tiên...

2. Nguyên Tắc #1: Đừng Build Agents Cho Mọi Thứ

Nghe có vẻ ngược đời nhỉ? Nhưng đây là sự thật:

Agents không phải là drop-in upgrade cho mọi use case.

Hãy tưởng tượng agents như việc thuê một consultant cao cấp. Bạn sẽ không thuê consultant để làm những việc đơn giản như photocopy tài liệu hay sắp xếp file Excel. Bạn chỉ thuê khi có vấn đề phức tạp, mơ hồ, cần judgment và khả năng tự điều chỉnh.

Checklist 4 Điểm: Khi Nào Nên Build Agent?

1. Task Complexity – Nhiệm vụ có đủ phức tạp không?

Agents thích hợp với ambiguous problem spaces – những vấn đề không thể map toàn bộ decision tree ra trước.

Ví dụ KHÔNG NÊN dùng agent:
"Khi user nhập form → validate → lưu database → gửi email"
→ Decision tree rõ ràng → Dùng workflow đơn giản

Ví dụ NÊN dùng agent:
"Từ design doc → tạo PR với full implementation"
→ Rất nhiều quyết định phải đưa ra dọc đường → Agent phù hợp

2. Task Value – Giá trị có đủ lớn không?

Agents tốn token rất nhiều. Bạn cần justify chi phí đó.

Budget 10 cents/task → chỉ có 30-50k tokens
→ Dùng workflow cho common scenarios
→ Capture được majority value

Budget "I don't care how many tokens"
→ OK, build agent đi (hehe)

3. Critical Capabilities – Có bottleneck nghiêm trọng không?

Trước khi build agent, hãy derisk các capability quan trọng:

Ví dụ coding agent cần:

• Viết code tốt
• Debug hiệu quả
• Tự recover từ errors

Nếu thiếu một trong những khả năng này → bottleneck sẽ nhân lên cost và latency.

4. Cost of Error – Lỗi có nghiêm trọng không? Có dễ phát hiện không?

High-stake + Hard to discover errors = NGUY HIỂM

Giải pháp:
- Giảm scope (read-only access)
- Thêm human-in-the-loop
- Nhưng điều này cũng hạn chế khả năng scale

Case Study: Tại Sao Coding Agent Là Use Case Tuyệt Vời?

Hãy áp dụng checklist vào coding agent:

Complexity: Từ design doc → PR là cực kỳ phức tạp và mơ hồ

Value: Good code có giá trị rất lớn cho business

Capabilities: Claude đã proven là giỏi nhiều phần của coding workflow

Error Discovery: Unit tests + CI giúp phát hiện lỗi dễ dàng

Đây chính là lý do mình thấy nhiều coding agents thành công: Claude Code, Cursor, Windsurf, Cline...

3. Nguyên Tắc #2: Giữ Mọi Thứ Đơn Giản (Keep It Simple)

Khi đã quyết định build agent, nguyên tắc vàng là:

Keep it as simple as possible, for as long as possible.

Agent = Model + Tools + Prompt (Trong Một Loop)

Theo Anthropic, một agent thực chất chỉ gồm 3 thành phần cốt lõi:

┌─────────────────────────────────────┐
│         ENVIRONMENT                 │
│  (System agent hoạt động trong đó)  │
└─────────────────────────────────────┘
            ↕
┌─────────────────────────────────────┐
│           TOOLS                     │
│  (Interface để take action &        │
│   get feedback)                     │
└─────────────────────────────────────┘
            ↕
┌─────────────────────────────────────┐
│       SYSTEM PROMPT                 │
│  (Goals, constraints, behavior)     │
└─────────────────────────────────────┘
            ↕
┌─────────────────────────────────────┐
│       MODEL (in loop)               │
└─────────────────────────────────────┘

Nói cách khác:

Environment = Thế giới mà agent sống Tools = Tay chân của agent System Prompt = Bộ não/instinct của agent Model Loop = Vòng lặp suy nghĩ → hành động

Hãy tưởng tượng agent như một nhân viên mới vào công ty:

• Environment = Văn phòng và hệ thống công ty
• Tools = Máy tính, quyền truy cập, các phần mềm họ được dùng
• System Prompt = Job description + company handbook
• Model = Khả năng suy nghĩ và ra quyết định của họ

Ba Use Cases – Cùng Backbone, Khác Scope

Barry đã share 3 use cases họ build:

Use Case	Environment	Tools	Prompt Focus
Coding Agent	Codebase + Git	Read, Write, Bash, LSP	Code quality, debug, recovery
Computer Use	Desktop OS	Mouse, Keyboard, Screenshot	Navigate UI, understand context
Search Agent	Internet	Web search, scraping, API	Query optimization, result ranking

Mặc dù rất khác nhau về product surface, nhưng chúng dùng gần như cùng một code backbone.

Chỉ khác ở 2 design decisions:

1. Tools nào cung cấp cho agent?
2. Prompt nào để instruct agent?

Tối Ưu Sau, Simple First

Khi mới bắt đầu, đừng vội optimize. Hãy build 3 thành phần cơ bản trước:

# Simple agent skeleton
class SimpleAgent:
    def __init__(self, tools, system_prompt):
        self.tools = tools
        self.system_prompt = system_prompt

    def run(self, task):
        messages = [{"role": "system", "content": self.system_prompt}]
        messages.append({"role": "user", "content": task})

        while not done:
            # Model thinks
            response = llm.generate(messages)

            # Model acts (if tool call)
            if response.tool_calls:
                for tool_call in response.tool_calls:
                    result = self.execute_tool(tool_call)
                    messages.append(tool_result_message(result))
            else:
                # Done!
                return response.content

Sau khi behavior đã ổn, bạn mới optimize:

• Caching trajectory để giảm cost (coding agents)
• Parallel tool calls để giảm latency (search agents)
• Progress streaming để tăng user trust

Complexity kills iteration speed. Giữ đơn giản giúp bạn iterate nhanh hơn rất nhiều.

4. Nguyên Tắc #3: Suy Nghĩ Như Agent Của Bạn

Đây là nguyên tắc mà mình thấy ít người làm nhất, nhưng lại quan trọng nhất.

Agent Chỉ Biết Những Gì Trong Context Window

Hãy nhớ một sự thật:

Dù agent có vẻ thông minh và sophisticated đến đâu, tại mỗi bước, nó chỉ đang run inference trên 10-20k tokens trong context window.

Mọi thứ agent "biết" về thế giới = những gì nằm trong context đó.

Tưởng tượng bạn là agent:

• Bạn không thấy màn hình liên tục (chỉ có screenshots tĩnh)
• Giữa mỗi hành động, bạn "nhắm mắt" 3-5 giây
• Khi mở mắt ra, không biết điều gì đã xảy ra
• Instructions bạn nhận được... khá tệ (poorly written)

Exercise: Làm Computer Use Agent Trong 30 Giây

Hãy thử nghiệm này:

Bạn nhận được:

You are a computer use agent.
You have tools: mouse_move, click, type.
Task: Update the spreadsheet.

Rồi bạn nhìn thấy một screenshot mờ mờ.

Bây giờ hãy:

• Click vào đâu đó (không biết độ phân giải màn hình)
• Nhắm mắt 3-5 giây (tool execution time)
• Mở mắt → nhìn screenshot mới
• Không biết click của bạn có work không
• Lặp lại...

Mình đảm bảo sau khi làm exercise này, bạn sẽ hiểu agent struggle với những gì (hehe).

Những Gì Agent Thật Sự Cần

Sau khi "sống" như agent, bạn sẽ nhận ra:

1. Screen resolution là critical

# Bad prompt
"Click on the button"

# Good prompt
"Screen resolution: 1920x1080
Click coordinates must be within bounds.
Button 'Submit' is located at approximately (960, 540)"

2. Recommended actions & limitations giúp tránh exploration vô ích

# Bad
"Do the task"

# Good
"You should:
- First, check if file exists using ls
- Use grep to search, not cat entire file
- Avoid recursive operations in large directories

Limitations:
- Do NOT run sudo commands
- Do NOT modify files outside /workspace
- Maximum file size to read: 10MB"

3. Clear success criteria

# Bad
"Update the records"

# Good
"Success = All 50 records in database have status='completed'
Verify by running: SELECT COUNT(*) FROM records WHERE status='completed'
Expected result: 50"

Hỏi Claude Để Hiểu Claude

May mắn là chúng ta build systems "nói ngôn ngữ của con người". Vậy nên bạn có thể:

Hỏi về prompt:

"Is this instruction ambiguous?
Can you follow this clearly?
What additional context would help?"

Hỏi về tool:

"Here's the tool description: [...]
Do you understand how to use it?
What parameters would make it easier?"

Hỏi về trajectory:

"Here's the agent's full trajectory: [...]
Why do you think it made this decision at step 5?
What could help it make better decisions?"

Đây không thay thế việc tự hiểu context, nhưng giúp bạn có perspective gần hơn với cách agent nhìn thế giới.

5. Bài Học Kinh Nghiệm: Khi Build Agent Cho Team

Mình có dịp build một agent nội bộ cho team để tự động hóa code review. Dưới đây là những gì mình học được:

Lesson 1: Bắt đầu với workflow, chuyển sang agent khi thật sự cần

Ban đầu mình nghĩ "làm luôn agent cho oách". Nhưng thực tế:

• Review 80% PRs đơn giản → workflow đủ rồi
• Chỉ 20% PRs phức tạp → mới cần agent reasoning

Kết quả: Hybrid approach tiết kiệm 70% cost.

Lesson 2: Context bloat là kẻ thù số 1

Agent ban đầu load cả:

• Coding standards (5k tokens)
• Previous reviews (10k tokens)
• Full file history (15k tokens)

→ 30k tokens chưa làm gì đã hết quota (haizz)

Giải pháp: Chỉ load on-demand, dùng retrieval khi cần.

Lesson 3: Error discovery phải dễ

Lúc đầu agent tự commit code → đôi khi sai mà không ai biết.

Cải tiến:

• Agent chỉ tạo suggestions
• Human approve trước khi commit
• Unit tests phải pass 100%

Trade-off: Mất autonomy nhưng gain trust.

Lesson 4: Prompt engineering ≠ one-time job

Cứ tưởng viết prompt một lần là xong. Thực tế:

• Hàng tuần phải điều chỉnh
• Dựa trên failure cases
• Dựa trên user feedback

Agents là living systems, không phải set-and-forget.

6. Tương Lai: Ba Open Questions Đáng Suy Nghĩ

Barry có share 3 vấn đề đang chiếm mind space của anh ấy. Mình thấy rất thú vị:

Question 1: Budget-Aware Agents

Vấn đề: Với workflows, chúng ta biết chính xác cost & latency. Với agents, mọi thứ unpredictable.

Open question: Làm sao định nghĩa và enforce budgets?

• Theo tokens?
• Theo time?
• Theo money?
• Theo "thinking steps"?

Giải quyết được vấn đề này sẽ unlock nhiều use cases mới.

Question 2: Self-Evolving Tools

Hiện tại chúng ta đã dùng LLM để improve tool descriptions.

Vision: Agents có thể design và improve tools của chính chúng:

• Tự tạo wrapper functions
• Tự optimize tool parameters
• Tự compose tools mới từ tools cũ

→ Meta-tool: agents thiết kế công cụ cho chính mình.

Question 3: Multi-Agent Collaboration

Barry tin chắc rằng cuối năm 2025 sẽ thấy nhiều multi-agent systems trong production.

Tại sao?

• Parallelization tốt hơn
• Separation of concerns rõ ràng
• Protect main agent's context window

Nhưng vấn đề lớn: Hiện tại agents giao tiếp theo pattern synchronous user-assistant turns.

Làm sao expand sang:

• Asynchronous communication?
• Agent-to-agent protocols?
• Roles phức tạp hơn (coordinator, worker, validator...)?

Đây là frontier mà community đang explore.

7. Kết Luận

Nếu chỉ nhớ 3 điều từ bài này:

1. Đừng build agents cho mọi thứ

• Dùng checklist 4 điểm
• Workflows vẫn cực kỳ valuable
• Agents cho complex & high-value tasks

2. Giữ đơn giản càng lâu càng tốt

• 3 thành phần: Environment, Tools, Prompt
• Optimize sau khi behavior đã ổn
• Complexity kills iteration speed

3. Suy nghĩ như agent

• Hiểu giới hạn của context window
• Put yourself in agent's shoes
• Ask Claude to understand Claude

Quan trọng nhất: Agents không phải silver bullet. Nhưng khi dùng đúng chỗ, đúng cách, chúng có thể tạo ra impact cực lớn.

Năm 2025 là năm của agentic systems. Hy vọng 3 nguyên tắc từ Anthropic sẽ giúp anh em build agents hiệu quả hơn, tốn ít token hơn, và tạo ra nhiều giá trị hơn.

Happy building! (hehe)

---

Nguồn tham khảo:

• Building Effective Agents - Anthropic Blog
• AI Agent Architecture Guide 2025 - Lindy
• Agentic Workflows vs AI Agents - Weaviate
• How to Build a Coding Agent - Together AI
• AI Agent Orchestration Patterns - Microsoft Azure

---

telegram: dinhlongit