Hiểu về Thinking Effort trong AI Agent: Điều lập trình viên cần biết

Hiểu về Thinking Effort trong AI Agent

Phần I · Thử thách những giả định phổ biến

Vì sao bảo AI “nghĩ kỹ hơn” không phải lúc nào cũng cho kết quả tốt hơn.

Một thiết lập thinking effort thực sự thay đổi điều gì, và khi nào bạn nên tăng nó? Bộ slide này đi theo câu hỏi đó qua 21 slide: khái niệm, sự khác biệt giữa reasoning và việc thực thi của agent, các tình huống kỹ thuật thực tế, một kiến trúc production, và cách quyết định dựa trên bằng chứng thay vì trực giác.

Cùng model. Cùng prompt. Kết quả khác nhau?

Phần I · Thử thách những giả định phổ biến

Bạn chạy hai lần một yêu cầu trông như y hệt nhau, một lần ra câu trả lời gọn gàng, lần sau lại rối. Trước khi đổ lỗi cho một thiết lập, hãy liệt kê mọi thứ đã thay đổi. Có những task chỉ có một lối đi hiển nhiên và được giải trực tiếp. Có những task có nhiều lối đi hợp lý, và câu trả lời tốt hơn khi hệ thống cân nhắc kỹ hơn hoặc thu thập thêm bằng chứng.

• Độ phức tạp và tính mơ hồ của task quyết định có bao nhiêu câu trả lời hợp lý.
• Context có sẵn và đầu ra của tool quyết định model thực sự có thể biết gì.
• Tính ngẫu nhiên khi sampling khiến hai lần chạy cùng một prompt có thể khác nhau.
• Hành vi model và cấu hình đều quan trọng, và effort chỉ là một phần của cấu hình.

Thinking effort cao hơn không tự động có nghĩa là thông minh hơn

Phần I · Thử thách những giả định phổ biến

Có ba giả định phổ biến, và mỗi cái sai theo một cách hữu ích:

1. “Effort cao hơn luôn cho câu trả lời tốt hơn.” Nó có thể giúp ở một số task. Nó không đảm bảo tính đúng đắn, và với task dễ thì chủ yếu chỉ tốn thêm chi phí.
2. “Nghĩ lâu hơn nghĩa là suy luận sâu và chính xác hơn.” Độ dài không phải chất lượng. Một chuỗi suy luận dài vẫn có thể dài mà sai.
3. “Nhiều bước agent hơn làm agent giỏi hơn.” Nhiều bước hơn có thể cộng dồn lỗi dễ như sửa lỗi.

Thinking effort nói về tài nguyên suy luận, không chỉ là chờ lâu hơn

Phần II · Nền tảng kỹ thuật

Thinking effort là một cơ chế điều khiển riêng của từng model hoặc nền tảng, nếu có, ảnh hưởng đến lượng nỗ lực dành cho việc suy luận về một task. Đó là một thiết lập trên API công khai. Nó không phải cửa sổ nhìn vào bên trong model.

Vậy cùng một từ mang nghĩa khác nhau trên các API khác nhau. Đừng giả định mỗi mức tương ứng một số token, số bước hay lượng tính toán cố định.

Độ phức tạp của task nên ảnh hưởng đến reasoning effort

Phần II · Nền tảng kỹ thuật

Task A chuyển một object JSON thành TypeScript interface. Đầu ra nhìn là kiểm tra được. Cân nhắc thêm hiếm khi thay đổi nó.

Task B là một race condition thỉnh thoảng xảy ra trong hệ thống phân tán. Ở đây suy luận có chủ đích có thể đáng giá: so sánh các giả thuyết, cân nhắc trường hợp biên và nối hành vi giữa các thành phần.

Nhưng độ phức tạp không phải trục duy nhất. Một task ngắn với hậu quả nghiêm trọng, như migration dữ liệu production, có thể đáng được suy luận cẩn thận, kiểm tra thêm hoặc con người review, dù nó dễ mô tả.

Suy luận của model và việc thực thi của agent là hai thứ khác nhau

Phần II · Nền tảng kỹ thuật

Thinking effort là phần suy luận được áp dụng trong một lần gọi model, khi model và API hỗ trợ cơ chế này.

Agent loop là chu trình bên ngoài: model nhận context, tạo ra một phản hồi hoặc một tool call, nhận kết quả tool, và tiếp tục cho đến khi gặp điều kiện dừng (ReAct là mô tả kinh điển về việc đan xen suy luận với hành động).

