/goal không phải là một tính năng. Nó là một nguyên hàm.
HTTP là một nguyên hàm. JSON là một nguyên hàm. /goal đang trở thành một nguyên hàm cho các tác nhân viết mã.
Vài tuần trước, Codex CLI của OpenAI đã thêm /goal như một cách để giao cho worker viết mã một công việc với trạng thái "hoàn thành" được xác định rõ ràng. Claude Code cũng đã thêm tính năng này trong tuần này.
Hermes Agent, bộ điều phối mà tôi chạy trên Mac Mini để phối hợp công việc giữa các worker viết mã, đã tích hợp sẵn /goal từ lâu.
Vậy là giờ tôi có một người xây dựng (builder), một người đánh giá (reviewer) và một bộ điều phối (orchestrator), tất cả đều chấp nhận cùng một định dạng lệnh, mặc dù chúng không chia sẻ gì khác.
Nếu bạn chỉ thấy /goal được dùng như một lời nhắc phức tạp hơn, bạn đã bỏ lỡ những gì nó thay đổi.
/goal thực sự là gì
Một lời nhắc thông thường yêu cầu một tác nhân đưa ra phản hồi tiếp theo. Bạn đọc kết quả, quyết định xem nó có đúng không, và thúc đẩy tác nhân thực hiện bước tiếp theo. Bạn đang điều khiển từng lượt.
/goal đảo ngược điều đó. Bạn viết ra "hoàn thành" trông như thế nào, gửi nó một lần, và tác nhân sẽ làm việc hướng tới mục tiêu đó cho đến khi đạt được. Đây là một ví dụ thực tế:
1/goal Xây dựng ứng dụng được mô tả trong SPEC.md. Hoàn thành có nghĩa là2các bài kiểm tra pass, bản build pass, README chính xác, và git status chỉ hiển thị3các tệp dự án có liên quan.
Mục tiêu vẫn hoạt động cho đến khi nó đạt được, bị tạm dừng, bị chặn, bị xóa, hoặc hết ngân sách.
Điều này khác với việc đặt từ "goal" bên trong một lệnh một lần thông thường. Nếu bạn viết codex exec 'goal: build the app', đó vẫn chỉ là một lời nhắc có nhãn. Nguyên hàm thực sự tồn tại bên trong một phiên làm việc worker tương tác. Bạn khởi chạy CLI, bạn gửi /goal, và bạn bỏ đi.
Sự thay đổi là từ việc ra lệnh (bạn lái xe) sang ủy quyền (tác nhân tự lái xe hướng tới mục tiêu bạn đã xác định).
GIF
Ba công cụ hiện đang hiểu /goal
Ba công cụ chấp nhận /goal không hoàn toàn giống nhau, vì vậy cần phải nói rõ ràng.
Codex là CLI viết mã của OpenAI. Mạnh về triển khai, đặc biệt khi có một bản spec rõ ràng. /goal là cách bạn đưa spec đó cho nó.
Claude Code là CLI viết mã của Anthropic. Mạnh về mặt ngược lại: tìm ra những gì sai với code có vẻ đúng. Tuân thủ spec, vấn đề an toàn, trạng thái lỗi, lỗ hổng bảo mật. /goal là cách bạn chỉ cho nó xem code và yêu cầu đánh giá.
Hermes Agent là một loại công cụ hoàn toàn khác. Không phải là worker viết mã, mà là một bộ điều phối phối hợp công việc giữa các worker viết mã như hai công cụ trên. /goal là cách Hermes chuyển giao nhiệm vụ cho công cụ phù hợp với công việc, và cũng là cách tôi nói với Hermes những gì tôi muốn ngay từ đầu.
Điều quan trọng không phải là bất kỳ công cụ nào trong số chúng đã phát hành /goal. Mà là ba nhóm khác nhau đã hội tụ về cùng một nguyên hàm, và sự hội tụ đó làm cho việc kết hợp chúng trở nên khả thi.
GIF
Thiết lập mọi thứ
Lần đầu tiên tôi cần Codex và Claude Code trên Mac Mini chạy Hermes, tôi đã không tự cài đặt chúng. Tôi đã gửi cho Hermes một tin nhắn yêu cầu nó cài đặt cả hai và đăng nhập cho tôi. Nó xử lý phần còn lại.
Đó là quy trình làm việc bây giờ. Bạn không cần gõ các lệnh cài đặt. Thiết lập chỉ là một mục tiêu khác.
Nếu bạn chưa có bộ điều phối nào đang chạy, các trang cài đặt cho Codex và Claude Code khá dễ làm theo. Nhưng một khi bạn đã có, bạn không nên tự tay thiết lập bất kỳ công cụ nào khác. Ý nghĩa của việc có một bộ điều phối là công việc cơ học không còn là của bạn nữa.
Hermes bổ sung thêm gì vào /goal
Một /goal thô tự nó đã hữu ích. Nhưng nó để lại cho bạn một vấn đề phối hợp.
Nếu Codex đang chạy trong một terminal và Claude Code đang chạy trong một terminal khác, bạn phải nhớ process nào đang làm gì. Bạn phải kiểm tra log. Bạn phải tự tay chuyển kết quả đánh giá từ công cụ này sang công cụ kia.
Hermes biến những lần chạy rời rạc đó thành một quy trình làm việc:
- Bạn nhắn tin cho Hermes (trong trường hợp của tôi, qua Telegram từ điện thoại)
- Hermes tạo các thẻ mục tiêu trên một bảng Kanban
- Hermes chọn worker phù hợp cho mỗi thẻ
- Worker chạy mục tiêu trong nền
- Thẻ lưu trữ process id, PID, repo và tiêu chí hoàn thành
- Khi bản build đã sẵn sàng, Hermes chuyển repo cho người đánh giá
- Nếu đánh giá bị chặn, Hermes gửi lại kết quả dưới dạng một mục tiêu sửa lỗi
- Hermes xác minh đầu ra cuối cùng bằng cách kiểm tra filesystem, bài kiểm tra, bản build và trạng thái git
Bảng là thứ mà /goal trở thành khi có một bộ điều phối ở trên nó. Mọi mục tiêu đều có một thẻ, mọi thẻ đều có trạng thái, mọi sự chuyển giao đều để lại dấu vết. Thay vì săn lùng các terminal, bạn xem công việc di chuyển qua các cột trên điện thoại của mình.
Ba vai trò
Các công cụ thay đổi. Các vai trò thì không.
Bộ điều phối: Nắm quyền kiểm soát vòng lặp. Phân rã nhiệm vụ, lựa chọn worker, thẻ Kanban, process nền, phụ thuộc, xác minh cuối cùng, bản tóm tắt cho người dùng. Trong thiết lập của tôi, đó là Hermes.
Người xây dựng: Nhận một spec và tạo ra code hoạt động được. Triển khai là nút thắt cổ chai mà vai trò này giải quyết. Codex thường mạnh ở đây.
Người đánh giá: Đọc những gì người xây dựng tạo ra và tìm ra những gì sai với nó. Tính đúng đắn là nút thắt cổ chai. Claude Code thường mạnh ở đây.
Một lần chạy thực tế, từ đầu đến cuối
Tôi đã giao cho Hermes agent một mục tiêu để làm điều này:
1/goal Xây dựng một công cụ CLI để tìm các đề cập đến tôi trên X và2thông báo cho tôi khi có điều gì đó bùng nổ.
Hermes đã chia yêu cầu thành sáu thẻ.
Shubham Saboo
@Saboo_Shubham_
·
Codex /goal xây dựng nó.
Claude Code /goal đánh giá và tinh chỉnh nó.
Hermes /goal quản lý sự điều phối và chuyển giao.
Tất cả được theo dõi trên một bảng Kanban duy nhất và các tác nhân tiếp tục chạy trong vòng lặp.
58
61
852
Thẻ 1: Spec. Hermes tự viết SPEC.md, ghi lại stack, đường dẫn repo, các ràng buộc chỉ đọc, yêu cầu chế độ mô phỏng, bài kiểm tra và các lệnh xác minh. Được sở hữu bởi vai trò PM.
Thẻ 2: Codex xây dựng. Codex chạy /goal dựa trên SPEC.md. Nó tạo các tệp dự án, triển khai UI và backend, thêm các bài kiểm tra và đưa ứng dụng đến trạng thái pass. Mất khoảng 15 phút. Khi hoàn thành, npm test pass, npm run build pass và git status chỉ hiển thị các tệp mới có liên quan.
Thẻ 3: Claude Code đánh giá. Claude Code chạy /goal để đánh giá những gì Codex đã xây dựng. Kiểm tra tuân thủ spec, an toàn chỉ đọc, xử lý API key, trạng thái lỗi, bài kiểm tra, tính hữu ích của UI, lỗi và vấn đề bảo mật. Kết quả: PASS, không có vấn đề chặn.
Thẻ 4: Codex vòng lặp sửa lỗi. Đã bỏ qua, vì đánh giá đã pass. Thẻ vẫn quan trọng khi bị bỏ qua. Nó cho thấy Hermes có thể mô hình hóa công việc có điều kiện. Nếu Claude Code đã chặn, Hermes sẽ chuyển kết quả lại cho Codex dưới dạng một /goal mới.
Thẻ 5: Claude Code xác minh cuối cùng. Đã bỏ qua vì lý do tương tự.
Thẻ 6: Hermes tóm tắt cuối cùng. Ứng dụng hoạt động tại đường dẫn cục bộ, cả UI và API đều được xác minh ở chế độ mô phỏng. Codex đã xây dựng nó với /goal. Claude Code đã đánh giá nó với /goal và trả về PASS.
Tất cả điều đó đến từ một tin nhắn duy nhất. Ba công cụ khác nhau đã thực hiện công việc thực tế, nhưng tôi chỉ nói chuyện với Hermes.
Quy tắc xác minh
Hermes không bao giờ tin vào báo cáo tự thân của Codex. Sau khi Codex đánh dấu bản build là đã hoàn thành, Hermes đã tự chạy các lệnh:
1npm test # 17 bài kiểm tra pass2npm run build # vite build pass
Trình xác minh là thứ làm cho /goal trở thành một hợp đồng thay vì một lời hứa. Đừng tin vào báo cáo tự thân của worker là cuối cùng. Hãy tin vào trình xác minh.
Các tác nhân viết mã rất tự tin. Chúng sẽ nói với bạn rằng bản build pass khi bản build chưa bao giờ được chạy. Chúng sẽ nói rằng các bài kiểm tra pass khi chúng viết các bài kiểm tra chưa bao giờ được thực thi. Trình xác minh thu hẹp khoảng cách đó.
Nếu không có xác minh, /goal chỉ là một lời nhắc phức tạp hơn. Với xác minh, nó trở thành một hợp đồng.
GIF
Chạy nhiều mục tiêu
Bạn có thể chạy nhiều /goal song song, nhưng bạn không thể chỉ nhiều worker viết mã vào cùng một tệp mà không suy nghĩ trước.
Mặc định của tôi là một builder chính cho mỗi repo. Nếu tôi muốn song song, tôi thêm nó qua các ranh giới rõ ràng. Các repo khác nhau, các nhánh khác nhau, git worktrees, các gói riêng biệt, tài liệu so với code, bài kiểm tra so với triển khai. Bất kỳ nơi nào hai worker không thể giẫm chân lên nhau.
Mô hình xấu là ba worker cùng chỉnh sửa một tệp trong cùng một repo. Bạn sẽ gặp xung đột, ghi đè một phần, và một worker âm thầm hoàn tác công việc của worker khác.
Mô hình tốt hơn là một người viết tại một thời điểm trên bất kỳ tệp nào nhất định. Builder viết, reviewer chỉ đọc, các mục tiêu sửa lỗi chỉ giới hạn trong phạm vi sửa lỗi. Hoặc chạy ba builder trong ba worktree trên ba cách tiếp cận cạnh tranh và để bộ điều phối chọn cách tốt nhất.
Bảng là thứ làm cho điều này trở nên thực tế. Nếu không có nó, các worker nền song song sẽ trở thành hỗn loạn terminal.
Những gì thay đổi đối với tôi
Cách nhìn hữu ích ở đây không phải là "Tôi có thể chạy các tác nhân trong nền."
Mà là một tin nhắn biến thành một đường ống qua ba công cụ viết mã khác nhau, và tôi xem toàn bộ mọi thứ di chuyển qua một bảng.
Bạn ngừng ngồi trong terminal chờ một tác nhân hoàn thành, và bắt đầu quản lý một hàng đợi công việc với trạng thái hiển thị.
Nếu Codex và Claude Code mỗi bên đã phát minh ra định dạng chuyển giao công việc của riêng mình, sẽ không có bộ điều phối nào có thể định tuyến giữa chúng. Bảng rất ấn tượng, nhưng nguyên hàm làm cho bảng trở nên hữu ích hơn.
Các worker có thể thay đổi, nhưng nguyên hàm vẫn giữ nguyên. Công cụ viết mã tiếp theo áp dụng /goal sẽ tham gia đường ống này mà tôi không cần thay đổi gì. Tôi sẽ chỉ định tuyến công việc đến nó.
Đó là những gì các nguyên hàm tốt làm.
Để có thêm nhiều mẹo thú vị và ý tưởng hay về Hermes, OpenClaw, Claude Code, Codex và các nhóm tác nhân 24/7 khác.
Theo dõi → @Saboo_Shubham_
