每天清晨自动跑一趟 ERP 巡检探一遍服务、数据库、日志和批处理再生成一份日报推到运维群——这套东西听起来很像“上个定时任务就能实现”但真正落地时你会发现难点根本不在定时器而在于把零散的巡检经验组织成一个会判断、会汇报、会告警的数字员工。我折腾了大半个月用开源版 Coze 这类自托管的智能体平台搭出了这个“每日 ERP 系统巡检计划”中间踩了不少坑也总结出一套可以复用的方法。这篇就完整拆一遍。1. 为什么一定得用智能体做每日巡检1.1 人工巡检的三个死穴以前我们项目组是每周五下午做一次固定巡检人手一张表从 Web 服务可不可用、数据库连接池有没有打满一直查到昨晚批处理有没有失败。一开始大家还很认真时间一长就变成了打勾游戏。原因很简单巡检是低刺激劳动今天和昨天大概率没区别人的注意力很快就会钝化漏项就成了必然。然后是发现滞后。夜间批处理失败、磁盘空间逼近水位、某个接口开始大面积超时这些事人不可能 24 小时盯住。我们至少遇到过三四次都是第二天早上业务打电话过来说“对账单怎么没生成”我们才去翻昨晚的日志。问题不在于日志不存在而在于发现问题的时机太晚等业务反馈过来影响已经扩散了。还有一个隐性成本记录分散。今天的巡检结果在群里上周的在 Excel 表格里上个月的在邮件附件里。真要去复盘一个周期性问题时根本拼不出一条完整的时间线。这三个痛点叠加让我下决心把巡检从“每周人工表”改成“每日智能体自动跑”。1.2 开源版 Coze 这类平台解决了什么问题有人会问商业智能体平台那么多为什么非要用开源版 Coze 这类自托管方案核心原因是数据边界。ERP 巡检要碰的东西太敏感了数据库连接状态、用户登录日志、批处理作业明细、文件服务器磁盘水位这些数据如果全部丢到公网 SaaS 平台在很多企业的合规审查里是过不了关的。开源版 Coze 严格说不是一个具体产品而是社区里一类自托管智能体编排平台的统称。它们通常具备几个关键能力可视化的工作流编排、定时触发、HTTP 请求节点、数据库查询节点、代码/函数节点、大模型接入以及对外通知用的 Webhook。把这些能力组合起来已经足够支撑一个企业级巡检智能体。选择平台时我比较看重四点定时器是否可靠、时区能不能配置数据库是否支持只读连接避免智能体账号误写业务数据工作流是否支持并行分支能把巡检总耗时压下来模型是否可替换方便后续换成内网私有化模型。这四点对应的不是花哨功能而是“能不能稳定跑起来”和“数据会不会出域”这两个根本问题。1.3 我们要交付的“每日巡检计划”长什么样最终交付物不是一纸文档而是一个每天自动执行、可观测、可干预的智能体。它每天清晨触发按四层逻辑运转采集探活 Web 服务、查询数据库指标、拉取应用日志、检查批处理和消息队列状态。判断把采集结果与基线阈值比对逐项标记正常/异常以及严重级别。汇总让大模型基于结构化数据生成巡检日报输出固定格式。通知日报推送运维群异常项按级别触发不同的告警通道。目标是让原本每周五下午耗时两小时的人工巡检变成每天早上花 5 分钟看一份日报真有异常时系统第一时间说话而不是等业务来投诉。这个设计的核心价值在于把边界划清楚机器负责周期性的采集和比对人只负责看异常和处理需要判断的事情。2. 巡检智能体总体设计先画清楚“谁做什么”2.1 不要一上来写 Prompt先把流水线画出来很多人接触智能体后第一反应是写一段很长的角色 Prompt指望大模型自己搞定一切。但巡检这种事不能这么干。巡检的稳定性来自流水线而不是来自模型的临场发挥。我在画布上把流程拆成四层采集层、判断层、分析层、通知层。采集层负责把服务探活结果、数据库指标、日志摘要变成结构化的 JSON判断层用确定性的规则去比阈值比如连接数使用率超过 80% 就标异常分析层才把异常结果交给大模型让它归纳成自然语言日报通知层根据异常级别走不同通道。每一层职责单一出了问题也容易定位。这个分层设计还有一个用意把大模型的使用范围尽量缩小。大模型只做“翻译”和“归纳”不做“决定”因为巡检决定必须可复现、可解释不能昨天觉得连接池 79% 正常、今天觉得 75% 就有风险。2.2 巡检对象与检查项怎么拆巡检项设计是整个智能体最核心的部分我建议按照“对象-检查项-采集方式-异常判定”四列来拆拆完就形成一张可以落地的表。巡检对象检查项采集方式异常判定Web 服务健康检查接口、HTTP 状态码、响应耗时HTTP 请求节点非 200 或响应超过 3 秒数据库活跃连接数、慢查询数、锁等待、表空间SQL 查询节点连接数使用率超 80%慢查询超过 5 条应用日志错误级日志、超时、OOM、连接拒绝日志接口或命令行采集出现 ERROR/Exception 关键词批处理作业作业状态、失败重试次数、执行时长调度平台 API 或作业表失败、重试超过 3 次、时长超历史均值 50%消息队列积压数量、消费速率队列管理 API积压超过 1000 且持续上涨用户安全非工作时间登录、连续失败锁定、权限变更数据库查询命中风险规则则标记待确认有了这张表后续每个节点要做什么就非常清楚。注意异常判定这一列必须写死因为阈值是后续判断节点的直接依据。2.3 智能体的角色定义巡检员、分析师、播报员三位一体一个巡检智能体其实身兼三个角色它要像巡检员一样按清单检查像分析师一样判断异常影响范围再像播报员一样把结果讲清楚。在开源平台里这三个角色通过系统 Prompt 加上不同的工具节点组合来实现。我给智能体的基础人格 Prompt 是这样写的你是 ERP 每日巡检助手。你的职责是根据工具返回的数据逐项检查系统健康状态识别异常并生成一份巡检日报。你的所有结论必须基于工具返回的真实数据不允许编造、猜测或补充未提供的信息。如果某项数据未获取到请明确标注“未获取到”不要推断。这段 Prompt 里最关键的是“不允许编造和猜测”。因为大模型天生有补全信息的倾向你不把这个口子堵死它会在日报里写出一堆看似合理、实际上不存在的结论。2.4 巡检基线与阈值先回答“什么算异常”阈值不能拍脑袋否则智能体要么天天乱报要么什么问题都发现不了。我们项目组把过去两周的人工巡检记录翻出来统计每个指标的正常分布再进一步确定阈值。举个例子数据库连接池上限是 200过去两周的活跃连接数 75 分位在 120 左右峰值到过 160。那连接数使用率超过 80%即 160作为告警线就比较合适再留一点缓冲空间到 85% 作为 P1 告警。慢查询阈值取的是“过去两周平均慢查询数加两个标准差”这样避免某一天业务流程特殊导致误报。需要提醒的是阈值不是一成不变的。系统大促、月末结账、新版本上线后基线可能整体抬升所以要留出“基线再校准”的机制比如每个月自动用最近 14 天数据重新算一次阈值。3. 实操一步步创建每日 ERP 巡检智能体3.1 在开源平台上创建智能体名称、模型、基础配置先回到画布最顶层新建一个智能体。名字我们叫“ERP 每日巡检助手”这个名称会出现在日报落款和告警消息里尽量起得正经一点方便群里人识别。模型选择上我建议优先用私有化的模型网关。如果短期没有用云 API 也可以但所有进入模型的日志数据必须先脱敏手机号、身份证、登录 IP 这类信息提前打码。另外把“短期会话记忆”关掉因为每次巡检都是一次独立的任务上一次的结果不应该影响下一次的判断否则容易出现“昨天有异常所以今天默认也有异常”的偏差。最后把基础人格 Prompt 填进系统设定里。这一步不需要写太长重点是约束行为边界而不是堆砌业务知识。业务知识放在工作流节点的提示词里按场景注入。3.2 配置每日定时触发时区是第一大坑在开源平台的工作流起始位置添加一个定时触发节点类似 Cron 配置。我们希望每天早晨 7 点 30 分执行就填0 30 7 * * *。这里有个坑必须单独强调很多平台底层容器默认是 UTC 时间如果你本地是东八区填入的 7:30 会实际在 UTC 7:30 也就是北京时间 15:30 触发。第一次上线时我们没注意这个眼睁睁看着巡检日报在下午出现排查半天才发现是时区问题。务必在平台配置里找时区设置把它改成服务器所在时区然后在测试页面多跑几次确认触发时间符合预期。定时触发还有一个隐蔽问题如果平台服务本身在触发时间点刚好重启或不可用任务可能被跳过。所以尽量找一个支持“失败重试”或“补跑”的触发机制或者保留手动执行入口避免某天漏跑。3.3 编排巡检执行工作流并行分支能救命定时触发节点后面就是巡检执行流程。我把六类检查项分成两条主分支服务与数据库相关走一条日志与批处理相关走另一条最后汇总。每个检查项用不同的工具节点实现Web 服务探活用 HTTP 请求节点访问健康检查接口读取返回的 JSON。数据库检查用数据库查询节点执行只读 SQL获取连接数、慢查询、锁等待等指标。日志采集用日志接口或命令行节点抓取过去 24 小时含错误关键词的日志行先做去重和计数。在画布上把这些节点并排铺开然后连成一个并行分支。实测下来串行跑完全部检查需要将近 10 分钟改成并行分支后压缩到 2 分半钟。巡检时间缩短的意义不只是快还能降低对生产系统的侵入时长毕竟每一次数据库查询都是有成本的。3.4 数据汇总与 LLM 分析节点让日报“只说人话”每个采集节点的输出默认是一堆 JSON 片段直接发给大模型会让它手足无措所以中间要加一个汇总节点。汇总节点把各分支输出合并成一个统一结构类似{ web_service: { status: 200, response_time_ms: 850 }, database: { active_conn: 128, max_conn: 200, slow_queries: 3 }, logs: { error_count: 2, keywords: [Connection refused] }, batch_jobs: { failed: 0, retries: 0 } }然后把这个 JSON 传给 LLM 分析节点。分析节点的提示词里要附上每个字段的含义和异常判定规则类似“database.active_conn 超过 max_conn 的 80% 属于异常请标记为 P1”。这样一来大模型的职责就从“自己判断什么是异常”变成了“按既定规则解读数据”稳定性明显提升。日报输出格式也要提前固定整体状态、异常项列表、严重级别、建议动作、巡检范围。格式固定后群里的每个人每天读日报的认知成本会大幅降低。3.5 通知与告警节点别把原始报错甩进群里日报生成后进入通知节点。我设计的路由逻辑是先判断是否有异常再判断最高严重级别。全部正常只推送一份“安心日报”到运维群附带关键指标摘要。存在 P2 级别异常日报里用黄色标记异常项不额外打扰。存在 P1 级别异常日报推送的同时通过群机器人 负责模块的同事并附上一句由大模型生成的现象描述、影响范围和建议动作。存在 P0 级别异常在 P1 基础上再增加电话或短信告警通道。这里要特别提醒一点不要把原始错误栈直接推到群里。群里大多数人不是写这段代码的人看到一串异常信息根本不知道要干什么。正确做法是先让 LLM 把技术细节翻译成业务语言比如“订单服务响应超时近 10 分钟失败率 32%建议检查实例健康状况并查看负载均衡配置”。3.6 测试、试运行与上线先骗它一次智能体上线前我建议至少做三轮验证。第一轮是平台自带的“运行一次”功能逐个节点看输入输出确认每个检查项的数据字段都有值。第二轮是故意破坏挑一个非核心服务手动停掉再触发一次巡检验证从发现异常到大模型分析再到告警推送的完整链路。第三轮是纯试运行连续跑一周每天把智能体的日报和人工巡检结果做对比校准阈值和提示词。试运行期最容易发现两类问题一是某些指标在夜间有规律性波动比如凌晨批处理会导致活跃连接数短暂升高需要在阈值里加上时间段条件二是日志关键词覆盖不全某些业务异常用的是自定义错误码而不是 ERROR 字样需要补进去。4. 巡检项与采集细节真正决定智能体质量的是数据4.1 服务可用性怎么探不要只探“通不通”健康检查接口比单纯“端口能连通”要可靠得多。我们每个服务都暴露一个/health接口返回类似{ status: UP, db: UP, cache: UP, version: 20240315-1 }HTTP 探活节点每次请求时除了记录状态码还要记录响应耗时和返回体里的status字段。如果 HTTP 状态码是 200 但status是 DOWN说明服务进程还活着但内部依赖已经挂了这种是更值得关心的“半死”状态。探活地址要使用内网地址不要绕公网否则会把公网链路的抖动误判为服务异常。这里的坑我们踩过某一天服务全部正常但智能体报了两个服务不可用最后发现是公网负载均衡节点瞬时抽风。4.2 数据库巡检连接数、慢查询、锁等待与表空间数据库是整个巡检里信息量最大的部分。以下是我们实际用到的几个查询按 PostgreSQL 语法为例-- 活跃连接数 SELECT count(*) AS active_conn FROM pg_stat_activity WHERE state active; -- 当前运行超过 2 秒的查询 SELECT pid, query, now() - query_start AS duration FROM pg_stat_activity WHERE state active AND now() - query_start interval 2 seconds; -- 数据库大小 SELECT pg_size_pretty(pg_database_size(current_database()));如果底层是 MySQL对应的是SHOW PROCESSLIST和information_schema表采集逻辑是一样的。关键原则是智能体连接数据库只允许使用只读账号账号密码不要直接写在工作流配置里而是放到平台自带的密钥管理环境变量中。连接数阈值还有一种更稳妥的算法连接池的max_conn是硬上限但不要直接拿 80% 当基线。应该结合业务周期做分时基线比如工作日上午和凌晨的活跃连接数差异很大统一阈值会导致白天误报或夜间漏报。4.3 日志巡检从海量日志里抓“生病的句子”日志巡检最容易犯的错误是让大模型直接吞全量日志。一天的日志可能有几十万行直接塞进去既不经济也不稳定。正确的做法是在采集阶段先做聚合用 grep 或日志平台的查询接口把包含ERROR、Exception、Timeout、OOM、Connection refused关键词的日志行筛出来按模块聚类统计数量和出现时间再把这个压缩后的摘要交给 LLM。这样才能保证大模型看到的是“体检报告”而不是“原始病历”。日志时间窗口我建议用“过去 24 小时”每天早上巡检时正好覆盖一个完整业务日。如果某些系统的日志滚动比较快也可以改成最近 2 小时宁可少看一点也要保证日志还没被截走。4.4 批处理与集成检查结账日最怕的隐藏故障批处理作业的检查分为三个维度状态、耗时、重试次数。我们从调度平台 API 拿到作业列表后重点关注三类信号失败作业状态不是 success说明有明确故障。重试超过阈值一次失败后自动重试很正常但重试超过 3 次还在失败通常不是偶发问题继续重试只会放大负载。执行时长偏离历史均值哪怕作业最终成功了执行时长突然翻倍也预示有资源争用或者数据量异常需要提前排查。消息队列检查也类似积压数量本身不是问题积压是否持续上涨才是问题。如果积压 2000 条但消费速率稳定可能是临时的高峰如果积压从 1000 涨到 5000消费速率还在掉就要告警了。这个判断逻辑我建议放在代码节点里做两次采样对比而不是只看瞬时值。4.5 用户与安全巡检数据敏感谨慎暴露安全类巡检项要单独说明因为它涉及个人隐私需要额外控制权限。我们只检查四类事件非工作时间登录、连续失败后锁定的账号、新增管理员账号、权限组异常变更。这些数据进入大模型之前必须脱敏登录 IP 只保留前两段用户名只保留工号后四位。这类巡检通常放在独立分支里日报中只呈现“安全巡检发现 3 条待确认事件详情请登录平台查看”不在群里暴露具体账号信息。这既是安全要求也是为了避免群里所有人都在围观某个账号的异常行为。5. 常见问题与排查实操5.1 定时任务没触发先查时区再查调度配置如果发现智能体某一天没有按时跑第一步不是看网络而是看调度记录里任务的执行状态。大多数开源平台会保留每次触发的日志区分为“已触发但执行失败”和“根本未触发”。“根本未触发”大概率是时区或 Cron 表达式问题。前面说过 UTC 和本地时间的坑还有一类问题是平台对 Cron 表达式的解析有差异比如有的平台用标准 5 段有的用 6 段带秒。我用过一个平台填0 30 7 * * *没问题换另一个平台同样的表达式却默认当成“每 7 小时的第 30 分”触发这个只能靠测试确认。“已触发但执行失败”就要往下游排查了数据库账号密码是否过期、日志接口是否有认证变化、目标服务是否升级导致健康检查接口路径变了。定时任务的排查思路和人工巡检没什么两样只是把“看日志”这一步也自动化了。5.2 日报结论不稳定让规则做决定大模型做翻译试运行头两天我发现日报里经常出现“系统整体存在一定风险建议关注”这种模棱两可的结论。问题出在提示词上——我一开始让大模型自己基于数据判断是否异常它就会在确定性规则面前表现出“过分谨慎”或“乐观估计”。后来我把所有异常判断都改为代码节点和条件分支完成比如连接数使用率 80% 直接输出level: P1日志错误数 0 且包含数据库关键字才输出level: P0。大模型拿到的输入就已经标好异常级别了它只负责把异常级别和相关数据组织成一段人话。这个改动之后日报结论的稳定性立刻提升连续一周没有出现前后矛盾。如果你发现自己写的 Prompt 怎么调都不稳大概率不是措辞问题而是把不该交给模型的判断逻辑交给了模型。5.3 告警风暴同一个根因不要重复轰炸数据库连接断开时所有依赖数据库的接口都会失败Web 探活、接口检查、批处理检查可能同时告警群里一两分钟内刷十几条消息。这就是告警风暴本质是多个检查项共享同一个根因却各自独立上报。解决办法有三个层面。第一是告警聚合所有告警先进入一个汇聚节点按照“系统模块 时间窗口”分组同一模块 30 分钟内的多条告警合并成一条。第二是抑制窗口同类告警在 30 分钟内只推送一次如果问题持续每 30 分钟升级一次而不是每 5 分钟刷屏。第三是关联分析部分平台的代码节点支持简单的相关性判断比如“数据库检查异常 订单服务探活失败 日志出现 Connection refused 数据库连接故障”输出一条综合告警而不是三条孤立告警。这条经验对夜间值班特别重要。夜里没人盯着群消息与其让服务器刷 20 条告警把人吵醒不如让它先静默聚合等真正确认根因后再一次说清楚。5.4 数据访问权限与安全巡检智能体也要被“巡检”智能体因为要连数据库、读日志权限天然不小它本身就是一个需要被保护的系统。我们在安全上做了四件事数据库账号设置成只读并且限制来源 IP 只能从平台所在网段访问。平台的管理后台开启访问白名单禁止外网直接登录控制台。所有大模型调用统一走脱敏层日志、数据库返回内容在进入模型前完成手机号、身份证等敏感信息的替换。每次巡检执行记录都会落库方便追溯某条日报结论是依据哪些原始数据得出的。不要因为做了自动化巡检就把原有的安全边界拆掉。这个智能体越是稳定可靠被授予的权限就越容易膨胀必须把权限控制纳入巡检项本身。5.5 一个完整的排障案例停掉一个微服务之后最后分享一个真实发生在我们环境里的案例方便你验证自己的智能体链路是否正确。某天早上 7 点 35 分运维群收到一条 P1 告警“订单服务健康检查失败HTTP 返回 502响应耗时超过 8 秒近 10 分钟日志出现 32 条 ORA-12514监听器无法识别服务名错误。”巡检日报显示订单服务探活失败应用日志异常数量较昨日上升 21 倍数据库连接池使用率正常批处理任务“订单日终汇总”未在规定时间内完成。智能体给出的建议是“优先检查订单服务所依赖的数据库监听器状态同时关注负载均衡是否将流量路由到已停止的服务实例。”后来排障发现确实是某个微服务实例被误停后负载均衡健康检查没有及时把节点摘除流量持续打到一个不存在的实例上进而引发数据库监听器连接请求堆积。整个过程智能体从发现异常到发出告警不到 4 分钟比我们之前人工发现的平均耗时提前了近 3 个小时。这个案例也说明了一个规则智能体不需要比人聪明多少它只需要比人及时、比人全面、比人稳定价值就已经足够大。结尾把智能体当“初筛员”而不是“决策者”这套巡检智能体跑了一个多月后我的体会是它真正的价值不是替代了谁而是把团队从重复劳动里解放了出来。原来每周五下午的巡检变成了每天早上看一眼日报夜里的异常终于有人在“站岗”。但我也很清楚它的边界——它所有的判断都基于我们预设的阈值和检查项真正复杂的问题仍然需要人去定位和决策。如果后续还想继续演进我会把三个方向纳入规划一是把巡检历史沉淀成知识库让智能体在遇到相似异常时能给出往期处理方案二是接入更多系统比如 OA、网络设备、云资源监控统一成一个企业运维数字员工三是增加多模型路由让复杂分析走強推理模型简单场景走轻量模型以节省成本。最后留一个小技巧给巡检智能体单独建一个“异常案例库”每次人工排障后把结论写进去。时间越长这个案例库就越值钱因为它不是文档而是直接让下一次巡检更聪明的养料。