Hanko exit_liquidity

hanko

Hanko 将加密市场上的讨论转化为适当规模的持仓，或诚实地拒绝，并附上证据；多年后，它还能逐字节证明当初做出的同一项决定。

将它指向一个代币，以及你在 X、Telegram 或 Bluesky 上信任的声音。它会读取每个人实际说了什么，检查这些声音彼此独立，还是同一论点被重复了三次，然后做出判断：

ENTER TOKENA  size 3.28%  confidence 0.66
  + independent_voices: 2 independent voice(s): voice_alpha, voice_gamma
  ~ echo voice_beta: marked as a repost or quote by the source
  ! wrong if price_usd < 1.0625 at any point within 72.0h (thesis fails if price falls 15% from entry)
  review at 2026-08-30T12:00:00Z

_{示例输出：真实引擎，合成输入。voice_alpha/voice_beta/voice_gamma 和 TOKENA 是虚构的测试样例，不是真实账户或真实代币。}

一年后再次运行相同输入，它会生成完全相同的决策 ID，因为决策过程不会触及网络、时钟或模型。它只会读取实际存储的内容。这就是整个项目：一种能让“证明一下”成为可执行命令，而不是 README 中一句承诺的架构。

正在评审？从 /judges 开始：已发布评分标准中的每一项，都对应一个你可以自行检查的页面或命令。 tryhanko.vercel.app 展示项目介绍和示例回执（合成输入，已标注）。/try 可以在浏览器中实时运行其中一部分，无需安装。完整技术详情请见 /docs。

---

**RYO-CHAN Hackathon 2026 提交项目，参加三个赛道。****赛道 1（自主 Agent）**就是上面的 Agent，专为 Multi-KOL Narrative Agent 专题打造。**赛道 3（新技能）**是 exit_liquidity：持仓退出的成本；如果有可执行的交易场所报价，就以此为依据，并采用 RYO 自己的响应格式。它也是 Agent 在投入前运行的规模门槛。**赛道 2（仪表板与界面）**包含三个屏幕：工作台、故障演练和回声指数。

已实时展示的内容

• 每三小时增长一次、无需密钥的账本。 定时工作流读取有关 BTC、ETH、SOL 和 BONK 的公开 Telegram、Bluesky 和新闻观点，做出判断，连同重放包一起封存本次运行，在 OpenTimestamps 上加盖时间戳，并提交到 live/。每项决策都会在 72 小时后，根据它预先写明的条件进行评分。 /ledger 按重要性从高到低展示自上次运行以来的变化（D-20）。
• 根据自身条件评分，包括判断错误时。 首批 32 项定时决策于 2026-10-27 和 28 日到期：所有 ENTER 决策都成立（7 项中 7 项，已实现收益率介于 -0.9% 和 +1.1% 之间）；25 项拒绝中有 7 项被证明是错误的，因为它们声称会促使判断反转的观点出现了。这些审查还发现了两个评分错误，已在 D-21 修复。
• 任何人都能重新推导的已封存实时 ENTER 决策。 BTC，2026-10-23，runs/run_836b976720f63dc0.json。清单列出了观察名单中的每个条目，包括 PASS 和两项 ABSTAIN。该记录锚定在比特币区块 972,817 中，该区块在封存 35 分钟后挖出；hanko verify-run 无需联网或密钥，即可根据已提交的数据包重放全部四项决策。（在 2026-10-24 之前，该数据包实际上并未纳入仓库；D-19。）
• 实测而非建模的退出成本。 BONK，$50,000：Jupiter 报价显示为 2.3%。该工具自身的恒定乘积模型给出的结果是 7.2%，报告直接列出 3.1x 的差距，而不加以掩饰。
• 审计 Agent 的研究。 Echo Index 使用 Hanko 的回声检测功能，检查了来自 15 个加密货币频道的 2,094 条真实帖子。回声膨胀为 1.005x，并如实公布。研究首先发现，Hanko 自身的检测器会漏掉在逐字复制内容中添加广告或页脚的情况（D-14，已修复）。
• 故意注入的九种故障。 RYO 下跌、所有来源都不可用、报价平台遭遇速率限制、模型不可用、模型实际服从了提示词注入、证据被篡改、已封存的运行记录被编辑、来源在扫描过程中失效、重启。九种情况全部通过，在 /drill 上实时计算。重启场景首次运行时未通过（D-18，已修复）。

