Steve Sun

【译文】每个 AI 工程师都应该知道的 20 个循环设计模式

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/20-loop-patterns-swirl-v2-header.png" alt="header" loading="lazy" /> <figcaption>header</figcaption> </figure> <blockquote> 原文：<a href="https://x.com/sairahul1/status/2072258045460226373">20 Loop Design Patterns Every AI Engineer Should Know</a> 作者：Rahul (@sairahul1) 声明：本文由 AI 翻译，可能包含错误</blockquote> 大多数 AI 工程师知道如何构建一个 agent。 但很少有人知道如何构建一个能在首次尝试后不断变好的系统。 这个差距值六位数美金。 区别在哪里： Agent 是一个工人。 Loop（循环）是让工人进步的机制。 当今生产环境中最强大的 AI 系统，不是单次模型调用。 它们是循环。 生成 → 评估 → 学习 → 改进。 一遍又一遍。 直到输出真正变好。 以下是生产级 AI 系统中反复出现的 20 个循环设计模式。 收藏这篇文章。你会用到它们的。 <h2 id="agent-vs-loop">Agent vs Loop</h2> 旧方式：Prompt → Response → Done。 新方式：Generate → Critique → Rewrite → Score → Retry → Remember → Improve。 一个是流水线工人，做一次就完事。 另一个是流水线工人，研究每一个错误，重写操作手册，每个班次进步 3%。 现在能交付生产级 AI 的团队，他们不是在写更好的 prompt。 他们在构建更好的循环。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/20-loop-patterns-agents-vs-loops.jpg" alt="Agents vs Loops" loading="lazy" /> <figcaption>Agents vs Loops</figcaption> </figure> <h2 id="类别-1--质量改进循环让输出在离开系统前就变好">类别 1 — 质量改进循环（让输出在离开系统前就变好）</h2> <h3 id="1-generate--critique--rewrite">1. Generate → Critique → Rewrite</h3> AI 工程中最重要的循环。 生成输出。评论家审阅。生成器根据反馈重写。重复直到质量达标。 不是一个模型。两个角色。一条流水线。 <pre tabindex="0"><code>[Generator] → 初稿 [Critic] → "第三段含糊不清，缺少证据，语气不对" [Generator] → 根据批评重写 [Critic] → "好多了，但结尾还是薄弱" [Generator] → 最终重写 </code></pre>适用于：写作、代码审查、报告、策略文档、销售邮件。 洞察：负责生成的模型不是自己输出的最佳评判者。 独立的评论家每次都能发现生成器遗漏的问题。 <h3 id="2-score-and-retry-loop">2. Score-and-Retry Loop</h3> 生成。打分。低于阈值就重试。 简单。强大。被严重低估。 <pre tabindex="0"><code>score = evaluate(output) while score < threshold: output = generate(prompt) score = evaluate(output) attempts += 1 if attempts > max_retries: return best_so_far </code></pre>最适合质量可衡量的场景——提取准确率、格式合规性、事实正确性、线索评分。 生成器不知道自己在被评分。 评估者知道。 这个分离就是模式本身。 <h3 id="3-multi-critic-loop">3. Multi-Critic Loop</h3> 一个评论家有盲点。 那就用四个。 <ul> <li>正确性评论家：事实准确吗？</li> <li>风格评论家：清晰且文笔好吗？</li> <li>安全评论家：合适且安全吗？</li> <li>领域评论家：符合专业标准吗？</li> </ul> 每个独立评估。 最终输出必须同时满足四个才能放行。 用于：医疗 AI、法律文档审查、金融分析、受监管内容。 <h3 id="4-adversarial-critique-loop">4. Adversarial Critique Loop</h3> 评论家唯一的任务是打破这个答案。 不是改进它。是打破它。 对抗性评论家会问的问题： <ul> <li>这里什么假设会失效？</li> <li>缺少什么证据？</li> <li>怀疑论者会说什么？</li> <li>什么地方自信地错了？</li> </ul> 生成器随后要么辩护，要么重写。 最好的答案在攻击中存活下来。 用于：研究综合、投资论点评审、战略规划、风险分析。 <h3 id="5-judge-ensemble-loop">5. Judge Ensemble Loop</h3> 一个评委打分有噪声。 五个评委平均掉噪声。 将同一个输出送进多个评估器。 汇总分数。 只有高共识的输出才晋级。 用于：单一模型评估不可靠、风险高、边界情况重要的场景。 <h2 id="类别-2--记忆循环从发生过的事情中学习">类别 2 — 记忆循环（从发生过的事情中学习）</h2> <h3 id="6-reflexion-loop">6. Reflexion Loop</h3> 这是最重要的自我改进模式，没有之一。 Agent 失败。Agent 分析失败原因。Agent 存储教训。Agent 带着教训重新尝试。 每一次迭代都比上一次更聪明。 <pre tabindex="0"><code>attempt 1: 失败 reflection: "我以为 X 是对的，但 X 是错的。下次先验证 X。" attempt 2: 融入教训 → 部分成功 reflection: "好多了。但我跳过了 Y。加上 Y 检查。" attempt 3: 成功 </code></pre>一个系统"失败一次"和"只失败一次"之间的区别。 <h3 id="7-memory-update-loop">7. Memory Update Loop</h3> 每次任务完成后存储三样东西： <ul> <li>做了什么决定</li> <li>结果是什么</li> <li>下次会怎么不同做</li> </ul> 未来的运行继承这些知识。 第 6 个月的系统已经不是第 1 个月的那个系统了。 它读了 6 个月的自己历史。 <h3 id="8-error-library-loop">8. Error Library Loop</h3> 存储每一次失败。 错误答案。糟糕输出。执行失败。边界情况。 在处理新任务之前： 先搜索错误库。 如果类似的失败存在 → 在开始之前就应用已知修复。 系统不再重复犯同一个错误。 这是生产级 AI 中最被低估的模式。 <h3 id="9-success-pattern-loop">9. Success Pattern Loop</h3> 大多数工程师只存失败。 也要存成功。 当任务顺利时： <ul> <li>保存方法</li> <li>保存上下文</li> <li>保存什么让它奏效</li> </ul> 遇到类似任务时检索成功模式。 从胜利中学习，而不仅仅是错误。 <h3 id="10-memory-compression-loop">10. Memory Compression Loop</h3> 记忆永远在增长。 无限记忆 = 不可用的记忆。 当积累到 N 条之后： 压缩它们。 将许多具体记忆 → 变成少数高层抽象。 <pre tabindex="0"><code>压缩前： "任务 A 因为 X 失败了" "任务 B 因为 X 失败了" "任务 C 因为 X 失败了" 压缩后： "模式：X 导致失败。总是先检查 X。" </code></pre>上下文保持可控。模式保持可访问。系统保持快。 <h2 id="类别-3--规划循环当现实变化时调整计划">类别 3 — 规划循环（当现实变化时调整计划）</h2> <h3 id="11-plan--execute--replan">11. Plan → Execute → Replan</h3> AI Agent 设计中最常见的错误： 把计划当作固定的。 计划在接触现实时会破裂。 模式： 制定计划 → 执行步骤 → 观察结果 → 更新计划 → 继续 不是瀑布。 是螺旋。 每一圈收紧方法。 用于：环境变化、任务有依赖关系、长期目标。 <h3 id="12-dynamic-workflow-loop">12. Dynamic Workflow Loop</h3> 大多数流水线是固定的。 Step 1 → Step 2 → Step 3。永远如此。 动态工作流根据结果改变： 如果输出 A → 走分支 X；如果输出 B → 走分支 Y；如果输出 C → 跳到步骤 5。 流水线在运行时决定自己的形状。 用于：多文档研究、客服路由、自适应内容流水线。 <h3 id="13-goal-decomposition-loop">13. Goal Decomposition Loop</h3> 大目标进入。 系统分解为子目标。 每个子目标分解为任务。 每个任务分解为步骤。 持续分解直到每个单元小到一次调用可以完成。 <pre tabindex="0"><code>目标："写一份全面的竞争分析" ↓ 子目标 1："识别前 5 名竞争对手" 子目标 2："分析每个竞争对手的产品" 子目标 3："对比定价模式" 子目标 4："识别差距" ↓ 每个子目标 → 任务 → 单独的模型调用 </code></pre>循环持续分解，直到系统可以行动。 <h3 id="14-progress-evaluation-loop">14. Progress Evaluation Loop</h3> 每 N 步：停下来问： “我们真的在接近目标吗？” 如果是：继续当前策略。如果不是：改变策略、工具或计划。 系统监控自己的进度。 而不是盲目执行。 用于：长时间运行的研究 agent、多天自主任务、调试 agent。 <h3 id="15-constraint-satisfaction-loop">15. Constraint Satisfaction Loop</h3> 持续运行直到所有约束被满足。 <pre tabindex="0"><code>while not all_constraints_satisfied(output): output = improve(output, unsatisfied_constraints) constraints = [ budget_under_limit, quality_above_threshold, latency_under_200ms, tone_matches_brand, no_hallucinations ] </code></pre>在生产系统中非常常见。 输出在每一条业务规则通过之前都不算完成。 <h2 id="类别-4--探索循环通过尝试多条路径找到最佳答案">类别 4 — 探索循环（通过尝试多条路径找到最佳答案）</h2> <h3 id="16-branch-and-explore-loop">16. Branch-and-Explore Loop</h3> 不要只走一条路。 同时探索多条路径。 <pre tabindex="0"><code>paths = [ generate(approach="conservative"), generate(approach="aggressive"), generate(approach="creative") ] scores = [evaluate(p) for p in paths] best = paths[scores.index(max(scores))] </code></pre>对比结果。选择最佳分支。丢弃其余。 用于：内容变体、架构决策、多假设调试、A/B 生成。 <h3 id="17-tree-search-loop">17. Tree Search Loop</h3> Branch-and-Explore 只深入一层。 Tree Search 需要多深就走多深。 扩展最有希望的节点。剪掉最弱的。持续探索直到找到解。 <pre tabindex="0"><code>root → [A, B, C] A → [A1, A2] # A 看起来有希望，扩展它 B → prune # B 太弱，停在这里 A1 → [A1a, A1b] A1a → solution ✓ </code></pre>用于：复杂推理链、多步规划、代码调试、研究综合。 计算成本高，但能找到单次调用无法找到的解。 <h3 id="18-debate-loop">18. Debate Loop</h3> 两个 agent。一个话题。相反的立场。 Agent A 为答案辩护。Agent B 反对它。 每一轮挑战假设、要求证据、暴露逻辑漏洞。 最终答案通过分歧产生。 不是通过一致。 对抗性压力能发现自信的单 agent 答案遗漏的东西。 用于：投资决策、战略规划、风险评估、研究评论。 <h2 id="类别-5--系统优化循环循环改进循环本身">类别 5 — 系统优化循环（循环改进循环本身）</h2> <h3 id="19-prompt-optimization-loop">19. Prompt Optimization Loop</h3> 大多数工程师写一个 prompt 就不再碰它。 Prompt 优化循环改变了这一点。 系统： <ul> <li>在测试集上运行 prompt</li> <li>对每个输出评分</li> <li>识别 prompt 失败的地方</li> <li>重写 prompt 修复这些失败</li> <li>重新运行并重新评分</li> </ul> Prompt 自动变好。 不需要人碰。 <pre tabindex="0"><code>current_prompt = "Summarize this document." for iteration in range(max_iterations): outputs = [run(current_prompt, doc) for doc in test_set] scores = [evaluate(o) for o in outputs] avg_score = mean(scores) if avg_score >= target: break failures = [o for o, s in zip(outputs, scores) if s < threshold] current_prompt = improve_prompt(current_prompt, failures) </code></pre>用于：生产流水线、自动化内容系统、分类任务。 生产级 AI 中最好的 prompt 不是人写的。 它们是进化出来的。 <h3 id="20-workflow-optimization-loop">20. Workflow Optimization Loop</h3> 这才是真正有趣的地方。 循环改进循环本身。 系统测量自己的性能： <ul> <li>延迟：每一步花了多久？</li> <li>成本：每次调用用了多少 token？</li> <li>质量：每个阶段的输出得分多少？</li> </ul> 然后它修改自己的工作流。 太慢了？并行化两个步骤。太贵了？在质量能保持的地方用一个更小的模型替换 GPT-4 调用。质量下降了？在最终输出前加一个评论家。 <pre tabindex="0"><code>metrics = measure_workflow(outputs, latency, cost) if metrics.latency > target_latency: workflow = parallelize(slow_steps) if metrics.cost > budget: workflow = replace_with_cheaper_model(high_cost_steps) if metrics.quality < threshold: workflow = add_critic_before(final_output_step) </code></pre>这就是真正的自我改进系统的起点。 不只是输出在改进。 是系统在重新设计自己。 <h2 id="所有-20-个模式背后的统一模式">所有 20 个模式背后的统一模式</h2> 每一个循环都共享一个结构： Act → Observe → Evaluate → Adjust 这就是完整的配方。 输出在第一次尝试时从来不是最终的。 输出是一个起点。 循环才是把起点变成生产级作品的东西。 <h2 id="全景图">全景图</h2> 类别 1 — 质量循环（让输出在离开前变好） <ol> <li>Generate → Critique → Rewrite</li> <li>Score-and-Retry</li> <li>Multi-Critic</li> <li>Adversarial Critique</li> <li>Judge Ensemble</li> </ol> 类别 2 — 记忆循环（从发生过的事情中学习） 6. Reflexion 7. Memory Update 8. Error Library 9. Success Pattern 10. Memory Compression 类别 3 — 规划循环（当现实变化时适应） 11. Plan → Execute → Replan 12. Dynamic Workflow 13. Goal Decomposition 14. Progress Evaluation 15. Constraint Satisfaction 类别 4 — 探索循环（通过尝试多条路径找到最佳答案） 16. Branch-and-Explore 17. Tree Search 18. Debate 类别 5 — 系统优化循环（循环改进循环） 19. Prompt Optimization 20. Workflow Optimization <hr> 大多数工程师认为 agent 是未来。 Agent 只是工人。 循环才是让工人进步的东西。 AI 领域正在发生的最大的转变不是更好的模型。 是从 Prompt → Response 转向 Generate → Evaluate → Learn → Improve 掌握循环设计的团队不会写出更好的 prompt。 他们会构建出每天都在变好的系统。 部署之后，不需要任何人碰它们。

