LarkBase khi agent cũng là người dùng: thiết kế schema, quyền và workflow cho cả người lẫn agent

TL;DR: Cho tới nay, LarkBase vẫn được thiết kế cho một loại người dùng: con người. Từ nay trở đi sẽ có loại thứ hai — agent đọc và ghi qua API, MCP hoặc lark-cli. Agent không nhìn bảng bằng con mắt; nó đọc cấu trúc: tên field, kiểu dữ liệu, option. Bài này chia cách tự thiết kế LarkBase cho cả người lẫn agent hôm nay — không chờ tính năng mới: schema tự giải thích, phân quyền bot hẹp hơn quyền người, view và audit riêng cho agent, và lớp phê duyệt bắt buộc khi agent muốn đổi dữ liệu nhạy cảm.

1. LarkBase đang có người dùng thứ hai

Nếu bạn đã từng nối AI vào hệ thống của mình — dù qua MCP, lark-cli, hay một workflow n8n tự viết — thì Base của bạn đã có người dùng không phải người. Nó đọc danh sách field, tự đoán ý nghĩa từng cột, rồi quyết định ghi gì vào đâu. Mọi chỗ nó phải "đoán" là một chỗ nó có thể đoán sai.

Hãng đang đi đúng hướng đó. Tại hội nghị Feishu Future 2026, Base (多维表格) được giới thiệu là "lớp dữ liệu chung cho con người và Agent" — agent thao tác phía trước, Base giữ dữ liệu có cấu trúc phía sau (mốc 01:04–01:12 của bản ghi lại). Changelog chính thức (đọc ngày 17/09/2026): bản V7.73 (27/07) thêm agent nội bộ cho từng Base, bản V8.0 (07/09) cho app Base nhúng agent luôn bên trong.

Tính năng được công bố tại sự kiện Feishu (thị trường Trung Quốc) ngày 15/09/2026; chưa kiểm chứng tính sẵn có trên LarkSuite quốc tế và tại Việt Nam.

Đó là định hướng sản phẩm. Nhưng bạn không cần chờ nó tới Việt Nam để bắt đầu, vì phần lớn việc không nằm ở tính năng — nó nằm ở cách Base của bạn được thiết kế. Một Base schema lộn xộn thì agent nhúng sẵn vào app cũng vô ích; một Base thiết kế đúng thì nối agent bằng MCP hay lark-cli hôm nay vẫn chạy tốt. Bài này đi theo con đường thứ hai: bốn lớp tự dựng — schema, phân quyền, view + audit, workflow phê duyệt. Bối cảnh lớn hơn vì sao dữ liệu có cấu trúc không mất đi trong thời agent đã bàn ở CRM không biến mất, nó xuống tầng nền; còn các đường nối agent vào Lark thì tổng hợp ở bài kiểm chứng MCP, lark-cli và Workmates.

2. Schema cho agent đọc: viết cho người đọc không biết ngôn ngữ của bạn

Người mới vào công ty đọc bảng và hỏi lại khi không hiểu. Agent thì tự điền khoảng trống bằng phỏng đoán. Vậy nguyên tắc thiết kế schema rất đơn giản: mọi thứ agent cần biết phải nằm ngay trong cấu trúc, không nằm trong trí nhớ của người già.

Đây là kinh nghiệm triển khai của chúng tôi — ghi nhận định tính, không phải con số đo được:

Tên field tự giải thích. trang_thai_don_hang thay cho st. Không viết tắt nội bộ, không tên field mô tả công dụng hôm nay nhưng sai nghĩa sau ba tháng (col_backup_2 là tội danh thường gặp). Người đọc nhanh hơn, agent đọc đúng hơn — một chỉnh sửa phục vụ cả hai.

Single-select thay text tự do cho trạng thái. Text tự do là nơi một sự thật sinh ra nhiều mặt: "đã gửi", "Đã gửi", "send rồi", "ok". Người đọc hiểu cả ba là một; agent lọc theo điều kiện thì nhận ba giá trị khác nhau. Single-select ép dữ liệu về đúng một tập đóng, agent lọc và nhắc việc theo đó mới chính xác.