判子是人们在文件上盖下、以示承诺的印章。印记会在结果揭晓前盖下，且无法撤回；这正是此 Agent 对每项决策所做的事：确定规模、做出承诺，并预先说明什么情况会证明它错了。

提交

• 项目提交表单（PDF，位于本仓库）
• 演示视频
• X 上的公告帖子

目录

• 在 60 秒内自行验证
• 适用对象
• 无需运行任何内容即可探索
• 唯一规则
• 结构
• 构建方式的原因
• 使用
• 状态
• exit_liquidity：全新 Track 3 技能
• 决策记录
• 审查循环
• 扫描
• 架构、决策与局限

在 60 秒内自行验证

无需实时凭据、账户或网络。以下每个数字都可由本仓库中已提交的合成测试数据重新生成（为测试编写的虚构观点和虚构代币，并非从真实账户采集）：

git clone https://github.com/IamHarrie-Labs/hanko && cd hanko
pip install -e ".[dev]"

pytest                                          # 349 tests, offline, ~20s

# make a decision, then prove it replays from stored bytes
hanko decide x --token TOKENA --subject voice_alpha --subject voice_beta \
  --subject voice_gamma --market fixtures/market_tokena.json \
  --as-of 2026-08-27T12:00:00Z --fixture fixtures/x_three_voices.json
hanko audit                                     # re-derives it, insists it reproduces

# the Track 3 skill, against the same fixture, no network
hanko exit-liquidity TOKENA --size 50000 --market fixtures/market_tokena.json

# the first live ENTER, re-derived from its committed bundle
hanko verify-run runs/run_836b976720f63dc0.json

# break it on purpose: nine failure scenarios, offline
python -c "from hanko.drill import run; print([r['held'] for r in run()])"

# re-derive every number in the Echo Index
hanko echo-index publish

适用对象

希望 Agent 的推理过程可审计，而不是只能盲目信任的开发者和交易者。他们可能曾被只会说“强烈买入信号”、却拿不出任何依据的机器人坑过，因此想看到证据、反证，以及坦诚说明的缺失之处。本次提交的评审也适用：他们可以根据决策所见的确切存储字节，重新验证任何决策，而不必相信本 README 中的说法。

本项目不适合任何希望 Agent 执行交易的人。它不会执行交易，而且根据本次黑客松自身的规则，它所基于的 RYO 工具也都不能执行交易。这里的一切都用于研究和仓位评估；没有任何功能会转移资金。

无需运行即可了解

打开	展示内容
tryhanko.vercel.app	项目介绍和示例决策凭证（使用真实引擎和合成测试输入，并明确标注）
/try	实时运行 exit_liquidity：RYO 事实、DexScreener 深度、Jupiter 报价，都封装在 RYO 的信封中
/judges	每条评审标准，以及对应的核验位置
/workbench	从示例决策中移除一种声音，或收紧阈值（使用合成输入，并明确标注），观察实际的 decide() 判定如何变化，以及触发变化的规则
/drill	在真实代码中注入的九个真实故障，以及实时计算出的每项防御
/echo	Echo Index：基于 2,094 条真实帖子，衡量加密货币共识中有多少只是同一声音的重复
/docs#track1-live	两个真实决策，实时 X 证据和实时 RYO 事实，均非挑选出来的案例
/docs#mcp-transport	实际的实时 MCP 握手和实时 x_search 调用会返回什么

/try，针对真实平台实时运行	/docs，完整技术说明

唯一规则

fetch()  touches the network, is allowed to fail, and is never deterministic
parse()  touches nothing, and is a pure function of its payload

Agent 只能看到 parse() 的输出。由于 parse() 是纯函数，且负载采用内容寻址，任何过往决策都可以根据存储的字节重新推导，并且必须得出相同的判定。如果在 parse() 中加入网络调用，推理轨迹就不再可复现，而整个提交所依赖的正是这一特性。

目录结构

hanko/provenance.py      canonical JSON, sha256 addressing, Status, Coverage
hanko/evidence.py        Evidence + Provenance: the source-agnostic unit
hanko/sources/base.py    the adapter contract
hanko/sources/xsearch.py X, via the xAI Responses API and its x_search tool
hanko/sources/rss.py     RSS/Atom: free, and the only source with trustworthy timestamps
hanko/sources/fixture.py local JSON: free development, and every failure mode in CI
hanko/snapshot/store.py  append-only content-addressed store, replay, integrity
hanko/ryotools/          the six RYO tools over MCP and REST; structural fact extraction
hanko/skills/exit_liquidity/  Track 3: what it costs to exit a position, not just enter one
hanko/review/outcome.py     grading a decision against its own commitment
hanko/review/reliability.py calibration, per-voice and per-rule track records
hanko/review/ledger.py      append-only reviews, one per decision
hanko/cli.py             collect / decide / review / scorecard / audit / verify

完整目录树：

hanko/
  sources/       X, RSS, fixtures -- fetch() impure, parse() pure
  snapshot/       append-only content-addressed store
  ryotools/       the six RYO tools, MCP + REST
  decision/       evidence quality, verdicts, falsifiers, the ledger
  review/         falsifier checking, calibration, reliability
  skills/exit_liquidity/   Track 3: exit cost, capacity, drift, turnover
  sweep.py, cli.py, config.py, provenance.py, evidence.py
site/            static landing page, /docs, /try -- the live web demo
  api/exit_liquidity.py    the /try endpoint, real assess() call, no fixture
tests/           349 tests, one file per hanko/ package
fixtures/        evidence and market fixtures used offline and in CI
.github/workflows/ci.yml       pytest on every push, Python 3.11 and 3.12
.claude/skills/hanko-exit-liquidity/SKILL.md   packages exit_liquidity as a Claude Skill
ARCHITECTURE.md  the one rule, the pipeline, the layers
DECISIONS.md     engineering decisions and the bugs that shaped them
LIMITATIONS.md   what hasn't been shown yet, and why
LICENSE          MIT

采用这种构建方式的原因

数据源可以互换。 Agent 无需了解证据来自何处。将 X 换成 Telegram，或将 Grok 换成直接 API，只需更换一个适配器，不会影响下游的任何部分。如果 x_search 在第 9 天弃用或价格高到无法承担，其他部分都无需变动。

这种替换是经过认真考虑的实际选项，而非假设：X 自己的 API 可直接返回结构化帖子，中间无需模型改述摘要，代价是需要单独的付费层级，且所需凭据与当前构建已有的凭据不同。以后值得这样做；但临近提交时，重写的风险不值得承担，因为适配器边界已经让将来的替换成本很低。

失败是数据，而不是异常。 收到请求却未响应的数据源会生成一份附带原因的 FAILED 快照。引发异常的适配器也会生成快照。沉默是这个存储唯一无法表示的结果；正因如此，头寸规模才能如实地根据证据缺失作出响应，而不是悄悄地把数据当作存在而继续执行。

三种不同的无结果状态彼此区分。 FAILED（数据源未响应）、包含零条内容的 OK（没有人发帖）以及 PayloadShapeError（收到的字节无法读取）是不同的事实。将它们合并，会让架构变更看起来像是市场风平浪静。

绝不夸大覆盖范围。 x_search 是搜索工具，不是时间线推送，因此其覆盖范围从定义上就是 UNKNOWN。声称覆盖范围为 COMPLETE，正是会夸大 KOL 共识数量的谎言。

只采集一次，免费开发。 真实快照只采集一次，之后的所有操作都基于存储的字节运行。开发和 CI 不花钱，也不会触及速率限制。每小时扫描 20 个账号时，实时采集约为每次调用 $0.005，整个构建约需 $25 到 $35。

使用

pip install -e ".[dev]"
pytest

hanko collect x --subject voice_alpha --subject voice_beta
hanko collect rss --subject https://example.com/feed.xml
hanko ls
hanko replay snap_7723f3520b7dfa2efa6856e3
hanko verify

离线运行，使用夹具：

hanko collect x --subject voice_alpha --fixture fixtures/x_three_voices.json

实时采集 X 时必须设置 XAI_API_KEY。未设置时，适配器会记录一份说明原因的 FAILED 快照，而不会抛出异常。

状态

349 项测试，全部离线运行，约 20 秒。在证据层覆盖：规范形式与地址稳定性、负载去重、防篡改检测、重放时适配器版本不匹配、重放确定性、证据身份固定到字节和位置，以及每种故障模式（速率限制、窗口不完整、结果为空、适配器抛出异常、数据源格式错误、负载不可读）。在决策层覆盖：回声降级、PASS 与 ABSTAIN 的区分、安全数据缺失／数据源故障／证据过期时机械地缩减规模、为入场和拒绝生成证伪条件、账本防篡改检测，以及从存储的字节端到端复现存储的决策。在审查层覆盖：检查证伪条件、盈利不能挽救已被证伪的论点、无法核查的指标保持未解决、结论不确定的审查不计入任何比率、回声既不获得功劳也不承担责备、校准，以及拒绝重新审查决策。

