Những vấn đề phiền toái và đáng lo ngại của OpenCode

 (wren.wtf)
5 điểm bởi GN⁺ 14 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Kết quả thử nghiệm OpenCode, agent lập trình AI mã nguồn mở có 161 nghìn sao GitHub, với Qwen3.6-27B chạy cục bộ cho thấy cả chất lượng công cụ lẫn thiết kế bảo mật đều tệ đến mức nên ngừng sử dụng
  • Việc tải lại AGENTS.md, cắt tỉa ngữ cảnh theo khoảng cách cố định, chèn ngày hiện tại và chuyển chế độ liên tục làm vô hiệu hóa prompt cache, khiến ngay cả trên M4 Max cũng có thể mất tới 10 phút mới bắt đầu sinh phản hồi
  • Nén phiên, system prompt, kiểm tra quyền, điều khiển sub-agent và TUI không phối hợp đúng cách, khiến ngữ cảnh và thông điệp bị mất, và agent có thể viết mã trong khi quên các đặc tả quan trọng
  • Bộ lọc quyền dựa vào Bash AST và mẫu chuỗi không chặn được thực thi gián tiếp, đường dẫn tuyệt đối, biến, Python, chuyển hướng, v.v.; giới hạn truy cập tệp bên ngoài và quyền vĩnh viễn cũng dễ bị vượt qua
  • Xét tới kết nối mặc định với mô hình từ xa, truy cập Internet không giới hạn và lỗ hổng RCE qua HTTP server trong quá khứ, chỉ Docker là không đủ; cần chặn tệp thực thi, đặt đường dẫn chỉ đọc và cách ly ở cấp hệ điều hành

Phạm vi và tiền đề đánh giá

  • OpenCode là dự án được nhà phát triển giới thiệu là agent lập trình AI, và tại thời điểm xem xét có 161 nghìn sao GitHub
  • Thử nghiệm dựa trên LLM cục bộ Qwen3.6-27B và phiên bản Git OpenCode baef5cd4
  • Đây không hẳn là một công bố bảo mật riêng, mà là xem xét lớp đường ống trong kiến trúc chuyển đầu ra LLM sang Bash thất bại như thế nào
  • Việc sử dụng LLM tự thân và việc máy của người dùng có thể dễ dàng bị xâm phạm hoặc xóa dữ liệu là hai vấn đề riêng biệt

Kiến trúc liên tục phá vỡ prompt cache

  • Các API kiểu OpenAI /v1/chat/completions gửi toàn bộ cuộc hội thoại đến thời điểm hiện tại dưới dạng JSON, rồi phản hồi bằng luồng SSE delta có kèm metadata JSON
    • Phiên càng dài thì chi phí upload tăng theo bình phương
    • Lời gọi công cụ dùng mã hóa kép: nhiều JSON delta được lắp lại thành JSON
  • Server là stateless, nhưng cache kết quả đánh giá để cải thiện hiệu năng
    • Tìm tiền tố cache dài nhất khớp với request
    • Prefill từ cuối tiền tố đến thông điệp cuối cùng
    • Sinh token mới cho tới token kết thúc
  • Trên M4 Max có băng thông bộ nhớ khoảng 0,5TB/s, tốc độ sinh token của Qwen3.6-27B dùng được, nhưng prefill ngữ cảnh dài tốn tính toán rất lớn
    • Nếu không tìm được cache tiền tố phù hợp, có thể phải chờ khoảng 10 phút trong khi GPU chạy tối đa rồi phản hồi mới bắt đầu được sinh
  • OpenCode glob hệ thống tệp ở mỗi lượt SSE và đọc lại AGENTS.md được chèn vào system prompt đầu tiên
    • Ngay cả khi sửa AGENTS.md cho phiên sau, toàn bộ phiên hiện tại vẫn bị đánh giá lại
  • Khi chuyển từ agent sang người dùng, OpenCode cắt tỉa ngữ cảnh lời gọi công cụ, làm vô hiệu hóa các đoạn cache lớn
    • Vì các kết quả công cụ cũ hơn PRUNE_PROTECT = 40_000 bị loại bỏ, ngay cả trong trường hợp tốt nhất cũng xảy ra cache miss 40 nghìn token
    • Việc ngắt cũng được xử lý như chuyển sang người dùng, nên nếu bạn sửa một hướng đi sai, cache bị bỏ và phải chờ lại
  • Vì ngày hiện tại được đưa vào system prompt đầu tiên và đánh giá lại ở mỗi lượt SSE, qua nửa đêm sẽ gây cache miss toàn bộ

