Cách P2ER xây dựng một môi trường có độ tin cậy cao để lập trình dựa trên tác nhân bằng Chrome DevTools dành cho các tác nhân

Peer Weidner
Peer Weidner
GitHub LinkedIn
José Luis Zapata

Xuất bản: Ngày 22 tháng 6 năm 2026

P2ER, một công ty chuyên về giải pháp kỹ thuật số, sử dụng Công cụ của Chrome cho nhà phát triển dành cho các tác nhân để đảm bảo chỉ có phần mềm đã xác minh và đang hoạt động được chuyển cho nhân viên đánh giá để xem xét lần cuối. Bằng cách chuyển đổi quy trình làm việc của mình thành một cơ sở hạ tầng dựa trên tác nhân, họ đã trao quyền cho các tác nhân AI thực hiện quy trình xác minh giao diện người dùng thực nghiệm, tăng tần suất triển khai từ một lần mỗi tuần lên nhiều lần mỗi ngày.

Thử thách: Nâng cao chất lượng trong các ứng dụng hiện có

P2ER mang đến trải nghiệm kỹ thuật số cao cấp cho các thương hiệu toàn cầu, bao gồm cả nhà sản xuất ô tô, thương hiệu đồng hồ và công ty khách sạn. Thách thức chính của họ (cũng như của nhiều công ty khác) là làm việc trong các ứng dụng phức tạp hiện có. Khi áp dụng phương pháp lập trình dựa trên tác nhân, nhóm này đã gặp phải 3 rào cản lớn:

  • Kiểm thử giao diện người dùng dễ bị lỗi. Các bộ thử nghiệm tiêu chuẩn gặp khó khăn với dữ liệu động, chẳng hạn như giá khách sạn biến động hoặc các sản phẩm theo mùa trong một số dự án của P2ER. Dữ liệu mô phỏng thường che giấu các lỗi tích hợp mà người kiểm thử sẽ tìm thấy ngay lập tức.
  • Vấn đề về độ tin cậy của trợ lý. Nếu không có chỉ dẫn rõ ràng, đôi khi các tác nhân AI sẽ tuyên bố đã hoàn thành một nhiệm vụ mà không thực sự xác minh.
  • Tổn thất. Các tác vụ rộng và thời gian chờ của mô hình khiến các tác nhân không theo dõi được mục tiêu của phiên. Điều này gây khó khăn cho nhà phát triển trong việc theo dõi và tiếp tục công việc mà một tác nhân đã bắt đầu.

Giải pháp: Xây dựng cơ sở hạ tầng cho hoạt động chế tạo

P2ER đã xây dựng một cơ sở hạ tầng coi AI là "đối tác tập luyện" và cũng có thể xử lý các khía cạnh lặp đi lặp lại của quá trình phát triển. Cách tiếp cận này cho phép nhóm mở rộng quy mô kỹ năng bằng cách tập trung vào kiến trúc và giải quyết vấn đề một cách sáng tạo.

Thực thi quy trình xác minh thực nghiệm bằng DevTools cho máy chủ MCP của các tác nhân

Để đảm bảo độ tin cậy, P2ER đã thiết lập một quy tắc Xác minh thực nghiệm bắt buộc. Yêu cầu kỹ thuật này, được mã hoá trong tệp AGENTS.md của dự án, nêu rõ:

All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.

Thay vì tin lời của nhân viên hỗ trợ, nhóm này sử dụng Chrome DevTools để cung cấp cho nhân viên hỗ trợ một môi trường an toàn để điều hướng ứng dụng một cách trực quan và tương tác.

