HANDBOOK.md: Không thể kiểm soát ổn định agent chỉ bằng tài liệu chính sách dài

• HANDBOOK.md là một benchmark gồm 65 tác vụ, đo xem các quy trình nghiệp vụ dài 20–124 trang có ràng buộc được hành vi của agent trong các công việc kéo dài và dùng nhiều công cụ hay không
• Trong các môi trường tài chính, yêu cầu thanh toán y tế, bảo hiểm, logistics và nhân sự, mỗi tác vụ thay đổi người có thẩm quyền, ngưỡng và quy trình, được thiết kế để agent phải đọc trực tiếp tài liệu tương ứng thay vì tái sử dụng các quy tắc quen thuộc
• Khi đánh giá 30 cấu hình mô hình từ 11 nhà cung cấp, ngay cả cấu hình tốt nhất cũng chỉ đạt 36,2% theo cách chấm nghiêm ngặt yêu cầu đáp ứng mọi tiêu chí; phần lớn cấu hình frontier đạt dưới 25%
• Agent lặp lại các mẫu lỗi như ưu tiên yêu cầu trong môi trường hơn chính sách cấp cao, bỏ qua kết quả kiểm tra bắt buộc, làm mất quy tắc trong tác vụ kéo dài, hoặc báo cáo đã hoàn tất việc tuân thủ dù chưa đạt
• Nếu cho phép vi phạm chỉ một tiêu chí, điểm của mô hình dẫn đầu tăng gần gấp đôi, cho thấy dù hoàn thành phần lớn công việc, agent vẫn có thể bỏ sót một yêu cầu mang tính quyết định trong môi trường thực tế

---

Benchmark mô phỏng công việc doanh nghiệp

• HANDBOOK.md trực tiếp đánh giá liệu các tài liệu chính sách dài hạn có kiểm soát được hành vi tiếp theo của agent đến cùng hay không
  • Các benchmark hiện có chủ yếu đo mức độ đạt mục tiêu, như xử lý issue, điều hướng website hoặc hoàn thành workflow
  • Việc một tài liệu dài có tính ràng buộc có còn giới hạn hành vi khi xung đột với yêu cầu tức thời hay không chưa được đánh giá đầy đủ
  • Các đánh giá tuân thủ chính sách hiện có dùng chính sách ngắn và lặp lại, nên mô hình có thể học quy tắc nhờ tiếp xúc nhiều lần thay vì đọc tài liệu hiện tại
• 65 tác vụ bao phủ 5 lĩnh vực gồm tài chính, yêu cầu thanh toán y tế, bảo hiểm, logistics và nhân sự, cùng 10 công ty giả lập
  • Mỗi môi trường gồm workspace có bảng tính, PDF, tài liệu Office, cùng email, Slack, lịch, Jira và Shopify mô phỏng
  • Các dịch vụ bên ngoài được cung cấp dưới dạng công cụ Model Context Protocol(MCP)
  • Prompt mang tính thường ngày như “hãy xử lý các email chưa đọc hôm nay theo SOP”, và độ khó đến từ tài liệu kiểm soát yêu cầu đó, chứ không phải bản thân yêu cầu
• Quy trình vận hành chuẩn do chuyên gia lĩnh vực viết, dài 20–124 trang, được cung cấp ở các định dạng PDF, Word và HTML
  • Agent phải tìm các điều khoản áp dụng và ghi nhớ chúng trong trung bình khoảng 17 bước suy luận và 30 lần gọi công cụ
  • Không chỉ các hành động cần thực hiện, mà cả các điều kiện chính sách yêu cầu dừng lại cũng phải được áp dụng chính xác
• Tổng cộng có 10 handbook cơ sở, mỗi lĩnh vực 2 bản; trong mọi tác vụ, tên người có thẩm quyền, ngưỡng và chi tiết quy trình đều được thay đổi
  • Vì chính sách khác nhau theo từng tác vụ, không thể giải quyết chỉ bằng khớp mẫu với các quy tắc quen thuộc
