Framein - Không phải cockpit, proxy hay harness, mà là lớp trạng thái công việc nằm bên dưới AI coding agent
(framein.dev)Dạo này tôi làm hầu hết công việc lập trình cùng với các terminal agent. Tôi mở song song Claude Code, Codex và Gemini CLI trong VS Code, giao phần triển khai cơ bản cho Claude, rồi khi cần một góc nhìn bên ngoài cho những việc như bảo mật hay hồi quy thì nhờ Codex rà soát. Vì thế, mỗi lần đổi model tôi lại phải giải thích lại từ đầu mục tiêu là gì, điều gì không được phép làm hỏng, và model ngay trước đó đã thử gì rồi thất bại ra sao. Cuối cùng tôi nhận ra mình đang trở thành một cái clipboard sống nối giữa ba terminal.
Khi tìm các công cụ tương tự, tôi thấy đã có khá nhiều. Từ cockpit gom nhiều agent trong một cửa sổ (như Claude Squad, Orch term), đến proxy cho phép gọi model khác từ một harness duy nhất (như opencodex, oh-my-free-models), rồi cả orchestrator chia vai trò để phân phối công việc (như Oh My OpenCode). Nhưng vấn đề tôi thực sự gặp phải — làm sao để dù đổi model thì chính công việc vẫn không bị đứt mạch — lại có surprisingly ít công cụ xử lý trực diện. Phần lớn đều đi theo hướng “làm handoff tốt hơn”.
Thay vì làm handoff tốt hơn, Framein chọn cách khiến handoff không còn là thứ cần đến nữa. Nó không phải IDE mới, không phải cockpit, không phải proxy, cũng không phải thêm một harness nữa. Đây là một lớp trạng thái công việc (work-state) cục bộ, mỏng, nằm bên dưới các agent bạn đang dùng. Vì ba agent cùng đọc chung hợp đồng công việc, lịch sử quyết định và kết quả xác minh trong repo, nên bản thân hành động “bàn giao” không còn là một bước riêng biệt. Model tiếp theo không đọc những gì tôi đã tóm tắt lại, mà đọc trực tiếp chính các sự kiện đó.
Vòng lặp gồm bốn động từ. Ở đây, “lead” chỉ model hiện đang trực tiếp đảm nhận việc triển khai. Cách gọi này dùng để phân biệt với model phụ trách review.
- start : cố định yêu cầu thành một hợp đồng công việc (mục tiêu, điều kiện chấp nhận, vùng cần bảo vệ, non-goal) trước khi việc triển khai bắt đầu chệch hướng.
- challenge : yêu cầu một model khác đưa ra phản biện có phạm vi hẹp, để lead chỉ phản hồi đúng một lần rồi tôi là người đưa ra quyết định. Đây là chỗ để, khi một model tự tin nói rằng “tôi đã hoàn thành toàn bộ triển khai”, một model khác đọc cùng hợp đồng và diff có thể hỏi rằng “rủi ro nào đã bị bỏ sót trong kế hoạch này?”.
- capsule : chuẩn bị các sự kiện để lead tiếp theo đọc được (hợp đồng, diff, xác minh, ADR, ledger).
- ship : không đóng công việc bằng việc model nói “xong rồi”, mà bằng cách cho nó đi qua build/test/risk gate thực tế.
Có thể gọi trực tiếp từ terminal, hoặc trong Claude/Gemini bằng lệnh slash /fr:*, còn trong Codex bằng skill $fr-*. Dù gọi từ phía nào thì chúng đều đọc và ghi vào cùng một local engine và cùng một trạng thái. Bạn vẫn giữ nguyên harness, skill pack và persona đang dùng; cấu trúc này chỉ đặt thêm lớp hợp đồng, sổ cái và gate ở phía dưới.
Đây là những điểm tôi đặc biệt chú ý trong thiết kế.
- Nhật ký quyết định (ADR) là append-only. Không sửa hay xóa, chỉ thay thế bằng bản ghi mới. Tôi cho rằng một bản ghi quyết định có thể bị lặng lẽ chỉnh sửa sẽ mất giá trị ngay từ khoảnh khắc model thứ hai tin vào nó.
- Không thu thập credential. Không relay token, không pooling subscription, cũng không scraping I/O của terminal. Việc xác thực vẫn do từng CLI chính thức giữ nguyên, và khi cần thì chỉ gọi cục bộ. (Vì thế nó nằm ở một tầng khác với nhóm proxy.)
- Runtime dependency bằng 0. Chỉ dùng
node:sqlitetích hợp sẵn của Node 22 và test runner tích hợp sẵn. SQLite store là cache, còn nguồn chuẩn là các JSON snapshot thân thiện với git, nên sẽ không có chuyện nửa năm sau cài đặt bị hỏng vì dependency thay đổi.
Hiện tại đang ở giai đoạn pre-release v0.0.6, và phần core (store, projection CLAUDE.md/AGENTS.md/GEMINI.md, hợp đồng công việc, các gate verify/risk/ship, wrapper /fr:*·$fr-*, MCP server) đã được triển khai, đồng thời đã vượt qua 249 bài test. Những phần vẫn đang được hoàn thiện là quy trình code signing trên Windows, phân phối file thực thi đã ký/chứng thực, xác minh cài đặt trên máy sạch, và workflow cho nhiều developer.
Có thể cài bằng npm install -g framein (cần Node 22.5+), và dùng giấy phép MIT. Tên gọi được lấy từ thuật ngữ điện ảnh. Khi chủ thể biến mất khỏi khung hình thì gọi là frame-out, còn đưa nó trở lại trong khung hình là frame-in. Tôi đặt tên như vậy với ý nghĩa đưa ba agent đang phân tán vào trong cùng một khung hình.
Ngay cả khi bạn đã dùng cockpit, proxy hay harness, nếu vẫn có cảm giác trạng thái công việc cứ bị rò rỉ ở tầng bên dưới, hoặc nếu bạn đang làm việc qua lại giữa từ hai coding agent trở lên, tôi rất muốn nhận được phản hồi xem Framein có lấp được khoảng trống đó hay không.
Trang web : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Ghi chú của nhà phát triển (vì sao làm ra nó) : https://www.framein.dev/ko/why
Chưa có bình luận nào.