Xây dựng nhà máy phần mềm AI: Khi agent tự mở, review và merge pull request

Một kỹ sư với coding agent giờ đây có thể tạo ra pull request nhanh hơn cả một nhóm có thể review. Câu hỏi không còn là làm sao để agent viết code, mà là làm sao hấp thụ được lượng code đó.

Kiến trúc nhà máy phần mềm AI với các agent tự động

Ngày 6 tháng 1 năm 2026, Stephen Toub mở chín pull request từ điện thoại khi đang ở độ cao 35.000 feet. Bảy trong số đó được merge. Anh làm việc trên dotnet/runtime, và ghi lại điều mà trải nghiệm đó cho anh thấy:

AI thay đổi kinh tế học của việc sản xuất code. Một người có phán đoán tốt cùng một chiếc điện thoại có thể tạo PR nhanh hơn cả nhóm review kịp.

Đây chính là chủ đề của bài viết này. Một kỹ sư duy nhất với coding agent giờ có thể làm bão hòa toàn bộ năng lực review của một nhóm, ngay từ ghế máy bay. "Nhà máy phần mềm AI" (AI software factory) là câu trả lời mà các công ty lớn đã hội tụ về, biến coding agent tự trị từ một bản demo thành thông lượng mà nhóm có thể hấp thụ được.

Nhà máy phần mềm AI là gì?

Nhà máy phần mềm AI là hệ thống bao quanh coding agent, chứ không phải bản thân agent. Công việc đến từ một hàng đợi, agent chạy trong không gian làm việc cô lập, xác minh diễn ra tự động, và con người đứng ở một cổng merge rõ ràng. Có nơi gọi nó là agentic software factory.

Sự khác biệt cần phân biệt là giữa một agent và một nhà máy phần mềm. Chạy coding agent trên laptop là dùng agent: bạn chọn việc, bạn nhìn nó làm, bạn đọc diff, bạn merge. Mọi thứ ngoài việc gõ phím vẫn là bạn, và sự chú ý của bạn là giới hạn.

Nhà máy phần mềm đẩy các bước đó vào hạ tầng. Không ai quyết định agent nhặt issue nào, vì các quy tắc tiếp nhận quyết định. Không ai dựng workspace, vì môi trường cô lập được cấp phát tự động. Không ai kiểm tra xem thay đổi có biên dịch được hay không, vì bước xác minh chạy trước khi con người can thiệp. Con người xuất hiện ở cuối, tại những quyết định mang tính trách nhiệm.

Addy Osmani diễn đạt ngắn gọn hơn:

Nhà máy phần mềm là việc vận hành các vòng lặp ở quy mô lớn.

Ba thuộc tính tách một nhà máy phần mềm thật khỏi một mớ script:

• Chạy theo hàng đợi, không theo prompt. Công việc vào từ issue, cảnh báo, hoặc kênh Slack, và hệ thống quyết định cái gì đáng để bắt đầu. Không ai gõ prompt.
• Môi trường dùng xong là bỏ. Mỗi agent nhận một workspace sạch có thể hủy, nên một lần chạy lỗi không tốn gì và các lần chạy song song không phá hỏng lẫn nhau.
• Xác minh chạy trước khi review. Lúc một diff đến tay người, nó đã được biên dịch, chạy test và kiểm tra phạm vi.

Bỏ sót điều thứ ba thì bạn chưa xây nhà máy phần mềm. Bạn chỉ xây một cỗ máy sinh ra việc review nhanh hơn tốc độ bạn hấp thụ, và đó là chế độ thất bại mà phần còn lại của bài viết này được tổ chức để tránh.

Năm giai đoạn mà mọi nhà máy phần mềm đã công bố đều có

Hầu hết các hệ thống này đều dựa trên background coding agent, tức agent chạy không giám sát trong môi trường riêng thay vì trong trình soạn thảo của bạn. Đọc đủ nhiều kiến trúc này, một bộ khung giống nhau hiện ra, dù mỗi công ty gọi tên khác nhau.