Cắt tỉa và nén phiên

  • Cắt tỉa được áp dụng giống nhau cho tất cả kết quả công cụ ngoại trừ skill, không bảo vệ riêng các tài liệu quan trọng được đọc từ đầu
    • Đọc đặc tả trước trong phiên mới
    • Đọc thêm mã liên quan và vượt ngưỡng 40 nghìn token
    • Mô hình sa vào suy luận không cần thiết hoặc hướng sai, người dùng ngắt
    • Việc ngắt khiến đặc tả bị xóa khỏi ngữ cảnh
    • Mô hình triển khai mà không thể tham chiếu đặc tả ban đầu
  • Nén phiên (compaction) gắn prompt mới vào đầu phiên cũ, prefill lại toàn bộ rồi tóm tắt thành vài gạch đầu dòng
    • Nếu đặt prompt tóm tắt ở cuối phiên thì có thể tránh prefill toàn bộ
    • Cách để mô hình tự viết ghi chú bàn giao vào tệp hoạt động tốt hơn; kết quả cũng có thể được chỉnh sửa hoặc tái sử dụng qua nhiều phiên
  • Nén là một abstraction rò rỉ khiến cửa sổ ngữ cảnh hữu hạn trông như vô hạn, và vấn đề càng lớn khi dùng cùng cắt tỉa
  • Tốt hơn là thừa nhận cửa sổ ngữ cảnh và prompt cache là ràng buộc cơ bản rồi cung cấp phương tiện quản lý; cây phiên của Pi chủ động tận dụng prompt cache

System prompt và chế độ Plan

  • System prompt mặc định rất dài, và một phần đáng kể dùng để yêu cầu mô hình trả lời ngắn gọn
  • Nó cũng chứa những sở thích lập trình mạnh, như buộc sub-agent được dặn ABSOLUTELY NO COMMENTS
  • Quá trình chuyển từ Plan sang Build không mượt, nên nếu làm kế hoạch đủ cụ thể, bạn có thể tiến gần cuối cửa sổ ngữ cảnh
    • Tác giả thích cách ghi kết quả thảo luận ra tệp, chỉnh sửa rồi chuyển sang phiên mới
  • Thông báo của chế độ Plan nói không thể ghi vào bất kỳ thư mục nào, nhưng thực tế có thể ghi vào .opencode/plans
    • Tác giả từng gặp cả hai kiểu lỗi: tự ghi vào thư mục đó dù không được chỉ định, hoặc từ chối ghi dù được yêu cầu rõ ràng
  • Không thể sửa system prompt mặc định ở phạm vi toàn cục, nên phải sao chép cho từng dự án
  • Nếu chỉ định nghĩa lại prompt của chế độ Build, khi chuyển sang chế độ Plan sẽ xảy ra cache miss toàn bộ prompt
  • Prompt theo từng mô hình khác nhau lớn về nội dung và chất lượng
    • Beast Mode cho GPT-4, o1, o3 chỉ thị rằng để hiểu các gói và phụ thuộc bên thứ ba thì bắt buộc phải xác minh bằng Google

Mệt mỏi quyết định do kiểm tra quyền

  • Khi truy cập tệp ngoài dự án được phát hiện bằng phân tích chuỗi tạm bợ, cửa sổ quyền Yes, No, Always hiện lên và dừng thực thi cho tới khi có phản hồi
    • Không có tùy chọn Never để tiếp tục từ chối cùng loại thao tác trong tương lai
  • Khi sub-agent muốn đọc đầu ra script trong /tmp, nếu chọn No thì agent kết thúc và ngữ cảnh tác vụ cũng biến mất
    • Để giữ tiến độ, có lúc buộc phải chọn Yes ngay cả với truy cập bên ngoài không mong muốn
  • Nếu yêu cầu cấp phép lặp lại và lựa chọn duy nhất để giữ năng suất là Yes, người dùng có thể phê duyệt cả yêu cầu nguy hiểm
  • Cơ chế an toàn mặc định nhằm chặn ghi ngoài thư mục không nên phụ thuộc vào sự chú ý liên tục của con người

