Các thành phần của coding agent

• Coding agent là một hệ thống gồm vòng lặp điều khiển và software harness xoay quanh LLM, lặp đi lặp lại việc viết mã, chạy mã và nhận phản hồi
• Agent harness phụ trách quản lý ngữ cảnh, truy cập công cụ, cấu trúc prompt và điều khiển trạng thái; còn coding harness chuyên biệt cho tác vụ lập trình sẽ quản lý repository, test và kiểm tra lỗi
• Coding agent vận hành dựa trên sáu thành phần: ngữ cảnh repo theo thời gian thực, cache prompt, truy cập công cụ, quản lý ngữ cảnh, bộ nhớ phiên và ủy quyền cho subagent
• Ngay cả với cùng một LLM, hiệu năng và trải nghiệm người dùng có thể khác biệt rất lớn tùy theo chất lượng thiết kế harness; một harness được thiết kế tốt sẽ cung cấp môi trường phát triển liên tục và nhận biết ngữ cảnh
• Mini Coding Agent là ví dụ tối giản được triển khai bằng Python thuần cho cấu trúc này, và khác với OpenClaw ở mức độ chuyên biệt cho lập trình cũng như phạm vi vận hành

---

Các thành phần của coding agent

• Coding agent là một hệ thống gồm vòng lặp điều khiển lấy LLM làm trung tâm và software harness bao quanh nó, với cấu trúc lặp lại việc viết, sửa, chạy mã và nhận phản hồi
• LLM là mô hình dự đoán token tiếp theo cơ bản, còn reasoning model là LLM được huấn luyện để thực hiện nhiều bước suy luận trung gian và kiểm chứng hơn
• Agent là vòng lặp điều khiển lặp lại việc gọi mô hình, sử dụng công cụ, cập nhật trạng thái và quyết định khi nào kết thúc để đạt được mục tiêu
• Agent harness là cấu trúc phần mềm bao quanh vòng lặp này, phụ trách quản lý ngữ cảnh, truy cập công cụ, cấu trúc prompt và điều khiển trạng thái
• Coding harness là dạng chuyên biệt cho công việc lập trình, quản lý ngữ cảnh repository, thực thi mã, test và kiểm tra lỗi

Mối quan hệ giữa LLM, reasoning model và agent

• Có thể ví LLM là động cơ, reasoning model là động cơ được tăng cường, còn agent harness là hệ thống điều khiển động cơ đó
• LLM và reasoning model có thể tự thực hiện tác vụ lập trình ở mức nhất định, nhưng trong môi trường phát triển thực tế cần quản lý ngữ cảnh phức hợp như duyệt repo, tìm hàm, chạy test, phân tích lỗi
• Coding harness giúp tối đa hóa hiệu năng của mô hình và mang lại trải nghiệm lập trình mạnh hơn nhiều so với giao diện chat đơn giản

Vai trò của coding harness

• Là lớp phần mềm bao quanh mô hình, thực hiện lắp ráp prompt, phơi bày công cụ, theo dõi trạng thái tệp, chạy lệnh, quản lý quyền hạn, cache và lưu bộ nhớ
• Ngay cả với cùng một LLM, hiệu năng và trải nghiệm người dùng thay đổi đáng kể tùy theo thiết kế harness
• Ví dụ, ngay cả mô hình open-weight như GLM-5 cũng có thể cho hiệu năng tương tự Codex hoặc Claude Code nếu được tích hợp vào harness ở cấp độ tương đương
• OpenAI từng duy trì riêng các mô hình hậu xử lý theo từng harness như GPT-5.3 và GPT-5.3-Codex

6 thành phần cốt lõi của coding agent

• 1. Ngữ cảnh repository theo thời gian thực (Live Repo Context)

  • Agent cần nhận biết trạng thái Git hiện tại, branch, tài liệu, lệnh test của repo
  • Chỉ dẫn như “sửa test” sẽ thay đổi theo cấu trúc và ngữ cảnh của repo, vì vậy cần thu thập thông tin tóm tắt repo trước khi làm việc
  • Nhờ đó, agent không phải bắt đầu từ trạng thái rỗng mỗi lần mà có được nền tảng làm việc ổn định (stable facts)

• 2. Cấu trúc prompt và tái sử dụng cache (Prompt Shape and Cache Reuse)

  • Tóm tắt repo, mô tả công cụ, chỉ dẫn chung thường ít thay đổi nên có thể cache dưới dạng "stable prompt prefix"
  • Thay vì lắp ráp lại toàn bộ prompt cho mỗi yêu cầu, chỉ cần cập nhật phần đã thay đổi
  • Điều này giảm lãng phí tính toán và duy trì tính nhất quán của phản hồi trong các phiên lặp lại