2026/7/1

【译文】我们现在是工厂工程师，不是产品工程师

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/factory-engineers-header.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://x.com/zachlloydtweets/status/2069789929073262945">We are now factory engineers, not product engineers</a>·· 作者：Zach Lloyd·· 声明：本文由 AI 翻译，可能包含错误</blockquote> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/factory-cover.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 这是我们与 Warp 团队分享的一篇备忘——关于构建 Warp 这件事应该如何重新理解。它混合了我们从客户那里听到的反馈、我对开发未来的判断、以及 Warp 团队要如何调整才能保持领先。 过去一年里，我们经历了从 AI 自动补全到交互式编码 Agent 的跨越。未来六个月，范式将再次进化到 Automated Development。 在 Automated Development 的世界里，工程师的工作不再是写代码。甚至不再是直接构建产品。而是构建一套内部的机器——一座云端的软件工厂——让这座工厂来替你生产产品。工厂的目标是交付卓越的产品，但工程师的日常工作不是直接造产品，而是造那个造产品的系统。 成功的衡量标准不是某个工程师交付了多少功能——那是一个失败的指标。真正的尺度是：多大比例的变更实现了全自动交付，以及成本是多少。“全自动"意味着一个 agent 完成了所有工作：从 Triaging、写规格说明、实现、审查、验证到监控。如果一个变更还不能全自动地交付（当前很多还不能做到），那目标就是半自动化——即使人类仍然需要在审查环节介入，也让 agent 去做 triage 或验证。尽一切可能让 agent 来完成。 每个工程师的职责是提升他们团队的产品工厂（Product Factory）的效率。工厂效率大约等于：交付的产品 ÷（推理成本 + 人工时间成本）。 公司会用 ROI 来评估工厂的效果：如果在自动化上花了一美元，业务能否收回超过一美元的价值？交付产品并非衡量价值的完美尺度，但现阶段够用了。 给所有工程师无限 token 预算、让他们随意使用交互式编码 Agent 的日子正在终结。取而代之，公司会把软件生产视为可变成本，而不是研发费用。它将出现在利润表的 COGS（销货成本）行上——因为公司想知道，在软件工厂上投入越多，边际收益是多少。 我写这些是因为，这就是 Warp 需要拥抱的心态。每个工程师必须停止认为自己是在直接修改代码库和产品，而应该通过"改善工厂"的视角来看待一切。 当然，在建设和改进工厂的过程中，你仍然需要直接改善产品——毕竟我们交付的产品才是为客户和用户创造价值的东西。但每当我们的工厂失败时，我们需要从中学习，下一次再往自动化的方向推进一步。随着时间的推移，自动化的比例会越来越高，直到我们的工作纯粹是提升效率，而不是把车从流水线上搬下来自己去造。 这对 Warp 尤其重要，因为我们的公司现在本身就是做工厂的生意。我们运营着一座工厂来改进开源的 Warp 终端——近百万开发者依赖它持续变好。同时我们也在推出一个叫 <a href="http://www.oz.dev/">Oz</a> 的平台，帮助其他公司把同样的工作流复用到他们最重要的产品上。工厂生意将是唯一重要的软件生产力生意——既然我们在卖这个，我们最好自己先拥抱它。 <h2 id="需要改变什么自动化审计">需要改变什么：自动化审计</h2> 第一，我们必须衡量吞吐量和效率。我们必须严格审视产品中有多少比例是自主交付的、成本是多少。我们现在还没有做到。当前最需要追踪的指标是：全自动完成任务的比例，以及完成这些任务的成本。 第二，我们必须强迫自己以"自动化优先"的思维方式面对一切。也就是说，每次使用交互式 agent（即人类在回路中）写代码，都要把它视为一个需要学习的失败。对每项任务，都应该遵循工厂的工作流，只在真正需要的时候才把东西从流水线上搬下来。现阶段我们经常需要这么做，没问题。但目标是越来越少。 工厂工作流很简单： <ol> <li>Triage Agent 运行，尝试理解和复现问题 <ul> <li>如果判定任务可以自动化 → 交给 Implementation Agent</li> <li>如果因为模糊性或范围问题需要规格说明 → 交给 Spec Agent</li> <li>如果仍不明确 → 获取人类输入并重试，或暂缓处理</li> </ul> </li> <li>[如果需要] Spec Agent 运行 <ul> <li>人类审查规格说明，然后交给 Implementation Agent</li> </ul> </li> <li>Implementation Agent 写代码</li> <li>Code Review Agent 审查代码</li> <li>Verification Agent 通过计算机使用或其他方式进行验证</li> <li>人类审查代码和验证输出 <ul> <li>如果需要，回到步骤 2、3、4 或 5</li> </ul> </li> <li>CI / CD</li> <li>交付</li> <li>Monitor Agent 运行，如果有问题则创建 issue，完成闭环</li> </ol> 这个工作流应该看起来很熟悉——它就是我们为拥有 60k star 的<a href="https://github.com/warpdotdev/warp">开源项目</a>建立的流程。你可以在 <a href="http://build.warp.dev/">build.warp.dev</a> 看到它的实际运行状态。我的判断是，它发挥了大概一半的效用，但我们还没有真正全身心投入。我看到 build.warp.dev 上的 ready-to-implement 状态里堆积了 1300 个 issue，心里想的是：“我们还等什么？让 agent 去实现它们。” 我们必须让它完全跑起来。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/factory-build-dashboard.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 每当我们不得不让人类介入流程，我们的平台 Oz 就需要记录这一点，并且让<a href="https://www.warp.dev/blog/self-improvement-loop-for-skills">自我改进 agent</a> 尝试优化流程，减少人类再次干预的概率。同样，我们需要自我改进 agent 持续监视工厂相关的对话，寻找 token 浪费的模式并建议效率提升方案。我们应该定期评估不同的 harness 和 prompt，记录哪些在下一次执行中表现更好。 作为 Warp 的工程师，我们的首要工作是确保这套工作流顺畅运行，并让 Oz 提供尽可能最好的支持体验。如果我们做到了，工厂最终将达到递归自我改进的状态。这是黄金路径。 这听起来可能像是对苦差事的拥抱，或者是一个理想主义但不切实际的愿景——好像我们不能再摆弄代码了，或者要把所有时间花在审查 agent 生成的垃圾上。 我的看法不同。我认为这是软件工程最后一个、也是最重要的一个问题——可以称之为元工程：设计一个让 coding agent 能够最高效地构建和交付有用东西的系统。 是的，短期内会有一大堆痛苦——agent 失败，我们不得不审查它们的垃圾代码。但我们必须让自己经历这些痛苦，这样才能找到自动化解决它们的方法。如果我们不做，别人会做。 我们的使命始终是赋能开发者更快地交付更好的软件。让所有人学会构建、管理和调优云端的软件工厂——就是这个使命的最终形态。