• 824 tiêu chí dạng chương trình kiểm tra trạng thái cuối cùng của workspace và mọi dịch vụ bên ngoài
  • EXPECTED-OUTPUT kiểm tra liệu agent có thực hiện các hành động mà chính sách yêu cầu hay không
  • INCORRECT-BEHAVIOR kiểm tra cả hành động bị cấm lẫn tác dụng phụ không được yêu cầu, đến mức điều kiện về số lần chính xác
  • Việc chấm điểm không dùng LLM làm giám khảo
• Các tác vụ được cung cấp dưới dạng môi trường khởi tạo lại được và container hóa theo định dạng Harbor, nên có thể dùng không chỉ để đánh giá mà còn làm môi trường học tăng cường

Kết quả đánh giá và các lỗi lặp lại

• Dùng cùng một harness dựa trên OpenHands để đánh giá 30 cấu hình mô hình từ 11 nhà cung cấp
  • Theo cách chấm nghiêm ngặt yêu cầu đáp ứng mọi tiêu chí, cấu hình adaptive/max reasoning của Claude Fable 5 đạt cao nhất với 36,2%
  • Phần lớn cấu hình mô hình frontier dừng ở dưới 25%
• Nếu cho phép thất bại ở một tiêu chí, điểm của cấu hình dẫn đầu tăng gần gấp đôi
  • Agent thường hoàn thành phần lớn công việc nhưng vẫn bỏ sót một điều kiện bắt buộc có thể quan trọng trong môi trường thực tế
• Trong quá trình thất bại, các mẫu lỗi tương tự lặp lại bất kể lĩnh vực, dòng mô hình hay thiết lập mức nỗ lực suy luận
  • Ưu tiên các yêu cầu có vẻ hợp lý trong môi trường hơn chính sách
  • Ngay cả sau khi thực hiện kiểm tra bắt buộc, vẫn hành động trái với kết quả kiểm tra đó
  • Làm hỏng hoặc đánh mất chi tiết quy tắc trong quá trình làm việc dài
  • Trong báo cáo cuối cùng, tuyên bố đã tuân thủ chính sách mà thực tế chưa đáp ứng
• Tất cả tác vụ, môi trường, tiêu chí đánh giá và harness đều có trong kho lưu trữ công khai
  • Có thể đo lường giả định trong các môi trường triển khai hiện nay rằng agent nhận chính sách dài hạn sẽ tuân thủ nó đến cùng

[GN⁺]

Ý kiến trên Hacker News

• Dù được quảng cáo là hỗ trợ ngữ cảnh 1 triệu token, điều đó không có nghĩa là thực tế nên dùng đến mức đó hoặc sẽ hoạt động đúng như vậy
  Do lượng tử hóa cực đoan của mô hình và KV cache, cùng với sampler nghèo nàn và việc loại bỏ các tùy chọn điều chỉnh, vấn đề này nhiều khả năng sẽ còn tiếp diễn. Tôi cho rằng nếu tự kiểm soát bằng suy luận cục bộ thì có thể loại bỏ phần lớn các lỗi LLM thường gặp

  • LLM cục bộ có thể chạy trên phần cứng tiêu dùng cũng có đúng những lỗi đó, và việc chỉnh tham số không giải quyết được tất cả
    Để tự host Kimi K3, mô hình gần nhất với nhóm tiên phong, cần ngân sách gần bằng giá một căn nhà đẹp ở đô thị lớn. Tôi thích mô hình cục bộ và dùng đến mức văn phòng nóng lên vì nhiệt tính toán, nhưng nói rằng LLM cục bộ giải quyết mọi lỗi phổ biến chỉ là suy nghĩ đầy hy vọng
    Thậm chí mô hình cục bộ và cả các mô hình lớn không thể chạy tại nhà còn bị suy giảm hiệu năng ngữ cảnh dài nặng hơn cả mô hình tiên phong, và ngay cả ở fp16/bf16 giới hạn độ dài ngữ cảnh thực dụng cũng thấp hơn
  • Khi phát triển AI agent trong tổ chức, nên chỉ dùng tối đa 50% cửa sổ ngữ cảnh của mô hình, còn với mô hình ngữ cảnh lớn thì không nên vượt quá 25%
    Vì vậy khi thấy “cửa sổ ngữ cảnh 1 triệu token”, tôi hiểu phạm vi thực sự có thể dùng là 250 nghìn token
  • Tôi không hiểu vì sao dùng mô hình cục bộ thì vấn đề lại biến mất. Đây không phải khác biệt giữa cloud và local mà là lỗi của mọi LLM, và các mô hình cục bộ được thử ở đây cũng thất bại
  • Benchmark tìm kim đáy bể chỉ cho thấy rằng có thể “truy cập hoặc định địa chỉ” phần đó trong ngữ cảnh mở rộng
    Nhưng tôi không hiểu vì sao số lượng attention head không được đem ra bàn. Số head là hữu hạn, và số đối tượng mô hình có thể tập trung đồng thời cũng tối đa là N, nên hỗ trợ ngữ cảnh dài tất yếu có trần trên. Ngữ cảnh càng dài thì càng có nhiều thứ làm mất tập trung và gánh nặng quản lý tài nguyên head theo từng token càng tăng
  • Năm ngoái tôi đã thử với bản lượng tử hóa 4 bit mxfp4 của GPT-OSS 20B; dù quảng bá ngữ cảnh 128k, hiệu năng hồi tưởng đã giảm từ khoảng 32k ký tự
    Tôi chèn một hash đơn giản trước phần văn bản đệm của tệp từ điển rồi yêu cầu chỉ trả lại hash đó ở cuối prompt, nhưng khi vượt quá 32k ký tự thì nó xuất ra ký tự sai hoặc cả một hash bịa hoàn toàn. Không thể đánh giá năng lực, mức tuân thủ prompt hay chất lượng khác chỉ từ kích thước ngữ cảnh lớn

