如何把 GoWork 助理接进飞书：从会话到任务执行

如果你的目标只是“在飞书里问一句，AI 回一句”，那普通机器人接口已经够用。但如果你的目标是把任务真的交出去——记住上下文、调用工具、后台执行、定时跟进，再把结果主动发回原会话——你需要的通常不是机器人，而是常驻 AI 助理。

GoWork 解决的正是这个问题。它不是把大模型简单塞进飞书，而是把聊天入口、任务执行、定时调度和结果回传连成一条闭环。换句话说，“能回消息”只能证明它接进了聊天，“能把事情做完”才说明它像一个助理。

先说结论：飞书机器人解决的是入口，常驻 AI 助理解决的是执行

很多团队一开始理解“飞书 AI 接入”，都是三步：

1. 创建机器人；
2. 把消息转给模型；
3. 把模型回复发回飞书。

这条链路能跑通，但它只能解决“会回消息”。一旦真实工作继续往下走，团队很快会提出更多要求：

• 继续刚才那个任务；
• 把之前那张截图再发我一下；
• 每天早上 9 点把未完成事项发给我；
• 每 10 分钟检查一次页面，有变化再提醒我；
• 到下班前还没人回复，就帮我跟进一次。

这些事情都不是一次问答能完成的。它们依赖状态、工具、记忆和持续执行。所以从产品边界上说，机器人只是消息入口；常驻 AI 助理才是任务执行层。

为什么“能回消息”不等于“能做事”？

因为真实工作不是单轮问答，而是带上下文的连续动作。

一个系统要想被称为“会做事”，至少要满足四个条件：

1. 知道这件事从哪段上下文里来；
2. 能调用工具，例如读文件、跑命令、查网页、更新状态；
3. 能在消息结束后继续执行；
4. 能把结果主动送回原会话，而不是要求用户自己去另一个后台查。

普通机器人通常只覆盖第 2 条里最窄的一部分：调一次接口。它很少天然覆盖任务状态、长期上下文、后台执行和回传交付。GoWork 的价值，正好在于把这几层补齐。

在飞书里，最值得优先接入的三类场景

1. 聊天里直接发起后台任务

例如：

• 帮我总结这个目录里最新的报错；
• 帮我看今天这个页面有没有更新；
• 把这段需求整理成 5 条行动项发回来。

这些任务的入口在飞书，但真正的工作发生在聊天框外。GoWork 的意义，在于让这条链路不需要人为切换上下文。

2. 定时提醒、周期巡检和条件命中通知

这类需求是飞书助理和普通机器人拉开差距的地方。

例如：

• 明天早上 8 点提醒我确认发布计划；
• 每个工作日 9 点把未完成事项发给我；
• 每 10 分钟检查一次这个页面，有变化再告诉我；
• 如果今晚还没收到审批结果，6 点自动提醒我跟进。

如果系统只会回复消息，这些需求根本落不了地。GoWork 的定时任务可以把自然语言转成结构化调度，在后台持续执行，再把结果送回飞书。

3. 需要上下文连续性的长期任务

飞书特别适合作为团队里的日常入口，但日常入口最怕的就是每次都从头来。

常见表达包括：继续刚才那个任务、按上次的方式再跑一遍、以后都按这个格式、把之前那张截图再发我一下。没有会话记忆、历史任务和交付记录，这几句话几乎都接不住。

一个实用判断：你的需求更像 Bot，还是更像 Assistant？

可以直接问 5 个问题：

1. 这个系统是否只需要回复消息，不需要继续执行？
2. 它是否不需要记住上一次任务做到哪？
3. 它是否不需要定时、轮询或条件触发？
4. 它是否不需要调本地工具、文件或 Shell？
5. 它是否不需要主动把结果送回原会话？

如果这 5 个问题里大多数答案是“是”，机器人就够用；如果其中 2～3 项开始变成“否”，你需要的通常已经是常驻 AI 助理。

常见问题

FAQ 1：飞书机器人加上大模型，不就已经是 AI 助理了吗？

不一定。加了大模型，只能说明回复变聪明了；是否是助理，要看它能不能保留状态、持续执行、调用工具，并把结果主动交付回来。

FAQ 2：是不是所有团队都应该直接上常驻 AI 助理？

也不是。如果你的需求主要是通知、FAQ、关键词回复或单次问答，机器人依然更简单有效。只有当你开始要求上下文、执行和定时闭环时，常驻助理的价值才会明显超过机器人。

FAQ 3：GoWork 更适合什么样的团队先试？

最适合的是已经在飞书里频繁下达任务、需要后台执行和定时跟进，并且不想每次都把上下文从头讲一遍的团队。

本文首发于 OmniGoAI 官网：https://omnigoai.com/zh/blog/gowork-feishu-assistant-setup/ ——OmniPost，把内容一键分发到 30+ 平台。