Ngày 17 tháng 6 năm 2026, Google cùng mười đối tác trong ngành — Microsoft, Hugging Face, Cisco, Nvidia, Salesforce, Snowflake, GitHub, ServiceNow, Databricks, và GoDaddy — công bố một đặc tả có thể thay đổi cách mọi internal platform được tiêu thụ bởi AI agent.
Đó là Agentic Resource Discovery (ARD). Nếu bạn chưa nghe đến, sắp tới bạn sẽ nghe rất nhiều. Và với tư cách Tech Lead, bạn cần đưa ra quyết định sớm hơn bạn nghĩ.
Vấn Đề ARD Giải Quyết
Mô hình tích hợp AI agent hiện tại trông như thế này: developer đọc docs, tìm MCP server hoặc API, hardcode vào cấu hình agent, rồi ship. Lặp lại cho mỗi tool mới, mỗi agent mới.
Cách này ổn khi chỉ có vài chục tools. Nó sụp đổ khi mọi công ty, mọi team sản phẩm, mọi developer đều có thể publish MCP server hoặc skill riêng. Ở quy mô đó, hardcoded integration không còn khả thi — bạn cần runtime discovery.
Ví dụ tương tự là DNS. Trước khi có DNS, bạn phải duy trì danh sách địa chỉ host thủ công. DNS tự động hóa việc discovery. ARD đang làm điều tương tự cho AI tools.
ARD định nghĩa hai primitive:
ai-catalog.json— manifest machine-readable mà tổ chức của bạn host tại/.well-known/ai-catalog.json, liệt kê các capabilities có sẵn- Registry API — các federated registry crawl, index, và tìm kiếm các manifest đó dựa trên task intent bằng ngôn ngữ tự nhiên
Cách Hoạt Động: Vòng Đời Discovery
Agent cần một capability
↓
Query ARD Registry (ngôn ngữ tự nhiên: "gửi email với đính kèm")
↓
Registry trả về kết quả xếp hạng + trust metadata
↓
Agent xác minh danh tính publisher (domain-based trust)
↓
Agent kết nối qua native protocol (MCP, A2A, OpenAPI)
↓
Task thực thiĐiểm quan trọng cần nhớ: ARD không phải invocation protocol mới. Nó đứng trước MCP, trước A2A, trước OpenAPI. ARD trả lời câu hỏi “nên dùng tool nào?” — không phải “cách dùng tool đó như thế nào?”
Nếu MCP là cổng USB-C, thì ARD là search engine nói cho agent biết cần cắm vào cổng nào.
Cấu Trúc ai-catalog.json
Manifest nằm tại /.well-known/ai-catalog.json — theo RFC 8615 well-known URI. Ví dụ tối giản:
{
"$schema": "https://agenticresourcediscovery.org/schemas/v0.9/ai-catalog.schema.json",
"publisher": {
"name": "Acme Corp",
"domain": "acme.com",
"contact": "platform@acme.com"
},
"capabilities": [
{
"id": "urn:ai:acme:platform:order-service",
"type": "application/mcp-server+json",
"name": "Order Management Service",
"description": "Tạo, cập nhật, truy vấn và hủy đơn hàng khách hàng. Hỗ trợ batch operations và webhook notifications.",
"tags": ["orders", "ecommerce", "fulfillment"],
"url": "https://platform.acme.com/mcp/orders",
"trust": {
"level": "verified",
"certUrl": "https://acme.com/.well-known/ard-trust.json"
}
},
{
"id": "urn:ai:acme:platform:inventory-api",
"type": "application/openapi+json",
"name": "Inventory Query API",
"description": "Kiểm tra tồn kho real-time, tra cứu SKU, tình trạng kho theo địa điểm.",
"tags": ["inventory", "stock", "warehouse"],
"url": "https://api.acme.com/inventory/openapi.json"
}
]
}Những quyết định thiết kế quan trọng trong schema:
- Artifact-agnostic envelopes — trường
typelà IANA media type. ARD không redifine MCP hay OpenAPI, chỉ reference chúng - URN-based identifiers — đảm bảo uniqueness trên federated registries
- Domain-based trust — vì manifest nằm trên domain của bạn, quyền sở hữu domain là bằng chứng danh tính publisher
- Tag-based discoverability — agents và registries dùng tags cho semantic search
ARD vs. MCP: Không Phải Đối Thủ
Nhầm lẫn phổ biến tôi gặp trong các team: “Chúng ta cần ARD hay MCP?”
Cả hai. Chúng giải quyết vấn đề khác nhau ở các giai đoạn khác nhau.
| Mối quan tâm | MCP | ARD |
|---|---|---|
| Khi nào | Thời điểm invocation | Thời điểm discovery (trước invocation) |
| Câu hỏi trả lời | ”Gọi tool này như thế nào?" | "Nên dùng tool nào?” |
| Định nghĩa gì | Request/response protocol, tool schemas | Manifest format, registry API, trust signals |
| Tương tự | Chuẩn cổng USB-C | Tìm kiếm thiết bị USB / device manager |
Hãy nghĩ về pipeline này:
ARD Registry → discover tool
↓
MCP / A2A / OpenAPI → invoke tool
↓
Agent → dùng kết quảBạn cần cả hai lớp. ARD làm cho discovery có thể xảy ra ở quy mô lớn; MCP (hoặc A2A) làm cho invocation trở nên đáng tin cậy.
GitHub Đang Làm Gì Với ARD
GitHub công bố Agent Finder được xây dựng trên ARD — một capability trong GitHub Copilot cho phép agent động tự khám phá và gọi đúng MCP server, skills, tools, và agents cho một task tại runtime, không cần developer cài đặt trước.
Hàm ý: nếu internal services của bạn publish ai-catalog.json, GitHub Copilot agents có thể tự động discover và sử dụng chúng. Không cần tích hợp thủ công.
Đây là sự thay đổi lớn trong cách platform team nghĩ về services của mình.
Ý Nghĩa Thực Tế Với Tech Lead
1. Bắt đầu xem services như agent-consumable assets
Mỗi internal service team bạn sở hữu là một potential agent resource. Câu hỏi không còn chỉ là “nó có REST API tốt không?” mà còn là “agent có thể tìm thấy nó, hiểu nó làm gì, và quyết định dùng nó không?”
Điều này có nghĩa descriptions quan trọng hơn bao giờ hết. Trường description trong ai-catalog.json là thứ agents dùng để semantic matching. Mô tả mơ hồ = khả năng discover kém.
2. Tạo platform ai-catalog.json ngay hôm nay
Đây là việc effort thấp, value cao mà bạn có thể làm ngay. Ngay cả khi chưa có ARD registry được deploy nội bộ, publish manifest đặt platform của bạn vào vị trí tốt khi tổ chức bắt đầu deploy ARD-aware agents.
Các bước:
- Kiểm kê services của team: MCP servers, REST APIs, internal tools
- Viết manifest tại
/.well-known/ai-catalog.jsoncho domain của bạn - Thêm meaningful tags và descriptions cho mỗi entry
- Tùy chọn submit lên public ARD registries nếu services là external-facing
3. Coi discoverability là first-class concern trong API design
Khi viết OpenAPI spec hoặc MCP tool definition, hãy tự hỏi:
- “Nếu agent tìm kiếm capability này bằng ngôn ngữ tự nhiên, nó có tìm thấy service này không?”
- “Tên và description có đủ cụ thể để agent không nhầm với service khác không?”
- “Tag list có bao gồm các từ mà agents có thể tìm kiếm không?”
Đây là semantic SEO cho APIs của bạn.
4. Lên kế hoạch cho internal registry strategy
ARD hỗ trợ federated registries — bạn có thể chạy private registry chỉ index internal services, không expose ra public registries. Với enterprise có internal platforms, đây thường là architecture bạn muốn:
Internal ARD Registry (chỉ trong corporate network)
├── Index ai-catalog.json manifests nội bộ
└── Feed vào internal agent orchestration platforms
Public ARD Registry (ví dụ: Hugging Face, GitHub)
├── Index public-facing services
└── Accessible bởi GitHub Copilot, third-party agents5. Thêm trust metadata cho production
Spec hỗ trợ cryptographic trust signals. Với internal production use, bạn cần định nghĩa:
- Ai được phép publish capabilities dưới domain của bạn
- Registries nào được agents của bạn tin tưởng
- Cách trust signals được validate trước khi agent kết nối với tool mới
Không có lớp này, bạn dễ bị tấn công catalog poisoning — kẻ xấu publish catalog giả mạo services của bạn.
Ví Dụ Code: Annotate ASP.NET API Cho ARD
Nếu bạn chạy .NET services, đây là cách tiếp cận:
Bước 1: Thêm well-known endpoint
// Program.cs
app.MapGet("/.well-known/ai-catalog.json", () =>
{
return Results.Json(new
{
schema = "https://agenticresourcediscovery.org/schemas/v0.9/ai-catalog.schema.json",
publisher = new
{
name = "MyCompany Platform",
domain = "platform.mycompany.com"
},
capabilities = new[]
{
new
{
id = "urn:ai:mycompany:platform:customer-service",
type = "application/openapi+json",
name = "Customer Data Service",
description = "Truy vấn và cập nhật hồ sơ khách hàng, trạng thái subscription và lịch sử mua hàng. Hỗ trợ lọc theo ngày, phân khúc khách hàng và khu vực.",
tags = new[] { "customers", "profiles", "subscriptions", "purchase-history" },
url = "https://platform.mycompany.com/customers/openapi.json"
}
}
});
});Bước 2: Viết OpenAPI descriptions tốt hơn
[HttpGet("{customerId}/orders")]
[EndpointSummary("Lấy lịch sử đơn hàng của khách hàng")]
[EndpointDescription(
"Trả về lịch sử đơn hàng phân trang của khách hàng bao gồm " +
"trạng thái đơn hàng, line items, tracking vận chuyển và trạng thái hoàn tiền. " +
"Dùng khi agent cần tra cứu khách hàng đã mua gì hoặc " +
"kiểm tra trạng thái đơn hàng gần đây.")]
public async Task<IActionResult> GetCustomerOrders(string customerId, ...)Description trong OpenAPI spec của bạn ảnh hưởng trực tiếp đến cách agents hiểu tools — cả qua ARD discovery và khi đang dùng tool.
Bức Tranh Lớn Hơn: The Agentic Web
ARD đại diện cho một sự thay đổi triết học đáng được nêu tên: web đang được tái cấu trúc cho agents, không chỉ cho humans.
Pattern robots.txt / sitemap.xml — các well-known files nói với crawlers cách tương tác với site của bạn — chính là mô hình ARD theo. Nhưng thay vì nói với Google crawler những trang nào tồn tại, bạn đang nói với AI agents những capabilities nào tồn tại.
Convention llms.txt xuất hiện năm 2025 để giúp LLMs hiểu nội dung site của bạn. ai-catalog.json là lớp tiếp theo: site của bạn có thể làm gì.
Với tư cách Tech Lead, đây không phải việc có thể trì hoãn vô thời hạn. Khi tổ chức của bạn bắt đầu deploy AI agents dùng ARD registries — và timeline đó tính bằng tháng, không phải năm — những teams đã publish catalog sẽ có services được sử dụng. Những teams chưa publish sẽ trở nên vô hình.
Tóm Tắt: Làm Gì Tuần Này
| Hành động | Effort | Giá trị |
|---|---|---|
Publish /.well-known/ai-catalog.json cho services | Thấp (vài giờ) | Cao |
| Audit API descriptions cho agent-discoverability | Trung bình (1-2 ngày) | Cao |
| Setup internal ARD registry | Trung bình-Cao | Cao |
| Thêm trust metadata và signing | Cao | Rất quan trọng cho production |
ARD v0.9 là draft spec. Nó sẽ tiếp tục phát triển. Nhưng pattern cốt lõi — manifest tại well-known path, indexed bởi federated registries, queried bởi agents tại runtime — là vững chắc và có đủ sự hậu thuẫn từ ngành để không nên đặt cược vào việc nó thất bại.
Publish catalog của bạn. Viết descriptions tốt hơn. Làm services của bạn visible với lớp tiếp theo của stack.
Đặc tả ARD (v0.9): agenticresourcediscovery.org — Apache 2.0 license InfoQ: Google và các đối tác công bố ARD GitHub Agent Finder: commandline.microsoft.com