掌握 Loop Engineering：让 Agent 持续自动找工作的长期循环系统设计指南

可能你已注意到，一个名为 Loop Engineering 的新概念正在技术圈掀起波澜。它由 OpenClaw 创始人与 Claude Code 核心维护者共同倡导，核心理念简洁而强韧：别再死磕提示词了，去构建循环吧。虽然名字里带着 Engineering，但这并非 AI 产品研发或系统设计的专属术语，而是一种更高效、更合理的 Agent 使用方与思维模型。换句话说，它属于每一个希望真正用好智能体的人。

一句话概括 Loop Engineering：围绕一项长期目标，设计一套位于 Agent 外部的循环控制体系，让智能体能够稳定地被触发、执行任务、产出交付物、进入待命、再次运行……

本文从一次真实的日常需求出发，应用 Loop Engineering 思维，把这项任务全面托付给 Agent，实现长期、自动化且高质量的循环执行。如果你正在考虑如何让智能体持续地帮你搜集并跟进工作机会，这个场景应该很对胃口。

Image

概念上下文：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 的深层奥义：

  1. 触发器 —— 解决 Agent 无法主动运行的问题，通过外部循环控制器按需激活它；
  2. 任务队列 —— 确保 Agent 在长期任务中清晰掌握“我已经见过什么，现在该处理什么”；
  3. 上下文组装 —— 让 Agent 每次被唤醒时立刻明白自己的身份与当前任务；
  4. 执行器 —— 不必把所有事都推给 Agent，脚本的可靠性远高于大模型；
  5. 交付载体 —— 使用飞书文档作为交付与反馈收集的界面，利用其事件订阅能力；
  6. 反馈学习 —— 让每一轮执行结果都能优化下一轮行为；
  7. 停止与降级 —— 长期循环并非无止境运转，必须有可控的终止与削弱条件；
  8. 可观测性 —— 每轮作业的数据与交付物均本地存档，随时可审计。

基于这些模块，Job Hunt Loop 能够实现：

  1. 提供简历、意向岗位、城市、薪资福利要求后，启动任务循环；
  2. Agent 每日定时激活，在 Boss 直聘或猎聘等平台搜集岗位，并整理到本地；
  3. 根据你的求职需求生成岗位投递规划，并创建工作文档发送给你；
  4. 当你在文档里标记反馈时，Agent 立即收到推送，并据此执行相应动作；
  5. 例如评论“已投递”，Agent 会将该岗位迁移至投递看板，同时准备面试资料；
  6. 若你 48 小时或 72 小时未给予反馈，Agent 会迭代筛选规则，减少相似岗位推荐；
  7. 每周自动生成求职周报，同步它做了什么、你又完成了什么。

Image

（图中的推荐岗位为模拟数据）

每一轮作业过程产生的数据和交付物都会在本地备份存档：

Image

项目源代码已开源到 GitHub，地址见文末。

下面，我们逐一拆解这个 Loop 的设计思路。

触发器：让 Agent 学会“主动”工作

很多人在使用 Agent 产品时，会不自觉地将它想象成 24 小时在线、随时待命的员工。但在实际系统里，Agent 本质上是被动响应式的——只有收到明确的触发事件，才会真正开始工作。所以 Job Hunter 的第一层不是 Agent，而是触发器。

触发器负责回答一个根本问题：什么情况下，系统应当唤醒 Agent？

在求职场景中，触发来源至少有三类：

Image

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

Image

Image

这是 Loop Engineering 的第一层认知：不要把 Agent 当作常驻服务，而应将其视为被外部循环控制器按需唤醒的执行体。Agent 负责推理决策，触发器负责让任务持续发生。

任务队列管理：让 Agent 知道“见过什么、该处理什么”

第二个实际约束：招聘平台每次返回的岗位数据往往会重复。假设系统每 4 小时搜索一次，如果不做去重和队列管理，就会引出两个严重问题：

  • 同一岗位被反复推荐给用户；
  • Agent 不知道哪些岗位此前已生成过报告。

所以，Job Hunter Loop 内部需要一套轻量级任务队列。我们可以在项目空间内用下面的文件记录历史岗位：

Image

我采用了开源项目 boss-agent-cli 在招聘网站搜索意向岗位信息（部分网站有反爬风险，使用时需留意）。搜索完成后，CLI 会产出结构化岗位数据，典型字段包括：

{
  "security_id": "job_xxx",
  "title": "企业 AI 应用顾问",
  "company_name": "某科技公司",
  "salary_desc": "35-50K",
  "city_name": "上海",
  "job_desc": "负责企业 AI 转型方案、RAG 知识库、Agent 工作流落地..."
}

基于这些数据，可通过脚本自动完成以下四件事：

  1. 读取本轮 CLI 搜索结果；
  2. 与 seen.jsonl 进行对比去重；
  3. 仅将新增岗位写入 queue.jsonl；
  4. 生成一个批次 ID，供后续报告、反馈与审计关联。

这一步看似平淡，却是长期循环系统的地基。因为系统每次被唤醒都必须能回答三个关键问题：

  • 我已经见过什么？
  • 现在需要处理什么？
  • 哪些任务已交付，哪些仍在等待用户反馈？

缺少队列，Agent 就只能依赖对话上下文维持状态；而上下文一断，任务必然中断。

记忆组装：每次唤醒都能恢复完整上下文

第三个约束来自长期任务必然跨 session 的特点。今天唤醒的是一个 Agent 会话，明天可能由另一个会话执行。模型不会天然知道：

  • 这个项目是干什么的；
  • 当前用户的筛选条件是什么；
  • 哪些岗位已经处理过；
  • 上一次用户给予了哪些反馈；
  • 哪些行为是被禁止的。

因此，每次唤醒 Agent 时，都必须组装一份稳定的上下文。Job Hunter 把上下文拆分为几个层级：

Image

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

Image

它不是给人看的 README，而是每次 Agent 被唤醒时所读取的“同频文档”。它会明确告知 Agent：

  • 你是一个求职岗位发现系统的执行器；
  • 你不能自动投递、也不能自动打招呼；
  • 你需要读取队列、偏好、简历和审计日志；
  • 用户反馈将通过飞书文档和消息进入系统；
  • 状态变更后必须更新看板与审计记录。

这就是 Loop Engineering 与普通“记忆功能”的本质区别。普通记忆是“模型记住用户偏好”，工程化记忆则是“任何一次执行，都能从稳定文件里重建完整上下文”。

此外，不能假设每次唤醒的 Agent 都会以相同的方法执行任务。如果没有明确的 SOP，今天的 Agent 可能按薪资排序，明天的按公司名排序，后天的干脆忘记读取简历。由于并非每次会话都涉及全部任务规范，可以把关键作业规则封装为标准 Skill，按需加载：

Image

Loop Engineering 的精髓不是让 Agent 每次“凭感觉再来一遍”，而是将专业方法、交付规范与反馈规则显式化。

执行器与工具：把确定性留给脚本，推理留给 Agent

千万不要把所有事情都一股脑塞给 Agent。在分配任务时，必须严格区分哪些适合大模型，哪些适合确定性脚本：

Image

Image

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

Image

交付物：将飞书文档变成反馈交互界面

第五个约束：用户不应该再被拽回聊天框里配合系统运转。求职报告发出后，用户真正的消费场景是在文档中——浏览岗位、比较匹配度、勾选感兴趣的项目、留下评论（如“薪资偏低”“已投递”“这个方向可以多挖掘”）。

因此，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，但人的判断必须能被系统捕捉并闭环。

Image

可观测性：长期系统绝不能是黑盒

第六个约束同样是长期任务无法绕开的：系统不能是一个黑盒。用户不知道它是否在正常运行，开发者不清楚进展到哪一步，下次唤醒的 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

这些文件各自承担着不同的“可观察性”职责：

Image

其中，飞书文档是面向用户的交付层，本地工作区是面向系统的交付层。用户可以截图报告和周报；开发者可以检查队列、审计日志和看板；Agent 下一次被唤醒时，可读取这些文件恢复完整的上下文。这就是长期循环任务的可观测性基础。

反馈学习：让每一轮结果滋养下一轮

第七个约束：如果系统每轮只是重复搜索，那它不过是又一个定时任务。Loop Engineering 要求每一轮的执行结果能够直接且有效地影响下一轮。

在 Job Hunter 中，用户反馈会持续流入 preferences.json：

Image

下一轮评分时，系统就不再仅仅依赖关键词，而会更加理解用户的真实方向偏好——比如更侧重于 AI 应用落地而非底层模型训练，更倾向于企业培训和 ToB 解决方案而非纯研发，更关注 RAG、Agent 与知识管理，而非 CUDA、K8s 或分布式训练。这样，循环就不再是机械重复，而是在持续生长。

停止与降级：可控循环，而非无限死循环

第八个约束：长期循环既不能无限等待，也不能无限运行。它必须清楚何时继续、何时沉默、何时降级、又该何时彻底停止。

Job Hunter 内置了几条基本规则：

Image

这一步极易被忽视。许多人在理解 Agent Loop 时，总误认为“越自动越好”。事实并非如此——一个可靠的循环系统，必须包含明确的停止条件、降级策略和人工介入节点。Loop Engineering 不是追求无限循环的工程，而是致力于构建可控的循环系统。

总结：Loop Engineering 到底是什么

拆解完 Job Hunter 之后，再回过头看 Loop Engineering，轮廓就很清晰了。它绝不是一个孤立的 prompt 技巧，也不是“Agent 自己循环调用工具”。

它是围绕一个长期目标搭建的外部任务循环系统：

Image

更精确地讲，Loop Engineering 是：围绕一个长期任务，设计一套能够持续感知输入、保存状态、按需唤醒 Agent、组装上下文、执行动作、观察反馈、更新记忆、验证结果并决定下一步行动的工程系统。

普通 Agent Loop 回答的是“模型这一步该调用什么工具？”，而 Loop Engineering 回应的是“这个任务系统如何长期稳定地跑下去？”

项目开源地址：https://github.com/comeonzhj/job-hunter