Blog

Cách xây dựng quy trình Claude tự động

Xây dựng các quy trình làm việc Claude tự động. Tìm hiểu thực thi không giao diện, cổng xác minh, các biện pháp kiểm soát, lập lịch và chuyển giao để đảm bảo an toàn cho các tác nhân không giám sát.

Ashley Innocent

Ashley Innocent

8 tháng 6 2026

Cách xây dựng quy trình Claude tự động

Apidog cho doanh nghiệp

Triển khai tại chỗ

SSO & RBAC

Tuân thủ SOC 2

Khám phá Apidog Enterprise

Có một câu nói đang lan truyền tổng kết về hướng đi của lập trình tác nhân (agentic coding): mục tiêu không phải là một câu lệnh (prompt) tốt hơn, mà là một quy trình làm việc tự động mà bạn không cần giám sát. Hầu hết mọi người dùng Claude như dùng cửa sổ trò chuyện. Bạn gõ, bạn đợi, bạn đọc, bạn lại gõ. Điều đó hiệu quả, nhưng nó giới hạn năng suất của bạn chỉ với một tác nhân mà bạn đang tích cực "trông nom". Các kỹ sư tận dụng sức mạnh thực sự của Claude đã xây dựng một thứ khác: các quy trình làm việc tự động khởi chạy theo lịch trình hoặc một sự kiện kích hoạt, thực hiện công việc, kiểm tra kết quả của chính chúng, và chỉ thông báo cho con người khi cần đưa ra quyết định.

Tải ứng dụng

TL;DR (Tóm tắt)

Một quy trình làm việc của Claude tự động chạy mà không cần bạn cần có năm phần: một đặc tả (spec) viết rõ ràng, thực thi không tương tác (headless), một cổng xác minh (verification gate) quyết định đạt hay không đạt, các rào chắn cứng (hard guardrails) (danh sách cho phép quyền, giới hạn số lần lặp, giới hạn chi phí, công tắc dừng), và một cơ chế bàn giao (handoff) thông báo cho con người hoặc leo thang khi thất bại. Chế độ headless của Claude Code (claude -p), Claude Agent SDK, các hook, và một công cụ lập lịch (cron hoặc launchd) cung cấp cho bạn cả năm yếu tố này. Tác nhân (agent) không phải là phần rủi ro. Việc chạy nó tự động mà không có cổng xác minh và rào chắn mới là rủi ro. Hãy xây dựng những thứ đó trước, sau đó bạn có thể buông tay.

Tại sao "chạy mà không cần bạn" mới là mục tiêu thực sự

Trò chuyện có giám sát có một giới hạn cứng: chính bạn. Mỗi lần lặp đều chờ một con người đọc đầu ra và quyết định bước tiếp theo. Mô hình tạo ra kết quả trong vài giây, sau đó lại nhàn rỗi trong vài phút khi bạn chuyển đổi ngữ cảnh. Bạn chính là nút thắt cổ chai trong một hệ thống vốn dĩ nhanh chóng.

Các quy trình làm việc tự động loại bỏ giới hạn đó. Tác nhân thực hiện công việc, một script kiểm tra nó, các lỗi tự động được chuyển lại, và bạn chỉ can thiệp ở các trường hợp đặc biệt. Lợi ích không chỉ là tốc độ. Đó là sự song song. Khi một quy trình làm việc chạy mà không cần giám sát, bạn mở rộng quy mô bằng cách thêm các quy trình làm việc, chứ không phải bằng cách gõ nhanh hơn. Đó là bước nhảy vọt tương tự mà chúng tôi đã đề cập trong các quy trình làm việc động của Claude Code, nơi một phiên làm việc phân tán thành nhiều tác nhân song song.

Nhưng "chạy mà không cần bạn" cũng tăng thêm rủi ro. Một tác nhân có giám sát mà thực hiện một chỉnh sửa sai sẽ bị phát hiện khi bạn đọc phần khác biệt. Một tác nhân tự động sẽ cam kết thay đổi đó, chạy bước tiếp theo và tiếp tục. Vì vậy, kỷ luật chuyển từ việc tạo prompt sang thiết kế hệ thống: bạn đang xây dựng một cỗ máy phải chính xác, có giới hạn và có thể quan sát được khi không ai giám sát. Bài viết của Anthropic về xây dựng các tác nhân hiệu quả cũng đưa ra lập luận tương tự. Đòn bẩy đến từ môi trường xung quanh mô hình, chứ không phải một thông điệp đơn lẻ thông minh hơn.

Năm phần mọi quy trình làm việc tự động đều cần

