Bỏ qua để đến nội dung
Control Center
Gắn sao cho kho mã5Tải xuống
Menu

Vòng đời điều phối agent

Một lần điều phối là gì

Phần tiêu đề “Một lần điều phối là gì”

Một lần điều phối là một lượt chạy của một agent, trong một cuộc hội thoại, trên một adapter. Mọi thứ về nó đều diễn ra trên cc_server: máy khách gửi một tin nhắn rồi quan sát dòng sự kiện chảy ngược về. Không có đường điều phối nào trong bất kỳ máy khách nào.

Agent được đánh thức vì sáu lý do, và lượt chạy mang chúng dưới dạng ngữ cảnh đánh thức để agent biết vì sao nó thức:

Lý do đánh thức Trình kích hoạt
userMessage Ai đó gửi một tin nhắn trong một space, hoặc nhắc đến agent
assignment Một phiếu được giao cho agent
pipelineStep Một bước quy trình đã điều phối nó
childCompleted Một phiếu con đã hoàn tất
followUp Một nhịp tim theo dõi đã được lên lịch
recovery Đường khôi phục đã điều phối lại sau một thất bại

Ngữ cảnh đánh thức mang các id đi kèm lý do — phiếu, space, tin nhắn, lượt chạy quy trình — và chúng được tiêm vào môi trường cùng prompt của agent.

Lắp ghép prompt

Phần tiêu đề “Lắp ghép prompt”

Prompt được dựng theo từng lớp, mỗi lớp là một phần có nhãn:

  • Danh tính — id, tên và id không gian làm việc của chính agent, kèm chỉ dẫn rõ ràng phải truyền đúng những UUID đó cho các công cụ theo phạm vi không gian làm việc. Không gian làm việc vốn thuộc về agent, nên nó luôn hiện diện.
  • Danh mục công cụ và giao thức tài nguyên, rồi đến bố cục không gian làm việc.
  • Ghi đè prompt hệ thống, nếu agent có, rồi đến persona (được tham số hóa theo vai trò) và bản tóm tắt đội.
  • Skill — những tên gắn trên agent.
  • Hợp đồng thực thi và thủ tục cho chế độ hiện tại.
  • Ngữ cảnh đánh thức và ngữ cảnh nhắc đến: ai đã gọi agent và danh sách những người xung quanh nó.
  • Khối chế độ — được tạo từ hồ sơ năng lực của chế độ và danh sách công cụ đã được cụ thể hóa của nó, nên một prompt không bao giờ có thể nêu tên một công cụ mà lượt chạy thực sự không có.
  • Ngữ cảnh bộ nhớ — những dữ kiện được truy xuất cho nhiệm vụ.
  • Ngữ cảnh hội thoại — lịch sử gần đây của space, giới hạn ở 50.000 ký tự cửa sổ nguyên văn bất kể kích thước ngữ cảnh đã cấu hình của agent. Lịch sử cũ hơn không bị cắt bỏ: agent tự truy xuất khi cần bằng get_messages, và những tin nhắn cũ hơn có liên quan về ngữ nghĩa vẫn hiện ra.

Các lệnh được chia về hai nơi. /todo và /compact bị chặn ngay trong trình soạn và cố ý không bao giờ được lưu thành tin nhắn hay gửi tới agent — lưu /compact sẽ đẩy mốc cắt nén lùi lại một lượt và làm bẩn bản ghi hội thoại. /plan được xử lý ở cả hai: trình soạn đổi chế độ của space, và chính điều đó khiến bề mặt công cụ, preset rào chắn và prompt khớp nhau trong lượt này cùng mọi lượt sau. /goal, /loop và /skill:<name> được xử lý bên trong chính lượt chạy và chỉ trên harness tích hợp — /goal và /loop bắt đầu công việc tự chủ với một ngân sách chi phí, còn một tên có tiền tố skill: được tra như một skill mà phần thân SKILL.md trở thành chỉ thị của lượt. Chính không gian tên giữ hai bộ từ vựng tách rời nhau: tra một tên trần theo skill nghĩa là một skill tên plan hay compact bị lệnh tích hợp che khuất vĩnh viễn. Một tên trần không phải lệnh tích hợp vẫn được tra, dành cho những tin nhắn được viết trước khi không gian tên ra đời. Một tên không được nhận diện chỉ đơn giản rơi xuống thành văn bản thuần.

