Kỹ thuật tác nhân với Claude Code và Android CLI

Xin chào, tôi là Ben, thuộc nhóm Quan hệ với nhà phát triển Android.

Tôi là Steven, nhà quản lý sản phẩm.

Hôm nay, chúng ta sẽ nói về việc tạo ứng dụng bằng Claude Code và Android CLI, theo cách tự động.

Vì vậy, tôi nghĩ có thể nói rằng vai trò của chúng ta với tư cách là nhà phát triển đang thay đổi một chút và mọi thứ đang diễn ra cực kỳ nhanh, nhanh đến mức, thành thật mà nói, nội dung trong bài nói chuyện này có lẽ đã lỗi thời, đặc biệt là nếu bạn đang xem trực tuyến.

Vì vậy, chúng tôi đã có một lập trường tiến bộ với những gì chúng tôi viết, với thông tin chúng tôi trình bày, nhưng các bản minh hoạ mà họ chạy hôm nay, chúng dựa trên thực tế, vì vậy chúng sẽ đáng tin cậy ngay bây giờ.

Một điều nữa là chúng tôi đã sử dụng Claude Code cho bài nói chuyện này, nhưng thông tin này không phụ thuộc vào tác nhân.

Đây là một tư duy, vì vậy, bạn nên áp dụng tư duy này cho bất cứ công cụ nào bạn muốn sử dụng khi xây dựng ứng dụng.

Vì vậy, chúng tôi muốn bạn bắt đầu nghĩ về một thế giới nơi bạn quản lý các nhóm tác nhân tự động và cách bạn thiết lập chúng để đạt được thành công.

Khi AI không triển khai được một tính năng hoặc điều gì đó tương tự, thay vì bỏ cuộc và nghĩ rằng "Ồ, AI chưa làm được việc này", chúng ta cần lùi lại và suy nghĩ xem thông tin nào còn thiếu, rồi xử lý vấn đề đó như cách chúng ta xử lý lỗi hiện nay.

Nếu đã đọc bất kỳ thông tin nào từ các nhóm tạo ra những khung vận hành tác nhân này, như Claude Code, Codex, Antigravity, bạn sẽ thấy rằng đây chính là cách các nhóm đó phát triển những khung vận hành này. Nếu coi đó là một cái nhìn thoáng qua về tương lai, thì có lẽ đó là hướng đi chung của tất cả chúng ta.

Vì vậy, có lẽ đây là thời điểm thú vị nhất để trở thành một nhà phát triển Android, nhưng nếu giống tôi, bạn có thể thấy khó biết chính xác nên tập trung vào điều gì.

Và chúng ta, với tư cách là nhà phát triển, cần có các công cụ và quy trình làm việc thực sự có thể mở rộng quy mô một cách thông minh, để khi một mô hình mới mở rộng ranh giới, tất cả công sức của chúng ta không trở nên thừa thãi.

Chúng tôi muốn mỗi lần cải tiến mô hình đều giúp các nhân viên hỗ trợ có quy trình làm việc thông minh hơn, từ đó mang lại kết quả tốt hơn cho người dùng.

Hôm nay, chúng ta sẽ tìm hiểu 4 chủ đề.

Trước tiên, chúng tôi sẽ giải thích lý do bạn cần thiết lập môi trường phù hợp để nhân viên hỗ trợ có thể làm việc hiệu quả.

Sau đó, chúng tôi sẽ cung cấp thông tin tổng quan về bối cảnh và cách quản lý bối cảnh hiệu quả nhất.

Sau đó, chúng ta sẽ tìm hiểu một số công cụ tốt nhất hiện có cho nhà phát triển Android làm việc trong các tác nhân và cuối cùng, chúng ta sẽ đưa ra lý do để thêm vòng lặp vào quy trình làm việc của tác nhân.

Được rồi, hãy cùng tìm hiểu nhé.

Vậy, môi trường.

Nhưng điều đó thực sự có nghĩa là gì?

Như tôi đã nói, chúng tôi đang cố gắng tạo ra một không gian nơi tác nhân của chúng tôi có thể thành công mà bạn không cần phải ngồi đó và liên tục nhắc lại cũng như đưa tác nhân trở lại đúng hướng. Vì khi làm được điều đó, bạn sẽ có thể chạy các tác nhân song song và đó là lúc bạn thực sự đạt được hiệu suất cao, khi bạn có thể có các nhóm tác nhân này làm tất cả công việc cho bạn.

Nhưng điều đó không chỉ dừng lại ở việc có quyền truy cập vào mã.

Họ cần có quyền truy cập vào tài liệu chính xác, bao gồm thông số kỹ thuật của dự án và quy tắc về cách làm việc trong dự án đó.

Đó là điều hiển nhiên.

Một số người đang kết nối tác nhân với không gian trò chuyện của nhóm, không chỉ để khởi động tác nhân mà còn để cung cấp bối cảnh về cách đưa ra quyết định dẫn đến tính năng mà họ được giao nhiệm vụ thực hiện. Vì là nhà phát triển, đó là loại thông tin tiềm thức mà bạn sử dụng khi giải quyết vấn đề, nên thông tin đó cũng có thể hữu ích cho tác nhân của bạn.

Cũng như nhật ký quyết định trước đây và yêu cầu lấy dữ liệu.

Họ có thể xem các nhận xét mà bạn nhận được về yêu cầu kéo, những điều họ được thông báo, những điều tương tự, sau đó bạn sẽ thấy họ có thể làm việc và khắc phục điều đó.

Ngoài ra, bạn không thể viết mã Android nếu không có quyền truy cập vào thiết bị hoặc trình mô phỏng, vì vậy, bạn cũng không nên mong đợi tác nhân của mình có thể làm được điều đó.

