Sơ đồ của Gergely Orosz về quy trình phát triển phần mềm nội bộ của OpenAI đã được lan truyền rộng rãi trong tuần này: một nhà phát triển đưa ra một yêu cầu, Codex viết mã, một đội ngũ tác nhân đánh giá chuyên biệt tranh luận về rủi ro, và một tác nhân giám sát việc triển khai trong khi theo dõi các bảng điều khiển mà nó tự xây dựng. Nó cũng là, đối với những phần quan trọng nhất đối với các kỹ sư của OpenAI, một mô tả về các công cụ nội bộ mà bạn không thể cài đặt.
Perf Factory, Sevbot và triển khai dựa trên tác nhân (agentic deploy) với các bảng điều khiển tự xây dựng chạy trên nền tảng quan sát của OpenAI và không phải là một phần của sản phẩm Codex mà bạn có thể mua. Những gì bạn có thể xây dựng trong tuần này là một vòng lặp nhỏ hơn nhưng vẫn thực hiện công việc thực tế: một nhà phát triển định nghĩa kết quả dưới dạng một vấn đề, Codex làm việc trên nhánh, CI kiểm tra xem thay đổi có hoạt động thực sự hay không, một hoặc hai tác nhân đánh giá xem xét nó, và một người sẽ phê duyệt bất kỳ điều gì rủi ro trước khi nó được triển khai sau một cờ chức năng (feature flag). Toàn bộ quá trình dựa vào một chi tiết mà sơ đồ gốc bỏ qua: "CI vượt qua" chỉ có ý nghĩa nếu CI kiểm tra đúng mọi thứ. Đối với một API, điều đó có nghĩa là kiểm thử API, chứ không chỉ mã gọi nó.
Sơ đồ hiểu đúng điều gì (và điều gì bạn không thể sao chép)
Phần công khai của bài viết của Pragmatic Engineer mô tả một vòng lặp cốt lõi nơi Codex "thực hiện một loạt các thay đổi mã cho đến khi đạt được mục tiêu, và sau đó xác minh rằng phần mềm hoạt động như mong đợi." Các khu vực rủi ro thấp có thể tự động phê duyệt; các thay đổi rủi ro cao hơn sẽ được AI xem xét kỹ hơn hoặc yêu cầu phê duyệt bắt buộc từ con người. Cấu trúc đó, đề xuất, xác minh, xem xét theo mức độ rủi ro, là có thể áp dụng. Các nhóm đã mô phỏng nó bằng bot pull request và cổng CI trong nhiều năm; các tác nhân chỉ làm cho vòng lặp nhanh hơn và ít cần giám sát hơn.
Điều không thể sao chép là các cơ chế nội bộ xung quanh nó. Perf Factory sàng lọc các cảnh báo và bảng điều khiển để tìm ra các lỗi hồi quy về độ trễ và đề xuất cách khắc phục. Sevbot điều tra các sự cố và trả lời các câu hỏi trong Slack, mặc dù nó không tự thực hiện các biện pháp giảm thiểu. Agentic deploy theo dõi một thay đổi được đưa vào sản xuất và xây dựng hệ thống giám sát của riêng mình bằng cách sử dụng ngăn xếp đo lường từ xa nội bộ của OpenAI. Không có ba thứ nào trong số đó được xuất xưởng trong sản phẩm Codex bên ngoài. Những gì đã xuất xưởng là ứng dụng desktop, lệnh /goal cho các tác vụ chạy dài, và các plugin vai trò và kỹ năng mà bạn tự cấu hình. Trang sản phẩm Codex của OpenAI bao gồm những gì thực sự có sẵn.
Vòng lặp năm bước bạn có thể chạy trong tuần này
Một phiên bản thu nhỏ trông như sau:
- Một nhà phát triển đưa ra yêu cầu dưới dạng một vấn đề. Không phải là danh sách tác vụ, mà là mô tả trạng thái cuối cùng: "đơn hàng có thể kèm theo một mã giảm giá tùy chọn giúp giảm tổng số tiền." Giao cùng một vấn đề GitHub đó cho một Agent trong Sharkly là tích hợp đã được triển khai: vấn đề trở thành một Nhiệm vụ, và kết quả trả về dưới dạng một PR chứ không phải một phiếu yêu cầu riêng biệt cần đối chiếu. Hiện tại nó miễn phí cho các tổ chức lên đến 10 người.
- Codex xử lý nhánh với
/goal. Như đã trình bày trong cách lệnh/goalđiều khiển các tác vụ tự động của Codex và Claude Code, bạn cung cấp cho tác nhân một mục tiêu và để nó lặp lại cho đến khi đạt được mục tiêu. - CI chạy quá trình xây dựng, kiểm thử đơn vị (unit tests) và kịch bản kiểm thử API. Đây là bước mà hầu hết các nhóm bỏ qua hoặc xây dựng nửa vời.
- Một hoặc hai tác nhân đánh giá kiểm tra sự khác biệt, và một người xem xét bất cứ điều gì có mức độ rủi ro cao. Các công cụ đánh giá mã AI có thể phát hiện nhiều lỗi trước khi một người xem PR. Trong Sharkly, đây là nơi Ready for Release thực hiện công việc: một người phải chuyển tác vụ ra khỏi trạng thái đó trước khi bất cứ điều gì đến Done, và một tác nhân đánh giá riêng biệt có thể ngồi trong cùng một Nhóm với tác nhân đã viết mã.
- Triển khai phía sau một cờ chức năng (feature flag), để một sự hợp nhất xấu chỉ là một công tắc, chứ không phải một sự cố.
Bước 3 là nơi vòng lặp hoạt động hoặc nói dối bạn.
Tại sao CI phải kiểm thử API, không chỉ mã
Tính năng đánh giá của chính Codex, được đề cập trong cách đánh giá mã của Codex hoạt động, đọc sự khác biệt và gắn cờ các vấn đề rõ ràng. Nó không chạy dịch vụ của bạn và kiểm tra những gì nó trả về. Các kiểm thử đơn vị, nếu tác nhân đã viết hoặc giữ chúng, chủ yếu xác minh mã làm những gì mã dự định, điều này không giống với việc xác minh API làm những gì hợp đồng hứa hẹn. Một tác nhân chỉnh sửa một bộ xử lý (handler) có thể vượt qua mọi kiểm thử đơn vị trong khi lặng lẽ làm hỏng phản hồi mà mọi client đều phụ thuộc.
Giả sử bạn chạy một API đơn hàng. POST /api/orders tạo một đơn hàng và trả về bản ghi của nó; GET /api/orders/{id} lấy một đơn hàng theo ID. Bạn duy trì một đặc tả OpenAPI cho cả hai, và bạn đã xây dựng các kịch bản kiểm thử Apidog dựa trên nó: tạo một đơn hàng, lấy lại nó, và kiểm tra bốn điều mà một kiểm thử đơn vị thường sẽ không làm:
- Mã trạng thái.
POST /api/orderstrả về201, không phải200hoặc một500âm thầm trong trường hợp biên xác thực. - Lược đồ phản hồi theo đặc tả OpenAPI. Trường
total_amountvẫn là một số,statusvẫn là một trong các giá trị enum bạn đã định nghĩa, và không có trường nào mà client phụ thuộc bị biến mất hoặc đổi tên một cách âm thầm. - Lỗi xác thực. Một yêu cầu không có mã thông báo hợp lệ trả về
401, không phải 200 với một phần thân rỗng, đây là một lỗi hồi quy khá phổ biến. - Ngưỡng độ trễ. Kịch bản khẳng định phản hồi trả về dưới một giới hạn đã đặt, do đó một thay đổi thêm một lệnh gọi cơ sở dữ liệu không theo lô (unbatched) bên trong bộ xử lý sẽ bị phát hiện trước khi khách hàng nhận thấy.
Đó chính xác là những kiểm tra mà một sự tái cấu trúc cấp handler có thể âm thầm làm hỏng trong khi mọi kiểm thử đơn vị vẫn vượt qua, bởi vì kiểm thử đơn vị thường mô phỏng ranh giới mà kịch bản API thực sự kiểm tra.
Tích hợp nó vào pipeline
Bạn đã chạy phiên bản CLI của các kịch bản này cục bộ nếu bạn đã theo dõi cách sử dụng Apidog CLI trong Codex. Cùng một lệnh chạy trong CI. Một tác vụ GitHub Actions xây dựng, chạy kiểm thử đơn vị, và sau đó chạy kịch bản Apidog trông như sau:
name: CI
on:
pull_request:
push:
branches: [main]
jobs:
build-test-verify:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install dependencies
run: npm ci
- name: Build and run unit tests
run: npm run build && npm test
- name: Install Apidog CLI
run: npm install -g apidog-cli
- name: Run orders API test scenario
env:
APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
run: |
apidog run \
--access-token $APIDOG_ACCESS_TOKEN \
-t 88214 \
-e 3301 \
-r cli,junit
- name: Upload Apidog reports
if: always()
uses: actions/upload-artifact@v4
with:
name: apidog-reports
path: apidog-reports/
Các giá trị -t và -e là ID kịch bản và môi trường thực của bạn từ Apidog, không phải là các giá trị giữ chỗ bạn tự nghĩ ra. Tham khảo lệnh apidog run bao gồm mọi cờ, và báo cáo kiểm thử Apidog CLI giải thích đầu ra JUnit mà tác vụ tải lên. apidog run thoát với mã lỗi khác 0 nếu có bất kỳ khẳng định nào thất bại, vì vậy GitHub Actions đánh dấu tác vụ thất bại theo cách tương tự như đối với một kiểm thử đơn vị thất bại.
Dạng prompt của tác nhân
Mục đích của /goal là bạn mô tả kết quả và điều kiện thoát, và Codex sẽ lặp lại mà không cần bạn phê duyệt từng bước. Đối với ví dụ mã giảm giá, một prompt hợp lý là:
/goal Add an optional `discount_code` field to POST /api/orders. Validate it
against the promotions service and apply the discount to `total_amount` in
the response. Do not rename or remove any existing response field. Run
`npm test` and `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` before you finish. Both must exit 0. If the Apidog run fails, read the
failing assertion and fix the handler, not the test.
Dòng cuối cùng đó rất quan trọng. Một tác nhân dưới áp lực để chuyển một kiểm tra sang trạng thái xanh đôi khi sẽ chỉnh sửa khẳng định thay vì sửa lỗi. Việc nói rõ ràng cho nó biết nên sửa phần nào của vòng lặp sẽ giữ kịch bản kiểm thử là nguồn chân lý, chứ không phải là một chướng ngại vật cần tránh.
Khi tác nhân vi phạm hợp đồng
Codex thêm trường giảm giá, và trong quá trình đó đổi tên total_amount thành totalAmount vì đó là quy ước trong một tệp nó đọc gần đó. Các kiểm thử đơn vị vẫn vượt qua; chúng kiểm tra phép tính giảm giá, không phải tên trường. Quá trình build thành công. Sau đó, kịch bản Apidog chạy trong CI, xác thực phản hồi dựa trên đặc tả OpenAPI, và thất bại: đặc tả nói total_amount, phản hồi giờ có totalAmount, và khẳng định lược đồ bắt được nó ngay lập tức.
CI báo cáo thoát với mã lỗi khác 0 và chỉ vào khẳng định lược đồ thất bại trong đầu ra JUnit. Codex đọc lỗi, thấy việc đổi tên là nguyên nhân, và hoàn nguyên nó trong khi vẫn giữ logic giảm giá. Kịch bản vượt qua, quá trình build chuyển sang màu xanh, và pull request chuyển sang giai đoạn xem xét với một sự đảm bảo thực sự đằng sau từ "vượt qua". Nếu không có kiểm tra cấp API, việc đổi tên đó sẽ được triển khai, và mọi client phân tích cú pháp total_amount sẽ bị lỗi trong bản phát hành tiếp theo.
Phân loại rủi ro bạn có thể dựa vào đặc tả
Thay vì một cảm giác mơ hồ về những gì được coi là rủi ro thấp, hãy gắn phân loại rủi ro của bạn với sự khác biệt của OpenAPI. Một thay đổi thêm một trường tùy chọn với giá trị mặc định là một ứng cử viên cho việc tự động hợp nhất khi các kiểm thử vượt qua. Một thay đổi loại bỏ một trường, đổi tên một trường, hoặc thay đổi mã trạng thái không bao giờ là rủi ro thấp, bất kể phần còn lại của sự khác biệt trông như thế nào. Quy tắc đơn giản đó bắt hầu hết những gì một tác nhân đánh giá chuyên biệt sẽ gắn cờ dù sao đi nữa. Chuyển bất cứ điều gì quy tắc gắn cờ đến một người đánh giá hoặc một lần kiểm tra thứ hai từ một công cụ đánh giá mã AI trước khi hợp nhất.
Triển khai sau một cờ chức năng, không phải vào hư không
Một khi một thay đổi vượt qua CI và được xem xét, hãy triển khai nó sau một cờ chức năng (feature flag) thay vì trực tiếp cho mọi người dùng. Đây là sự thay thế rẻ tiền cho bước triển khai dựa trên tác nhân của OpenAI: không có tác nhân nào giám sát quá trình triển khai hay tự xây dựng các bảng điều khiển. Một cờ bắt đầu ở 5% lưu lượng truy cập và một người kiểm tra tỷ lệ lỗi trước khi chuyển nó lên 100% sẽ mang lại cho bạn hầu hết sự an toàn mà không cần bất kỳ công cụ nội bộ nào. Nếu có gì đó không ổn, bạn chỉ cần tắt cờ thay vì phải hoàn tác một sự hợp nhất dưới áp lực.
Một khung sườn đã tồn tại
Bạn không cần phải xây dựng tất cả năm bước từ đầu. orchflows là một dự án mã nguồn mở đã xuất hiện trong các phản hồi cho chủ đề của Orosz: một lệnh /software-factory được cấp phép MIT cho Claude Code và Codex, được xây dựng xung quanh một số kỹ năng có thể tái sử dụng. Nó là một khung sườn khởi đầu, không phải là sự thay thế cho các bước CI và đánh giá ở trên; bạn vẫn chỉ định nó vào các kịch bản kiểm thử và quy tắc rủi ro của riêng bạn.
Những gì nên bỏ qua việc xây dựng
Đừng cố gắng tái tạo Perf Factory, Sevbot, hoặc triển khai dựa trên tác nhân với các bảng điều khiển tự xây dựng. Chúng là các hệ thống nội bộ của OpenAI được kết nối với hệ thống đo lường từ xa mà hầu hết các nhóm không chạy. Con người tại OpenAI vẫn xác định kết quả, phê duyệt các thay đổi rủi ro cao, ủy quyền các biện pháp giảm thiểu sự cố, và trực ban; như OpenAI đã nói, "trực ban không phải là chuyện của quá khứ." Hãy sao chép những phần của vòng lặp chỉ là kỷ luật kỹ thuật tốt: xác minh trước khi hợp nhất, phân loại rủi ro theo những gì thực sự thay đổi, và giữ một người ở bất cứ điều gì không rõ ràng là an toàn.
Bắt đầu vòng lặp
Bắt đầu với bước CI; nó làm cho mọi bước khác đáng tin cậy. Xây dựng kịch bản kiểm thử API đơn hàng của bạn trong Apidog, bao gồm mã trạng thái, lược đồ, xác thực và ngân sách độ trễ. Tích hợp nó vào pipeline của bạn bằng CLI, trỏ /goal vào một vấn đề thực tế, và để Codex lặp lại với một kiểm tra thực sự khẳng định hành vi API thay vì tin vào lời của tác nhân. Tải xuống Apidog để xây dựng kịch bản đầu tiên, sau đó thêm các bước đánh giá và gắn cờ khi vòng lặp đã chứng minh được hiệu quả.