大厂争夺 AI 工作入口，软件服务商如何升级

概念插画：大厂产品承接工作入口，企业服务承载数据、流程与领域能力；不表示三款产品已与同一底座互通。

最近关注腾讯 WorkBuddy、阿里千问办公和字节豆包工作，我在想：当大厂开始提供通用的 AI 工作入口，作为软件开发者，我下一步应该做什么？

我更想做的生意，是借助这些产品的影响力，帮助企业把 AI 接进真实业务。企业买下账号之后，仍然需要有人把流程、数据、系统和人员组织起来，让它持续产生价值。

三家正在布局什么，我能依托什么

先把产品名称和范围说清楚。这里说的“千问 Work”，按阿里官方名称写作千问办公（QwenWork）。豆包工作则按字节跳动旗下产品讨论；火山引擎的云与模型服务，是理解这套生态时需要另外区分的一层。

以下依据截至 2026 年 9 月 8 日可查的官方产品介绍和文档整理，描述的是公开能力，不代表我已完成三款产品的企业部署实测。

表中事实分别来自腾讯企业版发布说明、WorkBuddy 开放平台、阿里云千问办公文档及豆包官方发布动态。最后一列是我的业务判断。

它们面向个人和组织的能力存在交集，不能简单理解成三套完全同类、只面向 To B 的软件。更值得关注的共同方向，是用户开始直接表达工作目标，由 Agent 组织工具、处理信息并交付结果。

也要把入口与底层服务分开看。火山引擎将火山方舟定位为大模型服务平台；飞书官网则同时展示豆包工作、多维表格、妙搭和集成平台。这些能力可以形成生态联系，但采购某个工作入口，并不自动获得整套生态的服务与授权。火山引擎官网、飞书官网

对我而言，大厂品牌可能降低客户理解和尝试 AI 的门槛，已有办公生态也可能减少接入成本。但客户是否愿意付费、业务能否改善，仍然要靠具体场景验证。品牌带来的关注，是销售的起点。

而且，大厂并没有把协作和集成全部留给第三方。千问办公已经公开技能、连接器和企业管理能力；飞书也提供业务系统搭建与集成产品。因此，机会必须落在客户的具体问题上，不能建立在“大厂永远只做聊天框”的假设上。千问办公平台功能、飞书官网

买下一个 AI 入口，距离业务用起来还有多远

一家企业给员工开通账号，最先得到的可能是文档写得更快、材料整理更方便。真正影响经营的工作，却经常横跨多个岗位和系统。

下面用一个假设的制造企业场景展开，作为方案设计示例，并非这三款产品已经交付的客户案例。

销售负责人提出：“找出本周可能延期的订单，核实原因，给客户准备处理方案。”

这句话背后至少涉及 ERP 里的订单和交期、MES 里的生产进度、仓储系统里的库存，以及 CRM 里的客户承诺。还要有人判断能否插单、是否接受额外成本，以及什么内容可以发给客户。

Agent 即使能操作这些软件，也需要知道：哪个交期才是有效承诺，库存是否已被其他订单占用，什么情况下必须交给生产主管处理。

员工需要学会委派工作，组织需要接住结果

培训可以从真实任务开始。让使用者说明目标、时间范围、输入材料、预期交付物和可执行范围，再通过一次完整交付理解 Agent 的能力边界。

例如，首次运行可以要求：“分析本周待交付订单，输出风险清单和依据；数据缺失单独标记，由计划员核实后，再生成客户沟通草稿。”

这比孤立地教几条提示词更接近岗位工作。但培训之后，还需要安排业务负责人维护规则，IT 负责人处理接入，使用者反馈错误和例外。否则培训结束，工具很容易重新变成少数人的个人助手。

协作必须有一个共同的任务记录

在这条订单流程里，可以让 Agent 收集证据、生成候选方案；计划员确认原因；生产主管决定是否调整排产；销售审核客户沟通内容。

每个人都需要看见同一项工作的目标、状态、依据和待办。Agent 运行结束，也不等于这项业务已经完成。完成标准应当是风险已经核实、决定已经作出、必要动作已经执行，并留下能够检查的记录。

我正在做的 Silieco，是一个让人和 Agent 共同工作的企业协作平台，可以统一分配任务、按流程推进工作，并集中管理技能、人工审批和交付结果。

我在《公司真正需要的，不是更多 Agent》中讨论 Silieco 时，关心的正是这一层：让 Task 承载工作，让 SOP 定义阶段，让 Skill 提供方法，让人工决定和结果留在共同的上下文里。