Bảng tra thay giá trị mã nghĩa. Đừng nhét tên khách, số điện thoại, người phụ trách vào một ô text của từng dòng đơn hàng. Tách bảng khach_hang, để bảng đơn hàng link sang — agent tra thông tin qua quan hệ thay vì parse chuỗi tự do. Đây cũng là nguyên tắc cũ của người làm dữ liệu; agent chỉ khiến vi phạm nó tốn hại hơn trước.

Bộ ba field nền của mỗi bảng nghiệp vụ: trang_thai (single-select), nguoi_phu_trach (person), moc_thoi_gian (date). Có đủ bộ ba này, agent mới nhắc đúng việc cho đúng người vào đúng lúc — và người quản lý cũng dò được tiến độ mà không mở họp.

Đặt tên không dấu, snake_case. Field tiếng Việt có dấu vẫn chạy, nhưng khi viết prompt, filter API hay script đồng bộ, tên không dấu đỡ hỏng hơn. Chọn quy ước một lần rồi giữ cho cả Base.

Nếu Base hiện có của bạn lệch nhiều so với các điểm trên, đừng vội mời agent vào — rà và làm sạch chất lượng dữ liệu LarkBase là một dự án nhỏ đáng làm trước.

3. Phân quyền: agent đọc nhiều, ghi ít, không đụng cấu trúc

Agent kết nối vào Lark bằng danh tính app/bot, và quyền của nó theo app scope — không theo quyền của người tạo ra nó. Đây là điểm hay bị hiểu nhầm nhất: nhân sự phụ trách vận hành có thể xem mọi đơn hàng, nhưng không có nghĩa cái bot do nhân sự đó dựng được phép như vậy.

Nguyên tắc chúng tôi đặt ra khi triển khai:

Scope của agent phải hẹp hơn quyền hẹp nhất trong nhóm người mà nó hỗ trợ. Mẫu câu ngắn để nhớ: agent đọc nhiều, ghi ít, đổi cấu trúc thì không.

• Đọc nhiều: chọn đúng những bảng agent cần cho tác vụ của nó, không cấp cả Base "cho chắc".
• Ghi ít: giới hạn ghi vào ít bảng, tốt nhất là bảng "vùng đệm" (kết quả agent ghi vào đây, người hoặc workflow kiểm rồi mới chuyển sang bảng gốc).
• Không đổi cấu trúc: thêm field, đổi kiểu field, xoá bảng là những thao tác phá view, formula và automation của người. API có cho phép thì agent cũng không nên có quyền này.

Một lưu ý vận hành khi dùng CLI: chạy --as bot thì audit thấy tên app, quyền theo app scope; chạy --as user thì thấy tên người, quyền theo người — bài kiểm chứng lark-cli đã bàn chi tiết. Chốt danh tính ngay từ đầu, đừng để mặc định.

Thú vị là phía nhà cung cấp đang đi cùng hướng: Feishu 8.0 công bố nguyên tắc "agent của nhân viên không được vượt quá quyền của người đó", kèm kiểm soát công cụ và vô hiệu hoá agent — đúng tinh thần scope hẹp, chỉ được đóng gói thành tính năng sản phẩm (kèm ranh giới Feishu ≠ Lark như đã ghi ở mục 1; phân tích sâu hơn ở bài 7 lớp kiểm soát agent). Bạn không cần chờ: hôm nay đã tự thực hiện được bằng app scope.

4. View và audit: cho agent làm việc trong làn đường riêng

View riêng cho từng tác vụ agent. Thay vì để agent "tự hiểu" cả bảng, tạo view lọc đúng phạm vi nó cần: "đơn chờ nhắc hôm nay", "phiếu chờ duyệt", "khách chưa ai chăm trong hai tuần". View đóng vai hai chiều: agent nhận đúng dữ liệu tác vụ, người có một chỗ nhìn ngay nó đang xử lý gì.

Audit bằng modified by cộng bảng log phụ. Field modified by cho biết record cuối ai sửa — người hay app. Nhưng với hành động agent đáng kể (đổi trạng thái, ghi kết quả, tạo phiếu nhắc), chúng tôi thêm một bảng log phụ: thoi_gian, ten_agent, hanh_dong, lien_ket_ban_ghi, ket_qua, nguoi_duyet. Khi có sự cố, đây là chỗ trả lời được câu "agent đã làm gì hôm qua" — câu hỏi mà bảy lớp kiểm soát agent gọi là audit log. Không cần công cụ đắt tiền; chỉ cần kỷ luật ghi.

