Loop Agent：从提示词到自驱动智能体循环

wiki/ai/sources/loop-agent-engineering-research-2026-06-23.md

分类：ai / sources · 更新：2026-06-23 22:22

Loop Agent：从提示词到自驱动智能体循环

一句话结论

Loop Agent 不是“让模型多想几步”，而是把原来由人承担的外层循环——发现任务、提示 agent、检查结果、决定下一步、记录状态、继续迭代——做成一个可运行、可审计、可停止的系统。

如果说 Prompt Engineering 关心“这一句话怎么问”，Context Engineering 关心“这一轮该给模型看什么”，Harness Engineering 关心“这一次 agent run 的工具、权限、沙箱、日志是否可靠”，那么 Loop Engineering 关心的是：多次 agent run 如何自动被触发、验证、记录、继续，并在满足条件时停下来。

它的核心不是“完全无人”，而是“把人的重复性 steering 外部化成系统”。人仍然要设计目标、边界、验证标准、权限、预算和升级路径。

---

1. Loop Agent 到底是什么

Addy Osmani 对 Loop Engineering 的定义很直白：

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

翻译成工程语言：

过去我们使用 coding agent 的方式通常是：

人输入 prompt；
agent 执行；
人看结果；
人指出问题或给下一步；
agent 再执行；
如此反复。

这里真正驱动进展的不是模型，而是人的“下一步判断”。人是外层循环。

Loop Agent 做的事，是把这个外层循环变成系统：

Trigger
  → Assemble Context
  → Run Agent
  → Execute Tools
  → Observe Result
  → Verify / Grade
  → Update State
  → Continue / Retry / Stop / Escalate

所以 Loop Agent 的单位不是一次聊天，而是一个持续运行的控制系统。模型只是其中一个可调用组件，像函数一样被 loop 调用。

这也是为什么 Boris Cherny 关于 Claude Code 的那句说法会引发讨论：

I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

这句话的重点不是“人不重要了”，而是人的杠杆点变了：从逐轮提示，变成设计可复用的任务循环。

---

2. Loop Engineering 与 Prompt / Context / Harness 的区别

可以把 agent 工程分成四层：

层级	关注问题	典型产物
Prompt Engineering	单次指令怎么写	prompt 模板、role、few-shot
Context Engineering	这一轮模型该看到什么	摘要、检索、上下文裁剪、记忆注入
Harness Engineering	单次 agent run 如何可靠行动	tools、MCP、权限、沙箱、日志、hook、测试
Loop Engineering	多次 run 如何自动推进和停止	cron、webhook、STATUS.md、verifier、retry、budget、escalation

最容易混淆的是 Harness 和 Loop。

Harness Engineering 让一次 agent run 更稳。比如：

允许哪些工具；
禁止哪些命令；
是否在 git worktree 里执行；
是否自动跑测试；
工具调用是否有日志；
出错后如何恢复。

Loop Engineering 则让这些可靠的 run 被反复、有条件地调用。比如：

每天 9 点扫描 issue；
为每个候选任务开 worktree；
implementer agent 修改代码；
verifier agent 检查 diff 和测试；
失败则把证据喂回去，最多重试 3 次；
成功则开 PR，写入状态文件；
高风险则停止并找人确认。

一句话：

Harness 负责让 agent 不乱跑；Loop 负责让 agent 不停在原地。

没有 Harness 的 Loop 很危险，因为它只是把脆弱 agent 自动化；没有 Loop 的 Harness 仍然需要人不断检查、判断和再提示。

---

3. 一个 Loop Agent 的六个基本组件

综合 Addy Osmani、LangChain、Mem0、Firecrawl、Agent Shortlist 等文章，生产级 Loop Agent 至少需要六个组件。

3.1 Trigger：触发器

Loop 首先要知道什么时候启动。

常见触发方式：