落地时也不必强推一套新平台。如果客户已有的飞书、钉钉、企业微信或项目系统足以承载这些对象，就优先沿用。只有跨系统协作、长任务恢复、流程版本和证据管理出现明确缺口时，再补充 Silieco 这样的组织工作层。

客户购买的应当是协作改善，而不是再维护一份重复的任务清单。

打通数据库，以及补上企业缺少的系统

保留已有系统，通过受控服务接入数据和业务动作，再按实际缺口补建模块。

先统一业务含义，再连接数据

所谓“打通数据库”，容易被理解成给 Agent 配几个连接，再让它生成 SQL。

实际难点往往在连接之后。ERP 的客户编号和 CRM 的客户编号是否对应？财务的销售额按开票算，还是按回款算？两个系统更新速度不同，取出的数据是不是同一时点？

这些定义不清楚，Agent 越快生成报告，错误口径就越快进入决策。

所以，接入工作应当形成可以维护的数据说明：权威来源、字段含义、指标公式、主数据映射、刷新时间，以及各岗位可访问的范围。查询结果也要带回来源和取数时间，让业务人员能够核对。

有成熟业务 API 的系统，优先使用其接口；需要分析历史数据时，可以建立受控的数据视图或分析层。查询、批量同步和业务写回，按各自目的设计，不必先把所有数据搬进一个库。

对于订单修改、库存预留、退款等动作，更适合调用承载业务规则的服务。直接改表可能跳过原系统的校验、审批和状态变化。账号权限、请求范围和执行记录，要在服务与数据访问边界落实。

这也延续了我在《把 Chat2DB 变成一名数据库员工》中的思路：Chat2DB 这样的专业工具，可以负责数据理解和受控执行；组织工作系统负责这项工作属于谁、走什么流程、由谁验收。

企业没有系统时，先建立最小业务闭环

另一类客户的问题更基础：没有售后工单系统，没有供应商评价系统，甚至连订单异常记录都散在群聊和 Excel 中。

在这种情况下，Agent 可以帮助生成页面和代码，但企业仍然缺少稳定的业务记录与运行规则。

例如，为前面的企业补一个“订单异常处理”模块，第一版只需要几个明确对象：订单引用、异常原因、负责人、截止时间、处理方案、审批结果和关闭证据。正常流转可以是发现异常、核实、制定方案、批准、执行、关闭；退回和重新打开也要有规则。

员工从 WorkBuddy、千问办公或豆包工作发起请求，后台服务保存真实状态。人通过一个轻量页面检查清单和批准方案，Agent 通过接口提交材料、查询进度、执行获准动作。

这里描述的是我拟建设的接入方式，不代表三个产品已经与 Silieco 互通。各入口能调用什么接口、怎样映射身份和返回状态，需要分别验证。

入口可以减少对复杂前端的依赖，后台仍然需要处理数据一致性、并发、备份、版本升级和故障恢复。生成出来的程序进入生产之前，也必须经过业务验收。长期维护的负责人和费用，应当在交付前说清楚。

用业务动作组织能力

对软件开发团队而言，这意味着重新整理产品边界。

过去按菜单交付的功能，可以进一步整理成“查询订单履约风险”“创建异常单”“提交排产调整申请”这样的能力。每项能力明确输入、输出、权限要求、失败原因和执行状态，人和 Agent 都能使用。

技术接入也有现成路径可参考。WorkBuddy 的官方连接器文档列出了 MCP + Skill、CLI + Skill 两种方案，并要求说明认证、错误恢复和高风险操作规则。这说明现有软件有机会以服务能力进入工作入口。WorkBuddy 连接器文档

但同样叫 Skill 或连接器，不等于三个平台能够直接通用。我倾向于把业务规则保留在独立服务中，按平台开发适配层。对于没有开放接口的旧软件，可以评估浏览器或桌面操作，并把界面变化、登录失效和人工接管纳入维护成本。

Silieco 与自有 Agent，怎样找到合适的位置

顺着这条思路，我希望围绕大厂入口形成这样的分工。它是一套目标架构，具体哪些层需要建设，由客户现状决定。

自有 Agent 要能承接一项完整工作

如果一个动作规则固定、执行直接，用普通接口或脚本就足够了。需要多步分析、根据证据调整策略、调用专业工具的工作，才更值得交给领域 Agent。

比如数据库分析 Agent 接受一个经营问题，确认口径，组织查询，检查证据，再返回可复核的结论。它要能报告执行状态，在缺少权限或关键材料时停下来，在任务中断后继续处理。

