TL;DR

  • Agent = Model + Harness - công thức của LangChain: model chứa trí tuệ, harness là toàn bộ code, config và execution logic không phải model (system prompt, tool, memory, sandbox, middleware).
  • Loop engineering thiết kế vòng lặp có trigger, evidence và stopping rule rõ ràng - khác hẳn một prompt đơn lẻ chỉ gọi model một lần.
  • Graph engineering biểu diễn workflow thành node và edge tường minh - kiểm soát branching, fan-out song song, join và cycle có exit condition.
  • Ba lớp lồng nhau chứ không thay thế nhau: graph chạy bên trong harness, loop sống bên trong graph, và harness cấp state/tool/evaluator mà loop cần.

Vì sao ba thuật ngữ này cứ bị gộp làm một

Cả ba khái niệm đều xoay quanh cùng một model, đều ảnh hưởng độ tin cậy của agent, và đều có thể chứa "loop" theo nghĩa nào đó - lý do chúng dễ bị dùng lẫn lộn. Nhưng chúng mô tả ba quyết định kỹ thuật khác nhau, khác biệt trở nên quan trọng ngay khi agent rời notebook demo để chạm file thật, API thật hoặc code production. Mô hình tư duy gọn nhất: environment - feedback - flow. Harness xây máy móc quanh model, loop thiết kế chu kỳ làm việc và phản hồi, graph làm rõ tô-pô workflow: node, nhánh rẽ, join và cycle có kiểm soát.

Một raw model không thể tự tạo file, giữ trạng thái dự án, chạy test suite hay tự khởi động lại job lỗi - những năng lực đó đến từ môi trường model được đặt vào.

Agent Harness Engineering: lớp hạ tầng bao quanh model

Theo LangChain, agent chính là model cộng với harness, và harness là toàn bộ code, config, execution logic nằm ngoài model - system prompt, tool definition, memory, filesystem, sandbox, model routing, handoff, middleware hook, compaction, permission, logging, verification interface. OpenAI Agents SDK mô tả cùng lõi vận hành từ góc nhìn runtime: Runner gọi model, thực thi tool call, xử lý handoff, mang theo state và chỉ dừng khi run đạt điều kiện kết thúc thật sự.

Từ "harness" hữu ích vì nó kéo sự chú ý khỏi việc sùng bái model. Hai đội dùng chung một foundation model vẫn có thể cho kết quả rất khác nhau, vì một bên cấp tool sạch, workspace ổn định, permission giới hạn và state quan sát được, bên kia chỉ đưa prompt mơ hồ. Một harness nghiêm túc thường gồm:

  • Context injection: instruction, fact truy xuất được, trạng thái hội thoại, skill và policy theo task.
  • Action surface: API, trình duyệt, shell, code interpreter, database và tool tương thích MCP.
  • Persistence: file, checkpoint, session, progress log, git history và bộ nhớ dài hạn.
  • Execution control: timeout, retry, budget, model routing, spawn sub-agent, approval gate.
  • Safety & governance: permission, isolation, allow list, xử lý secret, ủy quyền con người.
  • Observability: trace, input/output tool, chuyển trạng thái, chi phí, độ trễ, kết quả evaluation.

Harness engineering đặc biệt quan trọng với task chạy dài. Với coding qua nhiều phiên, Anthropic phát hiện chỉ context compaction là chưa đủ - phải thêm một "initializer agent" thiết lập môi trường (script init.sh, file claude-progress.txt) và một "coding agent" làm việc tăng dần, để lại artifact cho phiên sau. Áp dụng khi agent thiếu năng lực, mất trạng thái, hoặc không thể audit.

Các thành phần của một agent harness xoay quanh model
Sáu thành phần cốt lõi của một harness nghiêm túc: context, tool, memory, sandbox, permission và observability - tất cả xoay quanh model.

Loop Engineering: vòng lặp chạy bằng bằng chứng, không phải niềm tin

Mỗi agent dùng tool mang sẵn một vòng lặp nhỏ: gọi model, xem kết quả, chạy tool, đưa quan sát trở lại model, lặp tới khi có câu trả lời cuối. Khi người xây dựng chủ động xếp chồng thêm chu kỳ mới quanh hành vi đó, loop engineering bắt đầu. Một verification loop cho agent tạo artifact, chạy check tất định hoặc grader, chỉ lặp lại khi có bằng chứng lỗi. Một event-driven loop đánh thức agent khi có lịch trình hoặc tài liệu mới. Một improvement loop phân tích trace và lỗi, chỉnh instruction/tool, rồi kiểm tra phiên bản mới có tốt hơn không.

Giải phẫu một loop tốt gồm: trigger (điều gì khởi động chu kỳ), goal (trạng thái cụ thể, không phải "cứ cải thiện đi"), state (chu kỳ sau cần biết gì mà không phải replay toàn bộ), action policy (agent được phép làm/chi gì), evidence (test, schema, citation, metric hoặc human review), và stopping rule (thành công, giới hạn ngân sách, timeout, hoặc escalate cho người). Đừng lặp theo độ tự tin - hãy lặp theo bằng chứng: "test pass, schema hợp lệ và reviewer đã duyệt" mới là điều kiện dừng, không phải "agent nói là đã xong".

Loop khác prompt engineering: prompt chỉ định model làm gì một lần, loop định nghĩa hệ thống làm gì sau đó. Đánh đổi là chi phí và độ trễ - chỉ thêm loop ở nơi chi phí thất bại cao hơn chi phí verify.

Vòng lặp loop engineering: trigger, action, evidence, feedback
Giải phẫu một loop được thiết kế tốt: trigger khởi động, action thực thi, evidence xác nhận kết quả, feedback quay lại trigger tiếp theo.

