Agent 越来越多，真正值钱的是什么

最近几个月，Agent for Work 突然变得热闹起来。

各家大厂都开始把 AI 从聊天框里往真实工作场景里推。

这并不难理解。

当大模型逐渐具备推理、工具调用、文件处理、浏览器操作、Coding、定时任务等能力之后，下一块真正有商业价值的高地，自然就是企业办公。

谁能成为企业员工每天工作的 AI 入口，谁就有机会占据未来企业软件生态中非常重要的位置。

而最近发布的「豆包工作」，恰好是这股趋势中一个很有代表性的案例。

---

豆包工作，并不是突然出现的

如果把字节过去几年的产品路线串起来看，会发现豆包工作其实不是一个突然从零诞生的产品。

它更像是几条 Agent 产品路线逐渐汇合后的结果。

其中一条来自 TRAE。

TRAE 最初是一个典型的 AI Coding 产品。

但 Coding 恰好也是 Agent 最早跑通的复杂工作场景之一。

在真正的软件开发任务中，AI 已经不能只是回答：

“这段代码应该怎么写？”

它需要理解整个项目、读取代码、拆解任务、修改文件、执行命令、运行测试、发现错误，再根据结果继续修正。

这已经不再是传统意义上的聊天，而是在执行一个完整任务。

随着这种能力逐渐成熟，一个很自然的问题出现了：

既然 Agent 能完成复杂的软件开发任务，为什么它只能服务程序员？

于是，TRAE 的能力开始从 Coding 向更广泛的工作场景延伸。

2026 年 6 月，TRAE SOLO 正式演化为 TRAE Work。

用户开始拿它处理产品文档、研究报告、数据分析、营销方案以及各种跨职能任务。

从 Coding Agent 走向 Work Agent，这条演化路径其实非常自然。

因为 Agent 在编程领域打磨出来的核心能力——规划、Context 理解、工具调用、文件处理和自主执行——本身就是通用能力。

---

另一条路线来自扣子：Workflow、Skill 和 Agent 编排

如果说 TRAE 更擅长解决“复杂任务怎么执行”，那么扣子长期积累的则是另一类能力：

怎么把 AI 放进一个持续运行的流程里。

扣子很早就在做：

• Workflow
• Agent
• 插件
• 工具调用
• 定时触发
• 外部服务连接
• Skill

这些能力背后的思路其实都一样：

不要每次都让一个人打开聊天框，从头告诉 AI 该干什么。

而是把已经成熟的工作逻辑沉淀下来，让系统按照规则自动运行。

从这个角度看，Workflow 解决的并不是“模型聪不聪明”，而是：

怎样让工作可以被重复执行。

这和传统企业自动化的目标其实非常接近，只不过 AI 让过去很难写死成规则的一些环节，也开始具备了自动处理的可能。

---

再往前一步，就是飞书里的企业数据

Agent 真正进入企业以后，还会遇到一个更基础的问题：

它凭什么理解我的公司？

一个模型哪怕再聪明，如果不知道：

• 公司内部的文档
• 历史会议
• 群聊
• SOP
• 项目信息
• 企业知识
• 工作流程

它依然只是一个能力很强、但刚刚入职的新员工。

所以今年字节在组织和产品层面另一个非常关键的动作，是豆包与飞书的进一步融合。

到了这里，几块拼图开始逐渐完整：

TRAE

提供复杂任务和 Coding Agent 的执行经验。

↓

扣子

提供 Workflow、Agent、Skill 和工具连接能力。

↓

飞书

提供企业文档、沟通、会议、知识和权限体系。

↓

豆包

提供统一的大模型和用户入口。

最终，这些能力逐渐汇聚到了一个共同方向：

Agent for Work

当然，这并不意味着豆包工作的每一个功能都可以简单归因于某一支原来的产品团队。

这更像是一种基于产品能力演化所做的观察。

但大的方向已经非常清晰：

过去分散在聊天机器人、Coding Agent、Workflow 平台和协同办公软件中的能力，正在汇流成一个统一的“工作 Agent”。

---

大厂真正争夺的，是“工作的入口”

如果把豆包工作、千问办公、WorkBuddy，以及海外正在出现的大量 AI for Work 产品放在一起，会发现它们的能力正在迅速趋同。

大家都在做：

• 深度研究
• 文件处理
• PPT
• Excel
• Coding
• 浏览器操作
• 软件操作
• Skill
• Connector
• Schedule Work
• Workflow
• Agent