Hai thứ này thay đổi độc lập. Một lần gọi có thể chứa rất nhiều suy luận mà không dùng tool. Một agent có thể thực hiện hàng chục tool call trong khi mỗi bước riêng lẻ đều đơn giản.

Một AI agent không chỉ là một model

Phần II · Nền tảng kỹ thuật

Luồng khái niệm: task và context của người dùng → model suy luận → quyết định trả lời hoặc gọi tool → thực thi tool → context được cập nhật → quyết định tiếp theo. Nó lặp lại cho đến khi task xong hoặc gặp điều kiện dừng.

Effort tác động lên một bước của vòng lặp này, phần suy luận bên trong lần gọi model. Hiệu năng tổng thể còn phụ thuộc vào chất lượng context, có những tool nào, cách harness điều phối retry và việc dừng, và liệu có thứ gì kiểm chứng kết quả hay không. Slide 15 biến vòng lặp này thành một kiến trúc tham chiếu cho production.

Các mức effort khác nhau là các đánh đổi khác nhau

Phần II · Nền tảng kỹ thuật

	Effort thấp hơn	Effort cao hơn
Latency	thường thấp hơn	thường cao hơn
Chi phí	thường thấp hơn	thường cao hơn
Task khó, nhiều bước	có thể kém kỹ lưỡng hơn	có thể kỹ lưỡng hơn
Task đơn giản	thường là đủ	lợi ích ít, vẫn tốn hơn

Đây là xu hướng, không phải đảm bảo. Khoảng cách lớn đến đâu phụ thuộc vào model, task và cách đo. Bài này không đưa ra con số cải thiện nào vì không con số nào khái quát được; slide 16 và 17 chỉ cách tự tạo số liệu của bạn.

Khi nào thinking effort cao hơn đáng giá?

Phần III · Tình huống kỹ thuật thực tế

Một API thỉnh thoảng trả về HTTP 500. Một model có reasoning effort cao hơn có thể giỏi hơn trong việc giữ nhiều giả thuyết cùng lúc, kiểm tra các dependency và cân nhắc trường hợp biên. Nó vẫn không đọc được log mà không ai thu thập.

Một quy trình tốt xen kẽ suy luận với quan sát:

1. Tạo giả thuyết, và nói rõ bằng chứng nào sẽ xác nhận hoặc bác bỏ từng giả thuyết.
2. Thu thập bằng chứng đó (log, metric, trace).
3. Cập nhật giả thuyết. Bỏ những gì bằng chứng bác bỏ.
4. Áp dụng bản sửa, rồi kiểm chứng triệu chứng đã hết.

Một thay đổi một dòng và một đợt refactor toàn hệ thống không cần cùng một chiến lược

Phần III · Tình huống kỹ thuật thực tế

• Đổi tên một biến cục bộ. Chủ yếu là cơ học. Trình biên dịch hoặc bộ test là đủ để chốt.
• Refactor authentication middleware. Suy luận phải bao quát nơi gọi, hệ quả bảo mật, tương thích ngược và các test chứng minh hành vi được giữ nguyên.
• Điều tra regression sau khi deploy. Suy luận chỉ tốt bằng những gì nó đọc được: diff, log, kết quả test và lịch sử thay đổi gần đây.

Chọn đúng cơ chế cho đúng vấn đề

Phần III · Tình huống kỹ thuật thực tế

Khi một agent làm sai, “nghĩ kỹ hơn” chỉ là một trong nhiều đòn bẩy, và không phải lúc nào cũng đúng.

• Nếu model chưa cân nhắc các giả thuyết hiện có, tăng reasoning effort có thể giúp.
• Nếu nó thiếu thông tin về repository, một tool tìm kiếm sẽ giúp nhiều hơn việc nghĩ thêm.
• Nếu một kết quả test phản bác giả thuyết ban đầu, thêm một vòng lặp agent với kết quả đó là bước đúng.
• Nếu task quá rộng, chia nhỏ giúp nhiều hơn bất kỳ thiết lập đơn lẻ nào.

Một lời giải thích thuyết phục không phải bằng chứng của tính đúng đắn

Phần III · Tình huống kỹ thuật thực tế

