Agent笔记 - 技术栈

Agent 架构入门：从单轮对话到自主代理

在过去的一年里，Anthropic 与数十个团队合作构建 LLM 智能体。他们发现，最成功的实现往往不是使用复杂的框架，而是使用简单、可组合的模式。

这篇文章是 Anthropic 官方发布的第一篇 Agent 系统化指南，也是整个系列的起点。它回答了一个最基本的问题：Agent 到底是什么，以及我们应该如何构建它？

一、核心概念：工作流 vs 智能体

Anthropic 将"智能体系统"分为两类架构：

类型	定义	适用场景
工作流（Workflow）	通过预定义的代码路径编排 LLM 和工具	任务明确、需要一致性和可预测性
智能体（Agent）	LLM 动态指导自身的流程和工具使用	需要灵活性和模型驱动决策

关键洞察： 不要一上来就构建复杂的智能体。大多数应用只需要通过检索和上下文示例来优化单个 LLM 调用就足够了。智能体系统通常以延迟和成本为代价来换取更好的任务性能。

二、从简到繁：五种工作流模式

1. 提示链（Prompt Chaining）

将任务分解为一系列步骤，每个 LLM 调用处理上一步的输出。

适用场景： 任务可以分解为固定子任务，以延迟换取准确性。

典型案例： 生成营销文案 → 检查合规标准 → 翻译成多语言。

2. 路由（Routing）

对输入进行分类并引导至专门的后续任务。

适用场景： 复杂任务中有明显不同类别的输入。

典型案例： 客服查询分类------一般问题走 Haiku，复杂问题走 Sonnet。

3. 并行化（Parallelization）

LLM 同时处理任务并聚合结果，包括"分段"和"投票"两种模式。

适用场景： 需要速度或多重视角以提高置信度。

典型案例： 并行进行内容审核与响应；多个模型并行审查代码漏洞。

4. 编排器-工作流（Orchestrator-Workers）

中央 LLM 动态分解任务、委派给工作流 LLM 并综合结果。

适用场景： 复杂任务且无法预测所需子任务。

典型案例： 涉及多文件更改的编码任务。

5. 评估器-优化器（Evaluator-Optimizer）

一个 LLM 生成响应，另一个在循环中提供评估和反馈。

适用场景： 有明确的评估标准，迭代改进能带来可衡量价值。

典型案例： 文学翻译；需要多轮搜索的复杂搜索任务。

三、真正的智能体模式

当上面的工作流模式都无法满足需求时，才需要使用真正的智能体模式：

核心特征： LLM 根据环境反馈循环使用工具。从人类指令开始，独立计划和操作，并在检查点或遇到阻碍时暂停寻求反馈。

适用场景： 开放性问题，步骤数量不可预测，且无法硬编码固定路径。

典型案例： 解决 SWE-bench 任务的编码智能体；使用计算机完成任务的 Computer Use。

四、工具工程：被低估的关键

Anthropic 提出了一个重要概念------ACI（Agent-Computer Interface），类比 HCI（人机交互），强调智能体与工具之间的接口设计同样重要。

工具设计的核心原则：

定义清晰：工具描述应准确无误，包含使用示例和边界情况
减少格式开销：避免让模型在 JSON 中处理大量转义字符
使用绝对路径：而非相对路径，以减少定位错误
测试驱动：像测试代码一样测试你的工具描述

五、两大高价值应用

客户支持

结合对话与行动的典型场景。Agent 需要遵循策略、查询数据库、执行退款等操作，同时保持对话的自然流畅。

编码智能体

输出可验证（代码能不能跑），问题空间结构化。这使得编码成为 Agent 最早取得突破的领域之一。

六、总结：三条核心原则

保持简洁：在设计中维持简单性，不要为了"智能"而增加不必要的复杂性
优先透明：明确显示智能体的规划步骤，让用户和开发者都能理解决策过程
精心设计接口：通过彻底的工具文档和测试来优化 ACI

读后感

这篇文章最打动我的一句话是：

"最成功的实现往往不是使用复杂的框架，而是使用简单、可组合的模式。"

在 Agent 领域，少即是多。与其急着引入复杂的多 Agent 编排框架，不如先把单个工具调用做到极致。

用 Agent SDK 构建你的第一个 Agent

导语

上一篇我们理解了 Agent 的基本架构模式。这一篇，我们动手做。

Claude Agent SDK 是 Anthropic 推出的官方 Agent 开发工具包，它将 Claude Code 的核心能力------理解代码库、编辑文件、运行命令、执行复杂工作流------封装成可编程的 SDK，让开发者能快速构建自主 Agent。

一、Agent SDK 是什么

Claude Agent SDK（原 Claude Code SDK）允许开发者以编程方式构建 AI Agent。它的核心理念是赋予 Claude 与程序员相同的计算机操作能力。

关键特性：

文件系统访问：读取、编辑、创建文件
命令执行：运行 shell 命令
代码理解：深度理解代码库结构和逻辑
工作流编排：串联多步骤任务

二、构建 Agent 的三步循环

每个 Agent 的工作本质上都是一个循环：

第一步：收集上下文

Agent 需要理解当前环境。这包括：

读取相关文件
查看 git 历史
搜索代码库
了解项目结构

第二步：采取行动

基于收集到的上下文，Agent 做出决策并执行：

编辑代码文件
运行测试
执行部署命令
调用外部 API

第三步：验证工作

Agent 需要验证自己的工作是否正确：

运行单元测试
检查编译是否通过
验证功能是否符合预期
使用浏览器自动化进行端到端测试

这三步不断循环，直到任务完成。

三、超越编程：多场景应用

Agent SDK 的能力不限于编程，它可以应用于：

场景	示例
金融分析	自动收集财报数据、生成分析报告
个人助理	管理日程、整理邮件、生成摘要
客户支持	自动处理工单、查询知识库、执行操作
研究分析	搜索文献、提取关键信息、生成综述

四、测试与优化

构建 Agent 后，关键是迭代优化：

定义评估标准：明确什么是"好"的 Agent 行为
收集测试用例：从真实场景中提取代表性任务
运行评估：批量测试 Agent 在各种任务上的表现
分析失败：找出 Agent 失败的模式，针对性优化
优化提示：调整系统提示和工具描述

五、安装与快速上手

复制代码

# 安装
npm install @anthropic-ai/claude-agent-sdk

# 基本使用
import { Agent } from '@anthropic-ai/claude-agent-sdk';

