LLM 代理：新一代高级编程语言

博主： admin
发布时间：2026 年 02 月 09 日
2 次浏览
暂无评论
6211字数
分类：人工智能架构 AI LLM 编程语言

# LLM 代理：新一代高级编程语言

# 一、概述

## 1. 核心假设

LLM 代理正在成为新的高级编程语言。

## 2. 历史演进

编程语言的发展历程展示了清晰的抽象层次提升模式：
- C 语言将开发者从汇编语言中解放出来
- Java 在 C 之上提供了更高层次的抽象
- JavaScript、Python、Perl 进一步提升了开发效率
- 现在，LLM 代理正在对所有编程语言进行类似的抽象提升

## 3. 定义与特征

### A. LLM 代理的定义

LLM 代理是指：
- **多代理并行**：多个代理同时工作，协同完成任务
- **自主运行**：代理仅需偶尔获得人类反馈，大部分时间自主工作

### B. 验证标准

判断这一假设是否成立的标准：人类开发者使用多个自主代理能够构建的功能输出，比不使用代理时多出一个数量级（10 倍）。

![编程语言演进图](https://static.op123.ren/static/54/5479958bdc9ccce9.svg)

# 二、常见质疑与回应

## 1. 度量标准质疑

**质疑**：10 倍代码行数并不等于构建了 10 倍功能，只是制造了混乱。

**回应**：衡量标准应基于实际交付的功能输出，而非代码行数。在假设框架下，对 LLM 的指令才是真正的代码行数。

## 2. 适用对象质疑

**质疑**：LLM 仅适合不懂编程的人。

**回应**：虽然 LLM 会带来许多新程序员，但这不意味着有经验的程序员不会受益。证据表明，许多经验丰富的程序员通过 LLM 获得了显著更高的产出。

## 3. 思考与工作强度

**质疑**：使用 LLM 是为了不想思考或工作。

**回应**：如果你使用 LLM 做的事比以前更多，你必须思考和工作的更多，而非更少。管理代理团队更具挑战性，你需要在相同时间内设计更多内容（因为你构建的是以前 x 倍的功能）。

## 4. 技能退化担忧

**质疑**：LLM 会让我们的编码技能退化。

**回应**：很可能确实如此。但在工作中，我们通常不担心汇编或 C 技能的退化。大多数人会在业余时间练习这些技能，因为我们无法证明在工作中使用汇编或 C 会更高效（对于大多数软件开发类型）。

## 5. 代码质量担忧

**质疑**：LLM 生成的代码比我能写的差得多。

**回应**：几乎可以确定是这样。但你的汇编或 C 代码也是如此。只要 LLM 生成的内容足够高效，它就能运行并立即可用。系统会更丑陋，但仍然能工作。

## 6. 成本考量

**质疑**：使用 LLM 代理很昂贵。

**回应**：如果它们能让你提高 50% 的生产力，且你的薪资是平均水平，那么它们并不昂贵。而且 LLM 只会越来越便宜。它们仅在绝对成本上昂贵，在相对成本上并不昂贵。

## 7. 学习曲线

**质疑**：我尝试了一个下午的 LLM 代理，浪费了我的时间。

**回应**：存在学习曲线。掌握使用多个 LLM 代理需要一段时间。想想你在编程工具和语法上花费的小时和天数，直到你或多或少掌握它们。

```mermaid
graph TD
    A[质疑] --> B{是否可辩护?}
    B -->|是| C[理性回应]
    B -->|否| D[情感障碍]
    C --> E[接受新范式]
    D --> F[需要时间适应]
    F --> E
```

![质疑处理流程图](https://static.op123.ren/static/d7/e2f5b9a4c8d1.svg)

# 三、核心挑战

## 1. 质量问题

**问题**：LLM 生成的代码是否会很快变成一团糟？我们是否在沙上建造城堡？

## 2. 可理解性问题

**问题**：LLM 生成的代码量是否将多到我们永远无法理解？即使系统能工作，我们是否会因为不理解它们而永远处于失控的危险中？

## 3. 框架目标

质量和可理解性应成为任何可接受的 LLM 编程框架的目标。

从经济角度看，只有质量是无可争议的目标。可理解性可能是一个浪漫的梦想或一个良好的长期赌注（作者选择后者，但你可以保持不可知论）。

```mermaid
graph LR
    A[LLM编程框架] --> B[质量目标]
    A --> C[可理解性目标]
    B --> D[经济价值]
    C --> E[长期维护性]
    C --> F{可选}
    D --> G[必须实现]
```

![框架目标关系图](https://static.op123.ren/static/fc/fc53addc38d03c76.svg)

# 四、系统架构愿景

## 1. 核心组件

### A. 文档

一组包含系统规范的 Markdown 页面：目的、主要实体、端点、约束、核心流程、编码标准。

### B. 实现

代码库及所有数据。这是运行内容和状态持有者。代码库应可从文档重建，数据应与文档中的描述保持一致。

### C. 对话

多个代理在处理任务时产生的文本流。代理在思考解决方案时产生文本，其中一些是代码。人类可以随时检查这个文本、代码变更和命令流；人类也可以进入对话。某些对话可能等待人类输入。当代理完成工作时，对话不再活跃但仍可访问。

### D. 任务

动态的离散工作集合，表达为 Markdown 页面。任务应可从文档 + 代码库现有状态重建。任务应可嵌套。任务具有状态（完成、待处理、进行中、等待人类交互、完成）。

```mermaid
graph TB
    subgraph 存量层
        DOC[文档]
        IMP[实现]
    end

subgraph 流量层
        DIA[对话]
        TASK[任务]
    end

DIA -->|构建| DOC
    DIA -->|构建| IMP
    TASK -->|构建| DOC
    TASK -->|构建| IMP

HUM[人类] -->|交互| DIA
    HUM -->|交互| TASK
    AGT[代理] -->|产生| DIA
    AGT -->|执行| TASK
```

![系统架构组件图](https://static.op123.ren/static/a2/a2ae0d515d0dd4fe.svg)

## 2. 存量与流量

系统中有两个存量和两个流量：

- **存量**：文档和实现，是系统的积累
- **流量**：对话和任务，构建文档和实现

人类可以直接修改文档和实现，但这不会经常发生，因为大部分流程是代理驱动的，人类将大部分时间用于与代理交互。

## 3. 代理角色

由于代理可以扮演多种角色（因为底层模型是通用的），可以在此保留尽可能多的自由度。如果任何代理可以进入任何对话，任何人可以进入任何对话，可以让人类尝试不同的可能性：

- **独立工作代理**：从开始到结束独立处理任务
- **管理代理**：负责协调下一步做什么
- **QA 代理**：尝试破坏新功能
- **审查代理**：在不了解构建者上下文的情况下审查未合并的新功能
- **合并代理**：解决冲突

重要的是，人类可以手动或自动启动带有指令的代理，这些指令可以是一次性的或文档的一部分。

```mermaid
graph TD
    H[人类] -->|启动/指令| A[代理池]
    A --> A1[独立工作代理]
    A --> A2[管理代理]
    A --> A3[QA代理]
    A --> A4[审查代理]
    A --> A5[合并代理]

A1 -->|执行| T[任务]
    A2 -->|协调| T
    A3 -->|测试| F[功能]
    A4 -->|审查| F
    A5 -->|解决| C[冲突]
```

![代理角色分工图](https://static.op123.ren/static/e2/e232640aa425b743.svg)

# 五、MCP 与应用打破

## 1. MCP 的意义

MCP（LLM 工具调用的标准）可以被视为新一代的通用 XMLHttpRequest。这开启了让你的 AI 代理获取孤立在现有应用中的任何功能和数据，并将其放入你选择的动态画布中的可能性。

## 2. 应用孤岛的终结

你只需说从 Salesforce 获取 X 数据，LLM 就会获取它，并在你想要的任何地方（文档页面或应用的另一个页面）做一个漂亮的小型临时可视化。这真正标志着孤岛时代的结束。

```mermaid
graph LR
    subgraph 传统应用孤岛
        APP1[Salesforce]
        APP2[Notion]
        APP3[Jira]
    end

USER[用户画布] -->|统一访问| MCP
    LLM[LLM代理] -->|智能集成| MCP

![MCP打破应用孤岛图](https://static.op123.ren/static/be/bec6003e80471c20.svg)

# 六、Cell 愿景扩展

## 1. 原始愿景

Cell 的原始愿景是一个代码和数据的网格（数据空间），你可以完全理解并且已经部署。但这还不够。

## 2. 扩展愿景

网格只是其中的一部分。围绕网格将是一组动态页面，文档和功能在此汇聚。

文档不再只是文档：你能够嵌入功能，无论是来自你自己的应用（将在网格中支持）还是来自外部应用。你可以拥有迷你仪表板或小部件，可以全屏显示。或者你可以导航到另一个页面。

你的 Cell 将是页面的集合，加上网格，加上在其上工作的代理。其中的很多内容可以从外部访问。

```mermaid
graph TB
 subgraph Cell系统
 GRID[网格 代码与数据]
 PAGES[动态页面集合 文档+功能]
 AGENTS[代理集群 持续工作]
 end

GRID <--> PAGES
 PAGES <--> AGENTS

EXT[外部访问] -->|API| PAGES
    EXT -->|API| GRID

subgraph 外部应用
        E1[应用1]
        E2[应用2]
    end

MCP|MCP集成| --> E1
    MCP --> E2
    PAGES --> MCP
```

![Cell系统架构图](https://static.op123.ren/static/a8/d3e6f9b4c7a2.svg)

# 七、技术考量

## 1. 服务器需求

系统仍需要服务器，原因如下：
- 当你不在线时接收请求
- 持久化数据
- 保持代理工作
- 许多调用由于安全原因无法直接从浏览器进行，需要服务器发出请求

## 2. 质量与可理解性

如果我们使用良好的底层技术而不是庞大的技术栈，LLM 输出的代码行数将更少，更易于理解。如果是这种情况，我们可以大幅提高构建系统的质量和性能。

系统前端现在是文档和代理，后端是技术栈或底层技术。

```mermaid
graph LR
    subgraph 前端层
        DOC[文档]
        AGT[代理]
    end

subgraph 后端层
        SUB[底层技术/技术栈]
    end

DOC -->|指令| AGT
    AGT -->|生成代码| SUB
    SUB -->|运行时反馈| AGT
    AGT -->|更新| DOC
```

![前后端分层架构图](https://static.op123.ren/static/d5/f8a2e4c6b1d7.svg)

# 八、开放性问题

## 1. 存储问题

如何将文档和对话与实现一起存储？

## 2. 版本控制

如何使用版本控制系统？

```mermaid
graph TD
    A[开放性问题] --> B[存储问题]
    A --> C[版本控制问题]

B --> B1[文档与实现]
    B --> B2[对话历史]
    B --> B3[统一存储模型]

C --> C1[传统Git适配]
    C --> C2[AI感知版本控制]
    C --> C3[增量变更追踪]
```

![开放性问题图](https://static.op123.ren/static/5d/5dad2d070261849a.svg)

# 九、结论

## 1. 核心洞察

LLM 代理作为高级编程语言的假设，虽然尚未完全验证（截至 2026 年 1 月），但值得认真考虑。这一范式转移类似于历史上从汇编到 C、从 C 到 Java 的抽象提升。

## 2. 关键要素

成功的 LLM 编程框架需要：
- 以质量为必须目标
- 以可理解为长期目标
- 支持多代理自主协作
- 提供清晰的文档-代码映射
- 打破应用孤岛

## 3. 未来展望

随着 MCP 标准的普及和 LLM 成本的持续下降，我们正在进入一个应用边界模糊、功能动态组合的新时代。开发者将从编写代码转向设计系统、管理代理和协调功能。

***

## 参考资料

1. [LLMs as the new high level language - Federico Pereiro](https://federicopereiro.com/llm-high/)
2. [Original publication at GitHub](https://github.com/altocodenl/cell/blob/master/docs/llm-high.md)

最后修改：2026 年 02 月 09 日

如果觉得我的文章对你有用，请随意赞赏

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

评论 *

私密评论

名称 *

🎲

邮箱 *

地址

kkk
老师可以加个联系方式吗
张
很不错。除了那个qemu-tools
angux
会考虑关停服务么。。如果不考虑可以支持你
zm
ishare2 config 这一步过不去，卡在了“Unabl...
sheldon
得劲的很

LLM 代理：新一代高级编程语言

admin • 2026 年 02 月 09 日

# LLM 代理：新一代高级编程语言

# 一、概述

## 1. 核心假设

LLM 代理正在成为新的高级编程语言。

## 2. 历史演进

## 3. 定义与特征

### A. LLM 代理的定义

LLM 代理是指：
- **多代理并行**：多个代理同时工作，协同完成任务
- **自主运行**：代理仅需偶尔获得人类反馈，大部分时间自主工作

### B. 验证标准

判断这一假设是否成立的标准：人类开发者使用多个自主代理能够构建的功能输出，比不使用代理时多出一个数量级（10 倍）。

![编程语言演进图](https://static.op123.ren/static/54/5479958bdc9ccce9.svg)

# 二、常见质疑与回应

## 1. 度量标准质疑

**质疑**：10 倍代码行数并不等于构建了 10 倍功能，只是制造了混乱。

**回应**：衡量标准应基于实际交付的功能输出，而非代码行数。在假设框架下，对 LLM 的指令才是真正的代码行数。

## 2. 适用对象质疑

**质疑**：LLM 仅适合不懂编程的人。

**回应**：虽然 LLM 会带来许多新程序员，但这不意味着有经验的程序员不会受益。证据表明，许多经验丰富的程序员通过 LLM 获得了显著更高的产出。

## 3. 思考与工作强度

**质疑**：使用 LLM 是为了不想思考或工作。

## 4. 技能退化担忧

**质疑**：LLM 会让我们的编码技能退化。

## 5. 代码质量担忧

**质疑**：LLM 生成的代码比我能写的差得多。

## 6. 成本考量

**质疑**：使用 LLM 代理很昂贵。

## 7. 学习曲线

**质疑**：我尝试了一个下午的 LLM 代理，浪费了我的时间。

**回应**：存在学习曲线。掌握使用多个 LLM 代理需要一段时间。想想你在编程工具和语法上花费的小时和天数，直到你或多或少掌握它们。

```mermaid
graph TD
    A[质疑] --> B{是否可辩护?}
    B -->|是| C[理性回应]
    B -->|否| D[情感障碍]
    C --> E[接受新范式]
    D --> F[需要时间适应]
    F --> E
```

![质疑处理流程图](https://static.op123.ren/static/d7/e2f5b9a4c8d1.svg)

# 三、核心挑战

## 1. 质量问题

**问题**：LLM 生成的代码是否会很快变成一团糟？我们是否在沙上建造城堡？

## 2. 可理解性问题

**问题**：LLM 生成的代码量是否将多到我们永远无法理解？即使系统能工作，我们是否会因为不理解它们而永远处于失控的危险中？

## 3. 框架目标

质量和可理解性应成为任何可接受的 LLM 编程框架的目标。

从经济角度看，只有质量是无可争议的目标。可理解性可能是一个浪漫的梦想或一个良好的长期赌注（作者选择后者，但你可以保持不可知论）。

```mermaid
graph LR
    A[LLM编程框架] --> B[质量目标]
    A --> C[可理解性目标]
    B --> D[经济价值]
    C --> E[长期维护性]
    C --> F{可选}
    D --> G[必须实现]
```

![框架目标关系图](https://static.op123.ren/static/fc/fc53addc38d03c76.svg)

# 四、系统架构愿景

## 1. 核心组件

### A. 文档

一组包含系统规范的 Markdown 页面：目的、主要实体、端点、约束、核心流程、编码标准。

### B. 实现

代码库及所有数据。这是运行内容和状态持有者。代码库应可从文档重建，数据应与文档中的描述保持一致。

### C. 对话

### D. 任务

```mermaid
graph TB
    subgraph 存量层
        DOC[文档]
        IMP[实现]
    end

subgraph 流量层
        DIA[对话]
        TASK[任务]
    end

DIA -->|构建| DOC
    DIA -->|构建| IMP
    TASK -->|构建| DOC
    TASK -->|构建| IMP

HUM[人类] -->|交互| DIA
    HUM -->|交互| TASK
    AGT[代理] -->|产生| DIA
    AGT -->|执行| TASK
```

![系统架构组件图](https://static.op123.ren/static/a2/a2ae0d515d0dd4fe.svg)

## 2. 存量与流量

系统中有两个存量和两个流量：

- **存量**：文档和实现，是系统的积累
- **流量**：对话和任务，构建文档和实现

人类可以直接修改文档和实现，但这不会经常发生，因为大部分流程是代理驱动的，人类将大部分时间用于与代理交互。

## 3. 代理角色

重要的是，人类可以手动或自动启动带有指令的代理，这些指令可以是一次性的或文档的一部分。

A1 -->|执行| T[任务]
    A2 -->|协调| T
    A3 -->|测试| F[功能]
    A4 -->|审查| F
    A5 -->|解决| C[冲突]
```

![代理角色分工图](https://static.op123.ren/static/e2/e232640aa425b743.svg)

# 五、MCP 与应用打破

## 1. MCP 的意义

## 2. 应用孤岛的终结

```mermaid
graph LR
    subgraph 传统应用孤岛
        APP1[Salesforce]
        APP2[Notion]
        APP3[Jira]
    end

USER[用户画布] -->|统一访问| MCP
    LLM[LLM代理] -->|智能集成| MCP

![MCP打破应用孤岛图](https://static.op123.ren/static/be/bec6003e80471c20.svg)

# 六、Cell 愿景扩展

## 1. 原始愿景

Cell 的原始愿景是一个代码和数据的网格（数据空间），你可以完全理解并且已经部署。但这还不够。

## 2. 扩展愿景

网格只是其中的一部分。围绕网格将是一组动态页面，文档和功能在此汇聚。

你的 Cell 将是页面的集合，加上网格，加上在其上工作的代理。其中的很多内容可以从外部访问。

```mermaid
graph TB
 subgraph Cell系统
 GRID[网格 代码与数据]
 PAGES[动态页面集合 文档+功能]
 AGENTS[代理集群 持续工作]
 end

GRID <--> PAGES
 PAGES <--> AGENTS

EXT[外部访问] -->|API| PAGES
    EXT -->|API| GRID

subgraph 外部应用
        E1[应用1]
        E2[应用2]
    end

MCP|MCP集成| --> E1
    MCP --> E2
    PAGES --> MCP
```

![Cell系统架构图](https://static.op123.ren/static/a8/d3e6f9b4c7a2.svg)

# 七、技术考量

## 1. 服务器需求

## 2. 质量与可理解性

系统前端现在是文档和代理，后端是技术栈或底层技术。

```mermaid
graph LR
    subgraph 前端层
        DOC[文档]
        AGT[代理]
    end

subgraph 后端层
        SUB[底层技术/技术栈]
    end

DOC -->|指令| AGT
    AGT -->|生成代码| SUB
    SUB -->|运行时反馈| AGT
    AGT -->|更新| DOC
```

![前后端分层架构图](https://static.op123.ren/static/d5/f8a2e4c6b1d7.svg)

# 八、开放性问题

## 1. 存储问题

如何将文档和对话与实现一起存储？

## 2. 版本控制

如何使用版本控制系统？

```mermaid
graph TD
    A[开放性问题] --> B[存储问题]
    A --> C[版本控制问题]

B --> B1[文档与实现]
    B --> B2[对话历史]
    B --> B3[统一存储模型]

C --> C1[传统Git适配]
    C --> C2[AI感知版本控制]
    C --> C3[增量变更追踪]
```

![开放性问题图](https://static.op123.ren/static/5d/5dad2d070261849a.svg)

# 九、结论

## 1. 核心洞察

## 2. 关键要素

成功的 LLM 编程框架需要：
- 以质量为必须目标
- 以可理解为长期目标
- 支持多代理自主协作
- 提供清晰的文档-代码映射
- 打破应用孤岛

## 3. 未来展望

***

## 参考资料

1. [LLMs as the new high level language - Federico Pereiro](https://federicopereiro.com/llm-high/)
2. [Original publication at GitHub](https://github.com/altocodenl/cell/blob/master/docs/llm-high.md)

LLM 代理：新一代高级编程语言

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

搭建国内LabHub

CentOS 7.9 编译并使用rpm方式升级openssh9.6p1（包括后续更新9.8p1等）

一天从 redis 大 key 开始

安装eve-ng

重装ensp

使用python实现邮件发送并携带附件

loki部署

想用Claude有点难

download jdk from oracle website

python常用知识

LLM 代理：新一代高级编程语言

发表评论 取消回复 使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款

LLM 代理：新一代高级编程语言

发表评论取消回复
使用cookie技术保留您的个人信息以便您下次快速评论，继续评论表示您已同意该条款