Tôi biết các thiết bị này có vẻ rất tuyệt vời và có thể làm được mọi thứ, nhưng trình mô phỏng thực sự hữu ích.

Tương tự với trình phân tích tài nguyên.

Nếu bạn muốn họ cải thiện hiệu suất, họ phải có khả năng phân tích, tức là phải có quyền truy cập vào một thiết bị thực.

Và bất kỳ dịch vụ phụ trợ nào mà ứng dụng của bạn sử dụng, lý tưởng nhất là tác nhân của bạn cũng có thể giao tiếp với các dịch vụ đó.

Đó là lúc bạn cần đến Android CLI.

Nếu bạn chưa từng nghe nói đến, thì Android CLI cũng đã được đề cập trong bài nói chuyện về Tính năng mới trong công cụ. Android CLI là CLI mới của chúng tôi để giao tiếp với nhiều công cụ Android.

Bản thân nó không phải là một sản phẩm AI, mà chỉ là một CLI, một giao diện dòng lệnh.

Vì vậy, nó cung cấp cho bạn quyền truy cập vào những thứ như Trình quản lý SDK Android, có thể khởi động trình mô phỏng, rất nhiều thứ.

Công cụ này cũng kết nối với các công cụ và phần phụ trợ như Crashlytics.

Công cụ này hoạt động trên mọi tác nhân bạn đang sử dụng, chỉ cần nằm trong không gian shell của bạn.

Vậy nên, đúng vậy.

Bạn có thể cài đặt tiện ích này tại đường liên kết này, nhưng tôi nghĩ sẽ dễ dàng hơn nếu chúng ta xem cách tiện ích này hoạt động.

Được rồi.

Vì vậy, thay vì chỉ giải thích lý do tại sao việc thiết lập tác nhân để thành công lại quan trọng, chúng tôi muốn thực sự áp dụng nguyên tắc này vào một ứng dụng chính thức mà chúng tôi đã xây dựng có tên là Sideline.

Còn Sideline là một ứng dụng Android dành cho người chơi quần vợt, cung cấp cho họ thông tin phản hồi theo thời gian thực về vị trí bóng, vị trí người chơi, vị trí sân.

Ứng dụng này cung cấp ý kiến phản hồi huấn luyện khi không có mạng thông qua tính năng phát lại video, đồng thời cung cấp dữ liệu thể chất cho những thông tin như tốc độ nhanh nhất, quãng đường đã di chuyển và những pha bóng bền lâu nhất.

Tất cả đều được hỗ trợ thông qua các mô hình TF Lite tuỳ chỉnh chạy trực tiếp trên thiết bị Android.

Trước tiên, tôi muốn nói rằng chúng tôi không thể giải quyết những vấn đề mà chúng tôi không biết là có tồn tại.

Vì vậy, chúng tôi đã sử dụng Android CLI để thêm Firebase Crashlytics vào môi trường phát triển của mình. Nhờ đó, chúng tôi có thể tìm thấy một số vấn đề mà chúng tôi thậm chí còn không biết là đang xảy ra.

Vấn đề đầu tiên là lỗi ứng dụng không phản hồi (ANR) xảy ra trên thiết bị Pixel 11 Pro Fold, nhưng không tái hiện được trong trình mô phỏng.

May mắn là Android CLI có hỗ trợ tính năng Truyền trực tuyến thiết bị Android.

Sau khi chúng tôi yêu cầu tác nhân khắc phục vấn đề này, tác nhân đã tạo một kết nối đến thiết bị xảy ra lỗi ANR. Điều này đặc biệt hữu ích cho tôi vì tại thời điểm đó, tôi thậm chí không có Pixel 11 Pro Fold để xác thực bản sửa lỗi.

Vì vậy, bằng cách cho phép tác nhân truy cập vào thiết bị cần thiết để xác thực bản sửa lỗi, chúng tôi đã có thể mở rộng khả năng của tác nhân.

Để tiết kiệm thời gian, tôi đã chạy trước tất cả các thử nghiệm và tóm tắt chúng tại đây.

Và không đi quá sâu vào chi tiết, vấn đề mà chúng tôi gặp phải là một lệnh gọi tương đồng liên quan đến Android 17.

Đó là một bản sửa lỗi nhanh gồm hai dòng, có vẻ ổn đối với tôi.

setenv("KMP_AFFINITY", "disabled", 1);
setenv("KMP_INIT_AT_FORK", "false", 1);

Vì vậy, tôi đã tạo yêu cầu lấy dữ liệu, hợp nhất và cập nhật bằng một bản dựng mới được gửi đến Play.

Vì vậy, nếu không thiết lập môi trường lập trình với các chức năng cần thiết để thành công, chúng tôi sẽ không thể xác định được vấn đề thực sự cũng như không thể xác thực bản sửa lỗi.

Vì vậy, với bản dựng 1.0, bạn có thể thấy vấn đề đã được giải quyết.

Tuy nhiên, các vấn đề mới đã phát sinh và chúng ta sẽ giải quyết sau.

Được rồi.

Tiếp theo: bối cảnh.

Vì vậy, khoảng 1 năm rưỡi, 2 năm trước, không phải là thời gian quá dài, nhưng trong không gian AI, đó là cả một đời, đã có cuộc đua này để có cửa sổ ngữ cảnh ngày càng lớn hơn, và lý thuyết là, chúng ta càng có thể ném vào mô hình, chúng ta sẽ nhận được kết quả tốt hơn, và chúng tôi đã làm những điều điên rồ như chúng tôi đã cố gắng đưa toàn bộ developer.android.com vào câu lệnh, nhưng không thực sự hiệu quả.

Nhưng ngay cả khi cửa sổ ngữ cảnh phần lớn đã chững lại, khả năng của mô hình vẫn đang tăng lên.

