无人值守的智能体连错 11 轮:不是它不长记性,是我把知识放错了地方

举报
阿诺林 发表于 2026/09/28 23:11:42 2026/09/28
【摘要】 引语:一个每天自动跑的数据采集任务,连续 11 轮把同一个已知死路完整重挖一遍,每轮都「成功跑完」,产出为零。修它的关键动作是改一行提示词,我却先写了 41KB 手册。复盘、三层防御的失败链、和一套按「无记忆前提」做的设计检查,全在下面。 1. 起点:一个没毛病的采集任务我们在做全国高校开发者生态的数据底座:近 3000 所高校,逐校从官网直抓在校生规模、院系结构这类硬数据,宁缺毋滥。为让管...

引语:一个每天自动跑的数据采集任务,连续 11 轮把同一个已知死路完整重挖一遍,每轮都「成功跑完」,产出为零。修它的关键动作是改一行提示词,我却先写了 41KB 手册。复盘、三层防御的失败链、和一套按「无记忆前提」做的设计检查,全在下面。

1. 起点:一个没毛病的采集任务

我们在做全国高校开发者生态的数据底座:近 3000 所高校,逐校从官网直抓在校生规模、院系结构这类硬数据,宁缺毋滥。为让管道自己往前走,挂了一个无人值守的 cron 任务:每轮自动取队首 2 所校、抓取、落库、留痕。单看每一环都没毛病——抓取有脚本,落库有校验,收尾有汇报模板。

问题出在队列头。有两所学校是「钉子户」:一所的子站被 WAF 挡死,拦截页固定 2465 字节,换 UA、加 Referer、连无头浏览器都穿不透;另一所官网可达,但全站穷尽后确认没有在校生数,简介里只有「累计培养 14 万余名」这类历史口径。它们的正确处置就是一条命令的事:前者跑一次状态码复核,后者零下钻直接跳过。

2. 空转 11 轮,长什么样

连续 11 轮的执行记录是这样一幅画面:智能体每轮都把钉子户当成「真候选」,走完整下钻流程——fetch 脚本、信息公开栏目、二级学院子站、招生章程 PDF,甚至把招生简章逐页下载后跑本机 OCR。全部命中已知死路,结论与上一轮零差异。还有三个连带损失:该写的跳过留痕漏做,库里查不到「已复核」状态,下一轮照旧;每轮 2 所的名额全烧在死路上,不给后续真候选补位;收尾汇报照抄模板输出,把空转包装成「本轮已处理 2 所」。

这 11 轮没有一次报错,每轮都「成功」。不去翻执行记录,任务看起来一直在正常运转——这是无人值守最贵的地方:静默空转比崩溃难发现得多。

3. 三层防御,三层失败

前几轮我的应对全是「加知识」。

第一层,写手册。把「开轮先查留痕」「钉子户只做状态复核」连同全部案例写进技能的参考文件,41KB、181 行——9 轮下来没人读过它。因为 cron 会话根本不加载技能库,手册躺在执行者永远到不了的地方。

第二层,把「复制即用」的命令块直接嵌进手册,连「开轮第一条命令就跑这个」都写明。还是失败:执行这些块,需要执行者先把手册教训「翻译」进自己的命令序列,而 cron 智能体的行为是逐字照抄任务提示词里的模板查询——翻译环节永远缺失。

第三层,把判定固化成守卫脚本:一条命令输出队首留痕、跳过判定、补位候选,把「理解成本」降到零。脚本被完整跑过的那一轮判定全对,但后续轮次根本不知道它存在——它不在任务提示词的调用链上,就等于不存在。

三层失败指向同一个根因:知识离执行路径每远一步,失效概率就翻一倍。手册是给人看的,文档是给会自己查资料的执行者看的,只有挂在「必然经过的调用链上」的东西,才对无记忆的执行者生效。

4. 按「无记忆」前提重新设计

想通这一点,我把整条链按「执行者每轮都是新同事」重画了一遍:

无人值守智能体任务的五道防线
├─ 开轮守卫:第 1 步 = 跑守卫脚本(判定+留痕+补位提示,一条命令)
├─ 留痕状态机:受阻/无数据结论写进状态字段,下一轮第一眼可见
├─ 名额兜底:名额被死路烧光时,自动补位后续真候选,一轮不全灭
├─ 产出审计:每轮统计「新增有效数据」,为 0 就告警,而不是照常报成功
└─ 时间盒:单轮硬预算,超时熔断——防止守卫做对了、单轮还是跑不完

第五道防线是今天早上新加的。第 12 轮还没等到守卫脚本挂上去,整轮先超时熔断了——执行记录里躺着一行 TimeoutError: Cron job idle for 623s (limit 600s)。单轮没做完,产出无从谈起;单轮时间没预算,前面几道防线做得再对也白搭。

对应的体检提示词,可以直接抄去检查你手上的任何无人值守任务:

你是无人值守任务的守门人。检查下面的任务设计,按四问逐条回答:
1. 开轮第 1 步是否直接执行判定逻辑(跑脚本),而不是靠执行者「记得去查」?
2. 跳过/受阻/无数据的结论,是否写进下一轮第一眼就能看到的状态字段?
3. 名额或预算耗尽时,有没有自动补位或降级路径,保证一轮不全灭?
4. 每轮有没有产出审计:新增有效数据为 0 时,是告警还是照常「成功」?
任何一问答「否」,先修这一问,再谈别的优化。

5. 总结

三条判断收尾。

第一,无记忆是常态,不是 bug。设计无人值守任务时,别指望执行者「吸取教训」——它每轮都是刚入职的新同事,上一轮的教训必须变成下一轮第一眼能看到的东西,比如状态字段,或者第 1 步的守卫命令。

第二,修上游一行,胜过下游十层。这 11 轮里我写手册、嵌命令块、写脚本,真正该做的是把 cron 提示词的第 1 步换成守卫脚本那一行——五分钟的修改被一拖再拖,眼看着轮次烧完。这是复盘里最疼的一条:我修的是我能修的地方,不是该修的地方。

第三,静默空转要用审计抓。11 轮「成功」的零产出,靠人工翻执行记录才发现;没有产出审计的无人值守任务,不是在自动推进,是在自动耗电。

最后记一个数字:手册所在的技能主文件已经膨胀到 184KB,超出平台单文件上限,只能另开文件续写——知识库越写越厚,该改的那行提示词一直没改。知识不进执行路径,就等于不存在。

作者:林华鼎 · 华为云开发者发展与支持部 · 科技博主系列

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0)

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。