Từ Tĩnh đến Thích ứng: Hệ thống Điều phối Tác nhân Động dựa trên Không gian làm việc Chia sẻ

Kiến trúc Cockpit và Chế độ Cộng tác Agent Đa nền tảng

📌 Tóm tắt Cốt lõi

Khi khả năng của các Mô hình Ngôn ngữ Lớn (LLM) được cải thiện, các Agent đơn lẻ đã bộc lộ những hạn chế cố hữu như sự lười biếng của tác nhân, thiên vị tự thân, và lệch hướng mục tiêu khi xử lý các tác vụ phức tạp, dài hạn.

Các quy trình làm việc động do Claude Code đề xuất giải quyết những vấn đề này thông qua sự cô lập đa phiên bản và điều phối tùy chỉnh theo tác vụ, nhưng thiết kế họ mô hình đơn lẻ và điều phối không trạng thái của chúng hạn chế các tình huống ứng dụng thực tế.

Bài viết này đề xuất Kiến trúc Cockpit — một hệ thống điều phối Agent thích ứng dựa trên không gian làm việc chung. Kiến trúc này giới thiệu:

• 🎯 Lớp Quản lý Trạng thái Tập trung (Cockpit)
• 🧠 Bộ điều phối Thông minh (PM)
• 🤖 Nhóm Agent Không đồng nhất (Worker Pool)

Trong khi vẫn giữ lại các lợi thế cốt lõi của quy trình làm việc động, nó đạt được sự cộng tác Agent đa nền tảng và tối ưu hóa thích ứng dựa trên hiệu suất lịch sử.

Thực tiễn cho thấy, kiến trúc Cockpit thể hiện tỷ lệ hoàn thành tác vụ cao hơn và khả năng kiểm soát kỹ thuật tốt hơn trong các tác vụ phức tạp như di chuyển mã và nghiên cứu chuyên sâu.

Từ khóa

: Quy trình làm việc động · Điều phối Agent · Không gian làm việc chung · Hệ thống thích ứng · Cộng tác đa nền tảng

01 Giới thiệu: Từ Thế khó đến Đột phá

🔴 Ba Thế khó của Ngữ cảnh Đơn lẻ

Trong các ứng dụng AI Agent thực tế, các nhà phát triển thường áp dụng cách tiếp cận trực tiếp nhất: để Claude, GPT hoặc các LLM khác hoàn thành tác vụ trong một cửa sổ trò chuyện duy nhất.

Chế độ này hoạt động tốt cho các tình huống đơn giản, nhưng khi các tác vụ trở nên phức tạp — yêu cầu xem xét 50 tệp, di chuyển toàn bộ cơ sở mã, hoặc tiến hành nghiên cứu chuyên sâu — chế độ ngữ cảnh đơn lẻ bắt đầu bộc lộ các vấn đề mang tính hệ thống.

Tài liệu phát hành của Anthropic cho các quy trình làm việc động của Claude Code chỉ ra rõ ràng ba chế độ thất bại:

💤 Sự lười biếng của Tác nhân

Agent tuyên bố tác vụ đã hoàn thành sớm sau khi chỉ thực hiện xong một phần công việc.

Kịch bản Điển hình: Trong một cuộc kiểm toán bảo mật, nó xử lý 20 trên 50 mục và đánh dấu phần còn lại là "đã xử lý."

🎭 Thiên vị Tự thân

Khi một Agent được yêu cầu xác minh đầu ra của chính nó, nó có xu hướng ưu ái kết quả của mình.

Vấn đề Cốt lõi: Một người xác thực có liên quan đến kết quả không thể là một thẩm phán công bằng.

🌊 Lệch hướng Mục tiêu

Trong các tương tác nhiều vòng, đặc biệt là sau khi nén ngữ cảnh, Agent dần dần đi chệch khỏi mục tiêu ban đầu.

Trường hợp Thực tế: Ràng buộc "không làm X" lặng lẽ biến mất vào vòng trò chuyện thứ 47.

🟢 Lời hứa của Quy trình làm việc Động

Để giải quyết những vấn đề này, Anthropic đã ra mắt tính năng Quy trình làm việc Động vào tháng 5 năm 2026.

Ý tưởng Cốt lõi: Để Claude tự động tạo ra một khuôn khổ điều phối tùy chỉnh cho một tác vụ cụ thể — một tệp JavaScript tạo và điều phối nhiều Agent con thông qua các chức năng đặc biệt, với mỗi Agent con có một cửa sổ ngữ cảnh độc lập và các mục tiêu tập trung.

Ba Khả năng Chính

✅ Cô lập theo Agent: Mỗi Agent con có một ngữ cảnh độc lập, ngăn ngừa sự can thiệp.

✅ Lựa chọn Mô hình theo Agent: Sử dụng Opus cho lý luận phức tạp và Haiku cho khám phá chi phí thấp.

✅ Mức độ Cô lập theo Agent: Cây làm việc (checkout Git độc lập) hoặc kho lưu trữ từ xa.

Sáu Mẫu Cốt lõi