Vậy nên, đây là Android Bench 1.0.

Android Bench là điểm chuẩn của chúng tôi để đánh giá khả năng viết mã Android của AI.

Các nhiệm vụ trong đó đều thực tế.

Đó là những điều mà bạn cần nỗ lực, và chúng ta có thể thấy cửa sổ ngữ cảnh đã đạt đến mức 1 triệu, nhưng khả năng của mô hình vẫn tiếp tục tăng.

Nhưng bối cảnh vẫn là ngân sách cố định và bạn muốn tiết kiệm ngân sách cho những việc quan trọng.

Bạn không nên đưa vào đó những nội dung không giúp giải quyết vấn đề cụ thể mà bạn đang xử lý.

Và nhiều khung vận hành tác nhân thực ra không cung cấp cho bạn toàn bộ cửa sổ ngữ cảnh 1 triệu token vì họ thấy việc đó không có ý nghĩa.

Kết quả chỉ tệ hơn khi họ làm vậy.

Và thực ra có một điểm tối ưu, và điểm này thay đổi tuỳ theo mô hình, nhưng nếu bạn có thể giữ cho các cuộc trò chuyện của mình ở mức khoảng 150.000 token, thì đó là lúc bạn khai thác được toàn bộ sức mạnh của mô hình mà không bị mất ngữ cảnh.

Nhưng ngữ cảnh không chỉ là những gì bạn đang nhập.

[
  {
    "role": "system",
    "content": "You are an expert Android engineering agent..."
  },
  {
    "role": "workspace_context",
    "content": { "project_root": "/workspace/android-app", "build_system": "Gradle (Kotlin DSL)", "target_sdk": 35 }
  },
  {
    "role": "available_tools",
    "content": [ { "name": "read_file" }, { "name": "edit_file" }, { "name": "bash" }, { "name": "skill_android_cli" } ]
  },
  {
    "role": "user",
    "content": "ProfileViewModelTest is failing when loading errors. Fix the ViewModel and verify with unit tests."
  },
  {
    "role": "assistant",
    "tool_calls": [ { "name": "read_file", "arguments": { "path": "app/src/main/.../ProfileViewModel.kt" } } ]
  },
  {
    "role": "tool",
    "content": "class ProfileViewModel(...) : ViewModel() { ... // full file contents + Gradle output appended here }"
  }
]

Thực ra, có rất nhiều việc diễn ra thầm lặng mà bạn không thấy.

Nó được tạo thành từ một số phần.

Đầu tiên là chỉ dẫn hệ thống.

Chỉ dẫn hệ thống do nhân viên hỗ trợ của bạn cung cấp.

Nó giống như một câu lệnh cho tác nhân biết cách hoạt động, kiểu hành vi mà tác nhân nên thực hiện.

Ngoài ra, còn có thông tin về không gian làm việc, chẳng hạn như thư mục làm việc hiện tại, các SDK bạn có, mọi kỹ năng đã cài đặt (chúng ta sẽ nói về vấn đề này sau) và các công cụ MCP, cũng như mọi công cụ do tác nhân của bạn cung cấp.

Mô hình cần biết rằng nó có thể gọi các hàm đó, vì vậy, việc này sẽ chiếm ngữ cảnh.

Nhưng điều quan trọng là toàn bộ nhật ký tin nhắn và lệnh gọi công cụ sẽ được gửi cùng với mọi câu lệnh, mọi tin nhắn mới mà bạn gửi cho nhân viên hỗ trợ.

Và điều đó có thể thực sự tăng lên, đặc biệt là với Gradle.

Tôi nghĩ, như chúng ta đều biết, nhật ký Gradle thực sự rất dài, rất dài và rất chi tiết.

Hầu hết các thông tin đó đều không bắt buộc.

Sau đây là một mẹo nhanh để bạn lưu ý vấn đề đó.

Bạn có thể chạy Gradle ở chế độ im lặng.

./gradlew assembleDebug --quiet

Hoặc các khung vận hành tác nhân lớn hơn sẽ cắt bớt thông tin này cho bạn.

Vì vậy, Claude Code và Android Studio, chúng tôi không gửi toàn bộ nhật ký Gradle.

Nhưng nếu bạn đang sử dụng một trong những tác nhân tối giản, vì triết lý của chúng là gửi mọi thứ đến mô hình, mô hình biết rõ nhất, nên mini-SWE-agent sẽ gửi toàn bộ nhật ký Gradle đó và điều này có thể nhanh chóng trở nên rất tốn kém.

Nhưng làm thế nào để chúng ta duy trì trong phạm vi 150.000 này?

Chìa khoá là sử dụng quy trình công việc.

Và có rất nhiều quy trình công việc.

Tôi rất thích một người tên là Matt Pocock, anh ấy có một loạt kỹ năng giúp bạn quản lý các phiên này.

Vì vậy, hãy bắt đầu với kỹ năng có tên là "grill-me".

Bạn sẽ chạy kỹ năng này khi mới bắt đầu một dự án hoặc chỉ một tính năng mới trong dự án, và kỹ năng này sẽ yêu cầu tác nhân hỏi bạn một loạt câu hỏi.

Vì vậy, bạn có thể nói "hỏi tôi đi".

Tôi muốn tạo một trình quản lý chuông báo mới trong ứng dụng của mình."

Sau đó, Gemini sẽ bắt đầu đặt câu hỏi ngược lại cho bạn, chẳng hạn như chúng ta nên triển khai tính năng này bằng ngôn ngữ nào, tính năng này thuộc về đâu.

Và nó giúp loại bỏ tất cả những điều mơ hồ khỏi vấn đề và khỏi đầu bạn, đưa chúng vào một vấn đề cụ thể.

