AI极客实战案例日报

【01】案例是什么？（普通人视角）

你公司内网现在大概跑着这些东西：几个用 Dify 或扣子搭的 Agent、十几个从 GitHub 或技能市场装来的 MCP Server 和 Skill、一台跑 Ollama 或 vLLM 的机器、还有一个"便宜的"第三方模型 API 中转。

A.I.G（AI-Infra-Guard）做的事很直白：把这些东西挨个"体检"一遍——这个 MCP Server 有没有后门？这个 Skill 会不会偷偷下载远程脚本、读你的 SSH 密钥？你内网的 vLLM 是不是某个已知 CVE 的受害者？那个便宜的中转 API 是不是"掺水"的模型？体检完给你一份带严重等级和修复链接的报告。

【02】为什么今天值得关注？

因为攻击面在过去一个月里集中爆发，而防守工具刚刚更新了一次。

• 2026-09-22，Akamai 发布《Beyond Identity: Governing the Agentic Enterprise》，指出恶意 MCP Server 可以通过提示词注入操纵 Agent 决策，且攻击可跨多个已连接的 Server 横向扩散；报告同期的行业数据是：一个月内出现 68 个 MCP Server 相关 CVE，审计发现 91.8% 的 MCP Server 缺少基本认证控制。五眼联盟的 Agentic AI 采纳指南、新加坡的 Agentic AI 治理框架，都已经把最小权限与监控列为基线要求。
• BlueRock Security 分析 7000+ 个 MCP Server，报告约 36.7% 存在疑似 SSRF 风险；OX Security 在 2026-04-15 披露 Anthropic MCP 参考实现的 STDIO 执行模型在设计上允许任意命令执行，累计影响下载量被报道超过 1.5 亿次。
• Cisco《State of AI Security 2026》报告称，只有约 29% 的组织准备好了把 agentic AI 投入生产——攻击面在扩，防守能力没跟上。
• 供给端也在变：2026 年 10 月 1 日 12:09（北京时间），AI-Infra-Guard 发布 v4.6.4，新增了提示词注入研究工具包 pikit（Research/pikit），并修复了 Skill-Scan 的推理强度透传问题。

说白了：以前企业的 AI 安全问题还是"要不要上 Agent"，现在变成了"我内网已经跑着 20 个我不知道能不能信的东西"。这件事第一次有了成熟的开源解法。

【03】案例的前世今生

前世（2019 → 2024）｜从"AI 攻防研究"到"扫公开的 AI Web 组件"
项目出自腾讯安全平台部朱雀实验室（2019 年成立，专注 AI 安全实战攻防）。2024-12-25 开源时，A.I.G 的定位还是一个基础设施漏洞扫描器：那个年代大量 Ollama、ComfyUI、vLLM 实例被直接暴露在公网，很多人把 Ollama 的 11434 端口当成"本地服务"其实全互联网都能访问。A.I.G 做的事就是识别组件指纹、匹配 CVE、告诉你该升级了。它最早的问题不是"Agent 不安全"，而是"AI 服务在裸奔"。

发展（2024 → 2026）｜攻击面每长一层，它就长一个模块
从官方 CHANGELOG 能看到一条非常清晰的能力扩张线：
① Agent 出现（企业开始用 Dify / Coze 编排 Agent）→ 新增 Agent Scan，一个独立的、多 Agent 自动化扫描框架，可对 Dify、Coze 上运行的 Agent 工作流做黑盒安全评估（v4.5.1 加入 5 个 OWASP 检测技能与 Web 数据外传检测）。
② MCP 出现（Agent 开始连外部工具）→ 新增 MCP-Scan，支持源码和远程 URL 两种输入，v4.5.2 加入"动态模式工具白名单防 RCE"，v4.6.1 加入"标记空/不完整扫描结果、上下文压缩时保留安全发现"。
③ Agent Skills 出现（Anthropic Skills 之后，技能变成可分发资产）→ 新增 Skill-Scan + SkillTrustBench，并提出了 T01–T09 九类技能安全风险分类法（指令劫持、记忆投毒、远程载荷下载执行、内嵌恶意代码、提权、系统驻留、工具劫持伪装、不安全依赖、不安全编码）。v4.5.2 加了 .pyc 字节码绕过检测和字符集走私防御，v4.6.2 减少无证据误报。
④ 模型 API 转售出现（"便宜的中转"）→ 新增 模型与 API 中转检测（模型指纹、Claude 签名校验、中转黑盒审计、PAMELA、Ventor QTest），v4.6.0 加入 API 投毒检测。

今生（2026-10-01）｜为什么现在值得关注
v4.6.4 本身是一个小版本，但把它放回上面这条线里看，信号很明确：这个项目的重心已经从"扫基础设施"整体迁移到"扫 Agent 供应链"。新增 pikit 说明它在往"提示词注入"这个最底层的攻击面补研究能力。同时它把能力做成了可以在 CI/CD 里跑的命令行工具（pip install aig-skill-scan）和对 Agent 友好的 ClawHub 技能（clawhub install aig-scanner）——也就是说，安全扫描不再是"上线前找安全部门评估一次"，而是可以塞进流水线、塞进 Agent 自己。

下一步可能怎么发展（分析 / 推演，非事实）
基于已观察到的事实可以推测三条路：① 与企业 CI/CD、镜像仓库、技能市场打通，做"发布即扫描"的准入闸门；② 从"扫描器"演进为"运行时护栏 + 扫描"的组合（README 里已出现 docs/api-checker-integration.md 提到的"Agent 嵌入式运行时架构"，说明运行态是他们在考虑的方向）；③ SkillTrustBench 这类基准可能被安全审计方引用为验收参照，进而把"AI 资产清单"变成合规交付物。以上均为推演，不代表产品路线。

【04】原始资料（均为具体页面）