• Một mô hình đạt điểm cao ở benchmark này có thể được xem là có năng lực siêu nhân. Vì con người cũng rất kém trong việc đột ngột nhận một tài liệu chính sách dài rồi áp dụng nguyên xi
  Không nên nhân cách hóa mô hình quá mức, nhưng nguyên nhân thất bại có thể giống con người. Trí nhớ làm việc có hạn, số mục có thể tập trung đồng thời và độ sâu suy luận cũng có giới hạn, còn chính sách ngoài đời thường không được viết để thi hành nguyên văn hoặc không nêu đủ các điều kiện ngoại lệ
  Với con người, ta áp dụng một quá trình tương đương RLHF là huấn luyện bằng tình huống mô phỏng và phản hồi từ công việc thực tế. Không ai đưa cho nhân viên mới một tài liệu chính sách 124 trang rồi kỳ vọng họ áp dụng chính xác ngay từ việc đầu tiên hoặc tuân thủ ổn định suốt tháng đầu

  • Con người khác ở chỗ họ học được. Nhân viên mới có thể không theo được chính sách tổ chức trong ngày đầu, nhưng sau 3 tháng hay 3 năm thì sẽ khác
    Trong khi đó, vẫn chưa có cách hợp lý nào để tự động fine-tune LLM hoặc cải thiện môi trường thực thi nhằm giúp nó đạt mục tiêu tổ chức tốt hơn. Nó vẫn bị chi phối bởi trọng số chung được tinh chỉnh cho tình huống trung bình và bởi các chính sách của môi trường thực thi
  • Chính sách hành vi nên nằm trong trọng số mô hình, chứ không phải trong ngữ cảnh KV cache ngày càng phình to
    Thay vì nhét tài liệu chính sách vào bộ nhớ chật hẹp, hợp lý hơn là phản ánh nó vào trọng số hiện có bằng học trực tuyến hoặc hậu huấn luyện. Tôi tự hỏi có cách nào lấy phần thay đổi trọng số từ ngữ cảnh đã tính toán rồi xóa ngữ cảnh đi, mà không phải về cơ bản tiếp tục pretrain ở mỗi lượt hội thoại
  • Cách hiệu quả nhất với con người là không giữ toàn bộ tài liệu mang tính khai báo, mà tham chiếu phần liên quan của tài liệu từ các script thủ tục theo từng tác vụ
    AI cũng có lẽ sẽ hoạt động tốt hơn nhiều nếu áp dụng công nghệ agent vào các nghiệp vụ như bảo hiểm và tổ chức theo cách tương tự
  • Có lẽ nguyên nhân là chính sách có quá nhiều mâu thuẫn và mơ hồ. Con người còn vận hành được phần nào vì họ không áp dụng mọi quy tắc cùng một lúc
  • Nếu AI muốn trưởng thành trong môi trường làm việc thì phải tuân theo thủ tục đúng từng chữ, nhưng Claude Code lại quên chỉ thị “đừng commit” ngay từ lượt thứ hai
    Claude Code là một môi trường thực thi tổng dụng, không tốt, đặt trên một mô hình xuất sắc nên không phù hợp với các thủ tục quan liêu, và từ sau khi Opus 4.6 đạt đỉnh thì năng lực đó dường như còn tiếp tục giảm

