Tối ưu Agent Loop: Harness, API và inference

Trả lời nhanh: tối ưu Agent Loop là giảm công việc lặp giữa model, tool và ứng dụng mà vẫn tăng tỷ lệ hoàn thành tác vụ. Ba lớp chính là harness xây context và kiểm soát hành động, API giữ state và vận chuyển item hiệu quả, inference quản lý KV cache cùng GPU. KPI đúng là chi phí, độ trễ và lỗi trên mỗi tác vụ thành công.

Cập nhật lần cuối: 20/08/2026

Một chatbot đơn giản có thể cần một lượt gọi model. Một coding agent hoặc research agent có thể lặp hàng chục vòng:

1. đọc yêu cầu;
2. tìm dữ liệu;
3. gọi tool;
4. đọc kết quả;
5. sửa kế hoạch;
6. gọi tool tiếp;
7. kiểm tra;
8. trả kết quả.

Nếu mỗi vòng gửi lại prompt khổng lồ, nạp mọi tool, chờ nhiều network hop và tính lại ngữ cảnh, chi phí sẽ nhân theo số bước. Model giỏi hơn có thể giảm vòng lặp, nhưng hệ thống xung quanh quyết định phần lớn trải nghiệm và hóa đơn.

ByteByteGo phân tích các kỹ thuật được báo cáo ở ba lớp: harness, API và inference. Tài liệu chính thức của OpenAI xác nhận vai trò của agent harness, vòng lặp tool, trạng thái Responses API và việc giữ reasoning context. Những chi tiết hạ tầng không có trong tài liệu chính thức được trình bày ở đây như thông tin do ByteByteGo báo cáo, không phải cam kết API công khai.

Tối ưu Agent Loop là gì?

Tối ưu Agent Loop là cải thiện toàn bộ chu kỳ model suy luận, yêu cầu hành động, ứng dụng thực thi, trả kết quả và model tiếp tục cho tới điểm dừng.

Tài liệu OpenAI Agents SDK mô tả một vòng chạy:

1. gọi model với input đã chuẩn bị;
2. kiểm tra output;
3. nếu có tool call, thực thi rồi tiếp tục;
4. nếu có handoff, chuyển agent;
5. nếu có final answer và không còn tool work, trả kết quả.

Vòng lặp này có thể do ứng dụng tự quản với Responses API hoặc do Agents SDK runner quản lý. Dù dùng framework nào, hệ thống vẫn cần quyết định context, tool, state, giới hạn, approval và điều kiện dừng.

Vì sao nên đo cost per successful task?

Giá mỗi triệu token chỉ phản ánh một đơn vị tài nguyên. Người dùng trả tiền cho kết quả: sửa bug qua test, xử lý ticket đúng, hoàn thành báo cáo hoặc tạo chiến dịch đạt yêu cầu.

Hai agent có thể dùng cùng model:

• Agent A dùng 20 vòng, gọi sai tool ba lần và thất bại 30%.
• Agent B dùng 8 vòng, xác minh sớm và hoàn thành 90%.

Agent B có thể đắt hơn mỗi token nhưng rẻ hơn trên mỗi kết quả đúng.

Công thức vận hành đơn giản:

Cost per successful task
= tổng chi phí model + tool + hạ tầng + review
  / số tác vụ đạt tiêu chí

Scorecard nên theo dõi thêm:

• task success rate;
• số model turn trung bình;
• tool call success và retry;
• input, cached input, output token;
• time to first action và total latency;
• human intervention rate;
• lỗi an toàn hoặc rollback;
• chi phí ở p50, p95 và p99.

Tối ưu token mà làm task success giảm là tối ưu sai mục tiêu.

Harness là gì trong kiến trúc agent?

OpenAI định nghĩa harness là hệ thống thực thi bao quanh model, giúp agent hiểu nhiệm vụ, duy trì context, gọi tool, hiển thị tiến độ, xử lý lỗi, xin phê duyệt và trả kết quả. Codex harness chính thức quản lý conversation state, streaming, tool use, sandbox và approval policy.

Harness thường sở hữu:

• developer instructions;
• chọn và mô tả tool;
• context builder;
• conversation state;
• tool executor;
• sandbox và permission;
• retry, timeout và budget;
• output validation;
• tracing và progress event;
• human approval;
• stop condition.

Model dự đoán hành động. Harness biến dự đoán đó thành một quy trình có giới hạn và có thể quan sát.

Harness tối ưu context như thế nào?

Giữ prefix ổn định

Prompt caching hoạt động tốt khi phần đầu request giống nhau. Đặt instruction, tool definition và context ổn định ở đầu; dữ liệu thay đổi đặt sau. Tránh chèn timestamp, ID ngẫu nhiên hoặc thứ tự tool thay đổi vào prefix nếu không cần.

