企业官网建设流程全解析

最近一段时间，围绕 WorkBuddy 的使用教程、安装方式和“一人公司”玩法，在技术群和短视频平台被反复提及。很多人一开始只是把它当成一个普通的 AI 助手：丢一个链接、传一份附件、给一段指令，它就能自动读取内容、生成摘要、整理待办，甚至继续触发后续动作。

但把 WorkBuddy 放到办公协作软件的语境里看，真正值得关注的不是某个工具好不好用，而是一个趋势：当 Agent 能直接“交付结果”时，钉钉、飞书这类软件过去赖以为生的“入口逻辑”，正在被一点点重构。

这篇文章不会只讨论行业趋势。我会把 WorkBuddy 所代表的“Agent 优先”工作流，拆成一套可以落地的技术方案：从钉钉机器人 Webhook 签名、飞书机器人通知，到飞书多维表格分页读取，再到和 AI 摘要组合成的完整自动化流程。无论你是后端开发者、运维工程师，还是对办公自动化感兴趣的产品、技术负责人，都能找到可以复制运行的代码和配置思路。

1. 背景：WorkBuddy 跑出来后，“入口”不再是核心答案

1.1 为什么“入口执念”会被重新审视

过去几年，钉钉和飞书之间的竞争，经常被概括成一句话：谁先成为企业办公的“超级入口”。这个逻辑在纯人力工作流里是成立的。用户需要打开某个固定应用，去处理聊天、审批、文档、考勤，平台只要占据了这个打开频率最高的入口，就能天然绑定用户的工作习惯。

但 Agent 出现后，用户目标从“我要去某个应用里做某件事”，变成了“我要直接得到某个结果”。举个例子，以前提交报销的路径是：打开钉钉 → 进入 OA 审批 → 新建报销单 → 填写内容 → 提交。而在 Agent 模式下，需求表达变成了：把发票和审批规则发给 Agent，Agent 自己判断、填表、提交，最后回传一个“已提交”的结果。

当工作流的主控权从“人操作 App”转移到“Agent 调用服务”时，那个被反复强调的“入口”价值就被削弱了。不是钉钉、飞书不再重要，而是它们要从“留住用户的界面”，变成“能被 Agent 安全调用的服务端口”。说得直白一点：以前是平台决定用户用什么，以后是 Agent 决定调用哪些平台能力，平台要做的，是开放更标准、更安全、更稳定的接口，让 Agent 愿意调用自己。

1.2 WorkBuddy 到底在热什么

从搜索热词来看，围绕 WorkBuddy 的高频问题包括：使用教程、安装方式、怎么用、skill 技能、以及大量“应用案例”。这类问题说明，用户关心的不是 WorkBuddy 背后是哪一家公司的产品，而是它能不能帮我把“读链接、取附件、做总结、列待办、跨系统通知”这一长串动作自动化。

用一句话概括 WorkBuddy 这类工具的能力模型：给它一个目标，它自己决定调用哪些工具，最后把结果返回给你。比如给它一个网页链接，它能读取页面内容并生成摘要；给它一份 Excel，它能转换成结构化数据；给它一个“把结果发到钉钉群”的指令，它能去调用钉钉机器人 Webhook。

必须说明的是，WorkBuddy 具体的能力边界、收费方式和开放接口，都在快速迭代，应当以官方最新说明为准。本文更想强调的是，这种“Agent 执行 + 办公平台 API 接入”的组合方式，已经成为一种可复制的工程模式。这也是钉钉、飞书愿意放低身段开放能力的原因。

1.3 “放下入口”不是技术倒退，而是接口标准化

钉钉和飞书最近的动作，已经能看出“入口优先”向“接口优先”转变的迹象。钉钉在持续强化机器人能力、AI 助理和钉钉流；飞书则在机器人消息、多维表格 API、自动化工作流上不断加码。这些能力有一个共同点：它们不强制要求用户进入某个固定页面，而是允许外部程序直接调用。

对开发者的直接影响是，我们不再需要纠结“用户是否安装了某个应用”，只需要关注“目标平台是否提供了可用的 API”。这其实是更大的技术红利：过去的集成要处理 H5 页面、SDK 嵌入、用户授权弹窗，现在很多高频场景只需要一个经过认证的 Webhook 或 OpenAPI 调用即可完成。

2. 核心概念：执行 Agent、协作平台、编排工具的分工

2.1 不要把 WorkBuddy 和钉钉、飞书画等号

很多读者容易陷入一个误区：WorkBuddy 跑出来后，钉钉、飞书是不是要被替代？答案是否定的。它们解决的问题不在同一个层面。

• WorkBuddy 属于“执行 Agent”，负责理解意图、处理内容、生成结果。
• 钉钉属于“组织协作平台”，负责组织沟通、审批、考勤、企业应用管理。
• 飞书属于“信息协同平台”，负责文档、多维表格、消息、工作流。
• n8n 这类工具属于“工作流编排器”，负责把不同系统的 API 连接起来，定时或按事件触发。

一个合格的新办公自动化架构，不是让某一种工具包办所有事，而是让 Agent 做决策，让编排工具做流程，让钉钉、飞书做触达和协作。WorkBuddy 跑出来后的典型用户路径可能是：

把材料交给 Agent（链接/附件/指令） ↓ Agent 调用大模型完成总结、分类、待办提取 ↓ Agent 调用 n8n 或直接调用 API ↓ 钉钉机器人/飞书机器人把结果推送到群里 ↓ 用户直接在聊天窗口看到最终结果

在这个链路里，钉钉和飞书仍然出现，但它们的角色从“工作台入口”变成了“消息出口和协作底座”。

2.2 表格：不同角色的能力边界

2.3 为什么这个分工对开发更友好

从工程实现角度看，这种分工最直接的好处是“解耦”。

如果所有能力都塞进一个超级 App，意味着开发要遵循它的私有协议、SDK 版本、审核流程。但 Webhook 和 OpenAPI 是相对标准的，钉钉机器人本质是一个 HTTP POST，飞书机器人也是一个 HTTP POST，多维表格是一个 REST API。任何语言、任何定时任务框架，只要能发 HTTP 请求，就能完成接入。

这也解释了为什么热词里会出现“n8n 分页获取飞书多维表格”“Jenkins 通知飞书”这类具体问题。因为大家正在把钉钉、飞书当成一个可以编程调用的“能力池”，而不是一个必须点开才能用的“界面”。

3. 从“占入口”到“开 API”：钉钉、飞书开放姿态的变化

3.1 钉钉：以机器人和 AI 表格为支点

钉钉的对外开放能力，最常用的是自定义机器人 Webhook。它的优点是配置门槛低：在一个群里添加自定义机器人，得到 Webhook 地址和密钥，就能通过 HTTP POST 发送文本、Markdown、链接卡片等消息。企业开发中常见的场景包括：

• 构建流水线失败后，自动把日志摘要推到研发群；
• 定时任务执行完毕，把数据报表推送到业务群；
• Agent 完成 AI 摘要后，把结论推送到审批群。

钉钉还提供了 AI 表格的能力，让表格不只是静态数据，而是能结合 AI 完成字段生成、内容补全。这本质上也是在告诉开发者：你可以不打开表格界面，而是通过接口让 AI 直接处理表格数据。

3.2 飞书：以多维表格和机器人为核心

飞书最亮眼的开放能力是多维表格（Bitable）。它把表格、数据库、看板几种形态融合在一起，同时提供了相对完整的 REST API。开发者可以通过 API 读取记录、新增记录、更新字段、按条件筛选。

实际业务中，飞书多维表格经常被当作轻量业务数据库使用。比如运营团队会用它管理客户信息，产品团队会用它维护需求池，数据分析团队会用它临时汇总数据。当表格里的记录达到几万条甚至几十万条时，一次性全量拉取就不现实了，必须处理分页。这也是热词里“飞书多维表格很多记录，如何通过 n8n 分页获取”出现的原因。

飞书自定义机器人同样提供了 HTTP Webhook 接入。将消息 Post 到 Webhook 地址，就能在群里看到结果。配合签名校验后，调用方需要传时间戳和签名，安全性比裸 Webhook 更高。

3.3 三类平台的共同点：标准 HTTP 接口

钉钉、飞书、企业微信虽然产品形态各不相同，但对外集成思路逐渐趋同：

• 都提供自定义机器人 Webhook；
• 都提供应用级鉴权（App ID、App Secret）；
• 都提供消息、通讯录、审批等 OpenAPI；
• 都支持应用在服务端调用，而不依赖用户在浏览器或客户端里的操作。

所以，不管以后 Agent 工具如何演进，开发者只要掌握“Webhook 消息推送”和“OpenAPI 数据读写”这两类通用能力，就能把 WorkBuddy 这类 Agent 和钉钉、飞书连接起来。

4. 技术底座：Webhook 与开放 API 配置实操

4.1 钉钉自定义机器人配置

在钉钉群里添加自定义机器人，步骤如下：

1. 进入目标群聊，点击右上角“设置”；
2. 找到“智能群助手”，点击“添加机器人”；
3. 选择“自定义机器人”，填写机器人名称；
4. 配置安全设置，推荐勾选“加签”；
5. 添加成功后，复制 Webhook 地址和安全密钥。

安全设置里的“加签”非常关键。开启后，每次 POST 请求都必须携带timestamp和sign两个参数，机器人才会接收消息。这样即使 Webhook 地址泄露，攻击者不知道密钥也无法伪造消息。

4.2 飞书自定义机器人配置

飞书自定义机器人的配置方式和钉钉类似：

1. 进入飞书群聊，点击“设置”；
2. 找到“群机器人”，点击“添加机器人”；
3. 选择“自定义机器人”；
4. 复制 Webhook 地址；
5. 开启签名校验，保存密钥。

飞书支持的消息类型包括纯文本、富文本（post）、交互卡片（interactive）。最简单的验证方式是拿curl发一条纯文本消息。

4.3 用 curl 快速验证 Webhook

创建好钉钉机器人后，可以先在命令行验证 Webhook 是否可用。假设你选择的是“关键词”安全设置，并且关键词设置为“通知”，那么 Markdown 里必须包含“通知”两个字。

curl 'https://oapi.dingtalk.com/robot/send?access_token=你的access_token' \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "markdown", "markdown": { "title": "通知", "text": "# 通知\n这是一条来自 Agent 的测试消息" } }'

如果返回结果中的errcode为 0，说明 Webhook 配置成功。

5. 开发实战：构建基于 Agent 的钉钉、飞书自动化工作流

下面这套示例会完成三件事：

1. 用 Python 调用钉钉机器人 Webhook，发送带签名的 Markdown 消息；
2. 用 Python 调用飞书机器人 Webhook，发送纯文本消息；
3. 模拟 Agent 生成摘要后，将结果自动推送到钉钉和飞书，同时演示飞书多维表格分页读取。

5.1 项目结构

workbuddy-demo/ ├── agent/ │ ├── main.py │ ├── dingtalk.py │ ├── feishu.py │ └── config.py └── README.md

文件职责如下：

• config.py：存放 Webhook、密钥等配置；
• dingtalk.py：封装钉钉机器人签名和消息发送；
• feishu.py：封装飞书机器人发送和多维表格分页读取；
• main.py：模拟 Agent 主流程。

5.2 钉钉机器人签名与消息发送

文件路径：agent/dingtalk.py

import base64 import hashlib import hmac import time import urllib.parse import requests def build_signed_url(access_token: str, secret: str) -> str: """生成带签名参数的钉钉机器人 Webhook URL""" timestamp = str(round(time.time() * 1000)) string_to_sign = f"{timestamp}\n{secret}" hmac_code = hmac.new( secret.encode("utf-8"), string_to_sign.encode("utf-8"), digestmod=hashlib.sha256, ).digest() sign = urllib.parse.quote_plus(base64.b64encode(hmac_code)) return ( "https://oapi.dingtalk.com/robot/send" f"?access_token={access_token}&timestamp={timestamp}&sign={sign}" ) def send_dingtalk_markdown( access_token: str, secret: str, title: str, text: str ) -> dict: """发送 Markdown 消息到钉钉群""" url = build_signed_url(access_token, secret) payload = { "msgtype": "markdown", "markdown": { "title": title, "text": text, }, } resp = requests.post(url, json=payload, timeout=10) return resp.json()

关键说明：

• 签名算法是先做 HMAC-SHA256，再做 Base64，最后做 URL 编码；
• timestamp必须是当前毫秒时间戳，服务端会校验时差；
• 如果你的服务器时间不准，会出现“签名错误”的报错，所以生产环境要配置 NTP 时间同步。

5.3 飞书机器人消息发送

文件路径：agent/feishu.py

import requests def send_feishu_text(webhook_url: str, text: str) -> dict: """发送纯文本消息到飞书群""" payload = { "msg_type": "text", "content": { "text": text, }, } resp = requests.post(webhook_url, json=payload, timeout=10) return resp.json()

如果你的飞书自定义机器人开启了“签名校验”，需要在请求体中额外携带timestamp和sign。不同版本的飞书自定义机器人签名规则略有差异，具体以飞书开放平台最新文档为准。

5.4 飞书多维表格分页读取

当多维表格记录很多时，必须使用分页接口。飞书多维表格 API 返回结构里包含三个关键字段：

• items：当前页数据；
• has_more：是否还有下一页；
• page_token：下一页游标。

文件路径：agent/feishu.py，继续追加以下代码：

BASE_URL = "https://open.feishu.cn/open-apis" def get_tenant_access_token(app_id: str, app_secret: str) -> str: """通过应用凭证获取 tenant_access_token""" resp = requests.post( f"{BASE_URL}/auth/v3/tenant_access_token/internal", json={"app_id": app_id, "app_secret": app_secret}, timeout=10, ) data = resp.json() return data.get("tenant_access_token", "") def list_records( tenant_access_token: str, app_token: str, table_id: str, page_size: int = 100, page_token: str = None, ): """读取一页多维表格记录""" url = f"{BASE_URL}/bitable/v1/apps/{app_token}/tables/{table_id}/records" params = {"page_size": page_size} if page_token: params["page_token"] = page_token headers = {"Authorization": f"Bearer {tenant_access_token}"} resp = requests.get(url, params=params, headers=headers, timeout=10) data = resp.json().get("data", {}) items = data.get("items", []) has_more = data.get("has_more", False) next_token = data.get("page_token", None) return items, has_more, next_token def fetch_all_records( tenant_access_token: str, app_token: str, table_id: str, page_size: int = 100, ) -> list: """循环分页，获取多维表格全部记录""" all_items = [] page_token = None while True: items, has_more, next_token = list_records( tenant_access_token, app_token, table_id, page_size, page_token, ) all_items.extend(items) if not has_more: break page_token = next_token return all_items

这段代码是“飞书多维表格很多记录如何分页获取”的标准写法。生产环境建议再加一个最大循环次数保护，防止异常导致无限循环。

5.5 模拟 Agent 主流程

文件路径：agent/main.py

from dingtalk import send_dingtalk_markdown from feishu import send_feishu_text, get_tenant_access_token, fetch_all_records def summarize_by_llm(source_text: str) -> str: """这里接入你自己的大模型服务""" # 示例伪代码： # from your_llm_sdk import chat # return chat("请总结以下内容", source_text) return "AI 摘要：本次订单数据整体增长 12%，主要来自华东区域。" def run(): dingtalk_token = "your_dingtalk_access_token" dingtalk_secret = "your_dingtalk_secret" feishu_webhook = "https://open.feishu.cn/open-apis/bot/v2/hook/xxx" # 1. 模拟拿到一段原始材料 source_text = "本周订单数量 1200 单，较上周增长 12%..." # 2. Agent 调用大模型生成摘要 summary = summarize_by_llm(source_text) # 3. 推送到钉钉群 dingtalk_result = send_dingtalk_markdown( dingtalk_token, dingtalk_secret, "订单周报", f"## 订单周报\n{summary}", ) # 4. 推送到飞书群 feishu_result = send_feishu_text(feishu_webhook, summary) print("钉钉返回：", dingtalk_result) print("飞书返回：", feishu_result) if __name__ == "__main__": run()

这里有一个建议：实际接入大模型时，不要把 API Key 直接写在源码里。更稳妥的做法是从环境变量或配置中心读取。

5.6 多维表格 + n8n 的分页处理思路

如果你不想写代码，而是用 n8n 完成“飞书多维表格很多记录的分页获取”，思路如下：

1. 先用 HTTP Request 节点调用飞书认证接口，拿到tenant_access_token；
2. 再调多维表格记录接口，设置page_size=100；
3. 读取返回结果中的has_more和page_token；
4. 如果has_more为 true，就用 IF 节点判断并继续请求；
5. 将每次返回的items数组追加到同一个集合中，供后续节点使用。

