TROISINH
Phát triển AgentMulti-Agent & Teams

Role-based Agents: Mỗi agent một chuyên môn

Role-based Agents giải quyết cognitive overload bằng cách phân chuyên môn rõ ràng—từ Architect đến Builder—tăng độ ổn định và giảm lỗi lan truyền trong hệ th...

Khi một agent đơn lẻ cố gắng vừa thiết kế kiến trúc, vừa viết code, vừa review bảo mật, nó sẽ nhanh chóng rơi vào trạng thái "cognitive overload"—context window trở thành mớ hỗn độn giữa constraint cao cấp và syntax error cụ thể. Role-based Agents khắc phục điều này bằng cách tách biệt rõ ràng các chuyên môn, biến hệ thống từ "một người làm hết" thành "một đội phối hợp" với ranh giới năng lực cứng nhắc.

Vấn đề

Single agent suffer skill interference—khi cùng một LLM phải liên tục chuyển đổi giữa chế độ "creative architect" (tư duy chiến lược, chấp nhận rủi ro) và "strict code reviewer" (tư duy phòng ngừa, zero trust), attention mechanism của model bị phân tán. Kết quả là:

  • Context pollution: Instruction về "bảo mật tuyệt đối" bị chìm nghỉm giữa hàng nghìn token code implementation, dẫn đến việc agent tự ý bỏ qua validation step.
  • Mode collapse: Agent không thể duy trì đồng thời cả tư duy high-level (system design) và low-level (syntax debugging), dẫn đến giải pháp "trung bình" không thỏa mãn yêu cầu nào.
  • Error cascade: Một hallucination ở bước thiết kế sẽ lan truyền qua 20+ bước implementation mà không bị chặn lại, vì cùng một "bộ não" tự thuyết phục chính mình rằng lỗi đó là intentional design choice.

Điều này đặc biệt nguy hiểm trong production, nơi specification drift—agent tự ý reinterpret yêu cầu gốc dựa trên statistical likelihood thay vì constraint cứng—xảy ra thường xuyên khi context window bị bão hòa.

Ý tưởng cốt lõi

Role-based architecture áp dụng nguyên tắc cognitive encapsulation (đóng gói nhận thức): mỗi agent chỉ nhìn thấy một tập hợp công cụ và ngữ cảnh phù hợp với chuyên môn, không bị nhiễu bởi concerns của vai trò khác.

Structural Role Discovery (SIRD)

Thay vì phân chia vai trò theo cảm tính ("em làm backend, anh làm frontend"), SIRD sử dụng hierarchical clustering trên action space: nếu hai loại action (ví dụ: "design database schema" và "write CSS animation") hiếm khi xuất hiện trong cùng successful trajectory, chúng sẽ được tách thành hai role riêng biệt. Điều này tối ưu hóa search space reduction—mỗi agent chỉ explore 1/N không gian hành động so với generalist agent.

Encapsulation qua Tool Restriction

Mỗi role được gán một capability boundary cụ thể:

# GoClaw Team Config: Backend Refactoring Squad
team:
  name: "API Modernization"
  task_board: "/shared/tasks/board.md"

agents:
  architect:
    role: "API Designer"
    soul: "./architect.soul.md"
    tools: ["openapi-spec", "dbdiagram", "cost-estimator"]
    outbound: ["builder"]        # Permission link: có thể delegate
    blocked_by: []              # Không phụ thuộc role nào
    
  builder:
    role: "Implementer"
    soul: "./builder.soul.md" 
    tools: ["code-editor", "git", "pytest", "docker"]
    outbound: ["reviewer"]
    blocked_by: ["architect"]   # Chỉ chạy khi architect đánh dấu "spec approved"
    
  reviewer:
    role: "Security & Quality Guard"
    soul: "./reviewer.soul.md"
    tools: ["semgrep", "bandit", "mypy", "license-checker"]
    outbound: ["architect"]      # Có thể yêu cầu redesign
    blocked_by: ["builder"]     # Chỉ review khi có code

Trong đó:

  • outbound/inbound: Định nghĩa permission links kiểm soát ai được quyền gọi ai, tránh "hot potato" loops (A gọi B gọi C gọi lại A).
  • blocked_by: Mô hình hóa task board trạng thái inbox → spec → build → review → done, đảm bảo flow tuần tự khi cần thiết nhưng vẫn cho phép song song hóa sub-tasks không phụ thuộc.