Stable prefix giúp hệ thống tăng khả năng tái sử dụng cache. ByteByteGo báo cáo đây là một kỹ thuật trong agent stack được phân tích. Ở cấp ứng dụng, nguyên tắc có thể áp dụng độc lập với nhà cung cấp.

Không gửi mọi thứ ở mọi vòng

Context nên là working set, không phải kho lưu trữ. Phân loại:

• invariant instruction;
• state quyết định hiện tại;
• tool output gần nhất;
• bằng chứng cần cho bước kế tiếp;
• dữ liệu có thể truy xuất lại;
• lịch sử đã lỗi thời.

Compaction tóm tắt phần cũ thành state có cấu trúc. Tài liệu OpenAI về Codex harness cho biết retained reasoning và context compaction có thể thay đổi đáng kể kết quả trên một benchmark cụ thể, đồng thời giảm output token. Đây là bằng chứng rằng harness design là biến số chất lượng, không chỉ biến số chi phí.

Deferred tool discovery

Nếu agent có hàng trăm tool, đưa mọi JSON schema vào prompt làm tăng token và gây khó chọn. Deferred discovery dùng catalog hoặc search để chỉ nạp mô tả chi tiết của nhóm tool liên quan khi cần.

Luồng điển hình:

Nhiệm vụ
  -> tìm tool phù hợp trong catalog
  -> nạp schema của 2-5 tool
  -> thực thi

Lợi ích là prompt nhỏ và không gian hành động rõ hơn. Chi phí là thêm một bước discovery, nên cần cache kết quả và đánh giá accuracy của tool search.

Programmatic tool calling

Khi model cần thực hiện nhiều thao tác có cấu trúc, nó có thể tạo một đoạn chương trình gọi nhiều primitive thay vì quay lại model sau từng phép biến đổi nhỏ. ByteByteGo gọi hướng này là Code Mode trong bài phân tích.

Ví dụ, thay vì:

model -> lấy file A -> model -> lấy file B -> model -> lọc -> model -> tính tổng

có thể là:

model -> chạy chương trình đọc A, B, lọc và tính -> model kiểm tra kết quả

Điều này giảm round trip nhưng làm mỗi tool execution mạnh hơn. Cần sandbox, time limit, network policy, file scope và output cap.

API layer tối ưu điều gì?

API layer nằm giữa harness và model serving. Nó nhận request, xác thực, quản lý state, tokenization, tool item, streaming và routing tới hạ tầng inference.

Responses API giữ cấu trúc agentic ra sao?

OpenAI mô tả Responses API là loop có cấu trúc cho reasoning và acting. Response có nhiều loại item như message, function call và function call output. Ứng dụng có thể dùng previous_response_id, conversation hoặc tự quản history.

Tài liệu OpenAI phân biệt:

• dùng Responses API khi ứng dụng muốn sở hữu loop và branching;
• dùng Agents SDK khi muốn SDK quản lý vòng lặp, handoff, session, tracing và approval.

Sự lựa chọn là mức abstraction, không phải hai kiến trúc đối lập.

Giữ reasoning state có lợi gì?

Với workflow nhiều function call, nếu mỗi lượt làm model bắt đầu suy luận lại, token và lỗi có thể tăng. OpenAI khuyến nghị giữ các reasoning item liên quan qua previous_response_id hoặc state phù hợp để model không phải khởi động lại reasoning sau tool call.

Official OpenAI documentation công bố trong một đánh giá nội bộ rằng GPT-5 qua Responses đạt kết quả TAUBench cao hơn 5% so với Chat Completions khi tận dụng preserved reasoning. Con số này thuộc thiết lập của OpenAI và không bảo đảm cho mọi use case, nhưng nó cho thấy state transport có thể ảnh hưởng chất lượng.

Delta processing và kết nối lâu dài

ByteByteGo báo cáo hai nhóm tối ưu hạ tầng:

• chỉ xử lý phần conversation mới thay vì token hóa lại mọi thứ khi có thể;
• dùng kết nối persistent để giảm handshake và network overhead giữa nhiều lượt.

Đây không phải contract mà mọi API client tự động nhận giống nhau. Khi xây hệ thống riêng, bài học là dùng state identifier, streaming hoặc persistent transport khi nền tảng hỗ trợ, thay vì tự gửi lại toàn bộ payload khổng lồ ở mỗi bước.

Chạy kiểm tra an toàn song song

Một pipeline tuần tự safety -> inference -> output safety cộng toàn bộ latency. ByteByteGo mô tả việc một số kiểm tra có thể chạy song song với inference để ẩn bớt độ trễ, sau đó chặn output trước khi trả nếu cần.

Không phải mọi safety check đều có thể song song. Authorization và kiểm tra quyền trước tool call phải hoàn thành trước hành động. Hãy phân biệt:

• check có thể speculative;
• check bắt buộc trước xử lý;
• check bắt buộc trước side effect;
• check có thể hậu kiểm.

Tối ưu latency không được làm mất fail-closed cho hành động rủi ro cao.

Inference layer tối ưu Agent Loop ra sao?

Agent loop tạo đặc điểm tải khác chat một lượt: nhiều request liên tiếp có prefix giống, output ngắn xen kẽ tool call và context tăng dần. Inference có thể tận dụng tính liên tục này.

Cache-aware routing

Nếu request tiếp theo được đưa về worker còn giữ KV cache hoặc prefix cache, hệ thống giảm tính lại. ByteByteGo báo cáo cache-aware routing là một kỹ thuật trong stack được phân tích.

Thách thức là cân bằng cache locality với load balancing. Đưa mọi request về một worker nóng có thể gây queue dài; phân tán đều lại làm mất cache hit.

KV cache management

KV cache lưu key và value của token cũ. Context agent càng dài và concurrency càng cao, cache càng tốn VRAM. Engine cần paging, eviction, quota và scheduling phù hợp. Xem phân tích chi tiết tại Chi phí bộ nhớ LLM.

Speculative decoding

Một model draft nhỏ đề xuất nhiều token, model chính kiểm tra chúng theo batch. Nếu nhiều token được chấp nhận, hệ thống giảm số bước decode tuần tự. Hiệu quả phụ thuộc tỷ lệ chấp nhận, độ dài output, phần cứng và overhead chạy model draft.

Đây là tối ưu serving. Nó không thay đổi semantics của agent loop ở tầng ứng dụng, nhưng có thể giảm time per output token.

Tách prefill và decode

Prefill xử lý prompt dài và thiên về compute. Decode tạo từng token, thường nhạy với memory bandwidth và latency. Tách hai pha ra pool phần cứng hoặc scheduling khác nhau có thể tăng utilization.

Với agent, nhiều lượt có prefill lớn nhưng output chỉ là tool call ngắn. Tối ưu prefill, cache prefix và state reuse vì vậy đặc biệt quan trọng.

Ba lớp tối ưu liên quan nhau thế nào?

Lớp	Quyết định	Chỉ số chính
Harness	Context nào, tool nào, khi nào dừng	Turn count, token/task, tool success
API	State, item, transport, streaming	Payload, round trip, cacheability
Inference	Routing, cache, batching, hardware	TTFT, TPOT, throughput, VRAM

Ví dụ harness thay đổi thứ tự tool definition mỗi lượt có thể phá prompt prefix. API gửi request tới worker ngẫu nhiên có thể mất locality. Inference cache tốt không cứu được một agent gọi sai tool 10 lần.

Tối ưu phải end-to-end.

Quy trình 8 bước tối ưu Agent Loop

Bước 1: Định nghĩa một tác vụ thành công

Dùng tiêu chí kiểm chứng được: test pass, ticket cập nhật đúng, báo cáo có nguồn, hoặc người duyệt chấp nhận. Không dùng “model đã trả lời”.

Bước 2: Thu trace theo logical task

Ghi model turn, tool call, token, cached token, latency, retry, approval và final outcome. Correlation ID phải đi qua mọi lớp.

Bước 3: Tìm vòng lặp lãng phí

Phân loại: model hỏi lại, tool trả quá nhiều, schema gây chọn sai, context trùng, retry không cần, hoặc điều kiện dừng kém.

Bước 4: Sửa harness trước

Rút instruction, giữ prefix ổn định, chỉ nạp tool liên quan, tóm tắt state và validate sớm. Đây là lớp nằm trong quyền kiểm soát của sản phẩm.

Bước 5: Chọn state strategy

Với OpenAI, chọn một trong history tự quản, session, conversation hoặc previous response ID theo kiến trúc. Tài liệu cảnh báo trộn local replay với server-managed state có thể làm trùng context nếu không chủ đích reconcile.

Bước 6: Giảm round trip an toàn

Song song hóa tool độc lập, batch thao tác đọc và dùng programmatic tool calling khi có sandbox. Không song song hai write phụ thuộc nhau.

Bước 7: Tối ưu model và inference

Chọn model theo task success, thử reasoning effort, prompt caching, routing và serving config. So sánh trên cùng harness và eval set.

Bước 8: Canary bằng cost per success

Đưa một phần traffic, đo chất lượng, latency, lỗi và chi phí. Giữ rollback. Một thay đổi giảm token nhưng tăng escalation cần bị loại.

Nên tối ưu gì trước cho AI Agency?

Thứ tự thực dụng:

1. Giảm số vòng vô ích: sửa tool contract và stop condition.
2. Giảm context: retrieval đúng, output tool gọn, state có cấu trúc.
3. Tăng cacheability: prefix ổn định và version rõ.
4. Giảm round trip: parallel read và batch operation.
5. Chọn model/router: dùng model mạnh cho bước khó, model nhỏ cho bước ổn định.
6. Tối ưu hạ tầng: chỉ khi volume đủ để justify.

Đừng bắt đầu bằng speculative decoding nếu agent chưa có eval, loop vô hạn và tool schema mơ hồ. Tối ưu ở tầng thấp chỉ làm hệ thống sai chạy nhanh hơn.

Các anti-pattern phổ biến

Nạp toàn bộ tool catalog

Prompt lớn và model khó chọn. Dùng phân nhóm, search hoặc specialist.

Gửi lại toàn bộ history đã có state server

Có thể nhân đôi context. Chọn một chiến lược state và kiểm tra input token thực tế.

Tool trả payload thô khổng lồ

API response nhiều MB biến thành token ở lượt sau. Tool nên hỗ trợ filter, pagination, projection và summary có provenance.

Retry model cho lỗi xác định

Nếu tool trả schema validation error, sửa tham số hoặc dừng. Gọi lại cùng input chỉ đốt token.

Không có max turn và budget

Agent có thể loop vì tool lỗi, instruction xung đột hoặc không biết dừng. Đặt hard limit và degradation path.

Chỉ đo latency model

Người dùng trải nghiệm queue, network, tool, approval và rendering. Trace tổng end-to-end.

Bảng chỉ số production đề xuất

Nhóm	Chỉ số
Outcome	Task success, human acceptance, rollback rate
Loop	Turn/task, tool calls/task, repeated call rate
Token	Input, cached input, output, token/success
Latency	Time to first action, tool latency, total p95/p99
Cost	Model, tool, infra, review trên task thành công
Safety	Block, approval, policy violation, unauthorized call
Reliability	Timeout, retry, resume success, stuck loop

Mỗi optimization phải nêu metric chính và guardrail. Ví dụ giảm tool definitions nhằm giảm input token, nhưng guardrail là tool selection accuracy không giảm quá ngưỡng.

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

Tối ưu Agent Loop có phải chỉ giảm token không?

Không. Token là một phần. Mục tiêu là tăng xác suất hoàn thành đúng với latency, chi phí và rủi ro chấp nhận được.

Harness có phải prompt không?

Không. Prompt là một thành phần. Harness còn quản lý state, tool, sandbox, approval, retry, trace và điều kiện dừng.

Responses API và Agents SDK khác nhau thế nào?

Theo OpenAI Docs, Responses API phù hợp khi ứng dụng muốn sở hữu loop; Agents SDK phù hợp khi muốn SDK quản lý loop, handoff, session, tracing và approval.

Giữ reasoning state có lộ chain of thought không?

Không mặc định. OpenAI mô tả reasoning state được giữ nội bộ và có thể tiếp tục bằng response ID hoặc reasoning item mà không lộ raw chain of thought cho client.

Tool gọi song song có luôn nhanh hơn không?

Không. Chỉ song song thao tác độc lập. Write có phụ thuộc, rate limit hoặc shared resource có thể gây race và lỗi khó phục hồi.

Khi nào nên tự host inference?

Khi volume, compliance, model control và năng lực vận hành đủ lớn để bù chi phí GPU, scheduling, reliability và đội ngũ. Đa số team nên tối ưu harness và eval trước.

Tóm lại

Tối ưu Agent Loop là công việc hệ thống. Harness quyết định model nhìn gì và được làm gì. API quyết định state cùng cách các bước nối nhau. Inference quyết định cache, scheduling và tốc độ token. Mỗi lớp có thể tiết kiệm một phần; hiệu quả lớn đến từ các cải tiến cộng dồn.

Năm nguyên tắc nên áp dụng:

1. đo cost per successful task thay vì chỉ giá token;
2. giảm số vòng sai trước khi tối ưu từng vòng;
3. giữ context nhỏ, liên quan và cache-friendly;
4. chọn một chiến lược state rõ ràng;
5. đánh giá end-to-end với guardrail an toàn.

Để đi sâu vào cache và serving, đọc Chi phí bộ nhớ LLM. Với tool có side effect, Idempotency là gì? giúp retry an toàn. Bài Rủi ro AI Agent bổ sung governance và quyền phê duyệt.

Nguồn tham khảo

• How ChatGPT Optimizes its Agent Loop, ByteByteGo.
• Codex as a platform, OpenAI.
• Why we built the Responses API, OpenAI.
• Running agents, OpenAI Docs.
• Reasoning best practices, OpenAI Docs.

Đọc tiếp

• Chi phí bộ nhớ LLM
• Idempotency là gì?
• Rủi ro AI Agent trong marketing