最近一段时间围绕 WorkBuddy 的使用教程、安装方式和“一人公司”玩法在技术群和短视频平台被反复提及。很多人一开始只是把它当成一个普通的 AI 助手丢一个链接、传一份附件、给一段指令它就能自动读取内容、生成摘要、整理待办甚至继续触发后续动作。但把 WorkBuddy 放到办公协作软件的语境里看真正值得关注的不是某个工具好不好用而是一个趋势当 Agent 能直接“交付结果”时钉钉、飞书这类软件过去赖以为生的“入口逻辑”正在被一点点重构。这篇文章不会只讨论行业趋势。我会把 WorkBuddy 所代表的“Agent 优先”工作流拆成一套可以落地的技术方案从钉钉机器人 Webhook 签名、飞书机器人通知到飞书多维表格分页读取再到和 AI 摘要组合成的完整自动化流程。无论你是后端开发者、运维工程师还是对办公自动化感兴趣的产品、技术负责人都能找到可以复制运行的代码和配置思路。1. 背景WorkBuddy 跑出来后“入口”不再是核心答案1.1 为什么“入口执念”会被重新审视过去几年钉钉和飞书之间的竞争经常被概括成一句话谁先成为企业办公的“超级入口”。这个逻辑在纯人力工作流里是成立的。用户需要打开某个固定应用去处理聊天、审批、文档、考勤平台只要占据了这个打开频率最高的入口就能天然绑定用户的工作习惯。但 Agent 出现后用户目标从“我要去某个应用里做某件事”变成了“我要直接得到某个结果”。举个例子以前提交报销的路径是打开钉钉 → 进入 OA 审批 → 新建报销单 → 填写内容 → 提交。而在 Agent 模式下需求表达变成了把发票和审批规则发给 AgentAgent 自己判断、填表、提交最后回传一个“已提交”的结果。当工作流的主控权从“人操作 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 表格不同角色的能力边界角色代表核心能力用户视角执行 AgentWorkBuddy 类工具读取链接/附件调用大模型生成摘要和待办“我把原始材料丢给它它返回结果”协作平台钉钉组织沟通、审批、考勤、机器人、AI 表格“组织内部需要统一协作入口”信息协同平台飞书文档、多维表格、机器人、开放 API“结构和非结构信息需要沉淀”工作流编排器n8n、自建脚本跨系统 API 连接、定时触发、错误重试“系统之间自动流转不做人工搬运”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 钉钉自定义机器人配置在钉钉群里添加自定义机器人步骤如下进入目标群聊点击右上角“设置”找到“智能群助手”点击“添加机器人”选择“自定义机器人”填写机器人名称配置安全设置推荐勾选“加签”添加成功后复制 Webhook 地址和安全密钥。安全设置里的“加签”非常关键。开启后每次 POST 请求都必须携带timestamp和sign两个参数机器人才会接收消息。这样即使 Webhook 地址泄露攻击者不知道密钥也无法伪造消息。4.2 飞书自定义机器人配置飞书自定义机器人的配置方式和钉钉类似进入飞书群聊点击“设置”找到“群机器人”点击“添加机器人”选择“自定义机器人”复制 Webhook 地址开启签名校验保存密钥。飞书支持的消息类型包括纯文本、富文本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 的钉钉、飞书自动化工作流下面这套示例会完成三件事用 Python 调用钉钉机器人 Webhook发送带签名的 Markdown 消息用 Python 调用飞书机器人 Webhook发送纯文本消息模拟 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.pyimport 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), digestmodhashlib.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, jsonpayload, timeout10) return resp.json()关键说明签名算法是先做 HMAC-SHA256再做 Base64最后做 URL 编码timestamp必须是当前毫秒时间戳服务端会校验时差如果你的服务器时间不准会出现“签名错误”的报错所以生产环境要配置 NTP 时间同步。5.3 飞书机器人消息发送文件路径agent/feishu.pyimport requests def send_feishu_text(webhook_url: str, text: str) - dict: 发送纯文本消息到飞书群 payload { msg_type: text, content: { text: text, }, } resp requests.post(webhook_url, jsonpayload, timeout10) 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}, timeout10, ) 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: fBearer {tenant_access_token}} resp requests.get(url, paramsparams, headersheaders, timeout10) 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.pyfrom 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 完成“飞书多维表格很多记录的分页获取”思路如下先用 HTTP Request 节点调用飞书认证接口拿到tenant_access_token再调多维表格记录接口设置page_size100读取返回结果中的has_more和page_token如果has_more为 true就用 IF 节点判断并继续请求将每次返回的items数组追加到同一个集合中供后续节点使用。n8n 的 HTTP Request 节点本身也支持分页配置但飞书多维表格的page_token是动态游标建议你在工作流里手动维护一个page_token变量这样更可控也容易排查问题。5.7 运行与验证执行主流程cd workbuddy-demo python3 agent/main.py预期效果钉钉群收到一条 Markdown 消息标题为“订单周报”飞书群收到一条纯文本消息内容是 AI 摘要控制台打印钉钉返回的errcode和飞书返回的code。如果返回errcode0或code0说明调用成功。6. 常见问题与排查思路问题现象常见原因解决思路钉钉机器人返回errcode310000签名错误、关键词不匹配、IP 不在白名单检查加签算法、消息是否包含关键词、IP 白名单配置钉钉机器人返回签名不匹配服务器时间偏差超过 1 分钟同步 NTP 时间重新生成 timestamp飞书机器人返回Invalid webhook urlWebhook 地址复制不完整或机器人失效重新到群设置里复制完整 URL飞书机器人消息未显示开启了签名校验但请求体缺少签名按开放平台要求补充timestamp与sign飞书多维表格只拉到 100 条没有处理分页使用has_more和page_token循环读取消息能发出但格式错乱消息类型和内容结构不匹配钉钉用markdown飞书用text/post/interactive对应结构推送频率过高被限流忽略平台 QPS 限制增加退避重试控制发送频率必要时合并消息排查 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”这条完整链路。下一步可以继续深入的方向有WorkBuddy skill 设计把一个长任务拆成多个可复用的 skill例如“读取链接生成摘要”“读取飞书多维表格生成周报”“定时触发并推送到钉钉群”。n8n 复杂流程编排把 Webhook、AI 摘要、钉钉通知、飞书多维表格写入串联成一个可视化工作流支持定时触发和事件触发。钉钉/飞书免登录集成如果你在开发 Web 系统可以研究钉钉扫码登录、飞书授权登录的 OAuth 流程把内部系统和企业身份体系打通。Jenkins 通知飞书在 CI/CD 流水线中增加飞书机器人通知构建失败或发布成功时自动推送结果。自建一个轻量 Agent如果你不想依赖第三方 Agent 工具可以基于大模型 API 和 Python 写一个最小实现把链接读取、内容摘要、Webhook 推送合并到一个脚本里。这类方向的价值不只是“少点几次按钮”而是把重复性工作从人的日程里解放出来。真正值得关注的也不再是某个工具是不是下一个“超级入口”而是你的系统能不能快速接入这些能力让数据在 Agent、协作平台和业务系统之间高效流转。如果你正打算在公司内部落地类似方案建议先从一条群消息通知的自动化开始试水再逐步扩展到多维表格读取、报表生成、审批触发等更高价值的场景。