const agent = new Agent({
  model: 'claude-sonnet-4-5',
  tools: [/* 你的工具 */],
});

const result = await agent.run('帮我重构这个函数');

六、最佳实践

从小处着手：先让 Agent 完成一个简单任务，再逐步扩展
提供清晰的上下文：Agent 的表现取决于它能获取到的信息质量
设计好工具：工具是 Agent 的手和脚，工具设计好不好直接决定 Agent 能力上限
加入验证环节：不要让 Agent "盲目"执行，每一步都应有验证
保持人类在环：在关键决策点保留人类审批

读后感

Agent SDK 最大的价值不是它提供了多少 API，而是它传递了一种思维方式：Agent 不是魔法，而是工程。

把"收集上下文 → 采取行动 → 验证结果"这个循环做好，就是一个好 Agent。

Agent 高级工具调用：并行、嵌套与错误处理

导语

随着 Agent 连接的工具越来越多------IDE 助手集成 git、包管理器、测试框架、部署管道；运维协调器连接 Slack、GitHub、Google Drive、Jira 和数十个 MCP 服务器------一个问题浮出水面：如何让模型在数百甚至上千个工具中高效工作？

Anthropic 在 Claude 开发者平台上推出了三项 Beta 功能，从根本上解决了工具调用的扩展性问题。

一、工具搜索工具（Tool Search Tool）

问题

传统做法是将所有工具定义预加载到上下文中。当工具数量达到数百个时，这会消耗大量 token（文中提到多达 134K tokens），而且容易导致错误的工具选择。

解决方案

将工具定义标记为延迟加载（defer_loading: true），Claude 仅在需要时通过搜索动态发现并加载相关工具。

效果

上下文消耗从 ~77K tokens 降低到 8.7K tokens，减少 85%
工具选择准确性从 79.5% 提升至 88.1%（Opus 4.5 在 MCP 评估中）

二、程序化工具调用（Programmatic Tool Calling）

问题

传统工具调用每个步骤都需要一次完整的推理，且中间结果（如处理大量日志或数据）会污染上下文窗口。

解决方案

允许 Claude 编写 Python 代码来编排工具调用。工具在代码执行环境中运行，处理大量数据，仅将最终结果返回给 Claude。

效果

复杂研究任务的 token 使用量平均下降 37%
显著降低延迟

三、工具使用示例（Tool Use Examples）

问题

JSON Schema 只能定义结构，无法表达具体的使用模式------可选参数何时填写、日期格式惯例等。

解决方案

在工具定义中直接提供 input_examples，通过具体示例向 Claude 展示正确的调用方式。

效果

复杂参数处理的准确率从 72% 提升至 90%

四、最佳实践：分层使用

根据你的瓶颈，分层选择功能：

功能	适用场景
Tool Search Tool	工具定义 >10K tokens 或拥有 10+ 工具
Programmatic Tool Calling	处理大型数据集、多步骤工作流
Tool Use Examples	复杂嵌套结构或多个可选参数

五、如何启用

复制代码

client.beta.messages.create(
    betas=["advanced-tool-use-2025-11-20"],
    model="claude-sonnet-4-5-20250929",
    # ... 其他参数
)

读后感

这三个功能解决了 Agent 工程化中最头疼的三个问题：工具发现、数据流和参数准确性。特别是 Tool Search Tool，它让"连接上千个 MCP 服务器"从理论变成了现实。

如何为 Agent 设计好用的工具

原文：Writing effective tools for agents --- with agents | Anthropic Engineering Blog | 2025.9.11

导语

Agent 的效能取决于我们为其提供的工具。

这是 Anthropic 在这篇博客中反复强调的核心观点。MCP 可以为 Agent 提供数百种工具，但如何让这些工具真正发挥效能？

这篇文章分享了 Anthropic 在实践中总结的工具设计方法论------甚至包括如何用 Claude 来优化 Claude 的工具。

一、工具的本质：一种新型软件契约

传统软件中，我们在确定性系统之间建立契约：getWeather("NYC") 每次调用都以完全相同的方式获取天气。

但工具是确定性系统与非确定性 Agent 之间的契约。当用户问"我今天应该带伞吗？"，Agent 可能调用天气工具，也可能根据常识回答，甚至先询问位置。

这意味着我们需要从根本上重新思考方法：为 Agent 设计工具，而不是像为其他开发者写 API。

二、工具开发的三阶段迭代

阶段一：构建原型

快速实现工具，包装在 MCP 服务器或 DXT 中，在 Claude Code 或 Claude Desktop 中测试。亲自使用工具，发现粗糙的边缘。

阶段二：运行评估

生成大量评估任务（基于真实用例），通过 LLM API 批量测试。收集准确率、运行时间、token 消耗等指标。

好的评估任务示例：

"安排下周与 Jane 开会讨论最新的 Acme Corp 项目。附上上次项目规划会议的笔记并预订会议室。"

差的评估任务示例：

"安排下周与 jane@acme.corp 开会。"

区别在于：好的任务需要多次工具调用，考验 Agent 的综合能力。

阶段三：与 Agent 协作

让 Claude Code 分析评估记录并自动优化工具------包括工具描述、参数设计和错误处理。

三、五条工具设计原则

原则 1：为 Agent 选择正确的工具

更多的工具不等于更好的结果。不要简单包装现有 API------要考虑 Agent 的"可供性"。

好的做法： 实现 search_contacts 而非 list_contacts；实现 schedule_event 而非分别实现 list_users、list_events、create_event。

原则 2：命名空间你的工具

按服务（如 asana_search、jira_search）和资源（如 asana_projects_search）对工具进行命名空间划分。

原则 3：返回有意义的上下文

优先返回自然语言名称而非不透明的 UUID
提供 response_format 枚举参数，允许 Agent 选择"简洁"或"详细"模式
简洁模式可以节省约 2/3 的 token

原则 4：针对 token 效率优化

实施分页、过滤、截断
合理的默认参数值（Claude Code 默认将工具响应限制为 25,000 tokens）
错误响应要具体、可操作

原则 5：对工具描述进行提示工程

工具描述被加载到 Agent 的上下文中，直接引导 Agent 的行为。即使微小的改进也能产生巨大的效果。

四、关键洞察

"对 Agent 来说最符合'人体工程学'的工具，对人类来说也出奇地直观易懂。"

这意味着：如果你觉得一个工具的 API 很别扭，Agent 也会这么觉得。

读后感

