Bạn Không Cần Thêm AI Agent. Bạn Cần Một Nền Tảng Agent Doanh Nghiệp.

Phòng Tài chính của bạn vừa xây một agent giúp rút ngắn quy trình chốt sổ cuối tháng xuống 40%. Phòng Thu mua thấy kết quả liền tự build một agent cho luồng intake-to-PO. Chăm sóc khách hàng đang prototype agent giải quyết khiếu nại. IT Operations muốn agent xử lý incident triage.

Mỗi phòng ban đều khởi đầu với ý định tốt. Nhưng mỗi phòng lại chọn một stack riêng. Tài chính log kết quả ra spreadsheet. Thu mua chọn một model gateway khác. Chăm sóc khách hàng lưu context trong file local. IT Operations thiết kế cơ chế phê duyệt custom.

Nhìn riêng lẻ, mọi quyết định đều hợp lý. Nhìn tổng thể, bạn đang có bốn agent không thể chia sẻ tool, không tuân theo access control thống nhất, tạo ra audit log không thể so sánh, và không thể đánh giá lẫn nhau. Cảm giác tiến bộ thực chất là sự phân mảnh.

Đây là lúc hầu hết tổ chức khám phá ra sự thật phũ phàng: bạn không phải đang xây nhiều ứng dụng agent. Bạn đang thất bại trong việc xây một nền tảng agent doanh nghiệp.

Kiến trúc tham chiếu tách biệt ba lớp: agent làm gì (runtime), agent biết gì (context), và agent bị kiểm soát thế nào (governance) — ba lớp có thể scale độc lập.

Một Sự Phân Biệt Thay Đổi Mọi Thứ

Sai lầm phổ biến nhất trong enterprise AI là nhầm lẫn giữa agent application và agent platform.

Một agent application giải quyết một bài toán nghiệp vụ cụ thể: xử lý ngoại lệ AP, tiếp nhận đơn hàng, giải quyết khiếu nại. Nó chứa workflow, prompt, tool, và context riêng của domain đó. Người dùng nhìn thấy nó. Họ yêu thích nó. Họ muốn thêm nhiều hơn.

Một agent platform vô hình với người dùng nghiệp vụ. Nó cung cấp các khả năng dùng chung mà mọi agent đều cần: identity và access control, model routing, tool registry, context retrieval, observability, evaluation, deployment, và policy enforcement.

Nếu không có sự phân biệt này, công ty sẽ đi vào một trong hai hướng sai. Một số xây agent đầu tiên với quá nhiều component custom đến nỗi không thể tái sử dụng. Số khác dành hàng tháng xây một platform chung chung mà không use case nào áp dụng.

Con đường đúng là một minimum viable platform — sinh ra từ use case thực tế, xây dựng với kiến trúc nhất quán, và phát triển khi nhu cầu xuất hiện.

Runtime Layer Thực Sự Cần Gì

Runtime layer là nơi agent thực thi. Nó không chỉ là "gọi model và trả về câu trả lời." Enterprise execution yêu cầu năm component mà hầu hết team bỏ qua.

Model gateway là component bị đánh giá thấp nhất. Nó không chỉ kết nối đến model — nó chọn model phù hợp cho từng tác vụ, xử lý fallback, log mọi cuộc gọi, và kiểm soát chi phí. Nếu không có nó, mỗi agent gọi model theo cách riêng, và bạn mất toàn bộ visibility vào spending và quality. Các tác vụ phân loại đơn giản có thể dùng model nhẹ. Suy luận phức tạp qua tài liệu cần model mạnh hơn. Gateway đưa ra quyết định đó một cách nhất quán.

Tool registry và tool execution phải tách rời. Registry là catalog: metadata, owner, permissions, risk tier. Execution service thực sự chạy tool sau khi validation — kiểm tra parameters, permissions, policy, và đôi khi yêu cầu phê duyệt. Một agent có thể yêu cầu draft purchase order, nhưng execution service từ chối nếu vendor chưa được phê duyệt. Một agent có thể chuẩn bị refund, nhưng execution tạm dừng nếu số tiền vượt ngưỡng.

State và memory phục vụ mục đích khác nhau. State lưu trạng thái workflow xác định — agent đang ở bước nào, quyết định gì đã được đưa ra. Memory lưu thông tin ngữ cảnh qua nhiều session. Nhiều implementation trộn lẫn chúng, nhưng state cần governance và auditability chặt chẽ hơn. Memory có thể linh hoạt hơn nhưng phải tuân thủ permission và retention policies.

Policy enforcement phải là một checkpoint rõ ràng gần mọi tool call, data access, và action execution. Nếu policy chỉ là một document hoặc logic rải rác, nó quá mong manh cho production.

Context Là Nơi Agent Thực Sự Thất Bại

Hầu hết thất bại của agent không phải lỗi của model. Context sai, không đầy đủ, lỗi thời, hoặc không có quyền truy cập.

Permission-aware retrieval là khả năng quan trọng nhất trong layer này. Một agent không bao giờ được truy xuất tài liệu chỉ vì nó tương tự về mặt ngữ nghĩa. Nó phải biết user là ai, agent nào đang hỏi, domain nào đang xử lý, và dữ liệu nào được phép. HR agent không được thấy tài liệu lương của các case khác. Customer service agent không được truy cập lịch sử của khách hàng khác.

Ingestion pipeline xử lý extraction, chunking, metadata enrichment, sensitivity classification, versioning, và sync. Nếu không có ingestion kỷ luật, retrieval sẽ kéo về nội dung cũ hoặc không liên quan.

Ba loại storage phục vụ nhu cầu khác nhau. Vector stores xử lý semantic search trên nội dung phi cấu trúc. Metadata catalogs cung cấp cấu trúc: source, owner, validity date, classification, access rights. Knowledge graphs nắm bắt mối quan hệ thực thể — vendor với contract, product với customer, incident với policy. Không phải use case nào cũng cần graph. Knowledge assistant đơn giản hoạt động tốt với vector cộng metadata. Nhưng supply chain disruption, customer entitlement, hoặc cross-entity finance exceptions được hưởng lợi rất nhiều từ graph-based reasoning.

Governance Layer Mà Không Ai Muốn Xây

Governance không phải là quan liêu. Nó là sự khác biệt giữa agent bạn tin tưởng và agent bạn không thể deploy.

Agent registry là catalog chính thức: name, purpose, business và technical owners, risk tier, tools, data sources, autonomy level, lifecycle status, dependencies. Policy registry lưu các quy tắc cross-agent: transaction thresholds, approval requirements, tool restrictions, risk classifications. Không có registry, bạn không có inventory để quản trị.

Risk tiering ngăn chặn kiểm soát một-size-fits-all. Một internal knowledge assistant ở chế độ assist khác với một agent thực thi ERP transactions. Soạn thảo commentary khác với trigger refund hoặc production remediation. Tiering kết nối với approval workflows, observability depth, testing rigor, và release controls.

Evaluation harness là môi trường kiểm thử agent trước và sau khi release. Golden datasets, scenario tests, policy compliance checks, regression tests khi model hoặc prompt thay đổi, và post-production sampling. Nếu không có nó, bạn chỉ biết agent đang chạy — không biết chất lượng đang cải thiện hay suy giảm.

Thứ Tự Xây Dựng Duy Nhất Có Thể Hoạt Động

Sai lầm kinh điển của platform là cố xây mọi thứ cùng lúc. Kết quả là chậm, đắt, và không kết nối với nhu cầu nghiệp vụ.

• Bắt đầu với model gateway. Cho mọi agent đầu tiên một đường dẫn chuẩn cho model access, logging, fallback, và cost control.
• Thêm tool registry và execution ngay khi agent chạm vào enterprise systems. Nếu không, integrations trở nên hoang dã và không thể kiểm toán.
• Tiếp theo là logging, tracing, và observability. Trước khi scale, bạn phải thấy agent đang làm gì, tốn bao nhiêu, và phản hồi nhanh thế nào.
• Permission enforcement và policy checks theo sau khi agent đọc dữ liệu nhạy cảm hoặc thực thi hành động.
• Evaluation harness trở nên quan trọng khi model, prompt, hoặc tool thay đổi thường xuyên.
• Memory service và agent registry có thể chờ trừ khi use case của bạn cụ thể cần chúng.

Nguyên tắc rất đơn giản: capabilities phải sinh ra từ real use cases. Xây knowledge graph mà không có use case cần quan hệ phức tạp tạo ra một tài sản đắt tiền không ai dùng. Xây memory tinh vi cho agent stateless, task-based là premature.

Áp Dụng Vào Hệ Thống Thật

Hãy tưởng tượng bạn bắt đầu với hai use case: AP exception handling và IT incident triage. Từ hai use case này, bạn sẽ khám phá ra các nhu cầu dùng chung cấp bách nhất: model gateway, tool registry, observability, permission-aware retrieval, và approval workflows. Knowledge graphs đầy đủ và cross-agent memory có thể chờ.

Một kiến trúc tham chiếu tốt không phải là cái hoàn chỉnh nhất trên giấy. Nó là cái cho phép bạn trả lời một câu hỏi với sự tự tin: nếu ngày mai chúng ta thêm mười agent mới trải khắp finance, procurement, customer operations, và IT, chúng ta có nền tảng dùng chung để chạy chúng an toàn, ở scale, mà không tạo ra agent sprawl không?

Nếu câu trả lời là không, ưu tiên tiếp theo của bạn không phải xây thêm agent. Đó là củng cố nền tảng.

Bài viết này xuất hiện lần đầu trên blog của tác giả.