Bỏ qua bất kỳ phần nào trong số này và quy trình làm việc sẽ tự tin làm sai hoặc không bao giờ dừng lại.

  1. Đặc tả chính xác. Một mô tả bằng văn bản về công việc đã hoàn thành mà tác nhân đọc vào đầu mỗi lần chạy. Các đặc tả mơ hồ sẽ tạo ra công việc mơ hồ. "Sửa API" sẽ thất bại; "endpoint POST /orders trả về 201, xác thực nội dung theo schema, từ chối các trường bị thiếu với mã 422" sẽ thành công.
  2. Thực thi không tương tác (Headless execution). Claude phải chạy mà không cần con người thao tác trên bàn phím. Điều đó có nghĩa là chế độ không tương tác, chứ không phải giao diện người dùng trò chuyện.
  3. Cổng xác minh. Một kiểm tra có tính xác định (deterministic check) trả về đạt hoặc không đạt cùng với một lý do cụ thể: các bài kiểm tra, kiểm tra kiểu, xác thực schema, kiểm tra hợp đồng. Đây là thứ cho phép quy trình làm việc quyết định nó thực sự đã hoàn thành thay vì tin lời mô hình.
  4. Rào chắn (Guardrails). Danh sách cho phép quyền, số lần lặp tối đa, giới hạn chi phí, ghi nhật ký và công tắc dừng. Những thứ này giữ cho một lần chạy bị lỗi không gây ra thiệt hại khi bạn đang ngủ.
  5. Bàn giao (Handoff). Khi quy trình làm việc hoàn thành hoặc bỏ cuộc, nó sẽ thông báo cho ai đó. Một thông báo, một bản nháp để xem xét, một cảnh báo lỗi. Im lặng không phải là thành công.

Ba phần giữa là nơi hầu hết các thiết lập còn yếu. Hãy xây dựng từng phần với các công cụ mà Claude cung cấp cho bạn.

Các khối xây dựng của Claude

Chế độ không tương tác (claude -p)

Chế độ in (print mode) của Claude Code chạy một prompt không tương tác và thoát. Đây là nền tảng của mọi quy trình làm việc tự động. Bạn giao cho nó một nhiệm vụ, giới hạn các công cụ của nó, thu thập đầu ra và tiếp tục.

claude -p "Implement the orders endpoint per spec.md, then run the test suite" \
  --allowedTools "Edit,Write,Bash" \
  --output-format json \
  >> run.log 2>&1

Cờ --allowedTools quan trọng hơn vẻ bề ngoài của nó. Trong giao diện người dùng trò chuyện, bạn phê duyệt từng hành động bằng tay. Ở chế độ không tương tác, không có ai để phê duyệt, vì vậy danh sách cho phép là kiểm soát duy nhất của bạn đối với những gì tác nhân có thể can thiệp. Bắt đầu với phạm vi hẹp và chỉ mở rộng khi bạn tin tưởng vào lần chạy. Toàn bộ các cờ được liệt kê trong tài liệu của Claude Code.

Claude Agent SDK

Khi một lệnh shell không đủ, Claude Agent SDK cho phép bạn điều khiển Claude bằng lập trình từ Python hoặc TypeScript. Bạn nhận được vòng lặp trong mã: gửi một nhiệm vụ, truyền kết quả, kiểm tra các lệnh gọi công cụ, quyết định xem có tiếp tục hay không. Đây là cách bạn bao bọc luồng điều khiển thực sự xung quanh tác nhân.

import { query } from "@anthropic-ai/claude-agent-sdk";

const MAX_ITERATIONS = 8;
let feedback = "";

for (let attempt = 0; attempt < MAX_ITERATIONS; attempt++) {
  for await (const msg of query({
    prompt: `${task}\n\nPrevious failures:\n${feedback}`,
    options: { allowedTools: ["Edit", "Write", "Bash"] },
  })) {
    // stream/log messages as the agent works
  }

  const gate = runVerification();      // your deterministic check
  if (gate.passed) break;              // done
  feedback = gate.failures;            // the next prompt writes itself
}

Các chữ ký chính xác nằm trong tài liệu, nhưng điểm mấu chốt là hình dạng: một vòng lặp chạy lại tác nhân với lỗi cuối cùng làm prompt tiếp theo. Nếu bạn đang quyết định giữa việc tự xây dựng vòng lặp của mình và một tùy chọn được lưu trữ, so sánh của chúng tôi về các tác nhân được quản lý so với Agent SDK sẽ giải thích khi nào từng tùy chọn có ý nghĩa.

Các hook cho rào chắn xác định

