通用 Agent 之后，企业真正应该落地什么？

上个月一个 CIO 给我看他们的 AI 成果清单，讲得很顺：接入了多少个 Agent、开了多少智能体账号、买了多少 token、做了几场全员培训。我听完问了他一句：「你们每天真实发生的业务里，有多大比例是 Agent 参与完成的？」

他停住了。停了几秒，说：「这个我们没统计过。」

这不是个例。绝大多数企业的 AI 成绩单，记的都是投入项——买了多少、接了多少、开了多少。而真正决定 AI 能不能产生业务价值的那个数字，没人算过。

通用 Agent 之后，企业要解决的，不是再做一个更聪明的 Chat，而是把 AI 真正嵌进每天发生的协同工作流。

过去企业数字化的路径大致是：

业务流程 → 表单 / 审批系统 → 人来操作系统
# generated by hugo AI

AI 时代正在变成：

业务目标 → Agent 理解与执行 → 人做判断与审核
# generated by hugo AI

所以引入通用 Agent 只是第一步。真正的问题是：你的企业有没有一个能让 Agent 进入、理解、执行、反馈、持续优化的工作流载体。 没有载体，Agent 再聪明也只是停在对话框里。

一、九步链条：Chat 和工作流的差别

通用 Agent 很强，但企业的真实工作不是一个个孤立的问题。

一个运营人员每天可能要干这些事：查看商品数据 → 分析销售表现 → 找出异常商品 → 做竞品分析 → 生成运营方案 → 分配任务 → 跟进执行 → 汇总结果 → 向主管汇报。

九步。如果 Agent 只是一个 Chat，它每次都要你重新交代背景：数据在哪、口径是什么、上次做到哪了、结果发给谁。九步里它只能帮你做「分析」和「生成」两步，剩下七步还是你在搬运信息。它解决的是一个点。

但如果 Agent 能进入业务工作流，这九步就变成一条链：数据它自己取，异常它自己标，方案生成后直接派成任务，执行进度自己跟，汇总自己写，最后按你主管要的格式发出去。你只在两个点出现——定目标、审结果。

这才是从「助手」到「员工」的分界。我在 Agent 进入企业，还差一个工位 里把这个条件拆成五层：Agent 要能干活，缺的从来不是智能，是身份、权限、上下文、工具和验收标准这一整套工位。九步链条跑不通，基本都是工位没配齐。

所以企业 AI 落地的关键，不只是模型能力，而是工作流。模型能力决定 Agent 会不会做，工作流决定它能不能一直做下去。

二、三类工作，三种载体

好消息是，企业没必要一开始就重新发明一套 AI 原生工作系统。大量工作已经有非常成熟的数字化载体，Agent 该做的是进去，不是替代。

按驱动方式分，企业协同工作流大致是三类。

第一类：重流程 —— 宜搭

请假、报销、采购、入职、转岗、离职、客户审批、合同流程、各类业务审批。

这类工作的特点是：路径固定、节点清晰、有明确的责任人和审批规则，绝大多数请求是标准情况。 它已经有十几年的数字化沉淀，缺的不是系统，是让 Agent 能在节点上替人干活。

因此适合用宜搭把流程固化下来，再让 Agent 进入流程节点执行工作。宜搭的价值不是让 AI 聊天，而是让 AI 进入企业已经存在的业务流程。

第二类：重项目管理 —— Teambition

产品研发、市场活动、门店开业、客户交付、大型项目、跨部门协作。

这类工作的核心不是审批，而是 目标拆解与推进。项目没有固定路径，任务边做边变，风险靠人盯，进度靠催——而「盯」和「催」恰好是最消耗人、也最适合交给 Agent 的部分。

Agent 可以从项目目标开始，拆解任务、分配工作、跟踪进度、识别风险、推动协作者，最终完成项目复盘。因此 Teambition 的价值不是多一个看板，而是让 Agent 承接「推进」这个动作本身。