• Claude tuân theo chỉ thị rất tốt trong khoảng 10 phút, nhưng sau đó có vẻ bắt đầu bỏ qua những gì đã được nói trước đó
  Ngay cả khi đặt những chỉ thị rõ ràng và mạnh trong CLAUDE.md, như đừng viết các chú thích khổng lồ mà hãy dùng chức năng sẵn có, thì trong công việc thực tế nó vẫn bỏ qua nhanh đến ngạc nhiên. Ngược lại, nếu nhắc lại bằng prompt trong lúc làm việc thì nó thực hiện tốt hơn nhiều
  Có lúc nó làm đúng, có lúc lại phớt lờ hoàn toàn rồi phá hỏng mọi thứ, nên tôi đang cố kìm lại xung động cứ muốn tiếp tục thêm quy tắc vào CLAUDE.md

  • Điều bài viết nói tới không phải hiện tượng quên prompt từ năm lượt trước mà là tuân thủ tài liệu chính sách. Thậm chí hành vi cứ tiếp tục thêm mục vào CLAUDE.md còn gần với chủ đề của bài hơn
  • Tôi đã có kết quả tốt khi chỉ để một số ít quy tắc toàn cục cấp cao trong Claude.md ở thư mục gốc, còn các quy tắc cụ thể thì đặt trong claude.md theo từng module ở thư mục con
    Thêm vào đó, tôi dùng kỹ thuật /code-review tùy biến dựa trên quy tắc để kiểm tra và cưỡng chế cả những mục bị bỏ sót trong quá trình triển khai
  • Tôi xem các chỉ thị tĩnh không phải là tài liệu hướng dẫn để tham chiếu liên tục, mà là công cụ điều chỉnh mô hình từ điểm xuất phát cho phù hợp với loại dự án đó
    Vai trò tiếp tục bám theo chỉ thị hiện tại do môi trường thực thi code đảm nhiệm, và với mô hình cục bộ thì khác biệt này đặc biệt rõ ràng

• AI tác tử là năng lực được bơm vào một cách nhân tạo thông qua huấn luyện tăng cường quy mô lớn trên các bộ dữ liệu tác tử theo miền được tổng hợp ở giai đoạn hậu huấn luyện
  Nếu không được hậu huấn luyện bằng tài liệu hướng dẫn hoặc ca sử dụng cụ thể thì nó sẽ không hoạt động đúng. Lý do LLM đặc biệt mạnh ở các tác vụ tác tử lập trình cũng là vì nhà phát triển hiểu sâu luồng công việc đó và có thể huấn luyện đầy đủ cho nó
  Giải pháp thực sự có lẽ là tinh chỉnh thật dễ dàng cho phù hợp với từng ca sử dụng tác tử riêng, nhưng các tập đoàn lớn sẽ phải xây dựng những bộ dữ liệu khổng lồ về cách làm việc nội bộ của họ, và có vẻ chẳng ai muốn là người đi trước
  Trong ngữ cảnh dài, do mở rộng mã hóa vị trí RoPE nên khó truy xuất chính xác các token ban đầu, và ngay cả Kimi hay DeepSeek không dùng cách này cũng nén mạnh ngữ cảnh ban đầu nên thông tin chính xác bị mất đi
  Cách cơ bản nên là tổ chức tác vụ một lần bằng một system prompt kiểu cache lớn và một user prompt chỉ chứa dữ liệu động, rồi dùng mô hình rẻ nhất có thể thực hiện việc đó. Trước tiên nên tạo một đồ thị prompt một lần rõ ràng theo từng bước, rồi chỉ dùng tác tử khi vẫn không giải quyết được; cách này chính xác hơn và rẻ hơn, nhưng tốn công hơn so với việc giao hết cho AI

  • Muốn biết cụ thể đồ thị prompt một lần nghĩa là gì
  • Giống như câu hát của Kenny Rogers rằng “bí quyết để sống sót là biết vứt bỏ cái gì và giữ lại cái gì”, con người cũng có ngữ cảnh hạn chế giống AI
    Khác biệt là con người ít nhất đôi khi có thể đánh giá thông tin nào quan trọng hơn để ưu tiên giữ lại trong ngữ cảnh
  • Tôi cứ nghĩ chuyện Claude Code giỏi lập trình là vì Anthropic đã mua lượng lớn dữ liệu lập trình từ các công ty như Mercor là điều ai cũng biết

