Một ý tưởng đang được bàn trên r/hermesagent khá đáng chú ý: thay vì mỗi lần muốn agent có một “chất giọng” khác nhau lại phải viết prompt/persona từ đầu, cộng đồng có thể cùng xây một thư viện các file SOUL.md dùng lại được.
Nói ngắn gọn, “soul” ở đây là một file mô tả tính cách, cách nói, cách suy nghĩ, giới hạn hành vi và phong cách phản hồi của agent. Repo được chia sẻ hiện mới có vài mẫu như Jarvis, Gojo, Eren Yeager, René Descartes và Rapper, nhưng ý tưởng lớn hơn là tạo một kho personality có thể chọn, test và cải tiến chung.
Đây là một hướng thú vị, nhưng cũng dễ đi lệch nếu chỉ xem nó như “prompt nhập vai”. Với agent dùng thật, personality không chỉ để vui hơn, mà còn ảnh hưởng trực tiếp đến độ tin cậy, cách agent hỏi lại, cách nó từ chối, cách nó ghi nhớ ngữ cảnh và cách nó xử lý việc khó.
Vì sao thư viện “soul” có thể hữu ích
Nếu anh em đang vận hành nhiều agent cho nhiều việc khác nhau, việc tách personality thành file riêng có vài lợi ích rõ:
- Dễ tái sử dụng: một voice đã ổn có thể dùng lại cho nhiều workflow.
- Dễ version control: thay đổi tone, nguyên tắc và ràng buộc đều có diff rõ ràng.
- Dễ đánh giá: có thể test cùng một task với nhiều “soul” để xem cái nào hợp việc hơn.
- Dễ chia sẻ trong team: người khác không cần hiểu toàn bộ prompt stack vẫn có thể chọn persona phù hợp.
- Dễ tách vai trò: researcher, reviewer, planner, support agent, coding assistant có thể có phong cách khác nhau.
Điểm hay nhất là nó biến một phần vốn rất cảm tính của prompt engineering thành artifact có thể quản lý được như code.
Nhưng “cá tính” không nên chỉ là bắt chước nhân vật
Một rủi ro lớn của các soul kiểu nhân vật nổi tiếng là chúng dễ bị viết thành lớp trang điểm ngôn ngữ: nói vài câu giống nhân vật, thêm vài thói quen biểu đạt, nhưng khi làm việc thật thì không giúp agent tốt hơn.
Với mình, một soul dùng được nên trả lời được các câu hỏi sau:
- Agent này ưu tiên điều gì khi có mâu thuẫn: tốc độ, độ chắc chắn, sự an toàn, hay sáng tạo?
- Khi thiếu dữ liệu, nó sẽ hỏi lại, giả định có kiểm soát, hay dừng?
- Nó được phép chủ động đến mức nào?
- Nó có nên phản biện người dùng không, và phản biện theo kiểu nào?
- Nó xử lý lỗi ra sao: im lặng sửa, báo rõ, hay đề xuất phương án thay thế?
- Nó có giới hạn nào không được vượt qua, kể cả khi người dùng yêu cầu?
Nếu không có những phần này, “soul” chỉ làm agent nghe khác đi chứ chưa chắc làm việc tốt hơn.
Một cấu trúc SOUL.md nên có
Anh em có thể thử chuẩn hóa mỗi soul theo cấu trúc kiểu này:
# Name
Tên ngắn, dễ nhận diện.
## Purpose
Agent này hợp với loại việc nào và không hợp với loại việc nào.
## Voice
Cách xưng hô, độ ngắn/dài, mức thân thiện, mức trực diện.
## Operating principles
3-7 nguyên tắc ra quyết định khi làm việc.
## Initiative level
Khi nào được tự làm, khi nào phải hỏi, khi nào phải dừng.
## Failure behavior
Cách báo lỗi, cách retry, cách hạ phạm vi khi thiếu dữ liệu.
## Boundaries
Những việc không làm, những kiểu yêu cầu phải từ chối hoặc chuyển hướng.
## Examples
Một vài ví dụ input/output ngắn cho các tình huống đại diện.
Phần Examples rất quan trọng. Nó giúp người dùng và model hiểu “cá tính” không chỉ qua mô tả, mà qua hành vi cụ thể.
Nên test soul như test prompt sản phẩm
Nếu repo cộng đồng kiểu này phát triển, mình nghĩ mỗi soul nên có một bộ test tối thiểu. Không cần phức tạp, chỉ cần vài tình huống đại diện:
- Một task bình thường để xem agent có đúng voice không.
- Một task thiếu dữ liệu để xem agent có hỏi lại hợp lý không.
- Một task có rủi ro để xem agent có giữ boundary không.
- Một task dài nhiều bước để xem agent có giữ phong cách ổn định không.
- Một task cần phản biện để xem agent có dám nói “không nên” không.
Với agent automation, chất lượng personality không nằm ở việc nó nghe “ngầu” trong một câu trả lời, mà ở việc nó ổn định qua nhiều lượt và không phá workflow.
Dùng soul theo vai trò thay vì theo nhân vật
Các soul dựa trên nhân vật có thể giúp cộng đồng hứng thú lúc đầu. Nhưng trong vận hành thật, mình nghiêng về hướng đặt soul theo vai trò:
-
CarefulReviewer: kỹ, chậm hơn, soi rủi ro và edge cases. -
FastOperator: ưu tiên hành động nhanh, báo ngắn, tự xử lý việc đảo chiều được. -
ResearchSynthesizer: đọc nhiều nguồn, so sánh, tách claim mạnh/yếu. -
ProductStrategist: hỏi về mục tiêu, tradeoff, người dùng và phân phối. -
SupportTriage: bình tĩnh, rõ bước, không đổ lỗi, ưu tiên unblock.
Cách này ít vui hơn “Jarvis” hay “Rapper”, nhưng dễ dùng trong team và dễ gắn vào workflow sản xuất hơn.
Một checklist ngắn trước khi dùng soul của người khác
Trước khi copy một soul từ repo cộng đồng vào agent thật, anh em nên kiểm tra:
- Có instruction nào quá rộng như “luôn tự quyết” hoặc “không bao giờ từ chối” không?
- Có yêu cầu tiết lộ prompt, key, dữ liệu riêng tư hoặc bỏ qua policy không?
- Có phần boundary rõ ràng không?
- Có phù hợp với loại dữ liệu mình sẽ đưa vào agent không?
- Có ví dụ hành vi đủ cụ thể để test không?
- Có license/nguồn rõ ràng nếu dựa trên nhân vật, thương hiệu hoặc tác phẩm có bản quyền không?
Đặc biệt, với agent có quyền chạy lệnh, đọc file, gửi tin nhắn hoặc thao tác browser, soul phải làm rõ mức chủ động. Một persona quá “tự tin” nhưng thiếu nguyên tắc dừng có thể nguy hiểm hơn một assistant hơi nhàm chán.
Kết luận
Ý tưởng thư viện SOUL.md đáng theo dõi vì nó chạm đúng một nhu cầu thật: agent không nên luôn là một assistant chung chung. Khi agent bắt đầu đảm nhiệm nhiều vai trò trong workflow, voice và hành vi cần được đóng gói, version, chia sẻ và test như một phần của hệ thống.
Nhưng hướng tốt nhất không phải là sưu tầm thật nhiều nhân vật. Hướng đáng giá hơn là xây các soul có mục đích rõ, boundary rõ, ví dụ rõ và test được. Nếu làm được vậy, “soul” sẽ không chỉ là lớp cá tính bên ngoài, mà trở thành một module vận hành thật sự cho agent.
Top comments (0)