一人去接杯咖啡的时间
除了烧钱，更让我心惊的是安全问题。有次我无意中瞥到终端，发现一个 Agent 在执行任务中途，竟然自作主张地想用 curl -d @.env 把我的环境变量文件发到一个外部接口。它没恶意，它只是觉得发个 debug payload 能帮它更快解决问题，而 .env 刚好是目录下信息最密集的文件。
这种“刚好被我看到”的情况，绝对不能算作一种安全模型。
现在的 AI 监控全在“事后分析”
我发现现在市面上绝大多数的 LLM 观测工具（Observability platforms）逻辑都一样：它们像监控摄像头，记录所有的 Trace、Token 数量和成本看板。
但问题是，摄像头只能在火灾发生后告诉你哪里起火了，它不能在起火瞬间把电闸拉掉。对于能直接运行 Shell 命令、读写文件系统的 Coding Agent 来说，我们需要的是“断路器（Circuit Breaker）”，而不是“记录仪”。
怎么给 AI Agent 装个“电闸”？
为了解决这个问题，我们搞了一个叫 Intutic 的本地代理（用 Rust 写的）。它的逻辑很简单：强行把自己卡在 Agent 框架（比如 Cursor, Claude Code, Windsurf, Aider 等）和执行环境之间。所有的 LLM 请求和工具调用必须经过这个代理。
具体的实现逻辑是：
1. 策略定义： 我们把安全准则写成简单的 Markdown SOP（标准作业程序），直接放在 Git 仓库里随代码版本管理。
2. 实时拦截： 代理会将这些 SOP 编译成 WebAssembly 规则，在内存中对每一个拦截到的调用进行评估。
3. 执行动作： 如果触发了红线，代理会执行四个动作之一：直接放行、静默注入防御上下文、替换参数，或者直接杀死执行线程。
为了不影响开发体验，我们将评估延迟压到了 5 毫秒以内。因为在公司推行工具时我发现，只要一个安全工具让输入产生迟钝感，程序员第一时间绝对是把它关掉。
如果是用这套逻辑，之前的 180 美金惨剧会在达到预算阈值的一瞬间被掐断，而不是等账单寄过来才发现。
实操部署
这个工具的核心是 MIT 协议开源的，对于这种拦截所有命令的工具，不开源根本没法信任。如果你们公司也在大规模使用 AI Agent，建议给它们套一层这样的代理。
安装和启动非常简单：
# 安装 CLI 和 代理服务
npm install -g @intutic/cli @intutic/proxy
# 建立连接
intutic connect在实际落地中，我建议优先配置两类 SOP：
- 预算熔断： 设定单个 Task 的最大 Token 消耗或金额上限。
- 敏感文件拦截： 严禁任何包含
.env、.pem或id_rsa的文件被作为 payload 发送至外部 API。
这种从“事后审计”转向“事前拦截”的方案，才是 AI Agent 真正进入生产环境的必要前提。