第三类：重数据运营 —— AI 表格

这一类我认为最值得关注。

大量企业运营工作既不是传统流程，也不是严格意义上的项目，而是围绕一张表持续发生：电商运营、销售线索运营、客户运营、招聘运营、内容运营、门店经营、库存管理、财务经营分析。

它们的共同特点是：既没有审批流那种固定路径，也没有项目那种明确终点，而是每天重复发生同一组动作——数据进来、看异常、想动作、派给人、看结果、调策略。表的每一行是一个运营对象（一个 SKU、一条线索、一个客户、一家门店），表的状态就是业务的状态。

传统表格只是记录数据。AI 表格可以进一步成为运营人员的 AI 工作流与协同空间。

以电商运营为例（这是机制示意，用来说明结构，不是某个客户的战报）：一张商品表，每行一个 SKU。Agent 每天扫一遍——哪些转化率掉了、哪些库存要断、哪些竞品在降价；把异常行标出来，附上归因和建议动作；运营点确认，动作直接派成任务；第二天回来看这个动作有没有把指标拉回来，没拉回来就换打法。

这已经不是「智能表格」了，而是 一个围绕数据持续运转的运营系统：表格是状态，Agent 是推进器，人是决策点。

我在 AI 表格做 Scrum 团队的大脑 里跑过这个结构的研发版本——表格不是任务看板，是团队的工作记忆；后来在 用一张钉钉表格，统一管理所有 Agent 的定时任务 里又跑了一遍调度版本。两次都是同一件事：把「调度」和「状态」变成数据，Agent 就能接手推进。

三、判断框架：不是选产品，是认工作方式

三类载体可以压成一张很简单的表：

我把它叫 载体三分法。它真正的用法不是选产品，而是换问题：

所以不是问「我们该上宜搭还是 AI 表格？」，而应该问「我这块业务是靠流程驱动、项目驱动，还是数据驱动？」

认错了类型，后面全错。最常见的错法是把数据运营当流程做——给电商运营配一套审批流，结果运营每天真正的动作（看异常、调策略）根本不在流程里，Agent 进去也没活干。反过来也常见：把项目管理当数据运营做，一张表列满任务，但没有目标拆解和推进机制，表越填越长，项目照样逾期。

判断清楚之后，动作就很直接：流程驱动的业务，优先流程 AI 化；项目驱动的业务，优先项目 AI 化；数据驱动的业务，优先数据运营 AI 化。

这和 企业业务流程 AI 化的决策框架 是两个不同的轴，不冲突：那篇回答「哪个流程先 AI 化」（ROI × 技术可行性），这篇回答「Agent 该进哪个载体」（工作类型 → 已有数字化载体）。先用载体三分法定位，再用决策矩阵排优先级。

四、CIO 该换指标：从 Agent 数量到 Workflow 覆盖率

回到开头那位 CIO。企业 AI 落地很容易陷入一个误区：把「上了多少 AI」当成绩——接入了多少 Agent、开了多少智能体账号、买了多少 token、做了几场培训。

这些指标当然有意义，但它们是投入指标，花钱就有。更重要的问题是：企业每天真实发生的工作里，有多大比例是 Agent 参与完成的？ 这是产出指标，要动业务才有。

建议把企业 AI 指标换成这一组：

这八个指标里，前四个量 广度（覆盖了多少工作），中间两个量 深度（覆盖的部分有多自动），最后两个量 质量和进化。只看广度会做出一堆「接入了但没跑起来」的僵尸 workflow；只看深度会在少数场景里过度打磨，整体覆盖率不动。

光有指标定义还不够用，因为它立刻会撞上一个执行问题：覆盖率的分母是什么？ 是流程数量、任务数量，还是别的？

我的答案是：分母应该是「步」，不是「流程」也不是「任务」。 按流程算，一个二十步的合同流程和一个两步的请假流程权重一样，覆盖率会被简单流程刷高；按任务算，Agent 建了一堆自动任务反而把分母撑大、覆盖率做低，指标方向就反了。按步算，每一步要么有人做、要么有 Agent 做，口径最干净，而且能直接映射到前面那张载体三分表——每一步属于哪一类载体，决定了它计入哪一类的覆盖率。

但「步」的边界谁来定，这是这套口径最容易被钻空子的地方——把一步拆成十步，覆盖率立刻好看。我的处理办法是：步的边界跟着载体系统的原生事件走，不跟着人的描述走。 宜搭的一次节点流转、Teambition 的一次任务状态变更、AI 表格的一次字段写入，各算一步。这样定义有两个好处：一是不可协商（系统日志里就这么多事件），二是跨企业可比（同一种载体的步长一致）。代价是粒度不完全均匀——AI 表格的一步可能比宜搭的一步细。但这个代价换来的是 这个数字没法靠重新定义来刷高，而可刷高的指标等于没有指标。

这套口径落地只需要一份留痕：每步记下 workflow_id、属于哪类载体、谁执行的、有没有被验证过。剩下的都是算术：

from __future__ import annotations

from dataclasses import dataclass, field
from datetime import date
from enum import Enum


class CarrierKind(Enum):
    """三类载体：决定这一步该计入哪一类覆盖率。"""

    PROCESS = "process"      # 重流程 —— 宜搭
    PROJECT = "project"      # 重项目 —— Teambition
    DATA_OPS = "data_ops"    # 重数据运营 —— AI 表格


@dataclass(frozen=True)
class StepRecord:
    """工作流里一步的留痕。覆盖率的分子分母都从这里算出来。"""

    workflow_id: str
    carrier: CarrierKind
    step: str
    actor: str          # "agent" | "human"
    verified: bool      # Agent 做的这步，有没有通过验收
    on: date


@dataclass
class CoverageReport:
    """企业 AI 成绩单。注意：这里没有任何一项投入指标。"""

    total_steps: int = 0
    agent_steps: int = 0
    verified_agent_steps: int = 0
    by_carrier: dict[CarrierKind, tuple[int, int]] = field(default_factory=dict)

    @property
    def coverage(self) -> float:
        """真覆盖率：只算 Agent 做了、且通过验收的步。"""
        if self.total_steps == 0:
            return 0.0
        return self.verified_agent_steps / self.total_steps

    @property
    def human_intervention(self) -> float:
        """人工介入率：责任有没有真转移过去，看这个数降不降。"""
        if self.total_steps == 0:
            return 0.0
        return (self.total_steps - self.agent_steps) / self.total_steps


def build_report(records: list[StepRecord]) -> CoverageReport:
    """为什么 verified 单独算：Agent 执行了但没通过验收的步，
    计入 agent_steps（用于人工介入率）却不计入 coverage。
    否则「Agent 跑了一堆错活」也会把覆盖率刷高。
    """
    report = CoverageReport()
    buckets: dict[CarrierKind, list[int]] = {k: [0, 0] for k in CarrierKind}

    for r in records:
        report.total_steps += 1
        bucket = buckets[r.carrier]
        bucket[0] += 1
        if r.actor == "agent":
            report.agent_steps += 1
            bucket[1] += 1
            if r.verified:
                report.verified_agent_steps += 1

    report.by_carrier = {k: (v[0], v[1]) for k, v in buckets.items()}
    return report


