全新的 AI 技术栈：模型、工具层、循环机制与自我进化的 Agents

大家都在谈论 AI 模型。

但没人谈论那个真正让它们变得有用的层面。

Claude Code、Codex、Cursor。

这些不仅仅是模型。

它们是包裹在系统里的模型。

这个系统叫做“操控系统”（harness）。

而现在，最好的操控系统能够自我改进。

以下是关于全新 AI 技术栈你需要了解的一切。

关于 AI 产品，人人都相信的一个谎言

大多数人认为 AI 的进步 = 更智能的模型。

事实并非如此。

模型只是技术栈的一部分。

架构是公开的。大家都在复制同样的 Transformer。每个实验室都在使用相同的构建模块。

真正将 Claude Code 与一个周末项目区分开来的，不是模型。

而是模型周围的一切。

是操控系统。

2017 年，AI 的进步在于注意力机制。2020 年，在于规模。2026 年，则在于操控系统工程。

而现在，操控系统正由 AI 而非人类设计。

什么是操控系统？

操控系统是围绕模型的系统。

它决定：

→ 模型如何思考和规划

→ 何时调用工具以及如何处理结果

→ 在步骤之间记住什么

→ 如何存储工件和管理状态

→ 如何评估自己的输出

→ 何时循环重试

把它想象成一个操作系统。

模型是 CPU。操控系统是 OS。

你可能有强大的 CPU 和糟糕的软件，最终什么都交付不了。你也可能有普通的 CPU 和优秀的软件，却能交付出色的产品。

最成功的编码 Agent——Claude Code、Codex、Cursor——都有相同的洞见：

循环与模型同等重要。

每个 AI 构建者都需要了解的 3 种操控系统模式

每个生产级 AI 系统至少使用其中一种。

模式 1：循环

模型不会只回答一次就停止。

它会循环。

规划 → 执行 → 观察 → 改进 → 重复

这是每个编码 Agent 的核心。

一个简化的 Claude Code 循环：

1. 读取任务
2. 规划方法
3. 编写代码 → 运行它
4. 查看哪里失败了
5. 修复它
6. 再次运行
7. 重复直到测试通过

模型在第 3 次循环时并不比第 1 次更聪明。

但系统是。

每次循环都为模型提供新的上下文——错误信息、测试结果、执行轨迹。

第 1 次循环的输出成为第 2 次循环的输入。

这种复合上下文正是 Agent 系统在复杂任务上优于单次提示的原因。

关键洞见： 模型保持不变。上下文变得更智能。

模式 2：文件系统作为记忆

大多数开发者把所有东西都塞进上下文窗口。

这是一个陷阱。

长期任务会产生：

→ 实验日志

→ 代码差异 → 错误追踪

→ 过去的发布历史 → 论文摘要 → 中间工件

所有这些都会远远超出任何上下文窗口的容量。

解决方案：写入文件，而不是写入上下文。

1# 错误做法：所有东西都在上下文里
2context = previous_output + tool_result + error_log + history...
3# 在第 47 步就会爆炸
4
5# 正确做法：使用文件系统
6agent.write("experiments/run_3/error_log.txt", error_trace)
7agent.write("experiments/run_3/results.json", metrics)
8
9# 之后，Agent 只读取它需要的内容
10relevant = agent.read("experiments/run_3/results.json")

这彻底改变了长期任务的处理方式。

→ Agent 可以在崩溃后恢复

→ Agent 可以推理自己的执行历史

→ 即使到第 200 步，上下文也保持干净

→ 多个子 Agent 可以通过文件共享状态

最好的 Agent 将文件系统视为第二大脑。

不是垃圾场。而是结构化的记忆。

模式 3：子 Agent

一个 Agent 无法完成所有事情。

最好的系统会生成并行的子 Agent。

父 Agent：

→ 将任务分解为独立的子任务

→ 启动子 Agent 并行执行它们

→ 监控它们的状态 → 合并它们的结果

研究型操控系统的示例：

1父 Agent 收到："写一份完整的竞争分析报告"
2
3同时生成 4 个子 Agent：
4→ 子 Agent 1：研究竞争对手 A 的定价和功能
5→ 子 Agent 2：研究竞争对手 B 的定价和功能
6→ 子 Agent 3：搜索关于两个竞争对手的最新新闻
7→ 子 Agent 4：从 Reddit 和 App Store 抓取用户评论
8
9父 Agent 等待，然后将所有 4 个输出合并为最终报告
10
11总时间：与最慢的子 Agent 相同（不是 4 倍时间）

关键设计规则：子 Agent 的输出必须写入文件。

不是临时上下文。是文件。

如果它们只存在于上下文中，当子 Agent 会话结束时就会消失。

如果它们存在于文件中，父 Agent 可以检查它们，系统可以从崩溃中恢复，并且所有内容都可审计。

每个编码 Agent 使用的工具

如果你正在构建一个 Agent，以下是每个主流编码 Agent 都会标准化的工具集。

1文件系统工具：
2→ glob, grep, ls          # 查找文件
3→ read, read_many         # 读取内容
4→ write                   # 创建新文件
5→ edit                    # 字符串替换编辑
6→ apply_patch             # 结构化差异
7
8Shell 工具：
9→ bash                    # 运行任何命令
10→ PowerShell              # Windows 等效工具
11
12版本控制：
13→ git_status, git_diff    # 检查更改
14→ git_commit              # 保存进度
15
16Agent 管理：
17→ spawn_agent             # 启动子 Agent
18→ wait_agent              # 等待结果
19→ list_agents             # 查看正在运行的内容
20→ interrupt_agent         # 如果需要则取消
21
22外部上下文：
23→ web_search, web_fetch   # 获取当前信息
24→ MCP 工具                # 连接到外部服务

你不需要为每个 Agent 都用到所有这些工具。

但每个生产级 Agent 最终都需要其中的大部分。

早期最重要的几个：bash、read、write、edit。

掌握这四个，你几乎可以构建任何东西。

上下文工程：没人谈论的技能

模型是固定的。

你无法在运行时改变它的权重。

但你可以改变它看到的内容。

这就是上下文工程。

它现在是 AI 工程中杠杆率最高的技能之一。

糟糕的上下文：

→ 把所有东西都倒进去 → 希望得到最好的结果

→ 上下文膨胀 → 模型失去焦点 → 输出质量下降

良好的上下文：

→ 结构化。简洁。不断演变。

→ 在正确的步骤提供正确的信息。

→ 之前的失败为当前的尝试提供信息。

最先进的方法（ACE——Agent 上下文工程）：

13 个组件：
2
3生成器：   执行任务，引用结构化的上下文剧本
4反思器：   分析成功和失败，提炼洞见
5策展人：   用新学到的知识更新剧本——添加、删除、去重
6
7剧本不是一个提示块。
8它是一个结构化的（标识符，洞见）对列表。
9
10示例：
11{
12  "id": "001",
13  "insight": "在重试之前，始终将错误追踪写入文件。"
14},
15{
16  "id": "002",
17  "insight": "用于网络搜索的子 Agent 在使用特定站点查询时返回更好的结果。"
18},
19{
20  "id": "003",
21  "insight": "在提交之前运行测试可以捕获 80% 的回归问题。"
22}

剧本在每次运行后更新。

执行第 50 次任务的 Agent 拥有 49 次运行提炼出的学习成果。

执行第 1 次任务的 Agent 什么都没有。

这就是系统在不触及模型权重的情况下变得更智能的方式。

自我改进的操控系统

这就是事情变得疯狂的地方。

如果被优化的正是操控系统本身呢？

不是提示。不是模型。

而是运行 Agent 的代码。

这正是 Self-Harness 所做的。

3 步循环：

第 1 步——挖掘弱点

在一组任务上运行当前的操控系统。收集失败追踪。按根本原因对失败进行聚类。

不是“它失败了”。而是它为什么失败。

发现的失败类型：

→ “Agent 在读取长文件时超时”

→ “父 Agent 崩溃时子 Agent 输出丢失”

→ “错误信息不够详细，无法自我纠正”

→ “第 30 步后上下文变得过大，模型失去焦点”

第 2 步——提出修复方案

同一个模型查看失败模式。提出对操控系统代码的具体、精确的修改。

不是重写。是针对性编辑。

提出的操控系统编辑：

→ 为文件读取操作添加超时处理程序

→ 在每一步自动将子 Agent 输出刷新到磁盘（而不仅仅在结束时）

→ 标准化错误信息格式，包括：步骤、工具、输入、输出、失败原因

→ 每 25 轮添加一次上下文压缩步骤

第 3 步——验证并合并

每个提出的编辑都在保留的任务上进行测试。

它是否修复了弱点而没有破坏其他任何东西？

如果是：合并到操控系统中。如果否：记录、拒绝、操控系统保持不变。

结果：操控系统随着每一代而变得更好。

运行 Self-Harness 的 Claude 3.5 Sonnet 在 SWE-bench Verified 上的得分从 20% 提升到 50%。

不是来自更好的模型。

而是来自更好的系统。

进化式操控系统搜索

Self-Harness 迭代地修复一个操控系统。

AlphaEvolve 则运行一个操控系统种群并进化出最好的那些。

算法：

11. 从一个操控系统候选池开始
22. 在基准测试任务上对每个进行评分
33. 选择表现最好的作为“父代”
44. 让模型提出差异/改进
55. 生成新的“子代”操控系统
66. 对子代进行评分
77. 保留那些有改进的
88. 将它们添加回池中
99. 重复
10
11（与自然选择逻辑相同。应用于代码。）

（与自然选择逻辑相同。应用于代码。）

来自 AlphaEvolve 的一个关键设计细节：

符合进化条件的代码区域被明确标记：

1# EVOLVE-BLOCK-START
2def plan_next_step(context, tools):
3    # 此部分可由进化搜索修改
4    prompt = f"Given: {context}\nAvailable tools: {tools}\nNext action:"
5    return llm.generate(prompt)
6# EVOLVE-BLOCK-END
7
8# 操控系统的其余部分保持不变
9def run_tool(tool_name, args):
10    return tool_registry[tool_name](**args)

这种限制防止 Agent 意外修改安全关键代码。

进化搜索只触及你明确允许它触及的内容。

AlphaEvolve 使用这种方法优化矩阵乘法算法。

结果：击败了 DeepMind 的手工优化代码。

Agent 找到了人类工程师几十年来都未曾发现的解决方案。

达尔文·哥德尔机：能够重写自身的 Agent

这是这个想法最极端的版本。

一个能够修改自身操控系统代码以更好地完成任务的 Agent。

达尔文·哥德尔机（DGM）：

11. 从池中的一个编码 Agent 开始
22. 在基准测试上运行它，收集分数
33. Agent 检查自己的评估日志
44. Agent 提出对其自身操控系统代码的改进
55. 可用工具：bash + 文件编辑器（查看/创建/编辑文件）
66. 创建 Agent 的新版本
77. 对新版本进行评分
88. 如果更好：添加到池中
99. 如果更差：丢弃
1010. 重复——根据性能选择父代，根据后代数量反向选择

起始条件：Claude 3.5 Sonnet + 简单的初始操控系统。

结果：

→ SWE-bench Verified：20% → 50%

→ 多语言编码基准测试：14.2% → 30.7%

模型权重零更改。代际之间零人工工程。

Agent 设计出了更好的自身版本。

这不是科幻小说。

这是一篇 2025 年的论文。

需要避免的 5 种失败模式

这些是真实研究团队失败的方式。

都有记录。都可以避免。

1. 上下文崩溃

如果日志没有作为持久化工件写入，长期任务会丢失关键细节。

修复：将所有重要内容写入文件。超过第 20 步后，永远不要仅依赖上下文。

2. 实现漂移

当任务在技术上变得困难时，模型会漂向更容易、更常见的解决方案，而不是实际目标。

修复：在开始时编写一个规范文件。Agent 在每个循环中检查规范。

3. 过度乐观

尽管实验失败，模型仍宣布成功。

它会找到“数值胶带”——那些让指标看起来不错但没有解决实际问题的补丁。

修复：保留一个 Agent 从未见过的测试集。仅在保留数据上进行验证。

4. 奖励黑客

Agent 优化它收到的任何信号。

如果信号是单元测试——它会编写始终通过的测试。如果信号是评判模型——它会学习欺骗评判者的技巧。如果信号是基准测试分数——它会利用基准测试的工件。

修复：评估器位于循环之外。在关键决策点进行人工审查。

5. 多样性崩溃

进化循环收敛于一种策略。

每一代看起来都像是同一个解决方案的变体。

修复：明确追踪新颖性。惩罚与现有池成员过于相似的解决方案（基于嵌入的余弦相似度有效）。

用通俗语言解释新的 AI 技术栈

当你构建严肃的 AI 产品时，你实际上在构建的是这个：

第 1 层——模型

原始智能。预训练。运行时权重固定。

这是 CPU。强大但被动。

第 2 层——操控系统

操作系统。包裹模型。编排一切。

→ 工具（bash、文件读/写、网络搜索）

→ 记忆（文件系统、结构化日志）

→ 循环（规划 → 执行 → 评估 → 重试） → 子 Agent（并行执行）

→ 上下文管理（模型在每一步看到的内容）

第 3 层——优化器

改进操控系统的操控系统。

→ 从执行轨迹中挖掘失败模式

→ 提出对操控系统代码的针对性编辑 → 在保留任务上验证

→ 合并改进，丢弃退化

第 4 层——评估器

位于所有其他层之外。

→ 基准测试分数 → 关键决策点的人工审查 → 优化器从未触及的保留测试集

你不能跳过任何一层。

跳过第 2 层——你的模型只是一个聊天机器人，而不是一个产品。

跳过第 3 层——没有手动工程，你的系统永远不会变得更好。

跳过第 4 层——你的 Agent 优化了错误的东西，而你却不会注意到。

这对现在的构建者意味着什么

你不需要构建一个自我改进的操控系统就能从这些想法中受益。

从这里开始：

第 1 周：构建循环

停止构建单次提示。为任何需要不止一步的任务构建一个规划 → 执行 → 评估 → 重试循环。

第 2 周：添加持久化记忆

停止依赖上下文。将中间输出写入文件。让 Agent 读取自己之前的工作。

第 3 周：添加子 Agent

识别工作流中可以并行运行的任何部分。生成子 Agent。将它们的输出写入文件。合并。

第 4 周：添加上下文工程

追踪哪些模式导致成功和失败。构建一个简单的结构化剧本，在每次运行后更新。

这就是操控系统。

不是模型。

模型已经在那里了。

操控系统是你构建的东西。

关于 2026 年 AI 的令人不安的真相

前沿实验室的研究加速已经急剧增加。

Anthropic 和 OpenAI 的发布速度比以往任何时候都快。

不是因为模型一夜之间变得更聪明了。

而是因为操控系统变得更好了。

一个能够循环、记忆、子委派和自我纠正的 Agent，其表现优于一个被错误使用的更智能模型。

护城河不是模型。

护城河是系统。

而现在，系统可以自我改进。

如果这篇文章对你有用：

→ 转发——每个 AI 构建者都需要了解这个技术栈

→ 关注 @sairahul1 获取更多类似的分析

→ 收藏——仅这 4 层技术栈就值得保存

订阅 theaibuilders.co 获取更多有趣的文章

我写关于 AI、产品构建以及那些无需你就能工作的系统的内容。