Agent tốt là agent biết bị chặn

Agent tốt là agent biết bị chặn

Tín hiệu mới từ HORIZON và WebBrain: agent production không thắng nhờ tự do hơn, mà nhờ có môi trường, gate và quyền hạn rõ ràng.

Có một kiểu demo agent mình hay gặp: mở terminal, gõ một câu dài như toa thuốc, agent chạy ào ào, sửa file, gọi tool, rồi cuối cùng hiện “done”. Cả phòng vỗ tay. Năm phút sau có người hỏi: “Ủa nó đúng chưa?” — không khí tự nhiên giống phòng khám vừa phát hiện bệnh nhân được kê thuốc trước khi đo huyết áp.

Tín hiệu đáng chú ý tuần này không nằm ở chuyện agent làm được nhiều việc hơn. Nó nằm ở chỗ các hệ thống nghiêm túc đang siết agent vào môi trường có kiểm chứng.

NVIDIA Research với HORIZON đặt bài toán hardware design vào git worktree, chạy evaluator, chỉ commit khi acceptance gate đạt. WebBrain thì chia browser agent thành Ask mode đọc-only và Act mode có quyền thao tác, kèm giới hạn theo tab. Còn lời khuyên prompting từ Anthropic lại xoáy vào blind spots: vấn đề không chỉ là model chưa giỏi, mà là người giao việc chưa biết mình đang thiếu gì.

Nói thẳng ra thì: agent production không nên được đánh giá bằng mức độ “hands-free”, mà bằng chất lượng của cái phanh.

Sơ đồ minh họa cho bài Agent tốt là agent biết bị chặn

Sơ đồ tóm tắt ý chính của bài viết.

Tín hiệu lạ: agent càng mạnh, quyền càng bị khoanh

Nếu chỉ nhìn tiêu đề, HORIZON dễ bị hiểu là “agent tự thiết kế hardware đạt 100% benchmark completion”. Con số đó đáng chú ý, nhưng thứ mình quan tâm hơn là kiến trúc vận hành phía dưới.

HORIZON không đối xử bài toán RTL như một prompt một lượt. RTL, hay register-transfer level, là mức mô tả phần cứng bằng luồng dữ liệu giữa các thanh ghi theo chu kỳ clock. Ở đây, “code nhìn hợp lý” chưa đủ. Sai một bit width, reset lệch convention, hoặc mô phỏng qua được case đơn giản nhưng fail theo chu kỳ là toang.

Cách HORIZON làm: biến mỗi bài toán thành một repository có version control. Input là một Markdown harness có cấu trúc: mục tiêu, chỉ dẫn domain, evaluator specification và acceptance predicate. Agent sửa một isolated git worktree, chạy evaluator, rồi chỉ commit nếu điều kiện chấp nhận đạt.

Đây là tín hiệu thị trường khá rõ: agent framework đang rời khỏi sân khấu prompt đẹp để bước vào quy trình có bằng chứng thực thi.

WebBrain cũng kể cùng một câu chuyện, nhưng ở mặt trận browser. Nó không nói “agent có thể làm mọi thứ trong trình duyệt” rồi thả quyền lung tung. Nó tách Ask mode — chỉ đọc trang — khỏi Act mode — có thể click, type, scroll, navigate. Khi cần thao tác thật trên Chrome, nó dùng Chrome DevTools Protocol qua chrome.debugger API, và trình duyệt hiện banner debugging tiêu chuẩn.

Hai sản phẩm/nghiên cứu khác miền, một bên hardware design, một bên browser automation, nhưng cùng đổi vị thế: môi trường thực thi và guardrail đang thành sản phẩm chính, không còn là phần phụ sau demo.

Ai hưởng lợi khi agent bị “khám sức khỏe” liên tục?

Người hưởng lợi đầu tiên là team builder phải chịu trách nhiệm khi hệ thống sai.

Trong demo, bạn có thể nói “agent đã cố gắng”. Trong production, câu đó không đủ. Tech lead cần biết:

HORIZON dùng git làm substrate, tức git không chỉ để lưu lịch sử cho vui. Diff cho thấy agent đề xuất thay đổi gì. Commit chỉ xuất hiện khi executable acceptance gate qua. Acceptance gate ở đây là cổng kiểm tra tự động quyết định phiên bản có được nhận hay không. Trong workflow dev thường ngày, nó giống CI bắt buộc pass trước khi merge, nhưng được đặt ngay trong vòng lặp agent.

