DeepSeek Harness 的发布，将 AI 任务调度推至台前。当模型开始处理真实任务，峰谷定价让运行时机直接决定成本。本文提出一套 AI 任务管理方法：入池、分级、排队、执行、验收、复盘，帮助产品团队构建可落地的调度规则，让 AI 真正高效运转。

DeepSeek 前段时间又刷屏了。

这次不是因为发布了新模型，而是它开放了一套叫 DeepSeek Harness 的 Agent 运行框架。目前产品还处于开发者预览阶段，但官方给出的那句话很有意思：

Agent = Model + Harness。

很多人在讨论它的一切皆插件，我更注意到的是另一个词：调度。

因为当 AI 不再只是回答一句话，而是开始调用工具、生成文件、等待结果、失败重试，甚至持续运行几个小时，它就不再只是一个模型，而是在处理一项项真实任务。

这些任务不可能全部挤在同一条通道里。

有人正在等待客服回复，晚几十秒都会影响体验；有人提交了视频生成请求，可以先离开页面；还有日报生成、历史数据打标、模型评测，本来就适合集中处理。

更直接的是，从8月17日起，DeepSeek API开始实行峰谷定价。同一项任务放在不同时间执行，价格可以差一倍。

什么时候运行在过去只是工程后台里的一个参数，现在却已经会直接影响产品的成本了。

很多团队看到这里，第一反应可能是让工程把日报、评测和批量打标挪到空闲时段。这个动作当然有用，但它只解决了几点执行，还没有解决哪些任务可以延迟。

当客服、运营、销售、产品和研发都开始使用AI，公司面对的就不再是几段Prompt，而是一整个不断进入、排队和执行的AI任务池。

哪些任务必须立即处理？哪些可以让用户稍等？哪些可以攒到固定时间统一运行？任务失败以后怎么处理？模型返回结果以后，又由谁确认它真的完成了？

如果这些问题没有答案，即使知道空闲时段更便宜，公司也不知道哪些任务可以放心挪过去。

我在这并不是想针对于Deepseek的价格进行解读，而是透过这个有更深层的思考点，想跟大家分享。当前值得产品团队和公司补上的，就应该是类似于相同逻辑的一套AI任务管理方法：先把分散的调用收进同一个任务池，再分级、排队、执行、验收和复盘。

DeepSeek 只是把价格摆到了台面上。产品真正需要重做的，是公司内部那套默认所有任务立即执行的调度规则。

第一步先把任务收进来

不少公司的 AI 调用是散着长出来的。

客服团队在总结工单，运营团队在生成日报，销售团队在给线索打分，研发团队还要定期跑模型评测。每个团队都知道自己的 Prompt 放在哪里，却没人能回答公司每天到底有多少类 AI 任务在运行。

这时候直接讨论即时、延迟和批处理，最后很容易变成一场抢资源会议。

客服说用户正在等，当然最急；运营说老板早上要看日报，也不能晚；研发说评测不跑完，新模型就没法上线。所有人都有理由把自己的任务放进快通道。

问题不在于大家不讲道理，而在于公司根本没有一张能放在一起比较的任务清单。

所以第一步不是分类，而是把任务收进同一个池子。

这里管理的单位也不能是一段 Prompt。

Prompt 只能告诉模型怎么处理输入，却不会告诉公司谁在等结果、最晚什么时候还有用、失败以后找谁、什么状态才算完成。

一项真正可管理的 AI 任务，至少应该写成这样：

在什么业务场景下，由谁触发，给谁使用，最晚何时交付，结果送到哪里，由谁按照什么标准验收。

例如，不要只写客户反馈聚类 Prompt，而要写成每周一上午，把上周客户反馈聚成问题类别，结果在周会前写入固定文档，由产品负责人确认分类是否可用于排需求。

后一种写法才具备截止时间、交付物和责任人，也才有资格进入队列。

如果某个产品每天会触发几万次对话，不需要把每次调用都手工填进任务台账。公司级任务池管理的是一类稳定的业务任务；这类任务每执行一次，再由系统新增一条执行记录，海量请求明细仍然留在日志系统里。否则表格很快会变成一片没人敢打开的数据海洋。

一套 AI 任务调度系统，跑完六个管理动作

我会把这套方法放进同一个多维表格系统，但不会把所有信息硬塞在同一张底表里。

底层只需要两张关联表：任务台账和执行记录。

任务台账代表一类长期存在的业务任务，主要保存使用者、任务类型、时间规则、负责人、验收规则、失败退路和当前版本。

执行记录代表这类任务的某一次实际运行，主要保存计划与实际时间、状态、重试、结果位置、验收证据、异常与成本。

两张表用任务 ID 关联。每周客户反馈聚类在任务台账里只有一行，但它每周运行一次，就会多出一条新的执行记录。这样更新本周状态时，不会把上周的耗时、异常和验收结果覆盖掉。

