5 cấp độ của AI Agents: Từ Prompt đến Production

Hiện tại, có năm thuật ngữ mà mọi người hay nhắc đến khi nói về agent: context engineering, loop engineering, Jev engineering, harness engineering và eval engineering.

Nghe thì có vẻ như năm hướng tiếp cận đang cạnh tranh nhau. Nhưng không phải. Chúng là năm lớp của cùng một hệ thống, và mỗi lớp giải quyết đúng một câu hỏi.

Cách dễ nhất để hình dung là hãy tưởng tượng bạn vừa tuyển một nhân viên mới:

• Context – trên bàn làm việc của anh ấy có gì khi bạn giao việc
• Loop – anh ấy làm theo checklist của bạn hay tự tìm ra bước tiếp theo
• Jev – quầy lễ tân phân loại thư từ, để anh ấy chỉ thấy những gì quan trọng
• Harness – văn phòng của anh ấy. Công cụ, chìa khóa, và ai là người kiểm tra công việc
• Evals – bài kiểm tra giống nhau mỗi tháng, để bạn biết anh ấy thực sự tiến bộ

Một AI agent chính là nhân viên đó. Model là con người, còn năm lớp này là mọi thứ xung quanh anh ta. Làm tốt năm lớp này, một đội ngũ nhỏ có thể đảm nhận khối lượng công việc mà trước đây phải tuyển thêm người. Những việc lặp đi lặp lại sẽ do agent xử lý ổn định trên production, còn người của bạn giữ quyền ra quyết định. Đó chính là cách mở rộng quy mô mà không cần tăng nhân sự trong thực tế.

Với mỗi lớp, tôi sẽ phân tích nó là gì, hoạt động ra sao, dùng khi nào và cách xây dựng.

Và với mỗi lớp, tôi cũng chuẩn bị sẵn một "lối tắt". Một cách đơn giản hơn để đạt kết quả tương tự mà không cần xây từ đầu, dành cho người mới bắt đầu. Những người bạn ở Viktor đã giúp tôi tổng hợp các lối tắt này.

Viktor là một nhân viên AI sống ngay trong Slack hoặc Microsoft Teams của bạn. Anh ấy ở cùng channel với mọi người và làm việc như một đồng đội thực thụ – một người bạn thêm vào team mà không cần mở vị trí tuyển dụng mới.

Làm việc với anh ấy y hệt như làm việc với một người thật:

• Bạn tag anh ấy trong một channel hoặc thread rồi mô tả công việc.
• Anh ấy tự vạch ra các bước, xử lý xuyên suốt các công cụ của bạn và trả kết quả về đúng thread đó.

Cài đặt rất đơn giản. Chỉ cần thêm Viktor vào workspace, anh ấy sẽ xuất hiện trong danh sách thành viên như bất kỳ ai khác trong team. Nếu muốn dùng thử ngay khi đang đọc bài, hãy nhập mã YARCHI100.

Hình 1. Năm lớp của một agent

1. Context engineering

Định nghĩa

Trước mỗi câu hỏi, bạn đặt tài liệu lên bàn của nhân viên. Đặt đúng ba trang cần thiết, anh ấy trả lời trong vài giây. Đặt ba trăm trang, câu trả lời sẽ bị chôn vùi giữa đống giấy tờ. Anh ấy bỏ sót luôn.

Model chính là nhân viên đó. Cái bàn là context window: mọi thứ model nhìn thấy trước khi trả lời. Chỉ thị của bạn, đoạn chat tính đến lúc đó, tài liệu lấy từ database, output của mọi tool đã chạy.

Context engineering là việc quyết định đặt gì lên bàn, và đặt ở đâu.

Cách hoạt động

Nhiều context hơn không có nghĩa là câu trả lời tốt hơn. Vượt qua một ngưỡng nhất định, nó lại cho kết quả tệ hơn.

Stanford đã kiểm chứng trực tiếp điều này. Đưa cho model 20 đến 30 tài liệu, độ chính xác với những tài liệu nằm ở giữa giảm xuống chỉ còn khoảng 50 đến 57 phần trăm. Khi không có tài liệu nào, cũng model đó lại đạt 56 phần trăm. Câu trả lời nằm ngay trong window mà model còn làm tệ hơn cả khi không có gì.