Giai đoạn	Stripe (Minions)	Spotify (Honk)	Shopify (River)	Ramp (Inspect)
Tiếp nhận	Tin nhắn Slack, thả emoji	Fleetshift chọn mục tiêu khắp các repo	@river trong kênh công khai	Task được giao
Cô lập	Devbox EC2 làm nóng sẵn	Pod Kubernetes, quyền truy cập hạn chế	Harness dùng xong là bỏ trên session bền vững	Sandbox Modal từ snapshot hệ thống tệp
Công cụ	Toolshed, khoảng 500 công cụ MCP nội bộ	Hệ thống nội bộ qua MCP	Proxy thông tin xác thực và gateway	Test, telemetry, feature flag, ảnh chụp màn hình
Xác minh	Lint và test dưới 5 giây, rồi CI có giới hạn	Kiểm tra tất định, LLM judge, CI	Chế độ review PR tự động	Xác minh hình ảnh và telemetry
Cổng merge	Con người review sau hai lần chạy CI	Con người review	Con người review	Con người review

Thứ tự các giai đoạn quan trọng hơn bộ công cụ. Mỗi cổng ngăn công việc chảy sang giai đoạn tiếp theo, và các giai đoạn tốn kém nằm ở cuối.

Một lưu ý về cấu trúc trước khi đi vào chi tiết. Kiến trúc managed agents của Anthropic chia nhà máy phần mềm thành brain (model và harness, không lưu trạng thái), hands (sandbox dùng xong là bỏ) và session (nhật ký sự kiện append-only bền vững). Shopify trích dẫn trực tiếp điều này trong bài "Under the River". Nếu chỉ xây được một thứ từ bài viết này, hãy xây session log, vì nó là thứ cho phép mọi thứ khác trở nên có thể vứt bỏ.

Giai đoạn 1: công việc đến tay agent như thế nào

Tiếp nhận quyết định cái gì đáng để bắt đầu. Làm sai bước này thì mọi giai đoạn sau đều đốt token vào những việc lẽ ra không nên bắt đầu.

Phiên bản ngây thơ giao một agent cho mọi issue đang mở. Các phiên bản đã công bố đều lọc trước. Seer của Sentry chấm điểm từng lỗi đến xem có khả năng xử lý được hay không, và chỉ điều tra những cái vượt ngưỡng. Shopify chọn cách khác và định tuyến tiếp nhận qua Slack, với một quy tắc: agent làm việc trong kênh công khai, không bao giờ qua tin nhắn riêng. CEO Tobi Lütke mô tả ràng buộc này là có chủ đích:

River không phản hồi tin nhắn trực tiếp. Cô ấy từ chối một cách lịch sự và đề nghị bạn tạo một kênh công khai để hai bên bắt đầu làm việc. [...] Mọi cuộc trò chuyện vì thế đều có thể tìm kiếm được. Bất kỳ ai ở Shopify cũng có thể nhảy vào.

Lập luận ở đây mang tính tổ chức hơn là kỹ thuật. Một phiên agent riêng tư chỉ dạy được một người và chết đi cùng cửa sổ chat.

Một bộ lọc tiếp nhận tối thiểu chỉ là một nhãn cộng một truy vấn. Đoạn dưới đây lấy ra các issue mà con người đã đánh dấu rõ ràng là phù hợp cho agent và có quy mô nhỏ:

gh issue list \
  --label "agent-ready" \
  --state open \
  --limit 20 \
  --json number,title,labels,body \
  --jq '.[] | select(.labels | map(.name) | index("needs-design") | not)'

Dữ liệu của Microsoft cho thấy vì sao bộ lọc quy mô cần nằm ở đó. Trong mười tháng trên dotnet/runtime, các PR của agent thay đổi từ 1 đến 50 dòng thành công 76 đến 80% số lần, trong khi các công việc liên quan đến hiệu năng chỉ đạt 54,5%. Bản tóm tắt được công bố nói thẳng về hình dạng của vấn đề: coding agent của Copilot "xuất sắc khi triển khai những thay đổi được đặc tả rõ ràng, rất tốt khi điều tra issue, và tương đối kém khi thiết kế kiến trúc giải pháp."

Cổng chống trùng lặp, và vì sao phần lớn phiên bản của nó thất bại theo hướng mở

Có một câu hỏi thứ hai mà bước tiếp nhận nên hỏi, và gần như không ai hỏi: đã có ai sửa vấn đề này ở thượng nguồn chưa?

