智能体全天候工作后KPI不应再考核员工忙碌度

最近一段时间，Notion 推出了 Custom Agents，强调可以通过触发器和计划任务自动执行团队里的重复工作；Claude Cowork 开始支持定时任务、插件和企业管理能力；Microsoft 推出 Copilot Cowork，强调后台执行、多步骤任务和人工可控；Perplexity 的 Computer 也在强调持续监控、跨工具执行和长流程任务。

这些产品最终能否成功落地，仍待时间检验。但它们共同指向一个清晰趋势：AI 正从“一次性问答”转向“持续在线执行任务”。

表面上，这只是工具层面的升级。但在企业内部，它已开始动摇管理体系的根基。

之所以对这个问题特别敏感，源于过去十几年在神策数据的工作经历。我们服务过大量重运营、重数据的企业客户，也在自己公司内部反复折腾数据看板、告警系统、流程工具和经营分析机制。时间久了会发现一个普遍现象：很多团队并不缺乏数据，真正卡住他们的，是数据、动作和责任之间，隔着太多的人工节点。

过去，一个运营同学每天最多能盯 8 个小时的数据波动。未来，一个 Agent 可以 24 小时盯着核心指标，在阈值触发时自动分析原因，甚至执行一些低风险动作。

到了这一步，如果 KPI 还在考核“每天做了多少报表、开了多少会、发了多少提醒”，这就显得不太合理了。

所以，值得认真讨论一个具体问题：当团队里开始出现 24 小时在线的数字员工时，岗位说明书和 KPI 到底该怎么改？

旧 KPI 的问题，过去就埋在那里

过去企业设计岗位、流程和 KPI 时，有一个隐含前提：执行工作的人，是白天上班、晚上下班的人。

人不仅有固定的工作时段，注意力也有限，需要休息，需要交接，同时能盯住的任务数量也有限。更重要的是，人经常要在多个系统之间来回搬运信息——比如从 CRM 里查客户状态，从数据系统里看指标，从文档里找背景，然后再去群里提醒别人。

所以，传统管理体系自然会把很多过程动作写进岗位和 KPI。

销售每天拜访多少客户，运营每天做多少报表，产品经理每周整理多少需求，管理者要开多少例会、做多少同步、催多少进度——这些指标在过去不能简单说它错了。因为在那个年代，很多过程动作确实是结果的前置条件。没人盯数据，异常就可能被漏过去；进度没人催，项目就容易卡住。那些看起来琐碎的周报、客户反馈整理，也确实能帮助管理者和产品团队补齐信息。

很多过程型 KPI，本质上是在用“人有没有做动作”来间接推断“事情有没有往前走”。

问题在于，这套方法很容易滑向另一个方向：衡量重点慢慢偏向了“这个人看起来忙不忙”，业务结果反而退到了后面。一个运营同学做了很多报表，不代表业务真的变好了；一个管理者开了很多会，不代表组织真的更高效了；一个产品经理整理了很多需求，不代表产品方向就更清晰了。

过去我们接受这种不完美，是因为没有更好的办法。很多工作确实必须靠人一点点往前推。

Agent 进入之后，这个前提开始发生变化。

Agent 进入后，前提变了

很多人讨论 AI，第一反应还是提效。比如，一个人以前写报告要 2 小时，现在 20 分钟就能写完；以前整理客户反馈要半天，现在让 AI 快速聚类就好；以前写代码要一天，现在借助 AI 几个小时就能搞定。

这些当然都重要。但更深层的变化在后面：很多工作正在从“人推动”变成“系统推动”。数据不必等到第二天上班后再看，系统可以持续盯着；任务也不必每一步都靠人提醒，到了时间节点就自动往前推。CRM、工单、文档、邮件里的信息，可以由 Agent 先汇总出一个可判断的状态。遇到低风险异常时，它也可以先执行预设动作；真正复杂或高风险的情况，再升级给负责人。

这时，很多流程会逐渐脱离“某个人现在有没有空”的限制。任务在后台继续推进，信息先被整理成可判断的状态，异常也更早进入分级处理。

绩效考核的对象，也就跟着变了。

过去考核的是单个人的劳动产出：你做了多少报表、发了多少消息、跟进了多少客户。未来更应该考核的是一套人机系统的运行结果：你设计的这套流程，是否更快、更稳、更便宜、更可控地创造了业务结果。

如果不理解这一点，企业很容易陷入一个奇怪的状态：一边买 Agent，一边继续用旧 KPI 奖励手工劳动。工具变先进了，管理逻辑还是旧的。员工为了绩效，反而不愿意把工作真正交给系统。

一个很熟悉的运营现场

为了说得具体点，不妨拿运营岗位来举例。

运营是一个很适合观察这种变化的岗位，因为它天然包含监控、报表、触达、复盘、异常处理这些高频工作。

前几年，跟一个做线上零售的客户聊活动复盘时，就遇到过很典型的一幕。他们做完一次大促活动，第二天早会上大家围着报表看效果。新增、留存、转化、投诉率——只要有一个指标不对劲，运营同学就得开始四处拼上下文：先看数据平台里的趋势，再问研发昨晚有没有发版，再找渠道同学确认投放有没有变化，还要翻客服反馈和用户群里的吐槽。

