Tóm tắt
Tác nhân mã hóa AI nội bộ của Google, Agent Smith, hiện đang tạo ra hơn 25% mã sản phẩm mới của công ty. Không giống như các công cụ tự động hoàn thành như Copilot, Agent Smith hoạt động không đồng bộ trong nền, viết, kiểm thử và lặp lại mã mà không cần tương tác của con người. Đối với các nhóm API, điều này đặt ra câu hỏi về tính ổn định của hợp đồng, độ bao phủ kiểm thử, sự lệch pha tài liệu và quy trình đánh giá khi một phần tư cơ sở mã của bạn được tạo ra bằng máy.
Giới thiệu
Trong cuộc họp báo cáo tài chính tháng 3 năm 2026, CEO Google Sundar Pichai đã đưa ra một con số khiến toàn bộ ngành công nghiệp phần mềm phải dừng lại: mã do AI tạo ra hiện chiếm hơn 25% mã mới được sản xuất tại Google.
Đây không phải là tự động hoàn thành. Đây không phải là các gợi ý của Copilot được các nhà phát triển chấp nhận. Đây là mã được triển khai trong môi trường production sau khi AI tạo ra. Công cụ đằng sau nó, được gọi nội bộ là Agent Smith (một sự ám chỉ đến nhân vật phản diện tự nhân bản từ Ma trận), đã trở nên phổ biến đến mức trong số hơn 180.000 nhân viên của Google, công ty đã phải hạn chế quyền truy cập để quản lý áp lực cơ sở hạ tầng.
Agent Smith đại diện cho một danh mục khác so với các công cụ mã hóa AI mà hầu hết các nhà phát triển sử dụng hiện nay. Trong khi Copilot và Claude Code hỗ trợ trong thời gian thực, Agent Smith hoạt động trong nền. Các kỹ sư giao nhiệm vụ, rời đi và quay lại sau để xem xét công việc đã hoàn thành.
Đối với các nhóm phát triển API, sự chuyển đổi từ mã “được AI hỗ trợ” sang “do AI tạo ra” này đặt ra những câu hỏi thực tế. Khi 25% cơ sở mã của bạn được viết bởi một tác nhân tự động, làm thế nào để bạn giữ hợp đồng API ổn định? Làm thế nào để bạn đảm bảo các bài kiểm thử bao phủ các điểm cuối được tạo ra bằng máy? Làm thế nào để bạn ngăn tài liệu bị lệch pha?
Bài viết này phân tích những gì Agent Smith làm, cách nó khác biệt so với các công cụ mã hóa AI khác và những gì các nhóm API nên chuẩn bị.
Agent Smith làm gì
Mã hóa tự động không đồng bộ
Agent Smith không ngồi trong IDE của bạn chờ bạn gõ. Nó hoạt động không đồng bộ trong nền. Dưới đây là quy trình làm việc:
- Một kỹ sư mô tả nhiệm vụ bằng ngôn ngữ tự nhiên
- Agent Smith chia nhiệm vụ thành các nhiệm vụ con
- Nó viết mã trên nhiều tệp
- Nó chạy kiểm thử và lặp lại các lỗi
- Kỹ sư xem xét công việc đã hoàn thành
Điều này hoàn toàn khác so với các gợi ý trực tuyến của Copilot hoặc các phiên tương tác của Claude Code. Agent Smith gần giống với một nhà phát triển cấp dưới nhận một vé, biến mất vài giờ và quay lại với một pull request.
Các kỹ sư có thể giao nhiệm vụ và kiểm tra tiến độ thông qua nền tảng trò chuyện nội bộ của Google, ngay cả từ thiết bị di động. Công cụ này tự động truy cập hồ sơ nhân viên và tài liệu liên quan, lấy ngữ cảnh từ cơ sở kiến thức nội bộ của Google.
Được xây dựng trên Gemini và Antigravity
Agent Smith chạy trên họ mô hình Gemini của Google, được bổ sung các hệ thống truy xuất giúp nó truy cập vào cơ sở mã và tài liệu nội bộ rộng lớn của Google. Nó được xây dựng dựa trên Antigravity, nền tảng mã hóa agentic hiện có của Google, nhưng mở rộng nó với khả năng phân tách và thực thi nhiệm vụ tự động.
Việc bổ sung truy xuất là chìa khóa. Agent Smith không tạo mã một cách cô lập. Nó tìm kiếm trong cơ sở mã nội bộ của Google để tìm các mẫu tương tự, tham chiếu các triển khai hiện có và tuân thủ các quy ước mã hóa nội bộ. Nhận thức ngữ cảnh này là điều giúp tạo ra đầu ra chất lượng sản phẩm ở quy mô 25%.
Ý nghĩa của việc “25% mã mới”
Con số của Pichai cần có ngữ cảnh. “25% mã mới” đề cập đến mã:
- Được AI tạo ra, không phải tự động hoàn thành
- Vượt qua đánh giá mã (các kỹ sư con người vẫn xem xét đầu ra của Agent Smith)
- Triển khai trong các hệ thống production
- Được đo lường trên toàn bộ đầu ra kỹ thuật của Google
Điều này không có nghĩa là 25% tổng cơ sở mã của Google được AI tạo ra. Nó có nghĩa là 25% mã mới đang được viết hôm nay đến từ Agent Smith. Sự khác biệt này quan trọng vì mã mới được bổ sung vào cơ sở mã hiện có do con người viết. Nhưng quỹ đạo rất rõ ràng: tỷ lệ này đang tăng lên, và Pichai đã nhấn mạnh nó như một lợi thế chiến lược.
Agent Smith khác biệt thế nào so với các công cụ mã hóa AI khác
Phổ công cụ mã hóa AI
| Công cụ | Chế độ | Tương tác | Phạm vi | Mã production? |
|---|---|---|---|---|
| GitHub Copilot | Tự động hoàn thành thời gian thực | Trực tiếp trong IDE | Mức dòng/hàm | Sau khi con người chấp nhận |
| Claude Code | Phiên tương tác | Đối thoại | Thay đổi nhiều tệp | Sau khi con người xem xét |
| Cursor Agent | Nền + tương tác | Nhúng trong IDE | Mức dự án | Sau khi con người xem xét |
| Agent Smith | Tự động không đồng bộ | Giao nhiệm vụ | Triển khai tính năng đầy đủ | Sau khi con người xem xét |
| KAIROS (chưa phát hành) | Daemon luôn hoạt động | Giám sát nền | Toàn bộ kho lưu trữ | Sẽ được xác định |
Agent Smith nằm ở phía tự động của phổ này. Bước tiếp theo duy nhất sẽ là triển khai hoàn toàn tự động mà không cần xem xét của con người, điều mà chưa công cụ lớn nào làm được (và không nên làm).
Tại sao tính không đồng bộ lại quan trọng đối với các nhóm API
Các công cụ mã hóa AI thời gian thực (Copilot, Claude Code) hoạt động trong luồng làm việc của nhà phát triển. Nhà phát triển thấy những gì AI viết, hiểu ngữ cảnh và thực hiện chỉnh sửa ngay lập tức.
Các tác nhân không đồng bộ thay đổi động lực này. Khi Agent Smith viết một điểm cuối API, nhà phát triển xem xét nó sau đó. Việc xem xét được tách biệt khỏi ngữ cảnh tạo ra. Điều này có nghĩa là:
- Nhà phát triển có thể không hiểu tại sao tác nhân lại chọn một định dạng phản hồi cụ thể
- Những thay đổi trong hợp đồng API có thể không rõ ràng trong một đánh giá mã tiêu chuẩn
- Các thành phần liên quan (kiểm thử, tài liệu, mock) có thể chưa được cập nhật
- Những thay đổi gây lỗi có thể lọt qua nếu người xem xét không kiểm tra toàn bộ tác động
Điều gì sẽ xảy ra khi AI viết mã API của bạn
Lệch hợp đồng API
Hợp đồng API là thỏa thuận giữa dịch vụ của bạn và người tiêu dùng của nó: các điểm cuối, lược đồ yêu cầu/phản hồi, mã trạng thái, định dạng lỗi. Khi một nhà phát triển con người sửa đổi một API, họ thường cập nhật đặc tả OpenAPI, thông báo cho người tiêu dùng và phiên bản hóa thay đổi.
Khi một tác nhân tự động sửa đổi một API, các bước phối hợp đó không xảy ra tự động. Agent Smith viết mã vượt qua kiểm thử. Nhưng kiểm thử chỉ bao phủ những gì đã được viết trước đó. Nếu tác nhân thay đổi lược đồ phản hồi theo cách vượt qua các kiểm thử hiện có nhưng làm hỏng các người tiêu dùng hạ nguồn, lỗi sẽ xuất hiện trong môi trường production.
Ví dụ kịch bản:
- Agent Smith được giao nhiệm vụ “Thêm tùy chọn người dùng vào điểm cuối hồ sơ”
- Nó thêm một trường
preferencesvào phản hồiGET /api/users/{id} - Các kiểm thử hiện có vượt qua vì chúng không khẳng định sự vắng mặt của các trường bổ sung
- Các loại TypeScript của nhóm giao diện người dùng không bao gồm
preferences - Phân tích cú pháp JSON nghiêm ngặt của ứng dụng di động báo lỗi khi gặp trường không mong muốn
Mã đúng. Các kiểm thử vượt qua. Hợp đồng bị phá vỡ.
Lỗ hổng về độ bao phủ kiểm thử
Mã được tạo bởi AI đi kèm với các kiểm thử được tạo bởi AI, và các tác nhân AI có xu hướng viết các kiểm thử để xác nhận những gì chúng đã xây dựng, chứ không phải các kiểm thử để chống lại các hồi quy. Điều này tạo ra một điểm mù: các kiểm thử xác nhận hành vi mới hoạt động, nhưng chúng không xác nhận rằng hành vi hiện có được bảo toàn.
Đối với các điểm cuối API, điều này có nghĩa là:
- Các tiêu chuẩn thời gian phản hồi có thể không được kiểm thử
- Các định dạng phản hồi lỗi có thể khác biệt so với lược đồ lỗi tiêu chuẩn của bạn
- Hành vi giới hạn tốc độ có thể không được xác thực
- Các trường hợp biên xác thực có thể không được bao phủ
- Hành vi phân trang có thể khác với các điểm cuối hiện có
Lệch tài liệu
Nếu tài liệu API của bạn được tạo từ các chú thích mã hoặc đặc tả OpenAPI, mã được tác nhân sửa đổi sẽ tự động lan truyền đến tài liệu. Nhưng nhiều nhóm duy trì tài liệu riêng biệt. Khi Agent Smith thêm một điểm cuối hoặc sửa đổi một lược đồ phản hồi, việc cập nhật tài liệu là một nhiệm vụ riêng biệt mà tác nhân có thể thực hiện hoặc không.
Ngay cả với tài liệu được tự động tạo, các mô tả, ví dụ và ghi chú sử dụng yêu cầu ngữ cảnh của con người mà tác nhân AI không có. Tác nhân có thể tài liệu hóa những gì một điểm cuối làm. Nó không thể tài liệu hóa lý do nó tồn tại, ai sử dụng nó hoặc những đánh đổi nào đã dẫn đến thiết kế của nó.
Mệt mỏi khi xem xét
Khi 25% mã được tạo bởi AI, 25% các đánh giá mã là đánh giá đầu ra của AI. Mã được tạo bởi AI có cú pháp nhất quán và cấu trúc tốt, điều này khiến nó trông “ổn” thoạt nhìn. Nhưng trông ổn không giống như việc đúng trong ngữ cảnh.
Người xem xét đối mặt với một thách thức mới: mã đọc tốt nhưng có thể không phù hợp với các quyết định kiến trúc, quy ước của nhóm hoặc các yêu cầu không được nêu rõ tồn tại trong đầu người xem xét nhưng không có trong lời nhắc của tác nhân. Theo thời gian, sự mệt mỏi khi xem xét mã được tạo bởi AI có thể dẫn đến việc thông qua dễ dãi, đó là lúc lỗi bắt đầu xuất hiện.
Cách xây dựng quy trình làm việc API 'chống agent'
1. Đặt hợp đồng API làm nguồn chân lý duy nhất
Phát triển API ưu tiên thiết kế là biện pháp phòng thủ mạnh mẽ nhất chống lại sự lệch pha do tác nhân gây ra. Khi đặc tả OpenAPI là nguồn chân lý duy nhất, bất kỳ thay đổi mã nào làm hỏng hợp đồng đều có thể phát hiện được.
Nếu không có ưu tiên thiết kế:
Thay đổi mã → Kiểm thử vượt qua → Triển khai → Hợp đồng bị hỏng
Với ưu tiên thiết kế:
Đặc tả định nghĩa hợp đồng → Mã phải khớp với đặc tả → Xác thực hợp đồng bắt được sự lệch pha
Trình thiết kế API trực quan của Apidog cho phép bạn định nghĩa các điểm cuối, lược đồ và định dạng phản hồi trước khi bất kỳ mã nào được viết. Khi Agent Smith (hoặc bất kỳ tác nhân nào) tạo mã, bạn xác thực nó dựa trên đặc tả, chứ không phải dựa trên các kiểm thử hiện có có thể không đầy đủ.
2. Sử dụng kiểm thử hợp đồng, không phải kiểm thử đơn vị
Kiểm thử đơn vị xác thực hành vi nội bộ. Kiểm thử hợp đồng xác thực thỏa thuận giữa các dịch vụ. Khi một tác nhân AI sửa đổi API của bạn, kiểm thử hợp đồng sẽ bắt được những thay đổi mà kiểm thử đơn vị bỏ lỡ.
Ví dụ kiểm thử hợp đồng:
// Kiểm thử này sẽ thất bại nếu hình dạng phản hồi thay đổi,
// ngay cả khi hình dạng mới "hợp lệ"
describe("GET /api/users/:id contract", () => {
it("trả về lược đồ mong muốn", async () => {
const response = await request(app).get("/api/users/123");
expect(response.body).toMatchSchema({
type: "object",
required: ["id", "name", "email", "created_at"],
properties: {
id: { type: "string" },
name: { type: "string" },
email: { type: "string", format: "email" },
created_at: { type: "string", format: "date-time" }
},
additionalProperties: false // Điều này bắt các trường không mong muốn
});
});
});
Dòng additionalProperties: false rất quan trọng. Nếu không có nó, một tác nhân thêm các trường vào phản hồi sẽ vượt qua tất cả các kiểm thử. Với nó, bất kỳ thay đổi lược đồ nào cũng yêu cầu cập nhật hợp đồng rõ ràng.
Apidog tự động hóa kiểm thử hợp đồng từ đặc tả API của bạn. Định nghĩa lược đồ của bạn một lần, và Apidog sẽ xác thực mọi phản hồi dựa trên nó trong cả kiểm thử thủ công và chạy CI/CD.
3. Chặn triển khai dựa trên xác thực đặc tả
Thêm xác thực đặc tả API vào quy trình CI/CD của bạn. Trước khi bất kỳ mã nào (do con người hoặc AI tạo ra) được triển khai, hãy xác minh rằng nó khớp với hợp đồng đã khai báo:
# Bước trong quy trình CI/CD
- name: Xác thực hợp đồng API
run: |
# So sánh đặc tả hiện tại với triển khai đang chạy
apidog run --test-scenario-id CONTRACT_TESTS
# Thất bại nếu tìm thấy bất kỳ vi phạm hợp đồng nào
if [ $? -ne 0 ]; then
echo "Phát hiện vi phạm hợp đồng API. Xem xét các thay đổi."
exit 1
fi
Điều này bắt được các thay đổi gây lỗi hợp đồng của Agent Smith trước khi chúng đến môi trường production.
4. Yêu cầu cập nhật đặc tả cho các thay đổi API
Tạo một quy tắc phát triển: bất kỳ PR nào sửa đổi hành vi API phải bao gồm một cập nhật đặc tả OpenAPI tương ứng. Đối với các PR do AI tạo ra, điều này có nghĩa là tác nhân phải cập nhật đặc tả, hoặc con người phải làm điều đó trước khi gộp.
Trong Apidog, các thay đổi đặc tả tự động lan truyền đến:
- Tài liệu API
- Phản hồi máy chủ Mock
- Khẳng định kiểm thử
- Các loại SDK của máy khách
Sự lan truyền này đảm bảo không có thành phần nào bị lệch pha khi hợp đồng thay đổi.
5. Giám sát hành vi API trong môi trường production
Ngay cả với kiểm thử hợp đồng và xác thực đặc tả, việc giám sát production vẫn bắt được những gì các kiểm thử trước production bỏ lỡ. Theo dõi:
- Vi phạm lược đồ phản hồi: Ghi lại khi các phản hồi không khớp với lược đồ đã khai báo
- Các trường mới xuất hiện: Cảnh báo về các trường phản hồi không có trong đặc tả
- Thay đổi tỷ lệ lỗi: Các điểm cuối do AI tạo ra có thể có phân phối lỗi khác nhau
- Thay đổi độ trễ: Mã do tác nhân viết có thể có các đặc tính hiệu suất khác nhau
- Thay đổi mẫu lưu lượng: Các điểm cuối mới có thể nhận các mẫu lưu lượng không mong muốn
6. Tách biệt đánh giá API khỏi đánh giá mã
Đánh giá mã tiêu chuẩn hỏi: “Mã này có hoạt động không?” Đánh giá API hỏi: “Thay đổi này có ảnh hưởng đến người tiêu dùng không?”
Đối với các thay đổi API do AI tạo ra, hãy tạo một danh sách kiểm tra đánh giá riêng:
- Thay đổi này có làm hỏng bất kỳ người tiêu dùng hiện có nào không?
- Đặc tả OpenAPI đã được cập nhật chưa?
- Các thay đổi không tương thích ngược có được phiên bản hóa không?
- Các phản hồi lỗi có nhất quán với định dạng lỗi hiện có không?
- Các điểm cuối mới có được tài liệu hóa bằng các ví dụ không?
- Các nhóm hạ nguồn đã được thông báo chưa?
Quỹ đạo: nơi mã hóa tự động đang hướng tới
Agent Smith hôm nay so với ngày mai
Agent Smith ở mức 25% là điểm khởi đầu. Sergey Brin gọi các tác nhân AI là “trọng tâm lớn” trong cuộc họp toàn thể về doanh số tháng 3 năm 2026. Con số 25% sẽ tăng lên khi công cụ cải thiện, các hạn chế truy cập được nới lỏng và quy trình làm việc thích nghi.
Các công ty khác đang xây dựng các hệ thống tương tự:
- KAIROS của Claude Code (bị rò rỉ trong mã nguồn): daemon luôn hoạt động với đăng ký webhook GitHub và các worker nền
- Chế độ Agent của GitHub Copilot: các nhiệm vụ mã hóa nhiều bước với chỉnh sửa tệp tự động
- CodeWhisperer của Amazon: mở rộng từ tự động hoàn thành sang các quy trình làm việc agentic
Xu hướng ngành rõ ràng: các công cụ mã hóa AI đang chuyển từ “trợ lý” sang “người đóng góp tự động” sang “cơ sở hạ tầng nền”. Trong vài năm tới, câu hỏi sẽ không phải là liệu AI có viết mã API của bạn hay không, mà là bao nhiêu trong số đó.
Những gì các nhóm API nên chuẩn bị ngay bây giờ
Thiết kế ưu tiên không còn là tùy chọn nữa. Khi các tác nhân viết mã, đặc tả API là thành phần ổn định duy nhất. Hãy biến nó thành nguồn chân lý duy nhất ngay bây giờ, trước khi việc áp dụng tác nhân khiến nó trở nên cấp bách.
Đầu tư vào cơ sở hạ tầng kiểm thử hợp đồng. Kiểm thử đơn vị là không đủ khi tác giả mã không hiểu các quy ước không được viết ra của bạn. Kiểm thử hợp đồng mã hóa các quy ước đó một cách rõ ràng.
Chọn các công cụ giữ các thành phần đồng bộ. Các công cụ bị ngắt kết nối (máy khách API riêng, trình chạy kiểm thử riêng, máy chủ mock riêng, trình tạo tài liệu riêng) tạo ra các cơ hội lệch pha mà các tác nhân sẽ khai thác. Các nền tảng tích hợp như Apidog giữ mọi thứ được đồng bộ hóa.
Xây dựng các quy trình đánh giá cho mã được tạo bởi AI. Đánh giá mã tiêu chuẩn không bắt được các vi phạm hợp đồng API. Tạo danh sách kiểm tra và xác thực tự động đặc biệt cho các thay đổi API.
Hãy dùng thử Apidog miễn phí để xây dựng các quy trình làm việc API nhất quán cho dù thay đổi mã tiếp theo của bạn đến từ một nhà phát triển con người, Agent Smith, hay bất kỳ công cụ mã hóa tự động nào tiếp theo.
Câu hỏi thường gặp
Google Agent Smith là gì?
Agent Smith là tác nhân mã hóa AI nội bộ của Google được xây dựng trên họ mô hình Gemini và nền tảng Antigravity. Nó hoạt động không đồng bộ trong nền: các kỹ sư giao nhiệm vụ, và Agent Smith viết, kiểm thử và lặp lại mã mà không cần tương tác của con người trong thời gian thực. Nó đã tạo ra hơn 25% mã production mới của Google tính đến tháng 3 năm 2026.
Agent Smith có sẵn bên ngoài Google không?
Không. Agent Smith là một công cụ nội bộ chỉ dành cho nhân viên Google. Google chưa công bố kế hoạch phát hành công khai. Công nghệ này tương tự như Copilot Agent Mode và Claude Code, nhưng nó được tích hợp sâu hơn với cơ sở mã và hệ thống tài liệu nội bộ của Google.
Mã do AI tạo ra có làm hỏng hợp đồng API không?
Có thể. Các tác nhân AI viết mã vượt qua kiểm thử, nhưng kiểm thử có thể không bao phủ tất cả các khía cạnh của hợp đồng API của bạn. Các thay đổi lược đồ, các trường phản hồi mới, các định dạng lỗi khác nhau và các sửa đổi hành vi có thể lọt qua kiểm thử trong khi làm hỏng các người tiêu dùng hạ nguồn. Kiểm thử hợp đồng và phát triển ưu tiên thiết kế ngăn chặn điều này.
Các nhóm API có nên lo lắng về Agent Smith không?
Không phải về Agent Smith nói riêng, vì nó là công cụ nội bộ của Google. Nhưng về xu hướng mà nó đại diện, thì có. Các công cụ mã hóa tự động tương tự (Copilot Agent Mode, KAIROS và các công cụ khác) sẽ đến với nhóm của bạn. Việc chuẩn bị quy trình làm việc API của bạn ngay bây giờ, với phát triển ưu tiên thiết kế, kiểm thử hợp đồng và các công cụ tích hợp, sẽ giúp bạn áp dụng các tác nhân tự động một cách an toàn.
Làm thế nào để tôi ngăn các tác nhân AI làm hỏng API của mình?
Sử dụng phát triển ưu tiên thiết kế với đặc tả OpenAPI làm nguồn chân lý duy nhất. Thêm kiểm thử hợp đồng với additionalProperties: false để bắt các thay đổi lược đồ không mong muốn. Chặn triển khai dựa trên xác thực đặc tả. Sử dụng một nền tảng tích hợp như Apidog tự động đồng bộ hóa các đặc tả, kiểm thử, mock và tài liệu.
Sự khác biệt giữa mã được AI hỗ trợ và mã do AI tạo ra là gì?
Mã được AI hỗ trợ (gợi ý của Copilot, các phiên của Claude Code) được viết trong thời gian thực với sự giám sát của con người. Nhà phát triển thấy và chấp thuận từng thay đổi. Mã do AI tạo ra (Agent Smith) được tạo ra không đồng bộ mà không có sự tham gia của con người trong thời gian thực. Nhà phát triển xem xét công việc đã hoàn thành sau đó. Sự khác biệt này thay đổi động lực đánh giá và tăng rủi ro vi phạm hợp đồng không được phát hiện.
Các tác nhân AI có thay thế các nhà phát triển API không?
Không. Agent Smith vẫn yêu cầu con người định nghĩa nhiệm vụ, xem xét mã và phê duyệt triển khai. Một nghiên cứu của MIT vào tháng 3 năm 2026 đã xác nhận rằng AI tăng cường năng suất của nhà phát triển nhưng không thay thế khả năng phán đoán, nhận thức ngữ cảnh và tư duy kiến trúc mà con người cung cấp. Vai trò chuyển từ viết mã sang định nghĩa nhiệm vụ, xem xét đầu ra và duy trì sự nhất quán của hệ thống.
Những điểm chính
- Agent Smith của Google tạo ra 25% mã production mới thông qua hoạt động không đồng bộ, tự động
- Điều này thể hiện sự chuyển đổi từ mã được AI hỗ trợ sang mã do AI tạo ra, làm thay đổi động lực đánh giá cho các nhóm API
- Sự lệch pha hợp đồng API là rủi ro chính khi các tác nhân tự động sửa đổi các điểm cuối và lược đồ
- Phát triển ưu tiên thiết kế với đặc tả OpenAPI làm nguồn chân lý duy nhất ngăn chặn việc phá vỡ hợp đồng
- Kiểm thử hợp đồng với xác thực lược đồ nghiêm ngặt bắt được những thay đổi mà kiểm thử đơn vị bỏ lỡ
- Các nền tảng tích hợp như Apidog đồng bộ hóa các đặc tả, kiểm thử, mock và tài liệu để ngăn chặn sự lệch pha
- Xu hướng hướng tới các tác nhân mã hóa tự động đang tăng tốc; hãy chuẩn bị các quy trình làm việc API của bạn ngay bây giờ
Agent Smith ở mức 25% là khởi đầu. Các công ty xây dựng quy trình làm việc API "chống agent" hôm nay sẽ là những người áp dụng các công cụ mã hóa tự động một cách an toàn vào ngày mai.