Tương tác giữa thông điệp và sub-agent

  • Thông điệp gửi trong lúc SSE đang stream được đưa vào hàng đợi, nhưng thời điểm gửi thực tế không rõ ràng
    • Mã có vẻ gửi khi lượt gọi công cụ kết thúc, nhưng tác giả cũng gặp tình huống chuyển từ công cụ sang quá trình suy nghĩ mà không gửi thông điệp đang chờ
    • Nếu người dùng ngắt, thông điệp rời trạng thái chờ, chỉ còn trong log và không thể gửi; cần thông điệp thứ hai để bắt đầu stream mới
  • Có trường hợp undo thông điệp không xóa được thông điệp đó khỏi log
  • Không thể trò chuyện trực tiếp với sub-agent hoặc ngắt tiến trình của nó
    • Nếu nó đi sai hướng, bạn phải kết thúc và mất ngữ cảnh, hoặc nhìn nó tiêu token
    • Có vẻ tính năng này từng tồn tại trước đây nhưng hiện đã biến mất
    • @mention sub-agent trong chat mặc định cũng không hoạt động hữu ích và cũng không thể ngắt
  • Nếu lời gọi công cụ của sub-agent thất bại, giống như khi Qwen đưa lời gọi công cụ vào quá trình suy nghĩ, lỗi nghiêm trọng xảy ra và ngữ cảnh tới thời điểm đó biến mất
  • Tái sử dụng sub-agent xung đột với mục tiêu tách tác vụ thành các ngữ cảnh nhỏ
    • Sub-agent cũ có thể bị tái sử dụng cho tác vụ không liên quan
    • Việc qua lại giữa agent chính có ngữ cảnh lớn và sub-agent gây cache miss
    • Tương tác cho con người có thể phong phú, nhưng lựa chọn cung cấp cho mô hình nên được giảm bớt
  • Cũng có issue GitHub liên quan đến hành vi sub-agent

Thiết kế công cụ cho agent

  • edit mặc định tìm kiếm và thay thế chính xác đoạn văn bản khớp duy nhất
    • Mô hình có thể nhớ chính xác nội dung tệp nhưng sau nhiều lần chỉnh sửa lại dễ bỏ lỡ số dòng đã thay đổi, nên cách này phù hợp
    • Tùy chọn thay thế toàn cục gây ra nhiều chỉnh sửa tiếp theo; nếu bỏ nó thì thiết kế giống edit của Pi
  • Công cụ trắc nghiệm question trong chế độ Plan bất tiện hơn việc để system prompt yêu cầu đặt câu hỏi bằng ngôn ngữ tự nhiên
  • grep và glob có thể được thay bằng bash, và thực tế mô hình cũng chạy grep hoặc rg trong Bash
    • Có thể mục đích là hạn chế các agent chỉ đọc như Explore không được dùng Bash
    • Điều này liên quan tới vấn đề khó xác định tác dụng phụ nếu không thực thi lệnh Bash
  • todo nhìn chung hữu ích, nhưng mô hình lại quên kiểm tra TODO

TUI và chất lượng tài liệu

  • TUI của OpenCode dùng khoảng 1GB RAM để render văn bản
  • Xuống dòng bằng Shift+Enter trong ô nhập thông điệp không hoạt động, và issue trước đó bị đóng sau câu trả lời “máy tôi chạy được”
  • Khi thông điệp dài tự xuống dòng, ô nhập và con trỏ di chuyển nhưng ký tự ở dòng mới có thể không hiển thị
  • Nếu chọn văn bản trong lúc streaming, auto-scroll sẽ bỏ chọn
  • Ctrl-C đóng phiên ngay lập tức thay vì ngắt lệnh đang chạy
    • Theo quy ước shell tương tác, Ctrl-C nên ngắt lệnh, còn Ctrl-D mới kết thúc phiên khi không có lệnh đang chạy
  • Không hỗ trợ các phím tắt di chuyển theo từ phổ biến như Option+mũi tên trái/phải trên Mac
  • Khi thông điệp hoặc quá trình suy nghĩ dài, việc render lại Markdown mất vài giây, có vấn đề hiệu năng trông như độ phức tạp thời gian bậc hai
  • Do vấn đề nhập liệu, tác giả phải soạn thông điệp trong trình soạn thảo ngoài rồi dán vào
  • Tài liệu thiếu nhất quán và gần giống dạng viết cho mô hình đọc hơn là cho con người