n8n 的 HTTP Request 节点本身也支持分页配置，但飞书多维表格的page_token是动态游标，建议你在工作流里手动维护一个page_token变量，这样更可控，也容易排查问题。

5.7 运行与验证

执行主流程：

cd workbuddy-demo python3 agent/main.py

预期效果：

• 钉钉群收到一条 Markdown 消息，标题为“订单周报”；
• 飞书群收到一条纯文本消息，内容是 AI 摘要；
• 控制台打印钉钉返回的errcode和飞书返回的code。

如果返回errcode=0或code=0，说明调用成功。

6. 常见问题与排查思路

排查 Webhook 问题时，建议先打印完整请求 URL 和请求体，确认参数没有被截断。尤其是钉钉签名参数里的+号，如果 URL 编码有问题，很容易导致签名校验失败。

7. 最佳实践与工程建议

7.1 密钥与凭据管理

不要把access_token、secret、app_id、app_secret写死在代码或提交到代码仓库。生产环境建议：

• 使用环境变量；
• 使用配置中心；
• 使用密钥管理平台。

对于机器人账号，建议遵循“最小权限”原则，只给 Agent 分配它真正需要的群和 API 权限。权限越大，一旦密钥泄露造成的风险也越大。

7.2 重试与幂等

Webhook 调用可能因为网络抖动失败。重试策略上，推荐指数退避：第一次失败后等 1 秒，第二次等 2 秒，第三次等 4 秒，最多重试 3 到 5 次。同时要保证消息推送的幂等性——同一份摘要如果被发送两次，接受方不会产生数据歧义，可以在消息里带一个msg_id或任务 ID。

7.3 日志与审计

Agent 调用逻辑越复杂，越需要完整日志。至少记录：

• 任务 ID；
• 触发时间；
• 输入材料摘要；
• 调用的平台和接口；
• 返回结果；
• 重试次数。

这能帮助你在 Agent“自作主张”出错时快速定位问题。

7.4 合规与边界

接入钉钉、飞书 API 时，务必遵守平台服务协议和公司内部数据安全规范。读取多维表格前，确认你有该应用的合法授权；调用机器人前，确认目标群允许外部程序推送。特别提醒：这类自动化能力不能用于绕过考勤、定位等管理功能，也不能用于窃取聊天记录或未授权导出隐私数据。技术能力应当用来提升生产和协作效率，而不是破坏规则。

7.5 主动设计“人机确认”环节

在自动化链路里，如果 Agent 的操作结果会影响审批、财务或业务流程，建议不要完全无人干预。可以在推送到钉钉/飞书群之后，增加“等待人工确认”的中间节点。这样既能享受 Agent 带来的效率提升，又能保留风险控制能力。

8. 下一步可以继续探索的方向

看到这里，你已经掌握了“Agent + 钉钉/飞书 Webhook + 多维表格 API”这条完整链路。下一步可以继续深入的方向有：

1. WorkBuddy skill 设计：把一个长任务拆成多个可复用的 skill，例如“读取链接生成摘要”“读取飞书多维表格生成周报”“定时触发并推送到钉钉群”。
2. n8n 复杂流程编排：把 Webhook、AI 摘要、钉钉通知、飞书多维表格写入串联成一个可视化工作流，支持定时触发和事件触发。
3. 钉钉/飞书免登录集成：如果你在开发 Web 系统，可以研究钉钉扫码登录、飞书授权登录的 OAuth 流程，把内部系统和企业身份体系打通。
4. Jenkins 通知飞书：在 CI/CD 流水线中增加飞书机器人通知，构建失败或发布成功时自动推送结果。
5. 自建一个轻量 Agent：如果你不想依赖第三方 Agent 工具，可以基于大模型 API 和 Python 写一个最小实现，把链接读取、内容摘要、Webhook 推送合并到一个脚本里。

这类方向的价值不只是“少点几次按钮”，而是把重复性工作从人的日程里解放出来。真正值得关注的，也不再是某个工具是不是下一个“超级入口”，而是你的系统能不能快速接入这些能力，让数据在 Agent、协作平台和业务系统之间高效流转。如果你正打算在公司内部落地类似方案，建议先从一条群消息通知的自动化开始试水，再逐步扩展到多维表格读取、报表生成、审批触发等更高价值的场景。