这篇文章改变了我对"工具"的理解。工具不是简单的 API wrapper，而是 Agent 与世界交互的接口。就像 UI/UX 设计师为人类设计界面一样，我们需要为 Agent 设计"ACI"。

Think Tool：让 Agent 学会"停下来想一想"

原文：The "think" tool | Anthropic Engineering Blog | 2025.3.20

导语

在复杂的工具使用场景中，Agent 经常犯一种错误：不假思索就行动。

它收到用户请求，立刻开始调用工具，却没有先想想"我是否已经收集了所有需要的信息？这个操作是否符合所有策略规则？"

Anthropic 发现了一种简单但强大的解决方案：给 Agent 一个"思考"工具------Think Tool。

一、Think Tool 是什么

Think Tool 是一个特殊的工具，它不会获取新信息，也不会改变任何数据库，只是在日志中追加一段思考过程。

复制代码

{
  "name": "think",
  "description": "Use the tool to think about something. It will not obtain new information or change the database, but just append the thought to the log. Use it when complex reasoning or some cache memory is needed.",
  "input_schema": {
    "type": "object",
    "properties": {
      "thought": {
        "type": "string",
        "description": "A thought to think about."
      }
    },
    "required": ["thought"]
  }
}

二、Think Tool vs 扩展思维

两者听起来相似，但本质不同：

特性	扩展思维（Extended Thinking）	Think Tool
时机	生成响应之前	生成响应之后，在工具调用链中
用途	深入思考并迭代计划	在新信息出现后停下来分析
最佳场景	简单的工具调用、编码、数学	复杂工具链、策略密集型场景

简单理解： 扩展思维是"想好了再动手"，Think Tool 是"做着做着停下来想一想"。

三、性能数据

τ-Bench 评估

τ-bench 是一个测试模型在客户服务场景中工具使用能力的基准测试。

航空领域（复杂策略）：

配置	pass^1	相对提升
基线	0.370	---
仅扩展思维	0.412	+11%
Think Tool + 优化提示	0.570	+54%

零售领域（较简单策略）：

配置	pass^1
基线	0.783
仅 Think Tool（无提示）	0.812

SWE-bench 评估

Think Tool 为 Claude 3.7 Sonnet 达到 0.623 的最先进分数做出了贡献，平均提高了 1.6% 的性能。

四、何时使用 Think Tool

适合的场景

工具输出分析：需要在采取行动前仔细处理先前工具调用的输出
策略密集型环境：需要遵循详细的指导原则并验证合规性
顺序决策：每个行动都建立在前一个之上，错误代价高昂

不适合的场景

非顺序工具调用：只需一次或并行工具调用
简单指令遵循：约束少，默认行为已足够好

五、优化提示示例

在系统提示中加入具体的思考示例：

复制代码

## 使用 think 工具

在采取任何行动之前，使用 think 工具作为草稿本来：
- 列出适用于当前请求的具体规则
- 检查是否收集了所有必需的信息
- 验证计划的操作符合所有策略
- 迭代检查工具结果的正确性

示例：
用户想取消航班 ABC123
- 需要验证：用户 ID、预订 ID、原因
- 检查取消规则：
  * 是否在预订后 24 小时内？
  * 如果不是，检查票务等级和保险
- 验证没有已飞或过去的航段
- 计划：收集缺失信息，验证规则，获取确认

六、实施建议

困难领域，提示至关重要：简单提供 Think Tool 可能有一定提升，但在复杂领域需要配合优化提示
复杂指导放在系统提示中：比放在工具描述中更有效
负面影响极小：除非 Claude 决定使用它，否则不会改变外部行为

读后感

Think Tool 的设计哲学很打动人：给 Agent 一个"停下来想想"的机会，比让它更快地行动更重要。

这和人类工程师的经验如出一辙------最好的 debug 方法往往不是立刻改代码，而是先在纸上理清思路。

Agent Skills：让 Agent 具备真实世界能力

原文：Equipping agents for the real world with Agent Skills | Anthropic | 2025.10.16

导语

Claude 很强大，但完成真实世界的工作需要程序性知识和组织背景。

比如，你公司的代码风格规范、特定的部署流程、行业特有的文档格式......这些知识不在 Claude 的训练数据里，也无法通过简单的提示词传递。

Agent Skills 是 Anthropic 提出的解决方案：用文件和文件夹将专业知识打包，让通用 Agent 变成符合你需求的专业化 Agent。

一、什么是 Skill

一个 Skill 就是一个包含 SKILL.md 文件的目录。就像给新员工写的入职指南，它包含有序的说明、脚本和资源，赋予 Agent 额外的能力。

SKILL.md 结构

复制代码

---
name: PDF Form Filler
description: Fill PDF forms using Python scripts
---

## Instructions

1. Use the extract_fields.py script to get form fields
2. Fill in the fields based on user data
3. Save the completed PDF

二、渐进式披露机制

Skill 的核心设计是渐进式披露------不一次性把所有信息塞进上下文：

层级	加载时机	内容
第一级	启动时自动预加载	仅元数据（name、description）
第二级	Agent 认为相关时	完整的 SKILL.md 内容
第三级+	特定场景下按需加载	捆绑的脚本、模板等额外文件

这种设计既保证了 Agent 知道有哪些能力可用，又避免了上下文窗口的浪费。

三、工作原理示例：PDF 编辑

Claude 擅长理解 PDF 内容，但无法直接操作 PDF（如填写表单字段）。通过 PDF Skill：

Skill 包含一个 Python 脚本 extract_fields.py
Claude 通过工具调用执行脚本，提取表单字段
Claude 根据用户数据填充字段
脚本生成完成的 PDF

关键点： 代码通过工具调用执行，而不是加载到上下文窗口中，既高效又可靠。

四、开发最佳实践

1. 从评估开始

先识别 Agent 能力的差距，再构建 Skills 来填补。

2. 为规模化构建结构

当 SKILL.md 变得庞大时，拆分为单独的文件。代码既是可执行工具，也是文档。

3. 从 Claude 的角度思考

观察 Claude 在真实场景中如何使用 Skill。特别关注 Skill 的名称和描述------它们直接影响触发机制。

4. 与 Claude 一起迭代

让 Claude 将成功的策略和常见错误捕获到可复用的上下文和代码中。

五、安全考量

Skills 通过指令和代码为 Agent 提供新能力，但也可能引入风险：

仅从受信任的来源安装 Skills
对不受信任的来源，使用前需彻底审计
特别检查代码依赖项和捆绑资源

六、未来展望

