像高级工程师一样用 Claude，而不是当聊天机器人

Fri, 07 Aug 2026 00:00:00 +0800

引言：两种用法之间的鸿沟
第一步：搞清楚你正在和哪个 Claude 对话
第二步：停止”提示”，开始”简报”
第三步：用努力控制，而不是碰运气
第四步：学会 Claude Code——真正的杠杆在这里
第五步：给 Claude 正确的上下文，而不是全部上下文
- Projects（项目）
- Artifacts（工件）
第六步：用 MCP 把 Claude 接到你的真实工具上
第七步：像 review 初级工程师的 PR 一样 review——因为它就是
一个现实的端到端工作流
把高级用户和聊天用户分开的五个习惯

引言：两种用法之间的鸿沟

大多数人在 Claude 里输入的方式，就像在操作一个搜索框：”帮我写一个做 X 的函数。”复制，粘贴，祈祷它能编译。

有经验的工程师是另一种用法：把 Claude 当成一个能读仓库、规划工作、执行命令、修改文件、最后交给你一份可审查 diff 的智能体——而真正上线的代码，决定权始终在你手里。

这两种工作流之间的差距是巨大的。而在 2026 年，围绕 Claude 的工具链已经快到这个程度：“聊天机器人”的心智模型，现在成了拖累大多数人进步的头号因素。

这篇文章是第二种用法的实操指南。没有 hype，没有”AI 将取代开发者”的论调，只有今天怎么从 Claude 拿到高级工程师级输出的具体方法。

第一步：搞清楚你正在和哪个 Claude 对话

谈技巧之前，先把模型选对。用错档次，是最常见的浪费时间和金钱的方式。

2026 年中的产品线，你需要关注的是：

模型	定位	价格（输入/输出，每百万 token）
Claude Sonnet 5	免费/Pro 版默认，原生 1M token 上下文，日常主力	发布价 $2/$10（8月31日前），之后 $3/$15
Claude Opus 5	困难 agentic 编码和企业级工作，默认高推理强度，有 `xhigh` 档	—
Claude Haiku 4.5	快速便宜，适合分类、简单转换等高吞吐低延迟任务	—
Claude Fable 5（Mythos 级）	Opus 之上的一档，用于最难、最长周期的推理，价格约为 Opus 两倍	大多数团队用不上

实操规则就一句话：

Sonnet 5 干大多数活。Opus 5 留给真正困难或长周期的任务。Haiku 用于便宜的批量调用。

一个值得知道的坑：Sonnet 5 和 Opus 4.7+ 用了新的 tokenizer，同样的文本可能比老模型多消耗大约 1.0–1.35 倍的 token。Anthropic 把 Sonnet 5 的发布价定在让你切换后成本大致持平的水平，但如果你在盯账单，别假设 token 数和上个季度完全一样。

第二步：停止”提示”，开始”简报”

高级工程师不会丢给初级员工一句话就走人。他们会给上下文、约束条件，以及”完成”的定义。

对 Claude 也该这样。

弱提示：

Add caching to this API client.

高级工程师级别：

You are working in an existing Swift package. Do not restructure the module.

Task: Add a lightweight in-memory response cache to APIClient.

Constraints:
- Cache only GET requests.
- TTL should be configurable, default 60 seconds.
- Thread-safe. Assume concurrent access.
- No new third-party dependencies.
- Keep the public API backward compatible.

Definition of done:
- Existing tests still pass.
- Add unit tests for cache hit, cache miss, and expiry.

Before writing code, list your plan and the files you will touch.

第二个版本有效，是因为它给了 Claude 一个好工单给人类时同样给的东西：范围、边界和验收标准。

最后那行”先列出你的计划再写代码”，是整篇文章里杠杆最高的一条习惯。下面展开讲。

第三步：用努力控制，而不是碰运气

近几代模型把固定的”思考 token 预算”换成了自适应推理：Claude 自己评估问题有多难，决定投入多少思考。

你用一个努力等级（effort level）来引导它，而不是一个原始 token 预算——把它想象成一个从 low 到 max 的滑块。

实践中，xhigh 介于 high 和 max 之间：它用于需要额外推理、但不值得花到最大预算的困难任务。Opus 5 默认就是高努力，并针对最难的问题暴露了一个 xhigh 档。

实践中的用法：

Standard / high → 大多数编码、重构和日常问题
xhigh → 棘手的 Bug、纠结的架构决策、微妙的并发问题
max → 只留给真正艰难的一次性问题，你心甘情愿为额外算力付费

在 Claude Code 里的模式是：

/effort xhigh

然后交给它那个困难任务。

大多数人犯的错误是”为了保险起见”把所有事情都开到最大努力。那只会更慢、更贵，没有任何收益。让努力匹配难度，就像你会派资深工程师解决难题、派初级工程师解决简单问题一样。

第四步：学会 Claude Code——真正的杠杆在这里

如果你只在聊天窗口里用 Claude，你大概只用了它 20% 的能力。

Claude Code 是 Anthropic 的智能体编码工具。它跑在你的终端、桌面应用或 IDE 里，能读文件、执行命令、改代码，通过一个智能体循环调用外部工具、积累上下文、管理长会话。下面这些功能，是真正改变你工作方式的。

Plan mode（计划模式）

Plan mode 是一个只读状态：Claude 能读和分析文件，但在你批准之前，它物理上无法编辑、写入或执行命令。

它会探索你的代码库并提交一份编号计划——不执行任何东西。这是在你让它碰文件之前划定工作范围的理想方式。

用 Shift+Tab（按两次）或 /plan 切换。

工作流：

进入计划模式
描述功能或 Bug
读计划，纠正它的错误假设
然后才让它动手实现

这一个习惯，就能避免大多数”AI 失控重写了我半个项目”的灾难。

Checkpoints（检查点）

Claude Code 会在每次修改前自动给工作区拍快照，你可以按两次 Esc 或运行 /rewind 瞬间回滚。可以只回滚代码、只回滚对话，或者两者都回滚。

这是你的安全网。正是它让你敢批准大胆的重构而不害怕，因为”撤销”覆盖的是数小时的工作，而不是一次编辑。

Permission modes（权限模式）

默认模式在每次写文件和执行 shell 命令前都会询问。其他模式用监督换速度。还有一个 Auto 模式，由一个独立的分类器审查每个动作，放行安全的、拦截有风险的。

我的建议是：凡是重要的活，把权限收紧。 全自动的便利，不值得一个智能体在你的仓库里执行破坏性命令。已经有不少公开的恐怖故事，讲编码智能体在权限给得太松时删掉了数据。

Subagents（子智能体）

Claude Code 可以派生子智能体并行工作，现在它们默认在后台运行，主会话可以继续干活，它们在后台跑。

对于大活，动态工作流可以从 Claude 写的脚本编排大量子智能体，实现代码库规模的迁移。第一天你不需要这个。但知道它存在，会改变你规划大型重构的方式：不再是串行长跑，而是把工作扇出去。

第五步：给 Claude 正确的上下文，而不是全部上下文

更多上下文不等于更好。

技巧是给 Claude 正确的那一片。两个功能让这件事变简单。

Projects（项目）

在 claude.ai 里，Projects 保存你的文件。当内容接近上下文上限时，Projects 会自动切换到检索模式——Claude 搜索项目，只拉取它需要的片段。这会大幅提高有效容量，而且不需要手动配置。

用 Projects 存： 你反复回来处理的代码库、产品规格、风格指南或领域文档。

Artifacts（工件）

Artifacts 在侧边栏渲染代码、文档、图表和交互内容，带实时预览。2026 年起你可以原地编辑一个 artifact：选中你想改的部分，输入指令，Claude 内联修改。

用 Artifacts 做： 迭代一个组件、脚本、图表或小工具，你想直接看到渲染结果并就地微调。

心智模型就一句话：Projects 是长期记忆，Artifacts 是工作台。

第六步：用 MCP 把 Claude 接到你的真实工具上

这一步把玩具和工作流区分开。

MCP（Model Context Protocol） 是一个开放标准，把 Claude 接到外部系统上——GitHub、数据库、浏览器、内部服务。MCP server 负责集成，Claude 负责推理该怎么用它。

实际例子：

接一个 GitHub MCP server，让 Claude 能读 issue、开 PR、查 CI
接一个只读的数据库 MCP server，让 Claude 能对着真实 schema 回答问题
在 Chrome 里用 Claude，让它读 console 错误、网络请求和 DOM 状态来帮你调试

一句重要的提醒：一个 MCP 工具是一个真实的能力，不是一个建议。 暴露最窄的实用工具，尽量用只读的，任何破坏性操作都要过人工批准。如果你不会在第一天把裸凭据交给一个新员工，就不要把它暴露成一个无防护的 MCP 工具。

第七步：像 review 初级工程师的 PR 一样 review——因为它就是

心态转变是串联一切的关键。

Claude 很快，而且经常很出色。它有时也会自信地犯错，能产出那种”看起来够对、错得够隐蔽”的输出——瞄一眼能过、上生产就炸的那种 Bug。

所以把每一次有意义的修改，都当成一个才华横溢的初级工程师提交的 PR：

读 diff，别只看摘要。 摘要是它对自己工作的叙述。diff 才是真正发生了什么。
自己跑测试。 不要凭一句”测试通过了”就信。
在一个新会话里让它 review 自己的代码。 和写代码的会话分开跑一次 review，能降低它只是自我验证错误逻辑的概率。
对钱、认证和持久化格外小心。 任何碰到财务数据或凭据的东西，人工 review 没得商量。

Claude Code 里有一条命令就是干这个的——一次报告正确性 Bug 的代码审查 pass。用它，但把它当第二意见，不是准予放行的盖章。

一个现实的端到端工作流

这些零件在一个普通功能上是怎么拼起来的：

在仓库里打开 Claude Code。默认 Sonnet 5
进入计划模式，用范围、约束和完成定义描述功能
读计划，在写任何代码之前修正错误假设
让它开着权限实现，这样你批准每次文件写入
真遇到困难问题，升到 Opus 5，xhigh 努力档
跑测试。读 diff
发起一次新会话代码审查要第二意见
出问题了，回滚到检查点，调整简报
提交——署上你的名字，因为你 review 过了

注意你在做什么：你不在打字写代码，你在指挥和审查。这才是高级工程师的动作。

把高级用户和聊天用户分开的五个习惯

如果你只记一条：

简报，不要提示。 范围、约束、完成定义
先计划后代码。 永远让它先展示计划
让努力匹配难度。 别把所有东西都开到 max
收紧权限。 尤其是破坏性和敏感操作
review diff。 你是最后一道防线，不是模型

2026 年用 Claude 拿到 10 倍产出的人，没有秘密提示词。他们跑着一套纪律化的工作流：激进地委派，无情地验证，把人的手放在真正重要的部分上。

2026 年的 Claude 真的有能力做高级工程师级的工作。而你能否拿到高级工程师级的结果，完全取决于你怎么驱动它。

