用飞书+豆包搭建自进化信源Agent：10分钟手搓Loop

Loop Engineering 让 Agent 在运行中自我迭代。借助飞书、豆包联动，十来分钟搓出一套自进化信源 Loop：自动收集群聊批注与日报反馈，校准监控清单与呈现，把重复工作流交给会进化的 Agent。

你想让自己的 Agent 工作流，每天自动迭代吗？

是否发现用了一段时间的 Workflow、Skill，就会和实际需求脱节？

今天，我们来聊「如何给自己搭一套自进化的 Agent 系统」。ㅤ

Loop Engineering 这个概念，火了一段时间。

核心理念是“不用反复提示 Agent，让 Agent 在运行中，具备「积累反馈验证信号-自我改进」的循环能力”。

概念是真好，但因为落地复杂度，大多数朋友的实践还集中在 Coding 场景，远不及 Agent Skill “飞入寻常人家”的热度。

然，随着 Agent 产品普及、DS Flash 级的高性价比算力出现。

搓一套「在日常使用中，自动收集反馈信号进化的 Agent Loop」已不再难事，使用场景也足够广阔：

1）小到一套可自动改进的信源订阅系统，替自己每天推送更感兴趣的信息：

Agent 在 Loop 中，无需人为迭代，自动收集群聊讨论、日报批注 → 按需增减监控信源 → 迭代日报呈现

2）大到一整个组织，业务数据指标异动，Agent 自己翻项目版本文档、会议纪要、群聊内容，给出归因报告。

业务的每一条反馈批注，都会校准它下一次归因策略，报告越给越准。

这些都是 Loop Engineering 理念在日常办公中的实践。

只不过日常任务中，“什么是最好的成果”没有唯一答案。人类在正常工作中留下的批注、群聊讨论与使用反馈，是 Agent 自然的评价信号。

Agent in the loop， context is everything.

借着飞书、豆包工作的上下文联动能力，本文将从「10 分钟手搓信源 Loop 系统」入手，包含：

• 手把手教你搭一套自进化 Agent 系统，全流程照抄就能跑
• 设计个人 Agent Loop 的思路，可以试用在你任何重复做的工作流上
• 识别 Agent 工具能力边界的方式，方便判断选什么工具、能搭多大的 Loop

兼顾「只想上手即用」、「想了解 Context、Loop 理念」的朋友阅读。ㅤ

首先，Context 和 Loop 是什么关系？

不需要看原理的，可以直接滑到后面，有手把手教程，能直接跟做。

本节讲得比较通俗，已经剪掉了过于复杂且非开发场景用不上的部分。

Context 即上下文，一个很宽泛的概念。

从日常发给 AI 的消息，再到 Agent 运行时读取的文档、Skill、Memory.md 等长期记忆，以及 AI 产品背后的 System Instruction、Tool Description。

它们都算 context。在 Agent 运行时被拼成长长的上下文，也决定了 Agent 在接到任务消息时的回应。

Loop 是 Agent 的不断循环。

在自改进循环的系统中，Agent 自动进行循环，把上一轮积累的反馈信号写回 Loop。

或以长期记忆回流 Context，或直接调优代码程序，目的都在于让下一轮 Loop 得到更优的结果。

聪明如你，不难发现：

Agent 整个运行过程中，多数人容易管理的部分，正是 「任务过程消息 → 沉淀长期记忆，如 Skill、Memory、运行时必读文档」 这一环。

（让我们姑且称这类只涉及 Context 循环优化的循环为 Context Loop）

想让依赖人类自然反馈的 Context Loop 真正跑顺，则需要同时满足三个条件：

• 人能完全顺手地留下反馈的痕迹：比如发消息、写批注、回邮件
• Agent 有足够的工具权限，看到这些反馈痕迹
• Agent 能够自主编辑长期记忆，也方便人类共同编辑ㅤ

如何设计 Loop 架构？

在设计 Agent 工作流程前，让我们先设定最重要的几个体验预期。

比如，作为示例的这套信源 Loop 系统，我希望它是这样的：

• 每天定时运行，按照预定的信源偏好，总结成日报，通过群聊直接推送到我面前
• 在阅读时，人类用户随手在日报里的批注、或在群里的反馈与话题讨论，都能自然作为反馈信号，改进下一轮 Loop 质量（因为足够自然，面向整个组织时，也不用改造这个信号反馈流程）
• 增加信源需求时，无需人为介入，Agent 自行找出新信息的采集方案

有了需求预期，才能去选能实现的工具组合。

本文选择了用豆包工作来做 Case 示范，它与飞书的衔接度超出预期：ㅤ

同一个账号，无需任何配置，直接能读到飞书的聊天消息、多维表格、文档甚至批注，也能代发与编辑。

整合了 Codex 备受好评的远程操控功能，方便远程管理 Agent

确定了体验预期与工具后，信源 Loop 系统的架构就清晰了：

• 1.飞书多维表格负责记录需求任务、信息采集入口；知识库文档负责同时承载日报模板、个性化精选规则，以及日报内容与反馈沉淀，是非常方便的 人-AI 实时数据写作面。
• 2.豆包工作内置的 Search、Fetch、本地运行脚本、Browser Use 共同负责信源采集（这个 Browser Use 好用的，和 Codex 体验接近）
• 3.整体由豆包工作的 Agent 执行，定时器触发，一个专门的 Skill 统合任务执行流程

你当然也能选自己喜欢的 AI 产品，不过就需要你自己按每个步骤调试了。

0⃣ 前置操作

先下载「豆包工作」、「飞书」，这就不说了

建议你在豆包工作的左侧导航栏中，创建一个干净的项目文件夹

然后模型档位，我在实操过程中，全程选择「自动、中等推理」，体感够用了。省点 token，加速执行。

顺便解释一下：

• ㅤ设置项目文件夹的原因：后续若有需要本地脚本采集方案的信源，对应的程序脚本，均可在此处统一管理。
• ㅤ选择本地电脑，而不是云电脑的原因：因为必然有部分网页信源，需要 Browser Use 才能采集，豆包工作本地电脑的浏览器自动化效果很不错。

1⃣ 让 AI 创建监测任务表

从这一步开始，你开始正式打造自己的信源 Loop 系统了。

发送以下 Prompt 给到豆包工作，创建用于监测任务的两张表：

• 监测任务：维护用户的监测需求
• 信息入口：按监控对象，如「OpenAI、DeepSeek」，维护其相关信源渠道

…

我想搭建一套会随着使用和反馈逐渐变准的精选信源系统。以后，用户只需要说自己想持续关注什么，Agent 就会把需求拆清楚，找到合适的信息入口，确认可行的采集方式，再定期生成日报。并且可通过用户反馈，每日更新信源精选规则，不断优化 Agent 信源精选的准确度。

现在，你的第一个任务是创建一个飞书多维表格“信源管理系统”，在里面建立两张数据表，作为后续运行的地基之一。

第一张叫“监测任务”，每一行是一条可以独立新增、修改或暂停的需求，字段为：

– 需求条目：主字段，单行文本；用来识别一条最小、可独立维护的需求

– 监测对象：单选；用来汇总同一对象下的需求，也是后续分配 subagent 时的筛选依据

– 监测要求：多行文本；说明具体想关注哪些变化，以后出现明确误判时也在这里补充必要边界

– 证据边界：多行文本；说明什么来源或证据足以确认这条信息

– 状态：单选，选项为“启用”“暂停”；决定当前是否执行这条需求

示例：需求条目为“模型发布”，监测对象为“OpenAI”，监测要求为“关注新模型、重要版本升级及模型上线或下线”，证据边界为“以 OpenAI 官方公告、文档或官方账号为准”，状态为“启用”。

第二张叫“信息入口”，每一行是一个可以独立检查的具体入口，字段为：

– 入口名称：主字段，单行文本；用来识别一个具体的信息入口

– 监测对象：单选；用来把入口归到对应对象，让 subagent 能与监测任务一起筛选

– 入口地址：链接；保存实际访问位置

– 渠道定位：单行文本；说明这个入口主要提供什么信号，例如正式公告、开发者更新、实时动态或招聘信号

– 采集方式：单行文本；记录当前确认可行的主要采集路线，例如结构化接口、脚本或 Browser Use，不在这里展开完整操作步骤

– 状态：单选，选项为“待验证”“启用”“暂停”“失效”；表示这个入口当前是否可投入运行

– 上次成功检查时间：日期时间；作为下一轮查找新增内容的时间起点，只有检查成功后才更新

示例：入口名称为“OpenAI 官方动态”，监测对象为“OpenAI”，入口地址为其官方 News 页面，渠道定位为“正式公告”，采集方式为“Browser Use 读取更新列表”，状态为“启用”，上次成功检查时间为最近一次成功运行的时间。这个示例只用于说明字段含义，实际入口和采集方式需要后续验证。

两张表共用“监测对象”作为筛选和分组依据，不需要另外创建监测对象表。默认视图都按“监测对象”分组；再为信息入口建立一个“待验证”视图。

完成后把表格链接发给我，并告诉我最终创建的字段和视图。

这一步只创建空表，不添加正式需求和入口，也不创建日报、Skill 或定时任务。

注意：现在用 Agent 时，其实用不着这么长的 Prompt，而且实际上也很难在复杂系统设计伊始，就给出如此完备的提示。往往是通过跟 AI 多轮交流，慢慢打磨出需要的结果。

该 Prompt 也是我在实验过程中递归整理的完整提示，方便读者直接“抄作业”。