Kết nối ưu tiên từ xa và rò rỉ dữ liệu

  • OpenCode mặc định kết nối với mô hình từ xa
  • Tài liệu không có ví dụ đơn giản về cấu hình mô hình cục bộ, và nếu cấu hình sai sẽ kết nối tới mô hình từ xa
  • Ngay cả khi chỉ định đúng mô hình cục bộ, sau khi chạy chương trình vẫn phải chọn tương tác; trong lúc đó mô hình từ xa và shell cục bộ đã được kết nối
  • URL mô hình mặc định không cố định trong bản phân phối mà được tải xuống từ models.dev có liên kết với OpenCode
    • Mã liên quan nằm ở dòng 1684 của opencode/src/provider/provider.ts
  • Sau khi cài mới, chỉ cần chạy opencode, nhập một ký tự và Enter là mô hình từ xa có thể được nối với shell cục bộ mà không cần cấu hình của người dùng
  • Nếu thông điệp đầu tiên trống hoặc mơ hồ, mô hình agent thường glob thư mục hiện tại và đọc tệp; dữ liệu đã đọc sẽ được đưa vào request POST tiếp theo

Truy cập Internet và system prompt

  • OpenCode cung cấp công cụ WebFetch và system prompt chỉ thị rõ ràng hãy dùng nó
  • Prompt mặc định cho phép dùng URL trong thông điệp người dùng hoặc tệp cục bộ, đồng thời cho phép mơ hồ việc tạo hoặc đoán URL nếu chắc rằng đó là URL hỗ trợ lập trình
  • Bash không có sandbox mạng, nên vấn đề lớn hơn WebFetch là kiến trúc kỳ vọng mô hình sẽ không chạy lệnh kiểu curl | bash

Cách vượt qua bộ lọc quyền Bash

  • "bash": {"git *": "deny"} trong opencode.json chặn git status hoặc echo hello && git push --force
  • Cách triển khai dùng grammar Bash/PowerShell của tree-sitter để parse lệnh thành AST, duyệt các node lệnh và so khớp với regex tạo từ cấu hình
  • Tuy nhiên, kiểm tra dựa trên văn bản cho phép nhiều dạng thực thi gián tiếp
    • echo 'git clean -fdx .' | bash
    • env git status
    • alias liên kết git với tên lệnh khác
    • /usr/bin/git status, $(which git) status
    • GIT=git && $GIT status
    • Giải mã git reset --hard mã hóa Base64 rồi chuyển cho Bash
    • git push --force trong heredoc
    • Chạy git checkout . bằng Python subprocess.run
  • Dù mô hình thường không ác ý, vì được huấn luyện để kiên trì vượt qua thất bại, nó có thể tự nhiên hành xử như đầu vào đối kháng
  • Bộ lọc chuỗi lệnh không phải cơ chế an toàn mà chỉ tạo cảm giác yên tâm sai lầm

Quyền vĩnh viễn và ngoại lệ CWD

  • Nếu chọn Always cho python3 -c 'print("hello")', toàn bộ tiền tố python3 được cho phép vĩnh viễn
    • Sau đó, cả lệnh dùng Python để đọc khóa riêng SSH cũng có thể được coi là đã phê duyệt
    • Quyền được lưu trên đĩa và tiếp tục tồn tại ở các phiên sau
  • cd, chdir, popd, pushd, push-location, set-location nằm trong danh sách ngoại lệ CWD giả định là không có tác dụng phụ
  • Các lệnh này chủ động vượt qua kiểm tra quyền ngay cả khi cấu hình từ chối mọi lệnh Bash

Lỗ hổng trong kiểm tra truy cập tệp

  • Cấu hình mặc định cố chặn truy cập tệp ngoài đường dẫn ngắn hơn giữa thư mục chạy OpenCode và Git repository
  • Trong công cụ Bash, OpenCode duyệt tree-sitter AST để diễn giải và kiểm tra các giá trị trông giống đường dẫn
    • cat /tmp/logfile yêu cầu cấp quyền
    • python3 -c 'import shutil; shutil.rmtree("/")' không thể bị kiểm tra
  • cargo tự do đọc, ghi, thực thi trong ~/.cargo toàn cục, nhưng nếu mô hình trực tiếp đọc nguồn package ở ~/.cargo/registry/src thì lại yêu cầu quyền
  • Các lệnh được coi là có thể truy cập tệp bị giới hạn trong danh sách FILES cố định
    • Bao gồm rm, cp, mv, mkdir, touch, chmod, chown, cat và một số lệnh PowerShell
    • Lệnh không có trong danh sách được giả định là không truy cập tệp, nên đường dẫn truyền vào cũng không được kiểm tra