Các kỹ sư của Anthropic đã tổng kết sáu mẫu điều phối lặp đi lặp lại:

• 🔀 Phân loại và Định tuyến
• 🌟 Phân nhánh & Tổng hợp
• ⚔️ Xác minh Đối kháng
• 🎯 Tạo và Lọc
• 🏆 Xếp hạng Giải đấu
• 🔄 Lặp lại Cho đến khi Hoàn thành

Các mẫu này giải quyết một cách có cấu trúc các chế độ thất bại của một ngữ cảnh đơn lẻ.

▲ Ba chế độ thất bại của ngữ cảnh đơn lẻ: Sự lười biếng của Tác nhân, Thiên vị Tự thân, Lệch hướng Mục tiêu

🟡 Khoảng cách giữa Lý thuyết và Thực hành Kỹ thuật

Tuy nhiên, các quy trình làm việc động phải đối mặt với hai hạn chế chính trong các ứng dụng kỹ thuật thực tế:

⚠️ Hạn chế về Họ Mô hình Đơn lẻ

Các quy trình làm việc động chỉ có thể sử dụng các mô hình thuộc họ Claude (Opus/Sonnet/Haiku).

Trong các tình huống thực tế, các Agent từ các nền tảng khác nhau có những thế mạnh khác nhau:

• Claude Code xuất sắc trong việc tái cấu trúc mã
• Codex hoạt động xuất sắc trong việc triển khai thuật toán
• Gemini có lợi thế trong các tác vụ đa phương thức

Một họ mô hình đơn lẻ không thể tận dụng hết chuyên môn của các nền tảng khác nhau.

⚠️ Điều phối Không Trạng thái

Mỗi tác vụ tạo ra một tập lệnh quy trình làm việc hoàn toàn mới; không có bộ nhớ lịch sử giữa các Agent.

Vấn đề:

• Không thể tối ưu hóa các chiến lược lựa chọn Agent dựa trên hiệu suất trong quá khứ
• Không thể tích lũy kiến thức giữa các tác vụ
• Mỗi lần đều "bắt đầu từ con số không"

💡 Kiến trúc Cockpit: Một Giải pháp để Thu hẹp Khoảng cách

Kiến trúc Cockpit được đề xuất trong bài viết này được thiết kế để thu hẹp khoảng cách này.

Chúng tôi giữ lại các lợi thế cốt lõi của quy trình làm việc động:

• ✅ Cô lập đa phiên bản
• ✅ Điều phối động

Trong khi giới thiệu các khả năng mới:

• 🆕 Không gian làm việc chung
• 🆕 Cơ chế thích ứng
• 🆕 Cộng tác đa nền tảng

Đạt được một chế độ cộng tác Agent linh hoạt và thông minh hơn.

02 Xem xét Lý thuyết Quy trình làm việc Động

Tĩnh so với Động: So sánh Hai Mô hình

Trước khi hiểu về quy trình làm việc động, cần phải làm rõ khái niệm về quy trình làm việc tĩnh.

🔵 Quy trình làm việc Tĩnh: Các Quy trình Cố định được Xác định trước

Cho dù sử dụng các nền tảng tự động hóa trực quan như N8N hay Zapier, hay các tập lệnh điều phối được viết bằng Claude Agent SDK, các đặc điểm là:

Ví dụ: Một "Quy trình làm việc Đánh giá Mã" được thiết kế trong N8N

1Trích xuất Mã → Gọi Claude để Phân tích → Lưu Kết quả → Gửi Thông báo

Quy trình này giống nhau bất kể mã nào đang được xem xét.

🟣 Quy trình làm việc Động: Các Kế hoạch Thực thi Tùy chỉnh theo Tác vụ

Một kế hoạch thực thi được Claude điều chỉnh cho tác vụ hiện tại:

Ví dụ: Đối với cùng một đánh giá mã, một quy trình làm việc động có thể:

1. Đầu tiên quét cơ sở mã để xác định đó là một dự án React
2. Quyết định sử dụng Haiku hay Opus dựa trên độ phức tạp của thành phần
3. Tạo một Agent đánh giá chuyên biệt cho việc sử dụng Hooks
4. Thêm một bước kiểm tra kiểu TypeScript
5. Xử lý song song thay vì tuần tự

Giải thích Chi tiết về Sáu Mẫu Cốt lõi

Các kỹ sư của Anthropic đã tổng kết sáu mẫu điều phối lặp đi lặp lại trong thực tế:

1️⃣ Phân loại và Định tuyến

Sử dụng một Agent phân loại để xác định loại tác vụ, sau đó định tuyến nó đến các Agent xử lý khác nhau.

Kịch bản: "Giải thích cách hoạt động của mô-đun xác thực"

• Agent phân loại đầu tiên đánh giá độ phức tạp
• Các mô-đun đơn giản sử dụng Sonnet
• Các mô-đun phức tạp sử dụng Opus

2️⃣ Phân nhánh & Tổng hợp

Phân rã một tác vụ thành nhiều tác vụ con độc lập, thực thi chúng song song và cuối cùng tổng hợp kết quả.