当前支持：Claude.ai、Claude Code、Claude Agent SDK、Claude Developer Platform。

未来方向：

支持 Skill 的创建、编辑、发现、共享全生命周期
探索 Skills 与 MCP 服务器的互补关系
长远目标：让 Agent 能够自主创建、编辑和评估 Skills

读后感

Agent Skills 的理念很巧妙：不是让模型更聪明，而是给模型更好的"工作手册"。

这和现实世界的团队管理一模一样------最好的团队不一定由最聪明的人组成，而是由有清晰 SOP 和知识库的团队组成。

上下文工程：Agent 的"记忆"与"注意力"管理

原文：Effective context engineering for AI agents | Anthropic Engineering Blog | 2025.9.29

导语

在提示工程之后，一个新概念正在崛起：上下文工程（Context Engineering）。

构建 LLM 应用不再只是"找到正确的提示词"，而是回答一个更宏观的问题："什么样的上下文配置最有可能产生模型的期望行为？"

上下文指的是采样 LLM 时包含的所有 token------系统指令、工具定义、外部数据、消息历史等。上下文工程就是精心策展这些 token 的艺术。

一、为什么上下文工程很重要

注意力预算有限

和人类一样，LLM 在处理过多信息时也会失去焦点。上下文窗口不是"可以塞多少就塞多少"的存储空间。

上下文腐烂

随着上下文窗口中的 token 增加，模型准确回忆信息的能力会下降。

边际收益递减

上下文是有限的资源，必须被视为一种需要精心管理的稀缺资源。

核心原则：找到能够最大化产生预期结果的最小化高信号 token 集合。

二、有效上下文的构成要素

系统提示词

使用简单直接的语言
找到"正确的高度"：避免过于复杂的逻辑，也避免过于模糊的指导
使用 XML 标签或 Markdown 标题结构化组织
从最简化的提示开始测试，根据失败模式逐步添加指令

工具

工具定义了 Agent 与信息/操作空间的契约
返回信息应节省 token，并鼓励高效的行为
避免臃肿的工具集：功能不应重叠，参数应清晰明确

示例

使用多样化、规范性的示例
对 LLM 来说，示例是"一图胜千言"的存在

三、上下文检索策略

即时上下文（Just-in-Time Context）

不要预先检索所有数据，让 Agent 在运行时通过工具动态加载：

Agent 维护轻量级标识符（文件路径、链接等）
按需获取数据，类似人类使用书签
支持渐进式披露，让 Agent 通过探索逐步发现上下文

混合策略

结合预检索和自主探索。例如 CLAUDE.md 文件预先加载，其他文件通过 glob 和 grep 按需访问。

四、长期任务的三大技术

1. 压缩（Compression）

当对话接近上下文窗口限制时，总结内容并用摘要重新初始化。

保留关键信息（架构决策、未解决的 Bug）
丢弃冗余的工具输出
最轻量的压缩形式：清除工具调用和结果

2. 结构化笔记（Structured Notes）

Agent 定期将笔记写入上下文窗口之外的持久化内存，稍后重新读取。

提供具有最小开销的持久记忆
Agent 可维护待办事项列表、战略笔记等
案例： Claude 玩《宝可梦》时，通过笔记记录数千步的训练进度和战斗策略

3. 子 Agent 架构（Sub-Agent Architecture）

使用专门的子 Agent 处理具有干净上下文窗口的特定任务。

主 Agent 负责高层协调
子 Agent 返回浓缩的摘要
实现关注点的分离

五、实用对照表

挑战	解决方案
上下文过长	压缩 + 清除冗余工具输出
需要跨会话记忆	结构化笔记
任务过于复杂	子 Agent 分解
工具响应太大	分页 + 截断 + response_format
预加载过多工具	延迟加载 + Tool Search

读后感

这篇文章最核心的一句话：

"找到产生预期结果所需的最小化高信号 token 集合。"

上下文工程的本质不是"塞更多信息"，而是"精心筛选最有价值的信息"。这和信息论的核心思想一脉相承。

Contextual Retrieval：让 RAG 更懂上下文

原文：Introducing Contextual Retrieval | Anthropic | 2024.9.19

导语

RAG（检索增强生成）已经是 LLM 应用的标配。但传统的 RAG 有一个根本性缺陷：在切分文本块时会丢失上下文。

一个文本块说"该公司收入较上一季度增长了 3%"------但它没说是哪家公司、哪个季度。这导致检索系统在面对精确查询时经常"找不到"相关信息。

Anthropic 提出了 Contextual Retrieval，通过在每个文本块前面添加上下文解释，将检索失败率降低了 49%，结合重排序甚至可降低 67%。

一、传统 RAG 的问题

传统 RAG 的预处理流程：

将文档分解为小块（通常几百个 token）
用嵌入模型将块转换为向量
存储到向量数据库中

问题所在： 切分后，单个块缺乏足够的上下文。

比如财务报告中的一段话：

复制代码

原始块："该公司收入较上一季度增长了 3%。"

这个块本身不说明是哪家公司或时间段，导致无法精确检索。

二、Contextual Retrieval 的解决方案

在嵌入之前，在每个块前面添加块特定的解释性上下文：

复制代码

上下文化的块："此块来自 ACME Corp 2023 年第二季度业绩的 SEC 文件；
上一季度的收入为 3.14 亿美元。该公司收入较上一季度增长了 3%。"

具体做法

使用 Claude 为每个块自动生成上下文：

复制代码

<document>
{{WHOLE_DOCUMENT}}
</document>
这是我们希望置于整个文档上下文中的块
<chunk>
{{CHUNK_CONTENT}}
</chunk>
请提供一个简短的上下文，以便将该块置于整个文档中，
以便改进块的搜索检索。仅回答简短的上下文，不要回答其他任何内容。

生成的上下文通常为 50-100 个 token。

成本控制

使用 Anthropic 的提示缓存 功能，文档只需加载到缓存中一次。生成上下文块的一次性成本约为每百万文档 token 1.02 美元。

三、两个子技术

上下文嵌入（Contextual Embeddings）

在嵌入之前添加上下文，让向量更准确地表示块的语义。

上下文 BM25（Contextual BM25）

BM25 是基于词法匹配的排名函数，特别擅长精确匹配（如"错误代码 TS-999"）。添加上下文后，BM25 的匹配能力大幅提升。

四、性能提升

方法	检索失败率降低
上下文嵌入	35%
上下文嵌入 + 上下文 BM25	49%
上下文嵌入 + 上下文 BM25 + 重排序	67%

