AI Work：把大模型能力编排进业务流程的工程实践

AI Work 并不是一个新模型，也不是某家大厂发布的某个 App，而是把大模型能力编排进业务流程后形成的一套可运行、可维护、可观测的工作流体系。最近关于“国产 AI Work”的讨论明显增多，也有人用“悟空四个月‘消失’”来形容某类 AI 产品在热度消退后没有持续迭代。单看这个现象会觉得是运营问题或模型不够好，但从工程视角观察，更接近真相的原因是：产品没有把 AI 能力沉淀成可稳定流转的业务流程，也就是缺少 AI Work。

模型能力决定 AI 的下限，AI Work 决定 AI 的上限。单次对话能写出不错的文案，这靠模型；让上千条待办工单自动完成分类、摘要、分派、回访、结案，并且每一步都可追踪、可回滚、可审计，这必须依赖 AI Work。下面先厘清 AI Work 与传统自动化的边界，再分析大厂重视它的工程原因，然后用一个最小可运行示例演示如何实现，最后补充参数设计、排错路径和生产落地清单。

1. 先厘清边界：AI Work 不是聊天机器人，也不是作业脚本

1.1 通俗理解：AI Work 是给大模型装上一套业务流程

普通聊天机器人的逻辑是“一问一答”：用户输入文本，模型返回文本，流程结束。AI Work 更像一条组装好的流水线。它会先判断当前任务是什么，决定调用哪套提示词；再调用模型生成中间结果；然后通过规则校验结果是否合格；不合格的进入重试或人工处理；最后把结果写入数据库、消息队列或报表系统。整个过程不是一次模型调用，而是多次模型调用和规则判断的组合。

举个例子，客服工单处理如果只靠聊天机器人，用户在对话框里问“怎么退货”，模型能回答一段退货政策。但 AI Work 会把这个动作拆成：读取工单文本，调用模型提取订单号、商品、退货原因，再调用规则判断是否满足退货条件，不满足则生成驳回文案，满足则创建退货单并通知仓库。每一步都有输入、输出、校验和异常分支。

从使用场景看，AI Work 适合输入量大、规则复杂、结果需要进入其他系统的任务，比如工单分类、文档审核、舆情摘要、数据清洗、代码提交描述生成等。它不追求一次对话惊艳，而追求一批任务稳定完成。

1.2 从单模型调用到 AI Work：为什么流程比单个提示词重要

单次模型调用解决的是“生成”，AI Work 解决的是“稳定地生成并交付”。在实际业务中，一次生成很少能直接成为最终结果。生产环境需要面对格式错误、字段缺失、置信度不足、调用超时、限流、重复提交等问题。这些问题无法靠更换一个更大模型解决，必须通过流程设计来兜底。

单模型调用可以写成：

response = llm_client.chat(prompt) text = response.content

这种写法适合跑通原型。一旦进入生产，就需要把上面这行代码扩展成包含输入校验、调用参数、超时控制、输出解析、结果校验、失败重试、日志记录的完整 AI Work。工作流的价值不是让模型变聪明，而是让不稳定的模型输出在业务边界内稳定落地。

大厂重视 AI Work 的核心原因也在这里：模型能力可以通过采购或自研获得，但把模型接进业务系统的工程能力只能靠团队自己沉淀。同一个大模型接口，有人只能做出聊天 Demo，有人能做出自动化运营系统，差别就在工作流设计。

1.3 AI Work 与 RPA、传统工作流的区别

判断一个系统是否属于 AI Work，可以从三个特征来看：第一，流程中存在大模型生成或决策节点；第二，生成结果会被后续步骤校验、转换和消费；第三，执行链路能够被跟踪和恢复。传统工作流和 RPA 也强调流程，但决策来自预定义规则，几乎不依赖模型泛化能力。AI Work 引入了模型节点之后，流程的复杂度从“分支多”变成“不确定性高”，因此需要额外的工程保护。

维度	传统工作流	RPA	AI Work
处理对象	结构化数据和固定接口	界面操作和模拟点击	文本、语义、决策和外部工具混合
规则来源	预定义业务规则	预定义操作步骤	模型生成 + 人工规则校验
异常处理	条件分支	固定重试	重试、校验、兜底、人工介入
最怕的问题	流程节点变化	界面元素变化	模型输出不稳定
典型落地	审批流、订单流	报表自动化、系统切换	工单、审核、摘要、辅助决策

