掌握 Loop Engineering:让 Agent 持续自动找工作的长期循环系统设计指南
可能你已注意到,一个名为 Loop Engineering 的新概念正在技术圈掀起波澜。它由 OpenClaw 创始人与 Claude Code 核心维护者共同倡导,核心理念简洁而强韧:别再死磕提示词了,去构建循环吧。虽然名字里带着 Engineering,但这并非 AI 产品研发或系统设计的专属术语,而是一种更高效、更合理的 Agent 使用方与思维模型。换句话说,它属于每一个希望真正用好智能体的人。
一句话概括 Loop Engineering:围绕一项长期目标,设计一套位于 Agent 外部的循环控制体系,让智能体能够稳定地被触发、执行任务、产出交付物、进入待命、再次运行……
本文从一次真实的日常需求出发,应用 Loop Engineering 思维,把这项任务全面托付给 Agent,实现长期、自动化且高质量的循环执行。如果你正在考虑如何让智能体持续地帮你搜集并跟进工作机会,这个场景应该很对胃口。

概念上下文:Loop Engineering 与各类“工程”是什么关系
Loop 和 Engineering 这两个词,总让人联想到 Agent Loop、Prompt Engineering、Context Engineering 或 Harness Engineering 等流行术语。但这个新概念和它们完全不在同一维度——后者更多出现在你设计或开发一款 Agent 产品时。因此,即便你不了解那些概念,也完全不妨碍你理解 Loop Engineering,并成为一个高阶应用者。
Loop Engineering 真正需要的能力是任务流程的抽象——把一个重复性事项固定下来,使其自动运行。这是产品经理的基本功,其实非常简单。即使暂时不熟练,读过本文后,你也能快速掌握。
从零开始:哪些任务值得采用 Loop Engineering?
在进入具体案例前,必须明确一个边界问题:并非所有让 Agent 完成的活都需要套用 Loop Engineering。
适合被设计成 Loop 的任务通常具备以下特征:
- 输入持续变化,而非一次性给定;
- 任务不是一次性完成,而是需要长期跟踪与迭代;
- 用户的反馈会直接影响后续执行策略;
- 多次执行之间需要共享状态信息;
- 需要由定时、事件或外部系统触发;
- 必须具备审计、恢复、降级甚至停止规则。
举个例子,“帮我找 10 个上海的 AI 产品经理岗位”这类指令,Agent 一次性搜索便可完成,最多再上传一份简历作为上下文。这是求职过程中的单次查询,虽然你很可能每天都会做类似的事,但如果你始终在循环中承担验收交付的角色,真正的循环成本就会很高。
更重要的是,真实求职远不是“每天执行一次找 10 个岗位”这么简单:
- 今天没有合适的机会,明天可能出现;
- 今天找到了合适岗位,或许两天后才有空仔细评估;
- 完成备选岗位的初步研究后,接下来的精力应转向生成投递方案,而不是继续刷新岗位列表;
- 已投出的岗位,下一次搜索结果中必须剔除;
- 连续几天收到的交付结果都不感兴趣,意味着筛选规则需要调整;
- 甚至当求职方向从“AI 产品”转向“AI 运营”时,每日搜索关键词也要随之改变。
显然,没有人不希望 Agent 能自行实现以上需求,而不需要我们一次次重复下达提示词。这正是 Peter 所指出的:“你应该设计循环,让循环去提示你的 Agent。”
接下来,我用 Loop Engineering 思维把这个问题彻底落地。
实战案例:Job Hunt Loop——长期求职岗位发现系统
这是一个持续运行的「求职岗位发现与跟进智能体套件」。
你只需提供城市、岗位方向、筛选条件和简历,系统便会持续监控新发布的 JD。一旦发现可投递岗位,立即生成投递报告。你有时间的时候在报告里勾选、评论或保持沉默,系统依据这些反馈继续学习与调整。
套件由以下 8 个模块构成,逐一理解后,你就真正掌握了 Loop Engineering 的深层奥义:
- 触发器 —— 解决 Agent 无法主动运行的问题,通过外部循环控制器按需激活它;
- 任务队列 —— 确保 Agent 在长期任务中清晰掌握“我已经见过什么,现在该处理什么”;
- 上下文组装 —— 让 Agent 每次被唤醒时立刻明白自己的身份与当前任务;
- 执行器 —— 不必把所有事都推给 Agent,脚本的可靠性远高于大模型;
- 交付载体 —— 使用飞书文档作为交付与反馈收集的界面,利用其事件订阅能力;
- 反馈学习 —— 让每一轮执行结果都能优化下一轮行为;
- 停止与降级 —— 长期循环并非无止境运转,必须有可控的终止与削弱条件;
- 可观测性 —— 每轮作业的数据与交付物均本地存档,随时可审计。
基于这些模块,Job Hunt Loop 能够实现:
- 提供简历、意向岗位、城市、薪资福利要求后,启动任务循环;
- Agent 每日定时激活,在 Boss 直聘或猎聘等平台搜集岗位,并整理到本地;
- 根据你的求职需求生成岗位投递规划,并创建工作文档发送给你;
- 当你在文档里标记反馈时,Agent 立即收到推送,并据此执行相应动作;
- 例如评论“已投递”,Agent 会将该岗位迁移至投递看板,同时准备面试资料;
- 若你 48 小时或 72 小时未给予反馈,Agent 会迭代筛选规则,减少相似岗位推荐;
- 每周自动生成求职周报,同步它做了什么、你又完成了什么。