Giá trị Cốt lõi: Giải quyết vấn đề "quá nhiều thứ được xử lý cùng một lúc." Mỗi Agent con chỉ nhìn thấy phần của nó và không bị phân tâm bởi 50 chi tiết không liên quan.

💡

Đây là mẫu được sử dụng phổ biến nhất

3️⃣ Xác minh Đối kháng

Tạo một Agent xác minh độc lập cho mỗi kết quả được tạo ra. Người xác thực này chưa bao giờ thấy công việc gốc và không thể tạo ra sự thiên vị tự thân.

Giải pháp Cấu trúc: Phương pháp cơ bản để giải quyết sự thiên vị tự thân.

4️⃣ Tạo và Lọc

Tạo ra nhiều giải pháp ứng cử viên và sau đó sử dụng một bộ xác thực để lọc chúng.

Sự khác biệt Chính: Không giống như trực tiếp yêu cầu "câu trả lời tốt nhất," mẫu này cho phép Agent trì hoãn cam kết, chỉ đưa ra quyết định sau khi tất cả các lựa chọn đã được thử thách.

5️⃣ Xếp hạng Giải đấu

Cho nhiều Agent cạnh tranh cho cùng một tác vụ và xác định người chiến thắng thông qua so sánh theo cặp.

Kịch bản Áp dụng: Công việc định hướng thị hiếu

• Các lựa chọn thiết kế
• Các phương án đặt tên
• Các quyết định về giao diện người dùng

Lợi thế Cốt lõi: Phán đoán so sánh đáng tin cậy hơn là chấm điểm tuyệt đối.

6️⃣ Lặp lại Cho đến khi Hoàn thành

Liên tục tạo ra các Agent cho đến khi một điều kiện dừng được đáp ứng.

Ví dụ về Điều kiện Dừng:

• Không có khám phá mới
• Không có lỗi trong nhật ký
• Lý thuyết đã được xác minh

Sự đảm bảo: "Thực sự hoàn thành" thay vì "tuyên bố hoàn thành."

▲ Sáu mẫu điều phối cốt lõi: Phân loại và Định tuyến, Phân nhánh & Tổng hợp, Xác minh Đối kháng, Tạo và Lọc, Xếp hạng Giải đấu, Lặp lại Cho đến khi Hoàn thành

Hạn chế của các Giải pháp Hiện có

Mặc dù các quy trình làm việc động là thanh lịch về mặt lý thuyết, chúng có bốn thiếu sót chính trong thực hành kỹ thuật:

Câu hỏi Cốt lõi: Liệu chúng ta có thể thiết kế một kiến trúc giữ lại các lợi thế của điều phối động trong khi vẫn có khả năng kiểm soát kỹ thuật?

03 Thiết kế Kiến trúc Cockpit

Tổng quan Hệ thống: Kiến trúc Ba Lớp

Kiến trúc Cockpit áp dụng thiết kế ba lớp:

1┌─────────────────────────────────────────┐
2│      Cockpit (Lớp Không gian làm việc Chung)│
3│  ┌──────┬──────┬──────────────────┐    │
4│  │ Kế   │ Nhiệm│ Nghiên cứu       │    │
5│  │ hoạch│ vụ   │                  │    │
6│  ├──────┼──────┼──────────────────┤    │
7│  │Báo cáo│Vấn đề│ Cơ sở Kiến thức │    │
8│  └──────┴──────┴──────────────────┘    │
9└─────────────────────────────────────────┘
10              ↕️ Quyền Đọc/Ghi
11┌─────────────────────────────────────────┐
12│         PM (Lớp Điều phối)               │
13│  • Phân rã Tác vụ                        │
14│  • Lựa chọn Worker (Hiệu suất Lịch sử)   │
15│  • Giám sát Tiến độ                      │
16│  • Duy trì Kế hoạch                      │
17└─────────────────────────────────────────┘
18         ↕️ Giao Tác vụ & Thu thập Kết quả
19┌─────────────────────────────────────────┐
20│      Worker Pool (Lớp Thực thi)          │
21│  ┌────────┬────────┬──────────────┐    │
22│  │ Claude │ Codex  │ Gemini       │    │
23│  │ Code   │ Agent  │ Agent        │    │
24│  └────────┴────────┴──────────────┘    │
25│       ↕️ Cập nhật Trạng thái Nhiệm vụ lên Cockpit│
26└─────────────────────────────────────────┘

▲ Kiến trúc Ba Lớp Cockpit: Lớp Không gian làm việc Chung, Lớp Điều phối PM, Lớp Thực thi Worker

Khái niệm Thiết kế Cốt lõi: Tất cả các Agent làm việc xung quanh cùng một "bảng trắng" (Cockpit) thay vì cộng tác thông qua việc truyền tin nhắn.

💡

Tương tự như một nhóm phần mềm cộng tác xung quanh một Kho Git + Bảng Dự án thay vì gửi email cho nhau.

Thiết kế Thành phần Cockpit: Sáu Thành phần Cốt lõi

