AI 场景清单：数字化搭平台，业务用自己的 agent

孙涛公开

总述

上半年主要尝试购置 SaaS 产品，作为特定场景的整体解决方案。但 SaaS 产品贴合不了永达自己的业务和口径；可以定制开发，但那是在 SaaS 上改，不是原生的，成本也高。

下半年情况变了：

  • 一是腾讯 WorkBuddy 这类办公通用智能体开始铺开，10 月底还和企业微信做了深度融合，很多业务同事手上已经有了自己的 agent1；
  • 二是模型能力进一步提高，自建软件的成本大幅下降（IT 工单系统从燕千云换成自建就是一例）。

有一个观点说：如果用一个产品得先登进它的后台、看它的界面，用户宁可不用，甚至直接让 AI 把这个产品重做一个。大的软件厂商也已经开始把整个平台开放给 agent 调用，不再要求用户登录界面。23

用户不想再进你的系统、看你的界面，他要让自己的 agent 去做；以后他会一直待在自己的 agent 里。

我的判断是：硅谷活在未来，我们 AI 组活在近未来，大概一年后，每个人都能低成本地用上自己的 agent。所以我们可以参照他们走过的路，不用自己去做「agent 产品」。这里说的 agent 产品，是从对话界面、模型、记忆到执行的一整套，像 WorkBuddy、Codex 那样。

数字化要做的，是给 WorkBuddy 等智能体搭好工具层：MCP、网关、权限、审批、日志这些，也就是 agent 接进永达系统的那一层。业务用自己的 WorkBuddy（或 Codex、Claude Code 等其他 agent 产品）在这个基础上做事。一步一步来：

  1. 先搭基座：统一取数、MCP 平台、权限和日志。这一步已经做完，组内我、张建、彭晨已经在用。 现在能做的，比如：

    • 按工号或姓名查一个人在 E8、E9 会计矩阵里挂了哪些分部，两边配得不一致的直接列出来；
    • 拿到一张门店接收人名单，让 agent 直接拉出这些人的企微 ID，不用再找人手工导；
    • 核对哪些人的企微账号和 OA 对不上，导致 OA 消息发不到。

    别的团队写的 MCP 也能挂进来，统一用企微登录、按人放行工具、每次调用留痕。

  2. 再跑通一个场景：一开始肯定跑不通，和用的人一起改，补接口、修工具、写 skill，直到这一个场景真的好用。

  3. 再从 1 扩到 100：把跑通的做法沉淀成 skill，收进统一的 skill hub（泛 AI 中台这类平台），给其他人、其他场景复用。最近很火的「赛博女娲」（女娲.skill）是把一个人的思考方式蒸馏成 skill4；我们要做的，是把业务同事跑通的做法蒸馏成 skill。

场景大致分三类，按 agent 能做到哪一步来分，越往后自主程度越高，需要的管控也越多：

  • 数据打通（读）：查数和分析
  • 流程打通（写）：在审批下操作业务系统
  • 主动协同（主动发起）：没人问，agent 自己推送和督办

这三类可以同时推进，用的是同一套基座；写操作需要的审批和留痕正在补。

全景图：业务用自己的 agent 在上面做三类场景（数据打通、流程打通、主动协同）；数字化在下面搭 MCP 平台，网关负责按人开放、写操作审批、审计留痕，下面接预算、费控、企业微信、BI 等系统。

一、数据打通

推荐场景（场景简述）

职能中心用自己的 agent（或 WorkBuddy 等）直接查到永达内部系统的数据，做类似 ChatBI 的分析；分权做好后再扩到企业。

数字化负责两层基座：统一取数，以及在上面加认证、按角色分权、日志留档的工具层（MCP）。业务在上面用自己的 agent 做分析，反复问的问题和业务一起写成 skill；前期需要业务人工配合，之后随模型能力提高逐步完善。

具体场景：

  • 预算、费用数据
    • 门店问「我的额度为什么是这么多」：要查这家店的预算版本、按月下达记录和实际花费明细。难点在口径：门店编码和预算主体编码不是一套，额度年中改成了按月下达。这些写进工具和 skill，agent 才答得准。
    • 融媒体费用：已经按他们的工作环节拆成工具（预算池、事前申请、费控单据、费控缺口），每个工具解决工作流里的一段。
  • 经营数据（BI）
    • 总裁驾驶舱：超期库存场景里一直没做出来。驾驶舱看什么，只有总裁自己清楚，需求天然个性化，适合由他个人的 agent 完成；数字化负责 MCP 和数据口径这层基座。
    • 超期库存、月度用户资产报告：口径之前已经和 BI 对过，可以先开放给需求部门的 agent 直接查，不用每次导表。
  • 制度、流程知识问答 难点在持续维护，不作为重点；企业微信未来可能有更好的综合方案。

