Trong thời gian gần đây, khi làm việc và tìm hiểu nhiều hơn về AI Agent, mình nhận ra một điều khá thú vị: phần lớn các cuộc thảo luận vẫn đang tập trung vào việc model nào mạnh hơn, reasoning tốt hơn, context window dài hơn hay benchmark cao hơn.

Nhưng khi đưa Agent từ một demo chạy được sang một hệ thống thực sự vận hành trong production, câu hỏi quan trọng dần không còn là:

Model thông minh đến đâu?

Mà trở thành:

Làm thế nào để một thành phần vốn mang tính xác suất có thể vận hành bên trong một hệ thống yêu cầu tính ổn định, an toàn và khả năng kiểm soát?

Và để hiểu tại sao Harness quan trọng, trước hết phải bắt đầu từ một đặc tính rất cơ bản của AI.

AI không deterministic

Với phần lớn phần mềm truyền thống, developer quen với một giả định rất đơn giản:

Input
  ↓
Logic
  ↓
Output

Nếu logic không thay đổi, chúng ta kỳ vọng cùng một input sẽ tạo ra cùng một output.

Một phép tính:

2 + 2 = 4

Không có lần chạy thứ hai nào tự nhiên trả về 5 chỉ vì hệ thống “suy nghĩ hơi khác”.

Một permission check cũng vậy:

if user.role == "admin":
    allow()
else:
    deny()

Nếu role không thay đổi, kết quả không thay đổi.

Nhưng LLM không vận hành theo cách đó.

Kết quả mà model tạo ra mang tính xác suất. Với cùng một vấn đề, model có thể chọn những hướng reasoning khác nhau, gọi những tool khác nhau hoặc đưa ra những kết luận hơi khác nhau giữa các lần chạy.

Điều này không nhất thiết là một điểm yếu. Chính sự linh hoạt đó khiến LLM có thể giải quyết những vấn đề khó logic hóa bằng code truyền thống.

Nhưng nó tạo ra một vấn đề rất lớn khi chúng ta bắt đầu xây Agentic Workflow.

Giả sử một Agent có xác suất thực hiện đúng một bước là 95%.

Nếu chỉ có một bước:

Success Rate = 95%

Con số này nghe khá tốt.

Nhưng một Agent production hiếm khi chỉ làm một bước.

Giả sử workflow gồm mười bước liên tiếp và tất cả đều phải đúng:

Step 1  → 95%
Step 2  → 95%
Step 3  → 95%
...
Step 10 → 95%

Xác suất toàn bộ chuỗi thành công khi đó là:

0.95 ^ 10 ≈ 59.9%

Từ một hệ thống mà từng bước có vẻ “95% chính xác”, chúng ta có thể kết thúc với một workflow chỉ còn khoảng 60% khả năng hoàn thành đúng toàn bộ chuỗi.

Đây là nơi sai số của AI bắt đầu trở thành một vấn đề engineering.

Một Agent production không chỉ “trả lời câu hỏi”

Hãy tưởng tượng một SRE Agent nhận được nhiệm vụ:

Production đang có latency tăng bất thường. Hãy tìm nguyên nhân và xử lý.

Ở phía sau câu lệnh đơn giản đó có thể là cả một chuỗi hành động:

Receive Incident
      ↓
Read Alert
      ↓
Query Metrics
      ↓
Read Logs
      ↓
Check Recent Deployment
      ↓
Form Hypothesis
      ↓
Query Another Data Source
      ↓
Identify Root Cause
      ↓
Select Remediation
      ↓
Execute Action
      ↓
Verify System Health

Nếu Agent hiểu sai log ở bước thứ tư, toàn bộ reasoning phía sau có thể đi sai.

Nếu Agent chọn nhầm remediation ở bước thứ chín, hậu quả thậm chí còn nghiêm trọng hơn.

Vấn đề không còn nằm ở một câu trả lời sai.

Vấn đề nằm ở việc một kết luận sai có thể trở thành input cho hành động tiếp theo.

Trong software engineering truyền thống, chúng ta đã giải quyết bài toán này từ lâu bằng validation, permission, isolation, retry, transaction, test, monitoring và rất nhiều control khác.

AI Agent cũng cần một lớp tương tự.

Đó là nơi mình hiểu Harness bắt đầu xuất hiện.