在 MCP 层：JSON-RPC 握手、会话处理、SSE 解码、所有传输故障模式，以及一项断言：从 MCP 负载中提取的事实与从 REST 负载中提取的事实完全相同。

已于 2026 年 8 月 28 日对照线上 API 确认。 x_search 不会返回结构化帖子对象。它返回模型对帖子的散文式呈现，以及一个 URL 引用数组。散文无法归属到特定帖子，因此适配器会请求 JSON 模式，然后根据工具自身的引用核验每个返回的帖子 ID：保留有引用的帖子，丢弃没有引用的帖子。这项检查能证明帖子存在且工具见过它；但无法证明模型忠实地转录了文本或时间戳，因此每条记录的这些字段都会标记为由模型转录。

已于 2026 年 9 月 5 日对照线上 RYO MCP 服务确认。 hanko tools、hanko facts SOL 和 hanko decide 均已在真实端点上运行，而非测试夹具。停止猜测后，有三项发现发生了变化：

工具目录中有六项工具，而不是黑客马拉松公开工具列表所列的七项。已认证的目录中没有 check_safety 和 supported_tokens；其中有 monitor_market_sentiment_shift，而之前完全没猜到它。六项工具中没有任何数值型安全分数，因此 MarketFacts 中的 safety_score 现在始终为 None，如实反映这一点。

参数键是 symbol（用于 analyze_token、deep_analysis）和作为一个逗号分隔字符串的 symbols（用于 compare_tokens），而不是 token。两种传输方式最初都是按后者猜测构建的，现在已修正以匹配实际情况。

REST 响应格式为 {"tool": ..., "result": {envelope}, "latency_ms": ...}；现在 _degraded() 读取的是信封自身的 status（ok／partial／unavailable）和 data_mode（live／mixed／simulated／unknown）。明确表示为 simulated 的响应会被视为与部分结果完全相同，因为平台声称绝不会发生的唯一造假，就是把模拟数据当作实时数据呈现。

更正，2026 年 9 月 22 日。 一次常规的 hanko audit 直接崩溃，报错为 PayloadShapeError: no message item in the response output。原因是一个标记错误：基于本地测试夹具数据构建的决策，被标记成了实时 X 数据源自身的 ID，而不是任何表示测试夹具的标记，因此重放时，真实适配器收到了它从未设计为可读取的字节。所有现有重放测试都未能发现此问题，因为每项测试都提供了自己的解析器，该解析器无条件返回测试夹具，而不是经过 hanko audit 实际使用的同一查找流程。完整说明、修复方案和用于验证修复的回归测试见 DECISIONS.md D-07。

尚未展示：基于真实结果的校准曲线、实时 ENTER，以及真实定价池。相关说明和原因已在 LIMITATIONS.md 中明确列出。

exit_liquidity，新的 Track 3 技能

这六个真实工具都在以某种方式回答：这值得入场吗？ 没有任何工具回答：这个仓位能平掉吗？平仓要付出什么代价？ 这个数字能把研究转化为交易。一个代币可能通过所有已测量的信号，但如果退出仓位会让价格下跌两位数，它仍然可能是个陷阱。

hanko exit-liquidity BONK --size 50000

OK  BONK  confidence high
  price $0.00000331 · 24h volume $1,395,538  (dexscreener)
  quoted: selling ~$50,000 on jupiter returns $48,886, 2.34% under its own near-mid rate (price impact plus fees, 5-hop route)
  model said 7.15% from $1,299,172 of on-chain depth
  the model overstates this exit's cost 3.1x: the route reaches concentrated liquidity a constant-product curve cannot see
  depth: 29 pools on solana, deepest $327,472, 1 rejected
  or exit over 8.6h at 10% of volume
  verdict from an executable jupiter quote; quotes move with the market

这是 2026-10-23 的实时输出，当时 RYO 自己的市场工具无法正常工作。RYO 从未公布过池子深度，因此 2.0 版会查询两个无需密钥的交易平台。DexScreener 会为代币的规范合约提供流动性池：绝不按代币符号搜索，因为那会返回冒牌池。Jupiter 会针对确切数量提供可执行报价。实测报价优先于模型，模型的误差也会并列显示。如果两个平台都没有响应，成本字段将为 null，绝不会是零。每个回答都采用 RYO 的公开响应封装格式，也通过 RYO 自己的 REST 路由结构（POST /api/tools/exit_liquidity/call）和 MCP 服务（/api/mcp）提供。

