★ FEATURED ARTICLE 做无人值守 Agent 有个很有意思的分水岭开发环境里跑通一次和让它每天凌晨自动跑完还能自己处理异常完全是两码事。我最近把一个定时自动化任务从“人盯着跑”改造成“无人值守”中间踩的坑比我预想的多一整个量级。这篇文章不聊 Agent 概念多火就聊无人值守场景下Agent 做定时自动化任务时怎么把可靠性设计落到实处以及效果怎么量化验证。不管你是正在搭 AI Agent 项目的开发者还是负责运维自动化任务的工程师下面这套方法论都能直接落地。先说结论无人值守 Agent 不是简单加个 cron而是要把非线性、概率性的 AI 执行过程塞进一个线性、确定性的运维框架里。这个框架里要有调度、要有记忆、要有工具权限边界、要有状态持久化还要有一套能跑回归的效果验证体系。缺了任何一块短时间看起来跑通了跑上三天就会暴露问题。1. 无人值守 Agent 的核心难点拆解1.1 交互式回合到定时任务思维模式的转变交互式 Agent 是“人机协同”用户可以在每一步确认结果、纠正方向、点重试。无人值守场景把这些兜底动作全部拿掉了。定时任务凌晨三点触发没有人盯着屏幕模型答错了没人指出来工具调失败没人手动换方案网络抖动也不会有人帮你重新发起请求。这个时候 Agent 的每次失误都从“小插曲”升级成“生产事故”。我见过很多团队犯同一个错误在 Jupyter Notebook 里跑通一个 Agent 流程就认为可以做定时任务了。交互式跑通和无人值守跑通之间差的不是 Agent 能力而是工程化能力。你需要提前回答几个问题任务失败后要不要重跑重跑会不会产生重复数据Agent 卡在某个循环里怎么办模型突然输出一段非法 JSON 怎么兜底工具返回超长文本把上下文撑爆怎么处理这些问题没有在代码里显式处理定时任务就会在某个凌晨精准地触发一次故障。交互式场景下你可以“救火”无人值守场景下只能靠代码自己救自己。1.2 可靠性的四个支柱做无人值守 Agent我习惯把可靠性拆成四个支柱可观测、可恢复、可验证、安全边界。可观测不是指打日志而是指你能回答“这个任务现在跑到哪一步了”“上一次失败原因是什么”“每一步消耗了多少 token”。没有观测能力Agent 就像一台没有仪表盘的飞机飞得再高也不知道有没有要爆炸。可恢复指系统在故障后能自动恢复至少能安全降级。比如外部数据源挂了是直接报错还是先用昨天的缓存生成报告模型连续调用失败是无限重试还是告警后停止可验证指每次任务结果不能只靠“看起来没问题”来判断。定时任务要求的是可重复、可回归你要有测试集、有 golden answer、有成功率指标。没有验证体系Agent 版本的每次升级都是在赌运气。安全边界在无人值守里尤其重要。没有人审核Agent 就越容易拿到工具调用权限后做出不可逆操作。发邮件、改数据库、删文件这类动作必须有明确的授权机制和人工审批兜底。记住无人值守不等于无人负责该审批的流程一定要通过外部系统卡住。2. 定时自动化任务的整体架构与关键技术选型2.1 Agent 框架、Harness、Skill 到底怎么分工很多朋友会把 LLM 和 Agent 画等号。简单说LLM 是一个文本生成引擎Agent 是一个拿着引擎去执行目标的完整系统。同一个 LLM 可以跑出行为天差地别的 Agent区别就在框架、技能和内存策略上。这里需要分清三个概念Agent 核心、Harness、Skill。角色承担什么我常用的技术选型Agent 核心根据目标拆解任务、决定下一步动作、评估工具结果LangGraph、自研状态机、Coze 等编排产品Harness提供工具执行环境、循环控制、上下文管理、安全隔离各类 Agent Runner、Spring AI、LlamaIndexSkill封装某个特定领域能力比如查报表、发消息、写周报自研工具集、插件市场里的技能包Harness 和 Agent 的区别经常被混淆。Harness 是“跑车外壳”负责提供轮子、方向盘、安全气囊Agent 核心是“司机”负责决定往哪开。工程上 Harness 的稳定性可以直接保证比如超时控制、重试机制、请求合并而 Agent 核心的稳定性只能通过提示词、评测和护栏来逼近。选型时别只看哪个框架更“智能”先看 Harness 层是否支持你需要的可靠性原语比如 Checkpoint、重试、暂停和恢复。Skill 则是整个系统里最容易复用的部分。定时自动化任务里我建议把每个工具封装成独立的 Skill输入输出都有明确 schema。这样 Agent 决策层和工具执行层解耦工具坏了可以单独降级不会影响整个流程。2.2 调度层定时触发的工程化细节调度层是无人值守任务的地基。生产环境我一般不用while True sleep而是用 APScheduler、GitHub Actions、Airflow 或者云上的定时触发器来处理。选哪种取决于任务粒度和依赖复杂度但核心要求是一致的时间准确、不丢任务、可补跑、可跳过。这里最容易踩坑的是“Catchup”逻辑。Cron 表达式被设计成“触发时刻执行”但 Agent 任务通常需要“触发后完成才算数”。比如每天 8 点生成报告如果 8 点整服务器刚好在做发布任务被跳过了那今天这份报告就永远缺失。好的调度系统必须有 missed_job 机制能补跑没执行的任务。另外要注意时区问题。服务器默认 UTC业务要求北京时间每天早上 8 点跑cron 表达式和系统时区不对齐就会导致任务在错误的时间点执行。我记得有一次排查半天最后发现是容器时区没有挂载宿主机时区造成的。Windows 11 上跑定时任务也有不少坑。任务计划程序虽然能用但默认电源管理可能让任务在休眠期间跳过。建议在电源设置里关闭“快速启动”任务触发器改成“如果错过计划开始时间尽快启动任务”。桌面端 Agent 尤其要注意这一点因为桌面会话可能因为锁屏、休眠被系统冻结。2.3 记忆体系与上下文策略跨任务状态管理Agent 记忆在无人值守场景里不是锦上添花而是必须。定时任务往往是连续多轮运行的比如每天早上读昨天生成的文件、对比前几天的数据趋势。如果 Agent 每次启动都是“失忆”状态它就需要重复向模型输入大量历史信息成本高还容易出错。我通常把 Agent 记忆分成三层短期记忆当前任务的会话上下文。包括正在执行的步骤、工具返回结果、中间产物。这一层直接放在内存里超时或者任务结束后清空。中期记忆跨任务的结果缓存。比如某天已经生成过日报下次任务直接复用避免重复计算。这层用数据库表或 KV 存储实现按任务 ID 和日期维度做 Key。长期记忆用户偏好、任务规则、领域知识。比如“报告里必须包含风险等级”“发送前必须经过校验”。这层我建议用独立的配置表或向量库保存并且不允许 Agent 随意修改。这里有个容易忽略的问题长期记忆和永久记忆不是一回事。长期记忆是“这个用户习惯什么样”永久记忆更像是系统级的“事实库”例如账号信息、固定业务规则。永久记忆的写入权限必须收得很紧不能让 Agent 在推理过程中把一条业务规则改掉。我遇到过一次 Agent 把周五发送规则记成周六后面整整跑了两次错误任务才被巡检发现。2.4 路由识别节点与工具调用执行链路里最容易跑偏的地方无人值守任务中Agent 通常要决定“这一步是去查数据库还是去调外部 API还是直接生成文本”。这个决策点就是路由识别节点。它可以是显式的路由规则也可以是模型根据用户目标自动判断。但自动判断在无人值守里风险很高因为模型可能因为 prompt 里的一个含糊描述选错工具。我习惯把路由设计成“先收窄再选择”。先根据任务类型从预设流程里确定候选工具集再让模型在这几个候选里做选择。比如日报任务只允许调用“读取数据”“汇总文本”“发送通知”三个工具模型就不会放飞自我去调用一个无关的“查询天气”工具。工具调用环节还要处理几个工程细节工具输入参数要做 schema 校验工具返回结果要限制长度超长结果要截断或摘要后再放回上下文。否则一次SELECT *可能把几十万行结果灌给模型直接把 token 预算打爆。我通常会给工具返回值设置一个白名单结构只保留后续生成报告真正需要的字段。3. 可靠性设计让 Agent 在无人盯守时不掉链子3.1 任务幂等与分布式锁避免重复执行的连带事故定时任务最典型的故障就是重复执行。网络抖动导致调度器发出了两次触发或者同一个任务在多个节点同时跑数据就会被写两次通知会被发两次。如果 Agent 执行的是“对账”或者“转账”这类有副作用的操作重复执行会直接造成业务损失。解决思路是幂等和分布式锁两层配合。幂等是让任务本身具备“重复执行结果一致”的特性比如写入记录前先查唯一索引插入时用INSERT ... ON DUPLICATE KEY UPDATE。分布式锁是保证同一个任务同一时间段只有一个实例在执行。我用 Redis 做锁很常见伪代码大概是import redis r redis.Redis(hostlocalhost, port6379, db0) def acquire_lock(task_id): # nxTrue 确保同一个 key 只能被一个客户端占住 # ex1800 表示锁的最长持有时间防止任务挂死导致死锁 return r.set(flock:{task_id}, 1, nxTrue, ex1800) def release_lock(task_id): r.delete(flock:{task_id})这里我建议把锁的 TTL 设成任务最长时间的两倍以上。设短了任务还没跑完锁就过期其他节点会并发执行设长了一旦进程崩溃锁要等很久才能自动释放。稳妥做法是在任务里显式心跳续期或者在 finally 块里释放锁。多节点部署时一定要确认所有节点连接的是同一个 Redis 或同一个数据库否则锁形同虚设。3.2 超时、重试与退避给模型执行装上护栏Agent 调用 LLM 是一个高延迟、高不确定性的过程。单次调用可能在几秒到几分钟之间波动极端情况下还会一直挂起。无人值守任务里必须给整个任务和单次调用分别设置超时。我给团队定的默认值是模型单次调用超时 60 秒Agent 单任务总超时 10 分钟。超过总超时的任务直接标记为失败进入告警队列。有人可能会担心 10 分钟不够 Agent 跑完复杂任务但 10 分钟是为了防止任务无限期挂起真正复杂的流程应该在设计上拆分成多个子任务而不是靠延长总超时。重试策略也要分层。网络错误可以重试但模型因为提示词问题返回错误盲目重试大概率还是失败反而浪费 token。我习惯用指数退避加抖动第一次失败等 1 秒第二次等 2 秒第三次等 4 秒最多重试 3 到 4 次。这比固定间隔重试更温和也不会在服务恢复瞬间造成流量风暴。记住一点Agent 的“思考”和“行动”之间也有潜在死循环。模型可能在一个工具调用失败后反复调整参数重试导致整个任务陷入死循环。我见过一个案例Agent 为了读取一个不存在的目录连续尝试了 10 次不同的路径。解决方法是给 Agent 的循环步数设置上限比如最多执行 20 步超过就强制退出并告警。3.3 输出校验与自我修正防止“很自信地做错”LLM 最大的特点是“输出正确时很自信输出错误时也常常很自信”。无人值守任务的输出如果没有校验一封措辞流畅但数据错误的日报就可能直接发送出去。我的做法是双保险。第一步是结构化输出校验。让模型输出 JSON用代码校验字段是否存在、类型是否正确、日期格式是否符合要求。第二步是语义校验。把关键数据点和源数据做比对比如报告里的“昨日新增用户数”是否等于源数据里的汇总值。数值对不上就直接判定为失败。如果校验失败不要把任务直接判死。把校验错误信息反馈给 Agent让它带着错误描述再尝试一次这通常能解决大部分格式问题。但要注意设置“自我修正次数”上限我一般设 2 到 3 次。超过上限后停止转入人工处理队列避免 Agent 在同一个坑里反复跳。这里有个小技巧每次校验失败时把模型的原始输出保存下来和修正后的输出放在同一个执行记录里。这样后面做评测集扩展的时候这些失败样本就是最宝贵的回归测试数据。3.4 状态持久化与可观测性出问题时给足线索无人值守任务跑失败了最怕的不是失败本身而是失败后找不到原因。所以我做 Agent 任务时会把每一步执行状态持久化到数据库而不是只靠 stdout 日志。我通常维护一张agent_task_run表字段包含任务 ID、触发时间、开始时间、结束时间、状态、当前步骤、最后错误信息、模型名称、token 消耗、输入摘要、输出摘要。每一步执行到关键节点时更新这些字段。这样即使进程崩溃重启后也能根据“当前步骤”恢复到上次打断的位置。日志层面要做结构化输出。每条日志至少包含task_id、step、timestamp、event、error。这样在日志系统里可以直接按 task_id 拉出整条链路。没有链路追踪Agent 的异步执行过程会非常难排查因为你不知道当前日志到底属于哪一次触发。还需要监控 Agent 的“运行健康度”。我常用的是成功率低于 90% 就触发告警连续 3 次失败直接发预警任务执行时间超过 P95 的两倍就提醒可能异常。这些指标最好都落到指标面板里定时任务不是“跑起来就完事”它需要你每天扫一眼状态而不是等用户来投诉。4. 效果验证从跑通到“真的可用”的评测方法4.1 定义效果指标不能只盯任务完成率验证 Agent 效果最粗的指标是“任务完成率”即定时任务成功执行的比例。但只有这个远远不够。完成率是 100% 也可能输出质量很差只是系统没有报错而已。我建议把效果指标拆成任务执行指标和任务产出指标两层。指标含义理想值参考任务成功率任务正常结束无未捕获异常长期 98%产出一致率输出与源数据关键数值一致的比例 99%单步准确率Agent 每一步路由和工具调用是否正确 95%人工修正率产出是否需要人为修改后才能用 10%P95 执行时长95% 的任务在此时间上限内完成服从目标 SLA单任务成本每次任务的 token 和 API 调用成本越低越好但要兼顾质量这里最容易被低估的是“人工修正率”。哪怕 Agent 每次都成功跑完但报告里数字错了、语气不对、结论偏了使用者每天都要手工改一遍那这个 Agent 对业务的真实价值就大打折扣。所以效果验证一定要加人工评估环节让真实用户给产出质量打分。4.2 建设评测集与回归机制Agent 项目迭代很快今天改了一个 prompt 或换了一个工具很可能某个旧场景就坏了。所以必须有一套评测集跑回归。评测集不需要一开始就很大。我从 20 个典型任务开始包含正常输入、边界输入、异常输入三个类别。正常输入验证主流程边界输入验证日期切换、空数据、超长文本异常输入验证数据源超时、模型返回错误、工具调用失败。每一条评测都有一份 golden answer或者至少有一份关键字段清单用来判断输出是否达标。跑评测时我倾向于把 Agent 的执行过程和最终输出分开评估。执行过程看它路由是否正确、工具调用是否合理、有没有跳进无效循环最终输出看报告内容是否完整、数值是否准确、可读性是否合格。这两项不是强相关有的 Agent 过程七扭八歪但结果居然是对的有的过程漂亮结果全错分开评估才能定位问题出在决策层还是生成层。评测集的维护也要纳入日常开发流程。每次线上任务出现新问题第一时间把它加入评测集。这样可以避免同一个问题在下一个版本“死灰复燃”。4.3 长时间稳定性验证与故障注入无人值守任务的稳定性必须用长时间运行来验证。我一般会安排 7 天到 30 天的“浸泡测试”每天都跑真实的定时任务同时启动一套模拟数据源故意触发各种故障。故障注入是可靠性验证里最有效的部分。你可以做的实验包括让外部 API 在第 3 秒返回 500把数据库连接池打满让模型服务的响应时长突然变成 3 倍在任务执行中途杀掉进程再重启让两个任务实例同时启动看锁有没有生效。每一个故障场景都对应一条可靠性设计没验证过就等于没做。我还会观察 Agent 在连续运行后的状态漂移。比如第 1 天输出正常第 7 天因为上下文积累内容变多输出开始偏离标准格式。这种问题只靠单次测试发现不了必须靠长时间运行的监控数据暴露出来。还有一个容易被忽视的问题是外部依赖变更。Agent 依赖的网页结构、API 字段、数据表 schema 可能悄无声息地变化。所以要给定时任务加入“外部依赖变更检测”比如记录工具调用前后返回的字段集合如果字段集合出现大规模变化就标记为疑似变更触发告警而不是把错误结果继续往下游送。4.4 成本与延迟的量化评估Agent 任务的成本主要由 token 消耗、模型调用次数、外部工具调用费用三部分组成。无人值守任务频率高、无人盯守成本失控的风险比交互式任务更大。所以我建议每次任务都记录 token 数和费用定期做成本趋势分析。延迟方面我个人关注 P95 而不是平均值。因为平均值会被少数快速任务拉低P95 更能反映用户体验。无人值守任务没那么在意秒级延迟但也不能容忍任务执行时间越来越长。如果发现 P95 持续上升先检查是不是工具返回内容越来越大导致模型上下文越来越长。效果验证里还有一个实用技巧做 A/B 测试。同一个任务一部分流量用旧 prompt一部分用新 prompt运行几天后对比成功率和人工修正率。这样既能验证新方案的效果又能防止一次改挂全部任务。注意 A/B 测试的任务要打上版本标签否则你很难判断某个结果到底来自哪个版本。5. 实战复盘一次无人值守日报任务的完整落地5.1 需求定义与方案选型用一个实际项目把这些方法论串起来。需求很简单每个工作日早上 8 点半自动读取项目管理系统里的任务状态生成一份昨日进展日报格式是标题、摘要、关键风险、明日计划最后发送到企业微信群。这个任务看起来不复杂但无人值守的可靠性设计点一个都不少。我选了 Python APScheduler 做调度LangGraph 做 Agent 编排Redis 做分布式锁PostgreSQL 存任务状态。模型接的通用对话 API但用了一层抽象封装方便未来切换模型服务。任务流程设计成固定管道模式而不是完全让 Agent 自由发挥读取配置生成当日任务 ID。获取分布式锁防止重复触发。检查任务状态缓存避免同一天重复生成。从项目管理 API 拉取原始数据。Agent 分析数据生成日报结构。校验关键字段和数值。发送企业微信通知。更新任务状态和运行指标。虽然 Agent 有决策空间但流程主干是确定性的。这样保证即使模型偶尔跑偏也不会把整个任务带到一个完全不可控的方向。5.2 调度与执行代码参考调度层我用 APScheduler下面这段代码基本可以作为模板from apscheduler.schedulers.blocking import BlockingScheduler from apscheduler.triggers.cron import CronTrigger import pytz def daily_report_job(): # 真正执行任务的入口 task_id fdaily-report-{datetime.now().strftime(%Y-%m-%d)} run_agent_pipeline(task_id) scheduler BlockingScheduler() scheduler.add_job( daily_report_job, CronTrigger( day_of_weekmon-fri, hour8, minute30, timezonepytz.timezone(Asia/Shanghai) ), iddaily_report ) if __name__ __main__: scheduler.start()核心流程run_agent_pipeline里我会把 Agent 封装成一个可重试、可恢复的函数def run_agent_pipeline(task_id): if not acquire_lock(task_id): log.warning(task already running, skip) return try: state load_or_create_state(task_id) raw_data fetch_data_with_timeout() if raw_data is None: # 数据源失败时使用缓存数据并在报告里标注“数据可能延迟” raw_data load_cache_data() report agent.generate_report( raw_dataraw_data, task_configget_task_config(), max_retries2 ) validate_report(report) # 字段校验数值一致性校验 notify_webhook(report) update_state(state, statussuccess) except RetryableError as e: update_state(state, statusretryable, errorstr(e)) raise except NonRetryableError as e: update_state(state, statusfailed, errorstr(e)) alert_oncall(str(e)) finally: release_lock(task_id)这里最关键的是区分“可重试错误”和“不可重试错误”。数据源超时是可重试的模型输出格式错误在修正次数内也是可重试的但企业微信群配置错误、工具 schema 错误这类问题重试多少次都没用直接告警找人才对。5.3 验证结果与踩坑记录这个任务上线前我先跑了两周模拟测试。第一周每天手动触发但故意在特定时间把数据源调成超时观察 Agent 是否正常降级。第二周完全无人值守每天早上检查任务状态和报告质量。结果很有意思任务成功率从第一周的 90% 提升到第二周的 99% 以上。失败点主要集中在凌晨外部 API 短暂不可用以及模型偶尔生成不完整的 JSON。针对这两个问题我分别加了“缓存降级”和“JSON 自动修复”逻辑后面就稳定很多。踩过的坑也很有代表性。第一个是分布式锁的 TTL 设太短导致一次模型调用超过锁有效期同一时刻另一个实例又开始跑结果发了两条日报。后来我把锁的 TTL 改为任务目标时间的 3 倍并在 finally 块中显式释放。第二个是调度器时区问题容器默认 UTCcron 表达式没带 timezone导致任务在下午 4 点半执行。改成 Asia/Shanghai 后解决。第三个是模型上下文膨胀连续跑几天后Agent 把历史报告也塞进上下文导致输出越来越长。后来我在上下文里只放最近一次报告摘要问题立刻消失。5.4 常见问题速查表最后整理一份速查表都是无人值守 Agent 任务里最常见的坑现象排查方向处理方式任务没有按预期时间执行时区配置、Catchup 设置、Windows 电源计划统一 timezone开启错过后立刻启动任务重复执行分布式锁未生效、网络重放Redis 锁 唯一索引锁 TTL 合理设置Agent 执行终止且没有日志进程被 OOM、容器被回收、有人工 Kill增加退出信号捕获记录最后心跳时间模型输出偶尔不是合法 JSONprompt/schema 不明确用结构化输出 解析器失败后带着报错重试Agent 自我修正陷入死循环没有最大步数限制设最大循环步数超限后强制失败报告里数字对不上源数据变更、模型幻觉增加数值一致性校验不一致时拒绝发送无人值守后效果突然变差外部依赖变更、prompt 被无意修改固定版本号外部依赖变更检测无法加载 Agent 预设配置路径、版本兼容问题固定预设文件版本配置变更走发布流程我现在每次上线新 Agent 任务都会拿着这张表去逐条检查。有些坑只有踩过一次才能真正意识到它的严重性但如果你还没踩过先把表里的问题当成已知风险写进代码里。最后分享一个我自己的体会无人值守 Agent 的验收标准不是“能不能跑通”而是“跑挂了以后你多久能发现发现以后能不能快速恢复”。可靠性设计做的不是让 Agent 永远不犯错而是让每一次错误都可控、可追溯、可修复。按照这个标准去做才有胆量把 AI Agent 放在生产环境里真正无人值守。
阅读完成 · 觉得有帮助？