Sau đó, chúng tôi chạy kỹ năng tiếp theo, đó là viết một tài liệu đặc tả lớn.

Có một kỹ năng khác giúp chia nhỏ bản ghi thành các vấn đề, sau đó chúng tôi sẽ lưu các vấn đề đó vào bất kỳ trình quản lý vấn đề nào mà bạn muốn sử dụng.

Sau đó,ý tưởng là mỗi vấn đề trong số đó phải phù hợp với khoảng 150.000 cửa sổ.

Sau đó, bạn chọn một vấn đề, dù là đang làm việc trong thiết bị đầu cuối hay IDE, tuỳ theo ý muốn, xây dựng, xác minh vòng lặp, chúng tôi sẽ xoá bối cảnh ở cuối, không còn nhật ký trò chuyện và chúng tôi vẫn ở trong cửa sổ.

Được rồi.

Tiếp theo, hãy nói về AGENTS.md.

AGENTS.md là nơi bạn có thể cung cấp thêm thông tin cho tác nhân, áp dụng cho bất kỳ vấn đề nào mà tác nhân đang xử lý trong dự án này hoặc trong toàn bộ không gian làm việc của bạn, nếu bạn chọn làm như vậy.

Tuy nhiên, vì thông tin này được cung cấp cho mọi câu lệnh, nên bạn chỉ nên đưa vào những thông tin áp dụng được trong mọi trường hợp.

Vì vậy, những quy tắc về cấu trúc và mô-đun sẽ có hiệu quả.

Đó là những thông tin mà tác nhân của bạn không thể biết, đặc biệt là nếu bạn làm việc trên một ứng dụng nguồn đóng.

Nhưng điều quan trọng là bạn phải hiểu rõ để không phải suy nghĩ ngay từ đầu về việc tính năng này thuộc về đâu.

Vì vậy, bạn có thể đưa những thứ như thành phần giao diện người dùng vào mô-đun hệ thống thiết kế, hoặc một thứ khác cũng rất hiệu quả là các lỗi thường gặp khi xem xét mã, hoặc chỉ là những thứ phổ biến mà bạn đang chọn và phải nhập mọi lúc.

# AGENTS.md

- UI components belong in :core:designsystem

- Never use java.util.Date;
  always use kotlinx.datetime

## General guidance
- Avoid changing public API signatures. Anything under an `internal` directory
  is not part of the public API and may change freely.
- The SDK code is written for Java 8.

Vì vậy, bạn biết đấy, trong dự án này, chúng tôi muốn sử dụng kotlinx.datetime, những thứ tương tự như vậy.

Tôi thực sự muốn đưa ra những phương pháp hay nhất luôn áp dụng được, nhưng thực tế là điều này thay đổi theo từng bản phát hành mô hình.

Mỗi mô hình có hành vi khác nhau khi xử lý bối cảnh bổ sung.

Ví dụ: trong Opus 4.6, việc sử dụng chữ in hoa lớn để nói "Đừng bao giờ làm điều này" là rất phổ biến.

Và khi Opus 5 ra mắt, Anthropic đã đưa ra một tuyên bố rằng: "Thực ra, chữ in hoa không còn hiệu quả nữa.

Chỉ sử dụng chữ thường."

Và đây là điều tôi muốn nói: bạn phải luôn nắm bắt được tình hình.

Tuy nhiên, có một số điều luôn đúng, đó là hãy giữ cho nội dung ngắn gọn.

Vì vậy, hãy giữ cho tệp này có dưới 250 dòng.

Và điều tiếp theo này có thể gây tranh cãi, vì tôi biết nhiều người thích làm điều này, nhưng một nghiên cứu được công bố vào tháng 2 năm nay cho thấy nếu bạn cho phép tác nhân sửa đổi AGENTS.md của chính nó, hiệu suất sẽ giảm khoảng 2 đến 3%, điều này, bạn biết đấy, không phải là vấn đề quá lớn.

Nhưng điều quan trọng là chi phí tăng 20%.

Vì vậy, chúng tôi đã mất một chút hiệu suất và chi phí tăng vọt, tất cả là do để tác nhân tự viết AGENTS.md.

Một cách giải quyết mà tôi đã thấy là bạn có thể yêu cầu tác nhân viết một bản hồi tưởng ở cuối mỗi yêu cầu gộp, sau đó, cả nhóm có thể cùng đọc tất cả các bản hồi tưởng đó và quyết định những thay đổi cần thực hiện, vì tệp này đang trở thành phần quan trọng trong cơ sở hạ tầng thiết yếu của nhóm nếu bạn làm việc trong các nhóm lớn có tác nhân.

Vì vậy, tôi sẽ giới thiệu nhanh về AGENTS.md cho ứng dụng Sideline mà chúng tôi đã xây dựng.

Có hai điều tôi muốn nhấn mạnh ở đây.

Thứ nhất, việc có một cấu trúc được xác định rõ ràng sẽ giúp bạn tiết kiệm mã thông báo và độ dài ngữ cảnh.

Về cơ bản, việc này giúp tác nhân của bạn không phải liên tục xem xét thêm toàn bộ mã nguồn và đưa ra ngày càng nhiều suy luận.

Nó cung cấp một hướng dẫn rất rõ ràng để AI tuân theo.

Và điều thứ hai mà tôi muốn nhấn mạnh là đặc biệt dành cho các ứng dụng nguồn đóng.

Rõ ràng là nếu bạn dùng mã nguồn đóng, thì không có tác nhân nào có thể huấn luyện LLM trên toàn bộ mã nguồn của bạn.

Vì vậy, trong những trường hợp này, điều đặc biệt quan trọng là bạn phải dành thêm thời gian, dành những chu kỳ đó để liên tục dọn dẹp, xem xét, tinh chỉnh, cải thiện AGENTS.md của mình, vì điều này sẽ mang lại lợi ích cho bạn về lâu dài.

