Anthropic

本文整理自 Anthropic 的工程师 Barry 和 Mahesh 在 AI Engineer 做的关于 Skills 的分享：Don’t Build Agents, Build Skills Instead。 Anthropic 这帮工程师真的非常高产，继创造了 MCP 协议、Claude Code 编码 Agent 后，又创造了 Skills。他们的每一次创新都是源于实际工程开发中的真实需求，比如： MCP 协议的提出是因为解决模型与异构数据源（如本地文件、SaaS工具）连接的碎片化与标准化难题； Claude Code 创造是因为突破对话框的限制，让 AI 直接深入本地开发环境，实现从“阅读代码”到“执行构建”的自主闭环。 而 Skills 的创造是因为 将高频、复杂的任务逻辑封装为可复用的标准化模块，让 Agent 拥有长期的“肌肉记忆”，避免在重复任务中反复进行低效的 Prompt 引导。 以下是本次分享的核心内容，由我和 Gemini 3 Pro 共同整理而成。 代码就是这一层通用的接口 以前我们有个误区，觉得不同领域的 Agent 应该长得完全不一样。做金融的 Agent 和写代码的 Agent，肯定需要完全不同的工具和脚手架，甚至得为每个用例单独造一个 Agent。 但后来我们发布了 Claude Code（我们的第一个编程 Agent），搞着搞着发现：原来底下那个通用的 Agent 其实比我们想象的要强大得多。 代码不仅仅是一个使用场景，它其实是连接数字世界的通用接口。 想象一下生成一份财务报告：模型调用 API 拉数据、在文件系统里整理、用 Python 分析、最后输出格式化文件。这一整套流程，其实只需要极薄的一层脚手架（Bash 和文件系统）就能搞定。 智商 300 的天才 vs....

本文整理自前 Meta 首席工程师、Claude Code 创造者 Boris Cherny 深度访谈。 你可能还没听过 Boris Cherny 这个名字，但如果你关注 AI 编程，你一定听说过 Claude Code。 Boris 是 Claude Code 的创造者，现在在 Anthropic 工作。在此之前，他在 Meta（Facebook）和 Instagram 摸爬滚打了多年，一路干到了 Principal Engineer（首席工程师/IC8 级别）。 从早期的 Facebook Groups 到 Instagram 的日本团队，再到如今在 Anthropic 重新定义编程方式，Boris 的职业生涯简直就是一本“工程师打怪升级指南”。 这不仅仅是关于写代码，更是关于如何在大厂里找到“潜需求”、如何用“旁门左道”的项目获得晋升，以及——在 AI 满天飞的今天，我们到底该怎么写代码？ 一、 产品哲学的核心：寻找“潜需求” (Latent Demand) 如果问 Boris 做产品最重要的原则是什么，他会毫不犹豫地告诉你：潜需求。 什么意思？简单说就是：你永远没法让用户去做他们根本不想做的事。你只能发现他们已经在笨拙地尝试做的事，然后帮他们做得更顺滑。 他在 Facebook 时的几个成功项目都验证了这一点： Marketplace（二手交易市场）： 他们发现 Facebook Groups 里居然有 40% 的帖子都是在买卖东西，尽管那个功能根本不是为此设计的。用户在“滥用”产品，这恰恰就是机会。 Facebook Dating： 数据显示，大量用户在查看非好友的異性主页。也是一种本来就存在的“潜需求”。 正如 Boris 所说：“找到用户的意图，然后给他们铺好路，别试图强行改变他们的行为。” 二、 大厂生存：跨部门协作与“Side Quests” 在大厂工作，常常像是在泥潭里跳舞。Boris 讲了一个他在 Facebook 做“Chats in Groups”项目时的噩梦。...

本文由 Anthropic 工程师 Justin Young 撰写：Effective harnesses for long-running agents。本文探讨了随着 AI Agent能力增强，在处理跨越数小时或数天的复杂任务（如软件工程）时面临的核心挑战：如何在多个有限的上下文窗口（context windows）之间保持工作的连贯性。作者指出，仅靠上下文压缩不足以解决问题，Agent 容易出现试图一次性完成任务（one-shotting）或过早宣布任务完成的失败模式。 为了解决上述问题，作者提出了一套基于 Claude Agent SDK 的双重解决方案： 初始化Agent （Initializer agent）：负责在首次运行时设置环境和规划任务。 编码Agent （Coding agent）：负责在后续会话中进行增量开发，并为下一次会话留下清晰的记录。 这一方案通过结构化的环境设置、详细的功能列表和严格的增量工作流，确保Agent 能够像人类工程师轮班一样，在没有先前记忆的情况下高效接手工作。 关键细节 核心挑战与失败模式 上下文限制：Agent 在离散的会话中工作，新会话开始时没有之前的记忆。 常见错误：在使用 Opus 4.5 等前沿模型时，若仅给出高层级提示，Agent 倾向于试图一次性构建整个应用，导致上下文耗尽、功能半途而废且缺乏文档；或者在仅完成部分功能后误判项目已完成。 解决方案的具体实施 环境初始化：Initializer agent 会创建关键的基础设施，包括： init.sh 脚本：用于启动开发环境。 claude-progress.txt 文件：记录Agent 的操作日志。 初始的 git 提交：建立版本控制基础。 功能列表（Feature List）：创建一个包含详细需求的 JSON 文件（例如 claude.ai 克隆项目包含 200 多个功能点）。选择 JSON 而非 Markdown 是为了防止模型意外覆盖文件结构。 增量工作流与状态管理 快速上手（Getting up to speed）：Coding agent 在每个会话开始时执行标准化步骤： 运行 pwd 确认工作目录。 读取 git 日志和进度文件以了解最近的工作。 读取功能列表，选择优先级最高且未完成的功能。 运行 init....

2025 年 11 月 25 日，Anthropic 正式发布了 Claude Opus 4.5 ，这是目前在编程、智能体（Agent）协作以及计算机操作领域最先进的模型。它在处理深度研究、幻灯片制作和电子表格等日常任务上也有显著提升，代表了 AI 系统能力的又一次飞跃。 关键细节 卓越的编程与推理能力 超越人类的测试成绩：在 Anthropic 内部用于招聘的高难度工程测试中，Claude Opus 4.5 在 2 小时的时间限制内，得分超过了以往所有的人类候选人。 基准测试提升：在 Terminal Bench 测试中，该模型比 Sonnet 4.5 提升了 15% ；在 Excel 自动化任务中，准确率提升了 20% ，效率提升了 15% 。 创造性解决问题：在 $\tau$-bench 测试中（模拟航空公司客服），模型展示了极高的灵活性，通过“先升舱再改签”的合规策略解决了看似无法处理的修改航班请求，体现了深度的推理能力。 成本效益与开发工具 定价与获取：开发者现在可以通过 API 使用 claude-opus-4-5-20251101 ，定价为每百万 token $5 / $25 ，这使得 Opus 级别的能力更加普及。 效率提升：在处理长程编程任务时，该模型可节省高达 65% 的 token 用量。工具调用错误和构建错误减少了 50% 到 75% 。 新的控制参数：API 新增了 “effort parameter” （努力程度参数），允许开发者在速度/成本与极致性能之间进行权衡。在最高设定下，其表现超出 Sonnet 4.5 4....

