用友、商派、百望进入 WorkBuddy 生态后，我更确定：多数企业没必要先自研 Agent

截至 2026 年 7 月 30 日，WorkBuddy 和企业软件之间有三条值得放在一起看的消息。

6 月 8 日，百望股份把发票识别、发票验真、交易伙伴风险识别等专业能力做成 Skills，上线 WorkBuddy。6 月 26 日，用友发布银账通与 WorkBuddy 的联合方案。7 月 24 日，商派宣布与腾讯云 WorkBuddy 企业版达成战略合作，旗下商城、B2B 和 OMS 系统计划通过 MCP 连接器和 Skills 接入。

三家的产品不同，合作进度也不一样。以当时公开信息为准，百望的 Skills 已上线，用友发布了联合方案，商派的业务系统仍处于「将接入」的表述。不能据此判断这些方案已经大规模部署，也没有公开证据证明客户获得了多少经营结果。

这些消息至少说明了一件事：企业 Agent 正在靠近订单、库存、资金和发票等真实业务对象。企业 AI 的重点，也应从「再做一个聊天入口」，转向怎样把业务系统、企业规则、自动任务和责任人接成可运行的流程。

从聊天问答到业务流程

仅凭厂商合作，不能判断一个产品能否成为企业 AI 的落地底座。还要看它能否承接团队协作、业务资料、连接器、自动任务和权限边界。

根据截至原文发布日期的官方产品信息，WorkBuddy 已不只是员工各自使用的桌面 Agent。它开始提供团队项目、成员协同、计划看板、项目资产库、动态记录，以及专家、Skill 和连接器的团队复用；自动化任务可以指定模型与 Skill 定时执行；MCP 可以连接业务系统、数据源和企微机器人；企业也可以按当时提供的能力接入模型或选择部署形态。

这些信息描述的是 2026 年 7 月的产品状态，不代表后续版本、合作进度和部署能力保持不变。企业实际选型时，仍需重新核对官方资料和部署边界。

当这些能力组合起来，AI 才可能从一次问答延伸到持续运行的业务流程。

以库存异常为例

假设一家零售企业已经在使用 OMS 或 ERP。运营人员需要定期查看销量、退款和库存，找出快断货、积压或数据异常的商品，再通知采购、仓库或业务负责人。

这项工作不只是查数据。它有固定触发时间，要跨系统汇总，需要按照企业自己的口径判断异常，发现问题后还要找到责任人，并跟进是否处理。

如果使用成熟 Agent 底座承接执行，可以把链路拆成下面几步：

1. 连接商城、OMS 或 ERP，通过 MCP、API 或连接器开放库存和订单查询能力；
2. 把可售库存口径、异常条件和责任归属沉淀成规则、资料或 Skill；
3. 创建按固定时间执行的自动任务，查询销量、退款、锁定库存和当前可售库存；
4. 按企业规则生成异常清单，给出缺货、积压或数据冲突的原因线索；
5. 把结果推送给对应运营、采购或仓库人员；
6. 由责任人在原有协作流程中处理、复核并留下反馈。

完成到这一步，AI 才进入业务流程。管理者不需要每天想起来再问一句，员工也不用各自保存一套 Prompt。系统按规则发现问题，Agent 调用现有业务数据完成初步判断，再把结果送到对应责任人面前。

同样的结构可以迁移到资金、发票和交易伙伴风险等场景。数据和规则虽然不同，运行结构却很接近：

定时触发 → 调用业务系统 → 按企业规则处理 → 生成结果 → 通知责任人 → 人工处置与复核

这才像一条可以进入日常经营的 AI 工作流，而不只是一个能聊天的 Agent。

把个人能力变成团队能力

员工个人使用 AI 时，经常会出现一种情况：有人把 Prompt 调得很好，有人做了一个 Skill，还有人接通了数据库，但这些能力都留在个人电脑和个人对话里。换一个人，流程又要重新搭。

团队空间的价值，是把已经验证过的规则、Skill、连接器、资料和任务过程放在共同使用的位置。新员工不用从零摸索，业务负责人也能看到团队正在执行什么任务、产生了什么结果。

重点不在「多 Agent」这个名字，而在于企业能否得到一套可复用的工作方式：同一个库存异常判断，不再由不同人员各自理解；同一个财务口径，不会因为换了对话就重新定义；同一个通知链路，也不用每个人重复配置。

当规则、连接和责任人可以被团队复用，AI 才开始从个人提效走向组织能力。

多数企业为什么不必先自研 Agent

企业准备做 AI 时，很容易先讨论技术：用什么框架，怎样写 Agent，是否要自己做任务系统、记忆、权限、调度和多模型接入。

这些能力当然可以开发。但对多数中小企业来说，通用 Agent 外壳通常不是竞争优势。自己搭一套系统，意味着模型升级、MCP 变化、连接器兼容、任务调度、权限、日志、多人协作和界面体验都要有人持续维护。第一版可以很快做出来，后续更新和员工使用才是长期成本。

因此，对于主要使用成熟企业软件和协作工具、又没有专门 AI 平台团队的企业，更合理的顺序通常是：先验证现成底座能否连接业务系统并跑通一个闭环，再判断缺失的能力是否值得自建。

这不意味着 WorkBuddy 或任何成熟平台适合所有企业。如果业务涉及严格的数据隔离、复杂内网、特殊硬件、无法适配的老系统，或者高频交易需要确定性执行引擎，企业仍可能需要私有化部署、专门工作流系统，甚至自研 Agent。

同样，「模型在本地运行」也不能自动证明整条链路都不联网。资料库、连接器、消息通知、云端任务和日志分别经过哪里，仍要逐项检查。方案选择应该跟着业务风险和系统条件走；某个产品功能再多，也构成不了一个企业必须采用同一种部署方式的理由。

把实施时间花在业务上

成熟底座越完整，企业 AI 服务的价值越应该回到业务现场：

• 找出重复发生、跨系统、跨角色的具体动作；
• 确认数据来自哪里，业务口径由谁负责；
• 把规则、经验和异常处理封装成可复用能力；
• 通过 MCP、API 或连接器接入现有系统；
• 设计什么时候自动执行，结果通知谁；
• 明确哪些判断必须由人完成，以及怎样验收。

如果一项企业 AI 服务花了大量时间开发 Agent 外壳，却没有说清谁在什么时间使用、调用哪套系统、发现什么问题、通知谁行动，那么程序做得再完整，也很难进入日常经营。

企业可以先选择一条重复发生、需要系统数据和多人协作的业务闭环，写清六件事：什么时候触发，数据来自哪里，AI 做什么，结果通知谁，谁做最终判断，用什么结果验收。

这六件事说清以后，再决定使用成熟平台，还是确实需要自研。技术应该服从业务风险、系统条件和长期维护能力，这一顺序不能反过来。