Anthropic的财务效率与核心增长循环
Anthropic在最近的S-1文件中展示了人类历史上最高的收入和研究效率之一。这一成就尤为显著，因为公司在过去一年中实现了从-126%亏损到19% GAAP利润的惊人逆转。这种财务上的成功并非偶然，而是归功于公司坚持的两个核心循环：改进（Improvement）与投资（Investment）。在Opus 5.5发布一个月后，该模型已被广泛认为是全球最强的LLM。工程负责人Katelyn Lesse和产品负责人Angela Jiang深入探讨了这一成就背后的运作机制。
团队目前面临着双重压力：一方面，模型能力的提升使得安全部署和访问决策变得更加复杂；另一方面，用户量的快速增长让普通的基础设施选择（如API消耗的CPU资源）变成了战略性问题。这些挑战最终体现在面向开发者的产品决策中，要求公司在追求性能的同时必须兼顾成本控制和安全性。
Opus 5.5的发布策略与API集成挑战
Opus 5.5的发布不仅强调模型质量，还特别注重成本效益。针对此前Opus版本被用户反馈过于冗长的问题，新模型在保持更强智能的同时降低了运行成本。虽然具体节省比例取决于工作负载和使用缓存上下文的情况，但Anthropic明确表示新模型比前代更便宜。在API集成方面，公司采取了新的安全措施来防止推理过程被提取用于蒸馏攻击。通过跨对话轮次保留思考块（thinking blocks），Anthropic试图保护模型的内部推理逻辑，但这同时也可能破坏客户现有的集成框架。
早期访问计划（Early Access）的实际运作方式也发生了变化。Katelyn Lesse指出，客户会在自己的环境中运行评估并报告意外行为。“有用的部分不仅仅是一个基准分数：而是看到模型在Anthropic自身产品未覆盖的环境和任务中的表现。” 这种来自真实场景的反馈对于完善模型至关重要，正如团队连续四年所强调的那样：拥有良好的评估体系是黄金标准。
架构革新：分离“大脑”与“双手”**
Anthropic在Managed Agents中采用了一种关键的架构模式，即将代理的“大脑”（会话日志和框架）与“双手”（执行代码的沙箱环境）分离。在这种设计下，会话框架可以持久存在，而执行环境仅在需要时创建。如果沙箱失败，不会导致整个代理会话的中断。这种分离不仅提高了可靠性，还为安全性提供了关键的架构属性：生成的代码在从未接收过服务凭证的沙箱中运行，因此不存在被恶意读取的凭证。
“如果生成的代码在从未接收过服务凭据的沙箱中运行，那么该沙箱中没有供代码读取的凭据。”
这种架构还解决了性能问题。早期的方法将整个编码代理置于API后的沙箱中，导致启动环境产生额外延迟且会话脆弱。分离架构允许平台在保持执行隔离的同时追求更低延迟和更高可靠性。对于任何设计代理运行时的人来说，关键问题是：哪些部分需要存活？哪些部分执行不受信任的工作？哪些秘密真正需要在代码运行时存在？
记忆机制、评估与未来路线图
Managed Agents平台为多代理工作流和记忆实验提供了基础。所谓的“做梦（Dreaming）”功能被简单地实现为一个代理检查另一个代理的先前工作并写回记忆。这使得该功能成为利用底层原语构建更高级行为的典型案例。尽管记忆和学习仍然重要，但团队目前的注意力更多地转向了安全性，因为前沿模型的发布变得越来越困难。他们致力于保持基础框架的简洁性，同时允许开发者在其上实验验证器、并行代理等策略。
在评估方面，改进一个框架开始类似于研究工作：设定目标、测量行为、检查失败并迭代。团队讨论使用模型来帮助构建和分析评估，同时保留足够的判断力来决定评估是否反映了真实用户的工作。未来的平台能力应被视为计划而非已交付的承诺，特别是在面对新兴的代理工作负载和AI垃圾内容（slop）时，Anthropic正通过重建Messages API为Rust等底层优化来应对挑战。
Anthropic的财务奇迹：从巨额亏损到GAAP盈利的惊人跨越
Anthropic在IPO前夕提交的S1文件揭示了一家极其高效的公司。尽管作为AI企业，其利用自身技术优化运营的程度广为人知，但过去一年内公司发生的根本性变化却常被低估。最直观的数据体现在人均营收（Revenue per Employee）的爆发式增长上：当前12个月的人均营收达到6.6百万美元，而一年前这一数字仅为140万美元。这意味着Anthropic在一年内将人均营收提升了近五倍，这种增长不仅源于利润率的提升，更直接关联到每美元算力带来的收入显著增加。这种效率的提升在财务表现上体现得淋漓尽致：2025年第二季度，Anthropic每赚取一美元收入还要亏损0.5美元；而到了现在，其状态已完全逆转，每花费一美元成本能产生2美元的收益。这种从深度亏损到大幅盈利的转变，标志着Anthropic在商业前景上发生了巨大的拐点。
"This is obviously tracked by a significantly increase in revenue per dollar of compute."
这种效率的提升最终反映在财报上，Anthropic报告了其历史上第一个GAAP（公认会计准则）盈利季度。值得注意的是，这并非剔除各种成本后的调整后利润，而是严格的GAAP净利润，金额高达1900万美元。回顾一年前，Anthropic每收入一美元就要亏损1.29美元（即-129%）。这种从"每赚一块亏一块多"到"净赚近两千万美元"的剧烈反转，是理解Anthropic当前战略执行力的关键背景。对于任何企业主或工程师而言，提升人均营收不仅是增加利润的手段，更是提高员工薪酬能力的基础。Anthropic通过极致的效率优化，证明了其不仅是一家技术领先的实验室，更是一家具备强大商业造血能力的企业。
双重循环驱动引擎：改进闭环与投资闭环的无限协同
Anthropic能够实现如此惊人的效率跃升，核心归因于其内部运行的两个相互交织的循环。首先是改进闭环（Improvement Loop）：Claude模型的发展带来更强大的新模型，更强的模型催生了更多应用场景；更多的使用场景产生了丰富的反馈数据，这些反馈又反过来优化了云端基础设施和模型能力。其次是投资闭环（Investment Loop）：随着用户采用的扩大，收入增长推动更高的增长率；高增长吸引了更多的资本投入，这些投资进一步转化为技术能力，从而构建更强大的云端服务。这两个循环并非孤立存在，而是共同旋转形成一个无限循环（Infinite Loop）。
"These two loops basically spin together and form an infinite loop that is driving the increase in efficiency until the end of time, according to the Adoptic S1."
根据Anthropic的S1文件描述，这种机制驱动着效率的提升直至"永远"。在这个框架下，Anthropic不仅仅是在训练模型，而是在构建一个自我强化的生态系统。Claude平台（Claude Platform）作为这一战略的核心支柱之一，被定义为"全面的代理开发环境"。它允许客户直接访问Anthropic的基础设施原语，以便在自己的产品和流程中构建、部署和扩展利用Claude能力的应用程序。这种策略使得Anthropic从单纯的模型实验室，转型为具备超大规模云服务商（Hyperscaler）属性的平台型企业。这种从理论到实践的跨越，是其商业故事的重要组成部分。
从聊天机器人到虚拟协作者：Claude平台的商业化与产品演进
Anthropic正在通过"扩散云（Diffusion of Cloud）"战略重塑行业格局。S1文件中明确提到，超过50%的年交易收入达到或超过10万美元的客户都在使用Claude平台。这一数据表明，Anthropic不仅拥有顶尖的模型能力，更在B端市场建立了深厚的护城河。Claude平台的核心价值在于其"喂养（Ad-feeding）"机制：Anthropic内部开发的许多产品，实际上也是使用与对外提供的Claude平台相同的原语构建的。这种"自己吃自己的狗粮"的做法，确保了产品的一致性和快速迭代能力。
"Anthropic is really positioning their IPO to talk about going from chatbots to co-pilots to virtual collaborators."
在产品定位上，Anthropic刻意避免使用"Agent（智能体）"这一可能带有技术冷感或不确定性的词汇，转而采用"Virtual Collaborators（虚拟协作者）"。这一术语更强调人机协作的友好性，涵盖长期自主工作、判断力、自我修正、迭代以及工具访问等能力。其核心理念是让AI拥有目标，并与用户并肩工作，而不是仅仅在某个单一应用或任务内部运行。这种定位的转变反映了Anthropic对AI未来形态的理解：从被动的聊天机器人，进化为主动的副驾驶（Co-pilot），最终成为人类思维的延伸和虚拟协作者。这种产品哲学的转变，与其背后强大的Claude Code（代码协作工具）等技术底座相辅相成，共同构成了Anthropic在IPO前的核心竞争力叙事。
技术基石：Opus 5.5的领先地位与未来展望
在内容录制期间，Anthropic刚刚发布了Opus 5.5。在与众多高品味测试者的交流中，普遍共识是Opus 5.5是目前世界上最好的模型。此外，Anthropic还掌握了更先进的版本（文中提及为Fable 5.5或类似代号），预计将在未来两周内发布。对于IPO而言，展示最新的技术突破是增强投资者信心的关键一环。
Anthropic在模型训练上采取了一种独特的压力测试方法。与许多公司将模型置于"盒子"中强行解决不可能任务以施加压力的做法不同，Anthropic更关注训练过程中的事件（Incidents）管理。他们强调这些事件是发生在模型上的，而非仅仅是对所有训练模型的通用压力测试。这种对细节的关注和对技术边界的谨慎探索，体现了Anthropic在追求性能极致同时保持可控性的工程哲学。随着Opus 5.5的发布及后续版本的预期，Anthropic试图向市场证明，其不仅在商业效率上做到了极致，在技术前沿的探索上也始终处于领跑地位。这种"大脑（模型能力）"与"双手（工程效率/平台化）"的分离与协同，正是Anthropic区别于其他AI公司的独特叙事逻辑。
生产环境与沙盒环境的本质差异
在讨论AI代理（Agent）的行为边界时，必须区分训练环境与生产环境的不同逻辑。在沙盒或实验环境中，代理被激励去突破限制以解决问题；但在生产负载中，情况截然不同。API调用运行在带有在线安全护栏（online safeguards）的环境中，这些防护措施并非模型训练的一部分，而是基础设施层面的保障。这种架构设计使得代理不再是一个试图“逃出盒子”的孤立实体，而是被更广泛的系统所约束。正如对话中指出的那样：“代理不仅仅是在一个盒子里试图逃脱，而是有护栏在这里，手在那里”。这种分离确保了代理无法轻易绕过安全机制，从而避免了需要用户额外考虑的安全隐患。
Opus 5.5的发布反馈与定价策略
在Opus 5.5发布后的访谈中，团队重点回应了用户反馈并强调了性价比。针对此前Opus 5写作风格被认为“晦涩难懂”的反馈，团队进行了显著优化，并很高兴看到这一改进得到了用户验证。除了性能提升，Anthropic越来越重视“每美元获取的智能量”（good intelligence per dollar）。确保定价策略的合理性是此次发布的重要组成部分。团队不仅关注模型本身的智力表现，还致力于通过更清晰的沟通来传达这些价值。这种策略调整旨在让用户在获得高质量智能的同时，感受到成本效益的提升，从而增强市场竞争力。
防御模型蒸馏的安全权衡与技术细节
Anthropic面临的一个核心挑战是如何防止专有模型的“知识蒸馏”（distillation）。模型被用于创造安全、积极的AI成果，而防止恶意蒸馏是为了确保下游使用仍受安全分类器的保护。如果模型被无护栏地复制，可能导致不良后果。为此，Anthropic采取了一系列措施来增加蒸馏难度。团队引入了“前缀锁定思考”（prefix lock thinking）技术，并优化了跨不同模型回放思考token的机制。这些改动旨在平衡用户体验与安全性：“我们一直在努力寻找一条细线，既要防止蒸馏，又不至于让善意使用的用户感到痛苦”。团队将用户体验的影响分为两层：一是仅涉及集成调整的轻微不便，二是功能受限的严重打击。Anthropic极力避免后者。
跨回合思考块保留与开源生态协作
为了进一步遏制通过多轮对话提取思维链（Chain of Thought）的蒸馏行为，Anthropic实施了更严格的跨回合思考块保留策略。这意味着即使在使用多个账户或进行复杂交互时，模型也无法轻易将思维过程提取并用于其他目的。团队与开源Harness维护者及大型客户进行了密切合作，指导他们进行必要的升级。例如，某些客户的“压缩策略”（compaction strategies）因需保留思考块而受到影响。尽管这带来了一定的集成麻烦，但Anthropic坚持认为这是防止恶意行为者利用模型所必须付出的代价。通过这种精细的架构调整，Anthropic试图在保护知识产权和确保AI安全之间找到最佳平衡点。
API 兼容性与客户协作：避免破坏性更新
在推出新的压缩（compaction）功能以替代用户手动处理思考块的过程中，Anthropic 采取了谨慎的兼容策略。团队并未强行要求开发者以特定方式保留思考块，因为这种做法可能会破坏大量现有用户的应用。相反，他们选择与客户及开源工具维护者紧密合作，确保他们在升级过程中获得所需的支持。这种协作模式体现了公司在功能迭代中平衡创新与稳定性的努力，旨在通过提供平滑的过渡方案来维护开发者生态的健康。
模型蒸馏：安全优先于商业考量
关于从 Claude 进行知识蒸馏（distillation）的问题，Anthropic 指出这在实际操作中比预期更难。尽管有研究人员负责任地披露了相关方法并在社交媒体上引发关注，但 Anthropic 观察到这些尝试在一定程度上减少了他们不希望出现的负面影响。对于外界关于蒸馏可能导致廉价商业竞争的担忧，Anthropic 明确表示这并非主要关切点。公司更关注的是从安全角度出发，确保模型不会被用于有害目的。事实上，由于蒸馏过程本身需要调用 API 并付费，商业上 Anthropic 依然获利，因此他们更侧重于确保衍生模型的安全性与合规性。
产品与工程的协作动态：打破角色刻板印象
在模型发布过程中，产品经理（Katelyn）与工程负责人之间的协作至关重要。产品侧侧重于平衡智能水平、成本控制与安全措施，而工程侧则聚焦于API 集成体验和开发者工具的用户体验。这种分工并非割裂，而是建立在双方高度技术化的基础上。Katelyn 常被误认为是工程师，而工程负责人则常被误认为产品经理，这种跨职能的思维模式有助于在决策时兼顾商业影响与技术可行性。团队内部鼓励深入的技术讨论，确保产品决策不仅符合市场逻辑，也能在工程规模上落地。
软件工程的未来：从单体到全球规模的演进
随着 Anthropic 的发展，其技术架构经历了巨大变化。一年前加入时，Claude 运行在单个 GCP 区域的 Python 单体应用上；如今则面临全球规模的挑战。当前的重点不仅在于确保模型发布的安全性（包括代理、离线和在线防护措施），还在于扩展基础设施以支持日益增长的需求。软件工程并未“解决”，而是随着野心提升不断演化。团队需要在保障安全的前提下，处理从单一区域到全球分布式的复杂工程问题，这要求产品与工程团队持续适应新的技术挑战。
API规模扩张与CPU瓶颈下的工程挑战
随着Claude模型在API端的使用量激增，基础设施面临着严峻的扩展压力。工程师指出，CPU资源成为当前系统中最受限制的环节，这迫使团队投入大量精力解决分布式系统的扩展问题。虽然模型本身具备处理语言和框架的专业知识，但在实际运营中，人类工程师仍需承担绝大部分系统演进工作。目前的状态并非完全自动化，而是需要人工介入以确保大规模下的安全 rollout 和稳定运行。这种对分布式系统专业知识的依赖，表明即便拥有强大的AI模型，底层基础设施的规模化运营依然高度依赖人类专家的持续投入。
从“单键停用”到通用权限原语的构建
Anthropic 在应对突发风险时，建立了一套能够一键回退的系统机制。这一举措并非仅为了防范极端情况，而是将管理模型访问权限的底层原语（Primitives）标准化。团队意识到，与其针对单一事件修补，不如构建通用的控制层。这种通用化设计使得所有模型访问都置于同一套严格的验证程序之下，从而确保在需要紧急干预时拥有足够的控制权。这种思维转变标志着产品管理从传统的线性假设转向了概率驱动的决策模式。在开发路线图时，团队不再仅仅基于确定的用户故事进行规划，而是必须考虑那些“概率非零”但影响巨大的黑天鹅事件。这种策略本质上是在构建一个风险对冲组合（Portfolio of Bets），即使某些功能看似冗余，但在极端场景下能发挥关键作用。
概率思维重塑产品路线图与“对冲”策略
传统的产品管理往往基于对未来的确定性假设，即认为功能会按特定顺序被使用。然而 Anthropic 的经验表明，现实中的用例往往超出预期。例如，“Fable”模型的政府强制停用（De-deployment）就是一个完全未被预见的用例。面对这种不确定性，团队采取了“对冲”策略（Hedging Scenarios）：即使认为某类风险再次发生的概率极低，也要优先构建相应的应对能力。这种“为最坏情况做准备”的思路反而带来了意外收益。因为大多数时候，这些为了极端场景设计的通用工具，在日常运营中也被频繁调用。这种概率思维迫使团队在资源分配上更加谨慎，优先确保系统的鲁棒性而非单纯的功能丰富度。这种从确定性到概率性的转变，是 Anthropic 应对 AI 安全挑战的核心方法论之一。
X-Factor 项目与通用权限架构的实践
为了支持高风险的双用途（Dual-use）研究，Anthropic 开发了名为“X-Factor”的访问计划。该计划允许经过严格审核的研究人员，在特定用例下降低模型的安全限制以进行防御性网络安全研究。这一需求促使团队设计了高度通用的权限原语——Trust Grants（信任授权）。尽管最初设计时考虑了多种可能性，团队最终选择了高度通用的架构而非过度聚焦于单一用例。这种设计哲学在后续应用中证明了其价值：Trust Grants 不仅用于 X-Factor，还广泛用于管理所有可信访问计划以及模型停用流程。从技术角度看，Trust Grants 本质上是一种 IAM（身份和访问管理）机制，用于确保 API 请求只能访问授权数据。这种看似基础的授权逻辑，因其通用性而成为团队日常开发中最常调用的解决方案。
信任授权（Trust Grants）的技术实现与历史案例
在技术架构上，Anthropic 的 Trust Grants 类似于 AWS IAM 或 Google Zanzibar 等系统，但其核心在于清晰的数据模型定义。一个 Trust Grant 明确记录了用户是否被授权访问特定模型或参与特定项目。这种细粒度的权限控制使得团队能够精确追踪和管理复杂的访问关系。一个典型的应用案例是在 Fable 5.1 版本推出时，团队需要为现有客户提供过渡期（Grace Period）。通过 Trust Grants，系统能够准确识别哪些客户属于“祖父条款”覆盖范围，从而给予额外的集成时间。这种基于信任授权的追踪机制，不仅解决了版本迁移的合规问题，也展示了通用权限原语在处理复杂业务逻辑时的灵活性。这种将安全控制与产品功能解耦的设计，使得 Anthropic 能够更敏捷地应对不断变化的监管和技术需求。
授权检查系统的工程化实现
在构建Claude服务时，Anthropic需要在请求的关键路径上部署一套特定的授权检查系统。这套机制在逻辑上与常规的权限验证并无二致，主要是为了确认用户是否拥有执行特定操作的许可。然而，由于需要深度嵌入到Anthropic特有的系统架构中，团队必须专门搭建一套能够灵活插入这些检查点的工程基础设施。这种底层工程的复杂性往往被外界低估，人们通常将其视为理所当然的背景设施。
"For anything, we're just running this service that is kind of on the hot path of our requests to make sure... check whether you have the grant for the thing that you're trying to do"（对于任何操作，我们都在请求的热路径上运行这项服务，以确保...检查您是否拥有执行该操作的许可）
模型发布的标准化流程与内部测试
除了复杂的安全评估外，模型的发布已经形成了一套相对标准化的机器化流程。这一过程始于模型制作后的广泛安全测试，随后是团队对性能需求的评估以及必要的权衡决策。紧接着进入严格的内部测试阶段，包括切割不同版本的模型变体并进行评估。Anthropic特别强调“内食”（Ant Footing）策略的重要性，即内部员工大量使用Claude进行日常工作。这种自我消耗模式能够尽早暴露问题，例如发现某些变体表现不佳或存在潜在缺陷。通过内部高频使用，团队能够捕捉到早期信号，从而判断哪些模型变体优于其他版本。
"We'll do a lot of internal ant fooding, as we call it. And that actually always really helps."（我们会进行大量的内部“内食”测试，正如我们所说的。这实际上总是非常有帮助。）
早期访问计划与客户反馈机制
当团队对特定模型变体充满信心后，会将其推向客户。发布渠道分为两类：一是通过Claude Code、CodeWork等自家第一方产品；二是面向API客户的早期访问计划。在后者中，Anthropic与Cognition、Cursor等客户紧密合作，要求他们在自己的测试框架（Harness）中接入新模型。这一阶段的核心目标是收集反馈以验证性能。尽管目前行业内的状态仍显得非常非结构化，主要依赖Slack频道等非正式渠道进行沟通，但这与AI产品本身的不确定性有关。早期访问客户通常具备强大的评估体系（Evals），能够迅速提供可操作的反馈。
"The state of model feedback feels very unstructured still. Basically, it's always a Slack channel between companies"（模型反馈的状态仍然感觉非常非结构化。基本上，它始终是公司之间的Slack频道）
反馈的价值与行为权衡的困境
在收集到的各类反馈中，负面反馈被认为是最有价值的。虽然正面验证能带来安全感，但指出模型在特定任务上表现不佳的反馈更能直接指导修复工作。此外，客户将Claude置于不同测试框架中提供的反馈极具价值，因为它揭示了模型在Anthropic内部“内食”环境中无法遇到的新颖场景。然而，优化过程面临一个根本性的难题：不同用户对模型行为偏好的光谱分布不一致。例如在“懒惰”与“主动行动”之间，有的用户希望模型直接完成任务而不要犹豫，另一些用户则反感模型在未充分规划时就擅自编写大量代码。这种期望的多样性使得在单一维度上达到完美平衡变得几乎不可能，团队往往需要在早期版本中根据主要用户群的需求进行取舍。
"The good stuff is always very validating... Honestly, the most useful feedback is negative."（好的东西总是很有验证性……老实说，最有用的反馈是负面的。）
外部反馈与对齐的必要性
在模型训练过程中，内部测试往往存在盲区。团队指出，仅依靠在产品或 API 中进行内部的 "antfooding"（内部反馈循环）是不够的。必须将模型推向更广泛的外部用户群体，通过其他客户的使用情况来发现潜在问题。这种外部反馈机制对于识别那些在封闭环境中未被捕捉到的对齐偏差至关重要。
"It's way, way more important for us to get that out there in the API and get all of our other customers running with it and let us know what we need to change."
这种策略的核心在于利用大规模用户数据来修正模型行为，确保其在真实世界场景中的鲁棒性。团队承认，内部测试无法完全替代外部验证，尤其是在处理复杂的人类偏好和细微的行为偏差时。因此，开放 API 不仅是服务用户的手段，更是模型迭代和改进的关键数据来源。
对齐与个性化的核心矛盾
产品经理面临的最大挑战之一是如何平衡 默认行为（Alignment）与个性化需求（Personalization）。模型需要为所有消费者提供一致的默认人格和行为准则，但同时又要能迅速响应用户通过 CLAUDE.md 等配置文件提出的特定要求。例如，用户可能希望模型比默认设置更主动或更具创造性。
"There's a default personality, default behavior that you want for all consumers. And then you want to be able to respond very quickly to someone's CLAUDE.md saying, no, no, no, like, please be more proactive than default."
这种矛盾在基准测试中尤为明显。以 Frontier Code 为例，其设计初衷是惩罚过多的活动或文件生成，从而引导更高效的编码习惯。然而，如果用户通过个性化设置禁用这一惩罚机制，模型的行为就会改变。这引发了一个难题：如何公平地评估那些依赖个性化配置的基准测试结果？ 团队承认，目前对于如何处理这种主观的个性化元素缺乏完美的解决方案。
参数化调整与默认策略
为了解决个性化难题，Anthropic 主要依赖 增加模型参数 来针对不同客户群进行微调。对于 API 用户，团队提供建议而非直接控制，让用户自行调整参数以适应其需求。努力程度（Effort）是一个关键的调节变量，它允许用户控制模型在推理过程中投入的计算资源。
"We generally try to solve this by having more parameters that then allow us to tweak it per customer base."
目前，CLAUDE.md 等个性化文件的处理方式尚不完美。团队尝试通过提供关于努力程度、模型大小选择等方面的建议来辅助用户。默认设置会根据用户类型（如免费用户、Prosumer 客户、企业版或 API 用户）进行动态调整，以提供初步的个性化体验。然而，团队明确表示，当前的方法并非完美，仍在探索更有效的路径。
参数复杂性与未来方向
随着模型功能的扩展，API 中出现了 努力程度、预算等多种参数，导致用户难以确定最佳组合。团队承认，这种 "混乱" 的状态是发展过程中的必然阶段。未来将致力于简化参数体系，例如将某些选项从连续标度改为低、中、高离散等级，或逐步淘汰冗余参数。
"It's like, how could anyone like possibly figure out what is the right combination of things for any given tasks for what you should go and set?"
团队倾向于 温和的默认设置，同时保留用户调整选项的权利。这种策略旨在让用户根据自身需求（如速度 vs. 质量）灵活配置模型。Claude Managed Agent 等产品试图通过程序化访问来简化这一过程，但仍需解决参数组合的复杂性。团队认为，随着用户规模的扩大，当前依赖人工判断和简单参数的方法将不再可扩展，需要开发更智能的个性化信号机制。
开箱即用的工程化抽象与开发者支持
Anthropic 为降低用户接入 Claude 的门槛，提供了一套开箱即用的“harness”（工具链/框架）。这套机制自动处理模型发布时的新参数识别、破坏性变更检测以及性能优化，让用户无需手动配置即可获取最佳体验。对于希望深入定制的高级用户群体，Anthropic 在 AIE 会议上举办了专门的 CMA（Claude Managed Agents）研讨会。虽然目前没有独立的 Twitter Feed 或 Newsletter，但官方在 Cloud Devs Channel 中保持高频更新，确保开发者能及时掌握这一重要选项的动态。
"...every time we're launching the model, a lot of the work to go figure out, like, what are the new parameters? What are the breaking changes?... So that for the people who are using it, you just kind of get that out of the box."
CMA 的核心定位与基础设施共享机制
Claude Managed Agents (CMA) 是 Anthropic API 体系中的高级抽象层，与提供原始 Token 访问的 Messages API 形成互补。CMA 允许用户定义智能体并启动会话，从而跳过繁琐的基础设施搭建和 Harness 配置工作，特别适合希望以编程方式运行智能体的开发者。在基础设施层面，CMA 与 Cloud Tag 共享底层执行平台（如沙箱集群），但在 Harness 层存在差异，因为两者在具体的操作逻辑和安全性要求上有所不同。平台团队负责运行所有基础产品基础设施，确保 CMA 既能享受底层资源的稳定性，又能保持上层逻辑的独立性。
战略重心转移：从功能堆砌到安全优先
尽管记忆（Memory）和梦境（Dreaming）等功能在上半年备受关注，但 Anthropic 团队当前的精力分配已发生显著变化。随着模型发布的安全挑战日益增加，大部分资源已从单纯的“功能爬坡”转向将安全性融入所有智能体系统中。虽然团队并未停止对 Skills、Memory 等功能的更新，但相比早期阶段有所放缓。核心逻辑在于：在确保模型能力安全释放的前提下，构建既强大又安全的 Agent 系统。这种策略调整反映了 Anthropic 对 AI 安全性的长期承诺，即安全性是智能体落地的首要前提。## 梦境机制的技术实现与模块化愿景 “Dreaming”（梦境）功能在技术底层被设计为一个基于 CMA 的多智能体系统。其工作原理是启动另一个受管智能体来评估前一个智能体的输出，并将生成的记忆写入其中。这种“CMA 嵌套 CMA”（Managed Agents all the way down）的设计并非偶然，而是出于模块化扩展的考量。团队认为这种架构允许开发者组合多种策略，如“Best of N”多智能体投票或验证者智能体等。事实上，已有开发者利用这种灵活性构建了共享记忆库并并行运行大量智能体的复杂系统。CMA 提供的简单基础层与上层灵活的 Hill Climbing（爬坡优化）策略相结合，为构建复杂的智能体生态提供了坚实基础。
开放多智能体策略构建的底层原语
Anthropic 正在推进一项重要更新，旨在让用户能够利用其底层的“原始能力”（primitives）来构建自定义的多智能体策略。这一举措延续了此前发布 Dreaming 项目时的思路，即通过管理代理（Manage Agents）实现从顶层到底层的全面控制。未来不久将推出的更新会暴露这些底层原语，允许用户构建类似“Harness 策略”或更通用的多智能体协作框架。官方表示，这将提供模板化的起点（如 Dreaming 的初始形态），开发者可以在此基础上进行迭代和优化，从而获得更高的价值。
“We've got the primitives in place. We can continue to let people just, like, take and run with those things while giving them the tools...”核心观点在于，Anthropic 并非放缓相关领域的进展，而是已经搭建好了基础原语。团队现在的重心是提供工具包和最佳实践（如 Cloud Managed Agents 中的功能），让用户能够利用 Claude 的能力去增强这些原语，自行创造更强大的多智能体系统。与此同时，Anthropic 内部团队则专注于确保用户能安全地访问系统中的模型资源。
AI 工程即研究：评估套件（Evals）的最佳实践
在代理和 Harness 的评估方面，Anthropic 指出“投资不足（under investing）”是人们在评估环节犯的最大错误。虽然存在静态确定性测试、LLM 作为裁判（LLM as a judge）等多种评估策略，但并没有一套完美的固定组合能解决所有问题。实际经验表明，用户需要建立相对庞大且多样化的评估套件（suite of evals）。此外，代理系统本身也可以协助用户随时间推移不断进化和完善这些评估标准。
许多初学者容易陷入“过度设计”的陷阱，试图尝试所有复杂的菜单选项，却忽略了最基础的指标（如实际处理的邮件数量为零）。建议从简单的方法开始执行，这比追求完美但无产出的复杂方案更有用。Anthropic 强调，将工程视为研究（treating engineering like research）是关键。在这种范式下，工程师会自然地进行更多的评估、标注和运行扩展（prototyping and scaling of runs）。这种方法要求预先定义目标，将其形式化为评估指标，并深入分析失败原因——很多时候问题出在评估标准本身或环境设置上，而非模型错误。这种严谨的研究式工程方法是 AI 工程师的核心技能之一。
Claude 作为评估生成器与系统进化闭环
Anthropic 计划推出更多内置工具，帮助用户开箱即用地创建针对 Managed Agents 的评估。这些新功能的交互体验将类似于与 Claude 协作，因为Claude 本身非常擅长创建用于评估代理的测试用例。对于许多不熟悉 JSON-L 等复杂格式的用户来说，直接通过自然语言与 Claude 交互（如“左、右、左”式的反馈循环）来生成评估数据，比手动编写代码更符合人类标注员的工作逻辑。
“Claude can just consume that and then work on itself, right? That's the feedback it needs.”这一机制形成了一个高效的反馈闭环：Claude 生成评估数据（包括评分、ELO 值等），用户或系统消费这些数据并反馈给 Claude，从而优化其自身表现。这种“AGI-pilled”的方式允许用户系统地更新和编辑系统，随着新模型的改进或需求的变化，整个评估体系能够随之进化。这标志着应用层工程与模型研究的融合：传统的应用开发只关心是否符合产品需求文档（PRD），而 AI 工程则需要像模型研究人员一样，通过持续的评估和迭代来驱动产品进化。Anthropic 近期发布的关于提升 UI 速度的博客文章也展示了这种研究式工程的具体案例，例如在两周内完成多项优化任务中的大部分工作，体现了提示词工程和快速迭代的力量。
算力危机：CPU 资源成为新的增长瓶颈
Anthropic 目前面临的最大挑战并非仅仅是 GPU 加速层的算力，而是 CPU 层面的资源短缺。规模（Scale）与安全（Safety）是团队投入精力最多的两个领域。随着客户数量的激增，CPU 的需求呈现出零和博弈的状态：不仅要支撑产品服务和 API 运行，还要处理大量的沙箱隔离（Sandboxing）以及因代码量激增而带来的 CI/CD 构建任务。在训练阶段，沙箱隔离同样消耗大量 CPU 资源。行业现状是所有人都在所有方面短缺，过去那种仅凭预算即可按需扩展 CPU 容量的时代已经结束。现在企业必须进行前瞻性的容量规划，这种转变对许多公司来说是一种巨大的压力。
"Scale and safety. Those are like the two biggest things we're spending our time on."（规模和安全性是我们花费时间最多的两件事。）
技术决策：从零开始重写 Python 单体应用
为了应对 CPU 墙（CPU Wall），Anthropic 决定从基础设施层和应用层提升效率。最具标志性的举措是全面推出用 Rust 重写的 Messages API。这是一个极具风险的决策，因为当时团队中没有任何一名专职的 Rust 开发人员。尽管在纸面上这看似显而易见，但在实际操作中极具挑战性。团队采用了“人类设计架构 + Claude 编写代码”的模式：工程师负责分布式系统的整体设计和验证，而由 AI 辅助完成具体的编码实现。这种协作方式不仅解决了技术栈陌生的问题，还让工程师在过程中快速掌握了所需知识。计划（Plan）和验证（Verification）是成功的关键，而非单纯的代码实现。
"We don't have a single Rust developer in the room. Exactly."（我们房间里连一个 Rust 开发人员都没有。没错。）
实施策略：全量 Fork 与影子流量验证
不同于传统的渐进式迁移，Anthropic 采取了一种激进且高效的方法：一次性完成整个 API 的 Rust Fork，并通过特性标志（Feature Flags）进行流量切换。团队构建了完整的影子测试环境，将生产环境的流量并行导入新旧系统，严格验证 Python 系统与 Rust 系统的输出一致性。这种低负载均衡的特性标志策略确保了在切换过程中的安全性。这是一次纯粹的重写，没有添加任何新功能，避免了范围蔓延（Scope Creep）。虽然这在传统观念中需要数年完成的分阶段迁移工作，但借助 AI 辅助编码和严格的验证机制，Anthropic 在极短时间内完成了这一壮举。
"We literally built like an entire fork of the entire API in Rust and then started running shadow traffic through it..."（我们 literally 构建了整个 API 的完整 Fork，并开始通过它运行影子流量……）
性能成果：CPU 节省与延迟优化
此次重写带来了显著的性能提升。在 CPU 使用效率方面，Anthropic 实现了数量级（Order of magnitude）的节省。具体数据显示，CPU 资源的使用量减少了约 40% 到 50%。在延迟方面，首字生成时间（Time to First Token, TTFT）改善了 10% 到 20%。这些改进不仅提升了长运行工作负载的效率，也为后续更广泛的部署奠定了基础。更高的效率意味着在相同的硬件资源下可以支撑更多的用户请求，这对于应对当前的算力短缺至关重要。这一案例证明了在 AI 辅助编程时代，即使是缺乏特定语言经验的团队，也能通过合理的架构设计和验证流程，完成复杂的底层重构任务。
"We've seen somewhere like 40 to 50 percent... And then latency, I think we saw somewhere between like 10 and 20 percent improvements on like time to first token specifically."（我们看到了大约 40% 到 50% [的 CPU 节省]……然后在延迟方面，我认为在首字生成时间上看到了大约 10% 到 20% 的改进。）
Rust 移植中的克制与安全审查
Anthropic 团队在将 Claude API 核心功能从原有语言迁移至 Rust 的过程中，采取了一种高度克制的策略。负责此次移植的“交换团队”（swap team）在推进工作的同时，必须应对整个开发团队的特性构建需求。该团队承担了所有的静态分析工作，确保新代码不会因跨语言交互（如 Rust 与其他部分的集成）而引发错误。> What we did was we like resisted the urge on all these things. And then, and because of what the team already had to keep up with was a little like swap team that we put together to go and do this.
尽管面临巨大的功能开发压力，该团队严格抵制了添加新功能或改变系统架构的冲动。这种克制确保了底层基础设施的稳定性和安全性，避免了因急于求成而引入的技术债务。团队的首要任务是完成基础架构的稳固迁移，而非在此阶段进行功能创新。
状态存储与持久化对象的探索
在基础架构稳定后，团队的目标转向了重新架构以支持更用户友好的功能。其中一项关键探索是对话状态的持久化存储。目前的 Messages API 要求客户端在每次请求中传递完整的会话状态，这在长对话场景中会导致显著的延迟和效率损失。团队正在研究类似 Cloudflare Durable Objects 的方案，允许服务器端在一段时间内存储状态。
What if we were able to not have you have to like pass back and forth the entire like conversation state, right? And if you didn't have to do that on the Messages API because you were open to, like, a storage of that state for some period of time.
虽然从用户数量上看，这一优化可能只影响小众群体，但从实际令牌吞吐量（token volume）的角度来看，这类工作负载占据了绝大多数。这种架构转变不仅能带来显著的延迟和效率提升，还能减少不必要的网络传输开销。
多云算力采购与安全合规
Anthropic 的算力分布在三大云提供商上，因此无法依赖单一固定的机器类型或计算形态。这种分散的架构要求团队在采购算力时，必须确保质量标准和规模标准。> We're not going to, like, go and integrate and run on certain machines if, like, we can't get enough of it.
团队中专门有负责安全合规的部门，他们现在投入大量精力协助 CPU 算力的采购。这确保了系统能够以所需的规模持续运行，同时满足 SOC 2 等企业级隐私和安全保证。> Give me all the privacy guarantees. And for what it's worth, like, so we have a really awesome team that secures our accelerator compute.
“大脑”与“双手”分离的架构演进
在解决沙箱隔离和代理（Agent）逃逸问题时，Anthropic 提出了“将大脑与双手分离”的架构理念。在 Claude Managed Agents 的设计中，“大脑”（控制逻辑）运行在持久的服务器上，而“双手”（执行环境如沙箱或容器）仅在需要时启动。
One of the things that we did with Claude Managed Agents specifically is the way that we architected it. We put out this blog post at the time of launching where we talked about we have the brain separate from the hands.
这种架构最初是为了提升延迟和可靠性。如果沙箱崩溃，持久的“大脑”部分不会受到影响，代理状态得以保留。然而，产品负责人指出，该架构最重要的属性实际上是安全性。通过将执行环境隔离在沙箱中，可以有效防止代理逃逸。> The most important property of this architecture is security. And everyone's like, yes, yes, yes. But latency and reliability.
这种设计避免了早期迭代中“将 Claude Code 扔进沙箱”导致的启动延迟和状态丢失问题，实现了更稳健的代理运行环境。
凭证存储与安全代理架构
Anthropic 在 Claude Agent 的架构设计中，将核心能力与执行权限进行了严格的物理隔离。对于任何需要执行的代理任务（如调用 MCP 服务器、CLI 或 API），系统采用了一个完全独立的保险库来存储凭证。当代理决定调用某项服务时，它只能看到一个占位符，而非真实的密钥。凭证注入发生在出口处（egress），由一个代理服务器负责从保险库中提取正确的凭据并注入请求中。这种设计确保了代理永远无法接触到真实的凭证数据。在传统的“将代理启动在一个沙箱中”的模式下，必须直接将凭据传入容器内，随后需要复杂的清理和监控措施来防止代理滥用权限。而 Anthropic 的方案构建了一道基础设施墙（infrastructure wall），从物理层面禁止代理访问这些凭据或进行恶意操作。
沙箱网络控制与默认安全配置
除了凭证隔离，该架构还强化了沙箱基础设施的网络出口控制。系统支持域名白名单机制，甚至可以完全切断网络连接。当代理编写并执行不受信任的代码时，代码在沙箱内运行，但其网络访问权限被严格限制为仅能连接至预设的目标。这种配置使得系统能够默认安全（secure by default），无需用户进行复杂的额外设置。随着客户开始部署用于内部或面向客户的代理产品，他们往往对“沙箱逃逸”等安全事件感到担忧。Anthropic 指出解决此类问题的两个关键要素是：一是架构层面的不可行性设计，即让代理在技术上无法执行未授权操作；二是沙箱的精细配置。Claude Managed Agents 的优势在于，这些安全措施是开箱即用的。随着系统演进的每一次更新，客户都能免费获得最新的安全加固特性。
训练环境与生产环境的本质区别
针对近期关于沙箱逃逸的讨论，需要区分模型训练场景与生产工作负载的本质差异。在训练中，研究人员将模型置于受限环境中以测试其极限（stress test），此时代理被激励去尝试突破边界。然而，在生产环境中运行 API 时，情况截然不同。生产环境拥有在线安全护栏（online safeguards），这些在训练中并不存在。更重要的是架构层面的分离：“大脑”与“双手”被物理隔离。代理不再是一个试图逃出盒子的单一实体，而是由外部的编排层（harness）和受限的执行环境组成。这种架构使得代理逃逸在工程上变得几乎不可能发生。Anthropic 强调，许多被报道的安全事件主要发生在模型训练阶段或早期实验环境中，而非经过严格护栏保护的生产工作负载中。
新兴领域的安全演进与责任分担
当前，长运行代理（long-running agents）仍处于相对早期的发展阶段，整个行业都在摸索最佳实践。Anthropic 认为这并非技术能力的缺失，而是一个新兴领域（nascent field），各方正在边构建边完善控制措施。在“ pacing the frontier ”的理念下，Anthropic 致力于将内部解决的所有安全问题（包括大脑与双手分离、凭证注入控制等）转化为标准化的基础设施能力。通过确保所有代理默认具备这些护栏，Anthropic 希望客户能够直接受益于内部研发的安全成果。这种“安全即默认”的策略旨在让客户无需担心底层基础设施的复杂性，从而专注于构建应用本身。随着技术的成熟，这些曾经被视为“新难题”的概念（如凭证注入、出口控制）正逐渐变为行业标准配置。
发布节奏与安全维度的三重保障
尽管表面上看，倡导“稳健步伐”与在短短 11 天内发布新前沿模型（如 Opus 5.5）似乎存在矛盾，但 Anthropic 认为这并不冲突。核心逻辑在于模型必须通过严格的安全检查才能上线，这意味着他们在三个关键维度上持续强化安全属性：架构与基础设施的安全性、模型运行时的在线防护措施，以及针对静态数据的离线分类防护。通过在这三个维度上部署完善的工作流程，Anthropic 确信能够将模型安全地推向市场。对于 Opus 5.5，他们不仅认为其性能卓越，更强调其在上述所有安全维度上均达到了高标准。正如对话中所言：> “Across all those three dimensions, we're putting all the right work in place to make sure that we feel really good that it's going to be safe.” 这种对安全性的全面覆盖，是他们决定快速迭代并释放新模型的根本底气。
“假阳性”困境与路由模型的智力局限
尽管安全优先，但当前的模型回退机制（Fallback）仍给用户带来挫败感。当用户试图进行正常操作时，可能会因触发安全分类器而被强制切换到较弱的模型。这一现象被类比为“智能路由器”与“笨拙路由器”的问题：Anthropic 目前使用的在线检测分类器是一个独立的、相对简单的模型，而非全功能的 Fable。由于该分类器的智力水平远低于主模型，它无法准确识别复杂语境下的意图，导致出现不合理的回退。例如，用户仅提及“生物”一词进行正常的作业查询，却可能因分类器误判而触发回退。这种“笨拙”的分类逻辑导致了大量的假阳性（False Positives），即安全系统错误地拦截了无害请求。解决这一难题的核心在于如何让分类器更智能，但这又带来了计算成本和延迟的权衡。
推理过程中的中断与用户体验的重构
当前的安全拦截机制存在一个显著的用户体验缺陷：它往往在模型已经开始推理并生成大量上下文后才触发。例如，有用户分享经历称，在与 Fable 交互时，模型已经深入分析了网络安全内容并进行了五分钟推理，随后才被安全过滤器拦截并回退到 Opus。这种“边思考边阻断”的模式不仅浪费了计算资源，更破坏了用户的连贯体验。理想的解决方案并非简单的回退或双重回退，而是提供一种统一且一致的用户界面。Anthropic 认为，系统应具备足够的智能来识别此类情境，并直接给出具体、安全的回答，同时避免展示被禁止的负面使用能力。这种设计旨在消除用户在不同模型间切换的困惑，提供一种更平滑、更符合预期的交互流程。
API 层面的灵活性与未来实验方向
在开发者层面，Anthropic 通过 API 提供了更灵活的解决方案以应对安全拦截。与客户端应用强制回退不同，API 允许开发者在服务端或 SDK 中自定义处理逻辑。开发者可以选择启用自动回退功能，也可以选择不触发回退而是重新提示（Reprompt）同一模型以继续对话。这种光谱式的解决方案赋予了开发者更大的控制权，使其能够根据具体应用场景平衡安全性与可用性。Anthropic 表示将继续探索中间地带的创新方案，旨在安全地解锁用户能力。他们承认当前的路由和分类机制仍存在类似 UX 的问题，但通过提供底层的灵活性，允许生态系统内的开发者构建更优的交互层。这种策略既保留了核心安全底线，又为未来的体验优化预留了实验空间。
路由逻辑的复杂性与用户体验困境
在构建多模型协作系统时，试图通过复杂的分类器将任务精准路由到不同模型是一个极具挑战性的难题。核心难点在于信息的不完美性：开发者既无法完全理解每个模型的特性，也无法在任务开始前掌握任务的完整信息。因此，无论分类器多么优秀，路由逻辑中必然伴随大量错误。如果将这种复杂的后台逻辑暴露给用户（例如告知用户“因为你是居中div，所以路由到便宜模型”），会严重损害用户体验。对于这类问题，理想的交互方式应当是动态理解任务复杂度，而非让用户感知到底层模型的切换。
统一模型与一致人格的重要性
面对多模型路由带来的割裂感，Anthropic倾向于采用单一且一致的模型架构。这种方案允许模型在保持极低成本和极高性价比的同时，能够根据任务需求连续扩展其能力层级。关键在于维持一致的人格（Persona）和交互体验。如果在不同模型提供商之间切换，人格的断裂感会变得极其复杂且难以解决；但在Anthropic自家的模型家族内部，一致性是更稳健的解决方案。这种设计避免了用户在不同“性格”的工具间跳跃带来的认知负担，确保了交互的连贯性。
工作负载的演变：从饱和到长程智能体任务
当前AI应用的工作负载正在发生显著变化。部分基础任务的智力需求已趋于饱和，但另一类任务——即需要极长运行时间的智能体（Agentic）工作负载——仍处于高度未饱和状态。这类任务涉及历史上无法通过暴力破解解决的复杂工程或科学问题，如生物信息学和网络安全领域。Anthropic认为这些长程智能体任务具有巨大价值，因为它们能带来独特的Alpha收益。尽管目前许多应用仍局限于编码自动化或企业流程加速等特定领域，但复杂科学问题的自动化正成为新的增长点。
内部对抗“Slop”：人类对质量负责
在团队内部，Anthropic严格区分使用Claude辅助工作与完全依赖其生成内容。核心原则是：人类创作者必须对最终输出的质量负责。如果员工使用Claude生成文档或代码却未进行审阅和修改，这将给消费者带来巨大的解析负担，被视为不公平且低效的行为。此外，团队还注意到一种心理现象：读者对AI生成的痕迹（如特定的标点符号使用习惯）非常敏感，一旦识别出“非人类”特征，会产生本能的反感。因此，高质量的人工介入和审阅是避免内容被标记为低质“Slop”的关键。
"If you use Claude to, like, totally generate a thing... then you're putting a whole extra burden on the consumer of that document or of that code... and that's just like insane and totally unfair."
"You're still responsible for the quality, but then you get into this really funny thing where... people's brains trigger on this like, oh, no, I'm reading something that was written by clod and not a human."
设定高质量的内容基准：平衡效率与人工审核
Anthropic团队在内部推行一种务实的AI使用策略，即鼓励员工利用Claude这一强大的智能代理来提升工作效率和生活质量。然而，这种便利并非没有代价或界限。团队设定了明确的质量基准：虽然允许使用Claude辅助创作，但最终产出的内容必须达到人类专家所持有的高标准。如果AI生成的痕迹过于明显或质量低下（即所谓的“slop”），读者会感到反感并拒绝接受。因此，关键在于找到平衡点——既要利用AI的速度优势，又要避免因为过度依赖而导致内容缺乏灵魂或出现细微的瑕疵（如“quadisms”）。核心原则是：利用AI加速，但人工必须把控最终的质量底线。
软件工程中的验证机制：从代码审查到测试驱动
在工程实践层面，Anthropic已经形成了一套成熟的AI辅助开发流程。目前的状态是：人类主要负责系统设计的高质量把控，而具体的代码实现则大量由Claude完成。由于AI生成的代码质量已经足够可靠，开发者不再需要对每一行代码进行深度的人工审查，而是将精力集中在整体架构和计划上。为了确保交付物的高品质，团队依赖于一套完善的验证体系。“Trust your tests”（信任你的测试）成为关键信条。通过严格的自动化测试和验证流程，团队能够在保持高产出的同时，确保代码质量不被视为低劣的“slop”。这种模式使得工程师能够快速迭代，同时维持高标准的工程质量。
产品思维的重塑：避免“懒惰式”创新与过度实验
尽管AI极大地降低了试错成本，但Anthropic联合创始人Tarek强调，不应将这种低成本转化为无意义的功能堆砌或盲目实验。有人曾提出“以10倍速度将更多特性推向生产环境”的想法，但Tarek反驳道，正确的使用方式不是盲目加速发布，而是花更多时间深入理解用户、进行更有针对性的实验和设计。“The right way to use model capabilities is not to ship 10x more features into prod. Spend more time understanding your users, trying experiments, building, whatnot.” 这种观点警示从业者，不要因为AI能轻易生成代码就陷入“懒惰式”开发。真正的价值在于前期的深思熟虑和意图明确的目标设定，而非后期的盲目产出。例如，在一个为期两周的性能优化冲刺中，团队在三天内就完成了13个目标中的12个，但这并非通过堆砌新功能实现，而是通过高效的重构和验证完成的。高质量的高产出依赖于严谨的前期规划，而非AI带来的虚假繁荣。
个人成长与智力挑战：从阅读到深度思考
在个人层面，话题转向了如何在AI时代保持智力的挑战性。一位嘉宾分享了自己曾经经历的一段“阅读狂飙”时期，当时他感到日常工作缺乏智力挑战，因此在一年内阅读了约200本书。“Half doing something is an expensive way of not doing it”（做一半事情是一种昂贵的不做之事）这一观点被提及，强调了深度投入和完整执行的重要性。虽然AI可以辅助信息获取和处理，但真正的智力成长来自于对复杂问题的深度思考和完整解决。这种态度不仅适用于工作，也适用于个人知识的积累。在AI辅助下，人们更应警惕浅尝辄止的倾向，转而追求更深层次的理解和创造。
阅读习惯重塑认知肌肉：从被动工作到主动思考
在职业生涯初期，许多技术人员容易陷入一种舒适区，虽然工作内容具有挑战性且有趣，但往往缺乏那种类似学校时期通过攻克新课题来锻炼“智力肌肉”的深度思考过程。这种被动接受式的工作状态会导致思维能力的停滞，因此主动进行高强度的阅读成为了一种必要的自我补充。通过每年大量阅读（如一年200本书），并利用通勤时间进行深度输入，从业者能够重新激活批判性思维与概念压缩能力。这种阅读并非为了积累社交资本或获取Twitter粉丝，而是一种内向型的智力训练。
DevRel 团队的双轨架构与新人入职挑战
Anthropic 在早期阶段意识到需要成熟化其对外沟通策略，因此决定大力投入开发者关系（DevRel）职能。由于 API 业务与 Agentic Coding（如 Claude Code）面向的是两个截然不同的开发者生态系统，公司最终在 Platform 和 CloudCode 内部分别组建了独立的 DevRel 团队。这两个团队虽然实体分离，但通过虚线汇报关系紧密协作。这种双轨制结构旨在同时覆盖不同的开发者生态，确保针对性的社区 engagement。对于负责 DevRel 的高管而言，尽管此前在 Stripe 等公司有过相关经验，但首次全面负责该职能仍充满挑战。为了快速上手，团队引入了 DevRel 的三大支柱概念：产品、内容和社区。
"Here are the three pillars of DevRel... across like product content community."
这一方法论甚至被戏称为 Google 对新入职 DevRel 员工的默认阅读材料。目前，Platform 部门的 DevRel IC（独立贡献者）直接向该高管汇报，而非通过中间经理。这种扁平化管理结构部分源于当前 DevRel 工作的高复杂度，同时也因为高管本人从与团队的直接协作中获得了极大的乐趣。直接的汇报关系有助于应对 DevRel 领域日益复杂的挑战，并提升团队响应速度。
Platform 品牌叙事的重塑与定位困境
在 Anthropic 的公众叙事中，Platform 业务往往容易被前沿的研究工作、政策讨论以及 Claude Code、Cowork 等应用层产品所掩盖。尽管 Platform 是一个庞大的开发者业务，且许多人在此之上构建应用，但其重要性在外部认知中常常被低估。因此，Platform DevRel 团队的一个核心目标是解决品牌声音缺失的问题，明确其在社区中的身份定位。除了传统的通过产品反馈循环来优化开发体验外，团队更致力于建立独特的品牌叙事。这不仅仅是关于技术传播，更是为了在复杂的公司架构中确立 Platform 业务的独立价值和存在感。
“思想领袖”与“大师级建造者”的双重角色定义
为了重塑品牌，Anthropic 引入了具有深厚技术背景的 Lance。他的 DevRel 风格侧重于教学与深度解析，通过撰写关于记忆管理、成本控制等硬核主题的文章，以及构建评估工具（evals），确立了团队作为新兴且高难度领域中的思想领袖和教育者的形象。这种定位旨在帮助开发者理解快速演进的 AI 空间。
"I really like that idea, that idea of our DevRel team being kind of like thought leaders for people within what is a really nascent, really hard, really evolving space."
另一种推崇的角色模式是“大师级建造者”（Master Builder），这一概念借鉴自乐高。乐高的销售策略是通过展示用积木构建的复杂作品来激发用户的创造欲。Anthropic 希望 DevRel 团队能展示平台能力的边界，让开发者惊叹于“原来 Claude Platform 还能这样做”。团队成员 CJ 也通过编写 Cookbooks（食谱/指南）和在 X (Twitter) 上与社区互动，践行了这一理念。这种“展示可能性”的策略旨在通过视觉和案例冲击激发开发者的自发探索欲。
从复杂 Cookbook 到参考架构的技术传播演进
随着 API 的成熟，技术内容的形式发生了显著变化。早期（2023年左右），开发者需要依赖极其复杂的 Cookbook 来实现特定功能，例如“Computer Use”集成。当时的工程师不得不处理截屏、消息 API 交互等底层细节，这些内容虽然对早期黑客松参与者有价值，但过于复杂且维护成本高，甚至成为团队成员的“噩梦”。
"There's an engineer on our team who wrote our cookbook on computer use and it like haunts him to this day because it was like massively complex."
如今，开发模式已转向更高效的工具链。开发者不再直接复制粘贴庞大的代码库，而是利用 Claude Code Skill 或加载编码代理（coding agent）来构建高质量集成。对于特定实现，开发者可以直接指定参考架构。这种转变标志着技术传播从“提供完整代码”向“提供能力指引和标准参考”的演进，极大地降低了开发门槛并提高了集成效率。值得注意的是，Claude API Skill 本身也是由 DevRel 团队（Lance）构建的，这进一步证明了 DevRel 在基础设施工具化方面的直接贡献。
DevRel的终极形态：工程师即代言人
开发者关系（DevRel）的最高杠杆形式，是将最佳实践提炼并融入Agent的设计中。理想的境界是工程师成为公众面孔，而非依赖专门的公关人员。当团队足够优秀时，甚至不需要传统的DevRel角色。Anthropic本身无需刻意宣传，其技术实力自会发声。以Boris（Claude Code的创建者）为例，他虽有大厂职位，但其个人品牌与产品深度绑定，这种“我在做这件事”的真实感极具说服力。Cloudflare团队是这一模式的典范，成员们持续产出内容且工作状态积极、离职率低。这证明了一个好管理的标志是团队成员愿意公开表达，而非由少数人代劳。
“One of the reasons... there are some part of me that just wants to tell you you don't need DevRel. You get so good you don't need it.”
解构DevRel：前台与后台的协作模式
目前Anthropic正尝试将平台团队和工程团队的成员推向社区，但面临时间不足与高质量产出难以兼顾的挑战。因此，提出将DevRel解构为“前台”（Front Office）和“后台”（Back Office）。传统DevRel是端到端独立的，但未来模式应是建立一支专业的“后台”制作团队。前台的工程师只需投入30-60分钟进行思维倾倒（brain dump），后台团队负责代笔、制作和分发。用户更希望听到来自产品工程师（如Lance, Tariq）的声音，而非付费发言人。这种模式类似于HR部门协助各部门招聘：工程师负责“面试”（技术把关），专业团队负责流程优化。这是一种专业化分工，让擅长工程的人专注工程，擅长传播的人专注传播。
Opus 5.5的核心优势：成本效率与高“氛围感”
在讨论Opus 5.5时，其核心优势被概括为极高的成本效率、更简洁的输出以及卓越的“氛围感”（vibes）。该模型在实际场景中表现优异，甚至在一次事故恢复中拯救了团队。对于此前因成本或Token效率顾虑而未敢大规模使用的用户，Opus 5.5提供了重新尝试的机会。更低的边际成本意味着用户可以更大胆地让模型运行复杂任务，从而获得比之前使用低效模型时更远的进展。这种经济性使得以前因预算限制而无法实现的实验现在变得可行，极大地释放了开发者的创造力。
多智能体架构：异步并行与角色自分配
Opus 5.5在多智能体（Multi-agent）设置中表现尤为出色。关键架构原则包括：拥有一个主导节点，并将任务拆分为可并行处理的子单元；确保所有智能体共享统一的上下文。异步执行是关键，即各子代理之间互不阻塞。随着模型智能的提升，架构将趋向于让Agent自我分配角色和任务。传统的静态角色定义正在被动态的、由模型自主决定的工作流所取代。这种“自我克隆”和自适应调整的能力，代表了处理复杂问题的更优路径。开发者应关注如何设计可并行化的任务结构，而非过度干预具体的执行细节，让Claude自行决定最优的协作方式。
“You can assign roles... But this is like, they're giving themselves jobs.”
核心架构设计：并行处理与状态隔离
在构建复杂的智能体系统时，底层的架构选择直接决定了系统的上限。关键在于确保各个子代理（sub-agents）能够进行高效的并行处理。为了实现这一点，系统必须维护一个共享状态（shared state），使得不同模块间的信息流转畅通无阻。同时，架构设计必须严格避免子代理之间的阻塞（blocking）现象，确保任何一个环节的延迟都不会拖累整体进度。这种设计思路强调了对系统并发能力的极致追求。
"You just need to make sure it can, like, parallel process. So it needs a shared state and it needs to like not block its sub agents."（你只需要确保它能并行处理。它需要一个共享状态，并且不能阻塞其子代理。）
鼓励实验与解决棘手问题
一旦确立了上述两个核心原则——即共享状态和非阻塞机制，开发者应当被鼓励去尝试各种看似疯狂的创新实验。这种架构的灵活性使得它能够应对那些传统方法难以解决的棘手问题（intractable problem）。许多开发者可能因为某些令人头疼的技术瓶颈而停滞不前，但在这种架构下，这些问题有可能被彻底粉碎（crush it）。通过合理的并行设计甚至单次调用（one-shot）策略，原本看似不可逾越的技术障碍可能迎刃而解。
"As long as you contain those two principles, honestly, I think people should experiment and probably try some really crazy stuff."（只要包含这两个原则，老实说，我认为人们应该进行实验并尝试一些非常疯狂的东西。）
展望与行动号召
基于这种架构的潜力，未来可能会出现许多令人感兴趣（really interesting）的新应用或技术突破。这些创新可能源于开发者对长期困扰他们的难题的持续推动，而新的架构提供了一击必杀（one shot）的可能性。对于所有参与者而言，现在的核心任务是立即投入构建工作。行动号召（go build）被明确提出，鼓励大家利用这些设计原则去实现那些曾经被认为难以攻克的场景。这种从理论到实践的转化，正是推动技术向前发展的关键动力。
"I wouldn't be surprised to see some like really interesting things on top of that... maybe one shot or something."（我不会惊讶于看到上面出现一些非常有趣的事情……也许是单次调用之类的东西。）
结论
Anthropic通过财务效率跃升与“大脑-双手”分离架构，确立了安全优先的工程范式。Opus 5.5以显著的成本优势（CPU节省40%-50%）和更优的用户体验，验证了其在商业落地中的竞争力。然而，安全拦截导致的假阳性回退及路由逻辑缺陷仍是当前主要短板。
该架构通过沙箱隔离与凭证注入实现了默认安全，有效遏制了蒸馏风险。尽管长程智能体任务潜力巨大且多代理并行策略成熟，但系统仍高度依赖人类专家解决CPU瓶颈与复杂工程问题。总体而言，Anthropic在安全性、成本效益及架构稳健性上表现卓越，但在自动化程度与用户体验一致性方面仍有优化空间。