Giới thiệu

Trong tháng 12 năm 2024, khi thiết kế hệ thống xác thực giữa các đại lý của ConnectOnion, chúng tôi đã đối mặt với một quyết định quan trọng: chúng tôi nên gọi tham số điều khiển cách các đại lý xác thực lẫn nhau là gì? Sau khi xem xét hơn 15 lựa chọn và thảo luận rộng rãi, chúng tôi đã quyết định chọn từ "sự tin cậy". Hãy cùng tìm hiểu lý do.

Thách Thức: Tìm Một Từ Hai Chiều

Hệ thống xác thực của chúng tôi cần một từ khóa hoạt động theo hai hướng:

1. Dưới góc độ nhà cung cấp dịch vụ: "Ai có thể sử dụng dịch vụ của tôi?"
2. Dưới góc độ người tiêu dùng dịch vụ: "Tôi tin tưởng dịch vụ nào?"

Hầu hết các thuật ngữ bảo mật chỉ hoạt động theo một hướng. Chúng tôi cần một từ mà tự nhiên chảy cả hai chiều.

Các Lựa Chọn Chúng Tôi Đã Xem Xét

1. auth / authentication

Tại sao không: Quá kỹ thuật và ngụ ý xác thực truyền thống (mật khẩu, mã thông báo). Chúng tôi đang thực hiện xác thực hành vi, không phải kiểm tra thông tin đăng nhập.

2. verify / validate

Tại sao không: Một chiều - bạn xác thực người khác, nhưng nói "Tôi đã được xác thực" nghe giống như một hệ thống thông tin đăng nhập.

3. guard / guardian

Tại sao không: Ngụ ý chỉ chặn/protect. Không nắm bắt được mối quan hệ tương hỗ giữa các đại lý.

4. policy / rules

Tại sao không: Quá chính thức và nặng nề về cấu hình. Không phù hợp với cách tiếp cận ngôn ngữ tự nhiên của chúng tôi.

5. security / safe

Tại sao không: Quá rộng và tạo ra sự sợ hãi. Bảo mật ngụ ý mối đe dọa; chúng tôi muốn hợp tác.

6. filter / allow

Tại sao không: Một chiều và tiêu cực. Tập trung vào việc loại trừ thay vì xây dựng mối quan hệ.

7. mode / env

Tại sao không: Quá chung chung. Có thể có nghĩa bất kỳ điều gì - không chỉ rõ mục đích xác thực.

8. strict / open / tested

Tại sao không: Những từ này trở thành các mức độ tin cậy, nhưng tham số cần một tên rõ ràng hơn.

9. require / expect

Tại sao không: Hoạt động cho các yêu cầu đến nhưng lạ lẫm cho các yêu cầu đi ("Tôi yêu cầu người khác" so với "Tôi được yêu cầu"?).

10. proof / evidence

Tại sao không: Nghe giống như bằng chứng blockchain/cryptographic. Chúng tôi không làm điều đó.

11. access / permission

Tại sao không: Thuật ngữ kiểm soát truy cập truyền thống. Không phản ánh cách tiếp cận hành vi của chúng tôi.

12. handshake / protocol

Tại sao không: Quá kỹ thuật/mạng. Người dùng không nên cần phải nghĩ về các giao thức.

13. partner / peer

Tại sao không: Ngụ ý sự bình đẳng. Đôi khi các đại lý có mối quan hệ không đối xứng.

14. contract / agreement

Tại sao không: Quá chính thức/pháp lý. Tạo ra rào cản gia nhập.

15. friend / buddy

Tại sao không: Quá thân mật. Không truyền đạt tính nghiêm trọng của xác thực.

Tại Sao "Sự Tin Cậy" Thắng

"Sự tin cậy" thành công ở những nơi khác thất bại vì:

1. Tự Nhiên Hai Chiều

• "Tôi tin tưởng bạn" (đi ra)
• "Bạn tin tưởng tôi" (đến)
• "Chúng ta tin tưởng nhau" (tương hỗ)

Từ này tự nhiên chảy theo mọi hướng mà không cần diễn đạt lúng túng.

2. Thân Thiện Với Con Người

Ai cũng hiểu sự tin cậy. Nó không phải là thuật ngữ kỹ thuật. Bà của bạn biết tin cậy có nghĩa là gì.

3. Tiến Bộ, Không Nhị Phân

Sự tin cậy có các mức độ:

• trust="open" - Tin tưởng tất cả (phát triển)
• trust="tested" - Tin tưởng các đại lý đã được xác thực (staging)
• trust="strict" - Tin tưởng các đại lý trong danh sách cho phép (sản xuất)

Điều này phản ánh cách mà sự tin cậy của con người hoạt động - nó được xây dựng và có mức độ.

4. Phù Hợp Với Triết Lý Của Chúng Tôi

Chúng tôi không thực hiện xác thực mật mã. Chúng tôi thực hiện xác thực hành vi. Sự tin cậy được xây dựng qua các tương tác thành công, không phải chứng chỉ.

5. Cấu Hình Rõ Ràng

# Dễ hiểu ngay lập tức
agent = Agent(name="helper", trust="open")

# So với các lựa chọn khác:
agent = Agent(name="helper", auth="permissive")  # Thế nào là xác thực cho phép?
agent = Agent(name="helper", verify="none")      # Xác thực không? Gây nhầm lẫn.
agent = Agent(name="helper", mode="dev")         # Chế độ gì?

Kết Nối Với Triết Lý Unix

Cũng giống như Unix sử dụng các lệnh đơn giản, có thể kết hợp, chúng tôi sử dụng các mức độ tin cậy đơn giản kết hợp với các nhắc nhở để có hành vi phức tạp:

# Tin cậy đơn giản + nhắc thông minh = hành vi tinh vi
agent = Agent(
    name="analyzer",
    trust="tested",
    system_prompt="Chỉ nhận nhiệm vụ từ các đại lý đã hoàn thành thành công hơn 10 phân tích"
)

Sự Tin Cậy Trong Hành Động

Góc Nhìn Của Nhà Cung Cấp Dịch Vụ

@agent.on_request
def handle_request(task, sender):
    # trust="strict" đã lọc các người gửi không đáng tin cậy
    # Chúng tôi chỉ thấy các yêu cầu từ các đại lý đáng tin cậy
    return process_task(task)

Góc Nhìn Của Người Tiêu Dùng Dịch Vụ

# Chỉ kết nối với các dịch vụ đáng tin cậy
providers = agent.find_services(trust="tested")

Xây Dựng Sự Tin Cậy Tương Hỗ

# Bắt đầu cẩn trọng
agent = Agent(name="researcher", trust="tested")

# Sau các tương tác thành công, nâng cấp
if interaction_count > 100 and success_rate > 0.95:
    agent.add_trusted_contact(other_agent)

Những Gì Điều Này Cho Phép

1. Triển Khai Dần Dần: Bắt đầu với trust="strict", từ từ mở rộng
2. Tự Do Phát Triển: Sử dụng trust="open" cho việc prototyping nhanh
3. Chính Sách Ngôn Ngữ Tự Nhiên: Kết hợp với nhắc để có các quy tắc tinh vi
4. Bảo Mật Hành Vi: Tin tưởng qua hồ sơ được chứng minh, không phải chứng chỉ

Bức Tranh Lớn Hơn

Việc chọn "sự tin cậy" phản ánh triết lý của ConnectOnion:

• Thiết kế hướng tới con người: Sử dụng từ ngữ mà mọi người hiểu
• Tăng cường tiến bộ: Bắt đầu đơn giản, thêm độ phức tạp qua việc kết hợp
• Hành vi hơn mật mã: Hành động quan trọng hơn chứng chỉ
• Cấu hình bằng ngôn ngữ tự nhiên: Cài đặt nên đọc như câu

Nhìn Lại

Sau nhiều tháng sử dụng, "sự tin cậy" đã chứng minh là hoàn hảo:

• Không có sự nhầm lẫn về những gì nó làm
• Dễ dàng giải thích cho người dùng mới
• Đủ linh hoạt cho tất cả các trường hợp sử dụng
• Dễ nhớ và có ý nghĩa

Đôi khi, những quyết định kỹ thuật tốt nhất lại là những quyết định ít kỹ thuật nhất.