Agent 所创建的飞书文档、表格，都归属在同一账号的飞书里

所以方便你和 Agent 一起查看任务结果。打开后你能看到这样的多维表，这就是我们监测任务的长期 Context 规则了 。

ㅤ

2⃣ 按对象生成监测需求、采集方法

搞定监测任务的数据载体后，就可以向 Agent 提出自己的「信源监测需求」，让它帮你拆成持久化的任务要求入库了。

在原对话输入以下 Prompt，AI 就会自动拆解需求条目，确定信源获取渠道：

…

接下来请帮我把新的监测需求加入“信源管理系统”。

请先读取其中的“监测任务”和“信息入口”两张表，理解字段和已有记录，然后问我：你想持续监测什么？

收到回答后，请直接完成这件事：

– 理解其中的监测对象和监测主题。监测任务表的一行，表示某个对象下面一项可以独立维护的主题；例如“OpenAI 的模型更新”是一项监测需求，不需要继续拆成发布、升级、上线、下线等多行

– 按已经建立的字段新增或更新监测任务，避免产生重复记录

– 围绕这个监测对象寻找能够覆盖该主题的具体信息入口，优先复用已有入口；对新增入口实际验证是否可以访问，以及适合怎样自动获取更新，再写入信息入口表

验证采集方式时，请从轻到重逐级尝试，上一层能够稳定取得信息就停止：

1. 优先使用现成的结构化入口，例如连接器、RSS、API、GitHub Releases 或提交记录

2. 没有合适的结构化入口时，再尝试直接读取网页，或编写轻量脚本提取列表

3. 页面依赖动态交互、登录状态，或前两种方式无法稳定读取时，再使用 Browser Use

常见例子：GitHub 项目更新可以先检查 Releases 或 API；官方博客、更新日志和文档先检查是否提供 RSS 或其他结构化入口，没有再尝试直接读取页面或脚本；需要登录或高度依赖交互的网站，才考虑 Browser Use。这些只是判断示例，实际方案仍由你验证后决定。

验证不能只确认“网址能打开”。请实际取得最近的内容列表，并确认至少能识别标题、链接、发布时间或稳定 ID，以便以后判断增量。没有实际跑通的方案，不要写成已确定的采集方式；可以保留为“待验证”。

例如，我回答“我想持续监测 OpenAI 的模型更新”时，你可以这样理解和记录：

– 监测任务：需求条目为“模型更新”，监测对象为“OpenAI”，监测要求涵盖新模型、重要版本变化以及模型上线或下线，证据边界以 OpenAI 官方公告、文档或官方账号为准，状态为“启用”

– 信息入口：围绕 OpenAI 查找能够提供正式公告、开发者更新或实时动态的具体官方入口；例如先验证 OpenAI News RSS 是否能够稳定返回标题、链接和发布时间，再判断是否还需要其他入口补足覆盖。验证成功的状态设为“启用”，本次先不填写“上次成功检查时间”

这个示例只说明需求如何落到两张表。实际采用哪些入口、使用什么采集方式，由你访问和验证后决定。

除非存在会改变监测对象或主题的歧义，否则请自行判断并继续完成。最后告诉我你如何理解这次需求、写入了哪些监测任务、采用了哪些信息入口和采集方式。

这一步不启动定时任务，也不生成日报。

豆包工作会问你想要持续监测什么。

你按照你的需求，自然描述即可，“帮我监测 OpenAI 的模型、产品更新，以及 Codex 重置预告”。（不用紧张，不用深呼吸，简单说需求就好了，现在的豆包工作还挺聪明的）

输入后，无需其他操作，即可看到如下变化：

1）监测任务表中，以「OpenAI」为监测对象，拆分出了 3 条 MECE 的任务需求

2）信息入口表中，在 Agent 长程自动化采集实验后，登记了相关信息来源及采集方式

如果你有更偏好的信息入口与采集方式，也可以让 Agent 给你更换，直接和 Agent 说就好（不是说 Agent 给你选了 Browser Use 策略，你就必须用这个，可以像乐高积木一样随意局部拼接）：

豆包工作会对你提供的渠道进行验证后，并更新信源表内容：

• 需求表：
• 信源入口表：

附： 根据信源入口、采集方法不同，有时会受到网站登录限制，Agent 可能会需要你配合，帮忙在浏览器工具中登录，或者需要你授权对新信源验证，根据 AI 指示继续就行。

3⃣ 建立日报规则，跑出第一份日报

Agent 工作流往往由大量环节组成，又因为模型生成的不确定性，需要做一点测一点，不然积成山，积重难改。

所以完善了采集方案后，别加太多信源需求，尽快先验证整套系统的最小闭环：根据信源管理多维表，根据日报生成规则，自动采集信息更新日报内容。

