Hầu hết các nhà phát triển ban đầu sử dụng tác nhân viết mã để viết code: kiểm tra kho lưu trữ, tạo một bản diff, chạy thử nghiệm và mở một pull request.
Đó vẫn là trọng tâm của Codex. Nhưng phần lớn công việc trên máy tính đã được trung gian hóa qua code: thực thi các lệnh shell, duyệt các trang web, gọi API, xuất tài liệu, phản hồi các sự kiện và kích hoạt tự động hóa. Khi những bề mặt đó trở nên khả dụng đối với Codex, nó bắt đầu cảm thấy ít giống một trợ lý viết mã theo nghĩa hẹp và giống một hệ thống hoàn thành công việc trên máy tính hơn.
Ứng dụng Codex biến sự thay đổi đó thành hiện thực. Một luồng (thread) có thể giữ ngữ cảnh, sử dụng công cụ, hiển thị các tạo phẩm (artifact) và tiếp tục qua các lời nhắc thay vì phải đặt lại sau mỗi lần trao đổi.
Để tận dụng tối đa Codex, bạn cần kết hợp các khả năng này với nhau:
- các luồng bền vững (durable threads) lưu giữ ngữ cảnh
- đầu vào bằng giọng nói (voice), định hướng (steering) và xếp hàng (queuing) trong khi người dùng vẫn tham gia
- trình duyệt, sử dụng máy tính, máy chủ MCP và các bộ kết nối (connectors) cho phép Codex hoạt động vượt ra ngoài một kho lưu trữ
- tự động hóa luồng (thread automations) và Mục tiêu (Goals) tiếp tục công việc khi người dùng rời đi
- bảng điều khiển phụ (side panel), nơi người dùng có thể xem lại code, tài liệu, bài thuyết trình và các tạo phẩm khác
Các luồng bền vững (Durable threads)
Các luồng bền vững:
Các luồng Codex chạy dài, bảo toàn ngữ cảnh làm việc qua nhiều phiên làm việc liên tiếp.
Các luồng được ghim (pinned threads) là một cách để luôn có sẵn các luồng bền vững trong tầm tay. Chúng hữu ích cho các luồng công việc định kỳ như:
- một luồng "Thư ký trưởng" (Chief of Staff)
- một luồng phát hành (release)
- một luồng xem xét tài liệu
- một luồng dành riêng cho giám sát bên ngoài
Đây là những không gian làm việc cố định (persistent workspaces), không phải các cuộc trò chuyện ngắn. Codex có thể quay lại chúng theo thời gian, lưu giữ các quyết định, ưu tiên và bối cảnh làm việc đã có trước đó, những thứ mà nếu không sẽ phải xây dựng lại từ đầu.
Các phím tắt đến luồng đã ghim làm cho điều này trở nên thiết thực. Command-1 đến Command-9 nhảy trực tiếp vào các luồng đã lưu.
Đầu vào bằng giọng nói (Voice input)
Đầu vào bằng giọng nói có giá trị vì nó nắm bắt được phiên bản thô của một ý nghĩ trước khi nó được nén thành văn xuôi trau chuốt.
Codex có đầu vào bằng giọng nói tích hợp sẵn. Nó hoạt động đặc biệt tốt cho những điểm khởi đầu mơ hồ (vague starting points) thường dễ nói nhưng khó gõ:
Tôi nghĩ ai đó tên Ben đã đề cập điều này trong Slack.
Tôi không nhớ chi tiết.
Vui lòng đi tìm.
Đối với một tác nhân có thể tìm kiếm, thu thập ngữ cảnh và báo cáo lại, điều đó thường là đủ.
Nó cũng hoạt động tốt khi bạn có một luồng suy nghĩ dài hai hoặc ba phút (thought dump) trước khi nhiệm vụ được hình thành đầy đủ.
Bản ghi âm (Transcripts) cũng hoạt động theo cách tương tự. Một bản ghi cuộc họp thô hoặc ghi chú kế hoạch được đọc chính tả thường cung cấp nguồn tài liệu tốt hơn một bản tóm tắt ngắn vì nó bảo tồn được sự không chắc chắn, sự nhấn mạnh và các dòng suy nghĩ chưa hoàn thiện.
Định hướng (Steering) và xếp hàng (Queuing)
Giọng nói thậm chí còn hữu ích hơn khi kết hợp với khả năng kiểm soát rõ ràng đối với một tác vụ đang hoạt động.
Định hướng:
Làm gián đoạn một tác vụ Codex đang thực hiện với hướng dẫn mới trước khi bước hiện tại kết thúc.
Định hướng hữu ích khi tác nhân đang đi sai hướng và cần được chỉnh sửa trước khi nó hoàn thành. Ví dụ, trong quá trình xem xét một trang web, người dùng có thể làm gián đoạn công việc trong khi chú thích bề mặt đó trên bảng điều khiển phụ:
- làm cái này nhỏ hơn
- khoảng cách giữa hai phần tử này có vẻ không ổn
- đoạn copy này sai
Xếp hàng:
Thêm công việc để Codex thực hiện sau khi bước hiện tại hoàn thành.
Xếp hàng thì khác. Nó không làm gián đoạn tác vụ đang tiến hành. Nó thêm tác vụ tiếp theo vào hàng đợi. Người dùng có thể nói:
Khi công việc hoàn tất, hãy gửi liên kết xem trước cho người đánh giá trên Slack.
Định hướng thay đổi những gì Codex đang làm ngay bây giờ. Xếp hàng thay đổi những gì sẽ xảy ra tiếp theo. Cả hai đều giữ người dùng gần gũi với công việc trong khi nó đang diễn ra.
Công cụ và phạm vi tiếp cận
Khi một luồng đã có tính liên tục, câu hỏi tiếp theo là nó có thể tác động lên những gì. Codex có thể mở rộng ra ngoài theo từng lớp:
- $browser cho trình duyệt trong ứng dụng ở bảng điều khiển phụ, nơi Codex có thể kiểm tra và chú thích các bề mặt web
- @chrome cho trạng thái trình duyệt đã đăng nhập và các quy trình làm việc dựa trên Chrome
- @computer cho công việc chỉ tồn tại thông qua giao diện đồ họa trên máy tính để bàn
$browser phù hợp với việc xem xét trình duyệt trên bảng điều khiển phụ. @chrome phù hợp với công việc trình duyệt đã đăng nhập phụ thuộc vào ngữ cảnh Chrome của người dùng. @computer phù hợp với các tác vụ chỉ tồn tại thông qua giao diện đồ họa trên máy tính để bàn.
Các máy chủ MCP và bộ kết nối mở rộng cùng một ý tưởng vào phần còn lại của quy trình làm việc. Slack, Gmail và Lịch (Calendar) quan trọng vì nhiều tác vụ quan trọng xuất hiện đầu tiên dưới dạng tin nhắn, mục trong hộp thư đến hoặc vấn đề về lịch trình trước khi chúng trở thành code.
Kỹ năng (Skills) làm cho các quy trình làm việc lặp đi lặp lại có thể tái sử dụng. Khi một quy trình làm việc tỏ ra hữu ích, hãy đóng gói nó thành một kỹ năng để Codex có thể chạy lại nó mà không cần học lại quy trình từ đầu.
Làm việc từ mọi nơi
Ứng dụng Codex trên thiết bị di động thay đổi thời điểm người dùng phải ngồi tại bàn làm việc. Một tác vụ có thể bắt đầu trên máy Mac nơi các tệp, quyền và thiết lập cục bộ đã tồn tại, sau đó tiếp tục trong khi người dùng kiểm tra từ điện thoại.
Điều đó quan trọng trong những khoảnh khắc nhỏ. Ai đó có thể rời khỏi bàn làm việc trong khi Codex chạy một tác vụ dài hơn, trả lời một câu hỏi từ bên ngoài, phê duyệt bước tiếp theo hoặc chuyển hướng luồng trước khi họ quay lại. Môi trường cục bộ vẫn được giữ nguyên; người dùng không cần phải ở đó.
Tự động hóa (Automations)
Tự động hóa chạy công việc của Codex theo một lịch trình. Sử dụng tự động hóa theo lịch trình (scheduled automation) khi công việc định kỳ cần bắt đầu lại từ đầu từ một không gian làm việc, chẳng hạn như một báo cáo hàng ngày hoặc một kiểm tra kho lưu trữ thường xuyên. Sử dụng tự động hóa luồng (thread automation) khi lịch trình cần quay lại một cuộc trò chuyện đang hoạt động với ngữ cảnh đang chạy của nó.
Tự động hóa luồng:
Các lời gọi đánh thức định kỳ kiểu nhịp tim (heartbeat-style) quay lại cùng một luồng Codex theo một lịch trình.
Các luồng được ghim rất hữu ích, nhưng chúng vẫn chờ người dùng quay lại. Một tự động hóa luồng có thể kiểm tra điều gì đó vài phút một lần hoặc vài giờ một lần, tiếp tục cho đến khi đáp ứng được một điều kiện và điều chỉnh nhịp độ theo thời gian.
Một luồng "Thư ký trưởng" có thể chạy 30 phút một lần:
Cứ 30 phút một lần, hãy kiểm tra Slack và Gmail để tìm các tin nhắn chưa trả lời cần tôi chú ý.
Hãy giúp tôi ưu tiên những gì quan trọng nhất.
Nếu ai đó hỏi tôi một câu hỏi, hãy nghiên cứu câu trả lời một cách sâu sắc nhất có thể và soạn thảo một câu trả lời cho tôi, nhưng đừng gửi nó.
Khi người dùng quay lại, phần tốn kém nhất của việc thu thập ngữ cảnh thường đã được hoàn thành. Người vẫn quyết định những gì được gửi đi.
Tự động hóa luồng cũng phù hợp với các vòng phản hồi. Một tự động hóa luồng có thể theo dõi các bình luận trên pull request, bình luận trong Google Docs hoặc trả lời trên Slack và giữ cho công việc xung quanh tiếp tục tiến triển trong khi người dùng vắng mặt.
Hãy xem xét một quy trình làm việc về hoạt ảnh (animation) nơi người đánh giá chia sẻ một video trong Slack. Một tự động hóa luồng có thể kiểm tra luồng theo lịch trình, kết xuất một phiên bản cập nhật khi có bình luận và trả lời trong cùng một luồng, gắn thẻ người đánh giá. Nếu một tích hợp không thể hoàn tất việc tải lên cuối cùng, tự động hóa trên máy tính để bàn (desktop automation) có thể hoàn thành bước đó thông qua giao diện đồ họa.
Vòng lặp này bao gồm Slack cho phản hồi, kho mã nguồn cho việc kết xuất và tự động hóa trên máy tính để bàn cho việc tải lên cuối cùng.
Mục tiêu (Goals)
Mục tiêu mạnh mẽ nhất khi nhiệm vụ có một vạch đích thực sự mà tác nhân có thể tiếp tục hướng tới. Một mục tiêu yếu là:
Mục tiêu:
Các tác vụ Codex chạy dài hơn với một vạch đích mà tác nhân có thể tiếp tục hướng tới theo thời gian.
Thực hiện kế hoạch trong tệp Markdown này.
Một mục tiêu mạnh mẽ hơn có một tiêu chí thành công có thể đo lường được.
Ví dụ, một kỹ sư có thể di chuyển một công cụ nội bộ từ Python sang Rust bằng cách thiết lập thư mục mới, xác định mục tiêu và làm cho vạch đích trở nên rõ ràng: quá trình triển khai mới chưa hoàn thành cho đến khi các bài kiểm tra đơn vị (unit tests) vượt qua.
Một mục tiêu kết hợp việc thực thi liên tục (ongoing execution) với một bộ xác minh (verifier). Người dùng xác định kết quả đầu ra, điều kiện dừng và tín hiệu cho biết liệu Codex có đang tiến gần hơn đến mục tiêu hay không.
Các bộ xác minh hữu ích bao gồm:
- một bộ kiểm thử (test suite)
- một điểm chuẩn (benchmark)
- một bản tái hiện lỗi (bug reproduction)
- một ma trận xác thực (validation matrix)
- một quy trình làm việc từ đầu đến cuối (end-to-end workflow) phải luôn vượt qua
Tham vọng rất quan trọng, nhưng nếu không có sự xác minh thì nó chỉ là một điều ước.
Bảng điều khiển phụ (The side panel)
Bảng điều khiển phụ giữ công việc bên cạnh cuộc trò chuyện đã tạo ra nó. Thay vì xuất một tạo phẩm và chuyển đổi ngữ cảnh, người dùng có thể xem lại nó ngay tại chỗ. Đầu ra có thể là code, nhưng cũng có thể là một bài thuyết trình, một tệp PDF, một trang trình duyệt, một bảng hoặc một tạo phẩm khác được tạo ra trong quá trình thực hiện.
Nó hỗ trợ bốn công việc đặc biệt tốt:
- Kiểm tra các tạo phẩm
- Chú thích những gì cần thay đổi
- Vận hành các bề mặt web
- Xem xét các thay đổi
Bảng điều khiển phụ cho phép người dùng xem lại Markdown, bảng tính, bảng dữ liệu, tài liệu và slide ngay tại chỗ. Họ có thể kiểm tra, đánh dấu và sửa đổi các tạo phẩm mà không phá vỡ vòng lặp.
Chú thích (Annotations)
Bài thuyết trình hoặc tệp PDF có thể được mở ngay bên cạnh luồng đã tạo ra nó, sẵn sàng để xem xét và sửa chữa trực tiếp.
Bảng tính trong Codex
Trình duyệt trong ứng dụng cho phép Codex kiểm tra một trang đã được kết xuất, điều khiển nó và phản hồi các chú thích trực tiếp trên bề mặt đang được xem xét. Các bình luận trên một trang hoặc tạo phẩm vẫn nằm trong vòng lặp làm việc thay vì trở thành một sự bàn giao riêng biệt.
Web trở thành cả đầu ra và bề mặt điều khiển. Codex có thể xây dựng một tạo phẩm, mở nó trong bảng điều khiển phụ, kiểm tra nó, gỡ lỗi nó và tiếp tục cải tiến cùng một đối tượng ngay tại chỗ.
Những bề mặt này hoạt động đặc biệt tốt:
- index.html cho các tạo phẩm tĩnh nhẹ
- Storybook để xem xét giao diện người dùng
- Remotion Studio cho hoạt ảnh lập trình (programmatic animation)
- Các bài thuyết trình dựa trên trình duyệt cho các buổi thuyết trình
- Ứng dụng dữ liệu (data apps) cho các quy trình làm việc phân tích
Một tệp index.html duy nhất có thể trở thành một tạo phẩm tương tác bền vững mà không cần máy chủ. Các tự động hóa luồng cũng có thể làm mới các tạo phẩm tĩnh theo thời gian để một luồng có nội dung mới chờ sẵn khi người dùng quay lại.
Bộ nhớ dùng chung (Shared memory)
Các luồng chạy dài trở nên hữu ích hơn khi chúng chia sẻ bộ nhớ bên ngoài bất kỳ cuộc trò chuyện đơn lẻ nào.
Bộ nhớ dùng chung:
Ngữ cảnh bền vững được lưu trữ bên ngoài một luồng duy nhất để công việc sau này có thể tiếp tục từ một thứ gì đó rõ ràng và có thể xem xét lại được.
Một mẫu hình bền vững là neo các luồng liên tục (persistent threads) vào một kho lưu trữ Obsidian (Obsidian vault). Trong thực tế, điều đó có nghĩa là một thư mục chứa các tệp văn bản thuần (plain files) luôn dễ dàng kiểm tra, chỉnh sửa, di chuyển và lưu giữ trong thời gian dài. Các nhóm có thể lưu trữ thư mục đó trên lưu trữ đám mây, Git, Dropbox, Google Drive hoặc một lớp đồng bộ khác phù hợp với quy trình làm việc của họ.
Một kho lưu trữ (vault) có thể trông như thế này:
vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/
Ở cấp cao nhất, AGENTS.md có thể xác định cách Codex nên cập nhật không gian làm việc đó khi nó tìm hiểu thêm về con người, dự án, quyết định và các vấn đề còn bỏ ngỏ (open loops).
Đừng sao chép nguyên một cấu trúc kho lưu trữ cụ thể. Hãy dạy cho tác nhân biết ngữ cảnh bền vững nên được đặt ở đâu, ngữ cảnh nào cần lưu giữ và khi nào không nên tạo ra sự xáo trộn không cần thiết.
Một tệp AGENTS.md thực tế có thể nói:
- Coi ~/vault như bộ nhớ làm việc bền vững.
- Ưu tiên các ghi chú chuẩn mực (canonical notes) thay vì ghi chú lan man.
- Phân loại rõ ràng các TODO, con người, dự án, tóm tắt hàng ngày và ghi chú nháp.
- Lưu giữ các quyết định, điểm nghẽn, chủ sở hữu, ngày tháng và các liên kết hữu ích.
- Nếu không có thay đổi ý nghĩa nào, đừng làm xáo trộn kho lưu trữ.
Các kho lưu trữ (Repositories) giữ code. Kho lưu trữ (vault) giữ ngữ cảnh luân chuyển: những người liên quan, điều gì đã thay đổi, điều gì bị chặn, điều gì cần theo dõi tiếp theo và điều gì sẽ biến mất giữa các phiên làm việc.
Ngữ cảnh quan trọng không nên chỉ tồn tại bên trong một bản ghi cuộc trò chuyện. Hãy ghi nó ra một nơi nào đó mà luồng tiếp theo có thể tiếp tục.
Codex cũng có tính năng bộ nhớ của bên thứ nhất trong Cài đặt > Cá nhân hóa > Bộ nhớ (Settings > Personalization > Memories). Chúng cung cấp một lớp truy xuất cục bộ cho các ưu tiên, quy trình làm việc định kỳ và các cạm bẫy đã biết. Chúng bổ sung cho ngữ cảnh được viết rõ ràng hơn là thay thế nó. Chronicle cũng đi theo hướng tương tự bằng cách giúp Codex xây dựng bộ nhớ từ ngữ cảnh màn hình gần đây.
Từ code ra bên ngoài
Codex vẫn bắt đầu từ code. Nhưng nhiều công việc xung quanh code hiện đã có thể tiếp cận được thông qua cùng một hệ thống: máy chủ MCP, bề mặt trình duyệt, điều khiển trên máy tính để bàn, tự động hóa luồng và các tạo phẩm có thể xem xét lại được.
Điều đó thay đổi mô hình điều khiển. Định hướng làm gián đoạn công việc đang tiến hành. Xếp hàng sắp xếp tác vụ tiếp theo. Tự động hóa luồng giữ cho một luồng hoạt động khi người dùng rời đi. Mục tiêu thêm một vạch đích cụ thể mà Codex có thể tiếp tục hướng tới.
Codex giờ đây có thể đưa một quy trình làm việc từ hướng dẫn đến thực thi đến xem xét tạo phẩm, ngay cả khi công việc rời khỏi kho lưu trữ.
