An open-source spec for Codex orchestration: Symphony

OpenAI · 2026 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc

Bài của nhà phát triển Codex kể công cụ nội bộ của chính mình rồi mở mã nguồn; số liệu do OpenAI tự báo, mọi nhận định là theo OpenAI.

Bối cảnh

• Sáu tháng trước bài này, một team ở OpenAI quyết định repo của một công cụ nội bộ không có dòng code nào do người viết, mọi thứ do Codex sinh ra; họ dựng repo thân thiện với agent, đầu tư mạnh vào test tự động và guardrail.
• Nút thắt tiếp theo là sự chú ý của người: mỗi engineer mở vài phiên Codex, giao việc, review, chỉnh hướng; quá ba tới năm phiên thì chuyển ngữ cảnh làm năng suất tụt, quên phiên nào làm gì, phải nhảy giữa terminal để đẩy agent đi tiếp, gỡ việc dài bị kẹt giữa chừng.

Thay đổi chính

• Lấy issue tracker làm control plane: Symphony theo dõi board Linear; mỗi issue đang mở ứng với một workspace agent riêng; mỗi task đang hoạt động luôn có một agent chạy tới khi xong; agent sập hay kẹt thì Symphony khởi động lại. Trạng thái ticket là máy trạng thái của workflow (tới Merging là gần chắc vào được nhánh chính).
• Việc tách khỏi phiên và khỏi PR: một issue có thể ra nhiều PR qua nhiều repo, hoặc chỉ là điều tra không đụng code. Việc lớn: agent đọc codebase, Slack, Notion để viết kế hoạch; người duyệt kế hoạch; agent sinh cây task có phụ thuộc, và chỉ task không bị chặn mới được làm (nâng React chỉ bắt đầu sau khi chuyển sang Vite xong). Agent tự tạo issue mới cho việc ngoài phạm vi mà nó thấy (hiệu năng, refactor), người xem rồi xếp lịch.
• Chặng cuối của PR trong monorepo: Symphony theo dõi CI, rebase, giải conflict, chạy lại check flaky.
• Kết quả, theo OpenAI: số PR được merge ở vài team tăng 500% trong ba tuần đầu; product manager và designer tự tạo yêu cầu tính năng và nhận lại gói review kèm video chạy tính năng trong sản phẩm thật; việc thăm dò rẻ tới mức tạo ticket thử rồi bỏ là bình thường.
• Đánh đổi: giao ở mức ticket thì mất khả năng chỉnh agent giữa chừng; khi kết quả lệch hẳn, team không sửa tay mà thêm guardrail và skill (chạy test e2e, điều khiển app qua Chrome DevTools, smoke test QA), viết lại tài liệu cho rõ "thế nào là tốt". Việc mơ hồ, cần phán đoán vẫn làm bằng phiên tương tác.
• Mục tiêu thay vì chuyển trạng thái cứng: bản đầu chỉ bảo agent "implement task"; sau cho agent công cụ (gh, đọc log CI) và giao mục tiêu (đóng PR cũ, báo cáo việc xong và việc bỏ).
• Chính Symphony: bản đầu là một phiên Codex trong tmux poll Linear và sinh sub-agent, không ổn định; bản hai nằm trong repo chính đã có harness; bản mở mã nguồn là một file SPEC.md cộng bản tham chiếu bằng Elixir (chọn vì nguyên thuỷ giám sát tiến trình đồng thời), do Codex viết; Codex được nhờ implement spec bằng TypeScript, Go, Rust, Java, Python để tìm chỗ mơ hồ. Quy trình làm việc trước đây người làm theo mà không viết ra nay nằm trong WORKFLOW.md. Nói chuyện với Codex qua App Server (JSON-RPC, chế độ headless); token Linear không lộ cho sub-agent nhờ dynamic tool call linear_graphql thay vì đưa token vào container.

Vì sao

• Theo OpenAI, phiên và PR chỉ là phương tiện; công việc vốn được tổ chức theo đầu việc (issue, milestone), nên đặt điều phối ở đó thì người không phải giám sát từng phiên.

Bài học cho SWE

• Khi máy làm nhanh, nút thắt dời sang sự chú ý của người; thiết kế lại để người duyệt kết quả theo đầu việc thay vì cầm lái từng phiên.
• Một vòng điều khiển "mỗi việc mở luôn có một tác nhân đang chạy" (như reconcile của Kubernetes) đơn giản hơn một hệ giám sát phức tạp.
• Thất bại của agent là tín hiệu thiếu guardrail hoặc tài liệu; sửa hệ chứ không sửa tay kết quả.
• Quy trình ngầm của team cần được viết ra để agent theo được; lợi phụ là người mới cũng theo được.
• Giữ bí mật ngoài môi trường của agent: cho agent một công cụ đã có quyền, không đưa token.

Liên quan

• Coding agent trong engineering (migrate, viết lại, chạy song song, quyền hạn)
• Cùng công ty: OpenAI 2021 · OpenAI 2024
• Cùng bài toán: Coinbase 2026 (chạy nhiều agent song song) · Spotify 2026 (PR tăng, review thành nút thắt) · GitHub 2026