Spark

Spark

Short notes and half-formed ideas — worth saying, but too small for a full essay. A running feed of what I’m building, reading, and paying attention to.

169 sparks Raw data

Synced from 即刻 (168), updated Oct 5, 2026

关于 DSH,抛砖引玉。

基本信息:

  1. Tianyi Cui 本身就有 FP 函数式编程的经验。
  2. DSH 的设计充分吸收了 Effect / Coeffect 的思想。
  3. 我在公司的 Spark 上说,Agent Loop 就是 Monad 和 Comonad 的交织美学。

技术观点:

众所周知,如果用上 FP,大概率是为了让一套抽象的计算模型可以得到严谨的形式论证,且是数学(范畴论等)层面可以推演的,就像 TLA+ 之于分布式计算领域。

这种严谨性论证的诉求,从现有的资料可以分析推断,起因是 DSH 找到了一种 Agent Loop 的核心抽象,且一开始就是朝着 RSI (递归自我进化)去的,不理解这个目标,就很难理解为什么这个抽象可以优雅地做到,而其它抽象则不行。

这个抽象就是 Monad 和 Comonad 的美妙交织:源源不断地向环境产生「副作用」- 时间维度的向后发散(Monad)以及从环境中不停获取上下文 - 空间维度的向前聚合(Comonad),互为「对偶」,这个交织是完全动态且响应式的,且因为是基于 FP 范式的,所以天然就叠加了它的严谨性和所有已知优点,可以让 DSH 在 RSI 过程中随便怎么折腾也能做到「稳定状态」,这就是 FP 众所周知的威力:Pointer-Free、Composable 等等。

这是一个在 「运行时」就可以达到「优雅自进化」架构的 Harness。

不是让模型自己去目录下改几个文件,就敢叫「自进化」的,DSH 创新地在 Agent Harness 领域引入函数式编程范式(门槛极高),这种跨学科领域的创新,本身就是顶级的,值得深入学习。

其它比如产品层面的讨论,那是完全另外一个角度。

15 4

Years deep in workflow automation now, from IFTTT fandom to reading the Node-RED and NoFlo source, to pulling apart n8n and Zapier. The itch that won’t leave: a platform that makes Automate Everything ordinary instead of a luxury. Also brewing a Skill Masters course on it under Code & Art Studio.

围绕 Durable Execution & Pi Durable 说几句:

「Durable Execution」 在 「Agent Infra」 领域被持续重视和提起,是 「Agent」 进入 「Cloud」 环境面临规模化挑战下的必然趋势。

当下社区热议的 Pi 终于把原来脏兮兮的 「Harness」 层拿了出去,推出了具备 「Durable」 特性的新包。

从服务端与分布式领域的工程架构视角来看,Pi Durable 在设计上亲和 「Actor Model」,其核心在于计算与状态在物理上的绑定,一旦抓住这个本质,很容易推导出其合适的载体就是当下流行的那些以 「Actor Model」 为设计核心的计算单元,例如 Cloudflare 的 DO、Node / Deno 之父写的 celld 以及 Rivet 等等,因此,它们也确实能第一时间蹭上热度,😄。

然而,这个 「Actor Model」 不是严格意义上的,更不可能算是 「Virtual Actor」,因为它存在一个根本限制,那就是「位置不透明」。

放弃位置透明性(也有号称正在实现中的),在单机维度锁定物理拓扑以降低网络通信开销,其初衷是为了打破长上下文场景下的 I/O 瓶颈并维持流式长连接特性。在多租户模型中,这种绑定设计最大的优势在于较低的基础设施依赖度,开发者无需在外部运维一套复杂的分布式事务日志集群,即可依靠内嵌存储做到开箱即用的持久能力(Checkpoint 机制),在面对轻量级常驻「Agent」、本地终端交互或边缘计算等场景时,能换取很高的研发效能与低成本优势。

然而,在 LLM 动辄数秒的推理时长面前,本地 I/O 相比网络通信的时延优势在总耗时中会被稀释,这也让绑定架构所追求的局部时延优势不再明显,反而让系统在生产环境进行规模化时,必须在应用层解决由于计算状态一体化带来的单机物理瓶颈,以及长周期状态机由于依赖历史日志进行确定性重放而带来的代码热升级与「Schema Migration」难题,单租户 Sandbox 架构同理。

相比之下,以 Restate 或 Temporal 为代表的存储(状态)计算分离的「Stateless Actor」架构,虽然每次状态持久化都必须跨越网络边界并承担确定的网络系统开销,但它通过将状态外置于独立日志引擎,在 LLM 耗时占绝对大头的物理现实下,用完全可接受的网络级 I/O 成本,换取了相对好的版本平滑升级能力与真正的无状态弹性扩展,从而成为 Cursor 等重型云端 「Coding Agent」 的主流选择。

持久执行并无银弹,Pi Durable 偏向于为轻量级长时任务提供一个高确定性、低依赖的应用级轻量宿主;而 Restate 等代表的计算与状态分离路线,则是用明确的网络开销换取了集群治理与工程演进的自由。

从业务场景角度来看,两者甚至可以相辅相成。

5

我在最近两天的极高密度生产级 Coding 实践中,使用 Opus / Fable 结合 Formal Verification(主要是 TLA+)来验证 Agent Service 在分布式环境下结合 Durable Execution 的 Race Condition 测试,效果相当地好,不仅发现诸多潜在的问题,也让回归变得更加踏实。

我曾短暂研究过形式验证系统的相关工具,尤其分布式领域的,如今在 AI Coding 时代重新放大它的价值,让我非常兴奋,也欢迎长期研究此领域的同学可以深入交流。

类型系统 / 形式验证,以及基于数学之上的种种编程范式,都是为了让程序变得可预测,可被证明。

而这些,必将成为 AI 时代写出高质量运行时及代码的重要一课。

对于做 Infra 的同学更是如此,共勉。

永无止境的 Loop 吧。

6

给 Jev 做了一个生产级别的 tiny sdk,同时让我感慨,真的要断代了啊,什么 Tagged Template Literals、什么 Type Safe,谁(大家)还(一定要)关心啊?!

12 1

今天,我把青春里的一款游戏找回来了。

这个项目并不是从写代码开始的,而是从一段已经有些模糊的记忆开始。

我只记得,在曾经的功能机和 Java ME 时代,有一款像素风格的摔角游戏。它运行在 240×320 的小屏幕上,有熟悉的按键音、音乐、角色和擂台,也承载着我青春时期的一段回忆。

于是,我开始从零调研和搜索。

从零散的画面、视频和文字线索,到一次次截图、OCR 和资料比对;从确认开发商和游戏名称,到最终找到它的原始版本——

它就是 Gameloft 在 2008 年推出的:

《Lucha Libre: Desafío Total》

找到它之后,我没有选择根据截图做一个“看起来相似”的版本,而是希望尽可能完整地把真正的原作带回来。

我分析了原始 JAR、Manifest、游戏入口、240×320 显示逻辑、输入映射、音频和本地存档系统;搭建 Java ME 运行环境,移除模拟器菜单和文件选择器,让游戏可以在网页中自动启动。

然后,我为它重新设计了一台属于浏览器时代的像素掌机:

  • 原始 J2ME 游戏逻辑与资源直接运行
  • 保留原版画面、动画、音乐、音效和操作方式
  • 保留原作本地存档,刷新和重新启动后仍可继续
  • 电脑支持键盘和网页实体按键
  • 手机和平板支持完整的多点触控 Java ME 键盘
  • 自动适配横屏、竖屏、平板和桌面设备
  • 支持全屏、暂停和重新启动
  • 可以直接双击单 HTML 运行
  • 打开网站即可自动进入游戏,无需安装 Java、模拟器或选择 JAR

过程中,我还在真实 Android 环境中解决了白边、颜色失真和严重闪烁的问题。最后保留下来的,不只是一个“能运行”的游戏,而是一段尽可能完整、稳定,并且依然可以继续游玩的青春记忆。

对别人来说,它可能只是一款已经被时代遗忘的 Java 游戏。

但对我来说,这是曾经握在手里的功能机,是按下数字键时的触感,是那个 240×320 像素屏幕里的另一个世界。

今天,它终于又可以被打开了。

不是重制,不是模仿。

而是让那段曾经真实存在过的游戏记忆,在现代浏览器中重新响起开场铃。

The bell rings again. 🛎️

🎮 在线体验 https://lucha.xiaoa.name

💻 GitHub 项目源码 https://github.com/a-side-project/lucha

全过程使用 https://lite.ego.app

这是一个个人非商业技术研究与游戏保存项目。原作、名称、音乐及相关素材权利归其各自权利人所有。

9

These are NEW ERA Agent Frameworks: Eve / Flue / Rivet AgentOS / …

NEW KEY WORD of Agent Runtime: Durable Execution

Now the NEW In/Egress Controller needs to be rebuild.

1 1

这是我见过思路最清晰、最不破坏 Chrome 用户习惯,同时又兼顾 Agent 和人类共同使用的浏览器。 而且 Pro 版听说也马上发布。

3

模型生成出来的 Timeline 组件,小圆点对不齐中线,Border Left 清一色的丑。

人类的价值还在,别慌,经验和品味永远在细节里。

你一定比 AI 更细心。

2

最近 OpenAI 开源了一个从 Linear 上不停拉取 issues ,然后并发多个 Agent 执行长时 Codex 任务的框架,这本来没什么值得说道的,直到看到这个框架居然是用 Elixir 开发的。

说到 Elixir 就不得不说到 Erlang 以及 BEAM VM,而后不得不提到 Actor,最近 Elixir 的作者何塞也发表文章,其认为今天所有其他语言想尽办法实现的可靠多 Agent 架构,Actor 并发模型在强大的 BEAM 上早已拥有,OTP 9 个 9 的高可用不是吹的。

Erlang 当年怎么支撑工业级别的电信系统可靠运行,40 年后,Elixir 就可以怎么支撑海量 Agent 调度和编排,正所谓要么不开张,开张吃 10 年。老家伙们的特点就是靠谱,不得不服,值得投入精力深入学习。

且 Elixir 对模型友好,CC 的代码补全率甚至高于 C#。

我个人在很早的时候在阿里接触的 AKKA,24 年带团队做基于 AKKA 的 Agent 框架,当时的这个选型其实很小众,即便在当时也仅看到 Model Scope 的 AgentScope 有受到 Actor 启发,但是我坚持认为 Actor 和多 Agent 调度天然架构适配,至今也是,所以看到 OpenAI 这个框架的选型思考,颇为感慨。

我相信,Elixir 以及 Erlang 可以在 AI 时代发挥重要作用,让我们拭目以待。

7

AI Agents are fundamentally rewriting the infra playbook.

We’re moving from ephemeral functions to persistent sandbox environments.

The future isn’t just containers;

It’s Stateful Containers.

1

小时候,雨后的清澈小河里,小龙虾会抓在芦苇杆上,非常呆蠢,基本一钓一个准,经常不一会就钓到一桶,拎回家红烧吃,到后来吃小龙虾的店满大街都是。

现在人类要完蛋了,小龙虾已经成精了,要来报仇了,让你们就知道:吃吃吃!

1

昨天看到 Browser Use 作者发的文章《代理框架的惨痛教训》,有感而发,文章本身的核心意思是一个不那么新鲜的观点:Agent 根本不需要框架,只需要一个主 Loop 加合适的工具,此前,Claude Code 的原理逆向分析被曝光后,大家就已发现这个「秘密」。

但我想说点不一样的东西。

请求大模型并且得到回应的执行过程本身是「无状态」的,而且,就算它内部有「状态」,也不一定和你程序内部的「状态」一致,原因很简单:大模型看不到你的程序,你的程序状态也只能通过数据给到它,所以就会出现很多莫名其妙的问题,比如:明明任务还没有完成,模型莫名其妙提前终止运行等等,(文中也提到了用一个 tool 来解决这个问题)。

所以,我认为今天大部分 Agent 框架的思路仍然不是遵循的「第一性原理」,仍然是要凌驾(以控制流为核心)于模型之上的设计。

我个人认为,Agent 的命题只有一个:那就是给模型做个「解释器」,对它友好的解释器,它生成的数据要解释到位,解释全,把它当成一个 Generator,那么 Agent 一开始就应该是面向数据流的,而不是控制流的。

然而,受到这样启发的框架并不多,接下来我会在 AStack 的博客上陆续分享背后的思考和打造过程的技术干货。

https://astack.tech/blog

PS:Agno 框架的主 Agent 实现,单文件就有超过 1 万 1 千多行代码,认真的吗?😄

4

我个人认为,RLM Pattern(来自 MIT 的突破上下文窗口限制的递归模型论文)有希望成为 2026 年所有 Agent Harness 的内置 Pattern 之一,也和 Cursor 最新的「动态上下文」的实践不谋而合。

虽然我无法知晓 Cursor 动态上下文的技术实现,但是我在 AStack 框架中完整实现了一个生产级可用(解决了论文中提及的问题)的 RLM Pattern 的 Agent,并附录 Real-World Example 以及 OOLong Benchmark。

详细思考和实现细节见官方博客。

5