Bỏ qua nội dung chính
OpenAI

23 tháng 1, 2026

Kỹ thuật

Tháo gỡ vòng lặp tác nhân Codex

Bởi Michael Bolin, Thành viên Nhóm Kỹ thuật

Đang tải…

Codex CLI⁠(mở trong cửa sổ mới) là tác nhân phần mềm cục bộ đa nền tảng của chúng tôi, được thiết kế để tạo ra các thay đổi phần mềm chất lượng cao, đáng tin cậy, đồng thời vận hành an toàn và hiệu quả trên máy của bạn. Chúng tôi đã học được rất nhiều về cách xây dựng một tác nhân phần mềm đẳng cấp thế giới kể từ khi lần đầu tiên ra mắt CLI vào tháng 4⁠. Để giải mã những hiểu biết đó, đây là bài viết đầu tiên trong một loạt bài viết liên tục, nơi chúng tôi sẽ khám phá nhiều khía cạnh khác nhau về cách Codex hoạt động, cũng như những bài học kinh nghiệm quý báu. (Để có cái nhìn chi tiết hơn nữa về cách thức Codex CLI được xây dựng, hãy xem kho lưu trữ mã nguồn mở của chúng tôi tại https://github.com/openai/codex⁠(mở trong cửa sổ mới). Nhiều chi tiết tinh tế hơn trong các quyết định thiết kế của chúng tôi được ghi lại trong các số phát hành và yêu cầu hợp nhất trên GitHub nếu bạn muốn tìm hiểu thêm.)

Để bắt đầu, chúng tôi sẽ tập trung vào vòng lặp tác nhân, đây là logic cốt lõi trong Codex CLI chịu trách nhiệm điều phối sự tương tác giữa người dùng, mô hình và các công cụ mà mô hình gọi để thực hiện công việc phần mềm có ý nghĩa. Chúng tôi hy vọng bài đăng này sẽ giúp bạn có cái nhìn rõ ràng về vai trò mà tác nhân của chúng tôi (hoặc “lớp khai thác”) đóng trong việc sử dụng một mô hình ngôn ngữ lớn (LLM).

Trước khi đi sâu vào, xin lưu ý nhanh về thuật ngữ: tại OpenAI, “Codex” bao gồm một bộ các sản phẩm tác nhân phần mềm, bao gồm Codex CLI, Codex Cloud và tiện ích mở rộng Codex VS Code. Bài viết này tập trung vào lớp khai thác của Codex, cung cấp vòng lặp tác nhân cốt lõi và logic thực thi làm nền tảng cho mọi trải nghiệm Codex và được hiển thị thông qua Codex CLI. Để thuận tiện ở đây, chúng tôi sẽ sử dụng các thuật ngữ “Codex” và “Codex CLI” thay thế cho nhau.

Vòng lặp tác nhân

Trung tâm của mỗi tác nhân AI là một thứ được gọi là “vòng lặp tác nhân.” Một minh họa đơn giản hóa của vòng lặp tác nhân trông như thế này:

Sơ đồ có tiêu đề “Vòng lặp tác nhân” minh họa cách một hệ thống AI xử lý yêu cầu của người dùng, gọi các công cụ, quan sát kết quả, cập nhật kế hoạch và trả về kết quả. Các mũi tên kết nối các bước như thông tin đầu vào của người dùng, suy luận của mô hình, hành động của công cụ và phản hồi cuối cùng.

Để bắt đầu, tác nhân lấy thông tin đầu vào từ người dùng để đưa vào tập hợp các hướng dẫn bằng văn bản mà nó chuẩn bị cho mô hình được gọi là câu lệnh.

Bước tiếp theo là truy vấn mô hình đó bằng cách gửi cho nó hướng dẫn của chúng ta và yêu cầu mô hình tạo ra một phản hồi, một quy trình được gọi là suy luận. Trong quá trình suy luận, câu lệnh văn bản trước tiên được chuyển đổi thành một chuỗi token⁠(mở trong cửa sổ mới) thông tin đầu vào—là các số nguyên dùng để lập chỉ mục ánh xạ đến khu vực từ vựng của mô hình. Sau đó, các token này được sử dụng để lấy mẫu từ mô hình, tạo ra một chuỗi token đầu ra mới.

Các token đầu ra được dịch ngược lại thành văn bản, trở thành phản hồi của mô hình. Vì các token được tạo ra dần dần, bản dịch này có thể diễn ra khi mô hình đang chạy, đó là lý do tại sao nhiều ứng dụng dựa trên LLM hiển thị đầu ra dạng luồng phát. Trong thực tế, chức năng suy luận thường được đóng gói phía sau một API hoạt động trên văn bản, trừu tượng hóa các chi tiết của việc phân tách token.

Là kết quả của bước suy luận, mô hình (1) tạo ra một phản hồi cuối cùng dành cho thông tin đầu vào ban đầu của người dùng, hoặc (2) yêu cầu một lệnh gọi công cụ mà tác nhân được kỳ vọng sẽ thực hiện (ví dụ: “chạy ls và báo cáo kết quả đầu ra”). Trong trường hợp (2), tác nhân thực hiện lệnh gọi công cụ và thêm thông tin đầu ra của nó vào câu lệnh gốc. Thông tin đầu ra này được sử dụng để tạo một thông tin đầu vào mới nhằm truy vấn lại mô hình; tác nhân sau đó có thể xem xét thông tin mới này và thử lại.

Quá trình này lặp lại cho đến khi mô hình ngừng phát ra các lệnh gọi công cụ và thay vào đó tạo ra một thông điệp cho người dùng (được gọi là thông điệp trợ lý trong các mô hình OpenAI). Trong nhiều trường hợp, thông điệp này trực tiếp trả lời yêu cầu ban đầu của người dùng, nhưng cũng có thể là một câu hỏi tiếp theo cho người dùng.

Vì tác nhân có thể thực hiện các lệnh gọi công cụ làm thay đổi môi trường cục bộ, “thông tin đầu ra” không chỉ giới hạn ở thông điệp của trợ lý. Trong nhiều trường hợp, thông tin đầu ra chính của một tác nhân phần mềm là mã mà nó viết hoặc chỉnh sửa trên máy của bạn. Tuy nhiên, mỗi lượt luôn kết thúc bằng một thông điệp của trợ lý—như “Tôi đã thêm architecture.md mà bạn yêu cầu”—điều này báo hiệu một trạng thái kết thúc trong vòng lặp tác nhân. Từ góc nhìn của tác nhân, công việc của nó đã hoàn tất và quyền kiểm soát được trả lại cho người dùng.

Hành trình từ thông tin đầu vào của người dùng đến phản hồi của tác nhân được hiển thị trong sơ đồ được gọi là một lượt của một cuộc trò chuyện (một chuỗi trong Codex). Mặc dù lượt hội thoại này có thể bao gồm nhiều lần lặp giữa suy luận mô hình và lệnh gọi công cụ. Mỗi lần bạn gửi một tin nhắn mới vào một cuộc trò chuyện hiện có, lịch sử cuộc trò chuyện sẽ được đưa vào như một phần của câu lệnh cho lượt mới, bao gồm các tin nhắn và các lệnh gọi công cụ từ các lượt trước:

Sơ đồ có tiêu đề “Vòng lặp tác nhân nhiều lượt” minh họa cách một tác nhân AI lặp lại việc tiếp nhận thông tin đầu vào từ người dùng, tạo ra hành động, tham khảo công cụ, cập nhật trạng thái và trả về kết quả. Bao gồm các bước được dán nhãn, mũi tên và đầu ra công cụ ví dụ minh họa chu trình suy luận của tác nhân.

Điều này có nghĩa là khi cuộc trò chuyện phát triển, độ dài của câu lệnh dùng để lấy mẫu từ mô hình cũng tăng lên. Độ dài này quan trọng vì mỗi mô hình có một cửa sổ ngữ cảnh, đó là số lượng token tối đa mà nó có thể sử dụng cho một lần gọi lệnh suy luận. Lưu ý rằng cửa sổ này bao gồm cả token thông tin đầu vào và token đầu ra. Như bạn có thể hình dung, một tác nhân có thể quyết định thực hiện hàng trăm lần gọi công cụ trong một lượt, có khả năng làm cạn kiệt cửa sổ ngữ cảnh. Vì lý do này, quản lý cửa sổ ngữ cảnh là một trong nhiều trách nhiệm của tác nhân. Bây giờ, hãy cùng khám phá cách Codex thực hiện vòng lặp tác nhân.

Suy luận mô hình

Codex CLI gửi các yêu cầu HTTP đến API Phản hồi⁠(mở trong cửa sổ mới) để thực hiện suy luận mô hình. Chúng ta sẽ xem xét cách thông tin luân chuyển qua Codex, sử dụng API Phản hồi để điều khiển vòng lặp tác nhân.

Điểm cuối API Phản hồi mà Codex CLI sử dụng là có thể cấu hình⁠(mở trong cửa sổ mới), vì vậy nó có thể được sử dụng với bất kỳ dịch vụ điểm cuối nào thực hiện API Phản hồi⁠(mở trong cửa sổ mới):

Hãy cùng khám phá cách Codex tạo câu lệnh cho lần gọi suy luận đầu tiên trong một cuộc trò chuyện.

Xây dựng câu lệnh ban đầu

Là người dùng cuối, bạn không cần chỉ định nguyên văn câu lệnh được sử dụng để lấy mẫu mô hình khi bạn truy vấn API Phản hồi. Thay vào đó, bạn chỉ định nhiều loại thông tin đầu vào khác nhau như một phần của truy vấn, và máy chủ API phản hồi sẽ quyết định cách cấu trúc thông tin này thành một câu lệnh mà mô hình được thiết kế để tiếp nhận. Bạn có thể coi câu lệnh như một “danh sách các mục”; phần này sẽ giải thích cách truy vấn của bạn được chuyển đổi thành danh sách đó.

Trong câu lệnh ban đầu, mỗi mục trong danh sách đều được gắn với một vai trò. Vai trò cho biết mức độ quan trọng mà nội dung liên quan nên có và là một trong các giá trị sau (theo thứ tự ưu tiên giảm dần): hệ thống, nhà phát triển, người dùng, trợ lý.

API Phản hồi⁠(mở trong cửa sổ mới) nhận một gói dữ liệu JSON với nhiều tham số. Chúng tôi sẽ tập trung vào ba điều này:

Trong Codex, trường hướng dẫn được đọc từ model_instructions_file⁠(mở trong cửa sổ mới) trong ~/.codex/config.toml, nếu được chỉ định; nếu không, hương dẫn cơ sở liên quan đến một mô hình⁠(mở trong cửa sổ mới) được sử dụng. Hướng dẫn cụ thể cho từng mô hình nằm trong kho lưu trữ Codex và được tích hợp vào CLI (ví dụ: gpt-5.2-codex_prompt.md⁠(mở trong cửa sổ mới)).

Trường công cụ là một danh sách các định nghĩa công cụ tuân theo một lược đồ được xác định bởi API Phản hồi. Đối với Codex, điều này bao gồm các công cụ được cung cấp bởi Codex CLI, các công cụ được cung cấp bởi API Phản hồi cần được cung cấp cho Codex, cũng như các công cụ do người dùng cung cấp, thường thông qua các máy chủ MCP:

JavaScript

1
[
2
  // Codex's default shell tool for spawning new processes locally.
3
  {
4
    "type": "function",
5
    "name": "shell",
6
    "description": "Runs a shell command and returns its output...",
7
    "strict": false,
8
    "parameters": {
9
      "type": "object",
10
      "properties": {
11
        "command": {"type": "array", "description": "The command to execute", ...},
12
        "workdir": {"description": "The working directory...", ...},
13
        "timeout_ms": {"description": "The timeout for the command...", ...},
14
        ...
15
      },
16
      "required": ["command"],
17
    }
18
  }
19

20
  // Codex's built-in plan tool.
21
  {
22
    "type": "function",
23
    "name": "update_plan",
24
    "description": "Updates the task plan...",
25
    "strict": false,
26
    "parameters": {
27
      "type": "object",
28
      "properties": {"plan":..., "explanation":...},
29
      "required": ["plan"]
30
    }
31
  },
32

33
  // Web search tool provided by the Responses API.
34
  {
35
    "type": "web_search",
36
    "external_web_access": false
37
  },
38

39
  // MCP server for getting weather as configured in the
40
  // user's ~/.codex/config.toml.
41
  {
42
    "type": "function",
43
    "name": "mcp__weather__get-forecast",
44
    "description": "Get weather alerts for a US state",
45
    "strict": false,
46
    "parameters": {
47
      "type": "object",
48
      "properties": {"latitude": {...}, "longitude": {...}},
49
      "required": ["latitude", "longitude"]
50
    }
51
  }
52
]

Cuối cùng, trường thông tin đầu vào của JSON payload là một danh sách các mục. Codex chèn các mục sau⁠(mở trong cửa sổ mới) vào thông tin đầu vào trước khi thêm tin nhắn của bạn:

1. Một thông điệp với role=developer mô tả môi trường thử nghiệm chỉ áp dụng cho công cụ shell do Codex cung cấp được định nghĩa trong phần công cụ. Nghĩa là, các công cụ khác, chẳng hạn như những công cụ được cung cấp từ các máy chủ MCP, không được Codex đưa vào môi trường thử nghiệm và phải tự chịu trách nhiệm thực thi các biện pháp bảo vệ của riêng mình.

Thông điệp được xây dựng từ một mẫu, trong đó các phần nội dung chính đến từ các đoạn mã Markdown được tích hợp trong Codex CLI, chẳng hạn như workspace_write.md⁠(mở trong cửa sổ mới) và on_request.md⁠(mở trong cửa sổ mới):

Văn bản thuần túy

1
<permissions instructions>
2
  - description of the sandbox explaining file permissions and network access
3
  - instructions for when to ask the user for permissions to run a shell command
4
  - list of folders writable by Codex, if any
5
</permissions instructions>

2. (Tùy chọn) Một tin nhắn với role=developer có nội dung là giá trị developer_instructions được đọc từ tệp config.toml của người dùng.

3. (Tùy chọn) Một tin nhắn có role=user với nội dung là “hướng dẫn của người dùng”, không được lấy từ một tệp duy nhất mà được tổng hợp từ nhiều nguồn⁠(mở trong cửa sổ mới). Nhìn chung, các hướng dẫn cụ thể hơn sẽ xuất hiện sau:

4. Một thông điệp với role=user mô tả môi trường cục bộ mà tác nhân hiện đang hoạt động. Điều này chỉ định thư mục làm việc hiện tại và shell của người dùng⁠(mở trong cửa sổ mới):

Văn bản thuần túy

1
<environment_context>
2
  <cwd>/Users/mbolin/code/codex5</cwd>
3
  <shell>zsh</shell>
4
</environment_context>

Sau khi Codex đã thực hiện tất cả các phép tính trên để khởi tạo thông tin đầu vào, nó sẽ thêm tin nhắn của người dùng để bắt đầu cuộc trò chuyện.

Các ví dụ trước tập trung vào nội dung của từng tin nhắn, nhưng lưu ý rằng mỗi phần tử của thông tin đầu vào là một đối tượng JSON với các thuộc tính loại, vai trò⁠(mở trong cửa sổ mới), và nội dung như sau:

JSON

1
{
2
  "type": "message",
3
  "role": "user",
4
  "content": [
5
    {
6
      "type": "input_text",
7
      "text": "Add an architecture diagram to the README.md"
8
    }
9
  ]
10
}

Khi Codex hoàn thành việc xây dựng toàn bộ gói dữ liệu JSON để gửi đến API Phản hồi, nó sẽ thực hiện yêu cầu HTTP POST với tiêu đề Ủy quyền tùy thuộc vào cách điểm cuối API Phản hồi được cấu hình trong ~/.codex/config.toml (các tiêu đề HTTP bổ sung và tham số truy vấn sẽ được thêm nếu được chỉ định).

Khi một máy chủ OpenAI API Phản hồi nhận được yêu cầu, nó sử dụng JSON để suy ra câu lệnh cho mô hình như sau (để đảm bảo, một triển khai tùy chỉnh của API Phản hồi có thể đưa ra lựa chọn khác):

Sơ đồ ảnh chụp nhanh thể hiện một bước duy nhất trong vòng lặp của tác nhân AI. Một yêu cầu của người dùng đi vào mô hình, tạo ra một suy nghĩ, một hành động với tên công cụ và một thông tin đầu vào công cụ. Sơ đồ làm nổi bật bước suy luận trung gian này trước khi công cụ được gọi.

Như bạn có thể thấy, thứ tự của ba mục đầu tiên trong câu lệnh được xác định bởi máy chủ, không phải máy khách. Tuy nhiên, trong ba mục đó, chỉ có nội dung của system message cũng do máy chủ kiểm soát, vì tools và instructions do máy khách quyết định. Tiếp theo là thông tin đầu vào từ tải trọng JSON để hoàn tất câu lệnh.

Bây giờ chúng ta đã có câu lệnh, chúng ta đã sẵn sàng để lấy mẫu từ mô hình.

Lần rẽ đầu tiên

Yêu cầu HTTP này tới API Phản hồi khởi tạo “lượt” đầu tiên của một cuộc trò chuyện trong Codex. Máy chủ phản hồi với một luồng Sự kiện Gửi từ Máy chủ (SSE⁠(mở trong cửa sổ mới)). data của mỗi sự kiện là một payload JSON với "type" bắt đầu bằng "response", có thể trông như thế này (danh sách đầy đủ các sự kiện có thể được tìm thấy trong tài liệu API⁠(mở trong cửa sổ mới)):

Văn bản thuần túy

1
data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2
data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3
data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4
data: {"type":"response.output_item.added", "item":{...}}
5
data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6
data: {"type":"response.output_text.delta", "delta":"two!", ...}
7
data: {"type":"response.completed","response":{...}}

Codex tiêu thụ luồng sự kiện⁠(mở trong cửa sổ mới) và xuất bản lại chúng dưới dạng các đối tượng sự kiện nội bộ có thể được khách hàng sử dụng. Các sự kiện như response.output_text.delta được sử dụng để hỗ trợ phát trực tuyến trong giao diện người dùng, trong khi các sự kiện khác như response.output_item.added được chuyển đổi thành các đối tượng được thêm vào thông tin đầu vào cho các lần gọi API phản hồi tiếp theo.

Giả sử yêu cầu đầu tiên tới API Phản hồi bao gồm hai sự kiện response.output_item.done: một sự kiện có type=suy luận và một sự kiện có type=function_call. Các sự kiện này phải được biểu diễn trong trường thông tin đầu vào của JSON khi bạn truy vấn lại mô hình với phản hồi cho lệnh gọi công cụ: 

JavaScript

1
[
2
  /* ... original 5 items from the input array ... */
3
  {
4
    "type": "reasoning",
5
    "summary": [
6
      "type": "summary_text",
7
      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8
    ],
9
    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10
  },
11
  {
12
    "type": "function_call",
13
    "name": "shell",
14
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15
    "call_id": "call_8675309..."
16
  },
17
  {
18
    "type": "function_call_output",
19
    "call_id": "call_8675309...",
20
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21
  }
22
]

Câu lệnh kết quả được sử dụng để lấy mẫu mô hình như một phần của truy vấn tiếp theo sẽ có dạng như sau:

Sơ đồ có nhãn “Snapshot 2” thể hiện một tác nhân AI sau khi thực hiện cuộc gọi công cụ. Mô hình nhận được một quan sát từ công cụ và tạo ra một suy nghĩ và hành động mới. Các mũi tên kết nối các thông tin đầu vào, quan sát và đầu ra để minh họa cách tác nhân lặp lại vòng lặp suy luận của mô hình này.

Đặc biệt, hãy lưu ý cách mà câu lệnh cũ là một tiền tố chính xác của câu lệnh mới. Điều này là có chủ ý, vì nó giúp các yêu cầu tiếp theo hiệu quả hơn nhiều do cho phép chúng tôi tận dụng bộ nhớ đệm câu lệnh (mà chúng tôi sẽ thảo luận trong phần tiếp theo về hiệu suất).

Nhìn lại sơ đồ đầu tiên của chúng ta về vòng lặp tác nhân, chúng ta thấy rằng có thể có nhiều lần lặp giữa suy luận và gọi công cụ. Câu lệnh có thể tiếp tục phát triển cho đến khi cuối cùng chúng tôi nhận được một tin nhắn trợ lý, cho biết kết thúc lượt:

Văn bản thuần túy

1
data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2
data: {"type":"response.completed","response":{...}}

Trong Codex CLI, chúng tôi hiển thị tin nhắn của trợ lý cho người dùng và tập trung vào trình soạn thảo để thông báo rằng đã đến “lượt” của họ để tiếp tục cuộc trò chuyện. Nếu người dùng phản hồi, cả tin nhắn của trợ lý từ lượt trước và tin nhắn mới của người dùng phải được thêm vào thông tin đầu vào trong yêu cầu API Phản hồi để bắt đầu lượt mới:

JavaScript

1
[
2
  /* ... all items from the last Responses API request ... */
3
  {
4
    "type": "message",
5
    "role": "assistant",
6
    "content": [
7
      {
8
        "type": "output_text",
9
        "text": "I added a diagram to explain the client/server architecture."
10
      }
11
    ]
12
  },
13
  {
14
    "type": "message",
15
    "role": "user",
16
    "content": [
17
      {
18
        "type": "input_text",
19
        "text": "That's not bad, but the diagram is missing the bike shed."
20
      }
21
    ]
22
  }
23
]

Một lần nữa, vì chúng ta đang tiếp tục một cuộc trò chuyện, độ dài của thông tin đầu vào mà chúng ta gửi đến API Phản hồi cứ tăng lên:

Sơ đồ có nhãn “Snapshot 3” thể hiện giai đoạn cuối cùng của vòng lặp tác nhân AI. Sau khi nhận được kết quả từ công cụ, mô hình tạo ra một suy nghĩ kết luận và một câu trả lời cuối cùng được trả về cho người sử dụng. Các mũi tên minh họa sự chuyển tiếp từ đầu ra của công cụ đến phản hồi đã hoàn thành.

Hãy xem xét câu lệnh ngày càng phát triển này có ý nghĩa gì đối với hiệu suất.

Những cân nhắc về hiệu suất

Có thể bạn đang tự hỏi, “Khoan đã, chẳng phải vòng lặp tác nhân có độ tăng bậc hai xét theo lượng JSON được gửi đến API Phản hồi trong suốt cuộc trò chuyện sao?” Và bạn đã đúng. Mặc dù API Phản hồi có hỗ trợ tham số tùy chọn previous_response_id⁠(mở trong cửa sổ mới) để giảm thiểu vấn đề này, Codex hiện không sử dụng nó, chủ yếu để giữ cho các yêu cầu hoàn toàn không trạng thái và để hỗ trợ các cấu hình Không lưu giữ dữ liệu (ZDR).

Việc tránh sử dụng previous_response_id giúp đơn giản hóa cho nhà cung cấp API Phản hồi vì nó đảm bảo mọi yêu cầu đều không lưu trạng thái. Điều này cũng giúp việc hỗ trợ khách hàng đã chọn tham gia Không lưu giữ dữ liệu (ZDR)⁠(mở trong cửa sổ mới) trở nên đơn giản, vì việc lưu trữ dữ liệu cần thiết để hỗ trợ previous_response_id sẽ mâu thuẫn với ZDR. Lưu ý khách hàng ZDR không phải hy sinh khả năng hưởng lợi từ các thông điệp suy luận độc quyền từ các lượt trước, vì encrypted_content liên quan có thể được giải mã trên máy chủ. (OpenAI lưu giữ khóa giải mã của khách hàng ZDR, nhưng không lưu trữ dữ liệu của họ.) Xem các PR #642⁠(mở trong cửa sổ mới) và #1641⁠(mở trong cửa sổ mới) để biết các thay đổi liên quan đến Codex nhằm hỗ trợ ZDR.

Nhìn chung, chi phí lấy mẫu từ mô hình chiếm ưu thế so với chi phí lưu lượng mạng, khiến việc lấy mẫu trở thành mục tiêu chính trong các nỗ lực nâng cao hiệu quả của chúng tôi. Đây là lý do tại sao việc lưu vào bộ nhớ đệm câu lệnh lại quan trọng như vậy, vì nó cho phép chúng ta tái sử dụng phần tính toán từ một lần gọi suy luận trước đó. Khi chúng tôi có các lần truy cập bộ nhớ đệm, việc lấy mẫu từ mô hình là tuyến tính thay vì bậc hai. Tài liệu bộ nhớ đệm câu lệnh ⁠(mở trong cửa sổ mới)của chúng tôi giải thích điều này chi tiết hơn:

Các lần truy cập bộ nhớ đệm chỉ có thể xảy ra đối với các trường hợp khớp tiền tố chính xác trong một câu lệnh. Để tận dụng lợi ích của bộ nhớ đệm, hãy đặt nội dung tĩnh như hướng dẫn và ví dụ ở đầu câu lệnh của bạn, và đặt nội dung biến đổi, chẳng hạn như thông tin dành riêng cho người dùng, ở cuối. Điều này cũng áp dụng cho hình ảnh và công cụ, phải giống hệt nhau giữa các yêu cầu.

Với điều này trong tâm trí, hãy xem xét những loại thao tác nào có thể gây ra “không tận dụng được bộ nhớ đệm" trong Codex:

  • Thay đổi các công cụ có sẵn cho mô hình trong quá trình hội thoại.
  • Thay đổi mô hình là mục tiêu của yêu cầu API Phản hồi (trên thực tế, điều này sẽ thay đổi mục thứ ba trong câu lệnh gốc, vì nó chứa các hướng dẫn dành riêng cho mô hình).
  • Thay đổi cấu hình môi trường thử nghiệm, chế độ phê duyệt hoặc thư mục làm việc hiện tại.

Nhóm Codex phải thận trọng khi giới thiệu các tính năng mới trong Codex CLI có thể làm ảnh hưởng đến việc lưu đệm câu lệnh. Ví dụ, việc hỗ trợ ban đầu của chúng tôi cho các công cụ MCP đã dẫn đến một lỗi khi chúng tôi không liệt kê các công cụ theo một thứ tự nhất quán⁠(mở trong cửa sổ mới), gây ra lỗi bộ nhớ đệm. Lưu ý các công cụ MCP có thể đặc biệt khó khăn vì các máy chủ MCP có thể thay đổi danh sách công cụ mà chúng cung cấp ngay lập tức thông qua thông báo notifications/tools/list_changed⁠(mở trong cửa sổ mới). Việc xử lý thông báo này giữa chừng trong một cuộc trò chuyện dài có thể gây ra một lỗi bộ nhớ cache tốn kém.

Khi có thể, chúng tôi xử lý các thay đổi cấu hình xảy ra giữa cuộc hội thoại bằng cách thêm một thông báo mới vào thông tin đầu vào để phản ánh sự thay đổi thay vì sửa đổi một thông báo trước đó:

  • Nếu cấu hình sandbox hoặc chế độ phê duyệt thay đổi, chúng tôi chèn⁠(mở trong cửa sổ mới) một thông báo role=developer mới với cùng định dạng như mục <hướng dẫn cho phép> ban đầu.
  • Nếu thư mục làm việc hiện tại thay đổi, chúng tôi chèn⁠(mở trong cửa sổ mới) một tin nhắn role=user mới với cùng định dạng như tin nhắn <environment_context> ban đầu.

Chúng tôi nỗ lực hết sức để đảm bảo các lần truy cập bộ nhớ đệm nhằm tối ưu hóa hiệu suất. Có một tài nguyên quan trọng khác mà chúng ta phải quản lý: cửa sổ ngữ cảnh.

Chiến lược chung của chúng tôi để tránh hết cửa sổ ngữ cảnh là nén cuộc trò chuyện khi số lượng token vượt quá một ngưỡng nhất định. Cụ thể, chúng tôi thay thế thông tin đầu vào bằng một danh sách mục mới, nhỏ hơn, đại diện cho cuộc trò chuyện, cho phép tác nhân tiếp tục với sự hiểu biết về những gì đã xảy ra cho đến nay. Một phiên bản triển khai tính năng nén⁠(mở trong cửa sổ mới) ban đầu yêu cầu người dùng phải tự mình thực hiện lệnh /compact, lệnh này sẽ truy vấn API Phản hồi bằng cách sử dụng cuộc hội thoại hiện có cùng với hướng dẫn tùy chỉnh cho việc tóm tắt⁠(mở trong cửa sổ mới). Codex đã sử dụng tin nhắn trợ lý kết quả chứa bản tóm tắt làm thông tin đầu vào mới⁠(mở trong cửa sổ mới) cho các lượt hội thoại tiếp theo.

Kể từ đó, API Phản hồi đã phát triển để hỗ trợ một /responses/compact điểm cuối⁠(mở trong cửa sổ mới) đặc biệt, thực hiện việc nén hiệu quả hơn. Hệ thống trả về một danh sách các mục⁠(mở trong cửa sổ mới) có thể được sử dụng thay cho thông tin đầu vào trước đó để tiếp tục cuộc trò chuyện đồng thời giải phóng cửa sổ ngữ cảnh. Danh sách này bao gồm một mục type=compaction đặc biệt với một mục encrypted_content không rõ ràng, giúp bảo toàn sự hiểu biết tiềm ẩn của mô hình về cuộc trò chuyện ban đầu. Hiện tại, Codex tự động sử dụng điểm cuối này để nén cuộc trò chuyện khi auto_compact_limit⁠(mở trong cửa sổ mới) bị vượt quá.

Sắp tới

Chúng tôi đã giới thiệu vòng lặp tác nhân Codex và hướng dẫn cách Codex xây dựng và quản lý ngữ cảnh của nó khi truy vấn một mô hình. Trong suốt quá trình, chúng tôi đã nêu bật các cân nhắc thực tiễn và những thực hành tốt nhất áp dụng cho bất kỳ ai xây dựng một vòng lặp tác nhân trên nền tảng API Phản hồi.

Mặc dù vòng lặp tác nhân cung cấp nền tảng cho Codex, nhưng đó chỉ là sự khởi đầu. Trong các bài đăng sắp tới, chúng tôi sẽ đi sâu vào kiến trúc của CLI, khám phá cách triển khai việc sử dụng công cụ, và xem xét kỹ lưỡng hơn mô hình thử nghiệm của Codex.

Tác giả

Michael Bolin

Lời cảm ơn

Xin gửi lời cảm ơn đặc biệt đến toàn bộ đội ngũ đã xây dựng Codex CLI.

Hãy tiếp tục xem

Xem tất cả
Tax Agent > Art Card
Xây dựng tác nhân thuế tự cải thiện với Codex

Kỹ thuật

codex windows > art card
Xây dựng sandbox an toàn, hiệu quả để hỗ trợ Codex trên Windows

Kỹ thuật

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Kỹ thuật