Context Sharding

Thay vì dump toàn bộ project history vào mọi agent, mỗi role chỉ nhận context slice phù hợp:

  • Architect thấy: requirement docs, constraint matrix, historical API error rates.
  • Builder thấy: approved spec, code patterns từ repo, recent test failures.
  • Reviewer thấy: diff của PR, security advisory database, compliance checklist.

Điều này giải quyết "lost in the middle" problem—khi critical constraint nằm ở giữa prompt nhưng attention mechanism bị phân tán bởi surrounding code.

Tại sao nó hoạt động

Attention là zero-sum game: Transformer allocation probability mass theo exponential decay. Khi agent chỉ focus một chuyên môn, 100% attention budget được dùng để optimize cho domain đó, thay vì phải compromise giữa "viết code đẹp" và "thiết kế an toàn".

Variance reduction: Benchmark trên StarCraft II micromanagement (SMAC) cho thấy role-based multi-agent không cải thiện đáng kể win rate (chỉ +3-6%), nhưng giảm độ lệch chuẩn (deviation) tới 66% ở mức độ phức tạp cao. Trong production, độ ổn định (predictability) quan trọng hơn peak performance—bạn cần biết chắc agent sẽ không hallucinate chức năng authentication hơn là thỉnh thoảng viết code nhanh hơn 10%.

Error containment: Rigid boundaries tạo thành firewall cho lỗi. Nếu Architect hallucinate schema sai, Builder không thể tự sửa (vì bị giới hạn tool chỉ là code editor, không có schema design), buộc phải trả task về inbox với trạng thái blocked_by: architect. Điều này buộc phải explicit correction thay vì silent propagation.

Ý nghĩa thực tế

Khi nào nên dùng Role-based

Tiêu chíSingle Agent (Đủ)Role-based (Cần)
Cognitive domains1-2 domain liên quan chặt (chỉ coding)≥3 domain phân biệt rõ (design + code + security)
Task topologyLinear pipeline (bước n sau bước n-1)DAG phức tạp (song song được, có dependency rõ ràng)
Risk toleranceCho phép "happy path" failuresYêu cầu audit trail và governance
Latency budgetThấp (<5s response)Chấp nhận 10-30s do coordination overhead

Trade-offs không thể tránh

Chi phí: Role-based tốn 2-3x token cost do:

  • Serialization overhead (handoff giữa agents qua message passing).
  • Redundant context (mỗi agent cần SOUL.md và system prompt riêng).
  • Tool call multiplication (Reviewer chạy lại test suite mà Builder đã chạy).

Debug complexity: Tracing lỗi qua 3 agents khó hơn debug single agent. Bạn cần distributed tracing (OpenTelemetry spans) để theo dõi decision path từ Architect → Builder → Reviewer, không thể chỉ nhìn vào một chat history duy nhất.

Granularity dilemma: Chia quá mảnh (tách "Frontend Builder" và "Backend Builder" cho dự án nhỏ) tạo coordination overhead không đáng. Nguyên tắc: "Nếu hai role phải communicate >5 lần để hoàn thành một task đơn giản, hãy merge chúng."

Production Stories

  • ROMAS: Hệ thống monitoring database tại enterprise sử dụng 4 role (Monitor, Diagnostician, Repair Planner, Executor) với rule-based handoff. Khi Monitor phát hiện anomaly, nó không tự fix (tránh "gut reaction" sai), mà delegate cho Diagnostician chuyên trách.
  • Devin-style coding swarms: Các agent có role cố định (Code Writer, Test Generator, Debugger) với shared workspace nhưng isolated write permissions—Debugger chỉ đọc code, không được tự sửa (bắt buộc phải trả về Writer).

Đào sâu hơn

Tài liệu chính thức:

Bài viết liên quan TroiSinh:

Cùng cụm

Đọc tiếp

Mở rộng:

  • XAgents Framework (GitHub) — Rule-based multi-agent với IF-THEN interpretability cho compliance-heavy environments.
  • Claude Code Sub-Agents — Kỹ thuật "context sharding" trong thực tế khi một Claude instance spawn sub-agent với toolset riêng.

On this page