if __name__ == "__main__":
    demo = [
        StepRecord("w1", CarrierKind.DATA_OPS, "标异常", "agent", True, date(2026, 9, 9)),
        StepRecord("w1", CarrierKind.DATA_OPS, "定策略", "human", False, date(2026, 9, 9)),
        StepRecord("w1", CarrierKind.DATA_OPS, "派任务", "agent", True, date(2026, 9, 9)),
        StepRecord("w1", CarrierKind.DATA_OPS, "写归因", "agent", False, date(2026, 9, 9)),
        StepRecord("w2", CarrierKind.PROCESS, "预审报销", "agent", True, date(2026, 9, 9)),
        StepRecord("w2", CarrierKind.PROCESS, "终审", "human", False, date(2026, 9, 9)),
    ]
    rep = build_report(demo)
    # 6 步里 Agent 执行 4 步，但其中 1 步没通过验收 → 覆盖率 3/6 = 0.5
    print("total:", rep.total_steps)                  # 6
    print("coverage:", round(rep.coverage, 3))         # 0.5
    print("human_intervention:", round(rep.human_intervention, 3))  # 0.333
    print("by_carrier:", {k.value: v for k, v in rep.by_carrier.items()})
    # {'process': (2, 1), 'project': (0, 0), 'data_ops': (4, 3)}
# generated by hugo AI

这段代码里有两个设计值得单独说，因为它们对应表格里的两个造假点。

第一，verified 必须单独算。Agent 执行了 4 步、但只有 3 步通过验收，覆盖率就是 3/6 而不是 4/6。不区分「跑了」和「跑对了」，覆盖率就是个可以刷的数字。 这也是上面表格里「上线一周就停的也算」那个坑的技术解法。

第二，by_carrier 里那个 (0, 0) 是这份报表最有价值的输出。它说的是：这家企业的项目类工作，Agent 一步都没进去。一个总数 50% 的覆盖率，配上某一类完全是零——这才是 CIO 该拿去开会的数字，比任何单一的总覆盖率都更能指出下一步该动哪里。

这两个 property 之间还差一个数：agent_steps − verified_agent_steps，也就是 Agent 执行了、但没通过验收的步数。上例里是 4 − 3 = 1。它既不在覆盖率里（没通过验收不算数），也不在人工介入率里（确实是 Agent 跑的，不是人跑的）。单独盯这个数，比盯人工介入率更精确——人工介入率高可能是「还没交给 Agent」，而这个数高是「交给了、但交砸了」，两种病要开两种药。

它们最终指向一条三段式的路径：

AI 辅助        →      AI 参与        →      AI 运营
人干活，AI 给建议    AI 干一段，人审一段    AI 持续跑，人管例外和标准
# generated by hugo AI

这三段不是技术阶段，是 责任转移阶段——每往前一段，就有更多的人类判断被固化成 Agent 可执行的标准。所以「人工介入率」这个指标最难也最诚实：它降不下去，说明责任没转过去，前两段的投入就还停在账面上。

顺带说一句，成功率和「成功标准由谁定」这两个问题是连着的。我在 数字员工按工作收费，谁来签「干完了」 里论证过：Agent 任务成功率如果没有一个署名的标准来源，这个数字就只是厂商自说自话。指标能落地，前提是评测标准有主人。

五、真正的变化是组织，不是软件

指标换掉之后，你会发现这背后不是一个软件升级问题，而是一次企业工作方式的变化。

过去：人设计流程，人执行流程，系统负责记录。 现在：人设计标准，Agent 执行流程，系统负责推进和留痕。

差别在「系统」那一栏——它从档案柜变成了推进器。这个转变我在 AI 时代的企业数字化 里从基础设施角度讲过（工作 Agent 化、知识 AI Ready 化、软件 CLI 化）；那三根柱子是这篇的前提——没有 CLI 化的软件，Agent 进不了载体；没有 AI Ready 的知识，它进来了也不知道口径。

更深一层的变化在流程设计的默认前提上：

过去的默认前提：每一步都有人在看着
  → 异常靠人发现，推进靠人催，标准在人脑子里

未来的默认前提：每一步都有 Agent 在跑
  → 人只定义什么算正常、什么算异常、异常了找谁
# generated by hugo AI

这两个前提不能混着用。很多企业 AI 项目做不出效果，是因为按第一个前提设计了流程，却指望 Agent 按第二个前提运行——标准没写下来，Agent 就只能猜，猜错了人再兜底，最后人比原来更累。

