DEV Community

Cover image for Sử Dụng Máy Tính So Với API Cấu Trúc: Ưu Điểm Từng Loại (2026)
Sebastian Petrus
Sebastian Petrus

Posted on • Originally published at apidog.com

Sử Dụng Máy Tính So Với API Cấu Trúc: Ưu Điểm Từng Loại (2026)

Điều khiển trình duyệt bằng LLM thông qua các mô hình “computer use” có thể tốn kém hơn khoảng 45 lần so với gọi cùng một nhà cung cấp qua API có cấu trúc.

Dùng thử Apidog hôm nay

Bài viết này phân tích vì sao khoảng cách chi phí đó xuất hiện, khi nào computer use vẫn đáng dùng, và cách thiết kế workflow AI agent nhanh hơn, rẻ hơn với Apidog. Khung ra quyết định bên dưới áp dụng cho OpenAI Operator, Anthropic computer use, browser agents, Skyvern và các công cụ dùng vòng lặp chụp màn hình tương tự.

Nếu bạn viết API cho AI agent, hãy đọc thêm hướng dẫn về cách viết tệp agents.md. Các quy ước trong đó giúp API có cấu trúc trở thành lựa chọn mặc định rõ ràng cho agent.

Tóm tắt

  • Computer use: LLM xem ảnh chụp màn hình rồi tạo thao tác nhấp chuột, gõ phím, cuộn.
  • API có cấu trúc: LLM tạo lệnh gọi công cụ JSON, backend của bạn thực thi.
  • Với cùng một tác vụ, computer use thường tiêu tốn nhiều token hơn 30–50 lần vì mỗi bước cần ảnh chụp màn hình mới và có thể phải retry.
  • Chỉ dùng computer use khi không có API, API bị giới hạn, hoặc workflow nằm sau giao diện không thể script hóa ổn định.
  • Dùng API có cấu trúc cho thanh toán, tìm kiếm, cập nhật CRM, công cụ nội bộ và mọi thứ có thể mô tả bằng OpenAPI.
  • Cách thực tế nhất là hybrid: API xử lý phần có endpoint; computer use chỉ xử lý phần còn lại.
  • Dùng Apidog để thiết kế JSON schema, mock endpoint và replay workflow trước khi tiêu tốn credit agent.

Vì sao khoảng cách chi phí lớn?

Con số 45 lần không đến từ benchmark phức tạp. Nó đến từ cách hai phương pháp tiêu thụ token.

Với API có cấu trúc, agent gửi:

  1. Yêu cầu của người dùng.
  2. Schema của tool.
  3. Nhận lại JSON.
  4. Backend gọi API thật.

Một lượt thường chỉ gồm vài trăm token đầu vào, vài chục token đầu ra và một request mạng.

Với computer use, agent phải lặp lại vòng sau:

  1. Gửi prompt và ảnh chụp màn hình.
  2. Model trả về thao tác: click, type, scroll.
  3. Runtime thực thi thao tác.
  4. Chụp màn hình mới.
  5. Gửi lại cho model.

Một tác vụ như “đặt vé máy bay” hoặc “lọc thanh toán thất bại trong dashboard” có thể cần 12–30 vòng. Mỗi ảnh chụp màn hình thường tương đương khoảng 1.500 token ở độ phân giải thông thường. Thêm retry, click sai, banner cookie, scroll sai vị trí — chi phí tăng rất nhanh.

Tài liệu computer use của Anthropic công khai cách tính token ảnh chụp màn hình. Chủ đề HN Computer use is 45x more expensive than structured APIs cũng đưa ra mức phạt điển hình 30–50 lần, phù hợp với kết quả khi phát lại cùng một tác vụ qua hai cách trong Apidog.

Khi nào API có cấu trúc thắng?

Mặc định hãy chọn API có cấu trúc nếu workflow rơi vào một trong các trường hợp sau.

1. Nhà cung cấp có OpenAPI, GraphQL hoặc REST docs

Nếu đã có JSON shape, LLM có thể điền tham số vào schema.

Ví dụ:

{
  "customer_id": "cus_123",
  "status": "active",
  "limit": 100
}
Enter fullscreen mode Exit fullscreen mode

Lỗi khi gọi tool thường dễ phát hiện và retry hơn nhiều so với lỗi click sai trong UI.

2. Tác vụ chỉ cần một hoặc hai endpoint

Các tác vụ sau không nên đi qua trình duyệt:

  • Tạo customer trong Stripe.
  • Cập nhật deal stage trong HubSpot.
  • Gửi tin nhắn Slack.
  • Trigger CI rerun.
  • Tìm invoice theo email.
  • Cập nhật trạng thái ticket.

Nếu tác vụ có thể là một HTTP request, hãy để nó là một HTTP request.

3. Workflow chạy tự động

Cron job, webhook handler và queue worker không phù hợp với vòng lặp screenshot. Chúng cần request có tính xác định, log được và retry được.

4. Độ trễ quan trọng

API call có cấu trúc thường trả về trong 200–800ms.

Computer use với 15 vòng có thể mất 30–90 giây, lâu hơn nếu retry.

5. Bạn cần test trước khi triển khai

Mock một endpoint JSON trong Apidog mất vài phút. Mock một browser screenshot loop ổn định là một bài toán phức tạp hơn nhiều.

Khi nào computer use vẫn đáng dùng?

Computer use không phải lúc nào cũng sai. Nó phù hợp khi UI là bề mặt duy nhất bạn có thể dùng.

1. Portal cũ không có API

Một số cổng mua sắm, logistics, bảo hiểm, phúc lợi hoặc hệ thống nội bộ cũ chỉ có giao diện web, thường nằm sau session ASP.NET hoặc cơ chế xác thực khó tích hợp.

Trong trường hợp này, computer use có thể thay thế script Selenium dễ vỡ. Trả chi phí token cao hơn đôi khi vẫn rẻ hơn bảo trì script mỗi quý.

2. Công cụ nội bộ không thể sửa đổi

Ví dụ:

  • CRM cũ.
  • ERP legacy.
  • SharePoint dashboard.
  • Admin portal do vendor quản lý.

Nếu bạn không thể thêm API và nhóm không muốn mua iPaaS, computer use là phương án thực tế.

3. Tác vụ một lần hoặc khối lượng rất thấp

Ví dụ: “Nghiên cứu 50 đối thủ và đưa highlight vào Notion.”

Nếu tác vụ chạy một lần, chi phí gấp 45 lần có thể vẫn chỉ là vài xu. Không đáng xây integration nhiều tuần cho một workflow sẽ không lặp lại.

4. Scraping vi phạm điều khoản

Nếu yêu cầu là “dùng computer use để cào dữ liệu từ site này”, hãy kiểm tra điều khoản dịch vụ trước. Chi phí token có thể không phải vấn đề lớn nhất.

Khung quyết định nhanh

Trước khi dùng computer use, chạy qua bốn câu hỏi sau:

Kiểm tra Nếu có Nếu không
Có API được tài liệu hóa không? Dùng API. Tiếp tục.
Có thể viết adapter server-side mỏng để bọc endpoint riêng tư không? Xây adapter và expose JSON. Tiếp tục.
Tác vụ là một lần hoặc khối lượng thấp, ví dụ dưới 100 lần/ngày không? Computer use có thể chấp nhận được. Tiếp tục.
Bạn chấp nhận chi phí token cao hơn 30–50 lần cho mỗi lần chạy không? Dùng computer use. Dừng lại và thương lượng quyền truy cập API.

Phần lớn workflow không vượt qua câu hỏi 1 hoặc 2. Computer use chỉ nên tồn tại khi cả hai hướng đó đều không khả thi.

API có cấu trúc trông như thế nào trong agent?

Ví dụ: lấy các khoản thanh toán thất bại của ngày hôm qua.

Thay vì mở dashboard Stripe bằng trình duyệt, agent nên gọi tool có schema rõ ràng.

import json
from openai import OpenAI

client = OpenAI()