Chuẩn bị worktree

Phần tiêu đề “Chuẩn bị worktree”

Trước khi bất cứ thứ gì chạy, cuộc hội thoại có gốc làm việc riêng, với một worktree copy-on-write tách biệt cho mỗi repo nằm bên dưới nó. Mặc định đó là mọi repo được liên kết với không gian làm việc; một space PR — hoặc một space được tạo với lựa chọn rõ ràng — chỉ chuẩn bị những repo nằm trong danh sách cho phép, và một hội thoại rà soát PR ghim repo duy nhất của nó vào head ref của pull request trong khi những repo khác nằm trên nhánh mặc định. Bản checkout nguồn không bao giờ bị thay đổi, và toàn bộ thư mục hội thoại được thu hồi khi space bị xóa.

Copy-on-write là cách hiện thực duy nhất ở bất cứ đâu rift được phát hành, dựa trên thành phần native đi kèm. Một hệ thống tệp không thể reflink — hoặc một thư mục dữ liệu nằm trên ổ đĩa khác với repo — sẽ làm bước chuẩn bị thất bại thay vì dùng phương án dự phòng. git worktree là backend trên Windows, nơi không có backend copy-on-write để xây dựng, và đó không phải là sự xuống cấp âm thầm trên các máy chủ khác. Thiếu rift trên một nền tảng vốn có phát hành nó nghĩa là bản cài đặt hỏng — máy chủ từ chối khởi động thay vì lặng lẽ dự phòng, bởi một phương án dự phòng âm thầm sẽ mãi mãi che giấu hỏng hóc phía sau một đường chậm hơn.

Danh tính và thông tin xác thực

Phần tiêu đề “Danh tính và thông tin xác thực”

Hai danh tính được xác định cho mỗi lượt chạy, trước khi bất kỳ tiến trình nào khởi chạy.

Quyền tác giả Git. Các commit do agent tạo được ghi tác giả là chính agent — <Name> (agent) <agentId@agents.control-center.local> trong cả GIT_AUTHOR_* và GIT_COMMITTER_* — không bao giờ mạo danh con người. Phần local là UUID của agent, không phải slug tên của nó. Người yêu cầu được ghi công bằng một trailer Co-Authored-By:, được mang trong môi trường và hướng dẫn trong prompt hệ thống. Một danh tính do bên gọi đặt rõ ràng luôn thắng cả hai.

Danh tính forge. Thông tin xác thực GitHub của lượt chạy luôn chỉ là của broker — một token cài đặt App giới hạn theo repo, hoặc phương án dự phòng PAT từ môi trường — không bao giờ là token đã lưu của chính thành viên yêu cầu. actingUserId giới hạn phương án dự phòng PAT để một thành viên không phải chủ máy chủ không thừa hưởng phạm vi của máy chủ; nó không phủ một token cá nhân lên môi trường của agent.

Thông tin xác thực của nhà cung cấp mô hình được xác định theo một thứ tự cố định và thứ tự đó quan trọng:

  1. ghi đè môi trường theo từng adapter,
  2. môi trường của bên gọi,
  3. kho thông tin xác thực của máy chủ (làm mới một token OAuth nếu nó sắp hết hạn),
  4. môi trường của tiến trình.

Vì ghi đè theo từng adapter đứng đầu, nó âm thầm thắng một tài khoản nhà cung cấp đã kết nối trong ứng dụng. Nếu một lượt chạy đang tính phí vào sai tài khoản, ghi đè đó là nơi đầu tiên cần xem. Thông tin xác thực của nhà cung cấp là toàn cục theo máy chủ — dùng chung cho mọi không gian làm việc trong bản cài đặt.

