Cyrus Omar：实时编程与人与 AI 共享的计算公共空间

Cyrus Omar 从一个简单问题开始：什么样的反馈循环才有用？钢琴家按下琴键后立刻听到声音，随即就能调整。编程中，从编辑代码到看到效果通常需要等待更长时间。

好的反馈要及时、具体，让人能够将行动与结果联系起来。如果钢琴要等很久才发出声音，学习和纠正演奏就会困难得多；编程工具也遵循同样的道理。

程序尚未完成，或包含语法及类型错误时，传统编辑器和编译器可能留下信息断层。依赖解析或类型检查成功的服务会消失，恰好发生在程序员正在编辑、可能最需要反馈的时候。

Hazel 是共同设计的研究性编程环境和编程语言，旨在缩小这一断层。Omar 演示快速排序的实现，说明代码尚未完成时，编辑器如何持续提供信息。

他从递归函数开始：以列表第一个元素为基准，将其余元素分区，对各部分递归排序，再将结果与基准元素组合。在构造其余部分时，Hazel 允许他将表达式的某些部分留为空洞。

传统解析器可能在类型检查器看到表达式之前，就拒绝不完整的表达式。Hazel 则明确表示缺失或出错的部分，让程序其他部分保持有意义的结构，并继续获得编辑器支持。

用户可以在表达式上放置探针，显示程序运行时该表达式取到的值。即使缺少一部分，结果也可以包含未完成计算的符号表示，而不是完全没有反馈。

演示暴露了一个错误：本应排好序的列表里出现了重复的 3。Omar 沿递归函数追踪数值，而不是等整个程序完成后，只凭最终输出调试。

中间结果帮助他定位各部分组合方式中的问题。通过检查分区和递归调用，他可以看到代码中看似微小的改动如何立即影响输出。

一位观众询问递归限制。Omar 解释说，实时环境必须处理可能无界的计算；实际运行时会施加限制，避免不终止的程序让编辑器卡住。

谈到副作用时，Omar 说 Hazel 受到 Haskell 处理效应方式的启发：可以先将 I/O 计算为一个值，等用户希望执行相应操作时再显式运行。编辑过程中反复求值时，这一区别十分重要。

测试关键字直接在编辑器中报告断言结果。探针则不同：它展示中间值，包括递归函数多次调用时的值，让程序员能够检查计算内部发生了什么。

进入选定样本会沿调用跳转到函数定义，并选中对应的调用。界面可以显示多个样本，也可以聚焦其中一个，使同一表达式的重复执行更易理解。

一位观众询问，将某部分替换为空洞后，是否能得到部分已知的值。Omar 演示了这一点：结果可以将已知的列表结构与符号空洞结合，在真正需要缺失信息之前继续求值。

另一个问题涉及程序不完整或不一致时的类型推断。Hazel 运用渐进类型和部分类型信息的思想：它可以展示约束所支持的信息，而不假装所有约束都已成功求解。

收集所有中间值有成本。Omar 讨论了限制某一点采集样本数量等控制方法，并将现有的插桩机制与即时编译器等未来可能的优化区分开来。

观众还问到，为什么某个分支没有运行，有些表达式却仍然高亮。Omar 解释了显示效果与所选位置可用样本之间的关系：未执行的分支没有对应的运行时样本。

Omar 继续追踪递归调用及其分区结果。展示连续的上下文，有助于看清每次递归调用接收和产生的内容，而不是将所有执行折叠成一个值。

他调整实现并测试结果。实时测试立即显示哪些案例通过；一个错误案例则表明还需要进一步修正。

接下来的演示从数字列表转向更丰富的值。Hazel 可以在编程环境中将表格呈现为交互对象，把数据的可视化视图与底层程序连接起来。

通过菜单给成绩表排序，会产生相应的程序变换。图形交互和文本代码是处理同一计算过程的两种相互关联的方式，而不是与计算脱节的独立可视化。

一个音乐示例结合了类似钢琴的音符选择器、增益与声像控件以及交互式触控板。这些控件让用户直接操作程序中的值并听到结果，同时仍然嵌在可组合的编程语言中。

同样的反馈问题也延伸到 AI 智能体。在一个智能体群中，多个智能体可能共同处理同一代码库，既需要彼此协调，也需要与人协调。缓慢的工具和冗长的输出同样会拖延它们获得反馈。

随着模型生成速度提高，重新编译、重新执行和重新建立上下文可能成为瓶颈。智能体还必须处理大量文本日志，找回后续行动所需的信息。

Omar 认为，实时增量环境既能帮助人，也能帮助智能体。即使智能体通常能生成语法正确的代码，它们仍需要及时了解改动的行为和含义。

程序发生变化时，增量执行会复用先前的工作。每次小改动之后，环境不必从头重跑每项测试，而可以追踪受影响的计算，只更新需要改变的部分。

团队一直在执行和类型检查两方面投入增量化工作，并对底层语义开展形式化研究。Omar 将快捷记忆化描述为降低重复计算成本的研究方向，而不是保证所有工作都会消失。

智能体还可以通过结构化动作语言与 Hazel 交互，不必只依靠 shell 命令和文本搜索。这些动作可以用智能体能直接使用的形式，提供代码及改动的语义信息。

这些智能体集成仍处于早期实验阶段，Omar 说正式研究正在进行。其假设是，更简短、信息更丰富的反馈可以减少智能体检查自身进展所需的工作量和 token；他并未声称已有确定的基准测试结果。

人工审查是另一个反馈循环。AI 提高了提出改动的速度，审查者可能面对越来越多积压的拉取请求，需要理解的不只是差异，还有背后的推理和顺序。

Omar 介绍了一个用于叙事式变更导览的 VS Code 插件：结构化说明可以按有意义的顺序引导审查者浏览改动。它旨在帮助人们评估发生了什么，而不必只凭原始差异自行还原过程。

协作还需要一种能够支持同时编辑的表示方式。Omar 介绍了使用无冲突复制数据类型进行结构化协作编辑的研究，其中将代码移动作为一等操作，避免位置变动造成不必要的冲突。

版本管理是另一个问题。他借鉴 Unison，讨论根据内容识别定义并保留旧版本，让新版本与现有引用共存，并使更新能够审慎进行。

当智能体可以访问工具和共享资源时，安全尤为重要。Omar 主张采用细粒度对象能力：智能体应获得适合特定任务的能力，而不是不受限制地访问操作者所能使用的一切。

所提架构将基线策略及证明与任务专属限制结合起来。他讨论了让其他智能体协助监督或限制访问的可能性，以及针对医疗数据等敏感场景的信息流策略。这是研究方向，并不意味着整个问题已经解决。

Omar 更宏大的愿景是一个实时计算公共空间，让人与智能体共同处理共享的数据、程序和说明。丰富的图形界面可以让非专业程序员也能有效参与。

他以一个环境数据工作空间说明这一构想：其中结合了文字、表格、地图、图表和可执行的数据变换。不同参与者可以使用合适的视图工作，同时底层计算保持关联，并随输入变化而更新。

一位观众质疑现有工具不足的说法：他们的组织已经借助 Git 运行数千个智能体。Omar 承认 Git 可以发挥作用，认为尚待回答的问题是，何时更细粒度的结构化协作会有用，特别是在并发工作时。

他区分了团队在基础研究上的成果，与证明这种方法能在大规模生产智能体群中奏效之间的差别。后者仍需要实证验证；这场演讲提出的是实验方向，而非已经证明可以取代现有工作流的方案。

讨论验证时，Omar 提到了形式化基础和证明工具方面的工作。证明可以确立指定模型的性质，但设计系统并让它在真实协作中实用，仍是重大的研究任务。

一位观众询问公共空间如何处理非常大的外部数据集。Omar 将概念模型比作电子表格，但指出行星尺度的数据不会真的全部存放在编辑器内存中。

外部数据接口可以将运行时连接到外部存储，并将过滤等操作下推到存储端，方式受到 Apache Spark 启发。Omar 提出针对大型数据集，未来可能通过即时编译接入 Spark，并欢迎进一步讨论。

有人问他的核心主张是否是所有代码都必须采用树形结构。Omar 回答，他更强烈的主张是以类型论作为本体的基础。与把每个事实都视为无类型的二元关系相比，积类型、和类型、函数及模块能更有效地表示不同种类的事物与关系。

他将自己的研究转化方式描述为：构建一个有吸引力、具备数学基础的系统，让其他人继续开发或从中汲取灵感。他提到图形化代码、实时编程和空洞方面更广泛的工作，作为思想可以跨社区传播的例子。

纯度有助于安全地在每次按键时求值。对于有副作用的语言，工具也可以接受执行这些副作用的后果，或者保守地识别看起来纯净的表达式；Omar 以 Chrome 开发者工具为后一种方式的例子。

另一位观众询问，随着代码变得图形化、智能体操作底层结构，人类还能理解多少。Omar 将设计归功于合作者，并指出 AI 让代码移植和库的构建更加容易，采用新语言的成本可能已经发生变化。

他的团队曾尝试将 Jupyter 笔记本等材料移植到 Hazel，用作数据分析案例。他认为计算机科学家有机会重新思考工具应该是什么样，而不必假定建立生态系统的成本永远不变。

最后一个问题是，当实时环境不断变化时，部署如何运作。Omar 认为更新更及时的气候数据和模型很有价值，但也承认软件用户需要稳定性，依赖不应在他们不知情时发生变化。

他再次提到 Unison 的方法：按内容寻址的旧版本仍可使用，是否将现有代码更新到新版本可以审慎决定。除了技术机制，良好的组织流程和沟通仍然重要。最后，他感谢了观众。