Series 0 - Bài 4: Mental Model để thiết kế Agent System
Cách bạn tư duy về agent quyết định cách bạn thiết kế nó. Bài này xây dựng mental model thực tế — agent như một junior developer với guardrails — thay vì xem nó như AI magic.
Cách bạn tư duy về một hệ thống quyết định cách bạn thiết kế nó, debug nó, và biết khi nào nó fail.
Vấn đề với hầu hết các mô tả về AI Agent là chúng dùng một trong hai extreme: hoặc "AI magic có thể làm mọi thứ", hoặc "chỉ là if/else phức tạp". Cả hai đều sai và đều dẫn đến thiết kế tồi.
Mental model tôi thấy hữu ích nhất: Agent như một junior developer được giao task và có quyền truy cập vào một số tools nhất định.
Junior Developer Analogy
Khi bạn giao task cho một junior developer:
Bạn (Manager):
"Refactor hàm processPayment trong payment.service.ts
để handle edge case khi amount = 0"
Junior Developer:
1. Đọc file payment.service.ts ← Tool: read_file
2. Hiểu code hiện tại
3. Đọc test file để hiểu expected ← Tool: read_file
4. Viết code mới ← Tool: write_file
5. Chạy tests để verify ← Tool: run_command
6. Báo cáo kết quả
Agent làm đúng như vậy. Nó nhận task, tự tìm context cần thiết, sử dụng tools có sẵn, và báo cáo khi xong.
Analogy này hữu ích vì nó đặt ra đúng expectations:
Những gì junior developer cần — agent cũng cần
1. Task description rõ ràng
Junior developer không làm tốt với "fix bugs" hay "improve performance". Họ cần:
- Scope rõ ràng: làm gì, không làm gì
- Success criteria: xong nghĩa là thế nào
- Constraints: không được đụng vào file gì, không được dùng library gì
Agent cần điều tương tự trong system prompt và task description.
Bad: "Improve the codebase"
Good: "Refactor hàm processPayment trong src/payment.service.ts
để handle trường hợp amount <= 0 bằng cách throw
InvalidAmountError. Không thay đổi function signature.
Tests phải pass sau khi refactor."
2. Tools phù hợp với task
Không giao junior developer làm database migration mà không cho access vào database. Không giao agent làm task cần đọc file mà không có read_file tool.
┌─────────────────────────────────────────────┐
│ Tool Availability │
│ │
│ Task: Refactor code │
│ │
│ ✅ read_file — cần để đọc source │
│ ✅ write_file — cần để ghi kết quả │
│ ✅ run_command — cần để chạy tests │
│ ✅ search_files — cần để tìm references │
│ │
│ ❌ call_external_api — không liên quan │
│ ❌ send_email — không liên quan │
└─────────────────────────────────────────────┘
Tools thừa không giúp ích — chúng tạo noise và tăng risk. Agent có thể quyết định dùng tool không cần thiết.
3. Guardrails và escalation path
Junior developer giỏi biết khi nào phải hỏi lại — khi task mơ hồ, khi gặp tình huống không lường trước, khi quyết định có risk cao.
Agent cần được thiết kế để biết điều tương tự:
┌─────────────────────────────────────────────────┐
│ Escalation Design │
│ │
│ Agent tự quyết định: │
│ → Read operations │
│ → Low-risk writes (theo spec) │
│ → Running tests │
│ │
│ Agent phải confirm trước: │
│ → Delete operations │
│ → Modify files ngoài scope │
│ → Run commands với side effects lớn │
│ │
│ Agent phải dừng và báo cáo: │
│ → Phát hiện conflict với requirements │
│ → Tool fail liên tục │
│ → Task scope lớn hơn estimate ban đầu │
└─────────────────────────────────────────────────┘
4. Context đủ để làm việc
Junior developer không làm việc tốt khi bị cô lập hoàn toàn — không có docs, không có codebase context, không biết convention của project.
Agent cần được cung cấp context tương đương:
- Project structure overview
- Coding conventions
- Relevant documentation
- Background về task (tại sao cần làm, không chỉ làm gì)
Những gì junior developer không làm tốt — agent cũng vậy
1. Ambiguous requirements
Junior developer với yêu cầu mơ hồ sẽ make assumptions — đôi khi đúng, đôi khi sai. Agent làm y chang, nhưng nhanh hơn và ở scale lớn hơn.
Implication: Invest vào task specification, không chỉ vào model quality.
2. Tasks quá lớn không có checkpoint
Giao junior developer một task 2 tuần mà không có intermediate check-in là recipe cho disaster. Họ có thể đi sai hướng từ ngày 3 và bạn chỉ biết vào ngày 14.
Agent với task lớn không có checkpoint cũng vậy — nó có thể thực thi 30 tool calls theo hướng sai trước khi bạn can thiệp.
Implication: Break task thành smaller chunks với explicit verification points.
3. Tasks đòi hỏi domain knowledge sâu không có trong context
Junior developer không thể refactor payment system mà không hiểu payment domain. Agent không thể làm task domain-specific nếu không có domain knowledge trong context.
Implication: Context injection là first-class concern, không phải afterthought.
Mental model trong thực tế: Thiết kế agent system
Khi bạn thiết kế agent system với mental model này, một số câu hỏi trở nên rõ ràng hơn:
"Tôi sẽ giao task này cho junior developer
được trang bị những tools này không?"
Nếu câu trả lời là không, agent cũng sẽ không làm được.
"Junior developer cần thêm context gì để làm task này?"
Đó là context bạn cần inject vào agent.
"Quyết định nào trong task này quá important để
junior developer tự quyết không cần hỏi?"
Đó là điểm cần human confirmation trong agent flow.
"Task này có scope rõ ràng không,
hay junior developer có thể đi lạc?"
Đó là signal bạn cần refine task specification.
Khi nào mental model này breakdown
Analogy có giới hạn. Agent khác junior developer ở một điểm quan trọng:
Speed và scale. Agent có thể thực thi 50 tool calls trong 3 phút. Junior developer mất 3 ngày. Điều này có nghĩa là agent có thể gây ra damage ở scale và speed mà human không thể.
Junior Developer:
Sai 1 ngày = 1 ngày sai
→ Dễ phát hiện, dễ fix
Agent:
Sai 3 phút = có thể modify 50 files sai
→ Khó phát hiện, khó rollback
Đây là lý do tại sao guardrails, permission model, và audit log trong agent system quan trọng hơn nhiều so với managing một junior developer thực sự.
Kết luận
- Mental model tốt nhất: agent là junior developer với tools và guardrails xác định.
- Agent cần rõ ràng về task scope, success criteria, và constraints.
- Tools cần phù hợp với task — không thừa, không thiếu.
- Escalation path phải được thiết kế trước: agent tự quyết điều gì, hỏi lại khi nào, dừng khi nào.
- Agent khác junior developer về speed và scale — điều này làm guardrails quan trọng hơn, không phải ít quan trọng hơn.
- Task specification quality ảnh hưởng đến agent performance nhiều hơn model quality.