Token GitHub của lượt chạy đến từ broker thông tin xác thực: một token chỉ đọc, giới hạn theo kho mã của worktree. Một lần push đi qua cổng lượt chạy agent, nơi hỏi quy tắc Push lên remote trước khi chuyển tiếp, và không có khóa ticketing nào được tiêm vào. Xem Sandbox và bảo mật.

Khởi chạy

Phần tiêu đề “Khởi chạy”

Lượt chạy được khởi tạo với worktree của nó làm thư mục làm việc và — với Claude Code — một cấu hình MCP được tạo để agent tiếp cận bề mặt công cụ của Control Center. ACP và bash của harness nhận một môi trường đã được làm sạch; Claude Code qua NoSandboxAdapter thừa hưởng môi trường của máy chủ.

Truyền phát

Phần tiêu đề “Truyền phát”

Lượt chạy truyền ngược về một chuỗi sự kiện có kiểu, mà bộ xử lý luồng lưu lại thành các delta tin nhắn, gấp thành các phân đoạn bản ghi hội thoại và biến thành các sự kiện nhắn tin:

Sự kiện Nội dung mang theo
thinking Đầu ra suy luận, được hiển thị nội tuyến
text Đầu ra hiển thị
toolCall Một lời gọi công cụ, kèm id và các đối số có cấu trúc
toolResult Kết quả tương ứng, được đánh dấu khi gặp lỗi hoặc là một luồng một phần
usage Số lượng token và chi phí cho một cửa sổ đo
error Một lỗi, kèm mã có cấu trúc của adapter khi adapter báo lỗi đó
sandboxViolation Hệ điều hành từ chối một syscall. Chỉ được phát ra ở nơi có sandbox thực sự bọc tiến trình — xem ghi chú ở trên
debug Chẩn đoán lúc chạy (dấu mốc khởi chạy, quyết định của rào chắn, nhắc nhở hợp đồng)
done Lượt chạy đã kết thúc

Điều gì giới hạn một lượt chạy

Phần tiêu đề “Điều gì giới hạn một lượt chạy”

Cố ý không có giới hạn số lượt ở bất cứ đâu. Một số vòng lặp cứng sẽ giết công việc dài chính đáng (di trú, dọn dẹp sau khi phân nhánh) mà chẳng bắt được gì sớm hơn những rào chắn bên dưới. Một lượt chạy kết thúc khi:

  • mô hình tự dừng;
  • một người dừng nó, hoặc tiếp quản cuộc hội thoại (việc này tạm dừng harness tích hợp ở ranh giới lượt sạch tiếp theo — còn một lượt chạy Claude Code, vốn không có ranh giới an toàn, thì bị dừng thay vì tạm dừng);
  • bộ giám sát im lặng kích hoạt. Không có đầu ra trong suốt ngưỡng thời gian thì phiên bị kết thúc với lỗi silentRun. Mặc định là 15 phút, giảm còn 10 ở những chế độ chủ yếu đọc (rà soát và kế hoạch); agent có thể ghi đè trong khoảng 1 đến 240 phút. Bộ giám sát được kích hoạt khi một tiến trình con báo PID của nó, nên nó bao được CLI Claude Code — không bao harness tích hợp, vốn không khởi tạo gì;
  • một trần chi phí có hiệu lực — nhưng chỉ với các lệnh tự chủ.

Rào chắn vòng lặp chết không phải là thứ chấm dứt: ba lời gọi công cụ giống hệt nhau liên tiếp và vòng lặp điều hướng agent đổi cách làm.

Gộp lại, một lượt tương tác thông thường trên harness tích hợp không có giới hạn số lượt, không có trần chi phí và không có bộ giám sát im lặng. Nó kết thúc khi mô hình dừng hoặc khi bạn dừng nó. Đó là một đánh đổi có chủ đích — mọi phương án thay thế đều giết công việc dài chính đáng — nhưng nó cũng có nghĩa là một lượt chạy tương tác không người trông chỉ bị giới hạn bởi chính phán đoán của mô hình.

