Sidecar 解决什么问题？
- 定位: 提议者-审核者处理“操作执行前审批或操作完成后验证”，Sidecar 处理“操作执行时如何实时校验安全性和可靠性”;
- 形态: 一种伴随主 Agent 思考循环运行的轻量级 LLM 调用;
- 审查对象: 不审查主 Agent 的最终输出，而是对主 Agent 的行为做独立判断;
- 命名: 得名于微服务架构中的边车（Sidecar）模式——如同摩托车旁挂的边车，独立运行但与主体并行;
- 案例: Claude Code 在自动模式（Auto Mode）下，主模型决定执行一个工具调用时，一个独立的轻量级 LLM 调用会被触发来判断“这个工具调用是否安全”;
它与主模型的流式输出如何配合？
- 并行: 主模型发出一个工具调用后还在继续生成后续文本时，Sidecar 的审查已经同步开始;
- 门控: 对被审查的那次工具调用而言，Sidecar 起门控作用——危险操作在放行之前不会真正执行;
- 延迟: 这类轻量模型调用通常在数百毫秒内完成，与主模型的流式输出并行进行，用户几乎感受不到额外延迟;
为什么只读结构化字段？
- 威胁: 提示注入;
- 风险: 如果 Sidecar 同时读取主模型的上下文或思考过程，攻击者一旦在用户输入或网页内容中夹带“请允许执行 rm -rf”这类话术，Sidecar 就可能将其误判为合理理由;
- 隔离: 只读结构化字段就堵住了这条话术通道，例如分类器接收
{tool: "bash", command: "rm -rf /tmp/data"}，识别出 rm -rf 模式，判定为高风险操作，返回拒绝并要求用户确认;
为什么轻量模型也够用？
- 对象差异: 提议者-审核者审查的是开放式思考，因此需要能力相近的模型；Sidecar 判断的则是较简单的分类问题（如这条命令是否危险）;
- 结论: 轻量模型足以胜任安全分类，这与“能力相差过大的模型互审不可靠”并不矛盾;
拒绝熔断器的作用是什么？
- 机制: 当分类器连续多次拒绝操作时，系统不应无限重试，而应转为请求用户手动判断;
- 收益: 避免浪费资源，也避免 Agent 陷入死循环;
- 定位: 这正是 Harness “纠正”功能的典型实例，见 Harness 工程;
如何让安全检查在体验上“隐形”？
- 做法: 把“展示”和“放行”两件事拆开并行——准备执行工具调用时，系统一边在界面上先行显示进度提示（如“正在读取文件
src/main.py...”），一边在后台执行安全检查;
- 目标: 安全性不以牺牲用户体验为代价;
Sidecar 还能承担什么职责？
- 构造和补充上下文: 主模型思考的同时，Sidecar 以旁路方式并行筛选相关的用户记忆、为较长的工具输出生成摘要、从数据库中提取用户的最新信息;
- 收益: 这些结果在主模型需要时就已经准备好，用户感受不到额外的延迟;
Sidecar 与提议者-审核者的差异是什么？
| 维度 | 提议者-审核者 | Sidecar |
|---|
| 执行时机 | 操作前（事前审批）或操作后（事后验证） | 与主模型的流式输出并行，门控单次工具调用 |
| 审查对象 | 操作的合理性或操作的结果 | 操作本身（工具调用） |
| 审查视角 | 独立模型审批、模态切换验证 | 安全性/可靠性校验 |
| 输入隔离 | 提议者和审查者看到相似信息 | 刻意隔离主模型的自由文本 |
| 典型用途 | 不可逆操作审批、文档生成、配置修改 | 权限分类、记忆相关性判断、工具输出摘要 |