[{"data":1,"prerenderedAt":451},["ShallowReactive",2],{"content:\u002F2026\u002Floop-engineering":3,"surround:\u002F2026\u002Floop-engineering":440},{"id":4,"title":5,"body":6,"categories":399,"date":401,"description":402,"draft":403,"extension":404,"image":405,"meta":406,"navigation":408,"path":409,"permalink":405,"published":405,"readingTime":410,"recommend":405,"references":415,"seo":428,"sitemap":429,"stem":430,"tags":431,"type":437,"updated":438,"__hash__":439},"content\u002Fposts\u002F2026\u002Floop-engineering.md","Loop Engineering：别再只会写 Prompt 了",{"type":7,"value":8,"toc":386},"minimark",[9,13,16,19,27,32,35,38,41,54,73,76,79,82,160,163,190,194,197,200,203,210,214,217,220,236,239,249,256,260,263,266,269,279,282,286,289,292,313,317,320,323,326,329,332,371,374,377,380,383],[10,11,12],"p",{},"第一次看 agent demo，很像看一个聪明小孩第一次拿到螺丝刀：它会点按钮，会查网页，会改文件，甚至会一本正经地说“我已经完成了”。你兴奋三分钟，然后让它干一个稍微长一点的活，它开始绕圈、忘事、误判成功、把错误输出当成证据，最后还很自信。",[10,14,15],{},"这时候问题通常不在模型“笨”。问题在循环没有被设计。",[10,17,18],{},"Prompt Engineering 关心的是“这一句话怎么让模型答得更好”。Loop Engineering 关心的是另一件事：模型答完之后，下一步谁来检查？失败怎么回滚？工具结果怎么进入状态？什么时候停？停之前凭什么说自己真的完成了？",[20,21,24],"alert",{"title":22,"type":23},"一句话理解","info",[10,25,26],{},"Loop Engineering 就是把 agent 的工作过程设计成可靠的闭环：观察状态，决定动作，调用工具，校验结果，更新记忆或计划，然后进入下一圈。真正的工程量往往藏在“下一圈”里。",[28,29,31],"h2",{"id":30},"agent-不是一次调用是一台会转的机器","Agent 不是一次调用，是一台会转的机器",[10,33,34],{},"普通聊天像点餐。你说“来碗面”，模型端上文字，事情结束。",[10,36,37],{},"Agent 更像厨房。它要看冰箱里有什么，决定先切菜还是先烧水，发现锅坏了要换锅，出餐前还得尝一口。这个过程不是一句 prompt 能兜住的，它需要一个循环。",[10,39,40],{},"最朴素的 loop 长这样：",[42,43,50],"pre",{"className":44,"code":46,"filename":47,"language":48,"meta":49},[45],"language-python","state = load_state(task_id)\n\nfor step in range(max_steps):\n    observation = observe(state)\n    action = decide(observation, state)\n\n    if action.type == \"finish\":\n        break\n\n    result = run_tool(action)\n    verdict = verify(action, result, state)\n\n    state = update_state(state, action, result, verdict)\n\n    if verdict.needs_human:\n        pause_for_review(state)\n","agent_loop.py","python","icon=tabler:repeat wrap",[51,52,46],"code",{"__ignoreMap":53},"",[10,55,56,57,60,61,64,65,68,69,72],{},"代码看起来短，麻烦全在函数里面。",[51,58,59],{"code":59},"observe"," 不是把所有日志塞回上下文，",[51,62,63],{"code":63},"decide"," 不是让模型自由发挥，",[51,66,67],{"code":67},"run_tool"," 不是裸奔调用系统权限，",[51,70,71],{"code":71},"verify"," 更不是相信模型一句“看起来没问题”。",[10,74,75],{},"这就是 Loop Engineering 的味道：模型只是齿轮之一，循环才是机器。",[28,77,78],{"id":78},"一圈里应该有什么",[10,80,81],{},"我喜欢把一个可用 loop 拆成五个部件。少任何一个，demo 也许能跑，生产里迟早会撞墙。",[83,84,85,101],"table",{},[86,87,88],"thead",{},[89,90,91,95,98],"tr",{},[92,93,94],"th",{},"部件",[92,96,97],{},"它解决什么",[92,99,100],{},"常见坏味道",[102,103,104,116,127,138,149],"tbody",{},[89,105,106,110,113],{},[107,108,109],"td",{},"状态",[107,111,112],{},"当前目标、计划、上下文、产物、错误记录放在哪里",[107,114,115],{},"全靠聊天记录硬撑，窗口一满就失忆",[89,117,118,121,124],{},[107,119,120],{},"策略",[107,122,123],{},"下一步该做什么，什么时候该保守一点",[107,125,126],{},"工具列表全开放，模型想点哪个点哪个",[89,128,129,132,135],{},[107,130,131],{},"工具",[107,133,134],{},"能真实改变世界的动作",[107,136,137],{},"权限太大，没有参数校验，没有幂等设计",[89,139,140,143,146],{},[107,141,142],{},"校验",[107,144,145],{},"动作到底有没有成功",[107,147,148],{},"“命令没报错”就当成功，“页面能打开”就当功能完成",[89,150,151,154,157],{},[107,152,153],{},"停止条件",[107,155,156],{},"什么时候收手",[107,158,159],{},"越修越坏，越查越偏，循环跑到预算耗尽",[10,161,162],{},"这里最容易被低估的是“停止条件”。人写代码时知道什么时候该停：测试过了，diff 合理，业务目标对上了。Agent 不一定知道。你不给它一个明确的刹车，它就会像扫地机器人卡在椅子腿旁边，一边撞一边努力。",[164,165,166,169,172,175,178,181,184,187],"timeline",{},[10,167,168],{},"{第一阶段：一次性回答}",[10,170,171],{},"用户问，模型答。适合解释概念，不适合处理会改变状态的任务。",[10,173,174],{},"{第二阶段：工具调用}",[10,176,177],{},"模型可以查资料、读文件、跑命令。能力变强了，事故半径也变大了。",[10,179,180],{},"{第三阶段：可控循环}",[10,182,183],{},"系统开始记录状态、限制工具、校验结果、设置预算，并在危险动作前暂停。",[10,185,186],{},"{第四阶段：可运营的 agent}",[10,188,189],{},"循环能被观测、评估、回放、恢复。失败不是黑盒，而是可诊断的工单。",[28,191,193],{"id":192},"只给工具不叫工程","只给工具，不叫工程",[10,195,196],{},"很多 agent 项目的第一版都长得差不多：给模型一串工具说明，再写一句“请一步步完成任务”。这能做出令人开心的录屏，也能制造一些很隐蔽的坑。",[10,198,199],{},"比如文件编辑工具。模型可以改文件以后，它会天然倾向于“继续改”，因为修改是一种看得见的进展。可是工程里真正重要的常常是“不改”：先读测试，先确认复现，先缩小问题，先看 git diff。一个没有策略约束的 loop，会把“能行动”误解成“该行动”。",[10,201,202],{},"再比如搜索工具。搜索会带来信息，也会带来噪音。没有资料缓存和证据筛选，模型每一圈都可能被新材料带偏。最后它给你一份报告，语气很稳，引用很散，结论像从十个网页里揉出来的纸团。",[20,204,207],{"title":205,"type":206},"我见过最危险的循环","warning",[10,208,209],{},"模型调用工具失败，然后自己总结出一个看似合理的失败原因；下一圈又基于这个“原因”继续行动。错误不再是错误，而变成了状态的一部分。几圈之后，你调的已经不是 bug，而是幻觉的后代。",[28,211,213],{"id":212},"让-loop-有记忆但别让它背着行李箱跑步","让 loop 有记忆，但别让它背着行李箱跑步",[10,215,216],{},"上下文窗口不是仓库。把所有工具输出、网页全文、日志、diff、计划都塞进去，短期看省事，长期看就是把厨房垃圾倒在案板上。",[10,218,219],{},"更好的做法是给 loop 分层记忆：",[221,222,223,227,230,233],"ol",{},[224,225,226],"li",{},"热状态：当前目标、下一步、最近错误，放在模型能直接看到的地方。",[224,228,229],{},"工作文件：搜索结果、长日志、草稿、测试输出，写到文件或数据库，需要时再读。",[224,231,232],{},"长期记忆：稳定规则和经验，比如项目约定、用户偏好、常用流程。",[224,234,235],{},"审计记录：每一步动作、参数、结果、校验结论，给人类和评估系统看。",[10,237,238],{},"这套分层听着麻烦，但它会让 agent 清醒很多。模型的上下文像手术台，只放本轮要用的器械；其他东西进器械柜，贴标签，随取随放。",[42,240,247],{"className":241,"code":243,"filename":244,"language":245,"meta":246},[242],"language-text","Goal: 发布一篇文章\nPlan:\n  - 读取主题文档\n  - 写 Markdown\n  - 本地构建\n  - 部署静态文件\nEvidence:\n  - build.log\n  - generated\u002Froutes.json\nGuards:\n  - 不覆盖未确认的用户改动\n  - 部署前确认目标目录\nStop:\n  - 线上 URL 返回 200，页面标题和正文片段可见\n","loop-state.txt","text","icon=tabler:clipboard-list",[51,248,243],{"__ignoreMap":53},[10,250,251,252,255],{},"注意最后的 ",[51,253,254],{"code":254},"Stop","。没有它，agent 很容易把“我已经写了文件”当成“文章已经发布”。这两件事差了一个宇宙。",[28,257,259],{"id":258},"校验要像验收不要像安慰自己","校验要像验收，不要像安慰自己",[10,261,262],{},"Loop Engineering 里最硬的一环是校验。不是因为技术多复杂，而是因为人很容易偷懒，模型也很容易配合你偷懒。",[10,264,265],{},"“构建成功”只能证明项目能构建。\n“HTTP 200”只能证明页面能访问。\n“正文里有标题”才开始接近“文章真的上线”。\n如果文章还有代码块、组件、公式、图片，那就继续验：路由是否生成，静态资源是否可用，MDC 组件有没有被吃掉。",[10,267,268],{},"我更愿意把校验写成验收清单，而不是一句抽象的“检查结果”。例如：",[42,270,277],{"className":271,"code":273,"filename":274,"language":275,"meta":276},[272],"language-yaml","route: \u002F2026\u002Floop-engineering\nchecks:\n  - status_code == 200\n  - title contains \"Loop Engineering\"\n  - body contains \"别再只会写 Prompt 了\"\n  - atom_feed contains route\n  - raw_markdown exists\nrollback:\n  - restore previous wwwroot snapshot\n","acceptance.yaml","yaml","icon=tabler:checks",[51,278,273],{"__ignoreMap":53},[10,280,281],{},"这类清单很土，但管用。Agent 需要的不是鼓励，而是边界清楚的验收标准。",[28,283,285],{"id":284},"预算是-loop-的氧气瓶","预算是 loop 的氧气瓶",[10,287,288],{},"人类做任务会自然感到“差不多该停了”。Agent 没有这种身体感。它只会继续预测下一步。于是预算就成了氧气瓶：步数、时间、费用、工具调用次数、失败次数，都要有上限。",[10,290,291],{},"预算不是为了抠门，而是为了暴露问题。如果一个修复跑了 30 圈还没收敛，继续跑通常不会突然变聪明。更好的选择是停下来，把当前状态、尝试过的路径、失败证据交给人。",[293,294,296,299,310],"folding",{"title":295},"一个实用的失败处理规则",[10,297,298],{},"同一种错误连续出现两次，不要让模型只换一种说法继续试。让 loop 做三件事：",[221,300,301,304,307],{},[224,302,303],{},"写下失败假设。",[224,305,306],{},"找一个能证伪这个假设的最小实验。",[224,308,309],{},"实验还是失败，就升级给人，或者切换到另一条策略。",[10,311,312],{},"这比“再试一次”靠谱。盲目重试只是把失败磨得更圆。",[28,314,316],{"id":315},"prompt-engineering-没死只是位置变了","Prompt Engineering 没死，只是位置变了",[10,318,319],{},"说 Loop Engineering，不是说 prompt 不重要。Prompt 仍然重要，只是它从“全部工程”变成了“循环里的一个配置项”。",[10,321,322],{},"你仍然要写清楚角色、目标、约束和输出格式。但真正决定系统稳定性的，是 prompt 外面的东西：状态怎么存，工具怎么封装，错误怎么恢复，人怎么介入，结果怎么验收。",[10,324,325],{},"换个比喻：Prompt 像驾驶员的口令，Loop 像车。只训练驾驶员喊“稳一点、快一点、安全一点”，但车没有刹车、仪表盘和安全带，这不叫自动驾驶，叫许愿。",[28,327,328],{"id":328},"可以从哪里开始",[10,330,331],{},"如果要把一个一次性 agent 改造成可用 loop，我会先做这几件小事：",[333,334,335,342,359,362,365,368],"ul",{},[224,336,337,338,341],{},"给每个任务一个 ",[51,339,340],{"code":340},"task_id","，把计划、步骤、产物和错误挂在它下面。",[224,343,344,345,348,349,348,352,348,355,358],{},"所有工具返回结构化结果，至少有 ",[51,346,347],{"code":347},"ok","、",[51,350,351],{"code":351},"summary",[51,353,354],{"code":354},"evidence",[51,356,357],{"code":357},"error","。",[224,360,361],{},"给危险工具加审批，给昂贵工具加预算，给外部写入加幂等键。",[224,363,364],{},"每一圈都写 trace，不要只保留最后回答。",[224,366,367],{},"为常见任务写验收清单，让模型按清单收尾。",[224,369,370],{},"失败时输出“已经试过什么”，而不是只输出“抱歉失败”。",[10,372,373],{},"这些东西不性感，但它们像地基。地基没打好，上面堆再多模型能力也会晃。",[28,375,376],{"id":376},"最后",[10,378,379],{},"Loop Engineering 其实是在承认一个朴素事实：智能不等于可靠。",[10,381,382],{},"一个模型可以很会说、很会猜、很会临场发挥，但工程系统要的是另一种品质：可重复、可观察、可恢复、可验收。Agent 想从玩具变成工具，就必须从“让模型回答”走向“让循环工作”。",[10,384,385],{},"等你开始关心每一圈怎么进、怎么出、怎么停，agent 才算真正上了工位。否则它只是穿着工牌的聊天框。",{"title":53,"searchDepth":387,"depth":387,"links":388},4,[389,391,392,393,394,395,396,397,398],{"id":30,"depth":390,"text":31},2,{"id":78,"depth":390,"text":78},{"id":192,"depth":390,"text":193},{"id":212,"depth":390,"text":213},{"id":258,"depth":390,"text":259},{"id":284,"depth":390,"text":285},{"id":315,"depth":390,"text":316},{"id":328,"depth":390,"text":328},{"id":376,"depth":390,"text":376},[400],"开发","2026-07-08 18:29:00","Agent 真正难的不是让模型调用一次工具，而是把观察、决策、执行、校验和收尾做成一圈能反复工作的工程闭环。",false,"md",null,{"slots":407},{},true,"\u002F2026\u002Floop-engineering",{"text":411,"minutes":412,"time":413,"words":414},"13 min read",12.825,769500,2565,[416,419,422,425],{"title":417,"link":418},"ReAct: Synergizing Reasoning and Acting in Language Models","https:\u002F\u002Farxiv.org\u002Fabs\u002F2210.03629",{"title":420,"link":421},"LangGraph overview","https:\u002F\u002Fdocs.langchain.com\u002Foss\u002Fpython\u002Flanggraph\u002Foverview",{"title":423,"link":424},"Why LangGraph?","https:\u002F\u002Flangchain-ai.github.io\u002Flanggraph\u002Fconcepts\u002Fwhy-langgraph\u002F",{"title":426,"link":427},"Building effective agents","https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents",{"title":5,"description":402},{"loc":409},"posts\u002F2026\u002Floop-engineering",[432,433,434,435,436],"AI","Agent","LLM","Loop Engineering","工程实践","tech","2026-07-08 18:43:06","K5jbXmFK-mhQlKXDkHXR1zKWMAo2pahK3ko8JOKIWPQ",[441,446],{"title":442,"path":443,"stem":444,"date":445,"type":437,"children":-1},"DeepAgents：给大模型一间真正能干活的工作室","\u002F2026\u002Fintroducing-deepagents","posts\u002F2026\u002Fintroducing-deepagents","2026-07-08 17:46:00",{"title":447,"path":448,"stem":449,"date":450,"type":437,"children":-1},"Deep Research Agent：让 AI 带着小本本去查资料","\u002F2026\u002Fdeep-research-agent","posts\u002F2026\u002Fdeep-research-agent","2026-07-08 21:14:04",1783560682660]