推荐人 / 部门

融媒体（张、陈）

需求是确定的。之前开过会，外部供应商、BI 都来讲过，但还是解决不了他们原本的需求：他们要看的东西太个性化，通用产品和固定报表都接不住。

他们已经在用 agent：陈自己付费用 Codex，模型很强；正在用的供应商产品里也接了 Claude。缺的是 BI 原始数据的 MCP 这一层。

痛点

数据不可见。要拿一份数据得辗转多方，数据的解释口径也一直在变。

ROI

初期难以量化，只能先减掉部分职能中心人员的工作量。长远看，这是支撑所有 AI 能力的数据基座，需要投入精力去做。

数据可得性

拆成两块看：

  • 基座：卡在 BI 原始数据。现在 BI 给出来的是人工加工过的报表和接口，每来一个个性化需求，就要 BI 再做一张表。这套体系是给人看报表设计的，还不够 AI native。 其实只要把原始数据开放出来，数字化包成 MCP、加上权限和日志，口径的解释写进 skill，和真实用户一起用、一起补准。这样 BI 不用再为每个个性化需求单独出表，工作量反而能减下来。融媒体费用 MCP 已经跑通，证明这条路走得通。
  • 智能：不是我们的重点。用户的反馈是只要问题解决，不在乎用的是什么产品；agent 这层腾讯 WorkBuddy 会做，陈手上的 Codex、供应商产品里的 Claude 也已经够强。我们参照硅谷的路走就行。

所以我们要做的是：多做 MCP，再和业务一起沉淀 skill。

之前为什么停 / 现在怎么做

之前：5 月数据魔方 POC 推广后有人用，但反馈不多。场景一直都在：融媒体用了数据魔方和其他 AI 产品，问题仍然没解决。根本原因是数据拿不到、口径不清，这些问题不能用 AI 来掩护，不是买了产品就自然解决了。

现在：数字化联合 BI，先把 BI 原始数据做成 MCP，直接对接融媒体；借助已经提升的模型能力，以及月度用户资产报告、超期库存这两次合作的经验，再扩到整个 BI 平台，从数据源头重新梳理数据基座。

二、流程打通

推荐场景（场景简述）

让 agent 在受限、安全的前提下直接操作业务系统。

（注：agent 拿不到业务系统的完整权限。它只能经过 MCP 层，调用开放给它的几个细粒度工具，比如「把某个分部的应付会计从 A 换成 B」，每个工具只做一件事。）

技术上做得到：到最后，agent 做一个操作就是调一次工具，难点在把工具做对、做安全（核对、回读、留痕都做在工具里；真正不能出错的操作还是人来做）。这件事不算难，但要一个系统一个系统地磨，光靠我们不够，需要各系统的对接方一起来。

  • 人员变动后更新 OA 权限矩阵 先做共享财务岗位的会计矩阵：一个会计调岗或离职，要查出他挂在哪些分部，再一个个改成新人。查的部分已经能用（总述第 1 步里的例子），改的部分是下一步。 要对接方帮忙的：写入走哪条路径、改完缓存怎么刷新，要和 OA 那边在测试环境先做通。之后再扩到其他岗位、其他系统。
  • IT 智能客服 提单后，agent 直接或经审批执行系统操作，比如密码重置、ECM 解锁。工单入口已经是我们自建的系统，接 agent 不用再等供应商。 要对接方帮忙的：每个系统得提供这个操作的接口，之前几个接口一直停在「待开发确认」。密码重置这类敏感操作，先走人工审批。
  • 主数据相关操作 由 agent 完成，但影响面大，单独评估，不放在第一批。

痛点

人员一变，矩阵要按分部一个个手工改，漏改、错改往往等单据卡住了才发现。IT 工单里很多是重复的系统操作，现在只能人工做。

ROI

可以量化，按工单量和每单处理时长算。之前的工单分析粗估：只靠知识库能答的约三成，接上系统接口后可以覆盖到接近八成（模型估算，需要核实）。

数据可得性