Cron / Schedule：每天、每小时、每周固定运行；
Heartbeat：按间隔醒来，先检查有没有事，没事就睡；
Webhook / Event Hook：issue 创建、CI 失败、文件更新、Slack 消息、网页变化；
Goal Loop：给定目标后持续运行，直到目标满足或预算耗尽。

没有 trigger 的 agent 仍然只是聊天工具；有 trigger 才开始成为系统组件。

3.2 Context Assembly：上下文装配

每轮 loop 都要决定：这次 agent 应该看到什么？

典型输入包括：

当前任务；
最近日志；
上一轮失败原因；
项目规则；
相关文件；
长期记忆；
工具说明；
预算和边界。

这里有一个核心 trade-off：token-rich loop vs token-poor loop。

Token-rich loop 给很多历史和上下文，质量更稳，但慢、贵、易超上下文；
Token-poor loop 给很少上下文，快、便宜，但容易遗忘、重复劳动、幻觉增加。

Mem0 的文章强调：如果没有显式 memory，Loop Engineering 很容易退化成“在一个上下文窗口里做字符串管理”。长期状态应该放在模型外部，而不是寄希望于模型记住。

3.3 Agent Run：执行单元

Agent run 是 loop 中真正调用模型、工具和代码的部分。

它可以是：

Claude Code / Codex / OpenCode 一次任务执行；
一个 LangChain agent；
一个 Hermes subagent；
一个自定义脚本调用 LLM；
一个带工具权限的 planner / implementer / reviewer。

Loop 的关键是不要把 agent run 当成全部。Agent run 只是一轮；Loop 负责决定是否再来一轮。

3.4 Tool / Connector Layer：行动层

Loop Agent 必须能作用于真实世界，否则只是自动写文本。

常见 connector：

GitHub / GitLab；
Linear / Jira；
CI / test runner；
数据库；
Slack / Feishu；
Web search / crawler；
文件系统；
MCP servers；
内部 API。

工具越多，能力越强，但权限风险也越大。无人值守 loop 尤其需要最小权限、审计日志和高风险动作的人类确认。

3.5 Verifier / Grader：验证器

这是 Loop Agent 最重要、也最容易被低估的部分。

Firecrawl 的总结很准确：

A loop multiplies whatever judgment you put into the rubric, the skills, and the verification step.

也就是说，loop 会放大你的判断。如果 verifier 弱，loop 会以机器速度制造错误。

验证器可以是：

单元测试；
lint / typecheck；
HTTP health check；
文件存在性检查；
diff scope 检查；
事实引用检查；
rubric-based LLM judge；
reviewer agent；
human approval gate。

最差的验证方式是让同一个 agent 自己说“我完成了”。这不是验证，只是自我确认。

3.6 Durable State：外部状态

Loop 需要记住：

做过什么；
哪些失败了；
当前进度；
下一步是什么；
哪些任务已经完成；
哪些需要人介入。

这些状态应放在模型外部：

STATUS.md；
issue comment；
Linear/Jira 状态；
SQLite / Postgres；
log 文件；
trace 系统；
wiki raw note；
vector index metadata。

Addy 文章里有一句核心原则：

The agent forgets, the repo doesn’t.

对于长期 loop，这句话可以扩展成：模型会忘，外部状态不能忘。

---

4. 四种常见 Loop Agent 模式

Agent Shortlist 把生产中的 loop 归纳成四类：Heartbeats、Crons、Hooks、Goals。这个分类很好用。

4.1 Heartbeat Loop：心跳型

固定间隔醒来，先看有没有事，有事才行动。

例子：

每 10 分钟检查客服队列；
每小时检查服务错误率；
每天早上检查是否有新的论文/文章；
每 5 分钟检查后台任务是否卡住。

优点：成本可控，不需要常驻。

风险：如果没有锁，上一轮没结束下一轮又开始，会重复处理或互相覆盖。

适合：监控、队列、提醒、状态巡检。

4.2 Cron Loop：定时型

到点就运行，不一定先判断状态。

例子：

每天 9 点技术 radar；
每晚 22 点知识库日报；
每周 lint；
每月生成财务/投资复盘。

