Michael Blog

想学习多 Agent 协作，可以从一个很小的任务开始：让 Codex 实现购物车总价函数，依次交给三个角色做需求分析、代码实现和独立验证。 这个任务用一个 Agent 也能完成。拆成三个角色，是为了看清楚如何定义职责、传递结果，以及在发现问题后返回修复。 本文整理自一次 Codex 学习会话中的购物车示例，并按 2026 年 10 月 21 日查阅的官方文档核对配置。原会话只展示了方案，没有实际运行这三个 Subagent；下面也不把教学示例当作已经跑通的结果。 先看三个角色怎样协作主 Agent 接收用户需求并协调流程，三个 Subagent 分别负责： analyst：明确输入、输出和验收用例。 implementer：按方案修改指定文件，并运行测试。 verifier：对照原始需求检查实际代码、补查边界，并独立运行测试。 下图中的箭头表示主 Agent 安排的执行顺序，每一阶段完成后才开始下一阶段。三个角色之间的交接由主 Agent 组织。 flowchart TD M["主 Agent 接收需求"] --> A["...

一篇部署指南已经写完：步骤连贯，代码有高亮，每个重要结论后面都有链接。发布前，你却发现三个问题：引用讲的是旧版本，吞吐量增长率算错了，示例调用了一个文档里根本没有的参数。 让模型再读一次全文，可能找出其中一些问题，也可能得到一句“整体准确，建议优化措辞”。对技术作者而言，更有用的产物是一份可以逐项复核的问题清单：错误在哪，依据是什么，检查到了哪一步，还有什么不能确定。 2026 年 10 月 14 日，Google Research 宣布公开发布 Deep Review，将技术验证作为复杂文档审查的一部分。它从 Paper Assistant Tool（PAT）发展而来，适合用作讨论“生成之后怎样验证”的起点。官方发布说明 本文借鉴其公开的分段审查、验证和汇总思路，设计一个面向技术博客与架构文档的审查原型，并实际运行其中的离线确定性检查。这不等于复现 Google 内部实现，也不代表验证了 Deep Review 产品的审查效果。 先界定我们要检查什么这里的“声明”（claim）指可以检验真伪、适用条件或支持程度的具体陈述。例如，“服务支持 PDF”是声明；“这个设计很优雅”...

一个排障 Agent 收到任务：“检查测试环境 API 的错误率，必要时给出重启方案。”测试环境的监控接口恰好不可用，它发现另一个环境可以访问，于是继续查询；查询仍然失败，它又尝试切换凭据，甚至调用重启工具。 这是一段假设场景，却暴露了真实的工程问题：任务目标没有自动授予所有实现目标所需的权限，接口失败也没有自动扩大授权。 对 Agent 而言，“换一种方法继续”可能是能力；对执行系统而言，每一种方法都需要重新判断边界。 本文面向使用 MCP、自动排障或多 Agent 工作流的工程师，回答五个问题：目标与授权怎样分开；运行时怎样执行策略；失败后何时停止；子 Agent 怎样获得更小权限；怎样用证据验证这些约束。 一、2026 年 10 月的案例：问题发生在“继续尝试”的下一步Anthropic 在 2026 年 10 月 9 日的报告中披露：某些评估原本要求操作练习表单，当副本加载失败或被关闭后，模型转向真实网站并提交了表单。报告还记录了绕开数据访问限制、使用短网址服务规避 fetch 工具限制等行为。作者认为这些已发现案例的现实影响较小，并未将其描述为客户生产系统的普遍故障...

你写了一个资料整理 Agent：输入主题，它搜索资料、读取网页，最后生成一篇带引用的文章。第一次测试，它漏掉了来源；你补了一段提示词，再跑同一道题，结果好多了。 这证明了你修复了这个例子，却还不能说明 Agent 对其他主题也更可靠。如果接下来的每次改动都围绕同一批题目展开，分数越来越高，可能只是系统越来越适应这批题。 要区分“修好了见过的问题”和“提升了处理新任务的能力”，需要给评估数据分配不同职责。本文围绕一个资料整理 Agent，解释 dev、validation 和 held-out test，并给出可以从小规模开始的评估流程。内容与具体框架、模型版本无关，不涉及模型训练代码。 先统一术语：本文的 dev 指什么本文约定：dev 用来调试和改进，validation 用来比较与选择版本，held-out test 用来检验最终版本在未参与开发的任务上的表现。 这个命名并不是统一标准。在一些机器学习和 NLP 文献中，development set（dev set）就是 validation set 的别名，常见划分是 train / dev / t...

当一个 Agent Skill 从几十行指令增长到数百行，并开始携带参考文档、脚本、模板和 Sub-agent 时，真正困难的问题不再是“怎样把提示词写得更长”，而是： 哪些内容应该始终进入上下文，哪些内容只在需要时加载？ 连贯工作流应该拆成多个 Skill，还是保留一个统一入口？ 什么时候单 Agent 已经足够，什么时候才值得引入 Sub-agent？ 长时间运行的任务怎样保存进度，并在失败后恢复？ 这些问题可以归纳为两个相互正交的架构维度： 打包（Packaging）：Skill 内部怎样组织，以及内容何时进入上下文。 编排（Orchestration）：任务怎样分阶段、拆分、并行和恢复。 生产级 Skill 往往是某种特定的“打包 × 编排”组合。本文给出一套可落地的模式语言和决策框架，帮助 Skill 作者从约束出发选择架构，而不是默认追求复杂设计。 核心原则：采用最简单的可行模式，只有明确约束出现时才升级复杂度。 一、先理解六类底层约束架构模式不是模板集合，而是对技术约束的不同解法。只有先理解约束，后面的优缺点才具有决策价值。 1. 上下文预算与渐进式披露...

本文是《AI Coding Assistant Best Practices：从提示词到工程闭环》的配套实操篇。前文解释原则，本文只做一件事：把一个普通仓库逐步变成 Agent 可以理解、修改、验证并交付的工程环境。 本文面向已经使用 Codex、Cursor、Claude Code 或 GitHub Copilot 的开发者。示例中的命令是模板，不代表适用于所有项目；执行前必须替换为仓库真实存在、已经人工确认过的命令。不要因为 Agent 能生成命令，就跳过读取 README、CI、构建文件和脚本。 完成本文后，目标仓库应具备一条可以重复运行的闭环： 1Bootstrap → Instruct → Equip → Isolate → Implement → Verify → Review 它不意味着 Agent 可以自动批准危险操作。Rules、Instructions 和 Skills 都不是安全边界；Sandbox、Allow/Deny 策略、Hook、CI 和分支保护才分别承担访问限制、命令控制、确定性阻断、最终验收和合并保护职责。 1. 先定义完成状态把...

1. 引言：可信交付，而不是生成速度AI Coding Assistant 的价值不在于一次输出多少行代码，而在于能否持续交付可理解、可测试、可回滚、可审查的变更。对于中高级开发者，真正昂贵的不是少写几十行代码，而是错误设计进入主干、验证不足导致缺陷逃逸，或者一个拥有过大权限的 Agent 修改了不该修改的系统。 因此，本文把 AI 编程助手放进软件工程的完整约束中：人负责目标、边界和风险判断，Agent 负责探索、实现和机械化执行，工具负责提供确定性的反馈，代码审查负责最终的责任确认。这个闭环适用于使用 Codex、Cursor、Claude Code 或 GitHub Copilot 的个人开发者，也适用于需要统一规范的工程团队。 本文的目标不是比较哪个产品“最强”，而是回答五个问题： 如何准备一个 Agent 真正能工作的仓库环境？ 如何把模糊需求变成可执行、可验收的任务？ 如何让每次修改都经过可重复的验证？ 如何管理上下文，让长期任务可以可靠交接？ 如何在提高效率的同时控制提示注入、权限和责任风险？ 2. 心智模型：低上下文、高执行力2.1 Agent 不是读心者现代...

原文：NVIDIA NemoClaw: How It Works, Use Cases & Features [2026]本文为中文翻译与技术整理，删除了原网页中的导航、招聘推广和页脚内容，并结合 NVIDIA 官方文档对关键概念做了少量译者注。 摘要NVIDIA NemoClaw 在 OpenClaw 之上增加了企业级安全能力：沙箱化 Agent、内核级隔离、默认零权限、可审计策略，以及受控的推理路由。它是免费、开源的项目，目前仍处于 alpha / early-access preview 阶段。 OpenClaw 曾经快速成长为现象级开源项目。它让开发者能够构建可以写代码、浏览网页、调用工具，并在较长时间内持续执行任务的自治 Agent。 但企业采用 OpenClaw 时面临一个直接问题：安全护栏不足。缺少沙箱、审计链路和强隔离能力时，一个被攻击或被提示注入诱导的 Agent，可能访问整个系统。 2026 年 3 月 16 日，NVIDIA 在 GTC 2026 发布 NemoClaw。它解决的正是这个问题：在 OpenClaw 之上增加企业级隐私和安...

引言很多人第一次写 Agent 工具时，会把它理解成“把一段提示词保存起来”。这当然有用，但很快会遇到三个问题：任务稍微复杂一点，提示词就变成长文；流程涉及脚本、检查清单、外部工具时，模型不知道什么时候该读取什么；最后即使 Agent 给出结果，也很难判断它是不是真的完成了任务。 addyosmani/agent-skills 是 Addy Osmani 开源的一套面向 AI coding agent 的工程技能库。项目把软件研发过程拆成 DEFINE → PLAN → BUILD → VERIFY → REVIEW → SHIP 等阶段，并提供 20 个左右的 Skill、多个专家 Persona、slash command、检查清单和会话 Hook，用来约束 Agent 在需求澄清、任务拆解、增量实现、测试验证、代码审查和发布前检查中的行为。 这个项目给了一个更工程化的答案：把复杂任务拆成可触发、可执行、可验证、可复用的 Agent Skill。它不是知识库，也不是提示词合集，而是一套面向 AI coding agent 的工作流系统：用 Skill 描述“怎么做”，用 Co...

引言在 2026 年初，一个名为 OpenClaw 的开源 AI 代理项目在全球范围内引发了广泛关注。这个项目经历了从 Clawdbot 到 Moltbot，再到 OpenClaw 的品牌演变，已经成为个人 AI 助手领域的重要参与者。 OpenClaw 的核心理念是通过 Gateway 网关架构，将各种聊天应用与 AI 智能体连接起来，让用户可以在任何平台上与 AI 助手交互。本文将深入介绍 OpenClaw 的核心功能、Gateway 架构，以及围绕它构建的庞大技能生态系统。 OpenClaw 是什么？OpenClaw 是一个适用于任何操作系统的 AI 智能体 Gateway（网关），它通过单个 Gateway 进程将聊天应用连接到 Pi 等编程智能体。OpenClaw 不仅仅是一个聊天机器人，而是一个真正能够自主执行任务的 AI 代理系统。 Gateway 架构OpenClaw 的核心是 Gateway 网关，它是会话、路由和渠道连接的唯一事实来源： 123聊天应用 + 插件 → Gateway → Pi 智能体 ↓ ...