读：已经上线，能按人查 E8、E9 会计矩阵里负责的分部，核对企微和 OA 账号。 写：会计矩阵的安全写是下一步，要先在测试环境做通。IT 客服要的接口（密码重置、ECM 解锁等）还没确认开发。

之前为什么停 / 现在怎么做

之前：IT 智能客服规划时，定了密码重置不让机器人直接做；几个系统接口一直停在「待开发确认」；知识库选型也暂停了。

现在：先从风险小、权限管得住的写操作开始，就是会计矩阵改人。审批和留痕做在统一的 MCP 平台上，跑通后同一套机制再给 IT 客服和其他系统用。另外，IT 工单系统已经从燕千云换成自建，在测试环境跑着，工单入口在自己手里。

三、主动协同

推荐场景（场景简述）

没人问，系统主动推消息：督促、提醒、给洞见。

先说清楚：现在能做的是规则驱动的主动，按规则定时查、命中了就推，严格说是「假主动」。真正的主动，是 OpenClaw（原 Clawdbot）这类个人 agent：自己定时醒来看一圈，判断有没有值得告诉你的事5。这种不归我们做，因为太个人了：每个人想被提醒什么都不一样。比如总裁驾驶舱，可以由总裁用自己的 agent（Codex、OpenClaw 这类）定时看数、主动提醒他；我们只要把 MCP 这一层给到位就行。

但规则驱动对业务已经够用，而且我们做过：超期库存督办、月度用户资产报告推送都跑过。所以这一类真正要做的，是把超期库存这样的做法扩出去：0 到 1 已经做过，现在是规模化，接更多场景。

已经做过的：

  • 超期库存督办：超期池每天随 BI 滚动，冻结一批车发督办工单，门店逐车回承诺和方案，按级别提醒。
  • 月度用户资产报告：每月生成，按集团、事业部、门店三级分别推到企微。
  • 系统健康 AI 巡检：OA、费控、MDM 已初步试点；推广卡在各系统的只读权限和责任人。

可以接的新场景（复用同一套规则、督办和推送）：

  • 预算额度：执行率快到上限时提醒门店和对口部门，不用等报销被卡才知道。
  • 费控缺口：没有事前申请就报销、执行比事前多出很多的单子，定期推给对口的人核。
  • 会计矩阵：已离职的人还挂在分部上、E8 和 E9 两边配得不一样，定期列出来推给共享财务。查的工具已经有了。
  • 企微账号：企微和 OA 对不上、OA 消息发不到的人，定期推给维护的人。
  • IT 工单：快超时的工单提醒处理人。自建工单系统已经有时限和企微卡片。

痛点

问题往往等业务方发现了才处理；督办靠人盯、靠群里催。

ROI

巡检看发现问题的提前量、减少的故障工单；督办看按期处理率；提醒类看提前拦下的问题数。

数据可得性

规则要的数据，大多来自数据打通那一层，打通一个就能多接一类提醒。推送渠道（企微）已经通了。巡检还缺各系统的只读账号和日志访问。

之前为什么停 / 现在怎么做

之前：超期库存项目 9 月终止，但超期池、督办工单、分级提醒这套机制做出来了；月度报告的三级推送也在生产上跑。

现在：把这套机制从超期库存一个场景泛化出来，变成通用的「规则 + 督办 + 推送」；能接哪个场景，主要看数据打通到哪。以后个人 agent 成熟了，再从规则驱动换成 agent 自己判断。

参考

  1. 2026-10-29 腾讯全球数字生态大会：「WorkBuddy 还与企业微信推出深度融合版本，进一步连接企业沟通、文档和会议记录。」报道 ↩

  2. Theo（t3.gg），2026-10-28：「If I have to go to a dashboard to use your product, I’m not going to use your product. If anything, I’m more likely to tell Claude to rebuild your product.」原帖 ↩

  3. Salesforce Headless 360，2026-04-15：把平台的数据、流程和业务逻辑开放成 API、MCP 工具和命令行；联合创始人 Parker Harris 问：「你为什么还要再登录 Salesforce？」官方公告 ↩

  4. 女娲.skill（「赛博女娲」），独立开发者花叔，2026-04：输入一个名字，自动调研、提炼，把这个人的思考方式蒸馏成可安装的 skill。GitHub · 量子位报道 ↩

  5. OpenClaw（原 Clawdbot）的 heartbeat：agent 定时醒来，读一份待查清单，没事就不出声，有事才主动发消息。官方文档 ↩

看法

登录后可以留看法。