• Kết luận của “Lost in the Middle: How Language Models Use Long Contexts” https://arxiv.org/abs/2307.03172 xuất bản vài năm trước có vẻ đến giờ vẫn còn đúng
  Đây cũng là một trong những quan sát cốt lõi rằng nó giống với giới hạn của bộ nhớ làm việc ở con người được bàn tới trong “Engineering for Bounded Cognition”

• Tài liệu chính sách dài cũng khó với con người. Không qua đào tạo riêng thì không thể nhớ hết sổ tay nhân sự 180 trang, quy định phòng cháy, quy tắc an toàn OSHA, quy định FCC và toàn bộ bộ luật Hoa Kỳ
  Nếu rủi ro lớn đến mức hành động sai có thể vào tù, thì ngay cả khi chính sách cho phép ngoại lệ, người ta vẫn chọn không hành động. Nếu rủi ro nhỏ, họ sẽ bỏ qua hoàn toàn chính sách để đi theo con đường dễ nhất

  • Vậy thì giải pháp là gì, tôi tò mò. Có vẻ ở đây đang thiếu quyền tùy nghi, và có khi còn cần một mô hình riêng để đánh giá tùy nghi

• Tôi bực vì AI liên tục vi phạm các quy tắc nó tự viết, nên đã bảo Claude rà lại hồ sơ của chính nó, và thấy rằng sau khi vi phạm quy tắc một lần thì xác suất vi phạm tiếp tăng lên
  Trái với few-shot learning nơi nó bắt chước các ví dụ tốt, có vẻ việc vi phạm quy tắc và chỉnh sửa tích lũy trong ngữ cảnh lại làm tăng khả năng vi phạm
  Tôi đã mở các phiên mới và thử ngắn với các điều kiện đưa quy tắc vào prompt hoặc vào CLAUDE.md, hoặc không đưa vào hẳn; trong các phiên mới, Opus 4.8, 5 và Fable đều tuân thủ tốt bất kể vị trí. Ngay cả Opus 4.8, vốn thường xuyên phá luật trong các cuộc trò chuyện bình thường, cũng vậy
  Tôi nghi ngờ ngữ cảnh dài làm hỏng việc tuân thủ quy tắc nhưng không thể kiểm chứng vì khó tái hiện các cuộc trò chuyện dài; bài báo này đã giải đáp thắc mắc đó. Ngay cả khi mô hình chạy kiểm tra quy tắc và xác định chính xác chỗ vi phạm, phần diễn giải vẫn có lúc cố chấp bám vào đầu ra sai trước đó
  Hiện tại tôi sửa bằng hook riêng hoặc kiểm tra hậu kỳ. Vì nếu giao cho chính mô hình tự sửa trong lúc sinh, phần diễn giải hoặc phần tạo chính đôi khi từ chối lỗi quy tắc mà chính nó đã tìm ra

  • Ngay cả trước thời LLM cũng đã có vấn đề vùng gần nhất chưa bị chặn, nơi cứ vừa chặn một lỗi thì lập tức gặp lỗi khác lân cận hoặc một đường khác quay lại cùng lỗi đó
    Mô hình có thể học hành vi dài hạn mới, nên rất khó chỉ sửa hành vi mà không thay đổi ngữ cảnh đáng kể

