
Phát triển Ứng dụng Doanh nghiệp Toàn diện với Agent Mã hóa harnext
Mười tháng, 1.409 PR được hợp nhất, ba cuộc kiểm toán pháp y: cách một pipeline agent được giai đoạn hóa đã đưa một codebase doanh nghiệp từ 12% đến 92% phát tr...

Cùng một pull request, cùng một prompt, cùng một model — chỉ có cách tải context khác nhau. Một context-engine digest cộng với một lần đọc tệp policy đánh bại việc đọc tài liệu về cả chi phí lẫn chất lượng. Dữ liệu đầy đủ bên trong.
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.
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ì?
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ừ đó.
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.
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.
| 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.
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.
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ó.
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.
model củ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.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.
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.
Štefan là một kỹ sư AI và phần mềm đang xây dựng FlowHunt. Ngoài sản phẩm itself, anh thiết kế các quy trình kỹ thuật phần mềm agentic cho các nhà phát triển giúp giảm chi phí phát triển đồng thời nâng cao chất lượng mã.

FlowHunt giúp các nhóm kỹ thuật thiết kế agentic workflows, context gates, và MCP integrations giúp giảm chi phí phát triển trong khi nâng cao chất lượng code.

Mười tháng, 1.409 PR được hợp nhất, ba cuộc kiểm toán pháp y: cách một pipeline agent được giai đoạn hóa đã đưa một codebase doanh nghiệp từ 12% đến 92% phát tr...

Khóa đào tạo thực hành cho nhà phát triển phần mềm: ngừng trông chừng các trình soạn thảo AI và tự động hóa toàn bộ vòng đời phát triển của bạn với CodeFactory,...
So sánh kỹ thuật chuyên sâu về cách 11 framework AI agent hàng đầu—từ Claude Code và CrewAI đến Voyager và DSPy—chèn kỹ năng, công cụ và chuyên môn vào cửa sổ n...
Đồng Ý Cookie
Chúng tôi sử dụng cookie để cải thiện trải nghiệm duyệt web của bạn và phân tích lưu lượng truy cập của mình. See our privacy policy.