五、重排序进一步提升

在检索后添加重排序步骤：

初始检索获取前 150 个候选块
使用重排序模型（如 Cohere Reranker）评估每个块的相关性
选择前 20 个最相关的块

六、关键发现总结

嵌入 + BM25 优于单独使用嵌入
Voyage 和 Gemini 嵌入模型表现最好
传递前 20 个块比前 10 或前 5 个更有效
向块添加上下文大幅提高检索准确性
重排序比不重排序更好
所有好处都是叠加的

七、小提示：何时不需要 RAG

如果你的知识库少于 200,000 个 token（约 500 页），可以直接将整个知识库放入提示中。配合提示缓存，延迟降低 2 倍，成本降低 90%。

读后感

Contextual Retrieval 的思路非常优雅：不是改模型，不是改算法，而是改数据。通过在预处理阶段投入小成本为每个块添加上下文，获得了巨大的检索质量提升。

这再次印证了一个 AI 工程的基本原则：数据质量 > 算法复杂度。

长时间运行的 Agent：如何设计可靠的执行框架

原文：Effective harnesses for long-running agents | Anthropic Engineering Blog | 2025.11.26

导语

Agent 能力越来越强，开发者开始让它们承担需要持续数小时甚至数天的复杂任务。但一个核心问题摆在面前：

Agent 必须在离散的会话中工作，而每个新会话开始时，对之前发生的事情一无所知。

想象一个软件项目的工程师轮班工作，每个新工程师对上一班次发生的事情一无所知。这就是长时间运行 Agent 面临的困境。

一、两种典型的失败模式

失败模式 1：一次做太多

Agent 试图一次性完成整个应用程序，用完上下文窗口后，留给下一个会话一个功能实现了一半且没有文档的烂摊子。

失败模式 2：过早宣布胜利

在已经构建了一些功能之后，后续的 Agent 实例四处查看，看到已有进展，就宣布工作完成了。

二、双 Agent 解决方案

初始化 Agent

第一个会话使用专门的提示，要求模型设置初始环境：

init.sh 脚本：可以运行开发服务器
claude-progress.txt：记录 Agent 所做的工作
feature_list.json：全面的功能需求文件
初始 git 提交

编码 Agent

每个后续会话要求模型取得增量进展：

运行 pwd 确认工作目录
阅读 git 日志和进度文件
阅读功能列表，选择最高优先级的未完成功能
实现功能并测试
提交 git 并更新进度文件

三、关键设计要素

功能列表（Feature List）

初始化 Agent 编写一个全面的功能需求文件（JSON 格式），扩展用户的初始提示：

复制代码

{
    "category": "functional",
    "description": "New chat button creates a fresh conversation",
    "steps": [
      "Navigate to main interface",
      "Click the 'New Chat' button",
      "Verify a new conversation is created"
    ],
    "passes": false
}

使用 JSON 而非 Markdown，因为模型不太可能不当更改 JSON 文件。

增量进展

一次只处理一个功能
通过 git 提交记录进度
在进度文件中写入摘要
使用 git 恢复错误的代码更改

端到端测试

明确要求 Agent 像人类用户那样使用浏览器自动化工具进行测试。在构建 Web 应用时，使用 Puppeteer MCP 服务器进行端到端验证。

四、失败模式与解决方案对照表

问题	初始化 Agent 行为	编码 Agent 行为
过早宣布完成	设置功能列表 JSON	阅读功能列表，选择单个功能
环境有错误或缺文档	写 git 仓库和进度笔记	开始前阅读进度文件和 git 日志
过早标记功能完成	设置功能列表	仔细测试后才标记"通过"
花时间弄清如何运行	编写 `init.sh`	阅读 `init.sh` 后启动

五、核心洞察

关键见解是找到一种方法，让 Agent 在从新的上下文窗口开始时能够快速理解工作状态。

这通过 claude-progress.txt 文件和 git 历史记录来实现。这些做法的灵感来自于了解有效软件工程师每天所做的工作。

六、未来方向

单个通用编码 Agent vs 专门的多 Agent 架构（测试 Agent、QA Agent、代码清理 Agent）
从 Web 应用开发推广到科学研究、金融建模等领域

读后感

这篇文章最有价值的洞察是：像管理一个工程师团队一样管理 Agent。

功能列表、进度文件、git 提交------这些不是什么新发明，而是软件工程师每天都在用的工作方法。最好的 Agent 框架设计，就是把最好的人类工程实践编码化。

多 Agent 协作系统：Anthropic 的实战经验

原文：How we built our multi-agent research system | Anthropic Engineering Blog | 2025.6.13

导语

Claude 的研究功能背后，是一个完整的多 Agent 协作系统。首席 Agent 负责规划，多个子 Agent 并行搜索，最后汇总生成带引用的研究报告。

这篇文章是 Anthropic 的实战经验分享------从原型到生产的全过程，包括架构设计、提示工程、评估方法和生产可靠性。

一、为什么需要多 Agent

研究任务的特殊性

开放式问题，无法预测所需步骤
需要根据发现动态调整策略
信息量可能远超单个上下文窗口

多 Agent 的优势

并行压缩：子 Agent 在各自的上下文窗口中并行操作，将海量信息压缩后返回
关注点分离：每个子 Agent 有独特的工具、提示和探索轨迹
超越个体限制：就像人类社会通过协作超越个体能力

性能数据

多 Agent 系统（Opus 4 首席 + Sonnet 4 子 Agent）在研究评估中比单 Agent Opus 4 高出 90.2%
仅 token 使用量就解释了 BrowseComp 评估中 80% 的性能差异

二、系统架构

协调器-工作器模式

复制代码

用户查询 → 首席研究 Agent
                ├── 子 Agent 1 (搜索方向 A)
                ├── 子 Agent 2 (搜索方向 B)
                └── 子 Agent 3 (搜索方向 C)
                         ↓
              首席 Agent 综合结果
                         ↓
              引文 Agent 处理来源
                         ↓
                    最终研究报告

关键设计

首席 Agent 将计划保存到内存（上下文窗口超过 200K tokens 时会被截断）
子 Agent 独立执行搜索，使用交错思考评估结果
引文 Agent 确保所有声明正确归因到来源

三、八条提示工程原则

1. 像你的 Agent 一样思考

在控制台中构建模拟，使用完全相同的提示和工具，逐步观察 Agent 工作。

2. 教导协调器如何委派