我自己过去半年密集使用了各种 Agent 产品，一个越来越明显的体会就是：

Agent 的很多基础能力正在快速商品化。

半年前，有些需求我们还得自己写代码、接 API、搭工作流。

甚至要专门开发一个小工具。

今天再看到类似需求，我首先考虑的问题已经不是：

“这个东西应该怎么写？”

而是：

“这个东西还有没有必要自己写？”

这其实是一个非常重要的变化。

因为企业 AI 化真正有价值的部分，从来都不应该是重复造轮子。

如果一个成熟产品已经能够稳定完成 80% 的需求，那么企业就没有必要为了剩下那一点差异，承担一整套软件开发和长期维护成本。

---

真正困难的问题，正在发生变化

过去我们面对 AI 项目，经常首先讨论：

怎么把这个 Agent 做出来？

而现在我越来越觉得，真正困难的问题已经变成：

这项工作到底应该由什么来完成？

我目前更倾向于把企业工作拆成四种类型。

---

第一类：规则明确、高频重复

例如：

• 定时抓取数据
• 固定格式转换
• 文件归档
• 数据同步
• 固定报表生成
• 定时通知

这类工作通常没有必要让一个 Agent 每次重新“思考”。

普通的：

Workflow + Automation

往往就足够了。

能确定，就不要故意搞成不确定。

---

第二类：步骤复杂，需要动态判断

比如：

• 深度行业研究
• 竞争对手调查
• 多文件综合分析
• 根据中间结果决定下一步操作
• 跨多个软件完成一次复杂任务

这种任务很难完全提前写死成规则。

这时候 Agent 才真正发挥价值。

它可以：

观察

↓

判断

↓

执行

↓

看结果

↓

决定下一步

这本质上是一种动态规划能力。

---

第三类：高复杂、高可靠、高敏感系统

还有一类业务，虽然理论上 AI 也能参与，但最终依然更适合成熟的软件工程。

例如：

• 核心交易系统
• 财务核心系统
• 高敏感客户数据
• 强一致性业务
• 高审计要求系统
• 长期运行的关键基础设施

这些系统真正困难的从来不是：

“能不能跑起来一次？”

而是：

能不能稳定运行三年、五年，出了问题是否能追踪、恢复和维护。

这种时候，AI 可以大量参与开发，但最终的系统仍然需要：

• 明确架构
• 严格接口
• 权限控制
• 日志
• 测试
• 容灾
• Governance

这依然是成熟软件工程解决的问题。

---

第四类：必须由人承担的工作

例如：

• 重大决策
• 价值判断
• 责任承担
• 高度模糊目标
• 人际关系
• 组织利益平衡

AI 可以提供信息和建议。

但最终决定为什么这么做，以及谁为这个决定负责，仍然应该是人。

所以 Agent for Work 真正重要的能力，不一定是：

“会不会用 Agent。”

而是：

能不能正确划分

Automation、Agent、Software 和 Human 的边界。

---

不要追逐所有新工具

这也是为什么，我现在越来越不建议普通工作者每天追逐所有新的 AI 产品。

AI 时代的软件变化速度太快了。

今天刚学会一个工具。

三个月以后，它可能：

• 改版了
• 被整合了
• 改名字了
• 功能免费了
• 被另一个产品替代了

今天还被包装成核心卖点的一项能力，半年以后可能已经成为所有 AI 产品里的普通按钮。

如果一个人的 AI 能力长期建立在：

“我会操作某个产品。”

这会是一件非常累的事情。

真正值得长期投入的，应该是那些变化速度远低于工具变化速度的东西。

我目前认为至少有三个。

---

第一，数据

企业的数据在哪里，AI 工具的选择就应该尽量靠近哪里。

这其实是一种非常现实的 Data Gravity——数据引力。

如果一家企业长期使用飞书：

• 文档在飞书
• 表格在飞书
• 会议在飞书
• 群聊在飞书
• 知识库在飞书
• 审批和流程也在飞书

那么选择能够充分利用飞书数据和 Context 的 AI，自然拥有巨大优势。

反过来，如果一家企业所有东西都沉淀在另一个生态里，为了追逐一个新 Agent，把数据重新搬一遍，可能并不划算。

企业数据不是随便可以迁移的。

数据迁移意味着：

• 成本
• 权限重建
• 员工重新学习
• 工作流程改变
• 历史资料迁移
• 新系统适应期

所以很多时候：

不是企业应该追着 AI 工具跑，而应该让 AI 工具靠近企业的数据。

