一个关于AI编程/Agent的讨论

TL;DR

昨天在一个群里看到一些前端的讨论, 回忆着LAMP php jquery, 似乎又有点梦回1998的感慨... 小时候因为家里的老叔叔要做CAD, 老阿姨要炒股票, 在1997年家里就有了电脑, 里面有一只33.6K的Modem于是很早就接触到了互联网... 其实更早的时候(1993年), 在响应“计算机要从娃娃抓起”的小学里就开始学习LOGO/BASIC编程, 然后初中开始就开始打OI比赛.... 机缘巧合赶在了那一波互联网泡沫里, 然后又和当年的“中国网络第一娃”琪缘是同学, 当然就有冲动去写网页当站长...

那个年代和如今AI应用遍地开花的场景很像, 大家都在面对新的技术变革做各种应用的尝试. 印象很深的是1999年有一个72小时网络生存测试^[1]来验证互联网触及生活, 网络购物的能力. 依稀记得那个年代还有很多的网页制作大赛, 诞生了各种各样对网络应用的探索. 恰逢阿里也在那一年前后成立, 也不难理解作为那个时代的亲历者, 马老师/吴妈在AI时代的判断和决心...

而如今的MCP仿佛和当年的CGI一样, 看似打开了一个通用的执行接口, 却又带来了很多的安全隐患. 时代的变革下,就会逐渐的发现MCP的丑陋和不完备的地方... 互联网的最近20年, 前端/后端技术栈也演进了很多年, 因此想做一些回顾和讨论避免在AI时代走一些弯路...

因此, 一些基于函数式编程的前端框架, 例如React+Redux和大模型的结合或许是对MCP改进的一条更恰当的路.

1. 一些前端的记忆

前端的历程,大概要从97年开始用Frontpage写静态页开始, 然后用windows 95上的PWS提供服务. 后来逐渐用Perl CGI提供一些动态内容的服务, 那个年代最常见的便是一些聊天室/留言板类的应用. 当然那个年代还有很多利用javascript炫技美化网页的小技巧. 那段时间主要是在做一个财经类的网站, 互联网泡沫破灭了就关了... 有些文字记录在以前的一篇文章里 《互联网30年，一些记忆里的东西》

后来在大学里跟着一些小伙伴用php写过一些小项目. 工作后很长一段时间在用Perl CGI做一些内部性能测试的框架和为一些集采项目提供一些定制化的网络管理系统. 然后就是被老板安排做了一些Telemetry分析的大数据平台, 同事做后端, 我做前端和市场, 写了两年的MySQL php jquery...

到后来前端MVC逐渐流行起来, 又开始用Node.js给量化私募基金做了一个交易监控和交割单管理的系统. 然后又逐渐的把Express.js换成Koa2.js用了很长一段时间. 前端框架上, 当时Cisco内部统一要用Angular,但是我个人非常讨厌这玩意, 于是用了React. web内的一些组件采用了Antd. 前后端的交互上又逐渐从RestAPI换成了GraphQL. 然后前端操作的一些状态选择了用redux处理, 采用函数式编程的方法对于前端执行复杂的状态机和简化后端的交互似乎是一个很不错的选择.

然后就是要在一些嵌入式的路由器平台上提供web服务, 考虑到资源的约束把后端的一些功能又用golang写了一遍和流数据处理平台整合...

2. 从MVC的视角看LLM的交互

前端MVC的框架已经非常成熟了, 但似乎LLM产生的一些代码还是存在大量的不足. 从本质上讲AI时代的前端是人和View组件的交互, 变成了更直接的人和Controller的交互. 而在模型本身的自回归Token生成的逻辑下, 那么就有一个想法:

对于大模型而言, 自回归模型可以生成相对稳定的状态机变化链, 而对于web端的操作由于函数式编程本身具有的约束不会产生副作用, 模型控制下多次执行和尝试的确定性更好.  另一方面函数式编程本身的pattern matching机制更容易和模型输出匹配.

3. 大模型和函数式编程结合的优势

大模型与函数式编程结合的优势：

1. 代码可预测性：纯函数的明确输入/输出关系使大模型更容易理解和生成正确代码
2. 声明式表达：函数式编程的声明式特性与自然语言表达更接近，便于大模型理解需求
3. 不可变数据：简化了状态追踪，使大模型能更准确地推理状态变化
4. 组件组合：模块化和组合性使大模型能够构建和理解复杂界面
5. 单向数据流：提供清晰的逻辑路径，帮助大模型追踪数据流向
6. 高阶抽象：使大模型能够在不同抽象层次工作，提供更灵活的解决方案
7. 测试友好：函数式代码的测试特性使大模型能生成高质量、可验证的代码

这种结合不仅提高了开发效率，还能提升代码质量、可维护性，并降低出错概率，代表了软件开发的一种强大范式。

3.1 代码可预测性与推理能力

函数式编程特点: 强调纯函数——相同输入产生相同输出，无副作用, Redux的reducer是纯函数的典型应用, 大模型能够轻松理解和生成这种函数式代码，因为：输入/输出关系明确，逻辑流程清晰, 其次没有隐藏状态，使得模型推理更准确 -状态转换逻辑遵循一致的模式.

3.2 声明式编程与自然语言的契合

函数式编程特点: 描述"做什么"而非"怎么做", React的JSX是典型的声明式UI表达,与大模型结合的优势:

• 声明式代码更接近自然语言描述
• 大模型更容易理解UI结构和组件层次
• 从需求描述到代码实现的转换更为直接

3.3 不可变数据与状态追踪

函数式编程特点:

• 避免修改现有数据，而是创建新数据
• Redux强制使用不可变更新模式

大模型能够：

• 更准确地跟踪状态变化
• 更容易理解数据流向和变换
• 生成符合不可变性原则的代码，避免常见的副作用问题

3.4 组件组合与代码生成

函数式编程特点:

• 通过组合小函数构建复杂功能
• React组件是UI函数，可以组合形成复杂界面

与大模型结合的优势:

• 理解组件之间的关系和数据流
• 从高层需求生成组件树结构
• 根据组件职责分离关注点

3.5 单向数据流与逻辑推理

函数式编程特点:

Redux实现了严格的单向数据流 Action → Reducer → State → View → Action

大模型优势：

• 能够理解并生成符合单向数据流的代码
• 可以推断从用户交互到状态变化的完整路径
• 在调试问题时能够追踪逻辑链

3.6 高阶函数与抽象层次

函数式编程特点:

• 使用高阶函数创建抽象
• Redux中间件、React高阶组件都是高阶函数的应用

大模型能够：

• 理解不同抽象层次的代码
• 生成符合特定模式的高阶函数
• 帮助实现代码复用和关注点分离

3.7 测试友好性与质量保障

函数式编程特点:

• 纯函数易于测试，只需验证输入/输出
• 组件和Redux逻辑可以独立测试

大模型可以：

• 生成测试用例及预期结果
• 理解测试失败的原因并提供修复建议
• 维护测试与实现之间的一致性