编程 Agent 选择：context 理解能力比模型更重要

你根据 model 的 benchmark 来选择 coding agent，但试用几周后团队的生产力并没有改变。一位开发者在中等规模的 Rust codebase 上连续两周将 OpenCode 作为日常 driver，得出的结论值得仔细一读：model 几乎不再重要。

决定一个 coding agent 是帮你节省时间还是浪费你一小时的关键，不在于它背后运行的是哪个 model，而在于这个 agent 对代码库的 convention 和实际 workflow 的理解程度。OpenCode、Cursor 和 Copilot 都跑在足够优秀的 model 上——真正的差异在于它们处理 context 的方式。

Vấn đề convention: agent có hiểu "phương ngữ" của repo bạn không

Repo nào cũng có luật ngầm: style xử lý lỗi, cách đặt tên module, cấu trúc test. Cursor giải quyết bằng rules file và bộ nhớ các lần edit trước, nhưng đó là hộp đen độc quyền — bạn tin vào heuristic của Cursor mà không sửa được logic bên trong. Copilot còn kém hơn ở điểm này: nó được train trên toàn bộ code trên internet, nên mặc định chọn pattern phổ biến nhất chứ không phải pattern của bạn.

OpenCode khác ở chỗ mã nguồn mở, nên pipeline context có thể kiểm tra được — bạn thấy chính xác file nào được đưa vào, thứ tự nào, phần nào bị cắt. Tác giả viết một config nhỏ yêu cầu agent luôn đọc CONTRIBUTING.md trước và ưu tiên cây src/ hơn tests/ khi lập plan ban đầu. Việc này mất 20 phút nhưng thay đổi chất lượng của mọi phản hồi sau đó.

Vấn đề workflow: agent có sống trong terminal của bạn không

Với dev sống trong terminal, chuyển sang Cursor nghĩa là phải rời tmux, mở GUI, làm việc trong editor riêng của họ — một khoản "thuế workflow" không đáng trả. Copilot đỡ hơn vì chạy trong VS Code, nhưng vẫn gắn chặt vào hệ sinh thái GitHub. OpenCode chạy trong terminal nên hòa vào workflow có sẵn: pipe output, script xung quanh nó, chạy trong CI nếu cần — nó là một Unix tool, không phải một sản phẩm đóng gói.

OpenCode vẫn thua ở đâu

Không phải mọi thứ đều màu hồng. Setup OpenCode với đúng model, đúng context rule, đúng permission mất cả buổi chiều; Cursor chạy được ngay trong 10 phút. OpenCode agnostic với model, nghĩa là bạn phải tự chọn và tinh chỉnh model — Cursor và Copilot ẩn hết việc đó sau lựa chọn model riêng của họ, đơn giản hơn dù kém linh hoạt hơn. Về độ mượt: diff preview của Cursor và gợi ý inline của Copilot vẫn nhỉnh hơn hẳn.

Nếu bạn thực sự cần linh hoạt nhiều model, đây là một pattern cụ thể

Một bài hướng dẫn kỹ thuật khác — viết cho bài toán phân loại code review — mô tả một cách làm cụ thể để không khóa cứng vào một provider: đặt một boundary OpenAI-compatible chat completions duy nhất phía sau service Node.js, discover model khả dụng qua API, và giữ nguyên prompt cùng JSON contract trong khi route model qua configuration.

Nguyên tắc cốt lõi mà bài đó đưa ra: giữ ba thứ về phía bạn — input cần review, schema các finding được phép, và bộ acceptance test. Đặt việc chọn provider sang phía bên kia ranh giới. Một thay đổi có thể chuyển từ model OpenAI sang Claude hay Gemini mà không đụng vào parser, miễn là mọi response bị ép vào đúng một schema hẹp. Đừng để một parser dễ dãi đoán ý model — điều đó khiến routing layer trông linh hoạt trong khi âm thầm đổi hành vi sản phẩm.

Lưu ý: bài viết đó đề xuất một gateway thương mại cụ thể cho vai trò này — đây là khuyến nghị của tác giả bài gốc, không phải một xác nhận trung lập, nên hãy tự đánh giá theo tiêu chí portability và chi phí của team bạn trước khi theo.

Kết luận

Nếu bạn đang đánh giá coding agent, đừng bắt đầu từ benchmark model. Hãy thử đo hai thứ: agent có cho bạn kiểm tra và sửa được context pipeline không, và agent có sống được trong workflow bạn đang dùng hay bắt bạn đổi workflow theo nó. Nếu team cần chạy nhiều model cùng lúc — một model local cho việc nhạy cảm, một model API cho việc nặng — hãy tách rõ boundary gọi model khỏi logic nghiệp vụ ngay từ đầu, thay vì để mỗi lần đổi provider lại phải sửa code rải rác khắp nơi.

Một cách kiểm tra nhanh trước khi commit vào một agent: chạy cùng một tác vụ thật trên cả ba lựa chọn, đo thời gian setup ban đầu, đo số lần bạn phải rời khỏi terminal hoặc editor quen thuộc, và đo xem sau một tuần bạn có còn phải sửa tay kết quả agent trả về hay không. Ba con số đó nói nhiều hơn bất kỳ bảng benchmark model nào, vì chúng đo đúng thứ quyết định năng suất: context và workflow, không phải độ thông minh của model đứng sau.

This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.