飞书豆包实操：搭建自进化Agent信源系统

你是否曾苦恼于自己搭建的Agent工作流渐渐和实际需求脱节？想要让你的智能代理系统能够随着使用自动迭代优化？本文将详细介绍如何搭建一套自进化的Agent系统，让智能代理能够自动收集反馈信号，不断改进自身的工作流程。

Agent in the loop, context is everything.

Loop Engineering的核心与应用场景

Loop Engineering作为智能代理领域的热门概念，其核心是让Agent在运行过程中自主积累反馈、验证并自我改进，无需人工反复调整提示。不过此前该概念的落地实践多集中在编程场景，热度不如通用的Agent Skill。如今随着Agent产品普及和高性价比算力的出现，搭建日常使用的自进化Agent Loop已经变得容易实现。

这类自进化系统的应用场景非常广泛：小到个人信源订阅工具，能够自动筛选推送你感兴趣的行业资讯；大到企业级的业务数据分析，当业务指标出现异动时，Agent可以自动查阅项目文档、会议纪要和群聊记录，生成归因报告，并根据每一条反馈批注不断优化后续的分析策略。

在日常任务中，“最优成果”并没有统一标准，人类在工作中留下的批注、群聊讨论和使用反馈，都是Agent自然的评价信号。

明确Context与Loop的关系

要理解自进化系统，首先需要明确Context和Loop的含义：Context即上下文，涵盖了Agent运行时读取的所有信息，包括文档、技能、长期记忆、系统提示等，这些内容会直接影响Agent的任务响应；而Loop则是Agent的自主循环过程，通过将上一轮的反馈信号更新到循环中，比如回流到长期记忆、调整代码程序，让下一轮的执行结果得到优化。我们可以将仅涉及Context循环优化的循环称为Context Loop。

要让依赖人类自然反馈的Context Loop顺利运行，需要满足三个基本条件：一是人类能够便捷地留下反馈痕迹，比如发送消息、添加批注、回复邮件等，操作门槛足够低；二是Agent具备足够的工具权限，能够获取这些反馈信息；三是Agent能够自主编辑长期记忆，同时也方便人类共同修改这些内容。

设计你的Agent Loop架构

在开始搭建具体的Agent工作流之前，我们需要先明确核心的体验预期。以信源Loop系统为例，我们希望它能够：

1. 每天定时运行，根据预设的偏好生成日报并推送至指定群组
2. 用户在阅读日报时的批注、群聊中的讨论都能作为自然的反馈信号，帮助系统优化下一轮的内容筛选
3. 当需要新增信源需求时，Agent能够自动找到合适的采集方案，无需人工介入

明确了需求后，我们可以选择通用的企业办公协作套件和智能代理工具，这类工具通常无需额外复杂配置，就能直接读取聊天记录、多维表格和文档，甚至支持批注的读取和代发编辑，同时还具备远程操控功能，方便管理Agent任务。

信源Loop系统的整体架构可以分为三个部分：

1. 使用多维表格记录需求任务和信息采集入口，知识库文档则承载日报模板、个性化规则以及日报内容和反馈的沉淀，作为人机协同的实时数据交互界面
2. 智能代理内置的搜索、脚本执行、浏览器自动化等功能负责信源的采集
3. 由智能代理的定时器和专门的技能统合整个任务执行流程

前置准备

首先需要准备好智能代理工具和配套的办公协作工具，建议在工具的导航栏中创建一个独立的项目文件夹，用于统一管理后续的信源采集脚本和相关任务。在模型档位的选择上，建议使用中等推理模式，既能保证效果又能节省token消耗，提升执行速度。

搭建监测与信源管理系统

第一步是创建用于管理监测任务的两张核心数据表：

1. 监测任务表：用于维护用户的具体监测需求，包含需求条目、监测对象、监测要求、证据边界和状态等字段，每条记录对应一个独立可维护的监测需求
2. 信息入口表：用于管理具体的信息来源渠道，包含入口名称、监测对象、入口地址、渠道定位、采集方式和状态等字段，每条记录对应一个可独立检查的信息源

你可以通过向智能代理发送完整的提示词来快速创建这两张表，提示词可以直接参考预设的模板，完成后系统会自动生成表格链接并说明字段和视图设置。

我想搭建一套会随着使用和反馈逐渐变准的精选信源系统。以后，用户只需要说自己想持续关注什么，Agent就会把需求拆清楚，找到合适的信息入口，确认可行的采集方式，再定期生成日报。并且可通过用户反馈，每日更新信源精选规则，不断优化Agent信源精选的准确度。
现在，你的第一个任务是创建一个多维表格“信源管理系统”，在里面建立两张数据表，作为后续运行的地基之一。
第一张叫“监测任务”，每一行是一条可以独立新增、修改或暂停的需求，字段为：
- 需求条目：主字段，单行文本；用来识别一条最小、可独立维护的需求
- 监测对象：单选；用来汇总同一对象下的需求，也是后续分配subagent时的筛选依据
- 监测要求：多行文本；说明具体想关注哪些变化，以后出现明确误判时也在这里补充必要边界
- 证据边界：多行文本；说明什么来源或证据足以确认这条信息
- 状态：单选，选项为“启用”“暂停”；决定当前是否执行这条需求
示例：需求条目为“模型发布”，监测对象为“OpenAI”，监测要求为“关注新模型、重要版本升级及模型上线或下线”，证据边界为“以官方公告、文档或官方账号为准”，状态为“启用”。
第二张叫“信息入口”，每一行是一个可以独立检查的具体入口，字段为：
- 入口名称：主字段，单行文本；用来识别一个具体的信息入口
- 监测对象：单选；用来把入口归到对应对象，让subagent能与监测任务一起筛选
- 入口地址：链接；保存实际访问位置
- 渠道定位：单行文本；说明这个入口主要提供什么信号，例如正式公告、开发者更新、实时动态或招聘信号
- 采集方式：单行文本；记录当前确认可行的主要采集路线，例如结构化接口、脚本或Browser Use，不在这里展开完整操作步骤
- 状态：单选，选项为“待验证”“启用”“暂停”“失效”；表示这个入口当前是否可投入运行
- 上次成功检查时间：日期时间；作为下一轮查找新增内容的时间起点，只有检查成功后才更新
示例：入口名称为“官方动态”，监测对象为“OpenAI”，入口地址为其官方News页面，渠道定位为“正式公告”，采集方式为“Browser Use读取更新列表”，状态为“启用”，上次成功检查时间为最近一次成功运行的时间。这个示例只用于说明字段含义，实际入口和采集方式需要后续验证。
两张表共用“监测对象”作为筛选和分组依据，不需要另外创建监测对象表。默认视图都按“监测对象”分组；再为信息入口建立一个“待验证”视图。
完成后把表格链接发给我，并告诉我最终创建的字段和视图。
这一步只创建空表，不添加正式需求和入口，也不创建日报、Skill或定时任务。

智能代理内置了多维表格、云文档等技能，能够便捷地完成表格的创建，相比其他工具只需额外配置终端授权的方式，这套组合的操作门槛更低。智能代理创建的表格会归属在当前账号的办公套件中，方便你和Agent共同查看和管理。

生成具体的监测需求与采集方案

完成数据表的创建后，你可以直接向智能代理提出你的信源监测需求，它会自动将需求拆解为持久化的任务并录入系统。智能代理会先读取已有的表格结构，然后引导你描述具体的监测需求，例如“帮我监测OpenAI的模型、产品更新以及Codex重置预告”。

在处理需求时，智能代理会按照监测对象拆分任务，避免重复记录，并优先复用已有的信息入口；如果没有合适的现有入口，会自动验证新的信息来源并确定采集方式，采集方式会按照结构化接口、网页读取、浏览器自动化的优先级依次尝试，确保方案的可行性。

如果对已有的信息入口和采集方式有特定偏好，也可以直接向智能代理提出，它会验证后更新信源表的内容。需要注意的是，部分网站可能需要登录授权，此时需要按照智能代理的提示完成登录或验证操作。

接下来请帮我把新的监测需求加入“信源管理系统”。
请先读取其中的“监测任务”和“信息入口”两张表，理解字段和已有记录，然后问我：你想持续监测什么？
收到回答后，请直接完成这件事：
- 理解其中的监测对象和监测主题。监测任务表的一行，表示某个对象下面一项可以独立维护的主题；例如“OpenAI 的模型更新”是一项监测需求，不需要继续拆成发布、升级、上线、下线等多行
- 按已经建立的字段新增或更新监测任务，避免产生重复记录
- 围绕这个监测对象寻找能够覆盖该主题的具体信息入口，优先复用已有入口；对新增入口实际验证是否可以访问，以及适合怎样自动获取更新，再写入信息入口表
验证采集方式时，请从轻到重逐级尝试，上一层能够稳定取得信息就停止：
1. 优先使用现成的结构化入口，例如连接器、RSS、API、GitHub Releases 或提交记录
2. 没有合适的结构化入口时，再尝试直接读取网页，或编写轻量脚本提取列表
3. 页面依赖动态交互、登录状态，或前两种方式无法稳定读取时，再使用 Browser Use
常见例子：GitHub 项目更新可以先检查 Releases 或 API；官方博客、更新日志和文档先检查是否提供 RSS 或其他结构化入口，没有再尝试直接读取页面或脚本；需要登录或高度依赖交互的网站，才考虑 Browser Use。这些只是判断示例，实际方案仍由你验证后决定。
验证不能只确认“网址能打开”。请实际取得最近的内容列表，并确认至少能识别标题、链接、发布时间或稳定 ID，以便以后判断增量。没有实际跑通的方案，不要写成已确定的采集方式；可以保留为“待验证”。
例如，我回答“我想持续监测 OpenAI 的模型更新”时，你可以这样理解和记录：
- 监测任务：需求条目为“模型更新”，监测对象为“OpenAI”，监测要求涵盖新模型、重要版本变化以及模型上线或下线，证据边界以 OpenAI 官方公告、文档或官方账号为准，状态为“启用”
- 信息入口：围绕 OpenAI 查找能够提供正式公告、开发者更新或实时动态的具体官方入口；例如先验证 OpenAI News RSS 是否能够稳定返回标题、链接和发布时间，再判断是否还需要其他入口补足覆盖。验证成功的状态设为“启用”，本次先不填写“上次成功检查时间”
这个示例只说明需求如何落到两张表。实际采用哪些入口、使用什么采集方式，由你访问和验证后决定。
除非存在会改变监测对象或主题的歧义，否则请自行判断并继续完成。最后告诉我你如何理解这次需求、写入了哪些监测任务、采用了哪些信息入口和采集方式。
这一步不启动定时任务，也不生成日报。

制定日报规则并生成首份日报

Agent工作流通常包含多个环节，为了避免后期维护困难，建议在完善采集方案后尽快验证最小闭环。首先创建一个统一的知识库作为系统的长期文档入口，包含首页索引、日报规则文档和每日日报目录。

首页需要登记当前系统的所有组成部分，比如多维表格和日报目录；日报规则文档则包含使用材料索引、信息筛选规则和日报模板，其中使用材料需要指向之前创建的多维表格，明确监测任务和信息入口的来源。