Có hai nguyên nhân dẫn đến việc này:

• Model chú ý nhiều nhất vào phần đầu và phần cuối của window, ít chú ý nhất vào phần giữa.
• Mỗi token đều tốn tiền và thời gian, dù nó có hữu ích hay không.

Cơ chế duy nhất đáng để bạn nắm là prompt caching. Nhà cung cấp lưu lại phần đầu prompt của bạn và tái sử dụng ở lần gọi tiếp theo, một token được cache rẻ hơn khoảng mười lần so với token mới.

Điểm mấu chốt: cache chỉ hoạt động nếu phần đầu đó giống hệt nhau, từng byte một. Đổi một ký tự ở gần đầu, mọi thứ phía sau sẽ bị tính giá đầy đủ. Vì vậy, nguyên tắc luôn là: nội dung cố định để trước, nội dung thay đổi để sau.

Cách xây dựng

Mọi mảnh context đều rơi vào một trong bốn chỗ:

1. System prompt. Chỉ chứa những gì luôn đúng ở mọi lần gọi: vai trò, giới hạn, định dạng output. Giữ nguyên từng byte. Không để timestamp ở đầu, không để key JSON lộn xộn.
2. Tools. Đừng thêm hay xóa chúng giữa cuộc hội thoại. Việc đó phá vỡ cache và khiến model gọi những tool không còn tồn tại. Muốn chặn một tool ở bước nào đó, hãy chặn lệnh gọi nhưng vẫn giữ nguyên định nghĩa.
3. Disk. Bất cứ thứ gì lớn hoặc dùng lâu dài đều đưa vào file, và chỉ giữ đường dẫn trong window. Tương tự với trang web: giữ URL, bỏ phần nội dung. Bỏ nội dung đi, chỉ giữ lại key để lấy nó về khi cần.
4. Tail. Cứ sau vài bước, hãy nhắc lại mục tiêu hiện tại ở gần cuối context. Bạn không thể sửa phần giữa, nên hãy giữ những gì quan trọng tránh xa khu vực đó.

Tools cũng có giới hạn. Anthropic đo được 58 định nghĩa tool ngốn khoảng 55.000 token trước khi người dùng gõ bất kỳ chữ nào. Việc cho phép model tự tìm kiếm tool thay vì tải tất cả đã giúp Opus 4 tăng điểm benchmark từ 49 lên 74 phần trăm.

Dưới khoảng 20 tool, cứ tải hết. Nhiều hơn mức đó, chuyển sang cơ chế tìm kiếm.

Thêm một mẹo nữa cho những tác vụ lớn: hãy cử một sub-agent. Nó đọc 50 file trong window riêng và trả về bản tóm tắt một trang. Context chính của bạn chỉ nhìn thấy bản tóm tắt đó.

Hình 2. Những gì tạo nên một lần gọi model

Lối tắt

Viktor gánh gần hết phần này cho bạn, vì context của anh ấy nằm ở cấp độ công ty.

• Memory. Anh ấy duy trì bộ nhớ liên tục về doanh nghiệp của bạn xuyên suốt cả team. Những gì anh ấy học được từ co-founder của bạn tuần trước không cần phải dán lại vào yêu cầu của bạn hôm nay.
• Nguồn dữ liệu đã kết nối. Khi đã kết nối Notion, Google Drive hay HubSpot, bạn không cần dán file vào chat nữa. Bạn chỉ cần gọi tên tài liệu hoặc bản ghi, anh ấy sẽ tự đọc nguồn. Quy tắc disk đã được lo xong.
• Skills. Bạn quay màn hình thao tác một lần. Anh ấy biến bản ghi đó thành quy trình bằng văn bản, bạn chỉnh sửa và duyệt. Từ đó trở đi, chỉ thị ấy được cố định và kiểm soát chặt chẽ, giống như một system prompt chuẩn chỉnh.

Phần việc còn lại của bạn:

• Viết một bản brief ngắn về công ty một lần duy nhất: bạn bán gì, ai mua, chỉ số nào quan trọng, những gì anh ấy tuyệt đối không được làm.
• Mỗi thread chỉ một tác vụ, kèm định nghĩa "xong" là như thế nào ngay trong tin nhắn đầu tiên.
• Nếu anh ấy học sai điều gì, hãy xóa bộ nhớ trong phần cài đặt thay vì phải sửa lại trong từng thread.

2. Loop engineering

Định nghĩa

Bạn có thể đưa cho nhân viên một checklist: mở file, sửa dòng 12, lưu lại. Hoặc bạn có thể giao cho anh ấy một mục tiêu: làm cho test chạy qua.

Với mục tiêu, anh ấy sẽ thử một cách, xem chuyện gì xảy ra, rồi quyết định bước tiếp theo. Checklist là workflow. Mục tiêu là loop.

Cách hoạt động

Một loop gồm bốn bước lặp đi lặp lại: suy nghĩ, hành động, quan sát, quyết định. Việc sửa bug diễn ra như sau:

1. Chạy test. Ba cái thất bại.
2. Đọc lỗi đầu tiên. Thiếu import.
3. Thêm import, chạy lại.
4. Vẫn còn một test lỗi. Đọc lỗi đó, sửa, chạy lại.
5. Tất cả đều qua. Dừng.

Không ai viết sẵn những bước này. Model tự chọn từng bước sau khi nhìn thấy kết quả của bước trước.

Đó là toàn bộ sự khác biệt. Một trăm bước do bạn viết vẫn là workflow. Ba bước do model tự chọn là loop.

Chỉ dùng loop khi bạn không thể viết trước các bước. Nếu viết được, hãy viết. Workflow rẻ hơn, chạy song song được, và khi bước bốn lỗi, bạn chỉ cần chạy lại bước bốn chứ không phải làm lại từ đầu.

Loop cũng rất tốn kém. Một agent dùng lượng token gấp khoảng bốn lần so với một lần gọi đơn lẻ. Hệ thống multi-agent tốn gấp khoảng mười lăm lần.

Cách xây dựng

Một loop cần bốn thành phần. Thiếu bất kỳ cái nào, nó sẽ ngừng hoạt động:

1. Mục tiêu với định nghĩa "xong" rõ ràng. Không phải "sửa bug". Mà là: "test đang lỗi trong auth_test.py phải chạy qua và không làm hỏng gì khác."
2. Checker. Một thứ bên ngoài model để phán pass hay fail: test suite, compiler, linter. Các nghiên cứu về self-correction đều nhất quán ở điểm này. Nó hoạt động khi có phản hồi thực tế từ bên ngoài và thất bại khi model chỉ tự review chính mình. Không có checker nghĩa là không có loop, chỉ là tiêu tiền vô tội vạ.
3. Quy tắc dừng. Checker báo pass, hoặc chạm giới hạn số lượt, hoặc hai lần thử cuối cho ra cùng một output.
4. Ngân sách. Cả số lượt lẫn số tiền.

Trong code, toàn bộ gói gọn trong vài dòng:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # done
7    if repeated(history, 2):  break   # stuck
8    if spent() > BUDGET:      break   # too expensive
9else:
10    fallback_workflow(goal)

Thiết lập production tốt nhất mà tôi từng thấy được công bố là dạng lai (hybrid). Atlan chạy một bộ lọc deterministic trước, và chỉ khoảng 14 phần trăm cảnh báo đầu vào thực sự đến tay agent.

Sau đó, loop chỉ được chạy tối đa ba chu kỳ. Nếu độ tin cậy vẫn dưới 50 phần trăm sau ba lần, một workflow Python cố định sẽ tiếp quản.

Lọc trước, loop ngắn, rồi fallback.

Hình 3. Cách quyết định giữa workflow và loop

Lối tắt

Mọi tác vụ bạn giao cho Viktor trong một thread đều là một loop. Bạn viết mục tiêu, anh ấy chọn các bước, xử lý qua các công cụ của bạn và quay lại thread với kết quả.

Bốn thành phần được ánh xạ như sau:

• Mục tiêu. Anh ấy sẽ phản biện lại những brief thiếu thông tin và chủ động hỏi thay vì đoán mò. Dù vậy, hãy viết rõ thế nào là "xong". "Báo cáo doanh thu tuần trước, tổng khớp với Stripe, đăng vào #finance trước 9h sáng thứ Hai" ăn đứt câu "làm báo cáo đi".
• Checker. Anh ấy sẽ gắn cờ những con số có vẻ sai lệch trước khi đăng. Hãy làm điều này mạnh mẽ hơn bằng cách chỉ đích danh nguồn để đối chiếu: tổng Stripe, số dòng, test suite.
• Quy tắc dừng. Các hành động nhạy cảm sẽ tạm dừng để chờ người duyệt, và kết quả luôn được trả về cho bạn.
• Ngân sách. Credits. Bậc reasoning quyết định giá của mỗi bước, và với các tác vụ định kỳ, tần suất rất quan trọng. Báo cáo hàng giờ tốn nhiều hơn hẳn báo cáo hàng tuần.

Mô hình hybrid của Atlan cũng hoạt động mà không cần code. Những việc lặp đi lặp lại sẽ thành tác vụ lên lịch: anh ấy đề xuất, và nó ở trạng thái tạm dừng cho đến khi bạn duyệt. Đó là workflow của bạn.

Bất cứ thứ gì mở (open-ended) thì đưa vào thread, và đó là loop của bạn. Bạn chính là phương án fallback.

3. Jev engineering

Định nghĩa

Chuyên gia trong công ty không tự bóc từng phong bì. Có người ở quầy lễ tân phân loại thư: hóa đơn để một đống, spam vứt sọt rác, hợp đồng chuyển cho luật sư.

Agent của bạn làm hai loại việc: viết ra thứ gì đó, và quyết định thứ gì đó. Hiện tại, một model lớn đang làm cả hai, nghĩa là bạn đang trả lương luật sư để ngồi phân loại thư.

Jev là quầy lễ tân. Nó không bao giờ viết. Nó chỉ chọn.

Cách hoạt động

Bạn đưa cho Jev một câu hỏi và các đáp án khả dĩ từ trước. Nó trả về một trong ba thứ, kèm theo điểm tin cậy:

• yes hoặc no
• một lựa chọn từ một tập hợp
• một con số trên thang đo

Vì chỉ làm nhiệm vụ chọn, nó rất nhanh và rẻ. Con số được công bố là 70 đến 500 mili giây so với 3 đến 329 giây, và $0.042 cho mỗi triệu input token, output miễn phí.

Giờ đến phần thực tế. Jev mới ra mắt được hai tuần và các bài test độc lập chỉ mới bắt đầu xuất hiện.

• Ở bài toán phân loại email, logistic regression cơ bản đạt 98.9 phần trăm so với 98.6 của Jev.
• Ở bài toán phát hiện phishing, Jev đạt 62.6 phần trăm trong khi Claude Haiku 4.5 đạt 81.3.
• Con số "không hallucination" đi kèm chú thích của chính tác giả: nó không dựa trên thực nghiệm, mà chỉ có nghĩa là output luôn khớp với schema.

Điểm tin cậy mặc định cũng không phải là xác suất thực sự. Hãy coi nó như một bảng xếp hạng và tự đặt ngưỡng dựa trên dữ liệu đã gán nhãn của bạn.

Cách xây dựng

Thiết lập hợp lý nhất là đặt một cổng chặn trước model đắt tiền:

1. Mọi thứ đi vào.
2. Jev trả lời một câu hỏi hẹp về từng mục.
3. Rõ ràng và quen thuộc: xử lý giá rẻ. Gán nhãn, điều hướng hoặc loại bỏ.
4. Không chắc chắn hoặc bất thường: chuyển cho model chính.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: unsure goes to the expensive path

Trước khi làm tất cả những việc đó, hãy thử cách ngớ ngẩn nhất mà có thể hiệu quả. Gán nhãn vài trăm ví dụ thực tế, train một classifier cơ bản, và chỉ nâng cấp nếu nó chưa đủ tốt.

Việc đó mất ba mươi phút, và nó là mốc chuẩn mà bất kỳ tuyên bố nào của nhà cung cấp cũng phải vượt qua được.

Hình 4. Ba loại câu hỏi mà Jev trả lời

Lối tắt

