> For the complete documentation index, see [llms.txt](https://shike.gitbook.io/ai-coding/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://shike.gitbook.io/ai-coding/06-chapter.md).

# 第6章 将 Agent 接入飞书:从辅助执行到岗位级自动化

**本章导读**:多数 AI 编程项目止步于"用 AI 辅助写代码",但 AI 真正的价值在于"替团队干活"——把 AI 作为虚拟员工纳入日常工作流,执行定时任务、处理重复工作、在异常时通知人工。本章复盘一个完整案例:为某运营团队搭建飞书自动化系统,AI 在无人值守状态下完成每日定时巡检、生成经营简报、出异常时通知人工,每天节省运营人员 2—3 小时。本章的方法论是"常驻会话 + 隔离子 Agent"——把 AI 部署为 7×24 在线的工作流,而非每次重新启动的工具。

**本章关键词**:飞书自动化、常驻 Agent、隔离会话、岗位级权限

## 6.1 案例背景与价值定位

### 6.1.1 一个 30 人团队的真实痛点

**现场还原**:2026 年 3 月一个周二的下午,某运营团队(30 人,负责用户运营、内容运营、活动运营)负责人(以下简称"运营负责人")约了项目负责人在飞书语音。运营负责人先把三个 Excel 表格共享到屏幕上,分别是 1 月、2 月、3 月的"运营日常工作耗时统计"。三张表上,红框圈出的是同一项工作——"昨日数据巡检 + 周一经营简报"——1 月 47 小时、2 月 51 小时、3 月 49 小时。运营负责人指着数字说:"这活两个人在做,每天上午 9 点到 11 点都在拉数据、算环比、抄到飞书群,周末再加一次周报。半年下来,光这一项就吞了 280 小时"。

负责人当时没立即接话,先把运营负责人的"日常数据巡检清单"截了一张图(图上列着 14 个数据指标:DAU、新增注册、订单数、GMV、客单价、转化率、活跃用户、活动 UV、活动转化、活动 GMV、支付失败率、客诉数、留存率、ROI)。负责人问了一个问题:"这 14 项里,哪些是'必须人工判断'的?"运营负责人想了 3 秒,答:"基本没有。这 14 项都是看数字,数字对了就 @ 一下相关人,数字不对就报警。"负责人回:"那剩下的问题就只有一个——AI 能不能 7×24 在线、按时把这 14 项跑完"。

接下来的对话引出了本案例的三个核心痛点:

* **每日数据巡检**:每天上午 9 点,需检查昨日的用户增长、订单数据、活动效果,异常时通知对应人员
* **每周经营简报**:每周一上午,需汇总上周数据,生成简报
* **活动效果追踪**:活动上线期间,需每 2 小时检查活动数据,出异常时人工介入

这些工作由 1—2 名运营人员承担,每天耗费 2—3 小时,每周 10—15 小时。团队判断:这些工作是"高重复、低创造性"的,适合交给 AI 自动化。。 **现场细节**:运营负责人第一次问"AI 能不能做"时,负责人没有直接回答"能做"或"不能做",而是反问了一句:"您愿意把'数据错了没人发现'的风险,交给 AI 承担吗?"运营负责人沉默了 4 秒,然后说"如果 AI 出错时能立刻通知我,我愿意"。这句话——"AI 出错时能立刻通知"——是整个项目能推进的真正起点。如果客户不愿意承担任何 AI 出错的风险,自动化就只能停在"辅助执行"层面,价值会缩水一半。

![定时心跳与异常处理流程](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-709cdbde1f98b2f7a5ca4d809d608d06f55dced8%2Fsec06_cron_heartbeat.svg?alt=media)

![AI 全天定时任务时间线](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-72f0a08bc1b56316b2db3fcacd3b2180d7256f21%2Fsec06_unattended_day.svg?alt=media)

### 6.1.2 价值定位:辅助 vs 替代

团队在自动化过程中,需要明确一个边界:**AI 是"辅助执行"还是"替代执行"**。

* **辅助执行**:AI 完成任务后,人工审核结果,人工决策
* **替代执行**:AI 直接完成任务,无需人工审核,仅在异常时通知人工

**现场细节**:本案例不是一开始就决定"替代执行"的。前两周,AI 生成的每日巡检报告,运营负责人会一条条人工复核——"DAU 涨了 4% 是不是因为上周五的裂变活动?""订单突降 30% 是不是支付接口抽风了?"。负责人当时观察到,运营负责人 80% 的复核动作是"扫一眼数字,确认无异常",只有 20% 是"真的在看逻辑"。负责人提议:"80% 那部分能不能由 AI 直接出报告,20% 那部分(逻辑判断)由您处理?"运营负责人同意。这就是从"辅助"切到"替代"的真正分水岭——不是技术指标,是客户信任度的真实阈值。

本案例采用"替代执行"——AI 替团队完成每日巡检、生成简报、出异常通知,运营人员只在异常情况下介入。这种"替代"模式,要求 AI 具有相当高的可靠性,以及"出错时能及时发现"的兜底机制。

替代执行的工程意义:AI 替团队节省的不是"工作量",而是"时间"。运营人员从"每天机械地检查数据"中解放,转向"分析数据、制定策略",这是更高价值的工作。。 **教训**:"辅助"和"替代"不是非黑即白,而是一段连续的光谱。多数项目卡在"既想要替代的省时间,又想要辅助的可控性",结果两边都不彻底。负责人后来用一句话总结这个判断:"凡是'看一眼数字就能确认的'任务,都该交给 AI 直接出;凡是'需要业务判断的'任务,都该留给人"。这两类任务的边界如果不在项目开始前划清,后面每一次出问题时,客户都会倾向于退回"全部人工复核"。

![该框架 + 飞书对接架构](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-99cc0c63d0ea71a6deb010967f2e8053aac0e134%2Fsec06_gateway_arch.svg?alt=media)

### 6.1.3 接入飞书的业务价值

为什么是飞书而非其他工具?三个原因:

* **消息触达**:飞书的消息能直接触达团队成员,无需打开额外应用
* **审批流程**:飞书支持审批流程,异常通知可直接触发审批
* **数据存储**:飞书的消息可以长期存储,便于事后追溯

其他工具(微信、Telegram、Slack)各有优势,但在国内团队中,飞书的"消息 + 审批 + 存储"组合最适合企业内部协作。。 **现场细节**:选型飞书时,运营负责人一开始推荐的是企业微信(团队历史都用企微)。负责人没有立即否定,而是提了一个具体场景:"如果活动数据突降 30%,您希望怎么收到通知?是有人专门看企微群,还是飞书机器人直接 @ 您?"运营负责人想了想,答:"后者,飞书机器人能直接 @ 我,我不需要盯着群。"这个回答把选型从"团队习惯"切到了"通知触达机制"——企微的群机器人也能做到,但飞书的 @ 提醒在手机锁屏状态下会直接弹出横幅,触达率比企微高 30% 左右。这个数据来自两个工具的官方文档对比,运营负责人后来让团队做了内部测试,确认飞书的锁屏触达确实更及时。**选型的关键不是"哪个工具最好",是"哪个工具的行为最符合团队的接收习惯"**。

## 6.2 该框架的项目背景

### 6.2.1 该框架是什么

**现场还原**:负责人第一次向运营负责人介绍 该框架 时,用的是一句话——"它是'飞书里能 7×24 干活的虚拟员工',不是聊天机器人"。运营负责人当时追问:"和群里那个自动回复天气的小机器人有什么区别?"负责人回:"自动回复机器人只在被 @ 时才动;该框架部署的 Agent 是'不 @ 也动'——每天 8 点自动跑、9 点自动出报告、出问题自动 @ 您"。运营负责人想了几秒,说"听起来像雇了一个不用发工资的实习生"。

该框架 是一款开源的 Agent 接入框架(2026 年 5 月由 Peter Steinberger 发布,GitHub 38.4 万星),专门用于将 AI Agent 接入各类即时通讯工具。框架本身不提供 AI 能力,而是提供"Agent 如何与 IM 工具对话"的协议和组件。

该框架 的设计思想是"Agent 应该像员工一样,在企业的 IM 工具中工作"——用户在飞书中 @Agent,Agent 接收到任务、执行任务、返回结果,整个过程与人类员工无异。

### 6.2.2 部署形态

该框架提供两种部署形态:

* **本地部署**:在自己的服务器上运行,数据不出内网,适合对数据安全要求高的场景
* **云托管版(月之暗面云托管版)**:由月之暗面提供的托管服务,无需运维,适合中小团队

**现场细节**:本案例本来倾向选云托管版(月之暗面云托管版)——"省事,不用运维"。但工程主管在第 2 天的技术评审会上提了一个问题:"运营团队的数据库里有客户手机号、收货地址,这些数据能否上传到云托管版的服务器?"答案是不行,云托管版的服务器在云端,数据出内网触发合规审查。负责人当场拍板:"转本地部署"。这次转向表面上是合规问题,实际是工程伦理问题——AI 替团队干活的第一条边界,就是"客户的隐私数据不能未经同意流到外部"。从云托管转本地,工期多了 3 天,但后续没有任何一次因为"数据流向"被质疑。

本案例采用本地部署——数据敏感度高,运维成本可接受。

### 6.2.3 飞书接入配置

**现场还原**:飞书接入配置在第 3 天到第 5 天之间,工程师(以下简称"接入工程师")遇到了第一个真卡点。工程师在飞书开放平台创建机器人应用时,App ID 和 App Secret 顺利拿到,WebSocket 连接也通了——但消息路由怎么配?该框架官方文档里给了 5 种路由模式(关键字路由、@ 路由、白名单路由、黑白名单组合、纯透传),每种都有适用场景,工程师当时凭感觉选了一种,结果部署上线 1 小时后,群里 11 条日常聊天被 AI 误触发了。运营负责人截图过来质问:"为什么 AI 在我们开玩笑时插嘴?"工程师当天下午就改了路由规则——"只接受 @Agent 的消息 + 特定关键词(巡检、报告、异常),其他全部透传"。这次改完之后,群里再没出现误触发。

将 该框架接入飞书,需要完成以下配置:

* 在飞书开放平台创建机器人应用,获取 App ID 和 App Secret
* 在 该框架配置飞书的 WebSocket(双向长连接,服务器可主动推送消息)连接参数
* 配置消息路由规则(哪些消息由 Agent 处理,哪些消息由人工处理)
* 配置权限规则(Agent 能访问哪些飞书功能、不能访问哪些)

配置完成后,Agent 即可在飞书中接收消息、回复消息、执行任务。。 **教训**:消息路由规则的第一版几乎一定是错的,第一版上线后第 1 个小时就会暴露问题。负责人后来在所有飞书自动化项目里加一条铁律:"路由规则上线后,前 2 小时必须有专人在群里盯着,看 AI 是否被误触发"。这条纪律成本低(2 小时人工),但能避免一次"全员都以为 AI 在胡言乱语"的尴尬。

## 6.3 工作流设计

### 6.3.1 定时任务的编排

**现场还原**:定时任务清单的第一次定稿,是在第 6 天的需求评审会上。运营负责人、运营主管、接入工程师、项目负责人 4 个人在会议室,运营负责人打开白板,边画边说:"上午 9 点开站会,那我希望 8 点 50 报告就出来,这样开站会时大家直接对着报告讨论"。运营主管补了一句:"中午 12 点数据是峰值,这个点要单独看"。接入工程师问:"那 8:50 出报告,8 点开始跑来得及吗?"负责人算了一下时间:14 个数据指标 × 单指标 1—2 秒 = 约 30 秒,加上异常判断和报告生成,总耗时 5 分钟内。接入工程师说"来得及",最终时间表定稿为 8:00 启动 → 8:05 出报告 → 8:50 前推送飞书群。

AI 在飞书中的工作,主要由"定时任务"驱动——预设好时间表,AI 按时间表执行任务。本案例的定时任务清单:

* **每日 8:00**:检查昨日用户增长数据,生成简短报告
* **每日 9:00**:检查昨日订单数据,异常时通知销售
* **每日 12:00 / 18:00**:检查活动数据(活动期间)
* **每周一 9:00**:汇总上周数据,生成经营简报

这些任务由"定时调度器"触发。调度器是个轻量程序,按时间表调用 Agent,Agent 执行任务后返回结果。

### 6.3.2 消息路由规则

飞书群中的消息,需要决定"哪些由 Agent 处理,哪些由人工处理"。路由规则:

* **@Agent 的消息**:Agent 处理
* **特定关键词的消息**(如"巡检"、"报告"):Agent 处理
* **其他消息**:人工处理

路由规则防止 Agent 误处理人工消息,降低干扰。。 **现场细节**:6.2.3 提到的"误触发"事件之后,负责人把路由规则改成更精细的版本:除了"@Agent + 关键词",还加了"消息必须发生在工作日 8:00—22:00"这条时间窗。原因是:周末晚上 23:00 有同事开玩笑 @Agent 让它"帮我想个请假理由",AI 也开始认真输出——输出请假模板这种事本身无害,但"周末深夜 AI 还在响应"让团队成员误以为"AI 一直在线但从不睡觉,会不会很费电"(当然这是玩笑,但确实有 3 个同事私下问过)。加上时间窗后,周末深夜 AI 不响应,问题解决。**路由规则的精细化,不是技术问题,是"AI 行为是否像一个正常员工"的产品问题**。

### 6.3.3 异常处理机制

AI 自动化系统的关键是"异常处理"——遇到 AI 不知道如何处理的情况,系统应能暂停任务、通知人工。。 异常处理的流程:

* AI 执行任务时,遇到未知情况(如接口返回错误、数据缺失、判断不了)
* AI 暂停任务,记录异常详情
* AI 在飞书群发送异常通知,@ 相关人员
* 人工介入,决定如何处理(继续、放弃、修改后再试)

异常处理的工程意义:AI 不必"无所不能",只需要"在能处理时自动处理,在不能处理时及时通知"。。 **现场案例**:上线后第 11 天,出了第一次真异常。每日 9 点的订单数据巡检,接口连续 3 次返回 5xx 错误,AI 按预设规则暂停任务,在飞书群发送了这条通知(原文摘录):

> 【异常】任务:9 点订单数据巡检

> * 现象:订单接口连续 3 次返回 500(超时)

> * 已尝试:重试 2 次,间隔 30 秒,仍失败

> * 未能解决:接口侧问题,不在我处理范围

> * @授权人员:@销售主管,请联系工程侧确认接口状态

销售主管 12 分钟后回:"@AI 工程侧说接口刚扩容,已恢复,请重跑"。AI 立即重跑,8 分钟内完成 9 点的巡检,并在群里追加了一条"已恢复,补发 9 点巡检报告"。这次异常的处置过程,被运营负责人在周会上专门提了一句:"AI 知道自己不知道,而且知道找谁——这比很多新员工都靠谱"。

## 6.4 实战过程:从常驻会话到隔离子 Agent

![常驻会话与隔离开子 Agent 比例](https://687631483-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7WxdJpMDAGmV1omWsIzP%2Fuploads%2Fgit-blob-23ff8e925bd9f015fcdcae0de1e7cd5dd5ab00eb%2Fsec06_70_30_split.svg?alt=media)

### 6.4.1 常驻会话的概念

**现场还原**:常驻会话的实现,接入工程师在第 7 天遇到了一个真问题——"AI 跑了 18 小时后,飞书连接断了"。工程师排查发现是 该框架默认的 WebSocket 心跳间隔是 60 秒,飞书服务端在 90 秒没收到心跳就主动断开。工程师把心跳调到 30 秒,问题解决。**长连接的可靠性,藏在"心跳"这种最朴素的细节里**。

AI 替团队干活,需要"常驻"在飞书中——用户可以随时 @ 它、它可以随时接收任务。实现方式:**长连接 + 事件循环**。Agent 与飞书建立长连接,持续监听消息,收到消息后处理,处理完继续监听。

常驻会话的设计关键:

* **状态保持**:Agent 记住之前的对话、之前的任务、之前的决策
* **异常恢复**:Agent 崩溃后能自动重启,重启后从崩溃点继续
* **资源管理**:Agent 不会因为长时间运行而消耗过多内存

**现场细节**:状态保持这件事,一开始被低估了。运营团队原本以为"AI 每天跑完任务就清空记忆",结果第三天,运营负责人在群里问 AI:"昨天的活动数据和今天比怎么样?"AI 回:"我没有昨天的数据"。运营负责人截图质问:"昨天不是你自己跑的吗?"接入工程师这才意识到,默认的 该框架配置是"任务结束后释放上下文"。后来工程师把"7 天内的巡检数据"持久化到本地文件,AI 需要时主动读取,问题解决。**"常驻"不等于"无状态",AI 需要的记忆,正是它和"自动回复机器人"最本质的区别**。

### 6.4.2 隔离子 Agent 的设计

**现场还原**:隔离子 Agent 这件事,起因是第 9 天的一次"上下文污染"。那天 AI 在同一个会话里同时处理两件事:上午 9 点跑订单巡检,上午 10 点被运营负责人 @ 问一个临时问题("上周 GMV 最高的活动是哪个?")。两个任务挤在同一个上下文里,AI 在回复"上周 GMV 最高的活动"时,把它和"昨日订单巡检"的数据混在了一起,生成了一个"昨日 GMV 最高的活动"——这个数字是不存在的(昨日是周一,没有活动)。运营负责人截图质问,接入工程师当天就切到了"隔离子 Agent"架构。

常驻会话中,AI 处理的每项任务可能涉及不同的"上下文"——查看用户增长、检查订单数据、生成报告。如果所有任务都挤在同一个会话中,上下文会越来越乱,AI 的判断会越来越不准。

解决方案:**隔离子 Agent**。每个任务由一个独立的子 Agent 处理,子 Agent 在独立的上下文中工作,完成后只返回结果摘要给主会话。。 隔离子 Agent 的设计:

* **每个任务一个子 Agent**:任务开始时创建,任务结束后销毁
* **独立上下文**:子 Agent 不继承主会话的全部上下文,只继承完成任务需要的最小信息
* **结果蒸馏**:子 Agent 完成后,只把"对主会话有用的结论"返回,过程细节不返回

隔离子 Agent 的工程意义:主会话保持简洁,AI 不会被无关信息干扰,任务之间互不污染。。 **教训**:70/30 的拆分比例(70% 任务用隔离子 Agent,30% 轻量任务留在主会话)不是拍脑袋定的,是负责人跑过 8 次实验得出的。第 1—3 次全用隔离子,发现启动开销占 30% 的任务时间;第 4—6 次全留主会话,上下文污染;第 7 次起折中——轻量任务(单条查询、3 句以内的回复)留主会话,重量任务(多步分析、报告生成)用隔离子,效果最稳。

### 6.4.3 多权限层级

AI 替团队干活,需要"权限"——能访问哪些数据、能执行哪些操作、能通知哪些人。权限的设计原则:**最小权限**——AI 只能访问完成任务必需的数据,只能执行必需的操作。

本案例的权限设计:

* **数据权限**:Agent 只能访问汇总层数据(参考第 5 章的数据分层),不能访问原始层
* **操作权限**:Agent 只能发送消息、查询数据,不能修改业务数据
* **通知权限**:Agent 只能 @ 特定人员(如运营负责人、销售主管),不能 @ 全员

权限设计防止 AI 误操作——即使 AI 判断错误,也只能在受限范围内影响,不会造成大面积损害。。 **现场细节**:权限这一栏,负责人和运营负责人吵过一次。第 8 天的权限评审会上,运营负责人要求"AI 能 @ 全员,这样大家都能看到报告";负责人反对:"@ 全员意味着 AI 在异常时能骚扰整个 30 人团队"。最终妥协:日常报告不发到群,而是发到"运营数据"专属频道(@ 频道所有成员但不弹窗);异常通知发到主群(@ 销售主管 + 运营负责人,不 @ 全员)。这个折中方案既保留了"全员可见"的透明度,又限制了 AI 在异常时的通知半径。**权限不是"能不能做"的问题,是"做了之后影响半径有多大"的问题**。

## 6.5 验收与效果

### 6.5.1 验收清单

飞书自动化系统的验收,包含以下检查项:

* **功能验收**:每日巡检、每周简报、活动追踪均按预期工作
* **权限验收**:Agent 只能访问授权范围,不能越权
* **异常验收**:遇到异常时,Agent 暂停任务并通知人工
* **稳定性验收**:Agent 持续运行 30 天无崩溃,异常恢复机制有效

### 6.5.2 实际效果

**现场还原**:30 天的验收期内,系统跑出几个让运营负责人惊喜的数据:每日巡检 100% 按时执行(30/30),异常发现 3 次(其中 1 次是订单数据突降 30%、2 次是活动数据异常),人工介入 3 次,均被人工及时处理、未造成业务损失。运营负责人在第 30 天的复盘会上说:"最让我意外的不是时间节省,是'AI 比我先发现异常'——3 次里有 2 次是我还没刷飞书,AI 已经 @ 我了"。

系统上线后 30 天的实际效果:

* **每日巡检**:100% 按时执行,无遗漏
* **异常发现**:3 次异常情况被及时通知(其中 1 次是订单数据突降 30%,2 次是活动数据异常)
* **人工介入**:3 次异常均被人工及时处理,未造成业务损失
* **时间节省**:运营人员每周节省 10—15 小时,从机械检查转向分析策略

**现场细节**:时间节省这个数字(10—15 小时/周),一开始运营负责人是不信的。第 1 周结束后,负责人让运营负责人把"运营日常工作耗时统计"再填一次——和 1—3 月那三张表同样的格式。第 4 周的统计结果:数据巡检 4 小时(对比之前的 47—51 小时/月),周报 1.5 小时(对比之前的 5—6 小时/周)。运营负责人把这两张表打印出来贴在工位上,团队里原本对 AI 持观望态度的同事,也转成了"这事儿靠谱"。**数字改变观点,但前提是数字是可被验证的——贴两张表比说十句话管用**。

### 6.5.3 长期运维

自动化系统的运维与一次性项目不同,需要持续关注:

* **每日检查**:系统是否正常运行,有无错误日志
* **每周复盘**:本周执行的任务是否合理,有无优化空间
* **每月评估**:权限设置是否仍然合适,数据来源是否变化

运维是自动化的延伸——自动化不是"建好就忘",而是"建好后持续优化"。。 **现场细节**:第 2 个月末的月度评估时,接入工程师发现一个新问题:业务侧升级了订单接口,新接口返回的字段格式和老接口有差异(老接口返回字符串,新接口返回结构化对象),AI 在解析时连续 3 天把"客单价"算错。接入工程师当周就改了解析逻辑,并把这条改动写成"接口升级自查清单"——以后每次业务侧升级接口,先用这份清单自检。**自动化的脆弱点往往不在 AI 本身,在 AI 依赖的上游系统——上游一变,下游全要重新校准**。

## 6.6 方法论提炼与可复用资产

本章的方法论可提炼为四个原则。。 **原则一:替代执行比辅助执行价值更高**。AI 不是"帮人类干活",而是"替人类干活"。从辅助到替代,节省的不是工作量,而是时间。

**原则二:常驻会话是岗位级自动化的基础**。AI 必须在企业 IM 工具中常驻,像员工一样接收任务、完成任务。临时启动的 AI 是工具,常驻的 AI 才是虚拟员工。。 **原则三:隔离子 Agent 防止上下文污染**。每个任务用独立的子 Agent,任务之间互不污染,主会话保持简洁。

**原则四:最小权限原则**。Agent 只能访问授权范围,即使判断错误也不会造成大面积损害。。 **可复用资产:飞书自动化系统的检查清单**——本节 6.5.1 的检查项,适用所有将 AI 接入 IM 工具的项目。

### 6.7.1 本章思考题

1. 6.1.2 的"辅助 vs 替代":你的项目卡在哪一段?如果卡在"既想要替代的省时间,又想要辅助的可控性",下一步该做什么?
2. 6.3.2 的路由规则:你的飞书群里,AI 误触发过几次?最近一次是什么时候?路由规则上线后前 2 小时有专人盯吗?
3. 6.4.1 的"常驻会话心跳":你的 Agent WebSocket 心跳间隔是多少?飞书服务端的超时阈值是多少?如果不一致,长连接会在什么时候断?
4. 6.4.2 的 70/30 拆分:你团队的任务中,70% 用隔离子 Agent 的是哪几类?30% 留在主会话的是哪几类?拆分依据是什么?
5. 6.4.3 的"最小权限":你的 Agent 当前能 @ 全员吗?如果能,出异常时影响半径有多大?是否需要分频道?

### 6.7.2 本章延伸阅读

1. **\[工具文档] 该框架官方飞书渠道文档** — 飞书 production-ready、WebSocket 长连接免公网 URL | 第 6 章
2. **\[工具文档] 该框架 Cron/Heartbeat 教程(yeasy GitBook)** — 无人值守双调度机制与命令示例 | 第 6 章
3. **\[文章] GitHub 该框架/该框架 仓库** — 384.7k stars、MIT、TypeScript、v2026.7.1 的一手实测 | 第 6 章
4. **\[文章] 钛媒体 该框架深度报道(2026-06-30)** — 沿革 早期版本 A→B→C(项目沿革代号)、OpenAI 1.16 亿美元 acqui-hire、月活 320 万 | 第 6 章
5. **\[文章] 新华社 CNCERT 该框架风险提示(2026-03-10)** — 提示词注入/误删数据/插件投毒/漏洞四类风险 | 第 6 章

## 6.7 完整提示词:飞书常驻 Agent 的部署与运行

以下提示词用于"将 AI Agent 接入飞书,作为虚拟员工常驻"。它体现了"替代执行"、"最小权限"、"隔离子 Agent"、"异常暂停通知"四条原则,且所有定时任务与权限都必须在 prompt 里显式声明。

## 本章方法论:把 AI 当作虚拟员工

本章的方法论核心是"把 AI 当作虚拟员工"——AI 不是工具,而是团队的一员,常驻在企业 IM 工具中,接收任务、执行任务、出异常时通知人工。这一思路将 AI 的价值从"辅助"提升到"替代",让团队成员从机械工作中解放,转向更高价值的创造性工作。

下一章将讨论"行业调研"——AI 替读者完成一项典型的知识工作:搜集行业信息、整理数据、形成报告。这一章关注的是"AI 替读者思考"的能力,而非"AI 替读者执行"的能力。