完整模型、诚实性约定和测试覆盖范围见 hanko/skills/exit_liquidity/README.md。 可在 tryhanko.vercel.app/try 上针对真实平台运行实时测试，但仅限少量代币和有上限的数量，以免公开页面对实时凭证进行无上限的调用。

Claude 技能

.claude/skills/hanko-exit-liquidity/SKILL.md 将这个确切命令封装为 Claude 技能：让 Claude Code 访问此代码库，它就可以直接回答“平掉这个仓位要花多少”，并受一条明确规则约束：回答中的每个数字都必须来自命令本身的输出，不得由模型编造或四舍五入。这是该工具对自身采用的同一套诚实性约定，如今也扩展到了运行它的人。

决策记录

一条记录会说明决策作出时的结论、依据的证据、采用的推理、缺失的信息，以及什么情况会证明结论有误。

hanko/decision/reading.py      interpretation, recorded once and frozen
hanko/decision/convergence.py  independence: is this many voices, or one echoed?
hanko/decision/quality.py      gaps, and the evidence-quality score that sets size
hanko/decision/policy.py       risk limits, hashed into every record
hanko/decision/engine.py       the verdict function -- pure by contract
hanko/decision/record.py       the record, and the commitment that names it
hanko/decision/ledger.py       append-only ledger, and the replay proof

引擎是纯函数。 decide() 只读取其参数，不读取其他任何内容：没有时钟、网络、模型调用或随机性。解读是唯一主观的步骤，因此会在上游完成，并固化到记录中。把大模型放进决策流程，回放就毫无证明力。

三种判定，而非两种。 ENTER、PASS（证据充分，且论据不支持入场）和 ABSTAIN（证据不足，无法判断是否支持入场）。把后两者合并，会让 Agent 声称自己持有一个实际上并不存在的市场观点。

数据缺失会以机械方式缩小仓位。 没有任何规则会说“如果无法获取安全信息，就把仓位减半”。信息缺口会降低完整性，完整性会降低证据质量，而证据质量决定仓位大小。四个质量组成部分会以加权几何平均数合并，因此任何一个组成部分为零，都会使总分归零。热情不能通过平均值掩盖缺失的安全检查。

会检查观点一致性是否独立。 三个账户引用同一个论点，实际上只是一个观察。把它算作三个，是多 KOL Agent 自信地犯错的最简单方式。每个回声都会连同它重复的帖子和被降级的原因一起记录。

每项决策都会预先登记其证伪条件。 证伪条件会在结果揭晓前写入，并由机械方式评估，且会哈希写入 decision_id。事后修改阈值、仓位大小或复核日期，就会得到不同的 id：这是一项新决策，而非对原决策的编辑。拒绝也同样需要承诺：PASS 会记录哪些情况会改变这一判定。

观察结果

hanko decide x --token TOKENA --subject voice_alpha --subject voice_beta --subject voice_gamma --market fixtures/market_tokena.json --as-of 2026-08-27T12:00:00Z --fixture fixtures/x_three_voices.json

ENTER TOKENA  size 3.28%  confidence 0.66
  dec_1c1fb9e7ae2020cb260d6f32
  evidence quality 0.82  (completeness 1.0, freshness 0.75, corroboration 1.0, independence 0.67)
  + independent_voices: 2 independent voice(s): voice_alpha, voice_gamma
  + safety: safety score 0.82
  ~ echo voice_beta: marked as a repost or quote by the source
  ! wrong if price_usd < 1.0625 at any point within 72.0h (thesis fails if price falls 15% from entry)
  ! wrong if independent_voices < 2.0 at review, within 72.0h (entry rested on convergence that no longer holds)
  review at 2026-08-30T12:00:00Z

  replayed from stored bytes: same decision id

三位作者提到了这个代币，其中两位彼此独立。换成没有安全评分、证据数量相同的市场 fixture，结果是 3.08%，而不是 3.28%。规则没有任何变化，变化的只是已知信息。

hanko audit 会根据存储的字节重新推导每项已记录的决策，并要求结果能够复现。这就是 CI 门禁，它将“保留可重复的推理轨迹”从 README 中的一句宣称变成构建失败条件。

