Làm Cùng Long.
← Quay lại Kho ghi chú
Automation & AI Workflow · 10 phút đọc ·

Agent Client Protocol (ACP) và BYOA: IDE đang trở thành môi trường làm việc chung của nhiều AI agent

Trong nhiều IDE, trải nghiệm AI trước đây thường gắn khá chặt theo một chuỗi:

IDE → assistant tích hợp sẵn → model/provider.

Muốn đổi assistant, bạn có thể phải đổi extension, đổi workflow hoặc mất một phần context đặc thù của IDE.

Android Studio đang thử một hướng khác.

Từ bản Rabbit 2 canary, Google bắt đầu rollout preview của Bring Your Own Agent — BYOA, cho phép kết nối các coding agent như Claude Agent, OpenAI Codex và Google Antigravity trực tiếp vào Android Studio.

Tin dễ thấy là “Android Studio hỗ trợ nhiều agent”.

Phần đáng chú ý hơn là lớp phía dưới:

Agent Client Protocol — ACP.

ACP giúp IDE và agent nói chuyện với nhau theo một giao diện chung hơn, thay vì mỗi agent phải tích hợp riêng toàn bộ context và toolchain của IDE.

Mục lục

1. BYOA thực sự thay đổi điều gì?

Google mô tả BYOA theo bốn lợi ích chính.

Codebase awareness và token efficiency

Android Studio có thể cung cấp project graph, build setup và thông tin platform cho agent qua ACP.

Thay vì agent tự quét toàn bộ repository rồi đoán file nào liên quan, IDE đã có sẵn rất nhiều cấu trúc mà compiler, build system và editor đang biết.

Agent có thể dùng lớp context đó để lọc phần cần xem.

Workflow continuity

Người dùng có thể chuyển giữa prompt với agent và các tool của Android Studio mà không tách hoàn toàn thành hai thế giới.

Agent flexibility

Google nói người dùng có thể kết nối bất kỳ agent nào tương thích ACP. Nếu một agent hết quota hoặc không đáp ứng kỳ vọng, có thể chuyển sang agent khác.

Native tool injection

Agent có thể được cấp các công cụ như:

  • build diagnostics;
  • Jetpack Compose Previews;
  • Android SDK tools;
  • emulator control.

Đây là phần làm BYOA khác với việc chỉ “mở terminal chạy CLI agent bên cạnh IDE”.

2. ACP đang giải quyết bài toán nào?

Zed, nơi khởi xướng ACP, mô tả protocol này như một chuẩn mở giúp agent tích hợp với editing environment.

Có thể hiểu theo mô hình:

User
  ↓
IDE / client
  ↓ ACP
Agent
  ↓
Model / tools / subagents

Trong sơ đồ này, IDE không chỉ là một cửa sổ chat.

IDE có thể giữ:

  • codebase state;
  • file selection;
  • diagnostics;
  • build state;
  • visual preview;
  • terminal;
  • test output;
  • permission UX.

Agent nhận được môi trường làm việc giàu context hơn.

Điểm này rất quan trọng với coding.

Một model nhìn một đoạn code riêng lẻ và một agent hiểu toàn bộ project state là hai mức năng lực khác nhau.

3. ACP khác MCP ở đâu?

ACP và MCP dễ bị đặt cạnh nhau vì đều là “protocol cho agent”, nhưng chúng không nên bị xem là cùng một lớp.

Một cách hiểu thực dụng:

ACP

Tập trung vào kết nối agent ↔ client/editing environment.

Ví dụ Android Studio đưa project context và native tools cho agent.

MCP

Thường tập trung vào kết nối agent/model ↔ tool/data/service.

Ví dụ agent truy cập documentation server, database, GitHub hoặc một API qua MCP.

Có thể hình dung:

IDE
  │
 ACP
  │
Agent
  │
 MCP
  │
Tools / Data / Services

Đây chỉ là mô hình tư duy, không phải yêu cầu rằng mọi hệ thống phải xếp chính xác như vậy.

Nhưng nó giúp tránh một hiểu nhầm:

ACP không “thay MCP”, và MCP cũng không giải quyết toàn bộ bài toán tích hợp agent vào IDE.

Hai protocol có thể bổ sung nhau.

4. IDE context có giá trị hơn một prompt dài như thế nào?

Giả sử bạn hỏi:

“Vì sao app này build lỗi sau khi nâng SDK?”

Nếu agent chỉ có prompt, nó phải tự tìm:

  • build.gradle ở đâu;
  • module nào liên quan;
  • SDK version hiện tại;
  • dependency nào conflict;
  • lỗi compiler/build tool là gì;
  • source file nào bị ảnh hưởng.

Một IDE đã biết phần lớn những thứ đó.

Do đó, cách hiệu quả hơn không phải luôn là:

“Cho agent thêm context window.”

Mà là:

“Cho agent structured access tới context mà environment đã có.”

Đây là một ví dụ điển hình của Context Engineering.

Context tốt không nhất thiết là nhiều token.

Context tốt có thể là:

  • một project graph;
  • một diagnostic object;
  • một list dependency;
  • một test result;
  • một preview state.

Tức là thông tin giàu cấu trúc hơn, không chỉ văn bản dài hơn.

5. Native tool injection: agent không chỉ đọc code

Một coding agent chỉ edit file vẫn là automation khá hạn chế.

Để hoàn thành task end-to-end, agent thường cần vòng lặp:

hiểu yêu cầu
→ sửa code
→ build
→ đọc lỗi
→ chạy test
→ xem UI
→ sửa tiếp
→ verify

Android Studio đang cho agent tiếp cận chính những tool cần cho vòng lặp này.

Google nêu các capability như:

  • read/write/edit file;
  • shell;
  • test;
  • web search;
  • subagents;
  • build diagnostics;
  • Compose preview;
  • Android SDK tool;
  • emulator control.

