Doanh nghiệp cần gì để đưa AI agent vào vận hành thực tế?

Khoảng cách giữa bản thí điểm và vận hành thực tế nằm ở hệ thống bao quanh agent. Đầu tư vào hệ thống ấy một lần, mọi agent về sau đều có thể đi vào vận hành chỉ trong vài tuần.

Những kỹ sư giỏi nhất của bạn giờ đây có thể vibe code một agent chạy được chỉ trong một, hai tuần, và buổi demo thường rất ấn tượng. Nhưng để agent đó thật sự làm việc cho người dùng thật, trên dữ liệu thật, lại mất hàng tháng, và không ít dự án bỏ dở giữa chừng. Gartner dự báo hơn 40% dự án agentic AI sẽ bị hủy trước cuối năm 2027 vì ba lý do: chi phí leo thang, giá trị kinh doanh không rõ ràng và kiểm soát rủi ro chưa đủ chặt. Không lý do nào trong số đó là mô hình AI chưa đủ giỏi.

Khi một dự án thí điểm bị chững lại, agent thường vẫn làm được việc. Cái thiếu là câu trả lời cho những câu hỏi mà doanh nghiệp luôn đặt ra với bất cứ ai, hay bất cứ thứ gì, hành động thay mặt mình: agent làm việc cho ai, được chi tiêu bao nhiêu, dừng lại bằng cách nào, và làm sao chứng minh nó đã làm gì.

Những câu trả lời ấy giống nhau cho mọi agent. Đầu tư một lần vào hạ tầng dùng chung, mỗi agent mới sẽ kế thừa toàn bộ và có thể đi vào vận hành trong vài tuần. Còn nếu để từng nhóm tự xoay xở, dự án thí điểm nào cũng phải trải qua cùng một vòng thẩm định bảo mật, cùng một cuộc tranh luận về ngân sách, và đó chính là lý do nhiều dự án không bao giờ về đích.

Hãy đầu tư vào nền tảng một lần, thay vì bỏ tiền làm lại ở từng dự án thí điểm.

› Kiến trúc agent cho doanh nghiệp

Mọi agent đang vận hành trong doanh nghiệp đều dựa trên một phiên bản nào đó của kiến trúc này, dù đã có ai vẽ ra hay chưa. Phần lớn thành phần bạn đã có sẵn: nhà cung cấp mô hình, hệ thống định danh, dữ liệu và hạ tầng. Tám lớp được đánh số là phần mà hầu hết dự án thí điểm bỏ qua, và cũng chính chúng quyết định agent có thể được giao việc thật hay không.

