Agent production cần bếp trưởng, không cần thêm dao

Agent production cần bếp trưởng, không cần thêm dao

Agent không hỏng vì thiếu feature. Nó hỏng vì memory, tool, quyền chạy lệnh và bước kiểm chứng bị trộn vào một nồi.

9 giờ tối, team Mây vẫn còn ngồi ở văn phòng vì con agent hỗ trợ dev vừa “tự tin” sửa nhầm file migration production. Không ai la lớn. Chỉ có một tiếng thở dài rất Việt Nam: “Ủa, sao nó được quyền chạy lệnh đó?”

Câu trả lời hơi đau: vì team đã bật quá nhiều thứ cùng lúc.

Agent có memory. Có tool calling. Có custom skill. Có plugin. Có MCP server. Có subagent. Có cả streaming API để demo nhìn mượt. Từng món riêng lẻ đều hợp lý. Nhưng khi đổ chung vào một nồi mà không chia lớp, hệ thống sẽ giống căn bếp đông người: ai cũng cầm dao, ai cũng mở bếp, không ai chịu trách nhiệm món cuối.

Luận điểm của mình hôm nay gọn thôi: agent production không đáng tin hơn vì có thêm feature; nó đáng tin hơn khi mỗi lớp biết rõ mình được thấy gì, được làm gì, và bị chặn ở đâu.

Sơ đồ minh họa cho bài Agent production cần bếp trưởng, không cần thêm dao

Sơ đồ tóm tắt ý chính của bài viết.

Cảnh đang diễn ra: coding assistant đã thành agent stack

Claude Code là ví dụ dễ thấy. Nó không còn chỉ là terminal assistant đọc file rồi gợi ý code. Bên dưới là một hệ nhiều lớp: CLAUDE.md để giữ quy ước repo, skills để đóng gói năng lực, subagents để tách ngữ cảnh, slash commands để gọi nhanh workflow, hooks để gắn hành động tự động, MCP để nối công cụ ngoài, plugins để bundle nhiều thứ thành một gói cài.

QwenPaw cũng đi theo hướng tương tự: workspace có cấu hình agent, model provider, console access, memory, streaming API, custom skills, knowledge files và guarded tool execution. Còn phía enterprise search, agentic RAG của Google thêm quy trình nhiều agent để lập kế hoạch, viết lại truy vấn, tìm qua nhiều nguồn, rồi kiểm tra đủ context trước khi trả lời.

Đây là tín hiệu chung: agent đang chuyển từ “chat với model” sang “vận hành một hệ điều phối”.

Orchestration, tức lớp điều phối nhiều bước và nhiều công cụ, giờ mới là phần đáng nhìn. Guardrail, tức lan can an toàn để giới hạn hành vi agent, không còn là checkbox trang trí. Với builder, câu hỏi không phải “tool nào mới nhất?”, mà là: mỗi feature nằm ở lớp nào trong hệ thống, và lỗi của nó sẽ lan tới đâu?

Va chạm của team Mây: feature nào cũng đúng, tổng thể lại sai

Team Mây có 6 người, đang làm agent nội bộ để hỗ trợ review pull request, tra tài liệu kỹ thuật và tạo checklist release. Ban đầu mọi thứ ngon: agent đọc repo, chạy test, sửa code nhỏ, tóm tắt PR.

Rồi team thêm memory để agent nhớ convention. Thêm skill release_check. Thêm MCP server nối Jira và Git. Thêm hook chạy formatter sau khi edit. Thêm subagent chuyên đọc log. Thêm slash command /hotfix cho ca gấp.

Từng quyết định nghe đều hợp lý. Nhưng sự cố bắt đầu xuất hiện:

Nói thẳng ra thì, lỗi không nằm ở “agent ngu”. Lỗi nằm ở việc team để context, capability và permission dính vào nhau.

Context là thứ agent được thấy. Capability là thứ agent có thể làm. Permission là thứ agent được phép làm trong môi trường thật. Ba thứ này mà trộn lẫn, bạn rất khó debug. Nó giống nêm muối, đường, nước mắm cùng một lúc rồi hỏi vì sao món bị mặn: bạn không còn biết tay nào gây ra.

Mổ xẻ lớp: đừng hỏi agent có gì, hãy hỏi lớp đó kiểm soát gì

Một cách đọc các feature kiểu Claude Code hay QwenPaw là xếp chúng vào 4 lớp. Mình gọi tạm là 4C: Context, Capability, Control, Continuity.

| Lớp | Nó trả lời câu hỏi gì? | Ví dụ feature | Rủi ro nếu làm ẩu |
|---|---|---|---|
| Context | Agent được thấy gì? | CLAUDE.md, knowledge files, context window | Nhớ sai, thiếu chứng cứ, lẫn quy ước cũ |
| Capability | Agent biết làm kiểu việc nào? | skills, slash commands, subagents | Workflow phình ra, khó biết ai làm gì |
| Control | Agent được phép tác động tới đâu? | hooks, permission modes, sandboxing, guarded tool execution | Chạy lệnh nguy hiểm, sửa file ngoài phạm vi |
| Continuity | Agent giữ phiên dài ra sao? | memory, checkpoints, compaction, streaming state | Lỗi âm thầm tích tụ qua nhiều lượt |