• GitHubgithub.com/Tencent/AI-Infra-Guard（主仓库）
• Releasev4.6.4 发布页（2026-10-01T04:09:31Z）
• 中文READMEreadme/README_ZH.md
• ChangelogCHANGELOG.md
• 官方文档tencent.github.io/AI-Infra-Guard（含快速开始 / FAQ）
• 子工具skill-scan · mcp-scan · agent-scan
• 基准SkillTrustBench 排行榜 · ClawScan · AI 安全技能市场
• 健康信号Black Hat EU 2025 Arsenal 收录
• 行业背景Akamai 报告解读（2026-09-22） · MCP Server 安全实践与真实 CVE 复盘

【05】作者是谁？

腾讯安全平台部朱雀实验室（Tencent Zhuque Lab）主导开发，企业内部团队而非个人。官方 README 自述：实验室 2019 年成立，方向覆盖大模型安全、AI 智能体安全、AI 赋能安全与 AI 生成检测；曾协助英伟达、谷歌、微软等厂商，以及 OpenClaw、Linux、Hugging Face 等开源社区修复漏洞并获得公开致谢。

v4.6.4 这一个版本的贡献者在 Release 页明确列出：Elwood Zonghao Ying（NY1024）、Patrick Erichsen。仓库规模：6,669 Star、627 Fork、Apache-2.0、Python 为主（配套 CLI 为 Go）。

【06】解决了什么真实问题？

从用户与企业的处境说，不是从技术说。今天一个中国企业的技术负责人被问到的问题通常是这样的：

• "我们内网连了 14 个 MCP Server，谁批准的？每个能读什么数据？"（有没有清单）
• "同事从技能市场装的那个 Skill，会往外发数据吗？"（技能可信吗）
• "我们那台 vLLM / Ollama / ComfyUI 有已知漏洞吗？"（组件安全吗）
• "这个便宜的中转 API，真是它宣称的模型吗？"（有没有掺水）
• "我们让 Agent 跑了半年业务，出过越权行为吗？"（Agent 本身抗不抗得住）

传统安全工具链不覆盖这一层：漏扫扫的是主机和 Web 应用，SAST 扫的是你写的代码，供应商尽调走不到"第三方 MCP 连接"这一层——这正好是一个供应链盲区。A.I.G 把上面五问压缩成几次点击。

【07】完整技术栈

语言 / 协议	Python（扫描引擎、大量检测技能）；Go（统一 CLI cmd/cli/main.go）；Apache-2.0
部署	Docker 20.10+，要求 4GB+ 内存、10GB+ 磁盘；Web 界面 http://localhost:8088；API 文档 /docs/index.html（Swagger）
镜像	Docker Hub 预构建镜像 zhuquelab/aig-server；也可源码构建（docker-compose up -d）
CLI 工具	pip install aig-skill-scan（可进 CI/CD）；aig-skill-scan --repo <目录> -m <模型> --language zh -o result.json
可接入模型	需自备 LLM API Key（LLM_API_KEY）。官方基准覆盖 Claude Opus 4.6、GLM 5.1、Gemini 3.5 Flash、Kimi 2.6、DeepSeek v4 Flash
Agent 生态	ClawHub 技能：aig-scanner、EdgeOne ClawScan、EdgeOne Skill Scanner；配置 AIG_BASE_URL 即可被任意 Agent 调用
插件规则库	data/fingerprints/（组件指纹） · data/vuln/（CVE 规则） · data/mcp/（MCP 安全规则） · data/eval/（模型评测集）
漏洞覆盖	2000+ CVE 规则；100+ AI 开源 Web 组件，含 Ollama、ComfyUI、vLLM、n8n、Triton Inference Server、LangFlow、PraisonAI、llama-cpp、MLflow 等
数据库	官方 README 未披露具体数据库选型——不编造

【08】完整 Workflow

【09】它到底是怎么实现的？

核心是"指纹库 + 规则库 + LLM 语义判定"的三层结构，而不是让模型去"猜有没有漏洞"。这样设计的好处是：确定性的问题（版本号对 CVE）用规则解决，语义性的问题（这段 Skill 指令是不是在劫持 Agent）才交给模型。

• 基础设施扫描是纯指纹 + 版本比对：连上服务、识别组件与版本、匹配 2000+ CVE 规则。输入是"运行中的网络地址"而不是代码仓库——这是官方 FAQ 特意强调的，也是最容易填错的一栏。
• Skill-Scan把"技能安全"拆成可分类、可评测的九类风险（T01–T09），这意味着它的判定标准是对外公布、可对标的，而不是黑箱。检测目标包括 .pyc 字节码绕过和字符集走私（v4.5.2 加入）。
• MCP-Scan最关键的设计是"动态模式工具白名单"：因为 MCP 的本质是"执行 OS 命令"，如果扫描器不加约束地按 MCP 描述去调用工具，扫描行为本身就可能变成一次 RCE。
• Agent-Scan不走静态分析，而是一个多 Agent 自动化扫描框架：用多个 Agent 去黑盒测试另一个 Agent 的工作流，检测 OWASP 类风险与 Web 数据外传。这是"用 Agent 测 Agent"。
• API 中转检测（模型指纹 + Claude 签名校验 + 黑盒审计）解决的是一个非常中国的问题：市面上大量"便宜的中转 API"，需要验证它给你的到底是不是它宣称的模型。

所以它"能工作"的原因不是模型强，而是先建规则、再上模型：把已知的、可枚举的风险沉到 YAML 规则库里（社区可通过 PR 贡献 data/mcp/ 规则），把需要语义理解的部分留给 LLM。

【10】手把手复现

以下命令来自官方 README（作者原始步骤），非推导：

# Step 1 · 拉取仓库
git clone https://github.com/Tencent/AI-Infra-Guard.git
cd AI-Infra-Guard