The eight layers inside the full enterprise agent stack Channels flow through an identity edge into the agent runtime, where your agent sits, between a control plane and guardrails. The runtime thinks through a model gateway, acts through tools with per-user data access, and grounds in knowledge and memory; the gateway calls model providers. Evidence and evals, security and governance, and build and release cut across every layer, on top of infrastructure. Below: the life of one request, and where a CTO should spend attention. 1 CHANNELS Web · IDE · Slack / Teams · Email · API · schedule · events message + who is asking 2 EDGE & IDENTITY API gateway + WAF · SSO (OIDC / SAML: Okta, Entra ID) · tenant routing · rate limits every request stamped: user_id · tenant_id · agent_id · session_id · trace_id authenticated turn 5 CONTROL PLANE lease ⇄ runtime kill in under 1 min deny user · caps pin version alerts → on-call 3 AGENT RUNTIME orchestrator · durable workflows human-in-the-loop approvals session state · retries · sandbox no keys, no DB creds on the host YOUR AGENT HERE Agent Packs, LangChain, CrewAI GUARDRAILS inline on every hop prompt injection PII / DLP redaction policy (OPA, Cedar) tool allow-lists output schema check think act ground 4 MODEL GATEWAY LLM proxy (e.g. LiteLLM) routing & fallback prompt / semantic cache budget checked pre-call over cap → refused cost attributed per user provider keys held here 6 TOOLS & DATA ACCESS MCP servers internal APIs · SaaS CRM, ITSM, GitHub code sandbox (microVM) browser automation acts AS the user (OBO) wrong user → 0 rows KNOWLEDGE & MEMORY ingestion + chunking ETL vector DB + keyword search ACL-aware retrieval session / long-term memory warehouse, systems of rec. SharePoint, Drive, wikis your keys, or our credits MODEL PROVIDERS Frontier APIs Cloud-hosted Self-hosted open weights Anthropic, OpenAI, AWS Bedrock, GCP Vertex, vLLM / TGI on a GPU pool, Google Azure AI Foundry fine-tuned small models CROSS-CUTTING · EVERY LAYER 7 EVIDENCE & EVALS OpenTelemetry traces cost · tokens · latency per user/agent/version tamper-evident (WORM) eval harness, LLM judges regression/drift alerts trace replay for debug SECURITY & GOVERNANCE agent workload identity short-lived scoped creds secrets vault (KMS/HSM) data residency · DLP SOC 2 · ISO 42001 EU AI Act mapping 8 BUILD & RELEASE IDE / CLI · templates signed, versioned packs prompt + tool versioning offline eval suites eval-gated CI/CD canary + one-cmd rollback agent registry / catalog INFRASTRUCTURE Kubernetes / VMs / Cloud Run · VPC + private link · Postgres · queues (Kafka / SQS) object storage · GPU capacity · IaC (Terraform) · multi-region DR · FinOps tagging LIFE OF ONE REQUEST 1. Alice asks in Slack [1] → the edge [2] checks SSO, stamps user + trace id 2. The runtime [3] holds a live lease from the control plane [5]; guardrails screen input 3. Agent loop: think via [4] → act as Alice via [6] → ground in knowledge (N steps) 4. Risky action (payment, prod deploy, customer email) → human approval in [3] 5. Guardrails check the output → reply; evidence [7] holds trace, version, cost, audit WHERE A CTO SHOULD SPEND ATTENTION Buy / adopt model providers, IdP, vector DB, Kubernetes, OTEL backend Standardize one gateway [4], one tool protocol (MCP) [6], one trace schema [7] Build (your edge) agents + prompts, integrations to YOUR systems, eval datasets Non-negotiable per-user identity [2], kill switch [5], spend caps [4], audit trail [7] Top risks prompt injection via tools/docs, over-privileged agents, runaway cost, silent quality regressions after a model or prompt change agenthippo.ai 
        1  CHANNELS   Web · IDE · Slack / Teams · Email · API · schedule · events
                                            │ message + who is asking
                                            ▼
┌─ 2  EDGE & IDENTITY ───────────────────────────────────────────────────────────────────┐
│ API gateway + WAF · SSO (OIDC / SAML: Okta, Entra ID) · tenant routing · rate limits   │
│ every request stamped: user_id · tenant_id · agent_id · session_id · trace_id          │
└───────────────────────────────────────────┬────────────────────────────────────────────┘
                                            │ authenticated turn
                                            ▼
┌─ 5  CONTROL PLANE ───┐  ┌─ 3  AGENT RUNTIME ─────────────────┐  ┌─ GUARDRAILS ─────────┐
│ lease ⇄ runtime      │  │ ┌─ YOUR AGENT HERE ──────────────┐ │  │ inline on every hop  │
│ kill in under 1 min  │◄►│ │ Agent Packs, LangChain, CrewAI │ │◄►│ prompt injection     │
│ deny user · caps     │  │ └────────────────────────────────┘ │  │ PII / DLP redaction  │
│ pin version          │  │ orchestrator · durable workflows   │  │ policy (OPA, Cedar)  │
│ alerts → on-call     │  │ human-in-the-loop approvals        │  │ tool allow-lists     │
│                      │  │ session state · retries · sandbox  │  │ output schema check  │
│                      │  │ no keys, no DB creds on the host   │  │                      │
└──────────────────────┘  └─────────────────┬──────────────────┘  └──────────────────────┘
             ┌──────────────────────────────┼─────────────────────────────┐
             │ think                        │ act                         │ ground
             ▼                              ▼                             ▼
┌─ 4  MODEL GATEWAY ───────┐  ┌─ 6  TOOLS & DATA ACCESS ─┐  ┌─ KNOWLEDGE & MEMORY ───────┐
│ LLM proxy (e.g. LiteLLM) │  │ MCP servers              │  │ ingestion + chunking ETL   │
│ routing & fallback       │  │ internal APIs · SaaS     │  │ vector DB + keyword search │
│ prompt / semantic cache  │  │ CRM, ITSM, GitHub        │  │ ACL-aware retrieval        │
│ budget checked pre-call  │  │ code sandbox (microVM)   │  │ session / long-term memory │
│ over cap → refused       │  │ browser automation       │  │ warehouse, systems of rec. │
│ cost attributed per user │  │ acts AS the user (OBO)   │  │ SharePoint, Drive, wikis   │
│ provider keys held here  │  │ wrong user → 0 rows      │  │                            │
└────────────┬─────────────┘  └──────────────────────────┘  └────────────────────────────┘
             │ your keys, or our credits
             ▼
┌─ MODEL PROVIDERS ──────────────────────────────────────────────────────────────────────┐
│ Frontier APIs              Cloud-hosted                 Self-hosted open weights       │
│ Anthropic, OpenAI,         AWS Bedrock, GCP Vertex,     vLLM / TGI on a GPU pool,      │
│ Google                     Azure AI Foundry             fine-tuned small models        │
└────────────────────────────────────────────────────────────────────────────────────────┘

══════════════════════════════ CROSS-CUTTING · every layer ═══════════════════════════════
┌─ 7  EVIDENCE & EVALS ────┐  ┌─ SECURITY & GOVERNANCE ──┐  ┌─ 8  BUILD & RELEASE ───────┐
│ OpenTelemetry traces     │  │ agent workload identity  │  │ IDE / CLI · templates      │
│ cost · tokens · latency  │  │ short-lived scoped creds │  │ signed, versioned packs    │
│ per user/agent/version   │  │ secrets vault (KMS/HSM)  │  │ prompt + tool versioning   │
│ tamper-evident (WORM)    │  │ data residency · DLP     │  │ offline eval suites        │
│ eval harness, LLM judges │  │ SOC 2 · ISO 42001        │  │ eval-gated CI/CD           │
│ regression/drift alerts  │  │ EU AI Act mapping        │  │ canary + one-cmd rollback  │
│ trace replay for debug   │  │                          │  │ agent registry / catalog   │
└──────────────────────────┘  └──────────────────────────┘  └────────────────────────────┘
┌─ INFRASTRUCTURE ───────────────────────────────────────────────────────────────────────┐
│ Kubernetes / VMs / Cloud Run · VPC + private link · Postgres · queues (Kafka / SQS)    │
│ object storage · GPU capacity · IaC (Terraform) · multi-region DR · FinOps tagging     │
└────────────────────────────────────────────────────────────────────────────────────────┘

LIFE OF ONE REQUEST
 1. Alice asks in Slack [1] → the edge [2] checks SSO, stamps user + trace id
 2. The runtime [3] holds a live lease from the control plane [5]; guardrails screen input
 3. Agent loop: think via [4] → act as Alice via [6] → ground in knowledge     (N steps)
 4. Risky action (payment, prod deploy, customer email) → human approval in [3]
 5. Guardrails check the output → reply; evidence [7] holds trace, version, cost, audit

WHERE A CTO SHOULD SPEND ATTENTION
 Buy / adopt       model providers, IdP, vector DB, Kubernetes, OTEL backend
 Standardize       one gateway [4], one tool protocol (MCP) [6], one trace schema [7]
 Build (your edge) agents + prompts, integrations to YOUR systems, eval datasets
 Non-negotiable    per-user identity [2], kill switch [5], spend caps [4], audit trail [7]
 Top risks         prompt injection via tools/docs, over-privileged agents, runaway cost,
                   silent quality regressions after a model or prompt change

Trong sơ đồ này, có hai điểm quan trọng hơn bất kỳ ô nào. Thứ nhất, agent nằm ở trung tâm nhưng không nắm giữ thứ gì đáng để đánh cắp: không khóa API, không mật khẩu cơ sở dữ liệu, không quyền hạn cố định. Thứ hai, mọi đường đi ra khỏi agent đều phải qua một lớp có quyền từ chối. Các ô còn lại là chi tiết kỹ thuật mà đội ngũ kỹ sư của bạn có thể tự lựa chọn.

› Dự án thí điểm thường mắc kẹt ở đâu

Cách dễ hiểu nhất về các lớp được đánh số là đi qua những vấn đề mà một dự án thí điểm gặp phải trên đường đi vào vận hành, theo thứ tự chúng thường xuất hiện. Mỗi đoạn dưới đây nói về một vấn đề và cách giải quyết; nếu muốn xem giải pháp trước, bạn có thể chuyển thẳng tới phần tiếp theo, nơi trình bày toàn bộ kiến trúc theo cách chúng tôi triển khai.

Người dùng. Agent đầu tiên thường chỉ chạy trên máy của một kỹ sư, và sáu tháng sau vẫn chỉ có đúng một người dùng. Agent chỉ tạo ra giá trị khi có mặt ở nơi công việc đang diễn ra, như Slack, Teams, email hay các tác vụ chạy định kỳ ban đêm, và được dùng bởi cả những người chưa từng xem demo. Khi đó, agent phải biết từng người là ai, và thông tin này phải lấy từ hệ thống định danh của công ty, không phải từ những gì người dùng tự gõ vào. Nếu không, bất kỳ ai cũng có thể tự xưng là giám đốc tài chính trong khung chat và nhận được những câu trả lời chỉ dành cho giám đốc tài chính.

Dữ liệu. Để làm cho nhanh, bản thử nghiệm thường kết nối vào kho dữ liệu bằng một tài khoản dùng chung. Khi đưa vào vận hành, lối tắt đó khiến một trưởng nhóm hỏi về chi tiêu của nhóm mình lại nhận được cả mức lương của đồng nghiệp trong câu trả lời, vì với cơ sở dữ liệu, mọi câu hỏi đều đến từ cùng một người. Cách khắc phục đã có từ lâu: agent truy vấn dưới danh nghĩa chính người đặt câu hỏi, và cơ sở dữ liệu áp dụng đúng những quyền truy cập vốn có. Trong các rủi ro ở đây, rò rỉ dữ liệu là điều dễ khiến doanh nghiệp gặp rắc rối với cơ quan quản lý nhất, và ngăn chặn từ trước khi ra mắt rẻ hơn nhiều so với xử lý hậu quả.

Chi phí. Agent có thể tự thử lại, chạy vòng lặp và tách việc thành nhiều nhánh song song. Chỉ cần gặp một lỗi không xử lý được vào tối thứ Sáu, agent có thể đốt hết ngân sách cả tháng trước khi có người mở bảng theo dõi vào sáng thứ Hai, và hóa đơn gửi về chỉ là một con số, không biết của ai. Giải pháp là một cổng kết nối mô hình (model gateway): một dịch vụ duy nhất đứng giữa mọi agent và mọi nhà cung cấp mô hình. Trước mỗi lệnh gọi, gateway kiểm tra ngân sách của agent và của người dùng, chặn lại nếu đã hết hạn mức, và ghi nhận từng đồng chi phí cho đúng người, đúng mục đích. Nhờ số liệu đó, bạn cũng biết được agent nào thực sự mang lại giá trị xứng với chi phí.

Lựa chọn mô hình. Bản thử nghiệm thường gắn chặt với mô hình của một nhà cung cấp, khóa API dán thẳng vào cấu hình. Khi mọi lệnh gọi đều đi qua gateway, việc chọn mô hình trở thành một thiết lập được quản lý tập trung. Việc thường ngày có thể dùng mô hình cloud rẻ hơn hoặc mô hình mã nguồn mở chạy trên máy chủ của bạn; yêu cầu liên quan đến dữ liệu nhạy cảm có thể xử lý bằng mô hình đặt trong mạng nội bộ; chỉ những việc khó nhất mới cần đến các mô hình hàng đầu, đắt nhất. Bạn cũng có thể cho một mô hình mới chạy thử trên một phần lưu lượng thật, so sánh chi phí và chất lượng rồi mới chuyển hẳn, mà không phải sửa agent. Khóa API của các nhà cung cấp nằm gọn trong gateway, không nhóm hay agent nào phải giữ, và lượng token của từng người dùng được theo dõi theo hạn mức riêng.