Context window là vùng ngữ cảnh model còn giữ được trong một lượt xử lý. Với builder, tradeoff nằm ở chỗ: nhét nhiều quá thì agent có vẻ “biết nhiều”, nhưng phần quan trọng có thể bị loãng.

Subagents là các agent con có ngữ cảnh riêng. Điểm hay là việc dài dòng, như đọc log hoặc rà test, không làm bẩn cuộc hội thoại chính. Điểm dở là nếu bạn không định nghĩa output contract rõ, subagent sẽ trả về một đoạn văn nghe ổn nhưng không đủ để hành động.

Hooks là điểm móc tự động chạy hành động tại một thời điểm nhất định, ví dụ sau khi agent sửa file thì chạy formatter. Hooks rất mạnh, nhưng cũng là nơi production hay bị “cháy nhỏ liu riu”: không nổ ngay, chỉ làm state lệch dần.

MCP là giao thức để agent kết nối công cụ và dữ liệu ngoài. Trong production, MCP nên được xem như cửa bếp ra kho nguyên liệu: không phải ai cũng được vào, và vào rồi không có nghĩa được lấy mọi thứ.

Điều đáng giữ: sufficient context check trước khi cho agent nói

Phần mình thấy đáng học từ hướng agentic RAG của Google không phải là “nhiều agent hơn”. Nhiều agent mà thiếu kiểm chứng thì chỉ là nhiều người cùng đoán.

Điểm đáng giữ là sufficient context check: bước kiểm tra xem ngữ cảnh đã đủ để trả lời chưa. Nếu chưa đủ, hệ thống quay lại lập kế hoạch, viết lại truy vấn hoặc tìm thêm nguồn.

Hình dung thế này: bạn hỏi agent “server của Project X đang dùng cấu hình gì để tính chi phí nâng cấp?” Một lần search có thể chỉ tìm được tài liệu nói Project X dùng server ID srv-17. Agent chưa đủ quyền kết luận cấu hình. Nó phải lấy ID đó đi tra hệ thống inventory, rồi có thể tra tiếp bảng giá hoặc log sử dụng.

Với team builder, đây là khác biệt lớn: không để model quyết định bằng cảm giác đủ; ép workflow có cổng xác nhận đủ dữ liệu.

Bạn có thể áp dụng bằng một schema nhỏ cho mọi câu trả lời quan trọng:

{
  "answer": "...",
  "evidence": ["file/path.md", "ticket-123", "command-output"],
  "missing_context": [],
  "confidence_reason": "Đủ vì đã kiểm tra A, B, C",
  "next_search_if_insufficient": "..."
}

Nếu missing_context không rỗng, agent không được trả lời cuối. Nó chỉ được đề xuất bước tìm tiếp. Đây là guardrail rẻ nhưng rất đáng tiền.

Điều nên bỏ qua: chạy theo feature mà không có hợp đồng lớp

Mình không khuyên bạn bỏ Claude Code, QwenPaw, MCP hay agentic RAG. Ngược lại, các primitives này đang rất hữu ích. Thứ nên bỏ là thói quen bật feature vì nó đang ồn ào.

Trước khi thêm một lớp mới, hãy viết layer contract, tức hợp đồng rõ cho lớp đó. Không cần dài. Một trang là đủ.

Ví dụ cụ thể cho skill release_check:

# Skill: release_check

## Input
- Branch name
- Release note draft
- Changed files list

## Allowed tools
- Read repository files
- Run unit tests in sandbox
- Query Jira release tickets

## Forbidden actions
- Push code
- Modify migration files
- Deploy staging or production

## Required output
- Blocking issues
- Non-blocking warnings
- Evidence per issue
- Commands executed

## Escalation
If deployment risk is detected, stop and ask human approval.

Trong một buổi chiều, team bạn có thể làm 5 việc này:

  1. Liệt kê mọi agent capability đang bật: skills, subagents, hooks, MCP servers, slash commands.
  2. Gắn mỗi capability vào một lớp 4C: Context, Capability, Control hoặc Continuity.
  3. Tìm chỗ bị trộn quyền: ví dụ skill vừa đọc tài liệu vừa có quyền chạy deploy.
  4. Thêm output contract cho subagent: bắt buộc có evidence, missing context và hành động đã chạy.
  5. Đặt chế độ dừng: nếu thiếu dữ liệu, quyền vượt phạm vi, hoặc command chạm production thì agent phải hỏi người.

Bạn không cần dựng lại toàn bộ hệ thống. Chỉ cần tách đúng lớp, nhiều lỗi sẽ lộ ra ngay.

Framework mang về: dao sắc để đúng ngăn

Sau bài này, mình muốn bạn đổi một câu hỏi trong đầu.

Đừng hỏi: “Agent framework nào mạnh nhất?”

Hãy hỏi: “Hệ agent của mình có tách rõ thứ nó thấy, thứ nó làm, quyền nó có, và ký ức nó giữ chưa?”

Nếu là mình, mình sẽ chọn stack theo thứ tự này: đầu tiên là guardrail và permission; tiếp theo là context và evidence; sau đó mới tới subagents, plugins, streaming API hay các lớp mở rộng khác. Demo cần mượt, nhưng production cần biết dừng.

Agent tốt không phải đầu bếp múa dao nhanh nhất. Agent tốt là người biết món nào cần lửa nhỏ, món nào phải tắt bếp trước khi khét.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo