最近看到一个很有意思的讨论：某款以“悟空”命名的国产 AI 产品连续四个月没有大版本更新，有人猜测是不是团队遇到瓶颈，也有人说是蓄力憋大招。舆论发酵一段时间后，更多信息透出来——团队并没有闲着，而是在集中精力重构底层的 AI Work 能力。这件事其实反映出一个趋势：大厂对“单个模型能力”的关注，正在逐步转向“把模型放进一条完整工作流里跑起来的能力”。

那 AI Work 到底是什么？为什么大厂会如此看重它？它对普通开发者和业务团队又意味着什么？这篇文章我想从产品迭代节奏、技术架构拆解、场景落地和工程实践几个角度，把这个问题聊透。

1. 背景与核心概念

1.1 从“悟空消失”说起，AI 产品竞争的焦点变了

在 AI 行业，一个产品四个月不更新，放在两年前确实“不正常”。当时各家拼的是模型版本号，比如今天放出 7B 模型，下周又放 14B，再过一个月放出支持 32K 上下文的版本。用户对“模型有没有变聪明”极其敏感，大厂也乐于用版本更新来刷存在感。

但这两年风向变了。基座模型的能力差距在缩小，很多厂商发现，单纯刷评测分数已经很难转化为用户口碑。用户真正关心的是：这个 AI 能不能帮我解决一个具体问题，能不能在我现有的系统里稳定跑起来，能不能和我的团队协作流程无缝衔接。

于是就出现了所谓的“悟空四个月消失”现象。产品表面上没有发布新功能，但团队实际上在重做内部的工作流引擎、工具调用框架、记忆体系和评测链路。这套东西，就是 AI Work 的范畴。

1.2 AI Work 是什么

先给一个通俗定义：AI Work 不是某一个模型，也不是某一个具体产品，而是 以大模型为大脑，串联工具调用、数据处理、人机协作、任务编排和结果交付的完整工作体系 。

对比一下就清楚了：

概念	关注点	典型问题
大模型	模型本身能力	模型能不能写出一段高质量代码？
AI 应用	单点功能	能不能做一个聊天机器人回答用户问题？
AI Work	端到端任务闭环	用户提出需求后，系统能否自动拆解任务、调用接口、获取数据、生成结果并交付给下游系统？

简单说， 大模型解决的是“能不能回答”，AI Work 解决的是“能不能干活” 。

1.3 为什么大厂如此看重 AI Work

从商业角度看，模型能力再强，如果无法嵌入到企业真实业务流程中，就无法形成付费价值。AI Work 是大模型进入生产环境的必经之路。

从技术角度看，单次模型调用只能完成“生成文本”或“理解语义”这类原子操作，但真实业务往往需要多步操作。比如“帮我把上周的销售数据做成图表，并总结下滑原因”，这需要模型调用查询接口、读取数据库、分析数据、生成图表代码、用自然语言总结，最后还要把结果发送到指定渠道。这就是一个典型的 AI Work 流程。

大厂看重的，正是这种“把复杂任务拆解并自动跑完”的能力。谁先把这一层做扎实，谁就掌握了下一次 AI 产品竞争的主动权。

2. AI Work 与大模型产品迭代的关系

2.1 为什么产品迭代会出现“空窗期”

很多团队在开发 AI 产品时，早期阶段进展很快，因为只需要把模型包装成聊天窗口，用提示词引导模型回答问题就行。但一旦进入生产环境，问题立刻变多：

• 模型输出的格式不稳定，下游系统无法解析。
• 工具调用总是失败，或者模型不知道该调用哪个工具。
• 多轮对话中，模型记不住用户之前提到的关键信息。
• 任务执行到一半中断，没有恢复和补偿机制。
• 无法评估“任务完成质量”，因为这不是简单的对错问题。

这些问题都不是靠“换一个更大的模型”能解决的。它们属于工作流、状态管理、任务调度和评测体系的问题，也就是 AI Work 要解决的核心问题。

所以“悟空四个月消失”背后，很可能就是团队在从“模型包装阶段”跨向“工作流成熟阶段”。这个阶段的研发工作量，远大于写几个提示词模板。

2.2 从“模型优先”到“工作流优先”

过去两年的产品迭代节奏是：模型升级 → 应用能力跟着升级。

现在正在转变成：工作流能力升级 → 模型升级只是其中一个环节。

举个例子，以前开发者关心的是“模型能不能理解一段复杂的 SQL 需求”，现在关心的是“模型生成的 SQL 能否安全地在生产库上执行，并在失败时自动回滚”。前者是模型能力问题，后者是工作流能力问题。

这种转变也解释了为什么大厂愿意在 AI Work 上投入巨大资源。不是因为模型不重要，而是因为模型已经趋向同质化，真正拉开体验差距的是模型外围的工作流体系。

2.3 AI Work 的成熟度分层

为了更清楚地理解 AI Work，可以把它分成几个成熟度阶段：

阶段	特征	常见形态
L1 单点问答	模型只做文本生成	聊天机器人、翻译工具
L2 工具辅助	模型可以调用少量外部工具	带搜索功能的问答系统
L3 多步编排	模型可以按计划执行多步任务	自动化报告生成、智能客服
L4 自主工作流	模型可以自主决策、动态调整计划	AI 员工、数字员工
L5 多智能体协作	多个模型代理分工协作完成复杂任务	跨部门自动化业务流程

目前的行业现状是：大部分产品停留在 L2 到 L3 之间，少数头部产品在向 L4 探索。大厂重仓 AI Work，本质上是在抢占 L4 和 L5 的入场券。

3. AI Work 的技术架构拆解

3.1 一个典型的 AI Work 系统包含哪些模块

以我接触过的企业级 AI 应用为例，一个完整的 AI Work 系统通常包含以下模块：

• 意图理解与任务规划 ：接收用户请求，拆解成多个子任务，并排列执行顺序。
• 工具注册与调用 ：将内部 API、数据库操作、第三方服务封装成“工具”，供模型调用。
• 记忆管理 ：保存用户偏好、历史对话、中间结果，支持短期记忆和长期记忆。
• 工作流编排引擎 ：负责执行任务计划，处理分支、并行、循环和异常。
• 人机协同机制 ：在关键节点暂停，等待人工审批或输入。
• 结果交付与反馈回路 ：把最终结果格式化输出，收集用户反馈，优化后续执行。

3.2 工作流引擎是整个系统的核心

如果要用一个词概括 AI Work，那就是“编排”。模型负责思考和生成，而工作流引擎负责把“思考”变成“行动”。

一个成熟的工作流引擎需要具备以下能力：

• 状态管理 ：保存每个任务的执行状态，包括已完成、执行中、失败、等待人工确认。
• 重试机制 ：当某个环节超时或失败时，自动重试，而不是直接中断整个流程。
• 人工介入 ：遇到敏感操作时暂停，等待管理员审批。
• 可视化追踪 ：完整记录每一步的执行过程和输入输出，方便排查问题。

3.3 工具调用的关键设计

模型本身不具备执行能力，它必须通过“工具”来影响外部世界。所以工具调用的设计直接决定了 AI Work 的上限。

常见的工具包括：

• API 调用类工具 ：查询订单、发送消息、创建工单。
• 代码执行类工具 ：执行 Python 脚本、生成图表。
• 数据库工具 ：在授权范围内执行 SQL 查询。
• 知识库检索工具 ：从向量数据库中检索相关文档。

工具设计有几点需要注意：

1. 描述要清晰 ：模型需要根据描述决定何时调用工具，描述模糊会导致误调用。
2. 参数要严格校验 ：模型生成的参数不可完全信任，必须做格式校验和权限校验。
3. 失败要有梯度反馈 ：工具失败时，要把错误原因反馈给模型，让模型尝试修复。

下面给一个工具注册的示例思路：

# 文件路径：tools/register.py
# 说明：示例代码，需要根据实际框架和版本调整

from pydantic import BaseModel, Field

class QueryOrderInput(BaseModel):
    order_id: str = Field(description="订单ID，例如 OD20250101001")
    user_id: str = Field(description="用户ID")

def query_order(order_id: str, user_id: str) -> dict:
    """
    查询订单状态，仅允许查询当前授权用户自己的订单。
    实际项目中，这里需要调用内部订单系统的 API。
    """
    if not order_id.startswith("OD"):
        raise ValueError("订单ID格式不正确")
    # 模拟查询结果
    return {"order_id": order_id, "status": "已发货", "logistics": "顺丰速运"}

# 注册到工具中心，供模型调用
TOOL_REGISTRY = {
    "query_order": {
        "name": "查询订单",
        "description": "根据订单ID和用户ID查询订单状态和物流信息",
        "input_schema": QueryOrderInput,
        "handler": query_order,
    }
}

这里的关键点是：工具描述写清楚“什么时候用、参数是什么、会返回什么”，模型才能准确选择工具。

4. 国产 AI Work 的落地场景解析

4.1 企业知识库问答

这是目前国产 AI Work 落地最成熟的场景之一。传统知识库问答只是“把命中的文档片段拼给模型生成答案”，而 AI Work 版本会在问答前后加入更多环节：

• 自动识别用户身份，判断其查看权限。
• 根据问题意图，决定检索内部文档还是互联网公开资料。
• 如果答案需要数据支撑，自动调用 BI 系统查询实时数据。
• 生成答案后，附上参考来源和置信度提示。
• 如果用户追问，基于记忆模块记住前文语境。

4.2 智能客服工单处理

一个典型的 AI Work 客服流程是：

用户提交问题 → 模型理解意图 → 检索知识库 → 调用订单系统查询用户订单 → 判断是否需要人工介入 → 生成回复或创建工单 → 跟踪用户满意度。

这个流程涉及至少四次工具调用和两次条件分支，如果靠传统的对话机器人架构很难实现，但用 AI Work 编排引擎就能很好地串起来。

4.3 自动化数据报告

工作中经常遇到这样的需求：“每周一早上，自动拉取上周业务数据，生成 PPT 报告，发送到管理层邮箱。”

在 AI Work 体系下，这个需求可以拆成：

1. 调用数据仓库查询上周核心指标。
2. 使用 Python 代码生成图表。
3. 把图表和结论组装成 PPT。
4. 通过消息机器人发送到指定群聊。

模型在这里要做三件事：理解需求、拆解步骤、生成中间代码。而工作流引擎负责定时触发、执行任务、重试失败环节。

4.4 编程辅助与自动化开发

编程是 AI Work 另一个重要场景。相比“让模型写一段代码”，成熟的 AI Work 系统会实现：

• 扫描项目代码仓库，理解模块结构和依赖关系。
• 接收开发任务，拆解为“修改哪个文件、新增哪个函数、补充哪些测试”。
• 生成代码后，自动执行单元测试。
• 如果测试失败，把错误信息反馈给模型，让其修复，并设置最大重试次数。
• 最终生成提交说明，由开发者审查后合并。

这类系统已经不再是一个“代码补全插件”，而是一个参与软件交付全流程的 AI 工作流。

5. 从零搭建一个最小 AI Work 流程

5.1 明确目标

这一节我们用代码和配置，演示一个极简的 AI Work 流程思路。目标场景是：用户输入“查询订单 OD20250101001 的物流状态”，系统自动调用订单查询工具，并把结果转成自然语言回复。

先说明：这里只是演示核心思路，不是完整可上线的项目。实际项目中需要使用 LangChain、Dify、Coze 或自研引擎来编排，模型名和 API 也需要按实际环境替换。

5.2 定义工作流配置

工作流配置用于描述“任务拆解和执行顺序”：

# 文件路径：workflows/order_query.yaml
# 说明：演示用工作流配置，实际字段以所选引擎为准
id: order_query_workflow
name: 订单查询工作流
description: 根据用户输入查询订单并生成回复

