AI on Renxin's Blog

你其实不需要更强的模型

Fri, 17 Jul 2026 00:00:00 +0000

你有没有这样一种感觉——

2023 年用上 GPT-4 的时候，那种震撼是真实的：它居然能写代码、能推理、能理解上下文。每发布一个新版本，你会迫不及待去试。但现在呢？GPT-5.6 发布了、Claude Fable 5 来了、Kimi K3 也出来了——你的第一反应是不是变成了：「哦，又强了一点。」

不是它们不够强。GPT-5.6 Sol 在复杂推理上确实甩开了上一代一大截。问题在于：你 90% 的日常任务，两三年前的模型就已经够用了。

这不是观点，是正在发生的现实。这篇不聊模型有多强，聊一个更实际的问题——为什么大部分 AI 项目依然在失败，以及真正该花精力在什么地方。

2026 年的模型版图

先看看我们现在有什么。

把今天的主流模型放在一张图里，按能力和价格两个维度看：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 经济层["💰 经济层
$0.10-0.50/1M 输入"] -->|"80% 日常任务"| 日常["分类/提取/摘要
客服/简单推理"]
 主力层["🔋 主力层
$2-3/1M 输入"] -->|"15% 复杂任务"| 复杂["多步推理
长文档分析"]
 旗舰层["🚀 旗舰层
$5-10/1M 输入"] -->|"5% 特殊场景"| 特殊["高难度代码
研究级分析"]
 style 经济层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 主力层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 旗舰层 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 日常 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 复杂 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 特殊 fill:#fef3c7,stroke:#d97706,color:#78350f

数据来源：OpenRouter API（2026-07 实时定价），涵盖 344 个模型。OpenAI GPT-5.6 于 2026 年 7 月 9 日发布，Claude Fable 5 于 6 月 9 日发布。DeepSeek V4 Pro 于 4 月开源，1.6T 参数/49B 活跃参数，1M 上下文。Kimi K3 据称可媲美 OpenAI 和 Anthropic 的旗舰模型。

这张图的信息量比看起来大。注意定价跨度——旗舰层和主力层之间是 5-10 倍的价格差，和 DeepSeek V4 Flash 比更是 100 倍的差距。更深层的信号是：经济层的模型能力线已经远远到了日常任务「够用」的基准线之上。 日常任务不需要旗舰模型的原因不是「没钱」，是「没必要」。

80/15/5 的分层现实

那实际在用的时候是怎么选的？

以我托管的 hermes-home 多 Agent 系统为例——它跑着 7 个 Agent，每天处理调研、写作、决策分析、知识管理等任务。实际用量比例：

层级	模型	用量	场景
经济层	DeepSeek V4 Pro（$0.44）	~80%	日常推理、内容生成、知识检索、决策辅助
主力层	GPT-5.6 Luna（$1.00）	~15%	需要更强推理能力的复杂任务
旗舰层	GPT-5.6 Sol / Claude Fable 5	~5%	高难度代码生成、架构设计、研究级分析

这不是预算问题。换成 DeepSeek V4 Pro 每百万 token 只需 $0.44，全跑旗舰模型（Claude Fable 5 $10/1M）也就多花二十几倍。真正的原因是：对于 80% 的任务，换旗舰模型的提升用户感知不到。

写一篇博客、整理一份调研、做一个决策分析——这些任务 DeepSeek V4 Pro 完成得很好。只有当你需要处理极其复杂的推理链条、或者生成需要深度理解上下文的高难度代码时，旗舰模型的优势才会显现。而且即便是这些时候，差距也在快速缩小：DeepSeek V4 Pro 的 Benchmark 已经追平了两年前的旗舰模型。

现在，旗舰模型针对的是「不可能轻松做到的业务」，是「需要博士级的研究分析」，是「5% 的场景」。大部分公司的绝大部分业务和大部分个人的日常任务，处在那个 80% 的范围内。

AI 项目真正的死因

如果模型已经够用了，那为什么那么多 AI 项目还是失败了？

RAND 公司对 65 个企业 AI 项目的元分析给出了一个发人深省的数字：80% 的企业 AI 项目以失败告终。 Gartner 的追踪数据给出了类似的结论，MIT 的研究甚至将这个比例推高到了 95%。这些项目不是用 DeepSeek V4 Pro 做的——很多花了大价钱上了最好的模型。

导致项目失败的原因，排在最前面的从来不是「模型不够聪明」。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 模型["📈 模型能力
飞速提升"] -->|"但……"| 失败["⚠️ 80-95% 项目失败"]
 失败 --> 根因["为什么失败？"]
 根因 --> 需求["❌ 需求没挖对
解决了错误的问题"]
 根因 --> 成本["❌ 成本跑飞了
不分层 > 预算超支"]
 根因 --> 工程["❌ 工程不靠谱
缺乏可观测性和错误处理"]
 style 模型 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 失败 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 根因 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 成本 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 工程 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

数据来源：RAND 企业 AI 元分析（65 个项目，80% 失败率）、MIT 研究（95% 企业 AI 项目未交付价值）。

我跑了几个月多 Agent 系统，最深的感受就是：模型从来不是瓶颈。 出错最多的地方，永远是需求没对齐、成本估算偏差、以及系统工程的细节。

真正卡脖子的三件事

如果瓶颈不是模型，那是什么？基于实战观察，我认为有三件事比模型选型重要得多。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 旧认知["过去以为瓶颈
是模型能力"] --> 新认知["实际瓶颈
（三件事）"]
 新认知 --> 需求挖掘["🔍 需求挖掘
解决对的问题"]
 新认知 --> 成本控制["💰 成本控制
分层选型不跑偏"]
 新认知 --> Agent工程["⚙️ Agent 工程
可靠系统需要 Engineering"]
 style 旧认知 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 新认知 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求挖掘 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 成本控制 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style Agent工程 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

需求挖掘：你确定你在解决对的问题？

大部分 AI 项目死得冤枉。团队花了几周时间搭建一个完美的 RAG 流水线，上线后发现用户根本不需要这个功能。或者花了大价钱微调了一个模型，结果业务需求已经变了。

这不是技术问题，这是需求挖掘问题。一个简单的判断标准：你能否一句话说清楚「这个 AI 系统做成了，用户的什么行为会改变？」 如果你说不清楚，模型再强也没用。

真实教训：hermes-home 里有一个 Agent 最早的设计是「帮我决定今天做什么」，上线后完全没人用。后来改成「帮我记录和管理待办事项」，用户每天在用。模型没换，Prompt 也没大幅改——换的是解决哪个问题。

成本控制：不分层的架构跑不远

很多团队的做法是：选一个最强的模型，全量流量都走它。结果第一个月账单出来，团队傻眼了。

分层的逻辑很简单：不是所有请求都值得用最好的模型处理。 80% 的请求可以用 DeepSeek V4 Pro 甚至 V4 Flash，15% 需要 GPT-5.6 Luna 级别，只有 5% 需要动用旗舰模型。

实操层面，成本优化的手段远不止分层：

语义缓存：重复查询命中缓存，彻底省掉模型调用
Prompt 压缩：精简历史记录和上下文，减少 token 消耗
Fallback 链：小模型先处理，处理不了再升级到大模型
输出长度控制：很多场景不需要完整输出，设置 max_tokens 能省一大半

2026 年的行业共识是：一个设计良好的分层架构，可以将 LLM 成本降低 30-50%，同时保持 95% 以上的用户体验不下降。

Agent 工程：能力是 Engineering 出来的，不是模型送过来的

这是最容易被忽视、但也是真正的壁垒所在。

从 GPT-3.5 到 GPT-5.6，模型能力在涨。但把一个 LLM 从「能回答问题」变成「能可靠地完成一个任务」，需要的是一整套工程能力——

Tool 设计：模型需要知道自己有什么工具可用，每个工具的输入输出是什么，什么时候该用哪个
Memory 管理：会话历史、长期记忆、知识库检索——怎么存、怎么查、怎么不爆上下文
错误处理：模型调用超时怎么办？工具返回异常怎么办？重试逻辑怎么写？
可观测性：每次调用花了多少 token？哪个环节耗时最长？出错了怎么定位？
多 Agent 协作：多个 Agent 之间怎么发现彼此的能力、怎么传递任务、怎么避免冲突

这些东西，换再强的模型也不会自动变好。它们需要工程投入。

实战案例：一个跑在 DeepSeek 上的多 Agent 系统

hermes-home 是一个真实运行的多 Agent 系统，7 个 Agent 分布在云服务器和本地 Docker 中，通过 MCP 协议通信。这个系统 80% 的请求由 DeepSeek V4 Pro 处理。

它能做什么？

知识库 Agent 每天自动扫描 GitHub 新项目，整理入库
博客 Agent 从知识库拉取素材，写成 Hugo 文章并部署
待办 Agent 管理日常任务并定时提醒
决策 Agent 综合分析多个来源，给出结构化建议

所有这些任务，没有一个需要用到 Claude Fable 5 的全能力量。系统的瓶颈从来不在模型能力上——而是在 Tool 设计得够不够好、Memory 管理得够不够稳定、错误处理得够不够健壮。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 subgraph 模型层["模型层 (80% DeepSeek V4 Pro)"]
 A["LLM 推理"]
 end
 subgraph 工程层["工程层 (真正的壁垒)"]
 B["Tool 系统"]
 C["Memory 管理"]
 D["错误处理"]
 E["可观测性"]
 end
 subgraph 应用层["应用层"]
 F["7 个 Agent
调研/写作/决策/待办"]
 end
 A --> B --> C --> D --> E --> F
 style 模型层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 工程层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 应用层 fill:#fef3c7,stroke:#d97706,color:#78350f

我花了大量时间优化的是中间这一层——Tool 的接口设计、Memory 的持久化策略、错误恢复逻辑、以及每次调用链路的可观测性。这些才是真正决定系统质量的因素。模型只要「够用」就行。

下次有新模型发布的时候，先问自己三个问题：

我的瓶颈真的是模型能力吗？ ——还是需求没挖对、成本没控好、工程没做扎实？
换模型能解决我的什么问题？ ——它会让用户感知到显著提升吗？
我的系统有足够好的可观测性吗？ ——如果你不知道每次调用花在哪、错在哪，换模型就是盲人摸象。

模型在飞速进步，这是好事。但 90% 的日常任务已经越过了「够用」的基准线。 真正的差距，从来不在模型本身。

数据来源：OpenRouter API 实时定价、DeepSeek 官方发布公告（2026-04-24）、OpenAI GPT-5.6 官方公告（2026-07-09）、Anthropic Claude Fable 5 公告（2026-06-09）、RAND 企业 AI 项目元分析、AP News Kimi K3 报道。

县城正在消失，而你还在犹豫要不要走

Fri, 17 Jul 2026 00:00:00 +0000

你有没有在夜间卫星地图上注意过一个细节——

北上广深的灯光像超新星一样向外蔓延，长三角、珠三角连成一片光海。而越往内陆走，那些曾经亮着星星点点灯光的地方，正在逐年暗淡。

这不是停电。这是一个正在发生的经济地理学事实：县城在消失。

不是物理消失，而是从资源版图上被剥离。

2026年的中国经济版图上，正在发生一场静默的断裂。一边是AI产业以举国之力狂奔，算力中心日夜不熄，海量资金涌入北上广深的核心研发圈；另一边是两千多个县城，机构缩编、学校撤并、年轻人外出不再回来。

这两件事之间有一根隐蔽的管道——资源正在从县城被系统性抽走，注入大城市的新质生产力机器。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 subgraph 大城市["💡 大城市"]
 direction TB
 L1["灯光如超新星
向外蔓延"]
 L2["AI产业聚集
资源持续注入"]
 end

 subgraph 县城["🌑 县城"]
 direction TB
 R1["灯光逐年暗淡"]
 R2["产业萎缩
人口外流"]
 end

 大城市 -->|"虹吸资源"| 县城

 style 大城市 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 县城 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style L1 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style L2 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style R1 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style R2 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

两套政策，一张底牌

如果你把近三年中国关于AI的支持政策和关于县城的政策放在一起看，会发现这不是两套并行的体系，而是一次明确的资源重新配置。

AI那一侧的关键词是「新型举国体制」「不惜代价」「资金狂奔」。从中央经济工作会议将新质生产力定为绝对核心驱动力，到东数西算工程、万亿产业大基金源源不断注入特定国家级算力枢纽——AI产业享受的是无限弹药的特权。

县城那一侧的关键词则变成了「过紧日子」「底线思维」「战略降级」。中央要求人口小县推行机构改革，山西试点县党政机构被砍掉三分之一，事业编制缩减六成。国务院明确下文，要求中西部12个债务高风险省份严控甚至停建新建政府投资项目。县城的主体功能定位，被严格限制在了保证粮食安全、生态安全和服务农业农村上。

翻译成大白话就是：你在后方待着，别添乱。

这不是歧视，这是财政分配的现实逻辑。在经济高速增长的年代，国家可以一边给大城市输血，一边通过转移支付给县城修路。那时叫雨露均沾。但现在进入了存量博弈的时代，当国家需要集中几万亿甚至几十万亿去搞大模型、算力中心、黑灯工厂的时候，这笔钱只能通过压缩对县城的转移支付来筹措。

国家对大城市AI产业的每一次巨额注资，本质上都是对县城资金的一次合法抽血。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 subgraph 中央["💠 中央财政"]
 财源["财政资金"]
 end

 subgraph AI方向["🚀 AI/新质生产力"]
 A1["万亿产业基金"]
 A2["算力中心补贴"]
 A3["芯片研发投入"]
 end

 subgraph 县城方向["🏘️ 县城"]
 B1["转移支付缩减"]
 B2["机构编制压缩"]
 B3["基建项目叫停"]
 end

 财源 --> 优先分配
 优先分配 --> A1
 优先分配 --> A2
 优先分配 --> A3
 优先分配 -.->|压缩| 县城方向
 style A1 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style A2 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style A3 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B1 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style B2 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style B3 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 财源 fill:#fef9c3,stroke:#ca8a04,color:#713f12

雁行模型的失效——廉价劳动力不再值钱

过去三十年，中国县城之所以还能保住一点工业基础、还能缓解一部分人的就业，全靠一个产业转移机制。

大城市是头雁。当北京上海深圳的土地和人口成本高到一定程度，那些需要大量劳动力的低端制造业，就会像大雁排队一样，先转移到内地的二线城市，最后落到广大的中西部县城。

这个模型成立的唯一前提是劳动力成本的差异。县城招商引资最大的也是唯一的底牌就是：我这里人工便宜，只要两三千块钱，地皮几乎白送。

但到了2026年，这张底牌正在失效。

AI和智能机器人直接抹平了地理空间上的劳动力成本差异。试想一个场景：如果富士康或比亚迪要扩建产能，它是会把工厂建在距离深圳一千公里外、交通不便、配套落后的内地县城，去管理几万个每月拿三千块的工人，还是会在深圳周边的东莞或惠州，直接建一个全自动化的黑灯工厂？

答案显而易见。

搭载了最新AI视觉检测系统、多柔性机械臂的智能生产线全面普及之后，工厂可以24小时无休运转。这些机器人不用交社保、不需要住宿、没有情绪波动、良品率接近100%。即便精算到极致，在长三角珠三角布置一个机器人工位的综合成本，也一定会远远低于中西部县城一个最廉价工人的最低工资。

既然机器的成本比县城的人工还要低，大企业为什么还要大费周折把产业链向内陆转移？它们完全可以把高度自动化的工厂留在核心城市周边——这里有世界级的港口、即刻可用的现代化物流、以及庞大的都市消费市场。

这就是新质生产力带来的产业空间折叠。过去产业是分散的，因为人需要吃喝拉撒，需要分布在不同地理空间里。但在AI时代，产业是极度集权的——它不再依赖人，只依赖算力和电力。

这不仅仅掐断了低端产业向中西部县城转移的生命线，更可怕的是，它还在反方向地绞杀县城原本仅存的初级加工制造业。在机器面前，县城最后的那点廉价劳动力优势，彻底归零了。

资本不再需要廉价的人，资本需要的是廉价的算力和不知疲倦的机械臂。

过去，产业沿着成本梯度向下转移：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 A1("一线城市
成本上升") -->|产业外迁| A2("二线城市
承接转移")
 A2 -->|产业外迁| A3("县城
靠廉价劳动力接盘")
 style A1 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style A2 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style A3 fill:#d1fae5,stroke:#059669,color:#064e3b

现在，AI 让产业不再依赖人，工厂留在了城市圈：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 B1("一线城市
AI + 机器人") --> B2("黑灯工厂
留在城市圈周边")
 B2 -.->|县城被踢出| B3(❌)
 style B1 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B2 fill:#d1fae5,stroke:#059669,color:#064e3b
 style B3 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

AI产业的三个要素，每一个都在排斥县城

传统工业时代，基础设施是可以下沉的。你修一条公路到县城，县城就能通车；你拉一根电线到县城，县城的灯就亮了。

但AI产业的核心要素——算力、数据、算法人才——都具有极端空间排他性，每一个都在天然地抛弃县城。

算力：建设一个顶级的大模型算力中心，不仅需要几百亿的硬件投入，还需要特高压专线电网来保证绝对不能断电，需要海量的水资源来进行液冷散热，需要极低延迟的骨干光纤网络。这些资源国家不可能平均分配给每一个县城——这不经济，也不符合规模报酬递增的规律。更残酷的是，在夏季用电高峰期，为了保证东部核心城市的AI算力中心不断电，中西部某些省份的传统高能耗产业会被行政命令要求错峰生产——让电于算。

数据：高价值的数据来自高密度的数字场景——千万级的日活用户、亿级的交易记录、复杂的线上交互行为。县城没有这些。县城的数字活动是碎片化的、低频的、低价值的。数据不是均匀分布的，它是跟产业密度绑定的。

人才：AI领域的顶尖人才天然向最前沿的公司和机构聚集。这不是因为"大城市好"，而是因为最好的同事、最多的GPU、最快的信息流动都在那里。县城走出去的高端人才，几乎不可能回流。

更隐蔽也更残酷的是AI产业的乘数效应差异。

传统工业时代，一个主导产业会拉动上下游一系列配套产业：汽车工业会拉动钢铁、橡胶、玻璃等上游产业，同时催生公路、加油站、维修店等下游产业。这些关联产业需要大量物理空间的劳动力，财富分配是发散型的，能够惠及县城和小镇。

但人工智能产业是一个极度罕见的高密度、闭环、单轴产业。它对上下游的索取表现为完全的虹吸而非溢出。上游的算力与芯片抽干县城的廉价电能，中游的模型与算法虹吸县城走出去的全部高端人才，下游的应用则清洗县城本地的中产。

AI产业链的运行逻辑，本质上就是 大城市开机、大厂收钱、县城失业、资金北上 的财富单向流动机器。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 传统["🏭 传统工业"] -->|"发散型就业→惠及县城"| A["县城受益"]
 AI["🤖 AI产业"] -->|"虹吸型资源→抽干县城"| B["县城受损"]
 style 传统 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style AI fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style A fill:#d1fae5,stroke:#059669,color:#064e3b
 style B fill:#fecaca,stroke:#dc2626,color:#7f1d1d

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 上游["⚡ 上游
算力+芯片"] -->|电能| 县城["🏘️ 县城"]
 中游["🧠 中游
模型+算法"] -->|人才| 县城
 下游["📱 下游
AI应用"] -->|岗位| 县城
 上游 --> 中游 --> 下游
 style 上游 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 中游 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 下游 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 县城 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

县城经济循环的崩塌，正在无声发生

在经济学中有一个核心概念叫「乘数效应」——一笔初始支出的变动，会通过经济体系内多轮循环消费，引发国民收入数倍于该初始支出的变动。

在过去的健康状态下，县城的经济循环是这样的：

外出打工的人寄钱回家 → 这笔钱发给县城的公务员、教师、工程老板 → 这批体制内中产和工程中产去饭店消费、去商场买衣服、去本地学校交学费 → 饭店老板和商场员工赚到了钱，再去菜市场买菜 → 养活县城底层的体力劳动者。

每一块钱在县城内部流转多次，就能创造出数倍的社会总价值。这就是县城的生命线。

但现在，三重打击正在让这个循环发生剧烈的负乘数效应。

第一重打击：外出收入减少。 大城市工厂全面换上机器人，服务业开始裁减人工。县城流出人口在大城市能赚到的钱正在大幅缩减。寄回家的汇款少了，县城消费的第一笔源头就断了。

第二重打击：工程老板群体消失。 顶层设计将资金集中于AI算力投资，县城传统基建项目被全面叫停。工程老板——这批县城最富有的群体——集体熄火了。没有他们的高消费，县城里高档餐厅、汽车维修店、建材市场这些依靠工程群体生存的产业，同步萎缩。

第三重打击：体制内中产萎缩。 AI大模型正在替代县城的白领岗位——会计、审批人员、文员。再加上人口小县机构改革对编制的大幅缩减，县城里唯一具有持续消费能力的体制内和半体制中产，数量正在急剧缩减。

当这三重打击叠加发生，负乘数效应就开始循环放大：

中产不再消费 → 餐馆倒闭 → 菜贩失去收入 → 保洁、搬运工等底层零工也接不到活 → 所有人都在缩减开支 → 更多店铺关门 → 更多就业岗位消失。

这就是AI和新质生产力背景下，发生在县城底层的、无声无息的经济链式死亡。

财富被AI技术和国家战略以最高效的方式抽调、压缩、打包，送往了大城市。留给县城的，只是一潭死水。

过去，县城的经济循环是正向的：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 P1["外出收入汇回"] --> P2["体制内中产消费"]
 P2 --> P3["餐饮/零售/教育等服务"]
 P3 -.->|循环放大| P1
 style P1 fill:#d1fae5,stroke:#059669,color:#064e3b
 style P2 fill:#d1fae5,stroke:#059669,color:#064e3b
 style P3 fill:#d1fae5,stroke:#059669,color:#064e3b

但现在，三重打击形成了负向的死亡螺旋：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 N1["①外出收入减少
②工程老板消失
③体制内中产萎缩"] --> N2["中产消费降级"]
 N2 --> N3["餐馆倒闭、底层失业"]
 N3 -.->|循环放大| N1
 style N1 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style N2 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style N3 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

三个不会说谎的硬指标

逻辑推理可能出错，但数据不会。这里有三个判断县城是否在衰落的硬指标。

第一个指标：存贷差。

这是判断一个地区有没有造血功能最准确的标志。近些年，许多中西部县城的银行数据呈现出诡异的特点：居民存款在上升，但当地企业贷款的发放量却在持续下跌。

这意味着什么？

老百姓把辛辛苦苦存下来的钱放进县城的银行，但银行因为当地没有能产生利润的新产业，根本不敢把钱贷给本地企业。更糟糕的是，县城银行的分支机构拿到这笔存款后，通过金融系统内部的资金调度，把这些钱上交给省行和总行。总行拿到钱后，转头就把贷款额度发放给了北京、上海、深圳搞芯片、大模型、自动化工厂的科创巨头。

结论很清楚：县城的金融系统已经完全异化为一台巨大的资金抽水机。 县城老百姓的血汗钱通过金融工具，转化成了大城市AI公司的研发弹药。县城在用自己的血，养活大城市的再生长。

第二个指标：小学生在校人数。

房地产研究员和人口经济学家判断一个城市未来五年基本面的最常用指标，就是小学生在校人数。因为这个数据最真实——学籍很难造假，家长也必须跟着孩子走。

从2024到2026年，绝大多数普通县城的小学生在校人数出现了肉眼可见的下降。背后的推力一方面是总和生育率下降，但更致命的是公共资源的逆向虹吸。国家把钱砸向新基建，县城就没钱了，于是县里开始强制撤并乡村和普通公办学校。但凡有一点认知和购买力的家长，为了不让孩子在教育上掉队，把孩子送往地级市甚至省会去读书，并在那里买房租房。

在经济学中，孩子是一个家庭资源投射的核心。县城学龄人口的断崖式下跌，意味着当地最有活力的中青年群体以及家庭的核心消费，正在对县城进行一场不可逆的物理逃离。

第三个指标：夜间灯光指数。

空间遥感经济团队通过对比近五年中国夜间灯光的卫星影像，发现了一个极度撕裂的趋势：北上广深、长三角、中三角等核心都市圈的灯光不仅亮度在增加，而且快速向外蔓延；而那些远离核心都市圈的中西部普通县城，其夜间灯光强度出现了显著的暗淡和收缩。

这是能源重配的视觉证据。大城市的万家灯火如同夜空中的超新星，吞噬着海量电力，点亮了数字经济的版图。而县城，因为传统高能耗产业被打压、工厂停工，不仅厂房黑了，连路灯都在被节能改造。

三个指标叠在一起，就是一份对县城衰落的判决书。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 存贷差["📊 存贷差
存款流向大城市企业"] ---> 结论
 学生数["📚 在校生数
学龄人口物理逃离"] ---> 结论["📋 判决书：
县城正在衰落"]
 灯光["🌙 夜间灯光
县城逐年变暗"] ---> 结论

 style 存贷差 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 学生数 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 灯光 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 结论 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

个体怎么办：不是恐慌，是规划

前面的分析不是让人绝望的。看清楚了趋势，反而可以开始行动。

在这个以新质生产力和算力集权为核心的大背景下，那些没有特定禀赋的普通县城，在宏观的战略沙盘里已经被正式定位为一种社会缓冲带——只需要按惯性待在那里，维持最低限度的消耗，不给前线正在打科技战的大城市添乱。

但个体完全可以主动选择。

第一条路：境内移民。

这不是今天收拾行李明天冲去北上广深。而是把你的人生坐标从"我出生在哪里"慢慢改成"哪里更值得我长期配置自己"。

一个三年的计划：

阶段	时间	任务
信息迁移	第一年	研究目标城市的招聘、房租、工资、产业、学校、医疗、生活成本
技能迁移	第二年	确保你的技能在目标城市能换到钱——如果不够，就补技能：编程、运营、设计、销售、护理、维修、跨境电商、短视频运营，至少选一个能在城市里交易的技能
身份迁移	第三年	社保、居住证、工作、租房、孩子教育、父母医疗，一步一步往目标城市挪

你不需要去最贵的一线城市。强二线和核心都市圈——杭州、成都、武汉、苏州、长沙——完全够用。关键不是买不买房，而是先问自己能不能在那边活下来。先租房、先找工作、先看行业、先建立人脉，先让自己在那个城市有一个落脚点。

普通人的迁移不是浪漫旅行，而是项目管理。你要有时间表，有预算表，有至少六个月的备用金，有一条撤退路线。

第二条路：不移民但接入。

如果你因为各种原因不能或不想离开县城，那么必须建立跨空间的货币获取能力——通过互联网和数字技术，从大城市的高势能网络中赚钱，而不是在县城里跟存量做内卷。

远程工作、自由职业、AI工具辅助的个体产出——这些东西不依赖你所在的地理位置，只依赖你接入网络的能力。如果你懂编程，可以远程接外包；如果你懂内容，可以做出海；如果你懂投流，可以在线上做生意。县城的生活成本低，只要你的收入来自大城市的渠道，你反而有套利空间。

这两条路并不矛盾，甚至可以并行。境内移民解决的是长期的安全边际，跨空间赚钱解决的是当下的收入来源。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 起点["你的选择"] --> 判断{"离开县城？"}
 判断 -->|"是"| 移民["📍 境内移民
三年计划：信息→技能→身份"]
 判断 -->|"否"| 接入["🌐 跨空间赚钱
远程工作/数字产出"]

 style 起点 fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style 判断 fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style 移民 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 接入 fill:#d1fae5,stroke:#059669,color:#064e3b

回到开头的卫星地图。

当一座城市的灯光在卫星图上逐年变暗，它不是消失了——它说明这座城市在资源版图上，正在变成"不被看见"的地方。

你不能决定资源怎么分配，但你可以决定自己往哪里移动。越早开始规划，选择权越大。等到所有人都想走的时候，你才发现自己没有技能、没有存款、没有社保、没有信息渠道——那才是真正的困境。

这件事情发生之前看起来离你很远，发生之后你才会知道：原来你所在的位置，决定了别人会不会及时看见你。

这不是鸡汤，这是生存。

本文观点来自对两期B站视频内容的梳理与分析。

AI Agent 入门：程序员视角的概念与实践

Sun, 05 Jul 2026 00:00:00 +0000

如果说 2024 年是"AI 聊天机器人"普及的一年，那么 2025-2026 年则是"AI Agent"从概念走向工程的一年。Claude Code、OpenAI Codex、Manus、Cline……越来越多的产品不再满足于"你问我答"，而是主动帮你完成任务——读代码、改文件、跑测试、甚至自己写一篇博客。

但 Agent 到底是什么？它和普通的 LLM 对话有什么区别？这篇文章将从程序员熟悉的概念出发，系统地梳理 AI Agent 的核心概念、关键特性和基础架构模式。

一、从对话到自主：Agent 的核心定义

最简单的定义来自 LangChain：

Agent = Model + Harness

翻译成程序员能理解的语言：Agent 不是更聪明的 LLM，而是把 LLM 装进了一个有工具、有记忆、有控制循环的"运行时环境"里。

你可以把 LLM 想象成一个天才程序员，但你只能跟他口头交流——他再聪明，不动手也写不了代码。Agent 就是给了这个天才一台电脑、一套工具链、和一份"你自己想办法搞定"的指令。

Anthropic 的 Barry Zhang 有一个更简洁的说法：

Agent = 在 Loop 中使用工具的模型

关键的区别在于：

特性	普通 LLM 对话	Agent
交互方式	一问一答	给定目标，自主行动
工具使用	不能	可以调 API、读写文件、执行命令
记忆	上下文窗口（易失）	持久化记忆（跨会话）
决策	用户决定下一步	自主决定下一步
错误处理	用户发现并纠正	自行检测和重试

二、Agent 的五个关键特性

从工程角度看，一个完整的 Agent 系统通常具备以下五个特性：

1. 工具调用（Tool-use）

Agent 不只"说"，还能"做"。通过工具调用操作外部系统——读文件、搜网页、发 API、执行命令。

💡 类比：工具的接口就像微服务的 API endpoint，有 schema、参数、返回值。Agent 根据任务自主选择调哪个"端点"。

2. 记忆（Memory）

Agent 需要跨会话记住你的偏好、工作环境、学到的经验。记忆分为多个层级：

文件层：MEMORY.md、USER.md 等结构化文件，持久化存储
语义层：向量检索，用于快速召回相关历史
上下文层：当前会话窗口，易失但高效

💡 类比：上下文窗口是 Redis（缓存，易失），文件系统是 PostgreSQL（持久存储）。

3. 规划（Planning）

复杂任务需要拆解。Agent 先制定计划（如 plan.md），再分步执行——每一步完成后再决定下一步做什么。

💡 类比：就像你写代码之前先画架构图、列 TODO 清单。Agent 也需要先规划再行动。

4. 自主决策（Autonomous Decision）

这是 Agent 和"带工具的聊天机器人"的本质区别。Agent 自主决定调哪个工具、用什么参数、是否重试。

关键设计原则：Error-as-Data。工具失败时，错误信息作为数据回写给 LLM，而不是抛异常——Agent 自己决定是重试还是换工具。

5. 验证与反馈（Verification）

Agent 需要自己检查结果是否正确。没有验证的 Agent 就像没有测试用例的 CI/CD 流水线——跑得再快也不知道对不对。

Boris Cherny（Claude Code 负责人）的一条核心经验：给 LLM 自我验证的能力，输出质量能提升 2-3 倍。

三、四层工程模型：理解 Agent 系统的骨架

这是理解 Agent 技术栈最清晰的可视化框架，由浅入深分为四层：

L4 Loop Engineering —— 设计替你跑 Agent 的系统
L3 Harness Engineering —— 怎么把 Agent 装好
L2 Context Engineering —— 怎么给 Agent 喂对信息
L1 Prompt Engineering —— 怎么把话说清楚

⚠️ 注意：四层是嵌套关系而非替代关系。L3 不覆盖 L2，而是在它上面叠加。

L1: Prompt Engineering

最基本的层次。研究"怎么写指令"能让 LLM 给出更好的回答。包括角色设定、示例引导、思维链（Chain-of-Thought）等技巧。

程序员熟悉的起点：就像写一个好的函数注释和调用说明。不同之处在于 Prompt 的"读者"是 LLM，它比编译器宽容得多，但也会产生你意想不到的输出。

L2: Context Engineering

这一层关注"给 LLM 什么信息"。Andrej Karpathy 提出的概念——长上下文不是银弹，关键是上下文的质量和结构。

核心实践包括：

渐进性披露：先给概要，逐步展开细节，避免信息过载
上下文窗口管理：当上下文超长时，如何压缩、优先排序、丢弃
结构化上下文：用 XML、JSON 等格式组织信息，让 LLM 更容易解析

💡 类比：Prompt Engineering 是"怎么问"，Context Engineering 是"给什么参考材料"。

L3: Harness Engineering

这是 Agent 工程的核心创新层。Mitchell Hashimoto（Harness Engineering 提出者）将其定义为：

围绕 LLM 构建一个"操作系统"——包括工具系统、权限控制、上下文管理、反馈回路、可观测性。

Harness 的四条铁律：

工具签名即文档 — 每个工具的名称、参数、返回值的设计本身就是使用说明
结果必须可验证 — 每一步的输出需要有明确的验证标准
错误不可沉默 — 所有失败必须可见并结构化回传（Error-as-Data）
渐进性披露 — 不要让 Agent 同时面对所有信息，按需呈现

LangChain 的 Deep Agents 项目做过一个令人印象深刻的实验：仅仅优化 Harness（不改模型），Terminal Bench 2.0 排名从第 30 位直接跃升至第 5 位。 这证明了瓶颈往往不在模型本身，而在"怎么装"。

L4: Loop Engineering

最高层次，研究"自动触发 Agent 的循环系统"。不是你自己跑一次 Agent，而是系统定期或按事件自动启动 Agent。

Boris Cherny 的实践是代表性案例——他不再"提示"Claude，而是"写循环"（I don’t prompt Claude anymore. I write loops.）。

典型的 Loop 模式：

事件驱动：文件变更 → 自动触发代码审查
定时任务：每日自动抓取信息、生成摘要
Pipeline：多个 Agent 接力完成复杂工作流

四、基础架构模式

4.1 ReAct Loop（核心循环）

ReAct（Reasoning + Acting）是所有现代 Agent 的基座模式。它的执行循环可以用一行伪代码概括：

while (task_not_complete) {
 think() // 推理：当前状态 + 下一步做什么
 act() // 行动：调用工具或生成输出
 observe() // 观察：收集执行结果
}

Manus、Cline、Claude Code 都是 ReAct Loop 的具体实现。不管上层叠了多少层 Harness 或 Loop，最底层永远是 observe-think-act 这个基本循环。

💡 类比：一个 while(true) { think → act → observe } 的事件循环。Agent 每次迭代都自主决定是调用工具还是给出最终答案。

4.2 Plan-and-Execute

Agent 先制定完整计划，再分步执行。典型流程：

Init 阶段：分析任务，生成 plan.md，分解为子步骤
Exec 阶段：按计划逐步执行，每步完成后更新进度
Check 阶段：验证结果是否符合预期，必要时回退或修正

这种模式的优点是任务可追溯、可断点续传。缺点是灵活性不如纯 ReAct——当实际情况偏离计划时，需要 Agent 具备"重新规划"的能力。

4.3 Tool-use 模式

专门优化工具调用的架构，关键要点：

工具名用动词短语：parse_resume、score_match，而不是 resume_tool、match
参数含正反面说明：告诉 LLM 什么情况下用什么参数
返回值结构稳定：格式可预测，方便 LLM 解析
工具隔离：每个 Sub-Agent 只装它真正需要的工具

4.4 MCP 协议

MCP（Model Context Protocol）是 Anthropic 提出的工具层标准协议。可以理解为 Agent 世界的 USB 协议——任何工具只要实现 MCP，就能即插即用。

“OneAgent + MCPs” 范式正在成为趋势：用一个统一的基础 Agent，通过不同领域的 MCP 服务器扩展能力，代替传统的"每个场景一个独立 Agent"的模式。

五、关键术语速查表

术语	一句话解释	程序员类比
Agent	能自主决定下一步做什么的 LLM	一个有 main loop 的微服务，每次迭代自己选路由
LLM	Agent 的"大脑"，负责推理和决策	一个超级强大的 if-else 引擎，输入是自然语言
Tool	Agent 操作外部世界的接口	微服务的 API endpoint，有 schema、参数、返回值
Memory	跨会话持久化知识	数据库（持久层）+ 缓存（上下文窗口）
ReAct Loop	基础执行循环	`while(true) { think → act → observe }`
Harness	把 Agent 装起来的"操作系统"	相比"怎么写"（Prompt），优化"怎么装"
Loop	自动触发 Agent 的循环系统	cron + event-driven 架构
Workspace	Agent 的"当前工作目录"	不是变量，是 git 仓库——每一步可回放、可审计
Verifier	检查 Agent 输出是否正确	断言之于测试
Skill	可复用的知识包	插件系统 + 懒加载库
MCP	工具层的标准协议	Agent 世界的 USB 协议

六、从哪里开始？

如果你是一个有编程基础的程序员，想开始实践 Agent 工程，以下资源值得关注：

一手信息源（英文，需网络环境）

来源	推荐理由
Lilian Weng, “LLM Powered Autonomous Agents”	Agent 入门圣经，系统讲工具调用、记忆、规划三大支柱
Anthropic, “Build Effective Agents”	官方最佳实践，简洁实用
Mitchell Hashimoto 博客	Harness Engineering 原创者
Boris Cherny, howborisusesclaudecode.com	Claude Code 之父，loop 实战
Addy Osmani Substack	Loop Engineering 提出者

国内可访问的中文资料

文章	来源	推荐角度
Agent Harness 工程实践	阿里云开发者	Harness 定义 + 四条铁律
Harness 工程之道：Skill 原理与最佳实践	阿里云开发者	渐进性披露、Skill 目录结构
Loop Engineering 四层模型	腾讯云开发者	四层嵌套框架（本文骨架来源）
OneAgent + MCPs 范式	阿里云开发者	Agent 发展四阶段模型
Boris Cherny 的 /loop 实战	歪脖抠腚	验证先行、CLAUDE.md 知识积累

七、结语

回到最核心的那句话：Agent = Model + Harness。

模型本身的能力固然重要，但工程落地的瓶颈往往不在模型够不够聪明，而在有没有把它装好。Prompt Engineering 只是起点，往上还有 Context Engineering（喂对信息）、Harness Engineering（装好系统）、Loop Engineering（自动化循环）——每一层都是值得深入的方向。

从今天开始，不妨试着用 Agent 的思维来思考问题：不是"让 AI 帮我回答这个问题"，而是"给 AI 一个目标、一套工具、一个自主决策的环境，让它自己去搞定"。

这才是 Agent 时代真正的编程范式转变。