从表格可以看到，AI Work 并不是替代 RPA 或传统工作流，而是在它们之上增加了“模型决策节点”。这带来的好处是能处理非结构化输入，坏处是必须为模型的不确定性设计额外的保护机制。

2. 大厂为什么把目光移到 AI Work：四个工程原因

2.1 模型能力被拉平，工作流成为落地差异点

过去几年，产品竞争重点在大模型本身，谁的参数多、谁的榜单高，谁就有优势。但模型能力发展到一定阶段后，开源模型和商业模型之间的差距逐渐缩小，单纯提供“模型调用”已经很难形成产品壁垒。

此时真正决定用户体验的是：模型输出之后，产品如何解析、校验、过滤、排序、回退和转人工。这些逻辑都长在 AI Work 里。同样一个摘要模型，A 产品直接把模型输出展示给用户，B 产品会先判断摘要是否完整、是否包含敏感词、是否覆盖关键指标，异常时自动重试或降级。用户感知到的差距不是模型聪明程度，而是流程的成熟度。

所以大厂强调 AI Work，本质是把竞争从“谁的模型更强”转向“谁能把模型用得更好”。这更接近软件工程问题，也更适合团队长期积累。

2.2 AI Work 可以把不可控输出变成可控流程

大模型输出具有概率性，同一个提示词在不同时间可能返回不同内容。如果业务直接把模型结果写入数据库，大概率会出现字段缺失、格式错误、逻辑冲突等问题。

AI Work 的处理方式是给模型输出加约束。常见的做法包括：

• 提示词中明确要求返回 JSON，并给出字段示例；
• 使用结构化输出或函数调用能力，让模型按 Schema 返回；
• 模型返回后，用代码校验必填字段、类型、范围、枚举值；
• 校验失败时，重新调用模型进行“修复式追问”，而不是直接抛错；
• 连续多次失败后，转入人工处理通道。

这些约束保证进入下游系统的数据完整、可信。AI Work 的本质，就是把不可控的模型生成行为，用工程手段约束到业务可接受的范围内。

2.3 成本与延迟：路由、缓存、并发控制

大模型调用不是免费的，成本由 token 数量决定，延迟由模型大小和排队情况决定。如果不做工作流，所有请求都发给最大模型，成本会快速失控。

AI Work 可以在流程中设计分级路由：

route_rules: - condition: intent == "greeting" model: small-fast-model max_tokens: 64 - condition: intent == "complex_query" model: large-model max_tokens: 1024 - default_model: medium-model

简单问题走小模型，复杂问题走大模型，重复问题走缓存。语义缓存可以把相同问题的历史回答直接返回，省去一次模型调用。再加上并发控制在合理范围内，让系统不会因为瞬时流量被限流，整体成本更可控。

延迟方面，AI Work 可以做到部分步骤并行。比如文档审核工作流，可以先并行抽取标题、作者、风险词，最后再汇总。单步模型调用延迟没有变，但整体任务耗时明显下降。

2.4 合规和审计：每步可追踪、可回滚

业务系统一旦接入 AI，就会出现一个很难回答的问题：这个结果是谁生成的？依据是什么？如果出错，如何定位？AI Work 通过流程编排，天然记录每一步的输入、输出、模型、参数和异常信息。

在审计场景下，这非常关键。比如银行对公开户材料审核，模型判断“资料齐全”，系统必须能追溯是哪次调用、哪个模型、哪些字段、置信度多少。AI Work 把每一步执行结果和上下文串起来，相当于给 AI 决策加了一条完整时间线。

可回滚也很重要。当新流程版本出现明显错误时，可以保留旧版本的执行逻辑，通过配置中心快速切换，而不是重新发版。这也是大厂在设计 AI Work 平台时会把版本管理放在第一优先级的原因。

3. 从零搭建一个最小 AI Work 示例

3.1 最小示例解决什么问题

先直接看代码，再解释设计。下面这个 Python 示例会完成一条客服工单的自动处理：输入工单文本，AI Work 自动完成预处理、模型调用、结果校验、落库展示。模型调用超时会自动重试，结果置信度过低会让任务失败，所有状态保存在上下文对象中，方便后续替换成数据库。

示例目标是体现 AI Work 的四个关键能力：

• 用状态机表达任务生命周期；
• 用上下文对象在步骤之间传递数据；
• 用异常和重试处理模型不稳定；
• 用校验步骤拦截不合格结果。

