Cải thiện hiệu quả mã thông báo trong Quy trình làm việc đại lý GitHub

GitHub Agentic Workflows giống như một nhóm người quét đường dọn dẹp những mớ hỗn độn nhỏ trong kho lưu trữ của bạn. Các nhóm này cải thiện đáng kể chất lượng và vệ sinh kho lưu trữ, nhưng cũng như tất cả các công việc đại lý, chi phí là mối lo ngại ngày càng tăng đối với các nhà phát triển. Và vì các công việc CI như quy trình làm việc tổng đài được tự động lên lịch và kích hoạt nên chi phí có thể tích lũy ngoài tầm kiểm soát. Rất may, việc tự động hóa trở nên hiệu quả hơn sẽ dễ dàng hơn so với việc thực hiện tương tự đối với các phiên tương tác trên máy tính để bàn. Công việc được thực hiện trong phiên dành cho nhà phát triển có thể khó dự đoán nhưng công việc của quy trình làm việc tổng đài được chỉ định đầy đủ trong YAML và lặp lại mỗi lần thực thi. Vì chúng tôi duy trì và sử dụng Quy trình công việc đại lý GitHub trong kho lưu trữ GitHub của riêng mình nên chúng tôi cũng lo lắng về hiệu quả của mã thông báo cũng như người dùng của mình. Đó là lý do tại sao vào tháng 4 năm 2026, chúng tôi bắt đầu tối ưu hóa một cách có hệ thống việc sử dụng mã thông báo của nhiều quy trình làm việc mà chúng tôi dựa vào hàng ngày. Bài đăng này mô tả những gì chúng tôi đã thực hiện, những tối ưu hóa mà chúng tôi đã áp dụng và kết quả sơ bộ của chúng tôi. Ghi nhật ký sử dụng mã thông báo Chúng tôi dựa vào hàng trăm quy trình làm việc tổng đài trong kho lưu trữ của mình để bảo trì và CI. Tất cả quy trình công việc đều chạy dưới dạng Hành động GitHub theo giới hạn tốc độ API thực. Chúng tôi đang chế tạo chiếc máy bay khi chúng tôi bay và đốt nhiên liệu máy bay khi chúng tôi bay. Trước khi có thể tối ưu hóa mức tiêu thụ mã thông báo của mình, chúng tôi cần biết mã thông báo được tiêu thụ như thế nào. Thử thách đầu tiên mà chúng tôi gặp phải là mỗi khung tác nhân (Claude CLI, Copilot CLI, Codex CLI) phát ra nhật ký ở định dạng khác và dữ liệu sử dụng có thể không đầy đủ cho các lần chạy lịch sử. Rất may, kiến ​​trúc bảo mật luồng công việc tác nhân sử dụng proxy API để ngăn các tác nhân truy cập trực tiếp vào thông tin xác thực. Proxy này đã cho chúng tôi một cách để nắm bắt việc sử dụng mã thông báo trên tất cả các lần chạy ở một định dạng chuẩn hóa duy nhất, bất kể khung tác nhân. Giờ đây, mọi quy trình làm việc đều tạo ra một cấu phần phần mềm token-usage.jsonl với một bản ghi cho mỗi lệnh gọi API chứa mã thông báo đầu vào, mã thông báo đầu ra, mã thông báo đọc bộ nhớ đệm, mã thông báo ghi bộ nhớ đệm, mô hình, nhà cung cấp và dấu thời gian. Việc kết hợp dữ liệu này với phần còn lại của nhật ký quy trình làm việc đã mang lại cái nhìn lịch sử về cách chi tiêu mã thông báo thường và cho phép chúng tôi tối ưu hóa cho các lần chạy trong tương lai. Quy trình làm việc tối ưu hóa quy trình làm việc Với dữ liệu mã thông báo trong tay, chúng tôi đã xây dựng hai quy trình tối ưu hóa hàng ngày. Trình kiểm tra mức sử dụng mã thông báo hàng ngày đọc các thành phần sử dụng mã thông báo từ các lần chạy quy trình làm việc gần đây, tổng hợp mức tiêu thụ theo quy trình làm việc và đăng báo cáo có cấu trúc. Nhiệm vụ của nó là gắn cờ bất kỳ quy trình công việc nào đã tăng đáng kể mức sử dụng gần đây, hiển thị các quy trình công việc đắt tiền nhất và ghi lại các lần chạy bất thường (ví dụ: quy trình công việc thường hoàn thành trong bốn lượt LLM, mất 18). Khi Kiểm tra viên gắn cờ một quy trình công việc, Trình tối ưu hóa mã thông báo hàng ngày sẽ xem xét nguồn và nhật ký gần đây của quy trình công việc để tạo ra Vấn đề GitHub mô tả sự thiếu hiệu quả cụ thể và đề xuất tối ưu hóa cụ thể. Trình tối ưu hóa đã phát hiện thấy nhiều điểm kém hiệu quả mà lẽ ra chúng tôi đã bỏ qua. Tất nhiên, Bản thân Trình kiểm tra và Trình tối ưu hóa là các quy trình công việc tác nhân và việc sử dụng mã thông báo của chúng cũng xuất hiện trong các báo cáo hàng ngày để tạo ra một chu trình đạo đức nhỏ. Loại bỏ các công cụ MCP không sử dụng Dựa trên kết quả của Trình kiểm tra và Trình tối ưu hóa ban đầu của chúng tôi, sự kém hiệu quả phổ biến nhất là việc đăng ký công cụ MCP không được sử dụng. Vì API LLM không có trạng thái nên thời gian chạy tác nhân thường bao gồm tên hàm của công cụ MCP và lược đồ JSON với mỗi yêu cầu. Trong thực tế, điều này có nghĩa là bộ công cụ đầy đủ có thể trở thành một phần trong bối cảnh của mọi cuộc gọi. Đối với máy chủ GitHub MCP có 40 công cụ, điều này có thể thêm 10–15 KB lược đồ mỗi lượt. Nếu tác nhân chỉ sử dụng hai công cụ thì 38 công cụ còn lại là chi phí thuần túy được thêm vào mọi yêu cầu. Các tác giả quy trình làm việc đương nhiên bắt đầu với một bộ công cụ đầy đủ vì đây là con đường ít gặp trở ngại nhất và tổng đài viên có thể tìm ra công cụ nào mình cần. Nhưng theo thời gian, hầu hết các quy trình công việc đều dựa vào một bộ công cụ ổn định và hẹp. Trình tối ưu hóa xác định mẫu này bằng cách tham chiếu chéo các bảng kê khai công cụ dựa trên lệnh gọi công cụ thực tế và đề xuất loại bỏ các công cụ không sử dụng khỏi cấu hình. Trong quy trình kiểm tra khói của chúng tôi, việc xóa các công cụ không sử dụng khỏi cấu hình MCP đã giảm kích thước bối cảnh mỗi cuộc gọi xuống 8–12 KB, tiết kiệm vài nghìn mã thông báo mỗi lần chạy mà không thay đổi hành vi. Thay thế GitHub MCP bằng GitHub CLI Loại bỏ các công cụ MCP không sử dụng là một chiến thắng tương đối đơn giản. Một cơ hội mang tính cấu trúc lớn hơn là thay thế các lệnh gọi GitHub MCP cho các hoạt động tìm nạp dữ liệu như truy xuất các khác biệt trong yêu cầu kéo, nội dung tệp và xem xét nhận xét bằng các lệnh gọi tới GitHub CLI. Thay đổi này không chỉ làm giảm chi phí hoạt động của các công cụ không được sử dụng vì lệnh gọi công cụ MCP là một bước lý luận bên cạnh việc truy xuất dữ liệu. Tác nhân phải quyết định gọi công cụ, xây dựng các đối số của nó và nhận đầu ra của nó như một phần của ngữ cảnh. Đó là lệnh gọi API LLM khứ hồi đầy đủ, sử dụng mã thông báo cho lược đồ JSON sử dụng công cụ, khối đối số và phản hồi. Ngược lại, việc gọi gh pr diff là một yêu cầu HTTP mang tính xác định đối với API REST của GitHub mà không có sự tham gia của LLM. Chúng tôi đã sử dụng hai chiến lược cho việc di chuyển này: Tải xuống dữ liệu trước đại lý. Đối với dữ liệu mà tổng đài viên sẽ luôn cần như khác biệt về yêu cầu kéo hoặc danh sách các tệp đã thay đổi, chúng tôi đã thêm các bước thiết lập trong quy trình làm việc chạy lệnh gh trước khi tổng đài viên khởi động và ghi kết quả vào tệp không gian làm việc. Tác nhân đọc các tệp đó thay vì thực hiện cuộc gọi MCP. Điều này giúp loại bỏ chi phí gọi công cụ và cho phép tác nhân tận dụng chương trình đào tạo chuyên sâu về tập lệnh bash để xử lý dữ liệu một cách hiệu quả. Thay thế proxy CLI trong đại lý. Không thể tải xuống trước trong trường hợp tác nhân xác định nội dung cần tìm nạp trong thời gian chạy. Trong những trường hợp này, chúng tôi dựa vào proxy HTTP minh bạch nhẹ để định tuyến lưu lượng truy cập CLI đến máy chủ API của GitHub mà không hiển thị mã thông báo xác thực cho tác nhân. Tác nhân chạy gh pr view –json và lấy lại dữ liệu có cấu trúc, giống như cách người dùng thực hiện từ thiết bị đầu cuối. Điều này làm giảm việc sử dụng mã thông báo mà không ảnh hưởng đến yêu cầu bảo mật không bí mật của chúng tôi đối với đại lý. Cùng nhau, thứ