Model có thể đưa ra kết luận nghe hợp lý nhưng sai vì thiếu thông tin, giả định sai hoặc các giới hạn khác. Độ trôi chảy của một lời giải thích nói rất ít về việc nó có đúng hay không.

Với coding agent, kiểm chứng nghĩa là các cơ chế cụ thể: test tự động, kiểm tra kiểu và lint, đọc diff được tạo ra, xem log và kết quả thực thi, đối chiếu tiêu chí chấp nhận, và chạy kiểm tra bảo mật khi phù hợp. Hãy đánh giá chất lượng của các kiểm tra đó độc lập với việc phần suy luận trông sâu đến đâu.

Chất lượng, latency và chi phí

Phần IV · Hệ thống production

• Chất lượng: tính đúng, hoàn thành task, độ bền vững và xử lý trường hợp biên.
• Latency: thời gian phản hồi, và tổng thời gian hoàn thành một task.
• Chi phí: mức dùng model, chi phí inference liên quan đến reasoning nếu có, tool call, và trên hết là tổng chi phí cho mỗi task thành công.

Mục tiêu không phải chất lượng tối đa bằng mọi giá, hay latency tối thiểu bằng mọi giá. Đó là một đánh đổi chấp nhận được cho workload và yêu cầu kinh doanh của nó. Ba chiều này không quy được về một điểm số chung.

Chi phí có ba lớp, và mỗi lớp trả lời một câu hỏi khác nhau:

Lớp	Đếm những gì	Con số đến từ đâu
Lần gọi model	Input, cached input, output và reasoning token, nhân với giá mỗi token của nhà cung cấp	Object usage của mỗi response, và trang giá của nhà cung cấp
Lần chạy agent	Mọi lần gọi model trong lần chạy, cộng với thực thi tool, retry, thời gian sandbox hoặc CI, và review của con người	Trace và hóa đơn hạ tầng của bạn
Kết quả task	Tổng chi phí và thời gian, chia cho số task đã qua kiểm chứng	Kết quả đánh giá của bạn

Effort tác động lên lớp thứ nhất, nhưng quyết định thuộc về lớp thứ ba. Một thiết lập làm mỗi lần gọi rẻ hơn có thể làm task đắt hơn nếu các lần chạy thất bại thường hơn và cần retry, hoặc cần một người, để hoàn thành.

Đừng mặc định dùng effort tối đa cho mọi yêu cầu

Phần IV · Hệ thống production

Chiến lược thích ứng coi effort là quyết định theo từng task: nhận task, đánh giá độ phức tạp, độ bất định và rủi ro, chọn một thiết lập được hỗ trợ, thực thi, kiểm chứng, và leo thang, thử lại hoặc thu thập thêm bằng chứng nếu kiểm chứng thất bại.

Việc định tuyến có thể dùng quy tắc, bộ phân loại, router dựa trên model, hoặc chính sách dựa trên phản hồi.

Hai lưu ý. Việc phân loại task có thể sai, nên hãy đánh giá router như mọi thành phần khác. Và chỉ dùng các mức effort mà model hay API đã chọn hỗ trợ.

Kiến trúc tham chiếu cho agent loop

Phần IV · Hệ thống production

Vấn đề	Cơ chế kiểm soát đề xuất
Vòng lặp chạy mất kiểm soát	Ngân sách số bước, token và thời gian thực, kiểm tra trước mỗi lần gọi model
Vòng lặp không tiến triển	Dừng khi cùng một tool call với cùng tham số lặp lại, hoặc cùng một kiểm tra liên tục thất bại
Tool lỗi và timeout	Mỗi tool một timeout. Chỉ retry các tool idempotent. Trả lỗi và timeout về cho model như kết quả; đừng giấu chúng
Hành động có hệ quả	Một policy cho mỗi tool: cho phép tool chỉ đọc, hỏi người trước khi ghi, deploy, xóa hoặc thanh toán, từ chối phần còn lại. Chạy code trong sandbox
Context	Thêm mỗi kết quả tool cùng trạng thái của nó; cắt bớt đầu ra lớn và giữ con trỏ tới artifact đầy đủ
Khả năng quan sát	Một trace span cho mỗi lần gọi model, tool call và kiểm tra, ghi lại thiết lập effort và lượng token dùng
Kết quả cuối	Chỉ chấp nhận những gì qua verifier

const LIMITS = { maxSteps: 30, maxOutputTokens: 400_000, maxWallClockMs: 15 * 60_000, maxRepeats: 3 };

