Gọi một LLM qua API chưa tạo ra một agent. Model về cơ bản vẫn nhận input, sinh output rồi kết thúc. Muốn nó đọc file, chạy code, làm việc nhiều bước, nhớ việc đang làm và tự kiểm tra kết quả, cần một lớp phần mềm bao quanh model. Lớp đó có thể gọi là agent harness.
Một cách dễ hình dung, harness có 6 thành phần chính:
1. Loop — vòng điều phối
Loop là vòng lặp quyết định agent sẽ tiếp tục làm gì và khi nào dừng.
Chatbot thông thường:
User → Model → Answer
Agent:
Ví dụ coding agent nhận yêu cầu sửa bug. Nó có thể đọc file, sửa code, chạy test, thấy test fail, sửa tiếp rồi chạy lại. Toàn bộ chuỗi đó tồn tại nhờ loop.
Nói ngắn gọn: Loop biến một lần gọi model thành một quá trình làm việc nhiều bước. OpenAI hiện cũng phân biệt giữa việc tự sở hữu agent loop và dùng runtime quản lý sẵn orchestration/session state.
2. Tools — agent có thể làm gì?
Tool là một capability mà harness cho phép model yêu cầu sử dụng.
Ví dụ:
- read_file(path)
- edit_file(path)
Model không trực tiếp đọc ổ đĩa hay gọi database. Nó phát một tool call, harness thực thi rồi trả kết quả lại.
3. Context — model đang nhìn thấy gì?
Context là toàn bộ thông tin model được nhìn thấy trong lần suy luận hiện tại.
Context có thể bao gồm:
- Prompt
- Lịch sử chat
- tài liệu đính kèm
Và không phải thông tin nào hệ thống biết cũng nên nhét vào context.
Một log 50.000 dòng không nên đổ nguyên vào model. Có thể lưu nó thành file, đưa model vài dòng lỗi quan trọng và đường dẫn để đọc tiếp khi cần.
Đó là context engineering: không phải “nhét càng nhiều càng tốt”, mà là chọn đúng thông tin cho đúng bước. Anthropic mô tả context như một tài nguyên hữu hạn và nhấn mạnh việc liên tục chọn, compact và lấy lại thông tin cần thiết trong agent loop.
4. Environment — agent được hành động ở đâu?
Environment là nơi các tool thực sự chạy và là nơi xác định giới hạn quyền của agent.
Ví dụ:
read_file → filesystem
query_db → database
Tool nói agent có khả năng gì. Environment quyết định nó được làm việc đó ở đâu và tới mức nào
Đây cũng là nơi hard constraint nên được thực thi. Thay vì chỉ prompt “đừng xóa file hệ thống”, tốt hơn là agent hoàn toàn không có quyền truy cập file hệ thống.
OpenAI hiện mô tả environment của agent như sandbox/computer tùy chọn nơi agent truy cập files, load skills và chạy commands.
5. Memory — thứ gì cần tồn tại qua thời gian?
Memory là state được giữ lại để agent có thể dùng lại sau này.
Context và memory không giống nhau:
Memory = thứ hệ thống giữ lại.
Context = phần memory được đưa cho model lúc này.
Nhưng không nên lưu mọi thứ. File structure có thể đọc lại từ filesystem, commit history có thể hỏi Git, nên memory chỉ nên giữ những fact bền và có giá trị cho session sau.
6. Observability — agent thực sự đã làm gì?
Observability là lớp giúp engineer nhìn thấy và đo được quá trình agent hoạt động.
Ví dụ cần biết:
Model nào được gọi? Tool nào chạy? Arguments là gì? Tool mất bao lâu? Bao nhiêu token? Fail ở bước nào?
Một trace có thể trông như sau:
Ghép cả 6 thành một Harness
Cuối cùng, sáu phần nối với nhau như thế này:
Đọc sơ đồ từ trên xuống: Loop điều phối quá trình. Context đưa đúng thông tin cho model. Model chọn Tool. Tool chạy trong Environment. Kết quả quay lại context để model quyết định bước tiếp theo. Memory giữ những thứ cần tồn tại lâu hơn một session, còn Observability đứng ngoài quan sát toàn bộ quá trình.
Đến đây có thể thấy model chỉ là một phần của agent. Cùng một model, nhưng harness khác nhau có thể tạo ra hai sản phẩm khác nhau hoàn toàn.
Nếu agent làm không tốt, trước khi đổi sang model mạnh hơn nên hỏi sáu câu: Loop có đúng không? Tool có thiếu không? Context có nhiễu không? Environment có đúng capability không? Memory có giữ đúng state không? Và mình có đủ observability để biết nó đang hỏng ở đâu không?
Đó mới là tư duy Harness Engineering.