Đóng khung agent trước khi mở tool

Đóng khung agent trước khi mở tool

Agent production không hỏng vì thiếu model xịn. Nó hỏng vì tool, quyền, dữ liệu và người duyệt chưa được đóng khung rõ ràng.

9 giờ 12 phút sáng, Mai bên marketing ops nhắn vào group dev: agent trả lời audience A nên được ưu tiên, nhưng dashboard hôm qua lại nói audience B. Cả team im vài giây. Không ai biết agent đã gọi tool nào, dùng dataset nào, quyền của ai, và có lẫn campaign cũ không.

Đây là kiểu khoảnh khắc làm mình tỉnh ngủ nhanh hơn cà phê. Không phải vì agent ngu. Mà vì team đã cho nó cầm quá nhiều đục, trong khi bản vẽ mộng gỗ còn chưa chốt.

Luận điểm của bài này: agent production chỉ đáng tin khi orchestration và guardrail được thiết kế như một phần của sản phẩm, không phải lớp vá sau demo. Cái mới nhất, ồn ào nhất, hay nhiều tool nhất chưa chắc là lựa chọn đúng. Với builder, câu hỏi nên đổi từ agent gọi được gì? sang agent được phép làm gì, trong trạng thái nào, với bằng chứng nào?

Sơ đồ minh họa cho bài Đóng khung agent trước khi mở tool

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

Cảnh của Mai: một agent marketing tưởng dễ mà không dễ

Team của Mai muốn làm một assistant nội bộ cho campaign planning. Người dùng hỏi bằng ngôn ngữ tự nhiên:

Mô hình tích hợp kiểu Amazon Quick với Adobe Marketing Agent cho thấy một hướng khá thực tế: chat layer nhận câu hỏi, orchestration chọn action đã được duyệt, MCP server kiểm tra request rồi truy vấn dữ liệu marketing có thẩm quyền. MCP — Model Context Protocol, hiểu ngắn là giao thức để agent khám phá và gọi tool theo cách có cấu trúc — ở đây không phải đồ trang trí. Nó là đường ray để assistant biết tool nào tồn tại, input schema ra sao, và action nào được phép đăng ký.

Nói thẳng ra thì, phần đáng học không nằm ở chuyện marketer hỏi được bằng tiếng người. Phần đáng học là luồng này có governance: least privilege là cấp quyền tối thiểu cần dùng, tenant isolation là tách dữ liệu giữa các tenant hoặc nhóm khách hàng, audit logging là ghi lại ai hỏi gì và tool nào được gọi, schema versioning là quản lý phiên bản cấu trúc dữ liệu, còn human review là bước người thật duyệt trước quyết định nhạy cảm như launch campaign.

Nếu bỏ các lớp đó, bạn không xây agent. Bạn đang dựng một ô chat biết bấm lung tung vào hệ thống nội bộ.

Playbook: khung 4 thanh trước khi nối tool

Trước khi team bạn cắm thêm tool thứ mười một, thử đóng khung agent bằng 4 thanh này. Mình gọi vui là I-A-D-R: Intent, Action, Data, Review.

| Thanh khung | Câu hỏi phải trả lời | Nếu bỏ qua sẽ sao |
|---|---|---|
| Intent | Người dùng đang muốn biết, quyết định, hay thực thi? | Agent trả lời như tư vấn nhưng người dùng hiểu là lệnh hành động |
| Action | Tool nào được gọi, với input nào, trong điều kiện nào? | Tool calling biến thành bốc thăm |
| Data | Dữ liệu nào được phép dùng, version nào, scope nào? | Kết quả đúng cú pháp nhưng sai bối cảnh |
| Review | Khi nào cần người duyệt trước khi tạo tác động thật? | Demo đẹp, production run thì run rẩy |

Tool calling — khả năng model gọi API hoặc công cụ thay vì chỉ trả lời chữ — là nơi nhiều team phấn khích quá đà. Nhưng tool chỉ là lưỡi đục. Không có khung, đục càng sắc càng dễ làm hỏng mặt gỗ.

Ví dụ cụ thể: Mai hỏi agent: Có nên đẩy campaign loyalty cho nhóm khách hàng X tuần này không?
Agent không nên nhảy thẳng sang tạo campaign. Nó nên phân loại intent trước:

intent: decision_support
actions_allowed:
  - rank_audiences
  - summarize_loyalty_segments
  - check_journey_conflicts
actions_blocked:
  - launch_campaign
  - modify_budget
review_required: true
answer_must_include:
  - data_source
  - time_range
  - confidence_note
  - recommended_next_step

Đọc hơi khô, nhưng đây là khác biệt giữa assistant nội bộ và một chatbot thích phiêu lưu.

Làm trong một buổi: dựng bản nháp orchestration map

Bạn không cần rewrite toàn bộ stack. Một buổi chiều là đủ để phát hiện agent của mình đang hở chỗ nào.

Bước 1: Liệt kê 5 intent thật nhất

Đừng bắt đầu từ tool. Bắt đầu từ câu người dùng hay hỏi.

1. Hỏi số liệu: campaign nào đang tốt?
2. So sánh: audience A hay B đáng ưu tiên?
3. Chẩn đoán: vì sao journey tụt performance?
4. Cảnh báo: có conflict trước launch không?
5. Hành động: tạo ticket, draft plan, hoặc đề xuất thay đổi budget

