Trong quá trình thúc đẩy việc giới thiệu các AI agent cho các phòng ban khác trong Notion như một phần công việc của tôi và hỗ trợ triển khai cho các công ty sử dụng phương pháp FDE, một số mô hình nhất định đã xuất hiện. Tôi đã xây dựng các agent cho bộ phận bán hàng, bán hàng nội bộ, tiếp thị, phát triển sản phẩm, thành công của khách hàng, v.v., nhưng tất cả đều phải đối mặt với những rào cản chung ở cấp độ thực địa và rào cản tổ chức ở cấp độ doanh nghiệp. Cả hai đều không thể tránh khỏi, và tôi tin rằng hầu hết các công ty đều mắc kẹt ở những chỗ giống nhau.
▍Rào Cản Tại Hiện Trường
① Vấn Đề Phạm Vi Trở Nên Quá Nhỏ
Tôi đã thử tạo một agent cho bộ phận bán hàng có chức năng "tự động nghiên cứu khi có khách hàng tiềm năng mới." Tôi hình dung toàn bộ quy trình: khi một khách hàng tiềm năng xuất hiện trong danh sách, agent sẽ nghiên cứu và phân tích thông tin nội bộ và bên ngoài, sau đó tạo bản nháp email. Tôi bắt đầu bằng cách xây dựng phần nghiên cứu thông tin khi có mục nhập mới vào cơ sở dữ liệu khách hàng tiềm năng. Ý định của tôi là một khi nền tảng đã sẵn sàng, việc tự động hóa việc tạo email sẽ trở nên dễ dàng.
Tuy nhiên, sau khi thiết lập bản dựng ban đầu và giao quyền sở hữu cho nhóm hiện trường, họ đã không tự động hóa các bản nháp email ngay cả sau vài tuần. Khi tôi phỏng vấn họ, họ nói, "Chỉ cần có nó nghiên cứu khách hàng tiềm năng thôi đã rất tiện lợi rồi!" Nhóm không nhận ra rằng họ có thể tiến xa hơn đến việc tạo bản nháp email, hoặc ý tưởng tự động hóa nhiều như vậy thậm chí còn chưa từng xuất hiện trong đầu họ. Có vẻ như họ cũng do dự vì cảm thấy nó khó khăn.
Đây là mô hình đầu tiên khiến việc triển khai agent bị đình trệ: làm cho phạm vi công việc quá nhỏ, dẫn đến việc sử dụng có lợi nhuận thấp mặc dù đã xây dựng được agent. Cuối cùng, nó chỉ được sử dụng cho các chức năng riêng lẻ hoặc các tác vụ nhỏ.
② Vấn Đề Dừng Lại Vì Quá Lớn
Vấn đề thứ hai là ngược lại: cố gắng biến một quy trình kinh doanh phức tạp thành một agent chỉ để nhận ra rằng bản thân quy trình đó không được cấu trúc với độ chi tiết cao. Những người khác nhau làm mọi việc theo những cách khác nhau, hoặc có quá nhiều kiến thức ngầm. Cố gắng quá kỹ lưỡng dẫn đến thời gian tan biến ngay trong các cuộc phỏng vấn, không bao giờ đến được giai đoạn xây dựng. Số lượng các bên liên quan tăng lên, và chi phí để đạt được sự đồng thuận tăng vọt. Sự nhiệt tình ban đầu dần dần lụi tàn...
Đây là một vấn đề về thiết lập phạm vi trong quản lý dự án. Bạn muốn làm gì với agent? Bạn muốn đạt được kết quả gì? Nếu kết quả đã được quyết định, phạm vi cần thiết và đủ cho agent sẽ được xác định. Việc mơ hồ nhắm đến "hiệu quả kinh doanh với các agent" sẽ dẫn đến sa lầy.
③ Sự Vắng Mặt Của Quyền Sở Hữu
Ngay cả khi người thúc đẩy xây dựng nó với động lực, nếu trách nhiệm cải tiến hoặc sửa lỗi còn mơ hồ, việc sử dụng sẽ dần dần giảm sút. Người thúc đẩy cũng hết hơi. Lý tưởng nhất là nhóm hiện trường nên nuôi dưỡng agent như của riêng họ. Nếu thiếu điều này, mọi thứ có vẻ tốt trong ba tháng đầu nhưng không thể mở rộng quy mô. Khi số lượng các bên liên quan tăng lên - đặc biệt là khi phạm vi công việc mở rộng - nhu cầu đồng thuận và xác nhận tăng lên, và ý thức về quyền sở hữu (ai sở hữu nó) dần dần mỏng đi.
Ba vấn đề này không phải là những vấn đề độc lập; chúng đều có liên quan với nhau. Nếu thiết kế phạm vi sai, quyền sở hữu sẽ không được thiết lập, và nếu không có chủ sở hữu, phạm vi sẽ không mở rộng.
▍Rào Cản Tổ Chức
Ngay cả khi bạn vượt qua các rào cản tại hiện trường, vẫn còn bốn bức tường nữa ngoài việc "tạo ra thứ gì đó hoạt động" trong một doanh nghiệp.
④ Tính Minh Bạch Của Vốn Token
Ngay cả khi mức tiêu thụ token có thể nhìn thấy được theo từng phòng ban, thường không rõ "loại công việc nào đã được thực hiện và kết quả nào đã đạt được." Điều này trở thành một vấn đề từ góc độ vốn token và quản lý token, khiến cho việc biện minh cho ngân sách là không thể. Do đó, ban quản lý chỉ xem token như một chi phí tiêu thụ, hỏi rằng, "Vậy, nó sẽ tốn bao nhiêu?"
⑤ Quản Trị
Ai có thể tạo agent, ai có thể xem chúng, và ai quản lý chúng? Nếu điều này còn mơ hồ, tổ chức sẽ bị tràn ngập bởi "các agent đi lạc" hoặc "các agent zombie" chạy nhưng không ai sử dụng. Không ai chịu trách nhiệm, không có ngân sách được đảm bảo, token bị tiêu thụ lãng phí, và rủi ro bảo mật tăng lên cho đến khi mọi thứ dừng lại.
⑥ Khả Năng Quan Sát
Agent đã chạy bao nhiêu lần, nó thành công thường xuyên như thế nào, và nó thất bại ở đâu? Đây là một yêu cầu tối thiểu cho hoạt động, nhưng nhiều công cụ lại yếu ở điểm này. Bạn không thể cải thiện những gì bạn không thể thấy. Chỉ với khả năng quan sát, bạn mới có thể xây dựng một vòng phản hồi để cải thiện agent.
⑦ Tính Linh Hoạt Trong Việc Lựa Chọn Mô Hình
Phụ thuộc quá nhiều vào một nhà cung cấp LLM cụ thể là một rủi ro. Điều gì xảy ra nếu hiệu suất giảm tạm thời? Điều gì xảy ra nếu nó dừng lại do sự cố? Điều gì xảy ra nếu các hạn chế xuất khẩu khiến nó không khả dụng? Nếu bạn không thể chuyển sang nhà cung cấp khác ngay lập tức, bạn không thể triển khai các agent gắn trực tiếp với hoạt động kinh doanh. AI đã trở thành cơ sở hạ tầng, nhưng sự phụ thuộc cực đoan hiện đang được dung thứ một cách mù quáng.
Tóm Lược
Việc triển khai agent trông giống như một cuộc thảo luận kỹ thuật, nhưng thực ra nó là về thiết kế kinh doanh và quyền sở hữu. Để đảm bảo nó không kết thúc chỉ với "AI thật tuyệt vời," cần có nền tảng cho quản trị và khả năng quan sát trước tiên.
Không quá nhỏ, không quá lớn, và được nuôi dưỡng bởi một người có trách nhiệm. Và một hệ thống để hỗ trợ điều đó như một tổ chức. Tôi tin rằng các agent chỉ bén rễ khi cả hiện trường và tổ chức đều đồng lòng.