Cockpit là trung tâm thần kinh của hệ thống, chứa sáu thành phần cốt lõi.

Dưới đây là giao diện Cockpit trong hoạt động thực tế:

▲ Giao diện Kế hoạch Cockpit - Hiển thị mục tiêu dự án và tiến độ cột mốc

▲ Giao diện Nhiệm vụ Cockpit - Theo dõi trạng thái hoàn thành nhiệm vụ theo thời gian thực

▲ Giao diện Dòng thời gian Cockpit - Phân tích mức sử dụng Worker và xu hướng Phân công

📋 Kế hoạch (Neo Mục tiêu)

Chức năng:

• Lưu trữ các mục tiêu và ràng buộc cốt lõi của dự án
• Tất cả các Agent phải đọc Kế hoạch để căn chỉnh mục tiêu trước khi thực thi

Giá trị: Ngăn ngừa lệch hướng mục tiêu — ngay cả sau nhiều vòng tương tác, ý định ban đầu vẫn rõ ràng.

Dữ liệu Thực tế: Từ ảnh chụp màn hình, tiến độ dự án HippoTeam là 89% (187/209), bao gồm 6 cột mốc từ M1-M6, mỗi cột mốc có trạng thái hoàn thành rõ ràng.

✅ Nhiệm vụ (Theo dõi Tiến độ)

Chức năng:

• Ghi lại trạng thái của tất cả các tác vụ con: Đang chờ, Đang thực hiện, Đã hoàn thành
• Worker cập nhật trạng thái sau khi hoàn thành tác vụ
• PM điều chỉnh điều phối tiếp theo dựa trên trạng thái thời gian thực

Giá trị: Giải quyết "sự lười biếng của tác nhân" — việc hoàn thành tác vụ rõ ràng trong nháy mắt, ngăn ngừa báo cáo sai.

Dữ liệu Thực tế: Có 408 tác vụ trong hoạt động thực tế, với tỷ lệ hoàn thành là 401/408 và có thể xem các bản ghi phân công chi tiết.

🔬 Nghiên cứu (Tích lũy Nghiên cứu)

Chức năng:

• Lưu trữ thông tin thu thập được trong quá trình nghiên cứu
• Có thể truy cập được cho tất cả các Agent để tránh nghiên cứu trùng lặp

Giá trị: Hỗ trợ tái sử dụng kiến thức và đào sâu lặp đi lặp lại.

Dữ liệu Thực tế: Hiện có 71 bản ghi nghiên cứu trong hệ thống.

📊 Báo cáo (Quản lý Sản phẩm Bàn giao)

Chức năng:

• Lưu trữ kết quả đầu ra từ mỗi giai đoạn
• Hỗ trợ theo dõi phiên bản và truy xuất nguồn gốc

Giá trị: Tạo điều kiện thuận lợi cho việc tổng hợp cuối cùng và kiểm tra chất lượng.

Dữ liệu Thực tế: 78 báo cáo đã được tích lũy trong hệ thống.

⚠️ Vấn đề (Quản lý Vấn đề)

Chức năng:

• Ghi lại các vấn đề được phát hiện trong quá trình thực thi
• Bất kỳ Agent nào cũng có thể thêm một Vấn đề

Giá trị: PM điều chỉnh chiến lược hoặc giao tác vụ sửa chữa dựa trên các Vấn đề.

📚 Cơ sở Kiến thức (Cơ sở Kiến thức)

Chức năng:

• Tích lũy kiến thức giữa các tác vụ
• Ghi lại số liệu thống kê hoạt động của Worker

Giá trị: Cung cấp nền tảng dữ liệu cho phân tích của con người và tối ưu hóa thích ứng trong tương lai.

Triển khai Thực tế: Ghi lại hiệu suất lịch sử của Worker thông qua chế độ xem Dòng thời gian. Từ ảnh chụp màn hình, có thể thấy dữ liệu chi tiết của Quan Vũ (55 lần phân công, trung bình 12 phút), Triệu Vân (21 lần phân công, trung bình 10 phút), Điển Vi (20 lần phân công, trung bình 10 phút) và Trương Phi (4 lần phân công, trung bình 7 phút), cùng với biểu đồ xu hướng Phân công từ 20/05 đến 25/05. Dữ liệu này hiện được sử dụng để giám sát và phân tích của con người, và có thể được sử dụng để thiết lập các vòng phản hồi tự động trong tương lai.

💡

Các Thành phần Bổ sung: Hệ thống thực tế cũng bao gồm các mô-đun phụ trợ như Ý tưởng (Kho ý tưởng, 4 ý tưởng đang chờ đánh giá) và Quyết định (Bản ghi quyết định, 24), hỗ trợ các mẫu nâng cao như "Tạo và Lọc."

Luồng Dữ liệu và Cơ chế Tương tác

Trước khi đi sâu vào cơ chế điều phối PM, hãy hiểu luồng dữ liệu giữa các Agent và Cockpit.

🔄 Sơ đồ Luồng Dữ liệu Agent-Cockpit

