Chiều hôm qua, một kỹ sư trong nhóm đã xem Anthropic trình bày về hệ thống GTM nội bộ của họ trên sân khấu SaaStr, chụp lại slide và hỏi Zero một câu duy nhất: chúng ta còn thiếu gì trong số này? Sáu giờ mười chín phút sau, Snowflake đã hoạt động trên môi trường sản xuất cho mọi khách hàng Zero. Đó là tích hợp thứ 180 mà chúng tôi đã phát hành trong một năm, và ngày càng nhiều, người viết tích hợp tiếp theo không còn là kỹ sư nữa. Đây là khung nền tảng, cùng kỹ năng nội bộ trên đó, giúp điều này trở thành hiện thực.
Điều không ai nói với bạn về nền tảng agent
Một LLM giống như bộ não trong lọ. Tự nó, nó có thể viết cho bạn một bài thơ về kho dữ liệu, nhưng không thể thực sự mở nó ra. Điều biến chatbot thành agent, điều mà nhóm của bạn thực sự trả tiền, là liệu agent có thể truy cập vào các công cụ bạn đang dùng và thực hiện công việc trong đó hay không.
Chúng tôi gọi khả năng truy cập đó là lớp connector. Sau một năm xây dựng Zero, chúng tôi tin rằng đây là phần hạ tầng quan trọng nhất trong một sản phẩm agent. Vì vậy, chúng tôi đã tự xây dựng nó. Quan trọng hơn, chúng tôi xây dựng một quy trình làm việc xung quanh nó để bất kỳ ai trong nhóm cũng có thể tự tạo một connector.
Vì sao không dùng MCP. Vì sao không dùng Zapier.
Cả hai đều được hỏi từ sớm. Cả hai đều tốt với mục đích của mình. Nhưng không cái nào phù hợp với nhu cầu của chúng tôi.
MCP là một giao thức, không phải sản phẩm. Tuyệt vời cho tác giả công cụ muốn dịch vụ của mình được bất kỳ LLM nào truy cập. Nhưng máy chủ MCP, như hiện tại, chỉ đưa cho mô hình một danh sách công cụ và tin tưởng nó gọi đúng cách. Không có kho thông tin xác thực riêng cho từng tổ chức, không có tường lửa kiểm soát endpoint nào được phép truy cập, không có nhật ký kiểm tra liên kết cuộc gọi với người đã phê duyệt. Với một sản phẩm mà một agent có thể truy cập Stripe sản xuất của khách hàng và agent khác có thể soạn email trong Gmail của CEO, "tin tưởng mô hình" không phải là mô hình bảo mật.
Nền tảng tích hợp kiểu Zapier giải quyết vấn đề khác: nối các trigger xác định với hành động xác định. Agent không hoạt động như vậy. Một agent quyết định, giữa chừng, rằng bước tiếp theo là truy vấn Snowflake rồi tạo ticket Linear. Nó cần thông tin xác thực, HTTP client được giới hạn phạm vi, và nhật ký kiểm tra ngay lập tức, không phải là công thức dựng sẵn.
Vì vậy, chúng tôi xây dựng thứ đơn giản: một registry tích hợp, mỗi mục mang metadata xác thực, ánh xạ môi trường để bí mật được tiêm vào sandbox, tường lửa kiểm soát host, và một handler nhỏ cho các trường hợp OAuth hoặc token đặc biệt. Đó là hạ tầng.
Nhưng hạ tầng không phải phần thú vị nhất. Phần thú vị là những gì xảy ra trên nền tảng đó.
Kỹ năng biến mọi người thành tác giả connector
Mỗi ngày, backlog tích hợp của chúng tôi lại có thêm một SaaS mới. Có cái đến từ yêu cầu khách hàng. Có cái do thành viên phát hiện Zero chưa làm được điều họ cần. Có cái từ cuộc trò chuyện BD khi khách hàng tiềm năng dùng công cụ chúng tôi chưa từng gặp.
Nếu mỗi cái đều phải qua hàng đợi kỹ sư, chúng tôi chỉ phát hành được một cái mỗi tuần. Nhưng thực tế là một cái mỗi ngày.
Lý do là một công cụ nội bộ mà chúng tôi gọi là kỹ năng tạo connector. Đây là một kỹ năng Zero, cùng định dạng như chúng tôi cung cấp cho khách hàng, nhưng hướng vào chính codebase của mình. Khi ai đó trong nhóm nói "Tôi muốn thêm connector Notion", Zero sẽ hướng dẫn từng bước:
- Bắt đầu từ kịch bản người dùng. Người dùng thực sự muốn làm gì với công cụ này? "Truy vấn cơ sở dữ liệu", "tạo trang", "tìm kiếm toàn workspace." Kỹ năng yêu cầu phải có câu chuyện người dùng cụ thể trước khi động đến bất kỳ file nào. Mục tiêu của connector là mở rộng khả năng cho agent, không phải bao phủ toàn bộ API.
- Xác định dạng xác thực. OAuth, API token, hoặc cả hai. Kỹ năng biết mỗi dạng cần gì: với OAuth là UI đồng ý và luồng chuyển hướng; với API token là tiêm bí mật cho từng tổ chức và nơi người dùng lấy token. Tác giả chọn dạng phù hợp với công cụ; mọi thứ phía sau sẽ tự động.
- Ánh xạ endpoint với kịch bản. Không phải "bao toàn bộ REST API." Chỉ chọn vài endpoint đáp ứng câu chuyện người dùng. Một connector với ba endpoint hợp lý còn hơn bốn mươi endpoint mà agent không bao giờ dùng.
- Tạo khung mười hai file. Mục registry, handler, mẫu tường lửa, icon nền tảng, luồng ánh xạ môi trường, kỹ năng hướng agent dạy Zero cách dùng connector. Kỹ năng viết khung; tác giả viết ý định.
- Mở hai PR. Một vào framework connector, một vào thư viện kỹ năng. Cả hai đều được kỹ sư review, nhưng review chỉ để kiểm tra đúng sai, không phải dạy tác giả cách framework hoạt động.
Những gì từng đòi hỏi kiến thức nội bộ (dạng xác thực nào, endpoint nào, mười hai file nào ở hai repo nào, cách mẫu tường lửa kết hợp với subdomain động) giờ đã nằm trong kỹ năng. Tác giả mang sự thấu hiểu người dùng. Kỹ năng mang khung sườn.
Đây là cách một designer, trưởng BD, hay PM có thể tự phát hành connector. Họ biết người dùng cần gì. Kỹ năng biết mọi thứ còn lại.
Nghiên cứu điển hình: Snowflake, ngày hôm qua
Hôm qua Anthropic trình bày về hệ thống GTM nội bộ trên sân khấu SaaStr: Salesforce làm hệ thống chính, Clay để làm giàu dữ liệu, LeanData để định tuyến, Gong cho cuộc gọi, Jira cho ticket, Intercom (Fin) cho hỗ trợ, Ironclad cho hợp đồng, Snowflake làm kho dữ liệu. [liên kết tới bài nói]
Một kỹ sư của chúng tôi chụp lại slide và gửi vào Zero với một câu hỏi: "chúng ta còn thiếu connector nào trong số này?"
Đây là dòng thời gian thực tế. Tất cả thời gian theo PDT.
16:59. Ảnh chụp được gửi vào. Zero so sánh với danh mục connector: 7 trong số 10 đã có (Salesforce, Gong, Jira, Intercom, Ironclad, Gmail, Slack). Còn thiếu ba cái (Clay, LeanData, Snowflake), và Snowflake được đánh dấu là giá trị nhất, vì kho dữ liệu là nền tảng của GTM stack. Phản hồi gửi lúc 17:00.
17:01. Hỏi tiếp: "cái nào có thể làm connector api-token?" Zero tra tài liệu xác thực: Clay có API key cá nhân, Snowflake vừa ra mắt Programmatic Access Tokens, LeanData chỉ có OAuth và phụ thuộc Salesforce. Kết luận lúc 17:02: Snowflake trước (giá trị cao nhất, xác thực sạch nhất), sau đó là Clay.
17:04. Kỹ sư nói "bắt đầu". Kỹ năng tạo connector nhận việc. Đến 17:07 đã loại Clay (chỉ có webhook từng bảng, không có connector thực sự để xây) và xác nhận dạng của Snowflake: bí mật SNOWFLAKE_PAT + biến SNOWFLAKE_ACCOUNT, xác thực bearer với Snowflake REST API và SQL API v2, mẫu tường lửa subdomain động dựa trên Zendesk.
17:35. Cả hai PR mở cùng lúc:
vm0-skills#176: kỹ năng hướng agent. Cách viết Snowflake SQL, định dạng kết quả, thử lại khi lỗi tạm thời.vm0#13356: chính connector. Mục registry, handler PAT, generator tường lửa, icon nền tảng, luồng ánh xạ môi trường.
18:22. Merge PR kỹ năng.
18:42. Merge PR connector.
18:52. PR phát hành tự động mở.
23:18. [email protected] và các phần còn lại của chuỗi phát hành được triển khai lên production. Snowflake hoạt động cho mọi tổ chức.
Sáu giờ mười chín phút từ "ảnh chụp stack của Anthropic" đến "Zero có thể truy vấn kho dữ liệu của bạn." Một kỹ sư. Một cuộc trò chuyện. Không chuyển giao cho "nhóm connector".
Tốc độ này không phải vì kỹ sư nhanh. Mà vì kỹ năng tạo connector đã gánh phần từng đòi hỏi kiến thức nội bộ: chọn dạng xác thực nào, endpoint nào phù hợp kịch bản người dùng, mười hai file nào cần vào hai repo nào, cách mẫu tường lửa kết hợp với subdomain động. Tác giả viết ý định. Kỹ năng viết khung sườn. Phần còn lại là production xử lý.
Đó là giá trị của framework này. Không chỉ là tốc độ (dù tốc độ rất thật), mà là ai có thể làm việc đó. Người tạo Snowflake lần này là kỹ sư. Nhưng không nhất thiết phải là kỹ sư.
Vì sao api-token là công dân hạng nhất
Một lưu ý đáng nói, vì đây là lựa chọn thiết kế có chủ đích khiến nhiều người bất ngờ.
Hầu hết nền tảng agent coi OAuth là xác thực duy nhất và api-token chỉ là giải pháp dự phòng cho công cụ cũ. Chúng tôi làm ngược lại. API token là công dân hạng nhất trong mô hình connector của chúng tôi, với cùng UI đồng ý, cùng kho bí mật cho từng tổ chức, cùng nhật ký kiểm tra, cùng kiểm soát tường lửa.
Có hai lý do.
Thứ nhất là xác thực api-token giúp thời gian đến lần sử dụng đầu tiên ngắn hơn. Snowflake vừa ra mắt Programmatic Access Tokens vì lý do này: thông tin xác thực lâu dài, có phạm vi, thu hồi được mà không cần quy trình OAuth. Người dùng có PAT có thể dùng Zero chỉ trong chưa đầy một phút. Quy trình OAuth, dù gọn, vẫn lâu hơn và đòi hỏi nhiều hơn từ người dùng.
Thứ hai là OAuth không phải lúc nào cũng có. Một số công cụ doanh nghiệp không cung cấp OAuth, hoặc chỉ có ở gói Enterprise. Đưa api-token lên ngang hàng (không phải dự phòng) giúp chúng tôi hỗ trợ các công cụ đó đầy đủ thay vì để chúng trong "sắp ra mắt" mãi mãi.
Connector Snowflake phát hành hôm qua dùng api-token. Connector Gmail gửi luồng email khách hàng dùng OAuth. Cả hai đều qua cùng framework, cùng kỹ năng, cùng quy trình review. Tác giả chọn dạng phù hợp với công cụ, framework giúp xây cái nào cũng dễ.
Tích hợp thứ 180 thực sự mở khóa điều gì
Con số không phải là điểm chính. Điểm chính là ở mật độ này, agent không còn là công cụ bạn gọi mà trở thành môi trường bạn sống trong đó.
Khi Zero có connector tới CRM và kho dữ liệu và hộp thư hỗ trợ và công cụ thiết kế và repo của bạn, nó có thể làm những điều mà agent chỉ có một tích hợp không thể làm. Nó có thể lấy truy vấn Snowflake, đối chiếu với ticket Linear đang mở, rồi đăng tóm tắt vào kênh Slack nơi nhóm CS làm việc. Nó có thể đọc cuộc gọi Gong, tìm tính năng khách hàng hỏi, kiểm tra xem đã có trong roadmap chưa, rồi soạn email follow-up, tất cả trong một lần.
Mỗi connector mới không tăng giá trị tuyến tính. Nó tăng giá trị theo tổ hợp. Connector thứ 180 giá trị hơn connector đầu tiên, vì nó kết hợp với 179 cái trước đó.
Đó là niềm tin phía sau framework. Và niềm tin phía sau kỹ năng là tốc độ cộng dồn phụ thuộc vào số người trong nhóm bạn được phép đóng góp.
Tiếp theo là gì
Chúng tôi đang làm việc để mở kỹ năng tạo connector cho khách hàng. Nếu bạn đang dùng Zero cho nhóm và cần tích hợp với công cụ nội bộ (hệ thống thanh toán, kho dữ liệu, bảng điều khiển quản trị nội bộ), quy trình giống hệt đã phát hành Snowflake hôm qua sẽ là quy trình bạn dùng để phát hành tích hợp của mình. Cùng khung sườn, cùng mô hình xác thực, cùng tường lửa, cùng nhật ký kiểm tra. Khác tác giả.
Nếu bạn quan tâm, hãy liên hệ với chúng tôi.
