Link bài viết gốc： Năm thành phần để xây dựng một "company harness"
Harrison Chase · X · @hwchase17 · 2026-10-25 01:08
Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc
Làm thế nào để xây dựng một agent cho doanh nghiệp?
Tại LangChain, chúng tôi đã xây dựng các agent nội bộ cho các đội ngũ marketing, sales và kỹ thuật; chúng đã thay đổi hoàn toàn cách các đội ngũ này làm việc. Nhưng để chúng vận hành hiệu quả thì không hề dễ dàng. Chúng tôi đã dành rất nhiều thời gian giải quyết các vấn đề phát sinh từ agent cộng tác nhiều người, và cuối cùng, mỗi đội ngũ đều đúc kết ra những nguyên ngữ cốt lõi giống nhau:
- Nó hiện diện ngay tại nơi mọi người đang làm việc (đối với chúng tôi là Slack)
- Nó biết ai đang đặt câu hỏi, đại diện cho người dùng đó khi tương tác với một số dịch vụ, và dùng danh tính riêng của mình đối với các dịch vụ khác
- Nó sở hữu memory, với phạm vi có thể ở cấp độ toàn cục và/hoặc cấp độ người dùng
- Code chạy trong sandbox, và có thể gửi request đến các dịch vụ yêu cầu xác thực
- Phần lớn các lượt chạy của nó được kích hoạt theo lịch định kỳ, thay vì được ai đó gọi trực tiếp (agent thường trực!!)
Cảm ơn @caspar_br đã hỗ trợ bài blog này
LangChain Internal Agents
Để làm nền tảng cho cuộc thảo luận này, trước tiên hãy điểm qua ba agent chính mà chúng tôi đang có tại LangChain:
GTM Agent : Một agent chủ động, thường trực hỗ trợ các hoạt động GTM. Giám sát và phản hồi email, xử lý các lead đủ điều kiện mới, gửi bản tin tóm tắt hàng ngày, có thể trả lời các câu hỏi về khách hàng và thực hiện các hành động outbound
OpenSWE : Agent kỹ thuật của chúng tôi, có thể xử lý và tạo bản nháp PR, đồng thời review code cho tất cả PR
Content Studio : Agent marketing của chúng tôi, có thể tạo bản thảo nhiều loại tư liệu (blog, hình ảnh, slide thuyết trình, video) theo đúng phong cách và định vị của chúng tôi
Tất cả các agent này đều được xây dựng theo cùng một cách. Chúng tôi tin rằng đây là cách tiếp cận chung để xây dựng agent cho doanh nghiệp.
Vấn đề: Trải nghiệm người dùng (User Experience)
Tất cả các agent của chúng tôi đều hiện diện ngay tại nơi mọi người đang làm việc, và đối với chúng tôi đó là Slack. Mỗi agent đều sở hữu riêng một ứng dụng Slack , bạn có thể gửi tin nhắn trực tiếp (DM) hoặc @tag chúng trong channel. Một lợi ích của việc cộng tác với các agent này trong channel là những người khác có thể thấy cách mọi người sử dụng chúng.
Một tính năng hay mà chúng tôi đã bổ sung là khái niệm "bật tách" khỏi cuộc trò chuyện trên Slack. Rất nhiều lần, khi một cuộc thảo luận sôi nổi đang diễn ra, bạn muốn đưa agent vào để lắng nghe ý kiến hoặc giao việc cho chúng. Nhưng nếu chúng chạy ngay trong luồng thảo luận (thread) đó, chúng sẽ làm loãng cuộc trò chuyện của con người và gây xao nhãng. Vì vậy, chúng tôi đã bổ sung một cách đơn giản để agent có thể "tách riêng" sang thread của chính nó trong channel.
Có những trải nghiệm người dùng tốt nhất không nên diễn ra trong Slack. Ví dụ, khi duyệt qua các email mà GTM Agent muốn tôi gửi, xử lý từng cái một trong Slack thì ổn, nhưng khi có một lượng lớn bị tồn đọng, việc theo dõi các email này qua tin nhắn Slack chắc chắn không phải là trải nghiệm dễ chịu gì. Đối với loại trải nghiệm này, chúng tôi cuối cùng đã xây dựng một giao diện người dùng tùy chỉnh.
Vấn đề: Danh tính (Identity)
Vấn đề hóc búa và phức tạp nhất mà chúng tôi từng giải quyết chính là danh tính, cụ thể là: khi các agent này thực hiện hành động, chúng đang đại diện cho ai?
Trong ngành hiện có hai cách tiếp cận chính cho vấn đề này:
- Đại diện (On-behalf-of) : Agent đại diện cho người dùng gọi nó để hành động
- Thông tin xác thực cố định : Bất kể ai gọi, agent đều sử dụng một bộ thông tin xác thực cố định (chẳng hạn như service account)
Dưới đây là cách chúng tôi xử lý cho từng agent (tài liệu: Thêm danh tính vào Managed Deep Agents , Quản lý kết nối ):
OpenSWE:
- Khi bạn nhắn tin cho nó, nó đại diện cho bạn để hành động (ví dụ: dùng tài khoản GitHub của bạn để mở PR)
- Khi nó chạy ngầm (ví dụ: với tư cách là agent review code), nó sử dụng danh tính của chính mình (ứng dụng GitHub)
GTM Agent:
- Nó có một số công cụ (ví dụ: quyền truy cập Salesforce) sử dụng danh tính cố định, nhờ đó không phải ai cũng cần đăng nhập
- Nó có một số công cụ (ví dụ: email) đại diện cho người dùng gọi nó. Các công cụ này chỉ khả dụng trong tin nhắn trực tiếp (DM). Trong channel chung, chúng không được kích hoạt
Content Studio:
- Nó có một số công cụ (ví dụ: Notion) đại diện cho người dùng gọi nó
- Nó có một số công cụ (ví dụ: Twitter) sử dụng một bộ thông tin xác thực cố định, ở đây là tài khoản Twitter của công ty chúng tôi. Tuy nhiên, chỉ những người dùng trong whitelist mới có thể gọi một số thao tác nhất định. Ví dụ: không phải ai cũng có thể đăng bài lên Twitter (họ có thể chỉ có quyền đọc / tạo bản nháp)
Vấn đề: Memory
Tất cả các agent đều có hai tầng memory :
- Memory toàn cục: memory áp dụng cho tất cả người dùng
- Memory người dùng: memory chỉ áp dụng cho người dùng cụ thể
Agent tự quyết định sự kiện nào nên được lưu vào tầng memory nào.
Đây có lẽ là mảng còn ít được khám phá nhất hiện nay — chúng tôi vẫn còn rất nhiều điều muốn làm ở đây!
Vấn đề: Thực thi code (Code execution)
Cả ba agent của chúng tôi đều có thể viết và thực thi code, và thường xuyên phải làm điều đó để hoàn thành nhiệm vụ. Chúng đều tuân theo mô hình chạy bên ngoài sandbox, nhưng kết nối vào sandbox và thực thi code bên trong đó. Mỗi agent đều có base image hơi khác nhau với các dependency khác nhau. OpenSWE (agent thiên về coding nhất) sẽ chọn khởi chạy base image nào một cách thông minh (tùy thuộc vào channel/người dùng). Tất cả chúng đều tận dụng secret proxy trong LangSmith Sandboxes (xem thêm Thêm sandbox vào Managed Deep Agents ), giúp agent kết nối đến các dịch vụ từ bên trong sandbox một cách an toàn và bảo mật.
Vấn đề: Chạy theo lịch trình (Scheduled runs)
Một phần lớn lượt chạy được lên lịch trước hoặc do các sự kiện kích hoạt ngầm, thay vì do người dùng trực tiếp khởi chạy.
Một số trong đó do nhà phát triển của agent thiết lập. Ví dụ: OpenSWE lắng nghe các pull request, và khi có PR mới được tạo, nó sẽ tiến hành review.
Một số khác được thiết lập theo yêu cầu của người dùng đối với agent. Ví dụ: tôi yêu cầu GTM Agent gửi bản tóm tắt hàng ngày cho mình, và nó đã tự tạo một cron job .
Tất cả đều được xây dựng trên Managed Deep Agents
Tất cả các agent này đều được xây dựng trên Managed Deep Agents , vốn dựa trên framework mã nguồn mở Deep Agents . Nó cung cấp cơ sở hạ tầng để giải quyết tất cả các vấn đề này (channel, cron job, sandbox, memory, danh tính), đồng thời mang lại đủ sự linh hoạt để tùy chỉnh hành vi của agent theo nhu cầu. Hãy trải nghiệm ngay thông qua quickstart nhé!