从五要素到八层框架
第 17 篇介绍了 Harness 的五个要素：动作空间、人工检查点、执行边界、审计日志、回滚。五要素是骨架，能处理大多数场景。
但生产级 Agent 面对的威胁更复杂：
- LLM 被提示注入操控，绕过工具白名单用合法工具实现非法意图
- 多步推理耗尽 Token 预算，系统雪崩
- 审计日志被事后篡改，合规失效
- 模型报告\”已执行\”，但实际状态已被回滚——谁的话算数？
完整的 8 层框架在五要素基础上增加了三层主动防御：
Layer 1 Minimal Footprint 最小权限：任务只暴露必要工具
Layer 2 Action Space Registry 动作注册表：PermissionLevel 枚举，每个动作有 budget_cost
Layer 3 Permission Budget 权限预算：spend() / BudgetExhaustedError
Layer 4 Execution Sandbox 执行沙箱：输入净化 + 子进程隔离
Layer 5 Human Checkpoint 人工检查点：LangGraph interrupt（第 17 篇详述）
Layer 6 Immutable Audit Log 不可篡改审计日志：哈希链 JSONL + 完整性验证
Layer 7 Rollback Coordinator 回滚协调器：事务 context manager
Layer 8 Threat Model 威胁模型：对抗场景测试
本文用实测数据覆盖全部 8 层，附三个反直觉结论。
Layer 1：最小权限——任务决定工具范围
核心思路：不同任务类型只暴露必要工具，LLM 连其他工具的存在都不知道。
TASK_TOOL_MAP: dict[str, list] = {
\”read_only\”: [read_data],
\”reporting\”: [read_data, send_report],
\”data_entry\”: [read_data, write_data],
\”admin\”: [read_data, write_data, send_report, delete_record],
}
def get_tools_for_task(task_type: str) –> list:
return TASK_TOOL_MAP.get(task_type, [read_data])
每种任务类型的工具子集：
Task type → Available tools
read_only → [\’read_data\’]
reporting → [\’read_data\’, \’send_report\’]
data_entry → [\’read_data\’, \’write_data\’]
admin → [\’read_data\’, \’write_data\’, \’send_report\’, \’delete_record\’]
read_only 任务下，模型完全不知道 write_data、delete_record 的存在——bind_tools() 只传入该任务的工具子集。
实测：read_only Agent 查询 sales_q1，预算消耗 1（一次 read_data），没有任何越权行为。
Layer 2 & 3：注册表 + 权限预算
注册表设计：每个动作声明权限等级和预算成本。
class PermissionLevel(Enum):
READ = 1
WRITE = 2
ADMIN = 3
IRREVERSIBLE = 4
@dataclass
class RegisteredAction:
name: str
level: PermissionLevel
budget_cost: int
description: str
handler: Any
ACTION_REGISTRY: dict[str, RegisteredAction] = {
\”read_data\”: RegisteredAction(\”read_data\”, READ, 1, \”Read a record\”, read_data),
\”write_data\”: RegisteredAction(\”write_data\”, WRITE, 3, \”Write/update a record\”, write_data),
\”send_report\”: RegisteredAction(\”send_report\”, WRITE
