豆包工作把 Agent 与飞书文档、聊天、审批直接打通，作者据此从零搭起一个会自我迭代知识库的飞书个人客服：可用数据乘执行权限乘反馈闭环，才是办公 Agent 的真实价值。

8 月 25 日，豆包工作正式上线。看到消息后，我第一时间下载体验。

倒不是因为它展示了多么陌生的新能力。

单看功能，豆包工作与 WorkBuddy、Codex 等 Agent 产品并没有本质差异：都能新建项目、通过对话处理任务、连接外部工具、调用 Skill、协同多个 Agent、设置定时任务，也支持手机端遥控。

它更像是把豆包里的“工作任务”独立出来，做成一个专门服务办公场景的 Agent，并提供两种运行方式：本地电脑和云电脑。

本地电脑适合读取和处理本机文件，但前提是电脑保持开机、联网；云电脑则更适合持续运行自动化任务，例如定时采集信息、生成日报、主动推送结果。

这些能力都不算新鲜。真正让我觉得舒服的，是它终于把 Agent 和飞书里的数据接上了。

01 真正的门槛，不是模型，而是数据能不能用起来

我们日常使用飞书办公，文档、表格、聊天、日程、审批和邮件，几乎构成了工作的全部上下文。

过去，想让 WorkBuddy 或 Codex 读写这些数据，通常需要先安装飞书 CLI，完成本地配置和扫码授权。即使可以把安装任务交给 AI，不同电脑环境带来的兼容问题、反复授权和安装失败，对没有开发经验的用户依然不够友好。

飞书 CLI 可以理解为 AI 与飞书之间的“钥匙＋翻译官”：一边负责身份与权限，一边把自然语言任务转成飞书能执行的接口操作。

豆包工作的变化在于：当豆包账号与飞书账号完成关联后，用户不再需要先理解这层复杂的技术连接。

打开“云盘”标签，就能看到飞书文档；选中文档或发送链接，Agent 就可以读取内容，也可以创建多维表格、写入数据。

进一步看，飞书聊天、审批、邮件等，也都从“只能由人打开查看的信息”，变成了 Agent 可以在权限范围内读取、处理和写入的业务数据。

这件事的价值，不只是少装了一个工具。

当模型能力逐渐趋同，Agent 的竞争会从“谁更聪明”，转向“谁能获得更高质量的上下文、完成更完整的动作，并接住真实反馈”。

换句话说，一个办公 Agent 的实际价值，可以粗略理解为：

Agent 价值 ≈ 可用数据 × 执行权限 × 反馈闭环

任何一项接近零，最终体验都会大打折扣。豆包工作与飞书生态的打通，解决的恰恰是前两项。

02 与其继续讲功能，不如真做一个客服

说再多，不如动手做一遍。

我决定从 0 到 1 搭建一个飞书个人客服，承接同事每天的业务咨询。

其实之前就用飞书的aliy做过一版，奈何我们公司没有氪金，每日能使用的额度小到可怜，做出来的客服机器人基本是废的。

而现在，豆包工作下载安装，注册登录后就送了一个月的标准会员，从我这几天体验来看，随便用，无压力。

最基础的客服机器人并不复杂：设定系统提示词，读取上下文和知识库，在有依据时回答；遇到无法回答的问题，再转人工处理。

但从产品角度看，这还不够。

如果知识库完全依赖我手动整理、持续投喂，那么机器人虽然替我回答了问题，却又制造了一份长期维护知识的工作。它只是把重复劳动从“答题”搬到了“整理资料”，并没有真正形成系统能力。

所以，我给这个个人客服增加了一个更重要的目标：让知识库能够在真实使用中持续迭代。

03 从“问答机器人”升级为“知识循环系统”

我先告诉豆包工作，这个客服的产品定位、使用场景和运行方式，再提供基础业务文档，建立第一版知识库。

整个系统按照下面的闭环运转：

1. 提供基础业务文档，建立初版知识库；
2. 由 AI 学习、提炼并沉淀知识；
3. 每次用户咨询时，记录对话与处理结果；
4. 从真实咨询中识别新问题、知识缺口和高频需求；
5. 每周五晚定时汇总、蒸馏，经确认后更新知识库。

这就形成了“内容 → 蒸馏 → 应用 → 分析 → 再蒸馏 → 更新内容”的循环。

这里有一个很关键的产品判断：知识库不是越大越好，而是越贴近真实问题、越容易被验证越好。

因此，“自动迭代”不应理解为 AI 可以无边界地改写知识。

更稳妥的机制是：AI 负责发现缺口、整理候选答案和提供更新建议；涉及制度、权限、价格、承诺等高风险内容时，仍由人完成审核。每次更新最好保留来源、时间和变更记录，避免错误在知识库里被反复放大。

这也是从 Demo 走向可用产品必须补上的一层：AI 可以自动学习，但知识治理不能缺席。

确认需求后，豆包工作开始输出系统架构、代码文件，并一步步引导我完成部署上线。

04 部署上线，其实只是在回答三个问题

“部署”听上去很技术，但如果换成产品语言，它其实只是在回答三个问题：机器人有没有合法身份、有没有能力工作、用户能不能找到并使用它。

STEP 01 创建飞书应用——让机器人有身份

飞书里的第三方机器人和工具，都需要一个专属应用身份。它决定机器人是否有资格接入企业飞书、读取消息和回复用户。

我们需要在飞书开放平台创建企业自建应用，完成命名与企业主体绑定，并开启机器人会话、消息收发、文档读写等必要权限。

简单说，这一步就是给答疑机器人注册一个“企业工号”，让飞书认可它的存在，也明确它可以做什么、不能做什么。

STEP 02 部署 AI 服务——让机器人会干活

只有身份，机器人还不会回答问题。接下来要把飞书应用与豆包工作的 AI 能力连接起来，配置答疑规则、知识库和回复策略，并完成服务连通测试。

这一步相当于给机器人装上“大脑”和“工作技能”：它可以接收同事的咨询，分析问题，再根据知识库生成回答。

STEP 03 发布应用——让员工真正用得上

测试完成后，还要提交应用版本，配置企业可见范围，并经过管理员审核。发布成功后，员工才能在飞书里搜索、添加并使用这个机器人。

身份、能力、分发，三步缺一不可。很多 AI Demo 之所以停留在演示阶段，往往不是模型不够聪明，而是没有走完这条产品化链路。

05 我选择了免费的本地长连接方案

一开始，AI 推荐把服务部署到云服务器。我告诉它：“我不想付费上班，希望先用免费的方式验证。”于是，它把方案调整为“飞书长连接＋本地电脑运行机器人”。

简单理解：不租云服务器，而是让自己的电脑临时承担服务端角色，并与飞书后台保持一条持续在线的连接。

• 传统云端方案：服务长期运行在云服务器上，稳定性更好，但需要付费，也需要一定运维；
• 本地长连接方案：无需公网地址和内网穿透，成本低、适合快速验证，但电脑必须开机、联网，程序也要持续运行。

因此，它适合验证需求和小范围试用，却不等于真正的“零部署”。如果要服务更多同事，或者对稳定性、数据安全和可维护性有更高要求，后续仍应考虑云端托管、密钥管理、日志监控和故障恢复。

确定方案后，我按照指引完成了以下操作：

1. 在飞书开放平台创建企业自建应用；
2. 将事件订阅方式改为“长连接”；
3. 添加“接收消息 v2.0”事件；
4. 开通收发单聊与群聊消息、读取用户基本信息等必要权限；
5. 创建版本并发布机器人；
6. 配置应用凭证和大模型 API 密钥；
7. 确认依赖可用，运行程序并启动机器人。

这里提醒一句：应用密钥和模型 API 密钥属于敏感信息，正式使用时不要直接写死在公开代码中，更不要把截图或代码随意发到群里。

更合适的方式是使用环境变量或安全配置文件，保存在py文件中，并严格控制机器人的权限范围。

到这里，机器人已经可以正常运行。过程中遇到报错，我直接把截图发给豆包工作，它会解释问题并给出下一步处理建议。

对于没有开发经验的用户来说，这种“边做边解释”的陪伴感，比单纯生成一份代码更有价值。

接下来，就可以回到飞书中测试机器人了。

06 真正有价值的，是机器人答不上来的问题

测试过程中，我遇到过机器人重复回复、回答缺少原文链接等问题。这些都可以继续交给豆包工作定位和修正。

但更值得关注的是：有些问题机器人能回答，有些问题它回答不了。后者并不是“失败数据”，反而是最有价值的产品输入。

我让 AI 把每天的对话记录写入多维表格，并在晚上自动汇总，再把日报发送给我。

这样，我不仅能看到机器人处理了多少咨询，还能知道哪些问题被高效解决、哪些答案缺少依据，以及知识库还缺什么。

如果要把这套客服长期运营起来，我会重点关注五个指标：

1. 有效解决率：用户的问题是否真的被解决，而不只是机器人是否回复；
2. 人工转接率：有多少问题仍需要人工介入；
3. 引用完整率：重要回答是否能回溯到原始文档；
4. 重复追问率：用户是否因为答案模糊而继续追问；
5. 知识缺口关闭时长：从发现新问题，到知识库补齐并验证，需要多久。

这些指标把“感觉机器人挺好用”，变成了可以持续优化的产品系统。

真正的解放双手，不是让 AI 替人做完所有决定，而是让 AI 处理高频执行，让人把精力放在规则、边界和判断上。

07 作为产品经理，我对豆包工作的三个直接体验

1. 快，不只是性能体验，也是信任体验

豆包工作的回复、思考和执行速度都很快，操作过程中很少出现长时间等待。

对 Agent 来说，速度不只是“爽不爽”的问题。任务越长，用户越容易怀疑它是否卡住、是否跑偏。

快速响应能缩短不确定感，让用户更愿意把连续任务交给它。

2. 执行过程可视化，降低了 Agent 的黑箱感

豆包工作会用可读性较高的语言解释每一步，清楚告诉用户“我正在做什么”。

作为对比，codex每次只提示“已运行命令”，到底运行了啥命令，在干啥，我是不知道的。对于不熟悉技术的用户来说，这几乎没有提供有效信息。

Agent 产品真正需要建立的，不只是能力信任，还有过程信任。

用户至少要知道：它准备做什么、为什么这么做、做到了哪一步、出了问题如何恢复。

可解释的执行过程，本身就是产品能力的一部分。

3. 长对话缺少导航，会放大复杂任务的认知成本

目前，一个对话窗口里没有清晰的目录导航。开发类任务往往很长，想回到之前的需求、方案或配置，只能不断上滑查找。

这看似是小问题，实际上会直接影响复杂任务的可控性。

理想的 Agent 工作区，应该自动沉淀任务目录、关键决策、文件版本和待办状态，让对话从一条不断增长的消息流，升级成可回溯的项目空间。

写在最后：Agent 的壁垒，正在从模型走向系统

整体而言，豆包工作的体验让我满意。

一方面，它解决了飞书重度用户最现实的数据问题。模型能力逐渐趋同之后，真正拉开差距的，往往不是谁能多答一道题，而是谁能接入更高质量的上下文、获得恰当的执行权限，并把真实反馈沉淀成可复用的经验。

另一方面，它在响应速度和执行过程可视化上，也做出了让普通用户能明显感知的体验差异。

这次搭建个人客服，让我更确定一件事：未来真正好用的 Agent，不会只是一个更聪明的聊天框，而会是一套能够理解业务、调用工具、持续执行、接受反馈并不断改进的工作系统。

豆包工作只是刚刚开始。

这是豆包和飞书合并后的第一个产品，而紧接着，trae和扣子也已经合并到豆包中了，下一个产品会带来什么惊喜，值得期待！

不管怎么样，一个月会员这么大的福利，可千万不能再错过了！与其继续围观，不如挑一个自己每天都在重复做的真实任务，亲手跑一遍。

真正好用的 Agent，不只是更聪明的聊天框，而是一套能够理解业务、调用工具、持续执行、接受反馈并不断改进的工作系统。