Quản lý các thành phần cơ bản của tác nhân AI như những gói phần mềm thực sự bằng APM và JFrog

Các tác nhân AI đã trở thành một phần của quy trình phát triển hiện đại.

Chúng viết mã, xem xét pull request, tạo test, gọi công cụ, tương tác với các máy chủ MCP và giúp các nhà phát triển làm việc nhanh hơn. Nhưng đứng sau mỗi tác nhân hữu ích luôn có một thứ quan trọng không kém mô hình: ngữ cảnh xác định cách thức tác nhân hoạt động.

Ngữ cảnh đó có thể bao gồm kỹ năng (skills), prompt, hướng dẫn, hook, lệnh, script, tài liệu tham khảo và định nghĩa máy chủ MCP.

Trong một dự án nhỏ, quản lý những nguyên tố này khá đơn giản. Có thể bạn là nhà phát triển duy nhất làm việc trên repository. Những gì bạn thấy trên máy cục bộ là tất cả. Bạn biết prompt nào đang được dùng, hướng dẫn nào được thêm, và công cụ nào được kết nối.

Nhưng khi điều này trở thành nỗ lực theo đội, nhiều câu hỏi xuất hiện:

• Làm sao đảm bảo mọi nhà phát triển đều sử dụng cùng một hướng dẫn tác nhân?
• Làm sao biết mọi người đã có phiên bản mới nhất của một kỹ năng dùng chung?
• Làm sao ngăn chặn việc ai đó âm thầm sửa đổi một prompt, hook hay skill?
• Làm sao kiểm soát ai được phép xuất bản, cập nhật hoặc sử dụng những nguyên tố tác nhân này?
• Làm sao áp dụng quản trị, kiểm soát truy cập và quy trình phê duyệt trước khi những nguyên tố này đến tay các nhà phát triển và công cụ lập trình AI?

Và quan trọng nhất: Làm sao đảm bảo những nguyên tố tác nhân này đến từ nguồn đáng tin cậy?

Chính ở đây APM, Agent Package Manager phát huy vai trò.

APM là gì?

APM là một trình quản lý gói mã nguồn mở dành cho các nguyên tố tác nhân. Nó mang mô hình quản lý gói quen thuộc vào thế giới tác nhân AI, cho phép các đội định nghĩa skills, prompt, hướng dẫn, hook, lệnh và cấu hình máy chủ MCP như các phụ thuộc có phiên bản trong một file duy nhất apm.yml.

Khi được khai báo, mọi nhà phát triển có thể chạy apm install và nhận được cùng một ngữ cảnh tác nhân trên các công cụ như Cursor, Claude Code, GitHub Copilot, Codex, OpenCode, Gemini và Windsurf.

Xem ngữ cảnh tác nhân như một gói

Dự án APM có một tiền đề cốt lõi đơn giản nhưng mạnh mẽ: coi các nguyên tố tác nhân như các gói. Nếu bạn quen với trình quản lý gói như npm, khái niệm này sẽ rất tự nhiên. Thay vì sao chép thủ công prompt, hướng dẫn, skill và định nghĩa máy chủ MCP giữa các dự án, bạn khai báo chúng như các phụ thuộc.

Một dự án có thể mô tả ngữ cảnh tác nhân nó cần trong một file apm.yml duy nhất. Sau đó, mọi nhà phát triển có thể chạy:

 
apm install 

Và nhận được cùng một cấu hình tác nhân.

Cấu hình đó có thể bao gồm:

 

name: my-org-ai-project
version: 1.0.0
description: Shared AI agent setup for the packages team
author: platform-engineering

targets:
  - cursor
  - claude
  - copilot

dependencies:
  apm:
    - jfrog/packages-skills#^1.1.0
    - jfrog/pr-standards-instructions#^2.0.0
    - jfrog/build-test-instructions#^1.3.0
  mcp:
    - name: slack
      registry: false
      transport: http
      url: https://mcp.slack.com/mcp
      oauth:
        clientId: ""
        callbackPort: 3118

    - name: linear
      registry: false
      transport: http
      url: https://mcp.linear.app/sse
      headers:
        Authorization: "Bearer ${LINEAR_TOKEN}"


includes: auto
scripts: {}

Trong ví dụ này, dự án không bắt đầu với một cấu hình tác nhân trống. Nó khai báo các nguyên tố dùng chung mà đội muốn mọi nhà phát triển sử dụng:

jfrog/packages-skills chứa các kỹ năng tái sử dụng cho các workflow liên quan đến package.
jfrog/pr-standards-instructions định nghĩa cách tác nhân hỗ trợ thông điệp pull request và tiêu chuẩn review.
jfrog/build-test-instructions cung cấp hành vi build và test mà đội mong đợi.
jfrog/artifactory-mcp khai báo cấu hình MCP server đã được phê duyệt để tác nhân sử dụng khi tương tác với Artifactory.

Thay vì sao chép thủ công các file giữa các dự án, đội chỉ khai báo một lần trong apm.yml. Khi một nhà phát triển chạy apm install, APM lấy các phiên bản đã được phê duyệt từ JFrog và đặt chúng vào đúng nơi để các công cụ lập trình AI tiêu thụ.

Phục dựng cùng một ngữ cảnh tác nhân ở mọi nơi

Khi một nhà phát triển chạy:

 
apm install

 

APM đọc apm.yml của dự án, giải quyết các phụ thuộc nguyên tố tác nhân đã khai báo, tải các gói cần thiết và ghi các tài sản liên quan vào dự án theo cấu trúc mà các công cụ lập trình AI đã chọn có thể tiêu thụ.

Điều đó có nghĩa là skills, prompt, hướng dẫn, hook, command, script và khai báo MCP không bị sao chép thủ công từ repo này sang repo khác hoặc từ wiki. Chúng được cài đặt như các phụ thuộc có phiên bản.

Điều này quan trọng vì cấu hình tác nhân trở nên có thể tái tạo.

Lần cài đầu tiên sẽ giải quyết chính xác các phiên bản gói và nội dung của chúng. Những phiên bản đã được giải quyết, cùng với hash nội dung, sẽ được ghi lại trong một file lock. Bằng cách commit file lock đó vào dự án, mọi nhà phát triển chạy apm install sẽ nhận được cùng một ngữ cảnh tác nhân đã được giải quyết.

Không phải “gần giống cùng một hướng dẫn.”
Không phải “bất cứ thứ gì mới nhất khi họ sao chép file.”
Cùng một phiên bản. Cùng một nội dung. Cùng một cấu hình tác nhân.

Vì vậy khi một nhà phát triển mới gia nhập dự án, chuyển máy hoặc clone một repo mới, họ có thể tái tạo cùng môi trường tác nhân mà đội đang dùng. Và khi đội quyết định cập nhật một skill hay hướng dẫn dùng chung, việc cập nhật này diễn ra có chủ ý thông qua workflow phụ thuộc và file lock thay vì sao chép-dán.

Một file apm.yml.
Một file lock chung.
Một ngữ cảnh tác nhân nhất quán trên mọi máy của nhà phát triển.

APM có thể quản lý những gì?

APM có thể quản lý nhiều loại phụ thuộc tác nhân khác nhau, bao gồm skills, prompt, hướng dẫn, agents, hook, command và máy chủ MCP. Nó không giới hạn ở một kiểu file hay cấu hình. Tài liệu nguồn bao gồm một bảng phân loại các loại nguyên tố và giải thích cách mỗi loại phù hợp vào workflow tác nhân.

Primitive	What it represents
Skills	Self-contained capability bundles with SKILL.md, scripts, and assets
Prompts	Reusable prompt templates with frontmatter
Instructions	Long-lived behavior rules, such as style guides and project conventions
Agents	Personas with explicit scope, tools, and triggers
Hooks	Event handlers fired by the runtime, such as pre-commit or on-tool-use
Commands	Slash-command shortcuts developers type into the agent UI
MCP servers	Tool-server declarations that consumers can wire into their agent harness

 

Đây là lúc APM vượt xa tiện ích đơn thuần. Nó tạo ra một cách có cấu trúc để chia sẻ, phiên bản hóa và tái tạo các nguyên tố định hình hành vi tác nhân.

Khi một thứ gì đó trở thành phần của workflow phần mềm, nó cũng cần được quản trị.

Thiếu mảnh ghép: Một registry đáng tin cậy

Quản lý nguyên tố tác nhân trên máy cục bộ là hữu ích, nhưng chỉ quản lý cục bộ thì chưa đủ. Ngay cả khi các đội lưu skills, prompt, hướng dẫn, hook và cấu hình MCP trong các repo Git nội bộ, họ vẫn phải xử lý checkout, cập nhật, trôi phiên bản và quản lý phụ thuộc giữa nhiều repo.

Điều đó có thể hoạt động với đội nhỏ, nhưng nhanh chóng trở nên khó khăn ở quy mô lớn. Mỗi dự án giờ phải biết nên kéo từ repo nào, dùng phiên bản nào, khi nào cập nhật, và làm sao đảm bảo các file đúng có sẵn ở đúng nơi để tác nhân tiêu thụ.

Và có một vấn đề thực tế khác: các repo Git có thể không luôn truy cập được đối với các tác nhân chạy gần môi trường production hơn, bên trong môi trường kiểm soát hoặc trong các mạng bị giới hạn. Trong những trường hợp đó, dựa vào Git như cơ chế phân phối runtime cho nguyên tố tác nhân trở nên mong manh.

Doanh nghiệp cần một cách đáng tin cậy để xuất bản, tiêu thụ, kiểm soát và kiểm toán các gói này thông qua mô hình registry đúng chuẩn. Nếu không có điều đó, các nhà phát triển có thể sẽ kéo hướng dẫn tác nhân, skills, script hoặc cấu hình MCP từ nhiều nơi rải rác, bản sao lỗi thời, hoặc nguồn không đáng tin — tạo ra một vấn đề mới trong chuỗi cung ứng phần mềm.

Một skill tác nhân không chỉ là “một prompt.”
Một hook không chỉ là “một script hỗ trợ.”
Một định nghĩa máy chủ MCP không chỉ là “cấu hình.”

Những nguyên tố này quyết định những gì tác nhân nhìn thấy, những gì nó được phép làm, và công cụ nào nó có thể gọi — về cơ bản ảnh hưởng tới chất lượng, an toàn và sự nhất quán của kết quả mà tác nhân tạo ra.

Điều đó có nghĩa chúng nên được quản lý với cùng kỷ luật như các gói phần mềm chúng ta đã áp dụng.

JFrog hỗ trợ cho các gói APM

JFrog hiện cho phép sử dụng APM cùng nền tảng JFrog thông qua một loại repository mới là Agent Packages.

Điều này có nghĩa tổ chức có thể xuất bản và tiêu thụ gói APM trực tiếp qua JFrog Artifactory, thay vì phụ thuộc vào các nguồn rời rạc hoặc không đáng tin cậy.

Với tích hợp APM–JFrog, các đội có thể:

• Xuất bản gói APM lên registry nội bộ đáng tin cậy của Artifactory
• Tiêu thụ gói APM từ registry nội bộ này
• Chia sẻ nguyên tố tác nhân đã được phê duyệt giữa các đội
• Giữ hành vi tác nhân nhất quán giữa các dự án và máy
• Quản lý ngữ cảnh tác nhân AI bằng cùng nền tảng họ đã tin tưởng để quản lý gói phần mềm

JFrog cho gói APM hoạt động như thế nào?

Từ phía JFrog, luồng hoạt động bắt đầu bằng việc tạo một repository mới loại Agent Packages.

Sau đó, APM cần được cấu hình để làm việc với registry đó bằng cách chạy các lệnh sau:

 
apm experimental enable registries

apm config set registry.agent-packages.url \
https://.jfrog.io/artifactory/api/agentpackages/

apm config set registry.agent-packages.token 

apm config set registry.agent-packages.default true

Chỉ đơn giản vậy thôi! Kể từ thời điểm này, các nhà phát triển có thể dùng APM để đẩy và kéo gói tác nhân đến/từ JFrog.

Một ví dụ đơn giản

Giả sử một tổ chức có ba gói APM:

 
jfrog/artifactory-instructions
jfrog/jfrog-instructions
jfrog/packages-skills

 

Cả ba gói đã được lưu trong Artifactory.

Bây giờ một nhà phát triển có thể tạo dự án với file apm.yml phụ thuộc vào:

dependencies:
 apm:
   - jfrog/packages-skills#^1.1.0
 mcp: ()
includes: auto
scripts: {}

Trong ví dụ này, dự án khai báo phụ thuộc vào jfrog/packages-skills#^1.1.0.

Gói này không chỉ là một skill độc lập. Nó cũng phụ thuộc vào jfrog/artifactory-instructions, và gói đó tiếp tục phụ thuộc vào jfrog/jfrog-instructions.

Sơ đồ chuỗi phụ thuộc trông như sau:

jfrog/packages-skills → jfrog/artifactory-instructions → jfrog/jfrog-instructions

Nói cách khác, dự án chỉ khai báo jfrog/packages-skills#^1.1.0 làm phụ thuộc cấp trên, nhưng gói đó phụ thuộc tiếp đến jfrog/artifactory-instructions, rồi đến jfrog/jfrog-instructions.

Khi nhà phát triển chạy apm install, APM giải quyết chuỗi phụ thuộc này một cách truyền, tải tất cả các gói cần thiết từ JFrog và bố trí các file đúng chỗ trong dự án để tác nhân tiêu thụ.

Sau đó họ chạy:

apm install

APM tải các gói cần thiết từ JFrog, giải quyết phụ thuộc theo chuỗi, và mang các file phù hợp vào dự án, đặt chúng ở nơi các công cụ lập trình AI đã chọn có thể sử dụng.

Không sao chép-dán.
Không đoán “bạn đang dùng phiên bản nào?”
Không tải nguyên tố tác nhân ngẫu nhiên từ nguồn không rõ.

Mọi nhà phát triển trong đội giờ có thể làm việc với cùng nguyên tố tác nhân được phê duyệt và cùng phiên bản. Dù bạn có hai hay hai nghìn nhà phát triển, kết quả vẫn như nhau: mọi người được đồng bộ.

Giữ nguyên tố tác nhân được cập nhật

Khi nguyên tố tác nhân được quản lý như các gói, việc cập nhật cũng trở nên quen thuộc.

Để lấy phiên bản đã được phê duyệt mới nhất, nhà phát triển có thể chạy:

apm update

APM sẽ tải những nguyên tố mới nhất theo hành vi phiên bản đã được định nghĩa trong cấu hình dự án.

Điều này mang lại cho các đội một workflow rõ ràng để triển khai hướng dẫn tốt hơn, cập nhật kỹ năng, lệnh mới hoặc khai báo MCP được cải thiện mà không cần phân phối thủ công.

Từ cài đặt đến runtime: nơi các tác nhân được phép chạy

Cài đặt cùng nguyên tố được phê duyệt mọi nơi là lợi ích đầu tiên. Khi một nhà phát triển chạy apm install, các gói đó chảy vào mọi tác nhân họ đang dùng, GitHub Copilot trong VS Code hoặc bất kỳ harness nào APM hỗ trợ. Cùng một nguồn tin cậy, cho mọi công cụ, trên mọi máy.

Nhưng tác nhân không chỉ nằm trong IDE. Chúng đang tiến vào CI/CD và runtime từ xa như GitHub Agentic Workflows, thực hiện thao tác trên repository một cách tự động. Điều này đặt ra câu hỏi thứ hai: Khi một gói được phê duyệt thực sự chạy, làm thế nào để sandbox, kiểm duyệt và đặt ngân sách cho nó?

Bởi vì gói APM có thể di động, gói chính xác nằm trong Artifactory có thể chạy, không thay đổi, như một tác nhân tự động với GitHub Agentic Workflows, chạy tác nhân AI như GitHub Actions trong CI/CD. GitHub Agentic Workflows coi các gói APM là phụ thuộc hạng nhất. Bạn import một thành phần chia sẻ, liệt kê các gói được phê duyệt đã ghim phiên bản, và workflow cài chúng vào runner được sandbox. Quản trị có thể được áp dụng nữa.

Dưới đây là ví dụ về một hàng rào phê duyệt của con người trước khi tác nhân chạy, và một giới hạn ngân sách cho mức tiêu AI trên mỗi lần chạy. Trong ví dụ này automation import một gói APM đã được phê duyệt tên acme/modernization-kit#v2.3. Gói này có thể chứa skills, hướng dẫn, prompt, hook, lệnh hoặc khai báo MCP cần cho workflow cụ thể — một sáng kiến hiện đại hóa trong trường hợp này.

on:
  issues: { types: (labeled), names: (modernize) }
  manual-approval: modernization-initiative         # human gate
imports:
  - uses: shared/apm.md
    with:
      packages: ( acme/modernization-kit#v2.3 )     # approved, pinned package
engine: { model: sonnet }
max-ai-credits: 500                                 # spend cap per run

Phần quan trọng là acme/modernization-kit#v2.3 không phải là một script lỏng lẻo hay prompt sao chép. Đó là một gói APM đã được ghim phiên bản có thể được phê duyệt, phiên bản hóa, lưu trong Artifactory và tái sử dụng qua các luồng automation có quản trị.

Vì vậy khi tác nhân chạy, nó không kéo các hướng dẫn tùy ý từ thiết lập cục bộ của một nhà phát triển. Nó sử dụng một phiên bản gói đã được phê duyệt, với một vòng phê duyệt bởi con người trước khi thực thi và một giới hạn ngân sách giới hạn chi tiêu AI cho mỗi lần chạy.

Skills, agents, instructions, hooks và khai báo MCP đều được xử lý như các gói. Một khi được đóng gói theo cách này, chúng có thể đi qua cùng loại kiểm soát mà các đội đã tin tưởng để phát hành phần mềm: phê duyệt, phiên bản hóa, lưu trữ trong Artifactory, tiêu thụ có kiểm soát và thực thi có thể lặp lại.

Đó là ý tưởng lớn hơn: các nguyên tố tác nhân không chỉ được cài vào công cụ lập trình. Chúng còn có thể trở thành khối xây dựng có quản trị cho automation. Được phê duyệt khi nghỉ trong Artifactory. Ghim bằng phiên bản. Kiểm duyệt trước runtime. Chạy trong sandbox, được đo lường chi phí và có thể truy vết khi thực thi.

Tại sao điều này quan trọng ngay bây giờ, và bước tiếp theo

Các tác nhân AI đã là những thành phần hoạt động trong vòng đời phát triển phần mềm. Nhưng ngành đang học cách quản trị lớp phụ thuộc mới mà chúng dựa vào: prompt, skills, instructions, hooks, commands và máy chủ MCP. Chúng không phải là gói truyền thống, nhưng lại hành xử như phụ thuộc: được tạo, chia sẻ, phiên bản hóa, tiêu thụ và cập nhật giữa các dự án. Chúng định hình workflow của nhà phát triển, mang rủi ro và cần được quản lý phù hợp.

APM mang đến cho nhà phát triển trải nghiệm như trình quản lý gói cho các nguyên tố tác nhân. JFrog cung cấp cho tổ chức một registry đáng tin cậy, khả năng quản trị và kiểm soát cấp doanh nghiệp cần thiết để sử dụng mô hình đó một cách an toàn ở quy mô. Kết hợp lại, chúng cho phép quản lý ngữ cảnh tác nhân AI theo cách các đội phần mềm hiện đại đã quản lý gói phần mềm.

Bước tiếp theo

Quản lý nguyên tố tác nhân như các gói là bước đầu tiên. Bước tiếp theo là bảo đảm chúng. JFrog đang phát triển một lớp bảo mật phân tích gói APM khi chúng được đẩy vào Artifactory. Lớp này sẽ kiểm tra skills, prompt, hướng dẫn, hook, lệnh và khai báo MCP để phát hiện chỉ dẫn độc hại, thao tác ẩn, hành vi không an toàn và các mẫu cấu hình rủi ro. Điều này cho phép các đội kiểm soát nguyên tố tác nhân như bất kỳ thành phần chuỗi cung ứng phần mềm nào khác: xuất bản vào registry đáng tin cậy, kiểm tra trước khi sử dụng, và chỉ tiêu thụ sau khi vượt qua các kiểm soát an ninh của tổ chức.

Mục tiêu cuối cùng là: khi các nhà phát triển và tác nhân kéo nguyên tố tác nhân từ Artifactory, họ có thể tin tưởng rằng các gói này không chỉ được quản lý mà còn được xác minh và an toàn để sử dụng.

Sẵn sàng triển khai?

Hãy bảo đảm chuỗi cung ứng tác nhân AI của bạn ngay hôm nay. Làm theo hướng dẫn triển khai đầy đủ trong tài liệu JFrog APM để tìm hiểu cách xuất bản, tiêu thụ và quản trị nguyên tố tác nhân với Artifactory.

Liên hệ với Softribution để được tư vấn và triển khai giải pháp

Nếu bạn cần tư vấn chuyên sâu, thiết kế luồng quản trị hoặc muốn mua giải pháp tích hợp APM với JFrog Artifactory và các công cụ tác nhân AI của đội, hãy liên hệ Softribution để được hỗ trợ — từ đánh giá hiện trạng, thiết lập registry tin cậy, đến xây dựng quy trình phê duyệt và kiểm tra an ninh. Đội ngũ tư vấn của Softribution sẽ giúp bạn triển khai an toàn và hiệu quả, phù hợp với yêu cầu doanh nghiệp.