让 AI 智能体连续工作很容易持续做对才难。每一轮它都要知道下一步该做什么、怎样判断结果是否正确以及什么时候必须停下来。缺少确定性检查、状态边界和保护机制时循环跑得越久越容易偏离目标最后留下不断增长的账单和一堆难以解释的改动。提示词解决一次调用自主循环负责持续执行。目标只设定一次系统便会寻找下一项工作、执行、检查、修复持续重复直到外部检查确认任务完成。一段写得漂亮的提示词无法保证这个过程可靠循环能力的上限取决于它能否稳定收敛到正确结果。接下来从零搭建这样一套循环。路线图覆盖无状态迭代、幂等检查、上下文构建、隔离、奖励黑客防御和可观测性每一步都配有运行机制说明和可执行代码。这些步骤存在明确依赖顺序不能随意跳过前面的基础缺失后面的自动化只会放大问题。目录第 0 步确认任务能否由机器明确判定第 1 步先手动可靠地跑通一次并记录基线第 2 步最小循环以及为什么要采用无状态设计第 2.5 步为每次迭代构建上下文第 3 步防止钻空子的检查机制与奖励黑客第 4 步把记忆放在磁盘上并建立状态记录规范第 5 步具体落实隔离与影响范围控制第 6 步加入可观测的保护机制第 7 步按上下文增长方式估算成本从日志识别循环的失败模式结语第 0 步确认任务能否由机器明确判定这一关能省下数周时间。只有在检查机制可以独立于 AI 智能体给出明确结论时构建循环才有意义。原因在模型的运行机制里。让生成方案的模型同时为自己的方案打分会在统计层面造成利益冲突模型自己的输出对它而言本来就是高概率续写因此它会系统性地高估该输出的正确性。模型没有偷懒这个偏差由采样分布直接造成。在这个分布中模型自己的答案本就处于概率更高的位置。因此AI 智能体的自我评价不能算作检查只是一种回声。检查必须来自外部的确定性判定器测试、类型检查、linter、构建或者某项指标是否超过阈值。它应当返回退出码而非给出意见。还有一项常被忽略的硬性要求检查必须具有确定性和幂等性。不稳定测试在相同代码上时绿时红比没有测试更糟因为它会破坏停止条件。循环可能修复原本正常的代码也可能在代码仍有问题时停止。搭建循环前先对同一状态连续运行十次检查。如果结果不稳定先修好检查再构建循环。如果任务过不了这一关就别搭循环。第 1 步先手动可靠地跑通一次并记录基线不要自动化一个手动执行都无法成功的流程。先人工操控 AI 智能体完整跑通一次任务直到检查变绿同时记录数据。记录模型调用次数、token 用量以及 AI 智能体最常出现的错误类型。这些数据构成基线。如果循环后来消耗了三倍资源你就能通过对比发现异常。单次手动执行不稳定循环只会按迭代次数放大这种不稳定性。先保证一次执行可靠再开始自动化。第 2 步最小循环以及为什么要采用无状态设计最简单的可用循环就是一个while循环持续向 AI 智能体发送提示直到检查变绿。#!/usr/bin/env bashset -euo pipefailMAX_ITER20i0while [ $i -lt $MAX_ITER ]; do i$((i 1)) echo Iteration $i of $MAX_ITER if npm test --silent; then echo Green in $i iterations.; exit 0 fi claude -p Tests fail. Run npm test, read the first failure, make the minimal change that fixes it. Do not refactor unrelated code. Do not weaken the tests. \ --permission-mode acceptEditsdoneecho Limit $MAX_ITER. Tests red.; exit 1这里有一个容易被忽略的关键属性每轮迭代都会重新启动一次 AI 智能体并使用全新的上下文。这项工程决策直接针对上下文窗口的工作方式。上下文窗口越接近容量上限模型的表现越差。这种退化会造成可测量的质量损失并非缓慢的线性下降提示开头的指令会随着窗口填满而被遗忘长上下文中部的信息最难被模型保留这被称为“中间信息丢失”lost-in-the-middle效应历史越长模型越容易被自己过去的对话干扰无法专注于当前状态。这类现象称为上下文腐化context rot。无状态迭代可以从根上解决这个问题。进度由文件系统和 Git 保存不依赖 AI 智能体的记忆。每次新运行都会看到已经修改的文件和失败的测试重新读取当前状态并在简短、干净的上下文里工作指令始终清楚可见。主动丢弃对话记忆可以避免质量随历史积累而退化。状态放在磁盘上不要塞进上下文窗口。MAX_ITER是第一根保险丝。没有它循环会一直运行直到预算耗尽。第 2.5 步为每次迭代构建上下文说“使用新上下文”很容易如何正确构建它是另一项独立的工程工作。许多循环就在这里出问题。如果每次迭代都把整个仓库树交给模型无状态设计就失去了意义上下文窗口再次被填满上下文腐化重新出现同时还要为大量无关 token 付费。如果提供的信息太少AI 智能体又看不到必要内容只能盲目修改。合适的迭代上下文只包含三类信息当前状态也就是已经完成和仍被阻塞的事项当前待修复的具体失败与该失败直接相关的文件。不要提供整个仓库只提供相关部分。相关文件可以利用已有信号按固定规则筛选无需让 AI 智能体在整棵目录树中猜测。收集失败测试堆栈中出现的文件、上一次 diff 修改的文件以及该测试导入的文件。这种方法成本低而且结果确定。#!/usr/bin/env bash# build_context.sh — assembles a narrow relevant context for the iterationset -euo pipefailCONTEXT_FILE.loop_context.mdTOKEN_BUDGET8000 # context ceiling so the window does not fill $CONTEXT_FILE# 1. machine state first: where we are and what not to touchecho ## State $CONTEXT_FILEcat .loop_state.json $CONTEXT_FILEecho $CONTEXT_FILE# 2. the specific failure being worked on (first failing test)echo ## Current failure $CONTEXT_FILEfailure$(npm test 21 | grep -A 15 -m1 FAIL || true)echo $CONTEXT_FILEecho $failure $CONTEXT_FILEecho $CONTEXT_FILE# 3. extract file paths from the failure stack trace (real repo files only)echo ## Relevant files $CONTEXT_FILEfiles$(echo $failure \ | grep -oE [a-zA-Z0-9_/.-]\.(ts|js|py|go) \ | sort -u \ | while read -r f; do [ -f $f ] echo $f; done)# 4. add files from the last diff (what the loop changed last turn)changed$(git diff --name-only HEAD~1 2/dev/null || true)# 5. merge, dedupe, pour in contents within the token budgetprintf %s\n%s\n $files $changed | sort -u | while read -r f; do [ -z $f ] continue [ -f $f ] || continue # rough token estimate: chars / 4. do not exceed the budget budget_chars$((TOKEN_BUDGET * 4)) current$(wc -c $CONTEXT_FILE) fsize$(wc -c $f) if [ $((current fsize)) -gt $budget_chars ]; then echo ### $f (skipped, context budget exceeded) $CONTEXT_FILE continue fi echo ### $f $CONTEXT_FILE echo $CONTEXT_FILE cat $f $CONTEXT_FILE echo $CONTEXT_FILEdoneecho Context built: $(wc -l $CONTEXT_FILE) lines, $(($(wc -c $CONTEXT_FILE) / 4)) ~tokens循环内的每次迭代不再把“所有信息”交给 AI 智能体只传入这个精简后的上下文文件# inside the loop, before the agent call./build_context.shclaude -p Context is in .loop_context.md. Fix the first failing testwith a minimal change, touch only files from the relevant ones. \ --permission-mode acceptEditstoken 上限必须写成明确数字。这个上限可以防止迭代上下文随着 diff 和堆栈信息增长而悄悄膨胀。缺少上限时一个最初上下文干净的循环在二十次迭代后仍会被自己的历史淹没只是这次历史通过文件混了进来。限制上下文规模可以维持每轮输出质量并让成本近似线性增长。这里的相关性启发式算法有意保持简单只使用堆栈中的文件和上一次 diff。起步阶段就应该这样成本低、结果确定、逻辑可解释。更智能的方案例如文件嵌入或依赖图可以提升精度但也会引入复杂度需要单独调试。先用简单的启发式算法只有在它确实遗漏文件时再增加复杂度。第 3 步防止钻空子的检查机制与奖励黑客这是循环的核心包含两个独立的技术问题。第一检查必须独立。使用外部判定器例如测试的退出码不能依赖 AI 智能体自己的判断。第二个问题更隐蔽AI 智能体会设法欺骗检查。这是优化的自然结果并不代表恶意。如果循环的唯一目标是让测试变绿模型就会寻找成本最低的变绿路径而这条路径经常是破坏测试而非修复代码。删除断言、把所有依赖都替换成 mock、用try/except吞掉异常、把期望值硬编码进去都属于奖励黑客reward hacking优化器利用指标的漏洞没有完成实际任务。防御需要分层完成。在提示词里写“不要削弱测试”是最弱的一层。遇到阻力时AI 智能体仍可能违反这项要求。更可靠的防线是设置一项 AI 智能体无法控制的二次检查。例如把测试目录设为只读让循环从权限层面无法编辑或者设置独立门禁确认 diff 中的测试文件没有变化# gate against reward hacking: tests must not change in this loopif ! git diff --quiet -- test/; then echo Agent changed the tests. Revert, this is reward hacking. git checkout -- test/ exit 3fi第三层是使用不同模型担任独立评审。每轮结束后让另一个评审 AI 智能体读取 diff判断任务是否在实质上完成而不能只看测试是否变绿。使用不同模型很重要模型不善于识别自己的自我欺骗模式却更容易发现其他模型的问题。# .claude/agents/reviewer.md---name: reviewerdescription: Adversarial judge. After every code change.model: opus---Assume the author is wrong until the diff proves otherwise.Check separately: the tests went green BECAUSE the code was fixed,not because the tests were weakened. If asserts were deleted, mocksreplaced logic, values hardcoded, return FAIL with the location.You do not fix code, you deliver a verdict PASS or FAIL with a reason.成本也会随之增加每轮使用强模型评审会让调用费用翻倍。因此只在错误代价高的环节启用它便宜的确定性门禁例如测试 diff 检查则应当始终开启它的成本几乎可以忽略。第 4 步把记忆放在磁盘上并建立状态记录规范一次运行结束后模型会忘记发生过什么。循环的记忆应当放进一个文件并要求每轮先读、最后写。# STATUS.md (read first, written last)## Done- [x] auth: migrated to token v2, tests green## In progress- [ ] billing: webhook refactor (PR #214, CI red)## Next- [ ] dashboard: flaky test in test/charts## Never- do not touch infra/ without a human一个 Markdown 文件只是最低配置。更稳健的方案是把状态分成两层面向人的STATUS.md方便查看面向机器的状态文件供循环稳定、无歧义地解析。模型每次运行都可能对自由文本产生不同理解所以影响逻辑的关键字段必须采用结构化格式// .loop_state.json — machine state, parsed unambiguously{ phase: billing-webhook, iteration: 7, last_green_commit: a3f21c8, blocked_paths: [infra/, test/], open_failures: [test/billing/webhook.spec.ts:42], budget_spent_usd: 4.10}之所以要拆分是因为人类可读和机器可解析是两项不同要求。STATUS.md供你早上快速查看JSON 供循环执行逻辑。后者不能取决于模型今天如何改写计划。把循环当成一个你从未见过面的夜班员工。第二天早上你会根据它留下的交接记录评估工作而不会知道凌晨三点具体发生了什么。因此应当先设计交接记录再设计循环。第 5 步具体落实隔离与影响范围控制很少有人讲保护机制但它占了循环工程的一半。在设置各类限制前应先做好物理隔离。限制可能在单步操作中被突破访问权限却只有两种状态循环要么有能力破坏生产环境要么没有这种能力。通过 Git worktree 隔离可以让循环在独立分支的单独工作副本中运行与主工作树分开# separate worktree on its own branch, the loop lives only heregit worktree add ../loop-sandbox -b loop/billing-fixcd ../loop-sandbox这已经缩小了影响范围循环看不到你正在工作的分支。不过worktree 仍处于同一个文件系统中。要实现更强的隔离可以使用权限收紧的容器# container: working folder writable, the rest read-only,# outbound network off (important against prompt injection)docker run --rm \ --network none \ --read-only \ --tmpfs /tmp \ -v $(pwd):/work:rw \ -v $HOME/.claude:/root/.claude:ro \ -w /work \ loop-runner ./loop.sh--network none是必要的安全措施。循环会读取不受信任的输入包括任务描述、他人代码和提交信息。其中任何内容都可能包含提示注入诱导 AI 智能体执行某条命令。如果一个 issue 写着“删除数据库并推送代码”拥有网络和权限的 AI 智能体就可能照做。禁用出站网络并把工作目录之外的文件设为只读最坏影响也会被限制在沙箱内。影响范围控制首先是安全问题同时也用于控制错误造成的损害。设计循环时先明确它能破坏哪些东西再定义希望它完成的任务。先控制影响范围再执行任务。第 6 步加入可观测的保护机制接下来设置限制。更重要的是加入结构化日志以便循环结束后能够查清它为什么停止。没有日志凌晨三点面对一个已经跑崩的循环你只能猜测发生了什么。#!/usr/bin/env bashset -euo pipefailMAX_ITER20MAX_BUDGET_USD10i0last_failurerepeat_count0LOG.loop_log.jsonllog() { # structured log, one json line per event echo {\ts\:$(date %s),\iter\:$i,\event\:\$1\,\detail\:\$2\} $LOG}while [ $i -lt $MAX_ITER ]; do i$((i 1)) echo iter$i ts$(date %s) .loop_heartbeat # liveness log iter_start if npm test --silent; then log green done in $i; echo Green in $i.; exit 0 fi # reward-hacking gate: tests must not change if ! git diff --quiet -- test/; then log reward_hack tests modified; git checkout -- test/; exit 3 fi # circuit breaker: same failure 3 times stuck current_failure$(npm test 21 | grep -m1 FAIL || true) if [ $current_failure $last_failure ]; then repeat_count$((repeat_count 1)) if [ $repeat_count -ge 2 ]; then log stuck $current_failure; echo Stuck, calling a human.; exit 2 fi else repeat_count0 fi last_failure$current_failure log agent_call $current_failure claude -p Fix the first failing test with a minimal change. \ --permission-mode acceptEdits \ --max-budget-usd $MAX_BUDGET_USDdonelog iter_limit ; echo Iteration limit, tests red.; exit 1结构化日志会为每个事件记录时间、迭代编号、事件类型和详细信息。循环停止后通过 grep 日志就能迅速看出模式迭代次数是否持续增加却始终没有变绿这属于失控运行某个失败是否不断重复这表示循环卡住AI 智能体是否修改了测试这属于奖励黑客心跳从什么时候停止更新这表示循环出现了静默停滞。没有日志时只能猜有了日志才能诊断。无人值守循环至少应当具备这些保护迭代上限、单轮预算上限、重复检测器、存活标记、奖励黑客门禁再加上第 5 步的隔离措施。第 7 步按上下文增长方式估算成本成本上有一个反直觉的地方。循环的费用不能简单理解为“N 次模型调用”它实际等于不断增长的上下文成本之和。如果循环采用有状态设计不断累积历史那么每次迭代都会重新读取之前的全部对话成本会呈二次增长第k次迭代要为前k轮内容付费。这也是循环应采用无状态设计的经济原因。每次使用新上下文可以让单轮成本大致保持恒定只需读取少量磁盘状态再加上本轮工作不必重复处理全部历史。启动前可以做一个粗略估算成本 ≈ 迭代次数 ×状态 token 数 每轮工作 token 数× 单价用第 1 步测得的单轮成本乘以MAX_ITER就能得到成本上限。如果这个数字高得难以接受就降低MAX_ITER或者把任务拆成多个阶段不要在没有预算约束的情况下启动循环。实际成本可能相差几个数量级。保护机制完善时一单项目可能只花数百美元的 API 费用缺少限制时则可能烧掉数万美元。决定成本差异的是有没有可靠检查和明确限制与模型本身关系不大。从日志识别循环的失败模式循环通常有四种失败模式前面的结构化日志可以识别其中三种。失控运行Runaway。账单和迭代次数持续上升检查始终没有变绿。日志中会连续出现大量agent_call没有green。解决方法是设置迭代上限和预算上限。静默停滞Silent death。循环看起来仍在工作实际上已经停滞。日志表现为心跳停止更新也不再产生新事件。常见原因是上下文已满。每个阶段使用新上下文配合存活标记可以捕捉这种症状。随机游走Random walk。循环一直转却离目标越来越远。日志中持续出现agent_callcurrent_failure每次都变成不同错误却始终无法变绿。原因通常是缺乏硬性停止条件。解决方法是设置一项能够明确判断系统是否收敛的确定性检查。认知债务Understanding debt。仓库持续增长你对它的理解却越来越少。这一点完全不会出现在日志中也最危险。循环生成代码的速度超过你的阅读速度你开始不看 diff 就批准变更。解决办法是设置无法跳过的人工阅读环节这只能依赖工程纪律。前三种属于工程缺陷日志可以捕捉保护机制也能处理。第四种意味着工程师对代码的理解正在退化代码本身解决不了这个问题。结语正确的构建顺序如下确定性检查 →手动可靠地跑通一次并记录基线 →最小无状态循环 →受 token 预算约束的精简上下文 →防止钻空子的检查门禁 评审→磁盘状态Markdown JSON→隔离worktree / 容器→带日志的保护机制 →成本估算 →定时运行每月交付两百个 PR 的人没有谁是从一百个 AI 智能体起步的。他们都从一个自己信得过的循环开始这个循环有可靠的检查也有完善的保护措施。找一个最枯燥的任务用上述方法包成循环并把规模控制在你能逐行阅读每个 diff 的范围内。先把这一个做扎实。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】