长篇写作的系统求解

长篇生成的难点会随篇幅迅速改变。几千字以内，模型可以依靠当前对话完成局部续写；进入数十章以后，作品同时承载人物状态、世界规则、时间线、未兑现承诺、文风、场景义务、篇幅预算和版本身份。一次看似顺畅的续写，可能在五章以后制造无法修补的因果裂缝。

ArcVellum 为这类问题建立一套本地文学工程系统。它把开放式创作保留给模型，把可重复计算的项目管理交给程序，把最终方向和高风险决定留给创作者。系统追求的成果，是一份能够持续推进、随时审计、可以阅读、可以导出的正式作品。

问题定义：在多重约束下寻找下一段有效叙事

一个场景的解空间非常大。人物可以沉默、说谎、离开、误判、冲突，也可以引出新的事实。系统需要同时优化几类目标：

• 文学有效性：场景产生转向、关系变化、信息增量或代价；
• 角色一致性：行动来自人物已经建立的信念、欲望、恐惧、秘密、道德边界与背景故事；
• 世界一致性：时间、地点、制度、技术和既有事件满足 Canon；
• 长篇效用：当前场景接住上文，并为后续场景留下可用压力；
• 篇幅效用：字数增长来自足够的事件库存和叙事展开；
• 语言质量：挂载文风、标点规范、叙事距离和反模板约束进入生成；
• 可验证性：候选、审查、修订和正式正文拥有可核对的内容身份。

可以把某一时刻的作品抽象为状态向量：

WorkState(t) = {
  canon,
  character_states,
  relationships,
  timeline,
  scene_inventory,
  reader_questions,
  promises_and_payoffs,
  rhythm_plan,
  word_budget,
  mounted_style,
  formal_manuscript,
  workflow_evidence
}

一次合法推进就是寻找一个变换 T，使 WorkState(t + 1) = T(WorkState(t), Candidate) 通过所有强制 Gate。模型可以提出 Candidate，内核负责判定 T 是否被允许发生。

三类权力形成稳定边界

ArcVellum 将创作系统里的权力拆成三类。

这项分工让模型可以充分发挥语言和推理能力，同时阻止一次回答直接覆盖项目事实。创作自由存在于候选空间，工程约束作用于正式状态迁移。

五层技术拓扑

文学工程内核

literary_engineering_studio_engine 保存正式路线、TaskPackage、Schema、Prompt Asset、Canon、人物、场景、文风、审查、晋升、连续性账本和导出规则。它只依赖自身合同与标准库，不依赖 FastAPI、Vue、Provider SDK 或 Agent 进程。

内核根据项目事实派生当前状态。文件存在只能说明磁盘上有内容；Task、Submission、Completion、内容指纹和 Gate 一起成立，才能说明流程已经完成。

Studio 应用层

literary_engineering_studio 组织用户用例：项目选择、自动推进、任务领取、沙箱创建、Runtime 调度、失败恢复、审批、事件持久化和界面读模型。应用层通过 Engine 的 public/* 接口使用文学真相，通过端口连接持久化、进程、事件和 Runtime adapter。

Agent Runtime

内置 Pi Worker 接收一项已经签发的任务。它在受限工作区读取任务上下文，使用白名单工具写入预期产物，再交回 Studio 进行确定性预检。Worker 无法领取下一任务，也无法直接晋升正文、改写 Canon 或调用任意 Shell。

产品界面

Vue 客户端把项目投影成叙事星仪、阅读器、档案 IDE、质量面板、策略面板、顾问和交付中心。所有可见状态来自 API 读模型；用户动作通过明确命令端口进入应用层。

桌面与发布

Tauri 管理 Windows/macOS 窗口、sidecar 生命周期、安全桥接和更新器。安装包携带 Python 应用服务、嵌入式 Engine、Pi Worker 和固定 Node 运行时，普通用户无需自行搭建开发环境。

七条正式路线覆盖作品生命周期

ArcVellum 当前的路由目录包含七条核心路线：

1. longform-planning：建立卷、章、场景库存、目标字数和长篇义务；
2. character-and-world-assets：创建、审查、批准和晋升人物及世界资产；
3. style-engineering：从合法语料形成可挂载文风版本；
4. scene-development：推演、分支、正文、审查、晋升与状态写回；
5. review-and-audit：在章节与全书尺度检查连续性、节奏和质量；
6. export-and-release：清理创作痕迹，生成 Markdown、DOCX 和交付证据；
7. source-ingest：把已有文本解析成可继续维护的项目资产。

这些路线共享任务生命周期和证据合同，又各自拥有领域 Gate。场景正文不能代替人物资产，审查报告不能代替晋升凭据，前端显示的绿色状态也不能代替内核结论。

单任务执行链

Engine 派生下一状态
  -> 签发 TaskPackage
  -> Studio 执行确定性前置步骤
  -> 创建 control-workspace 与 agent workspace
  -> 编译 Task Context 与 Prompt Program
  -> Pi Worker 产生语义产物
  -> 本地格式验证
  -> Studio deterministic preflight
  -> 事务写回正式项目
  -> task-submit / task-complete
  -> route-audit 派生下一状态

双工作区承担关键隔离。控制工作区包含 CLI 与预检所需的完整依赖；Agent 工作区只包含精简的可读资料和允许写入的产物。这样可以同时满足严格验证与最小上下文。

失败也属于求解状态

系统将失败定位在具体边界：Provider 连接失败、模型长时间无活动、工具调用无进展、输出缺失、Schema 无效、越界写入、预检失败、等待人类选择、Gate 阻断和项目事实冲突。每类失败拥有不同恢复策略。

恢复动作遵循最窄原则：缺输入时修正任务合同；格式错误时执行局部修复；文学结论失败时回到审查或分支；事实冲突时停止写回。扩大整个 Agent 文件权限会掩盖合同缺陷，因此不作为常规修复方案。

系统怎样衡量进展

作品进展由多组信号组成：创作准备度、已晋升正文占目标篇幅的比例、交付就绪度、路线阻断、待处理决策和审查债务。正文字符只计算正式内容，流程说明、YAML、Review 和工作痕迹不会进入作品字数。

工程效率也采用“成功产物成本”衡量：完成一次正式晋升消耗多少输入 Token、输出 Token、Provider 往返、修复轮次和墙钟时间。一次便宜却反复失败的调用，对长篇项目仍然昂贵。

当前边界

v0.99.3 已经具备可安装桌面端、嵌入式 Pi Worker、正式文学路线、真实项目星仪、正文阅读与 DOCX 交付。连续端到端项目证明了两章六场景、30,080 个中文内容字符可以通过正式闭环。

这份证据覆盖特定题材、模型和规模。千场景投影、更多 Provider、macOS 签名、本地小模型质量和更大规模的无人值守创作仍需独立验证。ArcVellum 将这些边界保留在发行与验证文档中，让技术承诺与真实证据保持一致。