从 WorkBuddy 到 FDE：企业 Agent 为什么会走向不同落地方式？

我之前写过一篇关于 FDE 的文章：《OpenAI 和 Anthropic 同一周下场做咨询，FDE 时代来了？》。那篇文章主要讨论的是，为什么企业 AI 的竞争正在从模型能力延伸到部署能力，以及 FDE 为什么会成为连接通用 AI 与真实业务需求的前线角色。

这里先限定一下本文所说的“企业 Agent”：主要指由软件或模型厂商（乙方）向企业客户（甲方）提供，能够连接企业数据、工具和流程并执行任务的 Agent 产品与服务。Codex、Claude、CodeBuddy 和 WorkBuddy 都可以被个人使用，但本文只讨论它们进入企业采购、部署和持续使用之后的产品与商业逻辑；企业完全自研、只供内部使用的 Agent，不是本文重点。

最近几款桌面 Agent 的产品变化，让我觉得这个问题还可以再往前推一步。2026 年 7 月 9 日，OpenAI 将 Chat、Work 和 Codex 放进了同一个 ChatGPT 桌面应用：Chat 负责对话，Work 面向研究和成品交付，Codex 仍然服务软件工程。与此同时，Claude Desktop保留了 Chat、Cowork 和 Code 三类入口；腾讯则分别布局面向软件工程的 CodeBuddy，以及面向通用工作和企业办公的 WorkBuddy。

这些变化说明，编码、知识工作和办公协作的产品入口正在靠近，但它们并不能证明企业落地方式也会自然趋同。相似的 Agent 能力进入不同软件市场后，仍然会受到既有生态、付费方式和交付体系的塑形。

所以这篇文章不是想做 WorkBuddy、Codex 和 Claude 的功能横评，也不是判断谁更强。我真正想讨论的是：当 Agent 从个人工具进入企业工作流后，为什么相似的技术，会走向不同的商业与组织路径？

一、同样是 Agent，它们从不同工作流切入

如果只看表面，ChatGPT、Claude、CodeBuddy 和 WorkBuddy 都可以被概括成“能够自主执行任务的 AI 工作台”。但 Agent 的价值不只取决于模型能回答什么，还取决于它能获得什么上下文、操作哪些工具，以及能否验证自己完成的结果。

Codex 的起点来自软件工程。代码能否编译、测试是否通过、diff 是否合理、PR 能否合并，这些任务都有相对明确的反馈，工程世界因此天然适合形成“任务—执行—验证—修正”的循环。OpenAI 目前仍将 Codex 定位为 coding agent，但它的边界正在向外扩展：非开发岗位已经开始用 Codex制作内部应用、管理材料、仪表盘和知识文档。更准确的说法不是“Codex 已经变成通用办公 Agent”，而是它仍以工程工作流为锚点，同时把工程式的任务拆解、工具调用和结果验证带到更多工作场景。

Anthropic 选择了另一种产品组织方式。Claude Chat 保留即时对话和思考入口；Claude Cowork面向跨文件、应用和连接工具的长任务，可以产出文档、表格、演示和研究结果；Claude Code 则继续围绕代码库、终端、测试和 Git 工作流展开。三个入口的能力已经存在交叉，但仍然向用户传达不同的任务语义：此刻是在对话、委托知识工作，还是开发软件。

腾讯也呈现出软件工程与办公两条产品线。CodeBuddy面向软件工程场景，腾讯官方将其描述为支持插件、IDE 和 CLI，并覆盖编码、评审、测试和运维流程的 coding agent；WorkBuddy则更强调个人工作台、企业版、办公 Agent Suite 和行业解决方案。二者都在向相邻场景扩展，但产品叙事的起点并不相同。

下面这张表比较的不是功能上限，而是各产品当前主要用什么入口、上下文和反馈机制组织工作。

注：表格依据各产品截至 2026 年 7 月的主要入口进行归纳，不表示其能力只能覆盖对应场景；产品边界正在持续重叠。

这张表揭示的不是“编码 Agent”和“办公 Agent”之间不可跨越的边界，而是不同产品最初选择了不同的工作入口与反馈闭环。Codex 和 Claude Code 从可验证的软件工程切入，Cowork 和 Work 更接近成品交付，WorkBuddy 则更明确地处在办公协作与企业组织的语境里。

腾讯还推出了更偏个人电脑与即时通信入口的 QClaw，说明它也在布局个人 Agent。但本文真正关注的不是个人电脑助手，而是 WorkBuddy 这类试图进入组织协作流程的企业 Agent。