优点：预期稳定，用户知道什么时候收到结果。

风险：prompt 和 rubric 会过期。一个 cron 可能“还在运行”，但质量已经变差。

适合：日报、周报、周期性扫描、定期维护。

4.3 Hook Loop：事件型

外部事件触发 loop。

例子：

GitHub issue 创建 → agent triage；
CI 失败 → agent 分析日志并尝试修复；
文档网站更新 → agent 检查是否影响内部文档；
Feishu 群消息 → agent 处理上下文并回复；
API changelog 更新 → agent 生成迁移建议。

优点：实时、精准，不靠轮询。

风险：事件风暴、重复触发、权限误用。

适合：开发协作、告警处理、客服、文档同步。

4.4 Goal Loop：目标型

给定目标，agent 持续执行直到目标达成或停止条件触发。

例子：

“修到测试通过”；
“把这组文章 ingest 进 wiki”；
“找出最近一周 AI coding agent 的高价值文章并写总结”；
“把这个 bug 修复并开 PR”。

优点：适合开放式、多步骤任务。

风险：最容易失控，需要强停止条件。

适合：研究、代码修复、批量整理、复杂自动化。

---

5. LangChain 的“堆叠循环”视角

LangChain 的 The Art of Loop Engineering 提供了另一个有用框架：Loop 不是一层，而是可以堆叠。

5.1 Agent Loop

最内层：模型调用工具，观察结果，再调用工具，直到完成。

这是 ReAct / tool-use agent 的基本循环。

5.2 Verification Loop

在 agent 外面包一层 grader。

流程：

Agent produces output
  → Grader checks rubric/tests
  → If failed, feedback goes back to agent
  → Retry until pass or limit hit

这是生产级 agent 的基本门槛。没有 verification loop，就很难从“能跑”走向“可靠”。

5.3 Event-driven Loop

把 agent 接入真实系统，让它由 cron、webhook、消息、文件变化等事件触发。

这一步让 agent 从“手动调用工具”变成“后台系统组件”。

5.4 Hill-climbing Loop

更高一层：用 agent run 的 trace 反过来改进 agent 自己的 harness、prompt、工具或 grader。

例如：

分析过去 100 次失败；
发现某类工具描述导致误用；
自动开 issue 修改 tool schema；
调整 rubric 或 prompt。

这是 AutoResearch / self-improvement loop 的方向，但风险也更高：如果 evaluator 错了，系统会自动朝错误方向优化。

---

6. 什么任务适合做成 Loop Agent

不是所有任务都值得 loop 化。一个任务至少要满足三个条件。

6.1 重复性

你会经常做，或者任务会持续出现。

一次性任务通常不值得写 loop；直接让 agent 做完即可。

6.2 可验证性

必须能定义“完成”的外部信号。

例如：

测试通过；
链接无 404；
引用都存在；
文件生成；
指标超过阈值；
人类批准。

如果没有可验证标准，loop 不知道什么时候该停。

6.3 价值密度

结果要值得消耗 token、时间、API 调用和工程维护成本。

如果任务很低价值，自动化只会制造低价值噪音。

一个简单判断：

任务如果“重复、可验证、有价值”，就可能适合 Loop Agent；缺一项，就先不要 loop 化。

---

7. Loop Agent 的主要风险

7.1 无限循环

没有停止条件，或者停止条件无法被可靠检测，agent 会一直尝试。

最低限度要有：

最大轮数；
最大时间；
最大 token / dollar 预算；
no-progress 检查；
hard stop。

7.2 错误被放大

Loop 会把验证标准、prompt、权限设计中的错误快速放大。

如果 rubric 本身错了，agent 会努力满足错误目标。

7.3 Verifier 被骗或误判

LLM judge 可能被表面文字骗过；测试也可能覆盖不足。

关键任务应组合多个 verifier：确定性检查 + LLM reviewer + human gate。

7.4 成本失控

Cron、subagent、verifier、web search、embedding 都会消耗成本。Goal loop 尤其容易烧 token。

要给每个 loop 设置预算，并在日报/日志里暴露成本。

7.5 权限过大

无人值守 agent 如果拥有删除数据、发消息、部署生产、修改账单等权限，风险会显著增加。

默认策略应是：读多写少，高风险动作需要审批。

7.6 理解债

agent 跑得越快，人越可能不知道系统实际变成了什么。

这就是 Addy 最后提醒的重点：

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

Loop Engineering 不是把责任交给系统，而是把责任提升到系统设计层。

---

8. 一个最小可行 Loop Agent 模板

下面是一个通用模板，可以套到技术 radar、代码修复、知识库 ingest、服务巡检等任务上。

Loop Name: <名称>

1. Trigger
   - cron / heartbeat / webhook / manual goal

2. Input Source
   - 从哪里拿任务或信号？
   - web search / GitHub issues / CI logs / Feishu / RSS / database

3. Rubric
   - 什么算值得处理？
   - relevance / novelty / durability / actionability / source_quality
   - 或 test pass / lint pass / no broken links

4. Context
   - 需要读哪些规则、wiki、历史日志、状态文件？

5. Agent Role
   - explorer / implementer / summarizer / verifier / publisher

6. State
   - raw note / STATUS.md / log.md / issue comment / DB row

7. Verification
   - deterministic checks
   - second agent review
   - human approval if risky

8. Stop Condition
   - 完成条件
   - 最大轮数
   - 最大预算
   - no-progress stop

9. Output
   - PR / article / digest / wiki update / alert

10. Escalation
   - 什么时候找人？
   - 权限不足、验证失败、成本超限、内容不确定

这份模板的关键是：先写停止条件和验证标准，再写 prompt。

很多失败的 loop 都是因为顺序反了：先让 agent “持续努力”，最后才想起来没有定义什么叫完成。

---

9. 对 Hermes / LLM Wiki 的落地启发

你的现有系统里已经有几个 Loop Engineering 的雏形。

9.1 知识库日报是 Cron Loop

每天固定时间运行：

扫描 wiki 状态；
统计文档数、wikilink、向量索引；
找最近新增/修改；
生成飞书摘要。

它的 loop memory 是文件系统和 cron 输出；它的 verifier 是脚本输出和索引状态。

这类 loop 的下一步优化不是“让模型更会写日报”，而是：

检查统计脚本是否覆盖新目录结构；
发现统计异常时自动报警；
定期 audit prompt 是否过期；
加入成本、失败、delivery error 监控。

9.2 Karpathy X Radar 是 Research Loop

它每天：

orient 现有 wiki；
尝试 xurl 或 web_search；
按 relevance / novelty / durability / actionability / source_quality 打分；
写 raw note；
高价值时更新 wiki；
最后发 digest。

这个 loop 的问题也很明显：技术 radar 现在过度围绕 Karpathy 一个人，容易视野收窄。

扩展方式不应该是“再建 20 个单人 cron”，而是改成 multi-source technical radar loop：

人物：Karpathy、Lilian Weng、Simon Willison、Swyx、Addy Osmani、Peter Steinberger、Boris Cherny、Anthropic / OpenAI / Google DeepMind 工程博客作者；
组织：Anthropic、OpenAI、Google DeepMind、LangChain、Hugging Face、Modal、Cloudflare、Vercel、Cursor、Sourcegraph；
主题：agentic coding、loop engineering、harness engineering、evals、context engineering、AI infra、MCP、skills、codebase understanding；
来源：official blog、GitHub releases、arXiv、Hacker News、engineering blogs、high-quality newsletters，而不是只盯 X。

这样 radar 的单位从“某个人今天说了什么”升级为“某个技术主题最近有什么高质量进展”。

9.3 Wiki Ingest 是 Goal Loop

当你说“把这本书/这批文章 ingest 进去”，这其实就是目标型 loop：

解析文件；
提取章节；
识别概念/实体；
创建/更新页面；
更新 index/log；
重建向量索引；
lint；
总结输出。

这里最重要的 verifier 是：

文件是否存在；
页面是否有 frontmatter；
wikilink 是否断；
index/log 是否更新；
vector index 是否覆盖；
是否制造了重复页面。

这比“读完然后总结一下”更接近真正的 Loop Engineering。

---

10. 技术 Radar 如何从“一个人”扩展成 Loop Agent

你刚才问“现在技术类 radar 都是一个人吗，怎么拓展”。结论是：当前 AI 技术 radar 的主 cron 确实主要是 Karpathy X Radar；另有 weekly skill radar，但它关注 Hermes skills 生态，不是通用技术 radar。

更好的设计是三层：

10.1 Source Layer：来源池

维护一个 technical-radar-sources.md，按类型列来源：

People；
Labs / Companies；
Blogs / Newsletters；
GitHub repositories；
arXiv / Papers；
Benchmarks；
Tool ecosystems。

每个来源带字段：

name:
type: person | org | blog | repo | keyword
url:
topics:
priority: high | medium | low
scan_frequency: daily | weekly | monthly
last_checked:
notes:

10.2 Topic Layer：主题雷达

每天不扫所有人，而是按主题跑：

周一：AI coding agents / Claude Code / Codex / Cursor；
周二：Agent architecture / Loop / Harness / Context；
周三：Evals / Benchmarks；
周四：MCP / Tools / Skills；
周五：AI infra / serving / observability；
周末：长文深读 / wiki consolidation。

这样可以避免每天被单一人物的信息流牵着走。

10.3 Ingest Gate：落库门槛

所有候选内容统一过 gate：

维度	问题
relevance	和你的 AI 工程/agent/wiki 方向相关吗？
novelty	是否提供新概念、新证据、新工具？
durability	一周后还有价值吗？
actionability	能否转化为实践、skill、workflow 或 checklist？
source_quality	是否一手来源、工程实战、可验证？

低分内容只进 daily note，不污染 wiki；高分内容才 deep ingest。

这就是一个更好的 Loop Agent：不是追热点，而是持续扩展知识图谱。

---

11. 最后判断

Loop Agent 是 agent 工程从“对话界面”走向“后台系统”的关键范式。

但它不是魔法，也不是简单地让模型一直跑。真正有用的 Loop Agent 有几个共同点：

目标可验证：没有 verifier 就没有可靠 loop；
状态在模型外部：模型会忘，文件/数据库/log 不该忘；
权限受控：自动化越强，权限越要小；
预算明确：每个 loop 都要知道最多能烧多少钱和多久；
失败可恢复：失败后不是继续胡跑，而是重试、降级、找人；
输出可审计：每一轮为什么做、做了什么、凭什么判断完成，都要留下证据；
人仍然负责设计：Loop 替代重复 steering，不替代工程判断。

我对 Loop Engineering 的一句总结是：

Prompt Engineering 优化一句话，Context Engineering 优化一轮输入，Harness Engineering 优化一次行动，Loop Engineering 优化一个会持续行动的系统。

它的价值不在于“无人值守”，而在于把原本散落在人脑和聊天记录里的工作流，变成可复用、可验证、可审计、可改进的工程系统。

---

参考资料

Addy Osmani, Loop Engineering

https://addyosmani.com/blog/loop-engineering/

LangChain, The Art of Loop Engineering

https://www.langchain.com/blog/the-art-of-loop-engineering

Mem0, Loop Engineering for AI Agents: Memory-First Design

https://mem0.ai/blog/loop-engineering-for-ai-agents-memory-first-design

Agent Shortlist, Loop Engineering: How to Design Self-Prompting AI Agents

https://agentshortlist.com/articles/loop-engineering

Firecrawl, Loop Engineering: Should You Stop Prompting Agents and Start Designing Loops

https://www.firecrawl.dev/blog/loop-engineering

本地 LLM Wiki：Loop-Engineering.md、Loop-Engineering-vs-Harness-Engineering.md