Graph Engineering: khi cần kiểm soát tường minh đường đi

Graph engineering đặt câu hỏi khác: không chỉ agent làm gì, mà thành phần nào được phép chạy tiếp theo. Bước là node, bước hợp lệ là edge - có thể diễn tả trình tự, nhánh rẽ có điều kiện, fan-out song song, join, cycle và điểm ngắt cho con người can thiệp. State di chuyển xuyên graph, tô-pô cho phép kiểm chứng luồng điều khiển mong muốn.

LangGraph là hạ tầng orchestration cấp thấp cho agent chạy dài, có trạng thái, với durable execution và human-in-the-loop control tích hợp sẵn - dùng khi workflow pha trộn thành phần tất định và agentic, hoặc cần oversight cao cho quyết định rủi ro.

Tài liệu Microsoft AutoGen về GraphFlow cũng thẳng thắn: dùng graph khi cần kiểm soát chặt thứ tự agent hành động, hoặc quy trình nhiều bước có cycle. DiGraphBuilder hỗ trợ fan-out song song và loop với exit condition an toàn - ví dụ writer viết nháp, fan-out sang hai editor độc lập, rồi join vào một reviewer cuối.

Kỹ sư graph quyết định: ranh giới node, schema state, điều kiện routing (bằng chứng nào đẩy việc tiến/lùi/escalate), và durability (checkpoint đặt ở đâu). Graph đáng công sức khi có nhánh rẽ ý nghĩa, việc song song, phê duyệt hoặc nhiều agent chuyên biệt; kém hữu ích khi chỉ là "đưa agent ba tool rồi để nó tự làm" - ép mọi đường đi vào sơ đồ cố định quá sớm khiến hệ thống giòn hơn.

Graph engineering: node và edge, fan-out song song và join
Một graph thực thi đơn giản: Start fan-out song song sang hai worker độc lập, rồi join kết quả tại một node cuối - kèm một cycle quay lại có kiểm soát.

Ba lớp lồng vào nhau thế nào trong một hệ thống thực

Hãy hình dung một agent nghiên cứu và xuất bản, chịu trách nhiệm tạo một bản tin ngành. Graph chạy bên trong harness: node "research", "viết nháp", "fact-check", "publish" nối bằng edge có điều kiện. Bên trong node "fact-check" là một loop hoàn chỉnh - trigger khi có nháp mới, evidence là citation hợp lệ, stopping rule là mọi claim đều có nguồn hoặc đã escalate cho người. Toàn bộ graph lẫn loop đó chạy trên nền một harness cấp filesystem lưu nháp, MCP tool tra nguồn, và observability để trace vì sao một bước fail. Ba lớp không thay thế nhau: harness mất trạng thái thì graph đẹp cũng vô nghĩa; harness tốt mà loop thiếu bằng chứng vẫn phí tiền; loop cẩn thận vẫn khó vận hành khi branching bị nhét vào code ad-hoc thay vì một graph tường minh.

Chẩn đoán lỗi: bắt đầu sửa ở lớp nào

Triệu chứngBắt đầu từHướng sửa
Agent không truy cập đúng dữ liệu/tool an toànHarnessTool contract, permission, sandbox
Agent quên tiến độ giữa các phiênHarnessDurable state, checkpoint, progress artifact
Lần thử đầu gần đúng nhưng chưa đủ tin cậyLoopGrader ngoài, test tất định, retry có giới hạn
Agent làm tiếp sau khi xong, hoặc dừng trước khi có bằng chứngLoopĐiều kiện dừng dựa trên bằng chứng, budget rule
Nhiều specialist agent cần chạy theo thứ tự kiểm soát chặtGraphNode, edge, điều kiện routing và join
Lỗi khó định vị trong quy trình nhiều bướcGraph + HarnessTrace khớp với node và chuyển trạng thái
Workflow đổi quá thường xuyên để cố định thành sơ đồHarness đơn giản hơnGiữ control model-driven, hoãn formalize graph

Những sai lầm tốn kém khi thiết kế kiến trúc agent

  • Vẽ graph trước khi hiểu công việc: nhiều đội dịch quy trình nghiệp vụ thành hàng chục node trước khi quan sát cách một agent đủ năng lực thực sự giải quyết nó. Nên trace từ harness đơn giản hơn, rồi mới formalize đường đi đã ổn định.
  • Để model vừa viết vừa tự chấm điểm không safeguard: self-review dễ dính chung điểm mù - ưu tiên check tất định, tách context reviewer riêng, bắt buộc người duyệt hành động tác động lớn.
  • Dùng "cứ thử lại" làm đặc tả cho một loop: retry không giới hạn là lỗ hổng chi phí. Mọi loop cần mục tiêu đo được, bằng chứng mới, số lần thử tối đa và một đường escalate rõ ràng.
  • Đổ lỗi cho model về thất bại thuộc orchestration: model không thể bù đắp đáng tin cậy cho state cũ, tool schema mơ hồ hay điều kiện exit bị thiếu - nên sửa đúng lớp gây lỗi.

Kết: cách nhớ khác biệt đơn giản nhất

Harness engineering xây môi trường để model vận hành được. Loop engineering làm quy trình lặp lại có thể kiểm chứng và tiếp tục sau gián đoạn. Graph engineering làm một đường thực thi phức tạp trở nên tường minh và có thể kiểm soát. Không lớp nào thay thế lớp còn lại - harness mất trạng thái thì graph đẹp cũng vô dụng, loop thiếu bằng chứng vẫn lãng phí tiền. Ba lớp thiết kế đồng bộ, cùng việc đội ngũ hiểu rõ lớp nào giải quyết vấn đề gì, là điều kiện để có một hệ thống agent đáng tin cậy. via LangChain, via Anthropic, via OpenAI Agents SDK