Intent-to-Transaction Compiler

Trình duyệt cho agent không phải một trình duyệt — nó là một transaction compiler

Trình duyệt dành cho agent nên làm cho việc "duyệt web" dần biến mất. Agent không cần những trang để ghé thăm; nó cần resource để phân giải, capability để gọi và hậu quả để xác minh. Rendering không biến mất hoàn toàn, nhưng bị hạ xuống thành bằng chứng kiểm tra, debug hoặc human review — không còn là giao diện chính.

Tác giả: Lương Quốc Dũng Bằng chứng: các failure thật khi vận hành PAM/MindPal qua browser MCP

00Manifesto

Sáu lập trường — mỗi lập trường có thể sai, và bắt nguồn từ những lần chính hệ thống này (Claude vận hành browser thay người) từng gặp lỗi thật trên PAM/MindPal.

1

Không có một "visual truth" duy nhất cho agent. Pixel có thể rỗng, text có thể bỏ sót canvas, DOM có thể đúng cấu trúc nhưng sai ngữ nghĩa; trạng thái phải đi kèm provenance, confidence và conflict.

2

Agent-first browser phải chạy được trên web cũ, không được chờ web viết lại. Legacy inference là đường mặc định hiện tại; Semantic State Contract là fast path có thẩm quyền hơn khi website chủ động hỗ trợ.

3

Semantic State Contract sẽ xuất hiện trước ở nơi agent tạo ra giá trị giao dịch. Nhưng contract không phải một cánh cửa mở: nó có thể là cánh cổng buộc agent xác thực danh tính, chịu quota, trả phí và để lại audit trail; còn các website sống bằng attention có thể tiếp tục từ chối agent.

Browser có thể chạy ở mọi nơi, nhưng chất lượng agent experience sẽ không đồng đều — và "agent-native web" không nhất thiết cởi mở hơn web hiện tại, nó có thể dễ thao tác hơn nhưng bị kiểm soát và định giá chặt hơn.

4

Agent điều hướng bằng mục tiêu và state transition, không bằng việc bắt chước con người click link. URL, selector và tab ID chỉ là chi tiết thực thi của compatibility layer; resource/action graph mới là navigation model.

5

Agent không được giả làm người dùng. Nó cần danh tính riêng, quyền được ủy nhiệm có scope, quota và hạn dùng; CAPTCHA "chứng minh không phải bot" phải nhường chỗ cho xác thực agent có thể kiểm chứng.

6

Memory không phải bản sao của trang web, và action API không dừng ở HTTP 200. Browser nhớ resource, ý định và audit history — nhưng phải xác minh lại mọi trạng thái mutable, và mọi hành động phải phân biệt "đã gửi" với "đã xảy ra" trước khi agent hành động tiếp.

01Intent-to-Transaction Compiler

Từ ý định đến giao dịch có thể xác minh. Chín bước, có vòng lặp verify → memory — không phải luồng thẳng chạy một lần rồi kết thúc.

Các tầng của compiler Agent nhận mục tiêu ("Hủy đơn ORD-1024") rồi biên dịch nó thành chuỗi: resolve resource → verify current state → obtain delegated permission → execute typed action → verify consequence. Trong mô hình này: Semantic State Contract là "ngôn ngữ máy" của web mới; resource/action graph là chương trình trung gian; Action API là tầng thực thi; còn DOM, screenshot và click chỉ là Browser Compatibility Runtime — legacy emulator để chạy trên web cũ.
1 · Agent intentNhận mục tiêu ("hủy đơn ORD-1024"), không nhận chuỗi click cố định
2 · Delegated AuthXác minh danh tính riêng của agent, cấp token scope hẹp, có hạn dùng
3 · Memory ResolverLấy stable resource ID, lịch sử, audit trail; state cũ chỉ là snapshot cần xác minh lại
4 · Goal NavigatorDùng resource/action graph để tìm đường tới trạng thái cần thiết
5 · Web capability check
native
Site Contract
legacy
Browser Compatibility Runtime
DOM · Text · Pixel
6 · Semantic State ResolverChuẩn hóa thành resource, state, state_version, available_actions, provenance, confidence, conflicts
7 · Policy & Action GatewayKiểm token scope, precondition, approval receipt, quota, idempotency key
native
8a · Site Action APIThực thi action có cấu trúc, site trả kết quả trực tiếp
legacy
8b · Browser Action ExecutorAutomation (click/fill/submit) trên DOM, không có API để gọi thẳng
9 · Verify outcomeNative: đọc response trực tiếp. Legacy: postcondition verification — quan sát lại DOM/network sau hành động để suy luận hậu quả, vì không có xác nhận chính chủ. Cả hai phân biệt confirmed / pending_confirmation / failed
↻ quay lại Memory Resolver (bước 3) — cập nhật hoặc re-plan nếu state đã đổi

