Haskell 全能编程：超越智能体编码的范式

基本信息

导语

随着大语言模型在代码生成领域的应用逐渐成熟，我们正面临一个新的技术拐点：如何超越简单的“智能体”模式，构建更具确定性和可维护性的系统。本文探讨了 Haskell 等强类型语言在这一转型中的独特价值，分析了形式化方法如何弥补当前 AI 编程在精确性上的短板。通过阅读本文，读者将了解到如何利用函数式编程的思维模型，与 AI 协作构建更严谨、更可靠的软件架构。

评论

基于对 Gabriel Gonzalez 的博客文章《Haskell for all: Beyond agentic coding》（超越智能体编程）的深入解读，以下是技术与行业维度的评价。

1. 核心观点与结构拆解

中心观点： 文章主张软件工程应从“构建单一智能体”转向“构建可组合的生态系统”，通过函数式编程的模块化思想，将复杂的 AI 能力分解为可验证、可复用的标准化组件，而非依赖不可解释的端到端模型。

支撑理由：

  1. 复杂系统的可组合性优于单体智能

    • 事实陈述： 当前的“Agentic Coding”（如 Devin、AutoGPT）倾向于训练一个巨大的端到端模型来解决所有问题。
    • 作者观点： 这种方法导致了“调试噩梦”。如果代码由 AI 生成且出错，人类很难修复。作者认为应借鉴 Unix 哲学，将任务分解为小型的、类型安全的函数或微服务。
    • 技术评价： 这触及了软件工程的核心矛盾：耦合度。端到端模型是高度耦合的“黑盒”，而模块化组件是低耦合的“白盒”。在金融或医疗等高风险领域，模块化带来的可审计性远比黑盒的“神奇”性能重要。

  2. 形式化方法与类型系统的安全性

    • 事实陈述： Haskell 等语言拥有强大的类型系统，能在编译期捕获错误。
    • 作者观点： AI 生成的代码往往缺乏形式化保证。将 AI 限制在强类型的框架内（例如利用 LLM 生成符合特定 Type Signature 的代码），可以大幅降低运行时错误。
    • 技术评价： 这是一个极具前瞻性的观点。目前的 LLM 大多基于概率生成，天然缺乏逻辑一致性。引入类型系统作为“护栏”，实际上是利用数学约束来弥补概率模型的缺陷。

  3. 工具链优于通用智能

    • 事实陈述： 现有的 IDE 和编译器已经非常成熟。
    • 作者观点： 我们不需要一个“AI 程序员”来替代 IDE，而是需要更好的“AI 工具”来增强 IDE。例如，不是让 AI 写整个文件，而是让 AI 优化选中的特定函数。
    • 技术评价： 这符合“人机回环”的最佳实践。技术演进往往是渐进的，试图完全替代人类的尝试（如全自动驾驶 L5）目前均遇阻，而辅助驾驶（L2/L3）已普及。

反例与边界条件：

  1. 边际场景下的灵活性不足：
    • 反例： 在处理遗留代码或高度非结构化的“一次性脚本”任务时，严格的类型系统和模块化设计带来的开发成本（前期设计、类型定义）可能远超其收益。端到端模型在处理模糊需求时表现更好。
  2. 上下文窗口的碎片化挑战：
    • 反例： 将任务极度细分会增加 LLM 对上下文理解的要求。如果组件 A 的输出格式发生微小变化，组件 B 可能无法理解。在单体模型中，这种内部表示是自适应的，而在管道模式中，接口变更会导致级联失败。

2. 维度深入评价

1. 内容深度：严谨的理论回归

文章的深度在于它没有盲目追逐“Agentic”的热度，而是回归到了软件工程的基石——抽象与组合。作者敏锐地指出了当前 AI 编程工具的一个致命弱点：不可逆性。一旦 AI 生成了大量垃圾代码，人类修复的成本比手写还高。作者提出的“形式化验证 + AI 辅助”路径，在理论上是解决 AI 幻觉的最优解。

2. 实用价值：高门槛的高价值

对于使用 TypeScript、Rust 或 Haskell 的团队，这篇文章具有极高的指导意义。它建议的“让 AI 填空而非写全篇”的策略，是目前 Copilot 等工具最高效的使用方式。然而，对于习惯了动态类型语言（如 Python、Ruby）或“快速原型”的开发者，这种强调严格类型和模块化的思想可能会被视为一种束缚。

3. 创新性：重新定义“AI 编程”

文章最大的创新点在于视角的转换：将 AI 视为一种“高级编译器优化”或“宏系统”，而不是“虚拟工程师”。这种去人格化的视角，有助于我们更客观地评估 AI 在开发流程中的位置。它提出了 “LLM as a Library” 的概念，即模型是库，调用者是程序员，而不是反过来。

4. 可读性与逻辑性

文章逻辑清晰，典型的 Hacker News 技术博文风格。作者使用对比论证，对比了“Agentic Approach”与“Composable Approach”的优劣。但文章带有强烈的 Haskell 社区色彩（即对类型系统的优越感），这可能让非 FP（函数式编程）背景的读者感到隔阂。

5. 行业影响

这篇文章是对当前“AI 全自动编程”热潮的一次必要的修正。随着行业从“震惊于 GPT-4 的能力”转变为“关注 GPT-4 的落地成本”，这种强调控制权、可预测性和模块化的声音会越来越强。它预示着下一代编程工具将从“Chat Bot”形态转向“Structural Editor”形态。

6. 争议点

  • 纯粹主义 vs. 实用主义： 作者暗示只有强类型语言才是出路，但这忽视了 Python + AI 的巨大生态

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

-- 示例1：使用类型类实现多态数据处理
class Summable a where
    sumValues :: [a] -> a

instance Summable Int where
    sumValues = sum

instance Summable Double where
    sumValues = sum

instance Summable [Char] where
    sumValues = concat

main :: IO ()
main = do
    print $ sumValues [1, 2, 3 :: Int]        -- 输出: 6
    print $ sumValues [1.5, 2.5, 3.5 :: Double] -- 输出: 7.5
    print $ sumValues ["Hello", " ", "World" :: [Char]] -- 输出: "Hello World"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

-- 示例2：使用Maybe类型处理可能失败的操作
safeDivide :: Int -> Int -> Maybe Double
safeDivide _ 0 = Nothing
safeDivide x y = Just (fromIntegral x / fromIntegral y)

processDivision :: Int -> Int -> String
processDivision x y = 
    case safeDivide x y of
        Just result -> "结果: " ++ show result
        Nothing -> "错误：除数不能为零"

main :: IO ()
main = do
    print $ processDivision 10 2   -- 输出: "结果: 5.0"
    print $ processDivision 5 0    -- 输出: "错误：除数不能为零"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

-- 示例3：使用惰性求值处理无限数据结构
-- 生成斐波那契数列
fibonacci :: [Integer]
fibonacci = 0 : 1 : zipWith (+) fibonacci (tail fibonacci)

-- 获取前n个斐波那契数
firstNFibs :: Int -> [Integer]
firstNFibs n = take n fibonacci

-- 计算斐波那契数列中第一个大于n的数
firstFibGreaterThan :: Integer -> Integer
firstFibGreaterThan n = head $ dropWhile (<= n) fibonacci

main :: IO ()
main = do
    print $ firstNFibs 10  -- 输出前10个斐波那契数
    print $ firstFibGreaterThan 1000  -- 输出第一个大于1000的斐波那契数

案例研究

1：Standard Chartered（渣打银行）—— 核心金融系统的架构重构

1：Standard Chartered（渣打银行）—— 核心金融系统的架构重构

背景: 作为一家全球性银行，渣打银行在 2010 年代初期面临着遗留系统维护困难的问题。其核心交易和风险系统主要用 Java 和 KDB（一种基于 q 语言的时序数据库）编写，代码库庞大且复杂，难以适应快速变化的监管要求和业务逻辑。

问题: 随着业务逻辑的复杂度增加，传统语言的类型系统难以在编译期捕获复杂的业务规则错误，导致运行时错误频发。此外，多线程并发处理金融数据时，极易出现竞态条件和死锁，系统的可维护性和扩展性达到了瓶颈。

解决方案: 渣打银行的 MoHS（Modular Haskell）团队决定引入 Haskell 进行核心系统的组件重写。他们利用 Haskell 强大的静态类型系统来建模复杂的金融产品，使用 GHC 编译器的高级特性（如 Software Transactional Memory，软件事务性内存）来管理并发状态。他们并没有完全替换旧系统，而是通过 Haskell 编写高性能、高可靠性的中间件和业务逻辑层，与现有基础设施集成。

效果: 通过引入 Haskell，银行在编译阶段就拦截了约 90% 以上的运行时错误，极大地提高了系统的稳定性。利用 STM 机制，开发者能够以更直观的方式编写无锁并发代码，消除了多线程环境下的数据竞争风险。最终，该系统成功处理了银行每天数百万笔的实时交易，代码行数相比 Java 实现大幅减少，且长期维护成本显著降低。

2：Facebook（Meta）—— 社交图谱垃圾信息过滤系统

2：Facebook（Meta）—— 社交图谱垃圾信息过滤系统

背景: Facebook 每天需要处理数十亿条用户动态和评论。为了防止垃圾信息和恶意内容的传播，平台需要一个能够实时分析文本语义、检测违规模式并进行处理的反垃圾系统。

问题: 早期的反垃圾系统主要使用 PHP 和 Python 编写。然而，随着用户量的爆炸式增长，脚本语言的性能瓶颈日益凸显，导致处理延迟增加。同时，复杂的文本匹配规则和状态机逻辑在弱类型语言中极易出错，且难以进行形式化验证，系统经常出现误判或漏判。

解决方案: Facebook 的工程师团队（包括著名 Haskell 专家 Simon Marlow）使用 Haskell 重写了核心的反垃圾邮件引擎。Haskell 的惰性求值特性使得处理大规模数据流更加高效，而其强大的代数数据类型非常适合用于解析复杂的文本语法和构建抽象语法树。团队利用 Haskell 的高性能并发能力，构建了一个能够在线动态更新规则的规则引擎。

效果: 新系统上线后，处理同样规模的数据请求，所需的硬件资源减少了数倍，系统响应延迟显著降低。Haskell 的类型安全性确保了复杂的规则变更不会引入意外的副作用，使得团队能够更频繁地更新反垃圾策略。该系统成功支撑了 Facebook 海量用户的实时内容审核需求。

3：Tsuru Capital —— 高频交易系统

3：Tsuru Capital —— 高频交易系统

背景: Tsuru Capital 是一家位于巴西的量化交易公司，主要涉足高频交易（HFT）和套利领域。在这个领域，微秒级的延迟差异直接决定了盈利与亏损。

问题: 高频交易系统对延迟极其敏感，且逻辑极其复杂。传统的 C++ 虽然速度快，但内存管理极其危险，容易出现导致崩溃的内存错误。而 Python 等动态语言虽然开发快，但运行速度无法满足要求。团队急需一种既能提供接近 C 的性能，又能保证极高数学逻辑正确性的语言。

解决方案: Tsuru Capital 选择 Haskell 作为其核心交易系统的开发语言。他们利用 GHC 编译器生成的极其优化的机器码来保证执行速度。更重要的是，Haskell 的类型系统允许开发者在编译期对复杂的金融数学模型进行严格的推导和验证，消除了“空指针异常”等低级错误。他们还利用 Haskell 的并发原语构建了低延迟的事件驱动架构。

效果: 该系统展现出了极高的稳定性和低延迟特性。由于 Haskell 的不可变数据结构和纯函数特性，系统能够轻松利用多核 CPU 进行并行计算而不产生副作用。这种架构使得 Tsuru Capital 在竞争激烈的市场中获得了速度优势，同时，极低的崩溃率确保了交易策略的持续稳定执行。

最佳实践

最佳实践指南

实践 1：将代码视为可组合的领域特定语言（DSL）

说明: 超越简单的“代理编码”，即不仅仅是编写独立的脚本或函数，而是将代码库构建为一套高度可组合的内部 DSL。这意味着设计 API 时应使其读起来像是一种专门针对问题领域的语言。通过抽象掉底层的实现细节（如状态管理、错误处理），开发者可以用声明性的方式组合复杂的逻辑，从而提高代码的复用性和表达力。

实施步骤:

  1. 识别业务逻辑中的重复模式和核心原语。
  2. 设计高阶函数或代数数据类型来封装这些模式。
  3. 确保核心组件是纯函数或无状态的，以便于组合。
  4. 编写组合器，允许用户通过简单的拼接原语来构建复杂行为。

注意事项: 避免过度抽象。确保 DSL 的学习成本低于其带来的生产力提升，否则会增加团队认知负担。

实践 2：优先使用声明式编程而非命令式编程

说明: 声明式编程关注“做什么”而不是“怎么做”。在构建系统时，应优先描述系统的属性、规则和约束，而不是编写一系列指令来修改状态。这种做法通常与函数式编程范式紧密相关，能够显著减少副作用，使代码更容易推理、测试和维护。

实施步骤:

  1. 审查代码库中的循环和状态变量，尝试用 map、filter 或 fold 等高阶函数替换。
  2. 在处理配置或业务规则时，使用数据结构（如 JSON 或 Haskell 的 ADT）来描述规则，而非编写大量的 if-else 逻辑。
  3. 采用惰性求值或生成器模式，仅在需要时计算结果。

注意事项: 声明式代码有时会隐藏性能瓶颈。在处理大规模数据或对性能敏感的路径时，需要关注底层的计算复杂度。

实践 3：构建可扩展的抽象层

说明: 不要为每一个具体用例编写特定的代码，而是构建能够适应未来变化的抽象层。这通常意味着定义接口或类型类，使得具体的实现细节可以独立于高层逻辑进行替换或扩展。这种“开放封闭原则”的应用是构建长期维护的大型系统的关键。

实施步骤:

  1. 定义清晰的接口或协议，描述组件需要做什么，而不是如何做。
  2. 依赖注入：将具体的实现作为参数传递给高阶模块，而不是硬编码依赖。
  3. 使用类型系统强制接口的一致性，确保所有实现都符合契约。

注意事项: 过早的抽象是万恶之源。只有在有两个或两个以上的不同实现需求时，才考虑引入抽象层。

实践 4：利用类型系统作为设计工具

说明: 强类型和静态类型系统（如 Haskell 的类型系统）不仅是捕获错误的工具，更是设计辅助工具。通过精心设计类型，可以“使非法状态无法表示”。这意味着类型结构应该直接映射业务领域模型，从而在编译阶段就排除掉大量运行时错误。

实施步骤:

  1. 使用代数数据类型精确建模业务状态，避免使用通用的字符串或整数来表示状态。
  2. 利用类型参数和泛型来捕获代码中的共性，同时保持类型安全。
  3. 编译时即进行严格的类型检查，不要依赖运行时的类型断言。

注意事项: 复杂的类型定义可能会增加初学者的上手难度。需要在类型安全性和代码可读性之间找到平衡。

实践 5：采用“无代理”的自动化测试策略

说明: 虽然标题提到“超越代理编码”，但这并不意味着放弃自动化。相反，应建立一种不依赖于外部智能代理的、确定性的测试体系。测试应该覆盖属性的普遍性，而不仅仅是具体的案例。基于属性的测试是比基于示例的测试更高级的实践。

实施步骤:

  1. 编写基于属性的测试，自动生成大量输入来验证定律或不变量。
  2. 将测试作为代码规范的一部分，确保测试用例能够准确反映业务需求。
  3. 集成 CI/CD 流程，确保代码变更立即触发自动化验证。

注意事项: 测试代码本身也需要维护。避免编写脆弱的测试，即那些因为实现细节微调而频繁失败的测试。

实践 6：关注代码的可读性与可维护性

说明: 代码被阅读的次数远多于被编写的次数。最佳实践要求将代码写得像散文一样清晰。对于复杂的逻辑，必须辅以清晰的文档和注释。此外，应避免为了炫技而使用过于晦涩的语言特性，保持代码的朴实和直接。

实施步骤:

  1. 遵循语言社区公认的命名约定和代码风格。
  2. 对非直观的业务逻辑编写文档注释，解释“为什么”而不仅仅是“是什么”。
  3. 定期进行代码审查，重点关注代码的清晰度和潜在的理解障碍。

注意事项: 注释不应成为代码质量的补丁。如果代码难以理解，首先应尝试重构代码，使其自解释，然后再添加注释。

实践 7：持续重构以降低技术债务

说明: 代码不是一次性完成的艺术品，而是持续演

学习要点

  • 基于对 Haskell 社区及“Beyond agentic coding”这一主题的深度解读，以下是总结出的关键要点：
  • 真正的软件工程价值在于构建高可信度的系统，通过数学化证明和强类型系统（如 Haskell）在编译期消除错误，而非依赖运行时测试或 AI 生成代码。
  • “超越代理式编程”的核心在于从“编写代码”转向“设计规范”，即通过精确的类型定义来描述程序的行为，让编译器强制执行这些规则。
  • 代码的可维护性远比初期的编写速度重要，使用纯函数式编程可以显著降低认知负荷，使代码逻辑更易于推理和重构。
  • 将业务逻辑与副作用（如 I/O）彻底分离，不仅提高了代码的模块化程度，还使得核心逻辑更易于测试和并行化处理。
  • 投资于编译期的类型检查是最高效的调试方式，它将大量的运行时错误转化为编译时错误，从而极大降低了修复缺陷的成本。
  • 优秀的编程语言应具备极强的表达能力，能够通过类型系统直接捕获复杂的业务约束，从而减少对文档和人工审查的依赖。

常见问题

1: 文章标题中的 “Beyond agentic coding”（超越代理式编码）具体指什么？

1: 文章标题中的 “Beyond agentic coding”（超越代理式编码）具体指什么？

A: “Agentic coding”（代理式编码）通常指利用具备一定自主性的 AI 智能体来辅助编写代码的过程。标题 “Beyond agentic coding” 暗示了作者的观点：虽然 AI 智能体目前很流行，但它们并不是提高编程效率或解决软件危机的终极答案。文章主张不应仅仅满足于让 AI 模仿人类程序员的行为（即“代理”），而应该探索更本质的改进，例如通过数学化、形式化验证或改变编程范式本身来从根本上提升软件的可靠性和开发效率。它呼吁业界关注比单纯“自动化写代码”更深层次的软件工程变革。

2: 为什么文章标题提到 “Haskell for all”？Haskell 在这个讨论中扮演什么角色？

2: 为什么文章标题提到 “Haskell for all”？Haskell 在这个讨论中扮演什么角色？

A: “Haskell for all” 是作者 Gabriel Gonzalez 的著名博客名称，也是他长期倡导的理念。在这个语境下，Haskell 代表了“高抽象度”和“强类型系统”的编程语言典范。文章可能暗示，与其依赖不可靠的 AI 代理生成代码，不如使用像 Haskell 这样的语言，利用其类型系统在编译期捕获错误，从而减少运行时 Bug。Haskell 在此不仅是工具，更是一种象征，代表了通过数学严谨性和高级抽象来构建“正确”软件的路径，这与依赖概率性生成代码的 AI 代理形成了鲜明对比。

3: 作者认为 AI 编码代理的主要局限性是什么？

3: 作者认为 AI 编码代理的主要局限性是什么？

A: 根据文章及相关讨论的语境，作者认为 AI 编码代理的主要局限性在于它们本质上是基于概率的“随机鹦鹉”。它们通过模仿训练数据中的代码模式来生成程序，而并不真正理解代码的语义或逻辑。这意味着 AI 生成的代码可能看起来是正确的，甚至能通过测试，但仍然可能包含微妙的逻辑错误或安全漏洞。此外，调试 AI 生成的代码可能比从头编写更困难，因为人类维护者可能无法理解 AI 的生成逻辑。作者认为，这种缺乏形式化验证基础的生成方式，无法解决软件工程中核心的可靠性问题。

4: 文章是否在主张完全禁止使用 AI 进行编程？

4: 文章是否在主张完全禁止使用 AI 进行编程？

A: 不是。文章的主张并非完全排斥 AI，而是反对盲目依赖“Agentic”模式（即让 AI 像人类代理人一样独立完成大量编码任务）。作者可能更倾向于将 AI 视为一种辅助工具，用于形式化验证、代码转换或作为高级编程接口的辅助，而不是让 AI 代替人类进行核心逻辑的构建。核心观点是：为了实现“Haskell for all”所设想的软件可靠性目标，我们需要的是数学上的确定性，而不是 AI 提供的概率性猜测。

5: Hacker News 社区对这篇文章的主要争议点在哪里？

5: Hacker News 社区对这篇文章的主要争议点在哪里？

A: Hacker News 上的讨论通常呈现两极分化。一方面，支持者赞同作者对 AI 编码不可靠性的担忧，认为形式化方法和强类型系统（如 Haskell）才是构建关键基础设施的正途。另一方面，反对者认为作者过于理想化，忽视了工业界的现实。他们指出，Haskell 等语言的学习曲线陡峭，采用成本高，而 AI 编程工具虽然不完美，却能显著提高普通开发者的短期生产力。争议的核心在于：是追求理论上的完美（数学证明、零错误），还是拥抱实用主义的效率（AI 辅助、快速迭代）。

6: 既然 Haskell 这么好，为什么没有在工业界像 Python 或 Java 一样普及？

6: 既然 Haskell 这么好，为什么没有在工业界像 Python 或 Java 一样普及？

A: 这是一个常见的衍生问题。虽然文章推崇 Haskell 的特性，但工业界普及面临几个主要障碍：首先是学习曲线，Haskell 的范畴论和函数式编程概念对习惯了命令式编程的开发者来说很难掌握；其次是生态系统和库的支持不如主流语言丰富；最后是招聘成本，寻找合格的 Haskell 开发者非常困难且昂贵。文章的观点可能是，虽然 Haskell 普及难，但其在软件可靠性方面的优势值得我们在设计未来工具或语言时借鉴，或者至少不应为了迎合 AI 而降低编程语言的严谨性标准。

7: 如果不使用 AI 代理，作者建议如何解决软件复杂性带来的问题？

7: 如果不使用 AI 代理，作者建议如何解决软件复杂性带来的问题？

A: 作者建议的解决方案通常回归到“软件工程的根基”。这包括使用具有强大表达能力的类型系统来通过编译器检查错误，采用函数式编程来减少副作用（Side Effects），以及利用形式化方法来证明算法的正确性。简单来说，就是通过更严格的数学约束和更高级的抽象来管理复杂性，让计算机在代码运行之前就发现错误，而不是写完代码后再依赖 AI 或人工测试来修补漏洞。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在传统的命令式编程中，我们经常使用“循环”来处理列表数据。请尝试使用 Haskell 的标准库函数（如 map, filter, 或 foldr）重写一个简单的 for 循环逻辑，例如：计算一个整数列表中所有偶数的平方和。

提示**: 思考如何将“遍历”和“条件判断”这两个步骤解耦。你需要先筛选出符合条件的元素，然后对这些元素进行变换，最后将它们合并。注意 foldl 和 foldr 在处理累加时的区别。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章