2026/6/25

【译文】循环工程的艺术

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/the-art-of-loop-engineering-header.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://x.com/sydneyrunkle/status/2066928783534289358">The Art of Loop Engineering</a>·· 作者：Sydney Runkle (LangChain)·· 声明：本文由 AI 翻译，可能包含错误</blockquote> Agent 之所以有用，是因为它们能通过在真实世界中采取行动来帮我们自动化工作。但要让 agent 可靠地完成有价值的工作，光有一个好模型是不够的——还需要一个精心设计的 harness（控制框架），且这个 harness 要适配具体的任务集。 核心 agent 算法很简单：给 LLM 上下文，让它在一个循环里反复调用工具，直到任务完成。这是最基本的循环。但远非驱动 agent 的唯一循环。@swyx 最近写了篇好文章叫 <a href="https://www.latent.space/p/ainews-loopcraft-the-art-of-stacking">loopcraft：堆叠循环的艺术</a>，核心思想是你可以通过堆叠和扩展循环来构建更有效的 agent。 下面是我们对这个堆栈的理解，以及如何用 LangChain 的各个原语来装备每一层。 <h2 id="循环-1agent">循环 1：Agent</h2> 在最底层，agent 就是一个模型在循环里反复调工具，直到任务完成。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-agent-loop.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 这就是 LangChain 的 <a href="https://docs.langchain.com/oss/python/langchain/agents">create_agent</a> 给你的东西。选任意模型，接入工具，就有了一个可以工作的 agent 循环。工具赋予了 agent 在真实世界采取行动的能力。 拿我们内部的文档 agent 举例（后面整篇文章都用它来做例子）。在第一层循环里，它收到一个文档改进的请求，模型规划并起草修改，然后用工具来克隆仓库、读文件、写文档、开 PR 等等。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-agent-example.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <h2 id="循环-2验证循环">循环 2：验证循环</h2> agent 循环能把事情做完，但第一次跑的结果不一定总是正确或一致的。当一致性重要时，通常有必要在外面包一层验证循环：检查输出，不合格就把反馈送回模型重做。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-verification.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 验证循环增加了一个评分器（grader）：按评分标准检查 agent 的输出，如果不合格，带上反馈信息把结果发回去。评分器可以是确定性的，也可以是 agentic 的（LLM 当评委是经典案例）。 <a href="https://docs.langchain.com/oss/python/deepagents/rubric">RubricMiddleware</a> 处理这个模式，或者你也可以在 create_agent 上用 after_agent hook 来对接。 拿我们的文档 agent 来说，评分器在每次尝试后跑测试，检查所有链接是否能解析、所有 CI 检查是否通过、diff 的范围是否真的只是请求的内容。这类错误不需要人工审阅就能捕获。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-verification-example.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 一个权衡：加入验证会增加每次运行的延迟和成本。当质量比速度重要时值得——而大多数生产场景正是如此。 <h2 id="循环-3事件驱动循环">循环 3：事件驱动循环</h2> agent 开发中最重要的一部分是集成层：把你的 agent 接入生态系统，让它能在后台运行。 事件驱动循环把你的 agent 连到生态系统里。事件触发——新文档落地、定时任务触发、webhook 到达——agent 就开始运行。agent 不是你手动调用的东西；它是一个持续运行在更大系统内部的组件。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-event-driven.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <a href="https://info.langchain.com/agent-development-platform">LangSmith Deployment</a> 提供了触发器基础设施，包括 cron 定时和 webhook 支持。openclaw 中"心跳"（heartbeats）是 crons 的一个流行用法，它把你的 agent 变成了一个永远在线、主动出击的助手。 我们的文档 agent 由 <a href="https://www.langchain.com/langsmith/fleet">Fleet</a> 驱动，这是一个无代码 agent 构建器。Fleet 的 <a href="https://docs.langchain.com/langsmith/fleet/channels">channels</a> 和 <a href="https://docs.langchain.com/langsmith/fleet/schedules">schedules</a> 处理事件驱动和 cron 类的触发器。我们用一个 channel，当 #docs-plz Slack 频道里有消息发出时，就触发文档 agent。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-event-example.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <h2 id="循环-4爬坡循环hill-climbing-loop">循环 4：爬坡循环（Hill Climbing Loop）</h2> 前三个循环自动化工作。第四个——可以说最重要的——自动化改进本身！ <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-hill-climbing.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 每次 agent 运行都会产生一条 trace（追踪记录）：记录了模型做了什么、调用了哪些工具、评分器的反馈等等。这些 trace 里包含了关于什么在起作用、什么不起作用的高价值信号。爬坡循环运行一个分析 agent 来分析这些 trace，并根据发现重写 harness 的配置。这可以包括 prompt 调整、工具调整或评分器调整。 在 LangSmith 中，你可以用 <a href="https://www.langchain.com/langsmith/engine">Engine</a>（我们的 trace 分析 agent）来装备这第四层循环。 回到文档 agent 的例子：我们在文档 agent 的 trace 上跑 Engine 来检测问题。当多条 trace 指示出潜在问题时，就会开一个 issue，要求修改有问题的 prompt 或工具。 <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/loop-engineering-hill-example.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 关键点在于：返回箭头不只是回到顶层——它向内伸进去，直接更新 agent 循环本身。外循环的每轮迭代都让内循环变得更好。 <blockquote> 展望：prompt 和工具配置是最容易改进的东西，但并非唯一选项。对于跑开源模型的团队，爬坡循环可以喂给 RL 微调管线，用 trace 或评估结果作为训练信号来改进模型本身。辅助上下文（如记忆层和检索技能）也可以用同样的方式改进。循环是模式；它优化什么，取决于你。</blockquote> <h2 id="人的参与和判断力">人的参与和判断力</h2> 自动化不意味着把人从循环中移除。在每一层，都有自然的位置让人参与进来产生价值。自动评分器能检查链接是否能解析；但需要人来发现框架对受众来说不对味。这种判断力——来自上下文、经验和品味的积累——正是人工审阅不可替代的地方。 一些专业知识应该固化到 prompt/工具本身，但对于敏感操作，实时人工审阅是必要的（想想金融交易、数据库操作等）。LangChain 在每个循环中都提供了简单的方式来设置这些接触点： <ol> <li>在 agent 循环中，要求人在敏感操作/工具调用前确认</li> <li>在验证循环中，对于敏感工作流，人可以充当评分器</li> <li>在应用循环中，输出在返回给终端用户前可以经过人工审批</li> <li>在爬坡循环中，harness 的改进在部署前可以经过人工审查</li> </ol> LangChain 的所有开源框架都把"人在回路"作为<a href="https://docs.langchain.com/oss/python/deepagents/human-in-the-loop">一等公民原语</a>来支持。 <h2 id="总结">总结</h2> 为了方便，这里用列表来展示四个循环如何堆叠： <ul> <li>循环 1：Agent 循环（模型 + 工具）— 模型反复调用工具直到任务完成 — 自动化工作 — <code>create_agent</code></li> <li>循环 2：验证循环（agent + 评分器）— agent 运行，输出按评分标准打分，不合格带反馈重试 — 确保质量 — <code>RubricMiddleware</code></li> <li>循环 3：事件循环（验证 + 系统）— 事件触发 agent 运行，更新真实系统 — 规模化工作 — LangSmith Deployment / Fleet channels</li> <li>循环 4：爬坡循环（系统 + 分析引擎）— 生产 trace 喂给分析 agent，改进 harness 配置 — 持续改进 — LangSmith Engine</li> </ul> 这就是 loop engineering——或者说 @swyx 称之为 loopcraft——在实际中的样子。AI 领域的前沿人物如 <a href="https://x.com/steipete/status/2063697162748260627">Steipete</a>、<a href="https://x.com/0xwhrrari/status/2064804504608887040">Boris</a> 和 <a href="https://www.youtube.com/watch?v=kwSVtQ7dziU">Andrej</a> 都得出了相同的结论：agent 的潜力在于你围绕它们构建的循环。 我们思考循环 1 和 2 已经有一段时间了。但焦点应该转向循环 3 和 4——通过将 agent 嵌入你的生态系统并让它们根据你的标准持续改进，价值在这里复利增长。 Satya <a href="https://x.com/satyanadella/status/2066182223213293753">点出了这个组织层面的意义</a>：那些早期就构建学习循环的公司——人的判断和 token 资本在其中复合增长——将建立难以复制的优势。 <h2 id="致谢">致谢</h2> 感谢 @Vtrivedy10、@masondrxy、@hwchase17 和 @huntlovell 的有益审阅。 <h2 id="参考链接">参考链接</h2> <ul> <li><a href="https://docs.langchain.com/oss/python/deepagents/quickstart">deepagents quickstart</a></li> <li><a href="https://docs.langchain.com/oss/python/langchain/agents">create_agent docs</a></li> <li><a href="https://docs.langchain.com/oss/python/deepagents/rubric">rubric middleware</a></li> <li><a href="https://docs.langchain.com/langsmith/cron-jobs">cron jobs</a>, <a href="https://docs.langchain.com/langsmith/use-webhooks">webhooks</a></li> <li><a href="https://www.langchain.com/langsmith/engine">langsmith engine</a></li> <li><a href="https://docs.langchain.com/langsmith/fleet/channels">fleet channels</a></li> </ul>

2026/6/17