Model tạo ra năng lực. Harness tạo ra độ tin cậy.

Có thể hình dung một Agent theo mô hình đơn giản:

                 ┌────────────────────────────┐
                 │           HARNESS          │
                 │                            │
                 │   Permissions              │
                 │   Context                  │
                 │   Validation               │
                 │   Guardrails               │
                 │   Observability            │
                 │   Retry / Recovery         │
                 │                            │
                 │        ┌─────────┐         │
User / Event ───►│        │  AGENT  │         │───► Action
                 │        └─────────┘         │
                 │                            │
                 └────────────────────────────┘

Model cung cấp khả năng reasoning.

Nhưng Harness xác định model:

• được nhìn thấy dữ liệu gì;
• được phép gọi tool nào;
• được phép thực hiện action nào;
• action nào phải validate;
• action nào cần approval;
• khi nào phải retry;
• khi nào phải dừng;
• khi nào phải chuyển cho con người.

Đây là một sự thay đổi khá quan trọng trong cách nhìn AI Agent.

Chúng ta không còn cố gắng tạo ra một Agent không bao giờ sai.

Thay vào đó, chúng ta thiết kế một hệ thống với giả định:

Agent sẽ có lúc sai. Vậy hệ thống phải làm gì khi điều đó xảy ra?

Đây chính là mindset mà software engineering đã sử dụng hàng chục năm.

Database có thể fail, vì vậy có transaction.

Network có thể fail, vì vậy có retry và timeout.

Service có thể chết, vì vậy có health check và orchestration.

Developer có thể viết bug, vì vậy có testing và code review.

AI Agent có thể reasoning sai, vì vậy cũng cần Harness.

Development Harness: Khi Coding Agent rất nhanh nhưng không nhìn thấy toàn bộ hệ thống

Một trong những ứng dụng dễ thấy nhất hiện nay là Coding Agent.

Coding Agent có một lợi thế rất lớn so với developer: tốc độ thực thi.

Nó có thể đọc hàng chục file, generate code, chạy test và sửa lỗi trong vài phút.

Nhưng tốc độ không đồng nghĩa với khả năng hiểu toàn bộ hệ thống.

Hãy lấy một ví dụ.

Developer giao cho Agent:

Rename field customerId thành clientId trong service này.

Agent search repository, thay đổi field, update unit test và chạy test.

Unit Tests: PASS

Task hoàn thành.

Nhưng customerId có thể đang được:

• một downstream service sử dụng;
• một Kafka consumer đọc;
• một dashboard query trực tiếp;
• một mobile application deserialize;
• một batch job chạy ban đêm phụ thuộc vào;
• một API external client sử dụng.

Ở góc nhìn local, Agent hoàn thành chính xác task.

Ở góc nhìn system, Agent vừa tạo ra một breaking change.

Một developer có kinh nghiệm khi nhìn vào yêu cầu này thường sẽ không chỉ hỏi:

Sửa file nào?

Họ sẽ hỏi:

Ai đang sử dụng contract này?

Đó chính là khoảng trống mà Development Harness phải bù lại.

Một Development Harness tốt phải liên tục cung cấp cho Agent những thứ như:

Architecture
Dependencies
Coding Convention
API Contracts
Schemas
Business Rules
Tests
Repository Structure
Known Constraints

Thay vì:

Task
 ↓
Agent
 ↓
Code

Chúng ta muốn:

                 Architecture
                      ↓
Dependencies → Agent ← Business Rules
                      ↑
              Tests / Constraints
                      ↓
                    Code

Mục tiêu là để Agent không chỉ biết làm thế nào để hoàn thành task, mà còn hiểu task đó đang tồn tại ở đâu trong toàn bộ hệ thống.

Đây cũng là lý do mình thấy context engineering ngày càng trở nên quan trọng khi sử dụng Coding Agent.

Prompt tốt chưa chắc đủ.

Agent cần một môi trường tốt.

Production Harness: Không phải thứ gì Agent làm được cũng nên được phép làm

Nếu Development Harness tập trung vào việc giúp Agent hiểu đúng hệ thống, Production Harness phải giải quyết một vấn đề khác:

Agent được phép làm đến đâu?

Có một ví dụ đời thường rất dễ hình dung.

Giả sử ai đó nói với một người bình thường:

Đi cướp ngân hàng đi.

Một người bình thường không tiếp nhận câu nói đó như một “task cần execute”.

Có rất nhiều control tồn tại trong đầu chúng ta:

Law
Ethics
Risk
Consequences
Social Norms
Authority

Nói cách khác, con người không chỉ hỏi:

Tôi có làm được không?

Mà còn hỏi:

Tôi có nên làm không?

Một AI Agent thì không nên được giả định rằng tự nhiên đã có đầy đủ những lớp kiểm soát đó.

Trong production, cùng một vấn đề xuất hiện dưới hình thức ít kịch tính hơn nhưng thực tế hơn rất nhiều.

Agent có thể có khả năng chạy:

DROP TABLE Customers;

Nhưng điều đó không có nghĩa Agent nên có quyền chạy câu lệnh đó.

Agent có thể restart Kubernetes cluster.

Không có nghĩa chúng ta nên đưa cluster-admin credential cho Agent.

Agent có thể approve payment.

Không có nghĩa Agent nên được phép approve mọi payment.

Điểm khác biệt nằm giữa:

Capability và Authority

Production Harness chính là lớp phân tách hai thứ đó.

Ba trụ cột quan trọng trong Production Harness

1. Execution Sandbox: Thiết kế với giả định Agent sẽ có lúc sai

Hãy tưởng tượng một intern mới vào công ty.

Chúng ta thường không đưa cho intern quyền:

Production Admin
Database Owner
Billing Admin
Organization Owner

Không phải vì chắc chắn intern sẽ làm sai.

Mà bởi vì nếu một sai lầm xảy ra, blast radius phải được kiểm soát.

AI Agent cũng nên được thiết kế theo nguyên tắc tương tự.

Ví dụ một Agent có nhiệm vụ điều tra incident.

Agent cần:

READ logs
READ metrics
READ deployment history

Agent không nhất thiết cần:

DELETE database
CHANGE IAM
ROTATE all secrets
DELETE cluster

Nếu Agent chỉ cần restart một pod:

restart pod

không có lý do gì để cấp:

cluster-admin

Nếu Agent chỉ cần tạo Pull Request:

create branch
commit code
open PR

không có lý do gì để cho Agent trực tiếp merge vào main và deploy production.

Execution Sandbox không khiến Agent reasoning tốt hơn.

Nó giải quyết một bài toán khác:

Nếu Agent reasoning sai thì nó có thể gây thiệt hại tới mức nào?

Đây là cách tiếp cận quen thuộc trong security:

Principle of Least Privilege

Agent chỉ nhận đúng số quyền cần thiết để hoàn thành nhiệm vụ.

Không hơn.

2. Computational vs Inferential Controls: Đừng dùng AI cho thứ vài dòng code đã giải quyết được

Đây có lẽ là phần mình thấy quan trọng nhất khi thiết kế Agent.

Khi có LLM trong tay, chúng ta rất dễ biến mọi thứ thành một prompt.

Nhưng không phải vấn đề nào cũng cần inference.

Hãy lấy permission làm ví dụ.

Chúng ta có rule:

Chỉ Admin được phép xóa user.

Một cách làm không tốt:

Prompt:
"Based on the user's profile and context,
decide whether this user should be allowed
to delete another user."

Không cần thiết.

Chúng ta đã có dữ liệu:

role = admin

Thì logic đúng chỉ cần:

if role == "admin":
    allow()
else:
    deny()

Đây là Computational Control.

Một số bài toán rất phù hợp với computational: permission check; schema validation; threshold; calculation; rate limit; timeout; retry count; format validation; deterministic business rule.

Chúng có đặc điểm: Fast, Cheap, Deterministic, Testable, Predictable.

Ngược lại, hãy tưởng tượng chúng ta có vài nghìn dòng log và muốn biết:

Pattern nào có khả năng giải thích incident này?

Không dễ viết:

if ...
else if ...
else if ...

cho tất cả trường hợp có thể xảy ra.

Đây là nơi Inferential Control có lợi thế.

LLM có thể đọc context, kết hợp nhiều nguồn dữ liệu và tạo ra hypothesis.

Ví dụ:

Logs
Metrics
Deployment History
Incident History
      ↓
     LLM
      ↓
Root Cause Hypothesis

