# Hướng dẫn đầy đủ về Warp Factories

[Benjamin Holmes](https://homus.dev/speakers/benjamin-holmes) · [Warp](https://homus.dev/orgs/warp)

> Đi hết Warp Factories: dựng factory, agent và automation as code, chạy từ Slack, rồi đo cost per PR, scoring, self-improvement và benchmark.

Topics: Software Factory, Coding Agents, Agents, Evals

Canonical: https://homus.dev/talks/warp-factories-the-complete-guide

## 1. Một vòng quanh "factory floor"

Benjamin mở đầu bằng lời mời đi một vòng quanh "factory floor" (sàn nhà máy): xem qua mọi tính năng bên trong Warp Factories để hiểu chúng nối với nhau thế nào, theo bản sản phẩm trong video đăng ngày 28/09/2026. Lộ trình anh đặt ra như sau.

- Trước hết là tạo factory đầu tiên trông ra sao.

- Sau đó là cách mọi agent được cấu hình, và cách nối chúng với automation để agent nói chuyện được với thế giới bên ngoài qua Slack, Linear, Microsoft Teams, hay bất cứ công cụ nào team đang dùng (danh sách theo video đăng ngày 28/09/2026).

- Tiếp theo là phần cấu hình với secrets, MCP và integrations.

- Rồi anh cho xem cách khởi động một run bên trong factory bằng cách nói chuyện với nó qua Slack (theo video đăng ngày 28/09/2026).

- Cuối cùng là các dashboard để đo và cải thiện factory theo thời gian: bắt đầu từ dashboard về chi tiêu (spend metrics), sang scoring để chấm chất lượng agent một cách định tính, rồi tới các agent self-improvement và benchmarking, những agent lấy điểm số đó và biến chúng thành thay đổi trong chính factory (các tính năng theo video đăng ngày 28/09/2026).

"Có rất nhiều thứ phải đi qua", anh nói, và bắt đầu từ màn hình welcome.

![Benjamin Holmes nói trước camera, phía trước là một chiếc MacBook](https://homus.dev/photos/pkO1eHkr1v0-0027.jpg)

Benjamin Holmes giới thiệu lộ trình của buổi hướng dẫn Warp Factories trước khi chuyển sang màn hình sản phẩm (video đăng ngày 28/09/2026).

## 2. Màn hình welcome: kết nối code host và chọn repo

Đây là màn hình bạn gặp khi dựng factory đầu tiên. Benjamin lưu ý giao diện có thể trông hơi khác với bạn, nhưng khái niệm thì vẫn vậy (theo video đăng ngày 28/09/2026).

Bước đầu tiên là kết nối các code host bạn muốn dùng, để factory có thể làm việc cho bạn. Theo video đăng ngày 28/09/2026, Warp hỗ trợ nhiều code forge; trên màn hình có GitHub, GitLab và Azure DevOps, kèm một dòng cho trường hợp không có codeforge được hỗ trợ: bỏ qua và clone repo bằng setup command tuỳ chỉnh. Anh nói GitHub có lẽ sẽ là lựa chọn phổ biến nhất.

![Bước Connect your code hosts với GitHub, GitLab, Azure DevOps; bên phải là một comment review PR của warp-agent](https://homus.dev/photos/pkO1eHkr1v0-0103.jpg)

Bước "Connect your code hosts" trong onboarding (video đăng ngày 28/09/2026): ba nút Connect cho GitHub, GitLab và Azure DevOps. Khung bên phải minh hoạ một comment review PR mà bot warp-agent để lại, với các mục Overview, Concerns và Verdict.

Từ đó, bạn chọn những repository mà agent được phép truy cập. Factory chạy bên trong một cloud environment, nên bạn cần đặt những gì phải có sẵn trong môi trường đó. Theo lời Benjamin trong video đăng ngày 28/09/2026, Warp sẽ tự suy ra tooling cần thiết để làm việc trên các repo ấy, như JavaScript, Rust hay Python.

## 3. Đặt tên, avatar và foreman agent

Sau đó bạn đặt tên cho factory. Thường thì tên kết thúc bằng chữ "factory", nhưng bạn cũng có thể sáng tạo hơn một chút. Factory mà Benjamin sẽ cho xem trong suốt video (đăng ngày 28/09/2026) tên là **Wilson**, factory team anh dùng cho mọi việc của mình. Lý do: người trong team đã dựng factory này mang họ Wilson, nên tên factory được "lưu danh mãi mãi" theo người đó.

Bạn cũng có thể đặt avatar để dễ phân biệt các factory với nhau. Rồi tới phần mà anh gọi là quan trọng nhất: dựng các agent. Theo video đăng ngày 28/09/2026, mỗi factory đi kèm một **foreman agent**, agent chính bạn tương tác mỗi khi tạo issue hay nói chuyện với nó qua Slack.

![Bước Configure your Factory agents: Foreman, Triage, Spec, Code, Review và sơ đồ How agents work together](https://homus.dev/photos/pkO1eHkr1v0-0203.jpg)

Bước "Configure your Factory agents" (video đăng ngày 28/09/2026): foreman được gọi bằng tên @mobile-factory khi @-mention trong Slack, bên dưới là các agent Triage, Spec, Code, Review có công tắc bật tắt. Sơ đồ bên phải cho thấy việc mới (mention trên Slack, issue được giao, request trong Warp) đi vào Foreman, rồi được giao cho Triage, Code, Review, và Spec khi cần.

Nhưng factory còn có sẵn nhiều agent khác để làm những việc cụ thể bên trong (theo video đăng ngày 28/09/2026). Ở bước này trên màn hình, mục đặt tên foreman gợi ý `@mobile-factory`, chính là cái tên bạn sẽ dùng để @-mention foreman của factory trong Slack.

## 4. Đội agent phía sau foreman và các integration

Bạn tương tác với foreman, và nó có thể giao việc tiếp (hand off) cho các agent khác, theo mô tả trong video đăng ngày 28/09/2026:

- một **triage agent** cho các task research;

- một **coding agent** để implement code và đi qua computer use;

- hoặc một **code review agent** để chạy vài vòng code review trước khi gửi kết quả lại cho bạn (vai trò theo video đăng ngày 28/09/2026).

Sau đó là bước dựng integrations. Theo video đăng ngày 28/09/2026, Warp có Microsoft Teams và Slack, rồi tới các issue tracker như Linear hay Jira. Trên màn hình onboarding, mô tả của agent Triage ghi rằng nó nhận việc từ các công cụ issue tracking như Jira và Linear.

Cách Benjamin mô tả luồng việc trong một factory (video đăng ngày 28/09/2026): việc đến từ các integration, foreman nhận rồi giao cho triage, coding và code review agent.

## 5. Chọn model cho từng bước, bật self-improvement

Onboarding cũng giúp bạn cấu hình model muốn dùng trên toàn factory. Theo Benjamin (video đăng ngày 28/09/2026), một điểm khá riêng của Warp Factories là nhờ dùng Warp harness, bạn có thể chọn model riêng cho từng phần trong stack. Warp đặt sẵn vài gợi ý phổ biến: một cấu hình nếu bạn quan tâm tới chất lượng, một cấu hình nếu bạn quan tâm nhất tới hiệu quả chi phí.

Anh nói team đã đưa các open-weight model và Grok 4.6 vào cho một số task ở đây, còn GPT ở chỗ kia, và Warp sẽ liên tục cập nhật phần gợi ý này khi benchmark các model mới (theo video đăng ngày 28/09/2026). Trên màn hình, lựa chọn "More cost-efficient" gán `glm 5.3 flash` cho Foreman, Spec và Code, còn `grok 4.6 (high)` cho Triage và Review; dòng ghi chú bên dưới nói reasoning effort là một phần của lựa chọn model, model nào hỗ trợ thì xuất hiện một lần cho mỗi mức effort.

![Bước Choose default model config với Higher-quality outputs, More cost-efficient và bảng model mặc định cho từng agent](https://homus.dev/photos/pkO1eHkr1v0-0243.jpg)

Bước "Choose default model config" (video đăng ngày 28/09/2026): hai lựa chọn "Higher-quality outputs" và "More cost-efficient", rồi model mặc định cho từng agent. Khung bên phải minh hoạ một báo cáo benchmark với khuyến nghị "Warp/gpt-5", biểu đồ Correctness so với Average cost, và bảng Efficiency so Warp/grok 4.6, Codex/gpt-5 và Claude/Fable 5.

Điều chính cần nhớ, theo anh, là bạn có thể cấu hình model cho từng bước trong chuỗi software factory (tính năng theo video đăng ngày 28/09/2026). Onboarding còn có **self-improvement**: tính năng cho phép agent tự soi lại công việc mà mọi agent khác đang làm, bằng cách đọc qua các cuộc hội thoại của bạn.

Khi mọi thứ đã dựng xong, bạn được đưa tới một web UI, một dashboard cho mọi thứ đang diễn ra bên trong factory. Factory Benjamin đang cho xem là factory hoạt động nhiều nhất trong công ty anh: mọi task full stack của họ chạy qua đây (theo video đăng ngày 28/09/2026). Anh hẹn sẽ đi hết dashboard sau, còn ở mức tổng quát thì đây là nơi bạn quản lý và xem mọi thứ đang diễn ra.

## 6. Tab Agents: sub-agent riêng và cấu hình bằng code

Để bắt đầu, anh bấm vào tab Agents để xem mọi thứ được cấu hình thế nào. Ở đây là bản phản chiếu của những gì đã thấy trong onboarding: foreman agent, và các agent riêng cho từng việc team muốn làm (giao diện theo video đăng ngày 28/09/2026). Trên màn hình factory Wilson có foreman ("Orchestrates the factory workflow and dispatches each gated step"), code-review, implementation, spec và triage.

Theo video đăng ngày 28/09/2026, bạn cũng có thể cấu hình sub-agent của riêng mình trong tab này. Benjamin lấy hai ví dụ của team: tìm code owner, việc họ giao cho một model nhẹ; và các task design, được route sang một model khác với một bộ instruction khác. Tất cả cấu hình được trong tab Agents.

Ở phía trên tab có dòng "Managed in GitHub": mọi cấu hình đều được backed by code (theo video đăng ngày 28/09/2026). Phần code đó có thể quản lý ngay trong Warp Factories, hoặc trong chính repo GitHub của bạn để có version control. Với factory Wilson, màn hình ghi cấu hình chỉ đọc ở đây, muốn đổi thì sửa trong repo `warpdotdev/factory-dev` tại `main:v1`.

## 7. Định nghĩa Foreman trong một file markdown

Mọi agent ở đây đều được phản chiếu thành file markdown, mà bạn có thể vào xem rồi tự sửa hoặc nhờ một agent sửa (theo video đăng ngày 28/09/2026). Benjamin mở định nghĩa của Foreman. Phía trên là metadata: model được chọn cho agent đó, các MCP server nó được truy cập, rồi tới phần định nghĩa factory. Anh nói có thể coi phần này như system prompt của agent. Foreman chẳng hạn được dặn phải làm orchestrator.

![File factory-dev/v1/agents/foreman/agent.md trên GitHub với mục Foreman và Procedure](https://homus.dev/photos/pkO1eHkr1v0-0423.jpg)

File `factory-dev/v1/agents/foreman/agent.md` mở trên GitHub (136 dòng, video đăng ngày 28/09/2026): phần "Foreman" mô tả vai orchestrator và mục tiêu chi phí, tiếp theo là mục "Procedure".

Hai đoạn đầu của phần Foreman trên màn hình (video đăng ngày 28/09/2026):

```
You are the orchestrator ("foreman") of the software factory. The factory is a team of agents that automates the software development lifecycle from start to end. You accept work into the factory and keep the work in motion. For the most part, you do not do all the work yourself; you delegate to subagents to handle different parts of the lifecycle, like triage and code review.

Your objective is to reach the user's goal at the lowest cost that gets there. The stages below get more expensive as the work moves forward: a message is cheap, an issue is cheap, a spec costs a round of review, and implementation is by far the most expensive stage in time, compute, and tokens. A question asked before implementation is cheap. A pull request that nobody asked for, or one that solves the problem in a shape the user would not have chosen, is the most expensive mistake the factory makes. When you are not sure whether to move to a more expensive stage, ask; do not proceed on a guess.
```

Mục "Procedure" ngay sau mở đầu bằng ý: việc có thể đi vào quy trình ở bất kỳ giai đoạn nào, không chỉ từ đầu; một request có thể là work item mới, một PR cần comment được xử lý, một CI failure cần sửa, một thông báo merge, hay một câu trả lời cho câu hỏi đã hỏi trước đó.

Benjamin chỉ thêm các instruction điển hình trong file: phần bày ra cách mọi subagent làm việc, và cả instruction cho những agent làm riêng mà team dựng, như design agent, nên hoạt động thế nào. Tất cả chỉ là markdown, bạn sửa dần theo thời gian (theo video đăng ngày 28/09/2026).

## 8. Automations và các trigger: Slack, cron, GitHub

Khi đã có agent, bạn có thể dựng automation. Theo Benjamin (video đăng ngày 28/09/2026), đó là cách bạn nối agent với thế giới bên ngoài. Với một factory rất đơn giản như factory vừa dựng trong onboarding, bạn chỉ có automation cho các connector đã thêm. Ví dụ, nếu bạn thêm Slack làm integration, nó tự cho bạn một automation để nói chuyện với factory từ bất kỳ kênh Slack nào bạn có.

Theo thời gian, như factory full stack của team anh, bạn sẽ thêm ngày càng nhiều automation. Theo video đăng ngày 28/09/2026, mỗi automation có nhiều loại trigger:

- **Slack** là một trigger như vậy.

- **Cron schedule** cho những job bạn muốn chạy hằng ngày hoặc hằng tuần.

- **GitHub** làm trigger, theo anh rất hữu ích cho các flow PR hoặc sửa CI.

Danh sách automation của Wilson trên màn hình (video đăng ngày 28/09/2026) có ví dụ như `daily-factory-self-triage-report` chạy "Daily at 10:00 AM", `github-pr-closed-or-merged`, `linear-warp-mention`, `slack-dms`, `feedback-factory-digest` và `daily-factory-usage-digest`.

Anh bấm vào một automation: team dựng nó để mỗi khi CI fail trên một PR, một agent tự xem vì sao CI fail và đề xuất cách sửa (demo trong video đăng ngày 28/09/2026). Bạn đặt agent nào được automation đó kích hoạt; ở đây nó chỉ route tới foreman, để foreman quyết định ai xử lý. Bạn cũng đặt được các thuộc tính front-matter cho cách trigger chạy. Ở đây team quy định: bất cứ khi nào một issue được gắn label là thứ do factory tạo ra, factory được phép nhảy vào và theo dõi mọi thứ fail hoặc timeout.

![Automation github-factory-pr-ci-failure: trigger GitHub Workflow run completed, label factory:wilson, conclusions failure và timed_out](https://homus.dev/photos/pkO1eHkr1v0-0543.jpg)

Automation `github-factory-pr-ci-failure` (video đăng ngày 28/09/2026): trigger "GitHub · Workflow run completed", label `factory:wilson`, conclusions `failure, timed_out`, danh sách repository, agent foreman và agent prompt bắt đầu bằng "Diagnose and fix the failing check or workflow on the triggering pull request".

Bên dưới là các repository mà trigger áp dụng, và một prompt khá đơn giản sẽ được chạy. Theo video đăng ngày 28/09/2026, automation này khởi động một agent trong cloud environment của Warp với tất cả các repo đó trong scope, để push lên một thay đổi nếu cần.

Và một lần nữa, Benjamin chỉ ra rằng phần này cũng được cấu hình bằng code; anh nói đó sẽ là chủ đề lặp lại cho mọi thứ anh cho xem trong dashboard. Theo video đăng ngày 28/09/2026: agent được dựng bằng file markdown, automation cũng là file markdown, cấu hình webhook cũng vậy, các MCP server mà mỗi agent được truy cập cũng vậy. Tất cả đều là file code.

## 9. Integrations, MCP và secrets ở cấp team

Tiếp theo là chuyện nối agent với các dịch vụ khác. Trong tab automations đã thấy thoáng qua việc kết nối với integration bên ngoài, và chúng nằm ở cấp cao nhất ngay trong menu (giao diện theo video đăng ngày 28/09/2026).

Theo Benjamin (video đăng ngày 28/09/2026), integrations là những giải pháp rất "turnkey" (cắm là chạy) mà Warp đưa sẵn để nói chuyện với các dịch vụ phổ biến như task board, code forge, Slack và Microsoft Teams. Ngoài ra Warp cho truy cập MCP và quản lý secret.

Ví dụ ở team DevEx của anh, họ dựng vài MCP và secret cho orchestrator dùng (demo trong video đăng ngày 28/09/2026). Team dùng Notion để theo dõi mọi việc, nên họ muốn orchestrator mà họ nói chuyện cùng có thể nhanh chóng ghi nhận việc lên Notion mỗi khi được hỏi trong các kênh Slack. Vì vậy họ dựng MCP cho Notion và gắn nó vào foreman agent. Họ cũng thêm một secret để kết nối Twitter API, để mỗi khi agent dùng tới một skill nói chuyện với Twitter, secret đó có sẵn trong context của agent. Trên màn hình, phần Agent resources của "DevEx Factory Foreman Agent" có hai MCP là Notion và Typefully, một secret cho X API, harness Warp, model `glm 5.3 flash`, runner default và host "Warp hosted".

Mọi MCP và secret đó được định nghĩa ở cấp cao nhất cho team (theo video đăng ngày 28/09/2026). Tức là MCP và secret được xác thực một lần ở cấp team, rồi gắn vào từng factory agent khi cần. Chúng hỗ trợ cả OAuth, và trên màn hình có một số đang kết nối với dịch vụ bên thứ ba. Secret cũng được quản lý ở cấp team.

Benjamin nói thêm, nếu bạn thắc mắc, Warp cũng hỗ trợ GCP, Azure DevOps và AWS (theo video đăng ngày 28/09/2026): nếu bạn quản lý secret ở đó, chúng có thể được inject vào các môi trường nơi agent chạy. Còn nếu chỉ muốn một giải pháp turnkey, Warp có kho secret ngay bên trong: lưu trữ key-value được mã hoá, và agent chỉ truy cập được khi bạn bind secret đó vào định nghĩa của agent.

Cách quản lý MCP và secret Benjamin mô tả (video đăng ngày 28/09/2026): định nghĩa và xác thực ở cấp team, rồi chỉ agent nào được bind mới truy cập được.

## 10. Chạy factory từ Slack và đọc stream của agent

Đã xem cách agent được cấu hình, giờ Benjamin cho xem nhanh cách nói chuyện với các agent đó. Một pattern phổ biến, theo anh (video đăng ngày 28/09/2026), là tạo một kênh trong Slack để đồng đội vào mention factory và bắt đầu giao việc. Trong ví dụ của anh, anh đưa vào vài ảnh chụp mock muốn implement trong app, và để các agent bắt đầu làm.

Khi agent tương tác với bạn, theo video đăng ngày 28/09/2026, bạn luôn nhận được link để xem chi phí đang chạy (running cost) suốt cuộc hội thoại, cùng link để xem trực tiếp session của agent và xem nó bên trong factory.

Anh bấm vào một link để cho xem. Đây là stream đứng sau cuộc hội thoại đang diễn ra trên Slack. Anh chỉ ra rằng có rất nhiều metadata được thêm vào phía trên tin nhắn Slack của bạn để cho agent thêm context, và bạn thấy ngay trong dòng những gì agent đang làm (demo trong video đăng ngày 28/09/2026). Có cả một timeline view mở rộng để hiểu agent nào đang làm ở phần nào trong chuỗi.

![Run Update Homepage to Inbox View: stream của foreman bên trái và Timeline các agent bên phải](https://homus.dev/photos/pkO1eHkr1v0-0903.jpg)

Run "Update Homepage to Inbox View" (demo trong video đăng ngày 28/09/2026): bên trái là stream của foreman, gồm phần context về event-payload và file đính kèm, các dòng "Launched triage", "Launched implementation", "Launched code-review" và bản tóm tắt cuối về draft PR #6. Bên phải là Timeline theo từng agent, đang trỏ vào một lượt code-review "Succeeded".

Trong ví dụ này, foreman agent là agent chính bạn tương tác. Nó khởi động một triage agent cho task research, chuyển sang implementation qua vài vòng review, và cũng chạy vài vòng với code review agent để mở PR (demo trong video đăng ngày 28/09/2026).

Nếu dùng Slack làm cách chính để làm việc với agent, anh nói bạn sẽ không nhìn view này nhiều. Nhưng nó hữu ích như một "paper trail" (dấu vết giấy tờ) để hiểu mọi tool call agent đang thực thi và các pattern orchestration, giúp bạn debug; và lát nữa view này còn được dùng cho các flow scoring và self-improvement. Theo video đăng ngày 28/09/2026, nếu cần bạn cũng có thể tương tác trực tiếp với agent trong ô "Follow up" ở đây.

## 11. Danh sách runs, artifacts và computer use

Để hiểu các run hơn một chút, anh bấm vào trang chính Runs. Theo video đăng ngày 28/09/2026, đây là danh sách toàn cục mọi run đang diễn ra trên tất cả factory của team: "global context" của mọi thứ bạn đang làm, rất hữu ích để hiểu chi phí và cũng để cải thiện chất lượng factory. Ở view này bạn thấy mọi metadata để hiểu agent đã làm gì: PR được tạo, nguồn đã kích hoạt run, và các artifact nếu có.

Bấm vào side panel, anh cho xem các artifact sinh ra từ một pull request. Theo Benjamin (video đăng ngày 28/09/2026), mọi agent mặc định đều được trang bị computer use, nghĩa là nó có thể chụp màn hình hoặc quay lại công việc của mình để người xem review. Ở đây agent đã chụp màn hình menu trượt ra mà nó tạo, và quay một đoạn screen recording trên device simulator ngay trong box đó (demo trong video đăng ngày 28/09/2026).

![Artifact là đoạn quay iPhone Simulator mở app Warp Factories và sheet Select a factory](https://homus.dev/photos/pkO1eHkr1v0-1043.jpg)

Artifact thứ hai của PR "Increase top padding on factory picker sheet" (demo trong video đăng ngày 28/09/2026): đoạn quay iPhone Simulator dài 11 giây, mở app Warp Factories, xem màn hình inbox rồi bấm factory picker để bật sheet "Select a factory" với Wilson, atlas-docs và flaky-hunter.

Với factory mobile này, team thực ra dùng một macOS runner cho phần implementation. Theo video đăng ngày 28/09/2026, đó là một lựa chọn bạn có; Warp cũng có box Linux và box Windows để test. Linux là mặc định, nhưng với các workflow native cụ thể thì lựa chọn này, theo anh, rất hữu ích.

## 12. Dashboard Productivity: tương tác của người và cycle time

Hiểu xong mọi thứ agent làm, anh quay lại dashboard. Theo video đăng ngày 28/09/2026, đây là các metric tóm tắt mọi run vừa xem thành một view, để thấy bạn đang chi bao nhiêu và chất lượng công việc của agent ra sao. Đầu tiên là view **Productivity**, cho biết team đã năng suất thế nào khi dùng các agent này.

Metric đầu tiên là **human interactions per PR**: số lần người tương tác cho mỗi PR. Theo Benjamin (video đăng ngày 28/09/2026), đây là phép thử hữu ích để xem các workflow của bạn tự động tới mức nào: bạn phải bước vào một thread và cho agent thêm feedback bao nhiêu lần. Mục tiêu là kéo metric này xuống, để phần lớn thời gian bạn chỉ đặt một prompt và nhận về kết quả sẵn sàng để review.

![Dashboard Productivity của factory Wilson: Human interactions per PR, Median cycle time, Pull requests, Total runs](https://homus.dev/photos/pkO1eHkr1v0-1103.jpg)

Tab Productivity của factory Wilson, 30 ngày gần nhất trên dashboard của team Warp (video đăng ngày 28/09/2026): Human interactions per PR 8.4; median cycle time Kickoff → merge 13h, Kickoff → PR 35m, PR → first human review 4.4h, first human review → merge 17m; 2.156 pull request (1.200 merged); 11.517 total runs.

Bên cạnh có các metric về **cycle time**: khoảng cách từ prompt đầu tiên tới lúc thực sự có thứ được merge (theo video đăng ngày 28/09/2026). Anh nói nó hữu ích để xem, trước hết, agent tới được một thứ đáng review nhanh tới đâu, và tất nhiên kéo con số đó xuống là tốt. Rồi đi từ một artifact tới thứ bạn đã review và merge mất bao lâu.

Bên dưới là velocity tổng: bao nhiêu pull request đã được tạo, cùng tổng số run chạy qua factory, chia theo từng sub-agent đã nói ở trên: bao nhiêu run của foreman agent, của các workflow triage và research, v.v. (số liệu trên dashboard của team Warp, video đăng ngày 28/09/2026).

## 13. Tab Spending: cost per PR là thứ cần kéo xuống

Theo Benjamin (video đăng ngày 28/09/2026), tab **Spending** sẽ là một trong những tab quan trọng hơn cả, vì nó cho thấy velocity đó chuyển thành chi phí bạn trả ra sao. Metric đầu tiên là **cost per PR**: trung bình tốn bao nhiêu để đi từ một prompt tới thứ bạn muốn merge. Anh gọi đây là "holy grail", thứ bạn muốn kéo xuống. Bạn vẫn theo dõi code quality, phần sẽ nói ở mục scores, nhưng mục tiêu nên là kéo average cost per PR xuống theo thời gian.

Anh kể chính team mình đã thật sự cố kéo metric này xuống trên công việc của họ, và theo lời anh trong video đăng ngày 28/09/2026, họ đã khá thành công nhờ dùng benchmark và cơ chế scoring để hiểu nên chuyển sang model nào, và nên cải thiện skill thế nào để agent không phí nhiều tool call khi làm việc. Khi bạn tinh chỉnh dần những thứ đó, kết quả sẽ hiện ra trong các metric.

Bạn cũng xem được **spend by source** (chi tiêu theo nguồn), hữu ích để thấy mọi người đang truy cập factory qua đâu và nguồn nào chi nhiều nhất. Theo video đăng ngày 28/09/2026, phần lớn công việc của team anh diễn ra trên Slack, nên thanh màu tím trên biểu đồ là Slack. Ngoài ra còn có phân tích chi tiêu theo agent và theo model; anh nói nó cho bạn một tín hiệu sớm xem có model nào đang làm chi tiêu của bạn tăng lên không.

Các khối trong tab Spending theo lời Benjamin (video đăng ngày 28/09/2026). Hình vẽ lại bố cục, không mang số liệu thật.

## 14. Scoring: agent chấm chất lượng các cuộc hội thoại

Tab thứ ba, theo Benjamin là tab thú vị nhất, là **scoring**. Theo video đăng ngày 28/09/2026, ở đây các agent review lại các cuộc hội thoại đã qua và đánh giá một cách định tính cuộc hội thoại đó diễn ra thế nào và code trông ra sao.

Anh cho xem vài metric mẫu team đã dựng (theo video đăng ngày 28/09/2026):

- **Task compliance**: khi bạn giao việc, agent có thực sự làm đúng điều bạn dặn không (metric mẫu trong video đăng ngày 28/09/2026).

- **Efficiency**: số tool call để thực sự tạo ra thứ cần tạo. Agent đang "quay bánh xe tại chỗ" (spinning its wheels) hay đi tới lời giải nhanh?

- **Code quality**: tất nhiên chủ quan hơn một chút, nhưng agent có tuân theo các guideline kiến trúc tốt và các skill của chính bạn cho loại việc đó không (metric mẫu trong video đăng ngày 28/09/2026).

Trên dashboard Scorers của factory Wilson (30 ngày, video đăng ngày 28/09/2026), Efficiency ghi 48% (1.688 passed, 1.797 failed) và Code Quality 45% (546 passed, 678 failed).

Sang tab Scorers, Benjamin nói "say it with me": tất cả đều được cấu hình as code. Theo video đăng ngày 28/09/2026, mỗi scorer có một file markdown định nghĩa nó chấm cái gì, tiêu chí đánh giá ra sao và khi nào thì chạy. Bấm vào Efficiency chẳng hạn: scorer này được đặt để đánh giá mọi cuộc hội thoại bạn có với từng agent, và được giao một rubric định nghĩa thành công trông thế nào. Với bạn, code hiệu quả là gì? Đó là thứ bạn có thể ship dưới dạng một file markdown để hiện ra ở đây.

Bạn cũng đặt được judge model (trên màn hình là `gpt-5.6-luna (xhigh)`) và phần classification. Benjamin ví classification như cái rubric bạn từng nhận hồi đi học, từ điểm tệ tới điểm tốt. Trên màn hình, Efficiency có bốn mức: `highly_efficient` (1), `mostly_efficient` (0.8), `mostly_inefficient` (0.4), `highly_inefficient` (0.2), với pass threshold 0.80 (cấu hình theo video đăng ngày 28/09/2026).

![Cấu hình scorer Efficiency: bốn classification, Pass threshold 0.80, Sample rate 100%, công tắc Self-improvement](https://homus.dev/photos/pkO1eHkr1v0-1443.jpg)

Scorer Efficiency của factory Wilson (video đăng ngày 28/09/2026): bốn classification từ "highly_efficient" (agent đi đường thẳng, không đọc lại hay chạy lại, không làm lại việc) tới "highly_inefficient", pass threshold 0.80, sample rate 100%, và công tắc Self-improvement để phân tích các run fail rồi gợi ý cải tiến cho factory.

Bạn còn đặt **sample rate**: agent này review công việc trong factory thường xuyên tới đâu. Theo video đăng ngày 28/09/2026, bạn có thể giảm xuống nếu chỉ muốn nó chạy trên vài cuộc hội thoại, hoặc đặt 100% để chấm mọi cuộc hội thoại.

Mở phần chi tiết của efficiency agent, anh cho xem nó đã chạy bao nhiêu run. Vì team đặt nó chạy "aggressively" trên mọi cuộc hội thoại, chi phí cộng dồn khá cao, theo lời anh (video đăng ngày 28/09/2026). Nhưng bạn thấy được phân tích theo từng task, và việc scorer đánh giá cuộc hội thoại đó là kết quả tốt hay tệ. Đây là "giám khảo" nhìn mọi thứ ở phía sau. Theo thời gian, bạn thấy hiệu quả của factory thay đổi ra sao; anh nói điều này hữu ích để xem, nếu team ship thay đổi cho skill nhằm cải thiện efficiency, thì có thấy nó hiện ra trong tiêu chí chấm không.

## 15. Self-improvement: agent sửa chính factory

Nhân nói về chuyện ship thay đổi cho skill, Benjamin chuyển sang tab **Self-improvement**. Theo video đăng ngày 28/09/2026, đây là một agent khác chạy theo lịch bạn đặt, có thể mỗi tuần, mỗi giờ hay mỗi ngày một lần. Nó xem qua mọi điểm số đã đổ về, tìm những điểm fail; quay lại metric efficiency, đó là bất cứ thứ gì bị scorer này hay bất kỳ scoring agent nào khác cho fail. Rồi self-improvement agent xem hết những điểm fail đó và tìm xem có thay đổi nào cho factory để tránh các lỗi đó trong tương lai không.

Team anh cấu hình agent này chạy khá "aggressively", vài giờ một lần (theo video đăng ngày 28/09/2026); trên màn hình ghi "Last check 15 minutes ago · Next in about 2 hours". Trang này liệt kê mọi pull request agent đã mở để cải thiện setup của factory dựa trên các lần fail trước, mỗi dòng ghi thay đổi, repository, agent liên quan và thời điểm mở.

Trong ví dụ anh mở (demo trong video đăng ngày 28/09/2026), agent đã review vài run fail của design agent và nhận ra design agent cứ đi tìm những link artifact view không tồn tại, một khoản tool calling bị phí. Nó trích dẫn bằng chứng, là các run đã được chấm điểm trước đó, và đề xuất thay đổi cho skill liên quan.

![Draft PR #969 Stop asking the design agent for artifact view links that don't exist, mục Evidence](https://homus.dev/photos/pkO1eHkr1v0-1623.jpg)

Draft PR #969 "Stop asking the design agent for artifact view links that don't exist" do bot `warp-agent-staging` mở từ nhánh self-improvement (demo trong video đăng ngày 28/09/2026). Mục Evidence dẫn hai run: lần đầu agent chỉ trả về UID của artifact, phải thay bằng link Figma, tốn thêm một vòng và ba call; lần sau cùng lỗ hổng lặp lại. Nguyên nhân ghi trong PR: file `agent.md` của design và skill `ui-verification` đều dặn "return each artifact view link and UID", điều mà upload tool không làm được.

Team có thể merge thay đổi này vào setup để cải thiện factory khi đi tiếp (theo video đăng ngày 28/09/2026). Để thêm chút context, Benjamin giải thích: mọi skill đứng sau factory đều nằm cùng chỗ với toàn bộ code khác, tức cấu hình agent và cấu hình automation đã xem lúc trước. Bạn lưu mọi skill trong đó để agent truy cập và thay đổi được chúng. Tương tự, cấu hình của các scorer cũng được lưu dưới dạng code cho tất cả các agent đó.

## 16. Benchmarks và Factory MCP

Cuối cùng là tab **Benchmarks**. Theo Benjamin (video đăng ngày 28/09/2026), đây là use case nâng cao nhất bạn có trong Warp Factories, nhưng là một use case thật sự hữu ích. Benchmark ở đây là benchmark tuỳ chỉnh, chạy bằng cách replay các cuộc hội thoại agent đã qua trên mọi model bạn muốn thử. Use case: bạn muốn kéo chi phí factory xuống, và muốn so vài model khác nhau để xem chúng làm thế nào về code quality và chi phí.

Để tạo benchmark mới, bạn có thể dùng UI, hoặc theo kinh nghiệm của team (video đăng ngày 28/09/2026), cuối cùng bạn sẽ nhờ một agent tạo benchmark giúp, dựa trên một mẫu các task trong factory. Ở đây team dùng **Factory MCP** để xem qua mọi cuộc hội thoại và tìm ra một benchmark tốt để chạy. Theo anh, Factory MCP là thứ bất kỳ agent nào cũng truy cập được để xem toàn bộ dữ liệu factory của bạn.

![Phiên agent trong Warp tạo benchmark candidate scaffold với Tier counts và Area counts](https://homus.dev/photos/pkO1eHkr1v0-1743.jpg)

Phiên agent trong Warp tạo "benchmark candidate scaffold" trong `v1/simple-frontend-tasks/` (demo trong video đăng ngày 28/09/2026): 2.143 candidate đã sàng lọc và xếp hạng, loại 574 trong 2.717 PR đã merge, chia Easy 528, Medium 939, Hard 676, kèm số lượng theo mảng như Go backend, React Factory, Tooling, Full-stack.

Trong demo (video đăng ngày 28/09/2026), agent đã xem qua các cuộc hội thoại trước, nắm được một bộ task dễ, trung bình và khó có thể dùng để benchmark các model. Rồi benchmark đó được commit, lại một lần nữa as code, vào factory definition. Trong thư mục benchmarks có một entry mới với một suite định nghĩa mọi task sẽ chạy trong benchmark đó, và định nghĩa đầy đủ của từng task trong một thư mục con; trên màn hình GitHub, thư mục `warp-bench-1.0` có `tasks`, `manifest.json` và `suite.yaml`.

Khi bạn commit benchmark, nó xuất hiện trong tab Benchmarks, và bấm vào là chạy được benchmark đó (theo video đăng ngày 28/09/2026). Trên màn hình, danh sách của Wilson có các mục như "Review Default Model Selection", "Spec Default Model Selection", "Foreman Default Model Selection", `warp-bench-1.0` và `warp-bench-1.0-mini`. Benjamin nói Warp có những video riêng về cách đọc báo cáo, nhưng bạn sẽ thấy mọi run ở đây, và bấm vào sẽ thấy model thắng benchmark đó cùng phân tích từng model đã làm ra sao.

Với phần này, anh nói họ đã đi qua gần như mọi khía cạnh của một factory, từ onboarding tới dựng benchmark tuỳ chỉnh. Muốn tìm hiểu thêm, anh mời người xem vào tài liệu của Warp để hiểu các tính năng này hoạt động thế nào. Video đăng ngày 28/09/2026 khép lại khi anh chào bằng câu "happy automating" và cảm ơn người xem.

## Nguồn và liên kết

- Tên gốc: Warp Factories - the complete guide
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=pkO1eHkr1v0](https://www.youtube.com/watch?v=pkO1eHkr1v0)

- Kênh YouTube Warp (Benjamin Holmes): [youtube.com/channel/UCKONdcQCTP3aozARj1ntKhw](https://www.youtube.com/channel/UCKONdcQCTP3aozARj1ntKhw)

- Trang sản phẩm Warp Factories (đọc ngày 24/10/2026): [warp.dev/factories](https://www.warp.dev/factories)

- Tài liệu Warp Factories, trang tổng quan (đọc ngày 24/10/2026): [docs.warp.dev/factories](https://docs.warp.dev/factories/)

- Quickstart: kết nối repo và gửi request đầu tiên (đọc ngày 24/10/2026): [docs.warp.dev/factories/quickstart](https://docs.warp.dev/factories/quickstart/)

- Factory definition syntax: cây file YAML và Markdown định nghĩa agent, automation, benchmark, scorer, skill, webhook (đọc ngày 24/10/2026): [docs.warp.dev/factories/factory-as-code](https://docs.warp.dev/factories/factory-as-code/)

- Factory dashboard (đọc ngày 24/10/2026): [docs.warp.dev/factories/factory-dashboard](https://docs.warp.dev/factories/factory-dashboard/)

- Factory benchmarks (đọc ngày 24/10/2026): [docs.warp.dev/factories/benchmarks](https://docs.warp.dev/factories/benchmarks/)

- Factory MCP cho coding agent (đọc ngày 24/10/2026): [docs.warp.dev/factories/factory-mcp](https://docs.warp.dev/factories/factory-mcp/)

Nguồn: https://homus.dev/talks/warp-factories-the-complete-guide · cập nhật 2026-10-24