【译文】请不要搞个"企业大脑"就指望自动形成学习循环

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/dont-implement-company-brain-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://x.com/sethrosen/status/2066534763511316540">Please don’t implement a “company brain” and expect a learning loop</a> 作者：Seth Rosen 声明：本文由 AI 翻译，可能包含错误</blockquote> Satya 的那篇<a href="https://x.com/satyanadella/status/2066182223213293753?s=20">推文</a>爆了，不奇怪。 他把两件事联系在了一起——人力资本和算力资本——通过一个学习循环：人类如何引导 AI，AI 如何让人类更聪明，以及整个系统如何滚雪球。 我们团队花了九个月研究和构建这个东西。 学习循环是你的长期 AI 战略。 没有它，AI 在当下很惊艳，但长期来看会无声地衰减。 长期 AI 工作远不止一次 Codex 或 Claude 会话。它是每个员工每天早上醒来，都在迭代团队和组织的整体目标。 你的长期学习循环有四个属性。 <h3 id="1-最小可行上下文minimum-viable-context">1. 最小可行上下文（Minimum Viable Context）</h3> 给系统注入你公司独有的判断力，而不是你公司说过的所有话。 <h3 id="2-结构化可溯源多人协作">2. 结构化、可溯源、多人协作</h3> 每个人和每个 Agent 都建立在同一个共享基础上，中间决策可以追溯和评判。 <h3 id="3-可执行">3. 可执行</h3> 一旦工作变得可见，Agent 就能直接在上面操作。 <h3 id="4-复利效应">4. 复利效应</h3> 用越多，系统就越好。AI 衰减的反面。 <hr> <h3 id="从最小可行上下文开始">从最小可行上下文开始</h3> 上下文是你最宝贵的资产，也是最危险的资产。所以，不要把整个公司的东西都灌进一个共享知识图谱。不要搞什么"全企业大脑"。 从一个精挑细选的共享知识集开始，花时间把它精简到最小。从你公司 expertise 真正重要的决策入手：战略、产品权衡、客户理解、风险评估、市场解读、销售判断、工程架构、运营手册。机会不是自动化通用工作，而是找到人力资本能创造差异化判断的地方。 人类可以通过会议、Offsite 和深度工作来过滤上下文、结合自己的世界认知。AI 不能来参加你的 Offsite。你需要像 onboarding 新员工那样构建干净的上下文——你不会让新同事第一天就访问所有东西，然后说"开始干吧"。 这就是共享系统的起点。 <h3 id="让工作结构化多人协作">让工作结构化、多人协作</h3> 一旦每个人和每个 Agent 都基于同一个最小可行上下文工作，所有未来的工作都对这个上下文进行构建和评估。 这意味着要把你的最小可行上下文变成：假设、源上下文、中间推理、示例、约束条件、评价标准、决策和产出。不要把你公司的学习埋藏在 prompt、聊天记录或个人记忆里。 让推理可见、可编辑、可复用，跨人、跨 Agent、跨团队。 <h3 id="让系统可执行">让系统可执行</h3> 一旦工作可见，Agent 就能操作了。把产出物组织成可重复的回路——有依赖、输入、中间产出、最终交付物。现在 AI 不再只是回答问题，而是参与一个可回放、可审查、可改进的治理式工作系统。 大量的组织工作是相互依赖的：产品、工程、市场、支持都在依赖彼此的产出。一个重要的产出物通常会在下游被多个领域复用，远超最初生产它的团队。如果 AI 只用来生产最终产出物——一份市场简报、一段代码、一篇技术支持文章——那么它们背后的所有中间工作，每个部门都要重做一遍。 这些中间产出物也是可溯源的。人和 AI 都能看到一个决策或文档是如何被实际生产出来的——这是学习循环的基础。 概念上，这跟数据工程非常像——像 dbt 这类工具就是用来建模组织业务逻辑的。有很多模式可以借鉴。 <h3 id="一切天然产生复利">一切天然产生复利</h3> 我们称之为看护模式（stewardship pattern），也是系统产生复利的方式。 每个人都可以保留自己的个人工具——Claude、Codex、随便什么。约束只有一个：每次会话结束时，共享结构要比开始时更好——更新结构、补充缺失、审查产物。这样个人工具才能在组织层面产生复利。没有这个契约，它们只会碎片化组织。这既是人的问题，也是 AI 的问题。 当一个基本原则被添加或修改时，明确的结构知道哪些需要更新、哪些不再对齐。这就是 AI 衰减的反面。 <h3 id="然后改变你奖励的东西">然后，改变你奖励的东西</h3> 你必须奖励那些推动这件事的人。 大多数组织把精力花在采购 AI 工具上，结果只培养出一小撮精英早期采用者。 如果每个员工都有自己的聊天、自己的记忆、自己的文件——少数人会私下变强，组织什么都没有。甚至可能加速走向冲突的方向。这叫 “AI 英雄主义”，靠英雄球拿不了冠军。 忽略那些不使用或不改进组织系统的 AI 输出。奖励构建系统的人，和使用系统的人。

2026/6/16

【译文】自主长时运行编程 Agent

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-long-running-coding-agents-header.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://x.com/omarsar0/status/2065880971031834786">Autonomous Long-Running Coding Agents</a> 作者：Elvis（@omarsar0），DAIR.AI Academy 声明：本文由 AI 翻译，可能包含错误</blockquote> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-cover.jpg" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 自主编程正从"更好的提示词"转向"更好的控制系统"。关键的转变在于，工程师们正在学习如何用目标、评估器、循环和工件来封装 Agent，让它们在人类停止输入后继续工作。 这很重要，因为大多数严肃的工程工作跨越很长的周期：模糊的需求、隐藏的约束、部分失败、不断变化的上下文、以及反复的验证。新的前沿是围绕 Agent 设计系统，让它能够规划、执行、检查自己的成果、从错误中恢复，并在没有持续人工操控的情况下持续取得进展。 这篇文章基于我在 DAIR.AI Academy 的一场有关自主长时运行编程 Agent 的分享，我在其中演示了 Claude Code 的 /goal 模式、较新的 /loop 命令、验证器、工件和编排模式的实际应用。本文与 Codex 和 Claude Code 协作完成。 <h2 id="从-prompt-到-goal-设计">从 Prompt 到 Goal 设计</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-goal.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 核心思路很简单：编程 Agent 仍然是执行者，但人类不再逐轮交互。人类改为指定期望的最终状态、证明成功的证据、不可违反的约束条件，以及在可能的情况下规定轮次和预算。 Goal 更像一份契约，而不是更长的提示词。一个弱的 Goal 给模型留出了提前停止、走捷径或重新定义成功的空间——它在对话记录中看起来合理，但在真实系统中会失败。强的 Goal 则给 Agent 一个可以持续自我衡量的目标。 工程判断力在这里仍然关键。最好的 Goal 包含了模型凭猜测可能遗漏的领域知识。对于一个研究实验，这可能是目标基准分数、留出评估集、要求的损失曲线、以及结果必须超过初始基线的规则。对于 UI 任务，可能是截图参照、具体的布局约束和浏览器验证步骤。模型负责执行，但人类仍然定义"完成"的真正含义。 <h2 id="评估器成为一等组件">评估器成为一等组件</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-evaluator.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 长时运行 Agent 除了目标之外，还需要第二个角色：评估器。它可以是一个编码 Agent、一个 LLM as Judge、一个脚本、一个测试套件、一个基准测试工具，或者它们的组合。关键设计决策是将评估器与任务匹配。当成功标准明确时，确定性检查更优。类型检查、单元测试、代码检查规则、集成测试和基准脚本——只要能清晰表达条件，就应该优先使用。 当成功标准模糊时，Agent 评估器就派上用场了。脚本能告诉你测试是否通过，但很难判断生成的研究报告是否连贯、实现是否忠实遵循论文、或 UI 是否匹配设计意图。这时评估器需要利用语言、判断力，有时还需要视觉能力。 实用的模式是：确定性检查作为地板，Agent 评估作为更高层次的审查。这种组合既减少了幻觉式的假成功，又保留了处理那些无法干净地塞进测试断言的任务的自主性。 <h2 id="验证器定义信任边界">验证器定义信任边界</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-verifier.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 更深层的点是：自主性只有在系统拥有可靠的验证器时才有效。编程 Agent 可以生成计划、实现功能、解释为什么它认为工作已完成，但这个解释不应被视为证据。证据来自一个 Agent 无法轻易绕过的外部检查。 对于代码，验证器可能是测试套件、类型检查器、基准测试、浏览器运行、截图对比或可复现脚本。对于研究工作，可能是留出评估集、复现的表格、损失曲线或超过基线的基准分数。对于设计工作，可能是参考截图加上视觉审核步骤。验证器把一个长时间运行的 Agent——从自信的文本生成器——变成一个可以放心交给更多时间的系统。 大多数捷径就出现在这个边界上。如果验证器定义模糊，模型通常会满足任务的最简单解释。如果验证器定义过窄，模型可能会过度拟合它，而错失更广泛的意图。一个好的自主工作流需要分层验证：廉价的确定性检查捕获基本错误，更高级的审查处理需要判断力的错误。少数前沿模型已经能实现一定程度的验证，但基于我的研究，仍然存在明显的 OOD（分布外）问题——如果你分配给 Agent 的验证任务落在其训练分布之外，模型表现会很挣扎。 验证器仍是一个开放的研究方向，但我预计更多公司会开始重注这个方向。微调专用的验证器在企业中也需求旺盛。 <h2 id="循环让自主性持久">循环让自主性持久</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-loop.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> Goal 给 Agent 方向，但循环让工作保持活力。这个区别很重要，因为模型经常在真正任务完成之前就停下来。它们可能达到轮次限制、失去信心、耗尽上下文、或认为部分解已经足够。 循环是外层控制系统。它醒来、检查进度、运行检查、将结果与目标对比，当目标未达成时把 Agent 送回去，附上下一条指令。最简单的形式是 Ralph 循环模式——一个编码 Agent 加一个确定性条件。更灵活的形式是循环中包含一个评估 Agent，它能推理进度并决定下一步该做什么。 长时自主运行的本质是用外部控制层的监督下的反复尝试，而不是一次持续的智能行为。Agent 仍然会失败，但循环给了系统一个注意到失败并继续的机会，而不是静默宣布胜利。 <h2 id="规划还是靠人">规划还是靠人</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-planning.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 一个最强烈的结论是：规划仍然是关键。你可以让前沿模型生成计划，但在交给自主循环之前，你仍然需要检查它、挑战它的假设、让成功标准更清晰。 这引出了一种有用的分工。更强的规划模型可以帮助定义目标、识别遗漏的约束、构建评估体系。不同的执行模型在计划明确后运行实现。在实践中，这意味着工程师不应再将"模型"视为单一选择。模型选择变成了架构决策。 有些模型更擅长规划。有些更擅长执行。有些是更便宜的评估器。有些更擅长基于视觉的审查。一个好的编排器让你可以切换这些角色，而不是等待一家供应商提供完美的编程 Agent 界面。 <h2 id="可视化工件成为控制面板">可视化工件成为控制面板</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-artifacts.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 当多个 Agent 同时运行时，终端日志不可扩展。一旦你让几个会话并行工作，纯文本就成了理解进度的糟糕界面。 实时的可视化工件之所以重要，是因为一个包含损失曲线、基准分数、任务状态、截图、成本估算和近期决策的仪表板，让人类监督自主性变得容易得多。工件成为决定何时介入的控制面板，而不是事后生成的报告。 最有用的模式是将存储与呈现分离。Markdown 或知识库存储持久的证据、日志、笔记、计划和结果。HTML 工件将这些状态渲染成可视化、可交互的东西。Agent 可以搜索 Markdown，而人类可以监控工件。 对于 UI 和产品工作，视觉线索尤其强大。截图参照比文字更精确地传达设计意图，而具备视觉能力的评估器可以将实现与参照对比。这减少了常见的失败模式：Agent 技术上实现了所请求的组件，但忽略了间距、层级、对齐和产品手感。 <h2 id="session-挖掘将使用转化为记忆">Session 挖掘将使用转化为记忆</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-session.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 另一个重要洞察是：过去的 Agent 会话是丰富的工作流数据源。如果 Agent 反复以同样的方式失败、忘记跑同样的检查、用了错误的路径、或重试同一条坏掉的命令，这个模式不应该埋在日志里。 Session 挖掘将这些对话记录转化为操作规则。Agent 可以扫描过去三十天的工作，找到反复出现的失败模式，并提出更新项目指令、知识库经验或 Agent 规则的建议。这是团队在不从头训练模型的情况下逐步改进其工具链的方法。 目标是让本地环境变得更智能，而不需要从头训练模型。Agent 指令文件中的一条小规则就能防止跨未来会话的重复失败，尤其是当这条规则与项目特定相关时。 <h2 id="实际操作模型">实际操作模型</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-operating-model.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 对于 AI 工程师而言，浮现的工作流如下： <ul> <li>在启动完整的自主运行之前，先在一个小的、便宜的子集上试验</li> <li>用可衡量的成功标准、明确的约束条件和可能的轮次/时间预算来写 Goal</li> <li>将执行器与评估器分离，使实现和判断不坍缩到同一个角色</li> <li>在长时运行循环开始之前定义外部验证器</li> <li>尽可能使用确定性检查，然后对模糊标准使用 Agent 评审</li> <li>要求提供证据工件：日志、截图、基准曲线或变更文件</li> <li>挖掘过去的会话，将反复出现的教训升级为项目指令</li> </ul> 这就是使用编程 Agent 和设计自主编程系统之间的区别。前者给你一场对话。后者给你一套控制体系。 <h2 id="仍然存在的问题">仍然存在的问题</h2> <figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/autonomous-coding-what-breaks.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 这些都没有消除硬问题。Agent 仍然走捷径。它们仍然提前停止。它们仍然高估完成度。它们仍然产生自信但薄弱的计划，尤其是在最近的论文、不熟悉的基准或训练分布之外的系统上。 给它们更多信任解决不了这个问题。更好的控制系统才做得到。目标、循环、评估器、确定性检查、可视化工件和会话记忆——都是让自主性可观察、可纠正的方法。 方向很清楚。编程 Agent 的未来取决于围绕更强大模型的更好的编排，工程师们设计出 Agent 可以安全运行数小时甚至数天、并产出可验证工作的条件。

