Cách Linear xây dựng AI Agent: Thiết lập ranh giới qua Prompt, công cụ và kỹ năng hệ thống

Hầu hết các phần mềm đều được thiết kế để hoạt động một cách nhất quán. Kỹ thuật tốt thường đồng nghĩa với việc thu hẹp phạm vi các kết quả có thể xảy ra, sao cho cùng một hành động luôn mang lại cùng một kết quả đáng tin cậy.

AI đảo ngược logic đó, ít nhất là ở một mức độ nào đó. Phần lớn giá trị của Linear Agent nằm ở việc thực hiện những công việc mà chúng ta không lường trước được theo những cách mà chúng ta chưa bao giờ định nghĩa rõ ràng; nếu lập trình hành vi của nó quá chặt chẽ, chúng ta sẽ làm loãng đi sự linh hoạt vốn làm nên tính hữu dụng của nó. Vì vậy, thay vì thiết kế một lộ trình cố định cho Linear Agent, chúng tôi xác định các ranh giới để nó có thể tự tìm ra lộ trình của riêng mình.

Chúng tôi đã vạch ra những ranh giới đó trong system prompt của agent, thiết kế các công cụ, mô hình Linear của agent, phạm vi của mỗi lần chạy và một bộ khung tùy chỉnh bên dưới.

System prompt

Chúng tôi tập trung prompt của Linear Agent vào một nhóm nhỏ các nguyên tắc cơ bản.

Phong cách giao tiếp

Agent cần giao tiếp rõ ràng và tự nhiên, không quá cứng nhắc kiểu công sở hay quá suồng sã. Nó cũng nên điều chỉnh tông giọng phù hợp với nền tảng mà nó đang hoạt động; ví dụ, nó có thể trò chuyện thoải mái hơn trên Slack so với trong một Loop.

Các ranh giới cứng

Agent không nên đưa ra ý kiến về các chủ đề nhạy cảm như chính trị, tôn giáo, các mối quan hệ cá nhân và những vấn đề tương tự. Nó cũng không nên thực hiện các hành động mở rộng đáng kể phạm vi yêu cầu của người dùng mà không yêu cầu xác nhận.

Giải thích các khái niệm đặc thù của Linear

Agent cần hiểu hệ thống phân loại của sản phẩm để diễn giải các yêu cầu của người dùng và thực hiện các hành động đúng đắn thay cho họ.

Các quan điểm mặc định về cách sử dụng một số tính năng nhất định

Các câu lệnh (prompt) của người dùng thường rất ngắn, vì vậy agent cần có khả năng nhạy bén trong việc xác định khi nào nên suy luận ý định thay vì đặt câu hỏi làm rõ.

Một system prompt cấp cao như thế này giúp định hướng cho agent, đồng thời vẫn để lại không gian cho các hành vi mang tính tự phát và nhận thức ngữ cảnh. Ví dụ, trên Slack, Linear Agent có thể nắm bắt được "vibe" của cuộc trò chuyện và góp vui bằng một câu đùa đúng lúc. Đồng thời, các ranh giới trong prompt đảm bảo rằng nó sẽ không tham gia nếu câu đùa đó liên quan đến một chủ đề nhạy cảm.

Thiết kế các công cụ của agent

Chúng tôi nhận thấy việc mã hóa các ràng buộc vào thiết kế công cụ của Linear Agent hiệu quả hơn là liệt kê chúng trong prompt. Chúng tôi định hình mỗi công cụ sao cho các tham số của nó dễ hiểu và khiến các hành động không hợp lệ trở nên bất khả thi. Nguyên tắc này tương tự như việc xây dựng các lớp trừu tượng mã nguồn tốt hoặc giao diện người dùng, nơi các hành vi trực quan không cần phải giải thích.

Điều này cũng tạo không gian để agent trở nên năng lực hơn khi các mô hình được cải thiện. Vì không gian hành động của nó không bị lập trình quá mức và các công cụ có thể được kết hợp linh hoạt, một mô hình thông minh hơn có thể điều phối chúng để giải quyết các tác vụ ngày càng phức tạp.

Mô hình Linear của agent

Việc cho phép agent tự ứng biến chỉ hiệu quả nếu nó hiểu được môi trường mà nó đang hoạt động. Đối với Linear Agent, điều đó có nghĩa là dạy cho nó cấu trúc và ngữ nghĩa của sản phẩm, một thách thức có hình thái rất khác so với việc xây dựng một coding agent.

Các coding agent có một tập hợp nhỏ các công cụ chuyên sâu, như read_file, write_file và run_command, và gần như mọi việc chúng làm đều là kết quả của cách chúng kết hợp các nguyên hàm này. Mã nguồn và lệnh shell cũng được thể hiện mạnh mẽ trong quá trình huấn luyện mô hình, vì vậy các agent này thường có bản năng tốt để sử dụng các công cụ đó ngay cả trong những tình huống lạ.

Linear Agent có hình thái ngược lại. Nó có một số lượng lớn các công cụ tương đối nông, mỗi công cụ gắn liền với một thao tác sản phẩm cụ thể như tạo issue hoặc sửa đổi tài liệu. Sử dụng chúng tốt cũng đòi hỏi sự hiểu biết về các khái niệm sản phẩm vốn không được thể hiện tốt trong kiến thức hiện có của mô hình (Linear có thể xuất hiện trong dữ liệu huấn luyện, nhưng chỉ ở mức không đáng kể so với mã nguồn và shell).

Kết quả là, để Linear Agent có thể làm việc với bất kỳ phần nào của sản phẩm, cần ba yếu tố:

Lấy Customer Requests làm ví dụ. Kỹ năng tương ứng cung cấp cho agent các công cụ để tạo, cập nhật và liệt kê các yêu cầu trên các issue, dự án và khách hàng. Nó giải thích rằng mỗi yêu cầu ghi lại phản hồi từ một khách hàng cụ thể, thường được liên kết với một issue hoặc dự án, và tóm tắt những gì đã được yêu cầu. Nó cũng mã hóa các phương pháp hay nhất để sử dụng tính năng này; ví dụ, nó sẽ hướng dẫn agent tổng hợp các mẫu hình trên các yêu cầu của khách hàng khi soạn thảo đặc tả dự án.

Phạm vi của mỗi lần chạy

Thách thức tiếp theo là cung cấp tất cả ngữ cảnh và công cụ này cho agent mà không làm nó bị quá tải. Vì hầu hết các yêu cầu của người dùng chỉ cần một phần nhỏ bề mặt sản phẩm của Linear, chúng tôi đã giới thiệu các "system skill" như một đơn vị cấu thành cho agent.

Mỗi system skill tập hợp một số siêu dữ liệu cơ bản, một đoạn của system prompt và một bộ công cụ. Cùng nhau, chúng đại diện cho một tập hợp các khả năng độc lập có thể được tiết lộ dần dần cho agent khi cần thiết. (Điều này tách biệt với các kỹ năng do người dùng tạo, vốn là những hướng dẫn có thể tái sử dụng được tạo trên nền tảng của agent, không phải là một phần của các system skill tích hợp được mô tả ở đây.)

Các system skill được tải ở chế độ nền, trước khi agent bắt đầu thực hiện tác vụ hoặc theo yêu cầu khi tác vụ diễn ra. Trước mỗi lần chạy, Linear Agent suy luận xem kỹ năng nào có khả năng liên quan từ prompt của người dùng và ngữ cảnh mà nó được gọi. Ví dụ, một agent được gọi từ kênh Slack hoặc trang Linear của một dự án, có khả năng sẽ được tải sẵn kỹ năng 'projects'.

Các tác vụ gián tiếp hơn có thể tiết lộ các yêu cầu bổ sung trong quá trình thực hiện. Nếu người dùng yêu cầu agent soạn thảo bản cập nhật cho một dự án, ban đầu chúng tôi có thể chỉ tải các kỹ năng 'projects' và 'project updates'. Khi bắt đầu công việc, agent có thể nhận ra rằng nó cần xem xét các issue và PR gần đây, sau đó tự tải các kỹ năng tương ứng.

Điều này giúp ngữ cảnh của mỗi luồng công việc luôn tập trung, đồng thời cho phép Linear Agent hỗ trợ một loạt các khả năng rộng lớn. Nó cũng cho phép chúng tôi mở rộng khả năng của agent theo thời gian mà không làm gánh nặng cho mọi tương tác bằng một prompt và bộ công cụ ngày càng phình to.

Trong quá trình xây dựng, chúng tôi đã cân nhắc việc cho agent quyền truy cập trực tiếp vào Linear SDK và môi trường lập trình, CLI hoặc GraphQL API. Việc phơi bày các nguyên hàm cấp thấp này có thể cho phép các hành vi tinh vi hơn, nhưng nó cũng làm tăng bề mặt rủi ro cho các sai sót.

Mô hình dữ liệu cơ bản hỗ trợ một loạt các hành động, và một số khái niệm UI đòi hỏi sự diễn giải trước khi chúng có thể được ánh xạ vào mô hình đó. Một chế độ lỗi tiềm ẩn sẽ là các yêu cầu dài hạn (long-tail), nơi mà nếu không có lộ trình hoàn thành rõ ràng, agent có thể cố gắng giải quyết tác vụ thông qua các hành động mang tính suy đoán ngày càng nhiều.

Khi đưa ra quyết định này, chúng tôi đánh đổi một phần phạm vi để lấy tính dự đoán được. Agent đôi khi có thể từ chối các tác vụ mà nó không thể hoàn thành một cách an toàn, nhưng khả năng gây ra sai sót của nó bị hạn chế hơn nhiều.

Bộ khung tùy chỉnh bên dưới

Về cơ bản, Linear Agent chạy trên một stack tùy chỉnh mà chúng tôi sở hữu từ các API của nhà cung cấp mô hình trở lên. Nó bao gồm:

Chúng tôi chọn một stack tùy chỉnh vì các thư viện khung (harness libraries) thường có những quan điểm cứng nhắc về luồng thực thi của agent được tích hợp sẵn. Về cốt lõi, điều này liên quan đến việc cung cấp prompt và một bộ công cụ ngay từ đầu, gọi 'run', sau đó chờ đợi trong khi agent thực hiện các lệnh gọi công cụ và tạo ra phản hồi cuối cùng. Mặc dù điều đó hoạt động tốt cho các tương tác đơn giản, chúng tôi muốn kiểm soát chặt chẽ hơn việc thực thi của Linear Agent để hỗ trợ một số hành vi điều phối nhất định xảy ra khi quá trình chạy vẫn đang diễn ra.

Chèn công cụ động thông qua các kỹ năng

Khi agent tải một kỹ năng, nó cần có quyền truy cập vào các công cụ của kỹ năng đó ngay sau khi lệnh gọi công cụ được giải quyết để nó có thể gọi các công cụ mới trước khi phản hồi cho người dùng. Chúng tôi cũng muốn thực hiện điều này theo cách bảo toàn bộ nhớ đệm tiền tố (prefix cache) của nhà cung cấp, điều mà nếu triển khai theo cách thông thường sẽ không đạt được, vì việc xử lý lại ngữ cảnh hiện có có thể làm tăng chi phí.

Phê duyệt lệnh gọi công cụ có điều kiện

Khi một hành động mang tính rủi ro hoặc khó hoàn tác, agent nên tạm dừng giữa chừng và yêu cầu người dùng xác nhận trước khi tiếp tục. Hầu hết các thư viện khung hỗ trợ điều này thông qua các quy tắc thô để quyết định xem có cần phê duyệt hay không chỉ dựa trên tên công cụ và tham số của nó, trong khi chúng tôi muốn logic phê duyệt này mang tính ngữ cảnh hơn. Ví dụ, agent có thể xóa thứ gì đó mà nó đã tạo trong cuộc trò chuyện hiện tại mà không cần hỏi, nhưng vẫn yêu cầu xác nhận trước khi xóa một issue hiện có. Tương tự, nó có thể đăng lên hầu hết các luồng bình luận mà không cần phê duyệt, nhưng nên tạm dừng trước khi đăng lên luồng được đồng bộ hóa với một kho lưu trữ công khai.