I would like to review the following points on the current PR (this branch vs main). Spawn one agent per point, wait for all of them, and summarize the result for each point.
- Security issue
- Code quality
- Bugs
- Race conditions
- Test flakiness
- Maintainability of the code
Trong kịch bản này, Codex có thể sẽ khởi chạy sáu đại lý phụ riêng biệt, mỗi đại lý chuyên về một trong các điểm đánh giá được liệt kê. Sau khi mỗi đại lý hoàn thành phân tích của mình, Codex sẽ biên soạn các phát hiện thành một báo cáo có cấu trúc duy nhất, cung cấp cái nhìn tổng quan toàn diện về yêu cầu kéo (pull request). Điều này minh họa hiệu quả đạt được bằng cách phân phối khối lượng công việc giữa các thực thể AI chuyên biệt.
## Quản lý và bảo mật hệ sinh thái đại lý phụ của bạn
Quản lý hiệu quả và bảo mật mạnh mẽ là những yếu tố quan trọng khi làm việc với các đại lý phụ. Codex cung cấp các công cụ và cơ chế để giám sát các hoạt động của đại lý phụ và đảm bảo các hoạt động an toàn trong môi trường sandbox của chúng.
Trong các phiên CLI tương tác, các nhà phát triển có thể sử dụng lệnh `/agent` để chuyển đổi giữa các luồng tác tử đang hoạt động, kiểm tra các quy trình đang diễn ra hoặc điều khiển một tác tử phụ cụ thể. Việc kiểm soát chi tiết này cho phép điều chỉnh và giám sát tiến độ của từng tác tử theo thời gian thực. Bạn cũng có thể yêu cầu Codex dừng một tác tử phụ đang chạy hoặc đóng các luồng đã hoàn tất để quản lý tài nguyên và tập trung.
Bảo mật là tối quan trọng, và các đại lý phụ kế thừa chính sách sandbox hiện tại từ phiên Codex chính. Điều này đảm bảo rằng các hoạt động của chúng tuân thủ các quy tắc an toàn và truy cập được xác định trước. Khi các yêu cầu phê duyệt phát sinh từ các luồng tác tử không hoạt động, đặc biệt trong các phiên CLI tương tác, Codex sẽ hiển thị chúng một cách thông minh cho người dùng. Một lớp phủ phê duyệt sẽ hiển thị luồng nguồn, cho phép bạn nhấn 'o' để mở và kiểm tra luồng đó trước khi đưa ra quyết định có cơ sở để phê duyệt, từ chối hoặc trả lời yêu cầu. Điều này ngăn chặn các phê duyệt mù quáng và duy trì sự giám sát của nhà phát triển.
Đối với các luồng không tương tác hoặc các tình huống không thể hiển thị phê duyệt mới ngay lập tức, bất kỳ hành động nào yêu cầu phê duyệt mới sẽ tự động thất bại, với Codex báo cáo lỗi trở lại quy trình làm việc mẹ. Cơ chế an toàn này ngăn chặn các hành động trái phép trong các ngữ cảnh tự động. Hơn nữa, Codex áp dụng lại các ghi đè thời gian chạy trực tiếp của lượt mẹ — chẳng hạn như các thay đổi được thực hiện thông qua `/approvals` hoặc cờ `--yolo` — cho các tác tử con được tạo ra, đảm bảo lập trường bảo mật nhất quán trên toàn bộ hệ thống phân cấp tác tử. Đối với người dùng nâng cao, cũng có thể ghi đè cấu hình sandbox cho từng [đại lý tùy chỉnh](#dinh-nghia-cac-dai-ly-tuy-chinh-cho-cac-tac-vu-chuyen-biet), cho phép kiểm soát chi tiết các quyền của chúng, ví dụ, bằng cách đánh dấu một tác tử là 'chỉ đọc'.
## Định nghĩa các đại lý tùy chỉnh cho các tác vụ chuyên biệt
Trong khi Codex cung cấp một số tác tử tích hợp sẵn, chẳng hạn như `default` cho mục đích chung, `worker` cho các tác vụ tập trung vào thực thi và `explorer` để khám phá cơ sở mã nguồn đọc nhiều, sức mạnh thực sự của hệ thống đại lý phụ nằm ở khả năng mở rộng của nó. Các nhà phát triển có thể định nghĩa **các đại lý tùy chỉnh** của riêng họ để giải quyết các yêu cầu rất chuyên biệt, điều chỉnh hành vi AI theo các ngữ cảnh dự án độc đáo.
Các đại lý tùy chỉnh được định nghĩa bằng cách sử dụng các tệp TOML độc lập. Các tệp này có thể được đặt trong `~/.codex/agents/` cho các đại lý cá nhân hoặc `.codex/agents/` cho các đại lý theo phạm vi dự án. Mỗi tệp TOML về cơ bản hoạt động như một lớp cấu hình, cho phép các đại lý tùy chỉnh ghi đè các cài đặt mà lẽ ra sẽ được kế thừa từ phiên mẹ. Điều này bao gồm các tham số quan trọng như mô hình AI được sử dụng, nỗ lực suy luận của nó, chế độ sandbox và thậm chí cả cấu hình kỹ năng cụ thể.
Mỗi tệp đại lý tùy chỉnh độc lập *phải* định nghĩa các trường sau:
* **`name`**: Định danh duy nhất của tác tử, mà Codex sử dụng khi tạo hoặc tham chiếu nó.
* **`description`**: Hướng dẫn dễ đọc giúp Codex hiểu khi nào nên triển khai tác tử này.
* **`developer_instructions`**: Tập hợp các hướng dẫn cốt lõi quy định hành vi và logic hoạt động của tác tử.
Các trường tùy chọn như `nickname_candidates`, `model`, `model_reasoning_effort`, `sandbox_mode`, `mcp_servers`, và `skills.config` cũng có thể được bao gồm. Nếu bỏ qua, các cài đặt này sẽ kế thừa từ phiên mẹ, đơn giản hóa cấu hình khi các giá trị mặc định được chấp nhận. Để biết các phương pháp hay nhất trong kỹ thuật nhắc, yếu tố ảnh hưởng trực tiếp đến hướng dẫn tác tử, hãy tham khảo các tài nguyên như [Hướng dẫn nhắc Codex](/vi/codex-prompting-guide).
Trường `name` là định danh xác định cho một tác tử tùy chỉnh. Mặc dù việc khớp tên tệp với tên tác tử là một quy ước phổ biến và được khuyến nghị, trường `name` trong tệp TOML là nguồn chân lý cuối cùng. Trường `nickname_candidates` là một bổ sung hữu ích cho trải nghiệm người dùng, cho phép Codex gán các tên hiển thị dễ đọc hơn cho các tác tử được tạo ra, điều này đặc biệt hữu ích trong các kịch bản đa tác tử phức tạp.
## Cài đặt toàn cục và cấu hình đại lý phụ nâng cao
Ngoài các định nghĩa đại lý tùy chỉnh riêng lẻ, Codex còn cung cấp các cài đặt cấu hình toàn cục để quản lý hành vi tổng thể của các quy trình làm việc của đại lý phụ. Các cài đặt này thường được tìm thấy trong phần `[agents]` trong tệp cấu hình chính của bạn, cung cấp quyền kiểm soát tập trung đối với phân bổ tài nguyên và các tham số hoạt động.
Dưới đây là bảng phân tích các cài đặt toàn cục chính của đại lý phụ:
| Trường | Loại | Bắt buộc | Mục đích |
| :--------------------------- | :----- | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `agents.max_threads` | số | Không | Giới hạn số lượng luồng đại lý mở đồng thời. Mặc định là `6` nếu không được đặt. |
| `agents.max_depth` | số | Không | Giới hạn độ sâu lồng ghép của các đại lý được tạo ra (phiên gốc bắt đầu từ 0). Mặc định là `1`. Ngăn chặn việc ủy quyền đệ quy vượt quá các tác tử con trực tiếp để quản lý việc sử dụng token và độ trễ. |
| `agents.job_max_runtime_seconds` | số | Không | Đặt thời gian chờ mặc định cho mỗi worker đối với các tác vụ `spawn_agents_on_csv`. Nếu không được đặt, mặc định là `1800` giây (30 phút). |
Cài đặt `agents.max_threads`, mặc định là `6`, cung cấp một biện pháp bảo vệ chống lại việc tiêu thụ tài nguyên quá mức bằng cách giới hạn số lượng đại lý phụ có thể hoạt động đồng thời. Cài đặt `agents.max_depth`, với giá trị mặc định là `1`, đặc biệt quan trọng. Mặc dù việc lồng sâu hơn có vẻ hấp dẫn đối với việc ủy quyền phức tạp, việc tăng giá trị này có thể dẫn đến việc tăng đáng kể việc sử dụng token, độ trễ và tiêu thụ tài nguyên cục bộ do sự mở rộng lặp lại. Nói chung, nên duy trì giá trị mặc định trừ khi một mẫu ủy quyền đệ quy cụ thể là hoàn toàn cần thiết và được quản lý cẩn thận.
Các tệp đại lý tùy chỉnh cũng có thể bao gồm các khóa `config.toml` được hỗ trợ khác, mở rộng khả năng cấu hình của chúng ngoài các trường bắt buộc. Cách tiếp cận cấu hình mô-đun và phân lớp này đảm bảo rằng các nhà phát triển có quyền kiểm soát chi tiết đối với các tác tử AI của họ, cho phép họ tối ưu hóa hiệu suất, chi phí và bảo mật phù hợp với nhu cầu phát triển cụ thể của họ. Bằng cách hiểu và tận dụng các khả năng đại lý phụ mạnh mẽ này, các nhà phát triển có thể đẩy lùi ranh giới của việc lập trình được hỗ trợ bởi AI và nâng cao đáng kể quy trình làm việc phát triển của họ.
Câu hỏi thường gặp
What are Codex subagents and how do they enhance AI development workflows?
Codex subagents are specialized AI agents that can be spawned in parallel by a primary Codex instance to tackle complex, multi-faceted tasks. They significantly enhance AI development workflows by enabling the division of labor across different agents, each focusing on a specific aspect of a task. This parallel processing capability is particularly beneficial for computationally intensive or intricate operations like comprehensive codebase exploration, implementing large-scale multi-step feature plans, or conducting extensive code reviews. By distributing the workload, subagents help in accelerating development cycles, improving the quality of outputs, and managing complexity more effectively than a single agent could.
How does Codex manage the orchestration of multiple subagents?
Codex excels at orchestrating subagent workflows by managing the entire lifecycle from spawning new agents to consolidating their results. When a complex task is initiated, Codex can intelligently route follow-up instructions to the appropriate subagents, monitor their progress, and await the completion of all requested tasks. Once all subagents have finished their assignments and returned their respective outputs, Codex then aggregates these results into a unified, consolidated response. This seamless orchestration ensures that even highly parallelized tasks remain coherent and deliver a comprehensive solution, simplifying complex project management for developers.
What are the security considerations and controls for Codex subagents?
Security for Codex subagents is a critical aspect, with several mechanisms in place to ensure safe operation. Subagents inherently inherit the current sandbox policy of the parent session, ensuring a consistent security posture. For interactive command-line interface (CLI) sessions, approval requests stemming from inactive agent threads can be surfaced to the user, allowing for informed decisions before actions are taken. In non-interactive environments or when immediate approval isn't feasible, actions requiring new approval will fail, preventing unauthorized operations. Developers can also apply runtime overrides for sandbox and approval choices, and even configure individual custom agents with specific sandbox modes, such as 'read-only', for fine-grained control over their operational scope and access.
How can developers create and utilize custom agents within Codex?
Developers can define custom agents in Codex to tailor AI behavior to specific needs. This is achieved by creating standalone TOML configuration files under `~/.codex/agents/` for personal agents or `.codex/agents/` for project-scoped ones. Each TOML file defines a single custom agent and acts as a configuration layer, allowing developers to override default settings like model choice, reasoning effort, or sandbox mode. Essential fields such as 'name', 'description', and 'developer_instructions' are mandatory, guiding the agent's identity and core behavior. This flexibility enables the creation of highly specialized agents for unique development tasks, further enhancing the adaptability of the Codex system.
What global settings are available for managing subagent behavior in Codex?
Codex provides several global settings to manage subagent behavior, primarily located under the `[agents]` section in the configuration file. Key settings include `agents.max_threads`, which controls the maximum number of concurrent open agent threads (defaulting to 6); `agents.max_depth`, which limits the nesting depth of spawned agents (defaulting to 1 to prevent excessive recursion and resource consumption); and `agents.job_max_runtime_seconds`, which sets a default timeout for workers in `spawn_agents_on_csv` jobs (defaulting to 1800 seconds if not specified). These settings are crucial for balancing performance, resource usage, and control over complex agent workflows, helping developers prevent unintended fan-out and manage token consumption effectively.
What are the primary advantages of using subagents for complex tasks?
The primary advantages of using subagents for complex tasks within Codex lie in their ability to parallelize and specialize operations. By breaking down a large task into smaller, manageable subtasks and assigning each to a specialized agent, development teams can achieve significant speed improvements and higher quality outcomes. For instance, in a large codebase review, one subagent might focus on security vulnerabilities, another on code quality, and a third on performance bottlenecks simultaneously. This concurrent processing not only accelerates the overall task but also allows for deeper, more focused analysis in each area, leading to more robust and comprehensive solutions than a single, monolithic AI agent could provide.
Cập nhật tin tức
Nhận tin tức AI mới nhất qua email.