当 Agent 开始 24 小时上班，KPI 不能再考核“人忙不忙”

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

这些产品最后是否能跑出来，当然还需要时间验证。但它们共同指向一个变化：AI 正在从“一次性回答问题”，变成“持续在线执行工作”。

表面看，这是工具升级，但在企业里，它会开始冲击管理体系。

我对这个问题比较敏感，也是因为来自过去十多年做神策数据的经历。我们服务过很多重运营、重数据的企业客户，也在自己公司内部反复建设过数据看板、告警、流程系统和经营分析机制。时间久了会发现，很多团队并不缺数据，真正卡住他们的，是数据、动作和责任之间隔了太多人工节点。

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

这个时候，如果 KPI 还在考核“每天做了多少报表、开了多少会、发了多少提醒”，就已经不太合理了。

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

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

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

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

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

销售每天拜访多少客户，运营每天做多少报表，产品经理每周整理多少需求，管理者开多少例会、做多少同步、催多少进度，这些指标不能简单说错。因为在过去，很多过程动作确实是结果的前置条件。

没人盯数据，异常就可能被错过；进度没人催，项目就容易卡住。周报、客户反馈整理这些看起来琐碎的事情，也确实能帮助管理者和产品团队补齐信息。

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

问题在于，这套方法很容易滑向另一个方向：衡量重点渐渐偏向了“这个人看起来忙不忙”，业务结果反而退到了后面。

一个运营同学做了很多报表，不代表业务真的变好了；一个管理者开了很多会，不代表组织真的更高效了；一个产品经理整理了很多需求，不代表产品方向就更清楚了。

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

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 时代，管理者要先把那些没人爱做、又每天都在发生的流程重新盘一遍。

让人类专注于判断、边界和责任，让数字劳动力专注于执行、监控和反馈。

接下来更值钱的人，是能把模糊目标说清楚、把流程边界画清楚、把验收标准定清楚，并且在关键时刻站出来负责的人。