本文由 Anthropic 应用 AI 团队撰写：Effective context engineering for AI agents。其中探讨了从提示工程 (prompt engineering) 到上下文工程 (context engineering) 的演变，并将其定位为构建高效、可控 AI 智能体的关键。文章指出，随着模型能力的增强，核心挑战已从编写完美的提示语转变为精心管理和优化输入给模型的整个信息集（即上下文）。 关键细节 上下文的基本构成与优化 系统提示 (System Prompts)：应使用清晰、直接的语言。避免过于具体、僵化的逻辑，也要避免过于模糊、宽泛的指导。建议使用 XML 标签或 Markdown 标题来组织提示结构，使其清晰。 工具 (Tools)：工具的设计应追求 token 效率和功能独立性，避免功能重叠导致智能体混淆。一个常见的失败模式是工具集过于臃肿。 示例 (Examples)：提供少量（few-shot）但多样化、有代表性的示例，比罗列大量边缘案例效果更好。 动态上下文管理策略 即时上下文检索 (Just in time context)：智能体并非预先加载所有数据，而是在运行时使用工具（如读取文件、查询数据库）动态地将所需信息载入上下文。这种方式模拟了人类按需检索信息的习惯，实现了信息的“渐进式披露” (progressive disclosure)。 混合策略 (Hybrid Strategy)：在某些场景下，可以结合预先加载部分数据和智能体自主探索，以平衡速度和灵活性。 应对长时程任务的专门技术 对于超出单个上下文窗口容量的长期任务（如大型代码迁移、全面研究项目），可以采用以下技术： 压缩 (Compaction)：当对话接近上下文窗口极限时，让模型对现有内容进行总结和压缩，然后带着这个摘要开启一个新的上下文窗口。最简单的压缩形式是清除历史记录中原始的工具调用结果。 结构化笔记 (Structured note-taking)：让智能体将关键信息、待办事项或中间结论记录到上下文窗口之外的持久化存储中（如一个 NOTES.md 文件），并在需要时重新读入。这相当于为智能体提供了外部记忆。 子智能体架构 (Sub-agent architectures)：将一个复杂任务分解，由一个主智能体进行高层协调，多个专职的子智能体处理具体的子任务。每个子智能体在自己的独立上下文中完成工作，然后将精炼后的结果返回给主智能体。 原文：AI 智能体的有效上下文工程 发布于 2025 年 9 月 29 日 上下文是 AI 智能体的一个关键但有限的资源。在这篇文章中，我们探讨了有效策划和管理为它们提供支持的上下文的策略。 在应用 AI 领域，提示工程 (prompt engineering) 几年来一直是关注的焦点，之后一个新术语开始崭露头角：上下文工程 (context engineering)。使用语言模型进行构建，正变得越来越不局限于为提示找到正确的词语和短语，而是更多地回答一个更广泛的问题：“什么样的上下文配置最有可能产生我们模型的期望行为？”...

本文由 Anthropic 工程师 Ken Aizawa 所写：Writing effective tools for agents — with agents。其中介绍了一系列为 AI 代理（agents）构建高效工具的最佳实践和核心原则。为非确定性的 AI 代理设计工具与为传统的确定性软件系统编写函数或 API 有着根本性的不同，需要采取一种以代理为中心、由评估驱动的迭代开发方法。 关键细节 1. 构建和优化工具的流程 文章提出了一个与 AI 代理协作、以评估为驱动的迭代流程： 构建原型： 快速搭建工具原型，并利用 Claude Code 等 AI 代理辅助编写。可以通过本地 MCP (Model Context Protocol) 服务器或桌面扩展进行测试。 运行综合评估： 生成任务： 与 AI 代理协作，生成大量源于真实世界、具有足够复杂度的评估任务。强任务可能需要多次、甚至数十次工具调用。 运行评估： 通过直接调用 LLM API，在简单的代理循环中运行评估。建议让代理输出推理过程（CoT）以更好地理解其行为。 分析结果： 代理是发现问题的合作伙伴。通过分析其推理过程、原始交互记录以及调用指标（如冗余调用、错误率），可以发现工具的不足之处。 与代理协作改进： 将评估结果和记录直接输入给 Claude Code，让它分析问题并重构优化工具代码和描述，从而形成一个持续改进的闭环。 2. 编写高效工具的核心原则 选择合适的工具： 质量优于数量。避免简单地将每个 API 端点都包装成一个工具。 应构建少数几个针对高影响力工作流程的、经过深思熟虑的工具。例如，用一个 schedule_event 工具整合查找空闲时间和创建会议等多个步骤。 命名空间（Namespacing）： 当工具数量增多时，使用共同的前缀（如 asana_projects_search）对相关工具进行分组，可以帮助代理在不同工具间做出正确选择，避免混淆。 返回有意义的上下文： 工具返回的数据应优先考虑上下文相关性，而非技术细节。使用自然语言名称（name）代替晦涩的标识符（uuid）。 提供多种响应格式（如 concise 和 detailed），让代理可以根据需要选择信息的详细程度，从而控制上下文的消耗。 优化令牌（Token）效率：...