以前看这种场景，最深的感受是，很多人其实非常负责。真正消耗人的地方，是每次出了问题，大家都得重新把上下文拼一遍。

有时候问题本身并不复杂。可能是某个活动入口在新版本里位置变了，导致点击率下降；可能是一个渠道突然换了人群包，带来的用户质量不一样；也可能是客服那边已经收到一堆反馈，但还没同步到运营和产品团队。这些信息散落在不同地方。单独看每个系统，都能解释一部分；放在一起看，才知道问题到底出在哪。

这类事情，相信很多做过运营、数据分析或者客户成功的人都不陌生。真正麻烦的地方，往往不在于看图本身，也不在于负责人的态度，而在于异常发生、被发现、被解释、被处理之间，每一步都要靠人去拉齐信息。

过去，一个运营岗位说明书里，通常会写很多具体动作：每天查看核心业务数据，输出日报、周报、月报，根据活动计划配置触达任务，监控转化率、留存率、投诉率等指标。发现异常后，要通知相关同事；活动结束后，还要定期复盘效果。对应的 KPI 也往往围绕这些动作展开：报表是否按时产出，活动是否按计划上线，触达量和推送量是多少，复盘文档写了几份，问题响应是否及时。

这些事当然都要有人负责。但如果一直这样设计岗位，运营就很容易变成“报表工、提醒工、配置工”。

把这个场景放到 Agent 时代，变化就很明显了。

一个运营 Agent 可以持续监控核心指标。发现异常后，它会先自动关联最近的版本发布、渠道投放、客诉关键词、活动配置和竞品动态，给出几个可能原因。如果只是低风险动作——比如提醒内部同事、生成排查清单、暂停某个明显异常的小流量实验——它可以直接执行。如果涉及价格、承诺、大规模用户触达，就必须等负责人审批。

（这一段描述基本就是我们做 Omni-Growth Agent 的日常。Agent 24 小时盯着客户的 Google Ads / Meta / Reddit / SEO 数据，转化率掉了、CPA 涨了、关键词排名跌了，它会自动关联出价调整、文案变化、竞品动作、平台算法更新等几条线索，给出几个可能原因。低风险动作直接执行，涉及预算、对外文案、合规边界的，必须等人审批。所以读到这一段，我自己是有点会心一笑的。）

这时，运营人员要盯住一组新的问题：指标体系设计得对不对，异常阈值是否合理，Agent 拿到的上下文是否完整，哪些动作可以自动执行，哪些动作必须审批，出了问题以后规则能不能及时修正。

新的运营岗位，重点会更靠近规则设计和结果验收。他需要定义哪些指标值得 24 小时监控，设计异常阈值和分级处理规则，也要配置 Agent 可以访问哪些数据和系统。更关键的是，他要说清楚哪些动作可以自动执行，哪些动作必须人工审批。Agent 生成报表、触达策略和复盘结论之后，运营还要负责验收质量，并持续优化自动化流程，降低错误率和人工兜底率。对关键业务结果和高风险动作的责任，也不能因为执行者变成 Agent 就消失。

好的运营会变得更重要。他要懂业务，也要懂指标；要知道哪些事适合交给机器连续跑，哪些事必须自己介入。岗位说明书也就从一张动作清单，变成了一套运行规则。

KPI 怎么改，先别搞复杂

如果岗位重心变了，KPI 就必须跟着变。

可以先用一个简单的三层框架来思考：业务结果指标、系统运行指标、人类责任指标。

第一层，业务结果指标。无论有没有 Agent，最终都要看业务有没有变好。收入是否提升、转化率是否提升、留存率是否提升、客户满意度是否提升、投诉率是否下降、人力和运营成本是否下降——这些仍然是最硬的指标。这一层很重要，因为它可以防止大家陷入“自动化自嗨”。Agent 跑得再勤快，如果业务结果没有改善，那就只是把低价值动作自动化了。就像一个团队每天自动生成 20 份报表，但没人据此做出更好的决策，这件事本身并没有太大价值。

第二层，系统运行指标。这是传统 KPI 里相对缺失的一层，也是 Agent 时代最该补的一层。比如自动化覆盖率、任务成功率、响应时延、错误率、人工兜底率、单位任务成本。这些指标听起来有点像工程指标，但管理者应该熟悉它们。过去考核运营同学每天是否按时出日报，未来更合理的问法可能是：核心指标是否 24 小时被监控？异常识别平均延迟是否下降？自动生成的分析结论有多少被业务采纳？哪些异常仍然需要人工兜底？

第三层，人类责任指标。这层最难量化，也最容易被忽略。它看的是人在关键环节有没有把关——有没有选对值得自动化的任务？有没有把任务拆成可执行、可验证的流程？Agent 拿到的信息是否完整、准确、不过量？哪些能自动做，哪些必须审批？关键时刻能不能拍板、取舍和担责？

这三层指标的好处，是把 KPI 从一句口号拆成了几个可观察的管理对象。到这一层，KPI 才开始覆盖那些过去很难量化、但出问题时一定会被追责的工作。