复核流程

在 review_at 时，会根据观测到的事实评估每个证伪条件，并根据决策承诺的内容评级，而不是看它是否碰巧赚钱。

两者分歧的情况，比让人安心的情况多得多。某项交易可能有盈利，却仍被证伪：价格上涨了，但足以支撑仓位规模的流动性已经枯竭，这意味着推理是错的，结果只是运气。两项事实都会分别记录和报告。仅按利润评级，会让 Agent 学会重复侥幸得手的错误。

第三种结果最为关键。 如果证伪条件指定的指标在复核时不可用，该检查会标记为 UNCHECKABLE，绝不会悄悄算作通过。无法检查的决策，不等于正确的决策。结论不明的复核会从所有比率中排除，并作为单独的数字报告，因为默默丢弃无法验证内容的 Agent，等于在事后自行挑选样本来给自己打分。

拒绝也会评级。 PASS 会承诺哪些情况会使其结论翻转，因此，只标记自己实际采取的交易的 Agent，永远学不到谨慎的代价。

每项决策只复核一次，并强制执行。 反复复核直到答案变好，正是预注册要防止的失败，因此账本会拒绝第二次复核，而不是保留最新结果。

hanko review --observations fixtures/observations_day3.json --now 2026-08-30T12:00:00Z

FALSIFIED  TOKENA  (enter at confidence 0.66)
  dec_1c1fb9e7ae2020cb260d6f32 -> rev_24903844c6020591a568451b
  x price_usd observed at 1.02 at 2026-08-30T12:00:00Z; committed to being wrong if < 1.0625 at any point in the window -- thesis fails if price falls 15% from entry
  + liquidity_usd held against < 630000.0 across 1 sample at 2026-08-30T12:00:00Z -- no intermediate readings; last observed 880000.0
  + independent_voices observed at 2.0; holds against < 2.0
  realised return -18.4%  (recorded, not used to grade)

liquidity_usd 这一行准确说明了它检查的内容：一次读数，没有中间读数。price_usd 和 liquidity_usd 会根据决策与复核之间 hanko sweep --samples 记录的每个样本进行评级（D-13）——即使违规在复核时已经恢复，也仍会证伪它所违反的论点；仅凭窗口结束时的一次读数得出的复核会如实说明这一点，而不会暗示它监测了整个窗口。

评分卡

hanko scorecard

reviewed 2   scored 2   unverifiable 0
held 1   falsified 1   hit rate 50.0%   brier 0.2461

calibration        said     actual    n
  0.6-0.8         0.7       50.0%    2

voices
  voice_gamma               0.0%   1 scored
  voice_alpha              50.0%   2 scored

rules satisfied on decisions that later
  independent_voices       0.0% held
  conviction              50.0% held

预言是 0.7，正确率却只有 50%。这个 Agent 过度自信，而且会如实说明。

每种声音的可靠性都来自 Agent 自身经过审计的历史记录，而非根据关注者数量宣称；回声既不加分，也不扣分。没有经过评分决策的声音，其结果是 None，而不是 0%。报告为零会诋毁它，报告为 100% 则会抬高它。规则级可靠性回答了一个令人不安的问题：如果一条规则在失败案例中总是满足，那它就不是筛选条件，而是装饰品。

扫描

hanko decide 手动处理一个来源中的一个代币。真正的关注列表需要按计划对多个来源中的二十个代币执行相同操作，而且不能让某个失效的来源或异常代币拖垮整次运行。hanko/sweep.py 负责协调这些操作。

hanko sweep --watchlist watchlist.json --as-of 2026-08-27T12:00:00Z

每轮扫描：对关注列表中的每个条目进行决策，然后评估账本中所有到期的决策。失败的代币会记录在报告中，扫描会跳过它继续进行，而不是抛出异常；从关注列表中移除的代币，其尚未完成的决策仍会接受审核，而不会被遗弃。

一次扫描中的每个快照都使用扫描自身的 as_of 时间戳，而非实际墙上时钟。 一轮中的多次来源调用会占用几秒实际时间，但它们都属于同一个逻辑时刻。对未发生变化的来源重新运行扫描，应得到相同的 decision_id，而不是仅仅因为重试晚了一秒就生成新的 ID。

审核会重新获取最新数据，而不是使用冻结的数据。 fresh_observations() 会在审核时重新收集证据并重新推导 independent_voices，而不是复用原始决策中的数值。审核的意义在于了解当前情况；用“当时为真”的过时副本来评估决策，只会让决策自我评估。

