本文永久链接 – https://tonybai.com/2026/07/07/how-to-create-loops-with-claude-code
大家好，我是Tony Bai。
在上两篇中，我们先后探讨了 Andrej Karpathy 关于长程运行的 Agent 的核心理念《LOOPS.md》，以及 20 个极具启发性的“LOOP 设计模式”。
这些前沿理论无一不在昭示着一个事实：AI 开发的下半场，是属于“循环（Loops）”的。
然而，理论再性感，无法落地也只是空中楼阁。基于 Anthropic 推出命令行工具 Claude Code，以及各大厂商纷纷跟进 Agentic 开发者工具，我们有了可以直接上手构建“Loop”的利器。
今天翻译的这篇实战指南，同样来自技术专家 Rahul (@sairahul1)。他将手把手教你如何利用极简的“4文件系统”和权限控制阶梯，在 Claude Code（或任何主流 LLM 开发环境）中无缝搭建一套“睡后运行”的自动化循环系统。
无论你是想做每日代码库自动审计、CI/CD 错误自动排查，还是想让 AI 自动跟踪你的项目进度，这套保姆级的实战模板都能让你直接复制粘贴、即刻上线。
以下为译文全文：
目前，绝大多数人使用 Claude 的工作流，依然是“一锤子买卖（One-shot）”。
你写一段 Prompt -> Claude 给出回复 -> 会话结束。
明天，一切又得从零开始。
对于一次性的简单任务，这种方式完全没问题。
但对于高频重复的工作——比如每日项目审查、CI/CD 故障排查、项目进度监控——这就称不上是一个“工作流”了。这充其量只是在传统的体力劳动上，撒了一点 AI 调味料。
更好的抽象设计，应该是构建一个“循环（Loop）”。
建议收藏本文，你绝对用得上。
什么是真正的 “Claude 循环”？
循环绝对不等于“重复地去问 Claude 相同的问题”。
循环，是围绕大模型构建的一套可复用的工作流结构。
它明确定义了：
- 什么事件触发了这次运行（Trigger）
- 在行动之前，Claude 需要读取哪些上下文（Context）
- 系统的最新状态保存在哪里（State）
- 什么时候该停下来、什么时候重复运行，以及什么时候该请求人类介入（Decision）
模型依然负责底层的推理（Reasoning），但循环为它提供了运转的框架结构（Operating Structure）。
这种转变至关重要。因为 Claude 的 Session（会话）是临时性的。没有循环，每一次运行都是从零开始；而有了循环，Claude 能够读取上一次发生的事，并在上一次停下的地方完美接棒。
每一个 Claude 循环都不可或缺的 6 个要素
一个缺乏结构的循环，不过是一个被运行了两次的普通 Prompt 而已。
要让一个循环真正跑起来，必须具备以下 6 个核心拼图：
1. 触发器（Trigger）
- 定义：是什么启动了这次运行？
- 示例：手动命令、定时任务（Cron）、文件变更、CI 构建失败、Git 提交事件。
2. 上下文（Context）
- 定义：在采取行动(action)之前，Claude 需要阅读并知晓哪些上下文背景信息。
3. 行动（Action）
- 定义：Claude 具体要干什么？
- 示例：撰写总结报告、草拟 Bug 修复方案、对错误日志进行分类、更新项目文档。
4. 验证（Verification）
- 定义：你如何校验执行结果的质量？
- 示例：核对清单（Checklist）、测试用例集、必备章节审查、安全边界检查。
5. 状态更新（State Update）
- 定义：下一次运行需要记住什么？
- 示例：更新
PROGRESS.md、记录当前的 Blockers（阻碍项）、为下一次运行留下指南。
6. 决策（Decision）
- 定义：下一步该怎么做？是继续运行、停下来，还是升级给人类（Escalate）？
在整个闭环中，每一步都生死攸关：
- 漏掉“验证” -> 循环就会盲目地自信，容忍垃圾代码产出；
- 漏掉“状态” -> 每次运行都会退化为从零开始；
- 漏掉“决策” -> 整个循环将沦为不知道何时停下的死循环。
极简“4文件系统”：无需任何复杂架构
你根本不需要配置复杂的数据库和后台系统，只需要在你的项目目录下新建 4 个 Markdown 文件：
my-loop/
├── TASK.md
├── LOOP_INSTRUCTIONS.md
├── PROGRESS.md
└── outputs/
└── daily-review.md
- TASK.md（终极任务）：明确这个循环的终极目标是什么。
- LOOP_INSTRUCTIONS.md（操作标准 SOP）：详细规定 Claude 应该如何运行、允许做什么、禁止做什么、以及如何验证结果。
- PROGRESS.md（记忆与状态）：记录上一次发生了什么、有什么被卡住了、以及下一次运行应该聚焦在什么地方。
- outputs/（产出目录）：存放最终产出的物理文件。
就是这么简单。
Claude 在每次运行开始前，会读取这些文件；在结束运行前，会更新这些文件。下一次运行启动时，它便能完美实现断点续传。状态存在于聊天窗口之外，这就是循环与普通 Prompt 调优的本质区别。
第一步：编写 TASK.md — 明确定义终极目标
这个文件告诉 Claude 这个循环是干嘛的。
保持高层次（High-level）的宏观描述，不要把具体的操作细节写在这里，那是 LOOP_INSTRUCTIONS.md 的工作。
你可以直接复制这个模板：
# 每日项目审查循环
## 目标（Goal）
审查当前项目文件夹，总结变更内容，识别当前的阻碍项（Blockers），并输出一份简短的每日审查报告。
## 预期输出（Expected Output）
每次运行应当产出或更新：
- `outputs/daily-review.md`
- `PROGRESS.md`
## 权限与范围（Scope）
Claude 允许检查当前工作区的文件并写入：
- 禁止删除或重命名文件
- 禁止直接发送消息或开 Ticket
请特别注意最后一节。任何循环的第一版，都必须有明确的“禁止行为（Do Not）”规则。这不是因为不信任 Claude，而是合格工程师的职业素养。
第二步：编写 PROGRESS.md — 循环的持久化记忆
这是整个系统中最灵魂的文件。
没有它，每一次运行都是盲目的。有了它，Claude 才能拥有跨越会话的记忆。
# Loop 运行进度表
## 当前状态（Current State）
- 状态：运行中（Active）
- 核心任务：每日项目审查
- 当前聚焦：[写下目前最重要的工作]
- 上次更新时间：[日期]
## 上次运行记录（Last Run）
- 日期：
- 摘要：
- 审查过的文件：
- 产出的结果：
## 未解决事项（Open Items）
-
## 阻碍项（Blockers）
-
## 需人工介入（Needs Human Review）
-
## 下次运行聚焦（Next Run Should）
-
## 已做出的决策（Decisions Made）
-
- “未解决事项（Open Items）”和“阻碍项（Blockers）”极度关键：它们防止 Claude 去愚蠢地重复尝试那些已经证明失败了的方案。
- “需人工介入”极度关键：当系统遇到无法解决的问题时，它能让整个循环优雅地暂停，并向人类求助，而不是硬着头皮悄悄把事情搞砸。
两条保持 PROGRESS.md 高效运转的铁律：
- 如果信息是 Claude 决定下一步行动所必须依赖的 -> 保留在
PROGRESS.md中。 - 如果信息仅仅是为了留档查看的备份记录 -> 移动到
outputs/history/文件夹中。
永远膨胀的状态文件等同于无用。请把 PROGRESS.md 当作控制面板（Control Panel）来维护，而不是当作无休止的历史档案馆。
第三步：编写 LOOP_INSTRUCTIONS.md — 标准操作规程（SOP）
这个文件精细控制着 Claude 的行为：该读什么、该写什么、什么东西绝对不能碰，以及在停止前如何进行质量自我验证。
实测表现最稳定的一套模板：
你当前正在执行【每日项目审查循环】。
## 启动准备（Before You Start）
1. 读取 `TASK.md`
2. 读取 `PROGRESS.md`
3. 检查项目当前的主文件夹
4. 识别出发生了哪些变更、哪些部分还没写完、哪些地方需要人工介入
## 标准操作流程（What You Should Do）
撰写一份简短的每日审查报告，并写入 `outputs/daily-review.md`，内容包含：
- 当前整体状态总结
- 审查过的文件列表
- 产生的实质性变更
- 当前遇到的阻碍项或未解决的疑问
- 建议的下一步动作
写完报告后，立即更新 `PROGRESS.md` 中的以下项：
- 本次运行日期
- 本次工作摘要
- 检查过的文件
- 下次运行的建议焦点
- 是否需要人工介入审查
## 安全与红线规则（Safety Rules）
- 严禁删除任何文件
- 严禁重命名或移动任何文件
- 严禁擅自修改任何源代码文件
在结束本次运行前，必须确认以下事项：
- `outputs/daily-review.md` 已生成，且包含所有必备章节
- `PROGRESS.md` 已被成功更新
- 没有任何安全红线以外的文件被擅自修改过
## 异常失败策略（Failure Policy）
如果自我验证（Verification）失败：
1. 报告中缺失部分章节 -> 尝试修复一次。
2. PROGRESS.md 未更新 -> 尝试更新一次。
3. 发现有红线外的源码文件被修改 -> 立即无条件终止运行（Stop Immediately）。
4. 相同的校验连续失败两次 -> 停止运行，将状态标记为“需要人工审查”。
注意底部的异常失败策略（Failure Policy）。大多数人设计的 Agent 没有任何失败退路，一旦出错，AI 只能当场胡乱发挥。优秀的循环，必须明确定义好失败后的退出机制。
别急着自动调度，先进行手动测试
在把循环放进定时任务之前，先手动跑通。
在工作区目录打开 Claude Code（或 Claude 桌面客户端），输入以下手动提示词：
请运行当前工作区的每日项目审查循环。
严格遵循 `LOOP_INSTRUCTIONS.md` 的要求。
在采取任何行动前，请先完整阅读：
- `TASK.md`
- `PROGRESS.md`
- `LOOP_INSTRUCTIONS.md`
接着检查当前工作区，将每日审查结果写入 `outputs/daily-review.md`，并在停止运行前更新 `PROGRESS.md`。最后执行自我校验清单，并向我汇报发生了哪些变更。
除了 `outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
检查产出的两个文件是否完美。如果格式和内容都正确，说明循环逻辑走通了。
接下来，手动模拟 3-5 次项目变更：
在目录里增加一个临时笔记、在 PROGRESS.md 里手动写一个阻碍项、改动一点代码。然后重新运行上面的指令，观察 Claude 能否完美读取上一次留下的状态，做到“断点续传”。
验证（Verification）：绝大多数人忽略的关键漏洞
这是整套 Agent 运行机制中，几乎所有人都在悄悄隐瞒的失败模式：
Claude 跑完了循环，自信满满地向你汇报它已经全部搞定了，接着更新了状态文件，然后利落地停止了运行。
你打开目录，一切看起来似乎都毫无破绽。
然而事实却是：最终生成的报告里，其实漏掉了几个必不可少的硬性章节；或者 PROGRESS.md 只是被敷衍地涂改了两笔，根本没有写入实质性进度；甚至更糟糕的是，Claude 在你看不见的地方，悄悄修改了一个根本不该碰的源码文件。
而这些致命的失误，你往往只有在系统彻底跑崩、或者项目上线报错的那一刻才会痛苦地发现。
这就是为什么验证（Verification）必须作为独立的一环存在。
一个优秀的循环之所以会停下来，绝对不是因为模型“觉得写完了”，而是因为某一个具体的、硬性的约束条件通过了校验。
优秀的“验证模式”应该如何设计？
独立运行一个专门的“验证步骤”：来审查最近一次(latest)循环的执行结果。
对照标准进行体检：严格根据 LOOP_INSTRUCTIONS.md 中写明的“验证清单（Verification Checklist）”来核对输出结果。
生成一份详尽的体检报告，内容必须包含以下 5 个硬性指标：
- 哪些检查项顺利通过了？
- 哪些检查项判定失败了？
- 此次运行，具体有哪些文件被修改过？
- 当前的运行结果是否可以被安全地整体接收？
- 是否存在必须留给人类进行人工确认的疑点？
在执行此验证步骤期间，验证器严禁修改工作区内的任何文件。
干活的与监工的，必须彻底分离。
先让“工人”（Worker）干活。干完之后，再让“监工”（Verifier）入场。两者必须分属不同的会话或不同的提示词逻辑。
因为监工需要一套绝对黑白分明的“通过/不通过”的标准。
- 弱验证（这根本不算验证）：
“帮我看看这个结果，告诉我它看起来怎么样，行不行？”
- 强验证（这才是真正的验证）：
“严格对照这 7 条硬性指标进行体检，只有在 7 条指标全部亮绿灯（PASS）的情况下，才允许将这次运行标记为‘接受（Accepted）’。”
使用/loop 自动化定时运行（Scheduler）
当你在手动模式下反复验证，系统表现极度稳定之后，就可以将它托付给自动化了。
在 Claude Code 中，直接使用自带的 /loop 命令行工具：
/loop 24h 请为当前工作区运行每日项目审查循环。
严格遵循 `LOOP_INSTRUCTIONS.md`。
先阅读 `TASK.md` 与 `PROGRESS.md`。
将审查报告写入 `outputs/daily-review.md`，并在退出前更新 `PROGRESS.md`。
执行验证 checklist。
若无 meaningful 变更，保持报告简短。
若需要人工介入，在 `PROGRESS.md` 中进行显式标记。
除了`outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
其中可选的时间间隔包括：
/loop 15m：测试节奏（在观看过程中使用）/loop 1h：每小时监控/loop 24h：每日定时运行/loop 7d：每周例行整理
敲黑板：
/loop自身不是魔法。它仅仅是一个帮你自动按时发送 Prompt 的定时器。一个循环系统的真正生命力，完全来自于你在 Prompt 之外所设计的 4 文件结构、SOP 指南、强验证机制和状态持久化。
此外，你还需要了解另一个强大的内置命令 /goal：
/loop：代表基于时间触发（因为时间到期了，所以再跑一次，适合做日常监控、日报生成）。/goal：代表基于状态/目标触发（不达目标不停下，比如：直到通过所有测试用例前，不断尝试修复 Bug）。
/goal outputs/daily-review.md exists, PROGRESS.md is updated,
verification checklist passes, no forbidden files modified.
建立权限控制阶梯（The Permission Ladder）
很多人在构建 Loop 时，一上来就给 AI 开放最高权限：让它自由地往 Slack 发消息、直接合并代码到 Master 分支、自动关闭工单。
一旦发生幻觉，后果就是一场毁灭性的车祸。
你应该使用“权限控制阶梯”，逐步放权：
第 1 级 - 只读（Read Only）：AI 只能读取文件、工单、日志，无法做任何修改。
第 2 级 - 输出草稿（Draft Outputs）：AI 只能在指定的 `outputs/` 目录下生成草稿报告，严禁与外界发生任何交互。
第 3 级 - 沙盒修改（Sandbox Edits）：AI 被允许在完全隔离的 Docker 容器或 Git 临时分支或Worktree上尝试修改源码。
第 4 级 - 外部动作草稿（Draft external Actions）：AI 准备好 PR 描述、草拟好 Slack 消息，但绝不发送，等待人类最后点击确认。
第 5 级 - 人类授权动作（Human-approved actions）：只有在人类显式授权后，才能实施修改。
第 6 级 - 授权低风险自动化（Automated Low-risk）：在有严格日志、范围限制和回滚（Rollback）方案的前提下，允许 AI 自动执行窄领域的低风险任务。
你的第一个循环系统，必须老老实实呆在第 1 级或第 2 级。
这绝不意味着系统无能，恰恰相反，这是极度成熟的工程化体现。即使是前两级的循环，仍然具有巨大的价值。
Claude 可以检查你的 GitHub 问题，查看持续集成中的失败情况，审核 Pull 请求，并汇总所有相关信息——而无需直接接触那些重要的文件或数据。
首先，请证明该循环在 2 级时能够正常工作。
然后判断它是否值得获得三级评级。
当循环走入歧途（以及如何阻止它）
这是大多数人最容易踩坑的地方。
一个反面教材（糟糕的初始循环设计）：
“每天持续优化产品战略文档，直到觉得它变得更强大。”
这个设计之所以糟糕，是因为：
- 没有终止条件（No stop condition）
- 没有验证机制（No verification）
- 没有状态记录（No state）
- “觉得更强大”无法作为客观的核对清单（Checklist）条款。
这样一个失控的循环，要么什么有用武之地的事情都做不成，要么会在后台把你根本不想改动的文件改得面目全非。
一个优秀的循环：
- 每周五，审查产品策略文档。
- 识别出本周内发生过变动的动作（Actions）。
- 列出所有尚未解决的假设（Assumptions）。
- 撰写一份格式规范的结构化评审文件，并写入
outputs/strategy-review.md。 - 严禁直接修改产品策略源文档。
这个设计之所以优秀，是因为它具备了：
- 明确的定时运行计划（Clear schedule）
- 被严格限制的执行范围（Limited scope）
- 可预测的目标输出文件（Predictable output file）
- 绝对安全的权限边界（Safe permission boundary）
这其间的差距，根本不在于模型的“智商（Intelligence）”，而在于你的“系统设计（Design）”。
摧毁循环系统的 5 大致命死穴
请在执行你的第一条 /loop 命令前，务必排查并解决这五个问题：
- 在手动测试通过前，就直接部署了自动调度运行。
- 没有配置状态文件（Memory） —— 导致每一次运行都像失忆一样，被迫从零开始。
- 没有引入验证机制 —— 循环选择无条件、盲目地信任自己。
- 没有配置失败应对策略（Failure Policy） —— 一旦遇到意外，只能任由 AI 在后台即兴胡乱发挥。
- 过早地给 AI 接入了太多工具 —— 这会导致系统一旦出错，其破坏半径（Blast Radius）会呈指数级扩大。
添加工具和连接器
一旦本地的单机循环运行稳定后，你才可以考虑逐步为它扩展外部连接：GitHub、Slack、Linear、Jira、CI 日志等。
但是，每增加一个新工具，都会相应地扩大系统的破坏半径。
请遵循完全相同的工程原则：先只读，再草拟，只有在经历过反复、多次成功的运行后，才放开写入权限。
你需要在 LOOP_INSTRUCTIONS.md 中，为特定的工具配置极其详尽的规则：
## 工具权限管理策略（Tool Permissions Policy）
### GitHub
允许的行为（Allowed）：
- 读取公开/未解决的 Issues
- 读取 Pull Request 的状态
- 读取 CI 的构建状态
- 在 `outputs/github-review.md` 中草拟摘要总结
禁止的行为（NOT allowed）：
- 在未经人类审核前，直接在公开讨论区发表评论
### Slack
允许的行为（Allowed）：
- 在 `outputs/slack-update.md` 中草拟消息内容
禁止的行为（NOT allowed）：
- 直接发送 Slack 消息
- 擅自 @ 提及用户
- 擅自往公共频道发帖
### Linear / Jira
允许的行为（Allowed）：
- 读取分配给当前用户的任务工单（Tickets）
- 在指定目录下草拟建议的更新内容
禁止的行为（NOT allowed）：
- 擅自修改工单状态
- 擅自关闭工单
- 在未经人类审核确认前，创建新工单
如果遇到任何未在上述策略中列出的工具，立即停止运行，并向人类寻求审核。
这项安全机制，能提供一道坚实的防火墙，保护你的系统不会在后台做出你意料之外的事情。
一个完整的循环系统长什么样？
以下是你可以从零开始直接复制的完整配置：
1. 创建配置文件
首先，建立 LOOP_INSTRUCTIONS.md 并在其中声明基础工具策略：
## 工具权限管理策略（Tool Permissions Policy）
### GitHub
允许（Allowed）：
- 读取 open 状态的 issues
- 读取 pull request 状态
- 读取 CI 状态
- 关闭 issues
- 在未经批准前，允许在公开区域进行非评论类操作
... (其余工具策略同上文)
随后，根据前文提供的模板，填满 TASK.md、PROGRESS.md 和 LOOP_INSTRUCTIONS.md。
2. 手动启动运行
运行以下提示词来手动触发任务：
在采取行动前，请先完整阅读 TASK.md、PROGRESS.md 以及 LOOP_INSTRUCTIONS.md。
将每日审查报告写入 `outputs/daily-review.md`。
在停止运行前，务必更新 `PROGRESS.md`。
执行自我验证核对清单。
除了 `outputs/daily-review.md` 和 `PROGRESS.md`，严禁修改任何其他文件。
3. 手动触发验证
运行以下提示词来进行独立验证：
请执行一次验证过磅（Verification Pass）。
严格对照 `LOOP_INSTRUCTIONS.md` 中的“验证清单”进行逐项检查。
向我汇报：哪些检查通过了、哪些失败了、有哪些文件被改动过，以及是否需要人类介入审查。
在此期间，严禁修改任何文件。
在手动模拟微小的项目变更、并反复运行上述流程 3 到 5 次之后。
4. 部署自动调度
如果你确认它的表现已经无懈可击，即可配置定时任务：
[使用与上述手动运行完全相同的提示词，但在其最前面加上 /loop 24h 前缀]
在自动运行的第一周，请务必对每一次输出结果进行人工复审，确认无误后再完全信任它。
这就是一套完整的、生产级循环系统的生命周期。
变革时刻：引入循环前后的世界线对比
在引入“循环工程”之前：
- 你手动写下了一句 Prompt。
- Claude 给你做了解答。
- 到了第二天，你不得不把相同的 Prompt 重新润色后再发一遍。
- Claude 根本没有关于昨天历史记忆。
- 你必须用自己的肉眼，去人工跟踪发生了哪些文件变化。
- 每次会话一结束，所有的上下文状态立即清空重置。
在引入“循环工程”之后：
TASK.md一次性向系统声明了终极目标。PROGRESS.md跨越不同的会话，完美传递运行状态和记忆。LOOP_INSTRUCTIONS.md如同法律般死死控死 AI 的行为。- Claude 自动完成“读取、执行、验证、更新、停止”的闭环。
- 第二天醒来，它能精准地在昨天留下的脚印处继续前进。
- 你再也不用审查 Prompt 了，你只需要审查它交付的输出成果（Outputs）。
至此，系统的瓶颈已经彻底从“如何生成代码/文案”，转移到了“如何更好地去审查和验证代码/文案”。
你真正地设计出了一套无需你肉身盯防、自己就能持续运转的自动化系统。
你在这周就可以动手构建的 10 个实用循环
- 每日项目审查（Daily project review）：自动审视工作区，撰写每日变动与进度小结。
- 会议跟进行动提取器（Meeting follow-up extractor）：自动将散乱的会议纪要转化为具体的 Action Items。
- 文件夹清理规划师（Folder cleanup planner）：自动分析杂乱目录，提出整理建议，但不擅自改动源文件。
- CI/CD 构建失败排查器（CI failure triage）：自动拉取失败日志，进行错误分类，并提供排查思路。
- GitHub 待办 Issues 梳理器（GitHub issue summarizer）：读取未决 Issue，按技术模块和主题自动聚合。
- PR 代码审查助理（PR review assistant）：自动读取 Diff 差异，标记潜在性能或安全风险。
- Newsletter 行业动态追踪（Newsletter research loop）：自动多源检索，提炼出带摘要的信息简报。
- 文档缺陷自查器（Documentation gap finder）：自动核对最新代码，找出并标记落后、缺失的文档段落。
- 每日 Standup 站会草稿器（Daily standup drafter）：读取
PROGRESS.md，自动为你润色好今天的站会发言稿。 - 周度回顾与沉淀循环（Weekly retrospective loop）：复盘本周的所有变动，提炼出项目演进中的潜在模式（Patterns）。
请记住，上面列出的每一个自动化工作流，全都是从那套极其简单的 “4文件系统” 开始起步的。
唯一需要修改的就是TASK.md 和 LOOP_INSTRUCTIONS.md。
小结
如果说调整 Prompt 是在教 AI “怎么说一句话”，那么构建 Loop 就是在教 AI “怎么打一份工”。
这套以 TASK.md 定目标、INSTRUCTIONS.md 定规矩、PROGRESS.md 存记忆、outputs 装成果的极简“4 文件系统”，完美击中了当下大模型落地的最痛点——状态丢失与行为失控。它不依赖任何昂贵的企业级架构，任何一个掌握了命令行的开发者，今晚就能在自己的本地文件夹里跑通。
请记住文章中的那句忠告：“永远膨胀的状态文件等同于无用。把 PROGRESS.md 当作控制面板，而不是历史档案馆。” 收起你的权限，从只读（Level 1）开始，让你的循环在严苛的强验证（Strong Verification）下经历 5 次手动测试，再放心地交给自动调度。掌握了这一套微型系统工程学，你便跨越了普通使用者的门槛，真正成为了 AI 时代的系统架构师。
所有这些，都只需要你复制、粘贴本文的模板，填写你的具体要求，即可开始在 Claude Code 中狂奔。
去构建你的第一个循环，把重复的体力劳动，交还给守纪律的 AI吧。
原文链接：https://x.com/sairahul1/status/2074063593759227938
还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：
- 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
- 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
- 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
- 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
- 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”
扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。
还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：
- 告别低效，重塑开发范式
- 驾驭AI Agent(Claude Code)，实现工作流自动化
- 从“AI使用者”进化为规范驱动开发的“工作流指挥家”
扫描下方二维码，开启你的AI原生开发之旅。
商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。
