主 题：[转载]rutis：让软件在运行中自己接上这个世界
发 布 者：megatron
标签分类： 技术
时 间：2026-10-23 14:42:13
内容预览：原文：微信公众号「Arcships」《我们想让软件自己去接上这个世界》https://mp.weixin.qq.com/s/zpi1tgZMoBaLNVqMzSjDQg很长一段时间里，软件和环境的关系是固定的：软件被写好、发布出去，然后在一个它无法改变的世界里运行。世界变了——接口升级了，新的系统出现了，旧的服务下线了——软件就等着人去跟进。这件事正在变化。模型让软件第一次有了改自己的能力。写一段接入代码、试一下、发现不对再改，这些曾经要排进迭代计划的事情，现在可能只需要几分钟。改代码的成本塌下来以后，一个新的问题浮了上来：软件怎样持续地接触环境、适应环境，并在环境里做试验和探索？这是 rutis 想回答的问题。rutis 是一个 MIT 开源的插件运行时：让 agent 用 Rust、TypeScript、Python、Go 写插件、换插件、热重载插件，并且跨进程、跨机器运行。项目地址：github.com/arcships/rutis。一、当改代码不再昂贵过去我们设计软件时，默认改动是昂贵的。所以要先把需求想清楚，把接口定稳，把依赖锁死，然后尽量少动。当改动变得便宜，这套默认就不成立了。一个能自我迭代的软件，它的日常不是“运行”，而是“试”：今天要接一个内网的日历系统，先写一版试试；明天发现那个系统有更好的接口，换一版；后天要用一台 GPU 机器上的模型，把一部分能力挪过去；再过一阵，用得最多的那部分要更稳、更快，用另一种语言重写。每一次都是一个小改动。但这样的小改动一周可能发生几十次，而且发生在一个正在运行的系统里。难点于是从“怎么写出来”变成了“怎么持续地换”：换的时候，旧的连接、定时器、监听有没有留下来？依赖它的部分会不会跟着坏？换坏了能不能退回去？换到另一台机器、另一种语言上，用它的那些代码要不要跟着改？这些问题决定了一个软件能不能真的“长”起来。二、等别人适配
直达链接： https://www.nodeseek.com/post-1003521-1
发 布 者：megatron
标签分类： 技术
时 间：2026-10-23 14:42:13
内容预览：原文：微信公众号「Arcships」《我们想让软件自己去接上这个世界》https://mp.weixin.qq.com/s/zpi1tgZMoBaLNVqMzSjDQg很长一段时间里，软件和环境的关系是固定的：软件被写好、发布出去，然后在一个它无法改变的世界里运行。世界变了——接口升级了，新的系统出现了，旧的服务下线了——软件就等着人去跟进。这件事正在变化。模型让软件第一次有了改自己的能力。写一段接入代码、试一下、发现不对再改，这些曾经要排进迭代计划的事情，现在可能只需要几分钟。改代码的成本塌下来以后，一个新的问题浮了上来：软件怎样持续地接触环境、适应环境，并在环境里做试验和探索？这是 rutis 想回答的问题。rutis 是一个 MIT 开源的插件运行时：让 agent 用 Rust、TypeScript、Python、Go 写插件、换插件、热重载插件，并且跨进程、跨机器运行。项目地址：github.com/arcships/rutis。一、当改代码不再昂贵过去我们设计软件时，默认改动是昂贵的。所以要先把需求想清楚，把接口定稳，把依赖锁死，然后尽量少动。当改动变得便宜，这套默认就不成立了。一个能自我迭代的软件，它的日常不是“运行”，而是“试”：今天要接一个内网的日历系统，先写一版试试；明天发现那个系统有更好的接口，换一版；后天要用一台 GPU 机器上的模型，把一部分能力挪过去；再过一阵，用得最多的那部分要更稳、更快，用另一种语言重写。每一次都是一个小改动。但这样的小改动一周可能发生几十次，而且发生在一个正在运行的系统里。难点于是从“怎么写出来”变成了“怎么持续地换”：换的时候，旧的连接、定时器、监听有没有留下来？依赖它的部分会不会跟着坏？换坏了能不能退回去？换到另一台机器、另一种语言上，用它的那些代码要不要跟着改？这些问题决定了一个软件能不能真的“长”起来。二、等别人适配
直达链接： https://www.nodeseek.com/post-1003521-1