模型和软件会快速变化。

但一家企业多年积累的数据，不会每半年迁移一次。

---

第二，方法论

另外一个我越来越确定的长期资产，是：

方法论。

模型会换。

Agent 会换。

IDE 会换。

Workflow 平台也会换。

但很多解决问题的基本逻辑并不会改变。

例如：

怎么观察一项工作？

怎么拆任务？

输入是什么？

输出是什么？

哪些步骤需要判断？

哪些步骤规则明确？

哪些地方适合自动化？

哪些地方需要 Agent？

结果应该如何验收？

这些能力不会因为某家公司明天又发布了一个新的 AI 产品，就突然失效。

我自己目前习惯使用一个很简单的框架：

Observe → Decompose → Automate → Validate

---

Observe

先去看真实工作。

不要一上来就问：

我们公司应该上什么 AI？

先问：

我们的人每天到底在干什么？

---

Decompose

然后把工作拆开。

拆成：

• 信息
• 输入
• 判断
• 执行
• 输出

把一个模糊的“岗位”，还原成一个个具体任务。

---

Automate

接下来才决定：

哪一步：

• 用普通自动化
• 用 Workflow
• 用 Agent
• 用传统软件
• 继续人工处理

---

Validate

最后验证：

• 准不准？
• 稳不稳？
• 真省时间了吗？
• 成本合理吗？
• 员工愿意用吗？
• 长期维护困难吗？

方法论最有价值的地方就在这里。

经验可以不断进入方法论。

方法论又可以不断修正。

最后它会形成一种可复用的判断力。

这有点像孙悟空学艺以后说的：

一窍通，百窍通。

真正理解了问题的结构以后，换一个 Agent，其实没有那么可怕。

大多数时候，剩下的成本只是：

• 新工具的操作熟练度
• 数据迁移
• 工作习惯迁移
• 新旧工具之间的阵痛期

---

第三，Evaluation 和 Governance

还有一个东西，我觉得随着 Agent 真正进入企业，会越来越重要：

评价与治理。

当 AI 只是聊天的时候，我们经常讨论：

它到底聪不聪明？

但是当 AI 开始真正执行工作以后，更重要的问题会变成：

我怎么知道它做对了？

谁来验收？

如果失败怎么办？

是否应该自动重试？

连续失败几次以后必须停？

什么时候必须转人工？

哪些文件可以读取？

哪些操作可以自动执行？

哪些动作必须经过审批？

谁能看到企业里的什么数据？

最后出了问题，谁负责？

这些问题不会因为模型更聪明就自动消失。

恰恰相反。

Agent 能力越强，这些问题越重要。

未来真正成熟的企业 AI 系统，不应该只是一个：

“特别能干的 Agent”。

它还必须是一个：

知道自己什么时候可以做、什么时候不能做，并且能够被检查、被控制、被追责的系统。

---

Agent 会越来越便宜，理解工作不会

所以我并不焦虑现在突然出现这么多 Agent for Work。

恰恰相反。

这说明很多过去需要专业开发才能完成的基础能力，正在快速标准化。

半年前还需要自己写脚本、搭 API、开发小程序的事情，今天可能已经成为产品里的一个功能。

再过半年，今天看起来还很复杂的一些 Agent 能力，也可能只是一个按钮。

这是技术成熟必然发生的事情。

而随着这些基础能力不断商品化，企业真正值得长期积累的东西反而会越来越清晰：

数据

决定 AI 能知道什么。

方法论

决定我们怎样重新设计工作。

Evaluation 与 Governance

决定我们能不能真正放心把工作交给 AI。

最后真正需要建立的，并不是一套永远不变的：

“AI 工具栈”。

而是一种持续判断和重构工作的能力。

面对一个流程，我们能够判断：

这个地方应该使用普通自动化，还是 Agent？

面对一个需求，我们能够判断：

应该买成熟软件，还是自己开发？

面对一个步骤，我们能够判断：

应该交给 AI，还是必须保留人工判断？

面对企业数据，我们能够判断：

哪些可以开放，哪些必须隔离？

面对 Agent 的结果，我们能够判断：

它到底有没有真正完成任务？

这些问题，不会因为下个月又出现一个新的 Agent 产品而过期。

工具会越来越多。

功能会越来越像。

Agent 也会越来越便宜。

但有一件事情不会因此变得廉价：

真正理解一项工作，到底应该怎样被完成。

也许这才是 Agent for Work 时代，人与企业真正需要建立的新能力。