46 篇文章带有标签 “ai-agent”

实践记录：我用 Claude Code 加 mattpocock/skills 技能集，从零开发了一款 macOS 原生应用「长辈计算器」。本文以这次真实开发为主线，拆解这套"AI 原生"软件工程流水线的每个环节、它背后的设计哲学，以及实战中暴露的问题。原始对话实录见前一篇。

一、为什么是"AI 原生"而不是"AI 辅助"

大多数人的 AI 编码方式是：打开编辑器，描述一个需求，AI 吐出代码，人肉检查。这是 AI 辅助——AI 是打字快的初级程序员，工程过程还是人的那套。

AI 原生的含义不同：整个软件工程过程——需求澄清、规格化、任务拆解、实现、测试、评审——都围绕 AI 的特性重新设计。AI 的特性是什么？

AI 的特性	对工程过程的要求
上下文窗口有限，塞满后质量衰减	任务必须切成"单个上下文能装下"的批次
每次会话开始时最"清醒"	频繁开新会话，而不是一条会话干到底
不会主动追问，猜错了就错到底	需求阶段强制访谈，分歧在写代码前解决
产出无限、判断有限	人只做检查点决策，不做中间执行
记不住上一次的对话	共识必须落盘为文件，而不是留在脑子里

mattpocock/skills 就是围绕这张表设计的。

摘要：在 LLM 标称上下文窗口动辄 1M、2M 的今天，工程落地的残酷真相却是：上下文用得越多，模型表现往往越差。本文基于 Smart Zone（黄金上下文区间） 概念，深度拆解上下文用量超越 40% 后的能力崩塌逻辑，剖析能力、行为、经济三大隐形边界，并结合“大文本处理”、“KV-Cache”等场景给出 Agent 上下文管理的最佳工程实践。

一、 引言：为什么上下文窗口越大，AI 反而越“傻”？

随着长上下文（Long-Context）技术的普及，许多开发者形成了一种思维惯性：把整个项目代码库、长篇文档、全量日志和全部历史对话一股脑塞给 AI Agent。

然而，HumanLayer 创始人 Dex Horthy 提炼出的工程实践法则表明：当上下文占用突破标称窗口的 40% 后，AI 的输出质量、推理准确率和任务完成度会面临急剧下滑。

为了直观展现这一现象，我们可以总结出Smart Zone（黄金上下文区间） 核心图景：

gantt
    title AI 编程助手上下文区间与边界示意图 (Smart Zone vs Danger Zone)
    dateFormat X
    axisFormat %s%%

    section 区间划定
    Smart Zone (黄金上下文区间)  :active, zone1, 0, 40
    Danger Zone (危险/衰减区间)  :crit, zone2, 40, 100

    section 核心边界拐点
    能力边界 (Accuracy Degrades, 16-24%)  :milestone, m1, 20, 20
    经济边界 (Cost Escalation, ~20%)      :milestone, m2, 20, 20
    行为边界 (Context Anxiety, ~30%)      :milestone, m3, 30, 30
    Safeguard Line (/clear 截断告警线, 40%) :milestone, m4, 40, 40

二、 核心公式：决定模型输出质量的两大隐形杠杆

在长上下文互动中，控制模型输出质量的本质是控制以下两个指标：

1. 信号密度（Signal Density）

$$\text{信号密度} = \frac{\text{任务相关 Token}}{\text{窗口内总 Token}}$$

• mattpocock-skills

安装

npx skills add mattpocock/skills

初始化（/setup-matt-pocock-skills）

/setup-matt-pocock-skills

在你的 agent 中，每个仓库运行一次。它会：

• 问你想使用哪个 issue tracker（GitHub、Linear 或本地文件）
• 问你在 triage ticket 时会给它们打什么标签（/triage 会用到标签）
• 问你想把我们创建的文档保存在哪里

目录结构

.
├── CLAUDE.md
└── docs
    └── agents
        ├── domain.md
        ├── issue-tracker.md
        └── triage-labels.md

软件开发工作流程

grill-with-docs → to-spec → to-tickets → implement (tdd → code-review) → code-review

/grill-with-docs

description