请创建一个知识库“信源 Loop 系统”，作为这套系统长期文档的统一入口。
目前只建立以下结构：
1. 知识库首页
用于长期维护整套系统的说明和文档索引，包括：这套系统解决什么问题、目前怎样运行；已有组成部分分别负责什么；指向各项正式资产的入口
当前先在首页登记：
- “信源管理系统”多维表格：维护监测任务和信息入口
- “每日日报”目录：归档系统每天生成的日报
以后新增日报规则、反馈日志或 Research Map 等正式文档时，再把它们补进首页索引。
2. “日报规则”文档
包含以下章节：使用材料索引、信息筛选规则、日报模板
在“使用材料”中放入“信源管理系统”多维表格的直接链接，并注明：“监测任务”表决定需要关注什么，“信息入口”表决定去哪里获取。
3. “每日日报”目录
作为独立目录使用。以后每天生成一份以日期命名的日报，并统一放在该目录下级子文档。
现在不要提前创建其他尚未实际使用的目录或文档。完成后把知识库链接发给我。

完成知识库的创建后，就可以让智能代理生成第一份日报，验证整个采集和生成流程是否正常运行。生成的日报会对应当前时间段的行业事件，归档在每日日报目录下，完成后就验证了信源日报的小闭环。

优化日报格式

如果你对日报的排版有特定要求，可以直接让智能代理调整日报本身的内容，很快就能得到更符合你习惯的排版效果。同时，也可以让智能代理将新的格式规则固化到核心文档中，这样后续的日报都会遵循新的格式规范。

由于云文档支持人机共同读写，你也可以直接手动编辑日报规则，修改后的内容会在Agent下次执行时自动生效。除了主动修改，后续还可以通过群聊和批注的反馈，让系统自动优化Loop流程。

设置定时推送，完成基础闭环

当日报生成流程验证通过后，就可以配置定时任务，让日报每天自动推送至指定群组。首先创建一个专用的技能，用于简化定时启动的提示词，指定每天早上九点将当日日报推送至目标群组。智能代理会自动搜索指定的群组ID，更新技能内容。

接下来，我希望这套系统，能在每天早上 9 点，把当天日报自动推送到我的群里。
请先创建一个 Skill，届时我将结合定时任务，用于指导该任务的自动定时执行。

在推送消息的形态上，支持文本、长文和交互式卡片等多种形式，你可以根据需求选择合适的方式，比如交互式卡片能够让消息更直观易读。需要注意的是，部分工具在发送消息时可能需要以当前账号代发，如果你希望以独立身份推送，可以为智能代理单独创建一个专属账号。

完成技能和推送设置后，就可以创建定时任务，创建完成后，每天九点就能自动收到筛选后的信源日报了。

搭建反馈Loop，实现系统自进化

到这里，系统已经能够每天自动推送日报，但它仍然是固定的工作流，无法根据用户的反馈自动优化。我们的目标是让系统能够根据用户的反馈自主迭代，实现真正的自进化。

要实现这一点，关键在于如何让人类的反馈信息自然流动到Agent中，并被用于优化系统。在日常使用中，常见的反馈途径包括：在推送日报的群组中直接留言、在日报文档中添加批注，或者通过固定问卷收集反馈。其中群聊和文档批注的方式最为便捷，用户无需额外操作就能留下反馈，更利于Loop的持续运行。

智能代理可以通过定时任务，在每天采集新内容之前，先整理前一天的反馈信息，将新的监测需求、采集方法、日报规则等更新到核心文档中。例如，当用户在群聊中提到“今天的日报不错”或者“这个方向不用再盯了”，智能代理会读取这些反馈，更新监测任务表和筛选规则，让后续的日报更加贴合用户的需求。

