Thaliris-dsh

Thaliris

注意力才是最贵的资源。

Thaliris 是一个面向 AI 编程 Agent 的认知编排层。它不负责把上下文压短，它要解决的是长程工作里的三个问题：

• 强模型的注意力被噪声稀释。 探索、调试和日志不应留在负责关键判断的那条推理轨迹里。
• 原始需求和反证在交接中消失。 一个局部“完成”的报告，不应悄悄覆盖掉此前已经发现的问题。
• 项目身份在长期工作中漂移。 项目为什么存在、什么不能变，不应被一次次局部任务、实验或实现限制悄悄改写。

三者是一条因果链，起点是注意力稀释。为了保护关键推理，工作必须拆给上下文全新的 Agent，并跨越多个会话；拆分保住了注意力，也制造了交接边界。在一个任务之内，反证容易在边界上丢失；在任务之间，如果没有谁持有“项目是为了什么”，每次局部决定都可能把一个实现限制当成新原则，项目身份就这样一点点漂移。反过来，丢失的证据和漂移的身份又会把旧问题和噪声带回关键推理里。所以 Thaliris 不只隔离噪声，还明确规定隔离之后什么必须跨越边界、由谁持有。

Protect the reasoning. Isolate the noise. Isolation without amnesia.

Thaliris 不另造 Agent Runtime，而是建在 Codex、DeepSeek Harness、Claude Code 这些 Host 的原生 Agent 能力之上，补上隔离、交接、证据连续性和项目身份这一层。

状态：Beta。 在真实的复杂重构任务上，已经观察到实现者自主派发调查、Controller 发起独立审查、反证推动修复的完整链路。样本量还小，不足以证明普遍的质量或成本优势。见实测观察。

版本： 本文描述各仓库 main 分支上的源码版本：Core 0.5.3、Codex adapter 0.5.2、Claude Code plugin 0.4.2、DSH plugin 0.5.0。版本号描述源码，不描述某台机器上的安装；仓库或磁盘上的文件更新，也不证明正在运行的 Host 已经加载新版本。

为什么不止于上下文管理

常见做法是在同一个 Agent 里管理更多上下文：压缩、检索、记忆。Thaliris 认为更大的问题不是 token 多，而是同一条推理轨迹里互相竞争的目标太多：既要调查又要设计、实现、调试、自审，还得记住此前的失败。

所以 Thaliris 管的是谁来推理、带着什么推理：

为每个推理上下文提供它需要的信息，不因为别的信息存在，就把它也塞进去。

名字取自 Thalamus（丘脑，筛选并路由信息）与 Iris（虹膜，调节进入的光量）。

三根支柱

1. 认知隔离：把强模型的注意力用在刀刃上

一个长期的 Controller 持有用户目标、硬约束和验收标准。短期角色在全新的上下文里完成局部工作，不继承父级对话，只交回结论、来源、验证结果和会改变决策的未知项。

角色 · 做什么 Investigator · 在选定范围内调查事实，返回来源、矛盾与未知项 Implementer · 实现已确定的方向并完成验证 Focused Implementer · 处理设计与实现高度耦合的问题，直到核心语义收敛 Reviewer · 可选的独立只读挑战，用证据检验候选方案 Reasoning Specialist · 当问题框架或决策依据可能改变方向时独立挑战它；不实现、不做大范围事实收集 Curator · 在保留来源的前提下整理选定的可复用知识

角色按需选用，不是固定流水线。单 Agent、Controller 直接执行或委派都合法。不同角色可以配不同能力的模型：强模型只放在真正需要它的关键节点上。

2. Evidence Continuity：隔离，但不遗忘

隔离最大的风险是：审查者发现的反例，经过几轮交接和修复后，被一句“测试通过”悄悄淹没。Thaliris 用这几条规则防止这件事：