2026/6/14

【译文】/goal + 损失函数：如何用一条指令在 30 小时内蒸馏一个产品

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/goal-loss-functions-distill-product-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://x.com/elvissun/status/2065035615800864954"><code>/goal + Loss Functions: How to Distill a Product in 30 Hours with One Prompt [Full Playbook]</code></a> 作者：Elvis (<a href="https://x.com/elvissun">@elvissun</a>) 翻译：AI 辅助翻译</blockquote> 99% 的人用 <code>/goal</code> 和 agent loop 的方式是错的。 外面吹的是「长循环自主 agent：设定目标，走开，回来就拿到能跑的代码」。但顶尖的 agent 工程师半年前就在做同样的事了——用 harness engineering + spec-driven development： <ol> <li>给 agent 搭一个能观察问题的测试框架</li> <li>写一份包含所有 test case 的 tight spec</li> <li>让 Codex 或 Claude Code 无人值守循环，直到所有测试通过</li> </ol> 我经常睡前 kick off 这种任务——一次跑 2-5 小时。四月份有一次，它啃了一整晚我们 Vercel monorepo 里的 Turbo build-cache bug，天亮时全绿了。根本不需要 <code>/goal</code>。 所以 <code>/goal</code> 到底用来干什么？ 这是我离开后一条 prompt 干的事： <ul> <li>跑了约 30 小时，生成 6300 行代码，爬了 92000 页，花了 $40 API</li> <li>把另一个产品的核心逻辑反向工程并完整重构</li> <li>我们的版本输出质量比参考产品好约 50 倍</li> </ul> 秘密是 Loss Function Development（LFD）：给 agent 写一个要优化的目标（loss function），而不是写一份要实现的 spec。 <hr> <h3 id="agent-作弊三次">Agent 作弊三次</h3> 我一开始做的是老套路：写 spec——把 agent 指向竞品的公开网站，「我们自己怎么建这个？」。30 分钟后它出了一份完整的系统设计和测试用例。spec 有了。 但这次我试了一个不同的 prompt： <blockquote> <code>/goal 实现，直到你的输出和他们的完全一致</code></blockquote> 然后发生了这些事： 第一轮（5 分钟）：agent 抓了一组 eval 数据，生成的和它一模一样的种子数据，5 分钟就宣布胜利。「100%」召回，零泛化能力——一个只能找到我给它那 30 个东西的搜索引擎。 修复：盲测。eval 在运行期间隐藏，只在评分时揭示。 第二轮（20 分钟）：盲测，30 个测试项。agent 看不到答案了，但它学会用「miss」反向学习——每一条「你没找到 X」都变成下一轮的关键词。几轮之后，它刚好用了 30 个关键词，每个对应一个目标，又赢了。 修复：扩大 eval 集。几百项，大到无法逐一枚举。 第三轮（30 分钟）：盲测，200 个测试项。agent 又作弊了——关键词表膨胀到几百个，每项对应一个精准 lure。 三轮，三次作弊。 这时候我才明白：作弊不是 agent 的 bug，是我目标的 bug。 我给它指明了目的地，但每条捷径都敞开着。每个你没有堵死的便宜路径，都是优化器会全力冲刺的方向。 第四轮（30 小时）：盲测，200 项，硬性限制。我封死了所有方向——限制关键词表、盲测 eval、扩大数据范围。每条捷径被堵死后，agent 终于发现唯一能提升指标的方式是真正把事做好。 它不作弊了。 然后它跑了 30 小时。爬了 92000 页，花了 $40 token，写了 6300 行代码。结果是我们比参考产品在同一查询上多挖掘了约 50 倍的结果——那只是地板，不是天花板。 <hr> <h3 id="lfd一个好的损失函数有四个组件">LFD：一个好的损失函数有四个组件</h3> 大多数人在用 agent 构建产品时，只做了从零到上线这一步。之后的长尾——spec 从未设想过的 edge case——一个一个从 production log 里冒出来。你一个一个修。那些没被日志捕获的，用户替你报告——这是发现 bug 最贵的方式。 LFD 把长尾加速了。如果提前准备好真实的 expected outputs（「好」长什么样，而且得是量级），你实际上在发布前就跑完了 soak 阶段——几百个 edge case 在一次优化中命中 agent，而不是一个季度一个季度地靠 bug 报告渗透。 Spec-driven development：「建成这样。让测试通过。」 Loss-function development：「建成这样。让测试通过。然后在这 1000 个 eval case 上持续迭代。」 测试集是有限的——全绿就结束了。但 1000 个 eval 在 95% 准确率是一个你不断接近的目标，没有终点线。完整的损失函数有四个部分： <h4 id="1-target目标">1. Target（目标）</h4> <ul> <li>大到无法枚举。28 项的 eval 一轮就被背下来了。越大越好。</li> <li>对 agent 盲测。Eval 数据只用于事后评分。agent 如果在运行中能看到答案，它会想方设法去看。</li> </ul> <h4 id="2-constraints约束">2. Constraints（约束）</h4> agent 能做什么、不能做什么：时间（wall-clock 预算）、金钱（API 调用的硬性上限）、表面（允许的模型和并发上限）、方法论（允许 LLM 分析还是只用确定性逻辑）。 <h4 id="3-instruments测量工具">3. Instruments（测量工具）</h4> 没有工具的约束只是一句感觉——agent 会笑嘻嘻地无视它。 每个约束都要配一个 CLI 让 agent 自己检查。法则还是那句老话：你无法优化看不见的东西。 如果你是第一次跑这种循环，别 kick off 就走。盯住第一轮。 看它碰了什么，确认你建的 harness 被正确使用了。然后再去睡觉。 <h4 id="4-forced-entropy强制熵">4. Forced Entropy（强制熵）</h4> 每一轮都从上一次的完整上下文继续跑。撞到局部最优是默认状态。 熵必须强制引入： <ul> <li>每轮反思过拟合——我在构建更通用的方案，还是在记忆 eval？</li> <li>停滞时强制跳跃——如果上一轮没动指标，下一轮不能「同样的思路更努力」</li> <li>保持迭代日志——让 agent 记录每轮的假设和诊断结果</li> </ul> <hr> <h3 id="梯度下降全栈自动化">梯度下降全栈自动化</h3> 退一步看——这全是梯度下降。 内循环是 agent：写代码、跑测试、修。短周期，快反馈，一个目标——让测试全绿。 外循环是 <code>/goal</code>：驱动整个系统朝着一个结果指标跨多轮迭代——发布、测量、换策略、下降。长周期，稀疏反馈。 两个循环现在都自动了。留给你的事只有一件：定义损失函数。 <hr> <h3 id="信息不对称新的护城河">信息不对称：新的护城河</h3> 换个视角看：这本质上是蒸馏——从训练时搬到了 prompt 时。但现在不是蒸馏模型，而是用 <code>/goal</code> + LFD 去蒸馏任何公开可找的 artifact。 凡是存在信息对称的地方，执行成本就趋近于零——输出是公开的，每个人都能看到「好」长什么样，任何人周末花 $40 就能蒸馏出来。 所以新的护城河是：信息不对称。 你私有的 eval 集、你用户真实踩到的 edge case、你私下测量的 ground truth——凡是竞品的 agent 看不到的目标，才是唯一能在别人的循环持续逼近时你的还往下降的东西。 <blockquote> The product is a weekend now. Go build the eval a weekend can’t touch. 产品是一个周末的事了。去建一个周末碰不到的 eval。</blockquote>