steps:
  - id: intent_parse
    type: llm
    prompt: |
      请判断用户意图。如果用户想查询订单物流，输出 "query_order"。
      用户输入：{{user_input}}
    output_var: intent

  - id: extract_params
    type: llm
    prompt: |
      从用户输入中提取订单ID和用户ID，按 JSON 格式输出。
      示例：{"order_id": "OD123", "user_id": "u456"}
    output_var: params

  - id: call_tool
    type: tool
    tool_name: query_order
    input: ${{ steps.extract_params.output }}
    depends_on:
      - intent_parse
      - extract_params
    retry: 2

  - id: generate_answer
    type: llm
    prompt: |
      根据工具返回结果生成自然语言回复。
      工具结果：{{ steps.call_tool.output }}
    output_var: answer

  - id: output
    type: return
    value: ${{ steps.generate_answer.output }}

这个配置体现了 AI Work 的核心思想： 模型负责理解和生成，工作流负责顺序控制和容错 。

5.3 编写简单的执行代码

仅用 Python 代码演示如何“按步骤执行”：

# 文件路径：workflows/simple_runner.py
# 说明：演示代码，实际项目请使用成熟的工作流引擎

import yaml

def run_step(step_name: str, context: dict):
    """模拟执行单个步骤，实际项目中需要接入 LLM 和工具系统。"""
    print(f"[执行步骤] {step_name}")
    # 这里仅做演示，真正的 LLM 调用和工具调用需要自行接入
    return context

def run_workflow(workflow_file: str, user_input: str):
    with open(workflow_file, "r", encoding="utf-8") as f:
        workflow = yaml.safe_load(f)

    context = {"user_input": user_input}

    # 实际项目中需要根据依赖关系决定执行顺序，这里简化为顺序执行
    for step in workflow["steps"]:
        result = run_step(step["id"], context)
        context[step["id"]] = result

    print("工作流执行完毕")
    return context

if __name__ == "__main__":
    run_workflow("workflows/order_query.yaml", "查一下订单 OD20250101001 的物流")

这段代码本身没有实际调用大模型，但它展示了一个重要原则： AI Work 的本质是把模型能力嵌入到可控的执行流程中，而不是让模型自由发挥 。

5.4 如何接入真实模型和工具

在真实项目中，你需要：

1. 选择一个大模型 API 或私有化模型服务。
2. 把“意图识别”“参数抽取”“答案生成”等步骤替换为真实的模型调用。
3. 把“工具调用”步骤替换为对内部系统的 HTTP 调用或 SDK 调用。
4. 为每个步骤增加日志、超时、重试和异常处理。
5. 增加中间结果的存储，方便出问题时回溯。

推荐的做法是：先画清楚流程图，再映射成代码或配置，最后才接模型。不要一开始就让模型掌控整个流程。

6. AI Work 项目中的常见问题与排查思路

6.1 工具调用失败率居高不下

问题现象	常见原因	解决思路
模型经常调用不存在的工具	工具描述不清晰，或工具列表过长	精简工具列表，优化描述，增加调用前的意图校验
工具执行报错但模型不知道	工具错误信息没有反馈给模型	把错误信息封装成提示词回传给模型，让其调整参数重试
工具参数格式错误	模型输出的参数与工具 schema 不匹配	使用 JSON Schema 做严格解析，不合法就重新生成

排查时重点看日志：模型到底输出了什么？工具返回了什么？中间有没有截断？大多数工具调用问题都是提示词设计和返回信息不畅造成的，不一定需要换模型。

6.2 多步任务总是执行到一半就中断

这种情况通常是因为工作流没有做状态持久化。一旦某一步超时或服务重启，任务状态就丢了。

解决方向：

• 使用数据库保存任务状态。
• 每执行完一个步骤就更新状态。
• 支持从失败步骤恢复，而不是从头执行。
• 设置合理的超时和重试策略。

6.3 模型输出不稳定

模型生成天然带有随机性，这在 AI Work 中是个大问题。参数抽取漏字段、意图判断错误、生成格式多变，都会导致下游环节崩溃。

常用办法：

• 把温度参数调低。
• 提供更明确的 few-shot 示例。
• 用结构化输出约束（如 JSON Schema）。
• 在模型输出后增加规则校验层，不合格就重新生成。
• 重要节点的判断不依赖单次输出，可以多次采样投票。