Với một kỹ sư đơn lẻ thì đây là thứ "có thì tốt". Nhưng ở mức 1.300 PR agent được merge mỗi tuần của Stripe, việc tung agent vào những vấn đề đã được giải quyết chính là lãng phí mà một nhà máy phần mềm tồn tại để loại bỏ, và không có gì phát hiện ra nếu không có thứ gì đó kiểm tra.

Chỉ mục developer của Firecrawl bao phủ dạng câu hỏi này, vì nó đánh chỉ mục các luồng issue, pull request đã merge, README và tài liệu, chứ không phải các bài blog viết về chúng. Phạm vi được giới hạn theo dependency đang xét:

curl -X POST https://api.firecrawl.dev/v2/search/developer \
  -H "Authorization: Bearer $FIRECRAWL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"query":"connection pool exhausted under high concurrency",
       "k":3,"types":["issue","pull_request"],
       "repos":["magicstack/asyncpg"],"passages":1}'

Đây là phần quan trọng đối với một cổng kiểm soát. Khi bạn giới hạn phạm vi bằng repos, phản hồi sẽ thêm một khối repos ở cấp cao nhất, và nó phân biệt hai trường hợp mà nếu không sẽ trông giống hệt nhau:

{ "success": true, "partial": false,
  "repos": [ { "repo": "magicstack/asyncpg", "indexed": true,
               "types": { "issue": true, "pullRequest": true, "readme": true } } ] }

{ "success": true, "partial": false,
  "repos": [ { "repo": "acme/internal-fork", "indexed": false,
               "types": { "issue": false, "pullRequest": false, "readme": false } } ] }

Cả hai đều trả về HTTP 200 với success: true. Cái thứ hai trả về không kết quả nào. Vậy nên một cổng được viết kiểu if not results: spawn_agent() không thể phân biệt "chưa ai báo cáo vấn đề này" với "chúng ta không có dữ liệu về repo đó", và thả cả hai qua. Cổng đó thất bại theo hướng mở.

Đọc trường repos[0].indexed và coi giá trị false là chưa biết thay vì đã rõ là một sửa đổi một dòng biến một ô tìm kiếm thành một cổng kiểm soát thực sự. Trường hợp chưa biết thì chuyển cho con người hoặc thử lại không giới hạn phạm vi.

Giai đoạn 2: chọn mô hình cô lập

Hai agent cùng sửa một thư mục làm việc là cách nhanh nhất để mất một ngày. Đây là chỗ phần lớn nhà máy phần mềm tự chế bị kẹt, vì câu trả lời hiển nhiên vẫn chạy tốt cho đến khoảng agent song song thứ tư.

Ba mô hình, theo thứ tự chi phí và năng lực tăng dần:

Mô hình	Cô lập được	Không cô lập được	Phù hợp cho	Ví dụ thực tế
Git worktree	Tệp, nhánh	Cổng mạng, cơ sở dữ liệu, dependency đã cài, mạng	Một máy, 2 đến 5 agent	Cờ --worktree của Claude Code
Container	Tệp, dependency, mạng, tiến trình	Tài nguyên máy chủ	Dependency xung đột, thay đổi không đáng tin	container-use, Sculptor
Cloud sandbox	Mọi thứ, cộng khả năng chạy song song	Không có gì bạn cần	Quy mô fleet, song song không giới hạn	Devbox của Stripe, Ramp trên Modal, Spotify trên Kubernetes

Worktree là nơi nên bắt đầu. Git worktree là thư mục làm việc thứ hai trên nhánh riêng của nó, chia sẻ cùng một repository. Claude Code tạo một cái cho mỗi phiên:

claude --worktree feature-auth

Lệnh này tạo ra thư mục .claude/worktrees/feature-auth/ trên một nhánh tên worktree-feature-auth. Bạn có thể ghim môi trường cô lập cho một subagent cụ thể, để một agent chuyên refactor luôn có cây làm việc riêng:

---
name: refactorer
description: Applies mechanical refactors across many files
isolation: worktree
---
Apply the requested refactor across every affected file, then run the tests
and report the results.

Phần mà mọi hướng dẫn về worktree đều bỏ qua

Worktree là một bản checkout mới, nghĩa là tệp .env của bạn không nằm trong đó. node_modules cũng vậy, và một cổng mạng trống cũng vậy. Đây chính là thứ thật sự vỡ ở agent thứ tư, và là lý do các nhóm kết luận worktree "không mở rộng được" trong khi thứ họ gặp phải chỉ là một bản checkout chưa được cấu hình.

