所谓循环工程（Loop Engineering），其本质在于将你——那个曾经亲自为编程智能体逐字撰写提示词的人——从一线操作中抽离出来。取而代之的，是你构建一个能够自主调度、提示并驱动智能体的自动化系统。这个“循环”并非简单的重复，而是一种具备递归目标的智能流程：你只需设定最终目标，AI 就会不断尝试、评估、调整，直至任务真正完成。
当前，这一范式已初具雏形，其核心由五大模块构成，而主流工具如 Claude Code 与 Codex 均已原生支持这些能力。尽管前景诱人，我们仍需保持审慎：该模式尚处早期阶段，Token 成本敏感度高（资源宽裕与紧张时策略截然不同），且必须建立有效的质量保障机制，以防输出流于表面或产生“垃圾代码”。
正如开发者 @steipete 所言：“别再直接给智能体写提示了，去设计能自动提示它的循环。” Anthropic 的 @bcherny 也表达了类似观点：“我不再手动提示 Claude，而是让运行中的循环来提示它，并决定下一步行动——我的工作是编写这些循环本身。”
这标志着人机协作方式的根本转变。过去两年，我们与编程智能体的互动基本停留在“写提示 → 看结果 → 再写提示”的线性交互中，人类始终是握着工具的手。如今，这种模式正被更高级的系统化协作所取代：你不再逐轮触发智能体，而是部署一个微型自治系统——它能主动发现任务、分配工作、验证成果、记录进展，并自主决策后续步骤。
这种思路可视为对“智能体运行框架”（agent harness）和“软件工厂模型”（factory model）的进一步抽象与升级。它不仅支持定时执行、动态生成辅助智能体，还能通过反馈实现自我优化。更令人惊喜的是，一年前实现此类循环还需大量自研脚本（如 Bash 脚本）并持续维护，如今这些能力已被深度集成进产品本身。无论是 Codex 还是 Claude Code，其底层架构高度一致，这意味着开发者可以专注于设计通用循环逻辑，而不必被具体平台绑定。
循环系统的五大支柱与记忆中枢
一个健壮的循环系统依赖五个关键组件，外加一个持久化记忆机制：
- 自动化任务（Automations）：作为系统的“心跳”，按预设节奏自动触发流程，执行信息采集、问题分类等例行工作。
- 工作树（Worktrees）：通过隔离的工作区，允许多个智能体并行处理同一代码库而互不干扰。
- 技能（Skills）：将项目特有的规则、上下文和最佳实践封装成可复用的知识单元，避免智能体每次“从零开始”猜测意图。
- 插件与连接器（Plugins & Connectors）：打通智能体与外部工具链（如 Jira、Slack、数据库），使其能在真实环境中执行操作，而非仅提供建议。
- 子智能体（Sub-agents）：拆分角色，例如一个负责编码，另一个专司审查，通过对抗性协作提升输出可靠性。
第六项——记忆——虽看似简单（可能只是一个 Markdown 文件或 Linear 看板），却是长期运行的关键。因为大模型不具备跨会话记忆，所有状态必须持久化到磁盘。正所谓：“模型会遗忘，但仓库不会。”
各模块详解：从理论到实践
自动化任务：让流程真正“循环”起来
Codex 提供图形化 Automations 配置界面，支持按频率调度任务，并智能归档或标记异常。Claude Code 则通过 /loop 和 /goal 实现类似功能：前者周期性执行，后者持续运行直至满足终止条件（如“所有测试通过”）。尤为关键的是，/goal 在每轮结束后调用独立轻量模型进行校验，实现“执行-验证”分离，极大提升可靠性。
工作区隔离：解决并发冲突
多智能体同时编辑文件极易引发冲突。Git 工作树机制为此提供天然解决方案——每个任务在独立目录中运行，共享历史但互不干扰。Codex 内置此能力，Claude Code 则通过 --worktree 参数或配置项实现同等效果。但需注意：工具能解决技术冲突，人的审核带宽才是并行规模的真正瓶颈。
技能模块：固化项目智慧
通过标准化的 SKILL.md 文件，将项目上下文、构建指令、特殊约束等沉淀下来。智能体在运行时自动加载相关技能，避免重复解释或意图偏差。这不仅提升效率，更形成“知识复利”。技能可进一步打包为插件，便于跨项目复用。
连接器：打通现实世界
基于 MCP 协议的连接器使智能体能操作真实系统：创建工单、推送通知、查询数据等。Codex 与 Claude Code 均兼容该协议，插件可跨平台使用。这让循环从“纸上谈兵”升级为“动手实干”——不仅能建议修复，还能自动提交 PR 并通知团队。
子智能体：引入制衡机制
让不同智能体扮演不同角色（探索者、实现者、审查者），利用视角差异发现盲点。Codex 与 Claude Code 均支持通过配置文件定义子智能体，指定模型、指令与权限。虽然会增加 Token 消耗，但在关键路径上引入二次校验，是无人值守场景下的必要投资。
一个典型循环实例
设想这样一个日常流程：
每天凌晨，自动化任务启动，调用“问题分拣”技能，分析昨日 CI 失败、未关闭 Issue 和新提交。结果写入状态文件或同步至 Linear。对每个待办项，系统拉起隔离工作区，派遣两个子智能体——一个写修复代码，另一个依据项目规范和测试用例进行审查。若通过，自动创建 PR 并更新工单；若失败，则归入人工待办队列。次日，循环从断点继续。
整个过程无需人工干预，一次设计，长期受益。而这正是“让循环提示智能体”理念的落地体现。
循环不会取代你，但会放大你的选择
尽管循环工程提升了自动化水平，但它绝非万能解药，反而凸显了三个更严峻的挑战：
- 验证责任仍在你肩：无人值守 ≠ 无错运行。“任务完成”只是系统判断，不代表代码可靠。你仍需确保交付的是经你确认可运行的代码。
- 认知负债风险加剧：当系统快速产出你未曾亲手编写的代码，你对系统的理解可能滞后，形成“认知断层”。若不主动阅读、消化生成内容，高效反而加速失控。
- 思维惰性陷阱：过度依赖自动化易导致“认知躺平”——放弃批判性思考，全盘接受输出。此时，循环不再是工具，而成了逃避责任的借口。
因此，构建循环不是终点，而是新起点。它要求你以资深工程师的严谨去设计系统架构，而非仅做一个点击“运行”的操作员。同样的循环，在不同人手中，可能成为提效利器，也可能沦为技术债温床。
未来已来，但方向盘仍在你手。
共同学习，写下你的评论
评论加载中...
作者其他优质文章