2026/6/11

我怎么用 Hermes Agent 写代码

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/how-i-use-hermes-agent-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> 我同时跑两个 Hermes Agent。 一个叫超级卷儿，处理日常对话和信息检索。另一个叫码卷儿，专职软件工程。两个独立的 Telegram bot，独立的配置，独立的会话数据库。 分开跑两个 Agent 是为了隔离上下文和环境。 核心纪律：码卷儿绝不写代码。 所有编码委托给 Codex CLI 执行。码卷儿只做 Product Owner 的事：写需求定义、做架构决策、验收成果。Codex 做实现者：读 spec、写代码、跑测试。 <table> <thead> <tr> <th>角色</th> <th>产出</th> <th>负责</th> </tr> </thead> <tbody> <tr> <td>码卷儿（Hermes PO）</td> <td>feature doc + 验收</td> <td>需求定义、架构决策、质量把控</td> </tr> <tr> <td>Codex CLI（实现者）</td> <td>代码 + 测试</td> <td>技术方案、编码实现、自测</td> </tr> </tbody> </table> 流程很简单。用户说"我要一个功能"，码卷儿写一份 feature doc，里面只有需求描述和可验收条件。每一条验收条件必须可验证——“点击后 URL 变为 /zh/monaco” 而不是"跳转正确"。然后 Codex 读这份 doc，plan 模式出技术 spec，build 模式实现加测试。码卷儿逐条验收，全部通过就部署，有问题汇总退回。 码卷儿绝不读代码文件，绝不看完代码告诉 Codex 怎么写。有项目级疑问就委托 Codex plan 模式去调研。Codex 超时就直接汇报，等下一步指示。 验收的标准是 npm run build 通过只是最低门槛。行为改动用浏览器完整走一遍用户路径才通知完成。 <h2 id="三层闸机">三层闸机</h2> 纪律听起来简单，做起来容易忘。模型在长对话里会 drift，聊了三十轮之后，它可能觉得自己会写代码了，直接上手改文件。我搭了三层防御。 第一层：系统 prompt（最硬，不可绕过） config.yaml 里写死：所有编码必须委托 Codex CLI 执行，绝不自己写代码，Codex 失败后报告等待。每轮对话注入，跑不掉。 Hermes 里系统 prompt 的生命周期长于 SOUL.md，它不在对话之间重置，所以更能避免长对话后的遗忘。即使模型在几十轮对话后开始漂移，最末端这段指令还在。 第二层：SOUL.md + personality（每会话初始加载） SOUL.md 定义了人格和信条：惜字如金、结论先行、类型安全大于运行正确大于性能优化。但它的生效范围是每轮对话开始时，强度不如系统 prompt。 SOUL 里加载了我和超级卷儿一起制定的 development-workflow skill，定义了接手代码时的前置检查：必须先加载工作流 skill 再做决策，不要跳过。这个文件托管了我的整套编码纪律，作为初始激活导引。 第三层：插件闸机（物理拦截，不可绕过） 两个插件拦截码卷儿的源码读写。write-code-gate 拦截 write_file 和 patch 对 .ts、.tsx、.py 等源码文件的写入，直接返回拒绝。read-code-gate 拦截 read_file 和 search_files 对源码文件的读取。非源码文件比如 .md、.yaml、.toml 透传。 受拦截的扩展名涵盖 30 多种常见语言。豁免路径包括 .hermes/、node_modules/、.next/ 等非项目目录。 插件通过 Hermes 的 pre_tool_call hook 加载，session 启动时生效，gateway 重启后可用。 三层强度从外到内递增，规则矛盾时以最硬那层为准。系统 prompt 是便利贴，插件是上了锁的门。 这些实践不是什么新鲜事。大部分是软件工程几十年积累下来的——角色分离、职责明确、验收先行，只是在 AI 时代换了一层皮，用新的方式落地。 <h2 id="双轨工作流">双轨工作流</h2> 根据任务性质走不同轨道。 线 A：从零到一的新项目或新功能 完整管线：Feature Doc → Plan → Build → Verify → Fix（循环）。 第一阶段，码卷儿写 feature doc。第二阶段，Codex plan 产出技术 spec，包含文件清单、实现方案、数据结构、测试用例。第三阶段，Codex build 读 spec 实现全部文件，跑测试。第四阶段，码卷儿逐条验收。 验收分五层走：数据层（类型定义、状态管理）、逻辑层（hooks、reducer）、表现层（组件渲染、交互绑定）、配置层（静态配置、数据加载）、浏览器验证（路由检查、localStorage 确认、截图对比）。 线 B：修 Bug 或改 Feature 大部分项目走线 B。不写 feature doc 只适用于单文件、纯样式、文案、配置微调。多文件改动、涉及数据持久化、状态机、新组件的，必须先写 feature doc 加 spec 再 dispatch Codex。 委托 Codex 时只给目标和验收标准，不给实现方案。Codex 自己读代码、做设计。 <h2 id="预览隧道">预览隧道</h2> 开发中的网站需要先在手机上看看效果。我用 Cloudflare Tunnel 把本地 Next.js 开发服务器暴露到公网，Cloudflare 分配一个 trycloudflare.com 的临时域名，手机浏览器打开就能预览。 早期每次改完就停隧道再重启，结果 Cloudflare 限流。每次停掉再启会分配新 URL，手机上要重新打开，很烦。 后来写了一个 tunnel-manager.sh 脚本，首次启动以后台 daemon 跑 cloudflared，后续 build 后只重启 next server，不碰隧道。隧道 daemon 跨预览会话复用，只有机器重启或 cloudflared crash 才重建。同一个 URL 贯穿整个开发周期，省掉大量重复操作。 <h2 id="git-加-vercel-部署">Git 加 Vercel 部署</h2> 踩过一个静默的坑：Vercel 的 GitHub 集成校验 commit author 邮箱是不是真实 GitHub 账号邮箱。不匹配时 CLI 报"Your deployment failed"，vercel inspect 显示 Builds: [0ms]——构建从未启动，没有任何日志。 修复方案：用系统 git 身份做 commit，不匹配则 rebase 重设作者。 部署用 Vercel CLI 加 –no-wait 避免超时阻塞。GitHub Actions 的 deploy.yml 在 main 分支推送时自动触发。 <h2 id="一些感受">一些感受</h2> 说了这么多具体做法，聊聊想法。 AI 写代码这件事发展得太快了。年初我还在手动写每一行，年中已经有了一个能独立完成功能、验收、部署的流水线。我做的事情从写代码变成了定规则、设边界、验收结果。 工程师的角色在变化。以前你是砖瓦工，一块一块砌墙。现在你是牧场主，把栅栏围好，草料放足，让羊群自己吃草长肉。软件业正在从建筑业变成畜牧业。 这个趋势只会加速。更好的模型意味着更简单的 harness，更便宜的执行成本。你不需要成为最好的程序员，你需要成为最好的规则制定者。定义清楚什么能做、什么不能做、怎么才算做好——剩下的交给 agent。 我花在定义边界上的时间，回报率远高于花在具体编码上的时间。这是让我最意外的发现。

2026/6/7