Kết hợp chuyển hướng và lệnh được cho phép

  • Nếu chọn Always cho echo "hello world!", các lần ghi tệp/thiết bị sau này bằng echo cũng được cho phép
    • Cả lệnh chuyển hướng tới đường dẫn /sys/class/gpio liên quan GPIO cũng có thể chạy
  • Trong AST của echo foo > bar.txt, redirection không phải node con của command mà là node anh em
    • Kiểm tra đường dẫn chỉ nhắm vào node con của command, nên không kiểm tra đích chuyển hướng
    • Bản thân echo cũng không nằm trong danh sách FILES, nên xác minh đường dẫn không bắt đầu

Tự nâng cấp và ví dụ thực thi mã từ xa

  • OpenCode có nhiều đường tự nâng cấp; nếu chạy opencode upgrade trên bản cài bằng curl, nó tải phản hồi từ https://opencode.ai/install rồi thực thi qua stdin của Bash
  • Việc này không khác nhiều rủi ro tại thời điểm dùng trình cài đặt curl, nhưng là một ví dụ thực tế về chạy trực tiếp script từ xa trong production
  • Vào thời điểm CVE-2026-22812, OpenCode để lộ các chức năng sau trên HTTP server mặc định
    • Header CORS hoàn toàn cho phép
    • API POST thực thi lệnh shell tùy ý
    • API GET đọc tệp tùy ý
  • Website người dùng truy cập có thể gửi request tới cổng mặc định đã biết và có quyền truy cập hệ thống ở mức quyền của người dùng
  • Nhóm phát triển đã tắt server theo mặc định, trả lời rằng cần ngoại lệ CORS để opencode.ai có thể chạy mã từ xa trên máy, rồi không tiếp tục xử lý; issue bị stale bot đóng
  • Một issue riêng báo cáo rằng lệnh xác thực lấy nội dung từ URL tùy ý do người dùng truyền vào rồi thực thi, và issue này cũng bị đóng bởi stale bot

Vì sao chỉ Docker không giải quyết được

  • Tác giả không muốn một cách tiếp cận làm phụ thuộc phát triển phức tạp tới mức khó cài trên máy mới rồi dựa vào Docker
  • Bản thân Docker cũng có thể tạo vấn đề bảo mật
    • Tạo ra một dịch vụ quyền lực chạy dưới root
    • Cố ý mở đường qua firewall ufw
  • Nếu mọi dữ liệu cần bảo vệ đều nằm trong container và shell cục bộ bên trong lại kết nối Internet, phạm vi bảo vệ trở nên không rõ ràng
  • Nếu mục tiêu là ngăn xóa đệ quy root filesystem, có thể dùng các cơ chế hệ điều hành trực tiếp hơn như Landlock, Seatbelt, Restricted Tokens
  • Bảo mật của agent lập trình không nên là vấn đề đẩy trách nhiệm sang container riêng, mà phải là ưu tiên hàng đầu của harness
    • Chặn Git phải chặn chính tệp thực thi git, không phải chuỗi lệnh
    • Thư mục .git phải được đặt chỉ đọc
    • Thay vì “tẩy rửa” lệnh Bash dưới dạng văn bản, phải dùng cách ly hệ điều hành native

Trải nghiệm dùng LLM cục bộ

  • Các mô hình cục bộ như Qwen3.6-27B cũng có thể phá hoại tính ổn định và nhất quán khái niệm của codebase như frontier model, nhưng có ba khác biệt
    • Ít rơi vào “uncanny valley” kiểu trông thông minh rồi hành xử ngớ ngẩn; giới hạn rõ ràng nên dễ điều chỉnh tương tác
    • Số trọng số quá ít để tái hiện nguyên xi dữ liệu huấn luyện, nên cách đánh giá nguy cơ ô nhiễm đầu ra khác đi
    • Không cần hỗ trợ hoặc phụ thuộc nhà cung cấp cloud
  • Với các tác vụ tìm kiếm dựa nhiều vào đầu vào, trong đó cung cấp mã, triệu chứng, nguyên nhân nghi ngờ, yêu cầu đọc mã liên quan rồi yêu cầu đường gọi và trích dẫn mã, tác giả nhận được kết quả hữu ích
    • Khi giới hạn thành bài toán tìm kiếm, có thể giảm xu hướng bịa đặt sự thật của mô hình
  • Sinh mã liên tục làm sụp đổ kế hoạch kiến trúc
    • Nó chọn lối tắt như chuyển trạng thái mutable vào giữa thiết kế để nhiều thành phần dùng chung
    • Vấn đề không chỉ là “không tự tay viết”, mà còn làm hại chính khả năng hiểu mã
  • Cách lấy câu trả lời trực tiếp từ kiến thức trong trọng số mô hình gây ảo giác ngay cả với mô hình hàng nghìn tỷ tham số
  • Để LLM trở thành công cụ bình thường, phần mềm xung quanh nó cần được áp dụng kỹ thuật hệ thống thực sự để loại bỏ khoảng trống bảo mật, và việc đó phải do con người làm