Claude Code xử lý nửa phần tệp bị gitignore bằng một tệp .worktreeinclude ở gốc dự án, dùng cú pháp gitignore:

.env
.env.local
config/secrets.json

Cổng mạng và cơ sở dữ liệu vẫn là việc bạn phải tự giải quyết. Hãy gán chúng theo tên worktree thay vì hardcode, và cấp cho mỗi agent một cơ sở dữ liệu riêng. Nhớ thêm .claude/worktrees/ vào .gitignore.

Hai cài đặt nữa đáng biết. Worktree mới tạo nhánh từ nhánh mặc định của repository, thường là điều bạn muốn cho các task độc lập; đặt worktree.baseRef thành "head" khi agent cần công việc đang dang dở của bạn. Và bạn có thể tạo worktree trực tiếp từ một pull request, đây là cách trỏ agent vào phản hồi review:

claude --worktree "#1234"

Dọn dẹp là chế độ thất bại mà không ai lên kế hoạch. Các phiên tương tác sẽ hỏi khi thoát, nhưng các lần chạy không tương tác với -p thì không dọn dẹp gì cả, và mỗi cái giữ một khóa cho đến khi một lượt quét sau giải phóng. Nếu bạn đang viết script cho cả fleet, hãy dọn dẹp tường minh:

git worktree list
git worktree remove .claude/worktrees/feature-auth

# nếu git từ chối vì cây làm việc đang bị khóa
git worktree unlock .claude/worktrees/feature-auth

Chuyển lên container khi agent bắt đầu cần các phiên bản dependency xung đột nhau, và lên cloud sandbox khi khả năng chạy song song quan trọng hơn chi phí vận hành hạ tầng. Inspect của Ramp lập luận cho nấc cao nhất này một cách thẳng thắn: "Khi background agent nhanh, chúng tốt hơn hẳn so với chạy cục bộ: cùng trí tuệ, nhiều sức mạnh hơn, và song song không giới hạn."

Giai đoạn 3: cho agent đôi tay, không chỉ bộ não

Một model với repository chỉ là autocomplete. Một model với test runner, telemetry, feature flag và công cụ triển khai của bạn là một đồng nghiệp. Khoảng cách giữa hai thứ đó là lớp công cụ, và đây là giai đoạn kém hào nhoáng nhất nhưng quyết định nhất trong nhà máy phần mềm.

Các con số đã công bố cho thấy giới lãnh đạo coi trọng nó đến mức nào. Toolshed của Stripe vận hành khoảng 500 công cụ nội bộ sau một MCP server duy nhất, với các kiểm soát chặn hành động phá hoại. Cloudflare vận hành một MCP Portal nội bộ và sinh tệp AGENTS.md trên hơn 3.900 repository. Ramp nối test, truy vấn telemetry, feature flag và xác minh ảnh chụp màn hình vào mọi sandbox.

Đòn bẩy nằm ở chỗ đây là cấu hình cho cả fleet, không phải thiết lập cho từng agent. Một khối MCP tiếp cận mọi agent:

{
  "mcpServers": {
    "firecrawl": {
      "command": "npx",
      "args": ["-y", "firecrawl-mcp"],
      "env": { "FIRECRAWL_API_KEY": "${FIRECRAWL_API_KEY}" }
    }
  }
}

Một lớp công cụ tiêu biểu cho nhà máy phần mềm trông đại khái như thế này:

Năng lực	Trả lời câu hỏi	Tiếp cận qua
Test và lint	Nó có build và pass không	Shell trong sandbox
Telemetry	Nó có làm vỡ production không	Observability MCP server
Feature flag	Nhánh code này có đang chạy thật không	Công cụ MCP nội bộ
Hệ sinh thái và tài liệu	API này còn tồn tại thật không	firecrawl_developer_search
Triển khai và rollback	Có thể hoàn tác được không	Công cụ MCP nội bộ, có cổng kiểm soát

Rauch đẩy lập luận này xa hơn, cho rằng bản thân ngữ cảnh nên nằm ở một chỗ:

Nhà máy phần mềm của bạn nên là một monorepo. Toàn bộ ngữ cảnh công ty (thiết kế, marketing, kinh doanh, kỹ thuật, hỗ trợ…) ở một chỗ để agent xây dựng dựa trên đó.

