Claude Code Since 1960

从大型机终端到 AI Agent：同一种控制关系，跨越六十多年

这篇文章还有 English 版本。

📹 序章：从大型机到大模型

六十多年

1960 年代中期的一个早晨，纽约，IBM 数据中心。

Jenny 走进办公室，在她的工位上坐下。面前是一台 IBM 2741 终端—— 一个嵌在桌面里的 Selectric 打字机，通过电话线连接到隔壁机房里占据一排机柜的 IBM System/360 Model 50。

她是一名 Operator。

她熟练地拨通调制解调器，在终端上敲下 LOGON 命令，连接远端分时系统。系统以每秒 14 个字符的速度，在纸上"打印"出欢迎信息。

她开始工作：用 EDIT 命令打开一个 COBOL 源文件，修改几行代码，然后 SUBMIT 提交一个批处理任务。等待结果的时候，她按下 ATTN 键中断当前输出，切换去查看另一个任务的状态。

她不需要理解 System/360 的微码是怎么执行指令的。她只需要知道：输入正确的命令，机器就会给出正确的结果。智能在那一端，她在这一端。中间连接她们的，是一根电话线和一个终端。

六十多年后的今天。你打开 MacBook，启动终端，输入 claude。

一个连接建立了——通过互联网，连接到机房里数千张 GPU 组成的集群。

你开始工作：用自然语言描述一个 bug，Claude Code 自动搜索代码、定位问题、修改文件、运行测试。等待的时候，你按 Esc 中断，让它换个方向试试。

你不需要理解 Transformer 的注意力机制是怎么计算的。你只需要知道：描述清楚意图，Agent 就会给出结果。智能在那一端，你在这一端。中间连接你们的，是一根网线和一个终端。

Jenny 和你，做着同样的事情：通过终端，操控远端的"智能"。

这是同一个架构模式的两次实现，第一次，远端是集中式算力（大型机）；第二次，远端是集中式智力（大模型）。

而两次实现之间，跨越了 六十多年。

为什么是同一个架构？

大型机时代的"终端-主机"分离，和今天的"终端-大模型"分离，源于同一个经济学原理：

核心资源价格较高，通常采用集中共享。

• 1960 年代：大型机的购置与运行成本较高，一个机构部署一套，许多人共享

• 今天：前沿模型的训练和部署依然昂贵，由少数机构集中建设，数百万人通过网络共享

终端存在的意义，是让个体用户以较低成本接入集中式资源。1960 年代是 IBM 2741 + 电话线；今天是 Terminal.app + 互联网。

Claude Code 的优势

Claude Code 于 2025 年以 research preview 形式发布，它的竞争力来自 六十多年的技术积累。

Claude Code 直接复用人类六十多年积累的 CLI 生态。

• 搜索代码：使用 ripgrep

• 安装依赖：使用 npm/pip

• 版本控制：使用 git

• 执行通用操作：使用 Bash

Claude Code 选择了成熟的终端交互形态，终端背后已有六十多年的工具链、协议和生态。

大型机 + 终端 → 大模型 + 终端

架构相似：

• 核心能力集中在远端（主机/云端模型），本地是轻量终端

• 人类通过文本指令操控，是"操作员"(Operator)角色

• 1960 年代的 Operator 需要精确语法，今天的 Operator 用自然语言

• 共同点是：人类在环，负责意图表达和结果验证

为什么选择终端？

Claude Code 选择终端，主要基于以下因素：

• 兼容性：六十多年的 CLI 工具链可以低成本复用，Git/npm/docker 可直接接入

• 信息密度：文本是 LLM 的原生语言，Terminal 是直接的人机通道

• 可编程性：管道、脚本、自动化，天然支持 Agent 工作流

• 安全性：文件系统 + 进程隔离 + Sandbox，比 GUI 更容易做权限控制

GUI 是为人类的眼睛设计的；Terminal 是为机器（和懂机器的人）设计的。当"操作者"变成 AI，Terminal 的文本接口和工具生态具有更高的适配度。

👋 第二章："Hi"

🧑‍⚕️ 第三章：A Doctor is STATELESS

想象一个这样的场景：你去看病，每次走进诊室，医生都一脸茫然地看着你——"你好，请问你哪里不舒服？"

"大夫，我上次来过啊。"

"抱歉，我不记得了。不过你可以把病历给我看看。"

于是你掏出一沓厚厚的病历本，上面记录着每一次的症状描述、每一次的诊断结果、每一次的用药方案。医生从第一页开始翻，一直读到最后一页，然后说："了解了，我们继续。"

下次再来，同样的流程——你递上病历本，只不过又多了几页。医生再从头读一遍。

这就是大语言模型的工作方式。

我们和 Claude 对话时感觉它"记得"之前说了什么，好像在和一个有记忆的助手持续沟通。其实现机制是——模型本身无状态。它没有记忆，没有会话，每次调用都是一次全新的、独立的请求。多轮对话由客户端在每次请求中打包之前的对话历史，让模型重新"读"一遍，再给出回应。

Claude Code 采用同样的机制。

这听起来像是一个实现细节，但它直接影响着你的使用体验——为什么长对话越来越慢？为什么有时候 Claude 好像"忘了"前面说过的话？为什么 token 消耗会随着对话推进急剧增长？这些现象都与上下文重放有关。

🩻 第四章：Subagent 以及 CT 检查

主治医生（主模型）在诊室里接诊病人，全程掌握病人的完整病史和对话。

病人说："我最近头疼。"

主治医生通常会开一张检查单，派病人去影像科：

就像影像科拍的 20 张片子不会贴进主治医生的病历本，主治医生只看到最终那份一页纸的报告。病历本（主上下文）保持相对简洁、可控。

🐎 第五章：Agent，Agent 编排，以及 Harness Engineering

Claude Code 的 Agent 编排

Agent 编排是决定"谁在什么时候做什么"的控制逻辑。

Agent 本身是 LLM + 工具 + 循环，但当你有多个 Agent、多种工具、多个阶段时，就需要一层"指挥"来协调它们。这层指挥就是编排。

用我们聊过的内容来说，Claude Code 里已经包含了好几种编排模式：

单 Agent 编排： Agent Loop 本身就是一种编排——stop_reason 决定是继续循环还是结束，模型自己决定调什么工具。编排逻辑就是那个 while(true) + if (stop_reason === "tool_use")。

主从编排（Subagent）： 主模型决定什么时候派出子代理、给什么任务、怎么汇总结果。编排逻辑在主模型的 Agent Loop 里——它通过 tool_use 输出 Task 调用来启动子代理。

流水线编排（Skills）：requirement-specification → tech-design → implement → code-review → commit，每个阶段有不同的 prompt 和工具集，按顺序串联。编排逻辑在 Skill 定义和触发规则里。

规划编排（Plan Mode）： EnterPlanMode → 探索 → 设计方案 → ExitPlanMode → 用户审批 → 执行。编排逻辑是一个状态机：规划态只能读不能写，审批通过后才切换到执行态。

Agent 编排是在 Agent Loop 之上的控制层，决定多个 Agent、工具和阶段之间的调度顺序、数据流转和状态管理。

Agent 是医生，编排是医院的分诊流程和会诊制度——决定病人先看谁、什么情况转诊、什么时候会诊、谁来汇总结论。

工作流与 Agent

主要区别在于：谁在做决策。

固定 Workflow：人预先定义每一步。

每一步做什么、下一步去哪、走哪个分支，都由代码里的 if/else 预先定义。LLM 是每个步骤里的"执行者"，不决定流程走向。

# 固定 Workflow
result1 = call_llm("提取用户意图", user_input)
result2 = call_llm("生成 SQL", result1)
result3 = execute_sql(result2)
result4 = call_llm("把结果翻译成自然语言", result3)
return result4

每一步干什么、顺序是什么、调什么工具，开发者在写代码时就决定了。运行时不会变。

Agent Loop：LLM 自己决定每一步。

模型在每一轮循环里自主判断：要不要调工具、调哪个、参数是什么、结果够不够、要不要继续。流程由运行时生成。

# Agent Loop 伪代码
while True:
    response = call_llm(messages, tools)
    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool)
        messages.append(result)  # 模型下一轮自己决定怎么用这个结果
    else:
        return response.text

同一个任务，模型可能走 3 步完成，也可能走 10 步。路径不固定。

类比医院：

实际项目中往往是混合使用：

smartflow 技能就是典型例子

commit 这个 Skill 内部是固定 Workflow（跑测试 → 检查覆盖率 → git add → git commit → push），但在决定"什么时候该用 commit"以及"commit 失败后怎么办"这些层面，是 Agent Loop 在做决策。

固定 Workflow 由开发者定义控制流，Agent Loop 由模型在运行时选择路径。

其它编排框架

在编排层做文章，区别在于用什么范式来组织 Agent 之间的协作。

1. LangGraph — 图状态机

把编排显式建模为一张有向图，每个节点是一个处理步骤（可能包含 LLM 调用），边是状态转移条件。

可以看作固定 Workflow 的增强版——图是人画的，但分支条件可以由 LLM 判断。介于纯固定和纯 Agent Loop 之间。

下面是按有向无环图拓扑序执行的一个例子：

A 完成后 B 和 C 并行，都完成后 D 执行。没有"回头"，每个节点只走一次。

2. CrewAI — 角色多代理

给每个 Agent 定义一个角色（PM、开发、测试），它们按编排顺序协作。

可以看作流水线编排 + 角色分工，和 smartflow 技能集（requirement → tech-design → implement → code-review → commit）非常像。

3. AutoGen — 对话协作

多个 Agent 通过互相发消息来协作，像群聊一样。

它采用去中心化的消息传递，接近 Agent Swarm 的 handoff 模式，但更自由。代价是 token 消耗高——每个 Agent 都要"读"其他 Agent 说的话。

这些框架解决的是同一个问题——"怎么编排多个 LLM 调用和工具执行来完成复杂任务"，编排范式包括图、角色、对话、沙箱和 SDK。底层大多使用 while(true) + tool_use + messages.push()。

Harness Engineering

Harness Engineering 是设计环境、约束和反馈循环，使 AI 编码代理在规模化场景下可靠工作的学科。

"Harness"这个词来自马具——缰绳、马鞍、嚼子——一整套用来引导能力强且行为存在不确定性的动物朝正确方向前进的装备。马是 AI 模型，骑手是人类工程师，没有 harness，AI agent 就像一匹旷野上的骏马——跑得很快、很壮观，但难以稳定完成预期任务。

我们之前分析的 Claude Code，可以看作一套完整的 harness。

回头看我们拆解的所有东西，按 harness 的框架重新分类：

工程关注点

工程师的工作从写代码扩展到设计环境、明确意图和构建反馈循环，让 Agent 能可靠地工作。

当 Agent 遇到困难时，除了继续重试，还可以检查缺少的能力，以及相关信息对 Agent 是否可读、可执行。

这和我们之前聊的 smartflow 技能（gatekeeper、record-lesson、evolve）相对应，它们可以视为 harness 的组件。

Harness Engineering 关注 Agent 在真实环境中的可靠性。

——约束、文档、测试、反馈循环、持久记忆。

🧑‍💻 终章：Operator Until 2026

1960 年代，波士顿郊外，Raytheon 工厂。

数百名女性坐在工位两侧，用针穿引着比头发丝还细的铜线，一针一针穿过磁芯环——穿过去是 1，绕过去是 0。

她们在做什么？她们在用手，一位一位地，把程序编织成硬件。

这是阿波罗导航计算机的 Core Rope Memory—— 72KB 的只读存储器，装着引导宇航员登月的全部软件。每个磁芯穿过 192 根感应线，每个模块需要 8 周手工编织。半英里长的铜线，对准确度要求很高。

工程师们叫这种方法 "LOL" — Little Old Ladies。负责监督软件开发的 Margaret Hamilton 被称为 "Rope Mother"。

三代人的"不可思议"

想象一下，如果那些 Raytheon 女工穿越到今天，看到你在 VS Code 里写代码——

"等等……你是说，你只需要在键盘上敲字，程序就写好了？不用穿铜线？不用织磁芯？不用一位一位地编入硬件？……怎么可能？"

这是她们无法理解的。因为在她们的世界里，编程 = 物理劳动。

2026 年 3 月发布的 GPT-5.4，在 OpenAI 公布的 OSWorld-Verified 评测中取得 75.0%。桌面操作能力正在从实验演示走向通用模型的原生能力。

Claude Code 用终端指挥 AI。GPT-5.4 Computer Use 直接看屏幕、点鼠标、敲键盘。Claude in Chrome 在浏览器里自主导航。

Human is leaving the loop.

再想象一下，2040 年的某个人，回看 2025 年的我们——

"等等……你是说，以前的人类要自己亲手写代码？一个字母一个字母地敲？还要自己 debug？自己跑测试？还要学什么'编程语言'？……怎么可能？就像那些用手编织二进制的人一样不可思议。"

三次 Operator 的消亡

• 1960s LOL 编织女工 → 被编译器和键盘取代

• 程序员 Operator → 正在被 AI Agent 取代

• AI Operator → 将被完全自主 Agent 取代

每一次消亡的模式都一样：

1. 一种新的"操作方式"出现（编译器 / AI Agent / 自主 Agent）

2. 旧的 Operator 技能从"需要掌握"变成"不可思议的古老知识"

3. 新的 Operator 觉得自己难以替代——直到下一次消亡

我们可以做的事

如果 Operator 的角色继续收缩，我们现在该怎么办？

不要做最后一代 Operator。要做第一代 Architect。

技术在变，工具在变，Operator 的职责也在变化。但理解系统如何工作、设计系统如何工作的人，从 1960 年代到 2026 年一直存在。

三项实践方向：

1. 理解 Agent 原理

   • 知道 Claude Code 是 while 循环 + API 调用，你就能设计更好的 Agent

   • 知道上下文是稀缺资源，你就能写出更高效的 CLAUDE.md 和 Skills

2. 从写代码转向写 Spec

   • Spec-Driven Development：描述做什么和怎么验证

   • 让 Agent 负责怎么做——这已经是 Claude Code 最佳实践

3. 构建 Agent 生态

   • 面向 AI 设计工具

   • 写 Skills，把你的领域知识打包成 AI 可复用的能力

   • 这些会形成 AI 时代的可复用资产

1960 年代，人类坐在终端前操控机器。六十多年的技术积累孕育了 Claude Code。2026 年，Claude Code 又开始改变 Operator 这个角色。这个过程仍在继续，智能体时代还处于早期阶段。

Claude Code Since 1960. Operator Until 2026.

参考资料

官方

• How Claude Code Works

• Agent Skills

• Claude Code Sandboxing

• Agent Safety Framework

逆向分析

• System Prompts 全集

• Agent Design Lessons

• Skills Deep Dive

• Skills 内部机制

GPT-5.4 & Computer Use

• Introducing GPT-5.4

• GPT-5.4 Computer Use Guide