每个子 Agent 需要：明确的目标、输出格式、工具使用指导和任务边界。简短的指令（如"研究半导体短缺"）会导致重复工作。

3. 将规模扩展到查询复杂性

简单事实查找：1 个 Agent，3-10 次工具调用
直接比较：2-4 个子 Agent
复杂研究：10+ 个子 Agent

4. 工具设计至关重要

给 Agent 明确的启发式方法：先检查所有可用工具，将工具与用户意图匹配。

5. 让 Agent 自我完善

Claude 4 可以成为出色的提示工程师。一个"工具测试 Agent"通过几十次测试发现了关键的工具缺陷，改进后任务完成时间减少了 40%。

6. 先宽后窄

Agent 默认使用过于冗长的查询。提示 Agent 以简短、宽泛的查询开始，逐渐缩小焦点。

7. 引导思考过程

扩展思考让首席 Agent 规划方法，子 Agent 用交错思考评估工具结果质量。

8. 并行工具调用

引入并行化后，研究时间减少了多达 90%。

四、评估方法

小样本快速启动

不需要数百个任务，20 个代表性查询就是很好的开始。

LLM-as-Judge

使用 LLM 评判器根据标准评估输出：事实准确性、引文准确性、完整性、来源质量、工具效率。

人工评估不可替代

人类测试者发现了 Agent 持续选择 SEO 优化的内容农场而非权威来源的偏差。

五、生产可靠性

Agent 是有状态的，错误会累积

构建可以从错误中恢复的系统，让 Agent 知道工具何时失败并适应。

调试需要新方法

添加完整的生产跟踪，监控 Agent 决策模式和交互结构。

部署需要仔细协调

使用彩虹部署，逐渐将流量从旧版本转移到新版本。

六、Token 经济学

类型	Token 使用量（相对聊天）
普通聊天	1x
单 Agent	4x
多 Agent	15x

多 Agent 系统需要任务价值足够高以支付增加的成本。

读后感

这篇文章最令人震撼的数据是：仅 token 使用量就解释了 80% 的性能差异。

这意味着多 Agent 的核心价值不是"更聪明"，而是"能处理更多信息"。本质上，多 Agent 是一种扩展计算资源的方式。

MCP 代码执行：构建更高效的 Agent

原文：Code execution with MCP | Anthropic Engineering Blog | 2025.11.4

导语

MCP（Model Context Protocol）是连接 Agent 与外部系统的开放标准。社区已构建了数千个 MCP 服务器。但随着连接的工具数量爆炸式增长，传统的"逐个调用工具"方式暴露出严重的效率问题。

Anthropic 提出了一个优雅的解决方案：让 Agent 通过写代码来调用工具。

一、传统工具调用的两大瓶颈

工具定义占用过多上下文

当工具数量达到数千个时，模型需要在处理用户请求前处理数十万 token 的工具定义。

中间结果消耗额外 token

直接调用工具时，每次调用的结果都会传回模型。如果在工具之间传递大量数据（如长文档），数据会重复流经上下文窗口。

例如： 从 Google Drive 获取会议记录并更新到 Salesforce，长文本会被加载两次（获取一次，写入一次），可能导致数万个额外 token。

二、代码执行方案

核心思路

不再用函数调用语法，而是将 MCP 服务器呈现为代码 API，Agent 通过编写代码来交互。

文件系统式工具发现

复制代码

servers
├── google-drive
│   ├── getDocument.ts
│   └── index.ts
├── salesforce
│   ├── updateRecord.ts
│   └── index.ts

Agent 通过探索文件系统按需加载工具定义。

代码编排工具调用

复制代码

import * as gdrive from './servers/google-drive';
import * as salesforce from './servers/salesforce';

const transcript = (await gdrive.getDocument({
  documentId: 'abc123'
})).content;

await salesforce.updateRecord({
  objectType: 'SalesMeeting',
  recordId: '00Q5f000001abcXYZ',
  data: { Notes: transcript }
});

效果： Token 使用量从 150,000 降至 2,000，节省约 98.7%。

三、五大优势

1. 渐进式披露

Agent 像浏览文件系统一样按需读取工具定义，使用 search_tools 快速定位。

2. 上下文高效的结果处理

数据在执行环境中过滤和转换，只将必要结果返回给模型。

例如： 从 10,000 行电子表格中仅筛选出"待处理"的 5 行数据。

3. 更强大的控制流

使用循环、条件判断和错误处理代码，比链式工具调用更高效。

4. 隐私保护

中间结果保留在执行环境中，可对敏感数据进行令牌化处理（如 PII 替换为占位符），数据不经过模型。

5. 状态持久化与技能

Agent 可将中间结果写入文件，将成功的代码保存为可重用函数（Skills）。

四、注意事项

代码执行引入了额外复杂性：

需要安全的沙箱执行环境
资源限制和监控
基础设施要求比直接工具调用更高
需要在效率提升和实现成本之间权衡

读后感

这篇文章揭示了一个重要趋势：Agent 的工具交互方式正在从"声明式"走向"编程式"。

传统的函数调用是"告诉模型调用哪个工具"，代码执行是"让模型写代码来编排工具"。后者更灵活、更高效，也更符合软件工程师的思维方式。

gent 评测怎么做

原文：Demystifying evals for AI agents | Anthropic Engineering Blog | 2026.1.9

导语

没有评测的 Agent 开发，就是盲人骑瞎马。

你修复了一个 Bug，不知道有没有引入新的；你优化了一个提示，不确定其他场景有没有退化。团队陷入被动循环------只能在生产环境中发现问题。

这篇文章是 Anthropic 写的最全面的 Agent 评测指南，覆盖了从概念到实操的完整链条。

一、核心概念

术语	定义
任务（Task）	具有明确输入和成功标准的单个测试
试验（Trial）	对任务的一次尝试（模型有随机性，需多次）
评分器（Scorer）	评估 Agent 性能某方面的逻辑
记录（Transcript）	试验的完整记录（输出、工具调用、推理过程）
结果（Outcome）	试验结束时环境的最终状态

二、三种评分器

类型	方法	优点	缺点
基于代码	字符串匹配、单元测试、静态分析	快速、客观、可重现	脆弱、缺乏细微差别
基于模型	LLM 规则评分、成对比较	灵活、可扩展	不确定性、需校准
人工评分	专家审查、A/B 测试	黄金标准	昂贵、缓慢

三、能力评估 vs 回归评估

能力评估

问："Agent 能做什么？" 针对 Agent 目前还做不好的任务，设定改进目标。

回归评估