Những "tác nhân kiểm thử" này thực hiện một số nhiệm vụ chính mà các kiểm thử tĩnh tiêu chuẩn không thực hiện được:

  • Kiểm thử dữ liệu linh động: Ngay cả trong môi trường dàn dựng, các tác nhân cũng kiểm thử dựa trên dữ liệu thực, biến động (chẳng hạn như giá khách sạn thay đổi theo mùa) để trải nghiệm ứng dụng giống hệt như người dùng. Tính năng này được bật bằng Công cụ cho nhà phát triển cho các công cụ tương tác của trợ lý ảo như new_page, navigate_page, fill, click và hover, được gọi trong kỹ năng github-issue-test của họ, cho phép trợ lý ảo xác thực một cách linh hoạt và mô phỏng đường dẫn nhấp của người dùng thực.
  • Kiểm tra trực quan: Các nhân viên xác định sự khác biệt về hình ảnh giữa bố cục Figma và việc triển khai thực tế. Bằng cách sử dụng công cụ take_screenshot trong DevTools cho các tác nhân, kỹ năng figma-validate của họ sẽ chụp ảnh màn hình có độ phân giải cao về các bản kết xuất Storybook trực tiếp để so sánh song song với các tệp xuất Figma.
  • Kiểm tra khả năng sử dụng: Nhân viên hỗ trợ phát hiện bản dịch bị thiếu hoặc lỗi về khả năng sử dụng mà tập lệnh tự động thường bỏ qua. Bằng cách tương tác trực tiếp với cây hỗ trợ tiếp cận và xem xét ảnh chụp nhanh trực quan, được truy xuất thông qua take_snapshot và take_screenshot, các tác nhân chủ động quét các điểm bất thường trên giao diện người dùng, chẳng hạn như các chuỗi MISSING_MESSAGE theo hướng dẫn rõ ràng trong quy trình xác minh tự động của chúng.

Phân tách và duy trì các việc phụ cần làm

Để chống lại tình trạng hết thời gian chờ và mất ngữ cảnh, P2ER phân chia công việc một cách nghiêm ngặt thông qua các tác nhân phụ. Sau đó, họ hướng dẫn các tác nhân của mình đóng vai trò là người điều phối như sau:

Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.

Để thông báo cho chủ sở hữu sản phẩm là con người trong quy trình này, nhóm đã tích hợp một kỹ năng tuỳ chỉnh để các nhân viên theo dõi công việc của họ trong các vấn đề trên GitHub. Điều này đảm bảo rằng mọi tác vụ của tác nhân phụ và kết quả của tác vụ đó đều được duy trì và ghi lại dưới dạng một vấn đề phụ bằng API GitHub, tạo ra một nhật ký kiểm tra rõ ràng và bối cảnh liên tục mà các nhà phát triển khác có thể tiếp tục.

Cách ly môi trường để thực thi song song

Để mở rộng quy trình phát triển sao cho nhiều tác nhân chạy mã song song, P2ER yêu cầu các tác nhân của họ có môi trường biệt lập cho mỗi tác vụ. Điều này giúp ngăn chặn các xung đột trạng thái và sự cố mạng trong quá trình xác minh giao diện người dùng.

Việc thiết lập kỹ thuật cho hoạt động cô lập này bao gồm:

  • Worktree Git riêng biệt: Để ngăn chặn xung đột tệp và ô nhiễm không gian làm việc khi nhiều tác nhân hoạt động song song, các tác vụ sẽ được thực thi trong worktree Git riêng biệt. Mỗi tác nhân sẽ có một không gian hệ thống tệp riêng, nơi các biến môi trường được sao chép và các phần phụ thuộc được liên kết tượng trưng, đảm bảo các thay đổi về tệp không bao giờ ghi đè lên nhau.
  • Môi trường riêng biệt: Mỗi tác nhân và tác vụ chạy máy chủ phát triển Next.js trên một cổng riêng biệt. Theo các quy tắc của dự án, các máy chủ sẽ được khởi động linh hoạt bằng npx next dev -p <custom_port> --turbopack để đảm bảo thực thi song song mà không xảy ra xung đột mạng.
  • Bản sao cơ sở dữ liệu: Để ngăn chặn xung đột dữ liệu trong quá trình kiểm thử song song, P2ER sẽ sao chép cơ sở dữ liệu chính thành một giản đồ dành riêng cho tác vụ khi khởi động tác nhân. Sau khi tác nhân hoàn tất quy trình xác minh và nhiệm vụ được phê duyệt, một quy trình dọn dẹp tự động sẽ loại bỏ cơ sở dữ liệu riêng biệt. Vòng đời này đảm bảo rằng mọi tác nhân đều hoạt động trong một không gian làm việc nguyên vẹn và không để lại dữ liệu dư thừa.
  • Thử nghiệm có mục tiêu: Tất cả hoạt động kiểm thử trình duyệt thông qua Chrome DevTools cho các tác nhân phải nhắm đến chính xác cổng tuỳ chỉnh được phân bổ cho phiên bản tác nhân cụ thể đó. Yêu cầu kiểm thử của họ cấm mã hoá cứng các cổng mặc định, yêu cầu các URL mục tiêu kiểm thử như http://localhost:<custom_port>.

