Anthropic

本文由 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....

Anthropic 的 Cat Wu (Claude Code) 和 Alex Albert (Claude Relations) 讨论了 Claude Code 团队如何对新功能进行原型设计，使用 Claude Code SDK 的最佳实践，以及在与开发人员一起构建我们的代理式编码解决方案过程中学到的其他经验。本文整理自对此讨论，带你 5 分钟了解这篇访谈的精华。 你有没有想过，当一群顶尖的AI工程师为自己打造一款编程工具时，会发生什么？答案是：迭代速度快得惊人，而且会催生出一些开发者社区独有的“黑话”，比如“Multi-Clauding”（多开Claude）。 最近，Anthropic 的 Claude Relations 负责人 Alex 和 Claude Code 产品经理 Cat 坐下来聊了聊，揭开了这款炙手可热的AI编程工具背后的故事。从团队内部的开发流程，到用户五花八门的使用姿势，再到未来人人都能构建专属智能体（Agent）的蓝图，信息量非常大。 迭代的秘诀：先让内部员工“嗨”起来 你有没有觉得，Claude Code 好像总是在更新？每次在终端里打开它，似乎都有新功能冒出来。这种“疯狂”的交付速度背后，藏着一套非常独特的开发哲学。 Cat 解释说，Claude Code 团队里全是些产品嗅觉敏锐的工程师。很多新功能的诞生，不是来自冗长的产品需求文档，而是源于一个简单的念头：“嘿，如果有个功能能帮我做……就太酷了。” 接下来会发生什么？他们不会去写文档，而是直接用 Claude Code 把这个功能的原型给做出来。 “用 Claude Code 做原型太快了，所以大部分时候，大家干脆跳过文档，直接动手。” 这个原型会立刻在公司内部发布，让所有 Anthropic 的员工（他们亲切地称自己为“Ants”）来试用。如果大家用得不亦乐乎，反馈特别积极，那它就达到了上线的标准，因为这强烈预示着外部用户也会喜欢它。 这就是他们的“吃狗粮”（Dogfooding）闭环——产品好不好，自己人先用个爽。这种方式不仅快，而且非常有效，因为开发者最懂开发者。 一种工具，N种玩法：从创业公司到世界500强 Claude Code 的一个神奇之处在于，它的上手体验极其顺滑。无论你是单打独斗的独立开发者，还是财富500强企业里的工程师，只需要一个 npm install 命令，几乎无需任何配置，它就能立刻投入工作。因为它能直接访问你本地的文件和工具，让你对它的能力范围有个非常清晰的认知。 有趣的是，不同规模的团队，渐渐玩出了完全不同的花样。 创业公司的玩法：放手去做与“Multi-Clauding” 小公司的工程师们更喜欢让 Claude “放飞自我”。他们会开启 auto-accept mode（自动接受模式），让 Claude 自主修改代码，无需每次都手动确认。...