这套系统不是月底才看一次的成本报表。任务从被提出到真正完成，要在两张关联表里经过六个动作：入池、分级、排队、执行、验收、复盘。入池和分级主要确定任务规则，排队、执行和验收记录每次运行，复盘再用历史记录修改下一版规则。

1. 入池：先把任务说完整

每一项任务进入任务台账时，先填写业务场景、触发方式、需求部门、结果使用者、任务量和负责人。

这里最容易漏掉的是结果使用者。

发起任务的人不一定是最后使用结果的人。运营同学可能发起一份日报，但真正拿它做决策的是业务负责人；系统自动生成一批标签，真正使用它的可能是后续推荐流程。

不知道谁使用，就很难判断结果几点出来才有价值，也不知道最后该找谁验收。

所以先给入池设一条简单规则：没有结果使用者、没有负责人、没有验收标准的任务，先不要进入正式调度。

比如一个10秒视频生成请求的任务，由用户提交素材触发，结果交给视频生成用户，负责人是视频产品经理。

验收标准也要提前写清楚：文件能够播放、视频时长在9至11秒之间、生成完成后用户能够收到通知，异常情况可以被系统识别。

把这三个空补上，就算失败，任务也不会跟皮球一样在部门之间来回转。

2. 分级：别问急不急，要问晚了会怎样

任务入池以后，再填写五个决定分类和排期的字段：是否有人同屏等待、产品承诺完成时间、最晚有用时间、延迟损失、能不能合并处理。

这五个字段比一句很紧急有用得多。

产品承诺完成时间和最晚有用时间不是一回事。

报告生成、风控判断和批量打标面对的等待场景完全不同，同一个产品在早期试运行和稳定规模化阶段，也不该使用同一份承诺。

真正通用的规则只有一条：产品承诺完成时间应该早于最晚有用时间，中间留出失败重试、人工验收和结果送达的缓冲。如果两者被填成同一个时间点，产品就等于承诺自己不能出任何异常。

同样是生成一份竞品报告，有人五分钟后开会，晚到就失去价值；有人下班前提交，明天上午拿到即可；还有一份是公司每周固定生成的行业追踪，只要周会前送到就行。

功能名相同，Prompt 可能也差不多，任务类型却完全不同。

规则写完，才轮到判断它应该走哪条通道。

用户提交视频以后可以离开页面，不需要一直盯着加载状态，所以它不必占用即时通道；但每一条视频又对应一个具体用户，也不能像模型评测一样攒到晚上统一处理。

因此，这条任务更适合被定义为延迟任务。产品可以承诺20分钟内完成，同时把30分钟设为最晚有用时间。

20分钟是产品对用户作出的承诺。30分钟则意味着，一旦超过这个时间，即使视频最终生成，用户也可能已经取消任务或者离开产品。

这里要注意，任务类型不是优先级。

一项延迟任务也可能比另一项即时任务更早到期。任务类型决定它走哪条通道，优先级决定它在通道里排第几。

所以优先级不要按部门级别或者谁催得凶来排。先看最晚有用时间，再看延迟损失。同样明天下午到期的两项任务，一项只是晚一点看报表，另一项会影响合同提交，后者应该排在前面。

3. 排队：让快通道有边界

分完类型以后，任务才真正进入队列。

即时任务进入快通道，但快通道不能无限扩张。公司需要给它设并发上限、预算或者调用额度，把资源留给真正会因为延迟受损的任务。

延迟任务按照最晚有用时间排序。用户中途突然着急，可以申请加急，但加急要留下记录，不能悄悄改成即时任务。

批处理任务则按执行窗口合并。相同模型、相同数据来源、相近截止时间的任务，可以集中到固定时段运行，减少零散请求。使用 DeepSeek 峰谷价时，执行窗口可以落在空闲时段；使用 Batch 或 Flex 时，表里应把它们写成服务模式，不能把异步误写成夜间半价。

多维表里可以基于执行记录建立一个今日调度队列视图，只显示待执行、排队中和执行中的记录，再从任务台账带出任务类型、优先级和最晚有用时间用于排序。

用户在9点26分提交了视频生成请求。

当时快通道正在处理需要用户同屏等待的提示词校验，这条视频请求便进入延迟队列，并在9点28分开始执行。

它在队列里等待了两分钟，但没有超过20分钟的产品承诺，更没有接近30分钟的最晚有用时间。

排队的目标不是让所有任务都不用等，而是把有限的处理能力留给更早失去价值的任务。

这样业务负责人不用在总表里翻几十个字段，打开这个视图就能看见今天谁先跑、谁在等、哪项快超时。

加急率也是一个很有价值的信号。如果某类延迟任务总被加急，不一定是同事爱插队，更可能是最初的分类或承诺时间就不合理。

