根目录中文入口见 ../../README.zh-CN.md。
Agent 说做完，VALP 要证据。
Oh! My Agent Teams 是人类入口；VALP（Visible Agent Loop Protocol）是其
下方的可见证据与验收协议。执行成功不等于交付完成。
本页是中文注解，不是协议规范原文。若本页与 SPEC.md、schemas/ 或
valp audit 行为冲突，以英文规范和机器可验证规则为准。
VALP（Visible Agent Loop Protocol）是一个面向多 Agent 工作流的可见证据协议。
它解决的不是“怎么让模型更聪明”，而是一个更朴素的问题：
Agent 或 Runtime 说 done，用户凭什么相信？
VALP 要求任务过程留下可审计的证据：
所以 VALP 更像一个 acceptance system，而不是聊天提示词集合。
Doctor 观察能力护照 -> 用户选择 Installation Leader -> 发布任务
-> Leader 声明 WorkItem 与 Agent 分工 -> VALP 验证并由 Adapter 绑定 Worker、可见派送
-> submission receipt -> Worker evidence -> completion receipt
-> 验证 -> 独立审查 -> 修复/复审 -> 建议处理 -> 审批
-> final synthesis + feedback -> valp audit -> PASS / WARN / FAIL
-> 独立受 gate 约束的任务状态 -> Done / Blocked / Failed
-> 可选 Task Graph（单任务、确定性、只读）
完整时序见可见工作流，图谱边界见 Task Graph 与 Ontology。Task Graph 不能生成 proof，也不能 改变 audit。Neo4j 不属于 v0.3.0 发布版；后续如采用，也只能作为读取现有 ledger 的 可选 ontology 投影，不能成为路由、证据或审计权威。
当前正式发布版本是 v0.3.0，可使用不可变 tag 或对应 main commit。该版本已完成
required checks、external review、merge、不可变 tag、GitHub Release 和发布后 smoke。
版本历史与迁移说明见 版本与兼容性。
当前正式协议版本是 0.3.0，已发布 reference CLI 版本是 0.3.0。
RFC 0001 已接受，其
installation-control-plane core、schemas、claim/review、task reducer 和
local-process adapter 已在 reference CLI 中落地。Runtime 支持范围仍以具体
adapter 证据为边界。
可以把变化理解成：0.2.0 主要检查“这个任务凭什么算 Done”，0.3.0
进一步检查“管理所有任务的安装级控制平面凭什么可信”。
| 层面 | 0.2.0 任务层基线 |
0.3.0 实现 |
|---|---|---|
| 控制主体 | 每个任务根据当前能力证据选择 coordinator | 用户明确选择 Installation Leader；确定性 core 和 epoch 负责约束与 fencing |
| 能力真值 | 当前 scan、routing、provider matrix 和 task evidence | 持久 registry 分开记录 official_claim、local_presence、live_callable、task_verified |
| 执行契约 | task receipts、expected evidence、review、approval、audit | 严格 message、event-sourced state、claim-evidence、deterministic failure、exact-artifact review |
| Provider 边界 | Runtime adapter 导出同等 receipts 和 evidence | Provider plugin 使用 manifest、最小权限和隔离边界，不能直接改协议 core state |
| 稳定证明 | 仓库测试、bundled examples、跨平台 CI，以及本地 LangGraph API 的真实非 HERDR false-done E2E | 生产托管、真实 HERDR Full Mode 崩溃恢复、原生 Windows Full Mode 仍需独立证据 |
这里最重要的不是多几个名词，而是 proof bar：用户选择 Leader 不等于信任 Leader；发现 CLI、Skill 或 MCP 不等于已经能调用；Runtime completed 仍不等于 VALP Done；写完 RFC 更不等于功能已经发布。
v0.3.0 的稳定发布范围只覆盖协议与 reference CLI，不表示跨 runtime continuation
或生产部署已经普遍成立。当前 LangGraph 开发 runtime 的公开脱敏 E2E 只证明
该 adapter/runtime pair。请同时查看当前项目状态，
不要把局部证明扩张成通用平台承诺。
对外完整性按证据包判断，不按愿景判断：协议、reference CLI、runtime adapter、
Full Mode、跨重启 continuation、生产托管和平台支持分别需要自己的证据链。跨重启
continuation 不仅需要完整到 resume_consumed 的 ledger，还需要在 provider 已消费、
VALP 未落盘 receipt 之间注入崩溃后的重启对账与去重证据。缺少这些或独立生产运行证据时，
公开文案只能声明已有的协议与审计能力，不能声明对应 runtime 或生产能力已经完成。
VALP 不是：
HERDR 只是当前参考 Runtime。其他 Runtime 只要能导出同等的 receipts、 evidence、state mapping 和 audit 数据，也可以实现 VALP。
如果你要从 Forward-Deployed Engineer（FDE，前线部署工程师）的一线交付场景开始，请先读 FDE 现场交付 walkthrough。它把
valp configure、route validation、Task Graph 摘要和 valp audit 串起来，并
明确区分配置/源码证据、Runtime 证据与生产证据。
如果你只是想理解协议，不需要先安装 Runtime：
git clone https://github.com/wcqxgjy6d8-pixel/Visible-Agent-Loop-Protocol.git
cd Visible-Agent-Loop-Protocol
python -m pip install -r requirements-dev.txt
bin/valp audit examples/minimal-task
通过时你会看到：
VALP audit: PASS
Summary: pass=14 warn=0 fail=0
再看这个演示：
它会让你看到：删掉 expected evidence 后，即使 receipt 说结果已提交，
valp audit 也会失败。
| 英文术语 | 中文注解 |
|---|---|
| Runtime | 实际执行和记录任务的运行层，例如 pane controller、queue、hosted platform 或人工手动流程 |
| Dispatch | 发给某个 Agent 的可见任务分配 |
| Receipt | 机器可读的状态收据，例如 dispatch_submitted、dispatch_completed |
| Evidence | 能证明工作发生过的文件、日志、截图、命令输出、审查记录 |
| Expected evidence | 这个任务完成前必须出现的证据路径 |
| Audit | 用 valp audit 检查任务证据是否满足 Done Criteria |
| Correction cycle | 退件、重试、blocked、invalid、superseded 后的修复闭环记录 |
| Final synthesis | 最终总结，必须指出结果、决策、分歧和证据缺口 |
| Task Graph | 单个任务的确定性只读视图；显示已有 receipt、evidence 与 audit 摘要，不是权威 |
完整术语表见 glossary.md。
可以把 VALP 想成“多 Agent 工作流的验收单”：
不要只听 Agent 说 done
要看 dispatch、receipt、evidence、review、approval、final synthesis
最后跑 audit
这对中文社区尤其重要，因为很多 Agent 演示容易停留在“看起来完成了”。 VALP 关心的是：这个完成状态能不能被另一个人、另一个 Agent、或者 CI 重新检查。
bin/valp audit examples/minimal-task。如果要实现 Runtime adapter，直接读英文：