一场为锐化计划或设计而不留情面的访谈，过程中还会同步创建文档（ADR 与术语表）。调用 Skill 工具两次，分别传入 "grilling" 和 "domain-modeling"。

详细介绍

grill-with-docs 就一个方案或设计对你进行访谈，直到你和 ag

Simon Willison 的 《Agentic Engineering Patterns》（智能体工程模式） 是一份面向软件工程师的实践指南，重点探讨在 Coding Agents（如 Claude Code、OpenAI Codex、Cursor 等能自主生成并执行代码、运行测试的智能体）普及的新时代，如何高效、高质量地进行软件开发。

一、 核心理念：什么是智能体工程？

Agentic Engineering（智能体工程） 明确区别于 Vibe Coding（氛围编程）：

• Vibe Coding：通常指非程序员完全依赖 LLM 编写代码，自己不看也不理解代码细节。
• Agentic Engineering：专业软件工程师通过 Coding Agent 来放大（Amplify）自身的专业技能。工程师依然担任架构师与质量把关人的角色，而将重复性、确定性的机械操作交给 Agent。

1. 观念重塑：“代码变得极其廉价”

传统软件工程的核心约束是代码编写成本昂贵（写几百行优质代码需要数小时或数天），因此衍生出了大量的预先设计、工时评估与严格的 YAGNI（You Aren't Gonna Need It）原则。 在 Agent 时代：

• 初始代码的生成成本趋近于 0。
• 优质代码的维护与理解成本依然存在。
• 如果不对 Agent 生成的代码进行严格审查和测试，廉价的代码会迅速演变成庞大的技术债务（Technical Debt）。

在 AI 辅助编程风靡的今天，许多开发者沉浸于 Vibe Coding（氛围感编码）——直接抛出几句自然语言需求，交由 AI 自动生成代码。然而，这种“野蛮生长”的方式往往会导致需求理解偏差、架构快速腐化（Ball of Mud）、上下文遗忘以及越改 Bug 越多的困境。

Matt Pocock 的开源项目 mattpocock/skills 正是为了解决这一痛点而生。它不是一堆零散的 Prompt 集合，而是一套为 Claude Code、Codex 等 AI 编程智能体设计的系统化软件工程最佳实践。

官方体系将技能划分为两大类：

1. User-Invoked（用户触发）：由开发者在终端中通过命令显式调用（如 /grill-with-docs、/to-spec），用于任务编排与流程推进。
2. Model-Invoked（模型自主调用）：由 AI 在执行具体任务时自行判断并调用的工程纪律规范（如 /tdd、/codebase-design）。

工作流全景链路 (The Engineering Harness)

核心开发主流程遵循着从“模糊想法”到“高质量交付”的递进逻辑：

HTML 版本

1. OpenSpec 是什么

OpenSpec 是一套规约驱动开发（Spec-Driven Development）的工作流工具。它要解决的问题是：在 AI 智能体参与编码的场景下，如何让"想清楚 → 写计划 → 写代码"这三个动作不互相污染，并且让代码之外还有一份可追溯的事实来源。

1.1 两种产物

产物	位置	回答的问题	生命周期
specs（规格）	openspec/specs/<capability>/spec.md	系统现在是什么行为（已交付、已归档的能力）	长期存在，随每次归档增量演进
changes（变更）	openspec/changes/<change-name>/	这一次要改什么（尚未实现的计划）	完成后整体移入 changes/archive/

一句话：specs/ 是唯一事实来源，changes/ 是待实现的增量，archive/ 是它是如何达成的历史。

关键差别在于 specs/ 是能力（capability）维度、changes/ 是变更维度。同一个能力会被多次变更反复修改，每次修改只写"增量"（delta），不重写整份规格。

1.2 五步循环

每个变更都走同一条闭环，本项目严格落在这条闭环上：

flowchart LR
    E["1 · Explore<br/>和智能体一起想清楚"] --> P["2 · Propose<br/>Agent 起草方案（不写代码）"]
    P --> R["3 · Review<br/>你修正方案"]
    R --> A["4 · Apply<br/>Agent 逐项构建"]
    A --> AR["5 · Archive<br/>增量写入 specs 并归档"]
    AR -. "下一次变更" .-> E

若渲染环境不支持 Mermaid，可读作线性流程：Explore → Propose → Rev

原文：The AI-Native SDLC playbook（Anthropic Applied AI 团队） 译者注：本文为完整中文翻译，英文术语首次出现时保留原文。

代码不再是瓶颈

组织已经开始以一年前难以想象的速度用 AI 编写代码，但围绕代码的流程并没有以同样的速度改变。

许多工程团队仍然沿用同样的审批关卡、评审、交接和策略，这使得使用 Claude Code 等智能体编程解决方案带来的生产力提升被拖延抵消。

软件开发生命周期（SDLC）是将软件从想法带到生产环境的过程。大多数组织运行的都是同样六个阶段的某种版本，涵盖规划、设计、构建、测试、部署和维护软件。传统上，每个阶段都是一个由不同角色负责的独立阶段：产品经理写需求，技术架构师把需求变成设计，工程师按设计实现，受监管企业的 QA 团队进行验证，发布团队负责上线，运维团队监控运行状况。工作在阶段之间通过文档、工单和签字确认来流转。

传统的软件开发生命周期（SDLC）流程繁重，是为了确保每一步的责任与控制。然而，传统 SDLC 的设计初衷是在「编写和实现代码」这一最耗时、最昂贵阶段的年代最大化效率——而这个前提已经不复存在。PRD、估点仪式和产品安全评审，本质上都是为了在长达数周、数月甚至数个季度的开发过程中强制对齐。

传统 SDLC 的另一点是：它的各种控制措施假设每一步都由人来执行。

00 摘要：10 条核心论断

这份报告不是工具评测，也不是范式百科。它的目标是回答一个工程决策问题：如果你要在 2026 年把 AI 编程从「个人提效」推到「团队与生产系统」，你该采用哪套范式、按什么顺序、用什么门禁？ 下面 10 条论断是全篇骨架，只读这一页也能拿走结论。

1. 位移点不在「写代码」，而在「定义意图 + 验证结果」。 代码正在从「资产」降格为「构建产物」。当重写一段代码的成本趋近于零，真正稀缺的是「为什么这么做」的可追溯记录与「这样做对不对」的判定能力。
2. 瓶颈已从生成迁移到验证。 生成的边际成本在两年内下降了一个数量级，验证的边际成本几乎没动。所有有效范式（SDD 的可执行验收标准、multi-agent 的 verifier 角色、TDD-as-gate）本质上都在做同一件事：压缩单位验证成本，而不是让评审更严格。
3. 规范的复兴不是复古，而是因为规范第一次变得可执行。 1980 年代的需求文档会腐烂，因为它不驱动任何东西。2026 年的 spec.md 直接驱动生成器、被 Git 版本化、被 CI 校验——可执行，才第一次值得写。
4. AI 是放大器，不是均衡器。 DORA 2025（n≈5,000）的核心结论：AI 放大高绩效组织的优势，也放大挣扎组织的失能。平台质量、数据生态、价值流管理决定收益的正负号，工具选择只决定幅度。
5. 个体提速的证据显著弱于感知，且高度依赖任务与代码库。 METR 的 RCT（16 名资深开发者 / 246 个真实任务）显示用时增加 19%，而参与者事后仍自认为快了 20%。用「感觉更快」做投资决策是危险的。
6. AI 改变的是缺陷的「结构」，而不只是数量。 Apiiro 在 Fortune 50 仓库的观测：语法错误下降 76%、逻辑 bug 下降 60%，但权限提升路径上升 322%、架构设计缺陷上升 153%。旧门禁（SAST + 人工 diff）恰好对新增的这一类是盲的。
7. 多 Agent 是一个分布式系统问题，不是「多开几个窗口」。 隔离（git worktree / devbox）、编排（blueprint / workflow）、合并策略、可观测性四件套缺一不可；经验并行度上限在 3–5，超过后协调成本吃掉全部收益。
8. 上下文工程是 agentic 时代的内存管理，Harness 是新的性能杠杆。 Anthropic 归纳为「写 / 选 / 压 / 隔」四类策略；产业侧报告显示，同一模型换一套 harness，标准基准可差 3 个百分点以上。
9. 角色迁移是 Coder → Conductor → Orchestrator，但「可完全委托」仅 0–20%。 Anthropic 2026 趋势报告：约 60% 的工作流已含 AI，可完全委托的任务却不到两成。这是协作悖论，是稳态，不是过渡态。
10. 安全与治理必须内建在生成路径，而不是事后扫描。 AI 生成代码的漏洞率在不同口径下为 25.7%（522 样本 / 5 个 SAST）到 45%（100+ 模型 / 80 任务）；更棘手的是斯坦福实验发现的系统性过度自信——用 AI 的人写了更不安全的代码，却更相信它是安全的。