async function runTask(task: Task): Promise<RunResult> {
  const ctx = newContext(task);
  const startedAt = Date.now();
  let outputTokens = 0;

  for (let step = 1; step <= LIMITS.maxSteps; step++) {
    if (outputTokens > LIMITS.maxOutputTokens || Date.now() - startedAt > LIMITS.maxWallClockMs) {
      return { outcome: "stopped", reason: "budget_exhausted", suspected: "orchestration" };
    }

    // The only place the effort setting acts.
    const turn = await trace("model_call", () => callModel(ctx, { effort: chooseEffort(task) }));
    outputTokens += turn.usage.outputTokens;

    if (turn.kind === "answer") {
      const check = await trace("verify", () => verify(task, turn.answer));
      if (check.passed) return { outcome: "verified", answer: turn.answer, check };
      ctx.append({ type: "verification_failed", findings: check.findings });
      continue;
    }

    const call = turn.toolCall;
    if (repeatCount(ctx, call) >= LIMITS.maxRepeats) {
      return { outcome: "stopped", reason: "no_progress", suspected: "reasoning" };
    }

    const policy = toolPolicy(call); // "allow" | "ask" | "deny"
    if (policy === "deny" || (policy === "ask" && !(await askHuman(call)))) {
      ctx.append({ type: "tool_denied", call });
      continue;
    }

    // Retry only idempotent tools; errors and timeouts go back to the model as results.
    const result = await trace("tool_call", () =>
      runTool(call, { timeoutMs: 60_000, retries: call.idempotent ? 2 : 0 }),
    );
    ctx.append({ type: "tool_result", call, result });
  }

  return { outcome: "stopped", reason: "step_limit", suspected: "orchestration" };
}

Gắn nhãn mọi lần chạy thất bại theo loại hỏng đầu tiên, bằng cách đọc trace của nó. Reasoning: dữ kiện đã có trong context mà kế hoạch vẫn sai. Thực thi tool: một lỗi, một timeout, hoặc đầu ra sai. Orchestration: mất context, một vòng lặp, hoặc cạn ngân sách. Kiểm chứng: một kiểm tra bị thiếu, chập chờn hoặc sai. Trường suspected trong code chỉ là phỏng đoán đầu tiên; trace mới là thứ quyết định.

Đo xem effort cao hơn có thực sự giúp ích không

Phần IV · Hệ thống production

Hãy xây một bộ đánh giá đại diện cho workload thật của bạn: các task thật, mỗi task có một verifier được viết trước khi bạn nhìn vào bất kỳ kết quả nào. Rồi so sánh các thiết lập mà model hỗ trợ trong điều kiện chỉ khác nhau ở effort.

Giữ mọi thứ khác không đổi. Cố định và ghi lại:

• ID snapshot của model và phiên bản SDK;
• system prompt, định nghĩa tool và phiên bản harness;
• context mà mỗi task bắt đầu: commit của repository, fixture, tài liệu được truy xuất;
• giới hạn output (max_output_tokens hoặc max_tokens) và ngân sách vòng lặp từ slide 15;
• verifier và tiêu chí đạt của nó.

Chỉ thay đổi giá trị effort, chỉ dùng các giá trị mà model có tài liệu, và xen kẽ các thiết lập theo thời gian để một thay đổi phía nhà cung cấp hay một giờ chậm không rơi vào chỉ một thiết lập.

Chạy mỗi task nhiều lần cho mỗi thiết lập. Hai lần chạy cùng một prompt có thể khác nhau, nên một lần chạy mỗi task đo may rủi nhiều ngang với đo thiết lập. Cố định số lần chạy trước khi bắt đầu, so sánh các thiết lập theo từng task trên cùng các task, và báo cáo một khoảng, không chỉ một giá trị trung bình. Với tỷ lệ thành công, một khoảng nhị thức như khoảng Wilson là phù hợp; với latency và chi phí, hãy bootstrap theo task.

Đừng đánh giá thành công bằng độ dài câu trả lời hay số reasoning token: cả hai đo nỗ lực đã bỏ ra, không phải chất lượng đã đạt.

Một mẫu benchmark để bạn tự điền

Phần IV · Hệ thống production

Định nghĩa mọi chỉ số trước lần chạy đầu tiên, để các con số không thể được chọn sau khi bạn đã thấy chúng:

Chỉ số	Định nghĩa	Cần để ý
Tỷ lệ task thành công đã kiểm chứng	Số lần chạy có kết quả cuối qua verifier, chia cho tổng số lần chạy	Con số chính
Tỷ lệ thành công ở lần đầu	Số lần chạy đạt ngay ở câu trả lời đầu tiên, không có phản hồi kiểm chứng và không retry, chia cho tổng số lần chạy	Bao nhiêu phần thành công đến từ khả năng phục hồi của vòng lặp
Tỷ lệ qua test	Số test qua chia cho số test đã chạy, ở cuối mỗi lần chạy	Điểm từng phần; không bao giờ thay thế được thành công đã kiểm chứng
Latency, trung vị và P95	Thời gian thực từ lúc bắt đầu task tới kết quả cuối, cho mỗi lần chạy	P95 cần nhiều lần chạy mới có ý nghĩa
Chi phí mỗi task thành công	Tổng chi phí trên mọi lần chạy, kể cả lần thất bại, chia cho số lần thành công đã kiểm chứng	Thêm chi phí tool và hạ tầng nếu có thể
Số lần retry trung bình	Số lần gọi model sau một kiểm tra thất bại hoặc một lỗi tool, cho mỗi lần chạy	Tách riêng khỏi tổng số lần gọi model

Vì sao phải đo thay vì giả định? Effort cao hơn có thể giúp ở các task cần cân nhắc nhiều hơn, và nó cũng thường làm tăng latency và output token. Hiệu ứng nào thắng phụ thuộc vào model, tập task và độ mạnh của verifier, và có thể thay đổi khi model thay đổi.

Biến reasoning effort thành một quyết định kỹ thuật tường minh

Phần IV · Hệ thống production

Khi nhà cung cấp hỗ trợ, effort là một tham số của request. Đây là một request OpenAI Responses API theo dạng được tài liệu hóa, với số reasoning token được đọc lại từ response:

import OpenAI from "openai";

const client = new OpenAI();

const response = await client.responses.create({
  model: "gpt-6-astra",
  reasoning: { effort: "high" }, // the setting this slide is about
  input: "Analyze this production bug...",
});

console.log(response.output_text);
console.log(response.usage?.output_tokens_details.reasoning_tokens);

Thiết lập này diễn đạt mức suy luận cần áp dụng. Nó không trả về suy luận riêng tư của model; chỉ có bản tóm tắt, tùy chọn bật thêm.

Cùng request đó trên Messages API của Anthropic và trên Gemini Interactions API:

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const message = await anthropic.messages.create({
  model: "claude-opus-5-5",
  max_tokens: 16000, // thinking counts toward this cap
  output_config: { effort: "high" },
  messages: [{ role: "user", content: "Analyze this production bug..." }],
});

console.log(message.usage.output_tokens_details?.thinking_tokens);

import { GoogleGenAI } from "@google/genai";

const gemini = new GoogleGenAI({});

const interaction = await gemini.interactions.create({
  model: "gemini-3.8-flash",
  input: "Analyze this production bug...",
  generation_config: { thinking_level: "high" },
});

console.log(interaction.output_text);
console.log(interaction.usage?.total_thought_tokens);

Tên giống nhau, hợp đồng khác nhau. Không có định dạng chung:

Nhà cung cấp và API	Trường trong request	Giá trị trong tài liệu	Trường usage cho reasoning	Nguồn
OpenAI, Responses	reasoning: { effort }	none, minimal, low, medium, high, xhigh, max	usage.output_tokens_details.reasoning_tokens	Reasoning models
Anthropic, Messages	output_config: { effort }	low, medium, high, xhigh, max	usage.output_tokens_details.thinking_tokens	Effort, Steering thinking
Google, Interactions	generation_config: { thinking_level }	minimal, low, medium, high	usage.total_thought_tokens	Thinking
Google, generateContent	config.thinkingConfig.thinkingLevel trong JavaScript SDK	cùng bốn mức đó	usageMetadata.thoughtsTokenCount	API reference; vị trí trường được kiểm tra trong type của SDK

Mỗi danh sách là hợp của các giá trị trên mọi model; một model cụ thể chỉ chấp nhận một phần. Và tên giống nhau không có nghĩa là hành vi giống nhau. high trên model này không được hiệu chỉnh tương đương với high trên model khác, kể cả cùng một nhà cung cấp.

Một heuristic khởi đầu để chọn effort