问："Agent 是否还能做它以前能做的？" 通过率应接近 100%。

关键机制： 当能力评估达到高通过率后，将其"毕业"为回归评估。

四、不同类型 Agent 的评估策略

编程 Agent

使用确定性测试（单元测试）验证正确性
结合 LLM 规则评估代码质量
参考基准：SWE-bench Verified、Terminal-Bench

对话 Agent

检查可验证的最终状态（退款是否处理）
评估交互质量（同理心、解释清晰度）
需要第二个 LLM 模拟用户

研究 Agent

事实核查 + 覆盖范围检查 + 来源质量检查
LLM 规则需频繁校准

计算机使用 Agent

在真实或沙盒环境中运行
检查是否达到预期结果
平衡 Token 效率和延迟

五、处理非确定性

Agent 行为在运行之间存在差异，需要专门的度量指标：

指标	含义	适用场景
pass@k	k 次中至少一次成功	"只要有一个成功就行"的开发工具
pass^k	k 次全部成功	需要每次都可靠的面向客户系统

六、从零开始的 8 步指南

尽早开始：20-50 个真实失败案例就是很好的起点
从手动测试开始：利用开发中的手动检查和生产 Bug
编写明确的任务：两个专家应独立得出相同的通过/失败结论
平衡问题集：测试应该发生和不应该发生的情况
构建强大的框架：每次试验从干净状态开始
精心设计评分器：优先确定性评分器，LLM 评分器需校准
检查记录：定期阅读记录确认评分是否公平
监控饱和度：100% 通过率意味着需要更难的任务

七、评估不是万能的

最有效的团队结合多种方法：

自动化评估：快速迭代
生产监控：真实用户行为
A/B 测试：衡量实际用户结果
用户反馈：发现未预料的问题
人工记录审查：建立失败模式直觉

读后感

这篇文章最重要的观点是：评估不是锦上添花，而是 Agent 开发的基础设施。

没有评估，你就无法衡量进步。投入到评估中的每一分钟，都会在后续迭代中产生复利效应。

Agent 安全：从权限提示到沙箱隔离

原文：Beyond permission prompts: Claude Code sandboxing | Anthropic Engineering Blog | 2025.10.20

导语

Claude Code 需要访问你的代码库和文件来辅助编码，但这带来了安全风险------尤其是提示词注入。

传统方案是"权限提示"：每个操作都弹窗让用户批准。但 Anthropic 发现，频繁的批准请求导致了审批疲劳，用户不再仔细检查，安全性反而降低了。

Anthropic 的解决方案是沙箱 ------通过定义明确的边界，让 Agent 在边界内自由工作。沙箱技术安全地减少了 84% 的权限提示。

一、为什么权限提示不够

审批疲劳

用户每天要点击数百次"批准"按钮，逐渐变成机械性的点击，不再审查具体操作内容。

安全假象

表面上"每个操作都经过批准"，实际上用户根本没有仔细检查。

二、沙箱的两个关键边界

文件系统隔离

确保 Agent 只能访问或修改特定目录，防止提示词注入导致修改敏感系统文件。

网络隔离

确保 Agent 只能连接到批准的服务器，防止泄露敏感信息或下载恶意软件。

重要： 单独使用任一隔离都不足以保证安全。必须两者结合------如果只有文件系统隔离，Agent 可以通过网络泄露数据；如果只有网络隔离，Agent 可以修改系统文件。

三、沙箱化 Bash 工具

技术实现

基于操作系统原语构建： - Linux ：bubblewrap - macOS ：seatbelt

工作机制

文件隔离：允许对当前工作目录读写，阻止修改外部文件
网络隔离：仅允许通过 Unix 域套接字连接到外部代理服务器，代理强制执行域限制

使用方式

在 Claude Code 中运行 /sandbox 命令。

四、Claude Code 网页版

在云端隔离的沙箱中运行 Claude Code，确保敏感凭据（如 git 凭据或签名密钥）永远不会与 Agent 一起存放在沙箱内。

Git 集成安全

使用自定义代理服务处理所有 git 交互： 1. 沙箱内的 git 客户端通过受限凭据向代理服务认证 2. 代理验证凭据和交互内容（如确保仅推送到配置的分支） 3. 代理在向 GitHub 发送请求之前附加正确的身份验证令牌

五、安全设计思考

安全 vs 自主性

沙箱解决了一个根本性矛盾：我们希望 Agent 更自主（减少人工批准），但又需要确保安全。

答案是：不限制 Agent 的能力，而是限制 Agent 的作用范围。在边界内，Agent 完全自由；超出边界，系统自动阻止。

开源

沙箱功能已开源，帮助其他团队构建更安全的 Agent。

读后感

这篇文章传递的理念很重要：安全不应该是通过"更多审批"来实现的，而是通过"更好的隔离"。

在人类世界中，我们也不是靠审批流程来保证安全的------我们靠的是物理隔离（门禁）、网络隔离（防火墙）和最小权限原则。Agent 的安全设计也应如此。

Coding Agent 最佳实践

原文：Claude Code: Best practices for agentic coding | Anthropic | 2025.4.18

导语

Claude Code 是目前最强大的 Coding Agent 之一。但工具再强，用法不对也白搭。

这篇文章汇总了 Anthropic 内部实战经验，从提示词技巧到项目配置、从工作流设计到团队协作，帮你把 Claude Code 的能力榨干。

一、提供有效的上下文

CLAUDE.md 文件

在项目根目录创建 CLAUDE.md，告诉 Claude 关于你项目的关键信息：

复制代码

# 项目信息

- 技术栈：React + TypeScript + Tailwind
- 包管理器：pnpm
- 测试框架：Vitest
- 代码风格：使用 Prettier，单引号

# 常用命令

- `pnpm dev` - 启动开发服务器
- `pnpm test` - 运行测试
- `pnpm lint` - 代码检查

# 架构约定

- 组件放在 src/components/
- API 路由放在 src/api/
- 使用 Zustand 管理状态

有效的提示技巧

具体：不说"优化这段代码"，说"将这个 O(n²) 的排序优化为 O(n log n)"
提供上下文：说明为什么要做这个改动，而不仅是要做什么
分步骤：复杂任务拆解为子任务
使用规划模式：按 Shift+Tab 让 Claude 先输出方案再编码

二、高效的工作流

探索 → 规划 → 编码 → 验证

探索：让 Claude 先理解代码库结构
规划：让 Claude 输出实现方案（不写代码）
编码：确认方案后再开始实现
验证：运行测试、检查 lint、手动验证