# Step 2 · 用预构建镜像启动（Docker Compose V2+ 把 docker-compose 换成 docker compose）
docker-compose -f docker-compose.images.yml up -d

# 或者：一键安装脚本（会自动装 Docker 并启动）
curl https://raw.githubusercontent.com/Tencent/AI-Infra-Guard/refs/heads/main/docker.sh | bash

# Step 3 · 打开 Web 界面
# http://localhost:8088

# Step 4 · 场景 A：扫本地 vLLM / Ollama 的已知漏洞
#   先正常启动 vLLM，界面点「AI基础设施安全扫描」，
#   目标填 http://127.0.0.1:8000（vLLM 实际监听的 IP:端口），开始扫描
#   批量扫一段网段就填 192.168.1.0/24 或 10.0.0.1-10.0.0.20

# Step 5 · 场景 B：扫一个 MCP Server / Agent Skill（不需要把服务跑起来）
#   目标框填 GitHub 仓库地址，例如 https://github.com/user/mcp-server
#   或直接上传本地源码压缩包

# Step 6 · 把 Skill 扫描接进 CI/CD（可选，命令行）
pip install aig-skill-scan
export LLM_API_KEY="your-api-key"
aig-skill-scan --repo /path/to/your/skill \
           -m deepseek-v4-flash \
           --language zh \
           -o result.json

【11】Prompt / Code / Config

官方未公开扫描用的 Prompt。可确认公开的部分：

• 命令行参数（原文公开）：--repo 指定本地目录、-m 指定判定模型、--language 指定报告语言、-o 指定输出文件。
• 插件规则格式（原文公开）：指纹规则放 data/fingerprints/，漏洞规则放 data/vuln/，MCP 规则放 data/mcp/，评测集放 data/eval/，均为可 PR 贡献的声明式文件。
• Agent 调用配置（原文公开）：clawhub install aig-scanner 后设置环境变量 AIG_BASE_URL 指向运行中的 A.I.G 服务。
• 本文推导（明确标注）：把 aig-skill-scan 接进 CI/CD 时，建议以 result.json 中严重等级作为流水线门禁条件——这是复现建议，不是官方给出的集成方案。

【12】踩坑

来自官方 README/FAQ 与 CHANGELOG 可确认的点：

• 最经典的错误：填错扫描目标。基础设施扫描要填"正在运行的 AI 服务的网络地址"，不是 GitHub 链接、也不是源码路径。很多人第一次会把 https://github.com/... 贴进去，然后发现识别不出组件。
• 扫描需要自备 LLM API Key。Skill-Scan 的语义判定依赖模型（LLM_API_KEY），没有 Key 时能力受限。
• 不要在公网部署。项目暂无鉴权机制，暴露在公网等于把"内网 AI 资产地图"公开。
• 误报是需要持续对抗的。v4.6.2 的 release note 本身就在修"减少无证据误报"、"避免流式响应卡死"——说明早期版本有误报和卡死问题，建议直接用最新版。
• 扫描结果为空要警惕。v4.6.1 专门加了"标记空/不完整扫描结果"的能力，也就是说：扫描没报错不等于扫全了，可能是连接失败。这一点在做安全验收时特别致命。

【13】中国用户能不能直接做？

国内访问	🟢 可以——GitHub 仓库 + Docker Hub，官方文档站国内可达；拉镜像慢时可用国内镜像加速
注册	🟢 不需要注册。在线 Pro 版（aigsec.ai）需要邀请码，优先给提交过 Issue/PR 的贡献者；开源版功能已足够自查
API	🟡 需要自备一个 LLM API Key（用于 Skill/Agent 的语义判定）
成本	🟢 软件 0 元（Apache-2.0）。硬件要求 4GB+ 内存 / 10GB+ 磁盘。若跑本地模型判定则需额外显存；用 DeepSeek / GLM / Kimi API 则按量计费
技术门槛	AI 用户级 会 Docker 就能用；技能扫描 CLI 需要 Python 环境

【14】国产替代方案

这个案例不需要"国产替代"——它本身就是国产、官方、中文优先。真正值得看的是模型侧的国产化：

原方案默认	官方基准里最强的是 Claude Opus 4.6（F1 0.9848）
国产方案 ①	GLM 5.1：F1 0.9836，Recall 0.9974 与 Opus 4.6 并列最高 —— 官方基准，已验证可跑（README 直接列出）
国产方案 ②	Kimi 2.6：F1 0.9780 / Precision 0.9895 —— 官方基准，已验证可跑
国产方案 ③	DeepSeek v4 Flash：F1 0.9740 / Precision 0.9868 —— 官方 README 的 CLI 示例里就用了它（-m deepseek-v4-flash），已验证可跑
海外同类	Cisco MCP Scanner（已引入行为级代码威胁分析）、Driftcop（仓库级 rug-pull 变更检测）、Code Scalpel —— 属理论替代/同类，本次未验证其国内可用性

【15】中国企业可以怎么用？

• 企业场景 1｜电商 / SaaS 研发团队：上 AI 功能前的准入闸门。把 aig-skill-scan 接进 CI，任何新引入的 MCP Server、Agent Skill 合并前先扫一遍，命中高危直接卡住。解决的是"工程师图方便随手 npx -y 装了一个来路不明的 MCP"这个最现实的漏洞。
• 企业场景 2｜金融 / 政企：内网 AI 资产盘点 + 组件漏洞基线。用 CIDR 批量扫一段内网，一次性拿到"跑着哪些 AI 组件、各是什么版本、命中哪些 CVE"的清单。这正好对应合规审计里最难答的那道题：你的 AI 资产清单在哪。
• 企业场景 3｜AI 服务采购 / 转售：验真。用模型指纹与 API 中转检测，验证供应商提供的"某模型服务"是否真身，避免采购到掺水或带后门的 API。对做 AI 应用集成的公司，这是采购环节的尽调工具。

