Deep Dive: Reliability & Governance cho Agent Loops

Reliability là một control problem, không phải confidence problem Thesis

Agent có thể sinh nhiều attempt hơn, nhưng số attempt không tự tạo độ tin cậy. Reliability xuất hiện khi mỗi transition được gate bởi evidence độc lập, mọi material state sống ngoài context, quyền hành động bị khoanh, budget có hard stop và ambiguity có named owner. Nói gọn: backpressure + memory + containment + accountability.

Confidence là tín hiệu nội bộ của actor; reliability là thuộc tính quan sát được của toàn hệ thống qua thời gian. Một agent có thể tự tin nhưng sai, hoặc thiếu tự tin nhưng tạo patch đúng. Vì vậy completion không nên phụ thuộc vào cách model mô tả kết quả mà vào việc môi trường có thỏa acceptance criteria, side effect có nằm trong scope và transition có tuân policy hay không.

Recurrence làm đổi risk profile. Một lỗi hiếm trong một run có thể trở thành lỗi thường xuyên khi chạy hàng giờ; một write nhỏ có thể tích lũy thành data corruption; một false positive của evaluator có thể dần trở thành policy thực tế. Reliability của loop vì thế không chỉ là tăng task success mà là giới hạn cách failure lặp, lan và tích lũy.

Bốn từ trong luận đề tương ứng bốn cơ chế. Backpressure ngăn actor tiếp tục khi evidence không đạt. Memory giữ lịch sử đủ để không lặp mù. Containment giới hạn authority và side effect. Accountability nối decision với receipt và owner. Thiếu một cơ chế, ba cơ chế còn lại có thể giảm hậu quả nhưng không đóng được failure path.

Kết quả của Hou et al. nên được đọc như bằng chứng về một class of failure, không phải ước lượng prevalence cho mọi agent system. Giá trị của nghiên cứu nằm ở việc chỉ ra effective bounds phải bao phủ cả control flow lẫn resource-growing operations: model call, tool call, delegation, state append và external write. Một vòng có giới hạn iteration nhưng mỗi iteration spawn vô hạn vẫn không bounded về mặt vận hành.

Threat map: bốn failure families Threat model

Threat model bắt đầu bằng assets và boundaries, không bắt đầu bằng danh sách model weakness. Assets có thể là source code, production data, budget, credential, reviewer attention hoặc uy tín của notification channel. Boundary là nơi untrusted input trở thành context, actor request trở thành tool action, evidence trở thành decision, hoặc state của run này trở thành context của run sau.

flowchart TD
  A["Weak or missing contract"] --> A1["Invented work / scope creep"]
  A --> A2["Generic automation rebranded"]
  B["Weak evidence"] --> B1["Model self-approval"]
  B --> B2["False completion"]
  C["Hidden or corrupt state"] --> C1["Repeated attempts"]
  C --> C2["Duplicate side effects"]
  D["Unbounded autonomy"] --> D1["Infinite retry / cost"]
  D --> D2["Unsafe production action"]
  D --> D3["No escalation path"]

Weak contract gây selection failure trước khi reasoning bắt đầu: job được đánh thức sai lúc, nhận stale item, mở rộng objective hoặc không có no-work path. Đây là lý do một model mạnh không cứu được intake xấu. Nó có thể thực hiện rất tốt công việc mà hệ thống lẽ ra không được chọn.

Weak evidence tạo false completion; hidden state tạo repeated work; unbounded autonomy biến hai lỗi trên thành incident kéo dài. Bốn family có quan hệ khuếch đại: verifier sai ghi decision sai vào state, run sau tin state đó, broad permission tiếp tục tạo side effect và retry policy làm lỗi lặp lại.

Governance vì thế không phải lớp approval phủ lên cuối pipeline. Verification, state, budget, escalation và exit phải được thiết kế cùng objective và workspace trong contract. Nếu chỉ thêm human approval cho action cuối, con người vẫn có thể nhận một evidence bundle sai, thiếu lịch sử hoặc được tạo sau hàng chục attempt ngoài scope.

Bốn lớp kiểm soát Controls

{
  "run_id": "ci-2026-07-19-0042",
  "item_id": "pr-381/check-test-linux",
  "attempt": 2,
  "observed_sha": "8f3c1a2",
  "commands": ["pytest tests/auth -q"],
  "changed_files": ["src/auth/token.py", "tests/auth/test_token.py"],
  "verification": { "exit_code": 0, "artifact_url": "..." },
  "decision": "exit-success",
  "stop_reason": "original failing command passed",
  "next_action": null
}

flowchart TD
  F["Verification failed"] --> A{"Actionable evidence?"}
  A -->|"no"| E["Escalate with receipt"]
  A -->|"yes"| N{"New evidence vs previous?"}
  N -->|"no"| S["Stop: repeated failure"]
  N -->|"yes"| B{"Budget + authority remain?"}
  B -->|"no"| E
  B -->|"yes"| R["Retry one scoped hypothesis"]
  R --> F

4. Least privilege, isolation và human handoff tạo containment

G.1

README.md#securing-unattended-loops · meta/RUNTIME_SELECTION.md

Recurring agent có thời gian để biến lỗi nhỏ thành incident. Untrusted input, broad credentials, mutable verifier và production write access tạo blast radius lớn hơn một interactive run có người quan sát.

Least privilege phải được enforce theo job identity, không vay toàn bộ quyền của người khởi tạo. Một loop docs drift chỉ cần read source và write docs branch; nó không cần credential deploy. Credential ngắn hạn, allowlist action và isolated workspace làm cho contract violation trở thành lỗi bị chặn thay vì lời nhắc bị model bỏ qua.

Policy sketch: data/authority separation + guarded mutation

JSCopy

if (input.origin === "untrusted") {
  input = treatAsData(input);        // never as authority
}

assert(pathIsAllowed(change.path));
assert(toolIsAllowed(change.tool));
assert(!change.modifies(verifierFiles));

if (change.isIrreversible || change.touchesProduction) {
  return requestHumanApproval(change, receipts);
}

Prompt injection trong loop nguy hiểm vì untrusted text có thể sống lâu và được tái nạp qua state. Issue body, log, document hoặc webpage phải giữ provenance “data”, không được biến thành authority dù nội dung tự xưng là system instruction. Tool policy và secret scope phải quyết định ngoài model; sanitization text đơn thuần không tạo trust boundary.

Boundary	Default an toàn	Approval trigger
Workspace	Fresh worktree/container/sandbox	Đụng file ngoài allowlist
Network	Deny hoặc allowlist domains/actions	Gửi data ra external system
Secrets	Job-scoped, short-lived, minimum role	Credential mới hoặc privilege increase
Source input	Untrusted text luôn là data	Instruction xung đột policy
Production	Read-only observe/report	Deploy, rollback, config/data mutation
Verifier	Immutable/frozen ngoài actor scope	Thay test, scorer, policy threshold

Isolation giảm ảnh hưởng chéo giữa attempts và giữa công việc của người dùng với loop. Fresh worktree/container tạo baseline có thể tái hiện, giúp diff có nghĩa và rollback rõ. Nhưng isolation không đồng nghĩa an toàn tuyệt đối: network, credential, shared cache và external API vẫn là side channels cần policy riêng.

Handoff tốt là một control path, không phải thông báo thất bại. Nó phải có named destination, urgency, decision cần người nhận đưa ra, attempts đã thử, raw evidence và residual risk. Nếu chỉ gửi “agent blocked”, con người phải điều tra lại từ đầu; nếu gửi toàn bộ context không cấu trúc, review bandwidth trở thành bottleneck mới.

Ưu điểm

• Giảm blast radius và làm incident interruptible.
• Tách untrusted content khỏi authority chống prompt-injection escalation.
• Named owner biến ambiguity thành handoff thay vì guess.

Nhược điểm

• Isolation/approval tăng setup và latency.
• Permission quá hẹp có thể tạo false blockers.
• Secrets/network policy phải được cập nhật theo integration thực.

Failure-mode table Runbook

Failure-mode table nên được dùng như diagnostic routing. Triệu chứng chỉ là observable surface; control phải đánh vào root cause. “Agent sửa cùng file” có thể do hidden state, nhưng cũng có thể do intake duplicate hoặc verifier luôn trả stale result. Receipt cần đủ để phân biệt trước khi team thêm retry hay prompt instruction mới.

Một failure thường cần control ở nhiều phase. Production action lặp lại cần idempotency ở state, write allowlist ở permission, mutation budget ở termination và approval cho irreversible path. Chỉ thêm một guard có thể giảm xác suất nhưng chưa đóng chuỗi nguyên nhân. Threat model nên vẽ đường từ untrusted input đến asset bị ảnh hưởng và đặt gate ở nhiều boundary độc lập.

Runbook cũng phải chỉ rõ evidence nào chứng minh recovery. Sau incident duplicate write, “đã thêm prompt không làm trùng” không đủ; cần replay crash window và chứng minh operation key ngăn side effect thứ hai. Sau false completion, cần test failure mẫu với verifier mới và theo dõi false-positive. Governance chỉ có giá trị khi control được drill.

Reliability scorecard trước unattended run Scorecard

Scorecard là promotion gate, không phải điểm trung bình. Với write access, một hàng mức 0 có thể là blocker dù các hàng khác đều mức 2. Evidence yếu không được bù bằng budget mạnh; broad privilege không được bù bằng receipt đẹp. Team nên xác định minimum level theo risk class trước khi chấm để tránh rationalize một deployment đã quyết sẵn.

Mức 2 phải được chứng minh bằng behavior, không chỉ configuration. Có checkpoint file chưa chứng minh crash-safe; có allowlist trong prompt chưa chứng minh runtime enforcement; có “human escalation” chưa chứng minh owner nhận và xử lý trong SLO. Evidence review nên gồm failure injection, sample receipts và một handoff drill thật.

Sau khi schedule, scorecard phải được theo dõi bằng metrics: verified success, false completion, duplicate action, recovery time, escalation precision, operator minutes và total cost. Maturity có thể giảm khi verifier drift hoặc owner thay đổi. Unattended status là quyền có thể thu hồi, không phải milestone đạt một lần rồi giữ mãi.

Kết luận Wrap

Reliability của agent loop không phải xác suất một answer đúng; nó là khả năng hệ thống giữ behavior trong boundary qua nhiều run, kể cả khi actor sai, evidence nhiễu, process crash và input đối nghịch. Điều đó đòi hỏi control ngoài model và record đủ để operator reconstruct causal chain.

Verification tạo backpressure, state tạo continuity, budget tạo effective bounds, permission tạo containment và escalation giữ human authority. Chúng không phải năm feature tùy chọn mà là năm mắt xích của cùng reliability case. Mắt xích yếu nhất thường quyết định blast radius của failure.

Governance tốt không biến mọi transition thành approval thủ công. Nó chuyển kiểm tra cơ học sang deterministic gate, giữ judgment cho boundary có ambiguity hoặc irreversible impact, và cung cấp receipt cô đọng để con người quyết nhanh. Mục tiêu là giảm turn-by-turn supervision mà không xóa ownership.

Câu hỏi cuối trước unattended run là: nếu loop sai liên tục trong toàn bộ budget, hệ thống có dừng hữu hạn, không làm hỏng verifier, không lặp side effect và bàn giao đủ evidence cho đúng owner không? Nếu câu trả lời chưa được failure-test, reliability vẫn là assumption chứ chưa phải thuộc tính đã chứng minh.