5. Khi agent muốn đổi dữ liệu nhạy cảm: phê duyệt, không ghi thẳng

Phân loại hành động của agent thành ba mức:

Cơ chế cho mức ba: agent soạn nội dung thay đổi (field nào, giá trị cũ, giá trị mới, lý do) rồi gửi phiếu phê duyệt — qua Lark Approval hoặc một record "chờ duyệt" trong Base. Người duyệt bấm một lần, workflow mới thực hiện ghi thật. Agent không giữ quyền ghi trực tiếp vào vùng nhạy cảm.

Mẫu này là phiên bản tự dựng của mô hình "agent thao tác phía trước, dữ liệu có cấu trúc phía sau" mà demo hội nghị trình bày — chỉ khác là dựng bằng công cụ có sẵn. Nó cũng là lớp approval trong 7 lớp kiểm soát khi doanh nghiệp chạy nhiều agent, và là ranh giới ở bài khi nào KHÔNG cho agent tự hành động. Nếu cần đồng bộ kết quả ra nơi khác để báo cáo, luồng Base ↔ Sheet bằng AnyCross ghép vào đây tự nhiên: chỉ chạy sau khi phiếu được duyệt.

6. Ba phản-dạng cần tránh

Nhét mọi thứ vào một bảng "cho agent dễ đọc". Nghe hợp lý nhưng ngược lại: bảng dày cột khiến người lẫn agent đều choáng. Agent đọc tốt bảng được tổ chức, không phải bảng phẳng. Chia bảng đúng chuẩn, link quan hệ — như mục 2.

Để agent ghi thẳng bảng tài chính, kho, lương không qua duyệt. Dù workflow chạy đúng chín lần, lần sai thứ mười không có người chặn là sự cố thật với dữ liệu thật. Mức ba ở mục 5 tồn tại vì lý do này.

Dùng chat lưu trạng thái. "Đã báo khách trong nhóm rồi" — thông tin nằm trong chat thì agent không đọc tin cậy được, và chính bạn cũng khó truy lại sau sáu tháng. Chat là giao diện trao đổi; trạng thái nằm trong Base — ranh giới này càng quan trọng khi người và agent cùng làm việc qua chat như ở chat là command center.

7. Demo: bảng CRM minh hoạ cho cả người lẫn agent

Tình huống minh hoạ — không phải case khách hàng, chỉ để bạn thấy đủ các mảnh ghép trên trong một thiết kế cụ thể. Ba bảng:

Bảng khach_hang (chỉ người ghi; agent chỉ đọc):

Bảng don_hang (người ghi; agent ghi có kiểm soát qua vùng đệm):

Bảng nhat_ky_agent (chỉ agent ghi; người đọc):

Vận hành mẫu: mỗi sáng, agent đọc view "đơn sắp đến moc_giao_du_kien trong 3 ngày", gửi nhắc qua IM cho nguoi_phu_trach, ghi vào nhat_ky_agent. Muốn đổi trang_thai_don_hang sang huỷ — hành động nhạy cảm — agent chỉ được tạo phiếu phê duyệt; người duyệt xong thì luồng tự ghi. Mọi bước đều có vết.

Đó là toàn bộ kiến trúc: schema tự giải thích, quyền hẹp, view + log, phê duyệt. Không chờ tính năng mới nào.

Kết

"Lớp dữ liệu chung cho con người và Agent" không phải khoá chức năng sẽ mở vào một ngày đẹp trời — đó là kỷ luật thiết kế bắt đầu từ hôm nay: tên field tự giải thích, single-select thay text tự do, quyền bot hẹp hơn quyền người, view riêng cho tác vụ, bảng log cho hành động agent, phiếu phê duyệt trước mọi thay đổi nhạy cảm. Làm tốt bốn lớp này, bạn nối agent vào bằng MCP, lark-cli hay n8n đều chỉ còn là chi tiết kỹ thuật — và khi tính năng agent-native sang LarkSuite quốc tế, hệ thống của bạn đón được ngay chứ không phải dở lại từ đầu.

Đang chọn nền tảng cho hệ dữ liệu đó? So sánh LarkBase và 1Office theo bài toán và trải nghiệm tự tạo field bằng automation là hai điểm khởi đầu tốt. Muốn bàn thẳng vào Base hiện có của bạn — dịch vụ LarkSuite của Diginno bắt đầu từ một buổi rà schema.