【16】中国消费者可以怎么用？

1. 装 MCP / Skill 之前先扫一遍。个人开发者在 Claude Desktop / Cursor / TRAE 里装 MCP Server 前，把仓库地址丢进去扫一次。成本几乎为零，收益是避免"用一个 npm 包换来一把被偷的 SSH 密钥"。
2. 给自己的 Dify / 扣子工作流做体检。Agent Scan 明确支持 Dify 和 Coze——你搭的企业知识库问答、客服 Agent，可以跑一次安全评估，看看会不会被提示词注入诱导去调用不该调用的工具。
3. 别让本地 AI 服务裸奔。如果你在家里的机器或云主机上跑 Ollama / ComfyUI，用基础设施扫描确认一下有没有暴露在公网、有没有已知 CVE。

【17】如何变成一个赚钱的项目？

• 产品化：面向中小企业的"AI 资产安全体检"轻量 SaaS / 私有部署包——企业填内网地址，出报告，订阅制。技术底座已经开源，你补的是报告美化、工单联动、周期复扫。
• 服务化：AI 安全审计交付服务。企业不想自己部署和维护时，卖"交付一份可提交审计的 AI 资产清单 + 风险处置建议"。
• 咨询化：帮企业设计 Agent 最小权限体系、MCP 准入白名单、Skill 供应链评审流程。这是"制度设计"层，价格比工具高。
• 培训化：企业对开发/运维团队的"AI Agent 供应链安全"内训，用 A.I.G 现场扫真实的 MCP Server 演示攻防。
• 内容化：把"MCP 供应链攻击"这个 2026 年最新的话题做成系列内容——真实 CVE 复盘（mcp-server-git、伪装 Postmark MCP、MCP Inspector RCE）、Skill 恶意分发案例，天然具备传播力。
• 行业化：金融、医疗、政企对 AI 合规的要求差异很大，可以做成行业专属的检查清单 + 报告模板。

【18】变现路径

路径	客户	产品 / 服务	收费方式	难度
AI 安全审计服务	中大型企业	AI 资产清单 + 风险报告交付	项目制	中
私有化部署 + 运维	金融 / 政企	内网部署包 + 周期复扫	年费 / 订阅	中
CI/CD 安全守门	研发型公司	扫描 CLI 集成实施	项目制 + 维护费	中
企业内训	企业技术团队	Agent 供应链安全 Workshop	按场 / 按人	低
内容 / IP	开发者 / AI 从业者	MCP 安全攻防专栏、课程	订阅 / 单课	低

※ 本表为基于案例结构的商业模式分析，不是收益保证。安全类项目普遍存在"交付周期长、依赖信任背书"的特点，个人承接时建议先从培训与内容切入。

【19】如果我是一个中国独立开发者（7 天 MVP）

前提：1 人、预算有限、有基础编程能力、使用国产模型。目标不是重做一个扫描器（那是以卵击石），而是做一个"扫描结果的翻译层"。

Day 1	用 Docker 跑起 A.I.G，拿 3 个公开 MCP Server 仓库做一遍 Skill/MCP 扫描，把 result.json 的字段结构摸清。产出一份"我看到的输出长什么样"。
Day 2	写一个报告转换器：把 result.json 渲染成中文的、老板能看懂的一页报告（资产清单 / 高危项 / 影响面 / 修复建议）。技术栈随意，Python + 模板即可。
Day 3	接国产模型（DeepSeek 或 GLM）做"修复建议的人话化"与"风险优先级排序"，输出到 Markdown/PDF。
Day 4	做一个最简 Web 表单：上传 GitHub 链接 → 出报告链接。不做账号体系，用一次性链接。
Day 5	写 3 篇内容：①"我扫了 10 个热门 MCP Server，5 个有问题"（脱敏真实结果）；②MCP 供应链攻击的真实 CVE 复盘；③一份可下载的《企业 MCP/Skill 准入检查清单》。
Day 6	把链接发到 3 个地方：掘金/公众号、AI 开发者社群、MCP 相关 GitHub Issue/Discussion。目标是拿到 10 份真实扫描需求（免费）。
Day 7	拿这 10 份真实需求复盘：谁在担心什么、愿不愿意为"一份能交给领导的报告"付 199 元。据此决定是做工具还是做服务。

【20】如何迁移到其他行业

【21】培训课程设计

【22】培训师点评

【23】最终判断

※ 以上是案例属性描述，不是"最佳案例排名"。变现"中高"而非"高"，原因是安全类服务的成交强依赖信任背书与交付资质，个人开发者更现实的切入点是培训与内容。

【01】案例是什么？（普通人视角）

一个 n8n 工作流，插到你的收件箱上自动干活：每来一封邮件，先判断它属于哪一类（销售线索 / 客服求助 / 发票账单 / 垃圾邮件），再把关键字段抽出来（姓名、公司、金额、单号、紧急程度、截止日期……）。

然后按类别动作：是销售线索 → 自动生成一封回复草稿发给老板；是高优先级客服 → 发一条告警（Telegram）；是发票或垃圾 → 只记录不打扰。每一封都落一行 CSV（可选写 Google Sheets），最后返回一个运行摘要（处理了多少封、平均耗时）。

模型跑在本机——Ollama 上的 qwen3.5:9b，模型文件约 6.6GB。不花 API 钱，邮件内容也不出本机。

【02】为什么今天值得关注？