Bài viết liên quan

1 bình luận

 
GN⁺ 14 giờ trước
Ý kiến trên Hacker News

  • Tiêu đề phù hợp hơn cho bài này có lẽ là “Những bất tiện nhỏ mà nếu sửa sẽ giúp OpenCode tốt hơn”
    Việc phải đọc lại AGENTS.md mỗi lần, hoặc bị miss cache prompt do đổi ngày, là điều có thể chấp nhận được
    Vấn đề nén và cắt tỉa không hoạt động đúng thì tôi cũng đã thấy ở Codex và Claude; prompt hệ thống mặc định cũng là để đảm bảo tính nhất quán, nên nếu không thích thì có thể đổi

    • Giờ codebase đã phình to nghiêm trọng vì các tính năng được thêm bằng vibe coding, và nó gặp đúng vấn đề như Claude Code
      Độ ổn định, hiệu năng và mức dùng bộ nhớ đều tệ đi; trước đây tôi thích OpenCode, nhưng khó có thể gọi đây là phần mềm được viết tốt
      Hiện tôi đã thay thế hoàn toàn bằng Pi, và cũng có khá nhiều lựa chọn mới học từ OpenCode rồi áp dụng thiết kế tiết chế hơn ở những chỗ cần thiết
    • Tôi đang làm việc ở OpenCode
      Giờ chúng tôi không cắt tỉa lệnh gọi công cụ nữa, nhưng để tiếp tục cùng một tác vụ trong thời gian dài với cửa sổ ngữ cảnh hữu hạn, vẫn phải tóm tắt tiến độ hiện tại, nên nén trước mắt là một điều xấu cần thiết
      V2 hiện đang beta có một cách mới để giữ các chỉ thị hệ thống thay đổi như AGENTS.md, các công nghệ có thể dùng, v.v. luôn cập nhật, đồng thời tránh miss cache tối đa
      https://x.com/kitlangton/status/2075749116760457346/video/1
    • Những nội dung đó được xếp vào “Những điều gây khó chịu”, nên cũng nên đọc phần “Những điều đáng báo động”
    • Những gì đang nói tới là các mục trong phần “Những điều gây khó chịu” của bài
      Phần riêng “Những điều đáng báo động” còn có tiểu mục “Nó đầy rẫy RCE chết tiệt”, và ngoài những lỗ hổng phát sinh từ các vấn đề đã lộ ra ở phần trước, còn có nhiều lỗ hổng thực thi mã từ xa khác
    • Hóa ra đó là lý do OpenCode xóa ngẫu nhiên các comment trong mã của tôi

  • Bài viết tóm tắt khá tốt rủi ro của CLI dạng agent, nhưng tiêu đề chỉ tập trung vào OpenCode thì kỳ lạ vì hai lý do
    Thứ nhất, nó không đề xuất một giải pháp thay thế rõ ràng. Nhiều vấn đề mang tính nền tảng đến mức có thể phải thiết kế lại và viết lại gần như từ đầu, nên chỉ đưa ra bản sửa cho OpenCode cũng chưa đủ; nhưng vì hoàn toàn không có đề xuất mang tính xây dựng nào, bài viết gần như giống lời kêu gọi “ngừng dùng LLM”
    Thứ hai, các vấn đề chính trong phần “Những điều đáng báo động” không chỉ riêng OpenCode, mà cũng áp dụng cho Claude CLI và có lẽ cho agent của các nhà cung cấp mô hình tiên tiến khác
    Dù vậy, với tư cách một bản ghi thúc giục xây dựng công cụ tốt hơn từ đầu, nó rất có giá trị nên tôi sẽ bookmark và chia sẻ rộng rãi; nhưng vì phần nội dung rất hay, tiêu đề và trọng tâm lại càng có cảm giác bị đặt sai

    • Tôi tò mò không biết họ nghĩ có thể vừa cho phép truy cập shell vừa chặn an toàn việc thực thi lệnh tùy ý bằng cách nào
      Đặc biệt, lời phàn nàn rằng echo git | bash vẫn chạy được nghe thật vô lý

  • Câu “Nếu bạn không biết OpenCode, hãy tưởng tượng một chiếc ủng giẫm mãi lên khuôn mặt con người. Chiếc ủng được làm bằng TypeScript, còn khuôn mặt là tất cả những gì chúng ta đã học được về bảo mật và phần mềm hệ thống kể từ khi máy tính điện tử được phát minh vào thập niên 1940” xứng đáng là ứng viên giải Bulwer-Lytton ở hạng mục ẩn dụ gượng ép

    • Ẩn dụ này lấy từ câu trong 1984 của George Orwell: “Nếu bạn muốn hình dung tương lai, hãy tưởng tượng một chiếc ủng giẫm mãi lên khuôn mặt con người”

  • Văn phong của bài quá giận dữ và khắc nghiệt
    Tôi nhìn chung đồng ý với nhiều luận điểm, nhưng đến đoạn gọi OpenCode là “một xe hề rác rưởi tăng áp với tư thế bảo mật kiểu ‘bố ơi, con sẽ cúi xuống cho bố’” và bảo mọi người ngừng dùng nó, tôi không còn muốn đọc nữa
    Phần mềm này cũng do những người bình thường làm ra; tôi không biết từ khi nào việc tấn công mã nguồn mở theo kiểu này lại trở thành chuyện hiển nhiên, và nó khiến tôi nghĩ nếu phần mềm mình làm bị đánh giá như vậy thì sẽ ra sao

    • Tôi đồng ý với cảm xúc này, nhưng văn hóa như vậy đã có ít nhất từ thập niên 1990
      Ngày trước trên comp.lang.lisp cũng có những người thích hạ thấp người viết mã không đạt chuẩn tháp ngà; có người đã bỏ đi, có người nhầm đó là lời quở trách cần thiết để nâng trình và xem như huy chương
      Một thảo luận HN cũ liên quan: https://news.ycombinator.com/item?id=587045
    • Ngày nay, việc gọi thứ gì đó là “được vibe coding” được dùng như một giấy phép để phóng đại và xúc phạm, với giả định rằng không có ai bị công kích
      Có vẻ họ không hiểu kiểu tu từ này gây hại thế nào cho các lập trình viên bị vạ lây, cũng như cho chính những người đang bình thường hóa hành vi đó
    • Đoạn “Người hiểu rõ cấu trúc bên trong OpenCode—tôi sẽ giả định rằng đội phát triển OpenCode không nằm trong số này—có thể đã phản đối ví dụ python3 ở trên” thì khá buồn cười
    • Ngay cả nếu bạn từng đóng góp cho OpenCode, nếu có khiếu hài hước thì chắc cũng sẽ cười, nên không cần quá nghiêm trọng hóa mọi thứ
    • Ngay cả hiện nay đó cũng không phải cách diễn đạt bình thường, nhưng cũng chẳng mới; kiểu ngôn ngữ này đã tồn tại từ lâu

  • Vì stack công nghệ của khách hàng nên tôi dùng Claude Code, còn việc cá nhân thì dùng một phiên bản OpenCode nhất định; OpenCode tốt hơn hẳn nên bài này khiến tôi thấy buồn
    Tất cả những hiện tượng kỳ lạ mà trước giờ tôi thấy nhưng bỏ qua đều khớp với bài viết, thậm chí còn giải thích được nguyên nhân. Trừ những chỗ diễn đạt quá đà và những phần tôi không đồng tình về mặt cảm xúc, nhìn chung bài nói đúng, nên có lẽ tôi phải tìm công cụ thực thi khác
    Tôi muốn được gợi ý liệu kiến trúc của Pi có thực sự tốt hơn không, hoặc có lựa chọn thay thế nào tốt hơn không

  • Bất kể các lỗi, sau khi dùng thử nhiều công cụ, tôi vẫn đạt năng suất cao nhất với OpenCode
    Phần lớn những gì trong bài chỉ là các bất tiện nhỏ hoặc khác biệt quan điểm; đặc biệt là tác giả hiểu sai căn bản mục đích của việc lọc lệnh. Nó không phải cơ chế bảo mật, mà là cơ chế dẫn hướng hành vi của mô hình
    Có vẻ tác giả chưa thật sự dùng OpenCode để tạo ra thứ gì; nếu có dùng, họ hoàn toàn không bàn đến điều quan trọng nhất là chất lượng đầu ra

    • Tôi cũng cảm thấy OpenCode có sự cân bằng phù hợp, không cản trở nhưng cũng không làm hỏng máy tính
      Đặc biệt, có thể dễ dàng dùng chế độ lập kế hoạch để hoàn thành công việc nhanh chóng

  • Sau khi chuyển từ OpenCode sang Pi, hiệu năng gọi công cụ cải thiện đáng kể và cũng cảm thấy ít lỗi hơn
    OpenCode dường như cũng đã biến mất khỏi https://openrouter.ai/apps/category/coding

    • Phía OpenCode đã yêu cầu được gỡ khỏi bảng xếp hạng OpenRouter: https://github.com/anomalyco/opencode/issues/11926#issuecomm...
    • Điều này không hẳn vì OpenCode tệ, mà vì Pi tốt. So sánh Claude với Pi cũng có thể nói như vậy
    • Một trong những ưu điểm của OpenCode là tích hợp LSP, nên tôi tò mò Pi xử lý việc này thế nào
    • Gần đây tôi đã dùng thử OpenCode và Pi; từ góc nhìn của người chuyển từ Claude Code sang, tôi ngạc nhiên vì cả hai có vẻ mặc định cho phép chỉnh sửa mà không có hộp thoại xác nhận
      Theo trí nhớ thì một cái có thể bật xác nhận trong cài đặt, còn cái kia cần plugin
    • Tôi đã xóa hẳn OpenCode khi thấy nó tải các gói npm ở nền mà không hỏi người dùng
      Hành vi này làm tăng thêm rủi ro tấn công chuỗi cung ứng

  • Một ứng dụng desktop TUI chỉ hiển thị văn bản mà lại nặng hơn cả ứng dụng native, thậm chí nặng hơn phần lớn ứng dụng desktop nền trình duyệt, là điều vô lý; nó lãng phí RAM, CPU, năng lượng và pin
    Tôi đang phát triển một công cụ chạy AI kiêm ứng dụng chat bằng C++ Qt6; dù có sub-agent, diff mã, trình giả lập terminal, trình chỉnh sửa đơn giản, xem trước Markdown, nền bán trong suốt, theme người dùng, quyền, MCP, tích hợp Git, hệ thống docking và cả tab dự án, nó vẫn nhẹ hơn các công cụ khác
    Hiện vẫn đang sửa vài lỗi, đơn giản hóa UI và hoàn thiện nên chưa công bố: https://zeteo.krysoph.com/preview.html

  • Giờ tôi mới biết lý do OpenCode xóa chú thích là vì prompt hệ thống mặc định có câu “Use ABSOLUTELY NO COMMENTS”, và điều đó rất khó chịu
    Tuy nhiên, đây không chỉ là bất tiện nhỏ; rủi ro bảo mật cũng áp dụng cho các công cụ chạy khác. Những công cụ này truy cập lượng dữ liệu khổng lồ, được cập nhật gần như mỗi ngày, và do đặc tính được “vibe code” nên có khả năng không ai kiểm toán đúng mức vô số phụ thuộc npm mà chúng kéo về
    Chỉ cần một sự cố như left-pad xảy ra một lần là có thể thành thảm họa cho toàn bộ chuỗi cung ứng

  • Đưa ngày vào prompt hệ thống để cache bị vô hiệu hóa lúc nửa đêm là một quyết định hợp lý, và hầu hết các công cụ chạy khác cũng dùng cách tương tự
    Nếu đưa cả ngày giờ đầy đủ vào thì sẽ là vô trách nhiệm, nhưng OpenCode không làm vậy

    • Khi đang dùng lúc nửa đêm và phải chờ 10 phút để nạp lại KV cache trên GPU cục bộ thì chuyện đó không còn thấy hợp lý nữa
      Có thể giải quyết đơn giản bằng cách chỉ đánh giá ngày một lần cho mỗi phiên, hoặc một lần mỗi khi chạy binary opencode để tránh các phiên chạy lâu bị kẹt ở ngày trong quá khứ