企业官网建设流程全解析

飞书“开门”迎Agent，这句话放到一年前，我大概只会当成厂商发布会的漂亮话。但当你真正在一家几百人的公司里，被反复问“能不能让机器人把我上午开会的纪要用多维表格生成出来”的时候，你就会明白，办公IM开放接口，对于做Agent的人来说，就是给AI找了一份“有工位的工作”。我是从去年开始把智能体往飞书群里塞的，从最初只会回“收到”的玩具，到现在能查数、做日报、盯项目进度的“数字员工”，踩过的坑比写出来的代码多。这篇东西不打算讲大道理，就聊聊飞书到底开了哪些口子、千问怎么接进去、WorkBuddy这类Agent框架为什么现在能抢到活，以及每一步该怎么落地。

1. 飞书这扇“门”到底开了多大

1.1 从“只能聊天”到“可编程工作台”的转身

很多人对飞书的印象还停留在“文档好用”“群消息体验好”，但做Agent的人看飞书，看的其实是底下的那套开放平台。一个IM如果没有开放能力，对Agent来说就是个只能发言的“喇叭”；有了开放能力，它才变成Agent的手和脚。飞书这几年最核心的变化，是把机器人、多维表格、云文档、审批这些业务组件一一开放成API，让你可以在消息旁边挂一个真正会读写数据的程序。我自己测试下来印象最深的是多维表格，它本质上是一个轻量的在线数据库，所有记录、字段、视图都能用接口操作，这意味着Agent既能从里面取数，也能把处理结果写回去，形成一个完整闭环。

这些能力组合起来，给Agent安排“工作”就顺理成章了。比如你在群里说一句“帮我把这批候选人状态更新一下”，消息事件被推送到后端服务，服务解析意图后调用多维表格API更新记录，再把结果以消息卡片形式发回群里。整个链路不需要人工碰文档，数据在表格里自动流转。这就是办公场景里“抢到活”的基础——先有路，车才能跑。

要提醒的是，开放接口不等于放权。飞书每个API都对应明确的权限范围，比如读取消息、读取用户、读写多维表格，全部要单独申请并由管理员审核。好处是安全边界清晰，坏处是你做Agent时如果不提早把权限清单梳理清楚，后面每走一步都会卡在“scope不够”上。

1.2 飞书开放能力里真正值钱的三样东西

第一样是消息卡片。普通机器人只能往群里丢文字，消息卡片可以容纳按钮、表单、图片、超链接，让Agent从“说话”进化到“交互”。我做过一个审批助手，收到待办后直接在卡片里放“同意”和“驳回”两个按钮，点击后通过回调触发后端逻辑，体验比让人切到审批应用里点几下顺滑得多。

第二样是多维表格。刚才说了它是轻量数据库，但真正重要的是它被无数团队用成了“业务中台”：日报、项目进度、客户信息、库存数据都存在里面。Agent只要会读写多维表格，就能触及一家公司的核心数据流。这也是为什么很多团队宁可让Agent去操作多维表格，也不愿先给它接数据仓库——前者零运维，后者太重。

第三样是事件订阅。飞书会把“有人发消息”“有人加入群”“有人更新了表格记录”这类变化主动推给后端，Agent不用轮询、不用猜，只要配置好回调地址就能感知现场。这一条往往被新手忽略，但没有它，Agent就是一个“只能被@才工作”的被动工具，谈不上智能。

1.3 飞书“开门”的具体路径：自建应用是第一步

无论你最终要用千问还是WorkBuddy，第一步都是在飞书开放平台创建一个“企业自建应用”。这个应用就是Agent的工作证，所有机器人能力、API权限都挂在它下面。创建后在“添加应用能力”里勾上“机器人”，再进入“权限管理”申请对应的scope，比如im:message、bitable:app这些。然后发布版本，等管理员审核通过，你就拥有一个可以加进群的机器人了。

审批通过后，要把机器人拉到内部测试群，群里发消息，后端就能通过事件订阅收到数据。注意飞书要求回调地址是HTTPS公网可访问，而且首次配置时会发一个challenge请求验证接口的真实性。可以这么说，飞书给Agent开的“门”并不是钥匙交到你手里就完了，它还有一套很严格的验房标准。

2. 千问：Agent的“大脑”怎么被飞书看到

2.1 千问在整条链里到底负责什么

飞书负责“手脚”，千问负责“大脑”。一个群内Agent收到用户消息后，第一件事不应该是写死规则去匹配关键词，而是把消息交给大模型做意图理解。比如“帮我看下这个月华东区销售完成情况”和“华东区这个月怎么样”，文本完全不同，但语义指向同一个动作。千问这类大模型的价值，就是把灵活的、口语化的请求翻译成结构化的任务，再决定调用哪个工具。

我在实际项目中喜欢让千问直接输出一个JSON结构，里面包含操作类型和参数，后端再根据这个JSON去调用飞书API。比如大模型输出{"action":"query_bitable","table":"sales","filter":{"region":"华东","month":"2025-04"}}，后端拿到后解析执行。这里的关键是千问要具备稳定的结构化输出能力，否则后面解析会各种崩。

2.2 飞书生态里接入千问的三种主流姿势

第一种是最常见的“飞书机器人 + 后端服务 + 千问API”。用自己的服务器起一个服务，接收飞书事件，调用千问的模型接口拿到回复，再通过飞书API把回复发到群里。这套方案的好处是简单直接，几乎所有模型都支持HTTP调用，调优空间大。缺点是所有请求都要经过你的服务，链路长一点，但办公场景完全够用。

第二种是本地部署千问。有些企业对数据敏感，不愿意把内部消息发到外部模型服务，那就把千问开源模型部署到自己机器上。Qwen系列有不少开源尺寸，7B、14B、27B、32B都有，27B这个量级在本地部署后，用Q4量化大约需要16GB左右显存，配上32GB内存，跑办公问答基本够用，质量比7B强很多。不过本地部署要自己处理并发、流式输出和负载，属于“麻烦但可控”的选择。

第三种是走飞书应用市场上已有的模型机器人插件。适合完全不想写代码、只想快速体验的人。但如果你想做深度业务定制，比如让它操作多维表格、触发审批，插件模式往往不够灵活，最后还是会回到自建应用这条路。

2.3 千问在办公场景里真正好用的点和不能碰的线

好用的点在于中文理解和任务抽取。飞书群里聊业务，经常夹杂简称、术语、错别字，千问在这类中文本地化场景下比很多国外模型更稳。另一个点是长文本聚合，比如把二十个人的日报汇总成一页晨会简报，千问可以做得比较漂亮。

不能碰的线有三条。一是不要把未经脱敏的业务数据直接当上下文塞给模型，尤其是涉及客户隐私和薪酬的内容。二是模型返回不等于事实，凡是涉及“金额汇总”“库存判断”这类结果，最好在后端对关键数字做二次校验，避免幻觉数据进表格。三是别让大模型直接执行有权限边界的操作，比如“把某个离职员工的共享文档删掉”这类高危动作，后端必须加人工确认或白名单校验。

3. WorkBuddy：让Agent从“会聊天”进化到“会干活”

3.1 WorkBuddy是什么样的Agent框架

如果说千问是“大脑”，飞书是“办公桌”，那WorkBuddy这类框架就相当于是“工作流”，负责把脑子里想的事儿拆解成一步步可执行的动作。很多人一开始做Agent，都从“问一句回一句”的聊天机器人入手，但真实办公里的活根本不是这样——一个任务往往要跨多个系统，经历多次判断和回退。WorkBuddy的关注点就是“任务完成”，它把可调用的能力封装成一个一个的Skill，Agent根据大模型生成的计划，按顺序调用Skill，最终完成一件完整的业务操作。