Kiểm soát. Sự cố thường xảy ra vào lúc bất tiện nhất. Câu hỏi là dừng agent chỉ mất một cú nhấp chuột, hay mất cả tiếng đồng hồ đi tìm xem nó đang chạy trên máy nào, trong khi kỹ sư phụ trách lại đang ngồi trên máy bay. Hơn nữa, agent làm theo chỉ dẫn từ bất cứ nội dung nào nó đọc được, kể cả một dòng chữ giấu trong phiếu hỗ trợ khách hàng hay trong file PDF của đối tác. Vì vậy, agent không nên giữ bất kỳ khóa hay mật khẩu nào, và các giới hạn của nó phải do hệ thống bên ngoài thực thi, chứ không chỉ ghi trong phần chỉ dẫn, nơi tài liệu tiếp theo nó đọc có thể ghi đè.

Trách nhiệm giải trình. Một khách hàng chuyển tiếp email do agent gửi và hỏi: thông tin này dựa trên cơ sở nào? Bạn cần trả lời trong vài phút: ai đã yêu cầu, phiên bản agent nào đã chạy, agent đã truy cập dữ liệu gì và tốn bao nhiêu. Log thông thường, do chính máy chạy agent ghi lại, đủ để kỹ sư gỡ lỗi. Nhưng với khách hàng hay kiểm toán viên, bạn cần một bản ghi được lưu ngoài tầm với của agent và không thể bị sửa đổi sau đó.

Thay đổi. Tuần này agent bỗng làm việc kém đi. Có người đã sửa prompt, thay một công cụ, hoặc nhà cung cấp vừa cập nhật mô hình, nhưng không ai biết nguyên nhân nằm ở đâu, vì các thành phần này không được quản lý phiên bản cùng nhau. Hãy coi prompt, công cụ, mô hình và engine là một bản phát hành thống nhất, gắn mỗi lần triển khai với một phiên bản cụ thể; khi đó, một thay đổi không tốt chỉ cần một câu lệnh để quay lại, thay vì mất cả tuần dò tìm. Và khi sai lầm dễ sửa, đội ngũ có thể tự tin phát hành cải tiến thường xuyên hơn.

Không có gì trong số này là mới. Doanh nghiệp vẫn luôn quản lý con người và phần mềm theo cách đó: tài khoản đăng nhập gắn với từng người, hạn mức chi tiêu, một người quản lý có quyền yêu cầu dừng lại, hồ sơ lưu vết, quy trình phê duyệt thay đổi. Điểm khác là với agent, những kiểm soát này không thể chỉ nằm trên giấy. Quy định có thể ghi rằng không ai được chuyển khoản quá 50.000 USD, nhưng chính hệ thống thanh toán mới là thứ chặn giao dịch lại. Agent cũng cần được kiểm soát theo cách đó, ngay trong các hệ thống mà nó sử dụng, vì không thể trông chờ agent luôn tuân thủ quy định bằng văn bản. Đó là điều chúng tôi gọi là quản trị trong vận hành (runtime governance): các kiểm soát được phần mềm thực thi trên từng hành động của agent.

› Kiến trúc trong thực tế

Dưới đây là cùng kiến trúc đó theo cách chúng tôi triển khai tại AgentHippo, với các thành phần mặc định. Thiết kế dựa trên hai cơ chế từ chối: lệnh gọi vượt ngân sách sẽ không bao giờ đến được mô hình, và yêu cầu truy cập dữ liệu của người khác chỉ nhận về kết quả rỗng. Mọi thành phần nằm trong đường viền nét đứt đều chạy trong môi trường của bạn.

How a governed agent deployment is wired A user's message passes through a TLS proxy, oauth2-proxy and your identity provider to the auth-broker, which hands the agent runtime a verified user and a short-lived token. Your agent runs inside the runtime as a signed Agent Pack. The runtime holds a lease from the control plane and receives signed packs from build and release. It makes metered calls through agenthippo-gateway, which refuses calls over the budget cap, reads data as the user through an on-behalf-of connector that returns no rows to the wrong user, and records every action in the evidence archive. Runtime, gateway, data access and evidence run inside your environment. YOUR ENVIRONMENT 1·2 EDGE & IDENTITY TLS proxy → oauth2-proxy ⇄ your IdP (Okta · Entra · Google) → auth-broker out: the verified user + a short-lived token for this turn 5 CONTROL PLANE agenthippo-control lease (TTL) ⇄ runtime kill · deny user · caps pin version · console alerts → PagerDuty / IRM 3 AGENT RUNTIME YOUR AGENT HERE signed Agent Pack agent.yaml · prompt · skills 4 GATEWAY agenthippo-gateway identity + budget → LiteLLM → model over cap → refused 6 DATA (OBO) connector container Postgres RLS DynamoDB (STS tags) Unity Catalog wrong user → 0 rows 7 EVIDENCE OTEL → evidence-server MinIO · S3 Object Lock WORM · Spotlight who·version·touched·cost 8 BUILD & RELEASE IDE / CLI → Agent Pack sign → GHCR image · store tag one-command rollback Alice · Bob via Slack · WhatsApp · Telegram · API · schedule serve · sandbox on your VM · Cloud Run · Databricks Apps · behind your proxy no provider key, no DB credential a lease it keeps renewing message + who is asking authenticated turn metered call as the user every action signed pack agenthippo.ai 
                                Alice · Bob   via Slack · WhatsApp · Telegram · API · schedule
                                                              │ message + who is asking
                                                              ▼
