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 系统」入手，包含：

1. 手把手教你搭一套自进化 Agent 系统，全流程照抄就能跑
2. 设计个人 Agent Loop 的思路，可以试用在你任何重复做的工作流上
3. 识别 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 真正跑顺，则需要同时满足三个条件：

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

如何设计 Loop 架构？

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

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

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

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

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

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

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

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

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

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

0️⃣ 前置操作

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

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

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

顺便解释一下：

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

1️⃣ 让 AI 创建监测任务表

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

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

1. 监测任务：维护用户的监测需求
2. 信息入口：按监控对象，如「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 点，你都能自动收到豆包工作为你筛选的信源日报了～

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

从日报系统本身来看，已足够完整，但它仍只是一个固定 Agent Workflow。它按照你给的规则、预设的信源需求而运行，并不能够自动按照你的阅读体验反馈而进行优化。

而我们真正的目标是达成自改进的 Context Loop ⬇️

Agent 能够在每天的运行中，自然收集你以及其他读者对日报的反馈看法，使得它能够自动增减需求、筛选规则和呈现形式，变成一个越来越懂你的信源 Loop 系统。

PS： 在开始下一步前，建议先让 Agent 总结一下监测任务与信息入口表的拆解与登记规则。

后续当有反馈涉及增删需求时，即可按 Skill 自动完成表格维护。（复杂 Skill 的维护过程，想要写的阅读体验丝滑，太累了= – =，想来想去还是塞这里提醒合适）

…

请参考我之前给你的指令，在 Skill 内增加多维表格中监测任务与信息入口表的登记规则，当用户有新的信源监测需求时，自动按之前的方式完成需求识别、采集方式验证与入表。

5️⃣ 反馈的 Loop：让系统学会自己变好

这一步的目标是让 Agent 能自己收集人类反馈，迭代下一次的行为：

关键在于：人反馈的 Context 如何流动到 Agent 那里去？又该什么时候处理、处理成什么样。

以这个场景为例，飞书内常见的反馈输入途径是这几样：

• 直接在发日报的群里说：「今天的日报不错」「这条我感兴趣」「这个方向不用再盯了」，自然、低门槛；
• 在日报文档里直接批注：看到哪条觉得好，就在那条旁边写一笔；
• 单独提供一份问卷：让读者按固定格式反馈。

我更偏向群聊的自然发送和文档自带的批注。因为它们在阅读过程中顺手就发，不用专门填表。

反馈越顺手，Loop 才越能持续。

所以需要让 Agent 定时去总结群聊与日报批注中的反馈留言。譬如，我在日报中批注、在群聊中留言：

借着豆包工作与飞书的联动，我所写的内容，自然能被 Agent 捕捉。

再者就是自动循环。

凭借豆包工作提供的「定时任务」功能，在每天抓新内容前，先整理前一天的反馈信息，进行 Autodream，就能把新的监控需求、采集方法、日报规则、模板更新在核心文档了。

故使用以下 Prompt，让 Agent 补上日报反馈目录，并更新 Skill，要求每天定时任务都得先总结反馈信号 ：

…

请在“信源 Loop 系统”知识库中新增“日报反馈”目录，并把它登记到知识库首页。该目录用于按天保存从群聊消息和日报批注中整理出的反馈，每天建立一份以对应日报日期命名的子文档。（当天无反馈可不创建）

并新增 Skill 规则：从下一次定时任务开始，每次运行信源采集前，必须先完成以下流程：

1. 读取上一份日报发布后至本次运行前，群聊中与该日报相关的消息，以及该日报中的批注。

2. 在“日报反馈”目录下创建当天的反馈文档，总结当天收到的日报反馈，以及根据这些反馈完成了哪些调整（谁、提出什么反馈、反馈处理结果）。

3. 根据当日反馈文档，按照本 Skill、知识库核心文档，指引更新它所对应的信源 Loop 系统的正式资产，比如：

– 涉及新增、修改或停止某项监测范围时，更新“监测任务”表

– 涉及新增或调整信息来源时，完成必要验证后更新“信息入口”表

– 涉及已有监测范围内更关注什么、哪些内容值得入选时，更新“日报规则”中的“选材规则”

– 涉及日报结构、篇幅、图片、截图或链接形式时，更新“日报规则”中的“日报模板”

向“日报规则”写入新规则时，说明它适用于全部日报、某个监测对象，还是某类监测主题，并放到对应位置。只有实际出现特定规则时，才新增相应的小标题，不提前建立完整分类。

你就可以看到：

豆包工作在之前创建的 Skill 中，增加了「日报反馈流程」指引：

飞书知识库中也成功建立了日报反馈目录，来归档每天的反馈信号：

这时再让豆包工作，就能根据最新的指引，完成整个反馈-优化信源规则-再生成的 Loop：

1 成功读取了我在群聊与批注中留言的反馈，形成了今日反馈总结

2 并根据反馈，在对应条目中，新增了监测需求与信息入口

3.随后根据新要求，开始重置今日日报内容。还主动结合表中的「上次检查时间」游标信息，简化了有无新内容的判断难度

最终成功在日报中插入了推文截图（Seed 多模态 + Browser Use 神力 ）

至此，Loop 验证通过！可以为自己鼓掌了！

恭喜你也为自己实践了一套自改进循环的 Agent 工作流，拥有了可以根据你 or 组织的留言反馈，自动「进化」的 Agent 工作流程了 ✅

加餐：个性化推荐机制

上文因行文节奏，着重只讲了采集固定信息需求的方法，如“OpenAI 的模型更新信息”。

但实际上，如果放宽要求，即使是同一组信源，这套 Loop 系统还能根据你的阅读喜好，自动推荐你可能感兴趣的内容。

譬如：

• 专心做 Agent 应用的产品同学，就多推“AI 应用新品”资讯
• 模型 Researcher，就多筛出模型训练相关的新论文
• 甚至你对某类“文风”、“调调”的内容不感兴趣，也能让这套系统逐渐熟悉你的偏好，为你筛选一二

那么怎么做呢？

答案是在整个 Loop 中引入「内容推荐画像」的概念，比如你的职业、关注话题、喜欢的内容风格等。要求 Agent 在筛选监测需求之余，同样留意有没有值得额外推荐的内容。

同样准备好了可以直接照抄的提示词，你也可以根据自己的理解再做修改，发给豆包工作就好：

…

请在知识库中创建一份「内容推荐画像」文档，用来记录我希望收到什么样的推荐内容，例如关注方向、判断偏好、喜欢或不喜欢的内容特征。同时更新「日报规则」：

1. 每次生成日报时，读取「信源管理系统」中的监测任务，以及「内容推荐画像」和「日报规则」。

2. 信息入口产生的新内容有两种入选方式：

– 命中已启用的监测任务：作为监测内容进入日报。

– 未命中监测任务，但符合「内容推荐画像」：作为推荐内容进入日报。

同一内容同时满足两种条件时，只保留一次，并优先标记其命中的监测任务。

3. 每日总结用户反馈后，按反馈所影响的对象更新对应资产：

– 关注范围发生变化，更新监测任务；

– 推荐偏好发生变化，更新「内容推荐画像」；

– 日报的通用呈现规则发生变化，更新「日报规则」。

你可以直接维护修改创建好的画像；也可以让 Agent 替你修改：

大概会是这么个效果：

这同样也是 Context 的新瓶装旧酒，就不再展开单独演示了。

另外，如果你是老读者，应该还记得我之前做的 Web Access Skill，其中有提到过「站点经验」的机制。

具体参考原文：Web Access：一个Skill，拉满Agent联网和浏览器能力

「信源入口」表的采集方式字段，也在起着类似的作用。

如果需要积累更完善的站点经验，让 Agent 操作更快更准确，或者直接叠加 Web Access Skill 来运行，当然也是可以的（感谢认可）

同样要求豆包工作调整日报流程 Skill 即可：可以在本地新增站点经验文件 or 存在云文档中，或者直接要求遵循 Web Access Skill 来联网。

写在最后：看 Context 是 Context

走到这里，你可能已经发现了：

这套 Loop 从头到尾，所有调整只围绕一件事 —— Context 的打通与循环。

• Context 可以提醒 Agent 读另一段 Context：日报 Skill 引导 Agent 读知识库、多维表里的规则；规则引导 Agent 联网采集新闻。ㅤ
• Context 的来源与存储形态很多样：可以是本地文件、飞书群聊、文档、表格甚至批注。ㅤ
• Agent 本身还是 Context 的输出者：既可以输出日报，也能推送聊天消息；也能自己编辑给自己看的 Skill、规则文件，仅在 Context Loop 层上就足以自循环优化。

虽然本文只列了信源日报场景的 Loop 系统，但实际上放宽到 Agent 场景中，「信息 input」非常开放，你能接入的信息远不止这些。

借助 MCP、API、CLI 生态，现在的 Agent 已经能够很方便的连接大量信息。

比如，豆包工作积累了飞书等 IM 内的组织关系、讨论、文档和决策；也提供了连接器，方便访问邮箱、会议、同花顺、淘宝，和企业内部数据来源。

而 Agent 对 Context 的处理结果，更不止日报这种形式：

读时事，分析外部行业趋势；读会议纪要，帮你拆行动项、盯完成进度；接内部系统，做异常告警分析；整理客户信息，生成跟进建议。ㅤ

设计 Agent，需要让自己到一种看 Context 不是 Context，但看 Context 是 Context 的状态。

换一种输入 Context、换一种输出形态，就是全新的 Agent 工作流。

定义好 Agent 体验预期、选好匹配的工具，好好设计每套 Loop 的自循环改进流程，就能让 Agent 自动捕捉你的每一次反馈，越用越合心意。