Rendering nằm ở capability check/state resolver (bước 5–6); navigation ở Goal Navigator (bước 4); auth ở Delegated Auth (bước 2); memory ở Memory Resolver (bước 3, và vòng lặp về từ bước 9); action API nằm sau Policy Gateway (bước 7–9).

Native và legacy không hội tụ vào cùng một cơ chế thực thi Trên web cũ, Site Action API thường không tồn tại — legacy path phải thao tác qua Browser Action Executor (click, điền form, submit), không phải gọi API có cấu trúc. Vì vậy state_version trên legacy không phải version do site cung cấp — nó là một fingerprint/hash suy luận từ trạng thái quan sát được (DOM + network), giúp phát hiện thay đổi nhưng không đảm bảo atomicity tuyệt đối như version chính chủ từ contract. Sau khi thực thi trên legacy, hệ thống phải làm postcondition verification — quan sát lại trạng thái để suy luận hậu quả — vì không có xác nhận trực tiếp từ site như native path.

02DOM/rendering → nguồn chân lý là gì

Bằng chứng — ba lần thất bại thật Screenshot/pixel: báo chụp thành công nhưng ảnh trả về rỗng. Text extraction: dễ đọc nhưng bỏ sót nội dung vẽ trên canvas. DOM/accessibility tree: có cấu trúc nhưng chưa chắc đúng ý nghĩa hành động — click vào grid row lại chọn checkbox thay vì mở detail.

Không có pixel, text hay DOM nào đủ làm source of truth tuyệt đối. Browser cho agent nên lấy semantic application state làm nguồn chân lý chính: trang đang ở resource nào, trạng thái nào, hành động nào hợp lệ, input nào đang được yêu cầu, kết quả dự kiến là gì.

Hai con đường, không đối xứng thẩm quyền

PathVai tròAi tạo ra
Legacy path
Browser Compatibility Runtime
Mặc định hiện nay. Runtime tự xây ObservedState bằng cách hợp nhất DOM/accessibility tree, text, network events và pixel/canvas — không phải "sự thật tuyệt đối" mà là trạng thái quan sát được, có confidence và provenance.Browser tự suy luận
Native pathFast path lý tưởng, có thẩm quyền hơn khi tồn tại.Site chủ động công bố SemanticStateContract, vì chỉ họ biết chính xác resource, business state và action semantics
Adapter pathCho site quan trọng nhưng chưa hỗ trợ native. Vẫn là lớp diễn giải, không có độ tin cậy ngang contract chính chủ.Browser hoặc bên thứ ba, theo domain
{
  "resource": {"type": "order", "id": "ORD-1024"},
  "state": "awaiting_payment",
  "available_actions": ["pay", "cancel"],
  "source": "legacy_inference",
  "evidence": ["dom", "network", "accessibility"],
  "confidence": 0.82,
  "conflicts": ["canvas_total_not_observed"]
}

Nếu cùng dữ liệu đến từ contract chính chủ, source là site_contract, kèm version và schema — hai con đường không giả vờ có độ tin cậy như nhau.

Ai có động lực công bố contract

Có động lựcÍt/không có động lực
SaaS B2B, thương mại điện tử, đặt vé, logistics, banking, dịch vụ công — agent hoàn thành task = tăng conversion, giảm chi phí hỗ trợ, xử lý giao dịch nhanh hơnBáo chí sống bằng quảng cáo, social network, nền tảng bán dữ liệu, website chống scraping — agent lấy nội dung mà không tạo page view hoặc làm mất lợi thế dữ liệu

Contract không nhất thiết mở miễn phí — site có thể yêu cầu auth, quota, tính phí, giới hạn action và ghi nhận giao dịch do agent mang tới.

04Auth

  • Danh tính riêng, không giả làm người: agent dùng danh tính được người dùng ủy quyền, không cầm toàn bộ credential để giả làm người — quyền, audit và thu hồi được tách riêng.
  • CAPTCHA lỗi thời với agent hợp lệ: "chứng minh không phải bot" không còn phù hợp. Cơ chế chính nên là danh tính agent có chữ ký số; authorization, quota và chống abuse áp dụng sau khi xác thực.
  • Token scope hẹp, có hạn: có thể cho phép tìm vé/tạo booking draft nhưng payment: false. Muốn vượt scope hoặc tạo side effect phải xin quyền mới.
{
  "token_type": "delegated_agent_token",
  "agent_id": "agent:pam-scheduler-07",
  "principal": "user:123",
  "scope": ["orders:read", "orders:cancel"],
  "resource_scope": "order:ORD-1024",
  "payment": false,
  "issued_at": "2026-08-03T11:40:00Z",
  "expires_at": "2026-08-03T12:05:00Z",
  "revocable_at": "/agent/v1/tokens/revoke"
}

Cùng một hình dạng interface (JSON có field máy đọc được) xuyên suốt cả ba lớp: state (mục 02), token (ở đây) và action (mục 06) — không lớp nào để agent tự suy đoán ý nghĩa từ văn bản tự do.

05Memory

LớpNên lưu gìCách dùng
Trong sessionMục tiêu hiện tại, plan, bước đã chạy, resource đang xử lý, kết quả tool, action đang chờWorking memory để tránh lặp và tiếp tục đúng bước
Giữa các sessionÝ định chưa hoàn thành, stable resource ID, artifact, audit log, quyền đã cấp, preference lâu dàiTìm lại công việc, không dùng như trạng thái hiện tại
Không nên persistTab ID, DOM selector, vị trí scroll, page state tạm, token hết hạn, kết luận mutable như awaiting_paymentDễ mất hiệu lực hoặc gây hành động sai
{
  "resource_id": "ORD-1024",
  "observed_state": "awaiting_payment",
  "state_version": 17,
  "observed_at": "2026-07-27T10:00:00Z",
  "source": "legacy_inference"
}

Khi quay lại, browser dùng resource_id để resolve resource mới và đọc lại trạng thái hiện tại. Nếu state_version đã đổi hoặc snapshot quá TTL, memory chỉ được dùng làm lịch sử, không dùng để ra action — agent nhận state mới rồi re-plan.

Nguyên tắc Nhớ danh tính của resource và lịch sử công việc; luôn xác minh lại trạng thái có thể thay đổi trước khi hành động.

06Action API — ví dụ: hủy đơn ORD-1024

Request cần chứng minh bốn thứ: agent là ai, được cấp quyền gì, đang tác động lên resource nào, và hành động dựa trên phiên bản state nào.

POST /agent/v1/actions/execute
Authorization: Bearer <delegated_short_lived_token>
Idempotency-Key: act_8f31
Content-Type: application/json

{
  "action": "orders.cancel",
  "resource": { "type": "order", "id": "ORD-1024" },
  "preconditions": { "expected_state": "awaiting_payment", "state_version": 17 },
  "input": { "reason": "ordered_by_mistake" },
  "approval": {
    "receipt_id": "approval_274",
    "approved_by": "user:123",
    "scope": "order:ORD-1024",
    "expires_at": "2026-08-03T12:05:00Z"
  }
}

Đã xác nhận thành công

{
  "action_id": "act_8f31",
  "execution": { "status": "confirmed", "certainty": "confirmed", "executed_at": "2026-08-03T11:52:14Z" },
  "resource": { "type": "order", "id": "ORD-1024", "state": "cancelled", "state_version": 18 },
  "effects": [{ "type": "order_cancelled", "reversible": false }],
  "available_actions": ["orders.view", "orders.reorder"],
  "audit_receipt": "audit_9812"
}

Đã nhận, chưa xác nhận hoàn tất

{
  "action_id": "act_8f31",
  "execution": { "status": "accepted", "certainty": "pending_confirmation", "status_url": "/agent/v1/actions/act_8f31" },
  "resource": { "type": "order", "id": "ORD-1024", "state": "cancellation_pending", "state_version": 18 }
}

Agent không được nói "đã hủy" khi response mới là accepted. Nó phải poll/subscribe tới khi nhận confirmed hoặc failed.

Precondition thất bại — đơn đã ship

{
  "error": {
    "code": "PRECONDITION_FAILED",
    "message": "Order can no longer be cancelled because it has shipped.",
    "retryable": false
  },
  "expected": { "state": "awaiting_payment", "state_version": 17 },
  "current": { "state": "shipped", "state_version": 21 },
  "available_actions": [
    { "action": "orders.track", "requires_approval": false },
    { "action": "orders.request_return", "requires_approval": true }
  ],
  "recovery_hint": "Refresh the resource state and re-plan using an available action."
}
Vì sao Idempotency-Key Nếu request hủy đơn timeout, agent có thể gửi lại mà không biết lần đầu đã tới server chưa. Cùng một key buộc server trả lại kết quả cũ thay vì thực hiện side effect lần hai.
Điểm cốt lõi API phải phân biệt request đã nhận với hậu quả đã được xác nhận, đồng thời trả state mới và action thay thế để agent tự lập lại kế hoạch khi precondition không còn đúng.

07Giới hạn & điều tôi không hứa

  • Đây là manifesto và thiết kế — không phải khảo sát toàn diện về mọi loại website hay mọi mô hình auth hiện có.
  • Bằng chứng nền tảng (screenshot rỗng, canvas bị bỏ sót, click sai ngữ nghĩa, tab ID đổi giữa session) đến từ một số lượng nhỏ lần vận hành PAM/MindPal thật — không phải khảo sát quy mô lớn trên nhiều loại web khác nhau.
  • Giả định "site có động lực kinh tế sẽ công bố contract" chưa được kiểm chứng bằng dữ liệu thị trường thật — đây là suy luận từ logic động lực, không phải quan sát hành vi thực tế của các công ty.
  • Semantic State Contract là đề xuất thiết kế cho tương lai; phần lớn web hiện nay sẽ tiếp tục chạy qua legacy inference trong một thời gian dài, có thể là vĩnh viễn với các loại site không có động lực.