4. 执行：状态必须能看见异常

任务进入执行以后，我建议每一条执行记录至少保留六种状态：待执行、排队中、执行中、待验收、已完成、异常。

这里不要只写成功和失败。

有些任务模型已经返回，但结果还没有回写系统；有些报告已经生成，但负责人还没有确认字段是否完整。它们都不该提前进入已完成。

执行记录还要放上本次执行时间、模型或通道、执行负责人、超时时间、最大重试次数和失败策略。下一次运行必须新建记录，不能用新结果覆盖旧记录。任务台账只保留启用、暂停、下线这类任务生命周期状态。

重试次数尤其不能留空。AI 任务失败后自动重试很方便，但没有上限的重试会把一个质量问题变成成本循环。超过次数以后，是切换通道、换模型、降级输出，还是转人工，需要在任务开始前就写好。

任务在9点28分进入视频通道A。

第一次生成发生超时，系统没有无限重试，而是按照预先设置的失败策略切换到视频通道B，并重新执行一次。9点39分，模型返回了生成结果。

这条记录先后经历了排队中、执行中和待验收。虽然模型已经返回，但这时还不能把它改成已完成，因为视频能不能播放、时长是否正确，仍然没有人确认。

如果它超过最大重试次数，状态就应该进入异常，不能继续在后台反复消耗成本。

5. 验收：模型返回，不等于任务完成

这一段是很多任务表最容易省掉的地方。

接口返回 200，只能证明模型服务响应了。报告有没有必要字段，标签有没有成功回写，内容能不能直接进入下一步流程，都还没有答案。

所以每项任务都要在任务台账里写清验收规则和验收负责人，但这不等于要求负责人逐条手工检查所有结果。

更可行的做法，是把验收分成四层：

1.任务规则首次人工验收，有新任务上线，或 Prompt、模型、数据源、验收规则发生实质变化时，主要检查交付物是否真的能被业务使用，规则有没有漏掉关键风险。

2.日常自动校验，每一次运行结束后，检查结构是否完整、数量是否对齐、格式是否合法、是否成功回写。

3.批量结果抽样，有高频或大批量任务按风险和任务量安排时，检查自动规则检查不到的语义质量、分类边界和业务可用性。

4.高风险与异常转人工，有命中高风险条件、低置信度、超时、校验失败或用户投诉时，检查是否可以放行、修正、重跑、降级或终止。

抽样比例也不需要从文章里抄一个统一值。任务量越大、业务风险越高、规则变化越频繁，抽样就应该越密；稳定的低风险任务可以减少人工检查，但异常仍要自动转人工。

会议纪要的自动校验可能是行动项、负责人和截止时间齐全；客户标签回填可以检查目标字段是否成功写入、格式是否合法、失败数据是否进入异常清单；模型评测则要确认指定样本是否跑完、结果文件能否追溯。至于内容是不是能直接用于业务，还要由首次人工验收、抽样或异常人工处理来判断。

完成这项任务所需的验收层级以后，本次执行记录才从待验收进入已完成，并留下自动校验、抽样记录或人工确认的证据链接。

这样算成本时，分母也不再是调用次数，而是成功交付次数。一次便宜调用如果反复重试、最终没被业务使用，它仍然是一项昂贵任务。

6. 复盘：让运行数据反过来改规则

最后一个动作不是归档，而是复盘。

基于执行记录建立异常与复盘视图，只显示超时、失败、被加急、被取消、验收不通过或者结果无人使用的运行记录，再按任务 ID 汇总问题集中出现在哪类任务上。

不同指标会指向不同问题：

• 加急率持续偏高：可能说明任务分类太慢或者承诺时间不合理，需要调整任务类型、执行窗口或快通道额度
• 取消率高：可能说明用户等不起，或者任务本身价值不足，需要缩短承诺时间，检查是否应该继续提供
• 重试率高：可能说明输入不稳、模型不合适或失败策略有问题，需要修输入校验、换通道或补人工兜底
• 一次验收通过率低：可能说明模型返回了，但交付物不合格，需要重写验收标准，检查 Prompt 和工作流
• 结果使用率低：可能说明任务完成了，却没有进入业务决策，需要检查通知、回写位置，必要时删除任务
• 成功交付成本上升：可能说明低价调用被失败、重试和人工成本吃掉，需要按完整链路重新算账

这些指标不需要一开始就设统一阈值。先连续看自己的任务，再决定什么水平值得预警。没有真实运行数据时，硬写一个行业标准只会让表格看起来很专业，却不一定适合你的业务。

到这里还不能只看见已完成三个字就结束。

同类视频任务正常完成一次的演示成本约为2.84元，这次因为发生了一次超时和重试，成本增加到了4.97元。