Phần V · Điều rút ra áp dụng được

Yếu tố	Nghiêng về effort thấp hơn	Nghiêng về effort cao hơn	Đòn bẩy thường tốt hơn
Độ phức tạp của task	Một đường đi rõ ràng, một thay đổi cục bộ	Nhiều phần tương tác, nhiều đường đi hợp lý	Chia nhỏ một task rộng chứ không sâu
Độ bất định và mơ hồ	Spec chính xác	Các giả thuyết cạnh tranh cần cân nhắc	Hỏi lại khi chính spec, chứ không phải phần suy luận, bị mơ hồ
Context	Mọi thứ cần thiết đã có trong prompt	Context đầy đủ nhưng phức tạp	Truy xuất file, log hoặc tài liệu khi thiếu dữ kiện
Nhu cầu thông tin bên ngoài	Không có	Tự nó không phải lý do	Gọi một tool; effort không tạo ra được dữ kiện
Cái giá của kết quả sai	Dễ hoàn tác	Đắt hoặc không thể đảo ngược	Phê duyệt của con người và kiểm tra mạnh hơn, đi cùng với effort
Kiểm chứng tự động	Test mạnh và nhanh, nên lặp lại rẻ	Kiểm tra yếu hoặc không có, nên câu trả lời đầu quan trọng hơn	Viết test còn thiếu trước khi tăng effort
Ngân sách latency và chi phí	Tương tác, khối lượng lớn, ngân sách chặt	Việc offline hoặc batch với giá trị cao mỗi task	Định tuyến theo task (slide 14) thay vì một thiết lập chung

Cách dùng: bắt đầu mỗi route ở mức mà hướng dẫn của nhà cung cấp khuyên cho loại workload đó, hoặc ở mức mặc định được ghi trong tài liệu. Chỉ tăng effort ở những route mà các thất bại qua trace chủ yếu là thất bại reasoning (slide 15) và verifier đủ mạnh để cho thấy khác biệt. Giảm nó ở nơi tỷ lệ thành công đã kiểm chứng vẫn giữ được ở mức thấp hơn. Sau đó chạy benchmark ở slide 16 và 17, và để các con số quyết định thay cho bảng.

Trước khi tăng thinking effort, hãy tự hỏi năm câu này

Phần V · Điều rút ra áp dụng được

Hãy giữ nó như một thẻ quyết định dùng lại được: nếu bạn không trả lời “có” cho câu 1 và câu 5, có lẽ bạn chưa nên tăng thiết lập.

Agent tốt nhất không phải là agent nghĩ nhiều nhất. Mà là agent phân bổ effort đúng chỗ cần thiết.

Phần V · Điều rút ra áp dụng được

1. Thinking effort có thể ảnh hưởng cách model xử lý một task. Nó không đảm bảo tính đúng đắn.
2. Suy luận, dùng tool, truy xuất context và kiểm chứng giải quyết những vấn đề khác nhau.
3. Cấu hình phù hợp đến từ việc đánh giá workload của chính bạn.

Thay vì hỏi "Làm sao để AI nghĩ nhiều hơn?", hãy hỏi "Task này cần bao nhiêu suy luận để hoàn thành một cách đáng tin cậy?"

Tài liệu tham khảo và đọc thêm

Mọi trang của nhà cung cấp được kiểm tra lần cuối ngày 22 tháng 10 năm 2026.

• OpenAI, Reasoning models: reasoning.effort, reasoning token và bản tóm tắt. Trang model GPT-6 Astra: các giá trị effort được hỗ trợ.
• Anthropic, Effort và Steering thinking: các mức effort và mặc định theo từng model, adaptive thinking, thinking token và chi phí.
• Google, Gemini thinking: thinking_level trên Interactions API, các mức theo từng model, bản tóm tắt thought và lượng thinking token. Tham chiếu generateContent: usageMetadata.thoughtsTokenCount.
• Các SDK dùng để type-check: openai 7.42.0, @anthropic-ai/sdk 1.1.0, @google/genai 2.30.0.
• Anthropic, Building effective agents (tháng 12 năm 2024): workflow, agent và khi nào nên thêm độ phức tạp.
• Yao và cộng sự, ReAct: Synergizing Reasoning and Acting in Language Models (2022).
• Snell và cộng sự, Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters (2024).
• Chen và cộng sự, Reasoning Models Don’t Always Say What They Think (2025).