▲ Tương tác luồng dữ liệu hoàn chỉnh giữa Agent và Cockpit

Đường dẫn Tương tác Cốt lõi:

Thiết kế Chính:

• ✅ Phụ thuộc Một chiều: Worker phụ thuộc vào Cockpit nhưng không giao tiếp trực tiếp với PM hoặc các Worker khác.
• ✅ Trạng thái Tập trung: Tất cả các thay đổi trạng thái đều đi qua Cockpit, đảm bảo tính nhất quán toàn cầu.
• ✅ Tách rời Không đồng bộ: Worker chỉ cần cập nhật trạng thái của chúng sau khi hoàn thành một tác vụ mà không cần đợi phản hồi từ PM.

🔒 Cơ chế Đồng bộ Trạng thái cho Truy cập Đồng thời

Khi nhiều Worker truy cập Cockpit đồng thời, tính nhất quán dữ liệu được đảm bảo như thế nào?

▲ Cơ chế đồng bộ trạng thái cho truy cập đồng thời của nhiều Worker

Cơ chế Đảm bảo Ba Lớp:

1️⃣ Khóa Lạc quan

Mỗi thành phần Cockpit duy trì một số phiên bản:

1Nhiệm vụ v1 → Worker A đọc
2Nhiệm vụ v1 → Worker B đọc
3
4Worker A gửi cập nhật → kiểm tra phiên bản v1 → Thành công → Nhiệm vụ v2
5Worker B gửi cập nhật → kiểm tra phiên bản v1 → Phát hiện xung đột → Tự động thử lại

Lợi thế: Không khóa trong hầu hết các trường hợp, hiệu suất cao.

2️⃣ Hàng đợi Giao dịch

Tất cả các thao tác ghi đi vào một hàng đợi và được thực thi tuần tự:

1Worker #1: Cập nhật trạng thái Nhiệm vụ-001 → Vị trí hàng đợi 1
2Worker #2: Ghi Báo cáo-042 → Vị trí hàng đợi 2
3Worker #3: Thêm Vấn đề-015 → Vị trí hàng đợi 3
4Worker #4: Cập nhật trạng thái Nhiệm vụ-002 → Vị trí hàng đợi 4

Sự đảm bảo: Tính nguyên tử và thứ tự của các thao tác ghi.

3️⃣ Phát hiện Xung đột và Tự động Thử lại

Khi phát hiện xung đột phiên bản:

1. Rollback: Hủy bỏ bản cập nhật hiện tại.
2. Đọc lại: Lấy trạng thái mới nhất.
3. Tính toán lại: Tạo lại bản cập nhật dựa trên trạng thái mới.
4. Gửi lại: Thử ghi lại.

Trường hợp Thực tế:

Worker A và Worker B hoàn thành Nhiệm vụ-001 và Nhiệm vụ-002 đồng thời, cả hai đều cố gắng cập nhật số liệu thống kê tỷ lệ hoàn thành trong thành phần Nhiệm vụ.

- Worker A gửi trước, Nhiệm vụ cập nhật từ v5 lên v6, tỷ lệ hoàn thành 400/408.

- Worker B phát hiện phiên bản đã thay đổi thành v6 (không phải v5 mà nó đã đọc) khi gửi.

- Hệ thống tự động yêu cầu Worker B đọc lại v6 và tính toán lại tỷ lệ hoàn thành thành 401/408.

- Worker B gửi thành công, Nhiệm vụ cập nhật lên v7.

Tối ưu hóa Hiệu suất:

• 🟢 Thao tác Đọc Không Khóa: Nhiều Worker có thể đọc đồng thời mà không chặn nhau.
• 🟡 Thao tác Ghi Nhẹ: Hầu hết các bản cập nhật là thao tác nối thêm (thêm Báo cáo, Vấn đề), do đó xác suất xung đột thấp.
• 🔴 Xung đột Hiếm: Xung đột chỉ xảy ra khi cập nhật cùng một trạng thái nhiệm vụ đồng thời, với tỷ lệ xuất hiện thực tế < 2%.

Cơ chế Điều phối Thích ứng của PM

PM (Project Manager) là bộ não của hệ thống, chịu trách nhiệm điều phối động.

Không giống như điều phối không trạng thái của các quy trình làm việc động Claude, PM của Cockpit sở hữu khả năng ghi nhớ và học tập.

🧩 Phân rã Tác vụ

Quy trình:

1. Sau khi nhận được yêu cầu của người dùng, PM phân tích các đặc điểm của tác vụ.
2. Đọc dữ liệu lịch sử và ngữ cảnh hiện tại từ Cockpit.
3. Phân rã tác vụ thành các tác vụ con song song hoặc tuần tự.
4. Cập nhật các thành phần Kế hoạch và Nhiệm vụ.

🎯 Lựa chọn Worker dựa trên Vai trò

PM thực hiện phân công thông minh dựa trên loại tác vụ và vai trò của Worker:

Quy trình Quyết định:

11️⃣ Xác định Loại Tác vụ
2   Tái cấu trúc Mã / Triển khai Thuật toán / Đánh giá Mã / Phân tích Đa phương thức
3
42️⃣ Khớp Vai trò Đặt trước
5   lập trình viên / người kiểm thử / người đánh giá / nhà nghiên cứu
6
73️⃣ Xem xét Phân công Rõ ràng của Người dùng
8   Các tác vụ cụ thể được giao cho các Worker cụ thể
9
104️⃣ Xem xét Tải hiện tại
11   Số lượng tác vụ hiện tại và khả năng sẵn sàng của Worker

Trường hợp Hoạt động Thực tế:

Từ dữ liệu hoạt động thực tế của HippoTeam, chúng ta có thể thấy:

Tác vụ Tái cấu trúc Mã

→ Được giao cho Worker có vai trò lập trình viên (Quan Vũ, Triệu Vân, Điển Vi)

Tác vụ Đánh giá Mã

→ Được giao cho vai trò người đánh giá độc lập (Chung Quỳ) để đảm bảo xác minh đối kháng

Tác vụ Triển khai Thuật toán

→ Worker lập trình viên thích hợp được chọn dựa trên độ phức tạp

Giám sát Dòng thời gian: Hệ thống ghi lại số lần phân công và thời gian hoàn thành trung bình cho mỗi Worker (ví dụ: Quan Vũ 55 lần/trung bình 12 phút, Triệu Vân 21 lần/trung bình 10 phút) thông qua chế độ xem Dòng thời gian, tạo điều kiện thuận lợi cho việc phân tích của con người và điều chỉnh cấu hình vai trò.

💡

Hướng đi Tương lai: Dữ liệu Dòng thời gian hiện tại để hiển thị; trong tương lai, có thể thiết lập một vòng phản hồi để cho PM tự động tối ưu hóa các chiến lược lựa chọn Worker dựa trên hiệu suất lịch sử.

📈 Giám sát Tiến độ và Điều chỉnh Động

Khả năng Thời gian thực:

• Đọc trạng thái Nhiệm vụ theo thời gian thực.
• Nếu một Worker không phản hồi trong một thời gian dài, hãy giao lại tác vụ.
• Nếu một vấn đề chặn xuất hiện trong Vấn đề, hãy điều chỉnh kế hoạch thực thi.

Thiết kế Worker Pool

Worker Pool là lớp thực thi của hệ thống, chứa nhiều Agent không đồng nhất.

🌐 Agent Không đồng nhất Đa nền tảng

Không giống như các quy trình làm việc động của Claude chỉ có thể sử dụng họ Claude, Cockpit hỗ trợ các Agent từ bất kỳ nền tảng nào:

Mỗi nền tảng có thể có nhiều phiên bản (ví dụ: Claude Code #1, #2, #3), đạt được xử lý song song thực sự.

⚖️ Vai trò Cố định so với Trách nhiệm Động

Đây là một sự đánh đổi kỹ thuật quan trọng.

Cockpit áp dụng chế độ "Nhóm Vai trò Cố định + Phân công Trách nhiệm Động":

✅ Vai trò Cố định: Ranh giới năng lực của Worker được xác định trước (Claude Code là chuyên gia mã, Gemini là chuyên gia đa phương thức).

✅ Trách nhiệm Động: Các tác vụ cụ thể được PM phân công động dựa trên tình hình.

Lợi thế Thiết kế:

🔄 Giao thức Cập nhật Trạng thái

Sau khi hoàn thành một tác vụ, Worker phải cập nhật Cockpit:

• ✅ Cập nhật trạng thái tác vụ trong Nhiệm vụ.
• 📄 Ghi kết quả vào Báo cáo.
• ⚠️ Thêm một Vấn đề nếu tìm thấy vấn đề.
• 📚 Ghi kiến thức tích lũy vào Nghiên cứu.

Điều này đảm bảo tính nhất quán và khả năng truy xuất nguồn gốc của trạng thái hệ thống.

▲ Các Agent không đồng nhất đa nền tảng cộng tác xung quanh một không gian làm việc chung

Triển khai Sáu Mẫu trong Cockpit

Kiến trúc Cockpit hoàn toàn tương thích với sáu mẫu của quy trình làm việc động Claude và nâng cao việc triển khai chúng:

🔀 Phân loại và Định tuyến

Triển khai:

• PM hoạt động như một bộ phân loại, chọn Worker thích hợp dựa trên đặc điểm của tác vụ.

Cải tiến:

• Không giống như mẫu gốc, quyết định phân loại của PM dựa trên dữ liệu lịch sử, do đó chính xác hơn.

🌟 Phân nhánh & Tổng hợp

Triển khai:

• PM phân rã tác vụ và giao nó cho nhiều Worker thực thi song song.
• Tất cả các Worker ghi kết quả vào Báo cáo trong Cockpit.
• PM đọc tất cả kết quả và thực hiện tổng hợp.

⚔️ Xác minh Đối kháng

Triển khai:

• PM giao một Worker xác minh độc lập cho mỗi tác vụ tạo.
• Worker xác minh chỉ đọc kết quả từ Báo cáo và không biết ai đã tạo ra chúng.
• Kết quả xác minh được ghi vào Vấn đề, và PM quyết định có làm lại dựa trên Vấn đề hay không.

🎯 Tạo và Lọc

Triển khai:

• PM giao nhiều Worker để tạo ra các giải pháp ứng cử viên.
• Sau đó giao các Worker xác minh để lọc và chấm điểm.
• Giải pháp tối ưu được ghi vào Báo cáo.

🏆 Xếp hạng Giải đấu

Triển khai:

• PM tổ chức so sánh theo cặp, giao hai tác vụ so sánh cho Worker mỗi lần.
• Kết quả so sánh được ghi lại trong Cockpit và PM duy trì bảng xếp hạng.
• Người chiến thắng cuối cùng được ghi vào Báo cáo.

🔄 Lặp lại Cho đến khi Hoàn thành

Triển khai:

• PM kiểm tra trạng thái của Nhiệm vụ và Vấn đề.
• Miễn là có các tác vụ chưa hoàn thành hoặc các vấn đề chưa được giải quyết, nó tiếp tục giao Worker.
• Cho đến khi tất cả các Nhiệm vụ được đánh dấu là hoàn thành và Vấn đề trống.

04 Các Quyết định Thiết kế Chính

Tại sao chọn Nhóm Vai trò Cố định?

Khi thiết kế Cockpit, chúng tôi phải đối mặt với một câu hỏi cốt lõi:

Chúng ta nên tạo Agent tạm thời mỗi lần như các quy trình làm việc động của Claude, hay duy trì một nhóm Agent cố định?

Chúng tôi đã chọn phương án sau vì những lý do sau:

💰 Khả năng Kiểm soát Chi phí

Việc tạo Agent tạm thời có thể dẫn đến chi phí mất kiểm soát.

Kịch bản Rủi ro: Trong một tác vụ phức tạp, nếu không có giới hạn, hệ thống có thể tạo ra hàng chục hoặc thậm chí hàng trăm phiên bản Agent.

Giải pháp: Một nhóm vai trò cố định đặt ra giới hạn đồng thời, làm cho chi phí có thể dự đoán được.

🛠️ Tính ổn định Kỹ thuật

Vai trò cố định có nghĩa là ranh giới năng lực của mỗi Agent rõ ràng, tạo điều kiện thuận lợi cho:

• Giám sát
• Gỡ lỗi
• Tối ưu hóa

So sánh: Các Agent được tạo tạm thời rất khó theo dõi và khó xác định vị trí khi có vấn đề phát sinh.

🌐 Lợi thế Đa nền tảng

Một nhóm vai trò cố định cho phép chúng tôi tích hợp các Agent từ các nền tảng khác nhau và tận dụng thế mạnh tương ứng của chúng.

Hạn chế: Các chế độ tạo tạm thời rất khó phối hợp giữa các nền tảng.

📊 Nền tảng cho Học tập Thích ứng

Chỉ với các vai trò cố định, chúng ta mới có thể tích lũy dữ liệu hiệu suất lịch sử cho mỗi Agent, cho phép phân công thông minh dựa trên hiệu suất.

Điều này không có nghĩa là mất đi tính linh hoạt

PM vẫn có thể quyết định động:

• ✅ Giao tác vụ này cho ai.
• ✅ Sử dụng bao nhiêu Worker để xử lý song song.
• ✅ Có cần xác minh đối kháng hay không.
• ✅ Khi nào nên dừng vòng lặp.

💡

Cái được cố định là vai trò; cái được động là chiến lược điều phối.

Không gian làm việc chung (Shared Workspace) so với Truyền tin nhắn (Message Passing)

Trong lĩnh vực cộng tác Agent, giải pháp chủ đạo hiện nay là chế độ truyền tin nhắn:

1Agent A hoàn thành nhiệm vụ → gửi kết quả dưới dạng tin nhắn → Agent B

Chế độ này đơn giản và trực quan nhưng có vấn đề:

❌ Ba Vấn đề Lớn của Chế độ Truyền tin nhắn

✅ Chế độ Không gian làm việc chung của Cockpit

Ưu điểm:

Phép so sánh: Sự thay đổi mô hình trong phát triển phần mềm

1Từ "Giao tiếp qua Email" → đến "Cộng tác xoay quanh một Git Repository"

Cách sau cải thiện đáng kể hiệu quả cộng tác.

Ưu điểm của Agent đa nền tảng

Một trong những lợi thế quan trọng nhất của kiến trúc Cockpit là hỗ trợ phối hợp lai ghép Agent đa nền tảng.

🎯 Tận dụng Thế mạnh của từng Nền tảng

🛡️ Giảm thiểu Rủi ro Phụ thuộc vào Nền tảng

Không bị ràng buộc vào một nền tảng duy nhất cho phép chuyển đổi nhanh sang các giải pháp thay thế nếu một nền tảng gặp sự cố hoặc bị giới hạn tốc độ.

💰 Tối ưu hóa Chi phí

Chọn mô hình phù hợp dựa trên độ phức tạp của nhiệm vụ:

• Nhiệm vụ đơn giản → Mô hình chi phí thấp
• Nhiệm vụ phức tạp → Mô hình năng lực cao

Cơ chế thích ứng của PM sẽ dần dần tìm ra điểm cân bằng chi phí - chất lượng tối ưu.

🏗️ Trường hợp Thực tế

Kịch bản: Nhiệm vụ di chuyển cơ sở mã nguồn

💡

Kiểu phối hợp lai ghép này là không thể thực hiện được trong một giải pháp đơn nền tảng.

So sánh Toàn diện Ba Chế độ

▲ Sự tiến hóa của ba mô hình quy trình làm việc: Từ Tĩnh đến Động, rồi đến Cộng tác

Khuyến nghị Kịch bản Ứng dụng

🔵 Sử dụng Quy trình làm việc Tĩnh (N8N/Zapier) khi:

• ✅ Quy trình nhiệm vụ rất cố định và hầu như không cần thay đổi.
• ✅ Không cần cộng tác Agent phức tạp.
• ✅ Theo đuổi sự đơn giản và trực quan tối đa.

🟣 Sử dụng Quy trình làm việc Động của Claude khi:

• ✅ Nhiệm vụ phức tạp và yêu cầu sự cô lập đa Agent.
• ✅ Chỉ sử dụng nền tảng Claude.
• ✅ Không cần tích lũy kiến thức giữa các nhiệm vụ.
• ✅ Chấp nhận mức tiêu thụ token cao.

🟢 Sử dụng Kiến trúc Cockpit khi:

• ✅ Cần phối hợp lai ghép Agent đa nền tảng.
• ✅ Có nhu cầu tái sử dụng kiến thức giữa các nhiệm vụ.
• ✅ Yêu cầu nhóm vai trò cố định và phân công thông minh dựa trên vai trò.
• ✅ Có yêu cầu về kiểm soát chi phí và khả năng truy xuất nguồn gốc.
• ✅ Bạn sẵn sàng đầu tư nguồn lực kỹ thuật để xây dựng hệ thống.

Kết luận

Kiến trúc Cockpit được đề xuất trong bài viết này đạt được một bước đột phá kỹ thuật trên nền tảng lý thuyết của quy trình làm việc động bằng cách giới thiệu không gian làm việc chung và cơ chế phối hợp dựa trên vai trò:

✅ Giữ lại các ưu điểm cốt lõi của quy trình làm việc động

• Cô lập phiên bản đa Agent, giải quyết tình trạng lười biếng và lệch mục tiêu của agent.
• Xác minh đối kháng, giải quyết thiên vị tự ưu tiên.
• Phối hợp động, tối ưu hóa cho các nhiệm vụ cụ thể.

🚀 Phá vỡ các giới hạn của giải pháp ban đầu

• Nhóm Agent đa nền tảng, tận dụng thế mạnh của từng nền tảng.
• Phân công thông minh dựa trên vai trò, đảm bảo nhiệm vụ phù hợp với năng lực.
• Không gian làm việc chung, đạt được sự nhất quán trạng thái và tái sử dụng kiến thức.
• Nhóm vai trò cố định, đảm bảo khả năng kiểm soát chi phí và sự ổn định kỹ thuật.

Thực hành Kiểm chứng

Dữ liệu vận hành thực tế từ dự án HippoTeam (408 nhiệm vụ, 8 Worker cố định, 71 bản ghi nghiên cứu, 78 báo cáo) cho thấy kiến trúc Cockpit thể hiện trong cộng tác nhiệm vụ phức tạp:

• ✅ Khả năng kiểm soát kỹ thuật tốt hơn
• ✅ Hiệu quả cộng tác cao hơn
• ✅ Khả năng truy xuất nguồn gốc hoàn chỉnh

Triển vọng Tương lai

Khi năng lực của LLM tiếp tục được cải thiện và các ứng dụng Agent ngày càng sâu rộng, chúng tôi tin rằng:

Chế độ không gian làm việc chung sẽ trở thành mô hình tiêu chuẩn cho các hệ thống cộng tác Agent phức tạp.

Tài liệu tham khảo

1. Anthropic. (2026). "Dynamic Workflows in Claude Code: 6 patterns and 14 steps"
2. "How to master Dynamic Workflows in Claude Code: 6 patterns and 14 steps Anthropic engineers actually use"
3. AutoGPT Project. "Autonomous AI Agent Framework"
4. LangChain Documentation. "Agent and Chain Orchestration"
5. CrewAI. "Role-based Agent Collaboration Framework"

Tác giả: Huangserva Ngày: Tháng 6, 2026 Từ khóa: Dynamic Workflow · Agent Orchestration · Shared Workspace · Adaptive System · Cross-platform Collaboration

💡

Nếu bài viết này hữu ích với bạn, hãy chia sẻ nó với nhiều bạn bè quan tâm đến kiến trúc AI Agent hơn nhé!