Nhưng inference đi kèm ba chi phí: Probability, Latency, Cost.

Do đó, nguyên tắc mình rút ra là:

Computational nếu có thể.

Inferential khi cần thiết.

Human in the Loop khi impact đủ lớn.

Ví dụ Agent có thể tự đọc log và xác định:

Likely root cause:
Connection pool exhausted.

Đây là inferential.

Agent sau đó kiểm tra connection count:

Current connections = 100
Configured maximum = 100

Đây là computational.

Agent đề xuất tăng connection limit từ 100 lên 150.

Nếu đây là environment test, có thể tự động.

Nhưng nếu action tiếp theo là:

Modify production database configuration

hệ thống có thể yêu cầu:

Human Approval

Khi đó workflow trở thành:

Inferential
    ↓
Hypothesis
    ↓
Computational Validation
    ↓
Risk Evaluation
    ↓
Human Approval
    ↓
Execution

Đây là điểm mình thấy thú vị nhất.

Câu hỏi không còn là:

Có nên dùng AI không?

Mà là:

Phần nào của bài toán nên dùng AI?

3. Closed-loop Self-correction: Agent phải biết quan sát hậu quả của chính hành động của mình

Hãy tưởng tượng một developer viết code.

Developer chạy test.

FAIL

Thông thường developer sẽ không quay sang Product Manager và nói:

Code lỗi rồi. Đây là stack trace.

Developer sẽ:

Read Error
   ↓
Debug
   ↓
Fix
   ↓
Run Test Again

Đây là một feedback loop.

Một Agent cũng cần khả năng tương tự.

Một implementation đơn giản có thể là:

Execute
   ↓
Error
   ↓
Return Error to User

Nhưng đó chưa phải Agent thực sự tự vận hành.

Một workflow tốt hơn là:

Execute
   ↓
Observe
   ↓
Detect Failure
   ↓
Diagnose
   ↓
Correct
   ↓
Retry
   ↓
Verify

Ví dụ Agent deploy một service.

Deployment thành công nhưng health check trả về:

HTTP 500

Agent có thể tiếp tục:

Read Application Logs
        ↓
Detect Missing Environment Variable
        ↓
Compare with Deployment Manifest
        ↓
Correct Configuration
        ↓
Redeploy
        ↓
Health Check
        ↓
HTTP 200

Chỉ khi Agent vượt quá số lần retry hoặc cần thực hiện một action vượt quyền hạn thì mới escalate:

Agent
  ↓
Unable to recover safely
  ↓
Human

Đây là điểm khác nhau giữa một hệ thống AI-assisted và một hệ thống thực sự có khả năng agentic execution.

Agent không nhất thiết phải giải quyết những công việc khó nhất

Một insight khác khá thú vị là Agent đôi khi tạo ra nhiều giá trị nhất không phải ở những task phức tạp nhất.

Nó tạo ra giá trị ở những task có hai đặc điểm:

High Frequency
      +
High Waiting Time

Giả sử có một công việc chỉ cần năm phút để xử lý.

Ở góc độ developer, chúng ta có thể nghĩ:

Năm phút thì automation làm gì?

Nhưng giả sử một ngày có 100 request.

Mỗi người phải chờ trung bình hai tiếng trước khi request được xử lý.

Thời gian thao tác thực tế:

100 × 5 minutes
= 500 minutes
≈ 8.3 hours

Nhưng tổng thời gian waiting:

100 × 2 hours
= 200 hours

Bottleneck thực sự không nằm ở năm phút thao tác.

Nó nằm ở queue.

Đây là tư duy rất quen thuộc trong engineering.

Chúng ta tối ưu system throughput chứ không chỉ tối ưu execution time của một operation.

Agent đặc biệt phù hợp với những công việc như:

Ticket triage
Incident investigation
Document classification
Approval preparation
Data reconciliation
Log investigation
Routine support request
Repeated operational checks

Không phải vì từng task quá khó.

Mà vì tổng số lần lặp lại khiến chi phí của tổ chức trở nên rất lớn.

Case Study: Azure SRE Agent và giá trị của Agent ở quy mô production

Một ví dụ rất rõ cho bài toán này là Azure SRE Agent.

Theo bài viết chính thức của Microsoft về cách đội ngũ xây dựng và sử dụng Azure SRE Agent với agentic workflows, trong khoảng chín tháng Microsoft ghi nhận:

• Hơn 35.000 incident được Azure SRE Agent xử lý tự động;
• Hơn 50.000 giờ developer được tiết kiệm nhờ giảm thời gian điều tra và phản ứng thủ công;
• Azure Container Apps ghi nhận 89% phản hồi tích cực đối với kết quả Root Cause Analysis do Agent tạo ra, bao phủ hơn 90% incident;
• Azure App Service giảm time-to-mitigation của live-site incident xuống khoảng 3 phút, so với mức trung bình 40,5 giờ khi chỉ dựa vào hoạt động thủ công của con người.

Điểm mình quan tâm ở đây không chỉ là những con số.

Nếu nhìn bài toán dưới góc độ engineering, Azure SRE Agent đang giải quyết chính vấn đề đã nói ở trên:

Incident
   ↓
Collect Evidence
   ↓
Analyze
   ↓
Generate RCA
   ↓
Recommend / Execute Remediation
   ↓
Verify

SRE truyền thống phải thực hiện rất nhiều bước mang tính điều tra:

Open alert
Check dashboard
Search logs
Compare deployments
Read runbook
Check previous incidents
Build hypothesis
Test hypothesis

Mỗi bước có thể không mất quá nhiều thời gian.

Nhưng trong một tổ chức lớn, tổng lượng toil được nhân lên bởi hàng nghìn incident.

Khi Agent có thể thực hiện phần investigation ngay lập tức, giá trị lớn nhất không nhất thiết nằm ở việc Agent “thông minh hơn SRE”.

Nó nằm ở việc:

SRE không còn phải bắt đầu mọi incident từ con số 0.

Đây là một distinction rất quan trọng.

AI không nhất thiết thay thế expertise.

AI có thể nén thời gian cần thiết để expertise được áp dụng.

Harness không phải một lớp “safety” thêm vào sau cùng

Một sai lầm mình từng dễ mắc phải khi nghĩ về Harness là xem nó như một lớp guardrail đặt bên ngoài Agent.

Kiểu:

Build Agent
    ↓
Make It Smart
    ↓
Add Safety Later

Nhưng càng nhìn từ góc độ engineering, mình càng thấy Harness phải là một phần của architecture ngay từ đầu.

Có thể hình dung:

             ┌──────────── Context ────────────┐
             │                                 │
             │        ┌─────────────┐          │
Input ──────►│        │    Agent    │          │
             │        └──────┬──────┘          │
             │               │                 │
             │        Tool Selection           │
             │               │                 │
             │        Permission Check         │
             │               │                 │
             │        Risk Evaluation          │
             │               │                 │
             │   ┌───────────┴───────────┐     │
             │   │                       │     │
             │ Low Risk              High Risk│
             │   │                       │     │
             │ Execute              Human Gate│
             │   │                       │     │
             │ Observe ◄─────────────────┘     │
             │   │                             │
             │ Self-Correct                    │
             │                                 │
             └─────────────────────────────────┘

Agent chỉ là một component.

Production system mới là sản phẩm thực sự.

Từ Coding sang Engineering Judgment

Điều cuối cùng mình suy nghĩ nhiều nhất sau khi tìm hiểu về Harness không phải là AI Agent.

Mà là vai trò của developer.

Trong nhiều năm, giá trị của developer gắn rất chặt với khả năng:

Write Code
Debug
Write Tests
Refactor
Implement Requirements

Những công việc đó vẫn tồn tại.

Nhưng AI đang làm chúng nhanh hơn từng ngày.

Một Coding Agent có thể tạo boilerplate trong vài giây.

Có thể viết test.

Có thể refactor.

Có thể đọc stack trace.

Có thể tạo Pull Request.

Vậy developer còn lại gì?

Mình nghĩ câu hỏi này hơi sai.

Câu hỏi đúng hơn là:

Khi execution ngày càng rẻ, phần nào của engineering trở nên giá trị hơn?

Câu trả lời mình đang dần thấy rõ hơn là judgment.

Developer cần hiểu:

What is the actual problem?

What should be deterministic?

What requires inference?

What requires human judgment?

What permissions does the Agent need?

What is the blast radius if it is wrong?

How do we validate its decision?

How does it know it failed?

When should it retry?

When should it stop?