深度思考指令

在提示词中使用以下关键词触发更深入的思考：

think - 基础思考
think hard - 深度思考
ultrathink - 最深层次思考

管道操作

复制代码

# 让 Claude 解释代码
cat app.py | claude -p "解释这段代码"

# 代码审查
git diff main | claude -p "审查这些变更"

# 生成提交信息
git diff --staged | claude -p "为这些变更生成规范的提交信息"

三、项目配置最佳实践

分层配置

全局 CLAUDE.md：通用规则（代码风格、提交规范）
项目 CLAUDE.md：项目特定信息
目录 CLAUDE.md：子模块特定约定

权限管理

默认只读模式------确保安全
使用 --dangerously-skip-permissions 跳过权限确认（仅用于可信环境）
使用 /sandbox 启用沙箱模式

四、团队协作

共享配置

将 CLAUDE.md 加入版本控制，确保团队成员使用一致的 Agent 配置。

代码审查集成

复制代码

# 自动化代码审查
git diff main | claude -p "审查代码，重点关注：
1. 安全漏洞
2. 性能问题
3. 代码风格一致性"

CI/CD 集成

将 Claude Code 集成到 CI 流程中，自动生成测试、检查代码质量。

五、常见陷阱与避免方法

陷阱	避免方法
提示太模糊	提供具体、可量化的要求
一次让 Claude 做太多	拆分为小任务，逐步完成
不验证 Claude 的输出	始终运行测试和 lint
忽略 CLAUDE.md	维护好项目配置文件
不使用规划模式	复杂任务先规划再编码

六、进阶技巧

多文件重构

复制代码

帮我将 src/utils/ 目录下所有使用 moment.js 的文件迁移到 dayjs。
请先列出需要修改的文件，然后逐一修改，每个文件修改后运行测试确认。

调试辅助

复制代码

这个测试失败了：[粘贴错误信息]
请分析原因并修复。修复后确保所有测试通过。

代码生成

复制代码

根据以下 API 规范，生成完整的 CRUD 接口：
- 资源：User
- 字段：id, name, email, role
- 包含：路由、控制器、service、验证、测试

读后感

Claude Code 最佳实践的核心是一个简单的道理：你给 Agent 的上下文质量，直接决定了 Agent 的输出质量。

花 10 分钟写好 CLAUDE.md，可能比花 1 小时调提示词更有效。

Agent 故障复盘：三个真实案例分析

原文：A postmortem of three recent issues | Anthropic Engineering Blog | 2025.9

导语

2025 年 8 月到 9 月初，三个基础设施漏洞同时导致 Claude 响应质量间歇性下降。用户报告模型"变笨了"、"输出出现奇怪的字符"、"回答质量不稳定"。

Anthropic 发布了这篇坦诚的事后分析，详细解释了三个问题的技术细节。这可能是 AI 行业公开的最详细的模型质量故障复盘。

一、Anthropic 的承诺

"我们绝不会因为需求、时间段或服务器负载而降低模型质量。"

用户报告的所有问题，纯粹是由基础设施漏洞引起的。

二、三个重叠的漏洞

漏洞 1：上下文窗口路由错误

发生时间： 8 月 5 日引入，8 月 29 日因负载平衡变更影响扩大

问题： 部分 Sonnet 4 请求被错误地路由到了配置用于即将推出的 1M token 上下文窗口的服务器。

影响范围： - Claude Code：约 30% 的用户至少有一条消息被路由错误 - Amazon Bedrock：错误路由流量峰值达 0.18% - Google Vertex AI：受影响请求少于 0.0004%

修复： 9 月 4 日部署路由逻辑修复。

漏洞 2：输出损坏

发生时间： 8 月 25 日部署，9 月 2 日回滚

问题： 运行时性能优化配置错误，导致 token 生成过程中偶尔高概率分配给本不该出现的 token。

症状： 在英文提示的回复中插入泰文或中文字符，代码中产生明显的语法错误。

影响： Opus 4.1、Opus 4 和 Sonnet 4。第三方平台未受影响。

漏洞 3：XLA:TPU 误编译

发生时间： 8 月 25 日部署，9 月 4 日开始回滚

问题： 为改进 token 选择而部署的代码意外触发了 XLA:TPU 编译器中的一个潜在漏洞。涉及混合精度运算（bf16 与 fp32 不匹配）和近似 top-k 操作的缺陷。

影响： 确认影响 Claude Haiku 3.5，可能影响部分 Sonnet 4 和 Opus 3。

三、为何检测困难

评估盲区

现有基准测试未能捕捉到退化，因为 Claude 通常能从孤立错误中恢复。

隐私限制

内部隐私控制限制了工程师访问用户交互数据的能力，阻碍了问题识别。

症状混乱

每个漏洞在不同平台上产生不同症状，看起来像随机的不一致性。

噪音干扰

过于依赖嘈杂的评估数据，未能及时将用户报告与基础设施变更联系起来。

四、改进措施

更敏感的评估：开发能更可靠区分正常和异常的评估工具
全方位质量评估：在真实生产系统上持续运行评估
更快的调试工具：在不牺牲用户隐私的前提下更好地调试社区反馈

五、对 Agent 开发者的启示

1. 模型质量不是恒定的

你的 Agent 可能因为底层模型的基础设施问题而表现异常。建立自己的质量监控，不要完全依赖模型提供商。

2. 评估需要贴近真实场景

Anthropic 的标准基准测试没有发现这些问题。这意味着你的评估也可能有盲区。确保评估覆盖生产中的实际使用模式。

3. 错误会以意想不到的方式表现

泰文字符出现在英文回复中、TPU 编译器的精度问题导致模型"变笨"......这些都不是显而易见的故障，需要细致的监控和分析。

4. 多平台部署增加复杂性

同一个漏洞在 AWS Trainium、NVIDIA GPU 和 Google TPU 上的表现完全不同。如果你的 Agent 部署在多个平台，需要分平台监控。

读后感

这篇文章最打动我的是 Anthropic 的透明度。

在 AI 行业，大多数公司对模型质量问题讳莫如深。Anthropic 不仅公开承认了问题，还详细解释了每个漏洞的技术细节------包括 XLA 编译器的底层 bug。

这种透明度本身就是一种信任构建。对于 Agent 开发者来说，这篇文章的价值不仅在于技术细节，更在于它提醒我们：即使是最好的模型提供商，也会犯基础设施级别的错误。你需要自己的防线。