tools = [
    {
        "type": "function",
        "function": {
            "name": "list_failed_payments",
            "description": "List failed payments in a date range",
            "parameters": {
                "type": "object",
                "properties": {
                    "start": {
                        "type": "string",
                        "format": "date"
                    },
                    "end": {
                        "type": "string",
                        "format": "date"
                    }
                },
                "required": ["start", "end"]
            }
        }
    }
]

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {
            "role": "user",
            "content": "Show yesterday's failed payments."
        }
    ],
    tools=tools,
    tool_choice="auto"
)

call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)

payments = stripe.PaymentIntent.list(
    created={
        "gte": args["start"],
        "lte": args["end"]
    },
    limit=100
)
Enter fullscreen mode Exit fullscreen mode

Luồng này có:

  1. Prompt của user.
  2. Tool schema.
  3. JSON arguments từ model.
  4. Một HTTP request đến Stripe.

Agent không cần nhìn thấy dashboard.

Phiên bản computer use sẽ phải:

  1. Mở trình duyệt.
  2. Đăng nhập Stripe.
  3. Chụp screenshot dashboard.
  4. Click date picker.
  5. Chụp screenshot lại.
  6. Chọn khoảng ngày.
  7. Chụp screenshot.
  8. Lọc trạng thái “failed”.
  9. Scroll.
  10. Trích xuất số liệu từ pixel.

Mỗi screenshot thêm khoảng 1.500 token đầu vào. 12 vòng là bình thường. Chi phí tăng mạnh và độ ổn định giảm.

Thiết kế API có cấu trúc với Apidog

Lý do nhiều nhóm dùng computer use không phải vì họ muốn trả nhiều tiền hơn. Thường là vì chưa ai thiết kế một tool surface sạch cho agent.

Apidog giúp bạn làm việc đó theo hướng contract-first.

Bước 1: Mô hình hóa operation agent cần

Tạo project trong Apidog và định nghĩa các endpoint agent cần gọi.

Ví dụ:

POST /payments/failed/search
POST /crm/deals/update-stage
POST /notifications/slack/send
POST /invoices/list
Enter fullscreen mode Exit fullscreen mode

Mỗi endpoint nên có:

  • Request body rõ ràng.
  • Response schema rõ ràng.
  • Error schema.
  • Ví dụ dữ liệu thực tế.

Bước 2: Xuất OpenAPI 3.1

Apidog có thể tạo OpenAPI 3.1 từ chế độ thiết kế. Schema này trở thành contract cho agent.

Các framework phổ biến đều có thể dùng schema tương tự:

  • OpenAI tools.
  • Anthropic tool use schema.
  • LangChain OpenAPI loader.
  • Các agent runtime tự viết.

Bước 3: Bật mock server

Mock server của Apidog trả về JSON thực tế cho từng endpoint. Nhờ đó bạn có thể chạy agent end-to-end mà chưa cần:

  • Môi trường production.
  • API key thật.
  • Chi phí cho workflow thật.
  • Dữ liệu khách hàng thật.

Cách tiếp cận này cũng được trình bày trong hướng dẫn contract-first development của Apidog.

Bước 4: Replay traffic

Khi agent chạy, ghi lại request và response để so sánh:

  • Run thành công gọi tool nào?
  • Run thất bại lệch ở tham số nào?
  • Schema có thiếu field không?
  • Agent có fallback sang browser không?

Đây là cách debug vấn đề “hôm qua agent chạy được, hôm nay bị hỏng”.

Bước 5: Triển khai và giám sát

Cùng một project Apidog có thể đóng vai trò:

  • API documentation.
  • Contract test.
  • Mock server.
  • Nơi review schema.
  • Bề mặt tool cho agent.

Hybrid: khi cần cả hai phương pháp

Trong production, nhiều agent sẽ là hybrid.

Một cấu hình hợp lý:

  • 90% operation đi qua API có cấu trúc.
  • 10% fallback sang computer use cho portal cũ.
  • Router quyết định dùng tool hay browser agent.

Ví dụ system instruction đơn giản:

Nếu operation nằm trong known_tools, hãy gọi tool tương ứng.
Nếu không có tool phù hợp, hãy chuyển cho browser agent.
Không dùng browser agent khi đã có structured tool.
Enter fullscreen mode Exit fullscreen mode

Anthropic Claude 4.5 và OpenAI GPT-5.5 có thể xử lý kiểu routing này đáng tin cậy. Bạn cũng có thể áp dụng cùng mô hình với DeepSeek V4; xem cách sử dụng API DeepSeek V4 để biết shape request.

Theo dõi hai nhóm riêng biệt:

  • Structured API calls.
  • Computer use runs.

Một tỷ lệ lành mạnh có thể là:

  • Structured calls: 99% volume, 30% cost.
  • Computer use: 1% volume, 70% cost.

Nếu tỷ lệ đảo ngược, có thể bạn đang thiếu endpoint và cần thiết kế thêm tool trong API surface.

Lỗi thường gặp cần tránh

Bỏ qua schema

Đừng chỉ viết prompt văn xuôi kiểu:

You can update payments when needed.
Enter fullscreen mode Exit fullscreen mode

Hãy truyền JSON Schema rõ ràng:

{
  "type": "object",
  "properties": {
    "payment_id": {
      "type": "string"
    },
    "status": {
      "type": "string",
      "enum": ["failed", "succeeded", "pending"]
    }
  },
  "required": ["payment_id", "status"]
}
Enter fullscreen mode Exit fullscreen mode

Schema nghiêm ngặt giúp model tạo tool call chính xác hơn.

Để agent tự thiết kế schema lúc runtime

Schema là bề mặt sản phẩm. Hãy version, review và test nó như API public.

Đừng để agent tự sửa schema trong production.

Chỉ log token, không log chi phí

Token của computer use nằm nhiều trong input hình ảnh. Một số observability tool định giá phần này khác với dashboard billing của provider.

Hãy kiểm tra billing thực tế từ provider, không chỉ token count nội bộ.

Nhầm computer use với RPA

RPA chạy script click cố định trên DOM hoặc selector đã biết.

Computer use quyết định lại thao tác dựa trên từng screenshot.

  • RPA: rẻ hơn, lặp lại tốt hơn, nhưng dễ vỡ khi UI đổi.
  • Computer use: linh hoạt hơn, đắt hơn, chậm hơn.

Nếu RPA đủ dùng, đừng dùng computer use.

Quên chi phí độ trễ

Token gấp 45 lần là một phần vấn đề. Phần còn lại là trải nghiệm người dùng.

Một screenshot loop 60 giây sẽ làm agent rời khỏi flow tương tác. Nếu user đang chờ kết quả, gần như luôn nên ưu tiên API.

Các lựa chọn thay thế trước khi dùng computer use

Nếu vendor không có API public nhưng có UI, hãy cân nhắc ba lựa chọn trung gian.

1. Headless browser script

Dùng Playwright hoặc Puppeteer.

Ưu điểm:

  • Không tốn token mỗi lần chạy.
  • Có thể chạy nhanh.
  • Dễ tích hợp CI.

Nhược điểm:

  • Dễ hỏng khi UI đổi.
  • Cần bảo trì selector.

2. Connector từ Zapier hoặc Make

Nếu vendor đã có connector, iPaaS đã trả chi phí tích hợp thay bạn.

Bạn trả phí nền tảng nhưng triển khai nhanh hơn.

3. API riêng tư được quan sát từ DevTools

Nhiều dashboard gọi endpoint JSON nội bộ. Bạn có thể quan sát tab Network trong DevTools, sau đó tài liệu hóa endpoint đó trong Apidog.

Cách này nên được xem là bán ổn định vì vendor có thể thay đổi endpoint. Xem thêm kiểm thử API mà không cần Postman.

Computer use nên là phương án cuối cùng, không phải mặc định.

Các trường hợp thực tế

Một nhóm compliance fintech thay báo cáo Stripe 6 bước bằng ba structured call. Chi phí token giảm 92% và thời gian chạy giảm từ 41 giây xuống 2 giây.