• 因为这是最好的教学样本（时间线需要说清）：项目仓库 2026-09-29 首次提交（GitHub 创建时间 2026-09-29T13:13:52Z，最后推送 2026-09-29T20:25:07Z），评测数据的日期标注为 2026-09-29；而它的社区验证讨论发生在 10 月 1 日前后（n8n 官方社区帖，抓取时显示"1 天前"发布，帖子内 3 条回复的时间戳在抓取时分别为 17 小时前、14 小时前、2 小时前）。也就是说：这是一个刚落地两天、正在被公开工程审查的案例。收录它的理由不是"它很新"，而是"它正在被同行按生产标准挑刺"。
• 因为"小模型够用"这个判断第一次有了可复现数据：6.6GB 的本地 9B 模型，在 60 封邮件的评测集上拿到 98.3% 分类准确率、精确字段抽取 95.6%。对中小企业来说，这意味着"AI 自动化"的成本可以从"每月 API 账单"降到"一台有显卡的机器"。
• 因为社区审查的内容本身就是干货。回复者提出的四点全部指向生产真实问题：①只报总体准确率没有意义，"把真线索误判成垃圾邮件"的代价远高于反向误判，应该公开混淆矩阵和 per-class precision/recall；②需要一个 "needs review"（待人工复核）类别，而不是强迫每封邮件落进四个桶；③低置信度应该进人工队列；④记录模型版本 + Prompt/Schema 哈希才能让 98.3% 这个结果可复现。作者当场回应：会补 per-class 指标、会加 needs review 队列、会把修正样本回灌进评测集。这是一次罕见的高质量公开工程对话。
• 因为提示词注入的防护在实战层面被验证了。评测集里专门有 4 封 prompt_injection 标签的邮件，工作流 12/12 通过。这跟今天另一个案例（AI 供应链安全）形成同一主题的两端：一边是理论上的攻击面，一边是工作流里真实做出来的防护。

【03】案例的前世今生

前世（规则时代）：收件箱分诊从来不是新需求。最早的解法是邮件规则和关键词黑名单：主题含"发票"就归档，来自某域名就标星，含"退订"就丢垃圾箱。问题是它只能抓字面，抓不了语义——"想问一下你们的报价"是销售线索还是客诉？"这个账单好像不对"是客服还是发票？规则会越写越长、越写越脆，而且完全不能定制业务语义（比如"高价值线索"在你公司到底怎么定义）。

发展（三个改进方向）：LLM 变便宜之后，所有人第一反应是"直接喂给模型分类"。然后撞上三堵墙，而这个项目的历史价值就在于它把三堵墙都记住了：
① 成本与单点故障墙——每一封邮件都是一次 API 调用，量一大就是账单；主模型返回 429/5xx 整个流程直接崩。于是出现"模型级联 / 降级路由"这一派（在 n8n 里做 Claude → GPT-4o → DeepSeek 三级降级，用 Continue On Fail 改错误处理、每次 8 秒超时、失败立刻切换而不是重试）。
② 输出格式墙——模型返回自然语言，下游节点解析不了。于是出现"结构化输出 + Schema 校验 + 失败带错误回灌重试"这一派。
③ 数据出境墙——邮件里有客户信息，很多公司不能发到外部 API。于是出现"本地小模型"这一派。

今生（为什么现在值得关注）：这条路线的三个分支第一次合流了。Qwen3.5:9b 这类 6.6GB 的本地模型，质量已经足够做结构化分类与抽取（评测 98.3%）；n8n 提供了可视化编排 + Code 节点做 Schema 校验 + 方便的降级与重试；两件加起来，把"零 API 成本 + 数据不出本机 + 输出可控"同时做到了。更关键的是作者没有停在"我跑通了"，而是做了 60 封合成邮件的评测集、标了 4 类困难样本（ambiguous 8 封、missing_info 8 封、prompt_injection 4 封、mixed_language 4 封）、跑了 3 轮、写了完整评测报告——这是"能跑"和"可交付"之间的分水岭。

下一步可能怎么发展（分析 / 推演，非事实）：① 按社区反馈补上 per-class 指标与 needs review 队列后，这个模式会更容易被企业接受为"可审计的自动化"；② 路由规则从 n8n 转移到可配置的策略层（而不是硬编码），才能卖给不同行业；③ 本地模型可换成更强的国产模型（Qwen 系列新版本、GLM、MiniMax）或走混合路由；④ 云端收件箱（Gmail）之外，国内更可能是企业微信 / 飞书 / 钉钉 + 企业邮箱的接入方式。以上均为推演。

【04】原始资料（均为具体页面）

• 社区原文n8n 官方社区帖：AI email triage in n8n: 98.3% accuracy on 60 test emails, runs free on a local model（作者 Efe_Alkan 发帖，讨论区含 3 条工程审查回复）
• GitHubgithub.com/alkanefe22/ai-inbox-triage（MIT，2026-09-29 创建）
• 评测报告eval/report.md（混淆矩阵、逐字段/逐标签准确率、提示词注入明细）
• 工作流 JSONworkflows/inbox-triage.json · 构建脚本 scripts/（含 scripts/prompts/）
• 数据集data/emails.json（60 封） · data/labels.json（标注；工作流永不读取）
• 商业线索README 顶部链接到 Gumroad 上的 "AI Inbox Triage Pro" 预配置包（含 Gmail/Sheets/Telegram 预配置、额外 Prompt 变体与安装指南）
• 对照参考n8n 多模型降级路由（Claude 3.5 / GPT-4o / DeepSeek V3 failover）构建指南（DEV Community，同一问题域的另一条路线）

【05】作者是谁？

Efe Alkan（GitHub alkanefe22，n8n 社区 Efe_Alkan）——独立开发者 / 自动化实践者，本人就是项目作者与评测执行者，属一手来源。README 的测试环境自述为 Windows 11 + Docker Desktop + NVIDIA RTX 5080（16GB）。许可证：MIT © 2026 Efe Alkan。

需要如实说明：该仓库当前 Star 数为 0，是刚上传的新项目，不是"热门项目"。收录它的理由是完整的实现、评测与讨论，不是热度。

【06】解决了什么真实问题？

