# SAI：以评估为核心的企业级 AI Agent 框架，构建可信的自动化工作流

> 一个面向企业场景的 AI Agent 开源框架，将评估数据（Eval Data）作为一等公民，通过级联执行、人机分离的验证机制、完整的审计日志，解决 AI 自动化在生产环境中的可信性问题。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-05T18:43:55.000Z
- 最近活动: 2026-05-05T18:55:07.600Z
- 热度: 141.8
- 关键词: AI Agent, 企业级框架, 评估数据, 级联执行, 审计日志, 可信 AI, 自动化工作流, 权限管理
- 页面链接: https://www.zingnex.cn/forum/thread/sai-ai-agent
- Canonical: https://www.zingnex.cn/forum/thread/sai-ai-agent
- Markdown 来源: ingested_event

---

## 背景：个人 AI 工具的局限与企业需求

大语言模型能力的爆发催生了大量个人 AI 工具——从智能聊天助手到代码补全插件，这些工具在提升个人效率方面表现出色。然而，当企业试图将 AI 自动化引入生产环境时，面临着一系列独特的挑战：

首先是可信性问题。企业无法简单接受"AI 说完成了"这样的结论，需要有明确的证据链证明工作确实按预期完成。其次是回归风险。AI 模型的输出具有不确定性，如何确保更新后的行为不会破坏已有功能？第三是审计需求。企业环境要求所有操作可追溯、可审计，而大多数个人 AI 工具缺乏这样的机制。最后是权限管理。企业场景需要精细的权限控制，不同工作流应该拥有不同的操作权限，而不是共享同一个超级用户令牌。

SAI（Structured AI）框架正是为解决这些问题而生。它起源于康奈尔大学的一门课程项目，最初作为 RAG 版本的助教帮助学生学习编程和讨论课程材料。经过两年的迭代，逐渐演变为一个面向生产环境的个人 AI 自动化框架。

## 核心哲学：评估数据作为一等公民

SAI 的核心理念可以概括为一句话："评估数据是一等公民，而非聊天记录的附属品。"

在大多数 AI 工具中，用户的每次交互（批准、编辑、拒绝、重写）都是潜在的标注训练样本，但这些数据通常在窗口关闭后就被丢弃。SAI 反其道而行之，将每次交互都视为结构化反馈，系统性地收集、存储和利用这些数据。

这种设计的价值体现在三个层面：

**工作流完成度测量**。系统不仅记录工具是否运行，更关注工作是否真正完成。通过定义明确的完成标准和评估指标，SAI 能够客观衡量每次执行的成效。

**结果评估反馈**。用户的每次批准、编辑、拒绝和覆盖操作都被转化为结构化反馈数据，用于持续改进模型表现和工作流设计。

**设计与执行分离**。设计工作流的实体不应是评判工作流成功与否的唯一实体。SAI 通过评估数据和审计日志建立了设计者与执行者之间的制衡机制。

## 级联执行架构：成本与质量的平衡

SAI 采用级联执行（Cascade Execution）架构，在规则 → 分类器 → 本地 LLM → 云端 LLM → 人类之间建立分层决策机制：

**早期停止策略**。简单任务在早期层级（规则、分类器、本地 LLM）解决，只有复杂或不确定的情况才会上升到更昂贵的层级。昂贵的云端 LLM 和人类介入是长尾，而非默认。

**双向级联**。运行时级联向上（从便宜到昂贵），而构建时级联向下（从云端到本地）。新任务从云端 LLM 开始，随着评估数据的积累，逐步"毕业"到更低成本的层级，每次毕业都需要人工在精确率/召回率指标上批准。

这种架构让企业能够在成本和质量之间找到动态平衡，避免为简单任务支付高昂的云端 API 费用。

## 五种评估数据集类型

SAI 定义了五种具体的评估数据集抽象，每种服务于不同的验证目标：

**CanaryDataset（金丝雀数据集）**。每个规则对应一个合成案例，未通过即硬失败。用于确保基础规则始终生效。

**EdgeCaseDataset（边界案例数据集）**。记录 LLM 需要推理的真实案例，软上限 50 条强制策展。防止数据集无限膨胀导致质量稀释。

**WorkflowDataset（工作流数据集）**。捕获工作流基础设施（系统提示、正则表达式、工具连接）的漂移。确保工作流本身的稳定性。

**DisagreementDataset（分歧数据集）**。记录本地与云端模型之间的分歧，等待批量人工审核。用于识别模型间的系统性差异。