涉及业务写入时，还要知道某次动作是否已经执行，避免重试导致重复创建订单或重复发送通知。这些执行责任，比给 Agent 取一个岗位名字更能构成产品价值。

Silieco 沉淀组织的工作方法

Silieco 人机协作概念图，非产品界面截图：Agent 执行任务，人作出关键决定，系统沉淀方法与交付记录。

对 Silieco 来说，我更看重的是把一次成功交付变成组织下次还能复用的方法。

订单延期分析经过几次运行，团队会逐渐知道哪些原因必须补证据，哪些方案需要生产主管批准，哪些结果容易误判。这些经过业务负责人确认的经验，可以进入 SOP、Skill 和评测案例。

这里需要持续维护的是方法与执行记录之间的关系：这次采用哪版标准，谁作了什么决定，最终效果如何。业务规则更新后，历史任务仍然要能按当时的版本解释。

这与《软件不再是成品：从 Chat2DB、DSH 到 Silieco 的可塑软件实践》是一条连续的路线：专业软件提供能力，运行环境组织执行，协作系统沉淀工作方法。

跨平台的价值，要在迁移时证明

我希望支持不同部门选用不同入口，但不必一开始把三个平台全部适配。先在客户已采用的平台上跑通一个业务，再验证第二个入口能否复用同一套服务。

迁移时，客户应该能够带走自己的业务记录、流程定义、知识资料和可导出的产物。平台内的会话、授权方式和专有扩展未必能完整迁移，需要提前识别依赖。

如果换了入口，业务规则和核心服务仍能继续使用，这才说明我积累了独立价值。只承诺“模型随时可换”，还不足以证明系统可迁移。

把这个方向做成生意，需要改变交付和收费方式

我倾向于先从一个熟悉的行业、一个有业务负责人的高频流程进入。优先找那些已经愿意试用 AI、拥有可访问数据、又存在明显人工交接成本的客户。

如果客户只需要通用文档生成或简单知识问答，原厂产品就可能足够。如果连业务责任人和数据口径都无法确认，应当先做流程梳理。额外开发要有清楚的理由。

从一个付费试点开始，逐步扩大范围

首个试点可以限定一个部门、少量系统和一种交付结果。例如先自动形成订单延期风险清单，由计划员核对；稳定之后，再加入方案审批和获准后的业务写回。

在试点开始前，记录人工处理耗时、错误类型和最终验收要求。用同类任务比较效果，检查漏报、误报、人工修正量，以及模型和执行环境的费用。不能只挑一次成功演示，也不能只统计生成了多少份报告。

单位合格任务成本可以按“平台与模型费用、运行费用、人工复核及返工成本之和，除以通过验收的任务数”估算。它比单次调用价格更接近客户实际付出的成本。

扩展流程之前，再确认业务人员是否持续使用，负责人是否愿意接管方法维护，以及支持成本能否被收费覆盖。

把一次性交付与持续责任对应起来

平台订阅、模型用量与我的实施维护费用应分项说明。结果付费可以在指标可归因时探索，但需要先约定基线、验收方式和例外，不能把难以控制的经营结果直接写成承诺。

这也要求团队结构变化。除了开发者，还需要有人理解业务流程、维护数据口径，并负责上线后的使用效果。研发产出从页面和接口，扩展为领域能力、流程模板、评测案例和可持续维护的接入包。

壁垒要能抵抗平台继续升级

大厂会继续补充连接器、行业技能和应用生成能力。通用安装、简单培训、薄薄一层接口包装，都可能快速降价。插件市场可以帮助分发，不能把获得流量或分成当成确定收入。

我需要积累的是可复用的行业规则、经过真实任务验证的案例、处理例外的能力，以及稳定交付的客户信任。每做一个项目，都应该让下一个同类项目少做一些重复开发。

同时，客户专属的数据和规则要与通用产品能力分开管理。能够沉淀的是经过授权的方法和技术组件，不能把客户资料直接变成跨客户共享的素材。

如果每增加一个客户，都必须重新写一套系统、长期派人驻场，那么这门生意仍然主要受人力规模限制。转型是否成立，要看复用比例是否提高、维护成本是否下降、客户是否愿意持续付费。

我希望走的方向，是让大厂的工作入口帮助客户开始使用 AI，让我的领域服务和协作能力帮助客户把工作完成。对软件公司来说，值得持续做厚的，是企业的业务理解、可靠执行，以及把工作方法不断改进的能力。