• 3. Truy cập và sử dụng công cụ (Tool Access and Use)

  • Thay vì chỉ đề xuất lệnh, mô hình có thể thực sự chạy lệnh thông qua bộ công cụ do harness định nghĩa
  • Mỗi công cụ có định dạng đầu vào/đầu ra và ranh giới rõ ràng, đồng thời trải qua quy trình kiểm tra tính hợp lệ và phê duyệt trước khi thực thi
  • Ví dụ: kiểm tra “đây có phải công cụ đã biết không?”, “tham số có hợp lệ không?”, “đường dẫn làm việc có nằm trong workspace không?”
  • Nhờ đó tăng tính bảo mật và độ tin cậy; mức độ tự do của mô hình giảm đi nhưng tính thực dụng tăng lên

• 4. Giảm thiểu phình to ngữ cảnh (Minimizing Context Bloat)

  • Trong các phiên dài, việc đọc tệp lặp lại, log và đầu ra công cụ có thể gây ra vấn đề vượt quá độ dài prompt
  • Harness quản lý việc này bằng hai chiến lược
    • Clipping: rút gọn văn bản dài, log và ghi chú xuống độ dài nhất định
    • Summarization: nén và tóm tắt lịch sử hội thoại cũ
  • Các sự kiện gần đây được giữ chi tiết, còn thông tin cũ được loại bỏ trùng lặp và nén lại
  • Kết quả là chất lượng ngữ cảnh ảnh hưởng đến hiệu năng thực tế nhiều hơn cả chất lượng mô hình

• 5. Bộ nhớ phiên có cấu trúc (Structured Session Memory)

  • Agent tách trạng thái thành working memory và full transcript
  • Toàn bộ lịch sử chứa mọi yêu cầu, phản hồi và đầu ra công cụ, cho phép tiếp tục lại phiên làm việc
  • Working memory lưu tóm tắt thông tin hiện đang quan trọng như tác vụ hiện tại, tệp chính, ghi chú gần đây
  • Compact transcript dùng để tái dựng prompt cho mô hình, còn working memory dùng để duy trì tính liên tục của công việc

• 6. Ủy quyền cho subagent có giới hạn (Delegation With Bounded Subagents)

  • Agent chính tạo subagent để xử lý song song các tác vụ phụ
  • Ví dụ: tách riêng các việc như tìm vị trí định nghĩa của một symbol, nội dung file cấu hình, hay nguyên nhân test thất bại
  • Subagent chỉ kế thừa ngữ cảnh cần thiết, đồng thời bị ràng buộc như chỉ đọc hoặc giới hạn độ sâu đệ quy
  • Cả Claude Code và Codex đều hỗ trợ subagent, và thiết lập ranh giới bằng phạm vi công việc và độ sâu ngữ cảnh

Tóm tắt các thành phần