文本由 Anthropic 工程师由 Erik Schluntz 和 Barry Zhang 撰写：Building effective agents，文中探讨了构建高效 AI 代理（Agent）的最佳实践。 最成功的 AI 代理系统并非建立在复杂的框架之上，而是采用简单、可组合的模式。开发者应从最简单的方案（如优化单个 LLM 调用）开始，仅在确实需要时才引入更复杂的代理系统。诸如 LangGraph 等框架虽然可以简化初始开发，但也可能引入不必要的抽象层，使调试变得困难。建议开发者直接使用 LLM API，并确保理解所使用框架的底层逻辑。 代理系统的核心在于 LLM 与工具的交互。因此，投入精力设计一个清晰、易于使用的“代理-计算机接口” (ACI) 至关重要，这包括编写详尽的工具文档和进行充分的测试。文章提出了一系列从简单到复杂的构建模式，从基础的“增强型 LLM”到自主代理，开发者可以根据具体需求组合和定制这些模式。 关键细节 代理系统的类型 工作流 (Workflows)：通过预定义的代码路径来编排 LLM 和工具，具有较高的可预测性。 代理 (Agents)：LLM 能够动态地指导自己的流程和工具使用，更加灵活，适用于无法预知步骤的开放式问题。 核心构建模式 基础模块：增强型 LLM 这是所有代理系统的基础，即一个集成了检索、工具和记忆等增强功能的 LLM。 工作流：提示链 (Prompt Chaining) 将一个任务分解为一系列连续的步骤，每一步的 LLM 调用处理上一步的输出。适用于可清晰分解为固定子任务的场景。 工作流：路由 (Routing) 对输入进行分类，并将其引导至专门的下游任务或模型。例如，将简单的客户问题路由到成本更低的 Claude Haiku 4.5 模型。 工作流：并行化 (Parallelization) 让 LLM 同时处理一个任务的不同部分。具体可分为： 分片 (Sectioning)：将任务分解为独立的子任务并行运行。 投票 (Voting)：多次运行同一个任务以获得多样化的输出或更可靠的结果。 工作流：协调器-工作者 (Orchestrator-workers) 由一个中央 LLM（协调器）动态分解任务，并将其分配给多个 LLM（工作者）执行。适用于子任务无法预先确定的复杂场景，如编码。 工作流：评估器-优化器 (Evaluator-optimizer) 一个 LLM 负责生成响应，另一个 LLM 在循环中提供评估和反馈，以迭代方式改进输出质量。 自主代理 (Autonomous Agents) 适用场景：用于解决难以预测所需步骤的开放式问题。代理能够独立规划和执行，并通过与环境（如工具调用结果）的交互来评估进展。 注意事项：自主代理的成本更高，且存在错误累积的风险。因此，必须在沙盒环境中进行广泛测试，并设置适当的护栏（如最大迭代次数）。 实践应用领域 客户支持：代理可以通过集成工具来查询客户数据、处理退款等，将对话与实际操作相结合。 编码代理：代理可以根据需求描述自主修改多个代码文件，并通过自动化测试来验证解决方案的正确性，例如在 SWE-bench 基准测试中的应用。 原文：构建高效的智能体 发布于 2024年12月19日...

本文由 Claude Code 负责人 Boris Cherny 所写：Claude Code: Best practices for agentic coding。本文档概述了高效使用 Claude Code 这一命令行编程工具的最佳实践。Claude Code 作为一个灵活、低阶的编程助手，旨在通过提供接近原始模型的访问能力，帮助工程师将其深度集成到开发工作流中。以下是核心观点和关键实践的总结。 关键细节 1. 环境定制与配置 创建 CLAUDE.md 文件：在项目根目录、父/子目录或用户主目录 (~/.claude/CLAUDE.md) 中创建此文件，用于提供项目特定的上下文，如常用命令、代码规范、测试指令等。Claude 会自动加载这些信息。 优化 CLAUDE.md：像优化提示词一样迭代 CLAUDE.md 文件，保持其简洁有效。可以使用 # 键快速添加指令到该文件中。 管理工具权限：通过会话中选择 “Always allow”、使用 /permissions 命令或编辑配置文件，自定义工具的白名单，以在安全和效率之间取得平衡。 安装 gh CLI：若使用 GitHub，安装 gh 命令行工具能让 Claude 更高效地进行创建 issue、提交 PR 等操作。 2. 扩展 Claude 的工具集 利用 bash 工具：Claude 可以直接使用您环境中的 bash 工具和自定义脚本，只需告知其工具名称和用法。 使用 MCP (Model Context Protocol)：通过连接到 MCP 服务器，Claude 可以使用更复杂的外部工具，如 Puppeteer 或 Sentry。 自定义斜杠命令：在 ....