6.4 如何评估 AI Work 的效果

很多团队抱怨“做完之后不知道效果好不好”。这是因为 AI Work 的评价指标比单次问答复杂得多。

建议从四个维度建立评测集：

维度	说明	示例指标
任务完成率	整个工作流是否走到了最终交付	完成率、中断率
单步准确率	每个关键步骤的输出是否正确	意图识别准确率、参数抽取准确率
工具调用质量	调用是否合理、失败率是否可接受	工具误用率、重试次数
用户体验	最终交付结果是否满足需求	用户采纳率、人工修正率

建设评测集时，最好收集真实业务中的失败案例，定期回归，避免“改好一个场景，弄坏三个场景”的窘境。

7. 搭建 AI Work 的最佳实践与工程建议

7.1 先把流程画清楚，再谈模型能力

很多团队的习惯是“先接模型，再想流程”，这会导致后期返工。正确路径是：

1. 明确用户任务的全过程，画出步骤图。
2. 标出每个步骤需要什么输入、产生什么输出。
3. 标出哪些步骤适合模型用，哪些必须走规则。
4. 设计好在哪些节点需要人工介入。
5. 最后才选择和配置模型。

7.2 工具要保持“小而专”

每个工具只做一件事，不要做一个“万金油工具”。模型更容易理解职责单一的工具。

比如不要设计一个 execute_task 工具，而应该拆成：

• query_order
• send_message
• create_ticket
• get_user_info

工具越多时，越要注意命名和描述规范。可以约定一个模板：

工具名：动词 + 业务对象
描述：什么时候用 + 做什么 + 返回什么
参数：每个参数的含义、格式、是否必填

7.3 安全边界要前置设计

AI Work 把模型从“建议”变成了“执行”，这就带来了新的安全风险。

必须做到：

• 所有工具调用都要校验权限，模型不能绕过权限体系。
• 敏感操作（删除、修改、转账、发布）必须插入人工审批节点。
• 外部输入不能直接拼接到提示词或 SQL 中，防止注入。
• 对模型生成的代码，在沙箱环境中执行并限制资源。
• 完整记录操作日志，保留审计追踪。

7.4 引入“人机协同”而不是“全自动化”

现阶段 AI Work 不适合追求全自动化。风险高、影响大、不可逆的环节，宁可让人多确认一次。

合理的做法：模型负责完成“可自动完成且风险低”的部分，关键决策保留人工审批。这既提升了效率，又控制了风险。

7.5 建立持续评测和灰度发布机制

AI Work 系统修改一个提示词或工具逻辑，影响范围往往不是单点，而是整条链路。所以必须要有：

• 可以回滚的流程版本管理。
• 小流量灰度测试。
• 线上运行监控和告警。
• 定期用真实失败案例补充评测集。

8. 总结与下一步学习路线

回到最初的问题：大厂为什么如此看重 AI Work？

最直接的原因是，大模型本身的差异化窗口正在关闭，而工作流能力的差异化窗口刚刚打开。“悟空四个月消失”式的产品节奏，未来会越来越多。这未必是坏事，反而说明 AI 产品正在从“炫技”走向“干活”。

如果你想系统学习 AI Work，建议按下面路线推进：

1. 理解基础 ：学习提示词工程、函数调用（Function Calling）、RAG 的基本原理。
2. 使用编排工具 ：上手 Dify、Coze、LangChain 或自研轻量引擎，跑通一条简单的工作流。
3. 深入架构 ：理解 Agent、记忆、工具注册、任务规划、状态机等核心概念。
4. 工程化实践 ：用真实业务场景搭建一个 AI Work 系统，重点关注评测、监控、安全和灰度发布。
5. 跟踪行业动态 ：观察头部产品的更新方向和开源项目演进，把握技术趋势。

最后想补充一句：AI Work 目前还处于早期阶段，没有人拥有“标准答案”。如果你正在做的项目也涉及工作流编排、Agent 设计或者工具调用，欢迎在评论里聊聊你的实现思路和踩过的坑。