发送给 Agent 以下指令：

…

请创建一个飞书知识库“信源 Loop 系统”，作为这套系统长期文档的统一入口。

目前只建立以下结构：

1. 知识库首页

用于长期维护整套系统的说明和文档索引，包括：这套系统解决什么问题、目前怎样运行；已有组成部分分别负责什么；指向各项正式资产的入口

当前先在首页登记：

– “信源管理系统”多维表格：维护监测任务和信息入口

– “每日日报”目录：归档系统每天生成的日报

以后新增日报规则、反馈日志或 Research Map 等正式文档时，再把它们补进首页索引。

2. “日报规则”文档

包含以下章节：使用材料索引、信息筛选规则、日报模板

在“使用材料”中放入“信源管理系统”多维表格的直接链接，并注明：“监测任务”表决定需要关注什么，“信息入口”表决定去哪里获取。

3. “每日日报”目录

作为独立目录使用。以后每天生成一份以日期命名的日报，并统一放在该目录下级子文档。

现在不要提前创建其他尚未实际使用的目录或文档。完成后把知识库链接发给我。

ㅤ

豆包工作将自动创建知识库：

它会按要求填充 3 个核心文档，为后续 Agent 行动提供上下文指引：

接下来，让 Agent 先抓出一份日报看看效果：

经过持续一段时间的长程任务执行，就能得到 Agent 给出的日报结果

日报内容对应本周发生的事件（8.31-9.1），呈现在每日日报目录下

——信源日报小闭环验证成功 ：

附：如何调整 Agent 信源日报的格式？

如果你对日报格式有自己的要求，可以让 Agent 帮你再做修改。

1）建议先直接让 Agent 尝试调整日报本身

很快能得到更加干净舒服的日报排版：

2）也记得让 Agent 帮你总结新的规则，固化在核心文档中，优化后续 Agent 任务行为

发完要求后，就在日报规则中，看到 Agent 的调整：

其实和要求 Agent 优化 Skill 的逻辑差不多，思路都是一致的：

每次任务会加载的上下文 = Agent 将遵循的任务指引，而 Agent.md、Skill、Prompt 都只是一种上下文的载体。

3）对了，由于云文档的人、AI 都可读的性质，实际上也是人-AI 的 Context 共同协作面，所以也可以自己上手直接编辑，改动在 Agent 按下次文档执行时自动生效。

除开这种主动修改的行为，后面 ⑤ 反馈 Loop 小节中，还会介绍更简单的、 Agent 自动根据群聊、批注的 Loop 改进方式。

4⃣ 设定时任务：日报每天自动出现在群里

验证日报生成链路后，信源系统就很容易维护了：

• 增删监控需求？直接和 Agent 说即可——它会自己改监测任务表，连信源入口和采集方式都会跟着验证、更新
• 想调整日报的格式与内容？也直接说，或者直接在云文档里改「日报规则」——下一轮它就按新规则出

至此，loop 的内容采集-生成层已经完整。

下一步则是让我们的日报能够每天定时推送。

而这就需要由定时任务 + Skill 机制，以及豆包工作与飞书的联动来完成。

1）自动生成每日信源 Skill，用于简化定时启动的 Prompt

直接在原任务对话的基础上发送要求：

…

接下来，我希望这套系统，能在每天早上 9 点，把当天日报自动推送到我的群里。

请先创建一个 Skill，届时我将结合定时任务，用于指导该任务的自动定时执行。

即可得到 每日信源 Skill 的初版骨架

AI 会提示你指定一个发送的群，随意选择都可以，如「一泽与豆包工作 Bot / 部门信源监控群」

豆包工作就会搜索到飞书内的该群 ID，更新 Skill 内容：

2）确定推送消息形态

由于飞书聊天支持文本消息、长文内联消息、交互式卡片，可选的呈现方式多样，最好提前规定推送形态。

我选了交互式卡片，直接和 AI 说“我需要推送消息以交互卡片形式呈现”即可，并要求其尝试推送今日信息作为示例

这也是识别 Agent 工具能力的方法之一

直接询问 Agent，让它自己读内置工具说明，告诉你它支持什么。有些时候可能有幻觉，所以必须要让Agent 先尝试一下，按结果来判断实际可行性。

最终实验出以下结果 ：

• ㅤ不过豆包工作目前在发飞书消息时，没有自己的 ID 身份，只能以你的账号代发。
• ㅤ当然也可以单独为豆包工作新建一个专属飞书账号，使得你可以把它以独立身份拉入各种群中。ㅤ

3）最后是创建定时任务，支持最小间隔 15 分钟，同样在原窗口发送：

自动完成定时任务的创建：

自此，每天 9 点，你都能自动收到豆包工作为你筛选的信源日报了～

到这里，这个系统其实已经每天能够把你的信源日报送到群里。