Các hook chạy các lệnh của riêng bạn tại các điểm cố định trong vòng đời của Claude, mà không có sự can thiệp của mô hình. Chúng là cách bạn thực thi các quy tắc mà tác nhân không thể tránh được. Muốn bộ kiểm thử chạy sau mỗi lần chỉnh sửa tệp? Một hook PostToolUse sẽ thực hiện điều đó một cách xác định.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "npm test --silent" }]
      }
    ]
  }
}

Vì một hook là mã thuần túy, không phải một yêu cầu gửi đến mô hình, nó luôn được kích hoạt. Đó là thuộc tính bạn muốn có cho các rào chắn trong một lần chạy tự động. Tác nhân không thể quyết định bỏ qua nó.

Một công cụ lập lịch để kích hoạt các lần chạy

Một quy trình làm việc tự động chạy mà không cần bạn cần một thứ gì đó để khởi động nó mà không cần bạn. Trên máy chủ đó là cron; trên Mac đó là launchd. Dù bằng cách nào, bạn cũng đang kích hoạt lệnh không tương tác theo một lịch trình.

# every weekday at 7am: run the maintenance workflow, log everything
0 7 * * 1-5  cd /srv/api && claude -p "$(cat tasks/nightly-maintenance.md)" \
  --allowedTools "Edit,Bash" >> logs/run-$(date +\%F).log 2>&1

Đó là toàn bộ xương sống của một thiết lập tự động: một công cụ lập lịch kích hoạt Claude không tương tác, tác nhân làm việc theo một đặc tả, các hook và một cổng xác minh giữ cho nó đáng tin cậy, và các nhật ký cho bạn biết điều gì đã xảy ra.

Thiết kế vòng lặp, không phải prompt

Đây là tư duy kết nối mọi thứ lại với nhau. Đừng hỏi "tôi nên nói gì với Claude?" mà hãy bắt đầu hỏi "vòng lặp nào sẽ khiến Claude tự nói với chính nó?". Tác nhân là một công cụ tạo nhanh nhưng không có khả năng nhận biết đáng tin cậy liệu nó có đúng hay không. Vòng lặp cung cấp khả năng đó thông qua cổng xác minh. Chúng tôi đã đi sâu vào điều này trong bài viết ngừng prompt cho tác nhân lập trình của bạn, thay vào đó hãy xây dựng vòng lặp, và đây là ý tưởng chủ chốt cho công việc tự động: sự tự tin của mô hình không còn quan trọng, chỉ có phán quyết của cổng xác minh mới quan trọng.

Đây cũng là lý do tại sao một đặc tả rõ ràng tốt hơn một prompt thông minh. Cùng một đặc tả thúc đẩy mọi lần lặp và đồng thời là tài liệu. Một tệp design.md hoặc AGENTS.md ghi lại mục đích, ràng buộc và định nghĩa về công việc hoàn thành sẽ cung cấp cho tác nhân một mục tiêu ổn định trong mỗi lần chạy, thay vì bạn phải giải thích lại ngữ cảnh mỗi lần.

Ví dụ thực tế: bảo trì API tự động

Cụ thể hóa vấn đề. Giả sử bạn muốn một quy trình làm việc giữ cho một tập hợp các endpoint API đồng bộ với đặc tả OpenAPI của chúng, chạy mỗi sáng, và không bao giờ đưa ra một endpoint bị lỗi. Đây là cấu trúc:

  1. Đặc tả. Hợp đồng nằm trong một tệp OpenAPI; hành vi nằm trong các trường hợp kiểm thử. Tác nhân đọc cả hai khi bắt đầu chạy.
  2. Kích hoạt. Một cron job lúc 7 giờ sáng kích hoạt Claude không tương tác với nhiệm vụ bảo trì.
  3. Tạo. Tác nhân điều chỉnh việc triển khai với đặc tả: thêm các endpoint bị thiếu, sửa các hình dạng phản hồi không khớp, thắt chặt xác thực.
  4. Cổng xác minh. Quy trình làm việc chạy bộ kiểm thử API chống lại dịch vụ đang chạy. Các khẳng định trạng thái, xác thực schema JSON trên mỗi phản hồi, kiểm tra hợp đồng chống lại đặc tả. Các lỗi được trả về có cấu trúc: "Dự kiến 422 khi thiếu customer_id, nhận được 500." "Trường phản hồi total là một chuỗi, schema nói là số."
  5. Vòng lặp hoặc leo thang. Cổng đỏ (thất bại)? Lỗi có cấu trúc trở thành prompt tiếp theo và tác nhân vá lỗ hổng cụ thể đó, lên đến giới hạn lặp. Cổng xanh (thành công)? Nó mở một bản PR nháp. Hết lượt thử? Nó gửi một cảnh báo với lỗi cuối cùng và dừng lại.
  6. Bàn giao. Một người nhận được một bản PR sạch để xem xét hoặc một báo cáo lỗi chính xác. Không bao giờ là một commit thầm lặng.