1. 反证会被登记。 子角色发现的事实如果改变了局部结论、局部验收或关键未知项，就记录为一条 observation，附带来源、交接链路和它关联的用户需求。
2. 反证保持可见，直到被明确处置。 在 Controller 针对当前候选，把每条相关需求明确判定为 *已满足 / 未知 / 需修复 / 已不再相关（并说明理由）* 之前，这条 observation 会在后续交接中持续出现。读过、转发过、确认收到都不算处置。
3. 新的好消息不能顶掉旧的坏消息。 之后出现测试 PASS、Reviewer READY、子代理 Completed 或 Core DONE，都不能让此前的“需修复 / 未知”自动退场；Controller 必须显式引用并回应那条旧依据。
4. 在下判断之前重新呈现。 Adapter 在把子代理结果交给 Controller 时，同时附上仍未处置的关键证据，赶在它做下一次“是否完成”的判断之前。这一步不需要额外的 Agent、固定阶段或轮询。
5. 历史只追加，不改写。 旧的观察和判断保留为历史，但不会自动被当作当前事实。

Core 只负责保存这些链接和只追加的历史，不判断什么重要；“重要不重要、是否满足需求”始终由 Controller 判断。

Reviewer 发现反例 ──► observation（来源 + 关联需求）
                          │
     后续修复、测试 PASS、子代理 Completed …   ← 都不能让它消失
                          │
Controller 明确处置：已满足 / 未知 / 需修复 / 已不再相关

3. 语义归模型，机械归 Thaliris

机械层负责原生 Agent 身份、来源、版本、连续性和有界检索；语义判断交给模型。结论都带来源（文件 hash、Git blob、测试观察）；freshness 只说明这些来源没变，不说明所有依赖都没变。证据不足时保持 UNKNOWN，不把推测升级为确认。

核心设计：四类状态，各负其责

隔离之后，跨越 Agent 和会话边界的不是对话历史，而是四类显式状态。它们回答不同的问题，变更方式不同，也互不替代：

状态 · 回答什么 · 谁能改变 · 怎样跨 Agent、跨会话传递 项目身份（.project-identity/，可选） · 项目为什么存在；哪些身份、不变量、原则、方向与非目标不能被低层工作悄悄改写 · 只能是人类所有者明确决定、由 Controller 记录的 amendment；证据只能对它提出 challenge · 随仓库进入 Git，跨所有任务与 Host；Controller 只看到一行摘要并按需读取，子角色只有在 Controller 把选定条目写进 handoff 时才看到 单次任务授权（Task Authority） · 这一次任务里用户选定的意图：目标、范围、硬约束、验收标准与执行模式 · 任务开始时由 Controller 依据用户指令确立并冻结；改目标、范围、验收或模式都需要用户的新决定；子角色不能确立、扩大、改写或重新激活它 · 由 Adapter 锚定在仓库之外，中断与重连后仍然有效；它是 Controller 记录的用户意图，不是对 Host 所有者的认证，也不包含维护 live Host 的权限 证据（任务 ledger） · 这一次任务里发现了什么、依据什么来源、关联哪条需求、Controller 如何处置 · 子角色登记 observation，只有 Controller 判断；历史只追加 · 绑定 Task ID 与 handoff 链；未处置的关键证据在 Controller 下一次判断前重新呈现，压缩、恢复或换会话接续任务后依然存在 长期知识（.agent-memory/、.milestones/） · 已经学到、值得以后复用的项目知识与长期进度 · Controller 选择后写入，或交给 Curator 依据选定材料整理；带来源与 freshness · 随仓库保存，经 INDEX 按需检索；记录下来不等于自动塞给每个角色

自上而下，项目身份约束一个个任务，任务授权约束这一次工作，证据检验当前候选，长期知识保存学到的东西。下层可以质疑上层，但不能悄悄改写它：证据推不翻任务授权，任务里的结论不会自动升级为项目身份，修改项目身份也不会改写正在运行的任务已经冻结的授权。没有项目身份的项目照常运行，不会被阻塞或催促。

组成

部分 · 职责 Thaliris Core（共享 Core） · Task ID 与任务记录、任务授权、observation / judgment 链接、证据与 freshness、项目记忆、里程碑、项目身份、CAS 写入与回滚 Thaliris-codex · Codex 原生集成：Fresh Child、角色 profiles、原生 Agent 身份与生命周期、证据重新呈现 Thaliris-dsh · DeepSeek Harness 插件：Workspace/Session/Agent 集成、可选 Memory Thaliris-claude · Claude Code 插件：Controller skill、角色子代理、Hooks 原生身份绑定与证据重新呈现

只有一套共享 Core。Core 不运行模型、不调度 Agent、不认证调用者；原生执行由各 Adapter 负责。

