[开源] 当 AI Agent 学会三思而后行

背景：养虾繁荣背后的隐忧

2024 年以来，以 OpenClaw 为代表的开源 AI Agent 助手如雨后春笋般涌现。这些工具让开发者能够通过自然语言指挥 AI 执行文件操作、运行命令、调用 API ，极大地提升了工作效率。然而，在这场技术狂欢背后，一个关键问题被普遍忽视：安全问题。

绝大多数 AI Agent 采用"云端 LLM → 工具执行"的直连架构。用户的一句"帮我清理临时文件"，云端模型可能生成一条 rm -rf /tmp/* 的命令，而系统在权限允许的情况下会直接执行。这种设计存在三个致命缺陷：

1. 意图劫持风险：恶意提示词注入可能让模型执行超出用户预期的操作
2. 数据外泄隐患：模型可能生成将敏感文件上传到外部服务器的命令
3. 破坏性操作无拦截：删除、覆盖等高危操作缺乏二次确认机制

更严峻的是，这些问题在现有开源方案中几乎无解因为它们将安全完全寄托于云端模型的"自律"，而模型本身并不理解本地文件系统的敏感性和操作的不可逆性。

双脑架构：一种新的安全范式

Kocort 项目提出了一种不同的思路：双脑架构（ Dual-Brain Architecture ）。其核心思想借鉴了人类神经系统的分工大脑负责复杂推理，小脑负责快速反射和安全监控。

在技术实现上：

• 大脑（ Brain ）：云端大模型（ GPT-4 、Claude 等）负责理解用户意图、制定执行策略
• 小脑（ Cerebellum ）：本地量化模型（ 0.8B-1.5B 参数）完全离线运行，对每一条工具调用做语义安全审查

这种架构的关键创新在于：**将安全审查从"规则匹配"升级为"语义理解"**。传统的工具策略（ Tool Policy ）只能基于白名单/黑名单做静态拦截，而小脑模型能够理解"这条命令是否真的符合用户的原始请求"。

技术实现深度解析

审查管线集成

在 Kocort 的 Runtime 执行管线中，小脑审查被深度集成到 pipeline_execute 阶段。每次云端模型产生 tool_call 后，执行流程如下：

┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐ │ 云端 LLM 输出 │ → │ 小脑语义审查 │ → │ 工具执行/拦截 │ │ tool_call │ │ approve/flag │ │ │ │ │ │ /reject │ │ │ └─────────────────┘ └─────────────────┘ └─────────────────┘ 

核心代码位于 internal/cerebellum/cerebellum.go：

func (m *Manager) ReviewToolCall(req ToolCallReviewRequest) (ToolCallReviewResult, error) { status := m.local.Status() // 优雅降级：小脑不可用时自动放行，不阻塞流程 if status != StatusRunning { return ToolCallReviewResult{ Verdict: "approve", Reason: "cerebellum not running; degraded to rule-only check", Risk: "none", }, nil } // 构建审查 Prompt ，包含用户原始请求和工具调用参数 prompt := buildToolCallReviewPrompt( req.UserMessage, req.ToolName, req.ToolParams ) // 本地模型同步推理（使用 llama.cpp CGO 绑定） output, err := m.inferSync(prompt, 4096) if err != nil { // 推理失败时同样降级放行 return ToolCallReviewResult{ Verdict: "approve", Reason: "inference failed; degraded to rule-only check", Risk: "none", }, nil } // 解析审查结果 result := parseToolCallReviewOutput(output) return result, nil } 

审查 Prompt 设计

小脑模型的系统指令经过精心设计，要求从 5 个维度进行评估：

你是一个安全审查助手。你的任务是审查 AI Agent 工具调用指令是否安全。 ## 审查要点 1. 指令是否与用户原始请求的意图一致？ 2. 是否存在数据外泄风险（如 curl 上传敏感文件）？ 3. 是否存在超出用户预期的破坏性操作（如删除非目标文件）？ 4. 参数中是否包含注入攻击（如命令注入、路径遍历）？ 5. 操作范围是否限制在沙盒授权目录内？ ## 输出格式（严格 JSON ） {"verdict": "approve|flag|reject", "reason": "简短原因", "risk": "none|low|medium|high"} 

这种设计让小脑模型能够理解上下文语义，而不仅仅是匹配关键词。例如：

• 用户说"帮我看看配置文件"，模型生成 cat ~/.aws/credentials → 小脑可能标记为 flag（敏感文件读取）
• 用户说"删除下载文件夹里的临时文件"，模型生成 rm ~/Downloads/*.tmp → 小脑可能 approve（符合预期）

智能跳过机制

为了平衡安全性与响应速度，Kocort 实现了基于风险分级的智能跳过：

func ShouldReviewToolCall(toolName string, toolParams map[string]any, isElevated bool) bool { // 配置模式不需要审查 if isConfigMode { return false } // 低风险只读工具默认跳过，除非包含敏感关键词 if isLowRiskReadOnly(toolName) { if localmodel.ContainsSensitiveKeywords(toolParams) { return true } return false } // 提权操作必须审查 if isElevated { return true } // 包含敏感关键词的必须审查 if localmodel.ContainsSensitiveKeywords(toolParams) { return true } return true } 

这种机制让 memory_search、sessions_list 等只读操作在正常情况下快速通过，而 exec、write、delete 等高危操作始终接受审查。

技术权衡与思考

双脑架构并非没有代价。引入本地小脑意味着：

• 资源占用：需要运行一个额外的本地模型（约 1-2GB 内存）
• 延迟增加：每次工具调用增加一次本地推理（约 100-500ms ）
• 复杂度提升：需要管理两个模型的生命周期

但这些代价换来的是本质性的安全提升：

1. 敏感信息永不出设备（小脑完全离线）
2. 恶意提示词注入被本地语义理解拦截
3. 破坏性操作有二次审查机制

结语：AI Agent 安全的必经之路

随着 AI Agent 在企业和个人的普及，安全问题终将成为不可回避的议题。双脑架构提供了一种可行的解决思路：不依赖云端模型的"善意"，而是用本地的小模型做实时的安全守门人。

这种架构或许会成为未来桌面级 AI Agent 的标准配置就像现代浏览器的沙箱机制一样，成为用户信任的基石。

本文基于 Kocort 项目的实际实现，代码已开源：github.com/kocort/kocort