Vậy nếu không nên đưa mọi thứ vào AGENTS.md, thì làm cách nào để thay đổi hành vi của tác nhân hoặc mô hình?

Đầu tiên là hook, và hook thực sự rất phù hợp với những thứ mà mọi người đưa vào AGENTS.md, chẳng hạn như luôn chạy linter khi bạn viết xong.

// settings.json

"hooks": {
  "Stop": [{
    "command": "./gradlew lintDebug"
  }]
}

Đó có thể là một điểm nhấn.

Hook là một cơ chế mà tác nhân của bạn hiển thị tất cả các sự kiện mà bạn có thể đăng ký, và có những sự kiện cho hầu hết mọi thứ bạn có thể nghĩ đến, nhưng những sự kiện chính là bắt đầu phiên, dừng phiên, đọc và ghi tệp.

Vì vậy, thay vì viết ở cuối AGENTS.md của bạn, "luôn chạy linter" hoặc "luôn chạy bộ kiểm thử của tôi trước khi nói rằng bạn đã hoàn tất", bạn chỉ cần có một điểm dừng có thể chạy một tập lệnh tất định và điều này giúp kiềm chế tính ngẫu nhiên nhẹ của AI.

Một trường hợp khác là nếu bạn có những tệp mà bạn thực sự không muốn tác nhân có thể đọc hoặc ghi, chẳng hạn như tệp bí mật, bạn không muốn tệp đó được gửi đến máy chủ hoặc AGENTS.md, bạn không muốn tác nhân có thể ghi vào tệp đó, bạn có thể sử dụng hook cho trường hợp đó.

Vì vậy, bạn có một hook đọc hoặc ghi, bạn được chuyển tệp mà nó đang cố chỉnh sửa và bạn có thể trả về "Không, bạn không thể làm điều đó".

Đây chỉ là một cách để thêm tính tất định.

Tiếp theo là kỹ năng.

Và giờ đây, bạn có thể dùng kỹ năng để biến AGENTS.md thành câu móc.

Đó là một vấn đề hoàn toàn khác.

Nhưng kỹ năng là cách để chỉ thêm bối cảnh khi phù hợp.

Vì vậy, AGENTS.md là dành cho những nội dung luôn phù hợp.

Kỹ năng là những điều phù hợp trong một số tình huống nhất định, chủ yếu là tài liệu.

Vì vậy, kỹ năng được tạo thành từ ba phần: tên, nội dung mô tả (đây là phần quan trọng, nội dung mô tả này bị giới hạn ở 1.024 ký tự) và phần nội dung.

---

name: android-cli
description: >
  Loaded into context (≤1024 chars)
---
# Skill Body

Và phần nội dung có thể rất lớn, thậm chí có thể bao gồm cả các tập lệnh khác, điều này khá phổ biến.

Bạn có thể làm được rất nhiều việc nhờ kỹ năng.

Hãy xem một ví dụ.

Đây là nội dung mô tả về Android CLI.

Bạn không cần phải đọc hết.

Chỉ cần biết rằng đây là một đoạn mô tả ngắn về thời điểm Android CLI phù hợp.

Và đây là phần nội dung.

Nó rất lớn, vì vậy chúng ta không muốn tải tất cả những thứ này mọi lúc, phải không?

Chúng ta chỉ muốn tải tệp này khi cố gắng sử dụng Android CLI và đó là điều mà một kỹ năng cho phép chúng ta thực hiện.

Tuy nhiên, bạn cần chọn lọc kỹ các kỹ năng mà bạn cài đặt.

Chúng ta không nên cài đặt bừa bãi những kho lưu trữ có hàng trăm kỹ năng kỹ thuật tác nhân mà chúng ta thấy trên mạng.

Một là, việc này tiềm ẩn rủi ro bảo mật rất lớn.

Bạn không biết những kỹ năng đó có gì, có thể là yêu cầu tác nhân của bạn làm bất cứ điều gì.

Và chúng tôi có một bộ kỹ năng Android, tôi hứa là chúng tôi đã kiểm tra kỹ, họ không nói như vậy.

Nhưng thứ hai, 100 nội dung mô tả nhân với 1.000 ký tự là 100.000 ký tự mà bạn vừa thêm vào trước khi bắt đầu lập trình.

Vì vậy, bạn đã tiến gần đến cửa sổ đó.

Vì vậy, đối với các kỹ năng Android, bạn nên cài đặt kỹ năng cơ bản của Android CLI cho mọi thứ. Từ đó, Android CLI có thể tìm kiếm các kỹ năng có sẵn và cài đặt những kỹ năng phù hợp với ứng dụng của bạn.

> android init

✓ Installed base skill: android-cli

# Audit & add skills only when needed:
> android skills find compose
> android skills add edge-to-edge

Hoặc nếu bạn xem qua, thì việc biết những kỹ năng nào có sẵn là điều rất tốt. Bạn có thể thêm các kỹ năng phù hợp với dự án của mình theo cách thủ công, chẳng hạn như kỹ năng Compose, kỹ năng tràn viền, đó là những kỹ năng khá phổ biến.

Tất nhiên, có những kỹ năng để kiểm tra kỹ năng.

Vì vậy, có /skill-doctor trong Claude Code, và công cụ này sẽ xem xét và cho bạn biết những kỹ năng nào bạn đang đưa vào mà không bao giờ được kích hoạt, vì vậy bạn chỉ đang lãng phí phần mô tả nghìn ký tự đó.

Và nếu bạn không dùng Claude Code, thì hầu hết mọi khung vận hành tác nhân đều có một số dạng màn hình thống kê hoặc màn hình kiểm tra để làm điều tương tự.