这些产品首先发生的不是模型能力分叉，而是工作入口与反馈闭环的分叉。

二、WorkBuddy 的优势，是进入组织的路径

只比较通用 Agent 能力，WorkBuddy 未必天然领先 Codex 或 Claude。Claude Cowork 已经可以在电脑、本地文件和连接工具中采取行动，ChatGPT Work 也能使用本地文件、桌面应用和内置浏览器完成研究与成品交付。“能够连接企业工具”本身，已经很难成为某一款产品独有的技术壁垒。

WorkBuddy 更值得观察的地方，是腾讯在国内办公协作市场中已经拥有一批现成入口。腾讯 Productivity Agent Suite 的官方介绍显示，腾讯文档和腾讯乐享会通过 One ID 接入 WorkBuddy 工作台；腾讯会议则会捕获和结构化会议上下文，让 Agent 通过 MCP、Skills 和 CLI 理解、检索与调用会议内容。腾讯并不是先做一个完全孤立的 Agent，再寻找可以嵌入的软件，而是在尝试给既有的文档、会议、知识与协作生态增加一层 Agent 交互。

这种优势可以从交易成本理解。一个孤立 Agent 要进入企业，首先需要说服员工迁移数据、授权工具并改变工作习惯；已经拥有文档、会议、知识与账号体系的平台，则可能降低一部分分发、连接、身份认证和权限配置成本。这并不保证 WorkBuddy 一定成功，但意味着腾讯的起点不同于只拥有模型或单点 Agent 产品的公司。

CodeBuddy 和 WorkBuddy 的关系也值得关注。腾讯云目前已经做到“一个账号，双产品通用”，企业用户无需分别订阅，就可以在软件工程和办公场景之间切换。现阶段可以确认的是账号、计费和服务权益的统一，至于二者未来是否会在产品功能上进一步合流，腾讯尚未公布明确路线。

不过，生态入口只是门票，不是护城河。会议纪要生成并不难，难的是会议结束后如何形成任务，任务如何进入项目系统，执行状态如何回流，历史会议如何沉淀成组织知识，以及错误行动最终由谁负责。如果这些环节仍然依赖员工手工搬运，Agent 只是已有办公工具上的新功能；只有当它真正连接并推动流程时，才可能成为企业工作方式的一部分。

WorkBuddy 的商业优势，不在于它一定比 Codex 或 Claude 更聪明，而在于腾讯可能拥有一条更短的组织进入路径；这条路径能否形成商业闭环，则取决于 Agent 进入组织后发生什么。

三、企业 Agent 的门槛，不是 Demo，而是组织可用性

今天做一个企业 AI Demo 并不难。输入几份文件，调用模型，再生成一份报告、页面或分析结果，很多团队都能在短时间内完成。真正困难的是让这套能力进入生产环境，并在真实权限、遗留系统和组织责任下长期运行。

企业 Agent 要读取会议和客户材料，就必须处理数据访问权限；要连接 CRM、邮件和知识库，就要解决接口、数据格式与身份体系问题；要自动创建任务或修改业务数据，就会遇到审批、审计、错误兜底和责任归属。模型能力越强，Agent 能够采取的行动越多，企业需要治理的范围反而越大。

这也是我在上一篇文章中讨论的“PoC 容易，生产很难”。PoC 可以用理想流程和脱敏数据验证技术可能性，生产系统却必须和真实基础设施、组织边界及维护责任绑在一起。本文不再重复展开 FDE 的历史与定义，而是在这个前提上继续追问：落地过程中吸收的复杂性，最后能否回到产品？

当 AI 只停留在对话环节时，最终动作通常仍由人完成；当它获得工具权限，开始读取数据、改变系统状态并推动其他人行动时，治理问题才会显著增加。此时企业关心的不再只是回答准确率，而是 Agent 能否被授权、被审计、被维护，以及出错后是否可以恢复。

OECD 对企业采用 AI 的研究也显示，技能、数据准备度、系统与流程适配、成本以及投资回报的不确定性，都是企业落地 AI 时普遍面对的障碍。这些问题并不是中国企业特有的，它们来自企业软件进入真实组织后的共同约束。

模型厂商可以提供通用能力，产品团队可以设计标准功能，但哪些流程值得改造、业务中的例外情况是什么、不同部门能够接受多大程度的自动化，往往只有进入客户现场后才能真正被发现。企业和厂商甚至可能都不知道，哪个场景才最值得优先产品化。