从人的处境开始说。小团队和个体户最典型的一天是这样的：早上打开邮箱，40 封未读，里面有 3 封是真询盘、2 封是客户在发火、1 封是发票要到期、其余是营销邮件。你得先花 20 分钟把它们分开，才能开始干活。而"分开"这件事不需要创造力，只需要判断力——这恰好是模型最擅长、人也最容易疲劳的部分。

企业侧的问题更具体：线索响应时效。跨境询盘从收到到回复超过几小时，成交率就明显下降；而漏掉一封高优先级客诉，代价远大于多处理十封垃圾邮件。所以这个案例真正解决的，不是"AI 很酷"，而是"让每一封有价值的邮件在 2 秒内被识别并推给对的人"。

【07】完整技术栈

模型	Ollama qwen3.5:9b（约 6.6GB；官方评测只验证过这一个模型，其他 Ollama 模型可跑但未评测）；或 Google Gemini（已实现，但官方明确"未做基准测试"）
推理参数	temperature = 0；输出强制 JSON schema
编排	n8n（Docker 部署，编辑器 http://localhost:5678，Webhook 入口 /webhook/inbox-triage）
语言 / 运行时	JavaScript（n8n Code 节点做 Schema 校验）；Node.js 18+（仅用于 npm run 辅助脚本，无 npm 依赖需要安装）
运行环境	Docker Desktop + WSL 2 引擎（Windows 需 BIOS/UEFI 开虚拟化，启用 Virtual Machine Platform 与 WSL）；Linux/macOS 对应命令在 README 中分别给出
输出	output/results.csv（每次运行覆盖）→ 可选 Google Sheets；Webhook 返回运行摘要
通知	Telegram（线索回复草稿 + 高优先级客服告警）
可选输入	Gmail Trigger 节点（默认关闭，需自建 Gmail OAuth2 凭据并手动启用）
MCP	本案例未使用 MCP——不编造

【08】完整 Workflow

以下结构直接译自作者 README 中的 flowchart LR 架构图（原文公开）：

【09】它到底是怎么实现的？

这个案例的价值几乎全在四个设计决策上，作者在 README 里明确列了其中三条：

1. 职责分离（原文："The model only classifies and extracts; routing rules live in n8n, not in the prompt"）。模型只做两件事：判断类别、抽取字段。所有"如果是线索就……"的路由逻辑全部写在 n8n 的 Switch 节点里，不写进 Prompt。这一条决定了整个系统能不能维护——改业务规则不需要重调 Prompt、不需要重新评测模型，只改编排图。
2. 输出 Schema 校验 + 一次性回灌重试（原文："Output is schema-checked and retried once with the error fed back"）。模型输出要过 Code 节点的结构校验；不合法时，把具体的错误信息回灌给模型让它改一次。注意是"1 次"而不是"循环重试"——因为在实时链路上无限重试等于无限等待。校验最终失败就老老实实记 status=error，并且在计算准确率时把它算作错误（作者明确说明），这是一个很诚实的评测口径。
3. 提示词注入防护（原文："Email content is treated as data"）。邮件正文被当作数据处理而不是指令处理，评测集里专门放了 4 封注入邮件，结果 12/12 通过。注意这是作者自述的评测结果，本次未独立复现。
4. 可复现的评测管线。npm run eval 会触发 webhook 三次（{"dry_run": true}，跳过回复草稿/Telegram/Sheets），对每次产生的 results.csv 打分，输出 eval/results/ollama.json、eval/report.md 与逐轮 CSV。评测集 60 封英文合成邮件，四类各 15 封，标注在 labels.json，工作流从不读取标注文件——这一点很重要，它排除了"答案泄漏"。

还有一个容易被忽略的工程细节：整个 JSON 输出契约由 LLM 节点保证，跨 provider 一致。因为 ollama 和 gemini 的返回包装格式不同，Schema 校验节点实际上承担了"输出归一化"的职责，让下游 Switch 节点不必关心用哪个模型。这正是"换模型不改下游"的关键。

【10】手把手复现

以下命令与流程来自作者 README 原文（作者原始步骤）：

# Step 1 · 准备环境
#   - Docker Desktop（WSL 2 引擎；Windows 需 BIOS 开启虚拟化 + 启用
#     Virtual Machine Platform 与 Windows Subsystem for Linux）
#     Windows 管理员 PowerShell 一条命令同时开启：wsl --install --no-distribution（之后重启）
#   - Node.js 18 或更新（只用于 npm run 辅助脚本，无依赖要装）
#   - Git
#   - 宿主机运行 Ollama，并拉取模型（约 6.6GB）：
ollama pull qwen3.5:9b

# Step 2 · 配置 .env（修改后必须重新 up，restart 不会重载 .env）
docker compose up -d

# Step 3 · 部署工作流（从 scripts/build-workflow.js + scripts/prompts/ 构建，
#          导入容器、发布、重启 n8n，并导出版本到 workflows/inbox-triage.json）
npm run workflow:deploy
#   之后每次改工作流源码都要重新执行这一步
#   n8n 编辑器：http://localhost:5678（首次访问需创建 owner 账号，仅编辑器需要）

# Step 4 · 跑起来（Windows PowerShell）
Invoke-RestMethod -Method Post -Uri http://localhost:5678/webhook/inbox-triage `
  -ContentType 'application/json' -Body '{"limit": 5, "dry_run": true}'

# Linux / macOS：
# curl -X POST http://localhost:5678/webhook/inbox-triage \
#   -H 'Content-Type: application/json' -d '{"limit": 5, "dry_run": true}'
# 结果写到 output/results.csv（每次运行覆盖）

# Step 5 · 完整演示（前 17 封，开启全部动作：回复草稿 / Telegram / Sheets）
npm run demo
npm run demo -- --limit 5      # 跑更少

# Step 6 · 复现评测（3 轮，写出 eval/results/ollama.json 与 eval/report.md）
npm run eval -- --provider ollama --runs 3

