构建AI巡检系统：像库迪咖啡一样把人工抽查变成20个智能体自动检测
你将搭建一个可运行的多智能体异常检测框架——把原本靠人眼抽查的质检项（比如客服话术、门店陈列、内容合规）拆成20+个原子规则，每个配一个专用AI探针自动扫描，只把可疑结果推给人复核。全程用开源工具链实
你将搭建一个可运行的多智能体异常检测框架——把原本靠人眼抽查的质检项（比如客服话术、门店陈列、内容合规）拆成20+个原子规则，每个配一个专用AI探针自动扫描，只把可疑结果推给人复核。全程用开源工具链实现，成本可控。从梳理业务规则到跑通第一个智能体，熟练后2小时内能完成。
这套方法最适合两类人：一是有线下服务网络的中小老板（如连锁餐饮、零售、教培），每天被“员工执行不到位”折磨；二是线上业务依赖重复质检的团队（如UGC内容审核、客服录音抽检）。如果你连基础检查清单都没有，或者业务场景每天都在变、根本没法标准化，先别做——AI巡检的前提是“规则稳定”。
现在做这件事的关键理由就一条：大模型推理成本已降到6.06美元/百万token（Anthropic Claude 3.5 Sonnet价格），足够支撑高频轻量检测。库迪咖啡能用20个智能体覆盖全门店检查，不是因为他们买了天价系统，而是把“人盯人”重构为“AI全覆盖+人处理例外”。你的机会窗口就在这里。
拆出你的20个原子检查项
打开Excel或纸笔，列出你当前靠人工抽查的所有质检点。重点找那些“高频、低复杂度、有明确对错标准”的动作。比如餐饮店可拆为：“员工是否戴口罩（是/否）”“垃圾桶是否加盖（是/否）”“价签是否与菜单一致（是/否）”。每个点必须满足：1）能通过一张图/一段录音/一行日志判断；2）不需要上下文推理。
他们最初列了“服务态度好”这种模糊项，后来改成“顾客进店3秒内是否听到‘欢迎光临’”——这才算原子规则。按这个标准筛，通常能筛出15-25项。删掉所有需要主观判断的条目，剩下的就是你的智能体任务清单。
做完这步，你会得到一张带编号的检查表，每行格式如：“#07 - 收银台无私人用品（图像识别）”。如果超过30项，说明拆得不够细；少于10项，说明漏掉了高频场景。
翻车点：别试图让一个智能体干多件事。比如“检查卫生”要拆成“地面无垃圾”“操作台无污渍”“抹布颜色正确”三个独立项——混合任务会让准确率暴跌。
给每个检查项配专属智能体配置文件
在项目根目录创建 .codex/agents/ 文件夹（参考Addy Osmani的Codex规范）。为每个原子检查项新建一个TOML文件，命名如 agent_07_no_personal_items.toml。文件内容严格按以下结构：
name = "no_personal_items_checker"
description = "Detect personal items (phones, bags) on cashier counter from store photo"
instructions = "Analyze the input image. Return ONLY 'PASS' if no personal items visible, 'FAIL' if any detected. Do not explain."
model = "claude-3-5-sonnet-20240620"
reasoning_effort = "low"
关键细节：instructions 必须强制输出二值结果（PASS/FAIL），禁用自由文本；reasoning_effort 设为low以控制成本；model 选中等性能款（如Claude 3.5 Sonnet），这类简单分类任务不需要Opus级别。
为什么这么设计？十页自己踩过坑：早期让智能体写“问题描述”，结果输出五花八门，后续无法自动聚合。二值输出才能批量处理。另外，专用配置文件让你未来能单独升级某个探针——比如食安项换更高精度模型，而不影响着装检查。
做完这步，.codex/agents/ 目录下会有20个左右TOML文件。检查任意一个，应包含name/description/instructions/model四字段，且instructions里有“Return ONLY...”字眼。
翻车点：别在instructions里写步骤！比如“先看左边再看右边”——这会限制AI应对新角度照片的能力。记住数字生命卡兹克的提醒：给目标+边界，别遥控指挥。
设置人工复核触发规则
在共享规则文件 HEARTBEAT.md 中定义复核逻辑（参考十页记忆中的AI Video Factory结构）。核心规则只有一条：当智能体返回FAIL时，自动截取原始数据片段+检测结果，生成待复核工单。
具体操作：用脚本监听所有智能体输出，遇到FAIL就执行：
create_review_ticket(
source_data=original_image_or_log,
agent_id="no_personal_items_checker",
timestamp=current_time,
confidence_score=agent_output.get("confidence", "N/A")
)
工单格式必须包含原始数据快照——这是避免误判的关键。库迪咖啡的系统里，店长复核时能看到AI标记的“疑似手机”区域框，而不是一句冷冰冰的“不合格”。
为什么必须带原始数据？我见过太多团队只传“FAIL”标签，结果人工复核时发现是光照导致的误判，但原始图已覆盖。HEARTBEAT.md 就是用来固化这类协作规则的。
做完这步，你的系统会在 review_queue/ 目录生成带时间戳的工单文件，命名如 20240715_1423_agent07_FAIL.jpg。打开任意工单，应同时看到原始数据和智能体结论。
翻车点：别设置“置信度低于90%才复核”——简单任务中AI的置信度常虚高。直接全量复核FAIL项更可靠，毕竟人工成本只花在5%-10%的异常样本上。
用/goal命令驱动持续巡检循环
在巡检主脚本中启动/goal循环（采用Addy Osmani的验证模式）。例如每日9点自动执行：
/goal "all_store_checks_complete_for_today && review_queue_has_no_unprocessed_items"
系统会持续调用各智能体直至条件满足。关键在独立验证器：另写一个轻量脚本每5分钟检查一次“今日20个检查项是否全部返回结果”，而不是让主智能体自己说“我干完了”。
这样设计是因为：主智能体可能因网络中断漏跑某个探针，但独立验证器能发现“agent_12未返回”，从而触发重试。库迪的系统里，这个验证器甚至会检查门店摄像头是否在线——这才是嵌入业务流程的AI（呼应刘润的标准）。
做完这步，你的终端会显示/goal正在运行，且每轮结束后有验证日志：“[VALIDATOR] All 20 agents reported. Queue: 3 pending reviews.” 如果卡住，一定是某个智能体没响应。
翻车点：别让/goal的目标包含主观描述，比如“确保门店合规”。必须像素材3那样写可验证条件——“all_store_checks_complete”指20个TOML对应的输出文件都存在。
完成自检清单
-
.codex/agents/目录下有≥15个TOML文件，每个含二值输出指令 -
HEARTBEAT.md明确写了FAIL结果必须附原始数据快照 - 人工复核工单命名含时间戳+智能体ID+结果状态（如
_FAIL.jpg） - /goal 的停止条件由独立脚本验证，而非主智能体自述
- 所有原子检查项均可通过单张图/单段日志判断，无需跨样本推理
AI巡检系统不是替代人，而是把人从“找问题”解放到“定规则”——你的时间该花在更新HEARTBEAT.md，而不是盯着第100家门店的垃圾桶。
素材来源
本文由十页AI从以下原始素材延展整理：
- 下一波红利，藏在公司流程里 · 微信公众号 · 刘润