紫垣 ZiYuan

用 Rust 编写的多智能体协作工具：你提出任务、分配权限、审阅结果，再决定是否把改动写入文件。界面和角色借用了中国古代朝廷的称呼。

当前版本 1.8.0：在 1.4 的译书流程（原文预览与注音、成稿导出、显式参考、词证与逐段勘校、用量账本）之上，加入本地人物/术语资料、段旁提示、第二版资料的生产准备与复核关联。版本变化见 CHANGELOG，下载见 GitHub Releases。保留初译、双路审校、朱批、修订、御览与人工分批，不自动推进整部小说；工程验收不等于文学质量保证。也可用命令行、Web 或终端界面管理代码任务，查看执行记录，并在批准前审阅文件差异。

1.5.3 说明：段旁提示并入「临时关联」流程，去掉重复 JSON 输入；Web 文案与 README 用词对齐。生产批准仍须显式 context approve，保存本地草稿不等于批准。

• 先试用，不必先配置模型：未设置 ZIYUAN_LLM_MODEL 时只演示派工，不会真的分析或修改文件。
• 接入模型后才执行真实工作：支持 OpenAI 兼容接口，已有 DeepSeek 实测。默认只能读取项目；修改文件和运行测试要另行授权。
• 模型提出改动，你决定是否写入：任务完成不等于文件已修改，要审阅后执行 apply。
• 逐块翻译小说：导入日文或英文原文后，按块下诏初译、请只读审校、逐段朱批、修订并御览定稿；所有译稿仍须准奏才落盘，长篇文学质量须人审。另可记下自己的认可译法（御笔札记），不必先建朝廷。
• 找回定稿译法（1.3）：显式设置 ZIYUAN_MEMORY_PROVIDER=local 后，用 ziyuan text memory status|build|search 或 Web 武英殿译书卡片的「译文记忆」查看、建库与查询。CLI 跨项目须逐个给出 --project，Web 仅当前项目。本地字符哈希只比较字面，不理解文意；没有远程嵌入，也不承诺文学质量提升。

原文预览与注音：TXT／Markdown 导入前先检查章序、正文、注音与警告，再确认导入；旧的纯 TXT 命令不变。见导入指南。新写入的文本项目使用 schema 2，旧 1.3 无法读取，须升级。

成稿导出：text export-originals 取回归档原件，text export-finished 将有效定稿与校验清单打包为 TAR。CLI 默认预览，Web 确认后下载；缺块或失效整批拒绝，不改变审批、不覆盖文件。Markdown 行内代码无法定位回填时明确拒绝，见导出指南。

显式选用参考：从译文记忆中主动选择参考，先预览完整参考外发文本，再确认初译或修订。默认不选；预览不发送，下诏只入队。Web 仅当前项目；所选原译文保存在事件簿，分享前须核对隐私与权利。详见选择、确认与重试及兼容边界。

本地资料与段旁提示

• 译书页可保存独立的人物/术语资料草稿；未批准，不进入生产译文。
• 在「临时关联」填写本段人物、称呼对象与说话人，点「刷新段旁提示」；段旁提示按当前关联显示术语、人物与称谓条件。
• 「对比草稿与生产」只读列出新增/删除/改动；保存草稿不等于批准；「准备生产资料」只写 context/glossary.json，仍需 ziyuan text context approve。
• 复核可带关联：ziyuan text verification show <项目ID> <块ID> --associations <关联.json>。
• 详见 N0 第 26 节。

词证与逐段勘校：词证是词义核对的出处和说明。CLI 和 Web 可按言行归属、事理正反、数目分寸、前后次第、称谓名分、谐趣留白六事逐段记录，保留历史；材料变化后须重新核对。结构通过、意见已处理、人工复核和御览定稿不能互相替代。说明与短例见勘校指南。

逐阶段用量账本：ziyuan text usage <项目ID> [--json] 只读查看初译、双路审校和修订的已报告用量。未报告就是未知，分币种估价不是账单。请求中省去较早的相同文件读取副本，保留最新全文，不改原始历史；词义核对、朱批与人工分批不削减。见账本与精简边界。没有新增付费小说复验，不承诺节费收益。

人工译稿（开发中，未发布）：不调用模型，自己写译文，经 text human save／submit／approve（准奏即落盘）／finalize 后导出成品；命令行与网页（逐段双语编辑与注音／着重号等标记编辑）都已开放，TUI 尚未开放。用法、草稿文件字段与恢复办法见人工译稿。

本文中的“皇帝”指用户，“官员”指执行任务的智能体，“诏令”就是任务，“准奏”是批准写入文件。命令名称保持这些约定，不需要先熟悉官制才能使用。

安装

可从 GitHub Releases 下载适合系统的压缩包，解压后运行其中的 ziyuan（Windows 为 ziyuan.exe）。Linux 预编译包需要 glibc 2.35 或更新版本。

也可以从源码安装，需要 Rust 1.89 或更新版本：

cargo install --git https://github.com/YuuUehara/Ziyuan ziyuan-cli --locked   # 安装 `ziyuan` 到 ~/.cargo/bin
cargo install --path crates/ziyuan-cli --locked                               # 或在本仓库中

正式发行版会通过标签触发的可信发布流程上传到 crates.io；首次发布须先手工完成，之后由发布作业自动跟进。是否可用、有哪些版本，以 crates.io 上显示的内容为准。若该版本尚未出现在 crates.io，请用上面的 cargo install --git 安装。

平台支持

快速开始

安装后，在一个独立目录试用。下面的命令可在 PowerShell 或常见 Linux/macOS shell 中逐行执行；使用已有目录时不要重新运行 mkdir。

mkdir ziyuan-demo
cd ziyuan-demo
ziyuan init
ziyuan court
ziyuan officials
ziyuan edict --dept works "概述当前目录的文件"
ziyuan tasks
ziyuan history

记录保存在当前目录的 .ziyuan/。未配置模型时，结果会注明只是演示；若已配置模型，上述任务会读取授权范围内的文件并产生模型费用。

想用图形界面，执行 ziyuan serve，再打开终端打印的本机地址。不要把带令牌的地址发给他人。终端界面用 ziyuan tui 启动。

接下来可按需要阅读：

• 接入真实模型：设置模型名称、服务地址和密钥。
• 让模型修改文件：授权后先看 ziyuan diff <任务ID>，确认后再 ziyuan apply <任务ID>。将占位的任务 ID 替换为实际数字，不要直接输入尖括号。
• 权限与安全：哪些文件会交给模型，哪些操作需要你批准。

任务如何分配？

三种制度决定任务经过哪些角色。这些规则由程序执行，不是只在提示中要求模型遵守：

• 正职空缺时由副职署理（丞相 → 左丞相，首辅 → 次辅，尚书 → 侍郎），路线中注明「署理」；正副俱缺则拒绝派工。
• 改制会撤销旧制度协调机构（中书省/内阁）的全部官职，防止旧身份在改制后继续自动保有最高权力；六部官员保留，品级随制度变化。新制度需要明确任命协调者。
• 开国时（#1–#10）设丞相一人，吏部、工部各有尚书与郎中，户、礼、兵、刑四部各有尚书（本部无郎中时尚书亲办），六部诏令都能承接；左都御史不设（设了常朝会自动复核、多花 token）。init 与 court 会列出缺位的官职及其影响（如左都御史空缺则无人复核），并由吏部荐举一位闲居、专长相符、考绩最优的官员；任命仍须皇帝确认（Web 朝堂可一键任命，经确认框）。
• 官员姓名在开国与 recruit（不给姓名时）随机生成：百余个常见单姓与复姓，配以士大夫取名常用字，单名双名皆有，不与在册官员重名。姓名记入事件簿，重放不变。
• officials、Web 与 TUI 显示每位官员的官职、品级与所用模型（ZIYUAN_LLM_MODEL；未设置时为演示后端）。

内阁制下诏令须先「票拟」再由皇帝「批红」，丞相制下丞相自行派工；详见内阁、皇权与昏君模式。

使用前需要知道

1. 你决定权限和任免：模型不能靠一句话把自己变成用户；改制、任免必须通过程序提供的操作入口。
2. 官员和官职不是一回事：官员换职后编号不变，便于追查同一执行者的记录。
3. 改制不等于停止任务：改制调整分配路线，执行机制仍然保留；停止或撤销任务要用相应操作。
4. 权限不能由模型自行扩大：模型可以提出建议，但不能自行授予新的系统权限。
5. 演示后端不是代码分析：DemoBackend 只验证调度线路，绝不声称已完成真实分析。
6. 记录保存在本地：.ziyuan/court.log 保存任务和操作记录，多个进程的写入会协调。.ziyuan/huidian 只是加快启动的缓存，损坏时会按记录重建。新版可读旧记录；旧版未必认识新事件，先用 ziyuan migrate 检查最低版本要求。

1.0 起的兼容承诺见稳定性约定。ChatGPT 订阅与 HTTP MCP 仍为实验性；内部 Rust 接口和 Web 页面不在兼容承诺范围内。

支持 recruit 动态扩充官员；同部门多个郎中按任务量均衡派工。择优任用通过 recommend 给出建议，由皇帝决定是否任命。

开发与发布

发布产品由十一个 crate 组成：core 定义任务与角色，governance 执行分配规则，runtime 执行模型与工具调用，llm 和 github 连接外部服务，storage 保存记录，memory 提供本地译文记忆索引与检索，app 提供各界面共用的功能，cli、web、tui 负责交互。工作区另有未发布的 sandbox-windows 独立启动探针，已通过 Server 2025 CI 基线的启动、身份、Job 与句柄检查，尚未完成文件／网络隔离验收，不接入生产；Windows 受保护执行仍失败关闭，见 ADR-0001。其余分层说明见体系结构。

在仓库根目录检查和构建：

cargo fmt --all -- --check
cargo check --workspace --all-targets --all-features
cargo test --workspace
cargo build --workspace
bash scripts/smoke.sh

最后一条需要 Bash 及脚本所需的运行环境。常规 CI 还检查 Rust 1.89、Linux glibc 2.35 基线，并在 macOS 和 Windows 上运行测试；具体流程见 .github/workflows/ci.yml。

推送与 Cargo.toml 版本一致的 v* 标签会触发发布：先建草稿，上传四个平台的包，再在对应平台重新下载验证，全部通过才公开；公开后按依赖顺序发布十一个 crate（含 memory，已存在的版本跳过）。可信发布配置与首次发布准备见发布指南，最终结果须分别核对下载包与 crates.io。说明取 CHANGELOG 中对应版本一节。crates.io 不能删除版本，只能 yank。Linux GNU 包在 Ubuntu 22.04 构建并检查 glibc 2.35 基线，不代表所有 Linux 发行版均经过验证。

文档

• 使用指南：各项功能的详细用法。
  • 前端：奉天门：Web 界面、紫禁城：终端界面、命令行：JSON 与补全
  • 模型与执行：接入真实模型、任务队列与并发、常朝：常驻执行与自动复核、外藩朝贡：MCP 工具
  • 权限与改动：玉玺：限定官员的权限、工部动手：受控写权限、户部度支：预算与限额、刑部与锦衣卫：防提示注入
  • 评定与监督：吏部：评定、考绩与荐举、都察院：复核回奏与证据核验、廷推与廷杖、内阁、皇权与昏君模式
  • 协作与文书：多官协作：分办与汇总、人格、字号与廷议、翰林院：诏令模板、礼部：科举与文书、礼部修 CHANGELOG
  • 记录与对接：起居注：按诏令、官员、类型、时间查、翰林院修史：实录与前例、兵部：驿传与八百里加急、兵部驿站 · GitHub、版本控制：Jujutsu
• 体系结构：分层、事件簿与设计取舍。
• 文档目录：全部文档的分类入口。
• 稳定性约定：1.0 起冻结哪些接口。
• CHANGELOG：各版变化。
• 路线图：下一版的规划。
• 整理原文与检查译稿：导入原文、分块与检查候选译稿，1.1.0 起可用。
• 作品更新提醒：syosetu 关注列表、检查、Web 定时设置与 1.2.0 的自动入队，不下载正文。
• 小说翻译指南：1.2.0 的逐块初译、审校、朱批、修订与御览流程；1.0.0 的日／英短样本保留为历史试点，长篇文学质量仍须人审。
• 本地译文记忆：启用、建库、查询与失效规则，以及 1.4 的人工选择、外发预览、确认与任务快照，不自动取用参考。
• 发布指南：标签发布、四平台验收、crates.io 可信发布的设置与注意事项。

许可

本项目采用 MIT OR Apache-2.0 双许可证，你可以任选其一使用：

• MIT License
• Apache License 2.0

除非另有明确说明，你有意提交并被本项目接纳的贡献也将按上述双许可证授权。

Web 界面内置的 JetBrains Mono 字体按 SIL Open Font License 1.1 随附，许可证见 crates/ziyuan-web/src/fonts/JetBrainsMono-OFL.txt（发行包中为 JetBrainsMono-OFL.txt）。界面推荐的中文、日文字体也都是 OFL 1.1，不随程序附带，见使用指南 · 字体。

软件的 MIT / Apache-2.0 许可不授权第三方文学原文、译文或书库品牌；模型上传、再分发与商业出版仍须逐项核对权利，见小说翻译版权边界。