WebBrain thì cho thấy một biến khác: quyền hạn không nên là trạng thái mặc định. Ask mode đọc trước, Act mode hành động sau. Trên web, đây là khác biệt sống còn, vì trang có thể chứa prompt injection — nội dung độc hại cố gắng dụ agent làm sai lệnh. Nếu agent vừa đọc vừa có quyền bấm nút thanh toán, tải file, đổi setting, thì bạn đang cho người lạ đứng trong phòng khám cầm cả hồ sơ bệnh án lẫn con dấu.

Hình dung thế này: team bạn build agent xử lý yêu cầu hoàn tiền. Nếu agent chỉ đọc ticket và đề xuất hành động, rủi ro thấp hơn nhiều so với agent tự đăng nhập dashboard, đổi trạng thái đơn, gửi email và cập nhật CRM. Cùng là “agent support”, nhưng mức cần guardrail khác hẳn.

Bóc lớp kỹ thuật: 4 thứ cần có trước khi khoe agent tự chạy

Nếu lấy HORIZON và WebBrain làm tín hiệu, mình sẽ không hỏi “dùng model nào?” đầu tiên. Với builder, câu hỏi nên là: agent của bạn có hồ sơ bệnh án vận hành chưa?

Một framework gọn để soi hệ thống:

1. Work unit: agent đang xử lý đơn vị công việc nào?

HORIZON chọn repository-level code evolution: bài toán là một repo có trạng thái, không phải một câu prompt. Đây là quyết định lớn.

Với team app, work unit có thể là:

Nếu work unit mơ hồ, log cũng mơ hồ. Khi lỗi xảy ra, bạn không biết cần replay cái gì.

2. Evaluator: cái gì kiểm tra được bằng máy?

Evaluator là bộ kiểm tra thực thi: test, simulator, linter, verifier, profiler, hoặc script domain-specific. Với RTL, nó có thể gồm compile, simulation, coverage extraction, assertion hoặc testbench checks. Với web automation, nó có thể là DOM state, URL hiện tại, text xác nhận, hoặc record thao tác.

Điểm quan trọng: evaluator phải chạy được, không chỉ là “AI tự nhận xét”. Nếu agent viết code rồi nhờ chính model đánh giá “có vẻ đúng”, đó là tự bắt mạch bằng gương selfie.

Ví dụ cụ thể: bạn build agent sửa lỗi frontend. Đừng chỉ yêu cầu “fix bug”. Hãy bắt nó chạy:

npm test -- --runInBand
npm run lint
npm run build
npx playwright test tests/checkout.spec.ts

Sau đó log lại output, diff, commit hash, và lý do chấp nhận hoặc từ chối.

3. Acceptance predicate: điều kiện nào mới được ghi nhận?

Acceptance predicate là luật chốt: pass thì nhận, fail thì ghi lỗi. Nó khác evaluator ở chỗ evaluator tạo tín hiệu, còn predicate quyết định có tiến trạng thái hay không.

Ví dụ minh họa, giả sử team bạn có agent cập nhật SQL migration. Evaluator chạy unit test và migration dry-run. Predicate có thể là:

Không có predicate rõ, agent rất dễ “gần đúng” rồi vẫn đẩy hệ thống sang trạng thái bẩn.

4. Permission boundary: agent được chạm vào đâu?

WebBrain nhắc một chuyện nhiều team hay bỏ qua: cùng một agent, đọc và hành động là hai chế độ khác nhau.

Permission boundary là ranh giới quyền hạn: file nào được sửa, API nào được gọi, tab nào được thao tác, dữ liệu nào được gửi ra ngoài. Với local-first browser agent như WebBrain, lựa chọn chạy model local giúp dữ liệu trang không rời máy. Nhưng nếu nối cloud API, tradeoff đổi ngay: năng lực có thể mạnh hơn, đổi lại bạn phải xét data policy kỹ hơn.