Chúng tôi cũng đi đến kết luận tương tự ở Firecrawl. Chúng tôi vận hành một monorepo nội bộ tên Firebrain chứa toàn bộ ngữ cảnh công ty, từ sản phẩm và kỹ thuật đến marketing, kinh doanh và hỗ trợ, ở một chỗ mà agent đọc được. Lợi ích là những agent đã biết công ty vận hành thế nào trước cả khi bắt đầu task. Điều này quan trọng hơn bình thường với chúng tôi vì nhóm làm việc hoàn toàn từ xa, trải khắp năm châu lục và nhiều múi giờ, nên repository thường là đồng nghiệp duy nhất còn thức.

Về tệp hướng dẫn, hãy cưỡng lại mong muốn viết một cuốn sách hướng dẫn. Nhóm Codex của OpenAI vận hành một repository khoảng một triệu dòng với AGENTS.md chỉ khoảng 100 dòng, đóng vai trò "chủ yếu như một bản đồ, với các con trỏ dẫn tới nguồn chân lý sâu hơn ở nơi khác". Dữ liệu của Microsoft ủng hộ nguyên tắc chung từ hướng ngược lại: thêm .github/copilot-instructions.md và cấu hình firewall đưa tỷ lệ thành công của agent trên dotnet/runtime từ 41,7% lên mức duy trì 71%. Việc chuẩn bị đáng giá hơn bất kỳ nâng cấp model nào trong cùng giai đoạn.

Giai đoạn 4: xác minh là nơi các nhà máy phần mềm thực sự khác nhau

Mọi nhà máy phần mềm đều sinh code. Thứ phân biệt chúng là những gì diễn ra giữa lúc sinh code và lúc nó đến mắt con người, và đây là giai đoạn có những kết quả công bố phản trực giác nhất.

Sơ đồ pipeline trong nhà máy phần mềm AI

Bài viết về các vòng phản hồi của Spotify mô tả cấu trúc rõ nhất: các vòng lặp lồng nhau, rẻ nhất trước.

• Vòng trong. Các bộ kiểm tra tất định được chọn tự động dựa trên những gì có trong repo. Format, biên dịch, test. Không có model tham gia.
• Bồi thẩm (judge). Một model đánh giá xem diff có nằm trong phạm vi hay không. Nó phủ quyết khoảng 25% số phiên agent, và khoảng một nửa trong số đó có thể cứu được bằng cách điều chỉnh hướng cho agent thay vì vứt bỏ công việc.
• Vòng ngoài. CI và các kiểm tra PR.

Spotify cũng xếp hạng các chế độ thất bại của mình, và phần xếp hạng mới là phần hữu ích. Một PR không sinh ra được là chuyện phiền nhỏ. Một PR trượt CI là gánh nặng cho kỹ sư. Một PR qua được CI nhưng sai về chức năng sẽ bào mòn niềm tin vào toàn bộ hệ thống. Hãy thiết kế hướng về thất bại thứ nhất và tránh xa thất bại thứ ba.

Cái bẫy điểm tin cậy

Đây là kết quả phủ định giá trị nhất được công bố trong lĩnh vực này, và nó sẽ tiết kiệm cho bạn một quý làm việc.

Faire xây một công cụ review nội bộ tên faire-review và thử đòn bẩy chất lượng hiển nhiên trước tiên: lọc bình luận theo điểm tin cậy của chính model. Nó không hiệu quả. Ở ngưỡng khắt khe nhất, 65% số bình luận bị vứt bỏ mà tỷ lệ được chấp nhận chỉ nhích 3%. Bài viết của họ cho thấy một bình luận được chấm 0,93 bị bỏ qua nằm cạnh một bình luận chấm 0,35 lại được chấp nhận và sửa theo.

Thứ thực sự đưa tỷ lệ chấp nhận lên 73% là ngữ cảnh tốt hơn về thay đổi, nhắm đúng chỗ đáng đưa ra bình luận, và các cổng do model chấm thay cho một ngưỡng tất định. Điểm tin cậy tự báo cáo không phải là tín hiệu chất lượng. Một model thứ hai hỏi "bình luận này có đáng để con người bỏ thời gian không" mới là.