Tác động: Tăng tốc độ phát triển lên gấp 10 lần mà vẫn đảm bảo chất lượng

Việc chuyển sang phương pháp lập trình dựa trên tác nhân với các biện pháp bảo vệ có độ tin cậy cao đã thay đổi kết quả của P2ER. Ban đầu, những thay đổi này là cần thiết để đảm bảo tác nhân hoạt động một cách đáng tin cậy, nhưng chúng cũng mang lại lợi ích cho toàn bộ vòng đời phát triển:

  • Chu kỳ làm việc nhanh hơn gấp 10 lần: Hầu hết các vấn đề hiện được giải quyết trong vòng một ngày, so với mức trung bình từ 1 đến 3 ngày trước đây. Tần suất triển khai tăng từ một lần mỗi tuần lên nhiều lần mỗi ngày.
  • Trọng tâm chiến lược cho nhóm đảm bảo chất lượng: Vì giờ đây, các tác nhân có thể phát hiện những lỗi hồi quy cơ bản và "lỗi dễ phát hiện", nên nhóm kiểm thử thủ công có thể tập trung vào các tình huống kiểm thử phức tạp và chuyên sâu hơn.
  • Triển khai mạnh mẽ cho các bên liên quan: Giờ đây, các hoạt động triển khai sẽ linh hoạt hơn vì việc kiểm thử vượt ra ngoài "lộ trình lý tưởng" tiêu chuẩn của lập trình viên.
  • Thông tin liên lạc và khả năng truy xuất rõ ràng hơn: Bằng cách thực thi quy tắc "vấn đề của con người đối với vấn đề phụ về việc triển khai", các bên liên quan sẽ nhận được hướng dẫn rõ ràng về những điểm cải tiến hợp lý đã được thực hiện thay vì đọc qua các phiếu yêu cầu chứa đầy thông tin chi tiết về việc triển khai kỹ thuật và cách kiểm thử các điểm cải tiến đó.

Ví dụ về cách điều này ảnh hưởng đến tốc độ phát triển, P2ER đã xây dựng một nền tảng mới trong 6 tháng, trong khi nếu sử dụng các phương pháp đã thiết lập thì sẽ mất nhiều năm. Con người vẫn là người kiểm soát chất lượng cuối cùng, xem xét các Yêu cầu kéo đã được các tác nhân xác thực.

Thông tin chi tiết về kỹ thuật dành cho nhóm

Trong quá trình xây dựng quy trình này, P2ER đã xác định được một số chiến lược giúp họ chuyển đổi từ thử nghiệm sang một mô hình phát triển trưởng thành, có sự hỗ trợ của nhân viên.

Những chiến lược này có thể giúp các nhóm khác tinh chỉnh việc triển khai dựa trên tác nhân của riêng họ:

Tối ưu hoá việc sử dụng mã thông báo bằng tính năng chèn tập lệnh và xử lý hàng loạt bằng giao diện dòng lệnh