(图中的推荐岗位为模拟数据)
每一轮作业过程产生的数据和交付物都会在本地备份存档:

项目源代码已开源到 GitHub,地址见文末。
下面,我们逐一拆解这个 Loop 的设计思路。
触发器:让 Agent 学会“主动”工作
很多人在使用 Agent 产品时,会不自觉地将它想象成 24 小时在线、随时待命的员工。但在实际系统里,Agent 本质上是被动响应式的——只有收到明确的触发事件,才会真正开始工作。所以 Job Hunter 的第一层不是 Agent,而是触发器。
触发器负责回答一个根本问题:什么情况下,系统应当唤醒 Agent?
在求职场景中,触发来源至少有三类:

对应到项目里,我们需要为这些来源设计一系列外部控制器:


这是 Loop Engineering 的第一层认知:不要把 Agent 当作常驻服务,而应将其视为被外部循环控制器按需唤醒的执行体。Agent 负责推理决策,触发器负责让任务持续发生。
任务队列管理:让 Agent 知道“见过什么、该处理什么”
第二个实际约束:招聘平台每次返回的岗位数据往往会重复。假设系统每 4 小时搜索一次,如果不做去重和队列管理,就会引出两个严重问题:
- 同一岗位被反复推荐给用户;
- Agent 不知道哪些岗位此前已生成过报告。
所以,Job Hunter Loop 内部需要一套轻量级任务队列。我们可以在项目空间内用下面的文件记录历史岗位:

我采用了开源项目 boss-agent-cli 在招聘网站搜索意向岗位信息(部分网站有反爬风险,使用时需留意)。搜索完成后,CLI 会产出结构化岗位数据,典型字段包括:
{
"security_id": "job_xxx",
"title": "企业 AI 应用顾问",
"company_name": "某科技公司",
"salary_desc": "35-50K",
"city_name": "上海",
"job_desc": "负责企业 AI 转型方案、RAG 知识库、Agent 工作流落地..."
}
基于这些数据,可通过脚本自动完成以下四件事:
- 读取本轮 CLI 搜索结果;
- 与
seen.jsonl进行对比去重; - 仅将新增岗位写入
queue.jsonl; - 生成一个批次 ID,供后续报告、反馈与审计关联。
这一步看似平淡,却是长期循环系统的地基。因为系统每次被唤醒都必须能回答三个关键问题:
- 我已经见过什么?
- 现在需要处理什么?
- 哪些任务已交付,哪些仍在等待用户反馈?
缺少队列,Agent 就只能依赖对话上下文维持状态;而上下文一断,任务必然中断。
记忆组装:每次唤醒都能恢复完整上下文
第三个约束来自长期任务必然跨 session 的特点。今天唤醒的是一个 Agent 会话,明天可能由另一个会话执行。模型不会天然知道:
- 这个项目是干什么的;
- 当前用户的筛选条件是什么;
- 哪些岗位已经处理过;
- 上一次用户给予了哪些反馈;
- 哪些行为是被禁止的。
因此,每次唤醒 Agent 时,都必须组装一份稳定的上下文。Job Hunter 把上下文拆分为几个层级:

这里最关键的是 AGENT.md 文件。

它不是给人看的 README,而是每次 Agent 被唤醒时所读取的“同频文档”。它会明确告知 Agent:
- 你是一个求职岗位发现系统的执行器;
- 你不能自动投递、也不能自动打招呼;
- 你需要读取队列、偏好、简历和审计日志;
- 用户反馈将通过飞书文档和消息进入系统;
- 状态变更后必须更新看板与审计记录。
这就是 Loop Engineering 与普通“记忆功能”的本质区别。普通记忆是“模型记住用户偏好”,工程化记忆则是“任何一次执行,都能从稳定文件里重建完整上下文”。
此外,不能假设每次唤醒的 Agent 都会以相同的方法执行任务。如果没有明确的 SOP,今天的 Agent 可能按薪资排序,明天的按公司名排序,后天的干脆忘记读取简历。由于并非每次会话都涉及全部任务规范,可以把关键作业规则封装为标准 Skill,按需加载:

Loop Engineering 的精髓不是让 Agent 每次“凭感觉再来一遍”,而是将专业方法、交付规范与反馈规则显式化。
执行器与工具:把确定性留给脚本,推理留给 Agent
千万不要把所有事情都一股脑塞给 Agent。在分配任务时,必须严格区分哪些适合大模型,哪些适合确定性脚本:


Loop Engineering 并非“凡事都让 Agent 做”,而是把 Agent 放在最需要发挥判断力的位置。在 Job Hunter 中,除了规则迭代之外,所有其他工作都先通过脚本对数据进行预处理和加工,然后把凝练后的信息发给 Agent 进行润色,最终输出报告。

交付物:将飞书文档变成反馈交互界面
第五个约束:用户不应该再被拽回聊天框里配合系统运转。求职报告发出后,用户真正的消费场景是在文档中——浏览岗位、比较匹配度、勾选感兴趣的项目、留下评论(如“薪资偏低”“已投递”“这个方向可以多挖掘”)。
因此,Job Hunter 没有把飞书文档当成一份静态报告,而是设计成反馈界面。在投递报告里,每个岗位前都有 checkbox:
- [ ] 1. 企业 AI 应用顾问 @ 某科技公司 | 35-50K | 匹配度 9.2/10
- [ ] 2. AIGC 产品运营专家 @ 某云服务公司 | 28-42K | 匹配度 8.1/10
- [ ] 3. AI 培训解决方案负责人 @ 某企业学习平台 | 30-45K | 匹配度 8.8/10
用户勾选,即表示强正反馈;评论“已投”,便是岗位状态变更;48 小时无动作,属于弱负反馈;72 小时仍未动作,系统自动归档相关岗位。
这个设计的关键并非“飞书文档有多好用”,而在于:用户虽然在循环外部,但其消费行为必须被设计成循环的输入。这也是 Loop Engineering 中极具分量的一层——人不必时刻盯着 Agent,但人的判断必须能被系统捕捉并闭环。

可观测性:长期系统绝不能是黑盒
第六个约束同样是长期任务无法绕开的:系统不能是一个黑盒。用户不知道它是否在正常运行,开发者不清楚进展到哪一步,下次唤醒的 Agent 同样不知道上次做了什么。因此,每一轮循环都必须留下充分的交付物。
Job Hunter 完成一整轮作业后,会生成以下文件:
workspace/
├── queue.jsonl
├── seen.jsonl
├── preferences.json
├── market-intel.json
├── kanban.csv
├── audit.jsonl
└── reports/
├── batch_xxx-delivery-report.md
└── weekly-YYYY-WW.md
这些文件各自承担着不同的“可观察性”职责:

其中,飞书文档是面向用户的交付层,本地工作区是面向系统的交付层。用户可以截图报告和周报;开发者可以检查队列、审计日志和看板;Agent 下一次被唤醒时,可读取这些文件恢复完整的上下文。这就是长期循环任务的可观测性基础。
反馈学习:让每一轮结果滋养下一轮
第七个约束:如果系统每轮只是重复搜索,那它不过是又一个定时任务。Loop Engineering 要求每一轮的执行结果能够直接且有效地影响下一轮。
在 Job Hunter 中,用户反馈会持续流入 preferences.json:

下一轮评分时,系统就不再仅仅依赖关键词,而会更加理解用户的真实方向偏好——比如更侧重于 AI 应用落地而非底层模型训练,更倾向于企业培训和 ToB 解决方案而非纯研发,更关注 RAG、Agent 与知识管理,而非 CUDA、K8s 或分布式训练。这样,循环就不再是机械重复,而是在持续生长。
停止与降级:可控循环,而非无限死循环
第八个约束:长期循环既不能无限等待,也不能无限运行。它必须清楚何时继续、何时沉默、何时降级、又该何时彻底停止。
Job Hunter 内置了几条基本规则:

这一步极易被忽视。许多人在理解 Agent Loop 时,总误认为“越自动越好”。事实并非如此——一个可靠的循环系统,必须包含明确的停止条件、降级策略和人工介入节点。Loop Engineering 不是追求无限循环的工程,而是致力于构建可控的循环系统。
总结:Loop Engineering 到底是什么
拆解完 Job Hunter 之后,再回过头看 Loop Engineering,轮廓就很清晰了。它绝不是一个孤立的 prompt 技巧,也不是“Agent 自己循环调用工具”。
它是围绕一个长期目标搭建的外部任务循环系统:

更精确地讲,Loop Engineering 是:围绕一个长期任务,设计一套能够持续感知输入、保存状态、按需唤醒 Agent、组装上下文、执行动作、观察反馈、更新记忆、验证结果并决定下一步行动的工程系统。
普通 Agent Loop 回答的是“模型这一步该调用什么工具?”,而 Loop Engineering 回应的是“这个任务系统如何长期稳定地跑下去?”
项目开源地址:https://github.com/comeonzhj/job-hunter