Giá trị không nằm ở số lượng tool.

Giá trị nằm ở việc feedback loop được khép kín.

Nếu agent sửa code nhưng không thấy build error, người dùng vẫn phải làm bridge.

Nếu agent thấy error nhưng không chạy lại test, vòng lặp vẫn chưa khép.

Khi toolchain native được expose, agent có cơ hội tự hoàn tất nhiều bước hơn trước khi trả lại cho con người.

6. Multi-agent không có nghĩa mọi agent giống nhau

BYOA có thể tạo cảm giác rằng agent sẽ trở thành commodity: cứ ACP-compliant là thay nhau được.

Tôi nghĩ cần cẩn trọng với kết luận đó.

Hai agent có thể cùng nói ACP nhưng vẫn khác nhau ở:

  • model;
  • agent harness;
  • planning;
  • memory;
  • subagent architecture;
  • tool selection;
  • permission defaults;
  • context compaction;
  • cost;
  • quota;
  • failure behavior.

Protocol chung giúp giảm integration friction.

Nó không xóa behavioral difference.

Tương tự trình duyệt đều hiểu HTTP nhưng không phải mọi ứng dụng web giống nhau.

Do đó, khi đánh giá agent trong cùng một IDE, cần đo task thực tế:

  • tỷ lệ hoàn thành;
  • số vòng sửa;
  • token/cost;
  • thời gian;
  • regression;
  • mức can thiệp của con người.

Đừng chỉ benchmark model.

Benchmark agent + environment + workflow.

7. Permission trở thành một phần của UX

Google nhấn mạnh granular permissions: routine work có thể tự chạy, action rủi ro có thể dừng để xin approval.

Đây là hướng rất quan trọng.

Với agent, permission không còn là một setting ẩn trong admin panel.

Nó trở thành một phần của trải nghiệm làm việc.

Một UX tốt phải giúp người dùng biết:

  • agent đang muốn làm gì;
  • vì sao cần quyền đó;
  • phạm vi action;
  • action có reversible không;
  • có thể preview diff không;
  • hậu quả nếu thất bại;
  • cách rollback.

Tôi thường chia action thành ba tầng.

Tầng 1 — Read / inspect

Có thể tự động rộng hơn.

Tầng 2 — Modify local / reversible

Có thể cho auto-run với log và diff.

Tầng 3 — External / production / destructive

Cần approval rõ hơn.

Ví dụ:

đọc code ≠ sửa local file ≠ push branch ≠ merge main ≠ deploy production.

Một agent “tốt” không nên coi tất cả là một loại quyền.

8. Kiến trúc nào có thể xuất hiện từ mô hình này?

Nếu ACP được nhiều editor và agent triển khai tốt, một kiến trúc thú vị có thể hình thành:

Work surface ổn định

IDE/editor giữ context, permission và UX.

Agent có thể thay

Tùy task, quota hoặc chất lượng.

Model có thể route

Agent có thể dùng model khác cho task khác.

Tool/data layer độc lập

Qua MCP, API hoặc native tool.

Skills/plugin độc lập

Capability package có thể được cài cho nhiều client.

Sơ đồ:

IDE / Work Surface
      ↓ ACP
  Agent Harness
      ↓
  Model Router
   ↙       ↘
Skills     MCP
            ↓
      Tools / Data

Đây là một kiến trúc ít lock-in hơn so với một assistant monolithic.

Nhưng đổi lại, orchestration và governance phức tạp hơn.

9. Bài học khi xây hệ thống agent ngoài IDE

Ngay cả khi không làm Android, có ba bài học đáng lấy.

1. Đừng bắt agent tự khám phá thứ hệ thống đã biết

Nếu CRM đã có schema, đưa schema.

Nếu Ads account đã có campaign map, đưa campaign map.

Nếu Sheet đã có data dictionary, expose nó.

Không cần agent đoán từ raw data mỗi lần.

2. Context nên được cấp qua interface có cấu trúc

Object, schema, API và registry thường tốt hơn dán một tài liệu dài.

3. Human control cần nằm ở nơi người dùng đang làm việc

Nếu approval nằm ở một dashboard khác quá xa workflow, người dùng dễ bypass hoặc bỏ qua.

Đó là lý do IDE là vị trí hợp lý để hiển thị diff, test, quyền và action.

Trong marketing automation cũng vậy: approval nên ở Chat/Sheet/CRM nơi người vận hành thực sự dùng, không nhất thiết ở một admin panel riêng.

10. Khi nào BYOA thực sự có giá trị?

BYOA không tự động tốt hơn built-in agent.

Nó tạo giá trị khi ít nhất một trong các điều này đúng:

  • team đã chuẩn hóa agent khác;
  • cần linh hoạt theo quota/provider;
  • có enterprise agent riêng;
  • muốn giữ IDE context nhưng không khóa assistant;
  • cần so sánh agent theo task;
  • có policy chọn agent/model khác nhau.

Nếu một người chỉ dùng một agent, một IDE và workload đơn giản, built-in vẫn có thể là lựa chọn ít ma sát hơn.

Điều tôi quan tâm là hướng kiến trúc.

Android Studio đang gửi một tín hiệu khá rõ:

IDE có thể trở thành nền tảng cho agent, thay vì bản thân IDE phải sở hữu duy nhất một agent.

Khi đó lợi thế của IDE nằm ở context, toolchain, permission và feedback loop.

Còn agent trở thành một lớp có thể lựa chọn.

Đây là một thay đổi nhỏ về giao diện, nhưng có thể là thay đổi lớn về cách hệ sinh thái coding AI được tổ chức.

Đọc tiếp trong Series Agentic Stack 2026

Nguồn tham khảo