# Step 7（可选）· 接真实 Gmail
#   在编辑器里打开工作流 → Gmail Trigger 节点 → 创建 Gmail OAuth2 凭据 → 启用节点并发布

Webhook 参数（原文公开）：limit 只处理前 N 封；dry_run=true 跳过回复草稿/Telegram/Sheets（评测就用这个）；provider 本次运行临时指定 ollama 或 gemini；gemini_delay_ms 本次运行的 Gemini 调用间隔。

【11】Prompt / Code / Config

Prompt 位置	公开在 scripts/prompts/（工作流由 scripts/build-workflow.js 从这些文件构建）——作者公开
Prompt 正文	本次未逐字提取；建议直接查看仓库 scripts/prompts/ 目录获取原文，避免二手转述失真
工作流定义	workflows/inbox-triage.json（每次 workflow:deploy 重新导出）——作者公开
配置样板	.env.example——作者公开
评测脚本	eval/ 与 scripts/ 内的评测与演示工具——作者公开
本文推导	第七节的"迁移建议"与第十节的"换成本地样本重跑基线"属本文复现建议，非作者原文

【12】踩坑

• 改 .env 后 docker compose restart 无效。README 明确写了：必须重新 docker compose up -d 重建容器，restart 不会重载 .env。这是最常见的"改了配置不生效"。
• Windows 环境门槛比想象中高。需要 BIOS/UEFI 开虚拟化，并启用 Virtual Machine Platform 与 WSL 两个 Windows 功能；作者给出的快捷命令是 wsl --install --no-distribution（管理员 PowerShell），装完要重启。
• Gmail 触发器拿到的是 snippet 不是全文。在节点的 simple 模式下，正文是 Gmail 的短摘要，不是完整邮件文本——这会直接影响抽取质量。需要完整正文时要改用 full 格式。
• 语义类字段是最大的短板。精确字段（姓名、公司、金额、币种、发票号、紧急度、截止日期）准确率 95.6%，但柔性字段（need / topic / budget / timeline）只有 73.3%。评测口径是：need/topic 需要去掉停用词后词集 Jaccard ≥ 0.5 才算对，budget/timeline 需要归一化文本或数字集合完全相等。也就是说——"这封邮件想要什么"和"预算多少"这两件事，9B 本地模型还不可靠，这两栏如果要用在业务上，必须加人工确认。
• 3 轮评测"完全一致"不等于稳定。作者自己在报告里澄清了：temperature 0 下三次运行返回了完全相同的答案，所以 min/max/mean 相等，但这三次不是独立样本，只能说明结果稳定，不能当作统计置信度。
• 评测数据的局限要认清。60 封是合成英文邮件（15/15/15/15），中等难度样本包括 ambiguous 8 封、missing_info 8 封、prompt_injection 4 封、mixed_language 4 封（土耳其语/英语混合）。没有中文样本，没有真实业务邮件。
• Gemini 路径没有基准数据。作者明确写了 gemini 分支"已实现但未做基准测试"。所以"本地模型 vs 云模型"的对比目前无数据可比。
• 开源版是简化版。README 顶部把"预配置好 Gmail/Sheets/Telegram、附带额外 Prompt 变体与安装指南"的版本放在 Gumroad 上作为 Pro 包——这意味着开源仓储里的一些便利配置是有意留白的。

【13】中国用户能不能直接做？

国内访问	🟢 n8n 可自托管（国内完全可用）；Ollama 与 Qwen 模型国内可正常下载；GitHub 访问视网络情况
注册	🟢 n8n 自托管不需要任何账号；Ollama 不需要账号；全流程无第三方注册
API	🟢 完全不需要外部 API Key（这是本案例对中国用户最大的价值）。前提是有一台能跑 6.6GB 模型文件的机器
成本	🟢 0 元方案可行：n8n 开源 + Ollama + Qwen3.5:9b 全部免费。唯一"成本"是本机算力（作者测试机为 RTX 5080 16GB；9B 量化模型在更小的显卡上也能跑，但速度会下降——具体下限未验证）。若改用云模型则按量计费
技术门槛	AI 用户级 需要会 Docker 与基本命令行；不用写代码（工作流是可视化的），但需要理解 JSON 与 Schema 概念

【14】国产替代方案

原方案的模型	Ollama qwen3.5:9b —— 本身就是国产模型（阿里通义 Qwen 系列），所以这个案例不存在"要不要国产替代"的问题，它已经是国产路线
模型可选升级	Qwen 系列更新版本 / GLM / Kimi / MiniMax 均可通过 Ollama 或对应 API 接入 —— 理论替代，本案例未验证
编排层替代	n8n → Dify（可视化工作流 + 知识库，中文文档好）/ 扣子 Coze（国内生态，与飞书、抖音打通）/ 自研 Python —— 理论替代，需重写工作流，不能直接导入 n8n 的 JSON
通知渠道替代	Telegram → 企业微信机器人 / 飞书自定义机器人 / 钉钉 Webhook —— 这三者在国内更常用，接口是标准 Webhook，替换成本低。属理论替代，本案例未做
邮件来源替代	Gmail Trigger → 企业邮箱 IMAP / 企业微信邮件 / 飞书邮箱 —— 需要自己写 IMAP 拉取节点或走邮件网关转发到 Webhook。属理论替代
结构化输出	作者用 n8n Code 节点做 Schema 校验；国内若走 Qwen API，可考虑原生 response_format JSON 模式减少一次校验 —— 本文推导

【15】中国企业可以怎么用？