┌─ 1·2  EDGE & IDENTITY ─────────────────────────────────────────────────────────────────────────────────┐
│ TLS proxy → oauth2-proxy ⇄ your IdP (Okta · Entra · Google) → auth-broker                              │
│ out: the verified user + a short-lived token for this turn                                             │
└─────────────────────────────────────────────────────────────┬──────────────────────────────────────────┘
                                                              │ authenticated turn
                                                              ▼
┌─ 5  CONTROL PLANE ────────┐   ┌─ 3  AGENT RUNTIME ─────────────────────────────────────────────────────┐
│ agenthippo-control        │   │ ┌─ YOUR AGENT HERE ────────────┐ serve · sandbox                       │
│ lease (TTL) ⇄ runtime     │◄──│ │ signed Agent Pack            │ on your VM · Cloud Run ·              │
│ kill · deny user · caps   │──►│ │ agent.yaml · prompt · skills │ Databricks Apps · behind your proxy   │
│ pin version · console     │   │ └──────────────────────────────┘ no provider key, no DB credential     │
│ alerts → PagerDuty / IRM  │   │                                  a lease it keeps renewing             │
└───────────────────────────┘   └──────────┬──────────────────────┬─────────────────────────┬────────────┘
              ▲ signed pack                │ metered call         │ as the user             │ every action
┌─ 8  BUILD & RELEASE ──────┐              ▼                      ▼                         ▼
│ IDE / CLI → Agent Pack    │   ┌─ 4  GATEWAY ───────┐ ┌─ 6  DATA (OBO) ─────┐ ┌─ 7  EVIDENCE ───────────┐
│ sign → GHCR               │   │ agenthippo-gateway │ │ connector container │ │ OTEL → evidence-server  │
│ image · store tag         │   │ identity + budget  │ │ Postgres RLS        │ │ MinIO · S3 Object Lock  │
│ one-command rollback      │   │ → LiteLLM → model  │ │ DynamoDB (STS tags) │ │ WORM · Spotlight        │
└───────────────────────────┘   │ over cap → refused │ │ Unity Catalog       │ │ who·version·touched·cost│
                                └────────────────────┘ │ wrong user → 0 rows │ └─────────────────────────┘
                                                       └─────────────────────┘

Không có gì trong sơ đồ này phụ thuộc vào việc mô hình luôn hành xử đúng. Nếu bị tấn công bằng prompt injection, môi trường chạy agent không có bí mật nào để lộ. Nếu agent chạy vòng lặp, gateway sẽ ngừng chi trả. Nếu agent đòi dữ liệu của khách hàng khác, cơ sở dữ liệu trả về kết quả rỗng. Và khi cần dừng, agent sẽ dừng, vì nó phải liên tục xin phép control plane mới được chạy tiếp. Dù bạn chọn thành phần nào, đây là đặc tính đáng học hỏi.

Các thành phần trên chỉ là lựa chọn mặc định, không bắt buộc: bạn có thể dùng identity proxy, kho lưu trữ hay khóa API của riêng mình. Control plane có thể do AgentHippo vận hành hoặc đặt trên hạ tầng của chính bạn.

› Nên và không nên đầu tư vào đâu