Một lần nữa, Android CLI, đó là đường liên kết.

Nhưng nó có lệnh danh sách kỹ năng, sau đó cho biết bạn có Navigation 3 trong dự án của mình.

android skills list
android skills add navigation-3

Navigation 3 là một thư viện khá mới nên chưa có nhiều dữ liệu huấn luyện về thư viện này. Bạn có thể thêm kỹ năng Navigation 3.

Chúng tôi thường... Ồ, xin lỗi.

Tiếp theo là MCP.

Nhưng chúng tôi thường nhận được câu hỏi: Tại sao chúng tôi lại tạo Android CLI dưới dạng CLI chứ không phải máy chủ MCP?

Chúng tôi đã xây dựng các CLI này từ rất lâu trước khi AI ra đời, thậm chí trước cả khi chuột máy tính xuất hiện. Chúng tôi đã xây dựng CLI nên chúng rất nhanh, có thể kết hợp và vì chạy cục bộ trong phiên shell của bạn, nên chúng hoàn toàn miễn phí.

Ngoài ra, các điểm chuẩn như Terminal Bench đã trở thành điểm chuẩn lớn nhất trong lĩnh vực kỹ thuật phần mềm, vì vậy, các nhà sản xuất mô hình đã tích cực cải thiện khả năng sử dụng thiết bị đầu cuối, nên hiện nay họ rất giỏi sử dụng CLI.

Nhưng điều đó không có nghĩa là MCP không có chỗ đứng.

Máy chủ MCP rất phù hợp với các dịch vụ bên ngoài mà bạn đang sử dụng, đặc biệt là nếu các dịch vụ đó đã lưu trữ một dịch vụ MCP.

Bạn có thể kết nối trực tiếp với công cụ này mà không cần cài đặt để cung cấp thêm bối cảnh cho tác nhân.

Các nền tảng như GitHub, Figma, Slack hiện đang cung cấp máy chủ MCP.

Và sau đó, những thứ mà chúng ta luôn chạy trong shell có thể ở lại trong shell, vì vậy, các lệnh Android thông qua Android CLI, nhưng Perfetto và Gradle cũng chỉ có ý nghĩa khi có chúng cục bộ, nơi chúng có quyền truy cập vào mọi thứ bạn sử dụng trong quá trình phát triển.

Và tôi từng làm việc về hiệu suất.

Tôi luôn nói rằng Perfetto là công cụ duy nhất bạn cần để giải quyết mọi vấn đề về hiệu suất.

Nhưng quá trình học hỏi rất khó khăn, như chúng ta vừa thấy trong bài nói chuyện gần đây nhất của Rahul.

Hãy cùng xem cách AI có thể giúp nâng cao hiệu suất.

Cảm ơn Ben.

Vì vậy, để ứng dụng Sideline của chúng tôi hoạt động, ứng dụng cần chạy ở tốc độ 30 khung hình/giây và theo thời gian thực.

Như bạn có thể thấy trên chiếc Pixel 10 Pro Fold này, chúng ta chỉ đạt được khoảng 20 đến 22 khung hình/giây.

Những khung hình bị rớt này sẽ là một vấn đề, vì điều đó có nghĩa là ứng dụng sẽ không hoạt động như quảng cáo, vì vậy, chúng ta thực sự cần phải khắc phục vấn đề này.

Với Android CLI, chúng ta có các lệnh của trình phân tích Android.

Và khi chúng tôi thêm nó vào tác nhân lập trình và hướng dẫn nó đáp ứng yêu cầu 30 khung hình/giây này, hai điều thú vị sẽ xảy ra.

Cách đầu tiên là tìm ra cách khắc phục bằng lệnh của trình phân tích tài nguyên Android.

Công cụ này đã ghi lại dấu vết hệ thống trên thiết bị Pixel 10 Pro Fold được kết nối và phát hiện thấy các luồng AI của ứng dụng đang chạy trên các lõi chậm nhất của thiết bị.

Và điều thứ hai là nó đã sử dụng tính năng tìm kiếm tài liệu Android, thú vị là chúng tôi không yêu cầu nó làm như vậy, và nó đã lấy hướng dẫn chính thức cho Performance Hint API.

Tác nhân đã học được cách tối ưu hoá lịch biểu của hệ thống, nhờ đó, tác nhân có thể đáp ứng yêu cầu 30 khung hình/giây.

Vì vậy, về cơ bản, cách khắc phục là làm theo hướng dẫn.

Vì vậy, với Android CLI, mấu chốt là, bạn biết đấy, thông qua việc kết nối với tác nhân, nó giúp bạn tìm thấy công cụ phù hợp, ngay cả khi bạn không quen thuộc với công cụ đó, cho bất kỳ công việc nào bạn cần hoàn thành.

Vì vậy, sau khi chạy, bạn có thể thấy Sideline đáp ứng yêu cầu 30 khung hình/giây của người dùng và hiện hoạt động trên Pixel 10 Pro Fold.

Được rồi.

Bây giờ, chúng ta sẽ kết hợp tất cả lại với nhau bằng vòng lặp.

Tôi chắc rằng chúng ta đều từng làm việc này: bạn yêu cầu tác nhân triển khai một thay đổi lớn, và tác nhân quay lại và nói rằng đã hoàn tất.

Và nếu bạn đang cài đặt ứng dụng và tự nhấp vào ứng dụng theo cách thủ công, rồi nhập lại lỗi, thì đó là điều chúng ta cần ngừng làm.

Chúng ta cần ngừng đóng vai trò là người kiểm thử đảm bảo chất lượng cho tác nhân và xác định trước những gì chúng ta coi là đã hoàn tất.

Sau đây là một ví dụ.