--samples samples.jsonl 为时间窗口提供实际可检查的数据。 每轮扫描都会为每个关注列表中的代币追加一条市场读数，并复用该轮已获取的数据。之后到期的决策会根据自其作出以来记录的每条读数进行评估，而不只是审核时采集的那一条——这样，ANY_POINT_IN_WINDOW 证伪条件（D-13）就能捕捉到在到期前已经恢复的价格或流动性违规。省略该选项时，hanko sweep 会像以往一样只保留窗口结束时的读数；审核会说明使用了哪种方式。

此命令适合由已有调度能力的工具调用，例如 cron、定时 GitHub Action 或 Windows 任务计划程序。每轮运行后退出，而不是在进程内循环休眠。运行失败就是一次调用失败，而不是需要另行查找并终止的进程。

本仓库会运行一次扫描。.github/workflows/sealed-sweep.yml 每三小时封存一次 watchlist.live.json，完全不需要密钥；随后根据已提交的文件验证运行结果，升级所有待处理的 Bitcoin 证明，并为 /ledger 写入 live/summary.json：

hanko seal --watchlist watchlist.live.json --ledger live/decisions.jsonl   --reviews live/reviews.jsonl --samples live/samples.jsonl   --manifest-dir live/runs --interpreter lexicon --lookback-hours 24 --ots
hanko live-summary --dir live

--interpreter lexicon 是关键词读取器，经过训练后既能识别“Bitcoin”，也能识别“$BTC”，并且只匹配完整单词。--lookback-hours 24 只读取信息流最近一天的内容，因为 Telegram 页面或 RSS 信息流会保留数天的历史记录，否则这些内容会被评为过时（D-20）。

hanko sweep --watchlist fixtures/sweep_demo/watchlist.json \
  --fixture-dir fixtures/sweep_demo --as-of 2026-08-27T12:00:00Z

sweep at 2026-08-27T12:00:00+00:00
  ENTER   TOKENA  dec_5b2eadbf21bc8c073927b4ac

16 项测试，全部离线运行；使用 RYO 工具响应的夹具替身（FixtureFactsSource，其结构仿照实时工具来源，而不是证据结构的 FixtureSource），并结合现有证据夹具。覆盖范围包括：证据来源或事实工具失败时记为缺口而非抛出异常、一个异常代币不会取消整轮扫描、账本中已有的决策会跳过而不是重复添加、从关注列表中移除的代币仍会接受审核，以及审核会拉取最新观察结果，而不是原始决策中冻结的结果。

架构、决策与局限

• ARCHITECTURE.md：唯一规则、以图示呈现的流水线、各个包负责的内容，以及 exit_liquidity 如何使用与 decide() 内部运行的相同规模门槛来确定自身规模。
• DECISIONS.md：按发生顺序记录的 13 项工程决策，包括本次构建中发现并修复的若干真实错误，以及每个错误实际造成的影响。
• LIMITATIONS.md：尚未展示的内容，包括基于真实结果的校准曲线、实时 ENTER、真实定价池。坦诚陈述，不掺入状态说明段落。
• SEALING.md：hanko seal——完整观察名单运行的编号清单（没有任何遗漏，连错误也包括在内），锚定到公开的 OpenTimestamps 日历，并在结果揭晓前发布。

下一步

将 sweep、audit 和 scorecard 接入 CI 或定时运行，并将各个声音的可靠性反馈到证据权重中，让 Agent 自身的历史记录开始影响它的判断。

证据更新，2026 年 10 月 30 日

Hanko 2.0.0 已作为 io.github.IamHarrie-Labs/hanko 发布到官方 MCP 注册表。

• 回顾性基准比较：76 个符合条件且经过审查的机会中，Hanko 与一条简单规则选出的入场标的完全相同。该样本无法证明存在选择优势。使用 python scripts/compare_baseline.py 可复现。
• 一项 SOL 拒绝判断经加封后证实有误：原始承诺、审核时间较晚时的观察结果，以及额外声音能够和不能够证明的内容。

首次成功的模型读取工作流于 10 月 30 日为 run_547a6eaf6c69d992 加封：调用模型 21 次，没有回退，拒绝了 3 次未命名代币读数，并对全部 4 项决策进行了独立重放。其 Bitcoin 时间戳尚待确认。