1. 当AI开始“造AI”一个正在发生的研发范式转移第一次看到“Claude主导Anthropic 26%的AI研发”这个数字时我的反应是这个比例大概率不是拍脑袋来的。它背后对应的是一个可量化的工程现实——Anthropic内部已经把Claude接入了代码生成、实验设计、数据标注、评测集构建等核心研发环节而且这个占比还在往上走。与此同时“3万Agent同时运行”这个量级说明他们跑的不是几个demo而是一套成规模的Agent调度系统。这两件事放在一起指向的是同一个方向RSIRecursive Self-Improvement递归自我改进。简单说就是让AI参与改进AI本身形成“模型变强→研发效率提升→下一代模型更强”的正循环。这个循环一旦转起来迭代速度就不再是线性的而是指数级的。但这里有个关键问题RSI不是一条路而是好几条路。头部公司在这件事上的路线选择正在明显分化。有的押注“模型能力上限”有的押注“Agent编排规模”有的押注“工具链闭环”。这篇文章我想把这件事拆开讲清楚——不是复述新闻而是从工程视角分析这些数字意味着什么背后的技术栈大概长什么样以及如果你在做Agent开发能从中学到什么可以直接抄的东西。适合谁看如果你在做AI Agent开发、关注大模型工程化落地、或者单纯想搞明白“AI造AI”到底是怎么落地的这篇应该能给你一些实在的参考。我会尽量用从业者之间聊天的口吻把原理、架构、实操要点和踩坑经验都摊开说。2. 26%这个数字背后Claude到底在“研发”什么2.1 拆解“AI参与研发”的四个层次很多人看到“Claude主导26%的AI研发”第一反应是“Claude在写代码”。这个理解太窄了。根据Anthropic公开的一些技术分享和行业常见实践AI参与研发至少分四个层次每个层次的技术难度和风险完全不同。第一层代码生成与补全。这是最成熟的场景。Claude Code、Cursor这类工具已经在做这件事。研发人员写注释或函数签名模型补全实现。这一层的价值在于减少重复劳动但本质上还是“人在主导AI在辅助”。第二层实验设计与参数搜索。这一层开始有意思了。模型不只是写代码而是根据实验目标自动生成实验方案、选择超参数组合、甚至决定先跑哪个消融实验。Anthropic的26%里这一层的贡献可能比第一层更大因为它直接压缩了“试错周期”。第三层数据标注与评测集构建。大模型研发最耗人力的环节之一就是数据。让Claude参与生成标注数据、构建评测集、甚至设计评测指标这一层的自动化程度直接决定了迭代速度。但风险也在这里——如果评测集本身是AI生成的怎么保证它没有偏差第四层架构搜索与训练策略优化。这是最深的一层也是RSI的核心。模型参与决定下一代的网络结构、训练数据配比、学习率调度等。这一层目前还处于早期但方向已经很明确了。注意这四层的自动化程度是递进的但风险也是递进的。第一层出问题最多是代码bug第四层出问题可能是整个训练方向跑偏。所以头部公司在推进时通常是“低层全自动高层强人工审核”。2.2 为什么是26%而不是更高或更低这个数字其实很微妙。如果太低说明AI在研发中的价值有限如果太高说明人类审核环节可能被压缩得太狠风险不可控。26%这个比例大概率是“AI生成人类审核”模式下的一个平衡点。我个人的判断是这个比例的计算方式可能是在研发流程的所有“可量化产出”中由Claude直接生成或修改的部分占比。比如代码提交量、实验方案数量、标注数据量等。但“人类审核”这个环节的时间成本可能没有被完全计入——也就是说实际节省的时间可能低于26%这个数字给人的直觉。但这不重要。重要的是趋势这个比例在涨。而且随着Agent编排能力提升涨的速度可能会加快。2.3 对普通开发者的启示你可能会说Anthropic是头部公司他们的做法跟我有什么关系关系很大。因为他们的技术栈会逐渐下沉成工具链而工具链会变成你的日常。举个具体的例子Claude Code现在已经可以做到“给一个需求描述自动生成代码、跑测试、根据报错修复、再跑测试”这个闭环。这个能力在Anthropic内部可能已经用了很久但现在通过Claude Code开放出来了。你不需要自己造一个RSI系统但你可以用他们的工具来提升自己的研发效率。所以我的建议是不要只盯着26%这个数字看要看他们用什么工具、什么流程、什么架构来实现这个数字。这些才是你能直接抄的东西。3. 3万Agent同时运行工程上的挑战和架构选择3.1 3万Agent是什么概念先做个简单的算术。如果每个Agent平均运行10分钟3万Agent同时运行意味着每秒有50个Agent在启动或结束。这需要一套非常高效的调度系统。如果每个Agent平均消耗1GB内存3万Agent就是30TB内存——这显然不现实。所以实际架构一定是“轻量级Agent共享资源池”的模式。更合理的推测是这3万Agent不是3万个独立进程而是3万个“任务单元”由一套统一的调度框架管理。每个任务单元可能只存活几秒到几分钟执行完就销毁。这种模式下真正的挑战不是内存而是调度延迟和状态一致性。3.2 Agent编排的三种典型架构根据行业常见实践大规模Agent编排通常有三种架构架构一中心化调度器。一个主控进程负责任务分发、状态管理、结果收集。优点是逻辑清晰、容易调试缺点是单点瓶颈3万并发下调度器本身可能成为性能瓶颈。架构二去中心化消息队列。Agent之间通过消息队列通信没有中心调度器。优点是扩展性好缺点是状态追踪困难出问题时很难定位是哪个Agent的锅。架构三分层调度。上层是粗粒度调度器下层是细粒度执行器。上层负责分配“大任务”下层负责把大任务拆成小任务并执行。这是目前大规模Agent系统最常用的架构兼顾了扩展性和可管理性。Anthropic的3万Agent系统大概率是第三种架构的变体。因为纯中心化扛不住3万并发纯去中心化又不好管理。3.3 实操中容易踩的坑如果你自己在做Agent系统以下是我踩过的坑供参考Agent生命周期管理Agent启动和销毁的开销比想象中大。如果每个任务都新建Agent系统很快会被创建/销毁操作拖垮。解决方案是维护一个Agent池复用空闲Agent。状态同步多个Agent同时读写共享状态时锁竞争会非常严重。我的经验是尽量让Agent无状态所有状态通过外部存储管理。错误传播一个Agent出错如果不及时隔离可能通过共享状态影响其他Agent。需要设计“熔断机制”某个Agent连续失败就自动隔离。日志爆炸3万Agent同时打日志日志系统会瞬间被冲垮。必须做日志采样和聚合否则排查问题时根本找不到有用信息。提示如果你刚开始做Agent系统不要一上来就追求大规模。先从10个Agent跑通闭环再逐步加量。很多架构问题在10个Agent时不会暴露到100个才会到1000个就彻底崩了。3.4 Agent框架选型Harness和Agent的区别热搜词里有个“harness和agent区别”这个问题其实很关键。简单说Agent是“执行者”Harness是“执行环境”。Agent负责决策和行动Harness负责提供工具、管理状态、处理错误。一个好的Harness可以让Agent开发变得简单因为很多底层问题网络重试、超时处理、资源清理都被Harness屏蔽了。目前主流的Agent框架比如LangChain、AutoGPT、CrewAI其实都在往Harness的方向演进。它们不只是提供Agent抽象还提供工具集成、记忆管理、错误处理等基础设施。选型建议如果你只是做原型验证用LangChain这类框架快速搭起来就行。如果要上生产建议自己写Harness因为通用框架很难满足你的特定需求而且出问题时不好排查。4. RSI路线分化头部公司在赌什么4.1 三条主要路线RSI这个概念听起来很统一但实际落地时头部公司的路线选择差异很大。我观察到的至少有三条路线一模型能力优先。代表是OpenAI和Anthropic。核心逻辑是先把模型本身的能力推到极限再用这个强模型去改进下一代模型。这条路的赌注是“模型能力上限决定RSI速度”。路线二Agent编排优先。代表是一些做Agent基础设施的公司。核心逻辑是模型能力可能暂时不够强但通过大规模Agent编排可以弥补单模型能力的不足。这条路的赌注是“工程能力可以部分替代模型能力”。路线三工具链闭环优先。代表是那些做AI编程工具的公司。核心逻辑是先把研发流程中的工具链打通让AI能在工具链中自动执行任务再逐步提升自动化程度。这条路的赌注是“流程自动化比模型能力更早产生价值”。4.2 路线分化的原因为什么会有这些分化因为RSI的瓶颈在不同阶段是不同的。早期瓶颈是模型能力——模型不够聪明什么都干不了。这个阶段路线一占优。中期瓶颈是工程能力——模型够聪明了但没法大规模并行执行。这个阶段路线二占优。后期瓶颈是流程整合——工程能力够了但流程没打通AI和人类研发流程还是两张皮。这个阶段路线三占优。目前头部公司大多处于中期向后期过渡的阶段所以路线二和路线三的讨论越来越多。4.3 对Agent开发者的启示如果你在做Agent开发这个路线分化对你意味着什么意味着不要只盯着模型能力。模型能力确实重要但Agent系统的价值不只来自模型。编排能力、工具集成、错误处理、状态管理这些工程能力同样决定系统上限。我见过太多团队花大量时间调prompt、换模型但Agent系统的工程架构一塌糊涂。结果就是单次任务效果还行一上规模就崩。所以我的建议是把至少一半的精力放在工程架构上。Agent池、状态管理、错误隔离、日志聚合这些才是决定你能不能从10个Agent扩展到1000个Agent的关键。5. 从Claude Code看RSI的落地形态5.1 Claude Code为什么重要Claude Code是Anthropic推出的AI编程工具但它的意义远不止“又一个Copilot”。它代表了一种RSI的落地形态AI在真实的研发环境中执行任务而不是在沙箱里做demo。Claude Code可以访问文件系统、执行命令、运行测试、查看报错、修改代码。这个闭环意味着它可以完成“写代码→跑测试→修bug→再跑测试”的完整循环。这个循环一旦跑通RSI就有了最基础的执行单元。5.2 安装和配置的实操要点热搜词里有大量关于Claude Code安装的问题比如“claude code安装”、“ubuntu安装claude code”、“vscode配置claude code”。我结合自己的实操经验把关键步骤和坑点整理一下。安装方式选择安装方式适用场景优点缺点npm全局安装大多数场景简单、更新方便需要Node环境桌面客户端不想折腾命令行开箱即用灵活性差VS Code插件已在用VS Code集成度高依赖VS Codenpm安装的核心命令npm install -g anthropic-ai/claude-code安装完成后运行claude命令启动。第一次启动会引导你完成认证配置。常见报错处理unable to connect to anthropic services通常是网络配置问题。检查你的网络环境是否能正常访问服务端点。claude : 无法将“claude”项识别为 cmdletWindows下PATH没配好。找到npm全局安装目录手动加到PATH里。claudes workspace requires the virtual machine platform on windowsWindows下需要启用虚拟机平台功能。在“启用或关闭Windows功能”里勾选对应选项重启后生效。注意安装过程中如果遇到认证问题优先检查系统时间是否准确。时间偏差过大会导致认证失败这个坑我踩过排查了半天才发现是系统时间不对。5.3 Claude Code的使用心得用了一段时间Claude Code有几个心得第一任务描述要具体。不要说“帮我优化这个函数”要说“这个函数在处理超过1000条数据时变慢帮我分析瓶颈并优化”。描述越具体Claude Code的执行越精准。第二善用“先分析再执行”模式。Claude Code可以先分析代码、给出方案你确认后再执行。这个模式在修改核心代码时特别有用避免它直接改出问题。第三注意上下文窗口管理。Claude Code的上下文窗口有限如果项目很大它可能看不到所有相关代码。这时候需要你手动指定关键文件或者分步骤执行。第四测试驱动是王道。让Claude Code先写测试再写实现最后跑测试验证。这个流程比“直接写实现”靠谱得多。6. Agent开发的学习路线和实操建议6.1 从零到一的四个阶段热搜词里有“agent开发学习路线”、“agent学习路线”、“ai agent for beginners”说明很多人想入门但不知道从哪开始。我结合自己的经验整理一个四阶段路线。阶段一理解基本概念。搞清楚Agent、Harness、Tool、Memory这些核心概念的区别和联系。不需要写代码先建立认知框架。阶段二跑通最小闭环。用一个简单框架比如LangChain搭一个能完成单一任务的Agent。比如“读取文件→分析内容→生成摘要→写入新文件”。这个阶段的目标是理解Agent的执行流程。阶段三加入工具和记忆。给Agent加上工具调用能力比如搜索、计算、文件操作和记忆能力短期记忆、长期记忆。这个阶段的目标是让Agent能处理更复杂的任务。阶段四工程化。加入错误处理、日志、监控、并发控制。这个阶段的目标是让Agent系统能稳定运行而不是跑一次就崩。6.2 Agent记忆管理的实操要点Agent记忆是热搜词之一也是实操中最容易出问题的环节。我的经验是短期记忆用对话历史就行但要注意截断策略。不能无限增长否则上下文窗口很快爆掉。长期记忆需要外部存储。向量数据库是常见选择但检索质量很关键。检索不准记忆就是噪音。记忆更新要有策略。不是所有对话都值得记住需要设计“记忆写入”的触发条件。提示不要一上来就搞复杂的记忆系统。先用最简单的对话历史跑通之后再逐步加向量检索、记忆摘要等功能。很多团队在记忆系统上过度设计结果核心任务都没跑通。6.3 Agent评测怎么做“agent evals”也是热搜词。Agent评测比模型评测难得多因为Agent的行为是序列化的单步正确不代表整体正确。我的做法是定义任务成功率一个任务从开始到结束是否达到了预期目标。这是最核心的指标。记录中间步骤每一步的工具调用、参数选择、结果处理都要记录。出问题时可以回溯。设计边界测试故意给Agent一些模糊的、有歧义的、甚至矛盾的任务看它怎么处理。这能暴露很多问题。人工抽检自动化评测只能覆盖已知场景人工抽检能发现未知问题。7. 常见问题与排查技巧实录7.1 连接类问题问题现象可能原因排查步骤unable to connect to anthropic services网络配置、认证失效、服务端问题检查网络、重新认证、查看服务状态failed to connect to api端点配置错误、防火墙拦截检查配置文件、测试网络连通性认证失败密钥过期、系统时间偏差更新密钥、校准系统时间7.2 执行类问题Agent执行中断agent execution terminated due to error。先看日志定位是哪个步骤出错。常见原因是工具调用超时或返回格式不符合预期。模型路由错误doesnt look like an anthropic model: expected a gateway model route。检查模型名称配置确认路由规则是否正确。Agent不执行任务检查任务描述是否清晰工具是否可用权限是否足够。7.3 性能类问题Agent响应慢先看是模型推理慢还是工具调用慢。模型推理慢可以换更小的模型或优化prompt工具调用慢可以加缓存或异步化。并发上不去检查Agent池大小、调度器性能、外部依赖的并发限制。内存泄漏Agent系统长时间运行后内存持续增长通常是Agent销毁时资源没释放干净。检查文件句柄、网络连接、缓存对象。注意排查Agent问题时日志是第一手资料。但日志太多也是问题。我的做法是给每个Agent分配一个唯一ID所有日志都带这个ID排查时按ID过滤效率高很多。8. 我个人的一些体会做Agent系统这段时间最大的体会是工程能力比模型能力更稀缺。模型能力在快速提升但工程能力需要时间积累。一个架构设计得好的Agent系统用中等能力的模型也能跑出不错的效果一个架构糟糕的系统用最强的模型也跑不稳。另一个体会是不要追求一步到位。RSI听起来很宏大但落地时都是从一个个小闭环开始的。Claude Code先跑通“写代码→跑测试→修bug”这个闭环再逐步扩展到更复杂的任务。你做Agent系统也一样先跑通一个最小闭环再逐步加功能。最后分享一个实用技巧给Agent设计“退出条件”。很多Agent系统跑着跑着就陷入死循环或者在一个任务上无限重试。设计明确的退出条件比如最大重试次数、最大执行时间、连续失败次数能避免很多资源浪费。这个技巧看起来简单但实际能省下大量调试时间。
