先给判断
自动化不是新能力,而是「到点自动复跑已验证的流程」。
前面几层都是「被动等指令」:技能要被触发、资料库要被查询、工具要被调用。 L5 唯一的增量是时间维度——把一组已验证的动作绑定到时间表,到点自动执行,无需人开口。
要素 | 要点 |
|---|---|
调度 | 周期性任务用自然语言描述即可(由系统转成规则);同一任务的多天 / 多时刻写在一条规则里,不要建多条。一次性任务用「单次 + 指定时刻」 |
提示词 | 必须自包含:未来运行看不到今天的对话,路径、工具、决策规则要全部写进提示词 |
工作目录 | 决定会话的默认可见范围 |
执行模型:到点后拉起一个独立会话,带全套工具(命令行 / 文件读写 / 检索),跑完产出结果。也就是说自动化会话里能做的事 ≈ 对话里能做的事。
误解(含一次被实测推翻的结论)
「自动化只有一种形态——到点由本机执行。」
真相
执行位置其实有三种,而且创建入口决定走哪条链。这是本篇最需要记清的一张表:
① 桌面端创建 | ② 小程序 · 本机模式 | ③ 小程序 · 云端模式 | |
|---|---|---|---|
跑在哪 | 这台电脑(本机执行器) | 这台电脑(手机远程连) | 腾讯云沙箱 |
PC 要开机吗 | 要 | 要 | 不要 |
本地技能 | ✅ | ✅ | ❌ 不支持 |
本地文件 / 脚本 | ✅ | ✅ | ❌ |
定时任务 | ✅ | ❌ | ✅ |
结果在哪看 | 本机会话 | 手机会话 | 手机端任务记录 |
实测结论(关键修正)
手机端「云端模式」创建的定时任务,确实跑在云端容器沙箱里,与 PC 开不开机无关。
实测证据:一次性测试任务在半夜执行,产出的文档里明确记录了执行环境为云端容器化沙箱(Ubuntu 24.04,可联网,跑完环境释放)。
⇒ 「关机等于没用」这个问题,靠换执行端就能解决。 此前「只有本机执行一种形态」的判断是错的——分水岭是创建入口是否带云端标识。
属性 | 含义 |
|---|---|
一次性 | 每次运行都是全新容器,跑完即释放,不保留任何文件 |
有临时磁盘 | 沙箱有自己的临时目录和自己的运行环境,只是没有你那台电脑的磁盘 |
可联网 | 实测公网可达、可写资料库 |
由「一次性」推出的一条操作性结论
云端没有持久磁盘 ⇒ 每次运行都必须重新取一次脚本 / 数据。
这不浪费——资料库是云端唯一的持久层。而且这个「每次现取」的架构有个隐藏好处:脚本永远只有资料库里那一份是权威版本,不存在版本漂移。
误解
「能不能用一句话唤起一个定时任务?」
真相:不能
两者是两套机制:
自动化(定时任务) | 技能 Skill | |
|---|---|---|
触发方式 | 只能被时间触发 | 被对话内容(触发词 / 语义)触发 |
一句话能否唤起 | ❌ 不能。它不在当前会话执行,而是后台另起会话,结果也不回当前窗口 | ✅ 命中即加载,当场执行 |
结果送到哪 | 后台会话 / 任务记录 | 当前对话窗口 |
适合 | 到点就该发生、人不必在场 | 人已经开口、要当场拿到结果 |
判定
要「人喊一声才做」→ 做成技能;要「到点自己做」→ 才用自动化。
这一节是全章最有价值的部分。它的必要性来自一个机制事实:
机制事实:自动化几乎没有可观测性
实测查运行时,能拿到的字段只有:id / 名称 / 状态 / 调度规则 / 提示词 / 生效窗口 / 下次运行时间。
没有:上次运行时间、上次状态、运行次数、上次输出。
⇒ 你无法回答三个问题:它到底跑没跑?成功还是失败?失败在哪一步?
这不是缺陷描述,是设计事实——它直接决定了下面这条军规必须成立。
军规 A · 让自动化自己留下痕迹
周期任务失败是静默的:没人看见、没有告警、下一次照常跑。
凡「跑没跑会影响后续判断」的自动化,都要在结果里落一个可查的东西(写一行日志、更新一个状态文件、往看板写一条记录),不能只靠「回一句话」。 反例:全绿时「只回一句摘要」——这句话如果没被看到,等同于这次任务没发生过。
军规 B · 提示词里不写死阈值、数量、路径
同一件事被写在两个地方(阈值既在脚本常量里、又在提示词里;路径既在提示词里、又在真实文件系统里),改一处,另一处不会跟着变。
实测抓到过三处这样的脱节:提示词里写着的阈值已过期、数量已变化、指引指向一个已被移动的文件。
修法:阈值类 → 改成「以脚本输出为准」,提示词不复述数字;数量类 → 删掉数字;路径类 → 指向唯一真源。
⇒ 提示词只写「流程与权限」(做什么、什么情况下不许做),不写「事实与数值」。
军规 C · 写进提示词的每一条命令,建之前先手工跑一遍
自动化不能手动触发,不存在「跑一下试试」。因此正确性必须在建之前就验证完。
提示词里的命令出错,要等下一次定时才能发现——调试周期被拉长到一整个周期。
军规 D · 验证要验交付物本身,不是验它的等价物
测了等价于脚本的命令 ≠ 测了那个脚本文件。落地形态是哪一种,就验证哪一种。
实测反例:某个入口文件的命令是对的,但文件本身换行符错了,结果只执行到最后一行,前面全部被吞。
军规 E · 不要用一条命令的成败直接推断外部世界的状态
命令失败的原因可能在工具自身。
实测反例:连通性预检裸调某个命令,得到一个「找不到远程助手」的报错,很容易被归为「目标不可达」——但这其实是本机配置问题。 一旦误判,自动化会安静地永远不工作,且不认为自己在失败。
修法:把环境处理、地址读取、超时、以及错误分类全部收进一个脚本,用不同的退出码区分「可达 / 真网络不通 / 本机配置错误」。
没有自动检测手段(可观测性薄)。当前可行的只有一条:
做法
每次改了源配置(脚本、路径、阈值)之后,回头打开引用了它的提示词看一眼。 人工、低频,但实测证明它有用——三处脱节全靠这一眼发现。
这一节来自一次真实事故,比任何理论都有说服力。
事故复盘(抽象后)
一条周期任务的目标是「重建某张在线表」。它在接口持续报网络错误时,用周期重试去「凑成功」。
结果:它依据一份过时的旧清单去重建,误删了用户前一天手动建立的十几条真实数据。
处置:任务目标本身作废,自动化被删除,并在项目记忆里写死一条硬规则——在线表记录一律视为真实数据,删除前必须先向用户确认。
由此提炼的两条边界
判定句式
「这件事有固定时间或固定周期吗?执行时需要人判断吗?」 两个都「否」→ 候选自动化;有一个「是」→ 重新考虑。
补充句式:「这个动作失败时的代价是什么?重跑一遍会怎样?」 失败无代价且重跑无副作用 → 可周期自动化;任一为否 → 改成一次性任务 + 人工确认。
一条容易忽略的经验(来自候选复核)
自动化候选能不能落地,先看数据源够不够得着,不看规则成熟度。
实测中有三个看起来很理想的候选(规则已写进技能、产出固定、周期明确),逐条核对后发现:
⇒ 先问数据从哪来,再问要不要定时。
核心思路
把任务拆成两半:「AI 判断」与「机械执行」。
需要判断的部分(分类、取舍、写文案)留在提示词里,由 agent 现场做;机械的重复劳动(取数、计算、渲染、批量写)打包成自包含脚本包传到资料库,由云端下载执行。
形态 | 速度 | 原因 |
|---|---|---|
纯提示词版 | 5–10 分钟 | 每一步操作都是一轮模型思考,几十轮叠加 |
脚本包版 | 约 2–2.5 分钟 | 机械部分一次跑完,agent 只剩四五个动作 |
实测两轮连跑:135.7 秒 / 139.7 秒,约 30 步。比纯提示词版快 3 倍。
步骤 | 做法 |
|---|---|
① 拆分 | 判断的写提示词,机械的打包成脚本 |
② 打包 | 把脚本与其依赖一起打成 zip,路径全部指向包内(相对路径) |
③ 改名 | 把 .zip 改名成 .dat 再上传——否则会被按扩展名分流成「页面」而不是「网盘文件」 |
④ 上传 | 传到资料库某个文件夹,拿到固定节点 id |
⑤ 提示词 | 只做三件事:下载 → 解压 → 执行 → 贴输出 |
⑥ 升版 | 用同一节点 id 替换内容——节点 id 永不变,提示词永不用改 |
升版机制是这套设计的精髓
脚本改了逻辑,只替换资料库里那一个节点的内容,云端下次跑自动就是新版。
⇒ 不存在「本机改了、云端还是旧的」的版本漂移问题。 这一点比本机定时任务还干净。
接口类别 | 在脚本里直连 | 说明 |
|---|---|---|
数据类(数据表增删改查、页面导入) | ✅ 直接可用 | 无需额外取票 |
节点类(遍历目录、列节点) | ❌ 会静默失败 | 脚本拿不到结果却不报错 |
由此定下一条分工
节点类的活交给 agent 的原生工具做,把结果写成临时 JSON 传给脚本。
实测修法:脚本新增一个参数,接收 agent 侧自己列好的清单文件。这样彻底绕开了在沙箱里会失败的那条子进程 / 节点接口通路。
一句话:脚本只负责取数 / 算 / 渲染 / 写回,不做节点遍历。
实测踩到的两类静默失败
两条硬性对策
一条被判据修正过的认知
节点的更新时间 / 版本号,不反映页面内容的覆盖和数据表记录的变更。
实测:页面明明覆盖成功了,节点时间戳却停在几小时前——差点被误判成「假成功」。
⇒ 查证写入一律看内容本体,不信节点元数据。
本节可带走的判据
文中所有「实测」「xx KB」「xx 个」这类数量,均来自某一台真实机器的快照,请当作方法示范而非通用阈值;真正通用的是判据与因果关系。
原创声明
本文系「当月光落下」原创,首发于腾讯云开发者社区。内容来自作者在实际使用中的逐条实测整理, 所有结论均有本机实机验证或真实接口调用支撑;文中出现的数量均为特定环境下的实测快照, 仅作方法示范,不作为通用阈值。
如需转载,请注明作者「当月光落下」及首发出处,未经许可不得用于商业用途。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。