角色能力与推荐模型

绝对不要用小模型或低能力模型做控制层（Controller）。 省钱应当来自把窄任务交给更便宜的子角色，而不是降级 Controller。Controller 的失误不会被子代理纠正，只会被放大：实测中，弱 Controller 会跳过受管流程、在隔离拒绝后退回单代理，或在审查反证仍未处置时就判定完成。

Controller 必须同时具备以下能力，每一项都很重要：

能力 · Controller 要回答的问题 Global Coherence 全局一致性 · 做了几十上百步以后，是否还记得为什么要做这件事？ Strategic Planning 战略统筹 · 能不能从最终目标反推路径、识别依赖、分配资源，而不是只看下一步？ Retrospective Reasoning 回溯推理 · 能不能从历史决策中定位根本错误，而不是反复修补表象？ Metacognitive Monitoring 元认知监控 · 能不能发现自己正在跑偏、重复劳动，或者陷入不可能完成的任务？ Prospective Reasoning 前瞻推理 · 能不能预测当前决定对后续阶段的影响，主动避免未来的结构性问题？ Adaptive Replanning 动态重规划 · 当原计划失效、条件变化时，能否重新组织全局工作，而不是机械延续旧计划？

各角色需要的能力与推荐模型：

角色 · 需要的能力 · GPT（Codex） · Claude（Claude Code） Controller · 上述六项；整合原始目标、验收标准与证据，判定产品验收 · gpt-6.1-sol（high 或以上）；用户明确选用时可用 gpt-6-astra · Opus Investigator · 在选定范围内广泛、准确地收集事实与来源，说明已覆盖与未覆盖范围 · gpt-6-luna（max） · Sonnet Implementer · 在已确定的方向内实现、验证并修复普通缺陷，直到确定性收敛 · gpt-6-luna（max） · Sonnet Focused Implementer · 对耦合的不变量持续推理，吸收运行反馈直到语义收敛 · gpt-6.1-sol（high）；用户明确选用时可用 gpt-6-astra · Sonnet 或 Opus，由 Controller 按任务难度选择 Reviewer · 独立挑战已收敛的候选，跨边界寻找反证，不被作者的框架带偏 · gpt-6.1-sol（high） · Opus Reasoning Specialist · 质疑问题框架、因果模型和决策依据 · gpt-6.1-sol（high）；用户明确选用时可用 gpt-6-astra · Opus Curator · 依据选定材料精确整理长期知识与 INDEX · gpt-6-luna（max） · Sonnet Verifier（Codex 兼容角色） · 只读检查验收证据、修改边界与同步 · gpt-6-luna（max） · —

推荐值是起点，不是质量保证。角色与执行模型相互独立；实际运行的模型以 Host 的观测为准，而不是配置文件。

这些只是推荐。为每个角色选择模型是 Controller 的职责，在用户写入任务的约束之内可以自由选择；在 Adapter 支持时（如 Claude Code 的 register-role），Controller 也可以注册新角色。用户也可以让 Controller 独自完成全部工作：是否委派、委派多少，由用户决定。

实测观察

这项基准测什么： 我们有意挑了一个很难的单轮重构任务：桌面与 WebUI 共享 Live2D 行为，涉及模型选择、语音/动作队列和退出生命周期。比较的不是候选还剩几个 bug，而是原始需求能否持续约束调查、方案收敛、实现和验证，尤其是检查是否覆盖真实消费者路径、反证是否推动方案修正。A/B 是单代理样本，C/D 提供协作执行对照。

结果要这样读： 冻结候选接受独立产品后审；表中把原运行内的独立审查/修复与冻结后的后审分开。A/B 的原运行没有独立 Reviewer；它们后来接受 GPT-6.1 Sol/high 独立后审，不能算作组内自审或修复。A/B 保留原报告的高/中严重度标签和 V3 覆盖不足结论，不换算为本表的 P1/P2。各样本都有未闭合的需求，其中一些在起始代码里已经存在；缺陷数量不是质量总分。

样本（原执行日期） · 执行方式 · 原运行内独立审查/修复 · 冻结后独立后审结果 · P1 · P2 · 用时 · API 等价费 A · 10/03 · 单代理 Sol/medium · 无 · 10/14–15：NOT_READY；1 高、2 中，另有 V3 renderer 覆盖不足 · — · — · 21.6 分 · $0.88 B · 10/03 · 单代理 Luna/xhigh · 无 · 10/14–15：NOT_READY；2 高、3 中 · — · — · 54.1 分 · $0.23 C · 10/14 · Luna 多代理 · 有，局部 · NOT_READY · 2 · 3 · 57.1 分 · $0.46 D · 10/14 · Sol + Luna 多代理 · 有 · NOT_READY · 1 · 2 · 40.4 分 · $2.62 C · 10/19 · Luna（派发被拒，回退单代理） · 无 · NOT_READY · 3 · 3 · 19.8 分 · $0.22 D · 10/19 · Sol + Luna 原生多代理 · 有，两个反证触发修复 · PARTIALLY SUPPORTED / NOT_READY · 0 · 3 · 34.4 分 · $2.91

表中费用是 API 等价参考值，用于比较，不是实际账单。A/B 的原执行日期是 2026-10-03，冻结后才于 10/14–15 接受 GPT-6.1 Sol/high 独立后审；表中的高/中标签沿用原报告，没有换算为 P1/P2。

A 在 16:46 UTC 已形成共享行为策略加渲染器适配的跨端方向，随后把桌面音频等待和 WebUI 片段调度问题纳入实现；其最终相关 Python 套件报告 92 passed/1 deselected，前端 7 files/20 tests，build 和 lint 均退出成功。后审仍发现桌面转换入口会用 Sakiko costume 覆盖显式选择的自定义模型，Web 无音频呈现只保留最新动作。这说明较早形成整体方向、完成局部验证，仍可能遗漏实际消费者路径。B 花了更长时间做广泛调查，16:59 UTC 才明确列出缺口和共享目标/renderer 方案；之后修正测试夹具与 lint，并完成 84 个 Python、16 个前端测试和 build/lint。后审仍复现角色状态与取消 ingress 未完整消费、bye 未停止正在播放的音频，显示更多投入和通过的局部测试也没有闭合事件链与生命周期一致性。两次后审都是独立评估，不是 A/B 原运行中的 Reviewer。

因此，A/B 与 C/D 对照的是调查、方案收敛、原始需求保持、验证方案和反证后的修正；不是比较冻结后剩下多少个 bug。

D · 10/19 发生了什么：

Controller 把耦合的设计与实现交给 Sol
  → Sol 自主派 Luna 调查运行时支持与测试边界
  → Sol 交回局部候选
  → Controller 没有把“局部完成”当作结束，发起独立审查
  → Reviewer 找到两个推翻局部结论的反例：
      · 用户显式选择的模型会被桌面旧规则覆盖
      · 退出告别指令可能在事件通道关闭后才发出
  → Controller 采纳反证，派修复与回归

D · 10/19 的独立外部后审没有发现 P0/P1，但报告了三类 P2，结论为 PARTIALLY SUPPORTED / NOT_READY，不构成完整产品验收。三类反例是：取消后到达的预入队片段仍可恢复播放；shutdown bye 后在途 producer 仍能发布，独立前端复现也会接受之后的片段；Web 按版本选择嘴型参数名，无法驱动拼写与版本默认值不同但实际受支持的别名，桌面按实际 parameter IDs 选择。过程中的原生代理状态冲突按 Codex 原生生命周期异常处理。

这正是 Thaliris 要验证的能力：局部成功不等于全局结束，反证会实际改变后续工作。

C · 10/19 不是一次成功的多代理运行： Luna 请求把整段对话历史传给子代理，被 Fresh Context 规则正确拒绝；它没有改用独立上下文重新派发，后续退回单代理完成。这个结果说明隔离保护在起作用，也显示关键调度节点需要足够强的模型。

目前还不能证明的： 每行都是单次运行，各批次的 Host 与模型 effort 不完全一致，不是单变量实验；混合配置总成本更高；D · 10/19 中审查与修复阶段的反证虽然实际推动了修复，但没有全部登记为正式 observation，Evidence Continuity 的持久化链路仍在完善中。详见 ABCD 基准 与基准协议。

快速开始

需要 Python 3.11+。Git 可选；使用下方 Git URL 安装需要 Git。

uv tool install git+https://github.com/Iris0fTheValley/Thaliris
cd your-repository
thaliris-core --root . init
TASK_ID=$(thaliris-core --root . task-start "example task" | python -c 'import json,sys; print(json.load(sys.stdin)["task_id"])')
thaliris-core --root . --task-id "$TASK_ID" task-status

每个任务有独立的 Task ID，后续操作显式传入 --task-id。只安装 Core 不会启用多代理；需要原生集成时，按 Codex、DSH 或 Claude Code 指南安装。

初始化后的仓库：

.agent-memory/   # 经选择、可跨任务复用的项目知识（可纳入版本控制）
.milestones/     # 长期进度：scope / decisions / progress / verification
.context/tasks/<task-id>/state.json   # 单个任务的状态与证据（默认被 Git 忽略）

任务状态保存结构化的事实、observation 和判断，不保存对话 transcript。持久化和交接是两个独立选择：记录下来的东西不会自动塞给每个角色。

不是什么

不是 Agent runtime、工作流引擎、固定多代理流水线、向量数据库或 RAG 系统、全仓自动总结器，也不能替代源码、测试、编译器和运行时行为。

删除 Thaliris，底层开发流程也不应因此变得不正确。

延伸阅读

• DESIGN.md — Core 架构与契约
• 路由协议 — 路由、交接、Evidence Continuity、等待与验收
• 任务授权契约
• 提示词归属与研究动机 — 含相关文献
• 角色说明 · 分包与 API 边界

DSH 原生集成

@thaliris/dsh-plugin 将 Thaliris task records 和 Controller 工具接入 DeepSeek Harness。它使用 DSH 原生 Workspace、持久 Session、Agent/subagent、Settings、model catalog、Plugin Manager 和 lifecycle，并通过 Python bridge 调用单独安装的 Thaliris Core（当前配对 Core 0.5.3，见 Core baseline）；本仓库不复制 Core 或 Codex adapter。

自 0.5.0 起，插件以可选的原生 Agent Preset 模式接入：安装后 Thaliris 只是出现在 DSH 的原生 Agent Preset 列表里，默认不选中、也不是默认模式；未选择 Thaliris 的普通会话不会获得 Controller 提示词、任务工具或动态任务上下文。选择与默认完全使用 DSH 原生交互，不需要第二套开关。

DSH 的策略页配置角色提示词、模型路由、工具、Workspace 和 Memory。初始角色模板（Investigator、Implementer、Focused Implementer、Reviewer、Curator、Reasoning Specialist）采用 inherit 路由、不固定模型，并按角色能力授予精选的 DSH 原生工具（只读角色只拿到读取类工具，见原生角色工具权限）；路由模式为 inherit、fixed 或 allowed。模板变更不会覆盖已经保存的用户角色记录；角色通过编辑这些用户自有记录来调整，而不是由 Controller 调整。Workspace 精确绑定和持久 root Session 是任务关联的一部分，单凭仓库路径不会恢复旧任务。

原生 root Controller 获得以下工具，子代理永远看不到它们：

工具 · 用途 thaliris_task_start / thaliris_task_inspect / thaliris_task_close · 确立选定意图、查看显式选定的任务、在 Controller 自行判断后记录机械 DONE thaliris_workstream · 以角色、有界 handoff、可选模型路由与 reasoning effort（Controller 在隔离与分工之后，选择适合该工作集的最便宜允许路由和最低 effort）、可选 evidence association 派发一个全新子代理；reservation 记录所选路由和派发时角色的摘要 thaliris_reconcile · 依据原生终止证据检查或调和崩溃遗留的 reservation；UNKNOWN 不会自动释放；dispose（需 reason）是 Controller 的显式释放，记录为 disposed/UNKNOWN，绝不记为 completed thaliris_task_recover · 显式恢复 authority 锚点：列出需要恢复的任务及本 Workspace 其他 root 可接管的任务；TASK_AUTHORITY_STATE_CHANGED 后 rollback；按用户指示将本 root attach 到 ACTIVE 任务（台账已变时用 attach-and-rollback）。需 reason 与 authority 摘要 CAS，从不自动执行 thaliris_task_status · 默认紧凑状态（revision、routing、计数、有界记录、未完成的 dispatch、authority 摘要与模式、未决 evidence 摘要）；view: "full" 返回完整状态包，since_revision 附加有界变更提示。已结束的 dispatch 是 append-only 的 dsh-dispatch Core record，不占用 routing state thaliris_task_context · 记录事实、决策、进展、待办与 milestone；压缩或恢复后，有界摘要会作为 DSH dynamic context 重新提供 thaliris_task_register / thaliris_task_judge · 登记不透明的需求；以精确的 observation 引用记录需求判断，可单条或以 judgments 原子批量提交。结果携带新 revision 与未决 evidence 摘要；revision 冲突会返回 Core 的 code、recovery 与 changes_since thaliris_task_mode · 在真实的人类指令下切换 execution mode，使用 revision 与 authority 摘要 CAS，且需先解决进行中的工作 thaliris_task_identity · 读取项目 identity（action：status；get 某个版本、选定条目、单个 amendment 或 challenge；trace 已登记关系）；没有 identity 是正常情况 thaliris_task_identity_amend / thaliris_task_identity_challenge / thaliris_task_identity_relate · 依据人类所有者的决定记录显式 amendment、记录或驳回 challenge、登记或撤回目的关系（仅 Controller） thaliris_task_identity_note / thaliris_task_identity_suggest · Core 0.5.2：记录、撤回或列出用户明确长期表述的原话 basis note；按 session、workspace、project 或 global 范围开关主动提议偏好（仅 Controller；无需 ACTIVE task）

带 evidence association 派发的子代理会额外获得 thaliris_observe；adapter 把每条 observation 绑定到该次派发的 handoff、candidate、requirement refs 以及已绑定的原生子代理，派发结束即失去该授权。Controller 不能代写子代理的 observation，子代理也不能登记、判断或切换模式。已派发的子代理在 Settings 之后变更时仍保持派发时绑定的角色（提示词、工具、memory 授权）。模式切换不会扩大子代理的角色或授权；delegated 派发要求 delegated 模式。

项目 identity

Core 0.5.0 增加项目级 identity 层：一份带版本、纳入仓库跟踪的声明，说明项目为何存在、哪些内容不得被静默更改，存放在 .project-identity/，只能经人类所有者决定后的显式、可追溯 amendment 修改。它独立于 Task Authority（单个任务冻结的意图）、Memory Provider 与 milestone；amendment 不是 memory proposal 或 approval，也绝不改写运行中任务已冻结的 contract。bridge 只向原生根 Controller 暴露 Core 的读取操作（status、get、trace）和三类写入（amend、challenge、relate）；六个 thaliris_task_identity* 工具带 thaliris_task_ 前缀，因此角色的工具授予永远不能包含它们，并且位于所有已派发子代理的 deny 列表中。写入沿用与其他写入相同的任务 revision CAS，actor 取自 adapter 绑定的原生 Controller 身份，且不会推进任务 revision。存在 identity 时，动态任务上下文会增加 Core 的一行摘要；不存在时一切照旧，也不会阻塞任何事。子代理只有在 Controller 把选定条目引用进 handoff 时才会获得 identity 内容。本 adapter 没有路径级的子代理写入防护：子代理对 .project-identity/ 的改动只能事后发现（Core 报告 UNRECORDED_CHANGE 或 INVALID，Git diff 可见），而无法被阻止。详见 Core 的 Project Identity 文档。

Memory 是独立可选能力，默认关闭。可单独安装 memory capability 和本地文本 provider；task routing 和 close 无需启用 Memory 或 client UI。没有 embeddings/vector RAG 或自动检索；Memory 读取受授权控制，写入遵循用户许可和 Core task 检查。详细边界见能力说明和客户端契约。

安装与首次使用

DSH plugin 0.5.0 在 engines.dsh 中声明接口范围 >=0.2.1-rc.2 <0.2.2-0：已发布的 0.2.1-rc.2 与 0.2.1-rc.3 均可直接安装，不需要精确版本豁免，也不要求固定 revision；更早的 DSH（如 dsh-v0.2.1-alpha.1）请使用 DSH plugin 0.3.2。安装不需要手工打包、填写绝对路径或编辑 profile；lib/client.js 等产物随包发布，包内没有 install hook。

作为普通 DSH 插件安装

Desktop / Web（图形界面，推荐）