如果最近你也在刷AI圈的热点会发现RSI这个词高频出现。OpenAI和Anthropic两家的新动作把这股讨论推到了顶点大家开始意识到AI不再是改改提示词、问几个问题就能打发的工具它正在进入一种“自己给自己布置任务、自己执行、自己检查结果”的循环状态。很多人把这个趋势叫作RSIRecursive Self-Improvement递归自我改进虽然不同人对它的定义还有争议但方向已经很明确——模型不再满足于当“答题选手”而是要当“带刀的项目经理”。这篇文章我想从概念拆解讲起落到API接入、Agent工作流搭建、常见坑位排查这些实操层面。不管你是刚拿到OpenAI API Key准备做第一个自动化脚本还是已经在用Anthropic的Claude系列跑长文本任务只要你的工作内容涉及“调用大模型干活”这篇内容都值得花十分钟看完。1. RSI到底是什么先把这个概念从玄学里捞出来1.1 递归自我改进不是“模型自己写自己”先说结论RSI在工程语境里并不是科幻片里AI半夜偷偷改自己权重那种“全自动进化”。更准确的理解是一种工作模式的转变——模型不再只是“单次推理”而是通过循环调用自身能力把复杂任务拆解成子任务边执行边总结再把新的信息带回下一轮推理形成一个可以持续迭代的闭环。打个比方过去你用AI像是雇了一个顾问问一句答一句现在你用AI像是带了一个实习生你只需要交代目标他会自己列计划、写草稿、找资料、跑测试、出报告然后拿回来给你看。如果环节出问题他会自己调整思路再试几轮。这种模式在OpenAI最新的Agent能力里、在Anthropic的Claude Code生态里都已经能看到雏形。递归自我改进还有另一个贴近实际的含义模型通过自我对弈、合成数据、自我评估来持续变强。比如用强模型生成训练数据去微调弱模型用模型A去评判模型B的输出质量或者让模型在不断试错中积累“经验”。这些方法不一定需要动到权重但确实让“提升”这件事从纯靠人类标注变成了一个可以自动运转的飞轮。1.2 为什么OpenAI和Anthropic都在往“墙角”逼两家公司最近的发布节奏明显都在押注同一个方向把模型从“会说话”变成“会办事”。OpenAI这边的Codex CLI、Agents API、Responses API本质上就是在给开发者提供让模型长出手脚的接口Anthropic这边则用更克制的产品形态把Claude放进终端、放进IDE让模型能在代码库里自己寻找上下文、修改文件、运行命令。“把人类逼到墙角”这个说法听起来吓人但落到现实里被逼到墙角的是两件事第一靠背API参数、写提示词模板混日子的“提示词工程师”红利期在快速收窄第二简单重复的编码、信息整理、文本处理工作确实在被这些循环式Agent大量吞掉。真正被压缩的是“重复劳动”而不是人的价值和判断力这个弦要绷住后面第三部分我会具体说怎么调整工作方式。2. OpenAI与Anthropic两条路线的正面交锋2.1 OpenAI工具链与Agent优先OpenAI现在的策略非常清晰模型能力是底座Agent和工具链是增长点。如果你去翻它的开发者文档能看到一套相对完整的路径先通过API Key拿到模型访问权限再用Function Calling让模型决定调用哪些函数然后用Agents API把它升级成一个可以管理多步骤任务的执行器最后用Codex这类命令行工具把整个开发流程卷进来。实际操作中我建议从Responses API入手它比老的Chat Completions API更容易理解而且自带工具调用、上下文管理、推理日志这些功能。你的工程代码里只需要维护一套接口协议不用自己拼历史消息数组省掉很多心智负担。Codex CLI更适合直接在本地仓库里跑任务它会把任务拆成“读文件、写代码、跑测试、提交结果”的循环你只需要在config.toml里配好模型供应商和密钥路径。2.2 Anthropic安全对齐与长文本智能Anthropic的产品路线强调“可解释、可控制、长上下文”。Claude模型在长文档理解、代码审查、复杂推理这些场景表现稳定并且它们的API设计更强调system prompt、工具描述这些面向结构化的输入。MCPModel Context Protocol是它们主推的开放协议目的就是给模型提供一套标准化的“接外部工具”的方式避免每个Agent项目自己发明一套工具协议。网上搜“Anthropic威胁报告”的时候你会发现很多讨论其实指向AI安全评估和风险治理。这个方向的工程含义是当模型开始自主执行任务就必须有评估机制、审计日志、权限控制。Anthropic在API策略上更严格很多账号一开始申请不到高级模型访问权这就导致开发者社区经常出现“unable to connect to anthropic services”“failed to connect to api.anthropic.com”之类的报错后面第4章我会专门拆这些故障。2.3 开发者怎么选型选OpenAI还是Anthropic不要看广告要看你的任务类型。维度OpenAIAnthropic上手难度资料多生态全文档示例丰富文档规范但部分高级能力需要权限智能体支持Agents API、Codex CLI工程化程度高Claude Code、MCP偏代码库内操作长文本处理足够用但有上下文窗口限制长文档优势明显稳定度高工具调用函数调用成熟兼容层多工具描述严格误调用率较低典型场景应用内Agent、工作流自动化代码审查、长文档萃取、深度分析我自己同时在线跑两家的接口OpenAI用于快速搭建对外服务Anthropic用于处理长文档和代码审查。选型的关键不是哪个模型更强而是哪个更容易在你的工程体系里稳定跑起来。3. 从零搭好一套可复现的Agent工作流3.1 工具准备与API接入先准备最基本的条件模型API Key、SDK环境和一个能跑Python的机器。以OpenAI为例你在官网创建好API Key后把它填进环境变量OPENAI_API_KEYAnthropic对应的是ANTHROPIC_API_KEY。代码里的调用方式大体是这样from openai import OpenAI client OpenAI( api_key你的key, base_urlhttps://你的网关地址/v1 # 没有网关可不填 ) resp client.responses.create( modelgpt-4.1-mini, input写一段Python代码统计一个目录下所有txt文件的词频。 ) print(resp.output_text)Anthropic的SDK风格略有不同使用Anthropic类型的client调用messages接口import anthropic client anthropic.Anthropic( api_key你的key ) resp client.messages.create( modelclaude-sonnet-4-5, max_tokens1024, system你是一个Python开发助手。, messages[{role: user, content: 写一段Python代码统计词频。}] ) print(resp.content[0].text)如果你只有OpenAI Key但某些开源工具只支持Anthropic接口会提示doesn’t look like an anthropic model: expected a gateway model route referenced。这种情况不要去硬改模型名而是找一个兼容层工具把OpenAI请求转成Anthropic协议再在兼容层里配置模型映射。这类网关配置本身不复杂重点是把模型名、base_url、密钥三个要素对应清楚。3.2 统一网关与多模型路由当你同时使用OpenAI、Anthropic以及其他兼容OpenAI协议的服务时最怕的是每个服务商一套SDK、一套配置。我的做法是在应用前面架一层统一的模型网关所有业务只认一个base_url由网关负责把请求路由到合适的模型供应商。网关配置一般长这样model_providers: openai: base_url: https://api.openai.com/v1 api_key_env: OPENAI_API_KEY anthropic: base_url: https://api.anthropic.com api_key_env: ANTHROPIC_API_KEY internal: base_url: https://ark.cn-beijing.volces.com/api/v3 api_key_env: VOLC_API_KEY model_routes: gpt-code: provider: openai model: gpt-4.1-mini claude-doc: provider: anthropic model: claude-sonnet-4-5 local-embedding: provider: internal model: doubao-embedding这样做的最大好处是当某个厂商模型服务不可用时你只需要在网关层切换路由业务代码完全不用动。网上很多人问“Cline Open AI Compatible 配置怎么填”本质就是让本地IDE工具通过一个OpenAI兼容地址去访问任意模型配置项通常只有三个Base URL、API Key、Model ID。3.3 从“单次对话”升级到“自主循环”真正体现RSI思路的是写一个最小化的Agent循环。核心逻辑不复杂让模型根据当前状态决定下一步动作执行动作把结果拼回上下文再让模型继续推理直到完成目标或触发停止条件。我用Python写过一版mini Agent思路可以分享一下import json from openai import OpenAI client OpenAI() def run_agent(task: str, max_iterations: int 5): messages [{role: user, content: task}] for i in range(max_iterations): resp client.responses.create( modelgpt-4.1-mini, inputmessages, tools[{ type: function, name: run_shell, description: 执行终端命令并返回输出, parameters: { type: object, properties: { command: {type: string} }, required: [command] } }] ) # 检查是否有工具调用 tool_calls resp.output if not tool_calls: return resp.output_text for call in tool_calls: args json.loads(call.arguments) if call.name run_shell: result __import__(subprocess).getoutput(args[command]) messages.append({ role: assistant, content: f命令执行结果{result[:500]} }) return 达到最大迭代次数 print(run_agent(统计当前目录下所有py文件的行数并按行数从高到低排序))这个脚本的核心价值在于演示“循环”模型不是一次给出答案而是不断生成命令、执行命令、观察结果、修正方向。实际工程中需要额外加入安全护栏比如禁止执行高风险命令、限制工具调用次数、记录完整执行日志。没有护栏的Agent能力越强越容易造成意外破坏。4. 常见故障与排查技巧实录4.1 API连接类问题先从网络与密钥查起搜“openai api key”和“unable to connect to anthropic services”的人特别多这类问题有几种典型表现第一种ConnectionError: Failed to connect to api.anthropic.com。看到这个先别怀疑账号大概率是网络出口不稳定、防火墙拦截或者网关超时时间太短。排查思路是先ping或curl一下目标域名确认基础可达性再检查代码里的超时配置把超时时间从默认的10秒放宽到30秒。对于有稳定内网环境的企业用户建议走合规的网络策略把目标域名加入放行白名单并预留独立的出口带宽。第二种AuthenticationError: Incorrect API key provided。这个报错很明确密钥不对或格式不完整。你需要重新复制Key注意不要带多余空格确认环境变量没有被其他配置覆盖。一个容易踩的坑是代码里同时写死了旧Key和环境变量环境变量优先级反而更高导致你改代码没生效。第三种网关地址填错比如把/v1路径拼错或者把OpenAI的base_url填到了Anthropic的client里。协议不匹配时报错信息往往是404 Not Found或者Missing required field: messages。碰到这类问题先确认SDK版本和base_url是否匹配再检查请求体的结构。4.2 模型路由与兼容性配置错了就报“not found”很多开发者遇到model provider not found这一类错误其实是模型路由配置的问题。比如你在config.toml里写model_provider openai model claude-sonnet-4-5工具会按OpenAI协议把模型名发到OpenAI接口OpenAI肯定不认识Claude的模型名于是返回模型不存在。正确的做法是在网关层把外部模型名映射成供应商支持的名字或使用工具内置的base_url切换到支持该模型的网关。[model_providers.openai] base_url https://ark.cn-beijing.volces.com/api/v3 api_key_env VOLC_API_KEY model doubao-seed-1-6-250615这里的关键点是model name是服务商定义的不是你自己随便命名的。改完配置文件后必须完全重启工具进程让配置重新加载否则改半天不生效。4.3 编排与工具调用的坑护栏比想象力更重要Agent跑起来以后报错反而不是最多的最头疼的是“看起来正常但结果不对”工具函数返回的数据量过大直接把上下文塞爆。解决方法是截断工具返回内容只保留关键片段比如命令输出前1000个字符文件内容按行取样。我在上一节代码里已经写了result[:500]就是这个道理。另一个常见问题是Agent陷入死循环同一工具反复调用。模型没有天然的“停止意识”所以必须在代码层面加max_iterations硬限制同时设定“重复结果出现两次以上就主动终止”的策略。还要注意极端输入问题。当模型拿到一个包含敏感信息的文件路径时如果Agent权限过大可能会读取到不该读的内容。所以我给Agent配置的所有工具函数都会做一层参数白名单校验只允许访问指定目录或指定命令前缀。毕竟是让模型“自主行动”权限边界必须由工程来框定。5. RSI时代工程师真正要练的三件事5.1 把“提示工程”升级成“评估工程”每天琢磨怎么写Prompt不如花时间构建一套评估集。你不需要给每个任务写几十条示例可以先准备10到20个代表真实场景的输入把模型的输出结果半自动判分每次模型更新、提示词调整都拿这套评估集跑一遍回归。有了这套“测试用例”模型能力强弱就能量化而不是靠感觉。实践中我会把评估集存成一个JSON文件每一条记录包含输入、期望行为、自动检查规则。发现Bad Case就往里补充现在已经积累了上百条任何新模型的引入都先过一遍这个测试集比网上各种测评榜单更贴近自己的业务。5.2 把“代码编写”让位给“系统编排”RSI带来的一个直接变化是模型写代码的能力在快速逼近初级工程师水准但工程的复杂性并没有消失而是转移到了编排层。你不再需要在每个函数里手写逻辑但你需要更懂如何把模型、工具、权限、数据流、异常处理、审计日志组装成一个闭环。比如我之前做的一个内部文档问答Agent业务逻辑本身只有几十行但围绕它需要设计索引更新策略、权限过滤、引用溯源、超时缓存、降级方案。这些工作远比“写提示词”更难替代。所以在日常工作中我会有意识地把时间花在研究架构、阅读SDK源码、配置网关和设计可观测性上。5.3 把“信任”建立成“可审计”人对AI的不信任很大程度来自“不可解释”。当Agent开始自动执行命令、修改文件、调用外部服务时信任问题会直接变成工程问题。我的经验是给Agent的每个关键动作都加上日志记录包括目标、调用工具、入参、出参、耗时、成功率。任务结束后能完整回放这个Agent“当时为什么这么做”。权限最小化也要提上日程能只读就不要给写权限能限定目录就不要给全盘访问能用一个临时Token就不要用长期Key。别看这些细节琐碎一旦Agent跑出问题审计日志和权限边界就是你翻盘的唯一凭据。我自己这几年的体会是RSI并不是某一天突然出现的“大新闻”而是一个渐进的过程。最开始大家把模型当玩具后来当搜索引擎再后来当结对程序员现在开始当可以托付任务的执行者。每次“能力跃迁”都会让一批旧技能贬值但也一定会冒出一批新岗位关键是你能不能比模型先一步理解体系、定义标准、守住边界。这个趋势不会停下我们能做的就是把技术底座做扎实让工具在规则内发光。