Jev không nằm trong stack chính thức của Viktor, nhưng ý tưởng này áp dụng được ở hai nơi do bạn kiểm soát:

• Bậc reasoning. Anh ấy chạy trên ba bậc: Smart trên Claude Opus, Balanced trên Claude Sonnet với chi phí bằng khoảng một nửa, Ultra trên Claude Fable với chi phí gấp đôi. Việc phân loại yêu cầu hay trích xuất một con số không cần đến bậc cao nhất.
• Cổng chặn trước mặt anh ấy. Nếu bạn muốn anh ấy xử lý một luồng dữ liệu như email hỗ trợ hoặc cảnh báo, đừng ném cả luồng cho anh ấy. Hãy đặt một classifier hoặc một lệnh gọi Jev trước, để chỉ những mục cần phán đoán mới trở thành tác vụ của anh ấy.

Đây là một trong hai lớp mà kỹ năng engineering của bạn vẫn đóng vai trò quyết định, kể cả khi dùng Viktor.

4. Harness engineering

Định nghĩa

Cùng một nhân viên, hai văn phòng. Ở văn phòng thứ nhất, anh ấy có đúng công cụ, sổ tay treo trên tường, đồng nghiệp kiểm tra chéo, và không có chìa khóa két sắt. Ở văn phòng thứ hai, anh ấy có một chiếc laptop và mật khẩu admin của bạn.

Kỹ năng y hệt, kết quả khác nhau một trời một vực. Nhân viên là model. Văn phòng là harness.

Agent = model + harness.

Cách hoạt động

Harness là mọi thứ không phải model: tools, quyền hạn, sandbox, các file giải thích dự án, khâu kiểm tra output.

Nó trở thành một chuyên ngành riêng vào năm 2026 vì mọi người bắt đầu đo lường, và model giải thích được ít hơn kỳ vọng:

• Anthropic chỉ thay đổi tài nguyên container mà điểm benchmark đã chênh 6 điểm.
• LangChain giữ nguyên model và cải thiện 13.7 điểm trên cùng benchmark đó chỉ bằng cách thay đổi harness.
• Sau đó họ tinh chỉnh harness quanh một open model rẻ hơn mười lần cho đến khi nó đạt 0.86 so với 0.87 của Opus 4.8.

Bạn không còn chỉ mua model nữa. Bạn mua cả model lẫn harness đi kèm.

Bạn cần harness ngay khoảnh khắc agent chạm vào thứ gì đó thực tế: một repo, một hộp thư, một khoản thanh toán, một production database.

Cách xây dựng

Hãy xây từ ngoài vào trong:

1. Containment (Khoanh vùng). Những gì agent không thể chạm tới về mặt vật lý. Một container, một branch riêng, user database chỉ đọc, không có mạng ngoại trừ allowlist. Làm việc này trước cả prompt đầu tiên.
2. Guides (Hướng dẫn). Những gì định hướng nó trước khi hành động. Một file trong repo như AGENTS.md, mô tả tool đủ rõ để model chọn đúng, vài ví dụ về output chuẩn.
3. Sensors (Cảm biến). Những gì kiểm tra nó sau khi hành động. Linter, type checker, test suite: nhanh và deterministic, nên chạy trên mọi thứ. Những bước kiểm chậm hơn, như dùng model thứ hai để review diff, chỉ chạy trên những gì quan trọng.
4. Permissions (Quyền hạn). Khi agent xin phê duyệt, con người đồng ý 93 phần trăm số lần. Lời nhắc phê duyệt gần như chẳng bảo vệ được gì. Sự bảo vệ thực sự nằm ở những hành động vốn không khả dụng. Hãy dành cơ chế phê duyệt cho vài thứ thực sự không thể đảo ngược.

File hướng dẫn không cần dài. Bốn dòng đã đủ thay đổi hành vi:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Run tests with `make test`. They must pass before any commit
4- Never edit /migrations by hand, use `make migration`
5- DB access is read only. Ask before any schema change

Hooks là phiên bản cưỡng chế của cùng ý tưởng đó. Trong Claude Code, hook là một script nhỏ chạy trước khi gọi tool và có thể chặn nó. "Không bao giờ push vào main" nên hoạt động như một hook, chứ không phải một dòng trong prompt.

