本文深入探讨了当前AI Agent领域从单循环（loop）向图结构（graph）转变的本质。作者指出，单循环优化存在四种典型失败模式：古德哈特效应（目标绑架）、向上盲视（不质疑目标合理性）、多循环冲突、以及测量退化。成熟的系统通过构建循环网络——包含冠军-挑战者循环、漂移监控、回滚机制和独立审计循环——来缓解这些问题。然而，图结构并非万能：若无锚定（anchors）和与现实世界的接触，它会沦为自我指涉的表演。文章强调，真正的进步不在于采用哪个模式，而在于保持改进机制与现实的连接，以及承认最终目标的设定需要人的判断。适合AI工程、MLOps和Agent设计者阅读。
绝大多数多步Agent被设计成单线程线性链，每个步骤依次等待，缺乏并行与分支，导致效率低下且易丢失上下文。本文提出基于图结构的Agent工程方法，使用Claude Code的dynamic workflows将Agent组织为有向无环图：节点是带合约的工作单元，边是数据流依赖。核心模式包括扇出并行（parallel()）、扇入汇聚、运行时路由、验证器防线、循环收敛等。文章提供14个具体步骤，附带代码示例和拓扑图，展示如何用图结构替代线性脚本，实现可扩展、可控的Agent协作。目标读者是构建多步骤Agent的工程师，尤其是希望提升Agent并行度和可靠性的实践者。
Anthropic 工程师基于内部使用数百条 Claude Code 技能的经验，系统总结了技能的九大类型（库/API 参考、产品验证、数据获取、业务流程、代码模板、代码质量、CI/CD、Runbook、基础设施运维），并给出了具体编写技巧：聚焦非显而易见的提示、构建 Gotchas 部分、利用文件系统渐进式披露、避免过度约束、合理设计配置、用 description 字段触发选择、在技能内存入数据（如日志文件或 SQLite）、以及用脚本/库减少模型 token 消耗。文章还讨论了技能的分发方式（仓库内嵌 vs 插件市场）、依赖组合与埋点测量。适合正在构建 Agent 工作流的工程师参考。
本文作者分享了自己从最初失败的长任务Agent编排尝试，到发现并使用Superpowers这一Skill Set解决核心痛点的经验。Superpowers通过将开发流程拆解为“头脑风暴（brainstorming）→ 编写计划（writing-plans）→ 执行计划与Subagent驱动开发（executing-plans / subagent-driven-development）”三个阶段，确保长任务的可控性与交付质量。关键设计包括：用多个Prompt模板（implementer、spec-reviewer、code-quality-reviewer）分离执行与评审职责；为每个Task创建独立Subagent并禁止继承主Session Context，防止上下文污染；通过“Never/HARD-GATE”等强约束词防止AI跑偏；贯彻TDD、DRY、YAGNI等软件工程原则。作者认为，当前Frontier模型（Opus 4.8、Codex GPT-5.5）能力已足够，核心在于Harness设计——通过规约与流程让模型变得可靠。
vLLM Semantic Router 提出了一个不同寻常的视角：路由器不只是请求分发器，更是模型能力的放大器。其核心思想是将多个模型的协作封装在同一个模型 API 调用内，用户看到的仍然是一个普通模型端点（vllm-sr/auto），但背后路由器可以根据任务自动选择协作模式——从成本感知的串行升级（Confidence）、并行聚合（Ratings），到多轮推理合成（ReMoM）、分歧发现（Fusion），乃至带资源预算的微代理工作流（Workflows）。这些模式都是可控、可配、可观测的运行时，而非应用层胶水代码。评测显示，在 LiveCodeBench、GPQA-Diamond、Humanity's Last Exam 三个硬基准上，这套闭源模型协作方案（VSR Closed）分别达到 92.6%、96.0%、50.0%，持平或超过了 Fugu Ultra、GPT-5.5 等单一前沿模型。这篇博文的价值在于，它首次把“多模型协作”从产品端或应用端下沉到了 serving 基础设施层，并且坚持以一个模型身份暴露，极大降低了接入成本。适合正在构建推理路由、多模型策略或成本优化方案的工程师阅读。
本文详细拆解了在Claude Code中使用Dynamic Workflows并行调度多个子Agent的9个步骤。作者指出，单纯并行启动多个Agent很容易导致冲突和混乱，真正的关键在于主管Agent的编排循环：先检查任务是否可分解，让主管Agent分解为原子子任务并等待人工审批，通过Git Worktree隔离每个子Agent的工作目录，并行分发后使用SubagentStop Hook强制门控（运行测试和lint），再用一个独立评分Agent根据预设标准评估每个结果并自动退回不合格者，最后只由主管Agent按依赖顺序合并通过的提交。文章强调，核心技能不是‘能启动10个Agent’，而是能收回10个干净、已测试、已合并的结果。
本文详细拆解了AI驱动开发循环（Loop）的工程实践，作者通过真实案例（单工程师月提259个PR vs 循环失控烧掉$47,000）引出核心矛盾：构建高效自动化的同时必须配备可靠的制动机制。文章将循环分解为状态文件、自动化触发/调度的具体命令、Git 工作树隔离、技能配置、MCP 连接器、子代理分离等6个可操作部件，并给出了每个部件的配置示例（Claude Code 和 OpenAI Codex 双版本）。同时提供了刹车配置模板（最大步数、预算上限、作用域、断路器）、四种常见失败模式及低成本入门方案。适合正在构建或评估AI代理工作流的工程师阅读。
AI 编码圈正从“写提示词让 agent 干活”转向“设计循环让 agent 自己干活”。本文是最接地气的实操版：什么是 agent loop，为什么它重要，生产环境里长什么样。作者拆解了 loop 的六个固定部件（触发、隔离、上下文固化、工具连接、独立评审、持久化状态），并用 PR babysitter（每15分钟检查PR，CI红则自动修复一次）和 Claude Code 的 /goal 命令作为具体例子。文章还讨论了 loop 的成本模型（迭代次数才是预算线，弱验证器是最贵的 bug）、何时不该用 loop（一次性修改、无明确通过条件的探索性工作）、以及常见的失败模式（验证负担转嫁给人、代码理解债累积、宽松检查导致无声漂移）。
本文展示了如何通过内外部 Agent 循环让 Skills 实现自我改进。内循环在每次新建 GitHub Issue 时通过 GitHub Action 触发云代理，运行分类技能并打标签。外循环每天运行一次，检查所有人工修正的标签和评论，自动生成 diff 更新技能文件，并合并回主分支。作者以 issue triage 为例，使用 Warp 的 Oz 云代理平台给出完整配置和代码示例，并提供了可复现的示例仓库。该方法适用于代码审查、Bug 修复、事件响应等场景。适合正在构建 AI Agent 并希望技能持续优化的工程师。
作者 Mike Piccolo 提出了一个观点：当前主流的 agent 框架（如 LangGraph, CrewAI）将循环、工具、记忆、审批等职责捆绑为一个整体，导致团队后期不得不重写整个 harness。他介绍了 iii 引擎的 worker 架构，将 agent 运行所需的 13 项职责（凭证解析、策略检查、会话持久化、预算追踪等）拆分为 11 个独立的 worker。每个 worker 通过同一个 WebSocket 原语（iii.trigger) 在总线上注册函数和触发器，能够像积木一样被单独添加、移除或替换。文中用生产环境的实例拆解了从 API 请求到 turn 状态机、流式响应、工具调用审批、预算记账和 OpenTelemetry 追踪的全链路，并给出了替换模型目录、新增模型供应商、私有 skill 存储、自定义审批界面等 5 个具体替换案例。核心论断是：agent harness 不应是一个需要被 fork 的单一框架，而应是一组可组装、独立版本化的 worker 合集，使架构从“选边站”的厚薄之争，变为一个可由配置文件滑动调节的连续体。本文适合在自建 agent 系统中遇到框架边界限制，或对松耦合 agent 基础设施设计感兴趣的后端工程师。
Anthropic 官方发布的金融领域 Claude 智能体参考实现，提供 9 个覆盖投行、研究、私募、财富管理等核心场景的端到端工作流代理，以及 8 个垂直技能包和 12+ MCP 数据连接器。所有内容均为 Markdown/YAML 配置，可一键安装为 Claude Cowork 插件或通过 Managed Agents API 部署到自有工作流引擎。适合需要快速构建金融 AI 应用、但又希望保留定制空间的技术团队。
本文来自 Addy Osmani 对编码智能体未来工作模式的深度观察。核心观点是，与编码智能体交互的方式正从直接的提示词工程转向循环工程：工程师不再亲自写每一步提示词，而是设计一个包含定时自动化、并行工作树、项目技能、连接器插件和子智能体检查者的闭环系统，让系统自己去发现任务、分配工作、验证结果。文章详细拆解了这五个构建块及其在 Claude Code 和 Codex 中的对应实现，并强调了循环运行中必须持续关注验证、理解债务和认知舒适区的陷阱。适合正在探索如何将 AI 编码工具从一次性助手升级为持续后台工作者的资深工程师，尤其是那些关心代码质量、认知负担和成本控制的团队。
本文系统梳理了 Claude Code 于 2026 年 5 月底发布的 Dynamic Workflows 功能。不同于手动串联 prompts 或编写死板的静态 harness，动态工作流让 Claude 为特定任务即时生成定制的 JavaScript 控制程序。文章从底层思维模型切入，解释了工作流如何从结构上解决单一上下文窗口面临的三类失效：智能体惰性（提前终止）、自我偏好偏差（无法客观验证自身输出）及目标漂移（长对话后丢失约束）。随后逐一拆解 6 种核心模式：分类后路由（classify-and-act）、扇出后综合（fan-out-and-synthesize）、对抗性验证（adversarial verification）、生成后筛选（generate-and-filter）、竞标赛排序（tournament）以及循环至完成（loop until done），并提供了实际的代码骨架。最后，文章展示了如何组合这些模式来解决迁移重构、深度研究、大规模分诊、代码评审等真实场景的问题，同时强调了使用 /goal、/loop 及 token 预算控制成本、用隔离模式防范来自不可信输入的提示注入风险、以及将成功的工作流保存并打包为 Skill 分发的实操技巧。适合已在使用 Claude Code 并希望突破单 agent 限制，处理长周期、高并行或需要严格校验的复杂任务的工程师阅读。
Anthropic 工程师 Thariq Shihipar 介绍了 Claude Code 新增的动态工作流功能，允许 Claude 在运行时自动生成定制的 JavaScript 编排脚本来协调多个子智能体。文章详细阐述了为什么需要绕过单上下文窗口的局限性，如智能体惰性、自我偏好偏差和目标漂移，并给出了分类-执行、扇出-聚合、对抗验证、锦标赛等具体的编排模式。作者通过迁移重构、深度研究、大规模分类、根因分析等真实用例展示了该功能的适用场景，同时诚实地指出动态工作流会增加 token 消耗，并不适合常规编码任务。文中还提供了组合使用 /goal、/loop 命令以及设置 token 预算的操作性建议，适合希望突破单一智能体能力边界的一线工程师阅读。