Với team Việt Nam, nhất là nhóm nhỏ đang chạy nhanh, đây là chỗ dễ “lười một tí rồi trả giá nhiều”. Một extension hoặc agent nội bộ dùng session đăng nhập thật có thể tiện, nhưng nếu không chia read-only và action mode, bạn đang gom quyền admin, dữ liệu khách hàng và prompt chưa kiểm chứng vào cùng một giỏ rủi ro.

Điều đáng giữ: agent loop có bằng chứng, không phải agent loop có cảm hứng

HORIZON đáng học ở cách đóng gói bài toán thành project pack. Bạn không cần bê nguyên công thức toán học của họ về app của mình, nhưng nên mượn tinh thần:

Đây cũng là chỗ lời khuyên về blind spots từ Anthropic khớp vào. Prompt tốt không phải prompt dài nhất. Prompt tốt là prompt làm lộ phần bạn chưa biết. Unknown unknowns — những điều bạn chưa nhận ra là mình chưa biết — thường chỉ lòi ra khi agent đụng evaluator thật.

Nếu bạn viết “hãy tối ưu query này” mà không đưa workload, index hiện có, constraint latency, cách đo regression, agent sẽ lấp chỗ trống bằng mặc định phổ biến. Có khi đúng, có khi lệch bệnh.

Một cách làm thực dụng: trước khi cho agent sửa, bắt nó tạo diagnostic note ngắn:

## Known constraints
- Không đổi public API
- Không thêm dependency runtime
- Phải giữ backward compatibility với schema hiện tại

## Unknowns to verify
- Test nào cover luồng lỗi?
- Query có chạy trên dataset lớn không?
- Có migration đang pending không?

## Acceptance gates
- Unit tests pass
- Integration test cho luồng chính pass
- Không tăng thời gian build đáng kể

Đây không phải giấy tờ cho đẹp. Nó là cách ép blind spots hiện hình trước khi agent cầm dao mổ.

Điều nên bỏ qua: benchmark ấn tượng nhưng thiếu đường về production

Mình không phủ nhận benchmark. HORIZON báo hoàn thành 100% trên các RTL benchmark được đánh giá là tín hiệu đáng đọc. Nhưng chính nguồn cũng nói rõ agentic hardware design chưa được giải quyết xong.

Với builder, câu hỏi không phải “benchmark có cao không?” mà là:

Tương tự, browser agent open-source local-first rất hấp dẫn, nhưng bạn không nên bê vào quy trình nhạy cảm chỉ vì nó chạy được trong Chrome và Firefox. Hãy hỏi: Act mode có cần không? Có thể bắt đầu bằng Ask mode không? Có domain nào phải cấm thao tác? Có trang nào chứa dữ liệu không được gửi sang cloud model không?

Market signal ở đây là incentive đang đổi. Nhà cung cấp agent muốn chứng minh “tự động hơn”. Người mua production lại cần “kiểm soát hơn”. Bên nào đóng gói được cả hai — tự động trong phạm vi hẹp, có kiểm chứng rõ — sẽ có lợi thế.

Nếu là mình, mình sẽ đổi checklist mua/built agent

Từ giờ, khi đánh giá một agent framework cho team, mình sẽ bớt hỏi “nó support bao nhiêu tool?” và hỏi 6 câu này trước:

  1. State nằm ở đâu? Repo, database snapshot, browser tab, hay chỉ trong context window?
  2. Có evaluator chạy thật không? Test, simulator, verifier, script nghiệp vụ?
  3. Acceptance gate có tách khỏi model không? Hay model tự chấm bài của mình?
  4. Permission có theo mode không? Read-only, propose-only, act-with-approval, act-autonomous?
  5. Failure có dùng lại được không? Có log, diff, trace, replay?
  6. Human takeover ở điểm nào? Khi gate fail, khi quyền nhạy cảm, hay khi confidence thấp?

Hệ thống agent đáng tin không phải hệ thống ít fail. Nó là hệ thống fail có kiểm soát, để team biết ca nào cần hội chẩn, ca nào được xuất viện.

Sau bài này, thứ mình muốn bạn nghĩ khác là: đừng chọn agent vì nó “tự làm hết”; hãy chọn agent vì nó biết khi nào không được phép làm tiếp. Agent không có gate giống bác sĩ không cần xét nghiệm — nghe tự tin thì có, kê đơn thì hơi run.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo