1. 一段清洗脚本把生产数据覆盖了
一家能源企业的风电场，三个场站、两百一十台风机，一天的巡检数据四万多条。运维班手上有一批用了好几年的数据清洗和统计脚本，把这批脚本交给智能体跑，让它每天自动清洗完再出统计表。
第一版上线第三天出事。有一段脚本在跑之前会先清空当天的数据表再重新写入，那天清洗跑到一半脚本报错停了，重跑的时候表已经被清空，新的数据又没写进去。近七天的运行记录没了，运维从备份恢复花了四个小时。
同一家单位的另一条线在政务这边。社保窗口的老系统只提供客户端，没有任何接口。要把纸质材料和回单录进系统，只能靠人在客户端上一项一项点。企业想用智能体替这一段，做法是让它看着屏幕、移动鼠标、点按钮、填表单。
这两条线看起来不搭边，要定的事情是同一批：它跑在哪台机器上、跑坏了能不能退回来、它去动别人的系统时能不能管住范围。
2. 它到底跑在哪儿
2.1 三个层次要说清
「运行环境」（Runtime）这个词在实际使用里指三件不同的事，说需求的时候要分开讲。
平台工作区是它干活的那个空间，里面有会话、文件、装好的技能和工具。工作区决定了它能看见哪些文件、能调哪些工具。
会话是用户和它的一轮交互。一轮会话有自己的上下文窗口，关了会话，窗口里的内容就没了。
长任务是跨会话、跨时段执行的一件事，比如每天定时清洗数据、连续几小时盯着一个监控指标。它比会话多两样东西：中间状态要存下来，断掉之后要能接着跑。
三者的关系是：一个工作区里可以有多个会话，一个长任务会跨过好几个会话。
2.2 本机跑和云上跑，差别在这几处
同一件事，跑在用户本机上和跑在单位的服务器上，产品上的差别集中在四处。
| 本机 | 云上 | |
|---|---|---|
| 数据在哪 | 数据不出本机，随用随走 | 数据要传到服务端 |
| 能用多久 | 用户关电脑就停 | 7×24 跑着 |
| 资源上限 | 受机器配置限制，模型大一点就装不下 | 按买到的规格扩，能扩到很大 |
| 谁负责维护 | 升级、装依赖都在用户自己机器上 | 平台方统一升级 |
选哪种看两点：这份数据能不能出本机；这件事要不要在没人守着的时候跑。政务那种要动内网老系统的活，只能在本机或内网里跑；风电场每天凌晨两点跑一次清洗，得在云上或常开的机器上跑。
2.3 长任务为什么单独看
短任务跑完就完了，长任务要管三件事：中间状态存哪、跑到一半断了谁发现、接着跑的时候从哪儿开始。这三件事在下一节展开。
产品经理定需求的时候，先分清这件事是短任务还是长任务。分错了，后面的检查点、告警、配额都会漏。
3. 跑到一半断了怎么办
3.1 检查点
检查点（Checkpoint）是在任务执行过程中定期把当前进度存下来。风电场那段清洗脚本，正确的做法是每清洗完一千条就落一次库，并记下已经处理到哪一条。
检查点要存三样：已经做到哪一步、这一步的中间结果、以及这次任务的标识。三样缺一样，恢复了也不知道该接着做什么。
多久存一次，看两个数：一次能处理多少条，以及重跑一次要多久。重跑成本高的任务，检查点要存密一点。
3.2 断点续跑
断点续跑（Resume）指任务中断之后，从最后一个检查点接着往下做，不用从头再来。
它有一个前提：已经做过的那部分不能重做。清洗脚本重跑时把表清空这件事，就是没考虑这一点。正确做法是先判断这批数据是「已处理」「未处理」还是「处理中」，只对未处理的干活，而不是先清空再全量写。
跑到 60% 断了，看检查点救回多少
左边 · 改之前（不带检查点的那一次）
- 这件活风电场的巡检数据清洗脚本，一次要处理 4.2 万条
- 日志01:00 开始清洗 ｜ 01:04 已处理 25200 条 ｜ 01:04 任务中断：脚本报错
- 提示没有检查点，只能从头再来
- 这一趟重做 42000 条、恢复耗时 4 小时
- 再叠上「先清空再写入」那一档日志出现「已清空当日数据表」，中断后写「当日数据已被清空且未写完，需要从备份恢复」
已经处理的两万五千多条白干，只能从头再来。
右边 · 改之后（带检查点的那一次）
- 每处理一千条落一次库日志里出现「检查点已保存：已处理 N 条」
- 中断后的提示可以从最后一个检查点继续，需重做 0 条
- 继续执行之后的日志从检查点恢复 ｜ 已处理 25800 条 ｜ 清洗完成，共 42000 条；统计写「重做 0 条，跳过 25800 条」
- 这一趟重做 0 条、恢复耗时 0 分钟，前提是不打开「先清空再写入」
中断那一刻最近的落库点落在两万五千八百条。
检查点多久存一次，看一次能处理多少条和重跑一次要多久。
3.3 断了谁发现
长任务最常见的失败是「静默失败」：任务断了，但没人知道，第二天早上才发现昨天的数据没出来。
要配三样：任务超时告警（超过预计时长还没结束就报）、失败告警（报错就报）、以及结果对账（跑完之后核对条数，比如今天应处理 4.2 万条，实际只处理了 2.5 万条就报警）。
第三样最容易被省，也最有用。前两样只能发现「跑失败了」，第三样能发现「跑完了但结果不对」。
4. 沙盒是关起来跑的地方
4.1 沙盒是什么
沙盒（Sandbox）是一块和外面隔开的执行环境。它跑在里面，能看见的只有这块地方里的东西，动不到外面的文件和系统。
让智能体执行生成的代码、跑一段来历不明的脚本、打开一个外部文件，这几类动作都该放进沙盒。风电场那段脚本如果跑在沙盒里，最坏结果是把沙盒里的副本改坏，重新拉一份就行，动不到生产数据。
4.2 独立内核与独立文件系统各隔开什么
沙盒的隔离通常从两层做。
独立的文件系统，指它看到的是一个单独的文件目录，不是你这台机器上的真实目录。它在里面删文件、改文件，外面不受影响。
独立的内核，指它连操作系统这一层都是隔开的，进程、网络这些也隔开。这一层隔得比文件系统更彻底：它在里面就算把系统跑崩，外面机器照样运行。
两层都有的沙盒，隔离程度最高，代价是启动慢一点、占资源多一点。只有文件层隔离的沙盒，启动快，但某些类型的代码还是能影响到外面。
4.3 什么时候必须放进沙盒
四种情况，任何一种出现都要放。
要执行模型写出来的代码。代码是当场生成的，谁也没看过。
要跑外部来的脚本或文件。来源不可控，里面有什么不确定。
要处理不受信任的内容。比如从网上下载的文件、用户上传的附件。
要试一些可能把环境弄乱的操作。装依赖、改配置、批量重命名。
反过来说，只是查一条数据库记录、读一份已知的文件，用不着沙盒，走工具调用的权限控制就够了。
5. 沙盒有几种做法，隔离到什么程度
5.1 微虚拟机、容器、浏览器沙盒
微虚拟机把每个执行环境跑成一个极轻量的独立虚拟机，内核也是独立的，隔离最彻底，启动从几百毫秒到几秒不等。
容器共用宿主机的内核，文件和进程隔开，但内核是同一个。它的隔离够应付绝大多数场景，启动快、开销小；一旦出现内核层的漏洞，隔离有被穿透的可能。
浏览器沙盒是把一段代码关在浏览器标签页里跑，网络和文件访问由浏览器管着。它最轻，适合跑前端页面、做页面交互；能做的事也最少，碰不到本地文件系统。
5.2 代码执行环境
让智能体跑代码这一段，产品经理只要知道三件事：代码在哪跑（沙盒里）、能访问什么（只给它要用的那几个数据源）、跑完的结果怎么带出来（结果数据回传，环境销毁）。
数据回传这条路要写清。常见做法是：环境里只放这一轮要处理的数据副本，脚本跑完把结果文件交出来，环境整块丢掉。这样下一轮不会带着上一轮留下的东西。
5.3 隔离程度对照
| 做法 | 隔离到哪一层 | 启动速度 | 适合什么 |
|---|---|---|---|
| 微虚拟机 | 内核也隔开 | 较慢 | 跑外部代码、处理不受信任的文件 |
| 容器 | 文件与进程隔开，共用内核 | 快 | 日常跑生成的脚本、跑数据处理 |
| 浏览器沙盒 | 只在浏览器里，网络受管 | 最快 | 页面交互、前端渲染、预览 |
选哪种，看这份内容有多不可信，以及这件事要多快。不确定的时候往上选一档，代价只是慢一点。
| 沙盒 | 隔离到哪一层 | 启动 | 适合 |
|---|---|---|---|
| 微虚拟机 | 内核也隔开 | 较慢 | 跑外部代码 |
| 容器 | 共用内核 | 快 | 日常跑脚本 |
| 浏览器沙盒 | 只在页面里 | 最快 | 页面交互 |
越不可信的内容，往上选一档。
图注：三种的差别在隔到哪一层，越不可信的内容越往隔得深的那一列放。
6. 让它去操作别人的电脑和手机
6.1 什么时候只能这么做
有一类系统就是没有接口：十几年前上的老客户端、只在窗口里用的录入程序、必须点进去才能看的报表。政务那条线就是这种情况，社保窗口的老系统只提供客户端。
判断顺序是固定的：有接口就用接口，没有接口才考虑操作电脑。 接口稳、快、可查；操作电脑慢、脆、难查。
6.2 什么时候别用
三种情况不要走这条路。
系统其实有接口，只是没开放。这种情况该做的是推动开接口，不是绕过去点界面。绕过去的做法，系统改一次版就失效一次。
操作频率很高。政务录入一条记录人工九十大几秒，操作电脑的方式也要四十秒，一天几百条的话，速度是够用的；如果一天上万条，这条路撑不住，还是得回去做接口。
涉及资金、处分、对外承诺的动作。这类动作让它去点按钮，出了问题追不回来。
6.3 它会怎么失效
操作电脑这条路有几种固定的失效方式，写需求的时候要一条条对上。
界面变了。按钮换了位置、弹窗顺序变了、系统升级改了配色，它找不到原来的元素。缓解办法是把定位条件写得稳一点：优先按元素名称和标签定位，少用坐标。
弹窗挡住。突然弹出更新提示、验证码、系统公告，它就卡在那里。
页面上多个相似的入口。列表里几十行长得差不多的按钮，点错一行。
中途权限不足。点到某一步提示没有权限，整个流程断在半路，系统里留下半条记录。
6.4 卡住了怎么交给人
卡住的时候，交给人要带齐四样：卡在哪一步、屏幕上现在是什么样、已经录进去什么、接下来该点哪个按钮。
交付方式上，常见做法是把控制权交回用户，让用户接着人工点完，并把这一段记进待补清单。比这更差的做法是让它自己猜一个差不多的按钮点下去：操作电脑的每一步都是真实动作，猜错就直接写进系统。
6.5 云电脑与云手机
除了在员工的本机或工位电脑上操作，还有一条路是在云端开一台电脑或手机，让它在里面操作。
云端的好处是环境可控：装什么版本的系统、开哪些端口、留多长时间的回放记录，都由单位定；坏处是要把数据传到那台云电脑上，还得管好谁能连、连上之后能看什么。
选哪一种，先看这条业务能不能接受数据上云。政务、医疗这类常把系统关在内网的，通常走本机或内网机器这条路；客服、运营这类系统本来就在云上的，走云电脑更省事。
7. 让它去操作网页
7.1 浏览器智能体怎么干活
操作网页这一类做的是同一件事的另一种形态：看页面内容、找到目标元素、点击或填写、提交、读取结果。
它和操作电脑的差别在层次：操作电脑看的是屏幕像素，界面一变就认不出来；操作网页看的是页面结构，同样一件事在不同窗口大小下都认得出来。所以有网页版系统的时候，优先走网页这一条。
7.2 托管服务和自建的差别
浏览器智能体有两条路。托管服务是第三方把浏览器环境和模型都准备好了，接一个地址就能用；自建是自己起一套浏览器环境，自己控制访问范围。
差别在这几处：数据经过谁、能访问哪些网站（托管服务通常有个默认的可访问清单）、能不能装单位的证书和插件、出问题能不能自己查日志。政务、金融这类场景，多数选自建。
7.3 反爬会让它失效
网页这边有一个绕不开的干扰：验证码、人机校验、访问频率限制。目标网站一加这些，浏览器智能体就停住。
这件事没有技术上的通解，也不该靠绕过去解决。可行的做法有两种：一是找目标站点要一个正式的接入方式，多数单位对单位的对接都能谈；二是把这类页面交给人处理，智能体只负责把前面的信息准备好。
8. 跑坏了怎么退回去
8.1 快照
快照（Snapshot）是在动手之前把当前状态存一份，包括数据、配置和文件。出了问题把快照恢复回来，就回到了动手之前。
什么时候必须拍快照：要批量改数据之前、要升级环境之前、要试一段没验证过的脚本之前。风电场那件事如果有快照，恢复的时间是几分钟，不是四个小时。
快照要存多久，按业务定。生产数据的快照通常保留到这次变更稳定之后再撤，一般不少于一周。
8.2 回滚
回滚（Rollback）是把系统恢复到快照那个时点。
回滚之前要确认一件事：这段时间里有没有新数据写进来。如果有，直接回滚会把新数据一起抹掉。稳妥的做法是先停写入再回滚，或者只回滚受影响的那一部分。
8.3 出网限制与白名单
它能访问哪些网站，要写成一个白名单。
白名单按域名给，不给整个网段。风电场的清洗任务只需要访问内部数据接口和两个公开的气象数据源，白名单里就这十二个域名，其余一律拒绝。
名单要有人维护，新增一条要有申请和审批记录。常见的做法是每季度过一遍：半年没访问过的域名移出名单。
9. 资源不够的时候怎么排队
9.1 配额
配额（Quota）指给一个场景或一个部门划定的用量上限，通常包含三样：单次任务的工具调用次数上限、一天的总调用次数上限、以及费用上限。
配额要写到具体数字。风电场那个场景，单轮工具调用不超过二十次、一天不超过两万次调用。写清楚之后有两个好处：出异常的时候能自动挡住，比如脚本陷入循环反复调用；算账的时候有依据。
9.2 并发与队列
并发是同时跑几件事，队列是排不上队的时候先排着。
并发开多大，看后头那些系统的承受能力，不看你这边想开多少。政务那条录入线，老系统本身只支持少数几个客户端同时连，并发开大了老系统会卡死，只能开小并发、把剩下的排进队列。
队列要有两个交代：排队的时候用户看到什么（第几位、大约等多久），以及等太久怎么办（超时之后转人工还是重新排队）。
并发开到几路，等太久的人去哪了
- 目标系统的承载力老系统最多同时 4 个连接
- 平均等待 46 秒最长等待 120 秒 · 超时转人工 3 个
- 提示并发 12 超过目标系统承载力 4，老系统连接排队，部分任务超时
被压垮的是老系统，超时的那 3 个还得有人收拾。
- 平均等待 11 秒最长等待 28 秒 · 超时转人工 0 个
正好卡在老系统承受的边上。
- 平均等待 62 秒最长等待 340 秒 · 超时转人工 4 个
- 提示并发太低，用户等太久也会走掉
老系统轻松了，用户在队列里等 340 秒。
- 一张等待超过 60 秒的任务卡片展开后已等待 82 秒，达到上限，转人工处理
- 三条交代排队时显示「前面还有 7 位，预计 1 分钟」；等待上限 60 秒；超过上限转人工，并把已填字段一起带过去
- 政务那条录入线人工录入 90 秒，操作电脑 40 秒
转人工时填过的字段跟着一起过去，不用从头问一遍。
并发上限跟着后头那个系统定，不按我们想开多大定。
9.3 推理服务的排队与吞吐
模型这一侧也有排队。同一时刻请求太多，模型服务会先把请求攒一批一起算，或者直接让后来的等着。
对产品的影响有两个：一是高峰期单次回答变慢，用户等到的「正在思考」时间更长；二是如果场景是长任务，它和人工对话抢同一份额度，人工这条线就会被拖慢。
常见的处理办法是给人工对话留出固定额度，长任务用剩下的部分跑，排在夜里跑也行。这件事要提前定，等上线了再抢就晚了。
10. 风电场和政务大厅各定了什么
风电场那条线改了四处。
清洗任务从生产服务器挪到了沙盒里跑。沙盒里只放当天数据的副本，脚本在里面怎么折腾都碰不到生产库；跑完把结果文件交出来，环境整块丢掉。
脚本改成不清空、只增量写。「先清空再写入」那段逻辑删掉了，改成按数据批次判断：已处理的跳过，未处理的才写。配合每一千条存一次检查点，重跑时不重做已经完成的部分。
出网白名单定了十二个域名，只有内部数据接口和两个气象数据源；新增一条要走申请。名单每季度清一次，半年没访问过的移出。
配额写成了具体数字：单轮工具调用不超过二十次，一天不超过两万次调用。任务失败配了三个告警：超时告警、失败告警、条数对账。前两个上线第一周没响过，第三个在第三天响了一次：当天只处理了两万五千条，脚本里有个字段类型不匹配导致一批数据被跳过，靠着对账才发现。
政务那条线改了五处。
操作电脑这条路只在老系统上保留，涉及录入，不涉及任何资金动作。新上的系统一律走接口。
一条记录的每一步都留了现场：卡住的时候把当前屏幕、已填字段、下一步该点哪儿交回给窗口人员，由人接着点完，并把这一段记进待补清单，每周汇总给信息科，推动开接口。
单条失败的重试上限设成两次，两次都失败就直接转人工，不反复试。它原来是会一直试的，试到老系统卡住为止。
并发压到四路。老系统本身撑不住更多连接，剩下的任务排队，排队超过六十秒就转人工。
整条录入线还配了一台云电脑做测试：界面改版先在云电脑上试一遍，确认定位条件还认得出来，再推给窗口。这一段做下来，界面改版导致的失效从原来的每次必翻车变成提前发现。
11. 定运行环境要过的八问
| 问题 | 答「否」的时候怎么办 |
|---|---|
| 这件事要不要在没人守着的时候跑？ | 要的，就不能放在用户本机上，换到常开的机器或云上 |
| 这份数据允许出本机吗？ | 不允许的，走本机或内网，别往云上放 |
| 它会不会执行模型当场写出来的代码？ | 会的，必须放进沙盒，别在生产环境直接跑 |
| 打断之后能不能接着跑，会不会重做已经做完的部分？ | 不能的，先加检查点和幂等判断 |
| 批量改数据之前拍不拍快照？ | 要拍，快照至少留到这次变更稳定之后 |
| 它能访问哪些网站，是不是有一份白名单？ | 没有的，先出白名单，按域名给，并定谁审批 |
| 目标系统最多能承多少并发，这边开几路？ | 不清楚的，先测一次承载力再定并发 |
| 长任务和人工对话抢不抢同一份额度？ | 会抢的，给人工留固定额度，长任务排到夜里 |
12. 别拿没验证的脚本碰生产数据
让它直接在生产环境跑。 没有沙盒、没有快照、没有副本，一段没验证过的脚本就能把近七天的数据覆盖掉。跑之前拍快照、放进沙盒、只给副本，三件事都不贵。
没有快照就让它改数据。 出了事只能从备份恢复，恢复时间按小时算。快照留到变更稳定之后再撤，这是成本最低的一道保险。
有接口的老系统还在用操作电脑。 界面一改版就失效，而且每次都要人来发现。判断顺序固定：有接口走接口，没有接口才考虑操作电脑，同时把「推动开接口」写进待办，别让它变成一个长期方案。
13. 环境隔离之外，还有看得见什么、查得到什么
环境这一段要能定下六件事：本机还是云上、长任务怎么断点续跑、什么内容必须关进沙盒、出网白名单和快照怎么定、并发和配额开多大、它去操作别人的电脑和网页时要加哪些限制。
环境定下来之后，紧接着要回答的是另一类问题：在这个环境里，它能看到哪些数据、用谁的身份去看、动过的每一步谁查得到。风电场那段脚本能碰到生产库，本质上是权限没收住；政务那条录入线把每一步都留了现场，靠的也不只是环境隔离。下一份材料讲数据与权限安全：智能体用谁的身份干活、权限怎么收到最小、数据怎么分级、出事了日志能不能查到人。