Renyi

Renyi 是 AI Agent 的脚本语言：由 Agent 编写，由你快速审阅，而且程序只能执行它声明的操作。

为什么选择 Renyi

如今，大多数替你运行的代码都由 Agent 编写。用当今的语言编写的代码，要么必须逐行阅读，要么只能盲目运行。Renyi 围绕这种分工而设计：由 Agent 编写，由人审阅，而语言让审阅只需一瞥。

1. 程序可以执行的操作都写在它的签名里。 每个函数都会声明其副作用（needs filesystem.read("data"), network.http("api.example")），并将其限定在路径或主机范围内、设置预算（at most 60 per minute）并加以约束（only to）。编译器会拒绝未声明的操作；运行时只允许这些操作，对程序的依赖项也同样如此。main 的签名就是整个程序的授权范围。
2. 每次运行都是证据。 运行可以记录、离线重放，并依据其清单（工具链、代码哈希、依赖项、授权范围、参数、结果）重现；--explain 会用程序作者写下的措辞讲述运行过程。你能以数据的形式了解运行做了什么。
3. 依赖项无法扩大你允许的范围。 软件包的副作用根据其源代码计算得出，绝不手动填写；如果某次更新会让程序获得更多能力，就会被拒绝，而不是事后才发现。
4. Agent 所需的工具都已内置。 项目地图、语义差异和按嵌入检索的文本块都是命令（renyi index、--diff、--chunks）；工具链是 MCP 服务（renyi mcp）；文档就是语法（purpose:）；每个错误都会附带修复方法，确保 Agent 下次尝试时能做对。
5. 任何人都能一遍读懂。 使用规范的英语，每个概念只有一种写法，布局统一，没有例外、没有 null、没有匿名函数、没有运算符重载。即使从未接触过 Renyi，审阅者也能从程序的签名中读懂它会触及什么。

public function active_adult_emails(path: Path)
  returns List of Email
  or fails with FileError or JsonError
  needs filesystem.read
  purpose: Read users from a JSON file and return the e-mails of active users who are at least 18.

  let text be filesystem.read_text(path) otherwise fail
  let users: List of User be json.parse(text) otherwise fail
  let emails be
    for each user in users
    where user.is_active and user.age is at least 18
    sorted by user.name
    collect user.email
  return emails
end

Renyi 是一种通用语言；它的首批用户是那些使用 Claude Code、Codex 等工具运行自动化任务，却不愿盲目运行 Agent 的 Python 代码的人。设计记录见 docs/design/08-positioning.md（决策 AH1 至 AH4）。

与其他方案的比较

每一行都是实现所保留、且一致性测试套件会检验的主张。其他语言是为其他任务构建的，也都能很好地胜任；此处的比较只针对一种任务：由 Agent 编写、且必须让人信任的程序。

对于由 Agent 编写的程序	Renyi	Python	TypeScript / Deno	Rust	Shell
运行前即可查看程序可能执行的操作	每个签名中都有声明，范围明确且设有预算，并由编译器检查	未声明；沙箱限制整个进程	面向整个进程的 --allow-* 标志	未声明；类型系统针对的是内存，而非效应	未声明
依赖项的效应	根据其源代码计算、锁定，并在效应范围扩大时拒绝	未声明	未声明	未声明	未声明
一次运行做了什么	由运行时记录、重放并复现	外部工具	外部工具	外部工具	set -x
错误意味着什么	每条诊断都按规则提供修复方案	回溯信息	消息	清晰易懂，面向程序员	退出代码
无需培训即可审查	使用常见英语，每个概念只有一种写法	程序员熟悉	程序员熟悉	需要专家阅读	简短
整数循环的速度	进程内的机器码	CPython	V8	原生速度，最快	不适用

如今，Agent 最擅长编写的语言是 Python 和 TypeScript，但它们都无法说明脚本运行前会触及什么。Rust 能保证内存安全和无数据竞争，但耗费的时间与专业知识不适合脚本，也不说明效应。Shell 是 Agent 最先使用的语言，也是最难审查的语言。

差距

从“Agent 写好了”到“我运行了”之间，需要经过审查，但没人有时间做。沙箱从外部限制进程，却无法告诉你程序的情况；类型系统检查结构，而非效应；记录和审计追踪则是事后添加的，如果有的话。Renyi 在语言内部弥合这一差距：效应是类型，授权是签名，运行记录是数据，而语法的设计目的，是让人读完函数头所需的时间内就能检查这三者。这就是全部设计；其他一切都由此而来。

源文件使用 .renyi 或 .ry 扩展名，两者等效。

安装

每个版本（决策 AI1 至 AI4；v0.1.0 是首个版本）都包含适用于 Linux（x86_64）、macOS（Apple silicon）和 Windows（x86_64）的二进制文件。在 Linux 和 macOS 上：

curl -fsSL https://raw.githubusercontent.com/renyi-lang/renyi/main/install.sh | sh

在 Windows 的 PowerShell 中：

irm https://raw.githubusercontent.com/renyi-lang/renyi/main/install.ps1 | iex

两种方式都会验证归档文件的校验和；RENYI_VERSION=v0.1.0 用于选择版本，RENYI_INSTALL_DIR 用于指定目录。使用 Rust 工具链时，cargo install renyi 会从 crates.io 构建相同的二进制文件，而 cargo install --git https://github.com/renyi-lang/renyi renyi 则会从代码仓库构建。VS Code 扩展（提供语法高亮以及语言服务器 renyi lsp 的客户端；位于 editors/vscode/）以 .vsix 文件的形式附在每个版本中。docs/RELEASE.md 是发布流程文档，文档网站位于 https://renyi-lang.org。Agent 可从 starter/ 开始（决策 AI3）：其中包含一个技能文件、MCP 配置，以及五个能完成实际工作的工作流，并附带相应的测试和记录。MCP 注册表将该工具链列为 mcp-name: org.renyi-lang/renyi。

状态

设计已完成（M0）；前端（M1）、类型与效应检查器（M2）、项目映射（renyi index）、虚拟机（M3）以及软件包（M4 的首个部分，决策 AC1）均已实现。现有内容：

• docs/design/01-decisions.md：迄今为止做出的每项设计决策及其理由。
• docs/design/02-syntax-sketch.md：这些决策所形成的具体表层；docs/design/04-stdlib-sketch.md：前导内容和标准库模块，它们也以声明文件的形式存在于 library/std/ 下。
• docs/design/03-readability-test.md：如何衡量大模型对语法的理解程度（语法由决策 V11 冻结）；测试框架和各轮测试位于 tests/readability/ 下。
• docs/design/05-agent-tooling.md：项目映射（renyi index）和供 Agent 使用的 renyi mcp 服务，两者均已实现；docs/design/06-runtime-guarantees.md：可记录和重放的运行、授权中的预算、来源保护；docs/design/07-system-design.md：该语言声称能够解决的权衡、能力安全的软件包、可复现性、进程内沙箱和经过检查的实时更新。
• docs/cheatsheet.md：一页涵盖整门语言，控制在 3000 个 token 以内（python3 tools/count_tokens.py）。
• docs/grammar.ebnf：语法层的形式语法，是基于词法分析器 token 的 W3C EBNF；语法 crate 中的测试会解析它，并检查它接受的内容是否与解析器完全一致。
• docs/reference.md：规范性语言参考；每种结构各有一个章节，包含语法摘录、含义、附带诊断代码的静态规则以及运行时行为；测试会将其中的摘录与语法文件核对，并将诊断代码列表与各 crate 核对。
• examples/：三十个示例程序，通过 python3 tools/lint_examples.py 检查。
• compiler/：用 Renyi 编写、由 Rust VM 运行的编译器：以 Renyi 类型表示的语法树（其派生 JSON 即 renyi parse --json 的输出）、词法分析器、解析器、类型与效果检查器以及字节码生成器；对于语料库、符合性测试套件、库和编译器自身中的每个程序，renyi run compiler/parse.ry <file> 都会逐字节打印与 renyi parse --json <file> 相同的树和诊断；对于语料库、符合性测试套件和编译器自身中的每个程序，无论是否带有 --strict，renyi run compiler/checker.ry --json <file> 都会打印与 renyi check --json <file> 相同的诊断；对于相同的程序，renyi run compiler/compile.ry --to <file.ryc> <file> 都会逐字节写出与 renyi compile 相同的字节码文件；测试会检查这三组结果是否全部一致。
• crates/：Rust 工具链。renyi check 以文本或 JSON 形式报告词法分析、解析、类型、效果和布局诊断，每条诊断都带有建议修复；renyi format 会按规范布局重写文件；renyi tokens 和 renyi parse [--json] 会转储 token 流和语法树；renyi index [--json] 会打印项目映射：每个定义一条记录，包含其签名、用途、声明效果和传递效果及失败、边、指标和内容哈希；renyi index --diff <map or revision> 会逐个定义，显示自保存的映射或 git 修订以来发生的更改、每项更改影响到的范围以及它要求的版本升级；renyi index --chunks 会将映射中的模块和定义输出为供嵌入检索使用的块（JSON Lines：仅当文本发生变化时才变化的 id、文本和元数据）；renyi run 会检查程序，并在字节码 VM 上运行其 main，使用 main 声明的授权，并由 --deny、--allow-host、--allow-read、--allow-write 和 --at-most 收窄；在每个函数内部，则由该函数自身的 needs 收窄（决策 Q1 的授权栈）；renyi record 会写入运行中每项效果的记录，并在文件头中包含运行清单（--redact 会将机密排除在记录之外）；renyi run --replay 会离线重新执行记录；renyi reproduce 会根据记录清单重放，并比较结果和输出；--explain 会通过运行经过的 purpose: 子句讲述运行过程，--profile 会报告时间花在了哪里；renyi serve --watch 会运行服务；当项目中的文件发生更改且程序检查通过时，它会在两次请求之间重新运行 main，同时保持监听套接字打开（决策 AO1）；renyi run --sandbox grant.json 会在比 main 声明范围更窄且带有内存预算的授权下运行程序；Rust 宿主会通过 renyi::Sandbox 以相同方式加载模块并调用其公共函数（决策 AP1）；C 宿主或通过 bindings/python/renyi.py 使用的 Python 宿主，则会通过库 renyi_c 以 JSON 文本传递值（决策 AW46；指南见 docs/embedding.md）；VM 会为二进制文件中的热点代码对象生成机器码（决策 AG1：整数循环在寄存器中运行，超出机器字范围的 Integer 会交回由大整数处理的解释器）；--interpret 会让运行始终使用解释器；renyi test 会运行每一行 example: 和每个 test 块，并从记录中运行 replays 测试（--strict、--refresh）；renyi compile 会将程序写为字节码文件（.ryc，即 compiler/bytecode.ry 中类型的派生 JSON），供 run、record、test 和 reproduce 加载，以取代源代码；renyi bind <header.h> --module <name> --library <names> 会根据 C 头文件生成外部模块（决策 AF1），renyi bind --python <package> 会根据 Python 软件包生成模块（决策 AM1 和 AM2）；renyi add、update [--accept-effects]、audit、fetch 和 publish 用于管理项目依赖（决策 AC1：renyi.json 指定依赖及其注册表、目录或 URL；renyi.lock.json 固定每个版本的哈希；每个软件包的文件都会根据其哈希进行验证，并从源代码重新计算其效果清单，因此软件包不能低报自身的行为；效果范围扩大的版本绝不会在不提示的情况下采用）。每个示例都能通过检查，符合规范格式，且其中的示例和测试均能通过；其中五个访问网络的示例和一个使用 SQLite 的示例会从 examples/fixtures/ 下的记录运行；十个带参考输出的程序都会打印出该输出。VM 覆盖整个库：前导内容、控制台、环境、时间、随机数、文件系统、JSON、CSV、正则表达式、HTTP 客户端（ureq）、HTTP 服务端（基于 std::net）、SQLite（内置编译的 rusqlite）和其他程序（std.process，决策 AE1）、帧循环绘制的屏幕（std.screen，决策 AW31）、通过外部模块使用的 C 库（决策 AF1；renyi bind 会根据头文件生成模块）以及通过桥接使用的 Python 模块（决策 AJ2、AJ3 和 AL1 至 AL4；renyi bind --python 会根据软件包生成模块，决策 AM1 和 AM2；指南见 docs/python.md）；run concurrently 会依次运行其任务（决策 S2）；二进制文件通过 mimalloc 分配内存（决策 X6）。bench/ 中有六个基准测试，其中四个有对应的 CPython 版本；tools/bench.py 会为它们计时（决策 AG4；CI 会打印测试结果）。

cargo build
./target/debug/renyi check examples/hello.ry
./target/debug/renyi check --json examples/hello.ry
./target/debug/renyi format --check examples/*.ry
./target/debug/renyi index examples
./target/debug/renyi index --diff HEAD examples   # what changed since the last commit, and the version bump
./target/debug/renyi run examples/hello.ry Renyi
./target/debug/renyi run --explain examples/statistics.ry 2 4 4 4 5 5 7 9
./target/debug/renyi run --profile compiler/parse.ry compiler/parser.ry   # where the VM's time goes
./target/debug/renyi run --interpret bench/primes.ry   # the interpreter alone; by default the hot code runs as machine code
python tools/bench.py target/debug/renyi              # the benchmarks of bench/, with --interpret, from their images and against CPython
./target/debug/renyi record --to hello.json examples/hello.ry Renyi
./target/debug/renyi run --replay hello.json examples/hello.ry
./target/debug/renyi reproduce hello.json
./target/debug/renyi test examples/invoice.ry
./target/debug/renyi compile --to hello.ryc examples/hello.ry && ./target/debug/renyi run hello.ryc Renyi   # from the bytecode file
./target/debug/renyi mcp examples        # the toolchain for an agent host, over standard input and output
(cd tests/conformance/packages/project && ../../../../target/debug/renyi audit)   # a dependency's effects against every main
./target/debug/renyi run compiler/parse.ry examples/hello.ry   # the parser written in Renyi, on the VM
./target/debug/renyi run compiler/checker.ry --json examples/hello.ry   # the checker written in Renyi, on the VM
./target/debug/renyi run compiler/compile.ry --to hello.ryc examples/hello.ry   # the compiler written in Renyi, on the VM
cargo test

0.4.0 版（2026-10-15）是稳定版本（决策 AW67）：函数值在绑定、存储或返回位置产生的效果（AW60、AW61）；括号中的类型（AW62、AW63）；在程序中编写的内存预算（AW64 至 AW66）；活跃性遍历在两侧留下的残留（AW67）；以及 C 归档中的静态库不包含胖 LTO 的位码。0.3.0 版（2026-10-15）新增了 C API（决策 AW46 至 AW48：crate renyi_c、Python 绑定，以及每个目标对应的库归档），并修复了嵌入 API 中的 Windows 路径问题。0.2.1 版（2026-10-14）修复了当前目录的作用域问题；filesystem.read(".") 此前会拒绝所有相对路径；此外还在 MCP 注册表中列出了工具链。0.2.0 版已发布（2026-10-13；发布流程见 docs/RELEASE.md，决策 AI1 至 AI5 和 AW36；扩展已上架 Visual Studio Marketplace 和 Open VSX，名称为 renyi-lang.renyi）。从 0.1.0 版（2026-10-07）到此版本之间，还新增了 Rust 原生函数注册 API（决策 AJ1 和 AK1 至 AK4；docs/extensions.md）、Python 桥接（决策 AJ2、AJ3 和 AL1 至 AL4；docs/python.md）、常驻世界、支持补全、引用查找和重命名的语言服务器、serve 的监视功能和嵌入 API（M5、决策 AN1 至 AP2、AW38、AW39 和 AW44）、对 VM 速度和前端进行的多轮优化（决策 AQ 至 AU、AW1 至 AW27）、浏览器工具链、游玩页面和展示游戏（决策 AW29 至 AW37），以及用于嵌入检索的分块功能（决策 AW40 至 AW43）。docs/ROADMAP.md 是所有阶段的路线图，按编号和轨道分组，并列出后续计划（决策 A5 中的 C API 是 AW28 排序中的下一阶段，尚未启动）。

为此代码仓库做贡献

CLAUDE.md 记录了 Claude Code 会话的约定，docs/HANDOFF.md 记录了当前状态和后续步骤；请从这里开始。

许可证

Apache-2.0。参见 LICENSE。