当所有人都在讨论”用哪个 Agent 框架”时，真正站在潮头的编码智能体产品，几乎清一色选择了裸写循环。这不是巧合，而是一场值得深挖的架构哲学分歧。
一、一个反直觉的事实如果你在 2025 年之后接触过 AI 编程工具，大概率听说过这几个名字：Claude Code（Anthropic 官方 CLI）、Codex CLI（OpenAI 官方 CLI）、OpenCode（开源新秀）。它们是目前最炙手可热的一批编码智能体（Coding Agent）。
一个很容易想到的问题是：这些产品是用什么框架搭建的？LangChain？LangGraph？CrewAI？
答案出人意料——一个都没用。它们全部是基于模型厂商原生 API 自研的 Agent 循环。而且不只这三家：Aider、Cline、Gemini CLI、Goose、Pi……你能叫得上名字的主流编码智能体，几乎清一色走上了”无框架、裸写循环”的路线。
为什么？这篇文章试着把这件事讲透。
二、先破除一个误解：Agent 到底是什么在讨论框架之前，先对齐一个认知。很多人被复杂的框架术语（Agent 类、Executor、Graph Nod ...
最开始部署 New API 时，更新一次代码就要登录服务器、停容器、拉新代码、重新构建，再把服务启动起来。偶尔改个小功能，前后折腾几分钟不算什么；线上已经有人在用时，这几分钟就不太好接受了。
我想要的不是一套看起来很复杂的发布平台，而是一个足够稳妥的流程：代码放到自己的仓库，准备好版本后点一下构建，服务器自动启动新版本，确认没问题再把流量切过去；新版本不正常时，能够尽快切回旧版本。
最后落地的是一套小而实用的方案：Gitee 保存代码，Gitee Go 负责流水线，Docker 镜像放在镜像仓库，运行环境是另一家云厂商的 Linux 服务器，Nginx 负责入口切换。服务器不需要和流水线在同一家云上。
图 1：一次发布从代码到线上请求的完整链路。
先把几个概念分开这次最容易绕进去的地方，是把“源码在哪里”“镜像放在哪里”和“服务跑在哪里”当成了一件事。其实它们可以完全分开：
位置
负责什么
这次的选择
代码仓库
保存 Dockerfile、源码和流水线配置
Gitee
构建服务
根据代码构建镜像
Gitee Go
镜像仓库
保存带版本号的 Docker 镜像 ...
2026 年 8 月 17 日，我看到 Tibo Sottiaux 在 X 上发了一组 Codex 配置：选择 gpt-5.6-sol，把上下文预算设为 100 万 Token，并在 90 万 Token 左右开始压缩旧历史。
帖子里有两个数字需要分开看。OpenAI 官方模型页列出的 GPT-5.6 Sol 上下文窗口是 1,050,000 Token，Tibo 写进 Codex 的预算是 1,000,000 Token。这组设置针对 Codex 客户端，不是 chatgpt.com 的设置，也不能直接套到其他 GPT-5.6 型号上。
Tibo 的原帖到底说了什么？我把原帖的核心部分截在下面，方便和配置逐项对照。Tibo 的公开账号简介写的是 “Codex & ChatGPT @OpenAI”。
图 1：Tibo 原帖的核心部分，完整内容和一次性 CLI 命令可以点开原帖查看。
帖子主要说了五件事：
GPT-5.6 Sol 的官方模型规格支持 1,050,000 Token 上下文窗口。
Codex 的默认上下文限制经过了性能和成本调优，默认不开到最大值。
用 ...
API 中转站是位于应用和模型厂商之间的一层 API 网关。你仍然通过 API Key 调用模型，但请求先到中转站，再由中转站转发给 OpenAI、Claude、Gemini、DeepSeek 等上游服务。中转站一般会比官方 API 便宜，这也是大多数人选择它的主要原因。
不过，不同中转站的可信度差别很大。有些商家会偷偷进行模型映射、在后台调整倍率，或者保留用户的请求内容。选择中转站不能只看低价，还要看模型、计费和隐私规则是否透明。
如果你只是想找一个便宜、透明的 OpenAI API 中转站，可以直接试试我自己使用并维护的 newapi.zahml.top：计费公开透明，部分模型最低 0.07 倍率，并且不会保存用户提交给模型的请求与对话内容。
API 中转站是什么？一次请求的链路可以简化为：
123456Codex / Claude Code / CursorCline / OpenCode / Roo Code ↓ API 中转站 ↓ OpenAI / Claude / Gemini 等模型
中转站负责校验 Ke ...
大模型的上下文缓存是什么？从底层原理到 GPT、Claude 的长对话策略使用 GPT、Claude 等大模型进行编程时，经常会出现这样的情况：刚开始对话只有几千 Token，经过多轮代码分析、工具调用和报错修复后，上下文很快就增长到几万甚至几十万 Token。
表面上看，模型每一轮都需要重新读取完整历史：
123456789系统提示词项目规范工具定义用户第一轮问题模型第一轮回答用户第二轮问题模型第二轮回答……当前问题
如果每次都按普通输入重新计算，长对话的费用和响应时间都会快速上升。Prompt Caching，也就是提示词缓存，正是为了解决这种重复计算问题。
不过，缓存并不意味着“历史对话免费”，也不意味着对话可以无限增长。理解它的底层逻辑后，才能真正用好长上下文。
缓存到底保存了什么？大模型收到一段输入后，并不是简单地把文字读进内存。
输入文本首先会被分成 Token，然后经过模型每一层的注意力计算。在这个过程中，模型会为已经处理过的 Token 生成 Key 和 Value 等中间表示，通常统称为 KV Cache。
可以把它理解为：
123456789原始输入 ↓Tok ...
2026 年国内外主流大模型 API 价格对比：GPT、Claude、Gemini、DeepSeek、Kimi、千问、MiniMax 怎么选？大模型能力越来越强，但不同厂商的计费方式也越来越复杂。
除了最基本的输入 Token 和输出 Token，现在还需要考虑：
缓存读取价格
缓存写入价格
长上下文阶梯价格
思考 Token
Batch 批处理折扣
Priority 优先服务
不同地区的部署价格
限时活动和分时折扣
本文整理了目前国内外主流厂商最新、最常用的模型，重点对比官方 API 价格、缓存价格、模型定位和适用场景。
本文价格统计截至 2026 年 7 月 21 日。除特别说明外，价格均为每 100 万 Token，即每 1M Tokens 的价格。本文比较的是厂商官方 API，不是 ChatGPT、Claude、Gemini 等网页会员订阅价格，也不包括第三方中转站加价。
一、先看懂大模型 API 是怎么收费的一次普通模型请求的费用，通常可以简化为：
1234请求费用 =输入 Token 数量 ÷ 1,000,000 × 输入单价+输出 Token 数量 ÷ 1,00 ...
深入理解 Java 并发中的 synchronized 与 volatile在 Java 并发编程中，synchronized 和 volatile 是两个非常基础但又非常容易混淆的关键字。很多人在刚开始学习并发时，会简单地认为它们都是“保证线程安全”的工具，但实际上二者解决的问题并不完全一样。
准确地说，volatile 主要解决的是可见性和有序性问题，而 synchronized 解决的是更完整的线程安全问题，包括原子性、可见性和有序性。理解这两个关键字的核心，不是死记硬背它们的语法，而是要先理解 Java 并发中到底会出现什么问题。
并发问题的本质在单线程程序中，代码通常按照我们写下的顺序执行，变量被修改之后，后面的代码马上就能看到这个修改。但在多线程环境下，情况就复杂得多。
现代计算机为了提升性能，并不是每次读写变量都直接访问主内存。CPU 有自己的缓存，线程执行时也可能把变量值保存到寄存器或工作内存中。这样带来的问题是：一个线程修改了共享变量，另一个线程不一定能马上看到。
例如下面这段代码：
1234567891011121314class Demo { p ...
一文讲透 Java 代理模式：从静态代理、JDK 动态代理到 Spring AOP代理模式是 Java 中非常重要的设计模式，也是理解 Spring AOP、Spring 事务、MyBatis Mapper 代理、RPC 远程调用等技术的基础。
很多人第一次看代理模式时，会觉得它很简单：不就是在真实对象外面包了一层吗？
这个理解没有错，但还不够深入。
代理模式真正重要的地方在于：它让我们可以在不修改原始业务代码的情况下，对方法调用过程进行增强。
比如原来的业务方法只负责保存用户：
123public void save(User user) { System.out.println("保存用户：" + user);}
现在我们想在保存用户之前打印日志，在保存用户之后统计耗时。如果直接修改业务代码，当然可以实现，但这样日志、耗时统计、事务、权限等非核心逻辑就会和业务代码混在一起。
代理模式解决的就是这个问题。
它的核心调用链是：
1调用方 -> 代理对象 -> 真实对象
调用方并不直接访问真实对象，而是先访问代理对象。代理对象 ...
责任链模式：从 if else 到 Spring 自动装配一、责任链模式是什么？责任链模式，英文叫 Chain of Responsibility Pattern。
它的核心思想是：
一个请求来了，不是由一个大方法统一处理所有逻辑，而是交给一组处理器按顺序处理。每个处理器只负责自己的职责，处理完后继续交给下一个处理器。
简单理解就是：
1请求 -> 处理器 A -> 处理器 B -> 处理器 C -> 结束
比如在下单场景中，创建订单之前通常要做很多校验：
12345登录校验库存校验风控校验优惠券校验活动规则校验
如果全部写在一个方法里，就很容易变成一大堆 if else。
责任链模式就是把这些逻辑拆成一个个独立节点：
1LoginHandler -> StockHandler -> RiskHandler -> CouponHandler
每个节点只处理自己的事情。
二、为什么不用普通 if else？假设我们有一个下单方法：
12345678910111213141516171819public void createOrder ...
从拼团优惠系统理解策略模式：客户端选择、工厂模式与配置驱动在实际业务开发中，我们经常会遇到这样一种场景：同一个业务流程中，会根据不同条件执行不同的算法逻辑。
比如在一个拼团系统里，不同活动可能有不同的优惠方式：
1234普通拼团：直减 20 元新人拼团：满 100 减 30 元会员拼团：打 9 折限时拼团：满 200 减 50 元
这些优惠方式本质上都是“计算优惠价格”的不同算法。
如果我们直接把所有判断都写在下单代码里，代码很快就会变得臃肿。策略模式就是为了解决这类问题而出现的。
一、什么是策略模式？策略模式的核心思想是：
1把不同算法封装成不同的策略类，并让它们实现同一个接口。
放到拼团系统里，就是把“满减”“直减”“折扣”等优惠方式分别封装成不同策略。
比如定义一个优惠策略接口：
1234public interface DiscountStrategy { BigDecimal calculate(BigDecimal originPrice, DiscountRule rule);}
然后不同优惠方式分别实现这个接口。
1. 直减策略1234 ...