本文来自于 YC 组织的一场圆桌论坛，本期节目的嘉宾是 Anthropic 联合创始人 Tom Brown：构建 Claude 代码，来自 GPT-3 和大语言模型系统设计的经验。以下是视频精华。 在AI的世界里，Anthropic的联合创始人Tom Brown是一个传奇人物。他的职业轨迹几乎贯穿了本轮AI浪潮的所有关键节点：从早期Y Combinator的创业生态，到OpenAI的核心团队，再到创立与OpenAI分庭抗礼的Anthropic。 但在风光背后，他的故事充满了自我怀疑、艰难抉择和一些出人意料的转折。这不仅仅是一个技术天才的成长史，更是一部关于如何从被动接受任务的“家犬”，进化成主动出击、为生存而战的“野狼”的真实写照。 告别安逸：“宁为野狼，不作懒犬” 故事的起点在2009年，刚从MIT毕业的Tom Brown，只有21岁。他没有选择去大公司当一颗螺丝钉，而是加入了朋友的初创公司，成了第一名员工。 “如果我去大公司，或许能学到更扎实的软件工程技能，”Tom回忆道，“但在初创公司，一切都得自己想办法。公司默认的结局就是死亡，我们必须像狼一样出去捕猎，否则就会饿死。” 这个比喻深深烙印在了他的职业生涯中。在学校，他习惯了老师布置任务、自己完成任务的模式，就像一只等着主人喂食的狗。而创业，则把他彻底变成了一匹必须在荒野中寻找食物的狼。这种“野狼心态”——主动寻找问题、解决问题，并为结果负全责——成了他日后成就一番事业最宝贵的财富。 他的早期创业并不总是一帆风顺。他曾和朋友一起创办过一个叫Solid Stage的DevOps公司，在Docker还没诞生的年代，他们的想法（一个更灵活的Heroku）太过超前，连自己都讲不清楚到底要做什么。在YC面试时，面试官甚至在白板上画了一个愤怒的皱眉脸，追问他们：“你们到底要构建什么？” 从约会App到AI：一次关键的“朋友圈”连接 离开那家创业公司后，Tom加入了一款名为Grouper的约会App。这在今天看来似乎是一个奇怪的职业选择，但对他个人而言却意义重大。 “我以前是个特别腼腆内向的小孩，”Tom坦诚地说，“Grouper的模式是三个男生和三个女生一起在一个酒吧见面，这让我觉得很安全，可以带着朋友一起去认识新朋友。”他想做的，就是为像他一样不善社交的人创造机会。 有趣的是，Grouper的用户中有一个超级粉丝——Greg Brockman（后来的OpenAI联合创始人兼总裁）。他几乎每周都会在公司的聊天群里吆喝大家一起去参加Grouper的活动。这层看似不经意的联系，为Tom日后进入AI领域埋下了关键的伏笔。 Grouper最终没能走下去，因为Tinder横空出世，用一种更高效的方式解决了同样的“社交破冰”问题。这段经历让Tom再次认识到市场的残酷，也让他陷入了一段职业倦怠期。他花了三个月时间去玩乐、放松，甚至造了一辆艺术车，直到把钱花光。 投身AI：一个“线性代数B-”学生的豪赌 2014年，Tom做出了一个改变人生的决定：转向AI研究。当时，这在很多人看来是个“奇怪又糟糕”的选择。 “我的朋友们觉得这事不靠谱，就像在担心火星上人口过剩一样遥远，”他笑着说，“他们甚至怀疑我到底行不行。” 这种怀疑并非空穴来风。Tom坦言自己大学时“线性代数只拿了B-，甚至可能是C+”。在那个年代，AI研究被认为是顶尖数学天才的专属领域。他感到巨大的不确定性，犹豫了整整六个月。 最终，他还是决定赌一把。为了获得进入这个领域的门票（当时主要是DeepMind和Google Brain），他制定了一个为期六个月的自学计划： 在Coursera上学习机器学习课程 参加Kaggle竞赛项目练手 重读《线性代数应该这样学》（Linear Algebra Done Right） 啃下一本统计学教科书 用YC校友福利买来的GPU，远程SSH进去跑代码 当OpenAI成立的消息传出时，他立刻联系了老朋友Greg Brockman，谦卑地表示：“我线性代数成绩不好，但我懂点分布式系统。如果需要，我愿意去拖地。” 正是这种谦逊和他在系统工程方面的经验，让他拿到了OpenAI的入场券。他最初的工作甚至和机器学习无关，而是为《星际争霸》项目构建游戏环境。 OpenAI岁月与“规模法则”的启示 在OpenAI，Tom亲身参与了从GPT-2到GPT-3的飞跃。这期间，一个关键的洞见改变了一切——规模法则（Scaling Laws）。 时任OpenAI研究副总裁的Dario Amodei（后来的Anthropic CEO）团队发现，只要用正确的配方，投入越多的计算资源，就能稳定地获得更强的智能。 “那篇论文里的图表，一条笔直的线贯穿了12个数量级，”Tom至今仍感到震撼，“12个数量级！我从没见过任何东西能有这么夸张的跨度。这让我确信，AI的未来就在于规模化。” 当时，学术界很多人对此不屑一顾，认为这只是“堆硬件、堆数据”的笨办法，不够优雅。但Tom和他的同事们坚信，这就是那个“能奏效的笨办法”。 创立Anthropic：从“不被看好”到行业颠覆者 坚信规模法则的威力，也让他们对AI安全产生了更深的忧虑。Tom和Dario等人认为，人类正处在一个将控制权交给AI的临界点，必须建立一个能承载这份沉重责任的机构。 于是，他们选择离开OpenAI，创立了Anthropic。 “刚开始，我们看起来一点都不像会成功的样子，”Tom回忆道，“OpenAI有十亿美元资金和全明星阵容，而我们只有七个创始人在疫情期间远程协作，连要做什么产品都还没想清楚。” 但正是这种 underdog 的处境，吸引了一批真正为使命而来的早期员工。他们本可以留在OpenAI享受更高的声望和薪水，却选择了一条更不确定的路。这个纯粹由使命驱动的早期团队，为Anthropic日后的快速发展奠定了坚实的文化基础。 Anthropic的崛起并非一帆风顺。在ChatGPT引爆全球之前，他们只做了一个内部使用的Slack机器人。他们犹豫着是否要公开发布，因为不确定这是否对世界有益，也缺乏相应的服务基础设施。 直到2024年，随着Claude 3.5 Sonnet的发布，局面才彻底扭转。YC的创业公司几乎在一夜之间，将编码任务的首选模型从OpenAI转向了Anthropic。 Claude的“X因素”：把模型当成用户 为什么Claude在编码等任务上表现如此出色，甚至超出了基准测试的预期？Tom揭示了一个令人意外的秘密。 “我们没有专门的团队去‘应试’，也就是针对公开的基准测试进行优化，”他解释道，“我们更关注内部的、更真实的评估体系，以及我们工程师自己的使用体验（Dogfooding）。” 但更深层次的原因，可能是一种思维模式的转变——把Claude本身看作是一个用户。 “当我们开发Claude Code时，我们不仅仅是为开发者构建工具，更是在为Claude构建工具，”Tom说，“我们思考的是，Claude需要什么样的上下文？它需要什么样的工具才能更高效地工作？我们团队对Claude这个‘用户’有更深的同理心。”...