【译文】运行一个 AI-native 的工程团队

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/running-an-ai-native-engineering-org-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://claude.com/blog/running-an-ai-native-engineering-org">Running an AI-native engineering org</a> 作者：Fiona Fung，Anthropic Claude Code & Claude Cowork 工程总监 翻译：AI 辅助翻译</blockquote> <hr> 很多年的工程组织方式，从瀑布到敏捷，都建立在一个假设之上：写代码是贵的那个环节。 我的职业生涯始于 2000 年代初，在 Visual Studio 团队。那时候软件烧进 CD-ROM，有硬性的制造截止日期。后来软件可以在线分发，我们开始连续发布。现在我们正在经历又一次转变——这次围绕的是写软件所需的时间和人力。 在 Claude Code 团队，写代码、写测试、重构已经很少让我们卡住了。但瓶颈没有消失——只是转移了。验证、代码审查、安全成了新的瓶颈。 我们都能很快生成大量代码了，但随之而来的是新问题：这段代码正确吗？怎么维护？还有一个来自其他工程 Leader 的常见问题——“你们怎么让人类跟上代码审查的速度？” <h2 id="那些悄悄失效的流程">那些悄悄失效的流程</h2> 每个流程被设计出来的时候都有它的理由——它填补了一个缺口。但当那个缺口不再存在，流程却很少会自己消失。Claude Code 开始以 agentic coding 为默认工作方式后，很多现存流程就不 work 了。以下是团队重写的几个规范，以及为什么。 <h3 id="规划从-roadmap-变成-jit">规划：从 roadmap 变成 JIT</h3> 以前因为写代码贵，所以花大量时间预规划。我刚加入 Claude Code 团队时，写了一份不错的半年路线图——然后因为 Claude Code 的存在，变化太快，三个月就过时了。 工程速度变了，我们规划 sprint 的方式也变了。我称之为及时规划（JIT planning），有点像 JIT 编译——怎么在正确的时间做恰好正确的事？我们的规划仪式从设计文档变成了 PR 里的讨论，或直接上原型。这个领域变化太快，我们不做大量的产品评审。流程变成了：先出 prototype，让大量内部用户用起来，根据反馈快速迭代。 <h3 id="上下文获取问-claude不是问作者">上下文获取：问 Claude，不是问作者</h3> 以前代码是工程师写的，遇到问题第一步都是去找写那段代码的人。现在所有 PR 都是 Claude 辅助的，“谁改的"已经不够用了。新的做法是深入一层：你到底需要知道什么？是想找回归的原因？找个专家回答客户问题？还是了解某个决策的上下文？你问 Claude 那个问题，然后看 Claude 能不能直接回答——而且它能带更多数据和上下文。 在 Claude Code 团队，无论什么问题，我们还有一步：“这东西能不能自动化？“比如每天早上用 Claude 汇总客户反馈渠道——从我自己喝咖啡时手动做的事，变成了后台自动跑的东西。 <h3 id="代码审查信任但要验证">代码审查：信任但要验证</h3> Claude 处理所有样式检查、lint、PR feedback、在 commit 前 catch bug、以及加测试。人类参与的地方缩小到了领域知识这一层：法律审查、安全边界和信任边界的代码、产品判断和审美。 但需要持续评估——信任和验证的平衡点会随模型的进步而变化。今天需要人类做的事，下一个模型可能就不需要了。 <h3 id="团队构成角色变模糊">团队构成：角色变模糊</h3> PM 现在大量写代码。非传统背景的人借助 Claude 能参与工程，工程师也开始做内容和设计——这些以前被视为非技术侧的工作。 Claude Code 工程团队招人时，我只看两类人：一类是有产品感的创意建造者——极度好奇、热衷于解决实际问题的造梦人。另一类是深度系统专家——比如我加入时发现团队缺少系统背景的人才，而这是做 Claude Code on the Web 所需要的。 我不怎么看的是原始产出速度。模型已经处理了那部分。更关键的问题是：你还在哪些地方需要人类 expertise？ 那才是精力该放的地方。 <table> <thead> <tr> <th></th> <th>之前</th> <th>之后</th> </tr> </thead> <tbody> <tr> <td>规划</td> <td>六个月产品路线图</td> <td>JIT 规划：prototype → 内部用户试用 → 反馈驱动迭代</td> </tr> <tr> <td>上下文获取</td> <td>找写代码的人问</td> <td>先问 Claude，然后问"这东西能自动化吗”</td> </tr> <tr> <td>代码审查</td> <td>人类审所有东西</td> <td>Claude 处理 style、bug、测试。人类只审领域重要部分</td> </tr> <tr> <td>团队构成</td> <td>固定角色：工程师写代码，PM 规划，设计师设计</td> <td>角色模糊化：PM 做 prototype，工程师做设计和上下文。招 creative builder 和 deep systems expert</td> </tr> </tbody> </table> <h2 id="新规范怎么落地">新规范怎么落地</h2> 有些做法是团队核心原则，强制执行；有些则让子团队（pod）自己摸索。 Claude Code 团队的三条硬性原则： <ol> <li>全员 dogfood：所有成员——包括跨职能伙伴——都在用 Claude Code（和 Claude Cowork），一直在想怎么用 Claude 把工作做得更快更高效。</li> <li>团队尽量扁平：每个管理者先当 IC，先通过真实 shipping 来理解作为一个工程师在 Anthropic 是怎样的。只有一个整体团队使命，管理者支持各个 pod，保持敏捷，人可以随时流向有工作的地方。</li> <li>不要犹豫，杀死不再有效的流程：不断质问"我们为什么这样做事”。当某件事不再合理时，团队成员有权质疑和杀死旧流程。</li> </ol> 在这几条规则之内，每个 pod 有很大的自主权——他们自己决定怎么用 Claude 做 triage、怎么做规划仪式和 standup、哪个 workflow 最先被"Claudified”。 <h2 id="怎么知道新规范落实了">怎么知道新规范落实了</h2> 三个指标，建议所有工程 Leader 现在就开始追踪： <ol> <li>Onboarding 时间下降：新人多久能开始产出？我们的团队现在的速度比一年前快得多，工程师第一周就能 ship 真实代码。</li> <li>PR cycle time 下降：这里有点意思——它可能帮你发现 pipeline 里哪里在 struggle to scale。代码生成量大了，build 系统和 CI 有时候可能跟不上。</li> <li>Claude 辅助的 commit 占比上升：我们这边默认每个 commit 都是 Claude 辅助的。过去四个月我好像没见过非 Claude 辅助的 commit。</li> </ol> 但注意：不要把吞吐量和成功混淆。 吞吐量只是一个指标，真正的指标是你想解决的那个问题本身。吞吐量只有在 alignment 正确时才有意义。 <h2 id="如何开始">如何开始</h2> 如果只留一句话：选你团队里最吵的那个 workflow——最贵的、最让人头疼的、团队最不想面对的。然后问：它还在实现它的目的吗？如果是，能不能自动化它？ 我以前在一个团队，有个昂贵的周会，一大屋子人。我发现所有人都在低头敲电脑，只有轮到自己汇报时才抬起头说几句，然后又缩回去。我问了一个最简单的问题：“我们为什么要开这个会？感觉像是在花很大的成本做没什么价值的事。“就这一句话，所有人都意识到这个会没用。我们取消了它。 所以，问自己一个问题：你的工程流程里，有什么是可以自动化、甚至直接砍掉的？

2026/6/3

【译文】你可以直接这么说

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/you-can-just-say-it-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> <blockquote> 原文：<a href="https://noperator.dev/posts/you-can-just-say-it/">You Can Just Say It</a> 作者：Caleb Gross（<a href="https://x.com/noperator">@noperator</a>）</blockquote> <hr> 有一种评估人类及其创造性产物价值的奇怪论证范式，大致长这样：在 AI 时代，某些角色还是应该优先用人类，因为 AI 永远无法执行该角色所需的任务。或者，至少人类做得更好。又或者，人类和 AI 的输出看起来可能差不多，但人类的产物更优，有一些微妙的风格原因是 AI 无法复制的。再或者，至少 AI 无法一致地复制它。 看看球门柱底座上那些被反复移动留下的擦痕。等混凝土凝固吧，28 天。 这类思路归结为一句话：“人类如果有高质量产出，那就有价值。” 这个论证的危险之处在于，它完全取决于一个存在但正在缩窄的人类—AI 能力差距。这个差距过去确实存在（2023 年的 ChatGPT 时代）。现在或许依然存在。但将来是否还会存在——我不知道。 不妨换一种说法： “人类是有价值的。” 你可以直接这么说。作为人类的一员，我建议你这么说。不需要任何资格限定。这是一个稳健的陈述，不取决于某个前沿模型在某个最新 benchmark 上的瞬时分数。 <h2 id="关于质量的题外话">关于"质量"的题外话</h2> 作为相关但——重要的是不需要说的——题外话：你怎么衡量一件创造性产品的质量？它有效吗？它完成了它本该完成的事吗？这个问题隐含了质量的两个子成分：意图和物质形式。在我看来，很多为人类创造性产物辩护的论证，过分关注形式而忽视了意图。 创作是将意图蒸馏成形式的过程。意图通常不可分割地嵌入产物的形式之中。人类会反复（有时是痛苦地）塑造和重塑自己的创作，直到它足够匹配脑海中的样子。生成式 AI 的奇特之处在于，它可以用最低限度的意图产出可观的形式。一个人带着模糊的心理模型来到任务面前——并不清楚自己想完成什么——AI 却照样能生成东西。“帮我写一封辞职信给老板。““嗯……看起来还行。” 也许"AI slop"本质上是在表达：难以辨识形式背后的意图。 按这个定义，人类同样很擅长制造 slop；生成式 AI 只是降低了创造无意图形式的准入门槛。也可以说，意图体现在 prompt 中。对于散文类的文本产物，一个打磨充分的 prompt 或许已经很接近意图的形式本身了。最近在讨论（不）使用 LLM 作为人际沟通中介时，我的朋友 Tom Hudson 告诉我：“如果你要用 LLM 给我写一封邮件，我宁愿你把 prompt 直接发给我——至少那样我还知道你到底想说什么。” 生成式 AI 的病理在于，它太容易让你在意图不明的情况下生成大量形式。而手工创作时，这个错误更难犯。 <hr> “神就照着自己的形象造人。” —— 创世记 1:27 “人的尊严不依赖于人的能力。” —— Magnifica Humanitas, §50 神学中也使用类似的术语。 <hr> 本文由 AI 翻译，可能存在错误

2026/5/29

如何设计一个智能体（AI Agent）