Các máy chủ MCP có thể tiêu tốn nhiều mã thông báo trong các phiên phát triển dài nếu các tác nhân chỉ dựa vào chế độ điều hướng từng bước (ví dụ: chụp nhanh, tìm mã nhận dạng, điền dữ liệu đầu vào và chờ). Để giảm thiểu mức hao tổn này, P2ER sử dụng một phương pháp gồm 2 hướng tiếp cận:

  • Chèn tập lệnh nội tuyến: Đối với các hoạt động tương tác có mục tiêu, chẳng hạn như xác thực thông qua các biểu mẫu React phức tạp, nhân viên hỗ trợ sử dụng công cụ evaluate_script để chèn JavaScript thuần tuý trực tiếp vào trình duyệt. Thao tác này bỏ qua các phương thức ghi đè setter tích hợp và thực thi nhiều hành động cùng một lúc, giúp tiết kiệm nhiều lượt trò chuyện.
  • Tập lệnh CLI theo lô: Khi nhân viên gặp "trở ngại" hoặc gặp phải một quy trình trình duyệt lặp đi lặp lại quá dài, họ sẽ chuyển sang phương án dự phòng theo lô CLI. Thay vì tốn mã thông báo cho các công cụ MCP riêng lẻ, lặp lại hoặc viết các tập lệnh tự động hoá tuỳ chỉnh từ đầu, P2ER sẽ nhắc Chrome DevTools CLI duy trì và xử lý hàng loạt các thao tác trên trình duyệt. Điều này cho phép các tác nhân thực thi toàn bộ quy trình nhiều bước theo cách có lập trình trong một lần, giảm đáng kể chi phí giao tiếp liên tục giữa mô hình và công cụ.

Tự động hoá việc theo dõi hiệu suất bằng Phân tích dấu vết

Thay vì chỉ dựa vào cảm nhận của con người, P2ER đã tạo ra một kỹ năng review-performance sử dụng DevTools cho các tác nhân để chạy các hoạt động kiểm tra Lighthouse tự động và dấu vết hiệu suất.

Các tác nhân sử dụng công cụ performance_start_trace và performance_analyze_insight để ghi lại và điều tra Core Web Vitals (LCP, INP, CLS) cũng như xác định các điểm tắc nghẽn của luồng chính hoặc sự thay đổi bố cục. Để hoàn thiện quy trình kiểm tra chất lượng, các tác nhân có thể chạy một lighthouse_audit đầy đủ để đặc biệt ngăn chặn các lỗi hồi quy về Khả năng tiếp cận (a11y), SEO và các phương pháp hay nhất chung trên web, đảm bảo chỉ có mã chất lượng cao được gửi cho Yêu cầu kéo.

Nâng cao quy trình xác minh bằng Chrome DevTools cho nhân viên hỗ trợ

Ngoài các kỹ năng tuỳ chỉnh, P2ER còn sử dụng các chức năng cốt lõi của máy chủ MCP Công cụ cho nhà phát triển Chrome để xác minh chức năng. Điều này bao gồm việc sử dụng máy chủ để mô phỏng các thiết bị khác nhau và kiểm thử khả năng thích ứng, đảm bảo rằng giao diện người dùng hoạt động trên nhiều kích thước màn hình và thiết bị.

Bằng cách sử dụng máy chủ MCP để điều hướng ứng dụng, các tác nhân có thể xác định sự khác biệt về hình ảnh giữa bố cục và việc triển khai thực tế, xác định các lỗi mà kiểm thử tĩnh thường bỏ qua.

Tài nguyên

Để khám phá thêm trường hợp sử dụng của P2ER, hãy khám phá tất cả các kỹ năng được đề cập trong kho lưu trữ GitHub có liên quan.

Để tự mình bắt đầu và tìm hiểu thêm về cách triển khai quy trình tương tự bằng Công cụ cho nhà phát triển dành cho nhân viên hỗ trợ, hãy khám phá các tài nguyên sau: