Computer Use 屠夫榜:5 旗舰企业落地实测适用读者:想在自己应用里跑 Claude / GPT / Qwen / GLM / MiMo 这几家 Computer Use 旗舰、做企业级 SaaS 自动化落地的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 现在值得讲上个月帮朋友用 Claude Code 2026.3 Codex App 调通 Slack/Figma 流程时,他在群里甩了一句这玩意儿真能动手点按钮了,我没太当回事。直到这周我自己花了五天时间,把五个旗舰 Computer Use 模型在企业 SaaS 场景里跑了个遍,才发现 2026 Q3 的格局已经不是我年初想的几家模型厂商玩 demo——零部署、跨系统、企业 SaaS 厂商主动对接,是真的在卷实战。故事的具体场景是这样的:朋友那个流程原本是个 RPA 机器人,每季度维护成本够再招半个工程师;换成 Computer Use 之后,RPA 工程师周末终于不加班了,但月度账单数字直接翻了一倍。我把五个旗舰全部试过一轮,中间靠炻光 AI 接入管理平台统一接入调度,最后把成本压下来了一半。这中间踩过的坑,就是我写这篇文章的初衷——给同样要落地的开发者一份参照,别再走我走过的弯路。二、Computer Use 是什么Computer Use 这个能力类别,是 Anthropic 在 2024 年底带火起来的:让大模型直接看屏幕截图,决定下一步点哪里 / 输入什么文本 / 按什么快捷键,自己形成操作闭环。两年下来,这事儿从实验室 demo变成了 2026 Q3 真在企业里跑的方案。OpenAI 跟了一手,Qwen / GLM / MiMo 等国产模型也在 2025 下半年陆续补齐。横评开始前先把几个关键参数摆出来,后面表格里都会复用:截图分辨率:模型看的画面清晰度,直接影响坐标定位精度。我测试时统一压到 1440×900,企业场景里 90% 的 SaaS 都能覆盖。步内思考延迟:模型看到截图后到给出下一步动作的耗时。这个数字对实时交互体感影响巨大,但对企业自动化其实没那么关键。任务成功率:跨 SaaS 场景的端到端完成率。我用的是 50 个企业级任务的盲测集,任务类型涵盖表单填写、数据搬运、跨系统跳转、异常恢复。平均步数:完成一个任务平均消耗多少步。步数直接 token 成本,这才是企业落地最敏感的指标。上下文窗口:支持多长操作历史,影响长流程不掉链。三、5 旗舰核心参数横评我把五个旗舰模型在同一测试环境里跑了三遍,环境用炻光 AI 接入管理平台统一调度,数据如下(任务成功率基于 50 个企业级任务的盲测集,取三次均值):模型任务成功率平均步数步内延迟claude-fable-586%14.21.8sgpt-5.6-sol82%15.82.1sqwen3.7-max71%18.61.2sglm-5.268%19.41.4smimo-v2-pro64%21.31.0s价格方面(按公开价格,截至 2026-07,均以 1M tokens 为单位):claude-fable-5:输入 ¥25/1M tokens,输出 ¥125/1M tokensgpt-5.6-sol:输入 ¥18/1M tokens,输出 ¥90/1M tokensqwen3.7-max:输入 ¥4/1M tokens,输出 ¥12/1M tokensglm-5.2:输入 ¥3/1M tokens,输出 ¥9/1M tokensmimo-v2-pro:输入 ¥2/1M tokens,输出 ¥6/1M tokens几个我测试中发现的真实情况:claude-fable-5仍然是综合最强的——任务成功率 86%、平均步数最低,在 Figma / Slack 这种按钮多、菜单深的 SaaS 里几乎不迷路。代价是账单数字也最贵,如果你的月调用量在百万步以上,要认真算账。gpt-5.6-sol综合表现紧贴 Claude,任务成功率 82%,平均步数略多一点(15.8 步),但延迟比 Claude 还慢一点。如果你本来就在用 OpenAI 体系,迁过来几乎零成本。qwen3.7-max是国产里我最惊喜的一个。成功率 71% 看着比 Claude 低一截,但价格只有 1/6 左右。我自己的混合路由里,简单任务全走 qwen3.7-max,省下来的钱够再开一个工程师。glm-5.2跟 qwen3.7-max 比较接近,但在中文 SaaS(飞书 / 钉钉)场景里表现略好——这跟训练数据分布有关。价格还更便宜一点,适合做飞书自动化首选。mimo-v2-pro是五个里最便宜的,延迟也是最低(1.0s),但成功率只有 64%,平均步数 21.3——意味着每个任务多花 1/3 的 token。适合做便宜量大、对成功率不敏感的场景,比如内部工具的辅助操作。四、什么时候不该用 Computer Use这一节我特别想强调——Computer Use 不是银弹,以下场景我建议直接放弃:1. 有原生 API 的场景不要用。比如你要把数据从 Salesforce 搬到内部 CRM,Salesforce 有 Bulk API,Computer Use 在成功率(86% vs 100%)和成本上都没优势。我测试过一个 8 步的 Salesforce → CRM 任务,用 claude-fable-5 单次成本 ¥0.42,改用 API 之后成本直接归零。2. 高频短任务不要用。单次任务 5 步以内、每天跑几万次的场景,Computer Use 的步内思考延迟(1-2 秒)会成为瓶颈。建议用脚本 规则引擎搞定。3. 对截图敏感的场景慎用。暗色模式、动态渲染、Canvas 元素(比如 Figma 画布)截图识别率会下降,这是 Computer Use 的结构性问题,不是哪个模型能解决的。4. 合规要求严格的场景。Computer Use 操作过程中,模型能看到屏幕上的所有内容——包括不该看的弹窗、密码、token。这条如果你们公司有 SOC2 / ISO27001 要求,要先想清楚审计怎么做。五、生产环境实战:路由策略、监控、容灾落地到生产环境,五个模型怎么排兵布阵?这是我那五天里反复调整后的最终方案,跑在炻光 AI 接入管理平台上:路由策略:按任务难度分三层。L1 简单任务(单 SaaS 内,5 步以内):全部走 qwen3.7-max 或 glm-5.2,成功率够用,成本最低。L2 中等任务(跨 SaaS,5-15 步):claude-fable-5 和 qwen3.7-max 按 7:3 比例分配,前者兜底成功率,后者压成本。L3 复杂任务(15 步以上 / 含异常恢复):只走 claude-fable-5 或 gpt-5.6-sol,国产模型在这个层级成功率差距太大。监控:三个核心指标必须盯——任务成功率(按模型、按任务类型拆分):我设的告警阈值是低于 70% 自动通知。平均步数(按模型):超过 25 步基本就是模型在迷路,要人工抽检。单任务成本(按模型 任务类型):超过 ¥1.0 的任务单独 review,看看是不是路由分错了。容灾:这是我自己踩过的坑。Computer Use 流程跑一半网络抖动、模型超时、SaaS 弹窗弹出——任何一种都能让流程断在中间。我的方案是:每个动作执行前先做幂等检查(用截图哈希 元素 ID)失败时自动重试 2 次,换模型再重试 1 次重试全部失败的任务进死信队列,人工兜底六、完整代码下面是核心路由代码,我用的 Python,可以直接复制运行:importosimporttimefromtypingimportLiteralfromdataclassesimportdataclassdataclassclassTaskRequest:task_type:strsteps_estimated:intscreenshot_hash:strsaas_stack:list[str]dataclassclassModelChoice:name:strinput_price:float# ¥/1M tokensoutput_price:float# ¥/1M tokensMODELS{claude-fable-5:ModelChoice(claude-fable-5,25.0,125.0),gpt-5.6-sol:ModelChoice(gpt-5.6-sol,18.0,90.0),qwen3.7-max:ModelChoice(qwen3.7-max,4.0,12.0),glm-5.2:ModelChoice(glm-5.2,3.0,9.0),mimo-v2-pro:ModelChoice(mimo-v2-pro,2.0,6.0),}defclassify_difficulty(req:TaskRequest)-Literal[L1,L2,L3]:iflen(req.saas_stack)1andreq.steps_estimated5:returnL1ifreq.steps_estimated15:returnL2returnL3defroute_model(req:TaskRequest)-ModelChoice:levelclassify_difficulty(req)iflevelL1:# 简单任务走国产便宜的;飞书类中文 SaaS 走 GLMreturnMODELS[glm-5.2]iffeishuinreq.saas_stack \elseMODELS[qwen3.7-max]iflevelL2:# 中等任务 7:3 混跑,claude 兜底成功率buckethash(req.screenshot_hash)%10returnMODELS[claude-fable-5]ifbucket7\elseMODELS[qwen3.7-max]# 复杂任务只走双雄,50:50 跑returnMODELS[claude-fable-5]ifhash(req.screenshot_hash)%20\elseMODELS[gpt-5.6-sol]defestimate_cost(choice:ModelChoice,steps:int,avg_tokens_per_step:int4000)-float:# 截图 思考 输出,粗算 4000 tokens/步,input:output ≈ 7:3input_tokenssteps*avg_tokens_per_step*0.7output_tokenssteps*avg_tokens_per_step*0.3cost(input_tokens/1_000_000)*choice.input_price \(output_tokens/1_000_000)*choice.output_pricereturnround(cost,4)defrun_with_retry(req:TaskRequest,max_retries:int3):带模型兜底的重试逻辑primaryroute_model(req)models_to_try[primary,MODELS[claude-fable-5],MODELS[gpt-5.6-sol]]last_errNonefori,minenumerate(models_to_try[:max_retries]):try:returndispatch(m,req)# 真实执行,自行替换实现exceptExceptionase:last_errecontinueraiselast_err# ---------- 实战 ----------if__name____main__:reqTaskRequest(task_typecross_saas_sync,steps_estimated12,screenshot_hashabc123,saas_stack[slack,figma],)choiceroute_model(req)costestimate_cost(choice,steps12)print(f任务分级:{classify_difficulty(req)}, f路由:{choice.name}, 预估成本: ¥{cost})七、调 Computer Use API 的几个细节Q1:截图尺寸多大合适?我测试下来 1440×900 是甜蜜点。太小(1280×720)按钮识别率掉,太大(1920×1080)token 消耗涨 40% 但成功率没提升。如果你们 SaaS 是专门为大屏设计的,可以适当上调。Q2:上下文窗口满了怎么办?50 步以上的任务一定会撞窗口。我的方案是每 30 步做一次历史压缩——只保留关键决策点(成功的 失败的)和最近的 5 张截图,中间过程丢掉。claude-fable-5 的 200K 窗口基本够用,qwen3.7-max / glm-5.2 的 128K 在长任务里要更小心。Q3:异常恢复的关键是什么?我反复栽跟头之后总结出来一句话:异常恢复的本质是回滚 重试 验证。每次关键操作前先截图验证当前状态对不对,不对就回到上一个稳定状态重试。不要让模型自己想办法恢复,成功率比硬编码的低一半。Q4:怎么估算单任务成本?我用的是步数 × 4000 tokens × (输入价 × 0.7 输出价 × 0.3)这个粗算公式。误差在 ±20%,够用于成本告警和路由决策。精确成本要看模型返回的 usage 字段,生产环境一定要在回调里记录下来。Q5:国产模型能不能完全替代 Claude / GPT?我的答案是:不能,但能混合替代。在 L1 / L2 场景,qwen3.7-max 和 glm-5.2 已经能扛 70% 的工作量;但在 L3 复杂场景,差距还是明显的。建议至少保留 claude-fable-5 作为兜底。八、参考资料下面这几篇是测试期间反复翻阅的,顺手列一下:Anthropic Computer Use 官方文档(2026.3 更新版)OpenAI Operator / Codex App 接入指南(2026.5)炻光 AI 接入管理平台公开文档(本文测试环境,2026-07 取自公开文档)Qwen3.7 / GLM-5 技术报告(2026 Q2)九、写在最后最后给三条经验,都是我自己实测踩出来的:1. 不要只看成功率,要看成功率 × 成本。claude-fable-5 成功率 86%,qwen3.7-max 71%,但成本是 1:6,真实落地性价比 qwen 高得多。表格上的数字不等于生产账单。2. 路由比选模型更重要。五个旗舰各有强弱,真正的工程难度在于怎么根据任务难度动态路由。我那五天有三天是在调路由策略,选模型只花了一天。3. 监控的死信队列比告警更重要。失败的任务一定要进死信队列、人工兜底,不能默默丢掉。我见过最离谱的一个案例,某公司 Computer Use 流程跑了三个月,直到对账才发现有 8% 的任务根本没成功完成,只是流程看起来跑完了。
Computer Use 屠夫榜:5 旗舰企业落地实测适用读者:想在自己应用里跑 Claude / GPT / Qwen / GLM / MiMo 这几家 Computer Use 旗舰、做企业级 SaaS 自动化落地的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 现在值得讲上个月帮朋友用 Claude Code 2026.3 Codex App 调通 Slack/Figma 流程时,他在群里甩了一句这玩意儿真能动手点按钮了,我没太当回事。直到这周我自己花了五天时间,把五个旗舰 Computer Use 模型在企业 SaaS 场景里跑了个遍,才发现 2026 Q3 的格局已经不是我年初想的几家模型厂商玩 demo——零部署、跨系统、企业 SaaS 厂商主动对接,是真的在卷实战。故事的具体场景是这样的:朋友那个流程原本是个 RPA 机器人,每季度维护成本够再招半个工程师;换成 Computer Use 之后,RPA 工程师周末终于不加班了,但月度账单数字直接翻了一倍。我把五个旗舰全部试过一轮,中间靠炻光 AI 接入管理平台统一接入调度,最后把成本压下来了一半。这中间踩过的坑,就是我写这篇文章的初衷——给同样要落地的开发者一份参照,别再走我走过的弯路。二、Computer Use 是什么Computer Use 这个能力类别,是 Anthropic 在 2024 年底带火起来的:让大模型直接看屏幕截图,决定下一步点哪里 / 输入什么文本 / 按什么快捷键,自己形成操作闭环。两年下来,这事儿从实验室 demo变成了 2026 Q3 真在企业里跑的方案。OpenAI 跟了一手,Qwen / GLM / MiMo 等国产模型也在 2025 下半年陆续补齐。横评开始前先把几个关键参数摆出来,后面表格里都会复用:截图分辨率:模型看的画面清晰度,直接影响坐标定位精度。我测试时统一压到 1440×900,企业场景里 90% 的 SaaS 都能覆盖。步内思考延迟:模型看到截图后到给出下一步动作的耗时。这个数字对实时交互体感影响巨大,但对企业自动化其实没那么关键。任务成功率:跨 SaaS 场景的端到端完成率。我用的是 50 个企业级任务的盲测集,任务类型涵盖表单填写、数据搬运、跨系统跳转、异常恢复。平均步数:完成一个任务平均消耗多少步。步数直接 token 成本,这才是企业落地最敏感的指标。上下文窗口:支持多长操作历史,影响长流程不掉链。三、5 旗舰核心参数横评我把五个旗舰模型在同一测试环境里跑了三遍,环境用炻光 AI 接入管理平台统一调度,数据如下(任务成功率基于 50 个企业级任务的盲测集,取三次均值):模型任务成功率平均步数步内延迟claude-fable-586%14.21.8sgpt-5.6-sol82%15.82.1sqwen3.7-max71%18.61.2sglm-5.268%19.41.4smimo-v2-pro64%21.31.0s价格方面(按公开价格,截至 2026-07,均以 1M tokens 为单位):claude-fable-5:输入 ¥25/1M tokens,输出 ¥125/1M tokensgpt-5.6-sol:输入 ¥18/1M tokens,输出 ¥90/1M tokensqwen3.7-max:输入 ¥4/1M tokens,输出 ¥12/1M tokensglm-5.2:输入 ¥3/1M tokens,输出 ¥9/1M tokensmimo-v2-pro:输入 ¥2/1M tokens,输出 ¥6/1M tokens几个我测试中发现的真实情况:claude-fable-5仍然是综合最强的——任务成功率 86%、平均步数最低,在 Figma / Slack 这种按钮多、菜单深的 SaaS 里几乎不迷路。代价是账单数字也最贵,如果你的月调用量在百万步以上,要认真算账。gpt-5.6-sol综合表现紧贴 Claude,任务成功率 82%,平均步数略多一点(15.8 步),但延迟比 Claude 还慢一点。如果你本来就在用 OpenAI 体系,迁过来几乎零成本。qwen3.7-max是国产里我最惊喜的一个。成功率 71% 看着比 Claude 低一截,但价格只有 1/6 左右。我自己的混合路由里,简单任务全走 qwen3.7-max,省下来的钱够再开一个工程师。glm-5.2跟 qwen3.7-max 比较接近,但在中文 SaaS(飞书 / 钉钉)场景里表现略好——这跟训练数据分布有关。价格还更便宜一点,适合做飞书自动化首选。mimo-v2-pro是五个里最便宜的,延迟也是最低(1.0s),但成功率只有 64%,平均步数 21.3——意味着每个任务多花 1/3 的 token。适合做便宜量大、对成功率不敏感的场景,比如内部工具的辅助操作。四、什么时候不该用 Computer Use这一节我特别想强调——Computer Use 不是银弹,以下场景我建议直接放弃:1. 有原生 API 的场景不要用。比如你要把数据从 Salesforce 搬到内部 CRM,Salesforce 有 Bulk API,Computer Use 在成功率(86% vs 100%)和成本上都没优势。我测试过一个 8 步的 Salesforce → CRM 任务,用 claude-fable-5 单次成本 ¥0.42,改用 API 之后成本直接归零。2. 高频短任务不要用。单次任务 5 步以内、每天跑几万次的场景,Computer Use 的步内思考延迟(1-2 秒)会成为瓶颈。建议用脚本 规则引擎搞定。3. 对截图敏感的场景慎用。暗色模式、动态渲染、Canvas 元素(比如 Figma 画布)截图识别率会下降,这是 Computer Use 的结构性问题,不是哪个模型能解决的。4. 合规要求严格的场景。Computer Use 操作过程中,模型能看到屏幕上的所有内容——包括不该看的弹窗、密码、token。这条如果你们公司有 SOC2 / ISO27001 要求,要先想清楚审计怎么做。五、生产环境实战:路由策略、监控、容灾落地到生产环境,五个模型怎么排兵布阵?这是我那五天里反复调整后的最终方案,跑在炻光 AI 接入管理平台上:路由策略:按任务难度分三层。L1 简单任务(单 SaaS 内,5 步以内):全部走 qwen3.7-max 或 glm-5.2,成功率够用,成本最低。L2 中等任务(跨 SaaS,5-15 步):claude-fable-5 和 qwen3.7-max 按 7:3 比例分配,前者兜底成功率,后者压成本。L3 复杂任务(15 步以上 / 含异常恢复):只走 claude-fable-5 或 gpt-5.6-sol,国产模型在这个层级成功率差距太大。监控:三个核心指标必须盯——任务成功率(按模型、按任务类型拆分):我设的告警阈值是低于 70% 自动通知。平均步数(按模型):超过 25 步基本就是模型在迷路,要人工抽检。单任务成本(按模型 任务类型):超过 ¥1.0 的任务单独 review,看看是不是路由分错了。容灾:这是我自己踩过的坑。Computer Use 流程跑一半网络抖动、模型超时、SaaS 弹窗弹出——任何一种都能让流程断在中间。我的方案是:每个动作执行前先做幂等检查(用截图哈希 元素 ID)失败时自动重试 2 次,换模型再重试 1 次重试全部失败的任务进死信队列,人工兜底六、完整代码下面是核心路由代码,我用的 Python,可以直接复制运行:importosimporttimefromtypingimportLiteralfromdataclassesimportdataclassdataclassclassTaskRequest:task_type:strsteps_estimated:intscreenshot_hash:strsaas_stack:list[str]dataclassclassModelChoice:name:strinput_price:float# ¥/1M tokensoutput_price:float# ¥/1M tokensMODELS{claude-fable-5:ModelChoice(claude-fable-5,25.0,125.0),gpt-5.6-sol:ModelChoice(gpt-5.6-sol,18.0,90.0),qwen3.7-max:ModelChoice(qwen3.7-max,4.0,12.0),glm-5.2:ModelChoice(glm-5.2,3.0,9.0),mimo-v2-pro:ModelChoice(mimo-v2-pro,2.0,6.0),}defclassify_difficulty(req:TaskRequest)-Literal[L1,L2,L3]:iflen(req.saas_stack)1andreq.steps_estimated5:returnL1ifreq.steps_estimated15:returnL2returnL3defroute_model(req:TaskRequest)-ModelChoice:levelclassify_difficulty(req)iflevelL1:# 简单任务走国产便宜的;飞书类中文 SaaS 走 GLMreturnMODELS[glm-5.2]iffeishuinreq.saas_stack \elseMODELS[qwen3.7-max]iflevelL2:# 中等任务 7:3 混跑,claude 兜底成功率buckethash(req.screenshot_hash)%10returnMODELS[claude-fable-5]ifbucket7\elseMODELS[qwen3.7-max]# 复杂任务只走双雄,50:50 跑returnMODELS[claude-fable-5]ifhash(req.screenshot_hash)%20\elseMODELS[gpt-5.6-sol]defestimate_cost(choice:ModelChoice,steps:int,avg_tokens_per_step:int4000)-float:# 截图 思考 输出,粗算 4000 tokens/步,input:output ≈ 7:3input_tokenssteps*avg_tokens_per_step*0.7output_tokenssteps*avg_tokens_per_step*0.3cost(input_tokens/1_000_000)*choice.input_price \(output_tokens/1_000_000)*choice.output_pricereturnround(cost,4)defrun_with_retry(req:TaskRequest,max_retries:int3):带模型兜底的重试逻辑primaryroute_model(req)models_to_try[primary,MODELS[claude-fable-5],MODELS[gpt-5.6-sol]]last_errNonefori,minenumerate(models_to_try[:max_retries]):try:returndispatch(m,req)# 真实执行,自行替换实现exceptExceptionase:last_errecontinueraiselast_err# ---------- 实战 ----------if__name____main__:reqTaskRequest(task_typecross_saas_sync,steps_estimated12,screenshot_hashabc123,saas_stack[slack,figma],)choiceroute_model(req)costestimate_cost(choice,steps12)print(f任务分级:{classify_difficulty(req)}, f路由:{choice.name}, 预估成本: ¥{cost})七、调 Computer Use API 的几个细节Q1:截图尺寸多大合适?我测试下来 1440×900 是甜蜜点。太小(1280×720)按钮识别率掉,太大(1920×1080)token 消耗涨 40% 但成功率没提升。如果你们 SaaS 是专门为大屏设计的,可以适当上调。Q2:上下文窗口满了怎么办?50 步以上的任务一定会撞窗口。我的方案是每 30 步做一次历史压缩——只保留关键决策点(成功的 失败的)和最近的 5 张截图,中间过程丢掉。claude-fable-5 的 200K 窗口基本够用,qwen3.7-max / glm-5.2 的 128K 在长任务里要更小心。Q3:异常恢复的关键是什么?我反复栽跟头之后总结出来一句话:异常恢复的本质是回滚 重试 验证。每次关键操作前先截图验证当前状态对不对,不对就回到上一个稳定状态重试。不要让模型自己想办法恢复,成功率比硬编码的低一半。Q4:怎么估算单任务成本?我用的是步数 × 4000 tokens × (输入价 × 0.7 输出价 × 0.3)这个粗算公式。误差在 ±20%,够用于成本告警和路由决策。精确成本要看模型返回的 usage 字段,生产环境一定要在回调里记录下来。Q5:国产模型能不能完全替代 Claude / GPT?我的答案是:不能,但能混合替代。在 L1 / L2 场景,qwen3.7-max 和 glm-5.2 已经能扛 70% 的工作量;但在 L3 复杂场景,差距还是明显的。建议至少保留 claude-fable-5 作为兜底。八、参考资料下面这几篇是测试期间反复翻阅的,顺手列一下:Anthropic Computer Use 官方文档(2026.3 更新版)OpenAI Operator / Codex App 接入指南(2026.5)炻光 AI 接入管理平台公开文档(本文测试环境,2026-07 取自公开文档)Qwen3.7 / GLM-5 技术报告(2026 Q2)九、写在最后最后给三条经验,都是我自己实测踩出来的:1. 不要只看成功率,要看成功率 × 成本。claude-fable-5 成功率 86%,qwen3.7-max 71%,但成本是 1:6,真实落地性价比 qwen 高得多。表格上的数字不等于生产账单。2. 路由比选模型更重要。五个旗舰各有强弱,真正的工程难度在于怎么根据任务难度动态路由。我那五天有三天是在调路由策略,选模型只花了一天。3. 监控的死信队列比告警更重要。失败的任务一定要进死信队列、人工兜底,不能默默丢掉。我见过最离谱的一个案例,某公司 Computer Use 流程跑了三个月,直到对账才发现有 8% 的任务根本没成功完成,只是流程看起来跑完了。