以下是 IBM 文章 《什么是规范驱动开发？》（What is Spec-Driven Development?） 的中文翻译：

作者： Anna Gutowska（IBM AI 工程师、开发者倡导者）

发布日期： 2026年5月19日

规范驱动开发的定义

规范驱动开发（Spec-Driven Development, SDD） 是一种软件开发方法论。在正式编码之前，团队需先编写并达成一份关于实现细节的详细规范（Specification）。换句话说，这份规范将作为“构建什么”以及“如何构建”的唯一真实来源（Single source of truth）。

随着 Microsoft GitHub Copilot、Anthropic Claude Code 或 IBM Bob 等 AI 工具与编程助手的普及，生成代码的门槛已大幅降低。基于先进 AI 模型的 LLM 驱动型 AI Agent，只需用户输入一条自然语言提示词（Prompt），即可随时实时运行一系列迭代任务。

对于软件开发而言，这意味着我们可以优化并自动化构建原型、新功能、单元测试等的开发工作流。生成代码从未如此简单。然而，“氛围程序员”（Vibe Coders）需要警惕一个潜在风险：AI 的表现上限完全取决于它所接收到的指令质量。

技术债务的抬头：一个典型场景

你可能在现实世界中见过技术债务，甚至自己都没意识到。

Hermes vs. OpenClaw - When to Reach for Which Agent

发布时间：2026-05-07 作者：Brendan O'Leary

上周，有人在 Kilo Discord 里问："我该从 OpenClaw 切换到 Hermes 吗？" 自 Hermes 今年二月发布以来，这个问题我已经见过不下十几次。问得好 —— 两者都是开源的，都能连接你的聊天应用，都能运行工具、记住上下文。单看功能列表，它们几乎一模一样。

但过去两个月同时运行两者之后，我认为功能清单反而让人分心 —— 真正让它们分道扬镳的是设计哲学。

Hermes 是在一个学习型智能体外包裹了一个网关。

OpenClaw 是在一个消息网关内包裹了一个智能体。

这个区别听起来很抽象，但它对你配置和与每个工具交互的方式有着切实的影响。

Hermes：智能体优先

Hermes Agent 来自 Nous Research，于 2026 年 2 月发布。截至本文撰写时，GitHub 星标数约为 13.5 万。其 headline 功能是所谓的"学习循环" —— 智能体会基于自身行为创建并进化自己的技能。

根据其功能文档：

• 自我改进的技能：智能体从经验中生成程序性知识。同一类任务跑上一百次，Hermes 真的会越做越好。
• 五种沙箱后端：本地执行、Docker、SSH、Singularity 和 Modal。你可以自行选择命令执行的隔离程度。
• 子智能体委派：生成拥有独立上下文和终端的子智能体。并行工作流，互不污染上下文。
• 更广泛的浏览器/语音栈：Browserbase、Browser Use、Firecrawl、本地 Chrome，外加 Discord 频道原生语音支持。

KiloClaw 安全

安全架构、租户隔离与面向托管式AI智能体算力的数据保护

2026年2月 v1.0；Andrew Storms 独立安全评估

KiloClaw 是一个托管式计算平台，在每个专用虚拟机中运行每个用户的 AI 智能体实例。每位客户都会获得一个隔离的环境，其 AI 智能体可以在其中执行代码、访问文件系统、浏览网页以及连接到聊天频道（如 Telegram、Discord 和 Slack）。