Cổng xác minh ở bước 4 là thứ giúp toàn bộ quy trình an toàn khi chạy tự động. Không có nó, tác nhân chỉnh sửa mã và báo cáo thành công dựa trên hiểu biết của chính nó, đó chính xác là cách các endpoint bị lỗi đến được môi trường sản xuất. Đây là nơi Apidog phù hợp với một quy trình làm việc tự động: thiết kế API, schema, máy chủ giả lập, và các kiểm thử tự động đều nằm trong một không gian làm việc, vì vậy cổng xác minh và đặc tả mặc định được đồng bộ. Bạn hướng dẫn lần chạy đến một kịch bản kiểm thử Apidog và tác nhân sẽ nhận được kết quả đạt/không đạt đã được xác thực schema trong mỗi lần lặp. Máy chủ giả lập thay thế cho các phụ thuộc không hoạt động, vì vậy một lần chạy lúc 3 giờ sáng không bị chặn chờ một bên thứ ba không ổn định. Các nhóm kết nối quyền truy cập endpoint của tác nhân thông qua công cụ gỡ lỗi tác nhân AI của Apidog cho phép nó truy cập và kiểm tra các endpoint theo cách mà một người kiểm thử sẽ làm. Tải xuống Apidog nếu bạn muốn xây dựng cổng xác minh một cách trực quan hơn là tự tay viết một runner.

Các rào chắn giúp các lần chạy tự động an toàn

Đây là phần phân biệt một quy trình làm việc bạn tin tưởng qua đêm với một quy trình làm việc khiến bạn thức giấc lúc 3 giờ sáng. Một tác nhân không giám sát cần các giới hạn cứng, không phải ý định tốt.

Hầu hết những điều này đều quy về một quy tắc: một tác nhân tự động nên có thể làm công việc của nó và không làm gì khác. Hạn chế các công cụ, giới hạn vòng lặp, cô lập không gian làm việc và làm cho mọi lần chạy có thể quan sát được.

Những sai lầm thường gặp

Một vài mẫu hình làm chìm các quy trình làm việc tự động nhanh chóng.

Nếu bạn làm đúng những điều này, một quy trình làm việc của Claude sẽ thực hiện một ngày làm việc được giới hạn và xác minh trước khi bạn kịp uống cà phê. Nếu bạn làm sai, bạn đã tự động hóa việc sản xuất mã tự tin nhưng chưa được kiểm thử. Sự khác biệt nằm ở cổng xác minh và các rào chắn, chứ không phải ở mô hình. Nếu bạn muốn kiến trúc sâu hơn, phân tích của chúng tôi về thiết kế khung tác nhân (agent harness design) sẽ giải thích cách các phần khớp với nhau ở quy mô lớn.

Điểm mấu chốt

Xây dựng các quy trình làm việc của Claude tự động chạy mà không cần bạn không phải là về Claude nhiều, mà là về hệ thống bạn bao bọc xung quanh nó. Năm phần mang trọng trách: một đặc tả chính xác, thực thi không tương tác, một cổng xác minh có tính xác định, các rào chắn cứng, và một cơ chế bàn giao rõ ràng. Làm đúng những điều đó và mô hình sẽ trở thành một người làm việc nhanh chóng bên trong một cỗ máy chính xác, có giới hạn và có thể quan sát được khi bạn không trông nom.

Hãy bắt đầu với một quy trình làm việc. Viết một đặc tả chặt chẽ, chạy nó ở chế độ không tương tác chống lại một cổng xác minh nhanh, giới hạn các công cụ, giới hạn số lần lặp, cô lập không gian làm việc và khiến nó thông báo cho bạn khi hoàn thành hoặc thất bại. Đối với bất kỳ thứ gì liên quan đến API, bộ kiểm thử của bạn là cổng xác minh giúp các lần chạy tự động an toàn, và Apidog cung cấp cho bạn thiết kế, giả lập và kiểm thử tự động trong một không gian làm việc để xây dựng nó. Tải xuống, kết nối cổng xác minh và để quy trình làm việc chạy các vòng của nó trong khi bạn làm việc khác.

Thực hành thiết kế API trong Apidog

Khám phá cách dễ dàng hơn để xây dựng và sử dụng API

Đăng ký miễn phíTải xuống