比如“统计销售数据并发日报”这件事，在WorkBuddy里会被拆成：读取多维表格、聚合数据、生成文案、发送消息这四个Skill。每一步都可以独立调试，哪个环节出了问题就修哪个。相比把所有逻辑写在prompt里让大模型自由发挥，这种编排方式对复杂任务更可控，也更容易让非技术同事理解和复核。

3.2 用WorkBuddy搭一个飞书群内的数据Agent

我自己做过一个最小可用的例子，功能就是“群里问数据，Agent查表并回复”。先在WorkBuddy中注册一个名叫query_bitable的Skill，输入参数是表格token、字段名和筛选条件，内部用飞书API查询记录并把结果整理成Markdown表格。然后再注册一个send_feishu_message的Skill，负责把一段文本或消息卡片发到指定群。

真正让这套东西跑起来的关键一步，是把飞书事件和WorkBuddy的入口连起来。飞书把消息事件推给后端，后端把消息文本交给大模型，大模型输出任务计划，WorkBuddy按计划执行Skill，最后把结果回传到飞书。这比“大模型一口把所有事干完”的做法稳定得多。因为每个Skill都有明确的输入输出，出问题时你能精确知道是查询没写好，还是消息发送失败。

3.3 CodeBuddy和WorkBuddy，开发与办公的两条腿

热词里经常看到CodeBuddy和WorkBuddy同时出现。我的理解是，CodeBuddy更偏代码任务，帮开发人员写代码、查bug、做代码评审；WorkBuddy更偏办公任务，帮团队成员处理数据、文档、协作流程。两者并非竞争，反而像工具箱里的不同扳手。在一个Agent体系里，你完全可以既接CodeBuddy处理研发侧的活儿，又接WorkBuddy处理运营侧的杂事，核心是它们都能复用飞书这个入口和千问这个大脑。

比如我现在的机器人，研发群里被@时走CodeBuddy的技能链条，能根据报错日志给出修复建议；运营群里被@时走WorkBuddy的技能链条，能查数据、做日报。用户只会感觉“这个AI在群里很有用”，而不关心背后调用了哪套框架。这种多框架并存、按场景路由的架构，我认为是办公Agent的常态解法。

4. 能不能抢到“活”：场景判断与价值边界

4.1 最容易抢到的活：高频、重复、有明确输入输出

做Agent最怕的是为了所谓的“智能化”去硬找一个需求。真正值得做的活往往有三个特征：频率高、规则明确、数据可获取。比如日报汇总，每天每个人都要提交，内容大同小异，多花点时间把格式调好，Agent完全可以每天早晨自动捞取数据、生成摘要、发到管理群。再比如群内数据问答，销售、运营、HR群里常有“咱们这边上个月新签了多少家客户”这类查询，如果数据已经在多维表格里，回复只是几秒钟的事。

我自己的经验是，这类活的ROI很高。你花一周搭好的Agent，每天能帮团队省下半小时起步的机械劳动，时间一长，大家自然把它当自己人。抢到活的第一个要点是让Agent出现在“工作现场”——也就是用户本来就在的地方。飞书群的天然优势是，用户不需要新开一个工具，直接@一下就能使唤AI，这种低门槛非常关键。

4.2 抢不到的活：涉及审批、隐私和强实时责任的场景

不是所有活都适合Agent干。第一类是需要法律效力的审批流，比如报销审批、合同用印，这些流程的本质是“责任人在制度要求下做出决策”，不能为了让AI替人类背锅就把审批权交出去。Agent可以辅助提醒“这份合同金额超出标准，根据制度需要法务确认”，但它不能点“同意”。

第二类是强隐私场景。比如员工绩效面谈记录、招聘评估意见，这类内容如果进入大模型上下文，哪怕只是内部模型也有扩散风险。我的做法是这类数据只展示必要条件，比如只让模型看到“候选人姓名+面试评分”，原始评语不进入prompt。

第三类是强实时且高可靠性场景。Agent抢到“活”之后，如果它执行的是一个被业务依赖的定时任务，比如凌晨三点跑数据、早上八点发报告，那么你必须给它配上完善的监控和告警。否则某天模型接口超时导致报告没发，你处理客诉的时间远超你省下的时间。可靠性带来自信，容错决定边界。

4.3 需求该不该做，先问自己四个问题

能不能抢到活，做之前就能判断。我每次接到一个“把AI接进飞书”的需求，都会先问四个问题：这个任务是不是每周至少出现一次？输入和输出能不能用接口或表格描述清楚？数据是否已数字化，无需人工额外整理？做坏了是否可回退？四个问题都回答“是”，才值得投入做Agent。

如果任务本身每周出现不到一次，或者输入输出极其模糊，比如“帮我分析一下公司整体竞争力”，那先把流程跑起来再说。如果数据根本没数字化，得靠人复制粘贴到表格，Agent在这个环节帮不上忙，应该先做数据治理。用这四个问题筛下来，十个需求里能真正做成落地的也就两三个，但这两三个一定比盲目铺开有价值。

5. 实操复盘：从建应用到跑通群内Agent

5.1 创建自建应用与配置回调：第一道坎

这部分我踩过不少坑，写详细点。先在飞书开发者后台点击“创建企业自建应用”，填写名称后进入详情页。左边菜单里“添加应用能力”，机器人必开；如果后续要操作多维表格，还要在“权限管理”里搜索并申请bitable:app、bitable:record这些权限。申请权限时记住一点，宁可多申请一个用不上的权限也别漏，因为每次更新权限都要重新发布版本并让管理员审核，来回折腾很费时间。

事件订阅配置是新手最容易卡的地方。你要准备一个公网HTTPS地址，比如https://yourdomain.com/webhook/event，飞书会对你这个地址发起一次请求验证，里面带一个challenge字段，你的接口必须原样返回这个值才能完成验证。如果你只有局域网环境，可以先临时用工具把本地服务暴露出去调通，但正式环境建议用有备案的域名。

还需要注意，飞书事件推送有重试机制。如果你的接口处理报错，飞书会按策略重新推送。因此接口里面对同一事件要做去重处理，否则会出现用户发一句话机器人回了三次的情况。我的处理方式是维护一个事件ID的集合，收到事件先查ID是否已处理，重复直接返回成功。

5.2 接住消息事件并调用千问：核心代码

后端我用FastAPI写的，逻辑分四步：验证请求头、解析事件、调用千问、回复消息。代码概览如下：

from fastapi import FastAPI, Request import json, time app = FastAPI() processed = {} @app.post("/webhook/event") async def webhook(request: Request): data = await request.json() # 首次URL验证 if data.get("type") == "url_verification": return {"challenge": data["challenge"]} header = data.get("header", {}) if "event_id" in header: eid = header["event_id"] if eid in processed: return {"code": 0} processed[eid] = time.time() if header.get("event_type") == "im.message.receive_v1": event = data.get("event", {}) msg = event.get("message", {}) content = json.loads(msg.get("content", "{}")) text = content.get("text", "") chat_id = event.get("chat_id", "") reply = ask_qwen(text) send_feishu_text(chat_id, reply) return {"code": 0}

调用千问的部分，不要直接把原始消息拼到prompt里，而是要设计一个系统提示词，告诉模型它是什么角色、有哪些可用工具、应该输出什么结构。比如对数据类查询强制要求输出JSON。发送消息的API我一般用飞书的“发送消息”接口，传receive_id_type="chat_id"，把回复发给群。

5.3 回写多维表格：让Agent真的“把活干完”

很多入门Agent只做到“回复消息”就停了，但真正能抢到活的Agent，一定要把结果沉淀下来。飞书多维表格的写入接口不复杂，先拿到你的app_token和table_id，然后构造一条记录数据，调用bitable/v1/apps/{app_token}/tables/{table_id}/records接口POST进去。