Một lời cảnh báo. Mỗi thành phần trong harness của bạn là một ván cược rằng model không thể làm điều gì đó, và những ván cược này có thời hạn. Anthropic đã xóa bỏ toàn bộ một thành phần scaffolding sau khi bản cập nhật model khiến nó trở nên thừa thãi.

Hãy rà soát lại harness vài tháng một lần và xóa đi những gì model đã vượt qua.

Hình 5. Bốn vòng tròn của một harness

Lối tắt

Nếu agent = model + harness, thì phần lớn những gì bạn nhận được từ Viktor là harness. Model bên dưới là Claude. Mọi thứ xung quanh model đều có sẵn:

• Tools. Hơn 3.200 tích hợp: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive và nhiều hơn nữa. Với tool chưa có kết nối sẵn, anh ấy có thể tự xây.
• Guides. Skills. Thay vì tự viết AGENTS.md, bạn quay màn hình, anh ấy soạn quy trình, bạn chỉnh sửa.
• Sensors. Anh ấy gắn cờ dữ liệu không khớp và chất vấn những brief thiếu thông tin. Và mọi bước đều nằm trong một thread Slack để team bạn theo dõi.
• Permissions. Email khách hàng và thay đổi tài chính sẽ tạm dừng để chờ duyệt. Các automation lên lịch mới sẽ ở trạng thái tạm dừng cho đến khi có người bật lên.

Phần duy nhất không sản phẩm nào xây hộ bạn được là containment, vì nó được tạo nên từ chính các credential bạn cấp. Hãy nhớ con số 93 phần trăm, và chỉ kết nối anh ấy với quyền truy cập tối thiểu cần cho công việc:

• một user database chỉ đọc
• một key Stripe bị giới hạn
• một hộp thư hỗ trợ chung, không phải hộp thư cá nhân của bạn
• một token GitHub chỉ khoanh vùng cho các repo cụ thể

Những gì anh ấy không chạm tới được, anh ấy không thể phá hỏng.

Hình 6. Harness của Viktor

5. Evals engineering

Định nghĩa

Làm sao bạn biết nhân viên mới đã tiến bộ? Bạn cho anh ấy làm lại bài test tháng trước rồi so sánh.

Không có cùng một bài test, mọi thay đổi bạn tạo ra chỉ là phỏng đoán. Evals chính là bài test đó cho agent của bạn: một tập hợp các tác vụ mà bạn đã biết đáp án đúng, được chạy mỗi khi bạn thay đổi bất cứ thứ gì.

Cách hoạt động

Có hai loại kiểm tra:

• End to end. Đáp án cuối cùng có đúng không? Nó cho bạn biết điểm số thay đổi, nhưng không cho biết tại sao.
• Behavioral. Có một hành vi cụ thể nào xảy ra không? Nó có gọi search trước khi trả lời không. Nó có hỏi lại khi yêu cầu mơ hồ không. Nó có xác minh trước khi báo xong không.

Kiểm tra behavioral chạy trên trace – log ghi lại mọi thứ agent đã làm – chứ không chỉ trên đáp án cuối. Nguyên tắc của Google là bộ test này phải hoàn thành trong dưới năm giây, để có thể chạy mỗi khi có thay đổi.

Nếu dùng model để chấm điểm, đó là judge, và bản thân judge cũng cần được kiểm tra. Airbnb phát hiện khoảng ba phần tư đáp án tham chiếu do model tạo ra cho kết quả khác nhau khi chạy lại cùng một input. Bài eval của họ đang đo chính nhiễu của nó.

Cách xây dựng

1. Bắt đầu từ những lỗi thực tế. Lật lại các lần chạy thật, tìm xem sai ở đâu, biến mỗi lỗi thành một test case. Bộ golden set của Airbnb chạy 50 đến 100 ví dụ, và bắt buộc phải có các trường hợp lỗi.
2. Viết một kiểm tra behavioral cho mỗi case. Một case, một thứ cần xác minh.
3. Kiểm tra judge của bạn. Tự chấm thủ công một mẫu và xem bạn với model đồng thuận bao nhiêu phần trăm trước khi tin tưởng nó.
4. Lấy mẫu từ production. Airbnb trích xuất 5 phần trăm traffic thực mỗi ngày. Bộ eval của bạn sẽ lỗi thời dần khi hành vi sử dụng thực tế thay đổi.