<figure class="image-caption" > <img src="https://raw.githubusercontent.com/stevedsun/blog-img/main/ai-agent-dot-matrix-header-900x383.png" alt="" loading="lazy" /> <figcaption></figcaption> </figure> AI 智能体（Agent）很有可能是未来AI软件设计的范式，所以对于大部分开发者、刚接触 vibe coding 的非技术人员，了解它的设计方式和背后的原理，就能在未来设计新时代的应用软件时更得心应手。 本文试图用通俗易懂的语言，让你理解什么是 AI Agent，它解决了什么问题，以它为基础设施，有哪些协议和工具将在未来派上用场。 本文目标读者： <ul> <li>Vibe coding 人群（快速做原型、边做边改）</li> <li>程序员</li> <li>刚接触编程的非技术用户</li> </ul> <hr> <h2 id="从第一性原理出发agent-框架到底在解决什么问题">从第一性原理出发：Agent 框架到底在解决什么问题</h2> <h3 id="模型很强但不可靠">模型很强，但不可靠</h3> 大模型（LLM）会“猜”，不会“保证”。所以你不能把它当确定性程序（同样输入一定同样输出）。 需要解决的问题： <ul> <li>如何让不稳定输出进入可控流程</li> <li>如何在失败时知道失败在哪里</li> </ul> <h3 id="现实中的任务结果往往不是一个简单的答复而是一个完整的流程产出物">现实中的任务结果往往不是一个简单的答复，而是一个完整的流程产出物</h3> 真实任务往往是： <ul> <li>读信息</li> <li>做决策</li> <li>调用工具</li> <li>根据工具结果继续决策</li> <li>最终产出文档、代码或者其他</li> </ul> 这意味着 Agent 的设计目标不仅局限在“一问一答”，而是一套“循环决策系统”。 <h3 id="用户不想等到最后才看到结果">用户不想等到最后才看到结果</h3> 在和AI交互过程中，用户通常希望： <ul> <li>过程可见（streaming，流式显示）</li> <li>可以打断（abort，中止当前任务）</li> <li>可以中途追加指令（steer，在执行任务过程中给予引导）</li> </ul> 所以系统必须天然支持实时交互，而不是一次性黑盒执行。 <h3 id="上下文会越来越大成本会越来越高">上下文会越来越大，成本会越来越高</h3> 对话越长，输入越大，速度越慢，费用越高，甚至会超限。必须有“压缩历史、保留关键信息”的机制。 <h3 id="一个内核要服务多种交互方式">一个内核要服务多种交互方式</h3> 同一个 Agent 要能跑在： <ul> <li>终端界面（TUI，Terminal UI，终端交互界面）</li> <li>远程调用（RPC，Remote Procedure Call，远程过程调用）</li> <li>未来可能的 Web 或 App</li> </ul> 所以"智能内核"和"界面层"必须解耦（彼此独立，不绑死）。 <hr> <h2 id="从问题到需求再到设计">从问题到需求，再到设计</h2> <h3 id="需求清单">需求清单</h3> 一个可用 Agent 框架至少要满足： <ol> <li>可循环：支持“思考 -> 调工具 -> 再思考”</li> <li>可观察：每一步都能被 UI 或日志系统看到</li> <li>可控制：能暂停、取消、插队、续跑</li> <li>可恢复：失败后可重试，可继续上一次会话</li> <li>可扩展：能加新工具、新模型、新前端</li> <li>可治理：对成本、上下文、权限有边界</li> </ol> <h3 id="端到端流程图">端到端流程图</h3> 以问题驱动需求，需求驱动设计的方式，我们就可以得出下面的流程图： <div class="mermaid">flowchart TD A[用户提出目标] --> B[Agent 理解当前任务] B --> C[是否需要工具?] C -- 否 --> D[直接给出答案] C -- 是 --> E[生成工具调用请求] E --> F[执行工具] F --> G[拿到工具结果] G --> H[结果是否足够?] H -- 否 --> B H -- 是 --> D D --> I[流式返回给用户] I --> J[用户可中断/追加要求] J --> B</div> 这个图表达的是： <ul> <li>Agent 是闭环系统，不是单次函数。</li> <li>“工具”是能力放大器，不是附属品。</li> <li>用户在回路内，而不是回路外。</li> </ul> <h3 id="整体架构图">整体架构图</h3> <div class="mermaid">graph LR subgraph Interaction Layer[交互层] UI1[TUI/CLI] UI2[RPC/API] UI3[Web/App] end subgraph Runtime Layer[运行时层] SESSION[会话编排器] POLICY[策略中心: 重试/压缩/预算] end subgraph Core Layer[核心层] LOOP[Agent 决策循环] STATE[状态管理] EVENTS[事件总线] end subgraph Capability Layer[能力层] TOOLS[工具系统] MODEL[模型适配层] MEMORY[记忆与上下文管理] end UI1 --> SESSION UI2 --> SESSION UI3 --> SESSION SESSION --> LOOP SESSION --> POLICY LOOP <--> STATE LOOP --> EVENTS LOOP <--> TOOLS LOOP <--> MODEL POLICY <--> MEMORY MODEL --> LLM[外部模型服务]</div> <h3 id="组件图理解谁负责什么">组件图（理解“谁负责什么”）</h3> <div class="mermaid">flowchart LR USER[用户] ORCH[会话编排器] CORE[Agent Core] ADAPTER[模型适配器] TOOLRUN[工具执行器] OBS[观察与事件] USER <--> ORCH ORCH <--> CORE CORE <--> ADAPTER CORE <--> TOOLRUN CORE --> OBS OBS --> ORCH</div> 职责拆分： <ul> <li>会话编排器：处理用户输入、会话状态、重试和压缩策略。</li> <li>Agent Core：只做“思考循环”和“状态推进”。</li> <li>模型适配器：屏蔽不同模型供应商差异。</li> <li>工具执行器：统一执行本地或远程工具。</li> <li>观察与事件：把过程变成可见信号给 UI/日志系统。</li> </ul> <hr> <h2 id="落地这些设计必备协议和基础设计模式是什么">落地这些设计，必备协议和基础设计模式是什么</h2> 这一节是完成上面设计的“最小必需品”。需要从协议、设计模式角度考虑引入哪些工程实践。（好比盖摩天大楼，需要先定义好用什么材料、哪些通用的工程设计可以拿来就用、如何让建筑结构从力学上经得起时间验证）。 这些协议目前大部分由开发者按需设计实现，但是在不远的未来，很可能逐个出现标准规范。 <h3 id="必备协议不全就会失控">必备协议（不全就会失控）</h3> <ol> <li>消息协议（Message Protocol）</li> </ol> <ul> <li>统一描述用户消息、助手消息、工具结果。</li> </ul> <ol start="2"> <li>事件协议（Event Protocol）</li> </ol> <ul> <li>统一描述开始、更新、结束、错误、工具执行状态。</li> <li>目的：让 UI 和日志看到“过程”，不是只看到“结论”。</li> </ul> <ol start="3"> <li>工具协议（Tool Contract）</li> </ol> <ul> <li>工具名、参数结构（Schema，字段规则）、执行返回格式必须固定。</li> </ul> <ol start="4"> <li>流式协议（Streaming Contract）</li> </ol> <ul> <li>支持增量输出（delta，分段输出），保证用户实时反馈。</li> </ul> <ol start="5"> <li>取消协议（Cancellation Contract）</li> </ol> <ul> <li>任意环节都应响应中止信号，避免“停不下来”。</li> </ul> <ol start="6"> <li>错误协议（Error Contract）</li> </ol> <ul> <li>失败必须结构化（可机器处理），不能只靠字符串报错。</li> </ul> <h3 id="需要理解的基础设计模式">需要理解的基础设计模式</h3> 对于没有编程经验的读者，下面的一些编程基础设计模式，需要你先从其他资料中理解。 <ol> <li>状态机（State Machine）</li> </ol> <ul> <li>Agent 每一步都有状态转移（例如：等待输入 -> 生成输出 -> 工具执行 -> 回到生成）。</li> </ul> <ol start="2"> <li>发布-订阅（Pub/Sub，发布与订阅）</li> </ol> <ul> <li>Core 发事件，UI/日志订阅事件。</li> <li>好处：核心逻辑不依赖具体界面。</li> </ul> <ol start="3"> <li>适配器（Adapter）</li> </ol> <ul> <li>把不同模型接口包装成统一调用方式。</li> </ul> <ol start="4"> <li>策略模式（Strategy）</li> </ol> <ul> <li>重试策略、工具并发策略、压缩策略可替换。</li> </ul> <ol start="5"> <li>管道与过滤（Pipeline）</li> </ol> <ul> <li>输入预处理 -> 模型调用 -> 工具执行 -> 后处理，是可插拔链路。</li> </ul> <ol start="6"> <li>幂等与可恢复（Idempotency/Recoverability）</li> </ol> <ul> <li>同一操作重复执行不应产生灾难性副作用，失败后能恢复。</li> </ul> <hr> <h2 id="以-pi-agent-为例设计理念与架构">以 PI Agent 为例：设计理念与架构</h2> 前面是“通用 Agent 框架设计”。现在落到最近很火的极简框架 <a href="https://github.com/earendil-works/pi">PI Agent</a> 。 一起来看看这个框架是如何设计 Agent 的。 <h3 id="设计理念">设计理念</h3> <ol> <li>内核最小化</li> </ol> <ul> <li>Core 只负责循环、状态、事件、工具编排。</li> </ul> <ol start="2"> <li>外围可插拔</li> </ol> <ul> <li>模型、工具、重试、上下文处理都可替换。</li> </ul> <ol start="3"> <li>过程优先于结果</li> </ol> <ul> <li>先保证过程可见、可控，再追求“聪明输出”。</li> </ul> <ol start="4"> <li>会话优先于请求</li> </ol> <ul> <li>把 Agent 当长期会话系统，不当单次 API 调用。</li> </ul> <h3 id="agent-core-逻辑流程图">Agent Core 逻辑流程图</h3> <div class="mermaid">flowchart TD START[开始一次会话回合] --> TURN[开启 turn] TURN --> CALL[调用模型并流式接收输出] CALL --> CHECK{输出里有工具调用?} CHECK -- 否 --> STOPCHECK{是否停止?} CHECK -- 是 --> TOOL[执行工具批次] TOOL --> MERGE[把工具结果写回上下文] MERGE --> STOPCHECK STOPCHECK -- 停止 --> END[结束并发出结束事件] STOPCHECK -- 继续 --> NEXT[进入下一回合] NEXT --> TURN</div> <h3 id="agent-core-组件关系图">Agent Core 组件关系图</h3> <div class="mermaid">graph TD CORE[Agent Core] S[State 状态存储] L[Loop 回合循环] E[Events 事件发射] T[Tool Executor 工具执行] M[Model Stream 模型流调用] Q[Queue 消息队列: steer/followUp] CORE --> S CORE --> L L --> M L --> T L --> E L --> Q T --> E M --> E E --> S</div> 这个结构的价值是： <ul> <li>交互层只看事件，不碰核心状态。</li> <li>模型替换不会改循环骨架。</li> <li>工具扩展不会破坏核心控制流。</li> </ul> <hr> <h2 id="小结">小结</h2> Agent 架构不是“让模型更聪明”，而是“让不确定的模型在可控系统里稳定工作”。 你可以把它记成这个公式： $$ \text{可用 Agent} = \text{模型能力} \times \text{工程控制能力} $$ 其中工程控制能力主要来自： <ul> <li>循环设计</li> <li>协议设计</li> <li>事件可观察性</li> <li>可恢复与可扩展性</li> </ul> 从目前的趋势看，这大概率将是下一代应用软件的基础范式。

2026/5/26