Anthropic 最近虽然口碑差，但人才密度还是高，继 MCP 之后他们又新推出来 Agent Skills，这个思路非常好，既给了 Agent 确定性，也给了其几乎无限的上下文，顺便帮你省了钱。也算是和 MCP 互补，一个连接外部系统，一个连接本地脚本和文档。 Agent Skills 的核心思想也很简单，就是通过提供一个由Skill、脚本和资源组成的结构化文件夹，将领域专家的知识打包在这些文件夹中，让 Agent 能够动态加载这些“Skills”。 Skill 的构成与工作原理大概是下面这样： 一个 Agent Skill 本质上就是一个包含 SKILL.md 文件的目录，该文件有一定的规范，比如必须以包含元数据（如name和description）的 YAML 前置内容开头等等。 Agent Skills 通过分层加载信息来高效管理上下文窗口： 第一层: Agent 在启动时仅加载所有已安装 Skill 的name 和 description，以便知道何时使用某个 Skill。 第二层: 当 Agent 认为某个 Skill 与当前任务相关时，它会读取该技能的 SKILL.md 文件的完整内容。 第三层及以上: 对于更复杂的任务，技能可以包含额外的辅助文件（如 reference.md 或脚本）。Agent 只在需要时才会读取这些文件，这个意思基本就是 Skills 可以包含几乎无限的上下文信息。 Skill 中可以包含预先编写好的固定的代码（如 Python 脚本）。Agent 可以像使用工具一样执行这些代码，以处理传统代码更擅长的确定性或高效率的任务，而不需要把代码本身加载到上下文中。 这个的好处很明显，把AI 生成的质量不稳定的代码变成稳定可控的代码，既大大缩小上下文，也节省了很多成本。 这篇文章中也举了两个 Skills 的典型应用例子： 通过AI 生成的代码来对列表进行排序，远比简单地运行一个排序算法要昂贵得多。除了效率问题，许多应用还需要只有代码才能提供的确定性可靠性。 PDF Skills 包含一个预先编写的 Python 脚本，用于读取 PDF 并提取所有表单字段。Claude 可以在不将脚本或 PDF 加载到上下文的情况下运行此脚本。而且由于代码是确定性的，这个工作流程是一致且可重复的。...

本文是 Anthropic AI 研究院 Julian Schrittwieser 所写，其主要观点是当前公众和许多评论员未能认识到人工智能（AI）正处于指数级增长阶段。人们常常因为当前 AI 模型的局限性而错误地断定其发展已停滞或影响有限，而忽略了其能力在极短时间内取得的飞跃式进步。 主要观点 普遍的误解：人们普遍低估了 AI 发展的指数级速度。他们关注于当前 AI 模型的错误和不完美之处，从而得出其发展已达瓶颈的错误结论，而忽视了其背后持续且迅速的能力增长趋势。 指数级增长是现实：作者引用多项研究证明，AI 在软件工程和跨行业通用任务上的能力正遵循着清晰的指数级增长曲线，并且这种趋势没有放缓的迹象。 未来预测：基于当前的发展趋势进行推断，AI 将在未来几年内对经济产生颠覆性影响。作者预测，到 2026 年中，AI 将能自主完成长达 8 小时的工作任务，并在 2026 年底在多个行业中达到人类专家的水平。 关键细节 METR 研究： 一项名为 “Measuring AI Ability to Complete Long Tasks” 的研究，专注于衡量 AI 模型自主完成软件工程任务的能力。 研究结果显示出一条明显的指数增长曲线，能力的“倍增”周期约为 7 个月。 最新的模型如 Grok 4、Opus 4.1 和 GPT-5 的表现不仅验证了这一趋势，甚至略高于预期，已能处理超过 2 小时的任务。 GDPval 评估： 由 OpenAI 发起，旨在评估 AI 在更广泛经济领域中的应用能力，涵盖了 9 个行业的 44 个职业。 评估任务由平均拥有 14 年经验的行业专家提供，总计 1320 项任务。 结果再次显示了类似的增长趋势。值得注意的是，Claude Opus 4....