请在“信源 Loop 系统”知识库中新增“日报反馈”目录，并把它登记到知识库首页。该目录用于按天保存从群聊消息和日报批注中整理出的反馈，每天建立一份以对应日报日期命名的子文档。（当天无反馈可不创建）
并新增 Skill 规则：从下一次定时任务开始，每次运行信源采集前，必须先完成以下流程：
1. 读取上一份日报发布后至本次运行前，群聊中与该日报相关的消息，以及该日报中的批注。
2. 在“日报反馈”目录下创建当天的反馈文档，总结当天收到的日报反馈，以及根据这些反馈完成了哪些调整（谁、提出什么反馈、反馈处理结果）。
3. 根据当日反馈文档，按照本 Skill、知识库核心文档，指引更新它所对应的信源 Loop 系统的正式资产，比如：
- 涉及新增、修改或停止某项监测范围时，更新“监测任务”表
- 涉及新增或调整信息来源时，完成必要验证后更新“信息入口”表
- 涉及已有监测范围内更关注什么、哪些内容值得入选时，更新“日报规则”中的“选材规则”
- 涉及日报结构、篇幅、图片、截图或链接形式时，更新“日报规则”中的“日报模板”
向“日报规则”写入新规则时，说明它适用于全部日报、某个监测对象，还是某类监测主题，并放到对应位置。只有实际出现特定规则时，才新增相应的小标题，不提前建立完整分类。

完成反馈流程的配置后，智能代理会自动在知识库中创建日报反馈目录，按天保存每日的反馈总结，并根据反馈调整系统的正式资产，比如新增监测任务、更新信息入口、调整日报规则等，最终实现整个反馈-优化-再生成的闭环。

加餐：添加个性化推荐功能

除了固定的监测需求，这套Loop系统还可以根据用户的阅读喜好自动推荐相关内容。比如专注于Agent应用的用户可以优先收到AI应用新品的资讯，模型研究者可以获得更多模型训练相关的论文，甚至可以根据用户对特定文风或内容类型的偏好进行筛选。

要实现个性化推荐，需要在系统中引入「内容推荐画像」的概念，记录用户的职业、关注话题、内容偏好等信息。每次生成日报时，Agent会同时读取监测任务和内容推荐画像，将符合条件的内容作为推荐部分加入日报。当用户反馈发生变化时，系统也会同步更新推荐画像和日报规则，确保推荐内容始终贴合用户需求。

请在知识库中创建一份「内容推荐画像」文档，用来记录我希望收到什么样的推荐内容，例如关注方向、判断偏好、喜欢或不喜欢的内容特征。同时更新「日报规则」：
1. 每次生成日报时，读取「信源管理系统」中的监测任务，以及「内容推荐画像」和「日报规则」。
2. 信息入口产生的新内容有两种入选方式：
   - 命中已启用的监测任务：作为监测内容进入日报。
   - 未命中监测任务，但符合「内容推荐画像」：作为推荐内容进入日报。
   同一内容同时满足两种条件时，只保留一次，并优先标记其命中的监测任务。
3. 每日总结用户反馈后，按反馈所影响的对象更新对应资产：
   - 关注范围发生变化，更新监测任务；
   - 推荐偏好发生变化，更新「内容推荐画像」；
   - 日报的通用呈现规则发生变化，更新「日报规则」。

你可以直接维护修改创建好的画像，也可以让智能代理替你完成修改，系统会自动根据更新后的规则生成更贴合你偏好的日报。

写在最后：Context的核心作用

通过前面的实践可以发现，这套自进化Loop系统的所有调整都围绕着Context的打通与循环展开：Context可以引导Agent读取其他上下文内容，比如日报技能会引导Agent查阅知识库和表格规则；Context的来源和存储形式多种多样，包括本地文件、群聊记录、文档表格甚至批注；而Agent本身也可以作为Context的输出者，生成日报、推送消息，甚至编辑自身的技能和规则文件，仅在Context Loop层面就能实现自循环优化。

虽然本文以信源日报场景为例，但Agent的信息输入来源非常广泛，借助各类API和生态工具，Agent可以连接邮箱、会议、企业内部数据等多种信息源，其输出的形式也不仅限于日报，还可以是行业趋势分析、行动项拆解、异常告警等。

设计Agent系统的关键在于，要能够灵活地转换Context的输入和输出形式，只要明确了体验预期、选好了匹配的工具，设计好自循环的改进流程，就能让Agent自动捕捉每一次反馈，越用越贴合用户的需求。

本来只是想分享一个教程，没想到还是写到了较长的篇幅，感谢你的阅读，也欢迎分享给更多有需要的朋友。