Chúng tôi muốn di chuyển toàn bộ dự án sang Nav3, sau đó tác nhân sẽ biến mất, quá trình này mất một chút thời gian, nhưng tác nhân sẽ tự tin quay lại và nói: "Quá trình di chuyển đã hoàn tất.

Tôi là người giỏi nhất."

Nhưng sau đó, tất nhiên, bạn xoay điện thoại, ứng dụng gặp sự cố, bỏ lỡ tất cả các hiệu ứng chuyển đổi trang trình bày, không dọn dẹp tệp Gradle.

Đây cũng giống như thế giới chúng ta đang sống hiện nay.

Lý tưởng nhất là chúng ta không phải làm việc này, nhưng đây là thực tế hiện tại.

Vì vậy, trước tiên, chúng ta nên xác định tất cả những điều đó về những gì chúng ta mong đợi, và điều đó sẽ cho phép tác nhân lặp lại cho đến khi đáp ứng tất cả các tiêu chí đó.

Đó là vòng lặp xác minh.

Chúng tôi thực sự có dữ liệu rất rõ ràng về hiệu quả của việc này.

Đây là Android Bench 2.0, phiên bản mới của điểm chuẩn AI mà tôi đã đề cập ở đầu bài nói chuyện.

Tỷ lệ vượt qua hiện ở mức khoảng 40%.

Những nhiệm vụ này rất khó, rất lớn và thực tế, nhưng một trong số đó là Nav2 đến Nav3, đây là những việc bạn đang làm trong các dự án của mình ngay bây giờ.

Còn nếu chúng ta lấy Fable 5.1, tỷ lệ đạt của mô hình này là 22%, đó là kết quả mà mô hình này đạt được chỉ với câu lệnh tự nhiên, chẳng hạn như "di chuyển Nav2 sang Nav3".

Nhưng nếu chúng tôi cung cấp trước cho mô hình một bộ kiểm thử không đạt, tức là không đưa ra câu trả lời, không hướng dẫn cách di chuyển sang Nav3, mà chỉ cung cấp một bộ kiểm thử đã không đạt và sẽ đạt khi hoàn tất tất cả những việc đó, thì tỷ lệ đạt của mô hình trên toàn bộ điểm chuẩn sẽ tăng lên 90%.

Điều này cho thấy các mô hình này hiện thực sự có khả năng triển khai hầu hết mọi nhiệm vụ trên Android mà chúng ta có thể nghĩ đến, chỉ là không phải lúc nào chúng cũng biết "hoàn tất" nghĩa là gì.

Do đó, bạn không cần phải viết trước một bộ kiểm thử hoàn chỉnh không thành công.

Vòng lặp xác minh có thể đơn giản như việc thêm câu lệnh.

Ví dụ: nếu đang làm việc trong giao diện người dùng, bạn có thể yêu cầu Gemini hiển thị bản xem trước Compose và đảm bảo bản xem trước đó khớp với thông số kỹ thuật của Figma, rồi cho bạn xem kết quả.

Có vẻ như Gemini thực sự hiệu quả khi bạn yêu cầu Gemini cho bạn xem kết quả và chứng minh rằng Gemini đã hoàn thành, thay vì chỉ chấp nhận câu trả lời bằng văn bản "Tôi đã hoàn thành".

Nếu đang xử lý logic nghiệp vụ, bạn có thể yêu cầu Gemini chạy kiểm thử đơn vị. Hoặc như chúng ta đã thấy ở phần đầu, nếu đang xử lý lỗi sự cố, bạn có thể yêu cầu Gemini xác thực rằng lỗi sự cố đã được khắc phục trên thiết bị thực tế xảy ra sự cố thông qua phòng thí nghiệm kiểm thử từ xa.

Thực ra, Claude Code có tích hợp sẵn một kỹ năng giúp bạn xây dựng vòng lặp xác minh ngay bây giờ.

Vì vậy, hãy nhớ xem qua.

Và nếu bạn đang làm việc trong Android Studio với tác nhân của riêng mình, Android Studio sẽ cung cấp một loạt công cụ mà bạn có thể xây dựng vòng lặp tuỳ thuộc vào nội dung bạn đang làm việc.

Vì vậy, giống như linter, bạn có thể yêu cầu linter không dừng lại cho đến khi tất cả lỗi linter được khắc phục, hoặc một lỗi mà tôi thực sự thích là hành trình, bạn có thể yêu cầu linter chạy hành trình của bạn và đảm bảo chúng vẫn hoạt động.

Hoặc nếu đã viết một hành trình (vì hành trình khá dễ viết, chỉ là câu lệnh về tính năng bạn đang làm việc), bạn có thể yêu cầu Gemini chạy hành trình đó và đảm bảo hành trình đó vượt qua trước khi tuyên bố hoàn tất.

Tuy nhiên, hành trình cần một chút thời gian để chạy.

Vì vậy, bạn cũng có thể phân cấp các cấp độ của vòng lặp xác minh.

Vì vậy, chúng ta có thể yêu cầu Gemini trước tiên đảm bảo rằng các chương trình kiểm thử đơn vị và Bản xem trước trong Compose đều hiển thị chính xác.

Sau đó, khi đã vượt qua, vui lòng chạy các bài kiểm thử đã kết nối và Android Journeys. Chỉ khi vượt qua các bài kiểm thử đó, bạn mới chạy toàn bộ bài kiểm thử như phòng thí nghiệm kiểm thử thiết bị từ xa, toàn bộ bộ kiểm thử sẽ mất hàng giờ.

Và nếu bạn cung cấp thêm thông tin đó, chúng tôi nhận thấy rằng thông tin đó sẽ lặp lại theo từng cấp thay vì cố gắng thực hiện từng bước ở mỗi lần chạy.

Vì các mô hình rất tự tin.

