AI Agent 要操作你的数据库和邮件，你敢不加人审批吗？Atizar 让人提议、你批准、服务器执行
全自动 AI Agent 跑起来很爽，但一旦它开始读写你的数据库、发送邮件、操作 API key——你真的敢让它全速前进吗？
问题：全自动 Agent 的信任困境
2026 年的 AI 编码 Agent（Claude Code、Cursor、Codex）已经能自主完成复杂的开发任务。它们的工具调用能力越来越强：读取代码库、执行 shell 命令、提交 PR、调用 API。但问题也随之而来——当 Agent 开始操作有副作用的资源时，谁在把关？
一个 Agent 说要「发送这封邮件给客户」「从数据库删除这条记录」「部署这个版本到生产环境」。你当然可以事后检查，但「事后」往往已经太晚了。数据泄露、不可逆操作、误发送——这些不是假设，而是正在发生的现实。
为什么这是个真问题
两组数据说明问题规模：
- AI 编码工具让代码产出速度提升 50% 以上，但代码审查速度没有同比例提升（来源：Pyor.review 博客分析）
- 2026 年 6 月曝出的 AgentJacking 攻击（Sentry MCP 漏洞）显示，一个公开的 Sentry key 就能劫持 Claude Code、Cursor 和 Codex 的会话——Agent 的工具调用权限一旦被滥用，后果远超传统钓鱼攻击
核心矛盾是：Agent 需要权限才能工作，但全权委托在安全上不可接受。 传统的「要么全有，要么全无」授权模型在 Agent 场景下彻底失效。
传统方案的局限
| 方案 | 问题 |
|---|---|
| 完全手动操作 | 丧失 Agent 的自动价值 |
| 预定义白名单 | 太死板，无法应对动态场景 |
| 事后审计 | 不可逆操作已发生 |
| 只读权限 | 限制了 Agent 的真正价值 |
需要一个介于「全自动」和「全手动」之间的中间态：Agent 提议，人审批，服务器执行。
Atizar：开源的人机协同审批框架
Atizar 是一个开源的 TypeScript 框架（GitHub: Yaroshuk/atizar，MIT 许可），它的核心理念可以概括为三句话：
开发者构建 · 人类指挥 · Agent 执行
它不是又一个 Agent 运行时——你已经在用 Claude CLI、Mastra 或其他引擎了。Atizar 是一个审批层，叠加在你的 Agent 之上，让每个有副作用的操作都必须经过人类确认才能执行。
安装与体验
Atizar 提供了一个零凭证的在线 Demo，无需安装即可体验：
https://atizar.io/demo
如果你想本地运行，使用官方模板项目：
git clone https://github.com/Yaroshuk/atizar-demo-inbox cd atizar-demo-inbox npm install npm run demo # 启动后访问 http://localhost:5173
生产环境需要 Postgres 数据库和 LLM 提供商（Mastra 或 Claude CLI）。
核心机制：Approval Gate
Atizar 最核心的设计是 Approval Gate（审批门）。开发者定义 Agent 时，可以指定哪些工具有副作用、需要审批：
import { defineAgent } from '@atizar/core'
export const reply = defineAgent({
id: 'reply',
name: '回复邮件',
role: 'worker',
provider: 'claude-cli',
instructions: '根据最新邮件内容起草回复。',
readonly: ['get_latest_email'], // 只读操作，无需审批
tools: ['get_latest_email', 'saveDraft'],
approvals: ['saveDraft'], // 需要审批的工具
effects: ['saveDraft'], // 审批后由服务器执行
renders: { saveDraft: 'ApprovalDialog' }, // 审批界面组件
})
流程如下：
- Agent 提议：Agent 分析邮件后，提出「我建议回复：XXX，保存为草稿」
- 人审批：你在界面上看到完整的草稿内容，选择「批准」或「拒绝」
- 服务器执行：你批准后，由服务器执行
saveDraft操作——模型永远不会持有执行权限
关键区别：模型只负责「提议」，实际执行权掌握在服务器手中。即使模型被提示注入攻击，也无法绕过审批门执行有副作用的操作。
特性速览
Atizar 的价值不止于审批门。它在开发者体验和运行安全之间做了一系列权衡：
模型提议 + 服务器执行（Safe by Code）
Effect 工具绑定到服务器端函数，模型永远看不到这些函数的实现。操作通过 Action Ledger（操作账本）执行，键值对为 workItemId + gateId，保证每个操作恰好执行一次。即使模型被劫持，也无法直接触发任何副作用。
双视图设计
Atizar 提供两个独立的界面：
- 开发者视图：写 TypeScript 代码定义 Agent 和审批流程
- 操作者视图：一个干净的审批看板，只有「批准」「拒绝」「查看详情」按钮
这种设计避免了传统 Node Editor（如 n8n）的双输困境——对开发者来说太简陋（不如直接写代码），对操作者来说太复杂（只需要按钮）。
引擎无关
Atizar 通过 Provider Conformance Suite 保证运行时可互换。目前支持：
- Mastra — 生产环境路径，需要 Anthropic API Key
- Claude CLI — 开发环境，使用本地 Claude Code 订阅
- Mock — 测试环境
切换运行时只需改环境变量 PROVIDER=mastra 或 PROVIDER=claude-cli，工作流代码无需修改。
操作账本（Audit Ledger）
Agent 执行的每一步都记录在 Postgres 操作账本中。所有审批、拒绝、执行记录都有完整的时间线和上下文——合规审计时可以直接导出。
实战场景：邮件审批工作流
官方示例 Inbox 展示了一个完整的 Gmail 审批流程：
- 新邮件到达 → Agent 分析邮件内容
- Agent 自动分类（重要/垃圾/待办）并起草回复
- 每条回复进入审批队列，等待人工确认
- 审批后，服务器自动保存草稿或发送邮件
核心安全性保障：
- Agent 可以读取邮件（只读），但不能发送
- 审批界面显示完整的回复内容，让你在点击「批准」前确认
- 所有操作记录在审计日志中，随时可回溯
要将此流程连接到你自己的 Gmail，需要配置 Google OAuth 应用、Postgres 数据库和生产环境 Provider。
注意事项
- Beta 阶段：Atizar 目前处于 Beta 阶段，API 可能会有变化。框架的核心设计已验证通过，但生产环境部署需要自行评估稳定性
- Postgres 依赖：状态存储依赖 Postgres，不像纯粹的无状态 Agent 那样轻量
- 开发门槛：需要写 TypeScript 代码来定义 Agent，不适合非技术用户
- Gmail 集成需要 OAuth：连接真实邮箱需要配置 Google OAuth 应用
- 费用：框架本身 MIT 许可免费，但需要自己承担 LLM API 费用和服务器成本
同类工具定位
Atizar 与 MakerCheck、Ask-a-Human 类似都解决「Agent 审批」问题，但定位略有不同：
- MakerCheck 更侧重「Agent 不应自审批」，适用于 CI/CD 监管场景
- Ask-a-Human 是轻量级 Pager 方案，通过手机推送审批请求
- Atizar 是完整的 TypeScript 框架，提供审批看板 + 审计账本 + 引擎无关的完整方案
如果你需要深度定制的审批工作流（自定义审批界面、多级审批、完整的审计日志），Atizar 的框架级能力更有优势。
总结
AI Agent 的全自动运行模式在触及敏感操作时面临信任困境。Atizar 的「提议→审批→执行」三阶段模式提供了一个务实的中间态：保留 Agent 的自动价值，同时让人类在每个关键操作上握有最终决定权。
如果你正在构建需要操作外部资源的 AI Agent 系统（邮件、数据库、API），可以试试 Atizar 的零凭证 Demo：
- 项目主页：atizar.io
- GitHub 仓库：github.com/Yaroshuk/atizar
- 快速开始模板：atizar-demo-inbox