Với mỗi intent, ghi rõ output mong muốn: answer, table, chart, recommendation, hay draft action. Amazon Quick + Adobe Marketing Agent gợi ý một điểm hay: cùng là câu trả lời, nhưng có lúc nên render thành bảng, có lúc là chart, có lúc là recommendation. UI cũng là guardrail, vì nó quyết định người dùng hiểu kết quả theo kiểu tham khảo hay hành động.

Bước 2: Gắn action vào intent, không gắn vào cảm hứng của model

Orchestration — cách điều phối nhiều bước, nhiều tool hoặc nhiều agent — nên là code và config có thể review, không phải prompt dài như sớ.

Một map tối giản:

intents:
  campaign_conflict_check:
    allowed_actions:
      - get_active_journeys
      - compare_audience_overlap
      - summarize_conflicts
    forbidden_actions:
      - pause_campaign
      - change_segment_rule
    max_tool_calls: 4
    requires_citations: true

Hình dung thế này: nếu bạn giao thợ mộc đóng tủ, bạn không chỉ đưa cả hộp dụng cụ rồi bảo làm sao đẹp là được. Bạn nói kích thước, loại gỗ, chỗ nào được khoan, chỗ nào không được chạm. Agent cũng vậy.

Bước 3: Chuẩn hóa context trước khi nói chuyện với model

Nguồn về OKF nhắc một ý đáng giữ: nhiều tri thức nội bộ nằm rải trong wiki, catalog, schema, runbook, code comment. OKF — Open Knowledge Format, một quy ước markdown/YAML để đóng gói context cho agent và người đọc — không cần hiểu như một sản phẩm phải mua. Hãy xem nó như lời nhắc: context nên portable, có cấu trúc, và đọc được bằng mắt người.

Với team Việt Nam nhỏ, bạn có thể bắt đầu rất mộc:

/agent-knowledge
  /metrics
    weekly_active_users.md
    campaign_roas.md
  /schemas
    audience_table.md
    journey_events.md
  /runbooks
    campaign_conflict_review.md

Mỗi file nên có:

owner: marketing-data
last_reviewed: 2026-06-01
applies_to: campaign_analytics
source_of_truth: warehouse_table_name

Không cần hoành tráng. Chỉ cần agent không phải lục tri thức như tìm đinh rơi dưới sàn.

Bước 4: Ghi log theo câu hỏi production, không theo câu hỏi demo

Log kiểu request in, response out chưa đủ. Với agent có tool, bạn cần thấy:

Nguồn từ Cloudflare về agent harness nhấn vào một vấn đề khác nhưng liên quan: khi agent chạy như hạ tầng thật, nó cần state, storage, compute, resume sau gián đoạn, và môi trường chạy code an toàn. Durable execution — thực thi bền bỉ, có thể tiếp tục sau khi bị ngắt — không phải ưu tiên nếu agent chỉ trả lời FAQ. Nhưng nếu agent chạy workflow dài, gọi nhiều tool, hoặc xử lý job nền, bạn nên đưa nó vào checklist sớm.

Hai bẫy builder hay dính

Bẫy 1: Nhầm framework với guardrail

Framework giúp bạn dựng project nhanh hơn. Harness giúp agent có môi trường chạy, kết nối tool, quản lý vòng đời. Nhưng guardrail — luật an toàn về quyền, dữ liệu, hành động và review — vẫn phải do team bạn định nghĩa theo domain.

Cloudflare nói đến lớp framework, harness và platform primitives. Điều mình rút ra cho team builder: đừng kỳ vọng đổi framework là tự nhiên có production discipline. Nếu policy nằm trong đầu tech lead, agent vẫn mong manh.

Bẫy 2: Để model tự nghĩ action interface

SpatialClaw thú vị ở chỗ nó không chỉ hỏi model tốt hơn, mà đổi cách agent hành động: dùng code làm action interface — giao diện để agent biểu diễn và thực thi hành động. Dù bài toán spatial reasoning khác marketing analytics, bài học chung rất rõ: interface quyết định chất lượng hành vi.

Với agent nội bộ, action interface nên hẹp, rõ, typed, có schema. Tránh kiểu:

{ "tool": "query_database", "sql": "...model tự viết gì đó..." }

Ưu tiên kiểu:

{
  "tool": "rank_audiences",
  "inputs": {
    "campaign_id": "CMP_123",
    "time_range": "last_14_days",
    "metric": "conversion_rate"
  }
}

Cùng là gọi dữ liệu, nhưng một bên là mở cả xưởng, một bên là đưa đúng dao bào cho đúng việc.

Sau bài này, bạn nên nghĩ khác điều gì?

Đừng đánh giá agent production bằng số tool nó gọi được. Hãy đánh giá bằng độ rõ của khung vận hành: intent có phân loại không, action có giới hạn không, data có nguồn gốc không, review có điểm dừng không, log có đủ để điều tra không.

Nếu là mình, mình sẽ không bắt đầu bằng câu nên dùng framework nào? Mình sẽ mở một file orchestration-map.yaml, chọn 5 intent quan trọng nhất, rồi khóa quyền tool theo từng intent. Framework đổi được. Khung sai thì thay model nào cũng chỉ là bào phẳng nhầm mặt gỗ.

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

Nguồn tham khảo