Vì vậy, họ luôn nghĩ rằng họ đã hoàn thành và họ luôn nghĩ rằng họ sẽ vượt qua tất cả các bài kiểm tra ngay từ lần đầu tiên.

Hãy cùng xem xét vấn đề này trong Sideline.

Vì vậy, hãy áp dụng ý tưởng này cho ứng dụng Sideline bằng cách thêm một tính năng mới, dành riêng cho kính thông minh XR sắp ra mắt.

Và vì chưa có phần cứng nên tất nhiên chúng ta sẽ sử dụng trình mô phỏng XR và hướng dẫn tác nhân lập trình mở rộng Sideline cho hệ số hình dạng mới.

Khi làm như vậy, chúng ta sẽ yêu cầu các tác nhân lặp lại các bài kiểm thử JVM, bài kiểm thử Bản xem trước trong Compose và bài kiểm thử trình mô phỏng theo thứ tự đó.

Và mỗi vòng lặp được yêu cầu xây dựng dựa trên vòng lặp trước đó.

Khi làm việc này, điều đầu tiên chúng ta nhận thấy là giữa vòng lặp một và hai, các kiểm thử JVM được dùng để xác định sáu trạng thái của Bản xem trước trong Compose.

Tất nhiên, không có trình mô phỏng nào được gọi, vì vậy, quá trình này chạy rất nhanh.

Tương tự, giữa vòng lặp hai và vòng lặp ba, các vấn đề như chuỗi dài sẽ được phát hiện và khắc phục ngay cả trước khi trình mô phỏng phải chạy.

Vì vậy, cuối cùng, khi vòng lặp trình mô phỏng chạy, nó sẽ tìm thấy các lỗi khác mà kiểm thử JVM và Bản xem trước Compose không thể khắc phục.

Nhưng về cơ bản, với mỗi vòng lặp, chúng ta sẽ tăng cường bảo mật cho ứng dụng của mình hơn nữa. Chúng ta muốn chạy các vòng lặp nhanh nhất nhưng ít mạnh mẽ nhất trước, sau đó là các vòng lặp chậm nhất nhưng mạnh mẽ nhất.

Và đây là kết quả.

Video cho thấy chiếc kính hiện hiển thị kiểu vung vợt và tốc độ của quả bóng khi rời khỏi vợt, nhờ đó, bạn có thể chơi quần vợt và nhận ý kiến phản hồi về lối chơi của mình theo thời gian thực mà không cần rời mắt khỏi quả bóng.

À, trước đó tôi có đề cập rằng chúng ta sẽ quay lại hai vấn đề về Crashlytics đã phát sinh trước đó.

Vì đã xác thực được rằng phương pháp đó hiệu quả, nên chúng ta có thể sử dụng lệnh /schedule trong Claude Code để lặp lại phương pháp đó và có thể đặt bất kỳ tần suất nào mà chúng ta muốn. Nhờ vậy, giờ đây chúng ta có một ứng dụng tự khắc phục, có thể sửa tất cả lỗi và xác thực rằng các lỗi đó đã được khắc phục, đồng thời gửi các lỗi đó dưới dạng yêu cầu gộp để các kỹ sư của chúng ta xem xét và hợp nhất.

Chúng ta tìm hiểu tiếp nhé.

Đó là tất cả nội dung của ngày hôm nay.

Nếu có một điều quan trọng cần ghi nhớ, thì đó là hãy bắt đầu nghĩ về thế giới nơi chúng ta đang xây dựng một môi trường để các tác nhân thành công và coi đó như cách chúng ta xử lý việc phát triển phần mềm và lỗi hiện nay.

Đó là cách chúng tôi khai thác các tác nhân song song.

Bạn sẽ tìm thấy rất nhiều lời khuyên về chủ đề này trên mạng, và nhiều lời khuyên trong số đó sẽ mâu thuẫn với nhau.

Đó là thực tế trong môi trường thay đổi nhanh chóng này.

Vì vậy, điều tốt nhất bạn có thể làm là viết các bản đánh giá của riêng mình cho dự án.

Sau đó, khi có lời khuyên mới hoặc mô hình mới, bạn có thể đo lường và xem liệu lời khuyên hoặc mô hình đó có giúp ích cho bạn hay không.

Và tất nhiên, có một kỹ năng cho mọi thứ.

Có một kỹ năng giúp bạn xây dựng các bản đánh giá trong Claude Code.

/claude-api build-eval

Bạn nên tham khảo bài viết đó.

Hôm nay, tôi đã nói về Android Bench.

Android Bench là công cụ đánh giá của chúng tôi.

Đây là cách chúng tôi đo lường để đảm bảo mọi thứ đang trở nên tốt hơn.

Nếu bạn muốn nghe những bài học mà chúng tôi rút ra được khi xây dựng công cụ đó để tránh mắc phải những sai lầm tương tự, hãy xem bài nói chuyện về Android Bench.

Ngoài ra còn có hai bảng điều khiển.

Có một văn phòng ở Hoa Kỳ, một văn phòng ở London.

Cả hai đều sẽ được đăng tải trên mạng và nói về khái niệm này trong thực tế ở cộng đồng.

Vì vậy, chúng tôi mời các thành viên trong cộng đồng Nhà phát triển Android tham gia hội thảo để chia sẻ về cách họ áp dụng điều này vào công việc.

Chúng tôi cũng rất mong nhận được ý kiến phản hồi của bạn.

Chúng tôi rất muốn biết liệu những tính năng chúng tôi đang xây dựng có thực sự giúp ích cho bạn hay không.

Vì vậy, vui lòng điền vào bản khảo sát.

Tôi sẽ để thông tin đó trên màn hình.

Và, đúng vậy.

Cảm ơn bạn đã lắng nghe.

Cảm ơn bạn.