Review code bằng AI là phần được triển khai rộng rãi nhất của nhà máy phần mềm, và Uber đi đến kết luận tương tự từ một hướng khác với uReview, hiện bao phủ hơn 90% trong khoảng 65.000 diff mỗi tuần. Nguyên tắc của nó là độ chính xác thắng số lượng, vì lập trình viên mất niềm tin rất nhanh khi gợi ý nhiễu. Lợi ích đo được: 65% bình luận của uReview được xử lý trong cùng changeset, so với 51% của người review.

Phép kiểm tra mà test không bao phủ

Các bộ kiểm tra tất định trả lời câu hỏi code có biên dịch được và test có pass không. Cả hai câu hỏi đó đều không bao phủ việc trang web còn trông đúng hay không. Một thay đổi CSS có thể qua mọi kiểm tra ở vòng trong và âm thầm làm vỡ giao diện điện thoại, vì gần như không ai viết test khẳng định rằng bố cục là hợp lý.

Điều này đáng để bù đắp, vì nó chính xác là thất bại mà Spotify xếp hạng nguy hại nhất: một thay đổi qua được CI nhưng lại sai. Hãy cho agent một trình duyệt, và ghim quy trình thành một skill file để mọi agent trong fleet chạy cùng một cách thay vì tùy hứng:

---
name: visual-verify
description: Screenshot affected pages before and after a change, then attach the evidence to the PR.
---
## Verify
1. Read the git diff to identify which pages changed
2. Screenshot each affected page at 1280px and 375px before applying the change
3. Apply the change, then screenshot the same pages at the same two widths
4. Capture anything the browser console printed
## Report
Attach every screenshot to the pull request, labelled before and after.

Bước 1 là bước chịu lực. Đọc diff giữ phạm vi kiểm tra đúng vào những gì thực sự thay đổi, thay vì kiểm tra cả ứng dụng một cách hời hợt.

Bước cuối từng là chỗ quy trình này đứt. Tạo ảnh chụp màn hình thì dễ. Đưa chúng lên pull request lại cần một người kéo thả tệp vào ô bình luận, đưa con người trở lại vòng lặp đúng ở điểm bạn đang cố tự động hóa. GitHub đóng khoảng trống đó vào ngày 1 tháng 9 năm 2026 bằng cờ --attach có thể lặp lại, trong gh v2.99.0 trở lên:

gh pr comment "$PR" \
  --body "Visual verification: checkout flow, desktop and mobile." \
  --attach './before-1280.png#Checkout at 1280px, before' \
  --attach './after-1280.png#Checkout at 1280px, after' \
  --attach './before-375.png#Checkout at 375px, before' \
  --attach './after-375.png#Checkout at 375px, after'

Phần văn bản sau dấu # trở thành alt text, và gh sẽ dùng tên tệp nếu không có. Cờ này hoạt động giống nhau trên gh issue create, edit, comment, và gh pr create, edit, comment. Ảnh giới hạn ở 10MB; video là 10MB với gói miễn phí và 100MB với gói trả phí. GitHub Enterprise Server chưa được hỗ trợ trong bản phát hành này.

Một giới hạn thành thật. Cách này chứng minh trang đã render và luồng đã chạy. Nó không chứng minh thay đổi được xây dựng tốt hay sẽ trụ được đến quý sau. Nó diệt được thất bại kiểu "nói là đã sửa nhưng chưa bao giờ thật sự chạy thử", và nó không thay thế việc review.

Sắp xếp các kiểm tra theo chi phí

Stripe giới hạn agent ở tối đa hai lần chạy CI trước khi chuyển cho con người. Với hơn 3 triệu test, một chu kỳ CI là tài nguyên đắt đỏ, nên câu hỏi trở thành kiểm tra nào xứng đáng có một suất trước nó.

Thứ tự này rút ra từ kinh tế học đơn vị. Lint và test trả kết quả dưới năm giây tại máy cục bộ. Một tra cứu hệ sinh thái có giới hạn phạm vi tốn 2 credit cho mỗi 10 kết quả tính đến tháng 9 năm 2026. Một chu kỳ CI trên bộ test cỡ đó tốn kém hơn hẳn cả hai. Vậy nên khi agent viết code dựa trên một API mà nó chỉ nhớ mang máng, việc đối chiếu lời gọi đó với issue, PR và hướng dẫn migration thật trước khi push gần như miễn phí:

curl -X POST https://api.firecrawl.dev/v2/search/