TÓM TẮT
Bạn ngừng "chăm sóc" các tác nhân AI bằng cách xây dựng ba thứ: rào chắn (guardrails - các ràng buộc ngăn ngừa lỗi thảm khốc), khả năng quan sát (observability - nhật ký và chỉ số cho biết điều gì đã xảy ra), và các điểm kiểm tra (checkpoints - tạm dừng tự động để con người xác minh các quyết định). Thiết lập những điều này một lần, và các tác nhân của bạn có thể tự chạy trong hàng giờ thay vì vài phút. Các công cụ như Apidog giúp ích bằng cách cho phép bạn định nghĩa các hợp đồng API mà tác nhân không thể vi phạm, biến lớp API của bạn thành một mạng lưới an toàn.
Giới thiệu
Tuần trước, tôi đã chứng kiến một nhà phát triển dành 4 giờ để giám sát một tác nhân AI đáng lẽ ra phải giúp anh ta tiết kiệm thời gian. Cứ vài phút, anh ta lại ngắt lời, sửa lỗi và khởi động lại. Cuối cùng, anh ta đã làm nhiều việc thủ công hơn so với việc tự viết mã.
Đây là vấn đề "chăm sóc trẻ con", và đó là lý do hàng đầu khiến các tác nhân AI không thực hiện được lời hứa của mình. Các công cụ hoạt động. Các mô hình có khả năng. Nhưng hầu hết các nhóm không bao giờ vượt qua được giai đoạn giám sát liên tục.
Đây là điều đang xảy ra: hầu hết các thiết lập tác nhân AI coi LLM như một nhà phát triển cấp dưới cần được hướng dẫn tận tình trong mọi nhiệm vụ. Nhưng LLM không phải là cấp dưới. Chúng giống như những thực tập sinh cực kỳ nhanh, đôi khi tạo ra thông tin sai lệch nhưng vẫn tự tin làm sai nếu bạn không đặt ra ranh giới.
Xác định các hợp đồng API mà tác nhân AI của bạn có thể tuân theo
Đến cuối hướng dẫn này, bạn sẽ có:
- Một mô hình tư duy để suy nghĩ về quyền tự chủ của tác nhân
- Các mẫu cụ thể cho rào chắn, khả năng quan sát và điểm kiểm tra
- Các ví dụ mã bạn có thể sao chép vào dự án của mình ngay hôm nay
- Một danh sách kiểm tra để đánh giá xem một tác nhân đã sẵn sàng chạy tự động hay chưa
Tại sao các tác nhân cần được giám sát liên tục
Các tác nhân AI thất bại theo những cách có thể dự đoán được. Hiểu rõ các chế độ lỗi này là bước đầu tiên để khắc phục chúng.
Chế độ lỗi 1: Lạm dụng phạm vi (Scope creep)
Bạn yêu cầu một tác nhân "thêm xác thực vào điểm cuối API." Nó thêm xác thực. Sau đó, nó thêm giới hạn tốc độ. Sau đó, nó tái cấu trúc lược đồ cơ sở dữ liệu. Sau đó, nó xóa những gì nó cho là các tệp "không sử dụng", hóa ra lại rất quan trọng.
Tác nhân cứ tiếp tục vì không ai bảo nó dừng lại. LLM không có ý thức bẩm sinh về việc "hoàn thành". Chúng sẽ tiếp tục thực hiện thay đổi cho đến khi đạt đến giới hạn token hoặc bạn ngắt lời chúng.
Chế độ lỗi 2: Trừu tượng hóa sai (Wrong abstractions)
Một tác nhân được giao nhiệm vụ "cải thiện xử lý lỗi" có thể thêm các khối try-catch ở khắp mọi nơi. Về mặt kỹ thuật là đúng. Nhưng thực tế lại tệ hại. Mã trở nên khó đọc, việc ghi nhật ký không nhất quán và các trường hợp lỗi thực tế không được xử lý.
Tác nhân hiểu yêu cầu theo nghĩa đen nhưng lại bỏ lỡ ý định. Nếu không có ví dụ về cách xử lý lỗi tốt, nó sẽ mặc định chọn cách giải thích rõ ràng nhất (và tồi tệ nhất).
Chế độ lỗi 3: Lỗi tầng (Cascading failures)
Một tác nhân mắc một lỗi nhỏ ở bước 1. Đến bước 10, lỗi đó đã lan truyền qua mọi quyết định tiếp theo. Điều bắt đầu bằng một lỗi đánh máy trong tên hàm trở thành một API bị hỏng, các bài kiểm tra bị lỗi và một nhà phát triển bối rối cố gắng tìm hiểu điều gì đã xảy ra.
Đây là chế độ lỗi nguy hiểm nhất vì tác nhân không biết mình đã thất bại. Mỗi bước đều có vẻ hợp lý khi đứng một mình. Chỉ kết quả cuối cùng mới tiết lộ vấn đề.
Chế độ lỗi 4: Cạn kiệt tài nguyên (Resource exhaustion)
Nếu không được giám sát, một số tác nhân sẽ lặp vô thời hạn. Chúng sẽ thử lại các lệnh gọi API thất bại không ngừng, tạo ra các tác nhân phụ mới không giới hạn hoặc tiếp tục tạo mã cho đến khi đạt đến giới hạn thanh toán của bạn.
Nếu không có ràng buộc về tài nguyên, các tác nhân không biết khi nào phải dừng lại.
Khung quyền tự chủ: rào chắn, khả năng quan sát, điểm kiểm tra
Bạn giải quyết những vấn đề này bằng ba lớp. Hãy hình dung chúng như một kim tự tháp: rào chắn ở dưới cùng (ngăn ngừa thất bại), khả năng quan sát ở giữa (phát hiện thất bại), và các điểm kiểm tra ở trên cùng (khôi phục sau thất bại).
Lớp 1: Rào chắn (ngăn ngừa)
Rào chắn là những ràng buộc ngăn ngừa các lỗi thảm khốc. Chúng là các quy tắc mà tác nhân của bạn không thể vi phạm, được thực thi bằng mã, chứ không phải bằng các lời nhắc.
Các ràng buộc cứng thông qua mã:
# Không nên: Tin tưởng tác nhân tuân thủ hướng dẫn
agent.run("Only modify files in the src/ directory")
# Nên: Áp dụng các ràng buộc trong mã
import os
from pathlib import Path
ALLOWED_DIRECTORIES = {"src", "tests", "docs"}
def validate_file_path(path: str) -> bool:
"""Tác nhân không thể ghi ra ngoài các thư mục được phép."""
abs_path = Path(path).resolve()
return any(
str(abs_path).startswith(str(Path(d).resolve()))
for d in ALLOWED_DIRECTORIES
)
# Use in your agent's file operations
def agent_write_file(path: str, content: str):
if not validate_file_path(path):
raise ValueError(f"Không thể ghi vào {path}: ngoài các thư mục được phép")
with open(path, 'w') as f:
f.write(content)
Các ràng buộc lược đồ API:
Khi tác nhân của bạn gọi API, hãy sử dụng lược đồ để ngăn chặn các yêu cầu không đúng định dạng. Đây là lúc Apidog phát huy tác dụng. Định nghĩa hợp đồng API của bạn một lần, và tác nhân của bạn không thể gửi dữ liệu sai định dạng.
// apidog-schema.ts
export const CreateUserSchema = {
type: 'object',
required: ['email', 'name'],
properties: {
email: { type: 'string', format: 'email' },
name: { type: 'string', minLength: 1, maxLength: 100 },
role: { type: 'string', enum: ['user', 'admin', 'guest'] }
},
additionalProperties: false
}
// Tác nhân phải xác thực trước khi gọi API
function validateRequest(schema: object, data: unknown): void {
const valid = ajv.validate(schema, data)
if (!valid) {
throw new Error(`Yêu cầu không hợp lệ: ${JSON.stringify(ajv.errors)}`)
}
}
Các ràng buộc về ngân sách:
import time
from dataclasses import dataclass
@dataclass
class AgentBudget:
max_steps: int = 50
max_tokens: int = 100000
max_time_seconds: int = 600 # 10 phút
max_api_calls: int = 100
class BudgetEnforcer:
def __init__(self, budget: AgentBudget):
self.budget = budget
self.start_time = time.time()
self.steps = 0
self.tokens_used = 0
self.api_calls = 0
def check(self) -> bool:
"""Trả về False nếu vượt quá ngân sách."""
elapsed = time.time() - self.start_time
if self.steps >= self.budget.max_steps:
raise RuntimeError(f"Đã đạt giới hạn bước: {self.steps}")
if self.tokens_used >= self.budget.max_tokens:
raise RuntimeError(f"Đã đạt giới hạn token: {self.tokens_used}")
if elapsed >= self.budget.max_time_seconds:
raise RuntimeError(f"Đã đạt giới hạn thời gian: {elapsed:.0f}s")
if self.api_calls >= self.budget.max_api_calls:
raise RuntimeError(f"Đã đạt giới hạn lệnh gọi API: {self.api_calls}")
return True
def record_step(self, tokens: int, api_calls: int = 0):
self.steps += 1
self.tokens_used += tokens
self.api_calls += api_calls
self.check()
Lớp 2: Khả năng quan sát (phát hiện)
Khi các tác nhân chạy trong nhiều giờ, bạn cần biết chúng đang làm gì mà không cần theo dõi từng bước. Khả năng quan sát cung cấp cho bạn một dòng thời gian các quyết định.
Ghi nhật ký có cấu trúc:
import json
from datetime import datetime
from typing import Any
class AgentLogger:
def __init__(self, log_file: str = "agent_trace.jsonl"):
self.log_file = log_file
self.entries = []
def log(self, event: str, data: dict[str, Any] | None = None):
entry = {
"timestamp": datetime.utcnow().isoformat(),
"event": event,
"data": data or {}
}
self.entries.append(entry)
# Ghi vào tệp ngay lập tức (không làm mất nhật ký khi gặp sự cố)
with open(self.log_file, 'a') as f:
f.write(json.dumps(entry) + '\n')
def log_decision(self, decision: str, reasoning: str, confidence: float):
"""Ghi nhật ký khi tác nhân đưa ra một quyết định quan trọng."""
self.log("decision", {
"decision": decision,
"reasoning": reasoning,
"confidence": confidence
})
def log_action(self, action: str, params: dict, result: str):
"""Ghi nhật ký các hành động của tác nhân và kết quả của chúng."""
self.log("action", {
"action": action,
"params": params,
"result": result[:200] # Cắt bớt kết quả dài
})
def log_error(self, error: str, context: dict):
"""Ghi nhật ký lỗi với đầy đủ ngữ cảnh."""
self.log("error", {
"error": error,
"context": context
})
# Cách sử dụng trong tác nhân
logger = AgentLogger()
logger.log_decision(
decision="Add rate limiting to API",
reasoning="Current endpoint has no protection against abuse",
confidence=0.85
)
logger.log_action(
action="write_file",
params={"path": "src/middleware/rate-limit.ts"},
result="Successfully wrote 45 lines"
)
Bảng điều khiển chỉ số:
Đối với các tác nhân chạy lâu hơn, bạn muốn các chỉ số tổng hợp, chứ không chỉ các nhật ký riêng lẻ.
from collections import Counter
from dataclasses import dataclass, field
@dataclass
class AgentMetrics:
actions_taken: Counter = field(default_factory=Counter)
files_modified: list[str] = field(default_factory=list)
api_calls: dict[str, int] = field(default_factory=dict)
errors: list[str] = field(default_factory=list)
decisions_by_confidence: dict[str, int] = field(default_factory=lambda: {
"high (>0.9)": 0,
"medium (0.7-0.9)": 0,
"low (<0.7)": 0
})
def record_action(self, action: str):
self.actions_taken[action] += 1
def record_file_modification(self, path: str):
if path not in self.files_modified:
self.files_modified.append(path)
def record_api_call(self, endpoint: str):
self.api_calls[endpoint] = self.api_calls.get(endpoint, 0) + 1
def record_error(self, error: str):
self.errors.append(error)
def record_decision(self, confidence: float):
if confidence > 0.9:
self.decisions_by_confidence["high (>0.9)"] += 1
elif confidence >= 0.7:
self.decisions_by_confidence["medium (0.7-0.9)"] += 1
else:
self.decisions_by_confidence["low (<0.7)"] += 1
def summary(self) -> str:
return f"""
Tóm tắt chỉ số tác nhân
=====================
Hành động: {dict(self.actions_taken)}
Tệp đã sửa đổi: {len(self.files_modified)}
Lệnh gọi API: {self.api_calls}
Lỗi: {len(self.errors)}
Quyết định theo độ tin cậy: {self.decisions_by_confidence}
"""
Lớp 3: Điểm kiểm tra (khôi phục)
Các điểm kiểm tra là những lần tạm dừng tự động nơi tác nhân chờ xác minh từ con người. Chúng cho phép bạn phát hiện vấn đề sớm mà không cần giám sát liên tục.
Các điểm kiểm tra tự động:
from enum import Enum
from typing import Callable
class CheckpointTrigger(Enum):
BEFORE_FILE_WRITE = "before_file_write"
BEFORE_API_CALL = "before_api_call"
BEFORE_GIT_COMMIT = "before_git_commit"
BEFORE_DELETE = "before_delete"
AFTER_N_STEPS = "after_n_steps"
@dataclass
class Checkpoint:
trigger: CheckpointTrigger
description: str
data: dict
requires_approval: bool = True
class CheckpointManager:
def __init__(self, auto_approve: set[CheckpointTrigger] | None = None):
self.auto_approve = auto_approve or set()
self.pending: list[Checkpoint] = []
def create_checkpoint(
self,
trigger: CheckpointTrigger,
description: str,
data: dict
) -> bool:
"""Trả về True nếu được phê duyệt, False nếu bị từ chối."""
# Tự động phê duyệt một số tác nhân kích hoạt nhất định
if trigger in self.auto_approve:
return True
checkpoint = Checkpoint(
trigger=trigger,
description=description,
data=data
)
self.pending.append(checkpoint)
# Trong một hệ thống thực tế, điều này sẽ thông báo cho con người và chờ đợi
# Hiện tại, chúng ta trả về False để tạm dừng thực thi
return False
def approve(self, checkpoint_id: int) -> None:
"""Con người phê duyệt một điểm kiểm tra đang chờ xử lý."""
if 0 <= checkpoint_id < len(self.pending):
self.pending.pop(checkpoint_id)
def reject(self, checkpoint_id: int) -> None:
"""Con người từ chối một điểm kiểm tra đang chờ xử lý."""
raise RuntimeError(f"Điểm kiểm tra bị từ chối: {self.pending[checkpoint_id]}")
# Cách sử dụng trong tác nhân
checkpoints = CheckpointManager(
auto_approve={CheckpointTrigger.BEFORE_FILE_WRITE} # Tin tưởng việc ghi tệp
)
# Trước hành động phá hủy
if not checkpoints.create_checkpoint(
trigger=CheckpointTrigger.BEFORE_DELETE,
description="About to delete src/legacy/ directory",
data={"path": "src/legacy/", "files": ["old_handler.ts", "deprecated.ts"]}
):
# Chờ phê duyệt từ con người
agent.pause("Đang chờ phê duyệt để xóa tệp")
Xây dựng các tác nhân tự chủ với Apidog
Khi tác nhân AI của bạn tương tác với API, rủi ro lớn nhất là các yêu cầu không đúng định dạng gây ra lỗi downstream. Apidog giúp ích bằng cách cho phép bạn định nghĩa các lược đồ API chính xác mà tác nhân của bạn phải tuân theo.
Thiết lập các hợp đồng API:
- Nhập hoặc định nghĩa thông số kỹ thuật OpenAPI của bạn trong Apidog
- Tạo mã máy khách với xác thực tích hợp
- Cung cấp cho tác nhân của bạn máy khách đã được xác thực thay vì HTTP thô
// Thay vì để tác nhân gọi API trực tiếp
const response = await fetch('/api/users', {
method: 'POST',
body: JSON.stringify(data) // Không có xác thực
})
// Cung cấp cho tác nhân một máy khách đã được xác thực
import { UsersApi } from './generated/apidog-client'
const usersApi = new UsersApi()
// Tác nhân chỉ có thể gửi các yêu cầu hợp lệ - lược đồ được thực thi
const response = await usersApi.createUser({
email: 'user@example.com',
name: 'Test User',
role: 'user' // Phải là giá trị enum hợp lệ
})
Điều này biến lớp API của bạn thành một rào chắn. Tác nhân không thể gửi dữ liệu không hợp lệ vì máy khách từ chối nó trước khi yêu cầu được gửi đi.
Tạo các máy khách API đã được xác thực cho tác nhân AI của bạn
Các mẫu đã được chứng minh và những sai lầm phổ biến
Mẫu 1: Quy trình phê duyệt hai lớp (Approval sandwich)
Đối với các hoạt động rủi ro, yêu cầu phê duyệt TRƯỚC VÀ SAU khi thực hiện.
def risky_operation(agent, operation):
# Phê duyệt trước
if not agent.checkpoint(f"About to: {operation.description}"):
return "Cancelled by user"
# Thực hiện thao tác
result = operation.execute()
# Phê duyệt sau (xác minh kết quả)
if not agent.checkpoint(f"Verify result of: {operation.description}"):
operation.rollback()
return "Rolled back by user"
return result
Mẫu 2: Ngưỡng tin cậy (Confidence thresholds)
Đừng để tác nhân hành động dựa trên các quyết định có độ tin cậy thấp.
MIN_CONFIDENCE = 0.75
def agent_decide(options: list[dict]) -> dict:
best = max(options, key=lambda x: x.get('confidence', 0))
if best['confidence'] < MIN_CONFIDENCE:
# Chuyển lên người quản lý
return {
'action': 'escalate',
'reason': f"Best option has confidence {best['confidence']:.2f} < {MIN_CONFIDENCE}",
'options': options
}
return best
Mẫu 3: Các hoạt động bất biến (Idempotent operations)
Thiết kế các hành động của tác nhân để có thể lặp lại mà không gây ra tác dụng phụ.
import hashlib
def idempotent_write(path: str, content: str) -> bool:
"""Chỉ ghi nếu nội dung thay đổi."""
content_hash = hashlib.sha256(content.encode()).hexdigest()
existing_hash = None
if os.path.exists(path):
with open(path, 'r') as f:
existing_hash = hashlib.sha256(f.read().encode()).hexdigest()
if content_hash == existing_hash:
logger.log_action("write_file", {"path": path}, "Đã bỏ qua - không có thay đổi")
return False
with open(path, 'w') as f:
f.write(content)
logger.log_action("write_file", {"path": path}, f"Đã ghi {len(content)} byte")
return True
Những sai lầm phổ biến cần tránh
Tin tưởng các lời nhắc như ràng buộc. "Đừng xóa tệp" trong lời nhắc không phải là một ràng buộc. Quyền tệp mới là ràng buộc.
Không có kế hoạch khôi phục. Khi một tác nhân mắc lỗi, bạn cần hoàn tác nó. Nếu bạn không sử dụng git hoặc các bản sao lưu, bạn đang tin tưởng tác nhân với những hành động không thể khôi phục.
Bỏ qua điểm số tin cậy. Hầu hết các LLM đều xuất ra độ tin cậy hoặc có thể được nhắc để làm điều đó. Độ tin cậy thấp = tạm dừng và hỏi con người.
Giám sát quá mức. Nếu bạn đang theo dõi mọi bước, bạn chưa xây dựng một hệ thống tự chủ. Bạn đã xây dựng một hệ thống thủ công chậm chạp.
Chỉ định không rõ ràng về thành công. Tác nhân cần biết khi nào nó hoàn thành. "Sửa lỗi" không có điều kiện kết thúc. "Sửa lỗi VÀ tất cả các bài kiểm tra đều vượt qua" thì có.
Các lựa chọn thay thế và so sánh
| Cách tiếp cận | Khả năng tự chủ | Rủi ro | Tốt nhất cho |
|---|---|---|---|
| Viết mã thủ công | Không | Thấp | Công việc phức tạp, quan trọng |
| Lập trình cặp với AI | Thấp | Thấp | Học tập, khám phá |
| Các tác nhân được giám sát | Trung bình | Trung bình | Các nhiệm vụ định kỳ |
| Các tác nhân tự chủ có rào chắn | Cao | Được kiểm soát | Các thao tác hàng loạt, di chuyển dữ liệu |
| Các tác nhân hoàn toàn tự chủ | Rất cao | Rất cao | Các quy trình làm việc đáng tin cậy, đã được kiểm tra kỹ |
Hầu hết các nhóm nên hướng tới "tự chủ có rào chắn." Đây là điểm lý tưởng nơi bạn tiết kiệm 80% thời gian với 10% rủi ro.
Các trường hợp sử dụng thực tế
Di chuyển cơ sở mã. Một nhóm đã sử dụng một tác nhân tự chủ để di chuyển 200 điểm cuối API từ REST sang GraphQL. Các rào chắn đã ngăn chặn thay đổi lược đồ. Các điểm kiểm tra yêu cầu phê duyệt trước khi xóa các điểm cuối cũ. Việc di chuyển mất 3 ngày thay vì 3 tuần, với không có sự cố sản xuất nào.
Tạo tài liệu. Một tác nhân tự động tạo tài liệu API từ mã. Các rào chắn đảm bảo nó chỉ đọc từ các thư mục cụ thể. Các điểm kiểm tra tạm dừng trước khi xuất bản. Nhóm xem xét tài liệu mỗi tuần một lần thay vì viết thủ công.
Độ bao phủ kiểm thử. Một tác nhân phân tích mã và viết các bài kiểm thử còn thiếu. Các ràng buộc ngân sách ngăn chặn việc tạo ra các bài kiểm thử không kiểm soát. Ngưỡng tin cậy gắn cờ các bài kiểm thử không chắc chắn để con người xem xét. Độ bao phủ đã tăng từ 60% lên 85% trong một tháng.
Tóm tắt
Đây là những gì bạn đã học:
- Các tác nhân AI thất bại theo những cách có thể dự đoán được: lạm dụng phạm vi, trừu tượng hóa sai, lỗi tầng, cạn kiệt tài nguyên
- Ba lớp giải quyết hầu hết các vấn đề: rào chắn (ngăn ngừa), khả năng quan sát (phát hiện), điểm kiểm tra (khôi phục)
- Rào chắn là mã, không phải lời nhắc. Thực thi các ràng buộc bằng chương trình.
- Khả năng quan sát có nghĩa là nhật ký và chỉ số có cấu trúc, chứ không phải theo dõi mọi bước
- Các điểm kiểm tra cho phép con người xác minh các quyết định mà không cần giám sát liên tục
- Các lược đồ API từ Apidog biến lớp API của bạn thành một rào chắn
Các bước tiếp theo của bạn:
- Xác định nhiệm vụ hỗ trợ AI lặp đi lặp lại nhất của bạn
- Xác định rào chắn: điều gì mà tác nhân không bao giờ được làm?
- Thêm ghi nhật ký có cấu trúc để xem điều gì đang xảy ra
- Tạo các điểm kiểm tra cho các hoạt động rủi ro cao
- Hãy để nó chạy trong 30 phút và kiểm tra nhật ký
Mục tiêu không phải là loại bỏ con người khỏi vòng lặp. Mà là đặt con người vào đúng vị trí trong vòng lặp: đưa ra các quyết định cấp cao thay vì sửa chữa các lỗi cấp thấp.
Xây dựng rào chắn API cho tác nhân AI của bạn - miễn phí
Câu hỏi thường gặp
Sự khác biệt giữa tác nhân AI và trợ lý AI là gì? Một trợ lý phản hồi các yêu cầu của bạn và chờ hướng dẫn tiếp theo của bạn. Một tác nhân nhận một mục tiêu và tự chủ lập kế hoạch và thực hiện các bước để đạt được nó. Trợ lý cần bạn trong mọi vòng lặp. Các tác nhân chạy cho đến khi chúng đạt đến một điểm kiểm tra hoặc hoàn thành.
Làm thế nào để tôi biết tác nhân của mình đã sẵn sàng chạy tự chủ chưa? Hãy chạy nó ở chế độ giám sát trong 10 phiên. Theo dõi mỗi lần bạn phải can thiệp. Nếu số lần can thiệp giảm xuống dưới 2 lần mỗi phiên và tất cả đều là nhỏ (làm rõ, không phải sửa lỗi), thì nó đã sẵn sàng. Nếu các can thiệp thường xuyên hoặc yêu cầu hoàn tác công việc, hãy thêm nhiều rào chắn hơn.
Rủi ro lớn nhất với các tác nhân tự chủ là gì? Các lỗi tầng mà tác nhân không nhận ra. Một lỗi nhỏ ban đầu trở thành một vấn đề lớn sau này, và tác nhân tiếp tục vì mỗi bước đều có vẻ hợp lý khi đứng một mình. Các điểm kiểm tra phá vỡ những lỗi tầng này bằng cách buộc phải xác minh.
Tôi có thể sử dụng các mẫu này với bất kỳ LLM nào không? Có. Các mẫu (rào chắn, khả năng quan sát, điểm kiểm tra) không phụ thuộc vào mô hình. Chúng hoạt động với Claude, GPT-4, Gemini hoặc bất kỳ mô hình nào khác. Các chi tiết triển khai cụ thể có thể khác nhau, nhưng các khái niệm thì tương tự.
Khả năng quan sát làm chậm tác nhân đến mức nào? Không đáng kể. Ghi vào tệp nhật ký mất vài micro giây. Sự chậm lại đến từ các điểm kiểm tra chờ đợi đầu vào của con người. Đối với các lần chạy thực sự tự chủ, bạn chỉ kiểm tra tại những thời điểm rủi ro cao, chứ không phải mọi bước.
Nếu tác nhân đưa ra một quyết định mà tôi không đồng ý thì sao? Đó là mục đích của các điểm kiểm tra. Khi bạn thấy một quyết định mà bạn không đồng ý, hãy từ chối điểm kiểm tra đó. Tác nhân sẽ hoàn tác hoặc thử một cách tiếp cận khác. Tốt hơn nữa: đưa sở thích của bạn vào hướng dẫn của tác nhân để nó học hỏi phong cách của bạn theo thời gian.
Tôi nên bắt đầu với tác nhân được giám sát hay tác nhân tự chủ? Luôn bắt đầu với tác nhân được giám sát. Chạy tác nhân với các điểm kiểm tra trên mọi hành động quan trọng cho đến khi bạn tin tưởng nó. Dần dần loại bỏ các điểm kiểm tra cho các hành động rủi ro thấp. Điều này giúp xây dựng sự tự tin dần dần thay vì mạo hiểm một thất bại thảm khốc trong lần chạy tự chủ đầu tiên của bạn.
Apidog giúp ích cụ thể như thế nào với các tác nhân AI? Apidog tạo ra các máy khách API đã được xác thực từ các lược đồ của bạn. Khi một tác nhân sử dụng các máy khách này, các yêu cầu không đúng định dạng sẽ bị từ chối trước khi chúng đến phần phụ trợ của bạn. Điều này ngăn chặn toàn bộ một lớp lỗi trong đó tác nhân gửi dữ liệu sai định dạng hoặc giá trị không hợp lệ.