When should a human take over?

Nếu trước đây developer nhận một requirement rồi nghĩ:

Tôi sẽ code feature này như thế nào?

Thì trong hệ thống có AI, câu hỏi có thể trở thành:

Feature này thực sự cần code deterministic, AI inference hay con người?

Đó là một level abstraction khác.

Ví dụ một workflow:

Customer Request
      ↓
Classification
      ↓
Business Rule
      ↓
Decision
      ↓
Action

Developer thế hệ trước có thể implement toàn bộ bằng code.

Developer trong Agentic Engineering có thể thiết kế:

Customer Request
      ↓
LLM Classification
      ↓
Deterministic Validation
      ↓
Risk Scoring
      ↓
┌───────────────┐
│               │
Low Risk     High Risk
│               │
Agent        Human
│               │
└───────┬───────┘
        ↓
      Action

Giá trị của developer không còn nằm ở việc viết từng dòng code của flow đó.

Giá trị nằm ở việc quyết định ranh giới giữa các thành phần.

AI không chỉ tự động hóa công việc. Nó nâng abstraction level của developer.

Khi compiler xuất hiện, developer không cần viết machine code nữa.

Khi cloud xuất hiện, phần lớn developer không cần tự quản lý physical server nữa.

Khi framework xuất hiện, chúng ta không cần viết lại authentication, routing hay dependency injection từ đầu.

Mỗi lớp abstraction mới đều lấy đi một phần công việc cũ.

Nhưng đồng thời, nó cho phép developer giải quyết những bài toán lớn hơn.

AI có thể là một bước dịch chuyển tương tự.

Machine Code
     ↓
High-level Language
     ↓
Framework
     ↓
Cloud
     ↓
AI-assisted Development
     ↓
Agentic Engineering

Nếu AI đảm nhận nhiều phần execution hơn, developer phải dịch chuyển sang những công việc có giá trị cao hơn:

Problem Framing
System Design
Architecture
Trade-off
Risk Management
Evaluation
Human Judgment

Và đây là điểm mình thấy quan trọng nhất.

Nếu toàn bộ công việc của một developer có thể được mô tả thành một tập rule cố định, nó có khả năng dần được thay thế bằng Computational System.

Nếu công việc chủ yếu là đọc context rồi tạo ra output có thể chấp nhận một mức sai số nhất định, nó có khả năng được chuyển sang Inferential System.

Phần còn lại của developer sẽ ngày càng tập trung vào nơi cần:

Context
Responsibility
Trade-off
Risk
Judgment

Tức là những nơi Human in the Loop thực sự tạo ra giá trị.

Kết luận

Ban đầu khi nhìn vào AI Agent, mình nghĩ bài toán chủ yếu là chọn model tốt hơn, viết prompt tốt hơn và cung cấp nhiều context hơn.

Nhưng càng đi sâu, mình càng thấy Agent production thực chất là một bài toán software engineering quen thuộc dưới một hình thức mới.

Chúng ta vẫn phải giải quyết:

Reliability
Security
Permissions
Validation
Observability
Failure Recovery
Human Oversight

Chỉ khác là lần này, ở trung tâm hệ thống có một component mang tính xác suất.

Model tạo ra capability.

Nhưng Harness mới biến capability đó thành một hệ thống có thể vận hành.

Và có lẽ mindset quan trọng nhất không phải là:

Làm sao để Agent không bao giờ sai?

Mà là:

Khi Agent sai, hệ thống của chúng ta có đủ tốt để phát hiện, giới hạn, sửa chữa và phục hồi hay không?

Đó cũng là cách mình đang nhìn lại vai trò của developer trong kỷ nguyên AI.

AI đang hỗ trợ ngày càng nhiều những công việc mà trước đây chúng ta phải tự thực hiện.

Điều đó không làm engineering trở nên ít quan trọng hơn.

Ngược lại, khi execution trở nên rẻ hơn, khả năng hiểu vấn đề, thiết kế hệ thống và đưa ra judgment đúng trở nên đắt giá hơn.

Nếu phải tóm lại toàn bộ bài viết bằng một câu, mình sẽ chọn:

Đừng chỉ xây một Agent đủ thông minh để làm đúng. Hãy xây một hệ thống đủ tốt để vẫn an toàn khi Agent làm sai.