24 小时在线，不等于 24 小时自动放权

既然 Agent 可以 24 小时在线，是不是就意味着它可以 24 小时自动决策？

24 小时在线，解决的是执行连续性问题，不解决责任归属问题。责任仍然必须落在人身上。

具体落到管理上，可以先把 Agent 的动作分成三类。

第一类，是可以自动执行的动作。这类动作通常低风险、可回滚、规则清晰，比如生成报表、发送内部提醒、整理需求、更新状态、汇总会议纪要、给负责人推送异常清单。

第二类，是需要人工审批的动作。这类动作通常会影响外部对象或关键指标，比如批量触达客户、修改活动配置、调整投放策略、变更客户分层、发送对外邮件。

第三类，是只能给建议的动作。这类动作涉及承诺、资金、权限、合规和品牌声誉，比如价格政策、合同条款、核心客户沟通、组织调整、重大资源投入。

这三类动作不能只写在原则里，还要落到具体流程里。

每个可自动执行的动作，都应该有明确的触发条件、执行日志和回滚方式。比如自动生成日报，出错了最多影响内部判断，补一版就可以；自动发送内部提醒，也可以通过下一条消息纠正。

每个需要审批的动作，都要明确审批人和时限。比如批量触达客户，如果凌晨发现异常，Agent 可以先生成触达文案和目标人群，但是否真的发出去，要由值班负责人确认。

每个只能给建议的动作，则要严格限制工具权限。比如涉及价格、合同、核心客户承诺时，Agent 可以整理背景和风险点，但不能直接替人做决定。

边界如果不清楚，Agent 越能干，风险反而越大。所以，企业要引入 24 小时在线的 Agent，就必须同步建立审批、回滚、审计和值守机制。否则，所谓数字员工就会退化成无人负责的自动化脚本。

最后，先从一条流程开始

如果 Agent 开始进入企业，但 KPI 仍然不改，会出现几个很奇怪的现象。

企业一边买 Agent，一边继续奖励手工劳动。员工明明可以把重复工作沉淀成流程，却因为旧 KPI 要求他“亲自做很多动作”，反而不愿意自动化——因为一旦自动化了，他在旧 KPI 里看起来就“不忙了”。员工也可能从“证明自己很忙”，变成“证明自己比 Agent 更忙”。过去很多组织里，忙碌本身就是一种姿态。晚上回复消息、周末改 PPT、每天开很多会，都容易被视为投入。未来如果 KPI 不改，这种忙碌文化不会消失，只会换一种形式继续存在。

更关键的是，真正会设计流程的人，反而可能在旧绩效里吃亏。有些人花时间把一个流程设计好，让它可以持续自动运行。短期看，他亲手做的事变少了；长期看，他创造的是可复用的系统能力。如果旧 KPI 不识别这件事，就会把真正有价值的人往外推。

最危险的情况未必是企业没有用 Agent。更危险的是，企业用了 Agent 以后，仍然用旧时代的 KPI 奖励旧时代的工作方式。

那管理者接下来该怎么办？建议不要一上来就大张旗鼓做组织变革，先选一条边界清楚的流程。比如运营监控、销售线索整理、客户反馈聚类、项目状态同步、竞品信息追踪、内部知识问答。挑选标准也很简单：高频重复，边界清楚，数据可获得，结果可验证，风险可控制。

（顺便提一句，如果你正好在做海外公域营销——Google Ads / Meta / Reddit / SEO，这其实是一条非常符合上述挑选标准的流程：高频、边界清楚、数据可获得（各平台 API 都开放）、结果可验证（ROAS / CPA / 转化率都是硬指标）、风险可控制（小流量先跑、关键动作待审）。我们选这个场景做 Omni-Growth Agent，恰恰是因为它是一条很适合让 Agent 先跑起来的流程。）

选定之后，先改这条流程对应的岗位说明书。不要只写“负责某某报表、负责某某流程”，而要把职责写到目标、Agent 配置、上下文维护、动作审批、结果验收、事故复盘这些具体环节里。然后再改 KPI——业务结果有没有改善，流程运行是否稳定高效，人在目标、边界、验收和责任上是否发挥了价值，这三件事要同时看。最好能真正把自动化覆盖率、任务成功率、响应时延、错误率、人工兜底率、单位任务成本这些指标放进管理看板里。

最后建立审批、回滚和值守机制。低风险动作自动执行，中风险动作人工审批，高风险动作只给建议。所有关键动作都要留痕可审计，出错后能回滚、能复盘、能改规则。

这里有一个简单原则：凡是 AI 可以稳定完成的重复劳动，就不要继续用旧 KPI 奖励手工完成它的人；凡是 AI 可能造成真实风险的动作，就必须让人承担最终责任。

AI 时代，管理者要先把那些没人爱做、又每天都在发生的流程重新盘一遍。让人类专注于判断、边界和责任，让数字劳动力专注于执行、监控和反馈。接下来更值钱的人，是能把模糊目标说清楚、把流程边界画清楚、把验收标准定清楚，并且在关键时刻站出来负责的人。