好在任务仍然按时完成，用户也使用了结果，所以没有必要把所有视频生成请求都升级为即时任务。更合理的处理，是继续观察视频通道A的超时率：如果同类问题反复出现，再调整超时时间、通道选择或者失败策略。

复盘不是给已经发生的问题写总结，而是决定下一次任务应该怎样运行。

任务台账和执行记录，不能混在同一行

运行管理里需要两张关联的数据表。

第一张是AI任务台账，保存一类任务长期稳定的规则，例如任务名称、触发方式、结果使用者、建议类型、产品承诺、最晚有用时间、验收规则和失败退路。

第二张是执行记录，保存每一次实际运行，例如执行ID、关联任务、实际开始、模型返回、验收完成、重试次数、成本和异常。

一项任务可以有很多次执行记录。任务规则发生变化时，只修改台账；一次运行失败时，只在执行记录里留下异常。这样不会因为更新本次状态，覆盖任务过去的运行历史。

在飞书多维表格里，真正建立关系的是关联记录字段。任务ID可以继续作为唯一编号和追溯标识，但它不会自动产生表间关联。

从一条真实开发任务中，抽取一条AI运行任务

不是AI项目里的每一项工作，都应该进入AI任务池。

需求评审、页面开发和接口联调，属于团队的开发任务；真正需要分级、排队和验收的，是这些功能上线后产生的模型调用。

这里选取一组脱敏的真实产品开发任务，演示产品经理如何从需求中识别模型调用，再把它转写成AI运行任务。

从这些真实任务里，可以做出下面的判断：

这个过程里最重要的判断是：AI项目任务不等于AI运行任务。

TASK-006在开发工作台里的任务是接入视频生成模型并完成10秒能力验证。这是一项真实的开发任务，但它本身还不是AI运行任务。

真正需要进入调度系统的，是功能上线后不断发生的10秒视频生成请求。

如果产品允许用户提交后离开页面，完成后再通过消息通知，这项任务更适合被定义为延迟任务；如果产品要求用户一直停留在当前页面等待，它就可能被定义为即时任务。

任务类型取决于产品承诺，而不是模型名称。

抽取以后，AI任务台账可以先这样填写：

任务台账接入后，你就会得到由实际开始时间、模型返回时间、重试次数、异常、成本和验收结果组成的执行记录。

产品界面和会员，只是任务管理规则的外显

公司内部把任务管理跑顺以后，产品界面才知道应该向用户展示什么。

即时任务需要响应时间、超时降级和失败兜底；延迟任务需要预计完成时间、状态、取消、有限加急和结果通知；批处理任务需要固定执行窗口、结果回写和异常清单。

这些功能不是凭空列出来的，而是内部任务字段在前台的对应物。

会员也一样。

对于报告、视频、批量分析这类任务型产品，交付速度可以成为一层权益。普通通道承诺在某个时间范围内完成，高等级会员获得更短的承诺时间、更多并发名额或者有限次数的加急机会。

但前提是公司真的有能力管理不同通道，也能兑现承诺。

内部队列都看不清，却先在会员页上卖极速生成，最后只会把调度问题变成客诉。

更不能为了卖加速包，故意把本来可以稳定、低成本完成的任务拖慢。付费用户购买的应该是更可靠的服务等级，不是产品人为制造出来的痛点。

会员设计不是这套方法的起点，而是任务分级、排队和验收稳定以后自然长出来的结果。

任务管理的最后一步，是允许任务退出

把任务收进任务池，完成分级、排队和验收，并不代表这项任务以后就要一直运行。

任务池如果只能增加、不能退出，最后一定会堆满技术上还能跑，业务上没人用的任务。

一份没人打开的日报，即使放到低价时段批量生成，仍然是在浪费成本；一项长期需要重试、人工修正才能交付的任务，即使单次模型调用很便宜，成功交付成本也可能并不低。

所以，AI任务台账还需要管理任务的生命周期：

判断一项任务是否应该继续，不能只看接口有没有成功返回。

产品经理还要看四件事：结果有没有被使用，是否在最晚有用时间之前完成，能不能一次通过验收，以及每次成功交付的完整成本。

如果一项延迟任务经常在排队时被取消，不一定只是执行速度太慢，也可能是用户根本没有那么需要它；如果一项批处理任务频繁被人工加急，说明执行窗口或者产品承诺可能设错了；如果任务已经连续几个周期没有结果使用者，就应该先暂停，而不是继续优化Prompt。

任务管理不是想办法让所有AI任务都跑得更快、更便宜。

DeepSeek的峰谷定价提醒我们，同一项任务在不同时间执行，成本可能不同。但比选择执行时间更重要的是先判断：这项任务是否值得继续执行。

真正有效的任务调度，是让有价值的任务在正确的时间完成，也让已经失去价值的任务及时退出。