Chúng tôi đã giao cùng một tác vụ code-review cho 22 AI agents. Cùng một pull request, cùng một commit được ghim, cùng một prompt, cùng một model — biến duy nhất là cách mỗi agent tải các quy tắc của dự án. Cấu hình rẻ nhất hóa ra là cấu hình kỹ lưỡng nhất, và lý do tại sao điều này nói điều gì đó chung chung về context engineering.
TL;DR: Một context-engine digest cộng với một lần đọc trực tiếp tệp chính sách có thể đọc được bằng máy đánh bại mọi chiến lược khác: $1,56 mỗi bài đánh giá và 9,6/13 phát hiện được xác minh — rẻ hơn việc đọc tài liệu ($2,30, 8,6/13) và tốt hơn digest một mình ($1,77, 7,8/13). Đọc mọi thứ có điểm kém nhất (7,4/13). Tất cả 22 agents chạy trên Claude Opus 4.8, và 21 trên 22 đạt được cùng một kết luận.
Cái Gì: một harness, một context engine, và một pull request
“Harness” là gì?
Mỗi nỗ lực nghiêm túc để cho phép các AI agents làm việc trong một kho lưu trữ sản xuất phát triển hai lớp quản trị.
Lớp prose — quy ước, quy tắc kiến trúc, tiêu chuẩn kiểm tra. Trong kho lưu trữ của chúng tôi đó là CLAUDE.md và docs/**: “backend là snake_case,” “domain không bao giờ nhập infrastructure,” “tất cả các route handlers đều là async.” Con người đọc nó; agents được yêu cầu đọc nó cũng vậy.
Lớp có thể đọc được bằng máy — harness config. Của chúng tôi là một tệp JSON duy nhất phân loại mọi đường dẫn trong kho lưu trữ thành các risk tiers và gắn kèm các gates có thể thực thi được cho mỗi tier. CI đọc nó. Merge policy đọc nó. Nó không phải là lời khuyên — nó là chính sách:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Lưu ý về thuật ngữ: “harness” cũng đặt tên cho runtime của agent — các giàn giáo công cụ, kỹ năng, và MCP servers mà một agent hoạt động thông qua, như trong harnext , “the coding agent harness.” Trong bài đăng này, harness config là tệp chính sách của kho lưu trữ mà một runtime như vậy và CI đều thực thi.)
Một code reviewer — con người hoặc agent — không thể đánh giá “PR này có được phép merge không?” mà không có tệp này. Một Tier-3 PR với kiểm tra review-agent bị bỏ qua là một vi phạm chính sách ngay cả khi mọi bài kiểm tra đều xanh. Hãy nhớ ví dụ đó; nó quyết định thử nghiệm.
Bởi vì cả hai lớp đều tồn tại, kho lưu trữ yêu cầu một gate: không agent nào bắt đầu công việc trước khi tải context này — và chứng minh rằng nó đã làm được, thông qua một khối xác nhận mà những người xem xét kiểm tra. Câu hỏi bài đăng này trả lời rất đơn giản: cách rẻ nhất chính xác để thỏa mãn gate đó là gì?
Gặp harnext và meaninggrid
meaninggrid là Context Engine được lưu trữ từ harnext
, MIT-licensed, provider-agnostic coding-agent harness của QualityUnit (sáu công cụ — read, write, edit, bash, skill, mcp — npm i -g harnext). Lập trình của nhà cung cấp cho Context Engine là thẳng thắn: “bộ não của agent của bạn.” Các nguồn chảy vào một chỉ mục được cập nhật liên tục — “the grid” — và mỗi truy vấn engine “xếp hạng và cắt nó thành context hiệu quả token, được nối thẳng vào harness”: continuous index, relevance ranking, dedup and cache. Con số tiêu đề của harnext là −89% tokens mỗi truy vấn trung bình. Đó là tuyên bố của nhà cung cấp; một mục đích của thử nghiệm này là đo lường, với các con số riêng của chúng tôi trên một tác vụ thực tế, nó tiết kiệm được gì thực sự — và nó có chi phí gì.
Trong triển khai của chúng tôi, grid lấy tài liệu prose của kho lưu trữ; mỗi lần lấy tạo ra một snapshot bất biến, có phiên bản. Các agents truy vấn nó qua MCP (meaninggrid.harnext.dev/mcp) với một lệnh gọi context_research duy nhất và nhận một digest được tổng hợp, được trích dẫn được đóng dấu với snapshot_id, mà agent phải trích dẫn trong khối xác nhận của nó — context có thể kiểm toán được được thực hiện cụ thể.
Cái mà gate tạo ra — khối xác nhận (ví dụ; chi tiết dự án được che):
Loaded via: optimized hybrid (context-engine digest + policy file only).
- context_research call #1 (conventions / layering / testing / security /
risk tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integration checklist +
flow-engine extra-care rules) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Read harness config (full) from disk for exact tier patterns,
requiredChecks, mergePolicy, evidenceConfig.
Did NOT read CLAUDE.md or docs/* (covered by the digest).
snapshot_id là thực — một người xem xét có thể xác minh chính xác phiên bản nào của các quy tắc mà agent đã làm việc từ đó.
Ba giả thuyết
Thử nghiệm được thiết kế để giải quyết ba dự đoán có thể kiểm tra được, được viết lại trước đó:
H1 — Một digest rẻ hơn việc đọc lại. Lấy tài liệu prose một lần, phục vụ cho mỗi agent một digest được tổng hợp nhỏ gọn, thay vì mỗi agent phải đọc lại mọi tài liệu trên mỗi tác vụ. Nếu đúng: chi phí mỗi bài đánh giá có ý nghĩa thấp hơn, ở những kết luận bằng nhau.
H2 — Paraphrase phá hủy chính sách. Một digest có thể mang “Tier 3 yêu cầu xem xét con người” mà không mất mát. Nó không thể mang "requireReviewAgent": true mà không mất mát — những chi tiết chính xác, có thể trích dẫn mà những người xem xét cần để khẳng định một vi phạm chết trong bản tóm tắt. Nếu đúng: các agents chỉ có digest nên có tính năng bỏ qua các vi phạm gate mà các agents giữ tệp chính sách theo nghĩa đen bắt được.
H3 — Context gọn hơn đọc sâu hơn. Context được thanh toán hai lần — một lần bằng đô la, một lần bằng sự chú ý: mỗi tài liệu dư thừa trong cửa sổ cạnh tranh với mã đang được xem xét. Nếu đúng: đọc mọi thứ (digest + tất cả docs) không nên thắng; cấu hình đủ gọn nhất nên.
Cách chúng tôi kiểm tra nó
Hai mươi hai agents đã xem xét cùng một Tier-3 pull request trong kho lưu trữ sản xuất của chúng tôi (một LLM-provider integration: 44 tệp, +2.111 dòng, những cổ phần thực — billing tables, flow-engine routing). Năm cánh tay, khác nhau chỉ ở bước tải context:
| Arm | Context loading | n |
|---|---|---|
| meaninggrid | context-engine digest only (2× context_research) | 5 |
| disk | reads 7+ docs from disk — no context engine | 5 |
| hybrid | digest + reads ALL the docs | 5 |
| opt-hybrid | digest + reads ONE file: the harness config | 5 |
| cold | no convention context at all (baseline) | 2 |
Quy tắc cơ bản: một commit được ghim, một phần thân prompt, một model — Claude Opus 4.8 — tất cả các cánh tay xen kẽ trong một batch đồng thời duy nhất. Các agents bị cấm khỏi chuỗi bình luận của PR, vì vậy các vòng thử nghiệm trước đó không thể rò rỉ vào. Mỗi con số đến từ các raw agent transcripts, với mức sử dụng token được khử trùng lặp mỗi yêu cầu API và được định giá theo giá danh sách. Chất lượng được chấm điểm dựa trên 13 lỗi được xác minh độc lập, thực tế trong PR, pattern-matched trong phần thân của mỗi bài đánh giá và được kiểm toán thủ công để tìm false positives. Thỏa thuận kết luận trên tất cả các cánh tay: 21/22 nói REQUEST CHANGES.
Vì vậy cái gì: cấu hình rẻ nhất cũng thắng về chất lượng
| Arm | Cost / review | Findings (of 13) | Gate findings (of 3) | Wall clock |
|---|---|---|---|---|
| meaninggrid | $1.77 | 7.8 | 0.2 | 5:34 |
| disk | $2.30 | 8.6 | 0.8 | 4:35 |
| hybrid | $1.83 | 7.4 | 0.8 | 5:40 |
| opt-hybrid ★ | $1.56 | 9.6 | 1.4 | 4:55 |
| cold | $1.64 | 8.0 | 0.5 | 4:13 |
★ = cấu hình chúng tôi hiện gửi làm kỹ năng mặc định của kho lưu trữ. Wall clock bao gồm tranh chấp chia sẻ từ việc chạy 22 agents đồng thời.
H1 — được xác nhận
Cánh tay chỉ có digest đã xem xét với giá $1,77 so với $2,30 cho việc đọc tài liệu (−23%), và cánh tay thắng digest-plus-one-file với giá $1,56 (−32%) — ở những kết luận bằng nhau. Tiết kiệm hợp chất: digest thay thế một ngăn xếp tài liệu mà nếu không sẽ đi qua mỗi lệnh gọi API tiếp theo của context.
H2 — được xác nhận, quyết định
Kiểm tra review-agent bị bỏ qua — một vi phạm merge-policy thực sự trong PR này — đã được bắt bởi 5 trên 5 agents giữ tệp chính sách theo nghĩa đen, và bởi 1 trên 5 agents chỉ có digest. Cơ chế chính xác là những gì H2 dự đoán: để viết phát hiện đó, một agent phải khớp tên kiểm tra CI chính xác với các trường cấu hình chính xác — một paraphrase không phải là bằng chứng có thể trích dẫn, vì vậy các agents chỉ có digest che phủ và thả nó. Một lần đọc trực tiếp khôi phục nó.
H3 — được xác nhận
Hybrid đọc mọi thứ mang context nhiều nhất của bất kỳ cánh tay nào và có điểm kém nhất (7,4/13), trong khi cánh tay đủ gọn nhất có điểm tốt nhất (9,6/13) — và là tốt nhất của tất cả các cánh tay ở phát hiện sâu nhất duy nhất, một lỗi mã chết yêu cầu truy vết một đường dẫn cuộc gọi trên ba tệp. Prose dư thừa không thêm thông tin; nó cạnh tranh với mã để có được sự chú ý.
Một chú thích trung thực: baseline lạnh (8,0/13 ở $1,64) cho thấy rằng hầu hết 13 lỗi là những lỗi mã đơn giản mà một model mạnh mẽ tìm thấy mà không có convention context nào cả. Cái mà lạnh không thể làm là nửa chính sách của công việc — gates, tiers, merge rules — đó chính xác là nơi các cánh tay tách biệt.
Sắp xếp prose thành một digest. Đọc tệp chính sách raw. Đừng đọc bất cứ thứ gì hai lần.
Công khai đầy đủ
- Model: mỗi lệnh gọi API của mỗi agent chạy trên claude-opus-4-8 (Claude Opus 4.8) — được xác minh từ trường
modelcủa mỗi dòng transcript, không được giả định. Kết quả có thể khác nhau trên các model khác; các model nhỏ hơn có thể phụ thuộc nhiều hơn vào context được sắp xếp, không phải ít hơn. - Giá cả: chi phí sử dụng giá danh sách của Anthropic tại thời điểm viết; hóa đơn thực tế có thể khác. Các so sánh tương đối không bị ảnh hưởng.
- Kích thước mẫu: n=5 mỗi cánh tay (n=2 cho lạnh), một PR, một kho lưu trữ, một loại tác vụ. Hiệu ứng gate (5/5 so với 1/5) là sắc nét; tỷ lệ mỗi phát hiện ở nơi khác là ±1 agent. Coi nó như một pilot mạnh mẽ, không phải một benchmark.
- Chỉ số chất lượng: phát hiện mẫu trên văn bản xem xét (trích dẫn bị loại trừ), được kiểm toán thủ công để tìm false positives. Nó đếm đề cập của các lỗi được xác minh, không phải sự hùng biện xem xét tổng thể.
- Thời gian: tất cả 22 agents chia sẻ một máy và một API quota; các con số wall-clock bao gồm tranh chấp đó.
- Chúng tôi đã sửa chính mình hai lần: số lượng token ban đầu bị phóng đại 2–3× (mỗi dòng sử dụng duplication trong transcripts; được sửa bằng request-ID dedup), và một hình ảnh thời gian trước đó undercounted wall time (được sửa bằng full interval attribution). Cả hai sửa chữa đều được baked vào mỗi con số ở đây.
Sẵn sàng phát triển doanh nghiệp của bạn?
Bắt đầu dùng thử miễn phí ngay hôm nay và xem kết quả trong vài ngày.
Bây giờ cái gì: ăn cắp vòng lặp
Cái chúng tôi đã gửi
Cánh tay thắng hiện là check-context-first skill mặc định của kho lưu trữ: kéo context-engine digest (hai lệnh gọi), sau đó đọc chính xác một tệp từ đĩa — harness config — và phát ra một khối xác nhận trích dẫn snapshot và các gates chính xác. Một điểm yếu được đo lường, một bản sửa chính sách một dòng, được xác nhận lại cùng ngày. Vòng lặp đó — đo lường, sửa chính sách context, xác nhận lại — là phần chúng tôi muốn khuyến khích bạn ăn cắp, bất kể context engine nào bạn sử dụng.
Cái bạn có thể làm vào Thứ Hai
- Chia context của agent thành hai phần: prose (quy ước, kiến trúc, kiểm tra) so với chính sách có thể đọc được bằng máy (CI gates, risk tiers, merge rules).
- Tóm tắt prose; không bao giờ tóm tắt chính sách. Phục vụ prose thông qua một context engine — meaninggrid là của chúng tôi — và làm cho tệp chính sách trở thành một lần đọc theo nghĩa đen bắt buộc trong context gate của bạn.
- Làm context có thể kiểm toán được. Phiên bản context được lấy vào; yêu cầu các agent trích dẫn id snapshot trong một khối xác nhận mà những người xem xét thực sự có thể kiểm tra.
- Đo lường trước khi bạn tin — bao gồm chúng tôi. Một số agents mỗi cánh tay trên kho lưu trữ của riêng bạn là đủ để thấy mẫu. Chấm điểm các bài đánh giá dựa trên các phát hiện được xác minh, không phải vibes.
Một lời mời cởi mở
Nếu bạn chạy thử nghiệm này trên kho lưu trữ của riêng bạn — các cánh tay tương tự, model của bạn, harness của bạn — chúng tôi thực sự muốn xem các con số của bạn, đặc biệt nếu chúng bác bỏ của chúng tôi. Và nếu nhóm của bạn muốn giúp thiết lập một context gate như thế này, hoặc muốn nói về meaninggrid và harnext stack, hãy liên hệ với nhóm FlowHunt hoặc tìm open-source harness tại harnext.dev . Các sao chép, câu hỏi, và sửa chữa đều được chào đón.
