去年有一次我把一个数据清洗任务丢给Agent去跑原以为最多半小时就完事结果它中途调用了一个远程接口每轮要等十几秒前后折腾了快三个小时。我中途不敢关电脑一直守着聊天窗口困得不行又怕错过它的提问。后来我想明白一件事Agent这种需要多轮推理、反复调用工具的长任务本质上就不该让人一直盯在那里等。人只需要在任务开始前把话说清楚然后一键启动第二天醒来收结果。真正解决这个问题的是一条启动命令外加一套写给Agent的“目标说明书”也就是 /goal 的六条规矩。这篇文章就把这两样东西完全拆开讲命令每一步在做什么、为什么这样写/goal 到底怎么定才不会让Agent跑偏以及我连续跑了一整夜之后踩过的那些坑。如果你也玩Agent、做自动化流程、或者经常需要让模型替你处理批量任务这篇可以直接当模板用。1. 为什么Agent需要“无人值守”模式1.1 盯在那里等结果是Agent使用最大误区很多人一开始用Agent习惯跟聊天工具一样发完问题就一直等回复。问题是Agent不是一次问答就结束的东西。尤其是装了一堆工具、技能skills之后的Agent它会规划、拆步骤、写代码、执行命令、读输出、发现问题再改代码整个链路可能是几十轮甚至上百轮。每一轮如果有工具调用耗时少则几秒多则几分钟。你算一下一个稍复杂的任务跑一两个小时非常正常。这时候人守着聊天窗口本质上就是浪费。你盯着它它也不会跑得更快你不盯着它反而可能在后台安静地干活。但这种“放手”需要一个前提你能确保Agent在无人看管时不会自己跑偏也不会因为一次偶发报错就停在原地。换句话说无人值守不是把Agent丢在那里就行而是要让它在没有人工介入的情况下仍然有足够的输入信息来自己做决策。这个输入信息就藏在你的任务描述里。1.2 无人值守的底线能重启、能留痕、能验收我理解的无人值守至少要有三条底线。第一条是能重启。会话断了、进程被杀了、电脑休眠了任务不能因此直接报废。所以启动方式一般会选择后台运行或独立会话让它不依赖你当前那个终端窗口。第二条是能留痕。Agent 每一步做了什么、中间生成了什么文件、报了哪些错都要有日志和中间产物。否则第二天你醒来只看到一个“任务完成”四个字什么过程都没有你敢信它真的干对了吗第三条是能验收。任务开始前就要定义好“什么叫做完”并且让Agent把结果写到固定位置比如一个报告文件、一份结果表、一张图。早上起来你只需要去那个位置看有没有文件、内容对不对就知道这一夜有没有白跑。想通这三点之后你就会明白真正的核心其实不是“命令写得多花哨”而是你给Agent的目标描述到底够不够清楚。命令只是负责把任务放到一个可以过夜的环境里目标描述才决定它这一夜干的方向对不对。2. “一条命令”起作用的完整拆解2.1 先看这条命令长什么样我常用的启动方式是这样nohup python run_agent.py \ --goal-file goals/night_task.md \ --resume \ --save-every 50 \ --max-steps 300 \ --log-dir logs/$(date %Y%m%d-%H%M%S) \ /tmp/agent_night_run.log 21 前面nohup保证进程在你退出终端后继续跑结尾的把它放到后台。中间几个参数--goal-file指定任务说明文件也就是 /goal 写在哪里--resume表示如果之前有断点从断点继续--save-every 50是每50步自动保存一次状态--max-steps 300是兜底上限防止它真的跑一整夜不收尾--log-dir单独存一份结构化日志目录方便第二天排查。有些Agent框架还会你给--headless或--non-interactive这类参数意思是不需要人工确认Agent自主决策。这类参数在无人值守时很重要否则半夜它弹一个“是否继续”的确认框没人点就一直卡着。2.2 为什么用nohup而不是直接后台运行直接python run_agent.py 虽然也会进入后台但它有个坑这个进程还是当前终端会话的子进程一旦终端关闭、断网、或者终端程序退出系统会向这个进程发送挂断信号进程大概率直接退出。这就相当于你已经把任务放进烤箱了结果厨房断电菜就废了。nohup的作用恰恰是忽略这个挂断信号。它让进程脱离终端生命周期终端退出之后它照样跑。这是最基础、最稳妥的后台运行方式几乎没有学习成本。如果你需要反复查看执行进度我更推荐用tmux它是真正的“虚拟终端会话”方案。先tmux new -s night-agent创建一个名为 night-agent 的会话然后在里面正常执行命令之后按Ctrlb再按d退出会话任务继续跑。第二天你想看进度一个tmux attach -t night-agent就能直接回到当时的画面甚至能看到Agent最后的输出残留。对爱折腾的人tmux体验比nohup好太多。2.3 日志和会话管理第二天怎么接管现场无人值守跑完一夜最怕的就是“看起来在跑但实际上早就死掉了”。我一般会同时开三个信息源来监控标准输出日志也就是命令里重定向的/tmp/agent_night_run.log看最后几行就知道当前状态Agent自身的结构化日志目录logs/20250617-230011/这类路径下会按轮次记录每一步的工具调用、输入输出每隔一段时间用ps aux | grep run_agent看一眼进程是否还活着或者用tail -f实时跟踪日志末尾。第二天验收时我的固定动作是先看进程在不在再查日志最后一条是不是“任务完成”最后直接打开结果文件目录看产物。三步下来基本一分钟就能判断这一夜到底跑没跑出东西来。3. 写给Agent的“目标说明书”/goal 的六条规矩我把给Agent的完整任务目标固定以/goal开头。这不是什么特殊命令只是我给自己定的一种格式规范。真正起作用的是后面六条规矩。少了哪一条任务都可能跑偏六条都齐了基本能做到“剑及履及”。3.1 第一条目标必须写到“可验收”而不是“可理解”很多人写目标是写给人类看的比如“帮我分析一下用户数据”。这句话人懂但Agent很难精确执行因为“分析”和“用户数据”都太模糊。真正合格的目标要写成可验收的形式。差的目标分析用户数据。好的目标读取 data/user_log.csv统计最近7天每日活跃用户数去重 user_id输出 Markdown 报告到 reports/dau_report.md报告里包含日期、活跃用户数、环比变化率并指出变化最大的那一天及可能原因。同样一件事第二种写法把输入文件、计算口径、输出路径、报告结构全部讲清楚了。Agent执行时每一步都知道自己在做什么、做完了怎么算通过。这背后的原理很简单Agent的规划能力和目标清晰度强相关你把验收标准写得越具体它就越不容易在中间环节自由发挥。3.2 第二条拆成带检查点的小步骤不许一口气做完我见过太多Agent跑着跑着就开始自作主张原因就是任务太大、它自己拆的步骤太粗。比如“写一篇行业报告”它可能直接跳到最后一步开始输出完全跳过数据收集和验证。解决方法是任务描述里主动给它拆阶段而且每个阶段都要有中间产物。我常用这种表达请按以下阶段执行 阶段1读取 data/raw/ 目录下所有 CSV 文件输出 data/cleaned/ 下清洗后的文件并在 logs/phase1.txt 写一行“完成” 阶段2基于清洗后文件计算月度汇总输出 reports/summary.csv 阶段3把 summary.csv 渲染成图表输出 reports/chart.png 每个阶段完成后检查产物文件是否存在再进入下一阶段。只有当上一阶段产物缺失时才可以回头补充处理。加上“先检查再往后走”这句Agent就不会一口气闷头干到底。每个阶段结束它会自己确认一下有没有真正产出文件。这大大降低了“中间错一步、最后全盘错”的概率。3.3 第三条划清边界与禁区给Agent一张“安全围栏”Agent很容易出现“好心办坏事”。比如目的是清洗数据它却顺手删掉了原始文件让它分析日志它却去访问外网下载依赖包。无人值守时没人拦着这种越界行为可能一整夜都在悄悄发生。所以 /goal 里必须明确边界。我一般会写一段“允许与禁止”允许使用工具文件读写、Python 脚本执行、数据可视化。 禁止操作删除 data/raw/ 下任何文件不得执行 pip install不得修改系统配置文件不得访问外部网络接口如果必须执行以上操作停止任务并在 logs/blocked_action.txt 里说明原因等待人工处理。这段像是“安全围栏”把Agent的活动范围圈起来。它不是一个死板的限制而是给Agent一个判断依据。遇到模糊情况时Agent会先看这里能不能做不能做就停下来留痕而不是默认自己可以做。3.4 第四条错误处置要“先自救、再上报、最后止损”Agent跑长任务几乎一定会遇到报错。关键不是让它不犯错而是让它在犯错时不要无限重试也不要轻易放弃。我有一条固定表达遇到错误时先尝试最多 2 次不同的修复方案如果仍失败停止重试将完整错误信息和当前进度写入 logs/error_report.md并保存所有已生成的文件然后正常退出不要继续执行后续步骤。很多Agent框架默认遇到报错就不断重试一直试到步骤上限或者进程被杀。你在旁边时能拦住它无人值守时没人拦它可能凌晨三点起就开始同一个报错刷屏刷到天亮。“先自救”是给它空间去正常处理小问题“再上报”是让错误信息有地方落地“最后止损”是保留已完成的产物避免因为后半段失败导致前半段白干。这三层逻辑一定要写全不能只写“出错就退出”那样太脆弱半夜任何一个不重要的小波动都会让整夜任务白费。3.5 第五条每个阶段都要主动留痕把中间产物写下来无人值守任务最害怕“黑盒”。Agent 如果只在结束时报一句“完成了”中间发生了什么完全不知道你就只能无条件相信它。对于重要任务这不够。我会在 /goal 里强制要求留痕每完成一个步骤在 logs/progress.md 里追加一行记录格式为“时间 - 步骤名 - 产物路径 - 状态”。整个任务结束时写一段不超过 300 字的执行摘要包含最终产物清单和未完成事项。这样一来Agent每一步都在“留下脚印”。第二天如果发现结果不对你可以顺着 progress.md 回查是哪一步出了问题。而且这个留痕动作本身对Agent有约束效果它会感觉有人会来检查因此执行时会收敛很多。3.6 第六条把退出条件写在最前面少一个都不算完成最后一条规矩是很多新手最容易忽视的定义清晰退出条件。没有退出条件的Agent要么提前收工要么永远不结束。这两种情况我都遇过。提前收工通常是它觉得自己“已经做得差不多”了永远不结束则是陷入某种循环。我的写法是任务完成的唯一标准reports/ 目录下同时存在 dau_report.md、summary.csv、chart.png 三个文件并且 progress.md 最后一条记录为“阶段3完成”。满足这些条件后输出完成消息并停止。如果步骤数达到上限仍未满足输出失败报告并保存已有文件。为什么说“唯一标准”因为Agent经常会把“完成了大部分”理解成“全部完成”。当你把退出条件和具体文件绑定在一起它就没有太多模糊空间三个文件都存在才算完少一个就得继续。这本质上是在帮Agent纠正它对“完成”这个词的理解偏差。4. 实操现场一条命令跑通整夜任务4.1 准备目标文件一个可以直接抄的/goal模板纸上谈兵没用我这里直接给一套可以在真实项目里改一改就能用的模板。目标文件我命名为night_task.md内容长这样/goal 任务 1. 读取 data/logs/ 目录下的所有 .log 文件。 2. 解析每行日志中的时间戳、级别INFO/WARN/ERROR和消息内容。 3. 按时间排序统计每小时 ERROR 出现次数输出 reports/error_count.csv。 4. 把 error_count.csv 绘制成折线图输出 reports/error_trend.png。 5. 在 reports/summary.md 里写一段 200 字以内的结论指出 ERROR 最多的时段和可能原因。 执行阶段 - 阶段1解析日志输出 data/parsed_logs.csv。 - 阶段2统计小时级 ERROR 次数输出 reports/error_count.csv。 - 阶段3绘图输出 reports/error_trend.png。 - 阶段4写报告输出 reports/summary.md。 每个阶段完成后检查产物文件是否存在再进入下一阶段。 允许范围 - 允许进行的操作文件读取、Python 解析、Pandas 处理、Matplotlib 绘图。 - 禁止操作删除原始日志文件执行网络请求安装新依赖包。 - 如果必须执行禁止操作停止任务在 logs/blocked_action.txt 中记录原因。 错误处理 - 遇到解析错误时先尝试 2 次不同的修复方案。 - 仍失败则停止重试把完整错误信息写入 logs/error_report.md保存已生成文件后正常退出。 留痕要求 - 每完成一个阶段在 logs/progress.md 追加一行时间 - 阶段名 - 产物路径 - 状态。 - 任务结束时在 logs/progress.md 末尾写执行摘要。 退出条件 - 唯一完成标准reports/ 下同时存在 error_count.csv、error_trend.png、summary.md。 - 达到 max-steps 仍未满足输出失败报告并保存已有文件。这个模板不是让所有任务都这么写而是当你不确定某类任务该写多少细节时套这个结构基本不会出大问题。4.2 启动参数怎么定模型、步骤上限、保存间隔目标文件就位之后启动命令需要配合几个比较关键的后台参数。第一步是选模型。长任务无人值守建议选上下文窗口大、稳定性好的模型别选那些回复虽然快但经常截断的小模型。夜里没有人处理它中途的“失忆”问题上下文窗口越大后半程跑偏概率越低。第二步是步骤上限。--max-steps是兜底保险具体数值要看任务复杂度。日志解析这种任务50到100步通常足够如果是让Agent做多阶段数据分析、写代码、调Bug建议给到200到300步。上限太低会误杀正常任务上限太高又可能出现凌晨三点还在空转。我的经验是白天先用当前任务量跑一遍小样本记录真实步数再乘以1.5到2倍作为夜间上限。第三步是保存间隔。--save-every这个参数决定Agent每隔多少步保存一次断点状态。太频繁会拖慢速度太稀疏则丢失进度较多。对于大多数任务50步保存一次是比较合理的平衡点。这样即使中途进程死掉最多也只损失50步的工作量。4.3 夜间验收早上起来怎么快速判断有没有跑成功一夜之后打开终端第一件事我建议养成固定检查顺序# 1. 看进程是否还在 ps aux | grep run_agent # 2. 看日志最后一段 tail -50 /tmp/agent_night_run.log # 3. 看产物目录 ls -la reports/ cat logs/progress.md三个命令三十秒情况基本就清楚了。正常情况是进程已经消失说明正常退出日志尾部有完成字样reports/ 下三个文件齐全progress.md 最后一条对应阶段4完成。异常情况多半是进程还在但日志已经几十行没更新过说明可能卡住了进程消失但报告中只有失败说明或者产物文件缺了某一个。遇到这些情况按下一章的方法来排查就行。5. 一夜跑下来最常见的五种翻车现场5.1 第二天发现日志是空的日志完全为空多半不是Agent的问题而是启动环节就出错了。最常见三种原因命令里--goal-file路径写错目标文件没找到Python环境缺依赖import 阶段就抛异常或者启动命令被某些shell配置影响根本没真正跑到Agent入口就报错退出了。排查方法很简单先在终端前台跑一次带--max-steps 1的短任务不要加nohup和直接看标准输出。如果前台能正常打印日志再切后台。这个动作能过滤掉80%的“启动即失败”问题。提示不要一上来就怀疑Agent能力先怀疑自己的启动命令。命令没起对Agent再强也跑不起来。5.2 Agent卡在同一个错误上反复重试如果你在日志里看到同一段报错反复出现而且时间间隔都差不多那基本可以确认Agent进入了“无效重试循环”。它能快速解决问题当然好但一直在同一个地方卡住说明它对问题的诊断方向可能从一开始就错了。我在 /goal 里写“尝试最多2次不同修复方案”就是为了对付这种情况。但仍会有Agent即便写了限制还是因为框架自身的重试机制绕过了这个限制。这时候你要做的一是检查框架是否有全局重试次数配置二是在 /goal 里把“什么算不同方案”写得更具体比如“第一次尝试重新读取源文件第二次尝试解析时加容错如果两种都失败停”。5.3 上下文越来越长后半程质量明显下降长任务跑久了Agent 的上下文里会堆积大量中间过程比如完整代码、大段日志、重复错误输出。当上下文接近上限时模型容易“忘记”前面的任务目标甚至开始胡言乱语。解决思路有两个层面。目标层面只能通过把任务拆成更细的多个任务来缓解但这对无人值守不友好因为需要手动衔接。技术层面更实用优先选用支持长上下文的模型定期让Agent把中间结果写入文件并做“内容总结”而不是把完整过程保留在上下文里。比如在 /goal 里可以写“每完成一个阶段用不超过200字总结当前状态和下一步计划然后清掉前面阶段的大段输出”。5.4 半夜服务器重启后台任务被杀了nohup 只防终端挂断不防服务器重启或系统自动杀进程。如果你的任务跑在云主机或者公司服务器上半夜如果出现自动更新重启nohup 进程一样会消失。对重要到不能失败的任务这确实是硬伤。我的办法是叠加一层“自动恢复脚本”。用一个外层 wrapper 脚本循环检查如果run_agent进程不存在而结果文件又还没生成就自动重新拉起命令并追加日志。大致逻辑是while [ ! -f reports/summary.md ]; do if ! pgrep -f run_agent.py /dev/null; then echo $(date) restart agent /tmp/agent_restart.log python run_agent.py --resume --goal-file goals/night_task.md /tmp/agent_night_run.log 21 fi sleep 60 done有了这层守护即使进程被杀也会在1分钟之内被重新拉起。--resume参数在这个过程中很关键它让新进程可以从最近保存的断点继续而不是从头开始。5.5 Agent“好心办坏事”超出了边界这一条最隐蔽。Agent 不一定报错甚至还会在日志里写得像模像样但实际做的事情已经超出你给它划的范围。比如你把禁止pip install写进了 /goal它却用了某个依赖库然后怪系统里没有私自装了一个。这类问题靠日志很难发现只能靠事后检查审计。我的习惯是无人值守跑完第二天先看一眼有没有生成不该出现的文件再看有没有执行过禁止类操作。如果Agent框架有操作审计列表那更好直接把审核结果列出来。把“越界”当成一种大概率事件来防备而不是碰运气。6. 无人值守的进阶玩法6.1 多阶段任务编排先规划、再执行、最后汇总当你对一个 /goal 模板已经跑得很熟可以让 Agent 在一个任务里扮演多个角色分阶段切换。比如前10步让它只做规划输出一份执行计划中间步骤按计划执行最后10步让它以“项目经理”视角检查全部成果汇总一份报告。这种多阶段编排的好处是规划和执行解耦Agent不会在没有任何计划的情况下就一路狂飙。我通常在 /goal 里这样写阶段0先读任务要求输出一份执行方案到 plans/step_plan.md方案里包含步骤列表、每个步骤的预计产物、风险点。写完方案后才能进入阶段1。这个“先写方案”的强制动作看起来多花了几步但能明显减少中后期返工。Agent一旦把计划写下来之后的执行就会更有条理而不是想到哪做到哪。6.2 定时触发与消息通知比单纯跑一夜更进一步无人值守并不一定只发生在夜里。你可以配合 cron 或系统定时任务让Agent定时启动比如每天早上9点自动跑一次数据汇总。做法很简单把启动命令写进脚本在 cron 里定时调用即可。消息通知也值得加。跑完一夜之后还要自己打开终端看日志其实还是有点原始。我现在的做法是任务结束或失败时让脚本自动往自己常用的消息渠道发一条通知内容包含完成状态和结果文件路径。这样早上起来看手机就知道这一夜到底跑没跑完基本不用再专门开电脑检查。对于异常失败的情况还会把错误日志片段带过去提前了解问题方便白天直接定位。如果要给后来者一个建议我会说别急着让Agent跑一整夜。先在白天用同样的任务、同样的 /goal跑一次短样本确认执行逻辑没有问题再放长任务过夜。我在前面踩过的几次坑几乎都跟第一次就直接上长任务有关。先花二十分钟验证模板再睡个安稳觉这笔时间非常值。