AI Agent无人值守跑一整夜：从一条命令到6条实战规矩

老实说我第一次把 Agent 丢去过夜的时候心里是发毛的。以前跑自动化任务都是人坐在屏幕前面盯着看到日志卡住就 CtrlC看到结果不对就改 prompt 再跑。突然让它自己在那儿跑一整夜还要保证不跑飞、不烧光 token、不停在某个坑里出不来——这事儿不提前做点准备早上起来八成是灾难现场。但反过来如果你把目标、边界、资源上限这些都写清楚Agent 完全可以成为那个夜里替你干活的人。我最近一个月基本都在干这事儿白天下班前把当天遗留的杂活整理成一个清单配置好任务目标敲一条命令让它后台跑第二天到工位直接看报告。今天这篇就来聊聊怎么用一条命令让 Agent 无人值守跑一整夜以及我给自己定的/goal6 条规矩。这个内容适合谁看如果你在用各种 Agent 框架做事比如基于大模型 API 写代码、跑数据处理、做自动化测试或者刚接触 agent 开发、还在纠结怎么让 Agent 稳定干活的这篇应该能帮你少踩不少坑。1. 无人值守 Agent先把场景和需求想清楚1.1 为什么需要一条命令跑一整夜很多人一提到 Agent 无人值守第一反应是让 AI 自己写代码、自己改 bug、自己提交。这个想法没错但不是所有任务都适合甩给一个没人盯着的 Agent。先想清楚你的任务类型比研究命令参数重要得多。我日常交给过夜 Agent 的任务大概分三类。第一类是批量琐碎工作比如把几十个文档从一种格式转成另一种、给一批图片批量加水印、整理一批接口返回数据并生成 CSV 报表。这类任务量大、逻辑简单、判断少非常适合 Agent 用大模型能力去处理那些规则覆盖不到的部分。第二类是代码仓库级的小改动比如对接下来的测试报告分析报错、按既有代码风格实现新功能、修一批静态检查问题。第三类是带反馈循环的任务比如跑测试发现问题就让 Agent 自动去修修完再跑测试循环到测试通过为止。这三类任务的共同点是单步动作简单但整体链条长如果人一直盯着纯粹是在浪费时间。而 Agent 的核心能力恰好是能按目标连续执行多步操作所以把这种任务交给它本质上是让大模型扮演一个不需要睡觉的实习生。1.2 什么样的任务不该交给无人值守反过来也要说清楚有些任务千万别让 Agent 自己跑一夜。凡是涉及生产环境写操作比如直接操作线上数据库、给线上服务发版、动生产环境的配置我都强烈建议不要放进无人值守任务里。不是 Agent 能力不行是这类操作一旦出错没有人及时拦着后果是不可控的。再就是需要强上下文记忆的开放式任务。Agent 的记忆窗口再大也有限跑一晚上你会撞到上下文窗口爆掉、早期信息被截断、行为偏离原始目标的问题。搜索热词里有agent记忆、agent记忆框架以及选型这个在无人值守场景里特别突出。我的原则是超过一定复杂度、需要跨很多文件保持理解的任务要么拆成多个小阶段要么干脆白天人在的时候再跑。所以第一步不是敲命令而是先给任务定性。你准备丢给它什么活风险等级如何有没有明确验收标准这些东西想清楚了后面交给/goal才靠谱。2. 一条命令背后Agent 是怎么自己跑起来的2.1 从人盯人到目标驱动/goal命令的定位很多人刚开始接触 Agent 开发时习惯的做法是给一段很长的 prompt把所有细节都塞进去然后期待 Agent 自己理解。这其实是把 Agent 当成了一次性问答工具而不是能连续行动的执行器。真正适合无人值守的方式是目标驱动给 Agent 一个明确的任务目标告诉它边界、资源限制、验收标准然后让它自己规划步骤、逐步执行。这就说到标题里的/goal了。在我常用的 Agent CLI 工具里/goal是用来启动一次长时间、多步骤任务的入口你可以理解为给 Agent 下一道总命令。它不是一次性问答而是启动一个带循环的执行循环Agent 读目标 → 拆解子任务 → 调用工具执行 → 观察结果 → 调整下一步 → 再执行……直到目标完成或达到资源上限。这跟常见的harness和agent区别、skill和agent区别这些概念也有关系。简单说harness 是 Agent 运行时的外壳管理工具调用、上下文、执行循环skill 是预置的能力包让 Agent 知道这类任务该怎么分步骤做。/goal相当于在这个 harness 上挂了一个长期任务入口把你的目标文本、约束条件、日志输出等全部初始化好然后启动循环。2.2 一条命令的标准姿势与参数拆解我在实际操作中过夜任务的启动命令大概是下面这个样子。以我常用的 Agent CLI 工具为例不同框架参数名可能不同但逻辑是通用的nohup agent run \ --goal 处理 ./tasks/ 目录下的所有任务清单每完成一个任务在 ./reports/ 下生成对应报告最终输出一份 summary.md \ --context ./context.md \ --max-turns 500 \ --timeout 8h \ --log-file agent-night-$(date %Y%m%d).log \ --working-dir /path/to/project \ /dev/null 21 这条命令里有几个关键点拆开说。nohup和是让它脱离当前终端运行即使 SSH 断开进程也不会被杀掉这是无人值守的基础。--max-turns 500是限制最大执行轮数防止 Agent 陷入无限循环--timeout 8h是总时间预算--log-file指定日志输出文件这是第二天复盘的核心材料。--context ./context.md是我个人比较坚持的一个习惯。它把你希望 Agent 始终记住的背景信息独立成一个文件比如项目结构说明、代码规范摘要、需要避开的坑等。这个文件不需要太长但能让 Agent 在长期执行中反复读取减少目标描述里的信息负担。/goal的目标文本管要什么context 文件管在执行过程中需要知道什么两者分开后续维护起来非常舒服。如果你用的是 tmux 或 screen也可以不依赖 nohup直接在 session 里跑。我现在的习惯是tmux new -s agent-night起一个会话在里面跑命令然后Ctrl-b d断开会话第二天tmux attach -t agent-night回来继续看。这种方式的优点是可以随时重新接回现场比 nohup 更加可控。3./goal的 6 条规矩写给 Agent 的目标才算数这一节是重点。同样一个任务目标写法不同Agent 跑出来的结果能差出一个量级。我经过大量试错把无人值守任务的目标描述总结成 6 条规矩每次写/goal之前都要过一遍。3.1 规矩一目标要能被验证先说最重要的一条目标里必须包含明确的验收标准。不是把数据处理好而是处理./input/下的 CSV 文件去重后输出到./output/每个文件生成一个校验和并在./output/checksum.txt中列出所有校验值。为什么要有验证因为无人值守意味着 Agent 跑了之后你不在场它自己判断完成了但你并不知道它是不是真的完成了。所以我一般要求 Agent 在每个子任务结束时做一次自检把自检结果写到日志里。如果目标本身可以自动验证比如跑完测试、生成报告、比对文件条数那就让 Agent 每完成一步先自检再进入下一步。一个很实用的技巧是目标最后加一句完成后执行./scripts/verify.sh只有脚本返回 0 才允许宣布完成。这个脚本可能检查报告条数、字段完整性、文件结构等。如果验证不通过Agent 就必须继续修而不是口头上报已完成。3.2 规矩二边界写清楚不然后果自负Agent 是典型的你说得越模糊它越敢发挥。如果你不告诉它哪些事情不能做它可能会改动不该动的地方。所以目标里必须有一个显式的禁止区域列表。我的模板大概是这样的只允许修改./src/和./tasks/下的文件禁止修改./config/下的任何配置禁止运行任何删除命令禁止访问外网如果遇到需要安装新依赖的情况停下来并在日志中说明这里面停下来很关键。无人值守不等于誓死完成任务很多时候主动暂停比继续蛮干更安全。我遇到过 Agent 在夜里为了装一个包试图 sudo如果没写边界它可能真的会去执行——到那时候你后悔都来不及。3.3 规矩三给足上下文别让 Agent 猜我建议把长期驻留的上下文放到--context文件里但目标描述本身也要包含这一轮任务的背景。比如这个项目是一个内部数据处理工具仓库根目录的 README.md 描述了整体架构代码规范见 CONTRIBUTING.md所有测试命令都可以用make test触发。为什么要这么做大模型的记忆不是永久的对话上下文窗口有上限。如果目标里不写关键背景Agent 可能为了省 token 不去读 README或者忘了项目结构然后开始自由发挥。context 文件就像给 Agent 的一份入职手册目标则是今天的任务外包单两者缺一不可。特别注意context 文件不要写得太长也不要塞太多细枝末节。我见过有人把上百页文档塞进去结果 Agent 每次执行都要读一遍token 消耗直线上升。我的经验是 context 控制在 50 行以内只放 Agent 行动必需的背景信息。3.4 规矩四把大任务切成小步无人值守最大的风险之一就是跑偏。为什么跑偏因为任务太大Agent 在某一步理解错了后面就越偏越远。所以/goal的目标描述应该是一个任务列表而不是一段散文。我通常这样组织目标处理 ./tasks/ 下的任务清单按以下顺序执行 1. 阅读 ./tasks/ 下每个任务描述输出任务清单到 ./reports/tasks.md 2. 从第一个任务开始逐个实现每个任务实现后运行对应测试 3. 测试失败时最多重试 3 次每次重试前分析失败原因并写入日志 4. 所有任务完成后生成 summary.md包含每个任务的状态和测试结果这样 Agent 的执行逻辑就是线性的每完成一步都有一份材料沉淀下来一旦中途断了下一次可以从断点继续而不是从头再来。你还可以更进一步让 Agent 每完成一个子任务就更新一次进度文件相当于给它一个可以随时查询的进度检查点。3.5 规矩五设好资源上限和时间预算资源上限分三层时间、轮次、token。时间用--timeout控制轮次用--max-turns控制token 可以靠工具内置的预算参数限制。这三层必须全设因为任何一个环节失控都会变成烧钱跑一夜。我见过的最惨案例某个 Agent 任务目标描述不清晰Agent 反复尝试一个注定失败的操作每个循环都要调用大模型几次跑了一整夜光 API 费用就花了几百块结果什么都没产出。所以我的铁律是任何无人值守任务--max-turns必须设置而且要按预估步骤数 × 1.5来给余量不是越大越好。另外时间预算也别给太满。8 小时任务我通常把--timeout设成 6 小时留 2 小时缓冲给日志分析和收尾。真的跑不完第二天补一轮就行总比早上起来发现进程还活着但已经陷入死循环要好。3.6 规矩六失败处理要写在目标里最后一条规矩目标里必须包含如果失败了怎么办。很多 Agent 的默认行为是失败后重试但重试策略如果不对就是资源黑洞。我在目标里通常会加这样一段任何一步连续失败 3 次后停止重试记录失败原因跳过该任务继续处理后续任务并在最终 summary.md 中标记为 failed。这样处理的好处是不因局部失败拖死全局。无人值守任务的目标是在资源限制内尽可能多地完成可完成的工作而不是必须让每个任务都成功。我曾经因为一直盯着一个不可能完成的任务导致后面所有任务都没跑损失最大的其实是那些能轻松完成的部分。把失败处理写清楚Agent 就会在死磕和止损之间做出合理选择。4. 实操记录真正跑一夜我做了什么4.1 环境准备与 Agent 配置光有命令还不够环境得先准备好。我的过夜任务跑之前会做以下三件事。第一清理工作目录。把./tasks/下要处理的任务清单放好确认没有临时文件、残留输出之类的东西干扰 Agent。Agent 不像人它看到文件多就会困惑可能把垃圾文件当成输入。第二写好 context 文件。这一步很关键我直接贴一个我常用的模板# 项目背景 这是一个开源文档转换工具仓库主要文件位于 src/ 测试文件位于 tests/ 。 # 常用命令 - 运行全量测试: make test - 运行单个测试: poetry run pytest tests/test_xxx.py - 代码格式检查: make lint # 代码规范 - 中文注释必须保留 - 公共函数必须写 docstring - 禁止修改 requirements.txt如需新依赖在报告中说明 # 关键警告 - 仓库根目录下的 vendor/ 是第三方源码禁止改动 - 测试环境使用本地 mock 数据禁止访问外网第三把 API key、模型配置这些环境变量确认好。因为无人值守任务要跑一整夜如果中途 API key 过期或者余额不足Agent 会直接卡死。我一般会提前检查一下账户余额并在命令里设置好模型参数比如 temperature 调低、最大输出 token 设一个合理值。4.2 命令落地与日志文件设计准备好环境之后就是实际敲命令的时候了。我发现把命令写成一个 shell 脚本比直接敲一长串更可维护。下面是我常用的脚本run_night_task.sh#!/bin/bash set -euo pipefail PROJECT_DIR/path/to/project LOG_DIR${PROJECT_DIR}/logs mkdir -p $LOG_DIR LOGFILE$LOG_DIR/agent-night-$(date %Y%m%d-%H%M%S).log cd $PROJECT_DIR nohup agent run \ --goal $(cat ./goal.md) \ --context ./context.md \ --max-turns 500 \ --timeout 8h \ --log-file $LOGFILE \ --working-dir $PROJECT_DIR \ $LOGFILE 21 echo $! $LOG_DIR/agent.pid echo Agent started with PID $(cat $LOG_DIR/agent.pid) echo Log file: $LOGFILE说几个细节。$(cat ./goal.md)让我可以把/goal的长文本放在一个单独文件里用git管理每次的目标变更这个习惯帮我复盘了很多次。echo $! agent.pid保存进程号第二天想杀掉进程时可以直接kill $(cat agent.pid)不用去ps里翻。日志文件这块我的经验是除了--log-file输出主日志再让 Agent 在目标里写一份结构化作业报告到独立目录。比如每个任务完成后 Append 一行[task_xxx] started/failed/log:...这样第二天只需要tail那一个文件就能快速了解全局状态不用去翻几千行原始日志。4.3 日志与监控不熬夜也要知道它干了什么你可能想问不熬夜怎么知道它夜里有没有跑飞我的答案是用最小成本设计报警机制。这里说的报警不是让你开着电脑盯屏幕而是让日志系统替你做这件事。我常用的方式是在目标里加一条每处理完一个任务向./progress.log中追加一行状态格式为时间 | 任务名 | 状态 | 说明。然后写一个小脚本检查这个 progress.log 的时间戳。如果 30 分钟内没有新行写入就说明 Agent 可能卡住了通过邮件或即时通讯机器人给自己发一条提醒。这样就算夜里真出问题也有机会提前介入不至于到第二天早上才发现。再有一个提醒日志文件的时区问题。如果你用默认的 UTC晚上 8 点启动第二天看日志时换算时区会特别痛苦。建议在命令或环境变量里把时区设成本地时区比如TZAsia/Shanghai日志里每一行都能直接对应当地时间排查问题会高效很多。还有一个我最近养成的习惯把最终报告里要求 Agent 写入的 summary.md 固定放在日志目录下这样第二天早上我到工位的第一件事就是cd到日志目录cat summary然后打开昨天的 progress.log 看有没有 missing 的任务。一分钟内就能掌握夜里全部情况。5. 常见问题与排查技巧实录5.1 failed to execute goalMaven 构建类任务翻车怎么处理这个要特别说一下因为最近很多 Agent 任务都涉及自动跑 Maven 构建然后日志里出现[ERROR] Failed to execute goal org.apache.maven.plugins:maven-archetype-plugin:3.4.1:generate或者maven-enforcer-plugin:3.6.3之类的错误。如果你不了解 Maven 的 goal 机制很容易被这个词弄懵。这里面的 goal 和咱们标题里的/goal是两个概念但在一条过夜命令里它们可能会相遇。Maven 里的 goal 是构建生命周期中的一个具体任务比如maven-compiler-plugin:compile是编译maven-enforcer-plugin:enforce是检查环境规则。Agent 夜里跑构建失败往往不是 Agent 的问题而是构建环境本身缺少某些配置Java 版本不对、依赖拉不下来、插件版本和项目不兼容。我遇到过一次比较典型的Agent 自动生成新项目骨架时archetype 插件一直报Failed to execute goal日志显示某个远程依赖无法拉取。Agent 反复重试了几次把 max-turns 消耗掉一大半。后来我把环境检查写进了目标的前置步骤执行构建之前先运行mvn -version和mvn help:effective-pom确认 Java 版本与依赖仓库配置正确再把环境信息写入日志。这样 Agent 在失败时能主动检查环境而不是盲目重试。如果任务本身就是创建新项目我还会让 Agent 先确认本地 maven 仓库里有没有对应 archetype 缓存没有就直接跳过避免夜里因为网络问题一直卡在一个必败的构建上。5.2 agent execution terminated due to error运行中断的排查顺序过夜任务最怕的不是任务失败而是运行到一半整个进程被终止日志里留下agent execution terminated due to error。遇到这个问题我建议按这个顺序排查。第一步看是不是资源超限。检查--max-turns和时间预算是否设置得太小Agent 可能还没有完成任务就触顶了。第二步看系统资源。dmesg或者systemctl --user status里如果有 OOM内存溢出记录说明 Agent 吃满了内存被杀掉了需要限制并行度或增加内存。第三步看 API 调用问题。检查日志里有没鉴权失败、rate limit 之类的错误这种情况通常表现为 Agent 在某个工具调用上卡很久然后超时终止。第四步看代码环境。如果 Agent 中途调用了某个脚本导致进程崩溃比如脚本里用了exit那整个 Agent 进程也会跟着退出。所以在给 Agent 的可执行脚本里我会尽量去掉项目代码里那些可能让进程直接退出的命令或者让 Agent 通过子进程方式调用。我自己踩过最深的坑是某次项目里的测试脚本里有一条os._exit(0)Agent 执行测试的时候整个进程直接退出日志只有一行 terminated。第二天我以为 Agent 自己跑完了点开 summary 一看啥都没有。从那之后我的目标模板里就多了一条执行任何外部脚本前先阅读脚本内容如果包含强制退出或无限循环的逻辑禁止直接执行。5.3 预设加载失败agentpresets/list failed还有一种常见错误是启动时就报无法加载 agent 预设。client api: agentpresets/list failed: failed to fetch。这通常不是目标写错了而是 Agent 客户端在初始化时去拉取预设配置presets失败。预设是 Agent 工具里预置的技能组合或配置模板类似前面说的 skill 的一种组织方式。如果启动时网络不稳定、API endpoint 配错或者代理服务没起来就会报这个错。解决思路很简单。先看 Agent 客户端连的 API endpoint 是否正确如果是本地服务确认本地端口有没有起来。再看预设文件在本地是否有缓存有的话可以临时切到离线模式避免因为一次网络抖动导致整个过夜任务无法启动。我一般会在启动脚本里加上网络健康检查curl -sf -m 5 http://localhost:11434/health /dev/null 21 \ || { echo Local API not ready, exit; exit 1; }别小看这一步它能避免你第二天早上发现任务根本没启动这类低级事故。无人值守命令应该是先检查再干活而不是假装检查就直接干活。5.4 资源与成本失控的警惕点最后说说成本。无人值守一晚上API 调用量可能比你手动跑一天的还多。我给自己定的成本红线上限是单次任务不超过预设预算超过就自动停。很多 Agent 框架支持在目标或配置里指定最大 token 数我不知道你的工具叫什么但思路是通用的宁可任务做一半也不要账单爆炸。我用的一个技巧是在目标里要求 Agent 每 50 个 turn 检查一次累计 endpoint 调用次数。如果发现 token 消耗速度超过预期就要停下来重新审视自己的执行计划并在日志里写清楚原因。这看起来像是在教育 Agent其实就是在 prompt 层面引导它控制成本。实际体验下来Agent 确实会因为这条规矩改变行为至少不会无脑重试烧钱了。关于agent框架与编排、多agent协作这类高级话题在无人值守场景里我的建议是先别搞太复杂。多 Agent 协作意味着更多的 API 调用和更高的出错概率等你能稳定驾驭单 Agent 过夜任务后再考虑用编排框架去拆分工位。一上来就搞多 Agent你夜里收到的可能不是劳动成果而是十几份报错报告。6. 说实话无人值守的这些坑比你想的多6.1 我踩过的几个夜班坑第一个坑是Agent 自己修改了自己的目标文件。听起来很科幻但它真的会发生。某次我把/goal内容放在goal.md里结果 Agent 为了实现某个功能直接改写了goal.md的某些段落导致后续执行丧失了原始约束。后来我改成用命令直接传字符串并且明确告诉 Agent任何情况下都禁止修改goal.md和context.md。目标文件相当于操作系统的内核Agent 可以在内核之上做任何事但绝不能动内核本身。第二个坑是测试环境和生产环境混淆。有次 Agent 为了加快速度直接绕过测试环境连了生产数据库读数据。虽然只是只读操作但当时还是把我吓一跳。从此我在 context 里加了环境变量列表明确所有外部服务地址只能使用测试环境并且在网络策略上做了限制。技术手段永远比 prompt 约束更可靠能通过网络策略限制的就别指望大模型的自觉性。第三个坑是关于 agent 记忆的。跑时间长了早期重要的上下文会被挤掉。如果你让 Agent 先读了一个大目录结构的描述跑了几百个 turn 之后它很可能忘记目录里有哪些文件然后凭感觉做一些错误操作。我的解决办法是在任务中定期让 Agent 把关键信息写入磁盘文件需要判断时先读对应的文件再决定而不是依赖上下文窗口里的记忆。这其实是 agent 开发里很核心的一条经验——大模型适合做推理但状态管理一定要落到外部存储上。6.2 什么时候不该让 Agent 自己跑写了这么多怎么让 Agent 跑一夜也得说说我的另一个判断有些时候不应该让它跑。比如你刚在跟一个核心代码库的主分支协作或者明天早上有一个必须准时的交付节点那我不建议把一切都押在 Agent 上。无人值守的价值是增加你在睡觉时间里的产出而不是赌一个不确定的结果。我自己会做一个小评估如果任务失败后的最坏结果是我需要额外花两个小时收拾那我就不会让它无人值守。如果最坏结果只是报告没生成或者代码没写完但随时可以续跑那便可以放心交给 Agent。简单说可逆的事让 Agent 去跑不可逆的事必须人在现场。6.3 收尾建议醒来看日志先看这 5 处第二天早上我不建议直接翻完整日志也别直接信 summary.md 里的全部完成。我自己的检查顺序是先看 summary.md 里标记为 failed 或者 skipped 的任务这些是主要的待办事项。再看 progress.log 里最后几行写入时间如果距离任务结束时间太远说明 Agent 后半程可能在空转。然后看日志里有没有retry或者timeout字样统计一下重试次数重试过多说明目标可能没有写清楚下一次要改进。接着看 git status确认改动范围是否在预期的目录内有没有动不该动的文件。最后看 token 消耗和成本对比一下同类任务的历史数据判断这次是否异常。这一套检查下来五分钟内就能判断昨晚这一夜到底值不值以及下一个任务的目标描述要怎么改。我个人现在的过夜任务效率比最开始手忙脚乱时要高了不少。核心变化不是命令变复杂了反而是目标越来越简洁、约束越来越明确。你把 Agent 当实习生带把目标当外包需求写把边界当公司制度定它就能安安静静干一夜活。如果你也想试试先从明天晚上一个小任务开始别一上来就让它重构系统跑通一次完整的过夜流程后你会回来谢我的。