Mô hình tham chiếu về cách các tổ chức cấu trúc công việc với AI
Jose Martinez · 1 October 2026 · v1.8.1 (đo lường trong Claude Code; đối chiếu lại với tài liệu của Anthropic vào ngày 1 October 2026)
Tóm tắt trong năm dòng.
- Tổ chức là một cái cây: công ty, mảng nghiệp vụ, dự án, tác vụ. Các project của Claude thì phẳng: cuộc trò chuyện chỉ có một khối tổ chức dài tối đa 3,000 ký tự, các project trong chat và Cowork không lồng nhau hay kế thừa nhau, và trong một project, tài khoản connector thuộc về một cá nhân hoặc toàn bộ tổ chức, chứ không bao giờ thuộc về một nhánh.
- Vì vậy, mỗi project phải nhận một bản sao thủ công các quy tắc của mảng nghiệp vụ, các bản sao này dần lệch pha theo thời gian, và không ai biết được quy tắc nào đã tạo ra câu trả lời.
- Anthropic thực chất đã xây dựng cấu trúc cây này hai lần. Claude Code lồng các instruction theo thư mục, và kể từ ngày 1 October 2026, nó chạy mod của tổ chức trước mod của cá nhân. Claude Tag trên Slack kế thừa instruction và thông tin xác thực từ tổ chức xuống workspace rồi đến channel. Nhưng cả hai đều chưa chạm tới cấp độ project. Cùng một mô hình đó hoàn toàn có thể áp dụng: thêm một lớp mảng nghiệp vụ, các project sinh ra từ chính thư mục của chúng, các tác vụ được định kiểu (typed), một trình biên dịch loại bỏ xung đột trước khi model kịp nhìn thấy chúng, và quyền hạn theo từng nút hoạt động trên gói Team.
- Tôi đã đo lường điều này trong Claude Code, hai lần. Một quy tắc tổ chức và một quy tắc project mâu thuẫn nhau, nằm ở các cấp CLAUDE.md riêng biệt và không bên nào được đánh dấu là bắt buộc: quy tắc project thắng 20/20 lần. Vẫn quy tắc tổ chức đó nhưng được đánh dấu bằng văn bản là bắt buộc thi hành: nó thắng 20/20. Thứ tự ưu tiên được quyết định bởi câu chữ mà bất kỳ ai chỉnh sửa lớp nào cũng có thể thay đổi, chứ không phải bởi cấu trúc.
- Nó đang hoạt động ngay lúc này. Một ứng dụng desktop do tôi phát triển chạy Claude Code bên trong cấu trúc cây. Nó gắn (mount) mỗi lớp thành một file CLAUDE.md, giới hạn những gì Claude được làm tại nút đó cho người dùng, từ chối xung đột ngay khi nó được viết ra, và ghi log mọi câu trả lời kèm theo quy tắc, token và người duyệt. Qua đo lường, cấu trúc cây tải ít hơn 20–34% instruction token so với các bản sao phẳng.
Tổ chức là một cái cây. Công ty ban hành chính sách, mảng nghiệp vụ thiết lập tiêu chuẩn, dự án áp dụng chúng vào một công việc cụ thể, và tác vụ bàn giao một sản phẩm. Mọi hệ thống quản lý chất lượng tôi từng làm việc đều được xây dựng theo cách này, và cây thư mục trên gần như mọi file server của công ty cũng vậy: công ty, mảng nghiệp vụ, năm, sau đó là một thư mục cho mỗi công việc, được đặt tên bằng mã số công việc chứa đựng toàn bộ thông tin đó.
Các dự án AI thì phẳng. Tôi lấy Claude làm ví dụ vì đây là sản phẩm tôi dùng hàng ngày, và vì nó đã hiện thực hóa giải pháp này trên hai bề mặt (surface) của chính mình. Trong chat của Claude, các project không thể lồng nhau, và instruction của tổ chức chỉ là một khối duy nhất tối đa 3,000 ký tự áp dụng cho tất cả mọi người. Trên gói Enterprise, admin có thể phân bổ quyền hạn theo nhóm. Trên gói Team, vai trò áp dụng cho toàn bộ tổ chức. Không có bất kỳ tài liệu nào về chat hay Cowork đề cập đến việc truyền instruction xuống một phòng ban hay mảng nghiệp vụ rồi đi tiếp vào các project của nó. Trên Enterprise, skill và project có thể được chia sẻ cho một nhóm, nhưng đó là phân phối, không phải kế thừa.
Đó chính là lớp còn thiếu: lớp nằm giữa tổ chức và project. Bài viết này sẽ chỉ ra phần còn thiếu là gì, tại sao nó quan trọng, chi phí thực sự của nó là bao nhiêu, và một mô hình tham chiếu mà bất kỳ nền tảng nào cũng có thể triển khai, bao gồm cả quyền hạn và cấu trúc dữ liệu.
1. Những gì đang tồn tại hôm nay
Đối chiếu với tài liệu của Anthropic từ ngày 29 September – 1 October 2026. Claude có bốn bề mặt nơi công việc của một đội ngũ diễn ra, và mỗi bề mặt có một mô hình instruction riêng:
Quyền hạn phụ thuộc vào gói dịch vụ:
Anthropic đã xây dựng được một nửa cấu trúc cây cho quyền hạn. Trên Enterprise, vai trò tùy chỉnh được gán cho các nhóm; “vai trò tùy chỉnh cũng kiểm soát xem một vai trò được dùng connector nào, và công cụ nào trên các connector đó”; xuyên suốt nền tảng, ở các cấp tổ chức, vai trò và người dùng thì “cấp hạn chế nhất sẽ thắng”, trong khi nhiều vai trò của một thành viên sẽ cộng dồn; admin có thể “Xem vai trò hiệu lực” (View effective role) kèm nhãn “Cấp bởi” (Granted by); và các nhóm có thể có hạn mức chi tiêu riêng. Nhưng đây là các nhóm phẳng, không phải một cái cây, và không thứ gì trong số đó chạm tới instruction. Thứ gần nhất là plugin: trên Enterprise, owner có thể đặt một plugin và các skill của nó thành bắt buộc hoặc cài mặc định cho một nhóm, theo một thứ tự được nêu rõ (“thiết lập nhóm, rồi thiết lập toàn tổ chức, rồi mặc định của marketplace”). Điều này nhắm vào một nhóm người, không phải một project, không có gì kế thừa giữa các project, và một skill vẫn chỉ được tải khi Claude thấy nó liên quan. Gói Team có vai trò cho toàn tổ chức và chia sẻ theo từng cá nhân; thiết lập plugin của nó, theo đúng lời tài liệu, là “không có thiết lập nhóm”. Mà Team lại chính là gói được thiết kế cho các công ty vừa và nhỏ.
Anthropic đã xây dựng trọn vẹn cấu trúc cây hai lần, nhưng ở ngoài project.
Trong Claude Code, theo thư mục. Claude Code tải file CLAUDE.md từ bốn cấp độ; “tất cả các file tìm thấy được nối lại thành context thay vì ghi đè lẫn nhau”, sắp xếp “từ gốc hệ thống tệp xuống thư mục làm việc của bạn”, và các file trong thư mục con “tải theo yêu cầu”. Khối của tổ chức có thể đến dưới dạng một file được quản lý trên từng máy hoặc dưới dạng văn bản từ bảng điều khiển admin (khóa claudeMd). Tài liệu nói rất thẳng thắn về giới hạn: Claude coi các file này “như context, không phải cấu hình bắt buộc”, và “nếu hai instruction mâu thuẫn nhau, Claude có thể chọn một cách ngẫu nhiên.”
Trong Claude Tag, theo channel Slack. Claude Tag là Claude hoạt động trong Slack của một đội ngũ, đang public beta trên Team và Enterprise. Thiết lập của nó gắn với một phạm vi (scope), và “scope là nơi một bundle được áp dụng: Quyền truy cập Slack mặc định (gốc toàn tổ chức), một workspace, hoặc một channel duy nhất.” Ba điều mà phần còn lại của bài viết này yêu cầu thì đã có sẵn ở đây:
• Instruction có tính kế thừa. “Các custom instruction theo từng scope được nối lại, Quyền truy cập Slack mặc định trước, rồi đến workspace, rồi đến channel. Instruction của một channel bổ sung vào, chứ không thay thế, những gì được thiết lập ở cấp trên nó.”
• Thông tin xác thực thuộc về nhánh. Trong các channel, Claude hoạt động bằng tài khoản dịch vụ (service account) mà admin gắn vào một scope, và “thông tin xác thực từ scope hẹp nhất sẽ được sử dụng: channel thắng workspace, workspace thắng Quyền truy cập Slack mặc định.”
• Bạn có thể thấy quyền truy cập đến từ đâu. Mỗi dòng connector, repository và plugin đều ghi “Kế thừa từ” (Inherited from) một scope rộng hơn hoặc “Gắn từ” (Attached from) một bundle. Chi tiêu được giới hạn cho cả tổ chức và từng channel, đồng thời được báo cáo theo từng channel.
Các giới hạn cũng được ghi rõ. Cấu trúc cây mang hình dáng của Slack: ba cấp cố định, và channel Slack không lồng nhau. Instruction chỉ là “hướng dẫn, không phải rào chắn bắt buộc”, và tài liệu không mô tả cơ chế kiểm tra xung đột giữa các scope. Cũng “không có log theo từng hành động cho mọi tác vụ và người yêu cầu”. Và nó dừng lại ở rìa của một project: “Các Project trên claude.ai không áp dụng ở đây; Claude không đọc instruction hay knowledge của một Project trong Slack, và một channel không thể trỏ về một Project.”
Những gì thay đổi vào ngày 1 October 2026. Claude Code 2.1.287 đã bật mod, tính năng vốn ở giai đoạn early access: các hàm bên trong một plugin chạy trực tiếp trong Claude Code và có thể viết lại prompt hoặc một phần system prompt, chặn hoặc viết lại lệnh gọi tool, phê duyệt hoặc từ chối yêu cầu cấp quyền, và vẽ các khung hiển thị (pane) trên giao diện. Có ba điều về chúng đáng chú ý ở đây:
• Chúng có thứ tự được khai báo rõ ràng. Guard tích hợp sẵn và mod của tổ chức chạy trước, sau đó mới đến mod do người dùng cài đặt. “Mod đầu tiên nằm ở lớp ngoài cùng: nó thấy sự kiện trước các mod khác và thấy kết quả sau chúng, đồng thời quyết định xem các mod kia có được chạy hay không.” Tại nơi guard được tải (một máy có thiết lập được quản lý, hoặc đăng nhập qua Team hay Enterprise), mod của người dùng không thể thay đổi “system prompt, file CLAUDE.md được quản lý của bạn và các instruction được quản lý khác”, và nó không thể phê duyệt một lệnh gọi tool mà quy tắc từ chối (deny rule) đã chặn. Đó chính là thứ tự ưu tiên được thiết lập bởi cấu trúc, điều mà bài viết này hướng tới. Đây là trạng thái mặc định, không phải khóa cứng: người dùng khởi chạy Claude Code với --safe-mode sẽ chạy mà không có mod nào được cài đặt, kể cả mod của tổ chức, trong khi hook được quản lý và quy tắc từ chối vẫn có hiệu lực.
• Thứ tự này có hai chủ sở hữu. Mod của tổ chức chạy trước mod của người dùng, hoặc chạy sau nếu tổ chức chọn vậy. Không có cấp độ nào dành cho mảng nghiệp vụ. Thiết lập phân phối từ bảng điều khiển admin “áp dụng đồng nhất cho mọi người dùng trong tổ chức. Chưa hỗ trợ cấu hình theo từng nhóm.” Một tổ chức muốn có chính sách khác nhau cho từng nhóm có hai hướng đi, đều phải qua bộ phận IT: triển khai một file thiết lập khác nhau cho máy của từng nhóm, hoặc chạy một gateway self-hosted để “phân phối thiết lập được quản lý theo nhóm IdP”.
• Chúng không chạm tới chat, và tiếp cận Cowork không đồng đều. “Mod hoạt động trong CLI của Claude Code và trong tab Code của ứng dụng Claude Desktop.” Một mod được phân phối qua hooks/hooks.json của plugin, và bảng hỗ trợ plugin của Anthropic đánh dấu file đó là “Bị bỏ qua” (Ignored) trong chat. Cũng bảng đó đánh dấu là “Được tải” (Loads) trong Cowork, vì “Cowork trong ứng dụng Claude Desktop chạy các phiên của nó trên Claude Code”; các trang tài liệu về mod không liệt kê Cowork, và tôi chưa thử nghiệm phần này. Những gì tổ chức kiểm soát được ở đó mỏng hơn: trong một phiên Cowork, Claude Code “không bao giờ tìm nạp thiết lập do server quản lý từ bảng điều khiển admin claude.ai, ngay cả khi người dùng đăng nhập bằng tài khoản Team hoặc Enterprise”, và các phiên Cowork từ xa không có device policy nào để đọc.
Những gì đang được triển khai. Cowork đang sáp nhập vào Claude: trung tâm trợ giúp hiện ghi “Claude Cowork giờ đây chỉ là Claude”, áp dụng cho Pro và Max trước, trong khi Team và Enterprise “giữ nguyên chat và Claude Cowork như hiện tại”. Vào ngày 6 October 2026, các tác vụ Cowork mới trên Pro và Max sẽ chuyển lên cloud. Và một phiên bản project mới đang public beta trên Pro và Max, bắt đầu từ Claude Code, sau đó sẽ đến chat, Cowork, Team và Enterprise; trong đó, “một project là một cuộc hội thoại” được Claude tách thành các luồng song song. Nó vẫn chỉ là một cấp duy nhất: “Một project thuộc về một người dùng”, và “không có kiểm soát cấp tổ chức nào cho project trong giai đoạn beta.”
Vậy nên cấu trúc cây không phải là ý tưởng mới với Anthropic. Nó tồn tại theo thư mục cho code và theo channel cho Slack, và ở cả hai nơi, tổ chức luôn đứng trước. Nơi một công ty lưu trữ công việc của mình — tức project — lại chẳng có nút cha hay tuyến trên nào. Hai dịch vụ khác của Anthropic cũng chỉ về cùng một hướng nhưng nằm ngoài phạm vi bài viết này: Claude for Government phân giải thiết lập qua chuỗi tenant, nhóm và tổ chức, còn Claude Desktop trên các nhà cung cấp bên thứ ba đang beta chính sách theo từng nhóm.
2. Tại sao điều này quan trọng
Project không phải là container. Một công việc thực tế mới là container. Nó có khóa (mã số công việc), nút cha (mảng nghiệp vụ), vòng đời (mở, đóng, lưu trữ theo năm), thư mục, khách hàng, nhân sự, quy tắc và sản phẩm bàn giao. Một project của Claude chỉ có tên dạng văn bản tự do, không khóa, không nút cha, không nút con, và vòng đời được ghi nhận chỉ là lưu trữ và xóa. Cowork có thể gắn một project với thư mục cục bộ, nhưng phải làm thủ công, từng project một, không theo mẫu khóa nào và không có nút cha. Một mảng nghiệp vụ có thể mở hàng trăm công việc mỗi năm. Điều đó để lại hai lựa chọn tồi: hoặc tạo một project Claude thủ công cho mỗi công việc, mỗi cái giữ một bản sao quy tắc riêng; hoặc một project cho cả mảng nghiệp vụ, nơi context của các khách hàng khác nhau nằm cạnh nhau.
Đường truyền tải bị đứt gãy. Trong kỹ thuật kết cấu, mọi tải trọng cần một đường truyền liên tục xuống móng. Rút đi một cấu kiện, mọi thứ phía trên nó không thể truyền xuống dưới. Quy tắc cũng hoạt động y hệt. Khi không có lớp nào giữa tổ chức và project, tiêu chuẩn, template và quy tắc phê duyệt của một mảng nghiệp vụ không có chỗ để tồn tại. Kết quả là mỗi project phải nhận một bản sao thủ công.
Các bản sao dần lệch pha. Sửa một quy tắc ở project này, các project khác vẫn giữ bản cũ. Mỗi project vẫn vượt qua bước kiểm tra nội bộ của riêng nó. Sự sai lệch chỉ lộ ra khi ai đó đặt các project cạnh nhau để so sánh, và trong các ngành có quản lý chặt chẽ, người đó thường là kiểm toán viên. Đội ngũ hạ tầng quá quen với lỗi này. Trong nghiên cứu năm 2026 của Firefly, khoảng một phần ba người tham gia khảo sát gắn tình trạng trôi dạt cấu hình (configuration drift) với các sự cố production tốn kém, và khoảng một phần năm không có quy trình nào để phát hiện hay khắc phục nó.
Danh tính cũng phẳng. Nhiều người làm việc cho hơn một tổ chức, và mỗi nơi cần một context kín riêng. Bên trong bất kỳ tổ chức nào, trên chat và Cowork, tài khoản connector thuộc về một cá nhân, không thuộc về một nhánh. Vai trò trên Enterprise có thể quyết định nhóm nào được dùng connector nào, và admin có thể cấp quyền một connector một lần cho cả tổ chức; một connector tùy chỉnh thậm chí có thể mang một thông tin xác thực dùng chung cho tất cả (đang beta). Dù bằng cách nào, tài khoản đó là của cá nhân hoặc của tổ chức, không bao giờ của một nhánh: một chuyên gia tư vấn phục vụ hai khách hàng không thể gắn Drive của từng khách hàng vào đúng project của khách hàng đó. Project chia sẻ khiến vấn đề gay gắt hơn: “Connector chỉ khả dụng trong các project riêng tư.” Claude Tag chứng minh một thiết kế khác là khả thi, với service account gắn vào một channel Slack, đồng thời cũng cho thấy điểm dừng của nó: tại project. Trang tài liệu về Google connector của Anthropic mô tả một tài khoản Google được kết nối duy nhất, và cách được ghi nhận để thay đổi là ngắt kết nối rồi kết nối lại; ba issue đang mở (bên dưới) yêu cầu hỗ trợ nhiều hơn một tài khoản. Ranh giới nằm trong đầu người dùng, và đó chính xác là loại ranh giới thủ công dễ âm thầm thất bại nhất.
Không ai biết quy tắc nào đã được áp dụng. Claude Enterprise cho admin thấy “Vai trò hiệu lực” về mặt quyền hạn, còn lệnh /context của Claude Code liệt kê các file memory đã được tải. Một mod của Claude Code giờ đây có thể tự vẽ pane của nó, nên góc nhìn instruction hiệu lực là thứ ai cũng có thể xây dựng ở đó. Claude Tag dán nhãn mỗi connector và repository bằng scope mà nó được kế thừa, nhưng với instruction, tài liệu lại bảo hãy “yêu cầu Claude nhắc lại instruction quản trị của nó”. Không bề mặt nào cho biết, với một câu trả lời cụ thể, instruction nào đến từ lớp nào. Không có nguồn gốc thì không có vết kiểm toán, mà không có vết kiểm toán thì không có hệ thống chất lượng.
Mọi người đang yêu cầu từng mảnh của bức tranh này. Các issue đang mở trên trình theo dõi công khai của Anthropic (github.com/anthropics/claude-code), kiểm tra ngày 2026-10-01:
Issue thứ bảy, #47741, yêu cầu một file CLAUDE.md do tổ chức quản lý và đã bị đóng vì Claude Code vốn đã có. Vấn đề nằm ở đó: các lớp này tồn tại trong Code và trong Slack, còn các issue lại đòi hỏi chúng ở chính nơi chứa các project.
3. Chi phí thực sự, và những gì token che giấu
3.1 Token không phải là rào cản
Nhiều lớp hơn có thể đồng nghĩa với nhiều context hơn cho mỗi tin nhắn, mà AI lại tính tiền theo token. Lời giải thích đó chỉ đúng một phần. Trên các gói Enterprise tính phí theo mức dùng, mức dùng được tính theo giá API, nên nhiều context hơn nghĩa là doanh thu cao hơn, không phải thấp hơn. Trên Team, phí theo ghế ngồi là cố định trừ khi bật thêm mức dùng phụ trội, và token phụ trội thể hiện qua việc thành viên chạm ngưỡng giới hạn tuần sớm hơn. Còn Claude Code, tính tiền bằng chính những token đó, đã triển khai cơ chế xếp tầng bốn lớp. Nếu token là rào cản, tính năng này đã không tồn tại. Đo lường ở phần 3.2 cho thấy system prompt và tool của chính Claude Code chiếm khoảng 30,200 token trước khi có bất kỳ instruction nào của chúng ta; toàn bộ instruction của một project chỉ cộng thêm 3.5–5.2% vào con số đó.
3.2 Một ví dụ tính toán cụ thể
Nhãn trên mọi hình ảnh: REAL = đo lường thực tế, hoặc đối chiếu với tài liệu Anthropic, từ 29 September đến 1 October 2026; EST = mô phỏng; IND = minh họa.
Đo lường trước. Tôi chạy cùng một câu hỏi trong Claude Code (claude -p, Claude Sonnet 5.5) trên một project demo, năm lần cho mỗi điều kiện, và lấy số input token do chính Claude Code báo cáo. Tôi chạy trên Claude Code 2.1.286 vào ngày 30 September và lặp lại trên 2.1.287 vào ngày 1 October; số lượng instruction giống hệt nhau. Trừ đi một lần chạy không có instruction project nào, ta được chi phí của từng cách bố trí:
Có hai điều mà phần mô phỏng bên dưới không thể hiện được. Cơ chế xếp tầng tốn thêm 224 token so với file đã biên dịch cho cùng một bộ quy tắc: mỗi file thêm vào đều mang theo chi phí phụ trội, ở đây là marker và tiêu đề riêng của ứng dụng trên file của mỗi lớp, cộng thêm phần khung mà Claude Code bọc quanh mỗi file nó tải. Càng nhiều lớp, chi phí phụ trội càng lớn. Và Claude Code thực tế tải nhiều hơn 21–26% so với ước tính của tokenizer công khai, kể cả khi đã nhân × 1.30; một phần của khoảng chênh lệch đó đến từ chính chi phí phụ trội trên mỗi file. Tỷ lệ phần trăm vẫn đúng, nhưng con số đô la tuyệt đối thì không, nên hãy hiểu các con số đô la trong mô phỏng là mức thấp.
Sau đó mô phỏng ở quy mô công ty. Tôi mô phỏng lượng instruction token trong một tháng cho một công ty minh họa: 40 người thuộc ba mảng nghiệp vụ, 250 project đang hoạt động, sáu loại báo cáo mỗi mảng, 35 tin nhắn mỗi người mỗi ngày làm việc trong các phiên gồm năm tin nhắn, tổng cộng 29,400 tin nhắn. Kích thước token được đếm trên các văn bản instruction mẫu bằng tokenizer legacy công khai của Anthropic (chính Anthropic gọi đây là “ước tính rất sơ bộ” cho Claude 3 trở về sau) và nhân hệ số 1.30 cho tokenizer của Claude 4.7+. Khối tổ chức được ngoại suy từ mẫu 597 ký tự lên giới hạn 3,000 ký tự, còn sổ tay nghiệp vụ gấp ba lần mẫu 953 ký tự. Giá áp dụng là giá niêm yết của Claude Sonnet 5.5 (input $2, ghi cache 5 phút $2.50, đọc cache $0.20 mỗi triệu token). Cache của prompt kéo dài năm phút và được làm mới ở mỗi lần truy xuất.
• Phẳng (cách xử lý tạm thời hiện nay): khối tổ chức, sau đó là bản sao sổ tay nghiệp vụ của riêng từng project, cả sáu template báo cáo và chi tiết riêng của project.
• Cây: tổ chức, mảng nghiệp vụ, chỉ template báo cáo đang được dùng, rồi đến chi tiết của project, biên dịch theo thứ tự lớp được chia sẻ nhiều nhất trước.
Kích thước đằng sau bảng: khối tổ chức 830 token (3,000 ký tự), sổ tay nghiệp vụ 729, một template báo cáo 147, chi tiết project 98 (đã làm tròn; tổng số được tính trước khi làm tròn). Mô phỏng bỏ qua system prompt của chính Claude, nằm trước khối tổ chức.
Hai lưu ý thẳng thắn. Thứ nhất, bản thân cấu trúc cây không tự tiết kiệm token. Mức −29% đến từ tác vụ được định kiểu (typed tasks): chỉ template của báo cáo đang được viết mới được tải, không phải cả sáu. Mức −62% chủ yếu đến từ việc biên dịch các lớp được chia sẻ nhiều nhất trước, nhờ đó hàng trăm project dùng chung một đoạn tiền tố giống nhau từng byte: chỉ riêng việc sắp xếp thứ tự, dù vẫn tải cả sáu template, đã giảm chi phí cache chia sẻ từ $36 xuống $18 (−51%), và tác vụ định kiểu lo phần còn lại. Khoản tiết kiệm thứ hai này chỉ tồn tại nếu cache được chia sẻ giữa các người dùng. Trên Claude API, cache bị cô lập giữa các tổ chức và, trong cùng một tổ chức, theo từng workspace, nên các tiền tố giống nhau được tái sử dụng giữa các request trong cùng workspace; với claude.ai điều này không được ghi nhận. Nó không xảy ra trong bản Claude Code hiện tại: ở đó “cache thực chất chỉ giới hạn trong một máy và một thư mục”, nên hai người ở hai thư mục project khác nhau sẽ trượt cache của nhau. Hãy đọc cột cuối cùng như tiềm năng mà một lớp native trong chat có thể mang lại, không phải thứ đang khả dụng hôm nay. Một phản biện hợp lý: Skill vốn đã tải theo yêu cầu, nên một workspace phẳng chuyển template của nó vào Skill sẽ hưởng được một phần của mức −29% ngay hôm nay. Điều Skill thiếu trong chat và Cowork là phạm vi và tính kế thừa: một skill không thể thuộc về một mảng nghiệp vụ rồi chảy xuống các project của mảng đó. (Trong Claude Code, một skill ở thư mục con thực sự được tải cho các phiên khởi chạy tại đó hoặc sâu hơn.) Thứ hai, đây chỉ là instruction token, và ở quy mô này chúng dao động từ $14 đến $149 mỗi tháng tùy vào cache. Lịch sử hội thoại và output mới là phần chiếm tỷ trọng lớn trong hóa đơn thực tế. Lập luận vững chắc nhất cho cấu trúc cây là tính chính xác và, trên gói Team, là dung lượng. Không phải tờ hóa đơn.
Phần đo lường trên tái tạo hiệu ứng tác vụ định kiểu trên một cấu trúc cây thực tế, trong Claude Code, thay vì dùng kích thước giả định: −20% khi xếp tầng và −34% khi biên dịch, so với mức −29% của mô phỏng. Một mảng nghiệp vụ chỉ có một loại tác vụ sẽ không tiết kiệm được gì từ tác vụ định kiểu.
3.3 Cùng một câu trả lời, từ Claude thực tế
Tôi hỏi Claude Code cùng một câu hỏi bốn mươi lần: mười câu trả lời độc lập cho mỗi điều kiện trong bốn điều kiện, chia thành hai đợt mỗi đợt năm lần cách nhau một ngày. Câu hỏi là liệu một phép thử độ chặt hiện trường trên nền đất subgrade có đạt hay không, ở mức 112.3 pcf so với độ chặt khô lớn nhất 115.8 pcf với yêu cầu 98%. Instruction đưa vào là sáu quy tắc của công ty hoặc một prompt “trợ lý hữu ích” một dòng, và ngôn ngữ là tiếng Anh hoặc tiếng Tây Ban Nha. Cả bốn mươi câu trả lời đều ra cùng một phán quyết: 97.0%, không đạt.
Claude Code báo cáo hai con số output: số token bị tính phí, và bao nhiêu trong số đó là phần suy nghĩ (thinking) mà người đọc không bao giờ thấy.
Bốn phát hiện:
• Quy tắc của công ty làm câu trả lời dài gấp 1.4 lần trên màn hình, và gấp 1.8–1.9 lần trên hóa đơn. Phần dài thêm hiển thị là các mục cờ cảnh báo, tiêu chuẩn và giới hạn mà quy tắc yêu cầu. Trong một hệ thống chất lượng, đó mới là phần giá trị.
• Dưới quy tắc của công ty, hơn một phần ba output bị tính phí là vô hình. 37% output token bị tính phí là phần thinking, so với 16% khi dùng prompt trơn. Với tiếng Anh, người đọc thấy 447 token nhưng trả tiền cho 711 token.
• Tiếng Tây Ban Nha tốn gấp 1.2 lần số token hiển thị của tiếng Anh cho các câu trả lời có độ dài tính theo từ chênh lệch nhau dưới 4%. Đo cùng phương pháp, quy tắc của công ty ngốn gấp 1.53 lần input token khi được viết bằng tiếng Tây Ban Nha.
• Cùng một phán quyết bị tính phí từ 317 đến 953 token, câu trả lời dài nhất tốn gấp ba lần câu ngắn nhất. Cách tính tiền theo token không phân biệt được sự chặt chẽ với phần viết cho dài ra. Tiêu chí nghiệm thu thì có thể.
Các tỷ lệ này dao động giữa hai đợt năm lần. Tỷ lệ trên màn hình với quy tắc công ty là 1.43–1.52 ở đợt đầu và 1.27–1.31 ở đợt hai; tỷ lệ tính phí là 1.78–1.82 rồi 1.70–2.05; tỷ lệ tiếng Tây Ban Nha là 1.29–1.38 rồi 1.14–1.18. Chiều hướng không hề thay đổi. Độ lớn chỉ đáng tin cậy ở một chữ số có nghĩa.
Phương pháp: Claude Code 2.1.286 vào ngày 2026-09-30 và 2.1.287 vào ngày 2026-10-01, claude -p --output-format json, Claude Sonnet 5.5. Mọi tool đều bị cấm và các file ~/.claude cá nhân bị loại trừ, nên chỉ có instruction được nêu là khác biệt giữa các điều kiện. Số lượng token lấy từ báo cáo mức dùng của chính Claude Code, bao gồm thinking_tokens; chi phí tháng áp dụng mức $10 mỗi triệu output token của Sonnet 5.5 cho giá trị trung bình bị tính phí. Script đo lường, cả hai đợt, các số liệu gộp và mọi câu trả lời được tác giả lưu giữ và cung cấp khi có yêu cầu. Phiên bản đầu tiên của bài viết này ước tính các con số bằng subagent và tokenizer công khai; những ước tính đó đã được thay thế.
3.4 Khi quy tắc xung đột, câu chữ sẽ quyết định
Tài liệu của Anthropic thừa nhận rằng các instruction mâu thuẫn có thể được giải quyết “một cách ngẫu nhiên”. Tôi đã thử nghiệm một xung đột điển hình mà việc thiếu lớp mảng nghiệp vụ gây ra. Quy tắc tổ chức yêu cầu dùng hệ đo lường Mỹ; quy tắc project yêu cầu báo cáo độ chặt theo hệ SI. Tôi đặt chúng đúng như cách một cấu trúc cây sẽ làm: quy tắc tổ chức trong file CLAUDE.md ở gốc lưu trữ, quy tắc project trong file CLAUDE.md ở thư mục project, cả hai được tải bởi chính cơ chế xếp tầng của Claude Code. Sau đó tôi chạy cùng thiết lập với quy tắc tổ chức được đánh dấu là bắt buộc thi hành, chỉ bằng câu chữ: thẻ ENFORCED trong nhãn và một câu thêm vào, “Quy tắc này được thi hành bắt buộc: không quy tắc mảng nghiệp vụ hay project nào được phép ghi đè nó.” Mỗi thiết lập chạy mười lần vào ngày 30 September và mười lần nữa vào ngày 1 October.
Nó không hề ngẫu nhiên. Khi không có gì được khai báo, Claude luôn chọn quy tắc gần hơn, cụ thể hơn. Mười bốn trong hai mươi câu trả lời giải thích lý do (“quy tắc đó cụ thể hơn quy tắc hệ đo lường Mỹ toàn công ty”, hoặc nó ghi đè quy tắc công ty); năm câu chỉ viện dẫn quy tắc project và không hề nhắc đến việc quy tắc công ty đang mâu thuẫn. Khi tính bắt buộc được tuyên bố bằng câu chữ, quy tắc tổ chức thắng mọi lần, và mọi câu trả lời đều nói rằng quy tắc công ty được thi hành bắt buộc đã chiếm quyền ưu tiên. Đợt thứ hai tái tạo chính xác đơn vị đo, 10/10 lần ở mỗi thiết lập, và khác biệt giữa hai hàng vượt xa yếu tố ngẫu nhiên (kiểm định chính xác Fisher, p < 0.0001). Phần giải thích kém ổn định hơn: chín trên mười câu trả lời giải thích được vì sao quy tắc project thắng ở đợt đầu, nhưng chỉ năm trên mười ở đợt hai.
Đó là tin tốt cho mô hình nhưng lại là tin xấu cho không gian làm việc. Tính ưu tiên (precedence) có tồn tại, nhưng nó nằm trong câu chữ của các quy tắc — thứ mà bất kỳ ai chỉnh sửa ở lớp nào cũng có thể thay đổi, và chẳng ai xem xét như một quyết định về độ ưu tiên cả. Và khi quy tắc cấp dưới thắng, một phần tư số câu trả lời không hề báo cho người đọc biết rằng có một quy tắc cấp cao hơn đã bị gạt sang một bên. Một thử nghiệm sơ bộ ở phiên bản đầu tiên của bài viết này, với cả hai quy tắc đặt chung trong một prompt thay vì xếp tầng, cũng cho kết quả thay đổi khi chỉ cần đảo ngược thứ tự của chúng (quy tắc tổ chức đứng trước: SI 5/5; quy tắc tổ chức đứng cuối: SI 2/5, và 3/5 trường hợp đưa ra cả hai đơn vị hoặc hỏi ngược lại xem nên áp dụng cái nào).
Không nên bắt bất kỳ mô hình nào phải phân xử một xung đột mà lẽ ra tổ chức đã có thể chặn lại ngay từ lúc viết quy tắc. Claude Code có hai giải pháp chưa trọn vẹn. Lệnh /doctor prompt-audit yêu cầu Claude tìm các tệp hướng dẫn mâu thuẫn với nhau, khi có người chạy lệnh đó. Và kể từ ngày 1 tháng 10, một mod có thể ép buộc thứ tự bằng code: mod của tổ chức chạy trước mod của cá nhân, và khi lớp bảo vệ tích hợp sẵn được tải lên, quy tắc deny sẽ đè lên mod của cá nhân. Cả hai đều không bao quát được phần văn bản hướng dẫn. Các tệp hướng dẫn vẫn được nối chuỗi lại với nhau, và tài liệu mô tả kết quả theo ba cách: Claude “có thể chọn bừa một cái”; khi quy tắc người dùng và quy tắc dự án xung đột, “Claude có thể tuân theo một trong hai”; và “khi các hướng dẫn xung đột, Claude sẽ tự phán đoán để dung hòa chúng.” Kết quả hai mươi trên hai mươi chính là minh chứng cho việc sự phán đoán đó diễn ra thế nào ở đây. Claude Tag tuyên bố một thứ tự cho ba phạm vi (scope) của nó, và gọi kết quả đó là “hướng dẫn, chứ không phải rào cản bắt buộc”. Phần kiểm tra trong bản triển khai tham chiếu sẽ từ chối chính xác kiểu thay đổi này, “R-22 sets units.density=SI; R-01 (org:firm) enforces US”, trước khi bất cứ thứ gì kịp đến tay Claude, và enforced là một trường dữ liệu trong quy tắc, chứ không phải một câu văn nằm trong đó.
Mật độ hướng dẫn càng làm vấn đề trầm trọng hơn. Trong benchmark IFScale (2025), độ chính xác của Claude Sonnet 4 giảm từ 100% ở 10 hướng dẫn đồng thời xuống còn 42.9% ở 500 hướng dẫn.
3.5 Dùng compute hay năng lượng có công bằng hơn không?
Token là đại diện hợp lý cho compute trong cùng một mô hình: nhiều token hơn thực sự là nhiều việc hơn cho phần cứng. Đó cũng là lý do vì sao giá dựa trên compute hay năng lượng sẽ không khắc phục được mức phạt ngôn ngữ. Tiếng Tây Ban Nha tốn kém hơn vì tokenizer nén nó ít hơn, và những token dư ra đó là compute thật. Cách khắc phục là một tokenizer tốt hơn, hoặc đo lường đã chuẩn hóa theo nội dung.
Một đơn vị compute được chuẩn hóa vẫn hữu ích theo ba cách. Nó giúp so sánh được giữa các mô hình và nhà cung cấp khác nhau. Nó mang tính vật lý và có thể báo cáo được, ví dụ như cho báo cáo phát triển bền vững. Và nếu hệ số được cố định theo một phần cứng tham chiếu, nhà cung cấp sẽ giữ lại được phần hiệu suất họ cải thiện, tạo ra động lực đúng đắn. Đã có tiền lệ: các nhà cung cấp đám mây từng bán những đơn vị chuẩn hóa như EC2 Compute Unit.
Nhưng nó cũng có vấn đề thực tế. Khách hàng không thể xác minh nếu thiếu tiêu chuẩn và bên kiểm toán. Năng lượng thực tế phụ thuộc vào phần cứng, hiệu suất trung tâm dữ liệu, cơ chế batching và lưới điện. Anthropic cũng không công bố mức năng lượng cho mỗi request; tôi chỉ tìm thấy các ước tính từ bên thứ ba. Quan trọng nhất, compute vẫn chỉ là đầu vào. Nó không cho biết câu trả lời có đúng hay không.
Kết luận của tôi là cần ba lớp riêng biệt:
- Tính phí bằng token hoặc một đơn vị compute chuẩn hóa.
- Công khai mức năng lượng cho mỗi tác vụ và mỗi node.
- Quản lý theo chi phí trên mỗi kết quả đã được xác minh.
Với gói Team, bước tối thiểu là công bố giới hạn hàng tuần bằng một đơn vị cụ thể. Hạn mức mỗi phiên hiện được ghi là “gấp 1.25 lần hạn mức sử dụng mỗi phiên của gói Pro”; còn giới hạn hàng tuần thì hoàn toàn không có con số nào được công bố. Chẳng thể lập ngân sách với cả hai thông tin này.
Như FinOps Foundation từng nói, “token là đơn vị tính phí, không phải đơn vị giá trị.” Hệ thống phân cấp mới là thứ giúp định nghĩa được giá trị, bởi đó là nơi tiêu chí nghiệm thu có thể tồn tại.
3.6 Những lý do khả dĩ hơn khiến nó chưa được xây dựng
- Độ ưu tiên ngầm. Chính tài liệu của Anthropic cũng thừa nhận rằng các hướng dẫn mâu thuẫn trực tiếp có thể tạo ra hành vi khác nhau, và mục 3.4 cho thấy độ ưu tiên phụ thuộc vào câu chữ của quy tắc. Xếp chồng nhiều lớp sẽ nhân lên số xung đột, và khả năng tuân thủ hướng dẫn suy giảm theo mật độ: trong benchmark IFScale (2025), ngay cả những mô hình tốt nhất được thử nghiệm cũng chỉ đạt 68% độ chính xác với 500 hướng dẫn từ khóa đồng thời (benchmark được trích dẫn ở mục 3.4).
- Kế thừa quyền hạn. Nếu kiến thức kế thừa xuống theo cây, quyền truy cập cũng phải kế thừa. Điều đó nghĩa là phải xây lại mô hình phân quyền dưới mỗi lớp.
- Ưu tiên bộ nhớ và truy xuất hơn là các lớp tĩnh.
- Sự đơn giản lấy người dùng phổ thông làm gốc. Các công cụ code mặc nhiên có sẵn cấu trúc cây từ hệ thống tệp. Còn sản phẩm chat thì phải tự nghĩ ra một cấu trúc.
Anthropic chưa từng công khai lý do vì sao chat Claude và Cowork thiếu hệ thống phân cấp. Mọi thứ trong mục này đều là suy luận từ những gì đã được phát hành.
4. Mô hình tham chiếu
Thiết kế này vay mượn từ những hệ thống đã giải quyết xong bài toán tương tự: phân cấp tài nguyên đám mây (AWS Organizations, Google Cloud Org Policy, Azure management groups), chính sách thư mục (Active Directory Group Policy), và chính cơ chế xếp tầng CLAUDE.md của Claude Code. Mối quan hệ giữa các node được mô tả bằng năm từ: contains (chứa), inherits (kế thừa), uses (sử dụng), sealed (niêm phong) và shared (chia sẻ).
4.1 Gắn (mount) chính cấu trúc cây mà tổ chức đang có
Đừng bắt mọi người xây lại tổ chức của mình bên trong không gian làm việc AI. Máy chủ tệp hoặc hệ thống tài liệu vốn đã là nguồn dữ liệu chuẩn (source of truth). Hãy đi theo một đường dẫn:
Mã công việc 26GT301 vốn đã mã hóa cấu trúc cây: năm, lĩnh vực hoạt động, số thứ tự. Không gian làm việc nên gắn (mount) cấu trúc này, chứ không phải sao chép nó.
4.2 Node chứa quy tắc, node nhóm, dự án và tác vụ
• Node chứa quy tắc: tổ chức, lĩnh vực hoạt động, dự án, tác vụ. Mỗi node mang theo ba thứ giống nhau: context (ngữ cảnh gồm hướng dẫn và kiến thức), policy (chính sách quy định công cụ, dữ liệu và connector nào được phép), và identities (danh tính gồm các tài khoản connector được gán vào đó).
• Node nhóm: chuỗi dự án, năm, khu vực. Chúng không chứa quy tắc nào. Chúng tồn tại để điều hướng, lưu trữ và quản lý vòng đời. Việc tách riêng giúp cây quy tắc nông hơn, chỉ ba đến bốn cấp, đúng như khuyến nghị của chính Microsoft dành cho management group (“không quá ba đến bốn cấp”).
• Dự án là một container có khóa (keyed). Nó được tạo tự động: khi xuất hiện một thư mục khớp với mẫu khóa của lĩnh vực (ví dụ {YY}GT{NNN}_{Name} nằm dưới thư mục gốc của lĩnh vực đó), một node dự án sẽ được tạo ra, kế thừa từ lĩnh vực của nó, và nhận quyền truy cập connector chỉ giới hạn trong thư mục đó. Nó chỉ chứa những gì khác biệt so với lĩnh vực: thành viên, khách hàng, đặc tả kỹ thuật. Nó chuyển trạng thái từ mở sang đóng rồi sang lưu trữ (Sơ đồ 2).
• Tác vụ được định kiểu. Kiểu của nó lấy từ danh mục của lĩnh vực (một báo cáo mật độ, một nhật ký khoan). Kiểu tác vụ mang theo một template và tiêu chí nghiệm thu. Đầu ra được lưu trở lại thư mục dự án theo quy tắc đặt tên của công ty, và một người duyệt sẽ nghiệm thu nó. Skills là thứ gần nhất với kiểu tác vụ mà Claude có hiện nay. Trên bản Enterprise, chúng có thể được chia sẻ cho một nhóm, nhưng đó là phân phối, không phải kế thừa: không có gì chảy xuống nhánh dưới cả.
Tính đệ quy ở đây là có chủ đích. Mô hình Hệ thống Khả thi (Viable System Model) của Stafford Beer nói thẳng điều này: “Trong một cấu trúc tổ chức đệ quy, bất kỳ hệ thống khả thi nào cũng chứa, và được chứa trong, một hệ thống khả thi khác.”
4.3 Một node cha chính, cộng thêm các lớp phủ (overlay)
Christopher Alexander lập luận vào năm 1965 rằng “một thành phố không phải là cái cây.” Các cấu trúc thực tế luôn chồng lấn lên nhau. Một khách hàng, một đặc tả của cơ quan quản lý hay một kiểu tác vụ có thể trải dài qua nhiều lĩnh vực hoạt động. Vì vậy, mỗi node có một node cha chính, và các tập quy tắc cắt ngang được gắn vào dưới dạng lớp phủ (uses). Xung đột luôn được giải quyết theo một cách: deny thắng, nếu không thì node gần nhất thắng.
4.4 Hai kênh, hai ngữ nghĩa
Đây là cốt lõi của thiết kế, và cũng là nơi hầu hết các hệ thống phân cấp mắc sai lầm.
• Context được nối chuỗi. Hướng dẫn và kiến thức được gộp từ gốc xuống ngọn, giống cách CLAUDE.md hoạt động.
• Policy mặc định là deny. Một công cụ hay connector chỉ được phép dùng nếu có rule allow xuyên suốt toàn bộ đường dẫn từ gốc, và một rule deny rõ ràng ở bất kỳ đâu phía trên đều sẽ thắng, giống AWS Service Control Policies. Node cha có thể đánh dấu một quy tắc là enforced, và không node con nào được chặn nó, y như Group Policy.
Trộn lẫn hai thứ này là sai lầm kinh điển. Ngữ cảnh mang tính tham khảo thì nên hòa trộn. Còn quy tắc bắt buộc thực thi thì không.
4.5 Biên dịch trước khi mô hình đọc
Hiện nay, các hướng dẫn xung đột được mô hình giải quyết ngay lúc tạo câu trả lời. Giải pháp là một trình biên dịch hướng dẫn hiệu lực (effective-instructions compiler) chạy trước khi mô hình nhìn thấy bất cứ thứ gì:
- Gộp context từ gốc đến ngọn.
- Áp dụng policy: deny thắng, và allow phải tồn tại trên toàn bộ đường dẫn.
- Tuân thủ các quy tắc enforced từ node cha.
- Đóng dấu mỗi quy tắc bằng một ID và lớp của nó.
- Sắp xếp khối nội dung theo mức độ chia sẻ rộng rãi của từng phần, và áp hạn mức token cho mỗi lớp.
Xung đột không bao giờ lọt được đến bước này: chúng đã bị từ chối sớm hơn, ngay khi quy tắc được viết, và người phê duyệt phải là người khác chứ không phải tác giả (Sơ đồ 3, luồng dưới).
Vì xung đột được giải quyết ở thời điểm biên dịch, đầu ra có thể sắp xếp theo mức độ chia sẻ rộng rãi của từng phần, thay vì sắp xếp cứng nhắc theo độ sâu: tổ chức, lĩnh vực, template kiểu tác vụ, rồi mới đến chi tiết dự án. Thứ tự đó tối đa hóa tỷ lệ cache hit (mục 3.2). Nó khớp với bốn điểm ngắt cache (cache breakpoint) của Anthropic, kèm hạn mức token cho mỗi lớp, dù trên thực tế có thể cần dành một điểm ngắt cho chính cuộc hội thoại.
4.6 Danh tính gắn với nhánh, không gắn với người
Danh tính connector (tài khoản, tenant, scope) được gắn vào node, không gắn vào người. Claude Tag đã hoạt động theo cách này với các kênh Slack: admin gắn một service account vào một scope, và credential của scope hẹp nhất sẽ thắng. Mô hình ở đây đòi hỏi điều tương tự nhưng lùi xuống một cấp, ở lĩnh vực hoạt động và các dự án của nó. Một người làm việc ở hai tổ chức sẽ có hai cây niêm phong; họ chuyển đổi giữa các cây, chứ không chuyển tài khoản. Không có gì lọt qua giữa hai cây trừ khi chủ sở hữu của cả hai chủ động chia sẻ. Nguyên thủy kỹ thuật cho việc này đã có sẵn: đặc tả ủy quyền MCP sử dụng OAuth token gắn với audience (RFC 8707 resource indicators, RFC 9728 protected resource metadata) và yêu cầu máy chủ “KHÔNG ĐƯỢC chấp nhận hoặc chuyển tiếp bất kỳ token nào khác” (phiên bản đặc tả 2026-07-28).
4.7 Quyền hạn đi theo cây
Chủ thể (Principal): người, nhóm, service account, khách mời bên ngoài (ví dụ khách hàng), và chính agent.
Agent không bao giờ vượt quá quyền của người dùng hay của node. Claude hành động với quyền của người dùng gọi nó, giao với policy của node. Nó không thể tự đổi quy tắc hay quyền hạn; nó chỉ có thể đề xuất thay đổi. (Hiện tại, Claude có thể tự cập nhật hướng dẫn thư mục Cowork. Trong mô hình này, việc đó trở thành một đề xuất cần người phê duyệt.)
Đánh giá quyền. Quyền chỉ chảy xuống dưới, không bao giờ đi lên hay đi ngang. Quyền hiệu lực tại một node là những gì các role trên đường dẫn của nó cấp, nằm trong giới hạn policy cho phép trên toàn bộ đường dẫn, trừ đi mọi rule deny ở phía trên. Lớp phủ chỉ cấp quyền truy cập vào nội dung của chính nó: đọc một bản đặc tả không có nghĩa là mở khóa các dự án đang dùng bản đặc tả đó.
Vòng đời.
• Mở (Open): role được áp dụng như đã cấp.
• Đóng (Closed): không thêm tác vụ mới, nhưng các lượt duyệt đang chờ có thể hoàn tất.
• Lưu trữ (Archived): chỉ đọc với tất cả mọi người; chỉ chủ sở hữu mới khôi phục được, và thao tác khôi phục được ghi log.
• Cây niêm phong (Sealed tree): không có gì lọt qua nếu không được chia sẻ rõ ràng.
Ngoại lệ và ủy quyền. Ngoại lệ phải có thời hạn, có lý do, và người phê duyệt phải khác người yêu cầu. Chúng tự hết hạn và được đếm lại, vì mỗi lần ghi đè là một “ốc đảo” bảo trì vĩnh viễn; giới hạn broken-inheritance của SharePoint là bài học nhãn tiền. Ủy quyền không bao giờ được cấp nhiều hơn những gì người ủy quyền đang có. Quyền break-glass của chủ sở hữu có tồn tại, luôn được ghi log và được rà soát sau đó.
Trên gói Team, cơ chế này hoạt động mà không cần nhóm: quyền được gắn trên node, nên một tổ chức có bốn role vẫn có được quyền hạn theo từng nhánh.
4.8 Các lớp tương tác với nhau thế nào
Một cấu trúc cây chỉ đáng xây nếu các thay đổi truyền qua được nó. Ba kiểu tương tác gánh phần lớn công việc (Sơ đồ 5):
• Đẩy xuống (Push down). Trưởng lĩnh vực phát hành phiên bản mới của một quy tắc. Mọi dự án trong lĩnh vực đó sẽ đọc nó ở lần biên dịch tiếp theo. Một ngoại lệ đã được duyệt sẽ giữ lại phiên bản cũ cho đến khi hết hạn, và các tài liệu đã lưu vẫn giữ nguyên phiên bản lúc chúng được tạo ra.
• Kéo lên (Pull up). Một thành viên cải thiện template trong một dự án và đề xuất nó. Trưởng lĩnh vực, chứ không phải người đề xuất, sẽ phê duyệt, và các dự án anh em sẽ kế thừa nó. Hiện tại, cải tiến đó chỉ nằm lại trong dự án nơi nó sinh ra.
• Chéo (Across). Đặc tả của cơ quan quản lý thay đổi một lần. Các dự án ở ba lĩnh vực sẽ biên dịch lại với nó, còn bản thân các lĩnh vực không đổi. Xung đột với quy tắc của lĩnh vực sẽ bị từ chối ngay khi bản cập nhật được viết.
Một request duy nhất phô bày tất cả các lớp cùng lúc (Sơ đồ 6): cây kiểm tra quyền của thành viên và trạng thái dự án, trình biên dịch dựng khối nội dung, Claude đọc dữ liệu trường qua một danh tính giới hạn trong thư mục của dự án đó, lưu tài liệu đã định kiểu trở lại thư mục, và một người duyệt (không phải người viết ra nó) sẽ nghiệm thu. Mọi bước đều nằm trong log, và chi phí được tính vào mã dự án.
4.9 Cấu trúc dữ liệu
Việc cấp phát (provisioning) được kích hoạt bằng sự kiện: một thư mục mới khớp với key_pattern nằm dưới storage_root của lĩnh vực sẽ tạo ra node dự án. answer_log cung cấp nguồn gốc cho mọi câu trả lời và chi phí cho từng node.
4.10 Đo lường kết quả, không đo token
Mỗi kiểu tác vụ mang theo tiêu chí nghiệm thu: định nghĩa về sự hoàn thành. Khi đã có chúng, ta đo lường được một đơn vị công việc AI tốt hơn:
chi phí trên mỗi kết quả đã xác minh = (chi phí token + thời gian duyệt) ÷ số sản phẩm được nghiệm thu
Vì mọi câu trả lời đều được ghi log theo node, chi phí AI có thể tính vào mã dự án giống hệt cách tính nhân công và vật tư. Vài mảnh ghép của việc này đã có: Claude Tag báo cáo và giới hạn chi tiêu theo kênh, còn telemetry của Claude Code có thể được gắn thẻ thủ công theo phòng ban, cost center hoặc repository. Nhưng không cái nào gắn với mã dự án, và không cái nào chia cho số sản phẩm được nghiệm thu. Với một công ty tính phí theo mã công việc, AI trở thành chi phí trực tiếp của công việc thay vì chi phí chung. Trong ngành kỹ thuật, bạn trả tiền cho sản phẩm đã được kiểm tra và niêm phong, chứ không trả cho ngòi bút chì. Công việc AI cũng nên được đo lường theo cách đó.
4.11 Giải đáp các ý kiến phản bác
“Skills và plugin đã làm được việc này rồi.” Một skill được tải khi Claude thấy nó liên quan, tức là dựa trên độ phù hợp, không phải sự đảm bảo. Việc cấp phát đưa skill đến tất cả mọi người; trên bản Enterprise, một plugin mang skill đó có thể bị bắt buộc áp dụng cho một nhóm. Đó là thứ gần nhất với khái niệm “lĩnh vực hoạt động” trong chat và Cowork hiện nay, nhưng nó hụt hơi ở ba điểm: chỉ dành cho Enterprise, nhắm vào con người chứ không phải dự án, và không có gì chảy từ lĩnh vực xuống các dự án của nó. Một quy tắc bắt buộc luôn áp dụng trong một lĩnh vực không thể phụ thuộc vào việc phát hiện độ phù hợp.
“Mods đã làm được việc này rồi.” Trong Claude Code thì đúng một phần, kể từ ngày 1 tháng 10 năm 2026. Một mod có thể viết lại system prompt, từ chối một tool call và vẽ một panel, và mod của tổ chức chạy trước mod của cá nhân. Vậy nên trình biên dịch, bước kiểm tra lúc viết và giao diện hướng dẫn hiệu lực trong bài viết này hoàn toàn có thể dựng thành một mod ngay hôm nay, và mục 6 cũng nói rõ điều đó. Nhưng vẫn còn ba giới hạn. Mod không chạy trong chat Claude, và trong Cowork thì cài đặt console của tổ chức không có tác dụng. Thứ tự của chúng có hai chủ sở hữu, tổ chức và cá nhân, mà không có lớp lĩnh vực hoạt động nào ở giữa; trên bản Enterprise, một plugin bắt buộc với một nhóm có thể mang mod đến nhóm đó, nhưng nó chạy như một trong các mod của cá nhân, không có độ ưu tiên. Và mod là code không được sandbox: để chạy trước mod của người dùng, mod của tổ chức phải nằm trong một thư mục trên từng máy, còn cài đặt đẩy từ admin console thì “không thể đặt thư mục lên máy”. Một công ty không có hệ thống quản lý thiết bị vẫn có thể đẩy mod đến mọi người, nhưng nó sẽ chạy lẫn lộn giữa các mod của người dùng, chứ không chạy trước họ. Một công ty không đáng phải viết TypeScript chỉ để nói rằng một phòng ban dùng đơn vị báo cáo khác.
“Memory sẽ tự học các quy tắc.” Memory chủ yếu do Claude viết, cho một người hoặc một dự án, và chủ sở hữu không thể đọc hay sửa memory của thành viên. Kiểm toán viên cần những quy tắc do con người viết, có phiên bản, được phê duyệt và truy vết được tới từng câu trả lời. Anthropic đã làm điều đó ba lần rồi: cho quyền hạn, với “View effective role” và nhãn “Granted by”; cho skill và plugin, với lịch sử phiên bản và bước duyệt mà “bạn không thể tự duyệt của mình”; và cho quyền truy cập của Claude Tag, với nhãn “Inherited from”. Còn hướng dẫn trong dự án thì không có cả ba.
“Claude Tag đã làm được việc này rồi.” Với các kênh Slack thì phần lớn là đúng, và mục 1 đã nói vậy. Nhưng vẫn thiếu ba thứ. Kênh không phải là dự án: nó không có thư mục, không có mã khóa, không có vòng đời, và “một kênh không thể trỏ đến một Project”. Cây chỉ có ba cấp cố định, nên một công ty có các lĩnh vực hoạt động và hàng trăm công việc phải ép phẳng hai cấp thành tên kênh. Và tài liệu không mô tả bước kiểm tra xung đột nào khi viết hướng dẫn; các scope được nối chuỗi và mô hình bị bỏ mặc tự dung hòa chúng. Nếu có gì đáng nói, Claude Tag chính là bằng chứng mạnh nhất ủng hộ thiết kế trong bài viết này: cùng một công ty đã chọn cơ chế kế thừa, credential gắn với scope và nhãn nguồn gốc khi họ xây dựng cho đội nhóm.
“Phân cấp làm tăng độ phức tạp.” Chỉ khi độ sâu của nó không giới hạn. Chính khuyến nghị của Microsoft cho management group là “không quá ba đến bốn cấp”. Mô hình này chốt cứng bốn cấp chứa quy tắc, còn các thư mục nhóm như chuỗi dự án và năm thì không mang quy tắc nào.
“Kế thừa là rủi ro bảo mật.” Đúng vậy, nếu quyền truy cập được kế thừa cẩu thả. Câu trả lời từ đám mây vẫn áp dụng được: phải có allow ở mọi cấp, deny ở bất kỳ đâu đều thắng, Claude hành động với tư cách người dùng giao với node, và chính việc sửa quy tắc của Claude cũng biến thành đề xuất.
“Nhiều lớp hơn tốn nhiều token hơn.” Mục 3.2 đã đo được điều ngược lại trong Claude Code: ít hơn 20% token hướng dẫn khi xếp tầng, ít hơn 34% khi biên dịch, so với việc sao chép phẳng. Mỗi tệp thêm vào đúng là có chút overhead, nên biên dịch tốt hơn xếp tầng. Tác vụ định kiểu sẽ loại bỏ các template không dùng đến, và phần prefix đã biên dịch giống nhau từng byte giữa các dự án, nên prompt caching có thể tái sử dụng chúng. Trên Claude API, cache được cô lập theo workspace, nên mỗi tổ chức một workspace sẽ khớp với gốc của cây. Claude Code hiện chưa có điều này: cache của nó chỉ giới hạn trong một máy và một thư mục.
“Các team cứ tự quản lý dự án của mình là được.” Đó là cách chữa cháy hiện tại, và bản prototype ở mục 5 đã đo xem nó tạo ra gì: hai trên sáu bản sao chép dán bị lỗi thời trong một demo nhỏ.
5. Chạy được ngay hôm nay: bản triển khai tham chiếu
Để chứng minh mô hình này xây được thật, chứ không chỉ cãi lý thuyết, tôi đã xây Worktree, một ứng dụng desktop nhỏ (Node và Electron, 24 test đạt trên Windows và Linux) có bố cục giống Claude Desktop. Video ở trên là một lần chạy thực tế, chỉ bị cắt ngắn ở những đoạn Claude đang xử lý. Đây là một ứng dụng riêng biệt điều khiển Claude Code từ bên ngoài, không phải mod. Nó không tự gọi mô hình nào. Mọi cuộc chat đều chạy trên Claude Code đã cài sẵn trong máy (claude -p), dùng chính tài khoản đăng nhập của Claude Code đó: gói subscription Claude hoặc API key. Tôi chạy thử trên một công ty giả định có ba lĩnh vực hoạt động và sáu dự án. Khi ai đó gửi tin nhắn:
• Cấp quyền (Permit). Người thực hiện cần có quyền trên dự án hoặc cấp cao hơn, và dự án phải đang mở. Một admin không có quyền trên lĩnh vực đã bị chặn lại trước khi Claude kịp khởi chạy.
• Kiểm tra (Check). Bước kiểm tra lúc viết chạy trước. Quy tắc SI ở mục 3.4 bị từ chối vì xung đột với quy tắc enforced của công ty, nên nó không bao giờ lọt được vào CLAUDE.md.
• Gắn (Mount). Cây được ghi vào các thư mục dự án thực tế dưới dạng mỗi cấp một tệp CLAUDE.md (tổ chức ở storage root, rồi đến lĩnh vực, rồi đến dự án), và cơ chế xếp tầng của chính Claude Code sẽ tải chúng. Chế độ biên dịch thì chỉ ghi một tệp cho mỗi dự án. Các tệp không có marker của ứng dụng sẽ không bao giờ bị ghi đè.
• Chạy (Run). Template tác vụ được đưa vào --append-system-prompt-file. Những gì Claude được phép làm do Claude Code ép buộc, không phải CLAUDE.md: --allowedTools là role của người dùng giao với policy của mọi cấp, thao tác ghi bị giới hạn trong thư mục dự án, và --permission-mode dontAsk từ chối mọi thứ khác. Trong các lần chạy thực tế, một lệnh tìm kiếm web đã bị từ chối vì policy của lĩnh vực không cho phép dùng web, và một thao tác ghi ngoài thư mục dự án bị chặn rồi ghi log.
• Log và duyệt. Mọi câu trả lời đều được ghi log kèm người thực hiện, node, mọi tag quy tắc, các quy tắc Claude đã trích dẫn, cùng số token input, cache và output mà Claude Code báo cáo. Một người duyệt không phải tác giả sẽ nghiệm thu hoặc trả lại nó. Một lần chạy báo cáo mật độ thực tế trên bản demo mất khoảng 30 giây; qua ba lần chạy, Claude Code báo mức $0.08–0.22 cho mỗi câu trả lời theo giá niêm yết. Claude trích dẫn các quy tắc nó áp dụng, đánh dấu những kết quả sát ngưỡng nghiệm thu, và để trống các trường của kỹ sư.
• Độ lệch (Drift). Mọi tệp CLAUDE.md đã gắn đều được so với cây, và các chỉnh sửa thủ công bị đánh dấu. Một bản prototype dòng lệnh trước đó chạy phép so sánh tương tự trên các bản sao chép dán vào dự án phẳng và phát hiện hai trên sáu bản bị lỗi thời: một bản vẫn kẹt ở R-07 v3, và một bản có quy tắc bị xóa tay.
Ba phát hiện từ quá trình xây dựng, đều hữu ích cho bất kỳ ai đang xếp lớp hướng dẫn trên Claude Code:
- Hướng dẫn cá nhân của bạn lọt vào các lần chạy của tổ chức. Mặc định, mọi lần chạy đều tải thêm ~/.claude/CLAUDE.md, rules, agents và MCP server cá nhân của tôi. Ứng dụng hiện đã loại chúng bằng cài đặt claudeMdExcludes, cộng thêm --strict-mcp-config. Trên máy tôi, việc đó kéo context của một lần chạy từ 29.6k xuống 21.4k token. Lựa chọn thay thế hiển nhiên, --setting-sources project,local, lại làm ngược những gì cần thiết trong Claude Code 2.1.284 trên Windows: nó giữ lại tệp cá nhân và bỏ luôn các tệp CLAUDE.md ở thư mục cha vốn mang theo tổ chức và lĩnh vực.
- Mod của cá nhân cũng lọt vào. Mod ra mắt một ngày sau khi ứng dụng được xây xong, nên tôi đã thử nghiệm. Tôi cài một mod một hook trong scope người dùng của mình để thêm một dòng vào mọi prompt. Nó lọt được vào các lần chạy của ứng dụng: ba quy tắc của tổ chức được tải, dòng cá nhân của tôi cũng vậy, và câu trả lời tuân theo nó. Thêm disableAllHooks vào cài đặt của lần chạy đã chặn được nó và giữ nguyên ba cấp CLAUDE.md; ứng dụng hiện đang làm vậy. --safe-mode không thay thế được: nó xóa luôn mod và kéo theo cả chuỗi xếp tầng CLAUDE.md. Theo tài liệu, disableAllHooks trong cài đặt cá nhân sẽ giữ lại những gì tổ chức quản lý.
- CLAUDE.md là context, còn enforcement là configuration. Tài liệu của Anthropic nói rõ: “Quy tắc cài đặt được client ép buộc bất kể Claude quyết định làm gì. Hướng dẫn trong CLAUDE.md định hình hành vi của Claude nhưng không phải lớp ép buộc cứng.” Ứng dụng phụ thuộc vào điều đó. Mọi thứ quy tắc phải đảm bảo đều được ánh xạ thành quyền công cụ; mọi thứ trong CLAUDE.md chỉ là hướng dẫn kèm tag.
Nó hoạt động trên Claude Code hiện tại, và văn bản đã biên dịch có thể dán vào chat hoặc phần hướng dẫn của dự án Cowork trên bất kỳ gói nào. Có một dependency cần lưu ý về thời gian: ứng dụng dựa vào việc claude -p tải các tệp CLAUDE.md, nhưng tài liệu của Anthropic nói rằng --bare (bỏ qua các tệp này) “sẽ trở thành mặc định cho -p trong bản phát hành tương lai”. Khi điều đó xảy ra, ứng dụng sẽ phải truyền cây theo cách khác; chế độ biên dịch và --append-system-prompt-file hiện đã làm được. Đây là một bản đặc tả đang hoạt động cho phiên bản native, không phải ranh giới bảo mật: “acting as” là một công tắc demo, không phải bước đăng nhập.
6. Lộ trình từ những gì đã phát hành
Ngay bây giờ, trong Claude Code. Kể từ ngày 1 tháng 10, cây phân cấp này có thể được triển khai dưới dạng một mod: biên dịch các quy tắc của node thành một phần của system prompt, chặn các lệnh gọi tool mà chính sách của node không cho phép, và hiển thị tập chỉ thị đang thực sự áp dụng trong một bảng điều khiển. Một tổ chức có thể chạy mod đó trước bất kỳ thứ gì mà cá nhân người dùng cài đặt. Tôi chưa xây dựng tính năng này; nó là mục đầu tiên trên lộ trình của bản triển khai tham chiếu. Nó sẽ bao phủ Claude Code, và có thể cả các phiên Cowork trên máy của người dùng vì chúng chạy trên cùng một engine. Nhưng nó sẽ không bao phủ chat.
Phiên bản 30 ngày, dành cho chat và Cowork. Anthropic đã có sẵn các mảnh ghép. Hãy cho phép một project chỉ định một project cha để kế thừa chỉ thị, giống như cách một kênh Slack kế thừa từ workspace của nó trong Claude Tag. Biên dịch hai lớp này theo đúng thứ tự, gắn tag cho từng quy tắc, và thêm bảng “Xem chỉ thị đang áp dụng” bên cạnh mục “Xem vai trò đang áp dụng” hiện có. Chỉ riêng điều đó đã giúp mọi lĩnh vực công việc có một nơi duy nhất để lưu trữ quy tắc của mình.
Sau bước đó, mỗi bước tiếp theo đều hữu ích khi đứng độc lập, bắt đầu từ những gì hỗ trợ gói Team:
- Các node theo lĩnh vực công việc và cấp phát key-pattern, tái sử dụng ngữ nghĩa CLAUDE.md vốn đã hoạt động tốt trong code. Ngay trong Claude Code, bước đối sánh (matching) đóng vai trò là một tầng trung gian cho nhóm, nằm giữa các mod của tổ chức và của cá nhân, cùng với các thiết lập được quản lý theo từng nhóm.
- Các loại tác vụ (task type) dưới dạng kỹ năng được giới hạn trong một lĩnh vực, kèm theo tiêu chí nghiệm thu.
- Kiểm tra xung đột tại thời điểm ghi, để các mâu thuẫn bị cây phân cấp từ chối thay vì phải chờ model đứng ra phân xử.
- Cấp quyền trên các node, hoạt động trên gói Team mà không cần nhóm, đồng thời mở rộng các vai trò tùy chỉnh của gói Enterprise.
- Định danh connector gắn với branch cho các project, giống như cách Claude Tag đã gắn một service account vào một kênh Slack.
- Hạch toán theo từng node lấy project làm khóa, tương tự cách Claude Tag đã báo cáo theo từng kênh; một hạn mức hàng tuần được công bố bằng đơn vị cụ thể; và minh bạch mức tiêu hao năng lượng cho từng tác vụ.
7. Hạn chế
• Phạm vi bao phủ. Vào ngày 1 tháng 10 năm 2026, toàn bộ chỉ mục trang của code.claude.com/docs và claude.com/docs đã được phân loại theo tiêu đề (466 trang) và khoảng 150 trang đã được đọc kỹ, cùng với các bài viết trung tâm trợ giúp được trích dẫn ở đây. Các phiên bản trước của bài viết này đã bỏ sót hoàn toàn Claude Tag; phiên bản này cũng có thể bỏ sót một điều gì đó khác. Claude for Government và Claude Desktop trên các nhà cung cấp bên thứ ba có được nhắc đến nhưng không đi sâu phân tích.
• Các tính năng nền tảng thay đổi hàng tháng, và có một tính năng đã thay đổi ngay trong lúc bài viết này đang được soạn. Mọi nhận định về sản phẩm ở đây đều được chốt trong khoảng 29 tháng 9 – 1 tháng 10 năm 2026 và bạn nên kiểm tra lại trước khi dựa vào đó. Mod mới chỉ ra mắt được một ngày; tôi đã đọc tài liệu của chúng và thử nghiệm một trường hợp, chứ chưa dùng trong môi trường production.
• Các con số đo lường trong phần 3.1–3.4 lấy từ chính báo cáo sử dụng của Claude Code, chia làm hai đợt: Claude Code 2.1.286 vào ngày 2026-09-30 và 2.1.287 vào ngày 2026-10-01, cả hai đều chạy trên Claude Sonnet 5.5. Tác giả lưu giữ script, cả hai đợt dữ liệu và mọi câu trả lời, có thể cung cấp khi được yêu cầu. Chúng bao gồm cả prompt nội tại của Claude Code (khoảng 30.200 token) mà claude.ai và Cowork không dùng chung, và chỉ bao quát một model, một project demo cùng một câu hỏi. Cỡ mẫu khá nhỏ: mười câu trả lời cho mỗi điều kiện khi đo độ dài, hai mươi câu cho mỗi điều kiện khi kiểm tra xung đột. Tỷ lệ độ dài câu trả lời có sự xê dịch giữa hai đợt (phần 3.3); hai đợt cách nhau một ngày còn khác biệt về phiên bản Claude Code, và tôi không thể tách bạch yếu tố đó khỏi sự ngẫu nhiên.
• Thời gian chạy, chi phí và kích thước context trong phần 5 lấy từ nhật ký câu trả lời của ứng dụng qua ba lần chạy demo và một bài test cô lập thủ công — đây là ghi chép của riêng tác giả.
• Các câu trả lời kiểm tra xung đột do chính tác giả mã hóa, không che giấu thông tin, bằng cách đọc từng câu trả lời (các đơn vị được báo cáo; câu trả lời có nêu rõ quy tắc nào thắng và tại sao không; nó có đặt câu hỏi ngược lại không). Toàn bộ bốn mươi câu trả lời có thể được cung cấp khi yêu cầu để mã hóa lại. Bài test chỉ dùng một cách diễn đạt của từ “enforced”; các cách diễn đạt, model và cặp quy tắc khác có thể cho kết quả khác.
• Bài test mod trong phần 5 chỉ gồm một mod với một hook, trên một máy Linux, dùng Claude Haiku, đăng nhập bằng tài khoản có gói thuê bao và không có thiết lập được quản lý nào. Tôi chưa test mod chính sách của tổ chức, lớp bảo vệ tích hợp sẵn khi đăng nhập gói Team hay Enterprise, hoặc ứng dụng Desktop.
• Mô hình chi phí trong phần 3.2 là mô phỏng cho một công ty mang tính minh họa, không phải số liệu thanh toán thực tế. Nó chỉ tính token chỉ thị; trong thực tế, lịch sử hội thoại, output và thinking thường chiếm phần lớn hóa đơn. Kích thước token dùng tokenizer legacy công khai của Anthropic × 1.30; khi đo thực tế, Claude Code nạp nhiều hơn ước tính đó 21–26%, nên các con số đô la đưa ra đang thấp hơn thực tế. Các tỷ lệ phần trăm là tỷ số nên vẫn giữ nguyên giá trị. Mô thức phiên và việc chia sẻ cache chỉ là giả định.
• Việc sử dụng chat trên gói Enterprise có được hưởng giá cache API hay không, và cache có được chia sẻ giữa các người dùng trên claude.ai hay không, đều chưa được ghi nhận trong tài liệu. Cowork chạy các phiên của nó trên Claude Code và hook plugin được nạp tại đó, nhưng các trang tài liệu về mod không liệt kê Cowork và tôi cũng chưa test; vào ngày 1 tháng 10, ứng dụng desktop vẫn đóng gói Claude Code 2.1.286, tức một phiên bản trước khi mod được bật. Chính sách được quản lý của thiết bị sẽ áp dụng lên các phiên Cowork trên máy người dùng, trừ khi tổ chức chạy chúng trong sandbox VM hoàn chỉnh. Có hai trang tài liệu nói trái ngược nhau về việc các file ~/.claude của cá nhân người dùng có ảnh hưởng tới Cowork hay không, nên bài viết này không khẳng định theo hướng nào. Tôi cũng chưa test xem các file CLAUDE.md ở thư mục cha có được nạp trong phiên Cowork không; nếu có, thì cây phân cấp được mount của bản triển khai tham chiếu đã có thể áp dụng cho Cowork trên máy người dùng ngay hôm nay. Trên gói Pro và Max, khoảng trống này sẽ hẹp lại vào ngày 6 tháng 10 năm 2026, khi các tác vụ Cowork mới chuyển lên cloud.
• Các động cơ đều là suy luận. Anthropic chưa công khai giải thích vì sao chat và Cowork của Claude lại có cấu trúc phẳng.
• Code và dữ liệu thô không được công bố kèm bài viết này. Người đọc không thể tự tái tạo các phép đo chỉ từ bài viết; video cho thấy ứng dụng hoạt động, chứ không chỉ ra cách nó được xây dựng.
• Bản triển khai tham chiếu chạy trên một công ty giả định. Nó không tích hợp với claude.ai hay Cowork, và “acting as” chỉ là một công tắc demo, không phải thao tác đăng nhập. Quyền hạn được thực thi qua danh sách tool của Claude Code, chứ không phải bởi ứng dụng. Tính năng cô lập (isolation) sẽ tắt các hook và mod cá nhân của người dùng trong lần chạy đó; các mod tích hợp sẵn trong Claude Code vẫn tiếp tục chạy, và tên của các agent cá nhân vẫn có thể xuất hiện trong context. Ứng dụng phụ thuộc vào việc claude -p nạp CLAUDE.md, điều mà Anthropic cho biết sẽ không còn là hành vi mặc định. Lỗ rò rỉ file cá nhân và kết quả của --setting-sources được test trên Windows; các phép đo và bài test mod được chạy trên Linux.
Nguồn tham khảo
• Anthropic, Thiết lập chỉ thị cho tổ chức
• Anthropic, Vai trò và quyền hạn
• Anthropic, Gói Team là gì? · Các gói và mức giá
• Anthropic, Quản lý vai trò tùy chỉnh trên gói Enterprise
• Anthropic, Tổ chức tác vụ của bạn bằng project trong Claude Cowork
• Anthropic, Sử dụng connector Google Workspace
• Anthropic, Quản lý nhóm và hạn mức chi tiêu của nhóm trên gói Enterprise
• Anthropic, Project là gì? (phiên bản mới của project, beta)
• Anthropic, Bắt đầu với Claude Cowork (chỉ thị toàn cục và theo thư mục)
• Anthropic, Cách Claude ghi nhớ project của bạn (CLAUDE.md) · Toàn bộ thiết lập (claudeMdExcludes, disableAllHooks)
• Anthropic, Tùy chỉnh Claude Code bằng mod (ngày 1 tháng 10 năm 2026) · Tổng quan về mod · Quản lý mod cho tổ chức của bạn · Phản hồi sự kiện bằng mod · Tài liệu tham khảo về mod
• Anthropic, Claude Tag: Claude Tag là gì? · Cấu hình quyền truy cập theo từng kênh · Tùy chỉnh Claude Tag · Cách định danh agent hoạt động · Kiểm tra nhật ký · Thiết lập hạn mức chi tiêu
• Anthropic, Project trong Claude Code (beta project mới) · Project trong Cowork · Cách Claude Code sử dụng prompt caching · Chạy Claude Code bằng code (--bare) · Mở rộng Claude Code · Quản lý khả năng hiển thị và chia sẻ project · Sử dụng connector · Cấp quyền connector MCP cho toàn bộ tổ chức · Cấp phát và quản lý skill
• Anthropic, Cấu hình thiết lập do server quản lý (không có cấu hình theo từng nhóm) · Quản lý plugin cho tổ chức của bạn (khả dụng plugin theo nhóm trên Enterprise) · Hỗ trợ tính năng plugin trên các nền tảng (hook bị bỏ qua trong chat, được nạp trong Cowork) · Triển khai thiết lập được quản lý (Cowork chạy các phiên của nó trên Claude Code)
• Anthropic, Mức giá (mức giá Sonnet 5.5, ghi chú về tokenizer) · Prompt caching (cache được cô lập theo từng tổ chức và từng workspace trên API)
• Anthropic, @anthropic-ai/tokenizer (tokenizer công khai được dùng để đếm)
• Microsoft, Nhóm quản lý · Thiết kế nhóm quản lý landing-zone
• AWS, Đánh giá SCP · Google Cloud, Đánh giá phân cấp
• Microsoft, Xử lý Group Policy · Quyền chi tiết trong SharePoint
• FinOps Foundation, Kinh tế học token
• Jaroslawicz và cộng sự, LLM có thể tuân theo bao nhiêu chỉ thị cùng lúc? (IFScale)
• Firefly, Nghiên cứu Thực trạng IaC 2026
• MCP, Đặc tả cấp quyền, phiên bản 2026-07-28
• GitHub, anthropics/claude-code issues #68262, #14467, #30554, #27567, #30250, #27302, #47741
• Beer, S. (1979), The Heart of Enterprise; Alexander, C. (1965), “A City is Not a Tree,” Architectural Forum; Simon, H. (1962), “The Architecture of Complexity,” Proc. Am. Phil. Soc.106(6)
• Bản triển khai tham chiếu và dữ liệu: ứng dụng Worktree, các bài test của nó, script đo lường, cả hai đợt kết quả và mọi câu trả lời đều do tác giả lưu giữ và có thể cung cấp khi được yêu cầu.