• Sáu thành phần này gắn kết chặt chẽ với nhau, và chất lượng thiết kế harness quyết định hiệu quả khai thác mô hình
• Một coding harness được thiết kế tốt sẽ mang lại môi trường hỗ trợ phát triển liên tục và nhận biết ngữ cảnh vượt xa chat LLM đơn thuần
• Mini Coding Agent(https://github.com/rasbt/mini-coding-agent) là ví dụ tối giản được triển khai bằng Python thuần cho cấu trúc này

So sánh với OpenClaw

• OpenClaw gần với nền tảng agent đa dụng hơn là trợ lý chuyên cho lập trình
• Điểm chung:
  • Sử dụng file prompt và chỉ dẫn trong workspace (AGENTS.md, TOOLS.md, v.v.)
  • Bao gồm file phiên JSONL, nén hội thoại và quản lý phiên
  • Có thể tạo phiên phụ và subagent
• Khác biệt:
  • Coding agent được tối ưu cho duyệt repo, chỉnh sửa mã và chạy công cụ cục bộ
  • OpenClaw tập trung vào vận hành agent dài hạn qua nhiều kênh và nhiều workspace

Phụ lục: giới thiệu sách mới

• Đã hoàn thành bản thảo Build A Reasoning Model (From Scratch), hiện đang mở bản truy cập sớm (Early Access)
• Nhà xuất bản đang thực hiện phần dàn trang với mục tiêu phát hành vào mùa hè
• Cuốn sách tập trung vào cách tiếp cận tự triển khai trực tiếp cơ chế suy luận của LLM để hiểu nó

[GN⁺]

Ý kiến trên Hacker News

• context dài vẫn tốn kém, và nếu có quá nhiều thông tin không cần thiết thì sẽ tạo ra nhiễu
  Vì vậy tôi nghĩ sinh dựa trên spec tốt hơn kiểu coding tương tác
  Ossature mà tôi làm đi theo hướng ngược lại. Trước hết viết một spec mô tả hành vi, rồi trước khi sinh code sẽ kiểm tra các phần thiếu hoặc mâu thuẫn, đồng thời tạo ra một build plan TOML ghi rõ mỗi tác vụ tham chiếu tới phần spec và file nào
  LLM chỉ xem những phần cần thiết, và không có chuyện tích lũy lịch sử hội thoại. Mọi prompt và phản hồi đều được lưu xuống đĩa nên khả năng truy vết được đảm bảo tự động
  Gần đây tôi đã dùng đúng cách này để làm hoàn toàn một trình giả lập CHIP-8 chỉ từ spec, và cũng có các dự án ví dụ

  • Gần đây tôi hay nghĩ rằng các coding agent hiện nay không có nguồn sự thật trung tâm
    Trước đây thì cả đội đều biết mình đang xây cái gì, còn bây giờ agent cứ phải bắt đầu lại từ đầu mỗi lần
    Vì thế tôi tin luồng chat → spec → code mới là tương lai. Bước spec → code nên chạy mà không cần con người can thiệp
    Nếu đặc tả còn mơ hồ thì phải hỏi con người thật rõ ràng, rồi dựa vào đó mới sinh code
    Hiện giờ các yêu cầu mơ hồ cứ lặp đi lặp lại, mà con người cũng không học được vì sao lại như vậy. “memory” hay các file agent chỉ là giải pháp tạm bợ
  • Tôi cũng đang làm thứ tương tự. Chưa công khai, nhưng đó là một workflow engine lấy spec làm trung tâm
    Thay vì hội thoại, tôi đưa cho LLM phần context được chiếu ra từ code và spec, và cấu hình context khác nhau cho từng bước
    Cách này ngăn drift do context tích lũy, và workflow do code của tôi điều khiển chứ không phải LLM
    Ý tưởng dùng TOML làm artifact truyền giữa các bước khá thú vị nên tôi định tham khảo
  • Tôi cũng nghĩ vậy. Agent A chỉ sửa spec, còn Agent B chỉ nhìn spec để build
    Người dùng chỉ cần xem diff do Agent A tạo ra, nhờ đó thoát khỏi việc xác minh code lặp đi lặp lại
    Cốt lõi là luôn giữ được ý định (intent). Phải lưu nguyên trạng đặc tả và ngữ cảnh
    Chi phí có thể cao gấp 2~3 lần, nhưng về dài hạn có vẻ sẽ hiệu quả hơn
  • Workflow dựa trên chat rất mệt và làm mất nhiều thông tin
    Tôi nghĩ cách tiếp cận dựa trên spec tốt hơn nhiều. Tôi tò mò con người sẽ can thiệp thế nào — có chỉnh song song spec và audit không, tỷ lệ sinh code thành công ra sao, và có dự định áp dụng cho code hiện có không
  • Tôi cũng thử bắt đầu từ spec rồi lặp cải thiện code bằng tổ hợp Claude Code + Cucumber
    Tôi muốn biết Ossature khác gì so với cách tiếp cận đó

• Thật ấn tượng khi chỉ với một state machine đơn giản và cách tiếp cận bash mà vẫn khai thác được tiềm năng của LLM

  • Vì thế tôi đang tự làm một coding agent cô lập
    Hệ sinh thái agent dạo này đầy rẫy tính năng thừa và những quyết định tệ
    Cách đây 10 năm người ta còn nói những công cụ như vậy cần có trách nhiệm, còn bây giờ thì đây là một giai đoạn hỗn loạn, trộn lẫn giữa nỗi sợ và cơn sốt thổi phồng
  • Cuối cùng cốt lõi vẫn là prompt/context engineering
    Mô hình đã có sẵn tri thức, nhưng để dẫn nó thành hành động thực tế thì thiết kế context rất quan trọng
    Một hướng đầy hứa hẹn là chuyển yêu cầu của người dùng thành các bước ở cấp độ của một lập trình viên lành nghề rồi nối với các công cụ cần thiết
    Tôi cho rằng cả model mã nguồn mở cũng hoàn toàn có thể cạnh tranh nếu có agent được tối ưu tốt và thêm một chút tinh chỉnh
  • Nhìn vào bản rò rỉ của Claude Code thì cấu trúc của nó không hề đơn giản
    Cần một harness phức tạp, nhưng nhờ vậy LLM hoạt động mang tính quyết định như một công cụ
  • Nhiều CLI agent cho rằng chỉ tiếp cận bằng bash là chưa đủ, nên đang cố nhồi đủ loại tính năng vào JavaScript TUI
  • Dùng Python thay cho bash hữu ích hơn
    Thay vì pipeline, bạn có thể tự do ghép bất kỳ logic nào mình muốn

• Ví dụ rất ngắn gọn và rõ ràng
  Tôi không dùng coding agent, nhưng bài này giúp hiểu được bản chất của coding agent
  Nó cho thấy rất rõ rằng chỉ 1k LOC code hữu ích cũng có thể biến thành mớ hỗn độn 500k LOC

• Đã có rất nhiều người nối các model mở như GLM-5 vào Claude Code hay Codex CLI để dùng
  Tài liệu chính thức của GLM cũng khuyến nghị điều này

  • Không đến mức Opus, nhưng tổ hợp GLM và Qwen3.5-plus là quá ổn cho các dự án cá nhân

• Bài viết rất ấn tượng. Tôi từng làm một agent không viết code dựa trên email, và nguyên lý cũng tương tự
  Mỗi vòng lặp email đều khởi tạo lại context nên tự nhiên giải quyết được vấn đề tích lũy context
  Điều quan trọng là cân bằng giữa phần context đưa vào prompt ban đầu và phần context tách ra thành tool
  Cũng phải tính đến caching và chi phí token
  Tôi có viết chi tiết trong bài blog của mình

• Tôi không thích từ “harness”. Tôi cứ nghĩ liệu có từ nào hay hơn không

  • Nó thường được dùng theo nghĩa shim để quản lý chương trình, như “test harness” hay “fuzzing harness”
  • Trớ trêu là giờ cái gì cũng thành “app”, nhưng ứng dụng để chạy LLM lại không được gọi là “app”
  • Rốt cuộc “harness” chỉ là cách nói bóng bẩy của scaffolding
  • Nhưng cũng có phản hồi rằng nếu vậy thì hãy đề xuất một từ thay thế đi

• tool output truncation rất hiệu quả trong việc giảm phình to context
  Tôi lắp ráp context trên nền SQLite, rồi khi cần thì khôi phục các lời gọi tool đã bị cắt bằng ID thông điệp
  Thử nghiệm liên quan được ghi lại trong tài liệu

• Chạy Claude Code bằng model khác là chuyện rất phổ biến
  Tài liệu ví dụ cũng có nhắc tới
  Nhưng theo kinh nghiệm của tôi thì vẫn chưa đạt tới mức của model Anthropic

  • Tùy dự án, các model giá rẻ như MiMo V2 Pro cũng làm được 70~80%, nhưng cũng có khi Sonnet vượt trội hơn hẳn
    Opus chỉ có giá trị tương xứng chi phí trong khoảng 5% trường hợp
    Tôi thấy OpenCode tốt hơn Claude Code rất nhiều nên đã mua credit API OpenRouter
    Chỉ với lệnh tùy chỉnh và định nghĩa agent đơn giản, OpenCode đã đủ mạnh
    Chỉ cần định nghĩa workflow bằng AGENTS.md, ROADMAP.md v.v. là đã đủ cho phần lớn dự án
    Tôi nghĩ cấu trúc linh hoạt phù hợp với thay đổi của các model mới hơn là một harness quá phức tạp
  • Tôi tò mò không biết Anthropic tốt hơn là đơn thuần vì chất lượng model, hay là nhờ tối ưu harness

• Sự tiến bộ của coding agent đến nhiều hơn từ việc cải thiện cấu trúc bao quanh (scaffolding) chứ không phải bản thân model
  Khi đã có tool, context của repo và state machine đơn giản, nút thắt sẽ chuyển sang chất lượng context

• Bài viết rất mạnh. Tôi cũng hay giải thích coding agent bằng ẩn dụ động cơ/ô tô
  Nếu muốn thử nghiệm các thành phần cơ bản, có thể tham khảo OpenHands software-agent-sdk