Phần lớn kiến trúc này bạn không nên tự xây. Nhà cung cấp mô hình, hệ thống định danh, tìm kiếm, Kubernetes, công cụ giám sát: hãy mua hoặc dùng giải pháp sẵn có, và đừng tự phát triển phiên bản riêng cho bất cứ thứ gì trong danh sách này. Các bộ lọc an toàn (guardrail) cho prompt và kết quả đầu ra cũng vậy. Chúng đáng có vì giúp mô hình ít mắc lỗi hơn, nhưng không thể hạn chế thiệt hại khi mô hình vẫn sai. Việc đó thuộc về các lớp đã nói ở trên.

Có vài thứ nên được chuẩn hóa trên toàn công ty từ sớm, trước khi mỗi nhóm tự chọn một kiểu: một gateway chung cho mô hình, một cách thống nhất để agent kết nối với công cụ, và một định dạng chung để ghi lại những gì agent đã làm. Khi đã chuẩn hóa, agent mới chỉ việc kết nối vào hạ tầng sẵn có thay vì xây lại từ đầu.

Thời gian của đội ngũ kỹ sư nên dành cho những thứ không nhà cung cấp nào làm thay được: bản thân các agent, phần tích hợp với hệ thống riêng của công ty, và bộ tình huống kiểm thử mô tả thế nào là làm tốt trong bối cảnh doanh nghiệp của bạn. Bộ kiểm thử này là tài sản bị đánh giá thấp nhất trong AI hiện nay. Mô hình sẽ còn thay đổi liên tục. Có bộ kiểm thử tốt, chỉ trong một tuần bạn biết mô hình mới có làm tốt hơn không và tự tin chuyển đổi; không có nó, mỗi lần đổi mô hình chỉ là một quyết định theo cảm tính.

› Chúng tôi ở đâu trong bức tranh này

Xin nói rõ, vì bạn đang đọc bài này trên website của chúng tôi: đây chính là kiến trúc mà chúng tôi xây dựng. AgentHippo cung cấp các lớp được đánh số ở trên dưới dạng đóng gói sẵn, để doanh nghiệp có thể triển khai trong môi trường của mình với bất kỳ mô hình và agent framework nào, dùng khóa API riêng hoặc gói credit của chúng tôi. Mỗi lớp được triển khai bằng một script đơn giản mà kỹ sư của bạn có thể đọc hết trước khi chạy, và mỗi lần triển khai đều tự kiểm tra trước khi báo thành công. Dù vậy, bạn không cần đến AgentHippo để áp dụng những gì trong bài: cùng một thiết kế hoàn toàn có thể xây dựng từ các thành phần khác.

› Bắt đầu từ đâu

Bạn không cần đủ cả tám lớp ngay từ ngày đầu. Bốn lớp đã giải quyết phần lớn rủi ro, và có thể tóm lại trong một câu: agent hành động thay cho một người đã được xác thực, trong giới hạn ngân sách, có nút dừng khẩn cấp, và mọi thao tác đều được ghi lại. Khi agent bắt đầu truy cập các hệ thống dữ liệu cốt lõi, hãy bổ sung phân quyền dữ liệu theo từng người dùng; khi có người thứ hai cùng sửa prompt, hãy áp dụng quy trình phát hành.

Tiếp theo, hãy chọn một quy trình mà nếu có sai sót thì dễ phát hiện và dễ khắc phục, đồng thời đo được hiệu quả bằng tiền hoặc giờ công. Vận hành quy trình đó với bốn lớp kiểm soát trên trong một tháng. Chỉ mở rộng quyền hạn của agent khi số liệu thực tế cho phép, và dựa vào những gì học được để chọn agent thứ hai. Đến agent thứ ba, ban lãnh đạo thường không còn bàn chuyện agent có hiệu quả hay không, mà là nên tự động hóa quy trình nào tiếp theo.

› Đưa một quy trình vào vận hành trong ba tuần

Nếu không muốn tự lắp ghép tất cả, chương trình Production Sprint của chúng tôi sẽ đưa một quy trình thực tế vào vận hành trên kiến trúc này, ngay trong môi trường của bạn, trong ba tuần, kèm số liệu cho thấy khoản đầu tư có hiệu quả hay không. Nếu đội ngũ của bạn muốn tự đánh giá trước, có thể bắt đầu miễn phí.

Đặt lịch Sprint Bắt đầu miễn phí