Tôi đã tự chạy một kỹ sư AI của riêng mình. Tôi giao một task và một repo; một executor chạy trên Claude Agent SDK sẽ lập plan, viết code, chạy test, tự review diff của nó, rồi mở pull request. Tôi gọi nó là Origin, và nó chạy hoàn toàn trên máy của tôi.

Rồi tôi muốn thêm cloud agent của Cursor — cái VM cloud cô lập của họ, tốc độ của composer, và một dàn model (grok, opus, gpt) mà tôi không tự host. Câu hỏi hiển nhiên là “chọn cái nào làm chuẩn?” Đó là câu hỏi sai. Câu trả lời đúng hoá ra là: đừng chọn executor — hãy làm cho nó tháo lắp được.

Cách nghĩ lại đó chính là toàn bộ câu chuyện. Một khi đã dựng xong lớp orchestration, thêm một engine thứ hai — kể cả một engine hosted của bên thứ ba — không phải viết lại. Nó chỉ là một adapter mỏng. Đây là hình dạng của nó.

Orchestrator mới là nền tảng; executor chỉ là plug-in

Một agent platform thực ra là hai thứ tách rời được: surface + orchestrator — cách giao task, theo dõi, review, chấm eval, quản ngân sách — và executor, cái thực sự làm việc. Toàn bộ sự khác biệt của tôi nằm ở phần đầu. Phần thứ hai nên là phần tháo lắp được.

flowchart TD
  subgraph Platform["Nền tảng của tôi — phần tôi sở hữu"]
    S["Surface: chat · bảng task · issues"]
    O["Orchestrator: state, review, evals, ngân sách, luồng PR"]
  end
  O --> REG{"Engine registry"}
  REG -->|self-host| C["Claude Agent SDK<br/>(máy của tôi)"]
  REG -->|hosted| CUR["Cursor Cloud Agents<br/>(VM của họ)"]
  REG -->|local| L["Model local<br/>(Ollama)"]
  C --> PR([Pull request])
  CUR --> PR
  L --> PR

Nền tảng của tôi vốn đã có một engine registry — ba cái. Thêm Cursor nghĩa là thêm giá trị thứ tư, cursor, và dạy orchestrator biết làm gì khi thấy nó. Không có gì phía trên registry thay đổi: cùng bảng task, cùng reviewer, cùng eval, cùng luồng review PR.

Một “integration agent” gồm bốn mảnh nhỏ

Bọc một coding agent hosted thành một engine hạng nhất cần đúng bốn phần. Đây là công thức tái dùng được.

Connector là phần code thật sự duy nhất, và nó nhỏ vì Cloud Agents API của Cursor rất hợp cho việc này:

sequenceDiagram
  participant P as Nền tảng của tôi
  participant A as api.cursor.com
  participant G as GitHub
  P->>A: POST /v1/agents {prompt, repo, model, autoCreatePR}
  A->>G: clone repo vào VM cô lập
  A-->>P: {id, latestRunId, status}
  loop tới khi kết thúc
    P->>A: GET /v1/agents/{id}/runs/{runId}
    A-->>P: {status, result, git.branches[].prUrl}
  end
  A->>G: push nhánh + mở PR
  P-->>P: hiện link PR lên run

Launch với một prompt và một repo, poll cái run tới khi có prUrl, hiện nó lên. Đó là toàn bộ hợp đồng. Connector của tôi phơi ra một helper blocking kèm callback on_event, nên bảng task stream trực tiếp các trạng thái của Cursor — y hệt engine self-host của tôi.

Một surface, chọn theo từng task

Vì engine chỉ là một trường trên task, lựa chọn là theo-từng-task, không phải theo-nền-tảng. Ô chọn engineer trên bảng task của tôi liệt kê cả hai:

Cùng kanban, cùng assignee/label/comment, cùng đồng bộ GitHub issue, cùng review PR. Tôi chọn engine như chọn một runtime.

Được gì — ba cái lợi cụ thể

• Không lock-in. Hãng là một executor, không phải nền tảng của tôi. Cursor đổi giá hay đổi hành vi thì tôi lật một trường, không phải di trú cả workflow.
• Một màn hình duy nhất. Run hosted và self-host dùng chung bảng task, event stream, bộ eval, và luồng review. Tôi so engine trên bộ golden set của mình, không phải theo lời quảng cáo của họ.
• Tích hợp rẻ. Bất kỳ agent hosted nào có REST API kiểu launch-and-poll đều lắp vừa bốn khe đó. Phần đắt — orchestrator — tôi chỉ dựng một lần.

Ý cuối mới là bài học thật. Ngành này liên tục ra executor tốt hơn; đó là món quà, không phải mối đe doạ, miễn là nền tảng của tôi coi chúng là thay thế được cho nhau. Tôi dựng surface và orchestration mình muốn bất kể ai đứng sau, đăng ký các engine như plug-in, và giờ cái tốt nhất thắng theo từng task.