Apple 把 MacBook 变成了 Linux 开发机：WWDC 26 被忽略的重磅发布

Fri, 07 Aug 2026 00:00:00 +0800

引言：所有人都错过的那条新闻
两年铺垫：从 Containerization 框架到 container 1.0
上手实操：今天就能用起来
需要知道的坑
这对你的工作流意味着什么
Apple 到底在下一盘什么棋

引言：所有人都错过的那条新闻

WWDC 26 的 Keynote 上，Apple Intelligence 拿了最长的时段，Vision Pro 拿了最炫的 Demo，新的设计语言拿走了所有营销预算。

而整个大会对开发者来说最有分量的发布，被埋在 Session 389 里——一个叫 Michael 的工程师，在一间小房间里，讲了一整场连标题卡片都没有的演讲。

这个发布叫 Container Machine。它是一个原生运行在 macOS 26 上的 Linux 环境：启动时间不到一秒，自动挂载你的家目录，使用你 Mac 上的用户名，支持任何 OCI 兼容镜像——也就是你在 Docker Hub 上拉过的所有东西。它免费、开源、随操作系统内置。

如果你是一名开发者，曾经为了在 Mac 上测试服务器代码而维护一台 Linux 虚拟机，或者花钱买过 Docker Desktop，或者被 Orbstack 的授权条款折腾过，又或者桌上始终放着一台破旧的 Ubuntu 笔记本专门用来”跑 Linux 的活”——Apple 刚刚把所有这些基础设施变得多余了。

你的 Mac，现在是一台一等公民的 Linux 开发机。不是”一台跑着虚拟机的 Mac”，而是一台 Linux 开发机。缝隙几乎消失了。

两年铺垫：从 Containerization 框架到 container 1.0

要理解 Container Machine，得先看它脚下的一年功夫。

第一步：WWDC 25 的 Containerization 框架

2025 年 6 月，Apple 同时开源了两样东西：一个叫 Containerization 的 Swift 框架，和一个叫 container 的 CLI 工具。

Containerization 是一个底层框架——负责镜像管理、容器执行、网络、存储，以及一套完全用 Swift 编写的 Linux init 系统。container CLI 是面向开发者的封装：一个长得像 Docker 的命令行工具，可以拉取 OCI 镜像、运行它们、管理它们。

让这一切成立的关键架构决策是：每个容器一台轻量虚拟机。

Docker Desktop 和 Podman 是另一条路：它们启动一台大型 Linux 虚拟机，然后在里面跑你所有的容器。容器共享内核、共享网络接口（这就是为什么你必须用 -p 8080:8080 做端口映射）、共享文件系统挂载面。

Apple 的 container 工具则为每个容器启动一台全新的轻量 Linux VM：

启动时间亚秒级
每个容器拥有独立的 IP 地址——不需要端口映射，直接访问容器的 IP 就行
每个容器只挂载你显式共享的目录
如果你停止了所有容器，你的机器上就不会运行任何 Linux——没有后台守护进程吃资源

安全上的影响是实打实的。在 Docker Desktop 模型里，如果一个容器被攻破，共享的 VM 内核就是其他所有容器的爆炸半径。在 Apple 模型里，每个容器独占一台 VM，爆炸半径就是一个容器。

隐私上的影响同样真实。在 Docker Desktop 模型里，你把宿主机目录绑定进容器时，这个目录会先挂载到共享 VM 里，只要允许，其他容器都能看到它。在 Apple 模型里，目录直接挂进目标容器的 VM，不会进入任何其他地方。

这套架构的核心叫 vminitd——一个静态链接的 Swift 二进制，在每个轻量 VM 里以 PID 1 的身份运行。没有 libc、没有核心工具、没有动态库，用 Swift 的 Static Linux SDK 对着 musl 编译。每个容器 VM 的攻击面，是能承载你工作负载的最小的 Linux 用户态。

这是 2025 年 6 月的事，是地基。

第二步：container 1.0，2026 年 6 月 11 日

一年后，经历了从 0.1（2025 年 6 月）到 0.8（2026 年 2 月）共二十个小版本，Apple 在 2026 年 6 月初发布了 container 1.0。生产就绪，标准 OCI 镜像兼容性验证完毕，Bug 数量降到个位数，性能基准在大多数指标上和 Docker Desktop、Orbstack 持平，内存吞吐上领先。

如果你只看新闻到这一步，你会以为 Apple 造了一个更快的 Docker。并没有。他们造的是真正那个发布的地基。

第三步：WWDC 26 的 Container Machine

这才是改变开发者体验数学的那部分。

一个容器机（container machine）是一个被赋予了两种它本不该有的属性的容器：持久化，和深度宿主机集成。Apple 在 Session 里的表述很准确：它”像容器一样快而轻量，像虚拟机一样持久，加上宿主机集成，容器机用起来就像 macOS 的原生功能”。

拆开看这些词背后的含义：

持久化意味着容器机有状态。 你周二在里面 apt install 的工具，周三还在。你周三在容器家目录里写的脚本，周四还在。这不同于普通容器——普通容器里，除了显式挂载的卷，其他东西一重启就蒸发。

自动用户映射。 容器机里的用户名和你 Mac 上的用户名一致。你的 Mac 账号叫 mike，你在容器机里登录也是 mike。UID/GID 一致，权限模型跨宿主机/访客边界直接工作。

自动家目录共享。 你的 Mac 家目录默认挂载进容器机——在同一路径下。你在 Mac 的 ~/projects/web-server 里编辑的文件，就是容器机里 cargo build 读到的那个文件。没有同步、没有 docker cp、没有卷挂载声明。

工作目录继承。 你在 Mac 终端里位于 ~/projects/web-server，敲下 container machine run，进入的就是 Linux 环境里的同一路径。”等等，我现在在容器里的哪里？”这种认知开销消失了。

真正的 init 系统。 systemd 能工作。你可以把 postgres、redis、nginx 跑成正经的系统服务，而不是被包裹的进程。你最终部署到的 Linux 服务器栈，本地模拟时行为完全一致。

如果你用过 Windows Subsystem for Linux 2，这个对比很贴切。The Register 的评价是”一个 WSL 式的东西”，这个说法公允。执行模型和安全模型不同，但开发者体验的目标是一样的。

上手实操：今天就能用起来

下面是从零开始用 Container Machine 的全部命令。

安装

brew install container

就这一条。不想走 Homebrew 的话，也可以直接去 apple/container 的 releases 页面拿安装包。container 和 container machine 是同一个 CLI 的两个子命令，Container Machine 不需要单独安装——macOS 26 上随 container 1.0 一起提供。

创建你的第一个容器机

先用最轻量的基础镜像 Alpine 验证一切正常：

container machine create \
  --name dev \
  --default \
  alpine:latest

这条命令做三件事：从 Docker Hub 拉取 alpine:latest 的 OCI 镜像；基于它创建一个名为 dev 的容器机；--default 把 dev 设为默认机器，之后的命令就不用每次都指定。

验证一下：

container machine list

你会看到你的机器、它的 IP 地址、CPU 分配（默认 7 核）和内存分配（默认是你系统内存的一半）。

跑一条一次性命令

container machine run uname -a

这行会打印 Linux ... GNU/Linux——证明你在 Linux 环境里。对比一下在 Mac 终端直接跑 uname -a，打印的是 Darwin。两个不同的内核，一套工作流。

进入交互式 Shell

container machine run

不带任何参数。你现在就在 Linux 里了，坐在你启动时所在的同一个工作目录。你的 Mac 家目录在，你的用户名一样，你的文件都在。

构建一台真正的开发机