一旦 AI 从回答问题走向参与流程，企业需要的就不只是更强的模型，还需要一种把技术能力嵌入真实组织的落地机制。

这正是 FDE 产生的背景。

四、企业面对的是相似复杂性，差别在于如何吸收它

企业 Agent 进入组织后，普遍要处理复杂流程、数据权限、新旧系统集成、安全合规、投资回报和责任归属。因此，国内外企业软件的差别不能简单概括成“欧美企业愿意付费，国内企业不愿意付费”。更值得比较的是：当标准产品无法覆盖全部业务复杂性时，企业和厂商通常用什么机制处理剩余部分。

一种方式是先购买相对标准的产品，再通过配置、API、低代码平台、合作伙伴和专业实施服务解决企业之间的差异。标准产品仍然是收入和迭代的核心，服务的主要作用是推动客户采用、续费与扩容。另一种方式则是从具体项目出发，由厂商围绕客户要求进行私有化部署、定制开发、系统集成和验收交付，产品能力与项目服务之间的边界会因此变得模糊。

这两种机制不是欧美和中国之间的绝对分界线。欧美大型企业同样会购买咨询、实施和定制服务，国内也存在产品化程度很高的 SaaS。差别更多体现在相对权重上。中国信通院《中国企业级 SaaS 产业发展研究报告（2024 年）》指出，国内订阅制发展并不理想，不少服务商仍采用项目制收费，或在订阅之外叠加硬件、业务咨询和专业培训等收入；同一份报告也认为，北美、欧洲等部分成熟市场的云计算接受度、付费意愿、客单价和利润率相对更高。

下面这张表归纳的不是中外企业的固定类型，而是两种吸收业务复杂性的主要机制。

注：这是本文归纳的两种主要机制，并非严格的地域分类；同一家企业可能同时使用标准产品、专业实施和定制开发。

这张表真正揭示的是，企业复杂性不会因为购买了 SaaS 或 Agent 就消失，它只会被不同的机制接住。信通院报告还提到，国内大型客户的个性化需求会提高服务商的沟通和生产成本，并削弱标准产品的规模化优势；相对理想的路径，是通过 PaaS、低代码和产品迭代，从定制需求中提取共性，再并入标准服务。

“国内人工相对便宜”可以放进这个框架，但我更愿意把它视为一个可能的放大器，而不是已经被单独证实的根因。我的判断是：当企业可以用运营人员、外包团队或现有员工以相对可控的短期成本处理流程例外时，“先改造流程，再采用标准软件”的紧迫性可能下降。但它还会与业务标准化程度、私有化要求、采购机制、数字化基础和 ROI 不确定性共同作用，无法单独解释国内软件市场的项目化倾向。

换句话说，同样面对一段不标准的流程，有的企业会先调整流程，让组织适应标准软件；有的企业则会要求厂商调整软件，让产品适应现有组织。前一种方式需要承担组织变革成本，后一种方式则会把复杂性转移给供应商。对企业来说，定制可能是当下更容易接受的选择；对软件厂商来说，大量不可复用的定制却会逐渐削弱规模效应。

这也解释了为什么“付费意愿低”不是一个充分的说法。企业可能愿意为一个能够验收的项目付出很高价格，却不愿意长期为标准产品订阅；也可能愿意购买软件，但同时要求厂商承担大量实施和运营服务。问题不只是客户愿不愿意花钱，而是收入最终流向可复用产品，还是流向一次性交付。

国内外企业并非面对不同的复杂性，真正的差异在于：复杂性最终更多由标准产品和实施生态吸收，还是由人力、定制开发和项目交付吸收。

五、FDE 位于两种复杂性吸收机制的交界处

企业 Agent 越深入权限、数据和核心流程，标准产品就越难直接覆盖所有情况，厂商也越需要有人进入客户现场，识别业务问题、配置系统、补充开发，并推动组织真正使用。这是 FDE 与传统远程技术支持不同的地方。

上一篇文章讨论的是“为什么企业 AI 需要 FDE”，这一篇进一步想问的是：前线人员吸收的复杂性，最后会回到产品，还是只会留在当前项目里？

为了分析这种差异，本文把 FDE 的组织方向抽象成两个理想型端点：产品闭环导向和项目交付导向。真实岗位通常同时包含两者，关键不是 FDE 是否参与交付，而是公司长期把前线人员推向哪一端。

