[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-loop-engineering-agent-completes-tasks-en":3,"article-related-loop-engineering-agent-completes-tasks-en":30,"series-ai-agent-daccbfdf-46f3-432e-8b8d-aecb8198d1c1":81},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"daccbfdf-46f3-432e-8b8d-aecb8198d1c1","loop-engineering-agent-completes-tasks-en","Loop Engineering 让 Agent 把事做完","\u003Cp data-speakable=\"summary\">我把 Loop Engineering 拆成一套能直接拿去用的 \u003Ca href=\"\u002Ftag\u002Fagent\">Agent\u003C\u002Fa> 完成任务模板。\u003C\u002Fp>\u003Cp>我前阵子一直在折腾 Agent 工作流，心里憋着一股火。Prompt 写得挺像样，工具也接上了，甚至上下文我都喂得很讲究，可结果还是老样子：它会开始做，也会很热情地汇报进展，但一到真正复杂的任务，就开始飘。要么第一轮输出看着对，第二轮就把自己带沟里；要么它知道“该做什么”，却不知道“做到什么程度算结束”。最烦的是，它还特别会装作已经完成了。你让它修一个项目，它给你一堆看起来很像回事的中间产物，最后留下一个半成品，像是把“努力”当成了交付。\u003C\u002Fp>\u003Cp>我后来才意识到，问题不只是 Prompt，也不只是 Context。Prompt 解决的是“怎么说”，Context Engineering 解决的是“该知道什么”，但真正让长任务落地的，是循环本身：执行、检查、修正、再执行。也就是这篇知乎文章里讲的 Loop Engineering。\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197\">原文\u003C\u002Fa>把它和 \u003Ca href=\"\u002Ftag\u002Fprompt-engineering\">Prompt Engineering\u003C\u002Fa>、Context Engineering 放在一条线上讲，我觉得这个拆法挺对味。因为很多人现在卡住的，不是不会让 AI 开始干活，而是不会让它把活干完。\u003C\u002Fp>\u003Cp>这篇文章的价值，不在于又发明了一个新词，而在于它把一个很烦但很真实的问题说透了：当任务变复杂，Agent 不能只靠一次性指令，而要靠迭代式执行机制。你得让它自己看结果、自己发现偏差、自己修正路径。说白了，Loop Engineering 不是“让 AI 更聪明”，而是“让 AI 更像一个会收尾的干活的人”。\u003C\u002Fp>\u003Ch2>Prompt 只能起跑，不能冲线\u003C\u002Fh2>\u003Cblockquote>但这个阶段的局限性也很明显：适合相对明确的任务（写文案、总结文章、提取要点），一旦任务变复杂，Prompt就不够用了。\u003C\u002Fblockquote>\u003Cp>这句话我太熟了。Prompt Engineering 最好用的时候，就是任务边界很清楚：写个摘要、改个标题、提炼要点、生成一段代码片段。输入和输出都比较明确，模型只要照着做，通常不会太离谱。但一旦任务开始有状态、有依赖、有中间判断，单次 Prompt 就开始发虚。它没有办法天然知道“这一步做完之后，下一步该怎么接”。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408826341-e6s0.png\" alt=\"Loop Engineering 让 Agent 把事做完\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我自己最早踩坑是在做一个文档整理 Agent 的时候。第一轮我给它一个很完整的指令：读取资料、分类、输出结构化结果。结果它每次都能给我一个“像样”的答案，但分类标准总在变，前后不一致，最后你根本没法把它接进后续流程。那时候我还以为是 Prompt 不够细，后来发现不是细不细的问题，是一次性指令本来就不适合这种多阶段任务。\u003C\u002Fp>\u003Cp>What this actually means is：如果任务需要多步推进，你不能只问“请给我答案”，而要设计“每一步之后怎么判断是否继续”。Prompt 的职责只是启动，真正决定交付质量的是循环控制。\u003C\u002Fp>\u003Cp>How to apply it：先把任务拆成几类，看看哪些是单轮可完成的，哪些必须多轮收敛。单轮任务继续用 Prompt；多轮任务直接别硬扛，改成循环式流程。你可以先写出三个最基本的问题：现在完成了吗？如果没完成，差在哪？下一轮应该改什么？\u003C\u002Fp>\u003Cul>\u003Cli>适合单轮：摘要、改写、信息提取、固定格式生成。\u003C\u002Fli>\u003Cli>适合循环：代码修复、研究归纳、复杂规划、跨文件编辑、长任务执行。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Context Engineering 负责喂对信息，但还不够\u003C\u002Fh2>\u003Cblockquote>当任务复杂之后，AI需要知道的更多。它要看的是项目背景、代码结构、目标指令、历史决策、团队规范……把哪些信息放进模型上下文里，是这个阶段要解决的问题。\u003C\u002Fblockquote>\u003Cp>这段其实讲的是我最认可的一层：上下文不是越多越好，而是越对越好。很多人一上来就把所有材料塞给模型，结果模型看得很累，输出也很散。Context Engineering 的关键不是“填满窗口”，而是把模型做判断真正需要的信息放进去。项目背景、历史决策、代码结构、团队规范，这些东西不是装饰品，它们决定模型会不会在错误的轨道上越跑越远。\u003C\u002Fp>\u003Cp>我在做代码审查助手时就吃过这个亏。最开始我只给它 diff，让它评审。结果它的建议很像一个刚进项目的人，语气很认真，判断很自信，但经常忽略仓库里已有的约定。后来我把目录结构、相关模块的历史改动、lint 规则、测试约束一起喂进去，它的建议才开始像“真在这个项目里干过活”。\u003C\u002Fp>\u003Cp>但这里有个坑：Context Engineering 只能解决“做对”，不能保证“做完”。你给它更好的背景，它更容易判断方向；可如果任务本身需要反复试错，单次上下文再漂亮也没用。模型还是会卡在中途，或者在某个局部最优里停住。\u003C\u002Fp>\u003Cp>What this actually means is：上下文负责减少误判，循环负责推动收敛。前者让它少走歪路，后者让它别半路停工。两者不是替代关系，是配合关系。\u003C\u002Fp>\u003Cp>How to apply it：我建议把上下文分成三层来准备。第一层是任务目标，第二层是当前状态，第三层是约束和历史。别把所有资料平铺进去，最好按“决策优先级”组织。模型先看目标，再看状态，最后看约束。这样它在每轮循环里都能快速定位自己现在在哪。\u003C\u002Fp>\u003Cul>\u003Cli>目标：最终要交付什么。\u003C\u002Fli>\u003Cli>状态：当前已经完成了什么。\u003C\u002Fli>\u003Cli>约束：不能违反什么规则。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Loop Engineering 的核心不是循环，是收敛\u003C\u002Fh2>\u003Cblockquote>Context Engineering让AI\"做对\"，Loop Engineering解决的是\"做完成\"。\u003C\u002Fblockquote>\u003Cp>这句是整篇文章最值钱的地方。因为“循环”这个词很容易让人理解偏了，觉得就是多跑几轮而已。不是。Loop Engineering 真正关注的不是“多跑”，而是“怎么从不确定状态逐步逼近完成态”。如果没有收敛机制，循环只会变成重复劳动；如果有收敛机制，每一轮都会减少不确定性。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408821907-1j0y.png\" alt=\"Loop Engineering 让 Agent 把事做完\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>我见过太多 Agent 流程死在“继续执行”这一步。模型每轮都在产出，但没人定义什么叫进步。于是它会在同一个错误方向上越修越远，或者因为局部结果看起来不错，就误以为全局已经完成。这个时候你再给它更长的上下文，也没用。因为问题不是信息不够，而是缺少一个明确的停止条件和校验标准。\u003C\u002Fp>\u003Cp>What this actually means is：Loop 不是让模型一直干，而是让每一轮都带着检查点。你得规定，输出必须经过验证，验证不过就回滚或修正，验证通过才进入下一步。没有这个机制，所谓“Agent”很容易退化成“自动复读机”。\u003C\u002Fp>\u003Cp>How to apply it：给每个循环加三个固定动作：执行、检查、修正。执行负责产生结果，检查负责判断结果是否达标，修正负责针对偏差重新尝试。你可以把检查写成规则，也可以写成另一轮模型判断，但一定要有明确标准。别让模型自己宣布自己完成了，这事儿我已经被坑过太多次了。\u003C\u002Fp>\u003Cp>如果你做的是代码类任务，我建议检查至少包含三项：语法是否正确、测试是否通过、结果是否符合目标。如果你做的是研究类任务，检查至少包含：信息来源是否可靠、结论是否和材料一致、有没有遗漏关键反例。\u003C\u002Fp>\u003Ch2>失败后修改，比一把梭更像真实工作流\u003C\u002Fh2>\u003Cblockquote>Agent处理长任务时，需要反复执行、自行检查成果、失败后修改、试错了积累经验。\u003C\u002Fblockquote>\u003Cp>这句话听起来很朴素，但它其实点出了长任务最真实的样子。现实里的工作从来不是“一次写对”。你写代码会报错，改文档会漏段落，做方案会被打回，整理数据会发现字段不一致。Agent 如果想真的像一个能干活的系统，就不能只会生成，还得会失败、会修正、会记住问题。\u003C\u002Fp>\u003Cp>我自己最有感的是做自动化测试修复的时候。第一轮模型经常会给出一个看起来合理的补丁，但跑完测试还是挂。以前我会很烦，觉得它没理解问题。后来我改成让它先看失败日志，再定位失败点，再提出修复方案，最后才动手改代码。效果立刻不一样了。因为它不是在空中猜，而是在错误信息里迭代。\u003C\u002Fp>\u003Cp>What this actually means is：失败不是流程外的意外，而是流程的一部分。你要把失败当成下一轮输入，而不是当成流程结束。只要失败信息能进入下一轮，Agent 就会越来越接近正确答案。\u003C\u002Fp>\u003Cp>How to apply it：把失败类型分门别类。比如语法错误、依赖错误、逻辑错误、格式错误、目标偏差。不同失败对应不同修正策略。这样 Agent 不会每次都从头乱试，而是能针对性地调整。\u003C\u002Fp>\u003Cul>\u003Cli>语法错：先修最小可运行版本。\u003C\u002Fli>\u003Cli>逻辑错：回看目标和约束。\u003C\u002Fli>\u003Cli>格式错：强化输出模板。\u003C\u002Fli>\u003Cli>目标偏差：重新注入任务定义。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>别让 Agent 自己猜完成标准\u003C\u002Fh2>\u003Cblockquote>信息给少了，AI缺少判断依据；信息给错了，它可能在错误的方向上越走越远；信息给多了，它又抓不住重点。\u003C\u002Fblockquote>\u003Cp>这段话其实也能拿来解释为什么很多 Agent 总是“差一点”。不是它不会做，而是它不知道什么叫“做到位”。完成标准如果不清楚，模型就会自己发明标准，而它发明出来的标准通常不靠谱。它会偏爱看起来完整、语言漂亮、结构工整的结果，但未必真能交付。\u003C\u002Fp>\u003Cp>我以前写过一个内容生成流程，最开始只要求“输出一篇完整文章”。结果模型每次都能交，但总有一种“已经写完了但没说到点上”的感觉。后来我把完成标准拆成了几个可验证项：是否包含目标主题、是否覆盖核心观点、是否提供可执行步骤、是否引用了指定来源。加上这些后，结果立刻稳定很多。\u003C\u002Fp>\u003Cp>What this actually means is：完成标准要显式化，而且最好是可检查的。不要只写“请认真完成”，这种话对模型没有约束力。你得告诉它，什么算完成，什么算未完成，什么情况要继续循环。\u003C\u002Fp>\u003Cp>How to apply it：每个 Agent 任务都配一个 checklist。这个 checklist 不需要长，但必须具体。比如“包含 3 个步骤”“引用 2 个来源”“输出可直接复制的模板”“测试通过后再结束”。只要标准能被检查，循环就有了方向。\u003C\u002Fp>\u003Cp>我特别建议把“完成”和“满意”分开。模型可能觉得自己已经很努力了，但你的标准不是努力，是交付。别心软，交付标准要硬一点，不然流程会一直拖。\u003C\u002Fp>\u003Ch2>把循环写成流程，不要写成愿望\u003C\u002Fh2>\u003Cp>如果只看概念，Loop Engineering 很容易被讲成一句很空的话：让 AI 反复做、反复改、直到完成。可真正落地时，你需要的是流程，而不是愿望。流程意味着每一步都有输入、输出、判断、转移条件。没有这些，循环只是一个漂亮的口号。\u003C\u002Fp>\u003Cp>我现在更愿意把它理解成四个固定件：目标、状态、动作、判定。目标决定方向，状态告诉你现在在哪，动作负责推进，判定决定要不要继续。只要这四个件齐了，Agent 才能从“会做”变成“做完”。\u003C\u002Fp>\u003Cp>这也是我觉得这篇知乎文章有用的地方。它没有把 Loop Engineering 说成什么神秘能力，而是把它放回工程问题里：怎么组织一套能反复执行、能自我修正、能最终收敛的机制。说白了，这就是把“聪明”变成“可交付”。\u003C\u002Fp>\u003Cp>How to apply it：你可以先从一个最小闭环开始，不要一上来就搞复杂架构。先做一个“生成-检查-修正”的三段式流程，跑通之后再加记忆、加工具、加多轮分支。很多人失败不是因为想得不够大，而是因为一开始就把系统做得太花，最后谁也不知道哪里出了问题。\u003C\u002Fp>\u003Ch2>你可以直接拿去用的模板\u003C\u002Fh2>\u003Cp>下面这个模板我建议你直接复制，然后按自己的任务改。它的重点不是文风，而是结构：目标、上下文、执行、检查、修正、停止条件，全都放进去。你可以把它用在代码 Agent、研究 Agent、写作 Agent，甚至是内部自动化流程里。\u003C\u002Fp>\u003Cpre>\u003Ccode># Loop Engineering Agent Template\n\n## 任务目标\n你要完成的最终结果是：\n- [写清楚最终交付物]\n\n## 当前上下文\n你现在已知的信息包括：\n- 项目背景：\n- 当前状态：\n- 相关文件\u002F资料：\n- 约束条件：\n- 历史决策：\n\n## 执行规则\n1. 先阅读任务目标和上下文。\n2. 制定当前轮次的最小可执行计划。\n3. 执行计划，输出结果。\n4. 自检结果是否满足完成标准。\n5. 如果未满足，说明失败原因并修正。\n6. 重复 3-5，直到满足停止条件。\n\n## 完成标准\n只有同时满足以下条件，才算完成：\n- [条件 1]\n- [条件 2]\n- [条件 3]\n\n## 失败分类与修正策略\n- 如果是格式错误：修正输出结构。\n- 如果是逻辑错误：回到目标和约束重新判断。\n- 如果是信息不足：请求补充上下文或暂停执行。\n- 如果是测试失败：根据失败日志定位问题并重试。\n\n## 每轮输出格式\n### 当前轮次\n- 轮次编号：\n- 当前动作：\n- 产出结果：\n- 自检结论：\n- 是否继续：是 \u002F 否\n- 下一步计划：\n\n## 停止条件\n满足以下任一条件时停止：\n- 所有完成标准通过。\n- 连续 [N] 轮没有实质进展。\n- 缺少关键上下文，无法继续。\n- 出现不可恢复错误。\n\n## 最终输出\n请输出：\n1. 最终结果\n2. 完成情况说明\n3. 仍然存在的风险或未解决问题\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>我建议你在这个模板外面再加一层“检查器”。如果是代码任务，就让检查器跑测试；如果是写作任务，就让检查器查结构和事实；如果是研究任务，就让检查器核对引用和结论。这样循环才不会只停留在“模型自评”。\u003C\u002Fp>\u003Cp>另外，别忘了给循环设置上限。无限循环听起来很优雅，实际上就是浪费 \u003Ca href=\"\u002Ftag\u002Ftoken\">token\u003C\u002Fa> 和时间。你应该明确告诉系统：最多跑几轮，没收敛就停下来，转人工或转更强的工具。这个边界非常重要，不然系统会把“坚持”误解成“死磕”。\u003C\u002Fp>\u003Cp>如果你想看原文，可以从这里开始：\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197\">知乎文章《全网爆火的Loop到底是什么？》\u003C\u002Fa>。我这篇是基于原文思路做的工程化拆解，很多表达和模板是我自己整理的，方便你直接拿去改进自己的 Agent 流程。\u003C\u002Fp>\u003Cp>我再补一个相关参考：\u003Ca href=\"https:\u002F\u002Fplatform.openai.com\u002Fdocs\u002Fguides\u002Fagents\">OpenAI Agents 文档\u003C\u002Fa>、\u003Ca href=\"https:\u002F\u002Fwww.anthropic.com\u002Fresearch\">Anthropic Research\u003C\u002Fa>，还有 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Flangchain-ai\u002Flangchain\">LangChain\u003C\u002Fa>。它们都在不同层面说明了一件事：长任务不是靠一次回答完成的，而是靠可控的循环推进。\u003C\u002Fp>","我拆开 Loop Engineering，给你一套让 Agent 反复执行、自检、修正并做完任务的可复制模板。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2049084372561687197",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782408826341-e6s0.png","ai-agent","en","1aeae331-e5da-4bc9-bee6-6d7bbf47874f",[17,18,19,20,21],"Loop Engineering","Agent","Context Engineering","Prompt Engineering","工作流",[23,24,25],"Prompt 适合起跑，Loop 才负责把任务做完。","上下文负责让模型做对，循环负责让模型收敛。","完成标准必须显式化，否则 Agent 会自己瞎猜。",0,"2026-06-25T17:33:18.472838+00:00","2026-06-25T17:33:18.465+00:00","a9bee732-b07c-4e5b-a0e6-3048577e32a7",{"tags":31,"relatedLang":40,"relatedPosts":44},[32,34,37],{"name":33,"slug":33},"agent",{"name":35,"slug":36},"prompt engineering","prompt-engineering",{"name":38,"slug":39},"context engineering","context-engineering",{"id":15,"slug":41,"title":42,"language":43},"loop-engineering-agent-completes-tasks-zh","Loop Engineering 讓 Agent 做完事","zh",[45,51,57,63,69,75],{"id":46,"slug":47,"title":48,"cover_image":49,"image_url":49,"created_at":50,"category":13},"e2049534-8d94-453a-8cee-8eced0b74e69","public-sentry-keys-hijack-claude-code-cursor-en","Public Sentry keys can hijack Claude Code and Cursor","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782413277883-xtvj.png","2026-06-25T18:47:31.313932+00:00",{"id":52,"slug":53,"title":54,"cover_image":55,"image_url":55,"created_at":56,"category":13},"07fb3bcc-9f38-4153-a9c8-5d67ba7f5018","codex-third-party-model-integration-guide-en","Codex 接入第三方模型完整指南","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782396176284-xvyq.png","2026-06-25T14:02:29.820439+00:00",{"id":58,"slug":59,"title":60,"cover_image":61,"image_url":61,"created_at":62,"category":13},"0003f204-e4d0-4015-8208-bbd23ecfb908","grok-build-goal-autonomous-coding-en","Grok Build Adds \u002Fgoal for Autonomous Coding","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782374583821-11kl.png","2026-06-25T08:02:38.973865+00:00",{"id":64,"slug":65,"title":66,"cover_image":67,"image_url":67,"created_at":68,"category":13},"c41b19d2-48c8-4d88-92f9-d92d73cf9e90","set-up-ai-agent-workflows-5-practical-steps-en","Set Up AI Agent Workflows in 5 Practical Steps","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782314280123-7fv1.png","2026-06-24T15:17:28.642801+00:00",{"id":70,"slug":71,"title":72,"cover_image":73,"image_url":73,"created_at":74,"category":13},"61c1e05c-ea78-4f0a-b389-3f09eeabf7e3","anthropic-claude-tag-research-slack-search-en","Anthropic’s Claude Tag Research turns Slack into search","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782285508413-kwit.png","2026-06-24T07:18:03.3764+00:00",{"id":76,"slug":77,"title":78,"cover_image":79,"image_url":79,"created_at":80,"category":13},"8dbcd7ac-bae7-46c1-ba11-bdca1fd774e8","benchmark-harness-quality-beats-model-hype-coding-en","This benchmark proves harness quality beats model hype in coding","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782253062750-lxuw.png","2026-06-23T22:17:21.750686+00:00",[82,87,92,97,102,107,112,117,122,127],{"id":83,"slug":84,"title":85,"created_at":86},"03db8de8-8dc2-4ac1-9cf7-898782efbb1f","anthropic-claude-ai-agent-task-automation-en","Anthropic's Claude AI Agent: A New Era of Task Automation","2026-03-25T16:25:06.513026+00:00",{"id":88,"slug":89,"title":90,"created_at":91},"045d1abc-190d-4594-8c95-91e2a26f0c5a","googles-2026-ai-agent-report-decoded-en","Google’s 2026 AI Agent Report, Decoded","2026-03-26T11:15:23.046616+00:00",{"id":93,"slug":94,"title":95,"created_at":96},"e64aba21-254b-4f93-aa21-837484bb52ec","kimi-k25-review-stronger-still-not-legend-en","Kimi K2.5 review: stronger, still not a legend","2026-03-27T07:15:55.385951+00:00",{"id":98,"slug":99,"title":100,"created_at":101},"30dfb781-a1b2-4add-aebe-b3df40247c37","claude-code-controls-mac-desktop-en","Claude Code now controls your Mac desktop","2026-03-28T03:01:59.384091+00:00",{"id":103,"slug":104,"title":105,"created_at":106},"254405b6-7833-4800-8e13-f5196deefbe6","cloudflare-100x-faster-ai-agent-sandbox-en","Cloudflare’s 100x Faster AI Agent Sandbox","2026-03-28T03:09:44.356437+00:00",{"id":108,"slug":109,"title":110,"created_at":111},"04f29b7f-9b91-4306-89a7-97d725e6e1ba","openai-backs-isara-agent-swarm-bet-en","OpenAI backs Isara’s agent-swarm bet","2026-03-28T03:15:27.849766+00:00",{"id":113,"slug":114,"title":115,"created_at":116},"3b0bf479-e4ae-4703-9666-721a7e0cdb91","openai-plan-automated-ai-researcher-en","OpenAI’s plan for an automated AI researcher","2026-03-28T03:17:42.312819+00:00",{"id":118,"slug":119,"title":120,"created_at":121},"fe91bce0-b85d-4efa-a207-24ae9939c29f","harness-engineering-ai-agent-reliability-2026","Harness Engineering: From Bridle to Operating System, The Missing Link in AI Agent Reliability","2026-03-31T06:36:55.648751+00:00",{"id":123,"slug":124,"title":125,"created_at":126},"7a09007d-820f-43b3-8607-8ad1bfcb94c8","mcp-explained-from-prompts-to-production-en","MCP Explained: From Prompts to Production","2026-04-01T09:24:40.089177+00:00",{"id":128,"slug":129,"title":130,"created_at":131},"116d5ee9-a4f1-4b5a-aac5-5d035dd22bbe","amazon-bedrock-agents-multi-agent-workflows-en","Amazon Bedrock Agents Gets Multi-Agent Workflows","2026-04-01T09:30:30.197685+00:00"]