Giữa lượt chạy, một tin nhắn gửi tới agent đang chạy được xếp hàng như điều hướng và được xử lý ở ranh giới lượt kế tiếp, nên bạn có thể thúc nhẹ một lượt chạy mà không giết nó. Điều hướng, tạm dừng, subagent và hợp đồng hoàn tất là những tính năng của harness tích hợp; Claude Code không có thứ nào trong số đó.

Cách một lượt chạy được ghi lại

Phần tiêu đề “Cách một lượt chạy được ghi lại”

Mỗi lần điều phối ghi một AgentRunLog: thời điểm bắt đầu và kết thúc, bản tóm tắt, số lượng token và chi phí ước tính (gồm chi phí tổng hợp từ các subagent), adapter và mô hình, id tiến trình và đường dẫn log, cuộc hội thoại cùng mọi phiếu hay lượt chạy quy trình mà nó thuộc về, cộng thêm hai trường phân loại mang phần lớn sự thật.

  • Trạng thái thì thô: pending, running, completed, error.
  • Độ sống là cách đọc chi tiết hơn: alive, productive, completed, blocked, empty, looping, failed, stalled, dead.
  • Nhóm lỗi gom các thất bại một cách hữu ích: transientUpstream, sandboxInfrastructure, budgetExceeded, processLost, silentRun, unknown.

Việc đóng lượt chạy phát AgentRunCompleted và rất nhiều thứ phụ thuộc vào nó: việc tổng hợp chi phí quy trình, việc tiếp tục một bước quy trình đang chờ lượt chạy, việc hoàn tất phiếu đứng sau, việc ánh xạ một điều phối sang một trạng thái cuối, quyết định tiếp tục hay dừng của bộ giám sát mục tiêu, vai trò trình kiểm tra và việc đánh giá ngân sách sau lượt chạy. Danh sách hiện diện theo sau một cách riêng, bằng cách quan sát các log lượt chạy gần đây thay vì sự kiện. Thông báo “Agent đã hoàn tất” không nằm trong danh sách đó: sự kiện được phát khi luồng của tiến trình kết thúc, trước khi câu trả lời được ghi, nên thông báo chính là MessageReceived của lượt hội thoại, được phát sau khi tin nhắn đã được lưu bền vững.

Ngân sách, sau khi việc đã rồi

Phần tiêu đề “Ngân sách, sau khi việc đã rồi”

Việc thi hành ngân sách là một phản ứng, không phải một cổng chặn. Khi một lượt chạy hoàn tất, bộ đánh giá so sánh chi tiêu từ đầu tháng đến nay của agent với mức trần hiệu dụng của nó (một chính sách ngân sách được liên kết nếu có, nếu không thì con số hàng tháng của chính agent; số không nghĩa là không giới hạn). Vượt ngưỡng mềm ghi lại một sự cố cảnh báo; cạn ngân sách ghi lại một sự cố cứng và đảo trạng thái vòng đời của agent thành paused trên sơ đồ tổ chức. Việc điều phối vẫn nhận công việc từ agent đó. Một trình kích hoạt quy trình BudgetThresholdCrossed có thể bắt đầu công việc tiếp nối từ chính sự kiện đó.

Dòng dõi thử lại

Phần tiêu đề “Dòng dõi thử lại”

Mỗi log lượt chạy có thể mang dòng dõi thử lại — id lượt chạy cha, một bộ đếm số lần thử và một bản tóm tắt tiếp nối. Cây lượt chạy của hội thoại hiển thị số lần thử khi nó khác không. Một lần “thử lại” từ chat là một lần điều phối mới với một log lượt chạy mới.

Các khái niệm liên quan

Phần tiêu đề “Các khái niệm liên quan”

Tùy chọn tài liệu

Giao diện
Ngôn ngữ
Tiếng Việt (Việt Nam)