对于代表客户执行任意代码的 AI 智能体托管式计算这类产品，其安全风险本身就很高。租户隔离的失误可能会将一个客户的秘密、对话和已连接账户暴露给另一个客户。机密管理的失误可能会危及客户托付给该平台的 API 密钥。

本白皮书介绍了 KiloClaw 的安全架构、保护客户数据的控制措施，以及 2026 年 2 月进行的独立安全评估的结果。它面向评估 KiloClaw 是否适合其组织的安全团队、合规官和技术决策者。

评估摘要

一项为期10天的独立安全评估通过威胁建模（采用 PASTA 框架，涵盖13项资产中的30个威胁）、代码审查、60多项对抗性测试以及实时基础设施测试，验证了 KiloClaw 的架构。总体结论是：KiloClaw 的安全架构是健全的，并在多个独立层实施了租户隔离。

KiloClaw 的工作原理

理解安全模型需要先理解其架构。

聊天软件集成 OpenClaw 的方式

聊天软件要集成 OpenClaw，主要有这几类方式（可以组合）： 用 OpenClaw 自带的“Channel 插件”直连（推荐，最省事） Telegram、WhatsApp、Discord、Slack、飞书/Lark、钉钉、Teams、Google Chat、Mattermost、Matrix、IRC、LINE、Signal、iMessage 等。 在 OpenClaw 的初始化或 openclaw channels add 里直接选通道、按向导配置即可。 本质上是：各 IM 的 Bot API / Webhook / Socket Mode / QR 扫码 对接到 OpenClaw 的 Gateway。初始化向导里可以看到支持的通道清单。 通用 HTTP 接口集成（适合任意聊天平台） OpenClaw 的 Gateway 提供了一个 HTTP 端点 /tools/invoke，可以调用单个工具（例如创建会话、发消息、拉取历史等），支持 Bearer 认证和 OpenAI 兼容的 /v1/* 风格接口。 你的聊天软件后端只要能发 HTTP POST，就可以用这个接口和 OpenClaw 交互。

1. Hermes 智能体基础认知与发展概况

1.1 技术定义与核心特征

Hermes Agent 是由 Nous Research 开发的开源自主 AI 智能体，于 2026 年 2 月正式发布，其核心定位为 "与你共同成长的智能体"（The agent that grows with you）(1)。与传统的 AI 聊天机器人或 IDE 绑定的代码补全工具不同，Hermes Agent 是一个运行在用户服务器上的自主智能体，具有持久记忆和自我改进能力，能够在运行过程中不断学习和进化。

Hermes Agent 的技术架构采用模块化单代理持久循环设计，核心是 run_agent.py 中的 AIAgent 类（约 9200 行代码），负责同步编排整个生命周期：输入→推理→工具执行→内存更新→输出。该系统支持 Linux、macOS 和 WSL2 平台，用户可以通过一条 curl 命令完成安装，无需任何前置依赖，体现了其设计的简洁性和易用性。

在技术栈方面，Hermes Agent 基于 Python 3.11 + 开发，使用 uv (Astral) 管理，主要依赖包括 openai SDK 进行 LLM 通信、rich 和 prompt_toolkit 构建终端 UI、SQLite FTS5 实现会话持久化(97)。

Harness 工程：给 AI 智能体一个"可靠的家"

想象一下，你有一个非常聪明但有点冲动的助手——它知识渊博、能说会道，但有时候会：

• 忘记五分钟前你们讨论的事情
• 直接执行危险操作而不问你
• 在复杂任务中迷路，绕来绕去
• 做错了事，但你不知道为什么

这就是没有 Harness 的 LLM 智能体。

什么是 Harness？

Harness 这个词在英文里有"马具"、"安全带"的意思。在 AI 智能体的世界里，它就是那个让智能体既能够发挥能力，又不会失控的"安全脚手架"。

这个隐喻是有意的：

• 马是 AI 模型——强大、快速，但它自己不知道去哪里
• Harness是基础设施——约束、护栏、反馈循环，以富有成效地引导模型的力量
• 骑手是人类工程师——提供方向，而不是亲自奔跑

用一个更贴近生活的比喻：Harness 就像是智能体的"驾驶舱 + 安全带 + 导航系统 + 黑匣子"的组合体。

根据 Harness Engineering 将原始模型能力转化为可靠 Agent 行为的脚手架。实用的 Agent 最好被理解为在 Harness 内部运行的模型，而不是带有外围能力的模型。

真实故事：Harness 工程的威力

在我们深入技术细节之前，让我们看看几个真实的例子，了解为什么 Harness 工程如此重要：

Claude Managed Agents 概览

这是一个运行在托管基础设施中的预构建、可配置智能体（Agent）框架，最适用于长时间运行的任务和异步工作。

Anthropic 提供了两种使用 Claude 构建应用的方式，分别适用于不同的使用场景：

	Messages API	Claude Managed Agents
定位	直接的模型提示词访问	运行在托管基础设施中的预构建、可配置智能体框架
最佳用途	自定义智能体循环和精细化控制	长时间运行的任务和异步工作
了解更多	Messages API 文档	Claude Managed Agents 文档

Claude Managed Agents 为将 Claude 作为自主智能体运行提供了框架和基础设施。无需构建自己的智能体循环、工具执行环境和运行时，你即可获得一个全托管的环境，让 Claude 能够安全地读取文件、运行命令、浏览网页并执行代码。该框架支持内置的提示词缓存、压缩以及其他性能优化，以实现高质量、高效的智能体输出。

核心概念

Claude Managed Agents 基于四个核心概念构建：

gstack 是由 YC 首席执行官 Garry Tan 发起的开源智能体技能集（Skills），旨在将 Claude Code 等 AI 编程助手重塑为一支全栈虚拟开发团队。它通过一套高度专业化的指令流，实现了从产品构思、架构设计、自动化编码到代码评审、质量保障及发布部署的软件全生命周期闭环开发。

你：      我想为我的日历做一个每日简报应用。
你：      /office-hours（发起咨询）
Claude： [询问痛点 —— 要求提供具体的例子，而不是假设]

你：      多个 Google 日历，活动信息已过时，地点也是错的。
          准备工作耗时太长，而且效果不够好……

Claude： 我想挑战一下你的设定。你说的是“每日简报应用”，但你实际描述的是一个“AI 私人幕僚长”。
         [提取了 5 项你甚至没意识到自己已经描述出的功能]
         [挑战了 4 个前提 —— 你对此表示同意、反对或进行调整]
         [生成了 3 种实施方案及工作量预估]
         建议： 明天先上线最核心的切入点，从实际使用中学习。完整愿景是一个为期 3 个月的项目 —— 
               先从一个真正好用的每日简报开始。
         [编写设计文档 → 自动同步至下游技能]

// ...

英文版本：

这是 Andrej Karpathy 设计的极简自主 AI 研究实验框架：让 AI 智能体仅修改 train.py，在固定 5 分钟训练预算内自主迭代优化 GPT 模型、以最低验证集 bpb 为目标，自动实验、记录结果并择优保留，无人值守持续运行。

README

曾经有一天，前沿 AI 研究是由人类在吃饭、睡觉、享受其他乐趣，以及偶尔使用声波互连进行被称为"组会"的仪式之间完成的。那个时代早已远去。现在的研究完全属于运行在天空中计算集群巨型结构上的自主 AI 智能体集群。这些智能体声称我们现在处于代码库的第 10,205 代，反正没人能说得清这是对是错，因为"代码"现在已经是一个自我修改的二进制文件，已经超出了人类的理解范围。这个仓库讲述了这一切是如何开始的故事。-@karpathy，2026 年 3 月。

这个想法是：给一个 AI 智能体一个小但真实的 LLM 训练设置，让它在夜间自主实验。它修改代码、训练 5 分钟、检查结果是否有所改进、保留或丢弃，然后重复。你早上醒来时会看到一个实验日志，以及（希望）一个更好的模型。这里的训练代码是 nanochat 的简化单 GPU 实现。核心思想是，你不需要像研究人员通常那样触碰任何 Python 文件。相反，你是在编写 program.