3.2 目录与运行环境

运行环境只有两个要求：Python 3.10 以上，无第三方依赖。目录结构保持最小：

ai-work-demo/ ├── workflow_demo.py └── README.md

把全部代码放在workflow_demo.py，便于在一篇文章里讲清楚。实际项目中会把步骤拆到不同模块，但核心思想不变。

3.3 用状态机和上下文表达工作流

状态机解决“任务处于什么阶段”的问题。这里定义任务级别的状态和步骤级别的状态：

from enum import Enum class WorkflowStatus(str, Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" FAILED = "failed" class StepStatus(str, Enum): PENDING = "pending" RUNNING = "running" SUCCESS = "success" FAILED = "failed" RETRYING = "retrying"

上下文对象解决“步骤之间如何传数据”的问题。不要把中间结果存在全局变量里，应该统一放在上下文对象中，这样每个步骤都能读取和写入，排错时也容易打印：

from dataclasses import dataclass, field from typing import Any @dataclass class WorkflowContext: input_data: dict records: dict = field(default_factory=dict) workflow_status: WorkflowStatus = WorkflowStatus.PENDING current_step: str = "" step_status: StepStatus = StepStatus.PENDING error: str = ""

records字典会保存每个步骤的关键输出。没有它，后续步骤只能重复调用前面的逻辑，工作流就退化成顺序脚本。

3.4 核心代码实现

先写一个模拟大模型调用的函数。它本身带有重试、退避和模拟异常逻辑：

import json import random import time RETRYABLE_ERRORS = (TimeoutError, ConnectionError) def llm_call_with_retry(prompt: str, max_retries: int = 3, base_delay: float = 0.5) -> str: for attempt in range(max_retries): try: print(f"[llm] 第 {attempt + 1} 次调用，prompt 长度 {len(prompt)}") # 模拟模型接口偶尔超时 if random.random() < 0.15: raise TimeoutError("模拟模型接口超时") # 正常情况返回一段 JSON 字符串 return json.dumps({ "summary": "用户申请退货，需要确认商品是否已寄回", "category": "售后", "confidence": 0.96 }, ensure_ascii=False) except RETRYABLE_ERRORS as e: if attempt == max_retries - 1: raise sleep_time = base_delay * (2 ** attempt) + random.uniform(0, 0.3) print(f"[llm] 调用异常：{e}，{sleep_time:.2f}s 后重试") time.sleep(sleep_time)

接下来定义四个步骤。每个步骤都接收同一个WorkflowContext对象，并往里写入结果：

def step_preprocess(ctx: WorkflowContext) -> None: raw = ctx.input_data.get("ticket", "").strip() if not raw: raise ValueError("工单内容不能为空") ctx.records["normalized_ticket"] = raw def step_llm_summary(ctx: WorkflowContext) -> None: prompt = ( "请对下面的客服工单做摘要和分类，只返回 JSON，" "字段包括 summary、category、confidence。\n" f"工单内容：{ctx.records['normalized_ticket']}" ) response = llm_call_with_retry(prompt) try: data = json.loads(response) except json.JSONDecodeError as e: raise ValueError(f"模型输出不是合法 JSON：{response}") from e if not isinstance(data, dict): raise ValueError("模型输出不是 JSON 对象") if "summary" not in data or "category" not in data or "confidence" not in data: raise ValueError("模型输出缺少 summary/category/confidence 字段") ctx.records["llm_result"] = data def step_validate(ctx: WorkflowContext) -> None: data = ctx.records.get("llm_result", {}) if float(data.get("confidence", 0)) < 0.9: raise RuntimeError("置信度过低，需要人工复核") ctx.records["validated"] = True def step_save(ctx: WorkflowContext) -> None: # 实际项目里写数据库或消息队列 ctx.records["saved_id"] = "TICKET-0001"

工作流引擎只需要一个简单的循环：顺序执行步骤，任何异常都会把整个任务标记为失败，并记录当前步骤和错误信息：

class LLMWorkflow: def __init__(self, steps): self.steps = steps def run(self, ctx: WorkflowContext) -> WorkflowContext: ctx.workflow_status = WorkflowStatus.RUNNING for step in self.steps: ctx.current_step = step.__name__ ctx.step_status = StepStatus.RUNNING print(f"[workflow] 开始步骤：{ctx.current_step}") try: step(ctx) ctx.step_status = StepStatus.SUCCESS print(f"[workflow] 步骤完成：{ctx.current_step}") except Exception as e: ctx.step_status = StepStatus.FAILED ctx.error = f"{ctx.current_step}: {e}" ctx.workflow_status = WorkflowStatus.FAILED return ctx ctx.workflow_status = WorkflowStatus.SUCCESS return ctx

最后是入口。输入一条工单，创建上下文，执行工作流，输出结果：

if __name__ == "__main__": workflow = LLMWorkflow([ step_preprocess, step_llm_summary, step_validate, step_save, ]) ctx = WorkflowContext(input_data={ "ticket": "我上周买的杯子碎了，想申请退货。" }) workflow.run(ctx) print(json.dumps({ "workflow_status": ctx.workflow_status.value, "current_step": ctx.current_step, "records": ctx.records, "error": ctx.error }, ensure_ascii=False, indent=2))

3.5 运行验证和预期输出

在项目目录下执行：

python workflow_demo.py

正常情况会看到类似输出：

[workflow] 开始步骤：step_preprocess [workflow] 步骤完成：step_preprocess [workflow] 开始步骤：step_llm_summary [llm] 第 1 次调用，prompt 长度 52 [workflow] 步骤完成：step_llm_summary [workflow] 开始步骤：step_validate [workflow] 步骤完成：step_validate [workflow] 开始步骤：step_save [workflow] 步骤完成：step_save { "workflow_status": "success", "current_step": "step_save", "records": { "normalized_ticket": "我上周买的杯子碎了，想申请退货。", "llm_result": { "summary": "用户申请退货，需要确认商品是否已寄回", "category": "售后", "confidence": 0.96 }, "validated": true, "saved_id": "TICKET-0001" }, "error": "" }

如果模型调用连续失败，或结果校验不通过，输出中workflow_status会变成failed，error会记录具体哪一步出了什么问题。这就验证了 AI Work 的异常处理链路。

注意：不要只验证程序能启动，还要故意把confidence改小、把模型返回改成非 JSON，观察工作流是否正确进入失败分支。只有失败分支可控，才能算真正的 AI Work。

4. 关键设计：超时、重试、参数和并发控制

4.1 模型调用参数速查表

模型调用参数不是随便填的，它们直接影响 AI Work 的成功率、延迟和成本。下面是一份常用参数速查表：

参数	含义	常见值	调大影响	调小影响
temperature	控制结果随机性	分类任务 0.2，写作任务 0.7	结果更发散，更有创造性	输出更稳定、更保守
max_tokens	单次生成最大 token 数	512 到 2048	能覆盖更长输出，但耗时和成本上升	可能截断，导致 JSON 不完整
timeout	单次请求超时时间	30 到 120 秒	避免误判慢请求，但任务堆积风险增加	更容易失败，适合快速降级
top_p	核采样概率	0.9 左右	候选词更多	输出更集中
max_retries	失败重试次数	2 到 3 次	提高成功率，但放大成本和延迟	成功率下降

重点是timeout和max_retries。很多人只配置max_tokens，却忘记了超时。结果模型接口无响应时，工作流一直卡住，大量任务堆在队列里。超时应该理解为“整体任务超时”，不只是“单次请求超时”。

4.2 重试策略要兼顾成功率和成本

重试不是简单地把同一个请求再发一次。直接重发可能造成重复扣费，也可能放大故障期间的调用压力。推荐的做法是采用指数退避，并加入随机抖动：

def get_retry_delay(attempt: int, base_delay: float = 1.0) -> float: return base_delay * (2 ** attempt) + random.uniform(0, 0.5)

同时，每个请求都要带上唯一的请求 ID。这样即使客户端重试，服务端也能识别出同一业务请求，避免重复生成、重复写库。请求 ID 在日志排查中也起到串联作用。

重试还要区分错误类型。网络超时可以重试，鉴权失败、参数错误这种 4xx 错误重试多少次都不会成功，应该直接失败进入人工处理。示例代码中RETRYABLE_ERRORS只包含TimeoutError和ConnectionError，就是这个原因。

4.3 并发控制：避免限流，保留排队语义

大模型接口通常有 QPS 或 token 速率限制。AI Work 如果同时发出大量请求，很快会被限流，造成大量重试，反而更慢。简单的做法是使用 Python 信号量控制并发数：

import threading semaphore = threading.Semaphore(5) def call_with_limit(prompt: str) -> str: with semaphore: return llm_call_with_retry(prompt)

生产环境更推荐用消息队列或任务队列来控制消费速度。任务进入队列后，按固定的并发数消费，每个任务都有独立状态。这样即使模型接口变慢，也只是队列积压，不会导致后端被击穿。

学习环境直接串行调用即可，重点是理解状态流转。生产环境再加入并发，不要在 Demo 阶段过度设计。

5. 常见问题与排查链路

5.1 任务一直处于“运行中”

现象：AI Work 的某个任务在数据库里长期处于 RUNNING 状态，没有结束。

可能原因：

• 模型调用没有设置超时，请求一直等在那里；
• 工作流进程崩溃，但状态没有更新；
• 步骤之间出现死锁或无限循环；
• 重试次数过大，加上指数退避，导致单任务耗时非常长。

检查方式：

• 先看任务日志里最后一次心跳时间，确认任务是否还在执行；
• 查看进程日志，搜索当前步骤名称；
• 统计单次模型调用的平均耗时和 P95 耗时，判断是否异常。

处理建议：

• 给每一步设置独立超时和整个工作流的整体超时；
• 状态更新使用“最后更新时间”字段，超时未更新的任务由定时器标记为失败并告警；
• 避免在步骤里写 while True 循环，必须设置最大循环次数。

5.2 模型返回格式不稳定

现象：模型返回内容有时是合法 JSON，有时是普通文本，有时 JSON 解析成功但字段缺失。

可能原因：

• 提示词没有明确要求 JSON 结构；
• max_tokens太小，输出被截断；
• 模型本身对不同输入理解不一致；
• 直接使用字符串切割解析，没有用json.loads。

检查方式：

• 打印原始响应，确认是截断还是格式错误；
• 把截断响应与max_tokens对比，检查是否到达长度上限；
• 记录连续失败的样本，观察失败集中在哪种输入。

处理建议：

• 提示词里给出 JSON 示例，并使用“只返回 JSON，不要解释”；
• 优先使用模型平台提供的结构化输出或函数调用能力；
• 解析失败时，把原始响应和错误信息一起放入失败队列，人工处理。

5.3 重试导致重复执行

现象：模型调用重试成功，但业务系统写了多条相同记录，或者用户收到多次通知。

可能原因：

• 重试的不是幂等请求；
• 第一次调用已经成功，只是响应超时，客户端误判为失败后重试；
• 写库操作没有唯一键约束。

检查方式：

• 查看日志中同一个业务请求 ID 对应的调用次数；
• 在数据库查request_id或order_no是否重复；
• 检查工作流步骤是否是纯函数，是否每次执行都会产生副作用。

处理建议：

• 每次任务生成一个request_id，并在写库前检查唯一键；
• 写库和通知操作放在流程末尾，并使用事务；
• 重试逻辑只对可重试错误生效，不能对所有异常无条件重试。

5.4 排查清单

现象	可能原因	检查方式	处理建议
任务一直 PENDING	队列消费线程挂起	查看消费者日志和线程数	给任务设置整体超时
任务失败但没有详细日志	异常被吞掉	检查 except 是否记录 error	至少记录异常类型和堆栈信息
模型返回非 JSON	提示词未约束或输出被截断	打印原始响应	使用结构化输出或修复式追问
重试导致重复写库	缺少幂等键	查库中 request_id 重复情况	写库前检查唯一键
并发一高就被限流	所有任务同时调模型	查看限流错误码	用队列或信号量控制并发
新版本流程出问题	缺少版本控制	查看当前配置是否指向新逻辑	保留旧版本，快速回切

6. 从 Demo 到生产：落地 AI Work 的工程要求

6.1 状态持久化不能少

示例中的WorkflowContext只存在于内存里，进程一重启就丢失。生产环境必须把任务状态存到数据库，让每个任务都能从断点继续，或者至少能定位到失败原因。

一张最简任务表可以这样设计：

CREATE TABLE ai_work_task ( id BIGINT PRIMARY KEY AUTO_INCREMENT, request_id VARCHAR(64) NOT NULL, workflow_name VARCHAR(64) NOT NULL, input_data JSON, status VARCHAR(16) NOT NULL, current_step VARCHAR(64), result JSON, error TEXT, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, KEY idx_status_update_time (status, update_time), UNIQUE KEY uk_request_id (request_id) );

request_id做唯一键，既保证幂等，也方便日志查询。status用于标记任务处于哪个阶段，current_step用于在失败时定位具体步骤。

6.2 日志和监控要覆盖调用全链路

AI Work 的日志不能只记录“成功了”或“失败了”，至少要包含这些字段：

request_id, workflow_name, step_name, model_name, prompt_tokens, completion_tokens, latency_ms, status, error_type, error_message, timestamp

这些字段可以回答四个问题：

• 哪个任务出了问题；
• 卡在哪一步；
• 模型调用花了多长时间、消耗了多少 token；
• 错误是重试后恢复，还是彻底失败。

监控指标建议至少覆盖：

• 任务成功率和平均耗时；
• 每个步骤的成功率；
• 模型调用错误率和重试率；
• 队列积压数量；
• token 消耗成本。

当某个步骤成功率低于阈值时，应该触发告警，而不是等用户投诉。

6.3 灰度上线：先处理低风险任务，再逐步放量

AI Work 直接全量上线风险很高。模型判断一旦出现系统性错误，所有任务都会受影响。推荐分三步走：

1. 第一阶段只处理内部测试任务，关闭真实写入，结果以人工核对为主；
2. 第二阶段选择低风险任务放量，比如摘要生成、内部工单分类；
3. 第三阶段接入有资金、合规影响的任务，并增加人工抽检和回滚开关。

灰度过程中要对比人工处理结果和 AI Work 结果的差异，记录失败样本。只有当失败样本比例下降到可接受范围，才继续放大流量。

6.4 学习环境与生产环境的差异

维度	学习环境	生产环境
状态存储	内存对象	数据库或消息队列
异常处理	打印异常	重试、死信、人工介入
日志	控制台输出	日志平台 + 链路追踪
参数配置	写在代码里	配置中心动态调整
权限	本机 API Key	密钥管理、最小权限
监控	手动查看	指标 + 告警 + 看板
上线方式	直接运行	灰度发布 + 快速回滚

学习环境跑通的是逻辑，生产环境要解决的是可靠性。不要把两者混为一谈。

7. 最佳实践和下一步扩展方向

7.1 可直接套用的检查清单

AI Work 落地前，可以按这份清单逐项检查：

• 每个任务是否有唯一request_id；
• 单次模型调用是否设置了超时；
• 重试是否使用指数退避 + 随机抖动；
• 重试是否只针对可恢复错误；
• 模型输出是否有格式校验；
• 关键字段缺失时是否进入失败分支或人工通道；
• 工作流状态是否持久化；
• 失败任务是否能定位到具体步骤；
• 是否记录模型、token、耗时、错误类型；
• 是否有灰度开关和版本回滚方案；
• 是否有并发控制，避免接口限流；
• 是否对敏感数据做脱敏和权限控制。

把这些检查项固化到代码审查和发布流程里，比靠个人经验更可靠。

7.2 从线性工作流到 Agent 循环

本文示例是线性工作流：步骤从上到下执行一次。真实业务中，模型第一次输出可能不够好，需要让模型根据反馈迭代。这就进入 Agent 循环，常见模式有 ReAct 和 Plan-Execute。

ReAct 模式里，模型先思考、再决定调用工具、观察结果后继续思考，直到完成任务。难度和工作量都比线性工作流大很多，但能处理更开放的问题。建议先掌握线性 AI Work，再逐步引入循环和工具调用。

7.3 人工审批节点和知识库增强

很多业务场景不能完全自动，需要插入人工审批节点。AI Work 引擎应该支持“任务挂起->等待人工处理->继续执行”的状态。比如风险较高的退款申请，AI 只做分类和摘要，最终审批权保留给人。

知识库增强是另一个常见的扩展方向。模型生成前先检索相关文档，把检索结果拼进提示词，能显著提高专业领域准确性。AI Work 不是在每个步骤都硬调一次模型，而是要把检索、判据、生成、校验组合成一条完整链路。

从“悟空四个月消失”这个观察回到工程本身，可以看到一个很朴素的结论：AI 产品的竞争力不在一次生成结果，而在能否稳定地把结果送进业务系统、能否在失败时快速恢复、能否在复盘时还原完整决策链路。这些能力需要主动设计，无法靠模型升级自动获得。先从小任务开始，把一个客服工单、一份审核材料、一类舆情摘要处理稳定，再逐步扩大 AI Work 的覆盖范围，是比较稳妥的路径。