Alpine 做概念验证没问题，真干活还是想要一个更完整的发行版。下面这个 Dockerfile 给你一个可用的 Ubuntu 24.04 开发环境：

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y \
  build-essential \
  git \
  curl \
  wget \
  vim \
  htop \
  systemd \
  && rm -rf /var/lib/apt/lists/*
# 真正的 init，让 systemd 管理的服务能工作
CMD ["/sbin/init"]

用 container 工具构建它：

container build -t local/ubuntu-dev .

再把它变成一个持久化的容器机：

container machine create \
  --name ubuntu-dev \
  --default \
  local/ubuntu-dev

这就是你常驻的 Linux 机器。从此以后，你装进去的任何东西——nodejs、postgres、redis、语言工具链、自定义工具——重启后都在。

用 SSH 连上你的编辑器

开发者社区反馈最多的坑是：在 Mac 侧编辑、Linux 侧运行时，VS Code 的热重载和调试断点不干净。文件系统桥是可靠的，但文件监听事件不会传播。

解决办法在 Apple 自己的文档里，两分钟搞定：不要通过宿主机挂载编辑，改成通过 SSH 连接编辑器。

# 获取 IP
container machine list
# 直接 SSH 进去
ssh <your-username>@<container-machine-ip>

然后在 VS Code 里装 Remote-SSH 插件，指向这个 IP。现在你是在容器机的网络内编辑文件。热重载正常了，断点正常了，文件监听正常了。

这一个动作，把 Container Machine 从”适合测试”变成了”适合日常使用”。

跑一套真实的服务栈

这是让整套架构物有所值的工作流。你可以在一个容器机里跑 Postgres + Redis + 你的应用，用 systemd 管理服务，然后从 Mac 的浏览器直接访问。

在容器机内部：

sudo apt-get install -y postgresql redis-server
sudo systemctl enable --now postgresql redis-server

这行 systemctl enable --now 就是魔法所在。Container Machine 有真正的 init 系统，所以 systemctl 确实干它该干的事。Postgres 起来了，Redis 起来了，容器机重启后它们还活着，行为就像真实 Linux 服务器上的服务。

从 container machine list 拿到 IP 后，打开 Mac 上的 Safari，访问 http://<ip>:<port>，你就在访问一套远程 Linux 服务器式的服务栈了——只不过它一秒启动、共享你的家目录。

多发行版并行

你不局限于一台容器机。Ubuntu、Alpine、Fedora 可以同时跑：

container machine create --name ubuntu-dev local/ubuntu-dev
container machine create --name alpine-test alpine:latest
container machine create --name fedora-check fedora:40

指定机器执行命令：

container machine run --machine alpine-test uname -a

这就是跨发行版测试变得轻松的那部分架构。如果你的项目需要在 Ubuntu 和 Alpine 上都跑通，你在 Ubuntu 机器上编译，立刻在 Alpine 机器上测试，全程不用离开终端。

需要知道的坑

有三件事，没提前看到的话一定会绊倒你。

内存是粘滞的

容器机默认占用你系统内存的一半，空闲时不会还给 macOS。如果构建过程内存飙升，这部分内存会一直被占用，直到你重启容器机。这是 Orbstack 最受好评的功能之一（动态内存释放），Apple 还没跟上。如果你在 16GB 的 Mac 上创建三台容器机，那就是 8GB 的分配问题。建议在创建时用 --memory 给每台机器设明确的内存上限：

container machine create --memory 4g --name dev local/ubuntu-dev

还没有 GPU 和 USB 透传

如果你的工作流涉及 CUDA、GPU 加速的 ML 推理，或者需要在 Linux 里访问 USB 设备，Container Machine 目前还不适合你。这两项都有开放的 issue，盯着 GitHub 看进展。

家目录默认读写挂载是安全暴露

把整个 Mac 家目录挂进 Linux 很方便，但代价是：Linux 里跑的任何东西——包括一个恶意的 npm 包或受污染的镜像——都能读到你的 SSH 密钥、~/.aws/credentials、你的一切。可以用 --home-mount readonly 把挂载变成只读，或者用 --home-mount none 完全关闭。任何你要跑不可信代码的容器机，都建议这么做。目前还没有按文件夹的挂载粒度。

Docker Compose 缺位

如果你看过 2026 年初的社区讨论，会知道 Compose 是 container 0.x 唯一明显的缺口。到 macOS 26 的 container 1.0，这个缺口还在。Apple 没有提供 Compose 等价物。社区在填补——至少有三个第三方封装在活跃开发中——但还没有一个达到 Docker Compose 的成熟度。

目前的务实做法是：多服务负载就跑成单容器机 + systemd 管理服务，这个方案很干净。如果你真的需要每个服务一台机器的 Compose 式编排，可以写个 shell 脚本，每个服务跑一条 container machine create，再用 IP 把它们串起来。

这个问题会被解决的，是几个月的事，不是几年。

这对你的工作流意味着什么

过去十年，”在 Mac 上为 Linux 开发”的工作流大致是：装 Docker Desktop、忍受它的内存占用和授权费、写 docker-compose.yml、在共享 VM 里跑服务、挂载需要的卷、祈祷文件监听能传播、容忍各种缝隙。

Container Machine 把这条工作流压缩成三条命令和一个 Dockerfile。缝隙变小了。”我是在 macOS 还是 Linux”的认知开销消失了——你的终端看起来一样、用户名一样、家目录一样、编辑器一直开着。你敲下 container machine run，shell 底下的内核就变了。

按我的统计，实际的效率提升：

不再有 Docker Desktop 的开销，回收 2-4GB 基础内存
不再有”文件去哪了”——宿主机目录就是容器目录
本地开发不再需要端口映射，每台机器有自己的 IP
用真正的 systemd 做本地服务级测试，测的就是要部署的
不出终端就能做跨发行版测试
通过 SSH 做编辑器侧热重载（一次性配置，之后一直生效）
亚秒级冷启动意味着你可以随手 container machine create 做一次性实验

如果你往 Linux 服务器上部署任何代码——除非你全职写 iOS 应用，否则大概率是的——你在 2026 年 6 月 8 日的工作流，不该是 2026 年 6 月 25 日的工作流。工具变了，该动了。

Apple 到底在下一盘什么棋

退一步看这些命令。

Apple 花了两年时间构建开发者基础设施，只做一件事：让 Mac 成为做 Linux 服务器端开发最高产的地方。他们本不必做这些。可以把容器留给 Docker，可以给 Orbstack 套个漂亮的壳然后说搞定。他们自己动手了，用 Swift 写，为 Apple Silicon 优化，安全模型超过现有玩家。

他们在争取的，是那批为了正经服务器端工作而流失回 Linux 笔记本的开发者。Framework 笔记本那拨人，”我需要真 Linux 跑 CI”那拨人，”Docker Desktop 太重”那拨人。Apple 想让这些开发者留在 Mac 上，为此愿意花两个 WWDC 的工程资本。

而且这招正在奏效。性能基准有竞争力，架构比替代品更安全，集成比 Windows 上的 WSL 更紧密，价格是零。

你桌上的 MacBook，现在是一台一等公民的 Linux 开发机。不是在营销意义上，而是在字面意义上——你可以从这台设备上交付生产级的 Linux 服务器软件，不需要第二台机器。

这就是 WWDC 26 真正改变的东西。这是大多数报道漏掉的东西。这是一个 brew install 就能解锁的生产力。

如果你团队里还有工程师在维护一台单独的 Linux 机器专门”跑服务器那摊事”，或者还在给 Docker Desktop 付费——把这套搭建命令发给他们，这就是全部的上手曲线。

30个Agent工程核心概念，每个开发者都得知道

Mon, 13 Jul 2026 00:00:00 +0800

问题的根源：工具跑得比思想快
第一层：核心构建块
第二层：工具与能力
- 5-10. 工具层概念
第三层：记忆架构
- 11-15. 记忆层概念
第四层：安全框架
- 16-20. 安全层概念
第五层：何时不该用Agent
工程化的建议
我的判断

问题的根源：工具跑得比思想快

Agent工程领域每周都有新工具、新框架、新模型上市，每个都号称颠覆一切。如果你试图追着每个工具跑，你会发现你花在切换工具上的时间比真正使用工具多得多。

但底层逻辑没那么复杂：跑在表面的是工具名，藏在下面的是几个反复出现的核心概念。一个工具叫它”skill”，另一个叫它”rule”，再另一个叫它”workflow”或”agent instruction”——它们解决的往往是同一个基本问题。理解了这些概念，任何新Agent工具你都能一眼看穿它在做什么。

不要追每个工具，追工具背后的思想。

第一层：核心构建块

1. Agent

Agent这个词现在到处都在用，但含义已经模糊了。简单来说，AI Agent是一个不会回答一次就停下来的LLM——它在循环中运行：理解目标、决定下一步、使用工具、读取结果、再决定下一步。

对比一下：

普通聊天机器人：

你提问 → 它回答

Agent：

你给目标 → 它思考下一步 → 使用工具 → 检查结果 → 继续直到任务完成

Agent不是产生一个最终答案，而是产生一连串行动链。每个行动依赖之前的结果。编码是最清晰的例子：你让Agent调试一个失败的测试，它可能检查错误、打开相关文件、修改代码、再次运行、看到另一个错误、再修复，直到测试通过。

2. 执行模型（Think - Act - Observe）

Agent循环的核心模式只有三步：

Think（思考） → Act（行动） → Observe（观察）

模型读取当前对话、查看目标、检查可用上下文，决定下一步做什么。然后执行行动——通常是调用工具（读文件、运行命令、搜索数据库、调用API、使用MCP）。最后观察结果并决定是否继续。

3. Agent状态

Agent在循环之间需要持续跟踪的信息：对话历史、已完成步骤、中间结果、已发现的错误。状态管理是Agent设计的核心挑战之一——太简洁会丢失上下文，太详细会撑爆上下文窗口。

4. 常见Agent模式

所有Agent框架本质上只有四种工作模式：

反思（Reflection） — Agent对自己的输出做自我检查。生成代码后让另一个LLM实例审查。
工具使用（Tool Use） — Agent动态选择调用哪个工具。读文件、写代码、搜索网络、执行命令。
规划（Planning） — Agent把复杂任务分解为子步骤。如”写一个博客文章”被分解为”搜索主题→写大纲→填内容→校对”。
多Agent协作（Multi-Agent） — 不同Agent扮演不同角色协同工作。一个写代码、一个测试、一个管理任务。

第二层：工具与能力

5-10. 工具层概念

工具是Agent与外部世界交互的接口。核心概念包括：

工具定义 — 描述工具的名称、参数、返回值的schema。Agent根据描述决定何时调用。
工具调用 — Agent生成结构化调用请求→系统执行→返回结果。格式通常是JSON或function calling。
MCP（Model Context Protocol） — 标准化的工具通信协议，让不同Agent和工具之间互相发现和调用。已成为Agent工具生态的事实标准。
知识检索 — Agent搜索向量数据库或外部知识库获取相关上下文。RAG（Retrieval-Augmented Generation）是其典型实现。
代码执行沙箱 — Agent生成的代码在隔离环境中运行，防止越权操作。Docker容器、Firecracker微VM都是实现方式。
文件操作 — 读/写/搜索文件系统的标准工具。注意权限边界：Agent不应该能写系统关键文件。

第三层：记忆架构

11-15. 记忆层概念

记忆决定了一个Agent能做多复杂的持续任务。

短期记忆 — 当前会话上下文窗口内的信息。随Token过期自然消失。适用于单次任务的中间状态。
长期记忆 — 跨会话持续存在的知识。通常通过外部存储实现：向量数据库、SQLite、JSON文件。
工作记忆 — Agent在单次任务中需要记住的中间状态。如调试过程中已经检查过的文件列表。
记忆检索 — Agent主动搜索记忆存储获取相关信息的过程。搜索质量直接决定Agent的”经验”是否有效。
记忆写入策略 — 什么时候应该把信息存入长期记忆？每次交互都写会造噪音，关键转折点才写需要识别机制。

第四层：安全框架

16-20. 安全层概念

安全不是功能的对立面，是Agent投产的入场券。

护栏（Guardrails） — 定义Agent不能做什么。结构化的约束条件而非模糊的建议：明确列出被禁止的操作（”不能执行系统命令”、”不能写/etc/passwd”）。
沙箱隔离 — Agent代码执行在隔离环境中运行。容器级别（Docker）、内核级别（Firecracker/KVM）或进程级别（子进程权限降级）。
人工审批（Human-in-the-Loop） — 高风险操作需要人类确认。写文件可以自动执行，但删除数据库、下单购买必须审批。
审计日志 — Agent的每次操作记录。不是事后调试用，是在Agent运行时就能实时监控它正在做什么。
权限边界 — Agent能接触什么数据、不能接触什么数据。最小权限原则：Agent只需要完成任务所需的最小数据子集。

第五层：何时不该用Agent

这个部分经常被忽略，但比前面所有内容加起来还重要。

用提示词就够的场景： 格式化日期、转换JSON、重命名文件、生成简短答案。Agent的每个循环都消耗时间，每次工具调用都花钱。

用脚本就够的场景： 固定的步骤流程、已知的输入输出映射。一个Python脚本比Agent循环便宜100倍。

使用Agent的场景只有一个：任务不可预测，下一步依赖上一步的结果。

比如”调试这个失败的测试”——你可能不知道测试失败的原因，需要先看错误日志才能决定下一步。Agent的价值在于灵活性，而不是自动化本身。

工程化的建议

入门路径

理解Think→Act→Observe循环：这是所有Agent的基石。
掌握两种工具使用方式：预定义函数调用 vs MCP动态发现。
从单一Agent开始：不要一上来就搭多Agent系统。先让一个Agent可靠地完成单一任务。
加上安全层：护栏、沙箱、审批流。投产之前先想好失败时的回退路径。

成本意识

Agent不是免费的。每个循环消耗时间，每次工具调用花费token。一个调试任务可能调用5次工具、消耗15万token。对于每天跑100次的自动化场景，月Token成本可能远超预期。

选型原则

不看工具名，看它解决问题的维度：如果你的Agent在执行时卡壳，先检查安全护栏是否太严，再考虑记忆配置，最后才是换模型。大多数Agent框架问题出在配置而非模型能力上。

我的判断

最让我认同的是”不要追每个工具，追工具背后的思想”——工具几周一换，但底层概念几个月甚至几年不变。理解了Agent循环、工具调用、记忆架构、安全护栏这四大支柱，任何新框架都只是这些概念的不同排列组合。

不过我也注意到一个问题：30个概念中对”什么时候不该用Agent”的强调比大多数同类文章多得多，这也正是该领域最普遍的错误。Agent不是万能药，很多时候一个JSON格式化脚本比Agent循环便宜100倍。

另一个值得关注的细节是，当你真正开始写Agent代码时，最大困难不是写循环或工具调用，而是让Agent可靠地决定”什么时候停下来”。好的Agent设计 = 好的循环入口 + 好的循环出口。”什么时候算完成任务”的判断逻辑往往比”如何执行任务”更难设计。

适合：刚开始接触Agent工程的开发者。不适合：已经熟悉Agent基础概念的资深工程师。

Claude Code循环实战：从零搭建自动化工作流

Wed, 01 Jul 2026 00:00:00 +0800

从手动到自动
Loop Readiness Check：什么时候值得搭循环？
最小可行Claude Loop
Verification by Separation：校验分离
定时调度：/loop 命令
Permission Boundaries：安全边界
实战要点
总结

从手动到自动

大多数人用Claude Code的方式还是手动的：写一个提示→等它回答→检查结果→决定下一轮问什么。单次任务没问题，但一旦工作变成重复的、有状态的、需要多轮校验的，更好的抽象不是更好的提示词，而是一个循环（Loop）。

A Claude loop is a repeatable workflow around the model. It defines:

什么触发执行
Claude应该读什么上下文
它被允许做什么
输出如何验证
状态存在哪里
何时停止、重试、或升级到人工处理

模型仍然负责推理和工具调用，但循环提供了操作框架。

Loop Readiness Check：什么时候值得搭循环？

不是所有事情都值得搭Loop。在开始之前，先问自己几个问题：

任务是否涉及多步决策？ 如果只需要三步以内就能搞定，手动更快。

是否涉及外部工具调用？ 读文件、写文件、执行命令——这些是Loop的典型场景。

输出需要验证吗？ 如果输出错了不会立刻发现，说明需要内置验证。

有一个明确的完成标准吗？ 没有完成标准的Loop会无限运行。

三步以上且有明确完成标准，才值得搭Loop。

最小可行Claude Loop

一个最小的Loop由四个文件构成，放在项目的 .claude/loops/你的循环名/ 目录下。

文件结构

.claude/loops/your-loop/
├── TASK.md              # 做什么
├── LOOP_INSTRUCTIONS.md # 怎么做（含验证规则和停止条件）
├── PROGRESS.md          # 持久化状态
└── outputs/             # 每次执行的产出物

TASK.md — 任务定义

描述要完成的目标和验收标准：

# 任务：定期检查依赖更新

## 目标
每周一检查项目依赖是否有安全更新，自动更新并跑测试。

## 验收标准
- 发现过期的依赖并列出
- 更新到最新兼容版本
- 跑完整测试套件确认无回归

LOOP_INSTRUCTIONS.md — 操作指令

核心文件。定义worker和checker的职责分工：

# Loop 指令

## Worker 职责
1. 读取 TASK.md，了解本次目标
2. 读取 PROGRESS.md，了解当前进度
3. 执行一轮任务操作
4. 更新 PROGRESS.md，记录做了什么
5. 把所有产出物写入 outputs/ 目录

## Checker 职责
1. 读取 TASK.md 的验收标准
2. 检查 worker 的输出是否达标
3. 如果达标：在 PROGRESS.md 标记完成，停止循环
4. 如果不达标：在 PROGRESS.md 记录问题，触发下一轮

## 停止条件
- 任务完成（checker 确认达标）
- 重试超过 5 次
- 遇到无法自动修复的错误 → 输出人工介入指令

PROGRESS.md — 持久状态

这是Loop区别于普通prompt的关键。状态文件让每次执行都能看到前一次干了什么：

# 进度追踪

## 当前轮次：0

## 完成项
（空）

## 发现
（空）

## 待办
- [ ] 初始运行

## 决策记录
（空）

每次循环执行后，模型更新这个文件，写入当前轮次、完成了什么、发现了什么、待办项和决策记录。即使模型上下文窗口有限，也能通过读写文件延续跨轮次的工作。

Verification by Separation：校验分离

这是最核心的模式：把「执行者」和「检查者」分开。

Worker 负责执行任务、写结果。它可以犯错，允许试错。
Checker 负责审阅Worker的输出、判断是否达标、决定是否需要重做。

这种角色分离的好处是：执行者不需要同时判断自己的输出是否正确——这是人类开发者也遵循的模式（写代码的人和Code Review的人分开）。

在单个文件里就能实现这种分离：LOOP_INSTRUCTIONS.md 中分别定义worker和checker的指令块。

定时调度：/loop 命令

Claude Code 的 /loop 命令可以设置定时执行频率：

/loop every 24h    # 每天跑一次
/loop every 7d     # 每周跑一次
/loop at 9:00     # 每天早上9点

这对于以下场景特别有用：

每天凌晨检查依赖更新
每小时拉一次数据并刷新看板
每周自动生成周报

Permission Boundaries：安全边界

Loop自动化不等于让机器无限制操作。需要在 LOOP_INSTRUCTIONS.md 中定义明确的权限边界：

## 权限
- ✅ 读取：src/、tests/、package.json、requirements.txt
- ✅ 写入：outputs/ 目录、PROGRESS.md
- ❌ 写入：.env、config/production.json、.git/
- ❌ 执行：git push、npm publish、rm -rf

这些边界确保Loop在失控时不会造成破坏。

实战要点

从最小版本开始

不要一开始就想做全自动。从「一个文件 + 一个校验」的极简版开始：

建目录和 TASK.md
写 LOOP_INSTRUCTIONS.md（含worker和checker）
跑一次看看
再加 PROGRESS.md 做状态持久化
再加定时调度

Checker的能力上限

Checker的能力上限就是Claude本身的能力上限。如果worker搞不定的复杂任务，换同一个模型做checker也很难发现问题。真正需要强校验的场景，应该引入：

不同模型做checker（比如worker用Sonnet，checker用Opus）
人工审核作为回退

PROGRESS.md 的读写竞争

如果Loop同时有多个实例在跑（定时任务和手动触发重叠），PROGRESS.md的状态可能被覆盖。生产级用法应该加时间戳分隔或单向状态机。

总结

Claude Loop的核心价值不在于让模型全自动运行，而在于为重复性工作搭建一个可控的自动化框架。按照”手动测试→搭最小Loop→加校验→加状态→加调度”的顺序逐步建设，不要一步到位。

你每天用Claude Code处理重复性任务超过30分钟吗？如果是，花两小时搭第一套Loop，成本一两天就能回收。

Claude Code 5个高阶技巧，90%的开发者不知道

Wed, 01 Jul 2026 00:00:00 +0800

引言
Hack 1: CLAUDE.md 是项目简报，不是设置文件
Hack 2: Hook 强制执行 CLAUDE.md 只能请求的事
Hack 3: ultrathink 一个词改变 Claude 回答前做的事
Hack 4: /compact 加焦点指令，不做盲压缩
Hack 5: 子 Agent 保持主 Session 干净
五步实操计划

引言

在 Claude Code 终端里输入 “ultrathink”，你的模型会在回答前获得大约 32,000 个 token 的推理预算。在 claude.ai 网页聊天里输入同样的词，什么都不会发生。

这个差距——Claude Code 实际能做什么 vs 大多数开发者知道它能做什么——正是这五个技巧存在的地方。

大多数开发者用 Claude Code 的方式是在循环里跑：打一个提示，Claude 改文件，再打一个提示。这是聊天模式，大概只用到了 20% 的能力。

剩下的 80% 没有被隐藏，只是文档化得不够好。

Hack 1: CLAUDE.md 是项目简报，不是设置文件

创建 CLAUDE.md，把项目信息放进去，Claude 在每次会话开始时读取它——这是最常见的建议。

但大多数教程跳过的是：你放什么进去至关重要，而且大多数人放得太多了。

CLAUDE.md 里的指令是建议性的。Claude 大概 80% 的情况下会遵守。这个数字不是猜的——Anthropic 自己的最佳实践文档说，如果 Claude 没有某条指令也能做对，就删掉那条指令。它是噪音。

正确使用 CLAUDE.md 的方式是把当做一个给新承包商的简报：技术栈、项目结构、什么不能碰、编码约定。不是政策，不是规则——那些放别的地方（见 Hack 2）。

几条实用测试：

「如果删了这一行，Claude 会犯错吗？」 如果不会，删掉。
「这个能放到另一个文件里，等 Claude 需要时才读吗？」 如果能，移过去，用 @filename 引用。
「这是规则还是偏好？」 规则放 Hook，偏好放这里。

CLAUDE.md 太长时，埋在底部的指令开始被忽略。更短不是懒惰——是确保重要的东西真正被记住的方式。

Hack 2: Hook 强制执行 CLAUDE.md 只能请求的事

这是改变你思考如何控制 Claude Code 的那一个技巧。

CLAUDE.md 里的每条指令都是一个请求。Claude 读到它，尝试遵守，偶尔不遵守。这对风格偏好没问题，但对「永远不要 force-push 到 main」或「改完文件一定跑 linter」来说不行。

Hook 解决了这个问题。

它们是确定性的。100% 触发，没有例外。不是因为 Claude 决定遵守——因为它们是代码，不是指令。

Claude Code Hook 在 Agent 生命周期的特定节点运行：工具运行前、完成后、提交提示时、Claude 完成响应后。最有用的是 Stop hook——Claude 每完成一轮对话、等待你下一次输入时触发。

这个 hook 在每次 Claude 回应后运行。不需要指令。不需要指望 Claude 记住。 每次编辑自动过 linter，报错回到会话里，Claude 修复它们。

Hook 能做的四件实用的事：

Claude 等待权限时发送桌面通知，让你可以走开
在写入敏感文件（.env、.git/）之前拦截
Claude 写完任何文件后立即运行格式化
自动跑测试套件，失败结果喂回会话

Hook 配置在 .claude/settings.json，可以是 Shell 脚本、Python 脚本或 HTTP 调用。一旦设好，它们在每个会话里安静地后台运行，不需要你多想。

Hack 3: ultrathink 一个词改变 Claude 回答前做的事

当你正常问 Claude Code 一个问题时，它读你的提示然后开始生成响应。思考和输出在同一个流里发生。

Extended thinking 把这两个阶段分开。

Claude 先推理问题，探索方法，考虑边界情况，然后才写回答。你看到更好的推理，因为模型在提交答案之前确实做了推理。

Claude Code 有触发短语，分配不同的思考预算：

短语	推理 Token 预算
“think” 或 “think about it”	基础
“think hard” 或 “think deeply”	更多
“ultrathink”	约 32,000 tokens

一个词。放在你 prompt 的任何位置。

注意： 这只在 Claude Code 终端里有效。在 claude.ai 网页聊天里输入 “ultrathink” 什么都没发生。这是 Claude Code 特定的功能，不是通用的 Claude 技巧。

使用前的两个诚实提醒：

Extended thinking 比标准响应消耗更多 token。个人项目差异可以忽略，团队每天几十个任务就积少成多了。把它留给值得的问题：架构决策、已经花了你几个小时的 bug、触及关键路径的重构。
简单任务上没用。用 ultrathink 重命名一个变量只是更慢更贵。匹配思考级别和问题复杂度。

不要把 ultrathink 加到每个 prompt 里。留给那些已经花了你时间的问题。

Hack 4: /compact 加焦点指令，不做盲压缩

这是列表里最小的改动，也是改善日常工作最明显的。

Claude Code 有上下文窗口限制——一次能保持在工作记忆里的内容有限。长会话会填满它，性能下降。/compact 压缩对话历史来腾空间。

大多数人跑 /compact 然后接受 Claude 产生的任何总结。会话继续，但 Claude 已经丢失了那些重要的细节。

更好的版本：

/compact focus on the auth refactor and the schema changes we made to users table

这一句话告诉 Claude 压缩时保留什么。不是笼统的整场会话总结，而是保留那些重要的决策，丢掉那些来回对话的噪音。

值得作为焦点包含的内容：

改了哪些文件以及为什么
出现了什么错误以及如何解决的
做了什么决策（选了 Postgres 而不是 Redis、决定暂时不加索引）
还有什么在进行中

compact 总结会成为会话剩下的「记忆」。给它好的输入，它会产生 Claude 真正能用的东西。

Hack 5: 子 Agent 保持主 Session 干净

这是架构级别的技巧。设置时间最长，回报也最大。

当 Claude Code 在你的主 session 里做探索性工作时——读几十个文件理解代码库、跑搜索追踪 bug、扫描测试输出——所有这些都会填满你的上下文窗口。等 Claude 完成探索时，你的上下文已经半满，全是研究时才需要的文件内容。

子 Agent 通过隔离工作解决了这个问题。

子 Agent 是一个独立的 Claude 实例，有自己的上下文窗口、系统提示和工具权限。在 .claude/agents/ 里定义：

# .claude/agents/code-reviewer.md
---
name: code-reviewer
description: Reviews code quality and security. Use proactively after code changes.
model: claude-sonnet-4-6   # 便宜的模型做审查，Opus 留给主工作
tools:
  - Read
  - Glob
  - Grep
---
你是一个资深代码审查者。关注安全漏洞、实现可能漏掉的边界情况、
以及任何违反团队约定的内容。返回带行号的具体问题列表。

这个文件存在后，Claude Code 自动把审查任务路由给子 Agent。审查在隔离的上下文里完成，返回总结，你的主 session 保持专注在构建上。

比并行更重要的一点：子 Agent 防止失败尝试污染上下文。

当 Claude 试了某事但没有成功时，失败的尝试会在上下文里积累。它们会把未来的回答往错误的方向拉。把探索性工作推给子 Agent，意味着你的主 session 永远不会看到那些死胡同。

几个实际好用的子 Agent 用途：

只读代码库探索（映射仓库而不修改主上下文）
验证（独立的 Agent 检查实现是否真的解决了问题）
代码审查（路由到便宜的模型，Opus 留在主工作上）
日志分析（筛选长输出，返回相关部分）

五步实操计划

今天就能做的五步：

第一步：打开你的 CLAUDE.md，删掉所有 Claude 没有也能做对的指令。大多数 CLAUDE.md 里至少 30% 是无用指令。

第二步：选一条必须执行的规则（如「改文件后跑 lint」），移到 Hook 里。测试确认 100% 触发。

第三步：这周遇到硬问题时，在 prompt 末尾加上 “ultrathink” 再试一次。

第四步：下次 /compact 时加 focus。对比有焦点和无焦点的压缩结果。

第五步：建一个 code-review 子 Agent，指向便宜的模型。Claude 会自动在改代码后触发审查。

从第一步开始。大多数 CLAUDE.md 文件至少 30% 的指令是 Claude 不需要的。把那些删掉，剩下的指令会更可靠。

Agent Harness实战：用Markdown文件搭AI工作框架

Wed, 01 Jul 2026 00:00:00 +0800

Agent = 模型 + Harness
Harness的五个子系统
仓库即规范
验证块：十分钟最高ROI的投入
如何给Agent画一张好地图
补充与反思
总结

Agent = 模型 + Harness

大多数人把AI Agent用不好归结为「模型不够聪明」。换个更强的模型试试就好了？实战中真正拖后腿的往往不是模型的理解能力，而是模型工作的环境。

作者的核心论点很简单：

Agent = 模型 + Harness（操作框架）

到了一定复杂度之后，Harness才是真正的瓶颈。好消息是，构建一个好的Harness不需要复杂的框架或代码层面的编排——只需要在仓库里放好几个Markdown文件。

Harness的五个子系统

经过多个项目实践后，作者把Harness拆解为五个子系统。缺任何一个，Agent用起来都会别扭——就像一辆没有仪表盘或刹车的车。

1. 指令（Instruction）

一个入口文件（AGENTS.md 或 CLAUDE.md），包含：

项目概述（一句话+目标受众）
技术栈和版本号
首次启动命令（从头拉代码到能跑起来）
硬规则（「永远不要修改这个文件」「生产环境必须过代码审查」）

2. 工具（Tools）

给Agent足够的权限去做实事。禁用Shell「为了安全」导致Agent连 pip install 都做不了，就像雇了一个工程师然后没收了他的键盘。

原则是最小权限，不是零权限。

3. 环境（Environment）

一个能自我描述的环境：锁定依赖、固定运行时版本、可复现的容器。Agent如果在一个broken的环境里挣扎，它的注意力会浪费在错误的战场上。

4. 状态（State）

记录完成了什么、进行中什么、卡住了什么。让工作跨会话延续。最简单的实现就是PROGRESS.md文件。

5. 反馈（Feedback）

这是ROI最高的子系统——给Agent明确的命令来判断自己的输出是否正确。这个子系统决定了Agent是「猜自己完成了」还是「可以自己检查」。

如果只加一个子系统，加这个。

仓库即规范

If it isn’t in the repository, it does not exist to the agent.

这句是整个文章最核心的一句话。一个AI Agent在一个结构混乱的仓库里，就像一个有才华的新员工没有任何入职培训——精力都浪费在找方向上了。

但如果你给它一张清晰的地图——一个入口路由文件、与代码同位的文档、准确的验证命令——同一个模型可以从20%的成功率跳到接近完美。

真实项目中，大量知识存在于：

Slack 聊天记录
早已过时的 Confluence 页面
零散的代码注释
两三个核心成员的脑子里

每一条对Agent来说都是盲区。每个盲区都迫使它做一次猜测。

测试方法： 打开一个全新的Agent会话，只给它仓库，问五个关于项目的问题。如果它答不出或答错，说明你的仓库作为规范不合格。

验证块：十分钟最高ROI的投入

在AGENTS.md里放一个验证命令块，十分钟的工作能改变一切：

## Verification Commands
- Tests:        pytest tests/ -x
- Type check:   mypy src/ --strict
- Lint:         ruff check src/
- Full check:   make check   # runs all of the above

作者把所有验证路由到 make targets。这样Agent不需要猜项目用npm、yarn、poetry还是pipenv——Harness提供一个统一入口。

如何给Agent画一张好地图

入口文件要短

AGENTS.md控制在200行以内。不是所有信息都塞进去——它只做路由和核心规则。

知识放在代码旁边

数据库Schema写在SQL迁移文件里而不是单独的文档里。API路由写在路由定义文件旁边而不是Wiki里。Agent不需要翻Wiki，它只需要翻代码。

删除冗余指令

每条指令加入前问自己：「如果删了这一行，Claude会犯错吗？」如果不会，删掉。CLAUDE.md底部的指令经常被忽略——保持简短才是真正让重要内容生效的方式。

补充与反思

最让我认同的观点

作者关于反馈子系统的判断是整篇文章最有价值的部分。给Agent一个能自己验证的命令，比给它一万字的指令文件有用得多。因为Agent能自己回答「我做对了没有」，不需要每次都等你检查。

一个被弱化的点

作者假设Agent能自动发现并理解Markdown文件的结构。实际上，对于文件多、层次深的仓库，即使有AGENTS.md做入口，Agent仍然可能在导航过程中丢失上下文。入口文件控制在200行以内、硬规则放在最前面，是目前实践中最有效的缓解措施。

实用建议

如果你正在用Claude Code或类似Agent工具做开发，花一小时改善仓库的AGENTS.md和验证体系，是本周ROI最高的技术投资。

从反馈子系统开始——先让Agent能自己验证结果。不要一上来就想搭完整的五子系统。

总结

Harness的核心思路——用Markdown文件做Agent的工作框架——可以在任何项目中直接复用，不需要重写任何代码。五个子系统中，反馈的ROI最高，也最容易见效。

从今天开始：打开你的AGENTS.md，删掉30%不需要的指令，加一个 make check 的统一验证入口。Agent的工作质量会立刻提升。

NotebookLM不只是摘要工具：20个你可能不知道的高阶用法

Wed, 01 Jul 2026 00:00:00 +0800

大多数人只用了10%
一、批判性思考类
二、深度理解类
三、决策与行动类
四、查漏补缺类
五、后续跟进类
几个让效果翻倍的小技巧

大多数人只用了10%

大多数人用NotebookLM的方式是：上传一个PDF，点一下「总结」按钮，看三个要点，然后关掉。我也这么干了几个月，才意识到自己只用了这个工具大概10%的能力。

NotebookLM不是一个摘要器。它更像一个研究伙伴——你喂给它的所有材料它都读完了，就等着你问更好的问题。问题在于，没人告诉你那些更好的问题长什么样。

下面是我实际用过的20个prompt，附上每个场景的使用说明。

一、批判性思考类

1. 「反向解释」检验法

用错误的方式向我解释这个概念。什么是常见的误解？

这是我偶然发现的一个技巧，后来成了最爱。知道一个想法的”错误版本”，往往比知道正确版本更能让你真正理解它。你读到误解时心里会想”哦，我明白为什么会有人这么想了，但实际上——”，然后你对正确答案的理解就更深了一层。

2. 同行评审

如果你是同行评审，要找这篇论文的漏洞，你会标记什么？

我们习惯只让AI正面解释事物。反过来问问——让AI找出弱点。你会对论证的实际可靠程度有更诚实的判断，不会再对站不住脚的东西点头称是。

3. 「那又怎样」过滤器

对每个主要观点，告诉我它在实践中为什么重要。如果不重要，直接说出来。

不是每个想法分量都一样。普通摘要把它们同等对待。这个prompt强制排序，而「如果不重要就直说」是关键部分——它允许模型告诉你某件事没什么大不了，而模型通常倾向于回避这个判断。

4. 找出支撑性假设

哪个假设如果错了，整个论证就会崩塌？

每个论证都依赖某个它从未真正证明的前提。这个prompt就是去找那个前提的。很多时候，找到这个假设比理解论证本身更有用，因为它直接告诉你如果想测试整套体系是否站得住，应该从哪里下手。

二、深度理解类

5. 为特定受众翻译

把核心发现改写给[12岁小孩/忙碌的高管/非英语母语者]看。

同一个材料用三种不同受众去试，你会发现解释的方式每次都变。如果你需要向别人解释某个东西，这个技巧能帮你先找到最能打动的版本。

6. 生成追问清单

关于这个主题，我应该问哪些我可能没想到的问题？

有时候最有用的输出不是答案，而是你没想到的更好的问题。

7. 角色转换对话

基于这个材料，把它写成两个持不同观点的人之间的对话。

对话比平铺直叙更容易理解复杂观点。而且用这种方式回顾你已经读过的东西也很有趣。

8. 术语词典

提取所有技术术语，用通俗语言定义，按出现频率排序。

频率排序比你以为的重要得多。出现最多的术语最值得先搞懂，其他的可以遇到了再查。

三、决策与行动类

9. 转化为决策

基于这个材料，我实际上应该做什么？给我选项，不只是信息。

很多材料描述了情况但从不告诉你该怎么办。这个prompt填补了这个空白。有时候答案是「什么都不做」，这本身也很有价值。

10. 辩论准备单

我要和一个持反对意见的人讨论这个。给我他们可能的反对论点以及我该如何回应。

我在知道有人要质疑的会议前用这个。老实说，在家庭聚餐前也很有用。

11. 一页纸挑战

如果你只能用一张幻灯片总结这个，上面应该放什么？

极限优先级。能通过这个筛选的才是真正核心的东西。

12. 写给未来自己的笔记

写一个6个月后给我自己的笔记，提醒我这是关于什么的、为什么重要。

第一次用觉得有点花哨，但它迫使你做到极限压缩。六个月后，这条笔记是重新回到材料的最快路径。

四、查漏补缺类

13. 找出过时内容

这个材料里哪些说法最可能已经过时了？为什么？

NotebookLM不能实时查证，但它很擅长标记哪些类型的声明最容易过期。在引用旧资料前值得跑一遍。

14. 矛盾检测

这个材料里有没有自相矛盾的地方？在哪里？

长文档，尤其是委员会写的那种，自相矛盾的频率比你想象的高。这个prompt能快速找到它们。

15. 映射所有角色

列出所有提到的人、组织或实体，用一句话说明每个的角色。

密集的报告里经常有十几个参与者，看到第三页就记不清谁是谁了。这个prompt一次性解决。

16. 找出缺失的部分

你觉得这个材料应该覆盖但实际没覆盖的内容是什么？

对识别空白很有用，尤其是那些声称有范围但读着读着范围悄悄变窄的研究论文或报告。

17. 找出现成的类比

这个材料里有类比或隐喻吗？如果没有，建议一个合适的。

有时作者已经在第12页埋了一个很好的解释工具。有时没有，你需要自己搭一个。

五、后续跟进类

18. 生成后续阅读清单

基于这个材料，接下来值得研究什么主题或问题？

这就把一份文档从终点变成了起点。老实说，这才是整个操作的核心。

19. 创建对比

这个材料的观点和这个主题的传统看法有什么不同？

这样我就能判断什么东西是真正新的，什么只是换了个包装的老观点。在炒作密集的材料上很省时间。

20. 找出会改变你想法的事

如果存在什么证据，会让这个论证崩塌？

这是我发现自己是否真的相信某事、还是只是没质疑过它的最好方式之一。

几个让效果翻倍的小技巧

多来源一起上传。 NotebookLM真正的强项是跨文档分析，单一份PDF发挥不出它的10%。一个Source和五个Source的差距是质的。

对格式要具体。 「给我一个表格」或「五条要点」能得到你直接能用的东西。模糊的请求得到模糊的答案。

不要满足于第一个回答。 追问它，让它深挖，为别人重写。这个工具是为来回对话设计的，第一个输出很少是最好的。

如果你有比这些更好用的prompt，我很想听听。欢迎在评论区分享。

手把手搭建个人Agentic系统：LLM就是新CPU

Tue, 30 Jun 2026 00:00:00 +0800

为什么你需要自己的Agentic系统
一个大 Prompt 搞不定一切
LLM OS 架构揭秘
实战：用 LLMlight 搭建多Agent系统
什么时候该用 Agentic 系统？
值得关注的细节

为什么你需要自己的Agentic系统

如果你还在把 ChatGPT 当写作工具用，你可能已经错过了最本质的变化。LLM 的真正角色不是「生成器」，而是计算核心。Andrej Karpathy 提出的 LLM Operating System（LLMos） 框架给出了一个非常直观的类比：

传统计算机	LLMos
CPU	大语言模型（LLM）
字节	Token
RAM	上下文窗口
硬盘	检索系统
软件接口	Prompt

这个类比揭示了 Agentic 系统的核心思想：你的 LLM 不是一个写手，而是一个 CPU。 Token 就是新的字节，上下文窗口就是新的内存。当我们摆脱「用 LLM 写文章」的思维，进入「用 LLM 做计算」的范式，视野就完全不一样了。

当然，挑战也随之而来。小模型虽然有隐私、便携和成本优势，但上下文窗口更小、推理能力有限。在本地跑 Agentic 系统面临的问题包括：Agent 之间如何通信？哪些任务应该用确定性逻辑、哪些用概率模型？如何防止幻觉？如何保证评分的一致性？

这些问题的答案，不在于某个精巧的单条 Prompt，而在于精心设计的流水线——分块策略、检索系统、嵌入模型、排序机制、结构化 Prompt、评分工作流、多个专业化 Agent 的协同。这就是本篇文章要讲的内容。

一个大 Prompt 搞不定一切

一个常见的错误是：把整份文档丢进 LLM，期望它一次搞定所有事情。这种「单片式」方法有四个根本性缺陷：

上下文窗口饱和。 即使模型支持 200K 的上下文，当文档内容、系统指令、评分标准、输出格式约束全部塞进去，关键信息会被隐式压缩或忽略，推理结果自然不如人意。

任务纠缠。 一次 Prompt 要求模型同时执行完全不同的认知操作——提取数据、解释上下文、应用规则、保持跨段一致性、生成结构化反馈。没有机制的分离，输出必然浅层或自相矛盾。

结构缺失。 单次 Prompt 输出一个结果，没有中间检查点，没有推理步骤。如果最终答案不对，你无法追踪断链的位置。这使得系统几乎不可调试、不可验证。

Prompt 不稳定。 哪怕措辞的微小变化，也可能显著改变评分和反馈质量。

复杂任务的本质是迭代式的——需要阅读、交叉引用、验证、修正判断。把所有这些步骤压缩成一次变换，就移除了人脑判断时天然依赖的结构。解决方案是把大系统分解成更简单的部件：多个小型本地 LLM 各自承担专门任务，协同完成复杂目标。

LLM OS 架构揭秘

如果我们把 LLM 视为新计算范式的 CPU，那么围绕它需要构建完整的外设系统：

上下文窗口 = RAM。 这是临时工作内存，容量有限，读写速度快。当文档超过窗口大小时，就需要外部的存储和检索机制来补充。

检索系统 = 硬盘。 RAG（检索增强生成）就是你的外部存储。通过嵌入模型将文档向量化，形成可搜索的知识库。查询时找到最相关的片段，再注入上下文窗口。

Agent = 专用处理器。 每个 Agent 是一个小型 LLM，配以专门的指令和任务定义。一个 Agent 负责检索，一个负责质量评估，一个负责结构化输出，一个负责最终总结。它们通过结构化的通信协议协同工作。

Prompt = 软件接口。 就像操作系统为应用程序提供 API 一样，LLMos 中的 Prompt 是组件之间的标准化通信协议。结构良好的 Prompt 就像定义良好的 API 契约。

实战：用 LLMlight 搭建多Agent系统

现在进入动手环节。我们将使用 Python 库 LLMlight 构建一个轻量级的多 Agent 系统，全部在本地运行，保护你的数据隐私。

安装与环境准备

pip install llmlight
# 或者如果使用 uv
uv pip install llmlight

LLMlight 的核心理念是「用结构化 Prompt 把小型本地模型组织成团队」。它内置了对 Ollama、llama.cpp 等本地推理引擎的支持。

核心架构

一个典型的 LLMlight 系统包含以下组件：

主控制器（Orchestrator）
  ├── 检索 Agent：从文档库中找到相关信息
  ├── 推理 Agent：对检索结果进行分析和推理
  ├── 评分 Agent：评估输出质量和一致性
  └── 输出 Agent：格式化最终结果

基本用法示例

from llmlight import AgenticSystem, Agent

# 创建一个检索 Agent
retriever = Agent(
    name="retriever",
    model="qwen2.5:7b",  # 可使用任何 Ollama 支持模型
    system_prompt="你是一个文档检索专家。从给定的知识库中找到与用户问题最相关的信息。",
    temperature=0.1
)

# 创建一个推理 Agent
reasoner = Agent(
    name="reasoner",
    model="qwen2.5:7b",
    system_prompt="你是一个分析推理专家。基于检索到的信息，进行逻辑分析和推理。",
    temperature=0.3
)

# 组建系统
system = AgenticSystem(
    agents=[retriever, reasoner],
    orchestrator_model="qwen2.5:14b"  # 控制器可用稍大的模型
)

# 执行任务
result = system.run("分析这份技术文档中的安全风险")

RAG 集成

要让系统能处理私有文档，需要集成检索增强生成：

from llmlight import VectorStore, Chunker

# 文档分块
chunker = Chunker(chunk_size=512, overlap=64)
chunks = chunker.chunk(document_text)

# 构建向量存储
store = VectorStore(embedding_model="bge-small-zh-v1.5")
store.add_documents(chunks)

# 在 Agent 中使用
retriever.with_retrieval(store, top_k=5)

评分与验证机制

一个常被忽略但至关重要的组件是评分 Agent。它的任务是在最终输出之前，对推理结果进行质量检查：

scorer = Agent(
    name="scorer",
    model="qwen2.5:7b",
    system_prompt="""评估以下分析的质量，从三个维度打分（1-10）：
1. 事实准确性：与检索到的信息是否一致
2. 逻辑连贯性：推理过程是否清晰
3. 完整性：是否覆盖了关键方面
返回 JSON 格式评分结果。""",
    temperature=0.1,
    output_format="json"
)

评分 Agent 的存在让系统从「黑箱输出」变成了「可审计的流程」。如果某个输出分数低于阈值，系统可以自动触发重试或回退到更保守的策略。

上下文管理策略

本地模型的一个主要限制是上下文窗口较小。以下是一些实用的管理策略：

分层检索：先检索文档摘要，再根据相关性深入检索详细内容
滑动窗口：对长文档使用滑动窗口 + 交叉引用的方式分段处理
摘要压缩：对中间结果进行摘要化处理，减少 token 消耗
优先级队列：根据相关性评分动态管理上下文中的段落优先级

# 分层检索示例
summary_agent = Agent(name="summarizer", ...)
detail_agent = Agent(name="detail_analyzer", ...)

# 第一层：获取文档概要
summary = summary_agent.run("总结本文档的核心内容")

# 第二层：基于概要定位关键段落
key_sections = retriever.search(summary, top_k=3)

# 第三层：深入分析选定段落
analysis = detail_agent.run(key_sections)

什么时候该用 Agentic 系统？

Agentic 系统不是万能的。在以下场景中收益最大：

✅ 适合用的场景：

需要处理大量文档的分析和结构化输出
任务需要多步推理和验证
对输出一致性和可审计性有要求
需要结合私有知识库的问答系统

❌ 不适合的场景：

简单的单次问答（一个 Prompt 就够）
对延迟敏感的场景（多 Agent 通信有额外开销）
需要 100% 确定性的场景（概率模型永远有不确定性）

值得关注的细节

最让我在意的一个判断是：Agentic 系统的价值不在模型参数量的增加，而在工程架构的精细度。 很多人以为多 Agent 就是多调几个 API，真正困难的地方在于：分块策略如何设计？嵌入模型怎么选？Agent 之间如何通信？失败重试怎么做？评分阈值设多少？

另一个容易被忽略的问题是：小模型组队 > 大模型单挑。 实验表明，3-4 个 7B 参数的模型组成的 Agent 团队，在很多任务上的表现可以超过单个 70B 模型，而且成本更低、速度更快、可解释性更好。这是因为每个小模型专注于特定任务，避免了认知资源的稀释。

不过我也注意到一个需要谨慎的地方：Agent 之间的通信增加了系统的延迟和不确定性。 每一次 Agent 调用都可能引入新的波动，需要设计完善的验证和回退机制。

目前我的判断是：Agentic 系统是当前 AI 应用最有价值的范式之一。它把 LLM 从「聊天工具」提升到了「计算平台」的层面。但工程化的成熟度还远不如传统软件——可观察性、调试工具、标准化协议都还在早期。如果你愿意投入精力打磨流水线，这可能是 2026 年回报率最高的 AI 技能投入。

Claude Code Subagent 是什么？从零搞懂这个核心概念

Tue, 30 Jun 2026 00:00:00 +0800

一个让我困惑了很久的问题
Claude Code 里的「Agent」其实有 4 种含义
Subagent 为什么存在？
构建第一个 Subagent
- 最小示例
- 字段说明
Subagent vs Skill：最容易被混淆的边界
最佳实践
Agent Teams：更上一层
什么时候不该用 Subagent
值得关注的细节

一个让我困惑了很久的问题

第一次看到 Claude Code 启动 subagent 时，我的第一反应是：这不就是跑了个更精准的 Prompt 吗？

看着它在十几个文件里穿梭，最后返回一份干净的摘要，很酷，但我其实没搞懂到底发生了什么。后来我发现很多人都有类似的困惑——他们把 subagent 理解成「带额外步骤的 Skill」，甚至是「写得更聪明的 Prompt」。

这个认知模型是错的。

Agent 确实和 Skill 一样用 Prompt 驱动，但关键区别在于：Agent 不在你的主会话里运行。 它有自己的上下文窗口、自己的系统 Prompt、自己的工具权限、自己的运行环境。它独立工作，然后返回结果。

这篇文章从零开始讲清楚 Claude Code subagent——它到底是什么、怎么构建、什么时候该用、什么时候不该用。

Claude Code 里的「Agent」其实有 4 种含义

在深入之前，必须先理清概念。Claude Code 语境下，「Agent」这个词至少指 4 种不同的东西：

1. Claude Code 本身就是一个 Agentic 环境。 Anthropic 把 Claude Code 定义为 agentic coding assistant——有工具、有执行循环、能跨多步自主规划和操作。你在用它的时候，就已经身处一个 Agent 环境了。

2. Subagent 是可自定义的 Agent 原语。 当从业者说「我在 Claude Code 里构建了一个 Agent」时，几乎都是在指 subagent。它有专属的上下文窗口、自定义系统 Prompt、独立工具权限。

3. Agent Teams 是独立的多会话特性。 Subagent 在单个会话内工作；Agent teams 跨多个会话协调。它们是独立的 Claude Code 实例，通过共享任务列表和消息通信。目前处于实验阶段，默认关闭。

4. Claude Agent SDK 是第四层。 是 Claude Code 底层工具循环的 Python/TypeScript 可编程接口，用于构建自定义 Agent 应用。

本文聚焦的是 subagent（第 2 点）。

Subagent 为什么存在？

核心原因只有一个：LLM 的上下文窗口是有限的。

每一个工具调用、每一次文件读取、每一次分析和中间结果——全都会落在上下文窗口里。随着会话增长，窗口里塞满了中间产物。这些产物在生成结果时需要，但生成完成后就成了噪声。这种噪声会降低模型性能——这就是所谓的 Context Rot（上下文腐烂）。

Subagent 就是为了解决这个问题而存在的。

一个 subagent 在自己的上下文窗口里运行，消耗自己的 Token 预算。主会话只收到一份摘要。官方文档说得很直白：

Subagent 可能读取几十个文件或运行大量搜索，但你的主会话只收到一份摘要。因为 subagent 的工作不消耗主会话上下文。

举个例子：你要排查测试套件为什么挂了。在主会话里做这个排查意味着要读 20 个文件、grep 错误模式、检查测试配置、扫描最近的提交——所有这些都会塞进你的上下文窗口。等排查完了，你已经消耗了成千上万 Token，而且大部分中间信息对你接下来的工作毫无帮助。

Subagent 改变了这个问题的结构。它在自己的上下文里跑完整个排查流程，返回一条干净的结果：「测试失败原因是 CI 配置中缺少环境变量。受影响的 3 个测试和修复方案如下。」主线程从未被搜索上下文撑爆。

上下文隔离是首要原因，还有三个次级原因：

专业化：Subagent 有自己的系统 Prompt。一个专注于代码评审的 Agent，配以团队标准指令，比一个什么都知道的通用助手更可靠。
约束执行：你可以精确指定 subagent 能用的工具。一个只读的研究 Agent 不能写文件、不能跑命令——风险轮廓和主助手完全不同。
成本控制：Subagent 可以使用不同的模型。把轻量任务路由到 Haiku 而主会话用 Sonnet，是很多人在被账单吓到之后才会发现的实用技巧。

构建第一个 Subagent

一个 subagent 就是一个带 YAML frontmatter 的 Markdown 文件。

它存放在两个位置之一：

.claude/agents/（项目目录）—— 团队可共享的 Agent
~/.claude/agents/（用户目录）—— 个人跨项目 Agent

最小示例

---
name: code-reviewer
description: Re一次代码变更的质量、安全和最佳实践。在重大代码变更后主动使用。
tools: Read, Glob, Grep
model: sonnet
---

You are a code reviewer. When invoked, read the changed files and provide
specific, actionable feedback on code quality, security, and best practices.
Focus on what matters. Don't restate what the code does — say what's wrong
or good about it. Flag security issues first, then logic problems, then style.

字段说明

name：唯一标识符，小写，只能连字符。用于日志和内部引用。
description：最重要的字段。 Claude 依据它来决定是否把任务委派给这个 Agent。用行为式语言描述——Agent 做什么、什么时候用。Use proactively 是一个关键信号——告诉 Claude 无需用户明确请求即可主动激活。不加这个短语的话，Agent 只在被直接调用时响应。
tools：限制该 Agent 能访问的工具。上面的评审者只能读取文件和搜索——不能编辑、不能跑命令、不能发网络请求。这是有意的设计。只读评审者不会意外修改它正在审查的代码。
model：将 Agent 路由到特定模型。可选值：sonnet、opus、haiku，或完整模型 ID。省略则默认 inherit（继承主会话模型）。

完整的可选前置字段还包括：permissionMode、maxTurns、skills、mcpServers、effort、memory、hooks、disallowedTools、color 等。

Subagent vs Skill：最容易被混淆的边界

如果你觉得上面的 subagent 看起来很像一个 Skill——你既对也不对。

相同点： 都是用 YAML frontmatter + Markdown body 定义的文件，都可以指定 tools 和模型。

核心区别：

维度	Skill	Subagent
运行位置	主会话上下文	独立上下文窗口
上下文消耗	占用主会话 Token	不占用主会话 Token
工具权限	继承主会话	独立声明和限制
返回结果	直接注入对话流	返回摘要到主会话
系统 Prompt	与主 Prompt 融合	完全隔离的独立 Prompt
适用场景	格式塔式的简单任务	需要大量文件交互的复杂任务

一个实用的判断标准：如果任务需要读 5 个以上文件、做多步搜索、或者需要完全隔离的上下文——用 subagent。如果只是格式转换、模板生成、单文件分析——用 Skill。

最佳实践

Description 怎么写？

这是最容易被低估的字段。好的 description 应该是行为式的，像这样：

Reviews PR diffs before merge. Calling this means the caller 
wants a thorough review with security-first analysis.
Use proactively after any significant code change.

而不是描述式的：

A code review tool.

Claude 会读取 description 来决定是否把任务委派给这个 Agent。写得越清晰、越行为化，它在正确时刻被调用的概率就越高。

工具限制为什么重要

只授予 Agent 实际需要的工具，有两个原因：

安全性：一个只读 Agent 不能意外破坏代码
可预测性：工具越少，行为越可控

代码评审 Agent 只需要 Read, Glob, Grep；数据库迁移 Agent 可能需要 Write, Bash, Read；研究 Agent 可能需要 Read, Glob, Grep, Search。

Context 隔离

Subagent 的最佳使用模式是：把大量文件读取和搜索操作塞进 subagent，主会话只处理结果。

看一个实际的例子。用 subagent 做端到端测试分析：

The subagent reads 15-20 test files, checks CI logs, 
grep for error patterns. Returns a 3-paragraph summary.
Main session: uses the summary to decide next steps.

主会话从未接触那 20 个文件的上下文负担。这是 subagent 最核心的价值。

Agent Teams：更上一层

Subagent 在单会话内工作。当任务需要跨多个文件、跨多个步骤、甚至跨多个代码库时，Agent Teams 可能更合适。

Agent Teams 是独立的 Claude Code 实例，它们通过共享任务列表和消息相互通信。当前处于实验阶段（通过 ANTHROPIC_AGENT_TEAMS=1 环境变量启用），但已经可以看到它的价值所在。

什么时候该用 Agent Teams？你的任务需要多个专业角色并行工作时——比如一个 Agent 在重构后端，另一个在更新前端类型，第三个在写文档。它们各自运行在自己的会话中，共享一个任务蓝图，相互通知进度。

什么时候不该用 Subagent

Subagent 不是万能的。以下场景请谨慎：

任务太简单。 如果只需要单文件分析或格式转换，一个 Skill 就够了。引入 subagent 的上下文切换开销不划算。

需要实时交互。 Subagent 独立运行，你无法在它执行过程中插手。如果任务需要反复确认方向，留在主会话更合适。

对延迟敏感。 Subagent 启动有固定开销（加载上下文、初始化工具）。毫秒级响应的场景不适合。

频率极高的重复任务。 如果每 30 秒就要跑一次的监控检查，subagent 的上下文创建成本会累积。

值得关注的细节

最让我认同的一个判断是：Subagent 不是「更聪明的 Skill」，而是一种架构模式——上下文隔离。 理解了这个本质区别，很多决策就变得清晰了。

不过我也注意到一个被弱化的问题：Subagent 的调试比主会话更困难。 它在自己的黑箱里运行，你无法看到它的中间推理过程。如果返回的结果质量不符合预期，排查原因比在主会话中要费劲得多。

另一个容易被忽略的点：Description 字段的战术价值。 很多人把它当作可有可无的副注，实际上它是决定你 Agent 被 Claude 主动发现和调用的关键入口。写得好，你的 Agent 会在恰当时刻被自动激活；写得差，再强大的逻辑也无人问津。

目前我的建议是：从代码评审 Agent 开始入手体验——限制工具为只读，提供明确的评审标准，观察它如何独立分析代码变更。这是理解 subagent 最佳实践的最短路径。

Mistral Vibe：一个活在终端里的 AI 编码助手

Tue, 23 Jun 2026 00:00:00 +0800

从补全代码到编排整个开发工作流
为什么值得关注
思维模型：终端的原生智能层
安装与配置
核心特性
MCP 服务器：Vibe 的超级能力
并行 Agent
谁应该用 Mistral Vibe
- 适合
- 不适合
我的感受

从补全代码到编排整个开发工作流

你在一个遗留系统现代化项目上干了三周。COBOL 代码库 5 万行，文档基本没有，团队在问”AI 真的能帮上忙吗？”

大多数 LLM 能做到的事：自动补全一个函数，或者建议一个重构。但你真正需要的是：能遍历 50 个文件、理解它们的依赖关系、从网上获取现代架构模式、生成等价的 Python 代码、写测试、并编排整个迁移过程——而你保持心流状态不被打断。

Mistral Vibe 就是这样——一个终端原生的 AI 编码助手，不只是写代码片段。它能操作你的整个开发环境，通过 MCP 服务器连接外部工具，并在并行 Agent 之间分配任务。

为什么值得关注

AI 编码工具改变了我们写函数的方式，改变了我们编辑文件的方式。Mistral Vibe 改变的是我们编排整个开发工作流的方式。

区别在于范围和自主性。一个 IDE 插件看到的是你当前文件，可能再加几个相邻文件。Vibe 在项目级别工作——它分析你的整个代码库、查询数据库获取 schema 上下文、抓取在线文档辅助决策、运行测试套件、并生成有意义的 git commit 信息。

而且关键的是：Vibe 在你需要的任何地方运行。本地笔记本、气隙数据中心、欧洲主权云。你的专有代码从不接触外部基础设施。

思维模型：终端的原生智能层

把终端想象成指挥中心。有 git、pytest、docker、kubectl、psql——每个都有独特的接口和怪癖。你是指挥，手动编排着几十个工具。Vibe 成为你的编排层。你描述目标，它协调执行。

你："把所有 Flask 路由重构为 FastAPI 异步处理器，跑测试，分析失败，建议修复"
Vibe：[读取 47 个文件] [重写 23 个函数] [执行 pytest] [分析 14 个失败] [用 file:line 引用建议修复]

没有上下文切换。没有管理工具参数的心智负担。只有持续的辅助心流。

安装与配置

第一步：安装 Vibe

pip install mistral-vibe
vibe --version

第二步：验证 MCP 运行时

MCP 服务器需要 Python 或 Node.js 运行时：

# Python 服务器
uvx --version  # 如果缺失：pip install uv

# Node.js 服务器
npx --version  # 如果缺失：从 nodejs.org 安装

第三步：创建配置

mkdir -p ~/.vibe
touch ~/.vibe/config.toml

打开 ~/.vibe/config.toml：

[models]
default = "devstral-2"

[agent]
enable_parallel = false  # 先串行，后续再开
max_concurrent_agents = 4

第四步：启动

vibe
# ✓ Mistral Vibe ready

试试这些命令：

/status   # 查看 token 使用情况
/help     # 显示所有命令
/model    # 当前模型
/exit     # 退出（或 Ctrl+D）

核心特性

@ 自动补全：代码库导航器

@ 符号是你的代码库导航器：

# 克隆一个项目
git clone https://github.com/pallets/flask
cd flask/examples/tutorial
vibe

# 在 Vibe 内部
> 这个项目里有什么？@ [按 TAB 查看所有文件]
> 分析 @flaskr/auth.py 并解释认证流程
> 对比 @flaskr/db.py 与现代 SQLAlchemy 异步模式

为什么用：当你导航不熟悉的代码库或需要引用特定文件而不输入完整路径时——省去了运行 ls 或 find 的上下文切换。

! 前缀：终端命令执行

在 Vibe 内部直接执行 shell 命令：

> !pytest -v  # 测试运行，输出显示
> 测试失败了。分析输出并告诉我哪里出问题了。
> !git status
> 审查我的未提交变更并建议合适的 commit 信息。

为什么用：当需要运行命令并立即让 Vibe 解释结果时——消除了终端和 AI 助手之间的复制粘贴。

代码库分析

> 分析整个项目结构并创建 README.md，包括：
> - 架构概览
> - 设置说明
> - API 端点
> - 测试方法

Vibe 读取所有文件，理解关系，生成文档。

为什么用：当接手遗留项目或生成不存在的文档时——Vibe 读取整个结构并从代码模式推断架构。

代码生成

> 创建一个新的 FastAPI 用户注册端点，包含：
> - 使用 pydantic 进行邮箱验证
> - 使用 bcrypt 进行密码哈希
> - 使用 SQLAlchemy 异步进行数据库插入
> - 正确的错误处理和日志记录
> - 成功后返回 JWT token

为什么用：当实现样板密集型功能或遵循已建立的模式时——Vibe 生成生产就绪的代码，包含错误处理、验证和日志记录。

对话压缩

长时间对话消耗 token。Vibe 支持对话压缩——压缩选项可以保留你的工作上下文，同时削减 70-80% 的 API 账单。

> /compact
# 压缩前：24,587 tokens → 压缩后：4,892 tokens（节省 80%）
# 保留历史记录中定义的所有变量和函数

为什么用：在多小时的会话中工作时，token 成本会累积——压缩可保留工作上下文，同时大幅降低账单。

MCP 服务器：Vibe 的超级能力

MCP（Model Context Protocol）服务器才是 Vibe 真正的杀手锏。它们将 AI 连接到实时外部系统，从根本上扩展了能力边界。

数据库集成

# 安装 PostgreSQL MCP 服务器
pip install mcp-postgres

# 在 ~/.vibe/config.toml 中配置

[[mcp_servers]]
name = "postgres"
command = "python"
args = ["-m", "mcp_postgres", "postgresql://user:pass@localhost:5432/mydb"]

配置后，你可以这样做：

> 查看数据库 schema，找出所有没有索引的表，并生成迁移文件。

Vibe 连接数据库，检查 schema，分析查询模式，生成添加索引的建议——全部在终端内完成。

浏览器集成（Playwright）

# 安装
npx @playwright/mcp@latest

[[mcp_servers]]
name = "playwright"
command = "npx"
args = ["@playwright/mcp@latest"]

> 打开我们的 staging 环境，截图 404 页面，然后记录一个 Jira ticket。

文件系统 MCP

[[mcp_servers]]
name = "filesystem"
command = "npx"
args = ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/projects"]

> 在 docs/ 中查找所有提到旧 API 端点的文件，并生成迁移清单。

并行 Agent

Vibe 支持并行 Agent 执行，显著加速复杂任务：

[agent]
enable_parallel = true
max_concurrent_agents = 4

启动后，Vibe 自动识别可以并行化的子任务：

> 更新三个微服务的依赖版本，并运行每个服务的测试套件

Vibe 会生成三个独立的 Agent 并行工作：

Agent 1：更新 auth-service 依赖 + 运行测试
Agent 2：更新 billing-service 依赖 + 运行测试
Agent 3：更新 notification-service 依赖 + 运行测试

监控进度：Vibe 显示每个 Agent 的实时状态，所有 Agent 完成后自动汇总结果。

谁应该用 Mistral Vibe

适合

全栈工程师：需要跨前端、后端、数据库和基础设施工作的开发者。Vibe 的 MCP 集成意味着你需要什么，它就能连接什么，不限于单个文件或语言。
DevOps/SRE 工程师：在基础设施配置和 kubernetes 清单中工作的工程师。Vibe 操作你的终端——kubectl、docker、terraform、ansible 都在原生环境中。
遗留系统现代化团队：迁移 COBOL、Fortran 或 Java 单体应用的团队。Vibe 不需要配置复杂的项目级索引——它读取你的 repo，理解架构，然后开始工作。

不适合

期望自动补全 IDE 体验的开发者：如果你希望在输入时获得实时代码建议，Vibe 不是 Copilot 的替代品。它不取代你的 IDE——它增强你的终端会话。
单文件编辑为主的开发者：如果大部分工作只涉及孤立的单文件更改，IDE 插件已经够用了。Vibe 的价值始于多文件项目理解和编排。

我的感受

Mistral Vibe 不是一个提示工程工具，不是一个对话界面，也不是一个自动补全引擎。它是一个完整的终端原生开发环境——将你的 CLI 从”执行命令”升级为”编排工作流”。

最让我惊讶的不是它能读代码库或多文件重构——这些其他工具也能做。让我印象深刻的是 MCP 服务器架构带来的扩展性：数据库集成、浏览器自动化、文件系统搜索、Jira/GitHub 集成——这些东西传统上需要写定制脚本和适配器才能做到，Vibe 通过 MCP 协议标准化了。

如果你已经在终端里工作，Vibe 是你终端能力的自然进化：从手动编排工具，到用语言编排工具，再到让 AI 为你编排工具。这不是一个”辅助工具”，这是一个新的工作范式。