**TrueNorthDataset（真北数据集）**。无上限的历史记录，每周运行但设有硬成本上限。作为长期趋势分析的基准。

## 技能插件协议与策略门控

每个工作流在 SAI 中都以技能（Skill）的形式存在，通过 skill.yaml 清单声明：

- 身份标识（Identity）
- 触发条件（Trigger）
- 级联配置（Cascade）
- 工具清单（Tools）
- 评估要求（Eval）
- 反馈渠道（Feedback Channel）
- 输出定义（Outputs）
- 策略规则（Policy）

框架在加载时验证这些声明，缺少三种必需评估类型的技能将被拒绝注册。这种强制契约确保每个上线的工作流都有基本的可观测性和可验证性。

**策略门控（Policy Gate）**是另一项关键设计。在执行任何副作用之前，门控系统读取 YAML 策略文件进行权限检查。工人（Worker）不自行决定权限，权限决策由独立的门控层做出。这种分离降低了权限升级的风险。

## 安全与审计机制

SAI 在安全方面采取了多层防护措施：

**每工作流 OAuth 作用域**。gmail.readonly 用于分类器，gmail.modify 用于标签器，gmail.send 仅用于发送者。没有跨系统共享的超级用户令牌。

**仅现实作为真值**。层级预测从不被视为真值。即使级联中所有模型达成一致，is_ground_truth 仍为 False，直到现实确认（直接用户操作、明确的 Slack 回复、Co-Work 会话批准）。模型之间的相互同意不是信号。

**仅追加审计日志**。每个门控决策、连接器调用、批准转换、验证失败都写入 JSONL 行。"系统本周做了什么"的答案只存在于一个地方。

**哈希验证加载**。每个合并文件进行 SHA-256 校验，不匹配时失败关闭。当你看到"工作流 X 在三月份通过率为 87%"时，你知道工作流 X 在整个月都是同一个文件。

**反思建议但不自动应用**。系统可以基于评估数据提出提示词修订建议，但不能自动应用。设计面（Co-Work）和执行面（Claude Code + 运行守护进程）通过哈希和签入分离。

## 使用方式与入门路径

SAI 提供两种入门路径：

**向导模式**。克隆仓库后，在 Claude Code 或 Co-Work 中粘贴 docs/onboarding_wizard_prompt.md 的内容。向导会在约 30 分钟的会话中引导用户从零到"第一封邮件被标记"：检测平台、选择密钥后端（1Password / Keychain / 纯文本 .env）、配置 Gmail OAuth、定义第一个 L1 分类法、在 5 封真实邮件上运行冒烟测试、可选安装 launchd cron 和 sai-eval Slack Agent。

**手动模式**。克隆仓库，创建 Python 3.12+ 虚拟环境，安装依赖，配置 ~/.config/sai/runtime.env 中的密钥，运行交互式 Gmail OAuth 流程获取令牌，在 prompts/email/keyword-classify.md 中定义分类法，运行冒烟测试。

安装完成后，主要通过 Slack #sai-eval 频道（或本地 HTTP 聊天回退 http://127.0.0.1:8765）交互。命令行仅用于偶尔的检查。

## 反馈渠道与持续改进

Slack #sai-eval 频道支持操作者可调教的反馈模式：

输入"add rule: <关键词> → <分类>"或"<关键词> 应该是 <分类>"，机器人会暂存提议，用户反应 ✅ 后应用。

这种轻量级反馈机制让用户可以在日常工作中持续改进分类法，而无需深入代码或配置文件。

## 局限与未来方向

SAI 目前仍处于早期阶段，项目自述"它会崩溃"。当前实现主要围绕邮件分类场景，其他工作流类型的支持仍在发展中。

未来的发展方向可能包括：更多工作流模板（ beyond 邮件分类）、更丰富的评估可视化、多模态输入支持、更强的错误恢复机制、企业级 SSO 集成等。

## 结语：可信 AI 自动化的探索

SAI 代表了一种重要的探索方向：如何在享受 AI 自动化效率的同时，建立企业级的可信保障。它的核心洞察——评估数据是一等公民、设计与执行分离、级联执行优化成本——为个人和企业 AI 工具的设计提供了有价值的参考。

对于希望将 AI 自动化引入生产环境的团队而言，SAI 提供了一个经过深思熟虑的框架起点。它可能不会让你最快地搭建原型，但可能让你的 AI 系统运行得更可靠、更可预测、更可维护。