Một case có thể nhỏ gọn thế này:

1input: "Refund order #1042, customer says it arrived broken"
2expect:
3  - looks up the order before replying
4  - asks for approval before issuing the refund
5check:
6  - trace has get_order before send_reply
7  - trace has approval_request before refund

Đừng chỉ盯着 tỷ lệ pass tổng thể. Nó có thể tăng lên trong khi một hành vi cụ thể âm thầm bị lỗi. Hãy theo dõi từng kiểm tra riêng lẻ.

Hình 7. Nguồn gốc của các eval case chất lượng

Lối tắt

Không sản phẩm nào làm hộ bạn lớp này, vì chỉ bạn mới biết đáp án đúng cho doanh nghiệp của mình trông như thế nào. Nhưng phương pháp thì áp dụng được trực tiếp:

• Sau hai tuần, chọn 20 thread của anh ấy mà bạn biết chắc đáp án đúng. Bao gồm cả những lần bạn phải sửa lại cho anh ấy.
• Viết một kiểm tra đơn giản cho mỗi case. Anh ấy có dẫn nguồn cho mọi con số không, có hỏi lại khi brief mơ hồ không, có tạm dừng trước khi gửi gì ra khỏi công ty không.
• Chạy lại bộ test sau mỗi thay đổi: skill mới, brief đã sửa, bậc reasoning khác. Chuyển từ Smart sang Balanced tiết kiệm khoảng một nửa credit, nên hãy test trước khi chuyển hẳn.
• Mỗi tuần một lần, tự chấm thủ công năm thread ngẫu nhiên.

Gộp lại tất cả

Năm lớp, năm câu hỏi. Context là những gì nó nhìn thấy. Loop là ai quyết định. Jev lo các quyết định giá rẻ. Harness là những gì nó chạm tới được và ai kiểm tra nó. Evals là cách bạn biết mọi thứ đang vận hành ra sao.

Với Viktor, ba lớp gần như có sẵn: context, loop và harness. Jev, evals và các credential bạn cấp vẫn là phần engineering của bạn.

Nếu bạn bắt đầu ngay hôm nay, đây là bước đi hữu ích và rẻ nhất cho mỗi lớp:

• Context: chuyển các chỉ thị cố định vào system prompt và ngừng thay đổi chúng.
• Loop: đặt giới hạn số lượt và giới hạn tiền trước khi để nó tự chạy.
• Jev: gán nhãn 200 ví dụ cho bất cứ thứ gì agent của bạn phải quyết định thường xuyên nhất.
• Harness: chạy agent dưới quyền một user không thể xóa bất cứ thứ gì.
• Evals: viết lại năm lỗi gần nhất của bạn thành test case.

Còn trên Viktor, một ngày làm việc sẽ trông như thế này:

• Context: viết company brief và ghi lại skill đầu tiên.
• Loop: đưa định nghĩa "xong" vào mọi tác vụ và chủ động chọn bậc reasoning.
• Jev: lọc mọi luồng dữ liệu trước khi chúng biến thành tác vụ cho anh ấy.
• Harness: kết nối anh ấy bằng credential chỉ đọc và được khoanh vùng.
• Evals: lưu 20 thread thực tế làm bộ test đầu tiên.

Đó là một ngày làm việc và nó bao quát cả năm lớp.

Quan điểm của tôi: model không còn là phần khó nữa. Năm lớp xung quanh nó mới là thứ khó. Làm tốt chúng, bạn tăng năng lực mà không cần tăng nhân sự. Hầu hết các team nên dùng ba lớp đầu tiên có sẵn và dành thời gian của mình cho hai lớp quyết định chất lượng: các quyết định giá rẻ và evals.

Cảm ơn Viktor đã tài trợ bài viết này.

Dùng thử miễn phí tại @viktor_com. Tặng $100 credit, không cần thẻ. Link đầy đủ ở bình luận đầu tiên của tôi.

Nhập mã YARCHI100 khi đăng ký.

Bài viết có tài trợ