• 企业场景 1｜跨境电商 / 外贸：询盘分诊 + 首响提速。把海外询盘邮箱接到工作流，线索类自动生成英文回复草稿推给业务员、高优先级客诉立刻告警。核心价值是响应时效（询盘越早回，成交率越高）和不漏单。注意：本案例的样本是英文邮件，跨境场景反而是最贴合的迁移方向。
• 企业场景 2｜SaaS / 服务业客服：工单分级与路由。把 support 邮箱分诊为"紧急 / 常规"，紧急的推给值班人，常规的进队列；同时把每封落行到 CSV/Sheets 作为客服响应数据。这个案例的"urgency=high 才告警"设计天然适配值班制度。
• 企业场景 3｜财务与行政：发票/账单自动归集。invoice 类自动抽取发票号、金额、币种、到期日，落到表格供对账。价值在于把"翻邮箱找发票"这件事从人身上拿掉。注意柔性字段（如预算）准确率仅 73.3%，财务场景必须保留人工复核环节。

【16】中国消费者可以怎么用？

1. 个人邮箱每日晨报。每天固定时间跑一次，把未读邮件分成"要回 / 要办 / 只是通知 / 垃圾"，生成一份摘要推给自己。这是本案例最直接的消费级用法。
2. 自由职业者 / 个体户的询盘优先级。把"哪几封是真客户"从 40 封未读里挑出来，并给出回复草稿。对靠邮箱接单的人，这直接等于时间。
3. 个人知识/事务整理。把发票、账单、订阅确认邮件自动抽字段归档，年底对账不用翻邮箱。

【17】如何变成一个赚钱的项目？

• 产品化：把它做成"邮箱 AI 分诊"轻量产品——目标客户是不想碰 Docker 的中小团队。你卖的是安装包、中文界面、企业邮箱适配（IMAP/企业微信/飞书）与一份可视化报表，而不是算法。
• 服务化：AI 收件箱自动化实施服务。按"邮箱接入 + 分类规则定义 + 一周调优 + 交付评测报告"打包交付。这个案例最值钱的部分其实是它的方法论（职业分离、Schema 校验、评测报告），可以直接作为交付物的一部分卖给客户。
• 咨询化：帮企业判断"哪些邮件流程值得自动化"。很多企业的问题不是没工具，而是把"需要判断的"和"只需要分类的"混在一起。用这个案例的框架帮他们切开，本身就是咨询价值。
• 培训化：这是全站最好的教学案例之一——因为它有真实的评测报告和公开的同行批评，可以完整演示"什么叫可交付的 AI 自动化"。见第 21 节。
• 行业化：跨境、教育招生、诊所前台、律所案件预分诊——凡是"大量格式相似的来信，需要分类+抽字段+路由"的行业都能迁移。差异化在于行业分类体系与字段定义。
• 内容化：把"我怎么把一个 AI 工作流的准确率从 80% 做到 98%"做成系列内容，比讲"10 个 AI 工具"有价值得多——尤其"柔性字段只有 73.3%"这种诚实的失败数据，最有传播力。

【18】变现路径

路径	客户	产品 / 服务	收费方式	难度
企业实施服务	跨境电商 / 外贸公司	收件箱分诊落地（含规则调优 + 评测报告）	项目制	中
SaaS / 本地部署包	中小企业	邮箱 AI 分诊产品（企业邮箱适配）	订阅 / 买断	中
行业解决方案	律所 / 诊所 / 教育招生	行业专属分类体系 + 字段模板	项目制	中高
培训 / Workshop	企业技术团队、独立开发者	「可交付的 AI 自动化」实战课	按场 / 按人	低
模板 / 内容产品	个人开发者	工作流模板、评测方法课程	一次性 / 订阅	低

※ 本表为基于案例结构的商业模式分析，不是收益保证。注意：作者自己已经用"Pro 包"占住了"卖模板"这条路径，个人进入时建议转向"行业适配 + 实施"，而不是卖通用模板。

【19】如果我是一个中国独立开发者（7 天 MVP）

前提：1 人、预算有限、有基础编程能力、使用国产模型（Qwen 本地或 DeepSeek API）。目标：把"跨境询盘分诊"做成一个能卖给外贸公司的最小交付物。

Day 1	把开源项目跑起来（照第 10 节 7 步）。跑通 npm run eval -- --provider ollama --runs 3，先亲眼确认 98.3% 是什么口径。
Day 2	准备你自己的数据：找 50 封真实的（脱敏后）外贸询盘 + 客诉 + 发票 + 营销邮件，按作者的标签格式标注，重跑评测拿到你自己的基线数字。这一步别跳——你会立刻发现中文邮件和合成英文邮件的差距。
Day 3	补齐社区指出的三个短板：加混淆矩阵与 per-class 指标、加 needs review 低置信度人工队列、在运行日志里记录模型版本 + Prompt/Schema 哈希。这三项直接是你对客户交付物里的"专业感"。
Day 4	替换通知与输入渠道：Telegram → 企业微信机器人 / 飞书自定义机器人（Webhook）；Gmail Trigger → 企业邮箱 IMAP 拉取或邮件转发到 Webhook。这是国内可售的关键一步。
Day 5	把"询盘类别 + 关键字段 + 回复草稿"输出成一份中文的每日摘要（表格或简单页面），让业务员不打开 n8n 就能用。
Day 6	找 2～3 家做跨境的朋友，把他们的一个邮箱接进来跑一周（免费）。记录三件事：漏单率、平均首响时间、业务员主观评价。
Day 7	拿真实数据谈第一单：报价方式建议"一次性实施费 + 月度调优费"，交付物是一份《收件箱分诊评测与调优报告》。如果对方只愿意为"报告"付钱，就把产品切成报告服务。

【20】如何迁移到其他行业

【21】培训课程设计

【22】培训师点评

【23】最终判断

※ 以上是案例属性描述，不是"最佳案例排名"。"中国市场相关性"给"高"而不是"极高"的原因：案例本身是英文邮件场景、Telegram 通知、Gmail 触发，需要做一轮渠道与数据本地化才能在中国落地。