Một agent hỗ trợ SaaS B2B chỉ giữ computer use cho một workflow duy nhất: portal mua sắm của vendor không có API. Mọi workflow còn lại đi qua OpenAPI tool được thiết kế trong Apidog. Tổng chi tiêu token giảm từ 4.200 USD xuống 310 USD mỗi tháng.

Một founder độc lập dùng computer use đúng một lần mỗi tuần để làm mới Notion dashboard từ ERP cũ. Chi phí gấp 45 lần cho một lần chạy mỗi tuần chỉ là vài xu. Xây integration nhiều tuần sẽ không hợp lý trong trường hợp đó.

Kết luận

Con số 45 lần là đủ lớn để thay đổi cách bạn thiết kế agent.

Mặc định hãy dùng API có cấu trúc được thiết kế trong Apidog. Chỉ dùng computer use khi không có API và workflow chạy đủ ít để chi phí token không đáng kể.

Năm điểm cần nhớ:

  • Computer use thường tốn nhiều hơn 30–50 lần token so với API có cấu trúc.
  • Endpoint được tài liệu hóa cộng với JSON Schema thắng screenshot loop về chi phí, độ trễ và độ tin cậy.
  • Hybrid là mô hình thực tế: thiết kế phần lớn workflow trong Apidog, fallback sang computer use cho phần còn lại.
  • Mock tool surface trước khi nối với model thật để tiết kiệm credit và rút ngắn vòng lặp test.
  • Theo dõi structured calls và computer use riêng biệt để phát hiện khi tỷ lệ chi phí thay đổi.

Bước tiếp theo: mở Apidog, tạo project cho tool surface của agent và bật mock server. Trong vòng một giờ, bạn sẽ biết workflow định triển khai bằng computer use có thể rút gọn thành vài structured call hay không.

Câu hỏi thường gặp

Computer use có bao giờ rẻ hơn API có cấu trúc không?

Không, nếu tính theo từng lần chạy. Token ảnh chụp màn hình thường chiếm phần lớn chi phí.

Computer use chỉ có thể rẻ hơn tổng thể khi chi phí xây tích hợp API lớn hơn chi phí vận hành trong thời gian dài. Điều này thường chỉ đúng với workflow khối lượng rất thấp và không có API.

Làm cách nào để mock tool JSON cho agent?

Thiết kế endpoint trong Apidog, bật mock server tích hợp và trỏ agent đến mock URL.

Mỗi request sẽ trả về JSON thực tế mà không cần gọi production API. Xem thêm workflow trong các công cụ kiểm thử API dành cho kỹ sư QA.

Có thể dùng OpenAPI cho tool call trong mọi model không?

Có. OpenAI tools, Anthropic tool_use và endpoint gọi tool của DeepSeek V4 đều có thể làm việc với schema kiểu OpenAPI 3.1.

Apidog xuất schema rõ ràng. Xem cách sử dụng API DeepSeek V4 để biết shape request của DeepSeek.

GPT-5.5 có còn hỗ trợ computer use không?

OpenAI cung cấp computer use qua Operator và Responses API. Hồ sơ chi phí tương tự Anthropic vì cả hai đều phải xử lý screenshot theo từng vòng.

Khuyến nghị trong bài viết này áp dụng bất kể provider.

Còn Skyvern, browser agents và các agent mã nguồn mở thì sao?

Tương tự. Chúng có thể giảm giá mỗi lần gọi bằng model rẻ hơn, nhưng vẫn cần nhiều vòng screenshot.

Khi đã có API, structured API vẫn vượt trội về chi phí, độ trễ và độ ổn định.

Làm sao biết agent đang thiếu endpoint?

Theo dõi các lần agent fallback sang browser.

Nếu agent liên tục cố dùng trình duyệt cho cùng một operation, đó là dấu hiệu tool surface đang thiếu endpoint. Thêm endpoint đó vào Apidog, tạo lại schema và agent sẽ không cần fallback nữa.

Top comments (0)