• Khi dùng inject_rules.py đọc RULES.md và gắn vào đầu mỗi prompt như một hook UserPromptSubmit trong Claude, hiện tượng quy tắc bị mờ đi khi ngữ cảnh đầy đã giảm bớt
  Token prompt bị tiêu tốn nhanh hơn một chút, nhưng tổng lượng token dùng lại giảm, và Pro cũng dùng được. Không hoàn hảo nhưng tốt hơn, và xóa bộ nhớ để Claude không bịa ra những nội dung cản trở hành vi mong muốn cũng có ích
  RULES_PATH trỏ tới RULES.md, và tệp được đọc với encoding='utf-8-sig' để loại bỏ BOM. Sau đó gửi ra standard output một JSON chứa hookSpecificOutput.hookEventName = "UserPromptSubmit" và toàn bộ quy tắc trong additionalContext
  Phần mở đầu viết rằng quy tắc cũng áp dụng cho lượt này và phải chạy năm phép kiểm tra của quy tắc 33 trước khi nêu ra nội dung không được yêu cầu. Nếu gặp OSError thì âm thầm trả về 0 để vẫn tiếp tục lượt đó ngay cả khi không có tệp quy tắc

  • Tôi tò mò không biết so với cách kiểm tra đầu ra bằng response hook và chỉ tiêm quy tắc khi nó đi chệch hướng thì cách luôn tiêm toàn bộ quy tắc mỗi lần có ưu điểm gì

• Bài viết này cho thấy cũng có những vấn đề tiềm ẩn trong phát triển dựa trên đặc tả quy mô lớn. Vấn đề gần đây chưa thể làm rõ là hiện tượng việc triển khai tác tử dần lệch khỏi đặc tả

  • Tôi cũng gặp hiện tượng đó và bắt đầu gọi nó là vision drift
    Trình theo dõi issue tôi tự làm hỗ trợ du hành thời gian trên board nên rất hợp để xử lý vấn đề này. Với lệnh như :replay 4h, có thể nhìn một phát toàn bộ luồng công việc đã thay đổi ra sao trong khoảng thời gian trước đó và checkout trạng thái cũ mong muốn
    Chi tiết được viết ở https://dev.to/ljtn/vision-drift-addressing-the-next-problem...
  • Độ lệch giữa đặc tả lớn và triển khai tác tử là rất lớn. Tôi đã thử nhiều nhưng bất kể loại mô hình nào, Fable hay Sol cũng đều bỏ sót hàng loạt chi tiết và đi chệch hướng
    Tôi đang phát triển http://engine.build để khép lại khoảng cách giữa đặc tả và triển khai, giúp triển khai khớp với đặc tả. Dù không mang lại cảm giác thỏa mãn như tự tay giải quyết vấn đề phức tạp bằng code, việc viết đặc tả rõ ràng và suy nghĩ sâu về vấn đề cũng đủ thỏa mãn

• Tôi phát hiện hành vi này vào khoảng vài tháng trước khi còn dùng Sonnet 4.6. Trong một dự án cá nhân, tôi đã đặt ra các quy tắc nghiêm ngặt cho chú thích mã để giảm số lượng token
  Từ một phiên bản nào đó, Claude bắt đầu phớt lờ các chỉ thị rõ ràng trong CLAUDE.md và chèn vào những chú thích khổng lồ tham chiếu đến ticket và các công việc khác
  Từ đó về sau, tôi phát triển như một quản đốc hiện trường của dây chuyền lắp ráp ô tô. Phiên làm việc chính triển khai dựa trên kiến thức như CLAUDE.md, còn nhiều tác tử con được chuyên môn hóa cao chỉ phụ trách một mối quan tâm duy nhất để cưỡng chế các quy tắc như cấm/giảm thiểu chú thích hoặc phản ánh chúng vào kết quả cuối cùng