注：“产品闭环导向”和“项目交付导向”是本文归纳的两个理想型端点，真实 FDE 岗位通常处在两者之间。

产品闭环导向的 FDE 同样要做 PoC、接系统和解决客户问题，但项目不是终点。现场反复出现的问题会进入产品路线图，逐渐沉淀成标准连接器、权限模型、行业模板和评估方法。完成一个客户后，下一个同类客户的部署周期应当缩短。

项目交付导向的 FDE 也可能具备很强的工程和沟通能力，但组织对他的主要要求，是响应销售承诺并按时完成验收。如果项目结束后留下的主要是一次性配置、客户专属代码和交付材料，那么它创造的是当前项目价值，却没有明显形成产品复利。

这也解释了你在国内招聘市场上可能看到的另一种 FDE：岗位名称很新，日常工作却更接近售前 Demo、PoC、驻场集成、客户沟通和项目验收。这些工作本身并不低价值，真正的问题是，公司是否建立了让现场经验回流产品的机制。即使前线人员能发现共性需求，如果销售持续按签单承诺大量定制，交付团队只考核验收，产品团队又没有资源承接反馈，FDE 最终仍然会变成交付补丁。

因此，判断一个 FDE 岗位的长期价值，不能只问它是否驻场、是否写代码或是否参与交付，还需要继续看：客户需求能否进入产品路线图，同类项目有没有形成标准连接器和行业模板，第二个客户的交付时间是否下降，绩效更看重使用、续费和扩容，还是只看 PoC 与项目验收。

FDE 的分水岭不是做不做项目，而是一个项目结束后，有没有留下能被下一个客户复用的能力。

不同软件环境会提高某种组织方向出现的概率。标准产品和订阅收入占比更高时，FDE 更容易围绕产品采用、续费和扩容工作；项目、私有化和定制收入占比更高时，FDE 更容易被售前、实施、验收和客户成功任务占满。但这不是地域决定论，而是收入模式、组织位置、资源分配和绩效目标共同作用的结果。

六、规模化的关键，是把现场复杂性变成产品能力

从产品层看，ChatGPT、Claude 和腾讯 Buddy 产品体系选择了不同的工作入口；从商业层看，标准订阅和项目交付决定了厂商如何获得收入；从组织层看，FDE 则决定客户现场无法被标准产品覆盖的复杂性，能不能重新回到产品。

这三层最终指向同一个问题：一次落地能不能降低下一次落地的成本。如果每进入一个客户，都要重新配置权限、重建知识库、重接系统和重写流程，企业 Agent 就会变成新一代项目制软件。单个项目可能创造很大价值，但规模增长会越来越依赖人力。

反过来，如果每次交付都能沉淀出行业模板、标准连接器、权限体系、评估指标和可复用工作流，那么客户越多，产品能力越强，后续交付成本也越低。FDE 此时不只是人力投入，而成为产品理解真实世界的传感器。

这也解释了为什么大量招聘 FDE 可以同时被理解成好消息和危险信号。它可能说明客户需求正在爆发，也可能说明标准产品不足以覆盖客户需求，只能依赖人力填补缺口。真正值得观察的不是 FDE 人数，而是随着项目增加，产品复用率有没有提高，单位客户的交付成本有没有下降。

前文提到的几种产品组织方式都在说明，软件工程、知识工作和企业协作的入口正在靠近，但入口的合流并不会自动消除企业落地中的权限、系统和组织复杂性。WorkBuddy 的腾讯生态给了它进入组织的路径，CodeBuddy 补上了软件工程工作流；真正的考验仍然在后面：这些入口最终会形成标准产品、持续订阅和复用能力，还是被大量定制和项目交付吸收？

企业 Agent 最终拼的不是谁更像未来，而是谁能把真实组织里的复杂性，持续转化成可复用的软件能力。

参考资料

官方产品与发布

• ChatGPT is now a partner for your most ambitious work
• Codex for every role, tool, and workflow
• Claude Desktop application
• Claude Cowork
• 腾讯云代码助手 CodeBuddy
• Tencent Cloud Debuts Productivity Agent Suite
• CodeBuddy、WorkBuddy 计费方案调整公告
• Tencent Launches QClaw Globally

机构研究

• 中国企业级 SaaS 产业发展研究报告（2024 年） — 中国信息通信研究院
• The Adoption of Artificial Intelligence in Firms — OECD、BCG、INSEAD

相关文章

• OpenAI 和 Anthropic 同一周下场做咨询，FDE 时代来了？