比如我做的客户信息整理Agent，收到的信息是“XX公司是深圳的，意向A级别”，后端解析后直接写进多维表格，字段分别是公司名、城市、意向等级、更新时间。这样Agent的产出不再是一次性对话，而是沉淀成了团队可以随时查询的资产。这一步是办公场景里Agent和chatbot的最大分水岭，一定不能忽略。

写完后可以用消息卡片把写的结果反馈给用户，比如“已成功录入：XX公司 / 深圳 / A级”，让用户确认，也给人工纠错留一个机会。如果解析失败，则提示用户补充字段，而不是默默写一条错误数据进去。

6. 常见问题与避坑速查

6.1 权限申请总被拒，其实是顺序不对

后台的权限管理看起来只是勾选，但顺序会影响审核效率。我的建议是先梳理Agent需要的完整能力清单，一次性发起申请，然后写清楚用途。很多管理员看到零散的权限特别烦，反而容易拒绝。权限说明里尽量写“用于业务数据汇总展示”这样的具体用途，不要只写“AI机器人需要”。

如果线上已有旧版本应用在跑，更新权限后一定要重新发布版本，并提醒管理员审核新版。以前有个项目，我明明在后台加了权限但没发布，线上机器人死活读不了多维表格，排查了半天才发现应用版本根本没更新。

6.2 事件订阅一直收不到消息，问题多半在回调地址

先确认你的回调地址是否公网可达，飞书服务器能不能访问到。接着确认接口有没有正确处理url_verification，很多人在这一步直接返回200但没返回challenge，导致配置保存不上。再检查应用是否真的添加了机器人并启用了事件订阅，订阅的是不是im.message.receive_v1这个事件类型。如果你订阅成im.chat.member.added之类，当然收不到消息。

还有一点，如果你的服务开启了网关鉴权，要记得对飞书回调接口放行。我遇到过因为网关加了一层token校验导致飞书推送全部被拒的情况，排查到怀疑人生。

6.3 模型返回的内容时不时带JSON噪声怎么办

千问的回复偶尔会在JSON前后加一句“好的，我已经整理好了”这种自然语言，直接json.loads必崩。我的做法是写一个容错解析函数，先尝试直接用正则提取JSON字段，提取不到再交给模型二次格式化。另外，可以在提示词里用示例明确“只输出JSON，不要任何前后缀”，实测能大幅降低噪声概率。

如果要的是高稳定场景，建议走模型的function calling能力，让模型调用预设函数，输出格式有协议兜底，比手工prompt可靠得多。function calling确实会多吃一些token，但换来的是稳定，值。

6.4 本地部署千问27B级别模型，显存到底怎么算

Qwen系列27B模型全精度跑需要大约54GB显存起步，实际没人那么干。本地部署大多用GGUF量化格式，Q4_K_M量化后大小大约16GB到17GB，单张24GB显卡能跑，配合CPU卸载和64GB内存也能勉强运行。如果你有双卡或48GB显存，就能获得更好的上下文窗口和并发能力。

用Ollama是最快的起步方式，安装后执行ollama run qwen:27b-chat就能拉模型，跑起来后再通过HTTP接口接入后端服务。但即使如此，也千万别指望它扛住大流量。真实办公场景建议把这类模型用在低频、高隐私的请求上，高频问题还是走云上API更划算。

关于“工作”这件事，我做了几轮飞书Agent项目之后，最大的体会是：飞书“开门”迎Agent，不只是飞书的战略，更像是一次“把AI安放在真实工作流里”的集体尝试。千问给Agent一颗听得懂人话的中文大脑，WorkBuddy这类框架把这些大脑里的想法变成可执行的动作，而飞书则提供了它们能发挥作用的工位。最终能不能抢到活，看的其实不是谁的模型更强，而是谁更愿意把高频、重复、有价值的那部分工作让渡给AI，同时还能接受它偶尔犯错、需要人工兜底的现实。数据都在表格里，权限都在后台，拉个群测一轮就知道答案了。