人的角色也随之变化：从执行者，变成标准制定者和例外裁决者。 一个运营原来一天处理两百行数据，往后是定义「什么样的行该被拦下来」，然后处理 Agent 拦下来的那二十行。工作量没少，但工作的性质变了——他的产出从「处理了多少」变成「定义得多准」。

这对绩效体系是个真问题：原来考核处理量，往后该考核标准质量和例外处理水平。这一步没跟上，组织会一边上 Agent，一边用旧指标惩罚那些把标准定义好的人。

反方：这是不是在三款产品打广告

写到这儿，最该被正面回应的反驳有两个。

反驳一：「载体三分法」说到底就是钉钉的三款产品——宜搭、Teambition、AI 表格。把自家产品线包装成企业工作方式的分类框架，这是销售话术，不是方法论。

一半是真的。三个载体确实是钉钉的产品，这篇文章也确实在钉钉的语境里写。但拆开看，这个框架的可证伪部分不依赖产品归属：企业协同工作流按「流程驱动 / 项目驱动 / 数据驱动」分三类，这个分法换成任何厂商的产品线都成立——微软那边对应 Power Automate、Planner、Lists，飞书那边对应审批、项目、多维表格。如果这个三分法是错的，证据会是「存在第四类大量企业工作装不进这三个驱动方式」，而不是「它恰好能映射到钉钉产品」。事实上我认为更准确的表述是：每类工作都应该有一个「状态可被 Agent 读、动作可被 Agent 执行」的载体，钉钉的三款产品只是这个载体的当前实现。 载体可以换，三分不动。

反驳二：Workflow 覆盖率听起来美好，但「把每一步都留痕、标注载体和验收状态」的埋点成本，比多买几个 Agent 账号贵多了。中小公司玩不起。

成本是真的，但我认为这笔账算反了。第一，三类载体本身就是数字化系统——宜搭的每次流转、Teambition 的每次任务状态变更、AI 表格的每次编辑，天然就是带时间戳和操作人的日志，覆盖率报表是从已有留痕里聚合出来的，不是额外埋点。真正要补的只有两样：给每步标载体归属（一次性映射），以及定义「什么算通过验收」（这件事你在 评测集是一份没人签字的文件 的意义上本来就必须做，不做的话你的 Agent 质量本来就没人管）。第二，对比一下不度量的代价：开头那位 CIO 的清单式投入已经花出去了，但没有人能回答「钱有没有变成业务结果」——度量覆盖率不是新增成本，是给已经花掉的投入装一个止损和纠偏的仪表盘。

这两个反驳回应完，我反而更确定这篇文章的主张该收窄成一句话：三分法不是产品说明书，覆盖率不是 KPI 游戏——它们是同一个判断的两面，企业 AI 的价值单位是「被 Agent 接管的工作步」，不是「被采购的 Agent」。

最后

企业 AI 落地的竞争，不在谁的 Agent 更聪明，在谁的工作流更能被 Agent 接管。模型是买得到的，工作流是长出来的——它长在你十几年的流程沉淀、项目习惯和数据口径里，抄不走。

这也是为什么我认为 CIO 该盯的不是 Agent 数量：数量是采购决策，覆盖率是组织决策。前者一个季度就能做完，后者要做几年。

AI 落地的差距，不在模型，在 Workflow 覆盖率。

你们企业现在算的是哪一类指标？如果换成 Workflow 覆盖率，第一类（流程）、第二类（项目）、第三类（数据运营）里，哪一类覆盖得最深、哪一类还是零？欢迎留言讨论。

See also

• 数字员工按工作收费，谁来签「干完了」
• 未来的员工，有两份成本单
• 制造业选中的 AI，运行时没有大模型
• 谁停掉了数字员工的早读？
• Grok Bot 能当队友，还当不了员工